Chapter 2: Data model

Introduction
The data model is a collection of conceptual tools for describing data, data relationships, data
semantics, and consistency constraints. To illustrate the concept of a data model, we outline two data
models in this chapter: the entity-relationship model and the relational model. Both provide a way to
describe the design of a database at the logical level.

I- The Entity-Relationship Model

The entity-relationship (E-R) data model is based on a perception of a real world that consists of a
collection of basic objects, called entities, and of relationships among these objects.

An entity is a “thing” or “object” in the real world that is distinguishable from other objects.

For example, each person is an entity, and bank accounts can be considered as entities.

Entities are described in a database by a set of attributes.

For example, the attributes

account-number and balance may describe one particular account in a bank, and they form attributes
of the account entity set. Similarly, attributes customer-name, customer street address and customer-
city may describe a customer entity.

An extra attribute customer-id is used to uniquely identify customers (since it may be possible to have
two customers with the same name, street address, and city).

A unique customer identifier must be assigned to each customer. In the United States, many
enterprises use the social-security number of a person (a unique number the U.S. government assigns
to every person in the United States) as a customer identifier.

A relationship is an association among several entities. For example, a depositor relationship

associates a customer with each account that she has. The set of all entities of the same type and the
set of all relationships of the same type are termed an entity set and relationship set, respectively. The
overall logical structure (schema) of a database can be expressed graphically by an E-R diagram.

ER model describes data in terms of:

• Entities and entity sets : Objects

• Relationships and relationship sets: Connections between objects

• Attributes : Properties that characterize or describe entities or relationships

1
Fig : Two entities, EMPLOYEE e1, and COMPANYc1, and their attributes

Example of The Entity-Relationship Model or Diagram

I-1 Entity type or set

• Collection (or set) of similar entities that have the same attributes

•ER model defines entity sets, not individual entities

•But entity sets described in terms of their attributes

2
I-2 Key or unique attributes
• Attribute values constrained to be distinct for individual entities in entity set

Fig : Two entity types, EMPLOYEE and COMPANY, and some entities of each

I-3 CATEGORIES OF ATTRIBUTES

-Simple (atomic) vs. composite attributes (address)

-Single-valued vs. multivalued attributes

-Stored vs. derived attributes

–Derived attributes

• Can be computed from other attributes

• E.g. age, given date of birth

-Key or unique attributes :Attribute values constrained to be distinct for individual entities in

entity set

The domain of an attribute of an entity type is the set of constant values associated with that
attribute.

Example of ER diagram of a company

Four entity types

-Most attributes are simple, single-valued, and stored

3
• Works_on and Locations are multivalued

• Employee’s Name is composite

- Employee has one key, department and project have two keys,

dependent has none

I-4 WEAK ENTITY

The entity set which does not have sufficient attributes to form a primary key is called as weak
entity set .
Weak entity is an entity that cannot be uniquely identified by its attributes alone, therefore,
it must use a foreign key in conjunction with its attributes to create a primary key.
Weak entity depends on the parent entity, it mainly depends on other entities ,The entity set
has a primary key is called as strong entity set

Example of Strong and Weak Entity

The example of strong and weak entity can be understood by the below figure

4
The strong entity is professor, whereas Dependent is a Weak Entity.
ID is the primary key (represented with a line ) and Name in Dependent entity is called partial
key (represented with a dotted line).

Examples
-Entity set Beers has two attributes, name and manf (manufacturer).
-Each Beers entity has values for these two attributes, e.g. (Bud, Anheuser-Busch)

I-5 Summary of ER diagram symbols

5
CHEN E-R Symbols

6
I-6 Relationship
A relationship connects two or more entity sets.

It is represented by a diamond, with lines to each of the entity sets involved.

A relation between pairs of entities (a binary relationship).

Example: Grust (an entity) teaches (a relationship) the course “Foundations of Databases” (an entity).

Example of relationship

A relationship type Teaches between entity type Lecturer and entity type Student:

7
Bars sell some beers, Drinkers like some beers, Drinkers frequent some bars .

I-7 Relationship set

-The current “value” of an entity set is the set of entities that belong to it.

Example: the set of all bars in our database.

-The “value” of a relationship is a relationship set, a set of tuples with one component for each related
entity set.

Example of Relationship set

For the relationship Sells, we might have a relationship set like:

8
Multiway Relationships
Sometimes, we need a relationship that connects more than two entity sets.

Suppose that drinkers will only drink certain beers at certain bars.

Our three binary relationships Likes, Sells, and Frequents do not allow us to make this distinction.

But a 3-way relationship would.

Example: 3-Way Relationship

9
A Typical Relationship Set

I-8 Cardinalities

Connecting lines, solid lines that connect attributes to show the relationships of
entity in the diagram. Cardinality specifies how many instances of an entity
related to one instance of another entity.
The ER model introduces the (min, max) notation to specify an interval of
possible participations in an relationship:

. An entity of type E1 may be related to at least m1 and at most n1

entities of type E2.
. Likewise, m2 is the minimum number and n2 is the maximum number of E1
entities to which an E2 entity is related

10
• Normally, the minimum cardinality will be 0 or 1, and the
maximum cardinality will be 1 or ∗.
. Thus, only the (0, 1), (1, 1), (0, ∗), (1, ∗) cardinalities are common in practice.
Alternative notations of Cardinalities many-to-many (N:M),
one-to-many (1:N), or one-to-one (1:1).

• To understand a relationship, one must know the cardinality specifications on

both sides.
• The maximum cardinalities on each side are used to distinguish between many-
to-many, one-to-many /

11
many-to-one, and one-to-one relationships.

Multiplicity Constraints in Relationship Types

-many-to-one (or one-to-many)

An Employee Works in one Department or a Department has many Employees.

-one-to-one

A Manager Heads one Department and vice versa.

-many-to-many

A Lecturer Teaches many Students and a Student is Taught by many Lecturers.

Example of many-to-one relationship type

The arrowhead is drawn at the “one” end of the relationship type

-Each Employee Works-in one Department

-Each Department has many Employees working in it

. Maximum cardinality 1 on the “many” side and ∗ on the “one” side:

12
Example of one-to-one relationship type

The arrowhead is drawn at both ends of the relationship type

-Each Manager Occupies one Office

-Each Office has one Manager occupying it

. Maximum cardinality 1 on both sides:

13
Example of many-to-many relationship type

No arrowheads are drawn

-Each Lecturer Teaches many Students

-Each Student is taught by many Lecturers

. Both maximum cardinalities are ∗ (the minimum cardinalities are 0 or 1):

14
Cyclic Relationship Types
Definition. A cyclic relationship type (also called recursive) is a relationship type between two
occurrences of the same entity type.
Examples:
-Marriage between Person and itself.
-Parent-Child between Person and itself.
-Part-Sub-Part between Part and itself.
With each entity type in a cyclic relationship type we associate a role, represented by labels
on lines in an ERD

Example of a Cyclic Relationship Type with Roles

15
Roles are specified by “parent” and “child” labels.

Relationship Types with Attributes

Examples:
-attribute Date associated with the relationship type
Married
-attribute Price associated with the relationship type
Supplies

16
I-9 Enhanced ER Modeling Concepts
In some cases, an entity type has numerous Although most properties of entities and
relationships can be expressed using the basic modeling constructs, some of them are costly
and difficult to express (and to understand). That’s why there are some extensions to the ER
model.
Subclasses, Superclasses, and Inheritance subgroupings ofits entities that are meaningful and
need to be represented explicitly because of their significance to the DB application.

• Relationships and attributes of superclass are inherited to subclass (in particular primary key
attribute(s)); subclass can have additional attributes and relationships
• An entity cannot exist merely by being a member of only a subclass.
Specialization
• Process of defining a set of subclasses of an entity type (top-down)

17
Generalization:
• Reverse process of specialization (bottom-up); identify common features of entity types and
generalize them into single superclass (including primary key!)

ISA Relationship Types

-When an entity type contains certain entities that have special properties not shared by all
entities, this suggests two entity types should be created with an ISA relationship type
between them.
- Also known as generalisation/specialisation.
- E.g. An Employee ISA Person and a Student ISA Person (see next slide)
-If Employee ISA Person then Employee inherits all the attributes of Person.

-Attributes of Employee: Name, Number and Salary.

-Attributes of Student: Name, Number and Degree

18
I-10 Crow’s Foot E-R Symbols
The following symbols are important in drawing E-R diagrams when using the crow’s foot notation.
You must carefully study and understand the meaning of each symbol; and you must understand how
to use them correctly when drawing E-R diagrams:

- A single bar indicates one, a double bar indicates one and only one, a circle indicates zero, and a
crow’s foot indicates many.

- Modality can be 1 or 0 and the symbol is placed on the inside, next to the cardinality symbol. For a
modality of 1 a straight line is drawn. For a modality of 0 a circle is drawn.

- For a cardinality of 1 a straight line is drawn. For a cardinality of many a foot with three toes is drawn.

19
CASE STUDY: SKY-POWER AEROCORP
SKY-POWER AEROCORP is a global air travel and cargo handling business enterprise. The company has
many different types of aircrafts, crews and managers at various cities around the world.

The company desires to build a central database system to manage information about their various
activities around the world; and part of the database development effort involves requirements
gathering and analyses. Some few parts of the requirements have already been gathered and
summarized as business rules, which are given in this manual. As a database engineer, you are now
called upon to draw a preliminary data model diagram, using crow’s foot notation, which would
represent the few business rules given in this manual.

3.1 The business rules of SKY-POWER AEROCORP

i. A flight may take off from one and only one airport at a time; but an airport may have more
than one flight taking off simultaneously.
ii. A flight is managed by one and only one cabin crew.
iii. On any given flight, a passenger boarding a plane may belong to one and only one flight
class (business, economy or first class); while any flight class may have no passenger at all, or
more than one passenger.
iv. Any flight ticket may be reserved by one and only one passenger; but a passenger may
reserve one or more flight tickets.
v. A cargo package may pass through more than one transit point before reaching its final
destination; and a transit point may handle zero or many cargo packages.
vi. A flight crew is headed by a captain at a time, and a captain may head only one flight crew
at a time.
vii. A passenger on board a flight may eat more than one plate of food, but any plate of food
may be eaten by zero or one and only one passenger on board.

20
viii. After meals on board, every passenger must wash at least one plate; and every plate may
be washed by more than one passenger.
ix. Each plane that is airborne must have two flight engineers on board; and any flight engineer
may service one and only airborne plane a time.
x. At approximately every 4–6 months, each plane is parked in one and only one hangar for a
routine B-Check maintenance; and any hangar may have zero or many aircrafts parked in it.

3.2 Identifying the major entities and relationships for SKY-POWER

AEROCORP
We can easily identify the major entities by going through the given business rules one after the other:

Rule (i) suggests that there are two important entities called FLIGHT and AIRPORT; and the relationship
is take off.

Rule (ii) suggests FLIGHT and CABIN CREW as the main entities; while the relationship is manage.

Rule (iii) suggests FLIGHT, PASSENGER and FLIGHT CLASS as possible entities; but we can drop FLIGHT
and just take PASSENGER and FLIGHT CLASS as possible entities needed to model the business rule.
The relationship here is belongs to.

Rule (iv) suggests FLIGHT TICKET and PASSENGER as the major business entities. Notice that a
RESERVATION will also be an entity, but we can leave that out for now. The relationship is reserves.

Rule (v) suggests CARGO PACKAGE and TRANSIT POINT as the key entities of interest; and the
relationship here is passing through.

Rule (vi) provides FLIGHT CREW and CAPTAIN as major entities involved in this business requirement;
and the relationship is heading (of the crew by the captain).

Rule (vii) gives PASSENGER, FLIGHT and PLATE OF FOOD as the three possible entities. We take
PASSENGER and PLATE OF FOOD as the important ones here, though; and the relationship is eating (of
the plate of food by the passenger).

Rule (viii) focuses mainly on PASSENGER and PLATE as the important entities; and the relationship is
washing (of the plates by the passenger).

Rule (ix) presents PLANE and FLIGHT ENGINEER as the important entities; and the relationship is
servicing (of the plane, by the engineer).

Rule (x) gives PLANE and HANGAR as main entities; and the relationship is park.

3.3 Drawing the E-R diagram for SKY-POWER AEROCORP

Now we draw the E-R diagrams for each of the business rules one after the other. Be sure to be in class
when these diagrams are explained; as there are many things not mentioned in this manual about the
diagrams, but they shall be carefully explained in class!

21
22
23
I-11 Steps in Designing an Entity-Relationship Schema
1. Identify the entity types (including weak entity types) of the application.

2. Identify the relationship (including ISA and ID) types.

3. Classify each relationship type identified in step 2 according to its multiplicity, i.e. if it is a one-to-
one, many-to-one or many-to-many.

4. Determine the participation constraints for each entity type in each relationship type.

5. Draw an ERD with the entity types and the relationship types between them.

6. Identify the attributes of entity and relationship types and their underlying domains

7. Identify a primary key for each entity type.

8. Add the attributes and primary keys to the ERD drawn in step 5.

II- Relational Model

The relational model uses a collection of tables to represent both data and the relationships among
those data. Each table has multiple columns, and each column has a unique name.

Relational model basics

• Introduced by Edgar F. Codd in 1970 (Turing award)

• At the heart of relational database systems

• the basic abstraction is a relation (a table)

• tuples are stored in rows

• attributes of tuples are stored in columns

• conceptually, a relation is a set of tuples

• Why this model?

• Simple yet powerful

• Great for processing very large data sets in bulk

Episodes (season: int, num: int, title: string, viewers: long)

24
• Relation: a set or tuples - order doesn’t matter, all tuples are distinct

• Attribute: a column in a relation (e.g., season)

• Domain: data type of an attribute (e.g., season: int)

• Tuple: a row in a relation, e.g., <1, 2, The Kingsroad, 2.2 M>

Schema vs. instances

• Relation schema is a description of a relation in terms of relation name, attribute names,
attribute datatypes, constraints (e.g., keys)
A schema describes all valid instances of a relation
Schema Episodes (season: integer, num: integer, title: string, viewers: integer

Quick reference: converting ER to relational

25
Rule-01: For Strong Entity Set With Only Simple Attributes
A strong entity set with only simple attributes will require only one table in relational model.

….Attributes of the table will be the attributes of the entity set.

…..The primary key of the table will be the key attribute of the entity set.

Example-

Rule-02: For Strong Entity Set With Composite Attributes-

A strong entity set with any number of composite attributes will require only one table in
relational model.
While conversion, simple attributes of the composite attributes are taken into account and not
the composite attribute itself.
Example-

26
Rule-03: For Strong Entity Set With Multi Valued Attributes

27
A strong entity set with any number of multi valued attributes will require two tables in relational
model.

One table will contain all the simple attributes with the primary key.
Other table will contain the primary key and all the multi valued attributes.

Example-

Rule-04: Translating Relationship Set into a Table-

A relationship set will require one table in the relational model.

Attributes of the table are-

Primary key attributes of the participating entity sets
Its own descriptive attributes if any.
Set of non-descriptive attributes will be the primary key.

28
Example-

NOTE

If we consider the overall ER diagram, three tables will be required in relational model-

One table for the entity set “Employee”

One table for the entity set “Department”
One table for the relationship set “Works in”

Rule-05: For Binary Relationships With Cardinality Ratios-

The following four cases are possible-

Case-01: Binary relationship with cardinality ratio m:n

Case-02: Binary relationship with cardinality ratio 1:n

Case-03: Binary relationship with cardinality ratio m:1

Case-04: Binary relationship with cardinality ratio 1:1

29
Also read- Cardinality Ratios in DBMS

Case-01: For Binary Relationship With Cardinality Ratio m:n

Here, three tables will be required-

1.A ( a1 , a2 )
2.R ( a1 , b1 )
3.B ( b1 , b2 )

Case-02: For Binary Relationship With Cardinality Ratio 1:n

Here, two tables will be required-

1.A ( a1 , a2 )
2.BR ( a1 , b1 , b2 )

NOTE- Here, combined table will be drawn for the entity set B and relationship set R.

Case-03: For Binary Relationship With Cardinality Ratio m:1

30
Here, two tables will be required-
1.AR ( a1 , a2 , b1 )
2.B ( b1 , b2 )

NOTE- Here, combined table will be drawn for the entity set A and relationship set R.

Case-04: For Binary Relationship With Cardinality Ratio 1:1

Here, two tables will be required. Either combine ‘R’ with ‘A’ or ‘B’

Way-01:

1.AR ( a1 , a2 , b1 )
2.B ( b1 , b2 )

Way-02:

1.A ( a1 , a2 )
2.BR ( a1 , b1 , b2 )

31
Thumb Rules to Remember

While determining the minimum number of tables required for binary relationships with given cardinality
ratios, following thumb rules must be kept in mind-

For binary relationship with cardinality ration m : n , separate and individual tables will be drawn for
each entity set and relationship.
For binary relationship with cardinality ratio either m : 1 or 1 : n , always remember “many side will
consume the relationship” i.e. a combined table will be drawn for many side entity set and relationship
set.
For binary relationship with cardinality ratio 1 : 1 , two tables will be required. You can combine the
relationship set with any one of the entity sets.

Rule-06: For Binary Relationship With Both Cardinality Constraints and Participation
Constraints

Cardinality constraints will be implemented as discussed in Rule-05.

Because of the total participation constraint, foreign key acquires NOT NULL constraint i.e.
now foreign key can not be null.

Case-01: For Binary Relationship With Cardinality Constraint and Total Participation
Constraint From One Side-

Because cardinality ratio = 1 : n , so we will combine the entity set B and relationship set R.

32
Then, two tables will be required-

1.A ( a1 , a2 )
2.BR ( a1 , b1 , b2 )
Because of total participation, foreign key a1 has acquired NOT NULL constraint, so it can’t be
null now.

Case-02: For Binary Relationship With Cardinality Constraint and Total Participation
Constraint From Both Sides-

If there is a key constraint from both the sides of an entity set with total participation, then that
binary relationship is represented using only single table.

Here, Only one table is required.

ARB ( a1 , a2 , b1 , b2 )

Rule-07: For Binary Relationship With Weak Entity Set

Weak entity set always appears in association with identifying relationship with total participation
constraint.

33
Here, two tables will be required-

1.A ( a1 , a2 )
2.BR ( a1 , b1 , b2 )

Representing Specialization

Create table for higher-level entity set, and treat specialized entity subsets like weak entity
sets (without discriminators)

34
Example:

Representing Generalization (Approach #1)

Create a table for each lower-level entity set only
Columns of new tables should include
• Attributes of lower level entity set
• Attributes of the superset
The higher-level entity set can be defined as a view on the tables for the lower-level entity
sets

Example:

35
Representing Generalization (Approach #2)

Treat generalization the same as specialization.

Example:

36
Example Translation: ER Diagram

Example Translation: Relational Diagram

37
38
39
40
OTHER MODELS

1.Flat data model

2.Entity relationship model
3.Relation model
4.Record base model
5.Network model
6.Hierarchical model
7.Object oriented data model
8.Object relation model
9.Semi structured model
10.Associative model
11.Contex data model
Let us explain all these types of data models in DBMS with diagram

41
Flat Data Model
Flat data model is the first and foremost introduced model and in this all the data
used is kept in the same plane. Since it was used earlier this model was not so
scientific.

Entity Relationship Data Model

Entity relationship model is based on the notion of the real world entities and their
relationships. While formulating the real world scenario in to the database model an
entity set is created and this model is dependent on two vital things and they are :

Entity and their attributes

Relationships among entities

An entity has a real world property called attribute and attribute define by a set of
values called domain. For example, in a university a student is an entity, university is

42
the database, name and age and sex are the attributes. The relationships among
entities define the logical association between entities.

Relational Data Model

Relational model is the most popular model and the most extensively used model. In
this model the data can be stored in the tables and this storing is called as relation,
the relations can be normalized and the normalized relation values are called atomic
values.

Each row in a relation contains unique value and it is called as tuple, each column
contains value from same domain and it is called as attribute.

Network Data Model

Network model has the entities which are organized in a graphical representation and
some entities in the graph can be accessed through several paths.

43
Hierarchical Data Model
Hierarchical model has one parent entity with several children entity but at the top
we should have only one entity called root. For example, department is the parent
entity called root and it has several children entities like students, professors and
many more.

Object oriented Data Model

Object oriented data model is one of the developed data model and this can hold the
audio, video and graphic files. These consist of data piece and the methods which are
the DBMS instructions.

44
Record base Data Model
Record base model is used to specify the overall structure of the database and in this
there are many record types. Each record type has fixed no. of fields having the fixed
length.

Object relation Data Model

Object relation model is a very powerful model but coming to it’s design it is quiet
complex. This complexity is not problem because it gives efficient results and
widespread with huge applications. It has a feature which allows working with other
models like working with the very known relation model.

Semi structured Data Model

Semi structured data model is a self describing data model, in this the information
that is normally associated with a scheme is contained within the data and this
property is called as the self describing property.

Associative Data Model

Associative model has a division property, this divides the real world things about
which data is to be recorded in two sorts i.e. between entities and associations. Thus,
this model does the division for dividing the real world data to the entities and
associations.

45
Context Data Model

Context data model is a flexible model because it is a collection of many data models.
It is a collection of the data models like object oriented data model, network model,
semi structured model. So, in this different types of works can be done due to the
versatility of it.

Exercise 1

Draw an ERD and relationship diagram for the following description:

Each department has a unique name, a unique number, and a particular employee who manages the
department. We keep track of the start date when that employee began managing the department. A
department may have several locations

Exercise 2

Draw an ERD and relationship diagram for the following description:

A department controls a number of projects, each of which has a unique name, a unique number, and
a single location.

Exercise 3

Draw an ERD and relationship diagram for the following description:

We store each employee’s name (first, last, MI), Social Security number (SSN), street address, salary,
sex (gender), and birth date. An employee is assigned to one department, but may work on several
projects, which are not necessarily controlled by the same department. We keep track of the current
number of hours per week that an employee works on each project. We also keep track of the direct
supervisor of each employee (who is another employee).

Exercise 4

46
Draw an ERD and relationship diagram for the following description:

We want to keep track of the dependents of each employee for insurance purposes. We keep each
dependent’s first name, sex, birth date, and relationship to the employee

Exercise 5

Draw an ERD and relationship diagram for the following description:

Countries host Olympics. A country is identified by its name. An Olympics event is identified by a year
in which it is held and the season (Winter or Summer). Each Olympics event is hosted by a specific
country. We only record countries that hosted Olympics in our database. A country may host multiple
Olympics (e.g., Japan hosted the Winter Olympics in 1998 and in 1972), and all such occurrences must
be recorded.

Exercise 6

Draw an ERD and relationship diagram for the following description:

A dish combines two or more ingredients by cooking them using some cooking method, at some
temperature. Dishes, ingredients and cooking methods all have unique names. Ingredients are
additionally described by a calorie count per unit weight. Each dish is prepared using at most one
cooking method. Only ingredients that are used in some dish are recorded in our database.
(Participation on Dishes in combine is fine. Ternary relationship set is fine.)

Exercise 7

Draw an ERD and relationship diagram for the following description:

Bands, identified by a name and a year in which they were formed, go on tours. A tour is described by
a name and is associated with a start and end dates. You may assume that tour dates for a particular
band do not overlap (i.e., a band is on at most one tour on any particular day). Further, assume that if
a band is removed from our database, then so are all of that band's tours.

. Exercise 8

Draw an ERD and relationship diagram for the following description:

Airlines, identified by their name and country, operate flights. Every airline stored in our database has
some flights associated with it. A flight has a unique flight number, and also has departure and arrival
times. A flight connects an origin and a destination city. A city is uniquely identified by its name and
country. There may be multiple flights for a particular pair of origin and destination cities, but each
flight is between a specific pair of cities. (Participation on Flights in operate is fine. Key constraint is
also fine.)

. Exercise 9

Draw an ERD and relationship diagram for the following description:

An artist is uniquely identified by her name. A painting is uniquely identified by the combination of
name and year when it was painted. Artists paint paintings. Each painting is painted by one artist, but
for some of the paintings the name of the artist is unknown. A museum is uniquely identified by its

47
name. Every painting is owned by a particular museum. We record the year in which the painting was
acquired by the museum that currently owns it in our database.

48