Naming Standards
for
Data Models

DRAFT
March 26, 1996
Version 1.3

First edition - Version 1.3
Copyright © 1995 by Stanford University. All rights reserved.

No portion of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying and recording, or by any information storage or retrieval system without the prior written permission of Stanford University.

For more information contact:

Douglas F. Smith, Jr., 415-725-1007, dsmithjr@leland.stanford.edu

Naming Standards for Data Models

Table of Contents . . . ToC (link)

• Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
  • What is a Data Model? . . . . . . . . . . . . .. . . . . . . 5
• Entities and Tables . . . . . . . . . . . . . . . . . . . . . . 7
  • Definition. . . . . . . . . . . . . . . . . . . . . . . . . . 7
  • Entity/Table Names. . . . . . . . . . . . . . . . . . . . . . 7
    1. Entity Names in Logical Models. . . . . . . . . . . . . . 7
    2. Table Names in Internal Schema 9
    3. Table Names in External Schema 10
  • Entity/Table Descriptions 10
• Attributes and Columns. . . . . . . . . . 12
  • Definition . . . . . . . . . . 12
    1. Attribute/Column Names . . . . . . . . . . 13
    2. Attribute Names in Logical Models . . . . . . . . . . 13
    3. Column Names in Internal Schema . . . . . . . . . . 16
    4. Column Names in External Schema . . . . . . . . . . 16
  • Attribute/Column Descriptions . . . . . . . . . . 17
• Relationships . . . . . . . . . . 19
  • Definition . . . . . . . . . . 19
  • Relationship Names . . . . . . . . . . 19
  • Relationship Descriptions . . . . . . . . . . 20
• Class Words . . . . . . . . . . 22
  • Definition . . . . . . . . . . 22
  • Class Word Usage . . . . . . . . . . 22
  • List of Standard Class Words . . . . . . . . . . 23
• Abbreviations, Acronyms and Other Terms . . . . . . . . . . 25
  • Definition . . . . . . . . . . 25
  • Use of the Terms List . . . . . . . . . . 26
  • Standards for Terms . . . . . . . . . . 26
  • Abbreviation Formulation . . . . . . . . . . 26
  • Acronym Formulation . . . . . . . . . . 27
  • Guidelines . . . . . . . . . . 27
    • Abbreviation Guidelines . . . . . . . . . . 27
    • Acronym Guidelines . . . . . . . . . . 27
  • Terms List . . . . . . . . . . 28

  ---

  (ToC)

  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 which 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 modeling and database design. It is not intended as a tutorial or instructional text of any type, although there are some definitions of modeling 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 modeling at SU 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 modeling has one type of schema in the logical model and two types of schemas in the physical model.

  1. 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 modeled, 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 cirumstances it may be necessary to include derived data in a logical model, but it must be labeled as such.
     
     
  2. 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 subsets 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.
     
     
  3. 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
     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.

  ---

  (ToC)

  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:

    1. ARE UNIQUE. Entity names must be unique within the SU ITSS library of approved data models.
    2. FOLLOW CORRECT FORMAT. Entities names will have the following format rules:
       1. An entity name will be in title case.
          • Student
          • Other Institution Name
          • State Type
       2. Numbers may be used.
          • Fed 1099 Type
       3. No special characters are allowed in an entity name.
          • Acceptable: Student Aid
          • Not Acceptable: Student's Aid
       4. Multiple terms in the name will be separated by spaces.
          • Acceptable: Computer Based Part
          • Not Acceptable: Computer-Based Part

    3. CONSIST OF A SINGULAR NOUN OR NOUN PHRASE.
       An entity name will be a noun or noun phrase in the singular form.
    4. 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.
    5. In summary, when creating entity names in a logical model, you should:
       1. Refer to the Logical Models & External Schema column of the Terms List presented in the Abbreviations chapter and only use terms from that column.
       2. 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:

       ¥ - Mandatory Abbreviation

       WORD		LOGICAL		PHYSICAL
       Advisor		advisor	¥	advr
       Amount	¥	amt	¥	amt
       Agreement		agreement	¥	agree
       Appointment	¥	appt	¥	appt
       Area		area		area
       Award		award	¥	awd

    GUIDELINES

    Entity/table names should also adhere to the following guidelines whenever possible:

    1. DESCRIBE BUSINESS MEANING. The modeler should strive for entity names that have meaning to the user community, instead of the ITSS community, DBAs, programmers, etc.
    2. ARE MEANINGFUL WHEN DESCRIBING AN ASSOCIATIVE ENTITY.
       It is common for modelers 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.
       • Enrollment (vs. simply Student Course)
       • Student Housing Association
    3. 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 modeler may choose to add modifiers to the entity name to distinguish between different "flavors" 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.

    1. USE UNDERSCORES FOR SPACES. Underscore characters will replace spaces as the dividers between terms in the name.
    2. 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.
    3. 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:

    ¥ - Mandatory Abbreviation

    WORD		LOGICAL		PHYSICAL
    Advisor		advisor	¥	advr
    Amount	¥	amt	¥	amt
    Agreement		agreement	¥	agree
    Appointment	¥	appt	¥	appt
    Area		area		area
    Award		award	¥	awd

    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:

    1. USE UNDERSCORES FOR SPACES. Underscore characters will replace spaces as the dividers between terms in the name.
    2. 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.

  ---

  (ToC)

  Entity/Table Descriptions

  The following standards and guidelines apply to entity/table descriptions in all models and schemas.

  STANDARDS

  1. 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.
  2. 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.
  3. 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.
  4. 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.

  ---

  (ToC)

  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:

  1. NOT A DERIVED VALUE (in in a Logical Model):

     Attributes which 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 active SU-ITSS Warehouse or 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 at SU is derived because it is computed from data which is still in existence in the SU 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 labeled 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.

  2. NOT AN ARRAY: Attributes in the logical model and columns in the physical models must not contain arrays or other forms of repeating values.

  3. 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 SU always uses them as a single attribute, so a single concatenated attribute is acceptable in the logical model.

     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.

  4. 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 modeling 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.

  ---

  (ToC)

  Attibute/Column Names

  • Attribute Names in Logical Models

    STANDARDS

    1. ARE UNIQUE. Each and every attribute name in the SU ITSS Enterprise Model must be unique.

    2. FOLLOW CORRECT FORMAT. Attribute names have the following format rules:
       1. 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
       2. Use spaces to separate terms within the name:
          • Acceptable: Employee Visitor Badge Id
          • Not Acceptable: Employee/Visitor Badge Id
       3. 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
       4. 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
    3. 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 which 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 which will decode them.

    4. FOLLOW A 3-Part STRUCTURE. Attribute names will normally be a noun phrase constructed following the subject/modifier/class word technique.

       Examples and a description of that technique follow.

       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 at SU are:
         • amount
         • code
         • date
         • description
         • identifier
         • image
         • indicator
         • name
         • number
         • quantity
         • rate
         • sound
         • text
         • time
         
         The definitions and the descriptions of usage of all class words approved for use at SU 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 candidates subjects, they are often too long to act as a subject. Also, subjects may be composed of several terms, but brevity is necessary to accomodate the rest of the noun phrase within a name of reasonable size.

    5. 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:

       1. Refer to the Logical Models & External Schema column of the Terms List presented in the Abbreviations chapter and only use terms from that column.
       2. 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:

       ¥ - Mandatory Abbreviation

       WORD		LOGICAL		PHYSICAL
       Advisor		advisor	¥	advr
       Amount	¥	amt	¥	amt
       Agreement		agreement	¥	agree
       Appointment	¥	appt	¥	appt
       Area		area		area
       Award		award	¥	awd

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

  1. USE UNDERSCORES FOR SPACES: Underscore characters will replace spaces as the dividers between terms in the name.
  2. 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.

  Sample of Terms List:

  ¥ - Mandatory Abbreviation

  WORD		LOGICAL		PHYSICAL
  Advisor		advisor	¥	advr
  Amount	¥	amt	¥	amt
  Agreement		agreement	¥	agree
  Appointment	¥	appt	¥	appt
  Area		area		area
  Award		award	¥	awd

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

  1. USE UNDERSCORES FOR SPACES: Underscore characters will replace spaces as the dividers between terms in the name.
  2. 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.

Attibute/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:

1. 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 typeof aid a student received
     The code representing the focus of a Sponsored Project

2. 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 at SU. 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.

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

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

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

6. EDIT MASK: The edit mask for the attribute.
   character 1

7. SOURCE: Source of the attributeThe 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

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

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

2. 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."

3. 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.
4. 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.

1. 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.
2. 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.

3. 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 beconstructed as follows:

     The word "must" or "may" will begin the verb phrase as a modifier to the actual verb

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

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

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

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

  2. 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 institutionalized 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.

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

Abbreviations, Acronyms and Other Terms:

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 acronymns, 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.

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 desireable 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 desireable 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 Adminstration.

All of the terms included in the list must adhere to these standards:

1. Terms must be unique. One term can stand for closely related words, but not for completely different words.
2. Terms will be in singular form.
3. Special characters will not be used in a term.
4. 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.

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

1. 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.
2. 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: SU for Stanford University.

Guidelines

• Abbreviation Guidelines
  1. Abbreviations should usually be tied to only one full-length business word.
  2. Abbreviations should be unique within all data models within a specific business area, and across the enterprise, if possible.
  3. Multiple words which 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.
  4. modeler should strive for abbreviations that have meaning to the business community, instead of the IS community.
  5. 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
  1. Acronyms should adhere to industry standards wherever possible.
  2. Acronyms may have more than one translation, but this should be avoided.
  3. 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.