Logical Data Model Conventions 16143327

CIBC Technology & Operations

Lo gical Logi cal Data Data Mod Mode el Conv onve enti ntions ons and Guidelines Vers Version ion 1.3 1.3

Revision Date: December 15, 2009

December 15, 2009

Logic al Data Model Conventions and Guidelines

Page i

Table of Contents 1. Bac kg ro un d ............................................................................................................................................. 1 2. Sco pe........................................................................................................................................................ 1 2.1. In Scope........................................................................................................................................... 1 2.2. Out of Scope.................................................................................................................................... 1 3. Au di enc e .................................................................................................................................................. 1 4. Rol es and Respon si bi li ti es .................................................................................................................... 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 Pro ces s ........................................................................................................................................... 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 Gui del in es ....................................................................................................................................... 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. Logi cal Mo del Chec kl is t ......................................................................................................................... 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 Deliver abl es .................................................................................................................................... 9 9. Open Iss ues ............................................................................................................................................. 9

December 15, 2009

Logic al Data Model Conventions and Guidelines

Page ii

10. Model an d Mod el Desc ri pt io n .............................................................................................................. 9 11. Pro ced ur es ............................................................................................................................................ 9 12. Glo ss ary ................................................................................................................................................. 9 13. As so ci ated Instr um ent s ..................................................................................................................... 10 13.1. Related CIBC Technology Architecture Guidebook Standards................................................... 10 13.2. Related Documents ..................................................................................................................... 10 14. Con tr ol Inf or mat io n............................................................................................................................. 11 14.1. Contact Information ..................................................................................................................... 11 14.2. Publication ................................................................................................................................... 11 14.3. Version History ............................................................................................................................ 11  Ap pen di x: Stan dar d A bb rev iat io n L is t ................................................................................................... 12

December 15, 2009

Logical Data Model Convention s 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 o f 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 Responsi bil iti es  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 Arc hit ects  The Data Architect’s 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 Modeler’s 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 Convention s 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 Analyst’s 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 Analyst’s 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 Responsibiliti es 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 Convention s and Guidelines

Page 3 of 13

5. LDM Process 5.1.1. Hold Project Data Planning Sessi on 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 Struc tur e and Defin iti ons 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 L ogical 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 CIBC’s 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. Resol ve Signif icant 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 Guideli nes  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 data’s 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 Convention s 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 CIBC’s 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 t he 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. Entit y Relations hip 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 ph ysical 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 Mod els 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. Entit y 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 Convention s and Guidelines

Page 5 of 13

6.1.6. Entity Definitio n Guidelines

1. Instances An entity must have instances. 2. Noun s

 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 reader’s 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. Attr ibut e Definiti ons 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 Convention s 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

Amount

amt

Category

cat

Code

code

Count

cnt

Date

date

Datetime

dttm

Description

desc

Measure

msr

Id

id

Image Indicator

img ind

Key

key

Name

name

Number

nmbr

Percentage

pct

Period Quantity

pd qty

Rate

rate

 Time

time

Value

 Year

value

yr

Description Comments and Examples 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 Used for comments, content, and varying in length. Text-type data generally remarks, and description contains a description that applies to a code or an fields. entity. May contain text, alphanumeric and other printable characters. A quantitative measure of spatial proportions in up to  To replace dimension 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 Examples: US dollars/hour, designated units of measure. A quantity or amount US dollars/French franc, measured with respect to another measured quantity or miles/gallon 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.

December 15, 2009

Logical Data Model Convention s and Guidelines

Page 7 of 13

6.1.9. Descr ipti on 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. Lengt h 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. Dom ain o f 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. Propert ies 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. Rolenam e 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 Convention s 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 qualit y or the entity r elationsh ip 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?

o

Were relationship names chosen properly? Are they meaningful? Do they describe the business?

o

If multiple relationship paths between the same entity types are required, what are the reasons why?

o

Are many-to-many truly many-to-many? (most are not)

o

Are mandatory one-to-one relationships required or should the two entity types be combined into one?

7.1.2. Technical qualit y of t he data dictio nary. o

Do entity types and attributes clearly indicate the meaning of what they store?

o

Do entity type definitions accurately describe the business usage of what the entity type contains?

o

Are entity type identifiers properly defined?

o

Do entity types have their custodians identified?

o

Do attributes fit the entity type? (proper normalization)

o

Do the names follow naming standards for full names and abbreviations?

o

Do attributes containing codes include a representative sample of code values?

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 Convention s 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 Iss ues  There are no open issues associated with this document.

10. Model and Model Descr ipt ion  There are no models associated with this document.

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

12. Glossary Word/Acronym

Definition

Attribute

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 Convention s and Guidelines

Page 10 of 13

Word/Acronym

Definition

Metadata

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

Modifier Normalization (3rd normal form)

• • • • • • •

Optionality

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

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 Convention s and Guidelines

Page 11 of 13

14. Control Information 14.1. Contact Information Please address queries to Technology Standards at [email protected].

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

14.3. Versi on Histor y  The following changes have been incorporated in versions of this document: Version

Date Published

1.0 1.1

Feb 17, 2003 Nov 07, 2007

1.2

October 31, 2008

1.3

December 15, 2009

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. Revised name of Data Management and Integration Management standard in Control Information section.

December 15, 2009

Logical Data Model Convention s and Guidelines

 Appendix: Standard Abbreviation List If you need a new abbreviation, e-mail your request to [email protected]. Word

ACCOUNT ACTIVITY ADDRESS ADJ USTMENT 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

Page 12 of 13

December 15, 2009

Logical Data Model Convention s and Guidelines

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

Page 13 of 13