Beruflich Dokumente
Kultur Dokumente
Version 1.9
January 15, 2004
Business Consulting Services
Revision History
Date Version Description Author
July 8, 2002 1.0 Draft M. Nawabzada, J. Singer, A. Merchant & CCTC
July 24, 2002 1.1 Draft M. Nawabzada, J. Singer, A. Merchant & CCTC
August 29, 2002 1.2 Draft M. Nawabzada, J. Singer, A. Merchant & CCTC
October 18, 2002 1.3 Draft M. Nawabzada, J. Singer, A. Merchant & CCTC
October 29, 2002 1.4 Draft M. Nawabzada, J. Singer, A. Merchant & CCTC
November 6, 2002 1.5 Draft M. Nawabzada, J. Singer, A. Merchant & CCTC
November 20, 2002 1.6 Final CCTC
April 29, 2003 1.7 Final M. Nawabzada, J. Singer, A. Merchant & CCTC
July 15, 2003 1.8 Final M. Nawabzada, J. Singer, A. Merchant & CCTC
January 15, 2004 1.9 Final J.Singer, Darren Addington, Judy Cullum, G. Burnet, A.
Merchant
Table of Contents
1. Introduction 1
1.3 Overview 1
1.4 References 1
2.2 Attributes 2
2.4 Relationships 4
3. Data Dictionary 5
PURPOSE 53
APPENDIX B – GLOSSARY 56
Non-Key Attributes
PARTICIPANT PARTICIPANT_ADDRESS
PARTICIPANT_ID PARTICIPANT_ADDR_SEQ_NMBR
PARTICIPANT_ID (FK)
COMPLETE_COMMUNICATION CASE
CASE_COMMUNICATION
COMMUNICATION_ID CASE_ID
COMMUNICATION_ID
CASE_ID (FK)
(FK)
Supertype
Entity Type COMMUNICA
TION
COMMUNICATI
ON_ID
COMMUNICATION_STA
COMMUNICATION_ST
RT_DATE
COMMUNICATION_ST
ART_TIME
COMPL_I
OP_TIME
COMMUNICATION_MET
ND
HOD_CAT
INCOMPLETE_COMMU COMPLETE_COMMU
NICATION
COMMUNICATION NICATION
COMMUNICATION
_ID (FK)
INCOMPLETE_REAS _ID (FK)
AID_ORG
ON_CAT SCHOOL_POC_SE
_ID
SCHOOL
Q_NMBR
PARTICIPA
_ID
AID_ORG_POC_SE
NT_ID
COMMUNICATION
Q_NMBR
CUSTOMER_FEEDBA
_DESC
CK_DESC
Figure 2-4: Super-type and Subtype Entity Types
2.4 Relationships
A relationship is an association between two entity types expressing a connection between them that is of
importance to the business. Typically, relationships can be described in terms of verbs. Since entity
types are nouns, a short sentence can be constructed using one entity (noun) as the subject and the
other as the object with the verb (relationship) in the middle. For example, a PARTICIPANT USES a
PARTICIPANT_ADDRESS; or a PARTICIPANT_ADDRESS IS_USED_BY a PARTICIPANT.
PARTICIPANT and PARTICIPANT_ADDRESS are the entity type names and USES/IS_USED_BY are
the relationship names. Relationships are represented in the data model using a line connecting the two
related entity types. The Figure 2-5: Cardinality and Optionality for a graphical representation of a
relationship. Two important characteristics of relationships are optionality and cardinality.
The optionality identifies whether a relationship must exist (is mandatory) or may exist (is optional) at the
instance when an occurrence of an entity is created, (e.g., if a PARTICIPANT must relate to a
PARTICIPANT_NAME when it is created, then the relationship is mandatory). If a PARTICIPANT can be
created without referencing a PARTICIPANT_NAME, the relationship is optional and is marked with an
“O”. The optionality symbol is placed at the end of the relationship opposite from the entity being
created. Two separate optionality symbols are required -- one at each end of the relationship line so that
optionality is explained for both members of the relationship.
The cardinality marking on a relationship identifies whether one or many occurrences of an entity may
exist for each occurrence of the related entity. A "crow's foot" at the end of the relationship means that
many occurrences of that entity can relate to a single occurrence of the entity at the other end of the
relationship. A straight line (without the crow's foot) means that a maximum of one entity occurrence may
exist for a single occurrence of the related entity. Thus a relationship may have one of the following
cardinalities: One-to-one; One-to-many; or Many-to-many.
Cardinality
one many
PARTICIPANT PARTICIPANT_ADDRESS
PARTICIPANT_ID PARTICIPANT_ADDR_SEQ_NMBR
BIRTH_DATE PARTICIPANT_ID (FK)
CITY_NAME
mandatory optional
Optionality
The most common type of relationship is one-to-many (e.g., a PARTICIPANT can have one or many
PARTICIPANT_ADDRESS). In the context of one-to-many relationships, the terms parent and child are
often used to refer to the entity types at the one-end and at the many-end of the relationship, respectively.
One-to-one relationships are relatively uncommon. An example of this type would be one DRIVER holds
one DRIVER'S LICENSE. Many-to-many relationships are “unresolved” and require that one associative
entity type and two one-to-many relationships be introduced to resolve the relation
3. Data Dictionary
This section provides the Data Dictionary that supports the Graphical representation of the Logical Data
Model. The Data Dictionary consists of the Entity Name, Entity Type, Entity Definition, Attribute Name
and Attribute definition. The Data Dictionary is in alphabetized by entity name and attributes are placed in
the order as scene on the graphical representation of the LDM.
APP_DENIED_FLG An indicator that states an applicant has had an APPLICATION denied in the
past.
APP_DENIED_DESC The applicant’s electronic description of the denied APPLICATION
circumstances.
DOC_CATEGORY_CD The code associated with the DOCUMENT CATEGORY. E.g. AA, FT, AR,
NT, RN. RI.
DOC_CATEGORY_DESC The description of the DOCUMENT CATEGORY. E.g. Added Authorization,
First Time, Added Restriction, New Type , Renewal and Re-Issuance
ENTITY NAME ENTITY TYPE ENTITY DEFINITION
DOC_RESTRICT Dependent DOC RESTRICT is an association between a DOCUMENT and an employment
RESTRICTION ORGANIZATION.
Attribute Name Attribute Definition
DOC_RESTRICT_ID The unique identifier for an occurrence of a DOCUMENT RESTRICTION.
DOCUMENT_ID The unique identifier for an occurrence of a DOCUMENT.
ORGANIZATION_ID The unique identifier for an occurrence of an ORGANIZATION.
ORG_TYPE_ID The unique identifier for an occurrence of a ORG_TYPE.
APPLICATION_ID The unique identifier for an occurrence of an APPLICATION.
ENTITY NAME ENTITY TYPE ENTITY DEFINITION
DOC_STATUS Independent DOC STATUS is the status of a DOCUMENT. E.g. GRNT = Granted
Attribute Name Attribute Definition
DOC_STATUS_ID The unique identifier for an occurrence of a DOC STATUS.
DOC_STATUS_CD The code associated with the DOC STATUS. E.g. GRNT.
NON_APP_STATUS Independent The status used to inactivate the approved program at the IHE's request. E.g. W=
approval withdrawn at institution's request. S = approval suspended at
institution's request.
Attribute Name Attribute Definition
NON_APP_STATUS_ID The unique identifier for an occurrence of a Non Approved status.
NON_APP_STATUS_CD The code associated with the Non Approved status.
NON_APP_STATUS_DESC The description for the Non Approved status.
ENTITY NAME ENTITY TYPE ENTITY DEFINITION
NON_PUBLIC_INFO Independent NON PUBLIC INFO is a state code that is used to identify if a CASE is non
public information. The use of a code on a CASE will enable the CASE
information to be private and not disclosed to the public. E.g., Title 5 80309, Ed
code 44438-PA.
Attribute Name Attribute Definition
NON_PUBLIC_INFO_ID The unique identifier for an occurrence of a NON PUBLIC INFO code.
NON_PUBLIC_INFO_CD The code associated with the NON PUBLIC INFO legislation code.
NON_PUBLIC_INFO_DESC The description of the NON PUBLIC INFO legislation code.
ENTITY NAME ENTITY TYPE ENTITY DEFINITION
NOTES Dependent NOTES is a free form text area to store information about various entities.
Attribute Name Attribute Definition
NOTES_ID The unique identifier for an occurrence of a NOTE.
EMPLOYEE_ID The unique identifier for an occurrence of an EMPLOYEE.
NOTES_TEXT The text of the NOTE.
NOTES_TYPE The type of NOTE. E.g. CASE note, APPLICATION note, etc.
NOTES_DT The date a NOTE was created.
PERSON_ID The unique identifier for an occurrence of a PERSON.
ORGANIZATION_ID The unique identifier for an occurrence of an ORGANIZATION.
DOCUMENT_ID The unique identifier for an occurrence of a DOCUMENT.
REJECT_LETTER_ID The unique identifier for an occurrence of a REJECT LETTER.
CASE_ID The unique identifier for an occurrence of a CASE.
APPLICATION_ID The unique identifier for an occurrence of an APPLICATION.
ENTITY NAME ENTITY TYPE ENTITY DEFINITION
PURPOSE
The purpose of this document is to present Data Modeling Standards for naming entities and attributes in
Logical Data Model This information modeling technique is used to model data in a standard, consistent,
predictable manner in order to manage it as a resource. The primary objectives of these standard are:
• To provide a means for completely understanding and analyzing an organization’s data resources
• To provide a common means of representing and communicating the complexity of data
• To provide a method for presenting an overall view of the data required to run an enterprise
• To provide a means for defining an application-independent view of data which can be validated
by users and transformed into a physical database design
• To provide a method for deriving an integrated data definition from existing data resources
1. Entity design should be based on functional information requirements in support of the mission and
enterprise.
2. An entity should be designed according to logical and not physical characteristics. Physical
characteristics include any connotations regarding technology (hardware or software), physical location
(databases, files, reports, forms or tables), organization (functional data steward, components, projects or
departments), or application (systems, applications, or programs).
3. An entity should be created based on the information requirement. The entity definition should describe
what it is rather than how, where, and when it is used. The entity should be named according to its
definition and represent a single concept.
Class Words
A class word is a noun within an attribute name that defines the generic grouping of data to which an
attribute belongs. Class words are the last component of an attribute name. Class words are reserved words
and must not be used anywhere else in the attribute name. A class word is a modeling technique used to
lend clarity to attribute names. A class word is a means of categorizing data: (Is it time, date, amount, or
coded information).
DEFINITION STANDARDS
• If the name of any object is referenced in a definition, the name must be capitalized.
• The definition must be in sentence form. One or more sentences may be used as required to
complete the definition.
• The format and order of a definition is as follows:
o DEFINITION: (required)
o EXAMPLE: (optional)
ENTITY STANDARDS
These are the guidelines followed when creating and maintaining entities.
ENTITY PROPERTIES
An entity has the following properties:
o Entity Name Required
o Unique Identifier/ Primary Key Required
o Entity Definition Required
o Entity Example Optional
ENTITY NAME
The name of the entity classifies the entity it describes. The name must be a noun or a noun phrase and be
unique within the business. These should be common nouns, not proper nouns. It can contain as many as 30
characters. These characters must be upper case, and not include any special characters. Entities with two
or more words in the name will be separated by an underscore “_.”
Do not use articles (a, an, the) or possessives when naming entity.
• The entity names:
o Shall be clear, accurate, and self-explanatory.
o Shall include only upper case alphabetic characters (A-Z) and spaces.
o Shall be named according to logical and not physical considerations.
o Shall consist of the minimum number of words for labeling. The name should not be
used to redefine the entity nor contain information that more correctly belongs in the
definition.
o May contain a class word, such as date or time, if appropriate.
ATTRIBUTE STANDARDS
These are the guidelines followed when creating and maintaining entities.
ATTRIBUTE PROPERTIES
An attribute is a characteristic of an entity. An attribute has the following properties:
o Attribute Name: Required
o Attribute Definition: Required
o Attribute Example: Optional
ATTRIBUTE NAME
An attribute name is a noun or noun phrase describing the purpose or content of the attribute and reflects
the terminology used in the business. An attribute name must consist of zero or more modifier words; and
may end in one and only one class word. Use upper case alphanumeric characters and underscores to
separate words. Example: The following are valid names for attributes of PERSON:
o PER_FIRST_NM
o PER_LAST_NM
o PER_SSN
FIRST and LAST are used as modifier words. NM is a class words. An attribute must describe one concept
and have singularity of purpose or use. Include the name or abbreviated name of the entity when naming
the attribute. This creates an efficient method of locating the entity that an attribute is contained in. An
attribute name can contain up to 30 alphanumeric characters. It cannot contain special characters.
ATTRIBUTE CONVENTIONS
• An attribute describes exactly one entity.
• An attribute must not have attributes of its own.
• An optional attribute may not participate in an identifier.
• The initial value of an attribute that participates in an identifier may not be changed.
• A derived attribute may not participate in an identifier.
APPENDIX B – GLOSSARY
This appendix lists all the abbreviations, acronyms and class words used in naming the entities and
attributes in the Logical Data Model.