Logical Database Design and

the Relational Model

 The Relational Data Model
 Integrity Constraints
 Transforming ER/EER Diagrams
into Relations
 Normalization
 Merging Relations

ALLPPT.com _ Free PowerPoint Templates, Diagrams and Charts

The Relational Data Model
 The relational data model was first introduced
in 1970 by E. F. Codd, then of IBM.

Two early research projects were launched to

prove the feasibility of the relational model and
to develop prototype systems.

1. Development of System R.
2. Development of Ingres, an academic-oriented RDBMS
 The relational data model represents data in the
form of tables.

 The relational model is based on mathematical theory

and therefore has a solid theoretical foundation.
The relational data model consists of the following
three components (Fleming and von Halle, 1989):

1. Data structure - data are organized in the form

of tables, with rows and columns.
2. Data manipulation - powerful operations
(using the SQL language) are used to
manipulate data stored in the relations.
3. Data integrity - the model includes mechanisms
to specify business rules that maintain the
integrity of data when they are manipulated.
 EMPLOYEE1 relation with sample data

RELATIONAL DATA STRUCTURE

A relation is a named, two-dimensional table of data. Each
relation (or table) consists of a set of named columns and an
arbitrary
number of unnamed rows. An attribute is a named column of
a relation. Each row of a relation corresponds to a record that
RELATIONAL KEYS

We must be able to store and retrieve a row of data in a relation, based

on the data values stored in that row. To achieve this goal, every relation m
ust have a primary key.

A primary key is an attribute or a combination of attributes that uniquely id

entifies each row in a relation. We designate a primary key by underlining
the attribute name(s).
A composite key is a primary key that consists of more than
one attribute. The primary key for a relation DEPENDENT
would likely consist of the combination EmpID and
DependentName.
 Often we must represent the relationship between two tables or
relations. This is accomplished through the use of foreign keys.

A foreign key is an attribute (possibly composite) in a relation

that serves as the primary key of another relation.
Consider the relations EMPLOYEE1 and DEPARTMENT:

Some authors emphasize the fact that an attribute is a foreign

key by using a dashed underline
PROPERTIES OF RELATIONS
1. Each relation (or table) in a database has a unique name.
2. An entry at the intersection of each row and column is
atomic (or single valued).

There can be only one value associated with each attribute on

a specific row of a table; no multivalued attributes are allowed
in a relation.

3. Each row is unique; no two rows in a relation can be

identical.
PROPERTIES OF RELATIONS cont.
4. Each attribute (or column) within a table has a unique name.
5. The sequence of columns (left to right) is insignificant.
The order of the columns in a relation can be changed
without changing the meaning or use of the relation.
6. The sequence of rows (top to bottom) is insignificant.
As with columns, the order of the rows of a relation
may be changed or stored in any sequence.
REMOVING MULTIVALUED ATTRIBUTES FROM TABLES
The second property of relations listed in the preceding section states that no
multivalued attributes are allowed in a relation. Thus, a table that contains one
or more multivalued attributes is not a relation.
SAMPLE DATABASE
A relational database may consist of any number of relations. The structure of
the database is described through the use of a schema,which is a
description of the overall logical structure of the database. There are two
Common methods for expressing a schema:

a. Short text statements, in which each relation is named and the names of
its attributes follow in parentheses.

b. A graphical representation, in which each relation is represented by a

rectangle containing the attributes for the relation.
A schema for four relations at Pine Valley Furniture Company is shown
in the figure below. The four relations shown in this figure are
CUSTOMER, ORDER, ORDER LINE, and PRODUCT. The key attributes
for these relations are underlined, and Other important attributes are
included in each relation. We show how to design these relations using
The techniques of normalization.
These is the text description of the relations:
It is a good idea to create an instance of your relational schema
with sample data for four reasons:

1. The sample data allow you to test your assumptions

regarding the design.
2. The sample data provide a convenient way to check the
accuracy of your design.
3. The sample data help improve communications with users
in discussing your design.
4. You can use the sample data to develop prototype
applications and to test queries.
INTEGRITY CONSTRAINTS
The relational data model includes several
types of constraints, or rules limiting acceptable
values and actions, whose purpose is to
facilitate maintaining the accuracy and integrity
of data in the database.

The major types of integrity constraints are

domain constraints, entity integrity, and
referential integrity.
Domain Constraints
All of the values that appear in a column of a relation must be
from the same domain. A domain is the set of values that may
be assigned to an attribute. A domain definition usually consists
of the following components: domain name, meaning, data type,
size (or length), and allowable values or allowable range
(if applicable).
Entity Integrity

The entity integrity rule is designed to ensure

that every relation has a primary key and
that the data values for that primary key are all
valid. In particular, it guarantees that every
primary key attribute is non-null.
The relational data model allows us to assign a null value to an
attribute in the just described situations. A null is a value that may
be assigned to an attribute when no other value applies or when
the applicable value is unknown. In reality, a null is not a value
but rather it indicates the absence of a value.

Everyone agrees that primary key values must not be allowed

to be null. Thus, the entity integrity rule states the following:

No primary key attribute (or component of a

primary key attribute) may be null.
Referential Integrity

In the relational data model, associations between tables

are defined through the use of foreign keys.

A referential integrity constraint is a rule that maintains

consistency among the rows of two relations. The rule
states that if there is a foreign key in one relation, either
each foreign key value must match a primary key value
in another relation or the foreign key value must be null.
Domain Definitions for INVOICE Attributes
A sample of referential integrity constraints
TRANSFORMING EER DIAGRAMS
INTO RELATIONS
During logical design, you transform the E-R (and EER)
diagrams that were developed during conceptual design
into relational database schemas.
Transforming (or mapping) EER diagrams into relations
is a relatively straightforward process with a well-defined
set of rules.

In fact, many CASE tools can automatically perform

many of the conversion steps.
However, it is important that you understand the steps in this process for four
reasons:

1. CASE tools often cannot model more complex data relationships such as
ternary relationships and supertype/subtype relationships. In these
situations, you may have to perform the steps manually.
2. There are sometimes legitimate alternatives where you will need to choose
a particular solution.
3. You must be prepared to perform a quality check on the results obtained
with a CASE tool.
4. Understanding the transformation process helps you understand why
conceptual data modeling (modeling the real-world domain) is
truly a different activity from representing the results of the
conceptual data modeling process in a form that can be
implemented using a DBMS.
1. Regular entities are entities that have an independent existence
and generally represent real-world objects, such as
persons and products. Regular entity types are represented
by rectangles with a single line.

2. Weak entities are entities that cannot exist except with an

identifying relationship with an owner (regular) entity type.
Weak entities are identified by a rectangle with a double
line.

3. Associative entities (also called gerunds) are formed from

many-to-many relationships between other entity types.
Associative entities are represented by a rectangle with
rounded corners.
Step 1. Map Regular Entities
Each regular entity type in an E-R diagram is
transformed into a relation. The name given
to the relation is generally the same as the
entity type. Each simple attribute of the
entity type becomes an attribute of the
relation. The identifier of the entity type
becomes the primary key of the
corresponding relation.
(a) CUSTOMER entity type

(b) CUSTOMER relation

Mapping the regular entity CUSTOMER

 COMPOSITE ATTRIBUTES
When a regular entity type has a composite attribute, only the simple
components of the composite attribute are included in the new
relation as its attributes.

(a) CUSTOMER entity type

with composite attribute

(b) CUSTOMER relation with

address detail

Mapping a composite attribute

MULTIVALUED ATTRIBUTES
When the regular entity type contains a multivalued attribute, two new
relations (rather than one) are created.
• The first relation contains all of the attributes of the entity type except
the multivalued attribute.
• The second relation contains two attributes that form the primary key
of the second relation.

The first of these attributes is the primary key from the first relation,
which becomes a foreign key in the second relation.

The second is the multivalued attribute. The name of the second

relation should capture the meaning of the multivalued attribute..
(a) EMPLOYEE entity type
with multivalued attribute

(b) Mapping a multivalued

attribute

Mapping an entity with a multivalued attribute

Step 2. Map Weak Entities
Recall that a weak entity type does not have an
independent existence but exists only
through an identifying relationship with
another entity type called the owner.
A weak entity type does not have a complete
identifier but must have an attribute called
a partial identifier that permits distinguishingthe
various occurrences of the weak entity
for each owner entity instance.
 (a) Weak entity DEPENDENT

(b) Relations resulting from

weak entity

Example of mapping a weak entity

Step 3. Map Binary Relationships
The procedure for representing relationships depends on both the
degree of the relationships (unary, binary, or ternary) and
the cardinalities of the relationships.

MAP BINARY ONE-TO-MANY RELATIONSHIPS

For each binary 1:M relationship, first create a relation for each of
the two entity types participating in the relationship, using the
procedure described in Step 1. Next, include the primary key
attribute (or attributes) of the entity on the one-side of the
relationship as a foreign key in the relation that is on the many-side
of the relationship. (A mnemonic you can use to remember this rule
is this: The primary key migrates to the many side.)
(a) Relationship between
customers and orders

(b) Mapping the

relationship

Example of mapping a 1:M relationship

MAP BINARY MANY-TO-MANY RELATIONSHIPS

Suppose that there is a binary many-to many (M:N)

relationship between two entity types, A and B.
For such a relationship, create a new relation, C.

Include as foreign key attributes in C the primary key for

each of the two participating entity types. These
attributes together become the primary key of C.
Any nonkey attributes that are associated with the
M:N relationship are included with the relation C.
(a) Completes
relationship (M:N)

(b) Three resulting

relations

Example of mapping a M:N relationship

MAP BINARY ONE-TO-ONE RELATIONSHIPS

Binary one-to-one relationships can be viewed as a special

case of one-to-many relationships. The process of mapping
such a relationship to relations requires two steps.

• First, two relations are created, one for each of the

participating entity types.

• Second, the primary key of one of the relations is

included as a foreign key in the other relation.
(a) In Charge
relationship (binary 1:1)

(b) Resulting relations

Example of mapping a binary 1:1 relationship

Step 4. Map Associative Entities
When a data modeler encounters a many-to-many relationship, he or
she may choose to model that relationship as an associative entity in
the E-R diagram. This approach is most appropriate when the end
user can best visualize the relationship as an entity type rather than
as an M:N relationship. Mapping the associative entity involves
essentially the same steps as mapping an M:N relationship, as
described in Step 3.
The first step is to create three relations: one for each of the two participating
entity types and a third for the associative entity. We refer to the relation form
ed from the associative entity as the associative relation.

The second step then depends on whether on the E-R diagram an identifier w
as assigned to the associative entity.
IDENTIFIER NOT ASSIGNED

If an identifier was not assigned, the default

primary key for the associative relation
consists of the two primary key attributes
from the other two relations. These
attributes are then foreign keys
that reference the other two relations.
Example of mapping an associative entity
IDENTIFIER ASSIGNED
Sometimes a data modeler will assign a single-attribute identifier
to the associative entity type on the E-R diagram.

There are two reasons that may have motivated the data
modeler to assign a single-attribute key during
conceptual data modeling:
1. The associative entity type has a natural single-attribute
identifier that is familiar to end users.
2. The default identifier (consisting of the identifiers for each of
the participating entity types) may not uniquely identify
instances of the associative entity.
(a) SHIPMENT
associative entity

(b) Three resulting

relations

Example of mapping an associative entity with an identifier

Step 5. Map Unary Relationships
We defined a unary relationship as a relationship
between the instances of a single entity type.
Unary relationships are also called
recursive relationships.
The two most important cases of unary relationships
are one-to-many and many-to-many relationships.
We discuss these two cases separately because the
approach to mapping is somewhat different for the
two types.
Step 6. Map Ternary (and n-arv)
Relationships
To map an associative entity type that links three regular entity types,
we create a new associative relation. The default primary key of this
relation consists of the three primary key attributes for the
participating entity types.

(In some cases, additional attributes are required to form a unique

primary key.) These attributes then act in the role of foreign keys
that reference the individual primary keys of the participating entity
types. Any attributes of the associative entity type become attributes
of the new relation.
Step 7. Map Supertype/Subtype
Relationships
The relational data model does not yet directly support supertype/subtype
relationships. For our purposes, we use the following strategy, which is the
one most commonly employed:\

1. Create a separate relation for the supertype and for each of its subtypes.
2. Assign to the relation created for the supertype the attributes that are
common to all members of the supertype, including the primary key.
3. Assign to the relation for each subtype the primary key of the supertype and
only those attributes that are unique to that subtype.
4. Assign one (or more) attributes of the supertype to function as the subtype
discriminator.
NORMALIZATION

It is a formal process for deciding which

attributes should be grouped together
in a relation so that all anomalies are
removed.
Steps in Normalization

Normalization can be accomplished and understood in stages, each of which

corresponds to a normal form . A normal form is a state of a
relation that requires that certain rules regarding relationships between
attributes (or functional dependencies) are satisfied. We describe these rules
briefly in this section and illustrate them in detail in the following sections:

1. First normal form Any multivalued attributes (also called repeating

groups) have been removed, so there is a single value (possibly null) at the
intersection of each row and column of the table.
2. Second normal form Any partial functional dependencies have
been removed (i.e., nonkey attributes are identified by the whole
primary key).
3. Third normal form Any transitive dependencies have been
removed (i.e., nonkey attributes are identified by only the primary
key).
4. Boyce-Codd normal form Any remaining anomalies that result
from functional dependencies have been removed (because there
was more than one possible primary key for the same nonkeys).
5. Fourth normal form Any multivalued dependencies have been
removed.
6. Fifth normal form Any remaining anomalies have been removed.
NORMALIZATION

It is a formal process for deciding which

attributes should be grouped together
in a relation so that all anomalies are
removed.