Velocity - Naming Conventions - Data Quality

• Print

User Rating: 5 / 5

Please Rate Vote 5  Rate

Details
Last Updated: June 28, 2015
Hits: 18277

Naming Conventions - Data Quality

Challenge
Standard naming conventions facilitate smooth migrations and improve readability for anyone reviewing or
carrying out maintenance on repository objects. If inconsistent names and descriptions are used, significant time may
be needed to understand the workings of mappings and transformation objects. If no description is provided, a developer
is likely to spend considerable time going through an object or mapping to understand its objective.

Description
Naming standards are an important but often overlooked component when considering the success of a project. The
application and enforcement of naming standards not only establishes consistency in the repository but provides for a
developer-friendly environment. In addition, the names of artefacts can convey relevant information for tracking and
management purposes. Choosing and adhering to a common convention is the key.

It is also important to consider the different ways in which artefacts and objects are viewed. For example, the Informatica
Analyst and Developer tools provide a contextual view to the objects in the Model Repository. Other perspectives, such as
published Model Repository views or external spreadsheets for specifications can leave the user less aware of the context
and potentially confused over what artefacts they are viewing.

This document offers standardized naming conventions for various repository objects. Whatever convention is adopted, it
is important to make the selection very early in the development cycle and communicate the convention to project staff
working on the repository. The policy can be enforced by peer review and at test phases by adding processes to check
conventions both to test plans and to test execution documents.

It is important to note that the casing of the names does matter. Name values are stored in the repositories in the chosen
case, so words with different cases are not the same. However, names at the same hierarchy level cannot be
differentiated by case alone. For example, it is not possible to have the following two projects in a single model repository,
“DQ_Content” and “DQ_CONTENT”.

Administration Console Objects

Administration console objects such as domains, nodes, and services should have meaningful names. Details for these
can be found in Informatica Platform Naming Conventions. It covers organizational, environment and service notation. It
should be noted that while these services are all listed together in the examples, this should not be taken as an
architectural recommendation that all services are placed in a single domain.

Database Connection Information

Security considerations may dictate using corporate naming standards for the database or project instead of {user}_
{database name}_CONN. Possible exceptions are developer scratch schemas, which are not found in test or production
environments. Be careful not to include machine names or environment tokens in the database connection name.
Database connection names must be very generic to be understandable and ensure a smooth migration.

To ease promotion across environments, keep the connection names the same in the Domains across the migration
landscape. The naming convention should be applied across all development, test and production environments. This
allows seamless migration when migrating between environments. As an example, if the developer created a mapping
with a connection to a Data Warehouse named the same and of the same type of database but that physically differs in
each of the three environments, when the administrator imports a project folder from the development environment to the
test environment, the mappings automatically use the existing connection in the test repository. With a consistent naming
convention across environments, physical data objects can be migrated from the test to the production model repository
without manual intervention.

jueves, 23 de agosto de 2018 Página 1 de 13

Velocity - Naming Conventions - Data Quality
As indicated above, certain artifacts can be visible through other interfaces such as the Model Repository Views. It is
therefore a good practice to include some clarification on the connection names so the content (name value), can verify
what it reported through the views. Ending the connection name with _CONN or _CON can help later on.

Note: At the beginning of a project, have the Repository Administrator or Database Administrator (DBA) set up all
connections in all environments based on the guidelines covered in this Best Practice. Then use permission options to
protect these connections so that only specified individuals or groups can modify them. As developers create artifacts for
reuse, they normally need access to database service accounts for sources and targets. It is usually a best practice to
restrict developers from creating their own connections and thus introducing possible variations on connection information
for promotable artifacts across the migration landscape. As row and column data access restrictions may apply to
Analysts in Production and across the migration landscape, there may be a need to permit those users to define their own
connections via the standard of {user}_{database name}_CONN, depending on the database type connection. The
database then controls the visibility the user has to the data. This is where the pass through credentials security option
available for some DBs may come in handy, particularly if authentication is outside the domain, such as via LDAP or SSO.

Analyst Tool Objects

Suggested Naming Conventions

The Analyst Tool and its heaviest users require additional consideration. Some, but not all Model Repository artefacts are
visible from within the Analyst Tool. Business users and analysts normally need a more descriptive approach that leads to
less abbreviation. Many of the artefacts created by analysts, start with the default prefixes. It is typically best to adopt this
approach as a standard.

Artefacts requiring some development effort can still be helped with some standard abbreviation as some development is
impacted by the length and format of the name. Below, note that Data Object Name reflects the standard default but for
each of these objects a description can be added in the comments.

The Rule is a bit different as it is a function. If it is a data quality rule, the Description could include a qualifier as to what
type it is. Examples can include: COM=>Completeness, CNF=>Conformity, CON=>Consistency, ACC=>Accuracy,
VLD=>Validity, DUP=>Duplication, INT=>Integrity, and TIM=>Timeliness. Optionally, the rule name description potion
could also contain specific logical entity types like: customer, product, order, service, and others. Other options include
specific logical attribute types (e.g., given_name, surname, phone, and email) if applicable. It is also important to consider
identifiers linking artifacts to outside specifications for the purpose of traceability.

Table 2: Object Developer Tool Object Naming Conventions

Developer Tool Objects Suggested Naming Conventions

Rule Rule_[DESCRIPTION]

Data object profile Profile_[DATA OBJECT NAME]

Scorecard Scorecard_[DESCRIPTION]

Physical Data object pdo_[DATA OBJECT NAME]

Mapping Specification (Logical

ms_[DATA OBJECT NAME]{_[DESCRIPTION]}
Data Object)

Logical Data Object ldo_[DATA OBJECT NAME]{_[DESCRIPTION]}

Projects

The objects are organized by project in the Analyst Tool. Project names should be meaningful and include the name or
identifier and whether its objects are reusable or not. To accomplish this, give projects a meaningful name based on the
business group or purpose.

Project folders are listed in alphabetical order in many of the object navigation screens. As a result, use prefixes in project
names to enforce a sort order so that is easier to see relevant groups.

jueves, 23 de agosto de 2018 Página 2 de 13

Velocity - Naming Conventions - Data Quality
A set of examples for project name prefixes are shown in Table 2.

Table 2: Project Name Prefixes

Type Description

Shared projects can be read by all users. They should be used to contain common
objects for all developers or analysts such as reusable content or accelerators*.

Shared i.e., a_Shared_Project

*As a best practice, all out-of-the-box content and accelerators from Informatica
should be kept in a single project named “Informatica_DQ_Content”.

Project specific is where all the completed work needs to be kept. These projects
are driven by the business and should be created as non-shared. Only developers
assigned to the project or users should be granted the rights to access these
Project Specific projects.

i.e., b_Project

Each IDQ Developer and Analyst should be given a project to use as a sandbox.

Developer or Analyst

i.e., z_Developer_Name

This way the Shared Projects appear at the top, User Projects appear at the bottom and Business Projects appear in the
middle as shown in Fig 1.

Fig 1: Project Names with Prefixes Enforcing Sorted Display Order

Note: To simplify promotion from environment to environment, keep the promotable project names the same across the
migration landscape.

Folders

jueves, 23 de agosto de 2018 Página 3 de 13

Velocity - Naming Conventions - Data Quality
Use folders to organize objects in a project. Create folders to group objects based on business needs and to keep the
objects organized.

Dictionary and Reference Data Table Names

These names should first follow the naming constraints of the underlying database repository. Either project or usage
prefixes should be assigned. This will designate where or how they are being used. Next, they should contain descriptions
of their content.

• Format - [Project or usage prefix]_[Description of data]

• Example - [BI_PROJ_ACCOUNT_TYPE]

Rule Comments

These comments are used to explain the process that the rule carries out. Informatica recommends reviewing the notes
regarding descriptions for the input and output transformation.

Developer Objects
Projects

Refer to the Analyst Tool Objects section

Folders

Refer to the Analyst Tool Objects section

Work Area

Individual developer folders or non-production folders should prefix with z_ so that they are grouped together and not
confused with working production folders, see Fig 2 for an illustration of this.

Fig 2: Functional Ordered Folders through Standardized Prefixes

Suggested Naming Conventions

Table 3: Further Developer Tool Object Naming Conventions

Developer Tool Objects Suggested Naming Conventions

dqm_{PROCESS}_{SOURCE_SYSTEM}_{TARGET_NAME} or suffix with _{descriptor} if

Mapping
there are multiple mappings for that single target table

jueves, 23 de agosto de 2018 Página 4 de 13

Velocity - Naming Conventions - Data Quality

Developer Tool Objects Suggested Naming Conventions

Mapplet mplt_{DESCRIPTION} or rule_{DESCRIPTION} if the mapplet can be validated as a rule

Rule Rule_{DESCRIPTION} if the mapplet can be validated as a rule

Physical Data object pdo_{PHYSICAL_OBJECT_NAME}

Logical data object model LDOM_{DESCRIPTION}

Logical data object LDO_{DESCRIPTION}

Custom data object CDO_{DESCRIPTION}

{update_types(s)}_{TARGET_NAME} this naming convention should only occur within a

mapping as the target object name affects the actual table that the Data Integration Service
Write will access

i.e. Insert_Sales_DQHub or Update_Sales_DQHub

Address Validator AVA_{DESCRIPTION} that uses the cycle which passes the data is taking through the
Transformation transformation

AGG_{FUNCTION} that leverages the expression and/or a name that describes the
Aggregator Transformation
processing being done

AST_{FUNCTION} that leverages the expression or a name that describes the processing
Association Transformation
being done

Case Converter
CCO_{DESCRIPTION}
Transformation

Classifier Transformation CLA_{DESCRIPTION}

Comparison Transformation CMP_{DESCRIPTION}

Consolidation
CNS_{DESCRIPTION}
Transformation

Custom Data
CD_{DESCRIPTION}
Transformation

Decision Transformation DEC_{DESCRIPTION}

EXC_{DESCRIPTION} or EXC_{EXCEPTION_TABLE_NAME} with _{DESCRIPTION} if

Exception Transformation
additional information are required

EXP_{FUNCTION} that uses the expression and/or a name that describes the processing
Expression Transformation
being done

jueves, 23 de agosto de 2018 Página 5 de 13

Velocity - Naming Conventions - Data Quality

Developer Tool Objects Suggested Naming Conventions

Filter Transformation FIL_ or FILT_{FUNCTION} that leverages the expression or a name that describes the
processing being done

Java Transformation JV_{FUNCTION} that describes the expression or the processing carried out

Joiner Transformation JNR_{DESCRIPTION}

Key Generator KGN_{DESCRIPTION}

Labeler Transformation LAB_{DESCRIPTION}

LKP_{TABLE_NAME} or suffix with _{descriptor} if there are multiple lookups on a single

Lookup Transformation
table. For unconnected lookups, use ULKP in place of LKP

Match Transformation MAT_{DESCRIPTION}

Merge Transformation MRG_{DESCRIPTION}

Parser Transformation PRS_{DESCRIPTION}

RNK_{FUNCTION} that leverages the expression or a name that describes the processing
Rank Transformation
being done

Read Transformation SRC_{DESCRIPTION}

Router Transformation RTR_{DESCRIPTOR}

Sorter Transformation SRT_{DESCRIPTOR}

SQL Transformation SQL_{DESCRIPTOR}

Standardizer
STD_{DESCRIPTION}
Transformation

Union Transformation UN_{DESCRIPTOR}

Update Strategy UPD_{UPDATE_TYPE(S)} or UPD_{UPDATE_TYPE(S)}_{TARGET_NAME} if there are

Transformation multiple targets in the mapping. E.g., UPD_UPDATE_EXISTING_EMPLOYEES

Weighted Average
WAV_{DESCRIPTION}
Transformation

Web Service Consumer WSC_{DESCRIPTION}

REST Web Service RWSC_{DESCRIPTION}

Consumer

jueves, 23 de agosto de 2018 Página 6 de 13

Velocity - Naming Conventions - Data Quality

Developer Tool Objects Suggested Naming Conventions

Sequence Generator SEQ_{DESCRIPTION}

Data Masking DMK_{DESCRIPTION}

Data Processor DPR_{DESCRIPTION}

Rule/Mapplet Descriptions

When a mapplet is validated as a rule, it will be available in the Analyst Tool. For this reason, rules and mapplets should
be given a meaningful description that can be easily interpreted by a Business Analyst or Business user. The descriptions
for the individual transformations are not exposed in the Analyst tool and should be written for a technical developer and
describe what each transformation is doing.

Workflow Objects

Workflow object naming conventions are shown below in Table 3.

Table 3: Workflow Object Naming Conventions

Developer Tool Objects Suggested Naming Conventions

Notification Task EML_{DESCRIPTION}

Exclusive Gateway Task EXG_{DESCRIPTION}

Assignment Task AST_{DESCRIPTION}

Command Task CMT_{DESCRIPTION}

HMT_{DESCRIPTION} or HT_{EXCEPTION_TABLE_NAME} with _{DESCRIPTION} to

Human Task
include the exception table name used for the human task

Mapping Task MPT_{DESCRIPTION} or MPT_{MAPPING_NAME}

Cluster Step CLS_{DESCRIPTION}

Exception Step EXS_{DESCRIPTION}

Review Step RVS_{DESCRIPTION}

Workflow WKF or WF_{DESCRIPTION}

Applications

Application names can be created to logically group objects based on Effort, Subject Area, Type of object etc. While it is
possible to create applications with the same names between Projects/Folders, one might overwrite the other on the Data
Integration Service when deployed so it is recommended that application naming conflicts are avoided.

If the environment is going to be shared:

jueves, 23 de agosto de 2018 Página 7 de 13

Velocity - Naming Conventions - Data Quality
• Always prefix the Application name with app_ and the Effort Identifier. A version number is also recommended, e.g.
app_EDW_ln_Address_Validation_v10.
• Always create Applications at the Project level and not within the Folders (to avoid clashes within the Project).

Port Names

Port names should remain the same as the source unless some other action is performed on the port. With respect to port
names, please keep in mind how autolink works. If a transformation connects to Sources, the same names are needed for
autolink to work. The same is true for Targets. The best approach is to use the port naming conventions so that work is
reduced. Unless the contents provided by a port are physically changed, it does not need to be (and should not be)
renamed. In that case, the port should be prefixed with the appropriate name.

For lookup transformations, the source/input port should be prefixed with in_. This allows users to immediately identify
input ports without having to line up the ports with the input checkbox. In other types of transformations, prefix the input
port with in_ if some process is applied in the transformation (and a corresponding output port was created as a result of
the process).

Generated output ports can also be prefixed. Along with selecting the port in developer tool and selecting the link path,
this helps to trace the port value throughout the mapping as it travels through other transformations. If the intention is to
use the autolink feature based on names, then output ports should be left as the name of the target port in the subsequent
transformation. For variables inside a transformation, the developer can use the prefix v, 'var_ or v_' plus a meaningful
name.

With some exceptions, port standards apply when creating a transformation object. The exceptions are the Read, Lookup
and Write transformation ports since these should be the same as the underlying data structures.

The following lists the most commonly used port names:

• in_ or i_ for Input ports

• o_ or _out for Output ports
• io_ for Input/Output ports
• v,v_ or var_ for variable ports
• lkp_ for returns from lookups

Prefixes on ports are preferable, as they are generally easier to identify as transformed; developers may not need to
expand the columns to see the suffix for longer port names.

Transformation object ports can also:

• have the read transformation port name

• be unique
• be meaningful
• be given the target port name

Exception Tables

An exception table created by the exception transformation or simply used by that transformation should follow a specific
naming convention, such as that shown in Table 4 below.

Table 4: Exception Tables

Object Recommended Naming Convention Example

Exception table EX_ or X_ followed by [OBJECT_NAME] X_Customers

Note: The table description along with the prefix total length must be less than 25 characters as another table is created
with the suffix “_ISSUE” and many of the database management systems do not allow more than 30 characters. Column
names are also an issue and must be less than 19 for the exception transformation as many database management
systems do not permit names longer than 30 characters and the exception transformation reserves 11 characters out of
that 30 for its own needs.

Transformation Descriptions
This section defines the standards to be used for transformation descriptions in the Developer Tool.

Fig 3: Transformation Description Space

jueves, 23 de agosto de 2018 Página 8 de 13

Velocity - Naming Conventions - Data Quality

As part of best practice development, transformations descriptions are expected to describe the following points for each
transformation.

Read Transformation Descriptions

As part of best practice transformations

• The purpose of the Read Transformations and the data it is intended to select.
• Indicate if any overrides are used and if so, describe the filters or settings used. Some developers prefer items
such as the SQL statement to be included in the description as well. NOTE: Use of SQL overrides is discouraged
as it disables the licensable push down optimization feature.

Lookup Transformation Descriptions

Describe the lookup along the lines of the [lookup attribute] obtained from [lookup table name] to retrieve the [lookup
attribute name].

• Lookup attribute – is the name of the column being passed into the lookup and is used as the lookup criteria.
• Lookup table name – is the table on which the lookup is being performed.
• Lookup attribute name – is the name of the attribute being returned from the lookup. If appropriate, specify the
condition when the lookup is actually executed.

It is also important to note lookup features, such as persistent cache, etc.

Expression Transformation Descriptions

Expression transformation descriptions should adhere to the following format: This Expression [explanation of what the
transformation does].

• Expressions can be distinctly different depending on the situation; therefore, the explanation should be specific to
the actions being performed.
• Within each Expression, transformation ports have their own description in the format: This port [explanation of
what the port is used for].
• In mapplets as well as mappings it is a common practice to route the input or output through an expression (e.g.
exp_src_xxx, exp_tgt_yyy) before connecting those ports to other transforms as this minimizes the effort to change
sources or targets later. In some cases for development purposes, the source or target may start as a flat file and
later be changed to a table, logical data objects or web service.

Aggregator Transformation Descriptions

Aggregator transformation descriptions should adhere to the following format: This Aggregator [explanation of what the
transformation does].

• Aggregators can be distinctly different, depending on the situation; therefore the explanation should be specific to
the actions being performed.
• Within each Aggregator, transformation ports have their own description in the format: This port [explanation of
what the port is used for].

Joiner Transformation Descriptions

Joiner transformation descriptions should adhere to the following format: This Joiner uses [joining field names] from
[joining table names].

• Joining field names are the names of the columns on which the join is done.
• The joining table names are the tables being joined.

jueves, 23 de agosto de 2018 Página 9 de 13

Velocity - Naming Conventions - Data Quality

Filter Transformation Descriptions

Filter transformation descriptions should adhere to the following format: This Filter processes [explanation].

• Explanation describes the filter criteria and what they do.

Update Strategies Transformation Descriptions

Describe the Update Strategy and whether it is fixed in its function or determined by a calculation.

Sorter Transformation Descriptions

Describe the port(s) that are being sorted and their sort direction.

Router Transformation Descriptions

Describe the groups and their functions.

Union Transformation Descriptions

Describe the source inputs and indicate what further processing on those inputs (if any) is expected to take place in later
transformations in the mapping.

Java Transformation Descriptions

Describe the function of the Java code, what data is expected as input and what data is generated as output. Also,
indicate whether the Java code determines the object to be an active or passive transformation.

Rank Transformation Descriptions

Indicate the columns being used in the rank, the number of records returned from the rank, the rank direction and the
purpose of the transformation.

Address Validation Transformation Descriptions

The address validation transformation descriptions should describe the input type: multiline, discrete or hybrid. It should
also specify the output type.

Association Transformation Descriptions

The association transformation descriptions should list the fields used for association.

Case Converter Transformation Descriptions

The case converter transformation descriptions should explain the main goal of the case conversion.

Classifier Transformation Descriptions

The classifier transformation descriptions should describe the goal of the classifying operation and which probabilistic
model is used to perform it.

Comparison Transformation Descriptions

The comparison transformation descriptions should describe the comparison algorithm used to calculate the score output.

Consolidation Transformation Descriptions

The consolidation transformation descriptions should list the association ID used for the consolidation and the different
consolidation type used on the different fields consolidated (most frequent, most non null, etc.).

Data Masking Transformation Descriptions

The data masking transformation descriptions should include input/outputs and data masking types being used.

Data Processor Transformation Descriptions

jueves, 23 de agosto de 2018 Página 10 de 13

Velocity - Naming Conventions - Data Quality
The data processor transformation descriptions should list the script type and description of the message being parsed.

Decision Transformation Descriptions

The decision transformation descriptions should explain the main goal of the algorithm. More descriptive information can
be added at the strategy level.

Exception Transformation Descriptions

The exception transformation descriptions should specify the type of exception (duplicate exception or bad record
exception), the exception table name and the list of fields for which exceptions are generated (in case of bad record
exception).

Key Generator Transformation Descriptions

The key generator transformation descriptions should explain the key generation strategies used to generates the groups.

Labeller Transformation Descriptions

The labeller transformation descriptions should explain what the labeller transformation is actually labelling. It should
specify if this is using probabilistic labelling or traditional reference data labelling.

Match Transformation Descriptions

The match transformation descriptions should list the type of match operation executed (traditional or Identity Match
Option (IMO)), whether it is using a match rule and which group keys are expected.

Merge Transformation Descriptions

The merge transformation descriptions should explain the main goal of the merge operation.

Parser Transformation Descriptions

The parser transformation descriptions should explain what the parser transformation is actually parsing. It must specify if
this is using a probabilistic parsing or a traditional token parsing.

REST Web Service Consumer Transformation Descriptions

The REST Web Service Consumer transformation descriptions should include WSDL information and mapping operation
inputs and outputs.

Sequence Generator Transformation Descriptions

The sequence generator descriptions should explain any configurations for sequence range or reset values.

SQL Transformation Descriptions

The SQL transformation descriptions should explain the purpose of the SQL transformation and list the tables involved in
the SQL query, which fields are used as parameters and the fields that are returned.

Standardizer Transformation Descriptions

The standardizer transformation descriptions should explain the actual goal of the standardization operation, which type of
data is standardized and what is the expected result.

Web Service Consumer Transformation Descriptions

The Web Service Consumer transformation descriptions should include WSDL information and mapping operation inputs
and outputs.

Weighted Average Transformation Descriptions

The weighted average transformation description should list the expected input weight and give a goal of the computed
weight given as output.

jueves, 23 de agosto de 2018 Página 11 de 13

Velocity - Naming Conventions - Data Quality

Write Transformation Descriptions

• Indicate the purpose of the Write Transformations and the data it is intended to select.
• Indicate if any overrides are used and if so, it should describe the filters or settings used. Some developers prefer
items such as the SQL statement to be included in the description as well. NOTE: Use of SQL overrides is
discouraged as it disables the licensable push down optimization feature.
• Indicate any update strategy being used for the write target

Workflow Task Descriptions

This section defines the standards to be used for task descriptions in the Developer Tool.

Notification Task Descriptions

The notification task descriptions should describe the type of notification sent to the user and who is the audience of this
notification.

Exclusive Gateway Task Descriptions

The exclusive gateway task description should describe the purpose of the gateway, what sequence flows are generated
and which is the default.

Assignment Task Descriptions

The assignment task descriptions should describe the purpose of the variable assignment operation and which variables
are impacted.

Command Task Descriptions

The command task descriptions should specify what actions are performed and which type of commands are executed.

Human Task Descriptions

The human task descriptions should specify the exception table, the participant types and if there is any notification
generated.

Mapping Task Descriptions

The mapping task descriptions can reuse the mapping description.

Human Task - Step Descriptions

This section defines the standards to be used for step descriptions in the Developer Tool.

Cluster Step Descriptions

The cluster step descriptions should describe the type of data to be reviewed, if there is any time out, which types of users
are involved and the list of notifications setup.

Exception Step Descriptions

The exception step descriptions should describe the type of data to be reviewed, if there is any time out for the step,
which types of users are involved and the list of notifications setup.

Review Step Descriptions

The review step descriptions should describe the type of data to be reviewed, if there is any time out for the step, which
types of users are involved and the list of notifications setup.

Workflow Comments
Workflow comments should cover a number of areas and provide relevant information about:

• the workflow purpose and function

• the type of exceptions reviewed (if needed)

jueves, 23 de agosto de 2018 Página 12 de 13

Velocity - Naming Conventions - Data Quality
• the Frequency the workflow should be run
• any timeout limits that have been set
• which type of users and data are involved in the processes

Mapping Comments
Mapping comments should provide relevant information about the workflow purpose and function. Describe the source
data obtained and the data quality rules applied.

Informatica recommends using business terms along with technical details such as, table names. This is beneficial when
maintenance is required or if issues arise that need to be discussed with business analysts.

Note: There are limitations to how much can be put in a comment so it is recommended that comments be kept succinct.
It is also cautioned that comments are not used to replace user documentation.

Mapplet / Rule Comments

These comments are used to explain the process that the mapplet carries out. Informatica recommends reviewing the
notes regarding descriptions for the input and output transformations.

Tags: Big DataData Quality

jueves, 23 de agosto de 2018 Página 13 de 13