Naming Conventions - Data Quality

Challenge
Implementing standard naming conventions facilitates smooth migrations and improves
readability for anyone reviewing or carrying out maintenance on repository objects. This can
help in understanding the processes that are affected. 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. Choosing and adhering to a convention is the key.
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.
Administration Console Objects
Administration console objects such as domains, nodes, and services should have meaningful
names.
Object Recommended Naming Convention Example
Domain DOM_ or DMN_[PROJECT]_[ENVIRONMENT] DOM_PROCURE_DEV
Node NODE[#]_[SERVER_NAME]_ [optional_descriptor] NODE02_SERVER_rs_
b (backup node for the
repository service)
Services
Data
Integration
Service
DIS_SVC_[ENVIRONMENT]_[optional descriptor] DIS_SVC_DEV_primary
Model
Repository
MREP_SVC_[ENVIRONMENT]_[optional
descriptor]
MREP_SVC_TEST
Analyst
Service
AT_SVC_[ENVIRONMENT]_[optional descriptor] AT_SVC_PROD_primar
y
Content
Managemen
t Service
CMS_SVC_[ENVIRONMENT]_[optionial_descriptor
]
CMS_SVC_DEV_master
Object Recommended Naming Convention Example
Data
Director
service
DD_SVC_[ENVIRONMENT]_[optionial_descriptor] DD_SVC_TEST
Reporting
and
dashboard
service
REPT_SVC_[ENVIRONMENT]_[optionial_descripto
r]
REPT_SVC_PROD
Database Connection Information
Security considerations may dictate using corporate naming standards for the database or
project instead of {user}_{database name}. 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.
The naming convention should be applied across all development, test and production
environments. This allows seamless migration when migrating between environments. For
example, if the developer just has a Data Warehouse connection in each of the three
environments, when the administrator migrates a folder from the development environment to
the test environment, then the mappings automatically use the existing connection in the test
repository. With the right naming convention, sessions can be migrated from the test to
production repository without manual intervention.
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 issues discussed
in this Best Practice. Then use permission options to protect these connections so that
only specified individuals can modify them. Whenever possible, avoid having developers
create their own connections using different conventions and possibly duplicating
connections.
Analyst Tool Objects
Suggested Naming Conventions
Developer Tool Objects Suggested Naming
Conventions
Rule rule_{DESCRIPTION}
Data object profile dop_{DESCRIPTION}
Scorecard scr_{DESCRIPTION}
Physical Data object pdo_{DESCIPTION}
Mapping Specification
(Logical Data Object)
ldo_{DESCRIPTION}
Projects
The objects are organized by project in the analyst tool. Project names should be meaningful
and include the project name and whether its objects are reusable or not. To accomplish this,
add a prefix, such as glbl_ for a project containing reusable objects or proj_ for a project
that contains only its own object.

Folders
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.

Suggested Naming Conventions
Mapping, Mapplet and Rule Objects
Developer Tool
Objects
Suggested Naming Conventions
Mapping dqm_{PROCESS}_{SOURCE_SYSTEM}_{TARGET_NAME}
or suffix with _{descriptor} if there are multiple mappings for that
single target table
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}
Write {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 will access
Address Validator
Transformation
AVA_{DESCRIPTION} that uses the cycle or which pass the data
is taking through the transformation
Aggregator
Transformation
AGG_{FUNCTION} that leverages the expression and/or a name
that describes the processing being done
Association
Transformation
AST_{FUNCTION} that leverages the expression or a name that
describes the processing being done
Case Converter
Transformation
CCO_{DESCRIPTION}
Classifier
Transformation
CLA_{DESCRIPTION}
Comparison
Transformation
CMP_{DESCRIPTION}
Consolidation
Transformation
CNS_{DESCRIPTION}
Decision
Transformation
DEC_{DESCRIPTION}
Expression
Transformation
EXP_{FUNCTION} that leverages the expression and/or a name
that describes the processing being done
Filter
Transformation
FIL_ or FILT_{FUNCTION} that leverages the expression or a
name that describes the processing being done
Java
Transformation
JV_{FUNCTION} that leverages the expression or a name that
describes the processing being done
Joiner
Transformation
JNR_{DESCRIPTION}
Key Generator KGN_{DESCRIPTION}
Labeler
Transformation
LAB_{DESCRIPTION}
Lookup LKP_{TABLE_NAME} or suffix with _{descriptor} if there are
Developer Tool
Objects
Suggested Naming Conventions
Transformation multiple lookups on a single table. For unconnected lookups, use
ULKP in place of LKP
Match
Transformation
MAT_{DESCRIPTION}
Merge
Transformation
MRG_{DESCRIPTION}
Parser
Transformation
PRS_{DESCRIPTION}
Rank
Transformation
RNK_{FUNCTION} that leverages the expression or a name that
describes the processing being done
Read
Transformation
SRC_{DESCRIPTION}
Router
Transformation
RTR_{DESCRIPTOR}
Sorter
Transformation
SRT_{DESCRIPTOR}
SQL
Transformation
SQL_{DESCRIPTOR}
Standardizer
Transformation
STD_{DESCRIPTION}
Union
Transformation
UN_{DESCRIPTOR}
Update Strategy
Transformation
UPD_{UPDATE_TYPE(S)} or
UPD_{UPDATE_TYPE(S)}_{TARGET_NAME} if there are
multiple targets in the mapping. E.g.,
UPD_UPDATE_EXISTING_EMPLOYEES
Weighted Average
Transformation
WAV_{DESCRIPTION}
Exception
Transformation
EXC_{DESCRIPTION} or
EXC_{EXCEPTION_TABLE_NAME} with _{DESCRIPTION}
if additional information are required

Note: Some transformations allow different processes to be applied to the input data. These
processes are called strategies. The following format should be applied to the strategies:
Format strat_[input port]_[strategy type]_[detail]
Example strat_name_remove_punctuation
Workflow Objects
Developer Tool
Objects
Suggested Naming Conventions
Notification Task NOT_{DESCRIPTION}
Exclusive Gateway EXG_{DESCRIPTION}
Developer Tool
Objects
Suggested Naming Conventions
Task
Assignment Task AST_{DESCRIPTION}
Command Task CMT_{DESCRIPTION}
Human Task HMT_{DESCRIPTION} or HT_{EXCEPTION_TABLE_NAME}
with _{DESCRIPTION} to 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}
Port Names
Port names should remain the same as the source unless some other action is performed on
the port. 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. This helps trace the port value throughout the
mapping as it may travel through many 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
mplt_ for returns from mapplets
Prefixes are preferable because they are generally easier to see; developers do 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 Table
An exception table created by the exception transformation or simply used by that
transformation should follow a specific naming convention, such as:
Object Recommended Naming Convention Example
Exception table EX_ or X_ followed by
[TABLE_DESCRIPTION]
DOM_PROCURE_DEV
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.
Transformation Descriptions
This section defines the standards to be used for transformation descriptions in the Developer
Tool.

Read Transformation Descriptions
Should indicate the purpose of the Read Transformations and the data it is intended to
select.
Should indicate if any overrides are used. 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.
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 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].
Aggregator Transformation Descriptions
Aggregator transformation descriptions should adhere to the following format: This
Aggregator [explanation of what 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.
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.).
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.
Key Generator Transformation Descriptions
The key generator transformation descriptions should explain the key generation strategies
used to generates the groups.
Labeller Transformation Descriptions
The labeler transformation descriptions should explain what the labeller transformation is
actually labeling. It should specify if this is using probabilistic labeling or traditional
reference data labeling.
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.
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 which
fields 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.
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.
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).
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. In general, they should provide
relevant information about:
the workflow purpose and function
the type of exceptions reviewed (if needed)
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 such technical details as table
names. This is beneficial when maintenance is required or if issues arise that need to be
discussed with business analysts.
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.