Special System Designs

1970

For
Beginners
Topic Analysis

1|Pagewrite2adnanalamkhan@gmail.com
 SSD
Entities
An entity is something of significance about which the enterprise wishes to store information. They are
shown in capital letters. For example, ORDER represents an entity.

SUBTYPE
A subtype, sometimes referred to as a sub entity, is a classification of an entity that has characteristics
such as attributes or relationships in common with the more general entity. LEGAL ORGANIZATION and
INFORMAL ORGANIZATION are, for example,
subtypes of ORGANIZATION.

Figure 1.2 shows the supertype ORGANIZATION and

its sub-types LEGAL ORGANIZATION and INFORMAL
ORGANIZATION. Notice that the name applies to the
supertype ORGANIZATION and the federal tax ID
applies only to the LEGAL ORGANIZATION subtype. It
is therefore shown at the subtype level of LEGAL
ORGANIZATION because it applies only to that
subtype. Both LEGAL ORGANIZATION and INFORMAL
ORGANIZATION would have a name because they will
inherit the values of the supertype.

Non-Mutually Exclusive Sets of Subtypes

Sometimes, subtypes are not mutually exclusive; in other words, supertypes may be subtyped different
ways and more than one set of subtypes may apply to the same supertype. Consider Figure 1.3, which
shows that a REQUIREMENT may be subtyped different ways. A REQUIREMENT may be from a customer
(CUSTOMER REQUIREMENT) or may represent an internal requirement of the enterprise (INTERNAL
REQUIREMENT). At the same time, the REQUIREMENT may be a requirement that states the need for a
specific product (PRODUCT REQUIREMENT) or a requirement that states the need for work to be done
(WORK REQUIREMENT).

Attributes An attribute holds a particular piece of information about an entity, such as the order date on
an order. Attributes are identified in the text of the book by boldface, lowercase letters such as the

2|Pagewrite2adnanalamkhan@gmail.com
previous order date example. Attributes may be part of the unique identifier of an entity (also referred to
as a primary key), mandatory, or optional.

# for PK , * for mandatory attribute, o for optional attribute. So, ORDER entity has order ID as a primary
key attribute, order date as a mandatory attribute, and entry date as an optional attribute.
Relationships
Relationships define how two entities are associated with each other.

Relationship Optionality
Relationships may be either optional or mandatory. A dotted relationship line next to an entity means
that the relationship from that entity is optional, and a continuous line means that the relationship is
mandatory (the relationship has to exist for all occurrences of each entity). Figure 1.5 shows a relationship
that "each SHIPMENT must be shipped from one and only one POSTAL ADDRESS."
This means that the postal address for each shipment must be specified in order to create a shipment
instance.

Relationship Cardinality
Relationships may be one-to-one, one-to-many, or many-to-many. This is generally known as the
cardinality of the relationship. The presence of a crowsfoot (a three-pronged line that looks like a crow's
foot) defines whether an entity points to more than one occurrence of another entity. Figure 1.6 shows
that "each ORDER must be composed of one or more ORDER ITEMs" because the crowsfoot is at the
ORDER ITEM side. The other relationship side states that "each ORDER ITEM must be part of one and only
one ORDER."

3|Pagewrite2adnanalamkhan@gmail.com
4|Pagewrite2adnanalamkhan@gmail.com
Foreign Key Relationships
A foreign key is defined as the presence of another entity's (or table's) primary key in an entity (or table).
For example, in Figure 1.6 the order ID from the ORDER entity is part of the ORDER ITEM entity; therefore,
it is a foreign key.
Foreign Key Inheritance
A diagramming convention in this book is to use a tilde (" ~ ") relationship line to indicate that the inherited
foreign key is part of the primary key of the child entity. The tilde ("~") line across the relationship in Figure
1.6 indicates that the order ID is part of the ORDER ITEM entity primary key.

Notice that in all the examples given, each relationship has two relationship names associated with it that
describe the relationship in both directions, as shown in the following format: "Each ENTITY {must be/may
be} relationship name {one and only one/one or more} ENTITY, over time," where the appropriate choices
are filled in. In the models presented, the crowsfeet on the relationships generally point up and to the left
in order to provide a consistent mechanism for reading the diagrams. This tends to organize the data
models in a more understandable format.
Exclusive Arcs
Exclusive arcs are used to identify relationships where an entity is related to two or more other entities,
but only one relationship can exist for a specific entity occurrence. The exclusive arc is represented by a
curved line going through two or more relationship lines. Figure 1.8 shows an example of an exclusive arc.
The relationships are read as "Each INVENTORY ITEM must be either located at one and only FACILITY or
must be located within one and only one CONTAINER, but not both." This communicates that inventory
items are stored at one of two types of levels: They are either located at facilities such as a warehouse or
stored within containers such as a bin that is located within a facility.

5|Pagewrite2adnanalamkhan@gmail.com
Recursive Relationships
Recursive relationships are relationships that show how one entity is related to itself. For example, a
recursive relationship could be modeled either via a relationship pointing from an entity to itself or via a
many-to-many-relationship.

6|Pagewrite2adnanalamkhan@gmail.com
Organization
For a human resources system, the data modeler might show an entity called a department within which
the employees work.
The problem is that an organization may play many roles, depending on the particular circumstance. For
instance, in larger companies, internal organizations sell to each other. When an organization's
information changessuch as a change in addressthe information might be updated in only one of the
many systems where organization information is stored. This, of course, results in inconsistent
information within the enterprise. It may also result in major frustration on the part of managers,
customers, suppliers, and anyone who might want to generate a correct mailing list!
The solution to this redundancy problem is to model an entity called ORGANIZATION that stores
information about a group of people with a common purpose such as a corporation, department, division,
government agency, or nonprofit organization. Basic organizational information, such as its name and
federal tax ID num (for legal entities), is stored once within this entity, reducing redundancy of information
and eliminating possible update discrepancies.

7|Pagewrite2adnanalamkhan@gmail.com
Person
To show separate entities for various types of people such as employees, contractors, supplier contacts,
and customer contacts is a problem.
E.g. For most systems, there would be a separate record for John Smith as a customer contact, then as a
contractor, then as an employee. Much of John Smith's information has remained the same, such as his
name, gender, birth date, skills, and other demographics. Because John Smith's information is stored in
several locations, many systems would have trouble keeping his information accurate and consistent.
Another problem is that the same person may have many different roles at the same time.
For instance, ABC Corporation is a large company with many divisions. Shirley Jones is an employee and
manager of the transportation division. She is also considered a customer of the supplies division. At the
same time, she is the supplier for the publishing division, which needs her services to transport catalogues.
Therefore, Shirley is an employee of one division, a customer contact of another division, and a supplier
contact of yet another division. Rather than have three separate records for Shirley with redundant
information, there should be only one record.

8|Pagewrite2adnanalamkhan@gmail.com
PersonAlternate Model
An alternate model for PERSON with the repeated attributes separated into their own entities. For
instance, the MARITAL STATUS entity allows the maintenance of the history of marital changes, and the
MARITAL STATUS TYPE entity could store instances such as "single," "married," "divorced, and
"widowed."
To reiterate the diagramming , a tilde ("~") across the relationship line indicates that the inherited foreign
key is part of the primary key of the child entity. For instance, the tildes ("~") across the relationship lines
in the top left corner of Figure 2.2b indicate that the party id and marital status type id are part of the
MARITAL STATUS entity primary
Key.
An example of this is in a prison or
correctional facility where the
enterprise would want to maintain a
history of names and aliases. In
these cases, the PERSON NAME
entity can be used to store all the
names and aliases. The current last
name, current first name, current
middle initial, current prefix,
current suffix, and current nickname
attributes are now maintained in
the PERSON NAME and PERSON
NAME TYPE entities. The PERSON
NAME entity stores the name and
the time period during which it is
valid, and the PERSON NAME TYPE
entity maintains the type of name it is in the description attribute.
PARTY
Organizations and people can also serve in similar roles as parties to contracts, buyers, sellers, responsible
parties, or members of other organizations. For example, membership organizations (like a computer
users group) may keep similar information on their corporate members and their individual members.
A super entity named PARTY that has as its two subtypes PERSON and ORGANIZATION. This PARTY entity
will enable storage of some of the common characteristics and relationships that people and organizations
share. Parties are classified into various categories using the entity PARTY CLASSIFICATION, which stores
each category into which parties may belong. There are subtypes for ORGANIZATION CLASSIFICATION
such as INDUSTRY CLASSIFICATION, SIZE CLASSIFICATION, and MINORITY CLASSIFICATION.
PARTY ROLES
The PARTY entity defines the nature of the party, which will not change over time. The PARTY TYPE
classifies the party into certain categories. The PARTY ROLE entity defines how a party acts or, in other
words, what roles the party plays in the context of the enterprise's environment.
The PARTY ROLE allows the enterprise to maintain information (attributes or relationships) about each
party within the context of their specific roles. For example, a certain party may have various contact
information (home address, office address, home phone, cell phone, and so on) regardless of how many
roles he or she may play within the enterprise (the party may be a customer, a supplier, and an agent).

9|Pagewrite2adnanalamkhan@gmail.com
10 | P a g e w r i t e 2 a d n a n a l a m k h a n @ g m a i l . c o m
Organization Roles
The ORGANIZATION roles include DISTRIBUTION CHANNEL (which typically is an AGENT or a
DISTRIBUTOR), COMPETITOR, PARTNER, REGULATORY AGENCY, HOUSEHOLD, ASSOCIATION, SUPPLIER,
various ORGANIZATION UNTTs such as a PARENT ORGANIZATION, SUBSIDIARY, DEPARTMENT, DIVISION,
and OTHER ORGANIZATION UNIT as well as INTERNAL ORGANIZATION, which indicates if the organization
is part of the enterprise or is an external organization.

11 | P a g e w r i t e 2 a d n a n a l a m k h a n @ g m a i l . c o m
An ORGANIZATION UNIT identifies the form of this organization and is useful to identify parts of
organizations as well as maintenance of organizational structures. This role may be further subtyped as a
PARENT ORGANIZATION, SUBSIDIARY, DEPARTMENT, DIVISION, or OTHER ORGANIZATION UNIT to cover
more unique types of organizations that are specific to the enterprise. A PARENT ORGANIZATION is a role
whereby this enterprise encompasses other enterprises.
Common Party Role Subtypes
Each PARTY ROLE may be valid for certain time frames, and therefore the attributes from date and thru
date are part of the PARTY ROLE. These attributes are optional because many of the time frames for the
roles will be dependent on (and can be derived from) the PARTY RELATIONSHIP entity, which will be
discussed in the next section. These attributes are particularly useful for relationship-independent roles
such as "notary" or "doctor."

TYPEs (party taking order, party giving order, party paying for the order) associated with PARTYs.
The PARTY RELATIONSHIP entity has attributes of from date and thru date in order to show when the
relationship started and optionally when (and if) it ended.

12 | P a g e w r i t e 2 a d n a n a l a m k h a n @ g m a i l . c o m
13 | P a g e w r i t e 2 a d n a n a l a m k h a n @ g m a i l . c o m
14 | P a g e w r i t e 2 a d n a n a l a m k h a n @ g m a i l . c o m
Barry Cunningham is a contractor for the parent company, ABC Corporation. Table shows person-to-
person relationship examples. These relationships are stored in the same entity (PARTY RELATIONSHIP)
as organization-to-organization relationships; however, above table shows only person-to-person
relationships for ease of understanding.

Party Relationship Information

Each PARTY RELATIONSHIP may have a PRIORITY TYPE, a PARTY RELATIONSHIP STATUS TYPE, and several
COMMUNICATION EVENTs associated with it. The PRIORITY TYPE entity establishes the relative
importance of the relationship to the enterprise. Examples may include "very high," "high," "medium,"
and "low." Alternatively, an enterprise may choose to use "first," "second," "third," and so on to prioritize
the importance of various relationships. The PARTY RELATIONSHIP STATUS TYPE entity defines it.

15 | P a g e w r i t e 2 a d n a n a l a m k h a n @ g m a i l . c o m
First of all, how does one know how many contact numbers to allow for and what types? What if someone
has two or three home addresses or home phones? What if new mechanisms arise for contacting people?
In practice, when the database doesn't allow for all possibilities, the user just adds this information into
the "comment" field which makes searching much more difficult!

16 | P a g e w r i t e 2 a d n a n a l a m k h a n @ g m a i l . c o m
Postal Address Information
One way to contact a person or organization is by either visiting them at their address or mailing them at
their postal address. The POSTAL ADDRESS entity maintains all addresses used by the enterprise in a
central place. The PARTY POSTAL ADDRESS entity shows which POSTAL ADDRESSes are related to which
PARTYs. The GEOGRAPHIC BOUNDARY entity maintains any type of encompassing area such as a COUNTY,
CITY, STATE, COUNTRY, POSTAL CODE, PROVINCE, or TERRITORY. The directions attribute provides
instructions on what roads to travel and what turns to take in order to arrive at that address.

17 | P a g e w r i t e 2 a d n a n a l a m k h a n @ g m a i l . c o m
Geographic Boundaries
Each address may have many other GEOGRAPHIC BOUNDARYs. For example, each POSTAL ADDRESS may
have a CITY, PROVINCE, TERRITORY, or other GEOGRAPHIC BOUNDARY, depending on its location within
the world. POSTAL ADDRESSES may also be identified within other boundaries such as a SALES TERRITORY,
SERVICE TERRITORY, or REGION.

18 | P a g e w r i t e 2 a d n a n a l a m k h a n @ g m a i l . c o m
Party Contact Mechanism-Telecommunications Numbers and Electronic Addresses
The CONTACT MECHANISM TYPE entity shows all the possible values for types of contact mechanism.
Examples include "phone," "fax," "modem,"

19 | P a g e w r i t e 2 a d n a n a l a m k h a n @ g m a i l . c o m
20 | P a g e w r i t e 2 a d n a n a l a m k h a n @ g m a i l . c o m