Different layers are identified when creating elements in a Data Virtualization project:

• Connectivity: Related to the physical systems. Data sources and base views are part of this level.
• Integration: Includes the combinations and transformations for the next layers. Not directly consumed views at this level.
• Business Entities: Canonical business entities exposed to all users.
• Report Views: Pre-built reports and analysis frequently consumed by users.
• Data Services: Web services for publishing views from other levels. Can contain views needed for data formatting and manipulation.

Data sources can be named as follows:

• ds_{data source name}
  
  • Examples:
    • ds_internet
    • ds_soap_billing
    • ds_phone

Base views can be named as follows:

• bv_{data source name}_{source table / description (if sql-query view) / source ws operation / stored procedure / ... (optional)}
  • {data source name} is the name of the data source over which the base view is created.
    • Examples:
      • bv_internet_incident
      • bv_phone_incident
  • {source table / description (if sql-query view) / source ws operation / stored procedure / ...} is the name of the table, stored procedure, web service operation or any descriptive text to identify what it is imported from the data source.
    • NOTE: It is optional if only one base view is created for a data source.
    • For example, to import a single XML file called “user_incidents.xml” in VDP the data source will be called “ds_user_incident” and the base view will be called “bv_user_incident”.
    • Example: bv_internet_incident

Using this naming convention the quick search will list all the views related to a specific data source when searching by the data source name.

With this approach, all the base views from a specific data source will also appear together if using external JDBC/ODBC clients to access a VDP database.

As defined in the project structure section, integration views are those derived views created for combination and transformation but they should not be directly accessed by final client applications. These integration views can be named as follows:

• iv_{integration view descriptive name}_{order #}_{action, description} (optional)
  
  • {integration view descriptive name} is the descriptive name for this integration view.
    • In order to get all related integration views ordered, it is recommended to use the same name for all of them.
    • This descriptive name can be:
      
      • Similar to the base view used.
      • Similar to the final view that will use this integration view.
    • Examples:
      • iv_data_customer_mail_03_flatten
        iv_data_personal_05_register_address
  • {order #} is the numeric value used to order the views.
    
    • If an integration view is created from different integration views, the new integration view should use the following number to the highest number of the views that the new view depends on.
    • Examples:
      
      • iv_data_customer_mail_03_flatten
      • iv_data_personal_05_register_address
  • {action, description} is a descriptive text about the action or meaning that identifies what the integration view does.
    
    • Examples:
      
      • iv_data_customer_mail_03_flatten
      • iv_data_07_union_customer_info

Interfaces should be named using a descriptive name that makes them easy to identify for final users:

• {interface name}
  
  • Examples:
    • customer
    • customer_address
    • customer_email

The name “final views” is applied to views that contain information that is directly accessed by external systems and/or published for their consumption. Final views can be named as follows:

• {identifier}_{by_input_parameters(optional)}
  
  • {identifier} is the identifier for this final view.
    
    • Examples:
      • customer
      • get_customer_info
  • {by_input_parameters} is used only if this view has mandatory input parameters.
    
    • Use the input parameters in the name of the view separated by “_”.
    • If the final view has a lot of input parameters, this notation should not be used.
    • Example: customer_search_by_name_lastname

Stored procedures can be named as follows:

• sp_{sp_name}_{by_input_parameters(optional)}
  
  • {sp_name} is the descriptive name of the stored procedure created
    
    • Example: sp_customer_global_search
  • {by_input_parameters} is used only if the stored procedure is always executed with input parameters.
    
    • Use the input parameters in the name of the stored procedure separated by “_”.
    • If the final view has a lot of input parameters, this notation should not be used.
    • Example: sp_customer_search_by_name_lastname

Associations can be named as follows:

• a_{principal entity name}_{related entity}
  
  • Example: a_customer_contract

The Web service/Widget name should be a business noun, a business concept, or a business process.

The naming of these elements depends on the specific customer/project naming conventions.

The Web Services operation names should be similar to the final view that implements the operation.

These are the naming conventions for published Denodo Web services:

• SOAP:
  
  • {web service name}:
    
    • Name of the Soap Web Service:
      
      • Should include the “service” suffix.
      • Should be in lowercase.
      • Should not use separators (“ “, “_”...).
      • Should be singular.
      • Should not use verbs.
    • Examples:
      • internetincident service
      • userinvoicing service
  • {Operations}:
    
    • Name of the Soap Web Service operations:
      
      • Should not include separators (“ “, “_”...).
      • Should use the name of the view.
      • Should use verbs.
    • Examples:
      • getINTERNETINCIDENTSBySTATUS
      • insertINTERNETINCIDENTS
• REST:
  
  • {web service name}:
    
    • Name of the REST Web Service:
      
      • Should not include the “service” suffix.
      • Should be in lowercase.
      • Can use the “_” separator.
      • Should be singular.
      • Should not use verbs.
    • Examples:
      • internet_incident
      • sale

JMS listeners can be named as follows:

• jms_{jms name}
  • Example: jms_customer

Summaries can be named as follows:

• s_{summary name}
  • Example: s_total_by_year_store

• Name identifier fields (id, code, ...) as “viewname_id”.
  
  • Example: If the view name is “bv_customer_mail” and it has an “id” field, it should be named “customer_mail_id”.
• Name fields from other views as “relatedviewname_id”.
• Name the input parameters as “input_descriptive_name”.