Cours Database System
Cours Database System
Systems
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
Fundamentals of Database
Systems
Chapter One
Introduction to Database Systems
6
Outline
• Introduction
• File Organization vs. Database Approach
• Characteristics of the Database Approach
• Actors on the Scene
7
Reference(Text book)
8
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
9
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
10
Introduction: What is DBMS?
• a software package designed to store and
manage databases.
• a collection of programs that enables users to
create and maintain a database.
• Example:
– Ms Access
– My Sql
– Oracle
11
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.
12
Example: Database Systems Today(social
network)
13
Example: Database Systems
Today(Entertainment)
14
Example: Database Systems Today(Banking)
15
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
16
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
17
File Processing Systems(Example)
Billing Purchasing
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
18
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
19
Drawbacks of File based Approach(cont..)
A B C
Ordering
Invoicing Payroll
filing
System System
System
Single repository maintains data that is defined once and then accessed by various 23
users
Disadvantages of Using the Database
Approach
• Expensive
– hardware, software, personnel,
processing overhead, operating cost , etc.
• Increased vulnerability to failure
• Recovery is more complex
24
Actors on the Scene
• Database domain has several roles and career paths
associated with it.
25
Actors on the Scene(cont..)
• Database Administrator (DBA):
– responsible for
• authorizing access to the database,
• for coordinating and monitoring its use,
• acquiring software and hardware resources,
• controlling its use and monitoring efficiency of
operations.
26
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. 27
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.
28
CHAPTER TWO
29
Data Abstraction, Data Models, Schema and Instances
30
Categories of Data models
• High-level or Conceptual data models:
– Provide concept that are close to the way many users
perceive data.
– Example: entities, attributes, and relationships.
• Low-level or Physical data model:
– Provide concepts that describe the details of how
data is stored in the computer
• Example: how data is stored on the computer storage
media such as magnetic tape
31
Data Abstraction, Data Models, Schema and
Instances
• What is Database Schema?
• The description of a database.
• It Includes descriptions of the database structure and
the constraints that should hold on the database.
• What is Schema Diagram?
• A diagrammatic display of (some aspects of) a
database schema.
• What is Schema Construct?
• A component of the schema or an object within the
schema, e.g., STUDENT, COURSE.
32
Db Schema, schema diagram and schema
construct (Example)
33
Db Schema, schema diagram and schema
construct (Example)
34
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.
35
DBMS Architecture and Data Independence
36
Three-Schema Architecture(The ANSI-SPARC Architecture)
Old Modern
37
Three-Schema Architecture(The ANSI-SPARC
Architecture)
38
Three-Schema Architecture(The ANSI-SPARC
Architecture)
• Defines DBMS schemas at three levels:
– Internal schema
• at the internal level to describe physical storage structures
and access paths (e.g indexes).
– Conceptual schema
• at the conceptual level to describe the structure and
constraints for the whole database for a community of users.
• Example: describe entities, data types, relationships, user
operations, and constraints
– External schemas
• at the external level to describe the various user views.
39
Database Language and Interface
• Data definition language (DDL)
• Used by the DBA and database designers to
specify the conceptual schema of a database.
• In many DBMSs, the DDL is also used to define
internal and external schemas (views).
• Data manipulation language (DML)
• Used to specify database retrievals and updates.
40
Database Language(Data definition language (DDL))
41
Database Language(Data Manipulation
language (DML))
• Used to specify database retrievals and
updates.
• DML can be embedded in a general-purpose
programming language (host language), such as
COBOL, C or an Assembly Language.
• Alternatively, stand-alone DML commands can be
applied directly (query language).
42
Data Manipulation language:Two main types of DMLs
44
DBMS Interfaces(contd.)
• Forms-Based Interfaces
– A forms-based interface displays a form to each user.
– Users can fill out all of the form entries to insert new
data, or they can fill out only certain entries, retrieve
matching data.
• Graphical User Interfaces
– displays a schema to the user in diagrammatic form.
– The user then can specify a query by manipulating the
diagram.
– In many cases, GUIs utilize both menus and forms.
45
DBMS Interfaces(contd.)
• Natural Language Interfaces
– These interfaces accept requests written in english
or some other language and attempt to understand
them.
– A natural language interface usually has its own
schema, which is similar to the database conceptual
schema, as well as a dictionary of important words.
46
DBMS Interfaces(contd.)
• Speech Input and Output:
– Limited use of speech as an input query and
speech as an answer to a question or result of a
request is becoming commonplace.
– Applications with limited vocabularies such as
inquiries for telephone directory for input and
output to enable customers to access this
information.
47
DBMS Interfaces(contd.)
• Interfaces for Parametric Users:
– Parametric users, such as bank tellers, often have a small
set of operations that they must perform repeatedly.
• Interfaces for the DBA:
– Most database systems contain privileged commands
that can be used only by the DBA staff.
– These include commands for creating accounts, setting
system parameters, granting account authorization,
changing a schema, and reorganizing the storage
structures of a database.
48
Classification of DBMS
• Several criteria are normally used to classify DBMSs.
• Data model:
– relational, object, object-relational, hierarchical,
network, and other.
• Number of users supported by the system
– Single-user systems and Multiuser systems.
– Single-user systems support only one user at a time and
are mostly used with PCs.
– Multiuser systems, which include the majority of DBMSs,
support concurrent multiple users.
49
Classification of DBMS(contd.)
• Number of sites over which the database is
distributed
– centralized, distributed DBMS (DDBMS) ,Homogeneous
DDBMSs, Heterogeneous DDBMSs
– A DBMS is centralized if the data is stored at a single
computer site.
– A centralized DBMS can support multiple users, but the
DBMS and the database reside totally at a single
computer site.
50
Classification of DBMS(contd.)
• A distributed DBMS (DDBMS) can have the actual database and
DBMS software distributed over many sites, connected by a
computer network.
• Homogeneous DDBMSs use the same DBMS software at all the
sites, whereas heterogeneous DDBMSs can use different DBMS
software at each site.
• Cost of the DBMS:
– It is difficult to propose a classification of DBMSs based
on cost.
– Today we have open source (free) DBMS products like
MySQL.
51
Chapter Three
Database Modeling
52
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
53
Database Design Principles
54
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.
55
Database Design Principles:Hierarchical
Model(cont..)
56
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
57
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.
58
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
59
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.
60
Relational Data model(Example)
61
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.
62
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
63
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
64
Database Design
65
Database design(contd.)
66
What is Conceptual database design?
68
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.
69
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.
70
Sample E-R Diagram
71
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,
72
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.
73
Entity Types: Strong versus Weak entity type
74
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.
75
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
76
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
77
A composite attribute
78
Single-Valued versus Multivalued Attribute
79
Entity with a multivalued attribute (Skill) and derived
attribute (Years_Employed)
80
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.
81
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
82
Simple and composite key attributes
83
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
84
(b) Composite key attribute
85
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
86
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.
87
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
88
Relationship types and instances
89
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
90
(b) Relationship instances
91
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’
92
An associative entity
93
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
94
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
95
(b) An associative entity (CERTIFICATE)
96
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
97
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
98
Unary relationship(cont..)
Relationships could be mapped from one
entity to itself.
Manager_Of
1
Employee Manages
N
Subordinate_To
99
Unary relationship(cont..)
100
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
101
Binary relationships(cont..)
N 1
Lives_In
Person City
Is_Born_In
N 1
102
Binary relationships(cont..)
103
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
104
Ternary relationships
105
Ternary relationships(cont..)
106
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
107
Structural Constraints: Cardinality and
Participation constraints
108
Structural Constraints: Cardinality and
Participation constraints(cont..)
109
Structural Constraints: Cardinality and
Participation constraints(cont..)
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.
110
Structural Constraints: Cardinality ratio and
Participation constraints(cont..)
• For example,
– in the WORKS_FOR binary relationship type,
• DEPARTMENT:EMPLOYEE is of cardinality ratio 1:N
111
Structural Constraints: Cardinality and
Participation constraints(cont..)
• 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.
112
Structural Constraints: Cardinality and
Participation constraints(cont..)
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.
113
Structural Constraints: Cardinality
and Participation constraints(cont..)
114
Structural Constraints: Cardinality
and Participation constraints(cont..)
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
115
Structural Constraints: Cardinality
and Participation constraints(cont..)
116
Structural Constraints: Cardinality
and Participation constraints(cont..)
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
117
Structural Constraints: Cardinality
and Participation constraints(cont..)
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 .
118
Structural Constraints: Cardinality
and Participation constraints(cont..)
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.
119
Structural Constraints: Cardinality
and Participation constraints(cont..)
120
Structural Constraints: Cardinality
and Participation constraints(cont..)
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 121
Structural Constraints: Cardinality
and Participation constraints(cont..)
122
Structural Constraints: Cardinality
and Participation constraints(cont..)
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.
123
Structural Constraints: Cardinality
and Participation constraints(cont..)
124
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?
125
Minimum Cardinality(cont..)
126
Maximum cardinality
127
Maximum cardinality(cont..)
128
Multiple relationships
129
(b) Professors and courses (fixed upon constraint)
130
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. 131
Summary of ER model notation
132
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.
133
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.
134
Developing E-R Diagram(cont..)
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
135
Developing E-R Diagram(cont..)
136
Developing E-R Diagram(cont..)
137
Developing E-R Diagram(cont..)
The entity Types:
EMPLOYEE DEPENDENT
DEPARTMENT
PROJECT
138
Developing E-R Diagram(cont..)
139
Developing E-R Diagram(cont..)
Entities with attributes:
address salary
dependent
name sex
140
Developing E-R Diagram(cont..)
141
Developing E-R Diagram(cont..)
143
Developing E-R Diagram(cont..)
Between PROJECT and EMPLOYEE
Employee works on several Projects
• Degree: Binary
• Cardinality ratio: M:N
• Participation: total
A Project contains several Employees
• Degree: Binary
• Cardinality ratio: N:M
• Participation: total
144
Developing E-R Diagram(cont..)
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
• Cardinality ratio: 1:N
• Participation: partial
• A Dependent is dependent on Employee
• Degree: Binary
• Cardinality ratio: N:1
• Participation: Total
145
Developing E-R Diagram(cont..)
• EMPLOYEE to EMPLOYEE
• An Employee is supervisor of several Employees
• Degree: Unary
• Cardinality ratio: 1:N
• Participation: Partial
Employees supervised by an Employee
• Degree: Unary
• Cardinality ratio: N:1
• Participation: Partial
146
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
147
The final E-R Diagram
name Depcode location
dependent
148
Example developing ER-Diagram
149
Developing E-R Diagram(cont..)
• Solution
– Identify entity types
• Student
• Course
– Attributes of each entity type
– Student
• Id
• Name
• Age
• DOP
• GPA
• Dept.
150
Cont…
151