Fundamentals of Database Systems - PPTX (Repaired)

Fundamentals of Database
Systems
1
Learning Outcomes
1.Design Database
2.Implement Database using Relational Data model
2
Course outline
• Chapter 1: Introduction to Database Systems
• Chapter 2: Database System Architecture
• Chapter 3: Database Modeling
• Chapter 4: Functional Dependency and Normalization
• Chapter 5: Record Storage and Primary File
Organization
• Chapter 6: The Relational Algebra and Relational
Calculus
• Chapter 7: The SQL Language
3
Textbook
4
Practical tool(MySQl Workbench)
5
Evaluation
• 30% mid
• 20% assignment(project)
• 10% Quiz
• 40% Final Exam
6
Fundamentals of Database
Systems
Chapter One
Introduction to Database Systems
7
Outline
• Introduction
• File Organization vs. Database Approach
• Characteristics of the Database Approach
• Actors on the Scene
8
Reference(Text book)
Read chapter one

Page 3-26
9
Introduction: Initial Vocabulary
• What is Data?
– raw facts about things and events
– Structured: numbers, text, dates
– Unstructured: images, video, documents
• What is Information?
– transformed data that has value for
decision making.
• It is Essential to organize data and
information for retrieval and maintenance
10
Introduction: What is Database?
• A set of information held in a
computer(dictionary definition)
• A very large, integrated collection
of data
• A collection of data arranged for
ease and speed of search and
retrieval.
– E.g. University- registration, grades
11
12
Introduction: What is Db System?
• Database System=DBMS +Data(db)
– is the DBMS software together with the
data itself.
– Sometimes, the applications are also
included.
13
Example: Database Systems
Today(social network)
14
Today(Entertainment)
15
Today(Banking)
16
Example:Database System
applications
• Airlines: reservations, schedules
• Sales: customers, products, purchases
• Human resources: employee records, salaries, tax deductions.
• Telephone directories
• Library catalogues
• Medical records
• Airline bookings
• Credit card details
• Student records
• Customer histories
• Databases touch all aspects of our lives
17
Data Handling Approaches(File based
approach)
• What is File?
– information stored on a computer as one unit with
one name
• In the early days, database applications were
built directly on top of file systems.
• Data is stored in files
– Each file has a specific format
– Programs that use these files depend on
knowledge about that format
18
File Processing Systems(Example)
Billing Purchasing
Program Program
Accounts Buyer Inventory Vendor

Customer
receivable file file file
file
file
Accounts Payable Sales Order Processing Payroll

Program Program Program
Inventory Employee
Vendor Invoice Customer
file file
file file file
Each user defines and implements the files needed for a specific software
application
19
Drawbacks of File based Approach
 Data redundancy and inconsistency
 Multiple file formats, duplication of information in
different files.
 Difficulty in accessing data
 Need to write a new program to carry out each
new task.
 Atomicity of updates
20
Drawbacks of File based Approach(cont..)
• Concurrent access by multiple users.

– Concurrent accessed needed for performance.
– Uncontrolled concurrent accesses can lead to
inconsistencies.
– Example: Two people reading a balance and updating it
at the same time.
• Security problems
– Hard to provide user access to some, but not all, data.
• So,What is the solution for those Problems?
• Answer: Database Systems Approach
21
Characteristics of the Database Approach
• Insulation between programs and data(program-

data independence):
– Allows changing data storage structures and operations
without having to change the DBMS access programs.
• Self-describing nature of a database system
• A DBMS catalog stores the description of the
database(meta data).
• This allows the DBMS software to work with different
databases.
22
Characteristics of the Database
Approach(contd.)
• Data Abstraction:
• A data model is used to hide storage details and present
the users with a conceptual view of the database.
• Support of multiple views of the data:
• Each user may see a different view of the database,
which describes only the data of interest to that user.
• Sharing of data and multiuser transaction
processing:
• allowing a set of concurrent users to retrieve and to
update the database.
23
Db System Approach(Example)
Order Dept. Accounting Payroll
Dept. Dept.
Program Program Program
A B C
Ordering
Invoicing Payroll
filing
System System
System
Back Inventory Customer Inventory Employee

Orders Master Master Pricing Master
file file file file file
 Single repository maintains data that is defined once and then accessed by various 24
users
Disadvantages of Using the Database
Approach
• Expensive
– hardware, software, personnel,
processing overhead, operating cost , etc.
• Increased vulnerability to failure
• Recovery is more complex
25
Actors on the Scene
• Database domain has several roles and career paths
associated with it.
26
27
28
29
Actors on the Scene(cont..)
• System(Application) Developer:
– a person in charge of developing applications
that access databases.
• End-users:
• they use the data for queries, reports and some of
them actually update the database content.
• Casual : access database occasionally when needed
• Naïve or Parametric : They use previously well-defined
functions in the form of “canned transactions” against
the database. 30
Actors on the Scene(End users cont..)
– Sophisticated :
• use tools in the form of software packages
that work closely with the stored database.
– Stand-alone :
• mostly maintain personal databases using
ready-to-use packaged applications.
31
CHAPTER TWO
Database System Architecture
32
Outline
• Terminologies: Data Abstraction, Data

models, Schemas, and Instances
• Over view of data models
• Architecture and Data Independence
• Database Language and Interface
• Classification of DBMS
33
Terminologies:Data Abstraction, Data Models, Schema and Instances
• What is Data Abstraction?

– One fundamental characteristic of the database approach is
that it provides some level of data abstraction.
– the suppression of details of data organization and storage
and the highlighting of the essential features for an
improved understanding of data.
• What is Data model?
– A set of concepts to describe the structure of a database,
and certain constraints that the database should obey.
– It includes a set of basic operations for specifying retrievals
or updates on the database.
34
Categories of Data models
• 3 categories[based on the type of concepts
they used to describe the database]
• High-level or Conceptual data models
• Low-level or Physical data model
• Representational(or implementation) data
model
35
Categories of Data models(contd.)
36
Categories of Data models(contd.)
37
38
Db Schema, schema diagram and
schema construct (Example)
39
Db Schema, schema diagram and schema
construct (Example)
40
Data Abstraction, Data Models, Schema and
Instances contd.
• What is Database State?
• the content of a database at a moment in time.
• Also called Database Instance .
• Initial Database State: the database when it is
loaded
• Valid State: A state that satisfies the structure and
constraints of the database.
• The database schema changes very infrequently.
• The database state changes every time the database
is updated.
41
DBMS Architecture and Data Independence
• Three of four important characteristics of

the database approach.
1. Self-describing of a DB (Schema)
2. Insulation between programs and data
3. Support of multiple views of the data
• Three-Schema Architecture was proposed to
help achieve and visualize these
characteristics
42
43
44
45
Client/Server Architecture
Old Modern
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
Chapter Three
Database Modeling
68
Outline
• Database Design principles, Network and
hierarchical
• Data Modeling using Entity Relationship Model
– Using High level Data Models for Database Design
– Entity types and Sets, Attributes and Keys Relationships,
Roles and Structural Constraints Weak Entity Types
– Database Abstraction
– E/R Diagram naming conventions, and Design issues
69
Database Design Principles
70
Database Design Principles:
Hierarchical Model
• Organizes its data using a tree structure.
• The root of the tree is the parent followed by
child nodes.
• A child node cannot have more than one
parent, though a parent can have many child
nodes.
• The first hierarchical database management
system was IMS (Information Management
System) released by IBM in 1968.
71
Database Design Principles:Hierarchical
Model(cont..)
72
Database Design Principles:
Hierarchical Model (Cont.)
• Advantages:
– Simple to construct and operate on
– Language is simple; uses constructs like GET, GET
UNIQUE, GET NEXT, GET NEXT WITHIN PARENT etc.
• Disadvantages:
– Navigational and procedural nature of processing
– Database is visualized as a linear arrangement of
records
73
Database Design Principles: Network
Model
• In 1969, CODASYL (Committee on Data Systems
Languages) released its first specification about the
network data model.
• recognized that data in a system is related to other
data in the same system.
• It is a network of links between the different records.
74
Network Model (Cont.)
• Advantages:
– model complex relationships and represents
semantics of add/delete on the relationships.
– Language is navigational; uses constructs like FIND,
FIND member, FIND owner, FIND NEXT within set,
GET etc.
• Disadvantages:
– Navigational and procedural nature of processing
75
Relational Model
• originated by E.F. Codd in the 1970s
• became widely used in the 1980s and 1990s.
• based on mathematics – relational algebra.
• data is stored in tables (also called relations).
• Each table is physically separate to other tables in the
system – unlike network or hierarchy models, where
there must be physical file links between data sets.
76
Relational Data model(Example)
77
Object-Oriented Model (OO)
• In an OO db, each type of object in the database’s mini-
world is modelled by a class.
• A class has properties (attributes).
• A class also has methods that are stored with the class
definition
• e.g. the code to create a new Customer object
belongs in the Customer class.
• When an application is working with data in the
database, the application creates (instantiates) objects
from the class definitions.
78
Object-Oriented Model (cont..)
• One advantage of the OO model is sub-classes
• Object Oriented data models are popular in
universities,
• but have not been widely accepted in the
industry;
• however, object-relational mapping (ORM)
tools are available which allow a seamless
integration of object-oriented programs with
relational database
79
Object-Relational Model (OR)
• It treats every entity as an object (instance of a class)
and a relationship as an inheritance.
• has the capability to store object relationships in
relational form.
• Entities have attributes, which are the data elements
that characterize the entity.
• Some features and benefits of an Object-Relational
model are:
• Support for complex, user defined types
• Object inheritance
80
Database Design
• Since the design process is complicated, especially for

large databases, it is divided into three sub phases:
 Conceptual database design
 Logical database design
 Physical database design
81
Database design(contd.)
82
Database Design Views(Summary)
83
What is Conceptual database design?
• It is a high-level graphical representation of the database

design.
– is the process of constructing a model of the
information used in an enterprise, independent of any
physical considerations.
– Its output is easy for communication between end-
users and developers.
– Conceptual design may be Structured SAD based
(Commonly ERDs)or Object-Oriented SAD based
(commonly UMDs)
84
Conceptual Database Design using Entity-
Relationship Model
85
Conceptual db design using Entity-
Relationship (ER) Model
 Conceptual modeling is a very important phase
 In designing a successful database application
 The ER model is a high-level conceptual data model
 It is a detailed, logical representation of the data for an
organisation or business area.
 It should be understandable to both the user and to the IT
technologist
 It was introduced by Peter Chen in 1976, and is now the
most widely used conceptual data model.
86
Conceptual db design using Entity-
Relationship (ER) Model(cont..)
 The model must be as ‘open’ as possible and not tied
to any technology or to any particular business
methodology
 It must be flexible enough so that it can be used and
understood in practically any environment where
information is modelled
 The E-R model is usually expressed as an E-R diagram.
87
Sample E-R Diagram
88
ER Model Concepts
• Entities and Attributes
– Entities are specific objects or things in the mini-world that are
represented in the database.
– Example the EMPLOYEE Habtamu, the CS
DEPARTMENT,etc
– Attributes are properties used to describe an entity.
– For example an EMPLOYEE entity may have a Name, SSN,
Address, Sex, BirthDate
– Each attribute has a value set (or data type) associated with it –
e.g. integer, string,
89
ER Model Concepts: Entity Types
• Entities with the same basic attributes are grouped
or typed into an entity type. For example, the
EMPLOYEE entity type or the DEPARTMENT entity
type.
• In ER Diagram, Entity type are represented by
rectangle and attributes are represented by ellipse.
90
Entity Types: Strong versus Weak entity type
 Most of the basic entity types are classified as strong entity

types.
 Exists independently from other entity types (such as
EMPLOYEE)
– Always have a unique characteristic (identifier) – an
attribute or combination of attributes that uniquely
distinguish each occurrence of that identity
 A weak entity type existence depends on some other entity
type.
 It has no meaning in the ER diagram without the entity on
which it depends (such as DEPENDENT)
91
Strong versus Weak entity type(cont..)
 The entity type on which the weak entity type depends is
called the Identifying owner (or owner for short).
 Identifying relationship is the relationship between a weak
entity type and its owner
 Weak entity identifier is its partial identifier combined with
that of its owner to form a full identifier for weak entity.
92
Types of Attributes
 An attribute is a property or characteristic of an entity
type.
 for example the entity EMPLOYEE may have attributes
Employee_Name and Employee_Address.
 Attributes may also be associated with relationships
 An attribute is associated with exactly one entity or
relationship
 In ER diagrams place attributes name in an ellipse with a
line connecting it to its associated entity
93
Simple versus composite attributes
(following Fig.)
 Some attributes can be broken down into meaningful
component parts, such as Address, which can be broken
down into Street_Address, City..etc.
 The component attributes may appear above or below the
composite attribute on an ER diagram
 Provide flexibility to users, as can refer to it as a single unit
or to the individual components
 A simple (atomic) attribute is one that cannot be broken
down into smaller components
94
A composite attribute
95
Single-Valued versus Multivalued Attribute
• It frequently happens that there is an attribute that

may have more than one value for a given instance,
e.g. EMPLOYEE may have more than one Skill.
• A Multivalued attribute is one that may take on more
than one value – it is represented by an ellipse with
double lines
• Single valued attribute is an attribute with single value.
– e.g Employee name
96
Entity with a multivalued attribute (Skill) and derived
attribute (Years_Employed)
97
Stored versus Derived Attributes
 Some attribute values can be calculated or derived
from others
 e.g., if Years_Employed needs to be calculated for EMPLOYEE,
it can be calculated using Date_Employed and Today's_Date
 A derived attribute is one whose value can be
calculated from related attribute values (plus possibly
other data not in the database)
 In ER Diagram, a derived attribute is signified by an
ellipse with a dashed line.
98
Identifier/key attribute
• Identifier attribute or Key is an attribute (or combination
of attributes) that uniquely identifies individual
instances of an entity type.
• E.g Student_ID
• To be a candidate identifier, each entity instance must
have a single value for the attribute, and the attribute
must be associated with each entity
• The identifier attribute is underlined
99
Simple and composite key attributes
(a) Simple key attribute
100
Composite Identifier
• A Composite Identifier is when there is no single (or
atomic) that can serve as an identifier
– E.g Flight_ID is a composite identifier that has component
attributes Flight_Number and Date – this combination is
required to uniquely identify individual occurrences of
Flight
• Flight_ID is underlined, whilst its components are not
101
(b) Composite key attribute
102
Criteria for selecting identifiers
 Some entities have more than one candidate
identifier, so the following criteria should be used:
 Choose identifier that will not change in value
over the life of each instance of the entity type
 Choose identifier that is guaranteed to have valid
values and Will not be null (or unknown). If
composite, make sure all parts will have valid
values
103
Criteria for selecting identifiers(cont..)
 Avoid the use of intelligent identifiers whose structure
indicates classifications, locations or people that might
change.
e.g. the first two digits of an identifier may indicate a
warehouse location, but such codes are often changed
as conditions change, which renders them invalid.
104
Relationship Types, Sets and
Instances
 A relationship is an association among the instances of one or
more entity types that is of interest to the organization
 Relationship Type is a meaningful association between (or
among) entities.
• A relationship type R among n entity types E1, E2, ..., En defines
a set of associations or a relationship set among entities from
these entity types.
 the relationship allows us to answer questions that could not
be answered given only the entity types.
 It is denoted by a diamond symbol in ER Diagram
105
Relationship types and instances
(a) Relationship type (Completes)
106
Relationship Types, Sets and
Instances(cont..)
• Relationship instance is an association between (or
among) entity instances, where each relationship
includes exactly one entity from each participating
entity type.
• For example, in the following figure each line
represents a relationship instance between one
employee and one course, indicating that the
employee has completed that course
107
(b) Relationship instances
108
Attributes on relationships
• Attributes may be associated with a many-to-many (or
one-to-one) relationship, as well as with an entity
– e.g., an organisation may want to record the date when an
employee completes each course
• In the following diagram, the relationship ‘Completes’
joins the EMPLOYEE and COURSE entities, and
Date_Completed is joined to this as it is a property of
the relationship ‘Completes’
109
An associative entity
(a) Attribute on a relationship
110
Associative entities
 The presence of one or more attributes on a
relationship suggests that the relationship should
perhaps be represented as an entity type
 An associative entity is an entity type that associates
the instances of one or more entity types and contains
attributes that are peculiar to the relationship between
those entity instances.
 E.g. The associative entity type CERTIFICATE is
represented with the diamond relationship symbol
enclosed within the entity rectangle
111
Associative entities (cont..)
 The purpose of this special symbol is to preserve the
information that the entity was initially specified as a
relationship on the ER diagram
 There is no relationship diamond on the line between
an associative entity and a strong entity, because the
associative entity represents the relationship
112
(b) An associative entity (CERTIFICATE)
113
Degree of a relationship
 Is the number of entity types that participate in it.
 e.g ‘Completes’ has degree 2, since there are two
participating entity types, EMPLOYEE and COURSE
 The three most common relationship degrees are unary
(degree 1), binary (degree 2) and ternary (degree 3)
 Higher degree relationships are possible but rarely
encountered in practice
114
Unary relationship
• Is between the instances of a single entity type (also called
recursive relationships)
– E.g ‘Is_Married_To’ is a one-to-one relationship between instances of
the PERSON entity type
– ‘Manages’ is a one-to-many relationship between instances of the
EMPLOYEE entity type
PERSON
Is_Married_To
115
116
Unary relationship(cont..)
117
Binary relationships
• Between the instances of two entity types, and is the most
common type of relationship encountered in data modelling.
– e.g. (one-to-one) an EMPLOYEE is assigned one
PARKING_PLACE, and each PARKING_PLACE is assigned to
one EMPLOYEE
– (one to many) many peoples may lives in a particular city
and each person only lives in one CITY.
– (many-to-many) a STUDENT may register for more than one
COURSE, and each COURSE may have many STUDENTS
118
119
Binary relationships(cont..)
120
Ternary relationships
• A ternary relationship is a simultaneous relationship
among the instances of 3 entity types
• It is the most common relationship encountered in data
modelling
• Here, vendors can supply various parts to warehouses
121
Ternary relationships
122
Ternary relationships(cont..)
123
Ternary relationships(cont..)
 The relationship ‘Supplies’ is used to record the specific
PARTs supplied by a given VENDOR to a particular
WAREHOUSE
 There are two attributes on the relationship ‘Supplies’,
Shipping_Mode and Unit_Cost
 e.g. one instance of ‘Supplies might record that VENDOR X
can ship PART C to WAREHOUSE Y, that the Shipping_Mode
is ‘next_day_air’ and the Unit_Cost is £5-00 per unit
124
Structural Constraints: Cardinality and
Participation constraints
 Relationship types usually have certain constraints that limit the

possible combinations of entities that may participate in the
corresponding relationship set.
 These constraints are determined from the miniworld situation
that the relationships represent.
 E.g. if the company has a rule that each employee
must work for exactly one department, then we
would like to describe this constraint in the schema
125
Participation constraints(cont..)
126
 The number of instances of one entity that can or must
be associated with each instance of another entity.
 There are two main types of Structural constraints
 Cardinality ratio and participation
• The cardinality ratio for a binary relationship specifies the
maximum number of relationship instances that an entity
can participate in.
127
Structural Constraints: Cardinality ratio and
• For example,
– in the WORKS_FOR binary relationship type,
• DEPARTMENT:EMPLOYEE is of cardinality ratio 1:N
– Meaning that each department can be related to (that is,

employs) any number of employees, but an employee can be
related to (work for) only one department.
– N indicates there is no maximum number
128
• On the other hand, an employee can be related to a
maximum of one department. The possible cardinality
ratios for binary relationship types are 1:1, 1:N, N:1, and
M:N.
129
 E.g 1:1 binary relationship MANAGES which relates a
department entity to the employee who manages that
department.
 This represents the miniworld constraints that at any
point in time an employee can manage one department
only and a department can have one manager only.
130
Structural Constraints: Cardinality
and Participation constraints(cont..)
131
 The relationship type WORKS_ON is of cardinality ratio
M:N, because the mini-world rule is that an employee
can work on several projects and a project can have
several employees
132
133
 Cardinality ratios for binary relationships are represented
on ER diagrams by displaying 1, M, and N on the diamonds.
 The participation constraint specifies whether the
existence of an entity depends on its being related to
another entity via the relationship type.
 Specifies minimum and maximum cardinality
134
 There are two types of participation constraints
 Total and Partial
 E.g:- If a company policy states that every employee must
work for a department, then an employee entity can exist only
if it participates in at least one WORKS_FOR relationship
Instance .
135
 The participation of EMPLOYEE in WORKS_FOR is called total
participation,
 meaning that every entity in the total set of employee entities
must be related to a department entity via WORKS_FOR.
136
137
 when all entity type instance are not related to the
second entity type instance we refer partial
participation.
– E.g. We do not expect every employee to manage a
department, so the participation of EMPLOYEE in the
MANAGES relationship type is partial,
– meaning that some or part of the set of employee entities are
related to some department entity via MANAGES, but not
necessarily all 138
139
 In ER diagrams, total participation is displayed as a
double line connecting the participating entity type to
the relationship, whereas partial participation is
represented by a single line.
140
141
Minimum cardinality
 Participation constraint Specifies minimum and maximum cardinality.
 The minimum cardinality of a relationship is the minimum number of
instances of an entity B that may be associated with each instance of
an entity A.
 E.g what is the minimum cardinality in WORKS_FOR relationship?
142
Minimum Cardinality(cont..)
143
Maximum cardinality
 Is the maximum number of instances of an entity B

that may be associated with each instance of entity A.
 E.g what is the maximum cardinality in WORKS_ON
relationship?
144
Maximum cardinality(cont..)
145
Multiple relationships
 In some situations an organisation may want to model more

than one relationship between the same entity types
 E.g.:- relationship between PROFESSOR and COURSE
 The relationship Is_qualified associates professors with the
courses they are qualified to teach.
 The relationship Is_scheduled associates professors with the
courses they actually teach during a given semester (where
the maximum cardinality for a given semester is 4)
146
(b) Professors and courses (fixed upon constraint)
147
Entity Relationship Diagram
 Diagrammatic notation associated with the ER model is referred
to as ER diagrams.
 In ER diagrams the emphasis is on representing the schemas
rather than the instances.
 This is more useful in database design
 A database schema changes rarely, whereas the contents of
the entity sets change frequently.
 The schema is obviously easier to display, because it is much
smaller. 148
Developing E-R Diagram
 Designing conceptual model for a database is not a one
linear process but an iterative activity.
 The entity sets, attributes, relationship sets, and constraints on
the data are to be specified from the requirement specification
documents.
 The basic E-R model is graphically depicted and
presented for review by the end-users.
 The process is repeated until the end users and
designers agree that the E-R diagram is a fair
representation of the organization’s activities and
functions.
149
Developing E-R Diagram(cont..)
• Relationships between entities indicate access from one
entity to another.
– It is possible to access one entity occurrence from another
entity occurrence even if there are other entities and
relationships that separate them.
• This is often referred to as navigation of the ER diagram.
• The last phase in ER modeling is validating an ER Model
against requirement of the user.
150
Summary of ER model notation
151
152
153
154
Relationship Cardinality
155
Developing ER Diagram(Example:1)
• Draw ER diagram for the following
requirements.
• Rift valley university has several employees and
departments.the database must store the
following information about
employees,empid,name,sex,age and
specialization.department have depid,depname
and deplocation. An employee may work in up
to two departments or may not be assigned to
any department. A department must have at
least one employee.
156
• Solution
• Step 1:Identify Entity Types
– Employee
– Department
• Step 2:identify attributes for each entity
types
– Employee:empid, name,sex,age and specialization
– Department: depid,depname and deplocation
157
• Step 3:identify relationship types
– Employee:Department:employee works for department
– Department:Employee:department has employees
• Step 4:identify relationship constraints
– Employee:Department
• Cardinality ratio:1:2
• Participation:partial
– Department:Employee
• Cardinality ratio:1:m
• Participation:Total
158
159
Developing ER-Diagram:Example 2
Given the following information, develop E-R Diagram.

– A student record management system will have the following
two basic data object categories with their own features or
properties: Students will have an Id, Name, Dept, Age, GPA and
Course will have an Id, Name, Credit Hours. Whenever a student
is enrolled in a course in a specific Academic Year and Semester,
the Student will have a grade for the course.
160
• Solution
– Step 1:Identify entity types
• Student
• Course
– Step 2:Attributes of each entity type
– Student Course
• Id ccode
• Name name
• Age credit
• DOP
• GPA
• Dept.
161
• Step 3:identify relationship types

– Student:Course: Student Enrolled in courses
• Step 4:identify relationship constraints
– Student: Course
– Cardinality Ratio:1:M
Course: Student
Cardinality Ratio:1:M
162
Cont…
M N
163
Draw ER Diagram: Example
• Car Insurance company
• Construct an ER diagram for a car insurance
company whose customers own one or more
cars .the database stores driver id,name and
address about owner and stores car plate,
model and year about each cars. it stores
report number,location and date for each
accidents. each car has associated with it zero
to any number of recorded accidents.
164
Draw ER Diagram: Example
• Identify Entity Types
– Person(Owner)
– Accident
– Car
• Identify attributes for each entity types
• Person(driver id,name and address)
• Car(car plate, model and year)
• Accident(report number,location and date )
165
ER Diagram Car insurance
166
167
168
169
170
Developing ER Diagram
1.Identify Entity Types
2.Identify attributes for each entity types
3.Identify relationship types
4.Identify relationship constraints
171
Developing E-R Diagram(Company Database)
Example
Given the following requirements, Draw E-R diagram for the Company
Database.
The company database keeps track of a company’s employees,
departments and projects:
Requirements:
Concerning the Department:
1. Company is organized into departments
2. A department has a unique name, a unique number, location
and a particular employee who manages the department
3. We track the start date for the manager function
4. A department may be in several locations
5. A department controls a number of projects
172
• Concerning the Project:

6.A project has a unique name, a unique number and is
in a single location.
• Concerning the Employee:
7.Each employee has a name,SSN, address, salary, sex
and birth date
8.An employee is assigned to one department but may
work on several projects which are not necessarily
controlled by the same department
173
9.We track the number of hours per week that an employee

works on each project
10.We keep track of the direct supervisor of each employee
11.We track the dependents of each employee (for insurance
purposes)
• Concerning the dependent:
12.We record each dependent’s first name, sex, birth date, and
relationship to the employee
174
Developing E-R Diagram(Company database)
1.Identify Entity Types

2.identify Attributes for each entity types
3.identify Relationship Types
4.identify Relationship Constraints
175
The entity Types:
EMPLOYEE DEPENDENT
DEPARTMENT
PROJECT
176
• Attributes of Each Entity Types

• EMPLOYEE DEPARTMENT DEPENDENT PROJECT
• Ssn -depcode -name -procode
• Name -name,depmgr,mgrstartdate - sex -name
• Sex -location -birthdate -location
• Address -relationship
• Salary
• Bdate
• empsupervisor
177
Entities with attributes:
fname minit lname
address salary
dependent
name sex
ssn name sex birthdate relationship

employee
bdate
name Depcode location project
department name Procode location
178
• Identify relationship type, Cardinality and Degree

between entity types
– Between DEPARTMENT and PROJECT
– Between DEPARTMENT and EMPLOYEE
– Between DEPARTMENT and DEPENDENT
– Between PROJECT and EMPLOYEE
– Between PROJECT and DEPENDENT
– Between EMPLOYEE and DEPENDENT
– EMPLOYEE to EMPLOYEE
179
• Between DEPARTMENT and PROJECT

– A department controls a number of projects
• Degree: Binary
• Cardinality ratio: 1:N
• Participation: partial
– A Project is controlled by one department
• Cardinality ratio:1:1
• Participation: total
• Between DEPARTMENT and EMPLOYEE
– An employee is assigned/works to one department
180
• Degree: Binary
• Cardinality ratio: 1:1
– A department contains a number of Employees
• Degree: Binary
– Between DEPARTMENT and DEPENDENT
– No relationship from or to DEPARTMENT and DEPENDENT
181
 Between PROJECT and EMPLOYEE
 Employee works on several Projects
• Degree: Binary
 A Project contains several Employees
• Degree: Binary
• Cardinality ratio: 1:M
182
 Between PROJECT and DEPENDENT
• There is no relationship between PROJECT and DEPENDENT
 Between EMPLOYEE and DEPENDENT
• An Employee may have one or more Dependents
• Degree: Binary
• Participation: partial
• A Dependent is dependent on Employee
• Degree: Binary
• Participation: Total
183
• EMPLOYEE to EMPLOYEE
• An Employee is supervisor of several Employees
• Degree: Unary
• Participation: Partial
 Employees supervised by an Employee
• Degree: Unary
• Participation: Partial
184
With relationships:
1
N works for department
1
employee 1
manages 1 controls
supervisee N
supervisor
N
N 1 M
supervision 1 works on project
dependents of
partial constraint
dependent
total constraint
185
The final E-R Diagram
name Depcode location
fname minit lname 1

N works for department
name sex address salary
1 number of
startdate employees
ssn 1
employee manages controls
bdate 1
1 N
degree
supervisor N hours N
supervisee M
1
supervision works on project
dependents of name procode location

N
dependent
name sex birthdate relationship
186
Draw ER Diagram:Quiz 10%
• Rift valley university has a large number of courses in its

catalog. Attributes of course include, course code, course title
and credit hour. each course may have one or more different
courses as prerequisites, or may have no
prerequisites.similarily,a particular course may be a prerequisite
for any number of Courses or may not be a prerequisite for any
other course.
• Draw ER diagram to keep this information
187
Chapter 4
Functional Dependency
and Normalization
188
Outline
• ER diagram to Relational Mapping
• Data Normalization
• Functional Dependency
• Normalization
• Decomposition
189
ER to Relational Mapping
• ER-to-Relational Mapping Algorithm
– Step 1: Mapping of Regular(Strong) Entity Types
– Step 2: Mapping of Weak Entity Types
– Step 3: Mapping of Binary 1:1 Relation Types
– Step 4: Mapping of Binary 1:N Relationship Types.
– Step 5: Mapping of Binary M:N Relationship Types.
– Step 6: Mapping of Multivalued attributes.
– Step 7: Mapping of N-ary Relationship Types.
Slide 7- 190
ER-to-Relational Mapping Algorithm
• Step 1: Mapping of Regular(Strong) Entity Types.
– For each regular (strong) entity type E in the ER schema,
create a relation R that includes all the simple attributes of E.
– Choose one of the key attributes of E as the primary key for R.
– If the chosen key of E is composite, the set of simple
attributes that form it will together form the primary key of R.
• Example: We create the relations EMPLOYEE, DEPARTMENT, and
PROJECT in the relational schema corresponding to the
regular(strong) entities in the ER diagram.
– SSN, DNUMBER, and PNUMBER are the primary keys for the
relations EMPLOYEE, DEPARTMENT, and PROJECT as shown.
FIGURE
The ER conceptual schema diagram for the COMPANY database.
Slide 7- 192
FIGURE 7.2
Result of mapping the COMPANY ER schema into a relational schema.
Slide 7- 193
• Step 2: Mapping of Weak Entity Types

– For each weak entity type W in the ER schema with owner entity type
E, create a relation R & include all simple attributes (or simple
components of composite attributes) of W as attributes of R.
– Also, include as foreign key attributes of R the primary key attribute(s)
of the relation(s) that correspond to the owner entity type(s).
– The primary key of R is the combination of the primary key(s) of the
owner(s) and the partial key of the weak entity type W, if any.
• Example: Create the relation DEPENDENT in this step to
correspond to the weak entity type DEPENDENT.
– Include the primary key SSN of the EMPLOYEE relation as a foreign key
attribute of DEPENDENT (renamed to ESSN).
– The primary key of the DEPENDENT relation is the combination {ESSN,
DEPENDENT_NAME} because DEPENDENT_NAME is the partial key of
DEPENDENT.
Slide 7- 194
• Step 3: Mapping of Binary 1:1 Relation Types
– For each binary 1:1 relationship type R in the ER schema,
identify the relations S and T that correspond to the entity
types participating in R.
• possible approaches:
1. Foreign Key approach: Choose one of the relations-say S-
and include a foreign key in S the primary key of T. It is
better to choose an entity type with total participation in R
in the role of S.
• Example: 1:1 relation MANAGES is mapped by
choosing the participating entity type DEPARTMENT to
serve in the role of S, because its participation in the
MANAGES relationship type is total.
2. Merged relation option: An alternate mapping of a 1:1
relationship type is possible by merging the two entity
types and the relationship into a single relation. This may
be appropriate when both participations are total. Slide 7- 195
(contd.)
• Step 4: Mapping of Binary 1:N Relationship Types.
– For each regular binary 1:N relationship type R, identify the
relation S that represent the participating entity type at the N-
side of the relationship type.
– Include as foreign key in S the primary key of the relation T that
represents the other entity type participating in R.
– Include any simple attributes of the 1:N relation type as
attributes of S.
• Example: 1:N relationship types WORKS_FOR, CONTROLS, and
SUPERVISION in the figure.
– For WORKS_FOR we include the primary key DNUMBER of the
DEPARTMENT relation as foreign key in the EMPLOYEE relation
and call it DNO.
Slide 7- 196
ER-to-Relational Mapping Algorithm (contd.)
• Step 5: Mapping of Binary M:N Relationship Types.

– For each regular binary M:N relationship type R, create a new relation S
to represent R.
– Include as foreign key attributes in S the primary keys of the relations that
represent the participating entity types; their combination will form the
primary key of S.
– Also include any simple attributes of the M:N relationship type (or simple
components of composite attributes) as attributes of S.
• Example: The M:N relationship type WORKS_ON from the ER
diagram is mapped by creating a relation WORKS_ON in the
relational database schema.
– The primary keys of the PROJECT and EMPLOYEE relations are included as
foreign keys in WORKS_ON and renamed PNO and ESSN, respectively.
– Attribute HOURS in WORKS_ON represents the HOURS attribute of the
relation type. The primary key of the WORKS_ON relation is the
combination of the foreign key attributes {ESSN, PNO}.
Slide 7- 197
ER-to-Relational Mapping Algorithm (contd.)
• Step 6: Mapping of Multivalued attributes.

– For each multivalued attribute A, create a new relation R.
– This relation R will include an attribute corresponding to A, plus the
primary key attribute K-as a foreign key in R-of the relation that
represents the entity type of relationship type that has A as an attribute.
– The primary key of R is the combination of A and K. If the multivalued
attribute is composite, we include its simple components.
• Example: The relation DEPT_LOCATIONS is created.
– The attribute DLOCATION represents the multivalued attribute
LOCATIONS of DEPARTMENT, while DNUMBER-as foreign key-represents
the primary key of the DEPARTMENT relation.
– The primary key of R is the combination of {DNUMBER, DLOCATION}.
Slide 7- 198
(contd.)
• Step 7: Mapping of N-ary Relationship Types.
– For each n-ary relationship type R, where n>2, create a new
relationship S to represent R.
– Include as foreign key attributes in S the primary keys of the
relations that represent the participating entity types.
– Also include any simple attributes of the n-ary relationship type (or
simple components of composite attributes) as attributes of S.
• Example: The relationship type SUPPY in the ER on the next
slide.
– This can be mapped to the relation SUPPLY shown in the relational
schema, whose primary key is the combination of the three foreign keys
{SNAME, PARTNO, PROJNAME}
Slide 7- 199
FIGURE 4.11
Ternary relationship types. (a) The SUPPLY relationship.
Slide 7- 200
FIGURE 7.3
Mapping the n-ary relationship type SUPPLY from Figure 4.11a.
Slide 7- 201
Summary of Mapping constructs and constraints
Table Correspondence between ER and Relational Models
ER Model Relational Model

Entity type “Entity” relation
1:1 or 1:N relationship type Foreign key (or “merged relationship”
relation)
M:N relationship type “Relationship” relation and two foreign keys
n-ary relationship type “Relationship” relation and n foreign keys
Simple attribute Attribute
Composite attribute Set of simple component attributes
Multivalued attribute Relation and foreign key
Key attribute Primary (or secondary) key
Slide 7- 202
Introduction:What is Data Normalization?
• The process of decomposing relations with

anomalies to produce smaller, well-structured
relations(tables).
• Primarily a tool to validate and improve a
logical design so that it satisfies certain
constraints that avoid unnecessary duplication
of data.
203
What is Well structured Relations?
• A relation that contains minimal data
redundancy and
• A relation which allows users to insert, delete,
and update rows without causing data
inconsistencies.
• data redundancy in relation causes problems
204
Redundant Information in Rows causes
update anomalies problems
 Mixing attributes of multiple entities may cause

problems
 Information is stored redundantly wasting storage space
• Storing natural joins of base relations leads to an
additional problem referred to as update anomalies.
 Problems with update anomalies
 Insertion anomalies
 Deletion anomalies
 Modification anomalies
205
insertion, deletion and modification
anomalies
• Insertion anomalies: Happens when the insertion of a
data record is not possible unless we also add some
additional unrelated data to the record.
• Deletion anomalies: happens when deletion of a data
record results in losing some unrelated information that
was stored as part of the record that was deleted from a
table.
• Modification(update) anomalies: occurs when updating
data for an entity in one place may lead to inconsistency,
with the existing redundant data in another place in the
table.
206
anomalies example(student relation )
Dep_code Dep_name Grade
Stid Name Course_code
Eit-m/ur3412/06 Lelisa Gutema Mu-Cs123 CS COMP2061 A
Eit-m/ur3612/06 Hagos G/Meskel Mu-Cs123 CS COMP2031 B+
Eit-m/ur 3112/06 Hayleab Tesfaye MU-Is7888 IS INYS2032 A
Eit-m/ur8112/06 Meresa G/Hawaria MU-Is456 IS INYS2031 A
Eit-m/ur5319/06 Meakuanint Gulema MU-SE789 SE SN2011 A
Eit-m/ur2218/06 Shewit Hagos MU-Is456 IS INSY2032 B

Eit-m/ur1213/06 Dejene Tolosa MU-Is456 IS INSY2031 A
Eit-m/ur3218/06 Yonas Hailemeskel MU-NU327 Nursing PH159 C
207
anomalies(example cont..)
• Insertion anomalies – can’t enter a new

student(register first year student) without having the
student take a course.
• Deletion anomalies – if student ‘Meakuanint Gulema’
is dismissed from campus, we lose information about
the existence of MU-SE789 dept
• Modification anomalies – changing department
code(Dep_code) of IS department leads to update of
the tuples of all Students who enrolled in IS
department 208
Why do update
anomalies(insertion/deletion and
modification) exist in student relation ?
• There are three entity types into one relation.
• Student
• Department and
• Course
• This results in duplication and an unnecessary
dependency between the entities.
• So,What is the solution?
• Decomposition
209
What is Decomposition?
• Breaking down a relational schema into

smaller and simpler relations that avoid
redundancy.
• The idea is to be able to query the smaller
relations for any information that we were
previously able to retrieve from the original
relational schema.
210
Decomposition(example)
Stud_id Name Dep_code
Eit-m/ur3412/06 Lelisa Gutema MU-CS123
C_code Grade Stud_id
Eit-m/ur 4112/06 Hayleab MU-Is456 COMP 2061 A Eit-m/ur3412/06
Tesfaye
Eit-m/ur2319/06 Meakuanint MU-SE789 INSY2032 A Eit-m/ur 3112/06
Gulema INSY 2031 A Eit-m/ur8112/06
Eit-m/ur2218/06 Shewit Hagos MU-Is456 SN2011 B Eit-m/ur5319/06
Eit-m/ur3218/06 Yonas MU-N327 COMP2031 B+ Eit-m/ur3612/06
Hailemeskel
Eit-m/ur1213/06 Dejene Tolosa MU-Is456 PH159 C Eit-m/ur3218/06
Eit-m/ur8112/06 Meresa MU-Is456
G/Hawaria
Dep_code Dep_name
MU-CS123 CS
MU-Is456 IS
MU-SE789 SE
MU-N327 Nursing 211
Functional Dependency and Normalization
• Functional Dependency is a type of constraint

in which the value of one attribute (the
determinant) determines the value of another
attribute.
• Given a relational schema R, with subset of

attributes A and B , we say that a functional
dependency A → B exists if the values in A
literally implies the values that B can hold for
any instance r of the relation R.
212
Functional Dependency and
Normalization(Example)
 FD can be understood as “A determines B”,“B is dependent
on A” or “A implies B” and denoted as “A → B”.
 If A1 → B1 , A2 → B2, A3 → B3 … An → Bn, then we
denote it as A1 A2 A3…. An → B1 B2 B3… Bn
 Example: consider the following relation R ( A, B, C, D ),
A B C D
a1 b1 c1 d1
a2 b2 c2 d1
a3 b3 c3 d1
a4 b3 c4 d2
 What are FD Exist in this relation?
213
Normalization(Example cont..)
• The possible FD exist
• A →B,A →C, A →D, {A,B} →C, {A,C} →B, {A,D}
→B
• A →{B,C}, A →{C,D}
• What about B→A?,D→A?
214
Normalization(goal of Normalization)
 Minimize data redundancy, thereby avoiding

anomalies.
 Make it easier data (insert, update, and delete)
 Provide a better design that is improved
representation of the real world and a stronger basis
for future growth.
215
Normalization(why Relations(tables) are
Normalized?
• Relations are normalized to ensure that:
• Collection of relations do not unnecessarily
hold duplicate data.
• When a data item is modified it is modified in
all relations where it appears -no inconsistency
is there.
• When data is deleted accidentally, required
data is not deleted
• Simplifies retrieval of required data.
216
Process of Normalization( Normal Forms
• What is Normal Forms?

• Condition using keys and FDs of a relation to
certify whether a relation schema is in a
particular normal form.
• It is the formal classifications used for
describing a relational database's level of
normalization.
• It is abbreviated as NF.
217
Functional Dependency and Normalization
(types of NF)
Steps in
normalization(NF)
218
First Normal Form(1NF)
• A relation is considered to be in first normal
form if
– No multivalued attributes
– Every attribute value is atomic
• All relations are in 1NF
219
In order to convert tables to First Normal
Form(1NF)
• Identify and Remove multivalued and

composite(if it is not in simple) attribute.
• Ensure Atomicity: Each attribute must contain a
single value, not a set of values.
220
First Normal Form(Example)
•Consider the following Employee1 Relation which store
information about employee and courses taken by
employees,
Employee 1
Emp_id Name Dept Salary CourseTitle DateCompleted
Mu-123/00 Behailu Economics 10,200 Java 10/04/01
OOSAD 23/04/01
Mu-623/02 Binyam CS 12,800 SAD 21/06/07
Mu-410/01 Behailu IS 8,340 DB 14/10/05

DSA 06/12/03
Is Employee1 relation is in 1NF? 221

First Normal Form(Example cont..)
• NO
• Convert Employee1 relation into 1NF
• Step 1:Identify and remove multivalued
attribute
– Course_title and date_completed
• Step 2:Ensure Atomicity
222
1NF Example (Removing Multivalued
attribute & Ensuring Atomicity)
Employee2
Mu-123/00 Behailu Economics 10,200 OOP 23/04/01
Mu-623/02 Binyam CS 12,800 SAD 26/08/07

Mu-410/01 Behailu IS 8,340 DB 14/10/05
Mu-410/01 Behailu IS 8,340 DSA 06/12/03
•We can say Employe2 relation is in 1NF
223
Second Normal Form (2NF)
• A relation is in second formal form when
• It is 1NF and
• Every non-key attribute is fully functionally dependent
on the ENTIRE primary key.
– No partial functional dependencies
• Fully FD:- if (X,Y) -> Z where removal of any attribute
from Y means the FD does not hold any more. or neither
X ->Z nor Y ->Z exist
• Partial FD: a FD in which one or more nonkey attributes
are functionally dependent on part (but not all) of the
primary key
– Given FD (X, Y) -> Z ,where there is some dependency from y -
> Z or X ->Z. 224
2NF(Fully FD and Partial FD example)
• What are FD exist in employee2 relation?

Mu-123/00 Behailu Economics 10,200 OOP 23/04/01
Mu-623/02 Binyam CS 12,800 SAD 26/08/07

Mu-410/01 Behailu IS 8,340 DB 14/10/05
Mu-410/01 Behailu IS 8,340 DSA 06/12/03
225
2NF(Functional Dependency in Employee2
example cont..)
FD1
EmpID CourseTitle Name Dept Salary DateCompleted
FD2
FD1:EmpID, CourseTitle  DateCompleted

Both FD are Partial FD
FD2:EmpID  Name, Dept, Salary
Therefore, NOT in 2nd Normal Form!!

226
Converting Employee2 relation to 2NF
• Step 1:Ensure that a relation is in 1NF

• Step2:ensure that every non key attribute must be
Fully dependent on key attribute.
Step 1: Employee2 relation is in 1NF? Yes

Step2:ensure Full FD.
• Descompose employee2 relation into two relations.
EMPLOYEE1 (Emp_ID, Name, Dept, Salary).
EMP_COURSE (Emp_ID, CourseTitle, Date_Completed)
227
Converting Employee2 relation to
2NF(cont..)
Decomposed into two separate relations
Both are full

EmpID Name Dept Salary functional
dependencies
EmpID CourseTitle DateCompleted
228
Third Normal Form(3NF)
• A relation is in 3NF when
– If it is in 2NF and
– No transitive dependencies exists,
• What is Transitive dependency?
• is a functional dependency between non-key
attributes.
• Example :R(A,B,C),
• FD1: A  B,
• FD2:B  C
• What is transitive dependency exist in Relation R?
TD:AC 229
Third Normal Form(example)
• Given the following Functional dependency, is
employee relation is in 3NF?
FD1:Empid Name,Dept,Salary
Employee1
Empid Name Dept Salary

Mu-123/00 Behailu Economics 10,200
Mu-623/02 Binyam CS 12,800
Mu-410/01 Behailu IS 8,340
230
Converting to Third Normal Form(example
cont..)
Step1:ensure that the relations are in 2NF.
Step2:remove if there is Transitive dependency.
Soln:-
Step1:is above relations are in 2NF? Yes
Step2:is there any transitive dependency b/n
attributes of relation? if so remove TD.
What are TD exist in Employee1 relation?
231
Converting to Third Normal Form(example
cont..)
Employee1
Empid Name Dept Salary
Mu-123/00 Behailu Economics 10,200
Mu-623/02 Binyam CS 12,800
Mu-410/01 Behailu IS 8,340
• Non key to non key FD in Employee1 relation

FD2:Dept Salary
So, Transitive dependency exist in Employee1 relation
Empid Dept Salary
232
Converting to Third Normal
Form(Removing Transitive dependency)
• In order to convert Employee1 relation to 3Nf,
– Decompose Employee1 relation to two relations
– Emp1(Empid, Name,Dept,)
– Emp_Dept(Dept,Salary)
• And make Dept attribute primary key in Emp_dept
relation and Foreign key in Emp1 relation
EmpID Name Dept
Dept Salary 233

Converting to Third Normal
Form(Removing Transitive dependency)
EMP 1 EMP_Dept
Empid Name Dept
Dept Salary
Mu-123/00 Behailu Economics
Economics 10,200
Mu-623/02 Binyam CS
CS 12,800
Mu-410/01 Behailu IS
IS 8,340
• Now, there are no transitive dependencies

Both relations are in 3rd NF
234
Types of Decomposition
• Lossless Decomposition
– Decomposition of a relation R into relations X and
Y is lossless, if no information from the original
relation is lost after the decomposition.
– In other words, the original relation can be
constructed back from the decomposed relations.
– Let R be a relation with functional dependency
R1 and R2 that is decomposed into R1 and R2.
Then the decomposition is lossless if
– R=R1 R2,where is natural join
235
Lossless Decomposition (Example)
But, now we can’t check A  B without doing a natural join!

236
Types of Decomposition(Lossy )
• Lossy Decomposition
– if a decomposition results in loss of information from
the original relation R then the decomposition is
lossy and is obviously not a desirable property.
– In other words, the original relation cannot be
constructed back from the decomposed relations.
– Let R be a relation with functional dependency R1
and R2 that is decomposed into R1 and R2. Then the
decomposition is lossy if
– R =R1 R2, where is natural join
237
Lossy Decomposition (example)
R R1 R2
238

Fundamentals of Database Systems - PPTX (Repaired)

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Fundamentals of Database Systems - PPTX (Repaired)

Uploaded by

Copyright:

Available Formats

Fundamentals of Database

Read chapter one

Accounts Buyer Inventory Vendor

Accounts Payable Sales Order Processing Payroll

• Concurrent access by multiple users.

• Insulation between programs and data(program-

Program Program Program

Back Inventory Customer Inventory Employee

Database System Architecture

• Terminologies: Data Abstraction, Data

• What is Data Abstraction?

• Three of four important characteristics of

• Since the design process is complicated, especially for

• It is a high-level graphical representation of the database

 Most of the basic entity types are classified as strong entity

• It frequently happens that there is an attribute that

(a) Simple key attribute

(a) Relationship type (Completes)

(a) Attribute on a relationship

 Relationship types usually have certain constraints that limit the

– Meaning that each department can be related to (that is,

 Is the maximum number of instances of an entity B

 In some situations an organisation may want to model more

Given the following information, develop E-R Diagram.

• Step 3:identify relationship types

• Concerning the Project:

9.We track the number of hours per week that an employee

1.Identify Entity Types

• Attributes of Each Entity Types

fname minit lname

ssn name sex birthdate relationship

name Depcode location project

department name Procode location

• Identify relationship type, Cardinality and Degree

• Between DEPARTMENT and PROJECT

fname minit lname 1

dependents of name procode location

name sex birthdate relationship

• Rift valley university has a large number of courses in its

• Step 2: Mapping of Weak Entity Types

• Step 5: Mapping of Binary M:N Relationship Types.

• Step 6: Mapping of Multivalued attributes.

Table Correspondence between ER and Relational Models

ER Model Relational Model

• The process of decomposing relations with

 Mixing attributes of multiple entities may cause

Eit-m/ur2218/06 Shewit Hagos MU-Is456 IS INSY2032 B

Eit-m/ur3218/06 Yonas Hailemeskel MU-NU327 Nursing PH159 C

• Insertion anomalies – can’t enter a new

• Breaking down a relational schema into

• Functional Dependency is a type of constraint

• Given a relational schema R, with subset of

• What about B→A?,D→A?

 Minimize data redundancy, thereby avoiding

• What is Normal Forms?

• Identify and Remove multivalued and

Mu-410/01 Behailu IS 8,340 DB 14/10/05

Is Employee1 relation is in 1NF? 221

Mu-623/02 Binyam CS 12,800 SAD 26/08/07

•We can say Employe2 relation is in 1NF

• What are FD exist in employee2 relation?

Mu-623/02 Binyam CS 12,800 SAD 26/08/07