Chapter 3 Database Modeling short slide.pdf

University of Gondar College of Informatics By Getnet T, Misganaw A, and Agereselam D.
College of Informatics
Department of Computer Science
Fundamentals of Database Systems
Chapter 3: Database Modeling Lecture Notes
University of Gondar

Entity-Relationships (ER) Model
An Entity Relationship (ER) Diagram
 A flowchart that illustrates how different “entities” are related to each other
within a system. They are used to design or debug relational databases in
the fields of SE, business IS, education and research
 They are also known as ERDs or ER Models.
 They used defined set of Symbols such as rectangles, diamonds, ovals and
connecting lines to depict the interconnectedness of entities, relationships
and their attributes

Entity, attribute, and Keys
An Entity
 Are a real world thing either living or non living that is easily recognizable and
no recognizable.
 It can be a place , person, object, event, or a concept which stores data in the
database
 The characteristics of entities are must have an attribute and unique key
An entity set
 It is a set of entities of the same type that share the same properties, or
attributes
 The set of all persons who are customers at a given bank, for example, can be
defined as the entity set customer
 Entity sets do not need to be disjoint
 E.g. Person: employee, student, patient
Place : store, building
Object: sale, registration, renewal
Concepts: account, course

An Entity Types
 Entities with the same basic attributes are grouped or typed into an entity type.
 For example, the entity type EMPLOYEE and PROJECT
Displaying an Entity Type
 In ER diagrams, an entity type is displayed in a rectangular box.
Weak Entity
 An entity set may not have sufficient attributes to form a primary key
 An entity that does not have a key attribute
 Aweak entity must participate in an identifying relationship type with an owner or
identifying entity type
 an entity that cannot exist without the entity with which it has a relationship
Strong Entity
 an entity which doesn’t rely on any other entity for its existence

Attributes
 Attributes are pieces of informationABOUT entities
 Attributes are displayed in ovals /ellipse
 Each attribute is connected to its entity type.
 Components of a composite attribute are connected to the oval representing
the composite attribute
 Each key attribute is underlined
 Multivalued attributes displayed in double ovals
 E.g.: an EMPLOYEE entity may have the attributes Name, SSN, Address, Sex,
BirthDate
Types of attribute
 Simple / Atomic
 Each entity has a single atomic value for the attribute. For example, SSN or Sex
 Composite: divided into sup parts
 The attribute may be composed of several components.
 e.g. Address (Apt#, House#, Street, City, State, ZipCode, Country), or
 Name (FirstName, MiddleName, LastName).

Multi-valued Attributes
 An entity may have multiple values for that attribute. For example, Color of a CAR or
PreviousDegrees of a STUDENT.
 Denoted as {Color} or {PreviousDegrees}.
Stored vs Derived attribute
 Stored: not possible to derive or compute
 E.g. Name,Address
 Derived:The value may be derived (computed) from the values of other attributes.
 E.g. G.P.A(grade point/credit hours), age (birth date –current date )
 NullValues
 NULL applies to attributes which are not applicable or which do not have values.
(eg. Middle name )
 You may enter the value NA(meaning not applicable)
 Value of a key attribute cannot be null.
 Default value - assumed value if no explicit value

Key Attributes
 An attribute of an entity type for which each entity must have a unique value is called a
key attribute of the entity type .
e.g. For example, SSN of EMPLOYEE
 Akey attribute may be composite
VehicleTagNumber is a key of the CAR entity type with components (Number, State).
 An entity type may have more than one key
 Each key is underlined
Types of Keys
 Super Key: A Super Key is an attribute or set of attributes that are taken collectively
and can identify all other tuples uniquely.
 Candidate Key: are a super key which are not having any redundant attributes. In
other words candidate keys are minimal super keys. (unique and irreducible)

Types of Keys continued
 Primary Key: the candidate key that is selected to identify tuples uniquely within
the relation.
oThe entire set of attributes in a relation can be considered as a primary case in a worst
case.
 Alternate Keys is a column or group of columns in a table that uniquely identify
every row in that table. A table can have multiple choices for a primary key but
only one can be set as the primary key. All the keys which are not primary key are
called an Alternate Key.
 Foreign Key is a column that creates a relationship between two tables. The
purpose of Foreign keys is to maintain data integrity and allow navigation between
two different instances of an entity. It acts as a cross-reference between two
tables as it references the primary key of another table.

Relationships,Associations, and Constraints
Relationship and Relationship types
 A relationship relates two or more distinct entities with a specific meaning.
 Is a meaningful associations between tables
For example, EMPLOYEE John Smith works on the ProductX PROJECT,
or EMPLOYEE Franklin Wong manages the Research DEPARTMENT.

Degree of a Relationship types
 It is the number of participating entity types or it represents the number of
entity types that are associated with a relationship.
Data Types
Types of Degree
 Now, based on the number of linked entity types, we have 4 types of degrees
of relationships
1. unary/recursive
2. Binary
3. Ternary
4. N-ary

Types of Degree
Data Types
Unary/ Recursive (Degree 1)
 both the associating entity types are the same.
 It is a relationship type where the same entity type participates more than once
in a different role
 E.g. In a particular class, we have many students, there are monitors too. So,
here class monitors are also students. Thus, we can say that only students are
participating here. So the degree of such type of relationship is 1

Types of Degree
Data Types
Binary (Degree 2)
 Tuples/records of two entities are associated in a relationship
 There are two types of entity associates
 Example: We have two entity types ‘Student’ and ‘ID’ where each ‘Student’
has his ‘ID’. So, here two entity types are associating we can say it is a binary
relationship. Also, one ‘Father’ can have many ‘daughters’ but each ‘daughter’
should belong to only one ‘father. We can say that it is a one-to-many binary
relationship

Types of Degree
Data Types
Ternary (Degree 3)
 Tuples/records of three different entities are associated
 There are three types of entity associates
 Example: We have three entity types ‘Teacher’, ‘Course’, and ‘Class’. The
relationship between these entities is defined as the teacher teaching a
particular course, also the teacher teaches a particular class. So, here three
entity types are associating we can say it is a ternary relationship

Types of Degree
Data Types
N-ary (N- Degree)
 Tuples from arbitrary number of entity sets are participating in a relationship
 there are n types of entity that associates
 It is very hard to convert into an entity relation table
 We have 5 entities Teacher, Class, Location, Salary, Course. So, here five entity
types are associating we can say an n-ary relationship is 5

Role
 It Indicates the purpose that each participating entity type plays in a relationship
 E.g. prerequisite, requester
 Role can be used when two entities are associated through more than one
relationship to classify the purpose of each relationship.

Relationship type
 Is the schema description of a relationship
 Identifies the relationship name and the participating entity
types
 Also identifies certain relationship constraint
Relationship Set
 The current set of relationship instances represented in the
database
 The current state of a relationship type
Constraint on relationship types
 Cardinality Ratio (specifies maximum participation)
 Existence Dependency Constraint (specifies minimum participation) (also called participation
constraint)

Cardinality Ratio
 the actual number of related occurrences for each of the two entities
 is the number of entity instances to which another entity set can map
under the relationship.
 The cardinality is the number of occurrences in one entity which are
associated to the number of occurrences in another.
 Types of cardinality in between tables are:
 One-to-one
 One-to-many
 Many-to-one
 Many-to-many
One-to-one (1:1)
 one tuple is associated with only
one other tuple
 X-Y is 1:1 when each entity in X is
associated with at most one entity
in Y, and each entity in Y is
associated with at most one entity
in X.
 E.g building - location

Cardinality Ratio
One-to-Many (1:M)
 one tuple can be associated with
many other tuples, but not the
reverse
 E.g. staff-doctors (As one staff can have
multiple doctors
Many – to – one (M:1)
 Many tuples are associated with
one tuple but not the reverse
 E.g. patient – Doctors: (many
Patients are examined by one doctor )

Cardinality Ratio
Many-to-Many (M:M)
 one tuple is associated with
many other tuples and from the
other side, with a different role
name one tuple will be associated
with many tuples
 E.g. medicines– patients (many
medicines can be taken by many
patients.)

Constraints

Example
• Example
• A university consists of a number of departments. Each department
offers several courses. A number of modules make up each course.
Students enrol in a particular course and take modules towards the
completion of that course. Each module is taught by a lecturer from
the appropriate department, and each lecturer tutors a group of
students.
Entity
• A university consists of a number of departments. Each
department offers several courses. A number of modules make up
each course. Students enrol in a particular course and take modules
towards the completion of that course. Each module is taught by a
lecturer from the appropriate department, and each lecturer tutors a
group of students

Example
Example – Relationships Types
A university consists of a number of departments. Each
department offers several courses. A number of modules
make up each course. Students enrol in a particular course
and take modules towards the completion of that course. Each
module is taught by a lecturer from the appropriate
department, and each lecturer tutors a group of students

Example
Module
Course
Department
Student
Lecturer
• Entities: Department, Course, Module, Lecturer, Student

Example
Module
Course
Department
Student
Lecturer
Offers

Example
A number of modules make up each courses
Module
Course
Department
Student
Lecturer
Includes
Offers

Example
Module
Course
Department
Student
Lecturer
Includes
Offers
Enrols In
Module
Students enrol in a particular course

Example
• Students … take modules
Module
Course
Department
Student
Lecturer
Includes
Offers
Enrols In
Takes

Example
Each module is taught by a lecturer
Module
Course
Department
Student
Lecturer
Includes
Offers
Enrols In
Takes
Lecturer
Teaches

Example
• a lecturer from the appropriate department
Module
Course
Student
Lecturer
Includes
Offers
Enrols In
Takes
Employs
Teaches
Department

Example
• each lecturer tutors a group of students
Module
Course
Department
Student
Lecturer
Includes
Offers
Tutors
Enrols In
Takes
Employs
Teaches

Example
E/R diagram
Module
Course
Department
Student
Lecturer
Includes
Offers
Tutors
Enrols In
Takes
Employs
Teaches

Existence Dependency Constraint
 Existence Dependency Constraint (specifies minimum participation) (also called
participation constraint)
 denotes whether the existence of an entity instance is dependent upon the existence of
another, related, entity instance
 Any instance of one entity might participate in a relationship with another
entity, but this is not compulsory
 every instance of one entity must participate in a relationship with another
entity.
zero (optional participation, not existence-dependent)
 one or more (mandatory participation, existence-dependent)

Participation constraint
 Total participation
 Total participation is where an entity must participate in a relationship to exist
 Partial participation
 Partial (optional) participation is where the entity can exist without participating in
a relationship with another entity

Relational Constraints/Integrity Rules and keys:
 Each row of a table is uniquely identified by a PRIMARY KEY
 A primary key in E/R model is represented by underlining the attribute or set
of attributes.
 A column or combination of columns that matches the primary key of another
table is called a FOREIGN KEY which is used to cross-reference tables.
 It states that no component of the primary key may contain a NULL value.
 for every foreign key value in a table there must be a corresponding primary
key value in another table in the database.
 are requirements on an attribute value to be in a specified range of values.
Entity Integrity Rule of the Model
Referential Integrity Rule
Domain constraints integrity rule

Attributes of a relationship types
For example, HoursPerWeek of WORKS_ON
Its value for each relationship instance describes the number of
hours per week that an EMPLOYEE works on a PROJECT.
Most relationship attributes are used with M:N relationships
 In 1:N relationships, they can be transferred to the entity
type on the N-side of the relationship
A relationship type can have attributes:
A value of HoursPerWeek depends on a particular
(employee, project) combination

Recursive Relationship type is supervision

Summary of notation for ER diagrams

Enhanced Entity Relationship (EER) model

Exercise
Build an ER dia5
g
7
ram for the following information
Solution
 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, GP
Aand
 Course will have an Id, Name, Credit Hours
 Whenever a student enroll in a course in a specific Academic Year and Semester, the
Student will have a grade for the course

Exercise
Build an ER dia5
g
7
ram for the following information
 “A football club has a name and a ground and is made up of
players.
 Aplayer can play for only one club and a manager, represented by his name manages a
club.
 Afootballer has a registration number, name and age. Aclub manager
also buys players.
 Each club plays against each other club in the league and matches have a date, venue
and score.”

Exercise
Solution

Mapping ER- Models to RelationalTables
Three basic rules to convert ER into tables or relations
Rule one: Mapping of Entity
 Entity Names will be automatically be table name
Rule two: Mapping of Attributes
 attributes will be columns of the respective tables.
 Atomic or single-valued or derived or stored attributes will be column
 Composite attributes: the parent attribute will be ignored and the
decomposed attributes (child attributes) will be columns of the table
 Multi-valued attributes: will be mapped to a new table where the primary key
of the main table will be posted for cross referencing
Rule three: Mapping of Relationships
 relationship will be mapped by using a foreign key attribute. Foreign key is a
primary or candidate key of one relation used to create association between tables

Rule three: mapping of relationship continued
A. For a relationship with one-to-one cardinality
 Post the primary key or candidate key of the table into the other as a
foreign key.
 In case where one entity is having partial participation on the relationship,
it is recommended to post the candidate key of the partial participants to
the total participants so as to save memory location due to null values on
the foreign key attribute.
B. For a relationship with one-to-many cardinality
 Post the primary key or candidate key from the –one side as a foreign key
attribute to the –many side..
 Example: for a relationship called –Belongs Tobetween Employee (Many) and
Department (one) the primary or candidate key of the one side, which is
Department, should be posted to the many side, which is Employee table.

Rule three: mapping of relationship continued
C. For a relationship with Many-to-many cardinality
 For a relationships having Many-to-many cardinality, one has to create a new
table and Post the primary key or candidate key from the participant entity as
a foreign key attribute in the new table along with some additional attributes (if
applicable)

Example: convert the following ER diagram to relational table

Example: solution
Mapping Employee entity
 There will be Employee table with Fname, Minit, Lname, SSN, Bdate,
Address, Sex and Salary being the columns.
 The composite attribute Name will be ignored.
 the Telephone attribute will be a new table as it is multi-valued

Example: solution
Mapping Department entity
 There will be Department table with Dname, Dnumber, and Dlocation (is
multi valued)

Example: solution
Mapping Project entity
 There will be Project table with Pnumber, Pname, and dnum being the
columns
Mapping Dependent entity

Example: solution
Final converted Relational table

End of Chapter Three
Thank You

Chapter 3 Database Modeling short slide.pdf

More Related Content

Similar to Chapter 3 Database Modeling short slide.pdf (20)

More from Getnet Tigabie Askale -(GM) (20)

Recently uploaded (20)

Chapter 3 Database Modeling short slide.pdf