Chapter 4

Logical Database Design and the Relational Model

The Relational Data Model
• The relational data model represents data in the form of tables.
• Relational data model is the primary data model, which is used widely
around the world for data storage and processing. This model is
simple and it has all the properties and capabilities required to
process data with storage efficiency.
• A relation is nothing but a table of values. Every row in the table
represents a collection of related data value.
The Relational Data Model
Basic Definitions
The relational data model consists of the following three components:
• Data structure: Data are organized in the form of tables, with rows and
columns.
• Data manipulation: Powerful operations (typically implemented using the
SQL language) are used to manipulate data stored in the relations. For
example, in alphabetical order.
• Data integrity: The model includes mechanisms to specify business rules
that maintain the integrity of data when they are manipulated. For
example, Make sure that same Emp ID is not assigned to multiple
employees.
RELATIONAL DATA STRUCTURE
Relation
• 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.
RELATIONAL DATA STRUCTURE
Relation
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 must have a
primary key.
Primary key
• An attribute or a combination of attributes that uniquely identifies each row in
a relation.
Composite key
• A primary key that consists of more than one attribute.
Foreign key
• An attribute in a relation that serves as the primary key of another relation in
the same database.
PROPERTIES OF RELATIONS
• Each relation (or table) in a database has a unique name.
• 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.
• Each row is unique; no two rows in a relation can be identical.
• Each attribute (or column) within a table has a unique name.
• 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.
• 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
REMOVING MULTIVALUED
ATTRIBUTES FROM TABLES
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.
INTEGRITY CONSTRAINTS
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).
INTEGRITY CONSTRAINTS
Domain Constraints
INTEGRITY CONSTRAINTS
Domain Constraints
INTEGRITY CONSTRAINTS
Domain Constraints
INTEGRITY CONSTRAINTS
Domain Constraints
INTEGRITY CONSTRAINTS
ENTITY INTEGRITY
• A rule that states that no primary key attribute (or component of a
primary key attribute) may be null.
• 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
NULL
• A value that may be assigned to an attribute when no other value
applies or when the applicable value is unknown.
INTEGRITY CONSTRAINTS
REFERENTIAL INTEGRITY CONSTRAINT
• A rule that states that either each foreign key value must match a
primary key value in another relation or the foreign key value must be
null.
INTEGRITY CONSTRAINTS
REFERENTIAL INTEGRITY CONSTRAINT
TRANSFORMING EER DIAGRAMSINTO
RELATIONS
• 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 for which 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.
TRANSFORMING EER DIAGRAMSINTO
RELATIONS
• 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.
TRANSFORMING EER DIAGRAMSINTO
RELATIONS
• 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.
• Figure 4-8a shows a representation of the CUSTOMER entity type for
Pine Valley Furniture Company. The corresponding CUSTOMER
relation is shown in graphical form in Figure 4-8b.
TRANSFORMING EER DIAGRAMSINTO
RELATIONS
• Step 1: Map Regular Entities
TRANSFORMING EER DIAGRAMSINTO
RELATIONS
• Step 1: Map Regular Entities
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.
• Figure 4-9 shows a variant of the example in Figure 4-8, where
Customer Address is represented as a composite attribute with
components Street, City, and State (see Figure 4-9a). This entity is
mapped to the CUSTOMER relation, which contains the simple
address attributes, as shown in Figure 4-9b.
TRANSFORMING EER DIAGRAMSINTO
RELATIONS
• Step 1: Map Regular Entities
COMPOSITE ATTRIBUTES
TRANSFORMING EER DIAGRAMSINTO
RELATIONS
• Step 1: Map Regular Entities
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.
• An example of this procedure is shown in Figure 4-10. This is the EMPLOYEE entity type for Pine
Valley Furniture Company. As shown in Figure 4-10a, EMPLOYEE has Skill as a multivalued
attribute. Figure 4-10b shows the two relations that are created. The first (called EMPLOYEE)
has the primary key EmployeeID. The second relation (called EMPLOYEE SKILL) has the two
attributes, EmployeeID and Skill, which form the primary key.
TRANSFORMING EER DIAGRAMSINTO
RELATIONS
• Step 1: Map Regular Entities
MULTIVALUED ATTRIBUTES
TRANSFORMING EER DIAGRAMSINTO
RELATIONS
• 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 partial identifier that permits distinguishing the various
occurrences of the weak entity for each owner entity instance.
• For each weak entity type, create a new relation and include all of the simple
attributes (or simple components of composite attributes) as attributes of this
relation. Then include the primary key of the identifying relation as a foreign
key attribute in this new relation.
TRANSFORMING EER DIAGRAMSINTO
RELATIONS
• Step 2: Map Weak Entities
• An example of this process is shown in Figure 4-11. Figure 4-11a shows the
weak entity type DEPENDENT and its identifying entity type EMPLOYEE, linked
by the identifying relationship Claims.
• Figure 4-11b shows the two relations that result from mapping this E-R
segment.
• An alternative approach is often used to simplify the primary key of the
DEPENDENT relation: Create a new attribute (called DependentID), which will
be used as a surrogate primary key in Figure 4-11b.
SURROGATE PRIMARY KEY
• A serial number or other system assigned primary key for a relation.
TRANSFORMING EER DIAGRAMSINTO
RELATIONS
• Step 2: Map Weak Entities