You are on page 1of 63

Chapter 3.

1
Database Models

By: Bekele Worku


Outlines

• Introduction to Modeling

• Network, hierarchical, Relational Model

2
Database Models

• A specific DBMS has its own specific Data Definition Language, but
this type of language is too low level to describe the data
requirements of an organization in a way that is readily
understandable by a variety of users.
• We need a higher-level language.
• Such a higher-level is called data-model.
–A data model is a collection of tools or concepts for describing data,
the meaning of data, data relationships, and data constraints.
• A model is a representation of real world objects and events and their
associations.
• The main purpose of Data Model is to represent the data in
understandable way.

3
Database Models … Cont’d

• A database model is a type of data model that determines the


logical structure of a database and fundamentally determines in
which manner data can be stored, organized, and manipulated.

• Record-based Data Models: Consist of a number of fixed format


records. Each record type defines a fixed number of fields, Each
field is typically of a fixed length.
• Categories of record-based data models:
•Hierarchical Data Model
•Network Data Model
•Relational Data Model

4
Hierarchical Model

• Consists of an ordered set of trees in a parent child mode.


• A parent node can have more than one child node and a child node
should have only one parent.
• Connection between child and its parent is called a Link.
• The simplest data model.
• Record type is referred to as node or segment.
• The top node is the root node.
• The relationship between parent and child can be either 1-1 or 1-M
• To add new record type or relationship, the database must be redefined
and then stored in a new form.

5
Hierarchical Model… Cont’d

6
Network Model

• Allows record types to have more that one parent unlike


hierarchical model.
• A network data models sees records as set members.
• Each set has an owner and one or more members.
• Allow no many to many relationship between entities
• Like hierarchical model network model is a collection of physically
linked records.
• Allow member records to have more than one owner.

7
Network Model … Cont’d

8
Relational Model
• Developed by Dr. Edgar Frank Codd in 1970 (famous paper, 'A
Relational Model for Large Shared Data Banks')
• Terminologies originates from the branch of mathematics called set
theory and relation.
• Can define more flexible and complex relationship.
• Viewed as a collection of tables called “Relations”.
• Relation: Two dimensional table.
• Stores information or data in the form of tables ( rows and columns).
• A row of the table is called tuple which is equivalent to record.
• A column of a table is called attribute which is equivalent to fields.
• Data value is the value of the Attribute.

9
Relational Model … Cont’d
• 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 some how.
• 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

10
Relational Model … Cont’d
Relational Data model (also called the second generation data
model), describes entities and their relationships in the form of table

Entity : Student Entity: course

Id Name Courseno Courseno Course_title Credit_ho


123 Abebe K. INST 321 urs

INST 321 Database 3


234 Almaz M. INST 205 Systems

456 Abebe W. INST 321 INST 205 Introduction to 3


ICT

11
Chapter -3.2
Data Modeling using Entity-Relationship Model

By Mr. Mezgebo Hailu (M.Tech. IT)


Department of Information Technology

12
Outline
 3.1 Introduction to the E-R Model
 3.2 Entity
 3.3 Attributes
 3.4 Relationships
 3.5 Degree of a Relationship
 3.5.1 Unary Relationship
 3.5.2 Binary Relationship
 3.5.3 Ternary Relationships
 3.6 Constraints on Relationships
 3.7 Maximum Cardinality
 3.8 Minimum Cardinality
 3.9 Total Participation
 3.10 Partial Participation
 3.11 Weak Entity Types
 3.13 Other E-R Notations

13
Database Design
Database design consists of several tasks:
•Requirements collection and analysis:
–DB designers interview DB users
–Should be specified in a complete form
–May include functional requirements such as the operations that
will be applied.
•Conceptual Design- create conceptual schema which:
–Is the concise description of the data requirements of users
–Includes detailed descriptions of entity types, relationships and
constraints
–Can be used to ensure that all requirements are met.

14
Database Design..Cont’d

• Logical Design,
–Actual implementation of the DB
–Also called data model mapping
–Result is db schema in the implementation data model
• Physical Design
–Physical implementation of the logical design
• In general, one has to go back and forth between these tasks to refine
a database design, and decisions in one task can influence the choices in
another task.
• In developing a good design, one should ask:
–What are the important queries and updates?
–What attributes/relations are involved?

15
Database Development Process in Short

16
The Three levels of Database Design

Constructing a model independent of any physical


Conceptual considerations.
After the completion of Conceptual Design one has to go for
Design
refinement of the schema, which is verification of Entities,
Attributes, and Relationships

Constructing a model of the information used in an enterprise


based on a specific data model (e.g. relational, hierarchical or
Logical network or object), but independent of a particular DBMS and
Design other physical considerations.

• Producing a description of the implementation of the database


on secondary storage.
• Describes the storage structures and access methods used to
Physical achieve efficient access to the data.
Design • Tailored to a specific DBMS system -- Characteristics are
function of DBMS and operating systems
• Includes estimate of storage space

17
3.1 Introduction to the E-R Model(1)
 The entity relationship(E-R) model is :
– A high-level(conceptual) data model
– It perceives the mini-world as a collection of basic objects called entities.
– It also contains the descriptions of entities called attributes and the relationship between/among
the entities

 E-R modeling is mainly used to create the conceptual schema for the database from the collected
system specifications

 This process is called the conceptual design

 The E-R model is totally DBMS independent

18
3.1 Introduction to the E-R Model(2)
 An entity-relationship model describes data in terms of the following:
– Entities
– Relationship between entities
– Attributes of entities

 We graphically display an E-R model using an entity-relationship diagram


(E-R diagram)

 The E-R diagram uses different notations(Symbols)

19
ER-diagram Symbols

20
21
3.1 Introduction to the E-R Model(3)

Lname CName
FName ID No. CCode Credit

Instructor Teaches Course

What do you understand from the above E-R diagram?

22
3.1 Introduction to the E-R Model(4)

INSTRUCTOR COURSE CSE309

Mezgebo
DBMS
e1 c1
Hailu C2 4

MIT/1999/2 CSE101

POC

23
3.2 Entity(1)
 An entity is an object that exists and which is distinguishable from other objects
– Can be a person, a place, an object, an event, or a concept

– Examples:
Person: Student, Employee, etc.
Object: Computer, Airplane, Machine , etc.
Place: City, Park, Room, Warehouse , etc.
Event: War, Marriage, Lease , etc.
Concept: Project, Account, Course , Holiday , Job , etc.

Entity Representation in an E-R Diagram

24
3.2 Entity (2)
 An entity type defines a collection of entities that have the same attributes

 An entity instance is a single item in this collection

 An entity set is a set of entity instances

 Example:
– Entity type: STUDENT
– Entity instance: Student with ID number MIT/0002/2001
– Entity set: Collection of all students

25
3.3 Attributes
 An attribute is a property or characteristic of an entity type
– We describe an entity with a set of attributes

– Examples:
STUDENT = {Reg. No, Fname , LName, Address, Phone, Email, DOB}
ORDER = {Order ID, Date of Order, Amount of Order}
ACCOUNT = {Account No, Account type, Balance}
CITY = {Name, State, Population}

– Types of Attributes :
Simple, composite, single-valued, multi-valued, stored, and derived

26
Attributes in E-R Diagram

Attributes of the STUDENT Entity Type

27
Simple VS Composite Attributes
 A simple or an atomic attribute cannot be further divided into smaller components
– Examples:
Age
DOB

 A composite attribute, however, can be divided into smaller subparts where each subpart is either
atomic or composite
– Examples:
Name: First Name, Last Name
Address: Street, City, State, ZipCode

28
Single-Valued VS Multi-Valued Attributes
 Single-valued attributes have a single value for an entity instance
– Examples:
Name
Date Of Birth
Reg. No

 Multi-valued attributes, on the other hand, may have more than one value for an entity instance
– Denoted with a double-lined ellipse
– Example:
Languages: Stores the names of the languages that a student speaks
College Degree: BSC., MSC. ,M.Tech. ,PHD, etc.
Phone number: Mobile phone , Office phone , Home phone

29
Stored VS Derived Attributes
 The value of a derived attribute can be determined by analyzing other attributes
– Therefore, no need to store them in the database

– Denoted with a dashed ellipse

– Example:
Age: Can derived from the current date and the attribute DateOfBirth

 An attribute whose value cannot be derived from the values of other attributes is called a stored
attribute

30
Complex Attributes
Complex Attributes

The composite and multivalued attributes can be nested in an arbitrary way.

Example:
Grouping components of a composite attribute between parentheses ( ),
Separating the components with comma, and
Displaying multivalued attributes between braces {}.

Example: A person with more than one address and phone number.

{AddressPhone( {Phone(AreaCode, PhoneNumber) },


Address(StreetAddress(Number, Street, ApartmentNumber), City, State,
Zip) ) }

31
Key Attribute
 A key attribute (or identifier) is a single attribute or a combination of attributes that uniquely
identify an individual instance of an entity type
– Underlined in an E-R diagram

– Example:
Student: StudentID

The Key Attribute

32
Candidate Key Attribute
 Sometimes no single attribute can uniquely identify an instance of an entity type

 A composite key is a composite attribute that uniquely identifies each entity instance

– Example:
City: {Name, State}

The Composite Key Attribute


33
3.4 Relationships(1)
 A relationship is an association, a linkage or a connection between or among entities.
 Examples:
– INSTRUCTOR “teaches” COURSE
– STUDENT “takes” COURSES
– CUSTOMER “has” ACCOUNT

A relationship set is a mathematical relation among n>=2 entities, each taken from entity sets
{(e1,e2,…,en) | e1an element of E1, e2an element of E2,and en an element of En} where
(e1,e2,…,en) is a relationship,E1,E2,…,En are entity sets

Instructor Teaches Course


16 34
3.4 Relationships (2)
A relationships of the same type are grouped into relationship type
A relationship type is represented by diamond connected to relating
entities by lines
A relationship should have a name , an optionality (optional or
mandatory) and a cardinality.
Examples:
– CUSTOMER “has” ACCOUNT
Relationship between CUSTOMER and ACCOUNT Entities
Note Entities can be taught as NOUNS & Relationships can be taught as
VERBS

35
Attributes of Relationships
 An attribute on a relationship stores information related to the relationship
– Much like attributes on entity types

Relationship
Attribute

Example of an Attribute of a Relationship

36
3.5 Degree of a Relationship
 The number of entity sets that participate in a relationship is called the degree of relationship
 Three common degrees in a database:
3.5.1 Unary (degree 1) –Recursive relationship
An association between two instances of the same entity type
R є E1 x E1
E.g. An employee supervises another employee

Supervisee
EMPLOYEE SUPERVISION
Supervisor

37
Role names in a recursive relationship

EMPLOYEE SUPERVISION

e1 
2
1 r1
e2  2
1 r2
e3  2
1 r3
e4 
2
e5  1
1 r4
e6  2
1
r5
e7 
2
r6

38
Recursive Relationship
 Recursive relationship is a kind of relationship when an entity type relates to itself

 In this case role names are essential to distinguish the meaning of each participation in the
relationship

 In the slide given above the mark “1” represents the Supervisor role , and the mark “2” represents
the Supervisee role

 Hence from the diagram in the previous slide we can easily know :
– e1 supervises e2 and e3
– e3 supervises e5 and e6
– e4 supervises e1 and e3

39
3.5.2 Binary Relationship

– Binary (degree 2) – Most relationship sets in a DB System are binary


An association between two different entity types
R є E1 x E2
E.g. Customer has bank Account

40
3.5.3Ternary Relationship

-Ternary (degree 3)
An association among three different entity types
R є E1 x E2 x E3
E.g. A bank employee who has a specific job in a bank branch

Emp_Name Assets

EMPLOYEE WORKS-IN BRANCH

Bankname BranchName
EMP_ID Emp_Salary

JOB
TITLE

LEVEL

41
Ternary Relationships – Extra examples

Musical Performance
Example

Student “Uses”
Equipment for a
Project Example

42
3.6 Constraints on Relationships
 The cardinality of a relationship defines the number of instances of one entity type that can be
associated with instances of another entity type
 The maximum cardinality of a relationship defines the maximum number of instances of one
entity type that can be associated with instances of another entity type

The Four Types of Relationships between Entity Types

43
3.7 Maximum Cardinality(1)
 Relationship types by maximum cardinality:
– One-to-One
– One-to-Many (and Vice-Versa)
– Many-to-Many

One Many

Relationship Types Based on Maximum Cardinality

44
Maximum Cardinality(2)

 How do you know the maximum cardinality between two entity types?
 Let’s say we have 2 entity types called X and Y

X R Y

 Two important questions:


 Q1. Can an instance of X be associated with more than one instance of Y?
 Q2. Can an instance of Y be associated with more than one instance of X?

The 2 questions above have 4 possible answers. Those answers determine the
type of maximum cardinalities

45
Maximum Cardinality(3)

QUESTION 1 QUESTION 2 TYPE OF MAXIMUM


CARDINALITY
YES YES Many-2-Many

YES NO One-2-Many

No YES Many-2-One

NO NO One-2-One

46
Maximum Cardinality(4)

 One-2-One Relationship
– An entity in X is associated with at most one entity in Y , and vice-versa.
– E.g. Each passenger has his own Ticket

Passenger Has Ticket


1 1

 One -2-Many Relationship


 An entity in X is associated with any number(zero or more) of entities in Y. But an entity in Y
can associate with at most one entity in X
 E.g. A department contains many employees who work under it

Department Has Employee


1 M
Maximum Cardinality(5)

 Many -2-One Relationship


An entity in X is associated with at most one entity in Y. But an entity in Y
can be associated with any number (zero or more ) of entities in X
E.g. Many needles can be injected into a single patient

Injected Into Patient


Needle M 1

 Many-2-Many Relationship
An entity in X is associated with any number(zero or more) of entities
in Y ,and an entity in Y is associated with any number (zero or more )
of entities in X

Student M Registers N Course

48
Many-to-one (M:1) Relationship Example
EMPLOYEE WORKS_FOR DEPARTMENT

e1  r1  d1
e2  r2
e3 
 d2
r3
e4 
r4  d3
e5 
r5
e6 

e7 
r6

r7

49
Many-to-many (M:N) Relationship Example

Employee Works-in Project

r9

e1  r1  p1
e2  r2
e3   p2
r3
e4 
r4
e5 
 p3
r5
e6 

e7 
r6

r7
r8
50
Exercise

 Identify the type of relationship (based on maximum cardinality) between the


following entities

1. Employee earns a degree


2. Physician performs Operation
3. Department head manages department
4. Student takes course
5. Building contains room
6. Husband is married to wife
7. Patient is injected by needle
8. Doctors have specialization in disease
9. Patient has patient history
10. Department contains division

51
3.8 Minimum Cardinality(1)

 Does the E-R diagram given below provide sufficient information ?


 What is the minimum number of employees who manage a department?
 What is the minimum number of departments that are managed by an employee?
 Is it must for an employee to be a manager of a department?
 Is it must for a department to have an employee?

Employee Manages Department


1 1

52
3.8 Minimum Cardinality(2)
 The minimum cardinality of a relationship is defined as the minimum number of instances of one
entity type that must be associated with each instance of another entity type

Minimum cardinality is also called participation constraint or
existence dependency constraints. There are 2 types of participation constraints:
1.Total participation
2.Partial participation

Optional

Mandatory

Relationship Types Based on Minimum Cardinality

53
3.9 Total Participation

 Total participation: every entity in the entity set participates in at least one
relationship in the relationship set. The entity with total participation will be
connected with the relationship using a double line.
 The example below shows that the participation of the entity set Department in the relationship
set Manages is total . This is because every department must have a manager .

Employee 1 1 Department
Manages

54
3.9 Total Participation… Continued

E.g.- Participation of EMPLOYEE in “belongs to” relationship with


DEPARTMENT is total since every employee should belong to a
department.

55
3.10 Partial Participation
 In partial participation , some entities (not all entities) in the entity set occurs in the relationship in
the relationship set. That is some entities may not participate in any relationship in the
relationship set.
 The example below shows that the participation of the entity set Student in the relationship set
Leader is partial because it is not possible for every student entity to be a leader.

Student Leader Team

56
3.10 Partial Participation Continued

• E.g.: Participation of EMPLOYEE in “manages” relationship with


DEPARTMENT, DEPARTMENT will have total participation but not
EMPLOYEE;
• EMPLOYEE will have partial participation since not all employees are
managers.

57
 A strong entity type exists independent of other entity types. They have their own primary keys
 A weak entity type is an entity type that doesn’t have a primary key of its own. It depends on
another entity type called the owner or identifying entity type to be uniquely identified
 It needs Foreign keys in conjunction with its attributes to create a primary key
A weak entity type always has a total participation constraint with respect to its identifying

relationship
FNAME LNAME
EMP_ID EMP_FNAME

HAS
EMPLOYEE DEPENDENT

EMP_LNAME EMP_ADDRESS

DOB

58
3.11 Weak Entity Types(2)

 From the previous slide we can see that DEPENDENT is a weak entity type. It is not an object of
interest to be stored in the database but it should be stored because of the existence of another entity
type – the EMPLOYEE – which it is related with

 EMPLOYEE is the owner or the identifying entity type

 DEPENDENT is described by the dependent’s first name , last name and birth date

 It is related with the owner entity type via the identifying relationship type HAS

 The participation of the weak entity type in the indentifying relationship type is always total. But
this doesn’t mean that all total participations involve weak entities

59
Other Notations for E-R diagrams
There are different notations for E-R diagrams.
Crow’s Foot Notation:
Known as IE notation (most popular)
Entity:
–Represented by a rectangle, with its name on the top. The name is
singular (entity) rather than plural (entities).

60
Other Notations for E-R diagrams…Continued
Crow’s Foot Notation…
Attributes:
Identifiers are represented by underlying the name of the
attribute(s)

61
Example Model Crow’s Foot Notation…Continued

62
Thank You!
ANY ???

63

You might also like