CIS 211C iLearning text notes associated with text slides.

Database Design
Section 2
2.1.1 Lets begin by reviewing conceptual and physical models. Conceptual models
are created to model the functional and informational needs of a business. These
models may be based on the current needs, but can also be a reflection of future
needs. This course is about modeling the information needs of a company.
Functional needs cannot be ignored while modeling data, as they form the only
legitimate basis for the data model. The physical model becomes the source from
which the fully functional database is created.
2.1.6 Lets begin by reviewing conceptual and physical models. Conceptual models
are created to model the functional and informational needs of a business. These
models may be based on the current needs, but can also be a reflection of future
needs. This course is about modeling the information needs of a company.
Functional needs cannot be ignored while modeling data, as they form the only
legitimate basis for the data model. The physical model becomes the source from
which the fully functional database is created.
2.1.7 The goals of entity relationship modeling are to capture all of the information
thats required, to identify the information in only one place, and to not model any
information that can be derived from other information already modeled. Let me
give you several examples of redundancy. You would not want to model the yearly
salary of a person if you already modeled the monthly salary, because you can
multiply the monthly salary to get the yearly salary. You would not want to model
the years worked because that would be derivable from a hire date and the present
date. And also, if you had the birth date of a person you would not need to model
the age, because you can derive the age from the birth date.
2.1.8 The entity relationship model becomes the blueprint to create the actual
database. Therefore, the physical model is the fully functional database, derived
from the entity relationship model and the associated data from the conceptual
model, such as the business rules, functional needs, and informational needs of a
business.
2.2.7 An entity relationship model has three basic parts, the three parts are called:
entities, attributes, and relationships. Lets first describe an entity. An entity is
described as something of significance to the business about which data must be
known. Entities are the major things that you can list about a business and they are
always written as a singular noun. Lets look at some examples.
2.2.8 You are taking this course and are a student; therefore, you would be modeled
as a STUDENT entity. If you think about the school where you teach, a student would

be someone that would sit in one of the desks in your classroom. In data modeling
entities always have instances. Instances are the specific examples of the entities.
For example, you are an instance of the STUDENT entity. The students at your
school also are instances of the STUDENT entity. The example given in the slide
shows an entity labeled CAR and the instances are specific cars: Volkswagen Beetle,
Corvette, etc.
2.2.10 However, remember that the context of the business determines the
entities. For example, on this slide, is DOG an entity or an instance? Well, it
depends. If you are talking about the ANIMAL entity for a veterinary clinic, then DOG
is an instance of the ANIMAL entity. However, if you are talking about different
breeds of dogs for a breeder, then DOG is the entity, and breed is the instance. This
slide addresses the business perspective for which you make your determination.
Entities also have attributes, which well look at next.
2.2.11 An attribute, which is a single-valued property or detail of an entity,
represents something of significance to the business. An attribute tells us
something about an entity. It could describe, quantify, qualify, classify, or specify
something about the entity. By being single-valued, it means that only one piece of
data can be placed in an attribute. For example, if you had multiple phone numbers
you could not use the generic label of phone number as an attribute. Think about a
customer. Some attributes of customer might be the first name, the last name, date
of birth, and possibly the cell phone number. Another way of describing an attribute
is by describing it as a small detail about an entity.
2.2.12 Attributes have data types. This means that each attribute can be classified
as something like a date, or text, or a number. Well discuss data types later when
we translate the conceptual model to the physical model as a database.
2.2.14 When modeling attributes you try to avoid what are called volatile attributes.
Volatile attributes are attributes that change over time. For example, we could
model age of a person, but age is a volatile attribute. Every year, in fact every day,
a persons age changes. We can do the same thing using a non-volatile attribute by
modeling the birth date. Then, if we need to know the age of a person, we can take
the birth date and subtract it from the system date or todays date and we will find
the exact age of a person. This way we do not have to change that attribute every
day, or every time we need new data.
2.2.17 Identifiers allow you to select the attribute or attributes that make that
record unique. Identifiers may be comprised of one or more attributes.
2.3.5 An entity relationship model is a list of the entities and attributes, as well as
all the relationships between the entities that are of importance to the company
being modeled. They provide background information, such as the description of the
entity, the data types, and constraints. This additional background information is

outside of the scope of an ER diagram. The diagram is often part of a model, but a
model does not have to have a diagram.
Section 3
3.1.5 The third part of our data model is the relationship. A relationship is also
something of significance to the business. It expresses how entities are mutually
related. Relationships are modeled as verbs. Relationships always exist between two
entities, or between one entity twice. For example, an EMPLOYEE may be supervised
by another EMPLOYEE. A relationship always has two perspectives, looking from one
entity to the other and then looking back. A relationship is named at both ends. It
also has optionality and cardinality, which well cover next.
3.1.6 All relationships are characterized by two properties. These properties are
called optionality and cardinality. When you look at optionality in a relationship, you
look at whether a relationship is mandatory or optional. These are the only two
choices you have. You must decide on whether each relationship fits these
characteristics. Lets look at two entities. The first one is called EMPLOYEE, the
second one is JOB. EMPLOYEEs have a relationship to their JOBs, and JOBs have a
relationship to EMPLOYEEs. The questions you need to ask when determining
optionality are listed here on the page. Note the use of the words must and can. The
answers using these words determine if a relationship is mandatory or optional.
3.1.7 The other property that every relationship has is cardinality. Cardinality
determines the degree in the relationship and answers the question How many?
Again, there are two choices. How many JOBs does an EMPLOYEE have? One or
more, or just one? From the Employee side, ask the question a JOB may have how
many EMPLOYEEs? Just one, or more than one? Lets look at both optionality and
cardinality illustrated together.
3.1.8 This example shows you how we write relationships using optionality and
cardinality. Notice that both the entities are named and listed in capital letters. The
underlined verb between them is the relationship. So, EMPLOYEEs must have only
one JOB. The solid line emphasizes that it is mandatory that the EMPLOYEE entity
hold only one JOB, indicating just one as the cardinality. And, again, looking back at
the other direction, a JOB may optionally be held by one or more EMPLOYEEs,
indicating one or more as the cardinality.
3.1.10 Looking at this scenario, songs are classified by TYPE and TYPE is a
classification for a SONG. The entities are SONG and TYPE. The relationships are
classified and classification.
3.1.11 Here we examine the SONG entity. Must every SONG have a TPYE? If every
SONG must have a TYPE, then this relationship is mandatory; otherwise it is
optional. In this case, it is required, so the relationship is mandatory. Can a SONG

have more than one TYPE? This determines the cardinality. In this example, the
SONG can only have one TYPE indicating a single cardinality.
3.1.12 Must every TYPE have a SONG? In other words, is this an optional or
mandatory relationship? You can look at this another way; the business rule of the
company determines the optionality of this relationship. Do SONGs get assigned to
a TYPE? Or, are the TYPEs created first and then assigned to SONGs? Can a SONG
ever be without a TYPE, not assigned to any particular TYPE? Can any TYPE have no
SONGs? These are the questions you have to ask in order to determine optionality
of a relationship. In this business case, new TYPEs can be created even if there is no
SONG yet. And a TYPE can have zero, one, or more SONGs.
3.1.15 Using this next business scenario, each CUSTOMER places an ORDER, and
they are allowed to have more than one ORDER. Any ORDER must be placed by only
one CUSTOMER. We actually describe this relationship by talking in a specific way
about the relationship.
3.1.16 We start with the word each. Each ORDER must be placed by one (and
only one) CUSTOMER. Looking from the other direction, we say each CUSTOMER
must place one or more ORDERs. With optionality, we look at the relationship as
being mandatory from ORDER to CUSTOMER, and mandatory from CUSTOMER to
ORDER. We look at cardinality as saying it is a one-to-one relationship between
ORDER and CUSTOMER, but its a many-to-one relationship between CUSTOMER
and ORDER.
3.1.17 This example shows the relationship of EMPLOYEEs to MANAGERs. Since
EMPLOYEEs are MANAGERs, this relationship is self-referential, therefore only one
entity (EMPLOYEE) is needed. The optionality is that every EMPLOYEE must have a
MANAGER, so the relationship is required between EMPLOYEE and MANAGER. Since
not all EMPLOYEEs are MANAGERs, the relationship is optional between MANAGERs
and EMPLOYEEs. Finally, since an EMPLOYEE can only have one MANAGER, the
cardinality is single in this direction, but it is multiple going the other direction.
3.2.7 This example is DJs on Demand, a small company that provides music
services for events. An ER diagram has a specific format, which we are going to
examine now. It is a picture or representation of the model or of a part of the model.
We represent entities by soft boxes. A soft box is a rounded rectangle. Notice that
the entities, CLIENT, EVENT, and THEME, are singular and are in all capital letters.
Lets review a few rules about naming entities. Every entity in a diagram must have
a unique name. No two entities can be named the same. You should be able to
create a formal description of an entity. Also, you want to avoid using reserved
words when you name an entity. Reserved words are the words that the database
will use for specific purposes. Examples are DATE and SELECT and other specific
words that are used by the database engine or by the SQL programming language,
a list of the reserved words is available in Section 0. Another thing to avoid is the

use of the same word to describe an entity and a relationship. An example is the
use of the word guest. You would not say the guest is a guest of and then put the
other entity in. You need to name your relationships different than your entity or
their attributes.
3.2.8 Attributes are then listed below the entity name. Look at number, first
name, last name, phone number, and email address these are the
attributes of CLIENT; notice that they are listed in lower case letters below the entity
name. Attributes can be mandatory or optional. Mandatory attributes must always
be present with any piece of data in the database. The asterisk (or star) represents
mandatory attributes; these mandatory attributes are things that must be stored for
every CLIENT. Optional attributes are attributes where you do not necessarily need
to know the information. The circle represents an optional attribute. Decisions about
whether an attribute is mandatory or optional often reflect the business rules of the
company. It is important, in the construction of a database, that each piece of
information be able to be uniquely identified. The pound symbol (or hash)
represents a unique identifier. As an example, many employers use employee
number to identify their employees. Social security numbers are used by the United
States Government to identify each person that works in the United States.
3.2.9 Lets now examine the way we draw relationships. A relationship is drawn in
three pieces. Every relationship has a name on each side. Every relationship has an
optionality on each side and every relationship has a degree or cardinality on each
side. In this case, we are looking at the relationship between CLIENT and EVENT. The
lines between the two entities are either dashed or solid indicating optionality. They
also terminate in a single toe or a crows foot indicating cardinality.
3.3.6 In ER modeling, we have a language we use called ERDish to describe the
relationship between entities. In this case were looking at the relationship between
EMPLOYEE and DEPARTMENT. First, the EMPLOYEEs must work in one DEPARTMENT.
We place the relationship name and optionality near the entity. The degree or
cardinality is placed near the opposite entity. To read this statement as we flow from
EMPLOYEE to DEPARTMENT, we say each EMPLOYEE must be working in one and
only one DEPARTMENT. Notice that we used a solid line to represent a mandatory
relationship. We use an unbranched line or single toe to represent a one type of
relationship.
3.3.7 Now, lets look at the relationship in the other direction. The DEPARTMENTs
are cost centers for EMPLOYEEs. To read this relationship as we flow from
DEPARTMENT to EMPLOYEE, we say each DEPARTMENT may be the cost center for
one or more EMPLOYEEs. Here, a dashed line represents an optional relationship.
We use a branched line or crows foot to represent a many type of relationship.
3.3.8 The entire diagram is shown in this picture. Remember, relationships can be
mandatory or optional. Do not get this confused with attributes. Attributes can also

be mandatory or optional. Attributes belong to entities. Relationships are between

entities.
3.4 No notes for section 3.4