Logical Data Model Conventions 16143327

7/28/2019 Logical Data Model Conventions 16143327

1/16

CIBC

Technology & Operations

Logical Data ModelConventions andGuidelinesVersion 1.3

Revision Date: December 15, 2009


2/16

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 Responsibi li ties .................................................................................................................... 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................................................................................... 35.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 Guidel ines .......................................................................................................................................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............................................................................................................................ 76.2.3. Cardinality...........................................................................................................................7

6.2.4. Optionality...........................................................................................................................7

6.2.5. Rolename............................................................................................................................7

7. Logical Model Checkl 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 Deliverables .................................................................................................................................... 9

9. Open Issues ............................................................................................................................................. 9


3/16

December 15,2009 Logical Data Model Conventions and Guidelines Page ii

10. Model and Model Descript ion ..............................................................................................................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 Informat ion.............................................................................................................................11

14.1. Contact Information ..................................................................................................................... 11

14.2. Publication................................................................................................................................... 11

14.3. Version History ............................................................................................................................ 11

Appendix: Standard Abbreviat ion List ................................................................................................... 12


4/16

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 duringthe development of an application. The LDM guidelines describe the specific requirements tested for inthe model reviews. The LDM responsibilities indicate persons or organizational roles responsible forproducing 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 indata models.

Project managers, business clients, and quality assurance analysts who sign off on models and verifyuse of the guidelines.

Developers, database analysts, and anyone else who reads and reviews data models.

4. Roles and Responsibil ities

The following are the responsibilities of data architects, data modelers, and business analysts who gatherdata 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, andnaming conventions

Support application development projects in applying the guidelines to project logical datamodels.

Resolve data model and naming convention conflicts that arise when integrating datamodels from different projects, and ensure uniqueness of names across the logical dataarchitecture.

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 leastthird normal form (3NF).


5/16


Ensure all informational business rules are documented in the data model, according tothe standards, including entities, attributes, and relationships, entity and attributedefinitions, 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 relationshipoptionality and cardinality, according to the standards.

May provide and sign off, on behalf of the business, on the business content of themodel.

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 usedin developing the model deliverables.

4.1.7. LDM Responsibil itiesProject 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.


6/16


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 DataArchitecture 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 modelsmay also be identified. The data planning session is held early in the project, well before formalrequirements are resolved. The Data Architecture Group will be responsive and cooperativeduring the planning session.

5.1.2. Develop Data Structure and Defin itions

During the application development process, the Project Manager will ensure that entity-relationship diagrams and a data dictionary are produced to standard, for any data pertinent tothe scope of the project. In some cases, existing models may be available from the DataArchitecture Group, and need only be changed and augmented. Ca ERwin CASE diagrammingtool should be used to develop the models. The models should be completed before any detaileddesign or coding is started. The standard for diagrams and the data dictionary are in the LDMStandards section.

5.1.3. Hold Logical Model Reviews

When an appropriate collection of data is prepared, the Project Manager schedules a LogicalData Model review two weeks in advance and provides the models to the Data ArchitectureGroup one week in advance. The review addresses how the models meet the standards anddocument, 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 fromstandards have been either remedied or minimized. Issues and concerns arising from the revieware documented, including risk and impact, and any significant problems are raised with either theprojects steering committee or other appropriate resolvers.

5.1.4. Resolve Signif icant Issues

Resolving significant issues is the hardest step. Typical issues include data already existing in anawkward 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 decision-making level.

5.1.5. LDM Process In Plain Terms

Hold a meeting early in any application project with key stakeholders, including the DataArchitecture Group and data users, to specifically anticipate issues concerned with the dataitself. Data profiling reports must be present at this meeting as supplementary information toassist 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 keptinformed 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 datato be stored and delivered in an application. Documentation provided for the review should be at a level ofdetail where little information is required to read and understand the datas structure as a whole. Thepresented model may refer to readily available documents or append any ancillary information asnecessary. The Logical Data Model (diagrams and dictionary) are produced with the CIBC-recognized


7/16


CASE tool. The currently recognized CASE tool within CIBC is Ca ERwin. Other forms of presentation arenot 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 notto impact that process, but enhance it, to the benefit of CIBCs business objectives as a whole. Where theefforts to produce the Logical Data Model appears excessive, and it can be shown that the risks themodels attempt to expose are understood and resolved elsewhere, the guidelines may be explicitlyrelaxed by the Data Architecture Group. Where significant maintenance is performed on a system thatdoe not have any models, data models must be provided for the parts of the system that are significantlyaltered. Where maintenance is performed on systems with existing models, the models must be changedto 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 warehouseapplications, the tools include ETL tools such as Informatica. The models are also used todevelop 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 andtheir relationships. The diagram is defined by an analysis of what information the businessrecords 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 areshown 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 modelsshould be split into Entity Display Groups (EDG) or sometimes referred to as Subject Areas. AnEntity Display Group is a group of entities that have a business coherence and are relativelydecoupled from other entities. Every entity is in one and only one EDG. The models deliveredmust 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 relationshipsbetween any pair of entities on the page must be shown. To complete the model, an EntityDisplay Group map must be provided to represent all of the Entity Display Groups on one page toact as a table of contents for the following models. The map contains one labelled box for eachEntity 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. Whereabbreviations are used, the full words must be obvious.


8/16


6.1.6. Entity Definition Guidelines

1. InstancesAn entity must have instances.

2. NounsThe first sentence of the definition should give a noun or group of nouns, with modifyingadjectives 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 thecompany.

3. ExamplesTypical examples are included.The first example should be one that is firmly in the collection, which solidly reinforces thereaders understanding. Other examples should reveal the bounds of the entity. Anexample that may not be considered an instance will help establish the boundary. Thisrequires anticipating instances where there may be confusion for the reader. Also ofvalue is an example of an instance that is not a valid member of the group. This showsthe boundary from another angle. Often wording that explains why and whether examplesare included are necessary. The definition should include a clear explanation of whythese 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 beentered 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 tounderstand the rationale for the entity and fit their own understanding of the business intothe one represented by this entity.e.g., The intent of the Employee entity is to capture any information about a person thecompany deals with in an employee-employer relationship. This includes personalinformation, tax, skills, and capabilities. Information relating to contracted individuals iskept with the client entity.

5. DifferentiationWhere there may be confusion between two similar entities, either because their namesare similar or because their descriptions or relationships are similar, there should beexplicit text that explains the difference.e.g., The Worker entity may be confused with the Employee entity. The Worker entity isused to collect information about clients who are supported in the work they do.

6.1.7. Attr ibute Definiti ons

Each attribute must be clearly named and defined. If the attribute is from a domain that will notchange, the values should be either listed or described. At the physical level, these domains willbe 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 DatePrimeword: 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, thePrimeword may be changed). This usually occurs when the Prime entity is subtyped (forexample, 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 whichthe attribute belongs. Classwords are the last component of an attribute name. Classwords arereserved words and should not be used anywhere else in the attribute name. A classword is a


9/16


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 thecurrent, valid classwords:

ClasswordPhysicalAbbreviation Description Comments and Examples

Address adr Identifies a component of an address that is not

covered by other classwords (in particular, to be usedfor e-mail addresses). May also apply to Line 1, 2 ofan address. For City, Province, use City Name,Province Name.

Amount amt A number of monetary units, which is alwaysexpressed in whole and fractional portions. A unit ofcurrency is required.

Category cat A classification of data that is not codified and does notrequire a reference or transaction table to becomemeaningful information.

Code code Words, letters, figures, or symbols used to representothers, for brevity or secrecy. Requires a reference ortranslation table to become meaningful information.

Count cnt An integer (>=0) that represents the whole number ofunits of a given item in the indicated unit of measure.Available for arithmetic use.

Date date A measurement of time from which year, month, andday may be derived.

Datetime dttm A measurement of time from which year, month, dayand time may be derived.

Description desc Data that is unstructured, relatively undefined incontent, and varying in length. Text-type data generallycontains a description that applies to a code or anentity. May contain text, alphanumeric and otherprintable characters.

Used for comments,remarks, and descriptionfields.

Measure msr A quantitative measure of spatial proportions in up tothree dimensions.

To replace dimension

Id id A non-intelligence bearing attribute whose purpose isto uniquely identify an independent entity.

Image img A picture or graphic.

Indicator ind A field that may contain one of two values only, usuallyY or N. When more than two states apply, use Code asthe classword.

Key key A system generated ID or surrogate key. Typicallyused in dimensional modelling as a primary key for adimension.

Name name A word or phrase that constitutes the distinctive, formalor legal designation of a person, place, thing, orconcept. What the person, place, thing, or concept isknown by or called.

Number nmbr A numeric integer used for identification or sequencing,and not intended for arithmetic use.

Percentage pct A numeric ratio of two values having the same unit ofmeasure, expressed in hundredths. A unit-lessmeasurement expressing a part of a whole.

Period pd A period of time month and year

Quantity qty A number of units. A real number indicating a measureimplied to be in units and available for arithmetic use.

Rate rate A measurement of change over time expressed indesignated units of measure. A quantity or amountmeasured with respect to another measured quantity oramount, or a fixed charge, cost or value.

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

Time time An indication of time of day that is capable of indicatinghours, minutes, and/or seconds, including fractions.

Value value A numeric quantity that is assigned or is determined bycalculation or measurement.

Note: For financial or monetary values, the classwordAmount is to be used.

Year yr A value that represents the year portion of a date.


10/16


6.1.9. Descr iption

An attribute description contains a narrative description of the data contained in the attribute. Thedescription:

Must be clear, concise and self-explanatory, using only CIBC business terminologywithout 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. Themaximum length varies according to the domain.

6.1.12. Optionality

Optionality identifies whether an attribute is mandatory or optional.

6.1.13. Domain of ValuesDomain of values refers to the allowable values for an attribute. This field is required for attributesthat 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 twoentities, 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 withanother 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 arelationship.

6.2.5. Rolename

Arolename must be applied to a relationship to specify the role that the entity is playing in thatrelationship.


11/16


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 businessrepresentatives to attend. Cross-functional entity types describe data used within a number ofapplications within CIBC.

7.1.1. Technical quality or the entity relationsh 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 informationrequirement?

o Were relationship names chosen properly? Are they meaningful? Do they describe thebusiness?

o If multiple relationship paths between the same entity types are required, what are thereasons 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 becombined into one?

7.1.2. Technical qualit y of the data dictionary.

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 typecontains?

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


12/16


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 logicaldata model is considered complete when unconditionally signedoff by the Project Manager, the business users, the Data Architecture Group, the ApplicationManager and the authors of the models

9. Open Issues

There are no open issues associated with this document.

10. Model and Model Descr ipt ionThere 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 singularityof purpose or use. An attribute is the lowest level of information that qualifies and describes an entityon a logical data model and represents facts about an entity.

Cardinality Describes the number of times an instance of an entity may participate in a relationship with anotherentity.

Values: 1-to-1, 1-to-many, and many-to-many

Examples: A Customer may have one or many Accounts.

Classword A noun within an attribute name that defines the generic grouping of data to which the attributebelongs. Classwords are the last component of an attribute name. Classwords are reserved wordsand should not be used anywhere else in the attribute name. A Classword is a modelling techniqueused to lend clarity to attribute names. A Classword is a means of categorizing data (e.g., is it time,date, monetary amount, coded information).

Dimensional Modelling This is a technique developed to structure data around natural business concepts, and to provide afoundation for performance-related data analysis. The focus in dimensional modelling is to organizeinformation 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.Enterprise (Logical) DataModel

Provides the ability to view the basic informational components of the enterprise independent ofexisting database constraints and political or parochial perspectives. An Enterprise (Logical) DataModel:

Represents one single version of the truth for the data and related business rules of theenterprise.

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 ofintegrated databases in which the commonality of data used by different areas is recognized.

Entity An entity is a fundamental thing of relevance to the enterprise about which data is kept. It iscomposed of a collection of logically related units of data or attributes that describe the entity (seeAttribute). An entity can be classified and have stated relationships to other entities.

Logical Data Model A representation of the data entities, relationships and attributes for the scope of the logical datamodel. A logical data model consists of a diagram and the supporting data dictionary documentation.


13/16


Word/Acronym Definition

Metadata Data about data. Metadata describes characteristics of data, such as size of field, what kind of datacan be in it (numeric, character), whether field is optional or must have a value, valid values, etc.

Modifier A component of the attribute naming conventions. A modifier is an adjective that narrows the scopeidentified by the prime and classwords (e.g., open, start, close).

Normalization

(3rd

normal form)

Represents business data requirements in its simplest form. Normalization in this context refers tothe 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

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

Physical Data Model Describes the proposed or existing data store structure.

Primary Key An attribute that uniquely identifies an entity. It is sometimes referred to as a unique identifier or UID.Primeword A component of the attribute naming conventions. A Primeword describes the high-level concept

associated with the attribute (e.g., Account, Party, Product).

Relationship In the context of a logical data model, relationships describe the interaction between entities and areoften a graphical representation of the business rules. The relationship on the diagram describes theoptionality of the business rule (i.e., is there a mandatory relationship?) and the cardinality of thebusiness 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 otherperson in the role of spouse. Therefore, the cardinality of the relationship is 0 or 1. The relationship isoptional; a person may or may not have a spouse.

Subject Area An area of interest to the enterprise, centered on a major resource, asset, product, or activity of theenterprise. A subject area is a logical grouping of related entities.

Upper Camel Case 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.

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
http://w2.cibc.com/en/techops/tech/Documents/tech-glossary.xlshttp://w2.cibc.com/en/techops/tech/Documents/tech-glossary.xlshttp://w2.cibc.com/en/techops/tech/Documents/tech-glossary.xlshttp://w2.cibc.com/en/techops/tech/Documents/tech-glossary.xls


14/16


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 CIBCs Intranet, CIBCTechnology 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 Date Published Changes

1.0 Feb 17, 2003 Original standard publication.

1.1 Nov 07, 2007 Significant modification to the standard we performed to reflect deficiencies with theoutdated standard.

1.2 October 31,2008 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 ControlInformation section.
mailto:%[email protected]://w2.cibc.com/en/techops/tech/standards/Pages/default.aspxhttp://w2.cibc.com/en/techops/tech/standards/Pages/default.aspxmailto:%[email protected]


15/16


Appendix: Standard Abbreviation List

If you need a new abbreviation, e-mail your request to [email protected].

Word Abbreviation

ACCOUNT ACC

ACTIVITY ACTV

ADDRESS ADDR

ADJUSTMENT ADJ

AGREEMENT AGRMT

AMOUNT AMT

APPLICATION APPL

APPROVE APRV

AUTHENTICATION AUTHN

AUTHORIZATION AUTHR

BALANCE BAL

CHANGE CHNG

CHARGE CHRG

COMMERCIAL LOAN CL

COUNT CNT

COUNTRY CTRY

CREDIT CRED

CREDIT ARRANGEMENT CRED_ARR

CURRENCY CCY

CUSTOMER CUST

DATE DT

DEFAULT DFLT

DELINQUENCY DELQ

DESCRIPTION DESC

DOCUMENT DOC

EFFECTIVE EFF

ELIGIBILITY ELIG

EMPLOYEE EMPL

ENROLLMENT ENRL

FINANCIAL FIN

FREQUENCY FREQ

HOLDER HLDR

IDENTIFIER ID

INDICATOR IND

INFORMATION INFO

INITIATE INIT

INSTRUMENT INSTR

INTERNAL INT

MAINTENANCE MAINT

MANAGEMENT MGMT

MARKET MKT

MATURITY MAT

MAXIMUM MAX

MESSAGE MSG

MINIMUM MIN

MULTIPLE MULTI

NOTIFICATION NOTIF

NUMBER NUM

OPERATION OP

ORGANIZATION ORG

ORIGINAL ORIG
mailto:%[email protected]:%[email protected]


16/16


Word Abbreviation

PACKAGE PKG

PAYMENT PYMT

RATE RT

PERCENT(AGE) PCT

PERFORMANCE PERF

PERSON PERSPORTFOLIO PORTF

PREFERENCE PREF

PRINCIPAL PRINCPL

PRODUCT PROD

PROGRAM PRGM

QUANTITY QTY

RECEIVE RCV

RECOMMEND/ RECOMMENDATION RECMD

REPAYMENT REPYMT

REPORT/REPORTING RPT

REQUEST REQST