CIBC Technology & Operations

Logical Data Model Conventions and Guidelines

Version 1.3

Revision Date: December 15, 2009

December 15, 2009

Logical Data Model Conventions and Guidelines

Page i

Table of Contents
1. Background ............................................................................................................................................. 1 2. Scope........................................................................................................................................................ 1 2.1. In Scope........................................................................................................................................... 1 2.2. Out of Scope.................................................................................................................................... 1 3. Audience .................................................................................................................................................. 1 4. Roles and Responsibilities .................................................................................................................... 1 4.1.1. Data Architects ................................................................................................................... 1 4.1.2. Data Modelers .................................................................................................................... 1 4.1.3. Business Analysts............................................................................................................... 2 4.1.4. Quality Assurance Analysts (where applicable) ................................................................. 2 4.1.5. Business Client ................................................................................................................... 2 4.1.6. Project Manager ................................................................................................................. 2 4.1.7. LDM Responsibilities .......................................................................................................... 2 5. LDM Process ........................................................................................................................................... 3 5.1.1. Hold Project Data Planning Session................................................................................... 3 5.1.2. Develop Data Structure and Definitions ............................................................................. 3 5.1.3. Hold Logical Model Reviews............................................................................................... 3 5.1.4. Resolve Significant Issues.................................................................................................. 3 5.1.5. LDM Process In Plain Terms .............................................................................................. 3 6. LDM Guidelines ....................................................................................................................................... 3 6.1.1. Use of the Data Models ...................................................................................................... 4 6.1.2. Entity Relationship Diagram ............................................................................................... 4 6.1.3. Standard Notation............................................................................................................... 4 6.1.4. Large Data Models ............................................................................................................. 4 6.1.5. Entity Naming Guidelines ................................................................................................... 4 6.1.6. Entity Definition Guidelines................................................................................................. 5 6.1.7. Attribute Definitions............................................................................................................. 5 6.1.8. Name Structure................................................................................................................... 5 6.1.9. Description .......................................................................................................................... 7 6.1.10. Format............................................................................................................................... 7 6.1.11. Length ............................................................................................................................... 7 6.1.12. Optionality ......................................................................................................................... 7 6.1.13. Domain of Values ............................................................................................................. 7 6.2. Standard: Relationship .................................................................................................................... 7 6.2.1. Definition ............................................................................................................................. 7 6.2.2. Properties............................................................................................................................ 7 6.2.3. Cardinality ........................................................................................................................... 7 6.2.4. Optionality ........................................................................................................................... 7 6.2.5. Rolename............................................................................................................................ 7 7. Logical Model Checklist ......................................................................................................................... 8 7.1.1. Technical quality or the entity relationship diagram ........................................................... 8 7.1.2. Technical quality of the data dictionary. ............................................................................. 8 7.1.3. Data Dictionary ................................................................................................................... 8 8. LDM Deliverables .................................................................................................................................... 9 9. Open Issues............................................................................................................................................. 9

December 15, 2009

Logical Data Model Conventions and Guidelines

Page ii

10. Model and Model Description .............................................................................................................. 9 11. Procedures ............................................................................................................................................ 9 12. Glossary................................................................................................................................................. 9 13. Associated Instruments ..................................................................................................................... 10 13.1. Related CIBC Technology Architecture Guidebook Standards................................................... 10 13.2. Related Documents ..................................................................................................................... 10 14. Control Information............................................................................................................................. 11 14.1. Contact Information ..................................................................................................................... 11 14.2. Publication ................................................................................................................................... 11 14.3. Version History ............................................................................................................................ 11 Appendix: Standard Abbreviation List ................................................................................................... 12

December 15, 2009

Logical Data Model Conventions and Guidelines

Page 1 of 13

1. Background
The Logical Data Management (LDM) process outlines how models are produced and reviewed during the development of an application. The LDM guidelines describe the specific requirements tested for in the model reviews. The LDM responsibilities indicate persons or organizational roles responsible for producing endorsed models.

2. Scope
2.1. In Scope
Standards and guidelines for documenting business data requirements in a logical data model. Logical data model naming conventions.

2.2. Out of Scope

Physical data model standards, guidelines, and naming conventions.

3. Audience
Data architects, data modelers, and business analysts who document business data requirements in data models. Project managers, business clients, and quality assurance analysts who sign off on models and verify use of the guidelines. Developers, database analysts, and anyone else who reads and reviews data models.

4. Roles and Responsibilities

The following are the responsibilities of data architects, data modelers, and business analysts who gather data requirements, and create and maintain logical data models.

4.1.1. Data Architects

The Data Architects responsibilities are as follows: Develop, maintain, and publish data architecture-related strategies, policies, guidelines, and naming conventions. Review data models to ensure conformance with data model standards, guidelines, and naming conventions Support application development projects in applying the guidelines to project logical data models. Resolve data model and naming convention conflicts that arise when integrating data models from different projects, and ensure uniqueness of names across the logical data architecture.

4.1.2. Data Modelers

The Data Modelers responsibilities are as follows: Strictly follow the LDM creation process and guidelines. Document business informational requirements and business rules in logical models, using the modeling guidelines. Non-dimensional data models are normalized to at least third normal form (3NF).

December 15, 2009

Logical Data Model Conventions and Guidelines

Page 2 of 13

Ensure all informational business rules are documented in the data model, according to the standards, including entities, attributes, and relationships, entity and attribute definitions, valid values, default values, and relationship optionality and cardinality. Ensure data-related naming conventions and standards are applied consistently. Ensure that all business data requirements are addressed by the data model. Sign-off on completed model from a modelling or standards point of view.

4.1.3. Business Analysts

The Business Analysts responsibilities are as follows: Document entity and attribute definitions, valid values, default values, and relationship optionality and cardinality, according to the standards. May provide and sign off, on behalf of the business, on the business content of the model.

4.1.4. Quality Assurance Analysts (where applicable)

The Quality Assurance Analysts responsibilities are as follows: Ensure data-related naming conventions and standards are consistently applied. Verify that all business data requirements are addressed by the data model. Sign off on completed data model.

4.1.5. Business Client

Sign off on business content of the data model.

4.1.6. Project Manager

Ensure that modelling resources are aware of the LDM process and that standards that are used in developing the model deliverables.

4.1.7. LDM Responsibilities

Project Steering Committee and User Management Identify Project Manager and charge this individual with following the LDM process.

Project Manager Follow LDM process. Perform Quality Assurance. Project Participants Prepare LDMs.

Data Administrator Provide consultation. Interpret standards. Expedite development. Produce feedback. Steering Committee and Managers Resolve issues.

December 15, 2009

Logical Data Model Conventions and Guidelines

Page 3 of 13

5. LDM Process
5.1.1. Hold Project Data Planning Session
At the initiation of a project, the Project Manager holds a data planning session with the Data Architecture Group to establish the broad data requirements for the project. The number and size of models are determined and the appropriate standards are identified. Sources for some models may also be identified. The data planning session is held early in the project, well before formal requirements are resolved. The Data Architecture Group will be responsive and cooperative during the planning session.

5.1.2. Develop Data Structure and Definitions

During the application development process, the Project Manager will ensure that entityrelationship diagrams and a data dictionary are produced to standard, for any data pertinent to the scope of the project. In some cases, existing models may be available from the Data Architecture Group, and need only be changed and augmented. Ca ERwin CASE diagramming tool should be used to develop the models. The models should be completed before any detailed design or coding is started. The standard for diagrams and the data dictionary are in the LDM Standards section.

5.1.3. Hold Logical Model Reviews

When an appropriate collection of data is prepared, the Project Manager schedules a Logical Data Model review two weeks in advance and provides the models to the Data Architecture Group one week in advance. The review addresses how the models meet the standards and document, with risks, any issues that may impact either the project or the rest of the organization. Any LDM that is developed must align to CIBCs certified sources. In the absence of concerns, the model may be approved at the review. The model is approved when deviations from standards have been either remedied or minimized. Issues and concerns arising from the review are documented, including risk and impact, and any significant problems are raised with either the projects steering committee or other appropriate resolvers.

5.1.4. Resolve Significant Issues

Resolving significant issues is the hardest step. Typical issues include data already existing in an awkward system or that not all the needs of potential users of the data can be economically met. The identified issues should be fairly represented and explicitly raised to the appropriate decisionmaking level.

5.1.5. LDM Process In Plain Terms

Hold a meeting early in any application project with key stakeholders, including the Data Architecture Group and data users, to specifically anticipate issues concerned with the data itself. Data profiling reports must be present at this meeting as supplementary information to assist in a meaningful LDM decision. Explicitly define all of the data that is used and show how it interrelates. Show it to key stakeholders and discuss issues that arise. Use the data models to portray the structure. Ensure that issues are appropriately disclosed to decision makers and that they are kept informed if the issues impact project delivery timelines.

6. LDM Guidelines
The intent of the Logical Data Model is to explicitly document a comprehensive understanding of the data to be stored and delivered in an application. Documentation provided for the review should be at a level of detail where little information is required to read and understand the datas structure as a whole. The presented model may refer to readily available documents or append any ancillary information as necessary. The Logical Data Model (diagrams and dictionary) are produced with the CIBC-recognized

December 15, 2009

Logical Data Model Conventions and Guidelines

Page 4 of 13

CASE tool. The currently recognized CASE tool within CIBC is Ca ERwin. Other forms of presentation are not permitted. Entity and attribute names must conform to CIBC naming standards. The intent of system development is to produce a working application. The intent of this document is not to impact that process, but enhance it, to the benefit of CIBCs business objectives as a whole. Where the efforts to produce the Logical Data Model appears excessive, and it can be shown that the risks the models attempt to expose are understood and resolved elsewhere, the guidelines may be explicitly relaxed by the Data Architecture Group. Where significant maintenance is performed on a system that doe not have any models, data models must be provided for the parts of the system that are significantly altered. Where maintenance is performed on systems with existing models, the models must be changed to reflect these standards before the maintenance is performed.

6.1.1. Use of the Data Models

Those who access the data using modern query tools use the models. For data warehouse applications, the tools include ETL tools such as Informatica. The models are also used to develop and assist in maintaining the application.

6.1.2. Entity Relationship Diagram

The entity relationship diagram is a graphical or pictorial representation of the entity types and their relationships. The diagram is defined by an analysis of what information the business records and what business rules are used. It has the following characteristics. It is at the logical level. It does not address physical implementation needs. Each entity type is named and represented by its own rectangle. A line connecting the two entity types represents a relationship between them. Each relationship is given two names for the information it imparts between the entity types. Each end shows the cardinality and optionality of the relationship. The diagram should only show those attributes that make up the key for the entity.

6.1.3. Standard Notation

Erwin uses the Bachman notation type to display notation within models. In general, entities are shown as rounded rectangles, relationships are not curved, cardinality is shown by crows feet, and optionality is shown by either circles or crossing lines.

6.1.4. Large Data Models

When the number of entities in a data model are not clearly shown on one page, the models should be split into Entity Display Groups (EDG) or sometimes referred to as Subject Areas. An Entity Display Group is a group of entities that have a business coherence and are relatively decoupled from other entities. Every entity is in one and only one EDG. The models delivered must include a page for each EDG showing the relationship of the entities within that single EDG. On this page, the included entities are shown within a rectangular boundary. All entities that have a relationship to those in the facet are shown on the page outside the rectangle. All relationships between any pair of entities on the page must be shown. To complete the model, an Entity Display Group map must be provided to represent all of the Entity Display Groups on one page to act as a table of contents for the following models. The map contains one labelled box for each Entity Display Group and has a single line joining any of the EDGs that share a relationship.

6.1.5. Entity Naming Guidelines

Names for the entities must be meaningful and must not conflict with other entity names. Where abbreviations are used, the full words must be obvious.

December 15, 2009

Logical Data Model Conventions and Guidelines

Page 5 of 13

6.1.6. Entity Definition Guidelines

1. Instances
An entity must have instances. 2. Nouns The first sentence of the definition should give a noun or group of nouns, with modifying adjectives or phrases that summarize the meaning of the entity. e.g., An Employee is any person, alive or dead, who works or has worked for the company. 3. Examples Typical examples are included. The first example should be one that is firmly in the collection, which solidly reinforces the readers understanding. Other examples should reveal the bounds of the entity. An example that may not be considered an instance will help establish the boundary. This requires anticipating instances where there may be confusion for the reader. Also of value is an example of an instance that is not a valid member of the group. This shows the boundary from another angle. Often wording that explains why and whether examples are included are necessary. The definition should include a clear explanation of why these examples are or are not included. e.g., As soon as a person becomes a candidate for a position in the company, he becomes an Employee whose status is un-hired. This allows personal information to be entered only once. Applicants who are not considered for a position are not Employees. 4. Intent Where possible, the intent of the entity should be shown. This allows the reader to understand the rationale for the entity and fit their own understanding of the business into the one represented by this entity. e.g., The intent of the Employee entity is to capture any information about a person the company deals with in an employee-employer relationship. This includes personal information, tax, skills, and capabilities. Information relating to contracted individuals is kept with the client entity. 5. Differentiation Where there may be confusion between two similar entities, either because their names are similar or because their descriptions or relationships are similar, there should be explicit text that explains the difference. e.g., The Worker entity may be confused with the Employee entity. The Worker entity is used to collect information about clients who are supported in the work they do.

6.1.7. Attribute Definitions

Each attribute must be clearly named and defined. If the attribute is from a domain that will not change, the values should be either listed or described. At the physical level, these domains will be implemented as code tables, but it is not necessary to show these for the logical model.

6.1.8. Name Structure

The structure for an attribute name is as follows: Primeword + (0-N Modifiers) + Classword Examples: Account Open Date, Customer Birth Date Primeword: Describes the high-level concept associated with the attribute (e.g., Account, Party, Product). Note: Primeword is more accurately a Primeterm and may consist of more than word (that is, the Primeword may be changed). This usually occurs when the Prime entity is subtyped (for example, Market Segment Identifier, Legal Item Amount). Modifier: A qualifier that further describes or distinguishes the Primeword and the Classword (e.g., Open, Start, Close). Classword: A noun within an attribute name that defines the generic grouping of data to which the attribute belongs. Classwords are the last component of an attribute name. Classwords are reserved words and should not be used anywhere else in the attribute name. A classword is a

December 15, 2009

Logical Data Model Conventions and Guidelines

Page 6 of 13

modeling technique used to lend clarity to attribute names and is a means of categorizing data (e.g. is it time, date, monetary amount, coded information). The following table defines the current, valid classwords:
Classword Address Physical Abbreviation adr Description Identifies a component of an address that is not covered by other classwords (in particular, to be used for e-mail addresses). May also apply to Line 1, 2 of an address. For City, Province, use City Name, Province Name. A number of monetary units, which is always expressed in whole and fractional portions. A unit of currency is required. A classification of data that is not codified and does not require a reference or transaction table to become meaningful information. Words, letters, figures, or symbols used to represent others, for brevity or secrecy. Requires a reference or translation table to become meaningful information. An integer (>= 0) that represents the whole number of units of a given item in the indicated unit of measure. Available for arithmetic use. A measurement of time from which year, month, and day may be derived. A measurement of time from which year, month, day and time may be derived. Data that is unstructured, relatively undefined in content, and varying in length. Text-type data generally contains a description that applies to a code or an entity. May contain text, alphanumeric and other printable characters. A quantitative measure of spatial proportions in up to three dimensions. A non-intelligence bearing attribute whose purpose is to uniquely identify an independent entity. A picture or graphic. A field that may contain one of two values only, usually Y or N. When more than two states apply, use Code as the classword. A system generated ID or surrogate key. Typically used in dimensional modelling as a primary key for a dimension. A word or phrase that constitutes the distinctive, formal or legal designation of a person, place, thing, or concept. What the person, place, thing, or concept is known by or called. A numeric integer used for identification or sequencing, and not intended for arithmetic use. A numeric ratio of two values having the same unit of measure, expressed in hundredths. A unit-less measurement expressing a part of a whole. A period of time month and year A number of units. A real number indicating a measure implied to be in units and available for arithmetic use. A measurement of change over time expressed in designated units of measure. A quantity or amount measured with respect to another measured quantity or amount, or a fixed charge, cost or value. An indication of time of day that is capable of indicating hours, minutes, and/or seconds, including fractions. A numeric quantity that is assigned or is determined by calculation or measurement. Note: For financial or monetary values, the classword Amount is to be used. A value that represents the year portion of a date. Comments and Examples

Amount

amt

Category

cat

Code

code

Count

cnt

Date Datetime Description

date dttm desc

Used for comments, remarks, and description fields.

Measure Id Image Indicator

msr id img ind

To replace dimension

Key

key

Name

name

Number Percentage

nmbr pct

Period Quantity Rate

pd qty rate

Examples: US dollars/hour, US dollars/French franc, miles/gallon

Time Value

time value

Year

yr

December 15, 2009

Logical Data Model Conventions and Guidelines

Page 7 of 13

6.1.9. Description
An attribute description contains a narrative description of the data contained in the attribute. The description: Must be clear, concise and self-explanatory, using only CIBC business terminology without references to technology, implementation or system processing rules. Must not include abbreviations or acronyms.

6.1.10. Format
Format refers to the type of data contained in an attribute (e.g., numeric, text, date, time).

6.1.11. Length
Length is the maximum number of characters or digits allowed for each value of an attribute. The maximum length varies according to the domain.

6.1.12. Optionality
Optionality identifies whether an attribute is mandatory or optional.

6.1.13. Domain of Values

Domain of values refers to the allowable values for an attribute. This field is required for attributes that end with the classword Category or Code.

6.2. Standard: Relationship

6.2.1. Definition
A relationship is used in a logical model to show that there is an association or link between two entities, or between an entity and itself. Relationships represent business rules.

6.2.2. Properties
A relationship has the following properties: Cardinality (zero, one or more to one or many) Optionality (mandatory or not) Rolename)

6.2.3. Cardinality
Describes the number of times an instance of an entity may participate in a relationship with another entity. Cardinality is documented using the IE notation in ERwin to draw the relationship.

6.2.4. Optionality
Indicates whether the relationship is optional or mandatory, for the entities that are joined by a relationship.

6.2.5. Rolename
A rolename must be applied to a relationship to specify the role that the entity is playing in that relationship.

December 15, 2009

Logical Data Model Conventions and Guidelines

Page 8 of 13

7. Logical Model Checklist

At the Logical Model review, the following is considered: Identification of cross-functional entity types that may require other line of business representatives to attend. Cross-functional entity types describe data used within a number of applications within CIBC.

7.1.1. Technical quality or the entity relationship diagram

o Does the cardinality (one-to-one, one-to-many, many-to-many) and optionality (sometimes, always) of each relationship reflect the true business information requirement? Were relationship names chosen properly? Are they meaningful? Do they describe the business? If multiple relationship paths between the same entity types are required, what are the reasons why? Are many-to-many truly many-to-many? (most are not) Are mandatory one-to-one relationships required or should the two entity types be combined into one?

o o

7.1.2. Technical quality of the data dictionary.

o o Do entity types and attributes clearly indicate the meaning of what they store? Do entity type definitions accurately describe the business usage of what the entity type contains? Are entity type identifiers properly defined? Do entity types have their custodians identified? Do attributes fit the entity type? (proper normalization) Do the names follow naming standards for full names and abbreviations? Do attributes containing codes include a representative sample of code values?

o o o o o

7.1.3. Data Dictionary

A data dictionary is considered an integral part of the required deliverable. It provides a definition of the entity, attributes, and relationships included in the diagrams. The definitions in the dictionary should have the following characteristics: Precision definitions resolve ambiguities and qualify imprecise terms. Completeness all terms are defined. Clarity plain English, with few, if any, buzzwords. Brevity brief and to the point. Compatibility with other definitions.

December 15, 2009

Logical Data Model Conventions and Guidelines

Page 9 of 13

8. LDM Deliverables
The LDM deliverables are as follows: A scheduled data-planning meeting, including agenda (Project Manager) Scheduled reviews of suitable size (Project Manager) A Logical Data Model consisting of entity relationship diagrams and the data dictionary (Project Manager) The review's feedback document (Data Architecture Group) Data Model Sign-off: The logical data model is considered complete when unconditionally signed off by the Project Manager, the business users, the Data Architecture Group, the Application Manager and the authors of the models

9. Open Issues
There are no open issues associated with this document.

10. Model and Model Description

There are no models associated with this document.

11. Procedures
There are no procedures associated with this document.

12. Glossary
Word/Acronym Attribute Definition A property or characteristic of an entity. An attribute must describe one concept and have singularity of purpose or use. An attribute is the lowest level of information that qualifies and describes an entity on a logical data model and represents facts about an entity. Describes the number of times an instance of an entity may participate in a relationship with another entity. Values: 1-to-1, 1-to-many, and many-to-many Examples: A Customer may have one or many Accounts. A noun within an attribute name that defines the generic grouping of data to which the attribute belongs. Classwords are the last component of an attribute name. Classwords are reserved words and should not be used anywhere else in the attribute name. A Classword is a modelling technique used to lend clarity to attribute names. A Classword is a means of categorizing data (e.g., is it time, date, monetary amount, coded information). This is a technique developed to structure data around natural business concepts, and to provide a foundation for performance-related data analysis. The focus in dimensional modelling is to organize information according to the way business analysts intuitively think about their data, and to minimize the number of joins required to retrieve the information into meaningful, integrated reports. Provides the ability to view the basic informational components of the enterprise independent of existing database constraints and political or parochial perspectives. An Enterprise (Logical) Data Model: Represents one single version of the truth for the data and related business rules of the enterprise. Consists of the set of logical data models for all the subject areas required by the business. All user views of the data are merged into one enterprise view to facilitate the development of integrated databases in which the commonality of data used by different areas is recognized. An entity is a fundamental thing of relevance to the enterprise about which data is kept. It is composed of a collection of logically related units of data or attributes that describe the entity (see Attribute). An entity can be classified and have stated relationships to other entities. A representation of the data entities, relationships and attributes for the scope of the logical data model. A logical data model consists of a diagram and the supporting data dictionary documentation.

Cardinality

Classword

Dimensional Modelling

Enterprise (Logical) Data Model

Entity

Logical Data Model

December 15, 2009

Logical Data Model Conventions and Guidelines

Page 10 of 13

Word/Acronym Metadata Modifier Normalization rd (3 normal form)

Definition Data about data. Metadata describes characteristics of data, such as size of field, what kind of data can be in it (numeric, character), whether field is optional or must have a value, valid values, etc. A component of the attribute naming conventions. A modifier is an adjective that narrows the scope identified by the prime and classwords (e.g., open, start, close). Represents business data requirements in its simplest form. Normalization in this context refers to the elimination of redundancy and inconsistent dependency. This is done by: Eliminating repeating groups in individual entities Creating separate entities for each related set of data Identifying atomic pieces of data (e.g., attributes) Identifying each set of related data with a unique identifier or primary key Creating separate entities for sets of values that appear in multiple instances (reference tables) Relating entities to each other with foreign keys (relating unique identifiers) Eliminate attributes in the entities that do not depend on the unique identifier Indicates whether entities joined by a relationship must participate in the relationship. Values: optional, mandatory Examples: An Account must have at least one Card associated with it. A Customer may or may not have an e-mail address. Describes the proposed or existing data store structure. An attribute that uniquely identifies an entity. It is sometimes referred to as a unique identifier or UID. A component of the attribute naming conventions. A Primeword describes the high-level concept associated with the attribute (e.g., Account, Party, Product). In the context of a logical data model, relationships describe the interaction between entities and are often a graphical representation of the business rules. The relationship on the diagram describes the optionality of the business rule (i.e., is there a mandatory relationship?) and the cardinality of the business rule (i.e., is it one or many?). For example, in a spousal relationship, at any given time, one person may be related to one other person in the role of spouse. Therefore, the cardinality of the relationship is 0 or 1. The relationship is optional; a person may or may not have a spouse. An area of interest to the enterprise, centered on a major resource, asset, product, or activity of the enterprise. A subject area is a logical grouping of related entities. Capitalization of the first letter of each word in the name of an entity, attribute name, and so on. For example: Customer Name, Customer Address.

Optionality

Physical Data Model Primary Key Primeword Relationship

Subject Area Upper Camel Case

13. Associated Instruments

13.1. Related CIBC Technology Architecture Guidebook Standards
http://w2.cibc.com/en/techops/tech/standards/Documents/standards/INT12.pdf TA-1033 Data Modelling Tool

13.2. Related Documents

CIBC Technology Glossary - http://w2.cibc.com/en/techops/tech/Documents/tech-

glossary.xls

December 15, 2009

Logical Data Model Conventions and Guidelines

Page 11 of 13

14. Control Information

14.1. Contact Information
Please address queries to Technology Standards at standard.mailbox@cibc.com.

14.2. Publication
This document (in PDF format) is available for viewing and printing on CIBCs Intranet, CIBC Technology Standards site: http://w2.cibc.com/en/techops/tech/standards/Pages/default.aspx

14.3. Version History

The following changes have been incorporated in versions of this document:
Version 1.0 1.1 1.2 Date Published Feb 17, 2003 Nov 07, 2007 October 31, 2008 Changes Original standard publication. Significant modification to the standard we performed to reflect deficiencies with the outdated standard. This document was formerly standard DT-126. The Data Management standard (INT-11) integrates DT-126, resulting in this supporting document.

1.3

December 15, 2009

Revised name of Data Management and Integration Management standard in Control Information section.

December 15, 2009

Logical Data Model Conventions and Guidelines

Page 12 of 13

Appendix: Standard Abbreviation List

If you need a new abbreviation, e-mail your request to standard.mailbox@cibc.com.
Word ACCOUNT ACTIVITY ADDRESS ADJUSTMENT AGREEMENT AMOUNT APPLICATION APPROVE AUTHENTICATION AUTHORIZATION BALANCE CHANGE CHARGE COMMERCIAL LOAN COUNT COUNTRY CREDIT CREDIT ARRANGEMENT CURRENCY CUSTOMER DATE DEFAULT DELINQUENCY DESCRIPTION DOCUMENT EFFECTIVE ELIGIBILITY EMPLOYEE ENROLLMENT FINANCIAL FREQUENCY HOLDER IDENTIFIER INDICATOR INFORMATION INITIATE INSTRUMENT INTERNAL MAINTENANCE MANAGEMENT MARKET MATURITY MAXIMUM MESSAGE MINIMUM MULTIPLE NOTIFICATION NUMBER OPERATION ORGANIZATION ORIGINAL Abbreviation ACC ACTV ADDR ADJ AGRMT AMT APPL APRV AUTHN AUTHR BAL CHNG CHRG CL CNT CTRY CRED CRED_ARR CCY CUST DT DFLT DELQ DESC DOC EFF ELIG EMPL ENRL FIN FREQ HLDR ID IND INFO INIT INSTR INT MAINT MGMT MKT MAT MAX MSG MIN MULTI NOTIF NUM OP ORG ORIG

December 15, 2009

Logical Data Model Conventions and Guidelines

Page 13 of 13

Word PACKAGE PAYMENT RATE PERCENT(AGE) PERFORMANCE PERSON PORTFOLIO PREFERENCE PRINCIPAL PRODUCT PROGRAM QUANTITY RECEIVE RECOMMEND/ RECOMMENDATION REPAYMENT REPORT/REPORTING REQUEST

Abbreviation PKG PYMT RT PCT PERF PERS PORTF PREF PRINCPL PROD PRGM QTY RCV RECMD REPYMT RPT REQST