The denodo “Base Layer” in the Logical Data Warehouse (LDW) can be thought of as the Data Staging local layer in a more traditional data warehouse (DW) development pattern. The Base layer is the level at which the source system data structures are transformed into denodo field types and the source data structures are rendered as created in base views (bv).
Base views (bv), the first step in virtualizing data, are the denodo structures reflecting the source system structure and the second step behind the data source connection and, therefore, are essential elements for the other layers of the Logical Data Warehouse (LDW). To provide some guidance to facilitate the usefulness and performance of base views here are some best practices:
Use consistent Object Naming conventions. It is strongly recommended that the denodo standard naming conventions be used.
Create indexes on Primary Keys (PK), Surrogate keys, and Foreign Keys (FK)
Import and or create the Primary Keys (PK), Foreign Keys (FK), and Associations.
Have Statistics Collection been set and include all critical fields?
Base views, as a rule, should not be cached unless absolutely necessary for reasons of performance.
Create performance Indexes to mirror sources system to improve performance.
Populate view Metadata properties describing the type and the nature of the data which the view contains.
Populate field Metadata properties describing Field. This is important for a few reasons:
The description can be inherited by view built from the base view.
This populates the Denodo Metadata Catalog within which data Stewards can maintain and improve the description.
Informs other developers and user of what the field is/means.
Field metadata should be annotated with “Not Used”, if the field is always null, blank, or empty. This saves time and labor when researching data issues
Retain the original table name (applying naming convention prefix and field names to facilitate data Lineage traceability.?
Use denodo tools against tables, where possible, rather than (Manual) SQL views, Database views, or Stored Procedure. Denodo cannot rewrite or optimize these objects.
In denodo associations follow the same concept as modeling
tools, which can be described as an ‘on-demand join.’
Should Associations Be Created In the Denodo Model?
You don’t necessarily need to define an Association at every
level; usually, the best practice is to apply associations at the following
On final views published for data consumers,
indicating relationships between related views; Especially, on published web
On the component views below, any derived view
that brings together disparate (dissimilar) data sources. The associations should be defined as
Referential Constraints whenever appropriate to aid the optimization engine.
On the component views below, any derived view
that joins a “Base View from Query” with standard views, since Base
Views from Query cannot be rewritten by the denodo optimization engine. Often Base Views from Query create
These best practices should cover the majority scenarios;
beyond these guidelines, it is best to take an ad-hoc approach to create
Associations when you see a specific performance/optimization.
Are Associations important in Denodo?
In a nutshell, associations performance and the efficiency
of the denodo execution optimizer along with other model metadata, such as:
A coworker recently asked a question as to whether denodo
generated joins automatically from source RDBMS database schema. After searching, a few snippets of
information became obvious. First, that
the subject of inheriting join properties was broader than joins and needed to
in modeling associations (joins on demand). Second, that there were some denodo
design best practices to be considered to optimize associations.
Denodo Automatically Generate Joins From the Source System?
After some research, the short answer is no.
Denodo Inherit Accusations From A Logical Model?
The short answer is yes.
Denodo bridges allow models to be passed to and from other
modeling tools, it is possible to have the association build automatically,
using the top-down approach design approach and importing a model, at the
Interface View level, which is the topmost level of the top-down design
However, below the Interface view level, associations and or joins are created manually by the developer.
A Denodo virtualization project typically classifies the
project duties of the primary implementation team into four Primary roles.
Denodo Data Virtualization Project Roles
Data Virtualization Architect
Denodo Platform Administrator
Data Virtualization Developer
Denodo Platform Java Programmer
Data Virtualization Internal Support Team
Project Team Member Alignment
While the denodo project is grouped into security permissions and a set of duties, it is import to note that the assignment of the roles can be very dynamic as to their assignment among project team members. Which team member who performs a given role can change the lifecycle of a denodo project. One team member may hold more than one role at any given time or acquire or lose roles based on the needs of the project.
virtualization Project Roles Duties
The knowledge, responsibilities, and duties of a denodo data
virtualization architect, include:
A Deep understanding of denodo security features
and data governance
Define and document5 best practices for users,
roles, and security permissions.
Have a strong understanding of enterprise
Defines data virtualization architecture and
Guides the definition and documentation of the
virtual data model, including, delivery modes, data sources, data combination,
The knowledge, responsibilities, and duties of a Denodo Platform
Denodo Platform Installation and maintenance, such as,
Installs denodo platform servers
Defines denodo platform update and upgrade policies
Creates, edits, and removes environments, clusters, and servs
Manages denodo licenses
Defines denodo platform backup policies
Defines procedures for artifact promotion between environments
Denodo platform configuration and management, such as,
Configures denodo platform server ports
Platform memory configuration and Java Virtual Machine (VM) options
Set the maximum number of concurrent requests
Set up database configuration
Specific cache server
Authentication configuration for users connecting to denodo platform (e.g., LDAP)
Secures (SSL) communications connections of denodo components
Provides connectivity credentials details for clients tools/applications (JDBC, ODBC,,,etc.)
Configuration of resources.
Setup Version Control System (VCS) configuration for denodo
Creates new Virtual Databases
Create Users, roles, and assigns privileges/roles.
Execute diagnostics and monitoring operations, analyzes logs and identifies potentials issues
Manages load balances variables
The Data Virtualization Developer role is divided into the
the knowledge, responsibilities, and duties of a Denodo Data
Virtualization Developer, by sub-role, Include:
The denodo data engineer’s duties include:
Implements the virtual data model construction
Importing data sources and creating base views,
Creating derived views applying combinations and
transformations to the datasets
Writes documentation, defines testing to eliminate
development errors before code promotion to other environments
The denodo business developer’s duties include:
Creates business vies for a specific business
area from derived and/or interface views
Implements data services delivery
The denodo application developer’s duties include:
Creates reporting vies from business views for
reports and or datasets frequently consumed by users
Denodo Platform Java
The Denodo Platform Java Programmer role is an optional,
specialized, role, which:
Creates custom denodo components, such as data sources, stored procedures, and VDP/iTPilot functions.
Implements custom filters in data routines
Tests and debugs any custom components using Denodo4e
Internal Support Team
The denodo data virtualization internal support team’s duties
Access to and knowledge of the use and trouble
of developed solutions
Tools and procedures to manage and support
project users and developers
Denodo provides some general Virtual Dataport naming
convention recommendations and guidance.
First, there is the general guidance for basic Virtual Dataport object
types and, secondly, more detail naming guidance recommends.