Naming Standards for Data Models

Table of Contents
Naming Standards for Data Models.....................................................................................................1
Table of Contents..............................................................................................................................1
Introduction..........................................................................................................................................2
What is a Data Model?.........................................................................................................................2
Logical Model..............................................................................................................................2
Physical Model.............................................................................................................................2
Components..................................................................................................................................2
Entities and Tables................................................................................................................................3
Entity/Table Names..........................................................................................................................3
Entity Names in Logical Models..................................................................................................3
Table Names in Internal Schema..................................................................................................5
Table Names in External Schema.................................................................................................6
Entity/Table Descriptions.................................................................................................................6
Attributes and Columns........................................................................................................................7
Attribute/Column Names.................................................................................................................8
Attribute Names in Logical Models.............................................................................................8
Column Names in Internal Schemas..........................................................................................10
Column Names in External Schema...........................................................................................11
Column/Column Descriptions........................................................................................................11
Relationships......................................................................................................................................13
Relationship Names........................................................................................................................13
Relationship Descriptions...............................................................................................................13
Class Words........................................................................................................................................15
Class Word Usage...........................................................................................................................15
List of Standard Class Words.....................................................................................................16
Abbreviations, Acronyms and Other Terms:..................................................................................18
Use of the Terms List.................................................................................................................18
Standards for Terms....................................................................................................................18
Abbreviation Formulation..........................................................................................................18
Acronym Formulation................................................................................................................19
Guidelines...................................................................................................................................19
Terms List...................................................................................................................................19

1 of 18
Introduction
This document presents a set of standards and guidelines that apply to both conceptual and physical
data models. Throughout this document, the term "standard" refers to those principles that are
required when creating models, where the term "guideline" refers to optional best practices which
should be followed.
This document is written for those individuals who have some experience in data modelling and
database design. It is not intended as a tutorial or instructional text of any type, although there are
some definitions of modelling and database concepts included to aid in communicating the intent of
various standards.

What is a Data Model?

The term "data model," as used in this document, means any specification or representation of the
data structures, data definitions, and business rules required to describe and/or support a business
area.
The approach to data modelling recognizes the need to model data from two different perspectives.
The first type of model is logical. It represents the perspective of the creators/users of the data. The
second type of model is physical. It represents how the data is physically stored and viewed. This
logical/physical approach to data modelling has one type of schema in the logical model and two
types of schemas in the physical model.
Logical Model
Conceptual Schema. The conceptual schema in the logical model addresses the concepts
represented by the data. This model is completely implementation independent, and represents
the complete information requirement for the area being modelled, from the users' perspective.
It also only contains atomic data: data at the lowest granularity from the operational source, data
which is not redundant, and data which cannot be inferred from other data. In rare
circumstances it may be necessary to include derived data in a logical model, but it must be
labelled as such.
Physical Model
Internal Schema. The physical implementation requirements of the data are represented by the
internal schema, which is part of the physical model. It represents the physical storage schemes
used to implement the information concepts, is implementation specific, and is mapped to the
conceptual schema. An internal schema is the same as a database schema.
External Schema. The subset of data required by each (group of) user(s) is called the external
schema. It is also a physical model. It is stated in users' terminology, but is concerned with
showing the specific information requirements of a particular group of users. It may contain any
subset of the conceptual schema, and may also contain derived data, if the user requires it.
Because different users have different information needs there may be more than one external
schema in a physical model.
Components
Components of the logical model are the basis for components in the physical models. Two of these
components are of particular interest to this document:
Entities become Tables
Attributes become Columns

2 of 18
Because of these close associations, naming and description standards for these components will be
presented in the same chapters of this document. In effect the standard for the physical models will
be presented immediately after the standard for the logical model. The physical model standards
will be referred to simply as standards for Internal Schema and standards for External Schema.

Entities and Tables

Definition
An entity is the representation of a distinguishable person, place, thing, concept, event or state
which has characteristics, properties, or relationships which are of interest to someone
A table is a physical collection of data that may or may not correspond with a logical entity.

Entity/Table Names
Entity Names in Logical Models
Standards
Entity/table names in logical models should follow these standards:
ARE UNIQUE. Entity names must be unique within the Organisations library of approved data
models.
FOLLOW CORRECT FORMAT. Entities names will have the following format rules:
An entity name will be in title case.
Student
Other Institution Name
State Type
Numbers may be used.
Fed 1099 Type
No special characters are allowed in an entity name.
Acceptable: Student Aid
Not Acceptable: Student's Aid
Multiple terms in the name will be separated by spaces.
Acceptable: Computer Based Part
Not Acceptable: Computer-Based Part
CONSIST OF A SINGULAR NOUN OR NOUN PHRASE. An entity name will be a noun or noun
phrase in the singular form.
USE THE APPROPRIATE STANDARD TERMS. Entity names must be composed of the standard
"terms" for a logical model. In logical models, the standard terms are mostly spelled out words,
but there are also a few mandatory abbreviations. Check the Terms List in the chapter on
Abbreviations, Acronyms and Other Terms for a list of the appropriate terms for a logical model
and for further information about terms in general.

In summary, when creating entity names in a logical model, you should:

Refer to the Logical Models & External Schema column of the Terms List presented in the
Abbreviations chapter and only use terms from that column.
If additional abbreviation of a word is needed for space considerations, refer to the Internal Schema
column for other standard abbreviations. These may be used on an optional basis in logical models
and external schemas, but the spelled out word is preferable.

3 of 18
 Sample of Terms List:
WORD LOGICAL PHYSICAL

Advisor advisor advr

Amount amt amt
Agreement agreement agree
Appointment appt appt
Area area area
Award award awd
- Mandatory Abbreviation

Guidelines
Entity/table names should also adhere to the following guidelines whenever possible:
DESCRIBE BUSINESS MEANING. The modeller should strive for entity names that have
meaning to the user community, instead of the ITSS community, DBAs, programmers, etc.
ARE MEANINGFUL WHEN DESCRIBING AN ASSOCIATIVE ENTITY.
It is common for modellers to name associative entities by simply concatenating the two
parent entity names. This should be avoided, if possible. The best approach is to create a
meaningful business name rather than a concatenation. Using words like "association,"
"intersection," "usage," "cross-reference," or "mapping" in the entity name will often
accomplish this.
Enrolment (vs. simply Student Course)
Student Housing Association
ARE SUFFICIENTLY DESCRIPTIVE. A balance must be pursued between entity names that
are short and easy to type and those that are longer and more descriptive. Some
"fundamental" entities, such as Person, Customer, Order, Product, etc. can be named in one
word. However, most entities will require a longer name. More descriptive names are better.
Even when a group of business users may use a single term, the modeller may choose to add
modifiers to the entity name to distinguish between different "flavours" of the data concept
that may exist in other business areas. Though some single-word names may appear
obvious, ask questions. Is there more than one type of Product, Customer, Invoice, Part,
Organization across the enterprise? Though one-word entity names do occur naturally, they
should be approached with care and analysis.
Table Names in Internal Schema
Standards
Table names in the internal schema will be the same as the entity name in the logical model
upon which the table name is based, with the following exceptions.
USE UNDERSCORES FOR SPACES. Underscore characters will replace spaces as the dividers
between terms in the name.
USE THE APPROPRIATE STANDARD TERMS. Table names must be composed of the
standard "terms" for an internal schema. In internal schemas, the standard terms are mostly
abbreviations, but there are also some words which are always spelled out. Check the Terms
List in the chapter on Abbreviations, Acronyms and Other Terms for a list of the appropriate
terms and for further information about terms in general.

4 of 18
In summary, when creating table names in an internal schema, you should:
Refer to the Internal Schema column of the Terms List presented in the Abbreviations chapter
and only use terms from that column.

Sample of Terms List:

WORD LOGICAL PHYSICAL

Advisor advisor advr

Amount amt amt
Agreement agreement agree
Appointment appt appt
Area area area
Award award awd
- Mandatory Abbreviation
Guidelines
Follow the same guidelines listed for entity names in logical models.
Table Names in External Schema
Standards
Table names in the external schema will be the same as the entity name in the logical model
upon which the table name is based, with the following exception:
USE UNDERSCORES FOR SPACES. Underscore characters will replace spaces as the dividers
between terms in the name.
USE APPROPRIATE STANDARD TERMS. Table names in external schema should be user-
friendly and consist of the same terms as used for logical models (see section A.4). Refer to
the Logical Models & External Schema column of the Terms List in the Abbreviations
chapter.
Guidelines
Follow the same guidelines listed for entity names in logical models.

Entity/Table Descriptions
The following standards and guidelines apply to entity/table descriptions in all models and
schemas.
Standards
DESCRIBE A SINGLE INSTANCE OF ENTITY. The entity's description will, like the entity
name, be in the singular form, describing a single instance of the entity.
DESCRIBE WHAT THE ENTITY IS. The entity description should describe what the entity is,
not how it is used. "How used" information may also be included, but only to illustrate a
point or give an example -- not to substitute for a poorly worded description. Often, "how
used" information is an implementation-dependent detail, dependent on current business
processes, systems, etc. -- all of which may change significantly.
ENCLOSE RELATIONSHIP REFERENCES WITHIN TICK MARKS. Relationships that are
referenced will be enclosed in tick (') marks. Only the verb phrase must be referenced, but
the entire relationship description should be included where it significantly improves
communication.

5 of 18
REFER TO PLURAL ENTITY/TABLE NAMES IN A SPECIFIED WAY. The plural form of an
entity is created by appending a lower case "s" onto the end of the entity name in the
description.

For example: the plural of the entity entitled "Person" is "Persons" not "People," the plural
form of "Company" is "Companies," etc. This is as much for consistency as to minimize
ambiguity. After all, there can be no such entities entitled "Person's, "Persons," "People,"
"Company's, "Companies," etc., since these violate the special character and plural form
standards.

This rule only applies to making the name plural in a description. It does not mean entities
can have plural names.

Guidelines
DESCRIBE BUSINESS MEANING. The description, like the entity name, should be worded in
the user's terminology, so that any user, even if only vaguely familiar with the business
concept, would be able to understand the meaning of the entity without having to consult
other documentation.

Attributes and Columns

Definition
An attribute name is the name given to a representation of a single valued fact about or
characteristic of an entity in the logical model. Attributes also have the following
characteristics:
NOT A DERIVED VALUE (in a Logical Model):
Attributes that are derived should not be present in a logical model, but are proper in an
external schema of the physical model. An attribute is considered derived when the
attributes required to compute it are present in the model being built, and are in existence for
the "lifetime" of the derived attribute.

For example: An attribute which contains the total number of credits a current student has
earned is derived because it is computed from data which is still in existence in the Data
Warehouse, and which will continue to be in existence for the life of the derived attribute.

Attributes in the logical model may contain derived data as long as the derived data is
labelled as derived. Such derived data will not be implemented in the internal schema but
will probably be implemented in one or more external schemas. The reason for allowing
derived data in the logical model is to satisfy business imperatives and to aid in
communication between model builders and model users.
NOT AN ARRAY: Attributes in the logical model and columns in the physical models must not
contain arrays or other forms of repeating values.
USUALLY NOT A CONCATENATED VALUE: Attributes in the logical model must not
contain concatenations of values or other aggregations, unless the business uses the
aggregation as a single value. Attributes in the external schema may use concatenated values
to accommodate the needs/preferences of users.

For example: An attribute such as phone number actually contains at least three different
attributes, but is usually used as a single attribute, so a single concatenated attribute is
acceptable in the logical model.

6 of 18
 On the other hand, course id is composed of quarter year date, course number, course
section name and course suffix name, Each of these attributes exists as an attribute in the
logical model, so it is not appropriate to concatenate them into a single attribute, called
course id, in that model. But, it is appropriate to have the concatenated course id attribute in
the external schema if it will aid users of the schema.
MUST REPRESENT A SINGLE ASPECT OF THE ENTITY: Attributes must not represent
"black holes." These are quite common, appearing as "comments" fields into which users
enter any number of data values for which there is no other convenient storage mechanism.
Since the modelling exercise is meant to discover all data of interest to the user, it is
important to find out the contents of "black holes" and model them as separate attributes.

Attribute/Column Names
Attribute Names in Logical Models
Standards
ARE UNIQUE. Each and every attribute name in the Enterprise Model must be unique.
FOLLOW CORRECT FORMAT. Attribute names have the following format rules:
No special characters: no characters other than letters and numbers.
Acceptable: Student Deposit Amount
Not Acceptable: Student Deposit $
Not Acceptable: Parent and/or Guardian Id
Use spaces to separate terms within the name:
Acceptable: Employee Visitor Badge Id
Not Acceptable: Employee/Visitor Badge Id
Use lower case letters, even when acronyms are included (this facilitates proper sorting; in
the case-sensitive Sybase environment, attribute/columns beginning with upper case
letters would sort separately from those beginning with lower case letters).
Acceptable: Employment Status Code
Acceptable (note acronym): GL Account Number
Not Acceptable: student birth date
Numbers must be qualified: Numbers may be used, but must be explained with other terms
in the attribute name.
Acceptable: Form 1099 Status Code
Not Acceptable: 1994
INCLUDE CONTEXT INFORMATION AS APPROPRIATE. Each attribute will be named
according to what it is rather than how it may be used or decoded.
For example an attribute which will be populated by a code that will be decoded by another
entity will have a name which describes the use of the specific code, rather than the
name of the attribute which will decode it. Employee Residence State Code and
Employee Birth State Code may be two attributes in the same entity. Neither will be
named simply state code even though that may be the name of the attribute in the State
Abbreviation entity that will decode them.
FOLLOW A 3-Part STRUCTURE. Attribute names will normally be a noun phrase constructed
following the subject/modifier/class word technique.

7 of 18
 An example and a description of that technique.
subject modifier class word

student birth date

student id
GL account number
contribution current status code

Table entries result in the following attribute names:

Student Birth Date
Student Id
GL Account Number
Contribution Current Status Code

The subject/modifier/class word noun phrase approach builds an attribute name as follows:
Class Word. The root part of the attribute name is the class word, which classifies the type of
information being represented by the attribute. Class words approved for use are:
amount indicator rate
code initial reference
date name sound
description number text
identifier percentage time
image quantity unit

The definitions and the descriptions of usage of all class words approved for use are presented
in a separate chapter later in this document.
Modifier. Immediately preceding the class word is a modifier, which serves to further qualify
the class word.
The modifier may be a single term or a group of terms. There is no standard list of
modifiers. Users are encouraged to create modifiers which are brief, but meaningful. In
some cases the modifier may be omitted from the name, as in the case of "Student Id"
above.
The analyst is encouraged to use modifiers in order to make attribute names more
descriptive rather than less. Only when the name becomes unacceptably burdensome for the
user to deal with or when compelling historical usage requires it, should compromises be
made to the full noun phrase approach.
Subject. Finally, to provide uniqueness, a subject is added as the first term in the attribute name.
The subject provides meaning, to the attribute name by providing the proper context for the
modifier and class word. Though there is no standard list of subjects, the terms which are
good candidates to become subjects are typically nouns which name things which are
common throughout the enterprise.
Examples of subjects include: account, employee, student, course and GL. Though entity
names are candidate subjects, they are often too long to act as a subject. Also, subjects may
be composed of several terms, but brevity is necessary to accommodate the rest of the noun
phrase within a name of reasonable size.

8 of 18
USE THE APPROPRIATE STANDARD TERMS. Attribute names must be composed of the
standard "terms" for a logical model. In logical models, the standard terms are mostly
spelled out words, but there are also a few mandatory abbreviations.

Check the Terms List in the chapter on Abbreviations, Acronyms and Other Terms for a list of
the appropriate terms for a logical model and for further information about terms in general.

In summary, when creating attribute names in a logical model, you should:

Refer to the Logical Models & External Schema column of the Terms List presented in the
Abbreviations chapter and only use terms from that column.
If additional abbreviation of a word is needed for space considerations, refer to the Internal
Schema column for other standard abbreviations. These may be used on an optional basis in
logical models and external schemas, but the spelled out word is preferable.

Sample of Terms List:

WORD LOGICAL PHYSICAL

Advisor advisor advr

Amount amt amt
Agreement agreement agree
Appointment appt appt
Area area area
Award award awd
- Mandatory Abbreviation

Column Names in Internal Schemas

Standards
Column names in the internal schema will be the same as the attribute name in the logical model
upon which the column name is based, with the following exceptions.
USE UNDERSCORES FOR SPACES: Underscore characters will replace spaces as the
dividers between terms in the name.
USE THE APPROPRIATE STANDARD TERMS: Column names must be composed of the
standard "terms" for an internal schema. In internal schemas, the standard terms are mostly
abbreviations, but there are also some words which are always spelled out.

Check the Terms List in the chapter on Abbreviations, Acronyms and Other Terms for a list of
the appropriate terms and for further information about terms in general.
In summary, when creating column names in an internal schema, you should:
Refer to the Internal Schema column of the Terms List presented in the Abbreviations chapter
and only use terms from that column.

9 of 18
 Sample of Terms List:
WORD LOGICAL PHYSICAL

Advisor advisor advr

Amount amt amt
Agreement agreement agree
Appointment appt appt
Area area area
Award award awd
- Mandatory Abbreviation

Column Names in External Schema

Standards
Column names in the external schema will be the same as the attribute name in the logical
model upon which the column name is based, with the following exception:
USE UNDERSCORES FOR SPACES: Underscore characters will replace spaces as the
dividers between terms in the name.
USE APPROPRIATE STANDARD TERMS. Column names in external schema should be user-
friendly and consist of the same terms as used for logical models (see section A.4). Refer to
the Logical Models & External Schema column of the Terms List in the Abbreviations
chapter.

Column/Column Descriptions
Standards
An attribute description will develop over time as the attribute becomes understood. When it is
fully implemented it will include the following components:
BRIEF NARRATIVE: A brief narrative definition of the attribute which conforms to the
following format.
Begin with the role of the data being described.
The name of the...
The date of the...
The code of the...
Follow the role with a reference to the subject component of the "subject, modifier, class
word" name convention described earlier.
The name of the student
The date of the employee
The code representing the type of Sponsored Project
Follow the subject with one or two statements which concisely describe the data. More
statements for a detailed description and fewer statements for a short description.
The name of the student applying for aid.
The date of the employee's birth
The code representing the type of aid a student received
The code representing the focus of a Sponsored Project
10 of 18
FULL NARRATIVE: A fully detailed definition of the attribute which conforms to the format
described above. "Fully detailed" in this context means using enough of the statements
described in Item c. above to describe the attribute fully.
The Project Function Code describes the nature or focus of a Sponsored Project. Sponsored
projects are categorized under general headings such as research and grants.
Classification of a sponsored project into a category determines the appropriate indirect
cost rate to be charged.
The Project Function Code will generally match the Budget Function Code of the parent
account associated with the project. Projects that are mixed function are coded as
multiple.
HISTORY OF CHANGES: The history of any changes/refinements to the full detailed
definition annotated with the date of the update and the initials of the author. The history
will always be displayed in reverse chronological order.
1-15-95 New Project Function Code approved and implemented. Project Function Code = e
Project Function Name = none
06-04-92 Project Function Code s agreed to with users
DOMAIN: The domain of the attribute, if it is a relatively static set of known data, or examples
of the data if the data is not a known set.

Example
Project Function Code Project Function Name

a Instruction
b Research
c Miscellaneous
d Multiple
e None

DERIVATION: The derivation of the attribute (if known).N/A

EDIT MASK: The edit mask for the attribute. character 1
SOURCE: Source of the attribute; The original source of this attribute is the selection of a
Project Function Code made by a user when setting up a new Sponsored Research Project.
Instruction Research
Miscellaneous
Multiple
None

11 of 18
Relationships
Definition
Relationships are statements of business policy and business rules expressed as the description
of an association between two entities in a data model.

Relationship Names
Standards
USE THE VERB FROM THE VERB PHRASE FOR A NAME. The name of the relationship
between two entities is the word which is the verb from the verb phrase from a declarative
sentence which describes the relationship.
The name of the following relationship is 'receive:'
each Employee must receive one or more Performance Review.
The name of the following relationship is 'offered':
each Course may be offered via one or more Course Offering
USE NAME IN CONTEXT TO ENSURE CLARITY. The relationship name will only be used
in the context of the two entities. For example an analyst might use the relationship name in
the following way:
"Let's discuss the 'receive' relationship between Employee and Performance Review"
"This stored procedure implements the 'offered' relationship between Course and Course
Offering."
MAKE EACH NAME UNIQUE BETWEEN THE SAME TWO ENTITIES. Because more
than one relationship may exist between two entities each relationship name must be unique
between the same two entities.
USE LOWER CASE LETTERS. Relationship names will be presented using lower case letters

Relationship Descriptions
Standards
A relationship must be thought of as a business rule, stating a fact which the Conceptual Data
Model is trying to capture and communicate. Each relationship or business rule makes a
statement that can be judged as "true" or "false" by the business users who are the Subject
Matter Experts (SMEs) about the area of business the relationship helps describe.
USE SUBJECT/VERB PHRASE/OBJECT STRUCTURE: Relationship descriptions will be
standard declarative sentences, consisting of a subject (source entity), verb phrase, and
object (cardinality and target entity), in that order.
MAKE THE SUBJECT THE SOURCE ENTITY. The subject will be the entity from which the
relationship originates, often referred to as the source entity. It will be constructed with the
modifier "Each" followed by the source entity name, such as:
Each Person
Each Organizational Unit
Each Unit of Instruction, etc.
FOLLOW THE SUBJECT WITH AN APPROPRIATE VERB PHRASE.
Following the subject is a description of the nature of the relationship. This description
should be a verb phrase. The verb phrase will be constructed as follows:
The word "must" or "may" will begin the verb phrase as a modifier to the actual verb
12 of 18
 The actual verb may directly follow the modifier, such as:
Each Invoice must contain
Each Person must be required
Each Customer may have
Each Product may belong, etc.
The verb phrase may be separated from the modifier by a prepositional phrase, such as:
Each Position may, over time, have,
Each Organization must, at one time, be composed of
The verb phrase may also be followed by a prepositional phrase, such as:
Each Course may be, over time, etc.
The verb phrase may end in an infinitive, such as:
Each Student must be required to have.
FINISH WITH CARDINALITY PLUS TARGET ENTITY FOR THE OBJECT.
The object, or the completer, of the relationship sentence follows the verb phrase. It consists of
the cardinality phrase followed by the target entity name. The cardinality phrase is an
indefinite pronoun "one" or "one or more" which is used as an adjective of the target entity.
The object may also be a prepositional phrase which includes the cardinality phrase.
Each Product may, over time, belong to one Product Family
Each Employee must receive one or more Performance Review
Each Course may be offered via one or more Course Offering, etc.

13 of 18
Class Words
Definition
A class word is a word or term that defines the content and role of a piece of data described by an
attribute (this is in contrast to a Domain, which defines the format and range of values of an
attribute instance).
A class word is defined by its name and description, and is further defined by a list of values
(domain).

Class Word Usage

Standards
ASSIGN A CLASS WORD TO EVERY ATTRIBUTE AND COLUMN.
Each attribute and column must be associated with a class word, in accordance with the
Attribute/Column Naming Standard. The class word, in this sense, is included as part of the
definition of the attribute.
ASSIGN CLASS WORDS ACCORDING TO THE NATURE OF THE DATA ITSELF.
Class words are not tied to specific data formats or editing rules. Class words will imply what
the rules might be, but the specific rules can vary between attributes with the same class
word.
Note: Though tying class words to format rules would be a benefit to data users there are a
significant number of widely accepted business terms which use class words inexactly. For
example the term "number" is properly formatted as a numeric but common practice, e.g.
California Drivers License Number, requires that it be formatted as an alpha numeric.
Common business practice has institutionalised these usages, and will continue to do so. In
the face of numerous occurrences of this inexactness, attempting to implement the
"correctness" of tying formats to class words is not practical.
ASSIGN CLASS WORDS FROM THE CORRECT CLASS WORD CATEGORY.
Class words are categorized as playing one of four different roles in a data base. Those roles are:
LABEL - A data item created primarily for the purpose of naming or identifying and
distinguishing instances of an entity (a person, a row in a table, etc.). When labels act as
names they are not necessarily unique and may be part of an unbounded set, as in the case of
a person's name or the name of the city a person was born in. If the data was originally
created to name something it is a label. When labels act as identifiers or indicators they are
still names, but the names are often codes developed specifically to aid in data processing.
SSN and gender id are examples of this second variation to the Label role.
MEASUREMENT - A data item created primarily for the purpose of representing a
measurement (in some defined unit) or pure number suitable for use in calculations beyond
simple additions and subtractions. Specifically, data which indicates dimension, capacity,
amount, performance or duration.
CHRONOLOGY - A data item created primarily for the purpose of indicating a point or span of
time.
DESCRIPTION - A string of characters that is not treated as "fielded" data. It is used primarily
for the purpose of allowing the free-form entry of terms used to describe some characteristic
of an instance of an entity.

Class words assigned to each of these categories may only function in the role defined by the
category name. This standard allows a data user to know the role an attribute plays in the data base

14 of 18
by noting the class word used in the attribute name. For example label attributes can be easily
identified. This is particularly useful when reviewing unfamiliar data bases.

List of Standard Class Words

Class words are presented by class word category.
LABEL - Label class words are:
Code - A set of one or more symbols, letters, and/or numbers that represents a more meaningful
and descriptive piece of business information (usually the title or description of some
business object). Sometimes the meaning of a code is intuitively obvious by the code itself
(at least to the Subject Matter Expert). A code usually represents a fairly static set of values
(e.g. US State Codes).
Identifier - A unique label of an entity. Identifiers come in two "flavours:" business and
surrogate. Business identifiers are those commonly used by a business unit to identify a
business object, such as a part number being the normal identifier for Part, product number
for Product, etc. These identifiers may carry some intrinsic meaning, or they may be "non-
intelligent." Surrogate identifiers usually have no meaning or intelligence -- they are simply
unique keys.
Indicator - An identifier which has a domain of only 2 states, such as: Y/N, ON/OFF,
TRUE/FALSE, 0/1, etc.
Initial - A single character field to denote an initial. Usually used for a middle initial in a
persons name.
Name - A character string which gives the name or title of a business object. It is usually a
commonly-used, descriptive name or title, but is not to be confused with a short description.
It is usually a proper name or title, such as Person Name, Product Name, Article Name, etc.
Number - A value which is not for the purpose of measuring a quantity or serving as a counter,
but which is usually a numeric value (it may contain non-numeric characters, such as a
Product Number, PO Number, etc.). It is distinguishable in that arithmetic operations are not
usually carried out on it.
Reference - A special type of label that indicates that the field is kept only for reference
purposes. i.e. it is a flied that exists in another system that is not used generally because it
has been replaced. However the users understand this field so well that it is important for
continuity to keep it in an entity for reference purposes. Usually it is an old entity identifier.
When used it is usually added onto the end of a class word as an extra word. E.g. we may be
joining different types of loans that come from separate systems such as: car loans system,
Boat loans system so we may have a field Boat Loan Identifier Reference
Unit - A character string denoting what type of measurement units are being used. e.g. kg,
metres, box, feet etc.
MEASUREMENT- Measurement class words are:
Amount - A numeric measurement of monetary value, e.g. dollars and/or cents ($99, $99.99).
This can also be referred to as cost or price. An amount field may be specified as an integer,
or may include decimal positions, may be positive or negative, or may be in various units of
measurement, depending upon the specific domain associated with the attribute.
Quantity - A number that represents the counted value of some business event or other object,
such as: Order Quantity, Returned Quantity, etc.
Rate - A number that represents a factor.
Percentage - This is similar to rate but specifically used for a percentage.
CHRONOLOGY - Chronology class words are:

15 of 18
 Date - A point in time in terms of day, month, or year in any combination. This includes Julian
dates (DDDYY), calendar days (MMDDYYYY, YYYYMMDD), fiscal dates, etc.
Time - A point in time, or measurement stated in terms of hour, minute, second, or fraction
thereof, in any combination (HH:MM:SS, HHMMSS, HH, etc.). This does not include
quantity of hours, e.g. the number of hours to perform a task is not a time, but a quantity.
DESCRIPTION - Description class words are:
Text - An unconstrained string of characters, or any freeform comment or notes field. Text,
unlike name, description, and address, does not have any specific pre-determined purpose.
Description - An word or phrase which interprets an abbreviation, code or other shortened term
so as to make it more understandable to users.
Examples include: California is the description of the abbreviation CA.
(UNCLASSIFIED) - Currently unclassified class words are:
Sound
A binary object that contains a (series of) sound(s).
Image
The binary representation of a picture, a photograph, etc.

List of Standard Class Words

Mandatory
Category Class Word Abbreviation

Measurement amount amt

Label code cd
Chronology date dt
Description description desc
Label identifier id
Unclassified image img
Label indicator ind
Label initial ini
Label name na
Label number num
Measurement percentage perc
Measurement quantity qty
Measurement rate rt
Label reference ref
Unclassified sound snd
Description text txt
Chronology time tm
Label unit unt

Abbreviations, Acronyms and Other Terms:

16 of 18
Definition
Abbreviations are shortened forms of a word, for example "dept" for "department". Acronyms are
generally shortened forms of a phrase, for example "SSN" for "social security number". Both
abbreviations and acronyms can be helpful, efficient ways to refer to commonly used words;
however they can also cause problems if there are not consistent standards about their use.
In this document, the word "term" is used to refer to any one component of an entity/table or
attribute/column name. The word term is used instead of the word "word" because in many cases
acceptable terms will be abbreviations or acronyms, rather than regular words. Terms may be
abbreviations, acronyms, shortened words which are not constructed according to the rules of either
abbreviations or acronyms, or fully spelled out words which usually have six or fewer characters.
All model names should be composed of terms from the standard Terms List included at the end of
this chapter. Specifying standard terms and term usage makes it possible to establish when
abbreviations and acronyms are used, and what abbreviations and acronyms are used. The Terms
List will be maintained and updated by Data Administration.

Use of the Terms List

When constructing entity/table or attribute/column names, all terms in the name should be taken
from the appropriate column in the Terms List.
For Logical Models and External Schema, it is desirable to have names that are as self-explanatory
as possible. Therefore most of the terms in that column consist of spelled out words. In a few cases,
mandatory abbreviated versions of a word are included instead, in cases where a word is very long,
very common, and/or has a well-known abbreviation or acronym. If a situation arises, where a name
is simply too long unless additional words are abbreviated, then abbreviations from the column of
Internal Schema terms may be used.
For Internal Schema, it is desirable to have short, abbreviated names. Therefore most of the terms in
that column consist of abbreviated words. Some words were left unabbreviated because they are
already short, or they might be ambiguous if abbreviated.
If any terms need to be changed or added, consult with Data Administration.

Standards for Terms

All of the terms included in the list must adhere to these standards:
Terms must be unique. One term can stand for closely related words, but not for completely
different words.
Terms will be in singular form.
Special characters will not be used in a term.
Terms will follow the case standard for the model in which they are used, i.e. all in title case if
being used for the entity tables in the logical model.

Abbreviation Formulation
Standard abbreviations must be formed in such a way that they make sense to business users.
Abbreviations should be formed by following the following steps:
remove unnecessary vowels,
remove unnecessary consonants,
substitute prefixes and suffixes, if possible.

Acronym Formulation
17 of 18
Acronyms should be taken from standard business usage, such as MBA for "Masters of Business
Administration," AMA for "American Medical Association," MBO for "Management by
Objective," etc.
If acronyms are to be created, they should be formed by concatenating the first letter of each
"significant" word of a business phrase. This may be used when creating names for projects,
organizations, etc. An example would be: ASC for Ascential Software.

Guidelines
Abbreviation Guidelines
Abbreviations should usually be tied to only one full-length business word.
Abbreviations should be unique within all data models within a specific business area, and across
the enterprise, if possible.
Multiple words that are commonly used together may be abbreviated when generating Physical
Data Models. For example, the attributes containing the phrase "Effective Date" may be
abbreviated "effdt" if desired by the DBA.
The modeller should strive for abbreviations that have meaning to the business community, instead
of the IS community.
Existing abbreviations should be used if they are commonly used by a business organization, even if
they do not follow the naming standard above. However, they must still be unique.
Acronym Guidelines
Acronyms should adhere to industry standards wherever possible.
Acronyms may have more than one translation, but this should be avoided.
When an acronym has more than one translation, it's specific meaning should be discernible from
the context in which it is used; if it is not, the acronym should not be used.

Terms List
Terms for Logical Models and External Schema:
In general, the terms are spelled out words; the few mandatory abbreviations are noted in the
reference list.
If additional abbreviations are needed upon occasion, choose from the ones listed in the Internal
Schema column.
Terms for Internal Schema:
In general, the terms are abbreviated. However, where a term is shown in its full, spelled out
form, that usage should be followed.

18 of 18