Chapter Three: Relational Database Model

CHAPTER THREE
RELATIONAL DATABASE MODEL
3. Relational Database Model
This model is the most widely used. It was
 Developed by Dr. Edgar Frank Codd in 1970 (famous paper, 'A Relational Model for
Large Shared Data Banks')
 Originated from the branch of mathematics called set theory and relation
 Intended for more flexible and complex relationship
 Viewed as a collection of tables called “Relations” equivalent to collection of record
types having the following properties.
 Relation: Two dimensional table
 Stores information or data in the form of tables rows and columns
 A row of the table is called tuple equivalent to record
 A column of a table is called attribute equivalent to fields
 Data value is the value of the Attribute
 Records are related by the data stored jointly in the fields of records in two tables
or files. The related tables contain information that creates the relation
 The tables seem to be independent but are related.
 No physical consideration of the storage is required by the user
 Many tables are merged together to come up with a new virtual view of the
relationship
Alternative terminologies
Relation Table File
Tuple RowRecord
AttributeColumnField
 The rows represent records (collections of information about separate items)
 The columns represent fields (particular attributes of a record)
 Conducts searches by using data in specified columns of one table to find additional data
in another table
 In conducting searches, a relational database matches information from a field in one
table with information in a corresponding field of another table to produce a third table
that combines requested data from both tables
Building Blocks of the Relational Data Model
The building blocks of the relational data model are:
1. Entities: real world physical or logical object
2. Attributes: properties used to describe each Entity or real world object.
3. Relationship: the association between Entities
4. Constraints: rules that should be obeyed while manipulating the data.
1. The ENTITIES (persons, places, things etc.) which the organization has to deal with.
Relations can also describe relationships.
Entity sets - An entity is a thing or an object in the real world that is distinguishable from
all other objects - An entity may be concrete (a person or a book, for example) or abstract
(like or a concept like Account in a bank) - An entity set is a set of entities of the same
type (share the same properties/attributes)
Example of entity:
 Person – employee, student, patient
1|Page
 Chapter Three: Relational Database Model

 Place – store, workhouse, state

 Object – machine, car, building
 Event – registration, renewal
 Concept – account, course, job, project
The name given to an entity should always be a singular noun descriptive of each item
to be stored in it.
Example: student NOT students.
Every relation has a schema, which describes the columns, or fields the relation itself
corresponds to our familiar concept of a table:
A relation is a collection of tuples, each of which contains values for a fixed number of
attributes. „
Existence Dependency: the dependence of an entity on the existence of one or more
entities. „
Weak entity: an entity that cannot exist without the entity with which it has a relationship
– it is indicated by a double rectangle

2. The ATTRIBUTE the items of information which characterize and describe these
entities. Attributes are pieces of information ABOUT entities. The analysis must of
course identify those which are actually relevant to the proposed application. Attributes
will give rise to recorded items of data in the database At this level we need to know such
things as:
 Attribute name (be explanatory words or phrases)
 The domain from which attribute values are taken (A DOMAIN is a set of values
from which attribute values may be taken.) Each attribute has values taken from a
domain.
o For example, the domain of Name is string and that for salary is real
 Whether the attribute is part of the entity identifier (attributes which just describe
an entity and those which help to identify it uniquely)
 Whether it is permanent or time-varying (which attributes may change their
values over time)
 Whether it is required or optional for the entity (whose values will sometimes
be unknown or irrelevant)
Types of Attributes
(1) Simple (atomic) Versus Composite attributes
 Simple : contains a single value (not divided into sub parts) E.g. Age, gender
 Composite: Divided into sub parts (composed of other attributes)
E.g. Name, address
(2) Single-valued versus multi-valued attributes
 Single-valued : have only single value(the value may change but has only
one value at one time)
E.g. Name, Sex, Id. No. color_of_eyes
 Multi-Valued: have more than one value
E.g. Address, dependent-name Person may have several college degrees
(3) Stored vs. Derived Attribute
 Stored : not possible to derive or compute
E.g. Name, Address

2|Page
 Chapter Three: Relational Database Model

 Derived: The value may be derived (computed) from the values of other
attributes.
E.g. Age (current year – year of birth)
Length of employment (current date- start date)
Profit (earning-cost)
G.P.A (grade point/credit hours)
(4) Null Values
 NULL applies to attributes which are not applicable or which do not have
values.
 You may enter the value NA (meaning not applicable)
 Value of a key attribute cannot be null.
Default value - assumed value if no explicit value
Entity versus Attributes
When designing the conceptual specification of the database, one should pay attention to the
distinction between an Entity and an Attribute.
Consider designing a database of employees for an organization:
 Should address be an attribute of Employees or an entity (connected to Employees by a
relationship)?
If we have several addresses per employee, address must be an entity (attributes cannot be set-
valued/multi valued)
If the structure (city, Woreda, Kebele, etc) is important, e.g. want to retrieve employees in a
given city, address must be modeled as an entity (attribute values are atomic)
3. Relationship
The RELATIONSHIPS between entities which exist and must be taken into account when
processing information. In any business processing one object may be associated with
another object due to some event. Such kind of association is what we call a
RELATIONSHIP between entity objects.
 One external event or process may affect several related entities.
 Related entities require setting of LINKS from one part of the database to another.
 A relationship should be named by a word or phrase/Roles which explains its
function
 Role names are different from the names of entities forming the relationship: one
entity may take on many roles, the same role may be played by different entities
 For each RELATIONSHIP, one can talk about the Number of Entities and the
Number of Tuples/rows participating in the association. These two concepts are
called DEGREE and CARDINALITY of a relationship respectively.
Degree of a Relationship
 An important point about a relationship is how many entities participate in it. The
number of entities participating in a relationship is called the DEGREE of the
relationship.

Among the Degrees of relationship, the following are the basic:

 UNARY/RECURSIVE RELATIONSHIP: Tuples/records of a Single entity are
related with each other.

3|Page
 Chapter Three: Relational Database Model

 BINARY RELATIONSHIPS: Tuples/records of two entities are associated in a

relationship
 TERNARY RELATIONSHIP: Tuples/records of three different entities are
associated
 And a generalized one:
o N-NARY RELATIONSHIP: Tuples from arbitrary number of entity sets are
participating in a relationship.
Cardinality of a Relationship
Another important concept about relationship is the number of instances/tuples that can be
associated with a single instance from one entity in a single relationship. The number of
instances participating or associated with a single instance from an entity in a relationship is
called the CARDINALITY of the relationship. The major cardinalities of a relationship are:
 ONE-TO-ONE: one tuple is associated with only one other tuple.
 E.g. Building – Location
o As a single building will be located in a single location and as a single location
will only accommodate a single Building.

 ONE-TO-MANY, one tuple can be associated with many other tuples, but not the
reverse.
o E.g. Department-Student as one department can have multiple students.

 MANY-TO-ONE, many tuples are associated with one tuple but not the reverse.
o E.g. Employee – Department: as many employees belong to a single department.
 MANY-TO-MANY: one tuple is associated with many other tuples and from the other
side, with a different role name one tuple will be associated with many tuples
 E.g. Student – Course

4|Page
 Chapter Three: Relational Database Model

o As a student can take many courses and a single course can be attended by many
students.

Relational Constraints/Integrity Rules

Relational Integrity
 Domain Integrity: No value of the attribute should be beyond the allowable limits
 Entity Integrity: In a base relation, no attribute of a Primary Key can assume a value
of NULL
 Referential Integrity: If a Foreign Key exists in a relation, either the Foreign Key
value must match a Candidate Key value in its home relation or the Foreign Key
value must be NULL
Enterprise Integrity: Additional rules specified by the users or database administrators of a
database are incorporated
Key constraints
If tuples are need to be unique in the database, and then we need to make each tuple distinct. To
do this we need to have relational keys that uniquely identify each relation.
 Super Key: an attribute or set of attributes that uniquely identifies a tuple within a
relation.
 Candidate Key: a super key such that no proper subset of that collection is a Super Key
within the relation.
A candidate key has two properties:
1. Uniqueness
2. Irreducibility
If a super key is having only one attribute, it is automatically a Candidate key.
If a candidate key consists of more than one attribute it is called Composite Key.
Primary Key: the candidate key that is selected to identify tuples uniquely within the relation.
The entire set of attributes in a relation can be considered as a primary case in a
worst case.
Foreign Key: an attribute, or set of attributes, within one relation that matches the candidate key
of some relation. A foreign key is a link between different relations to create the
view or the unnamed relation
ER Diagram
The overall logical structure of a database can be expressed graphically by E-R diagram. There
are several standard symbols used in ER diagram. The symbols are as below.

5|Page
 Chapter Three: Relational Database Model

Example:

6|Page
 Chapter Three: Relational Database Model

7|Page
 Chapter Three: Relational Database Model

Reducing/ Mapping ER Diagram to Tables

Basically, the ER diagram is used to represent the relational data model concepts ENTITY,
ATTRIBUTES, RELATIONSHIP in symbols. Through ER diagram, it is possible to capture the
formal business logic of organizations/clients for which a database is supposed. A database
compatible to an ER diagram can be translated or mapped to a collection of tables. For each
entity set and relationship set, there is a unique table which is assigned the name of the
corresponding set
 Each table has a number of columns with unique names
 Converting a database representation from an ER diagram to a table format is the way we
arrive at a relational database design from an ER diagram
 To implement the database, it is necessary to use the relational model.
 There is a simple way of mapping from ER model to the relational model.
 There is almost one-to-one correspondence between ER constructs and the relational
ones.
Mapping Algorithm
The mapping algorithm gives the procedure to map ER diagram to tables. The rules in mapping
algorithm are given as:
Mapping Strong Entity
- For each strong entity type say E, create a new table/conceptual schema. The columns of the
table are the attribute of the entity type E.
Eg. Mapping regular entity type tennis player

8|Page
 Chapter Three: Relational Database Model

Mapping Weak Entity

Weak entity type does not have an independent existence and it exist only through an identifying
relationship with another entity type called the owner
 For each weak entity type create a new relation and include all of the simple attributes as
attributes of the relation.
 For each weak entity W that is associated with a 1-N or M-N identifying relationship, or
participates in more than one relationship, create a new table T and include as its
columns, all the simple attributes and simple components of the composite attributes of
W. also form its primary key by including as a foreign key in R, the primary key of its
owner entity.
Eg. Mapping weak entity type dependents

Mapping Composite Attribute

When a regular entity type has a composite attribute, only the simple components attributes of
the composite attribute are included in the relation
Eg. Under the CUSTOMER entity customer address consists of four simple attribute

9|Page
 Chapter Three: Relational Database Model

Mapping Multi-valued Attribute

One way to map a multivalued attribute is to create two tables
Eg.
Under Employee entity- employee can have more than one skill for each multivalued attribute,
create a new table and include as columns of T, the simple attribute or simple components of the
attribute A. Include as foreign key, the primary key of the entity or relationship type that has A.
Specify as the primary key of T, the foreign key and the columns corresponding to A.

10 | P a g e
 Chapter Three: Relational Database Model

Mapping Associate Entity to tables

Many-To-Many relationship can be modeled as an associative entity in the ER diagram
Without identifier
 the associative entity which is without any key attribute
 The first step is to create three relations.

11 | P a g e
 Chapter Three: Relational Database Model

That is one for each of the two participating entities and the third for the associative entity. The
relation formed from the associative entity is associative relation.

With identifier
Sometimes data model assigns an identifier to the associative entity on the ER diagram. There
are two reasons to motivate this approach
 the associative entity type has a natural identifier that is familiar to end user
 the default identifier may not uniquely identify instance of the associative entity
Eg. Shipment number is a natural identifier to end user rather than having the default identifier
customer id and vendor id as an identifier for the associative entity called shipment

12 | P a g e
 Chapter Three: Relational Database Model

Enhanced E-R (EER) Models

 Object-oriented extensions to E-R model
 EER is important when we have a relationship between two entities and the participation
is partial between entity occurrences. In such cases EER is used to reduce the complexity
in participation and relationship complexity.
 ER diagrams consider entity types to be primitive objects
 EER diagrams allow refinements within the structures of entity types
EER Concepts
 Generalization
 Specialization
 Sub classes
 Super classes
 Attribute Inheritance
 Constraints on specialization and generalization
Generalization
 Generalization occurs when two or more entities represent categories of the same real-
world object.

13 | P a g e
 Chapter Three: Relational Database Model

 Generalization is the process of defining a more general entity type from a set of more
specialized entity types.
 A generalization hierarchy is a form of abstraction that specifies that two or more entities
that share common attributes can be generalized into a higher level entity type.
 Is considered as bottom-up definition of entities.
 Generalization hierarchy depicts relationship between higher level superclass and lower
level subclass.
 Generalization hierarchies can be nested. That is, a subtype of one hierarchy can be a
super type of another. The level of nesting is limited only by the constraint of simplicity.
Example: Account is a generalized form for Savings and Current Accounts
Example: the figure below shows the concept of generalization and specification.

Specialization
 Is the result of subset of a higher level entity set to form a lower level entity set.
 The specialized entities will have additional set of attributes (distinguishing
characteristics) that distinguish them from the generalized entity.
 Is considered as Top-Down definition of entities.
 Specialization process is the inverse of the Generalization process.
 Identify the distinguishing features of some entity occurrences, and specialize them into
different subclasses.
 Reasons for Specialization
o Attributes only partially applying to super classes
o Relationship types only partially applicable to the superclass
 In many cases, an entity type has numerous sub-groupings of its entities that are
meaningful and need to be represented explicitly. This need requires the representation of
each subgroup in the ER model. The generalized entity is a superclass and the set of
specialized entities will be subclasses for that specific Superclass.
Example: Saving Accounts and Current Accounts are Specialized entities for the
generalized entity Accounts. Manager, Sales, Secretary: are specialized
employees.

14 | P a g e