1. ENTITY RELATIONSHIP MODELLING
TOPIC 2
DATABASE MODELS
&
INTRODUCTION TO
ENTITY RELATIONSHIP MODELLING
Dr. Wenny Rahayu
Readings : Chpts 5 & 3 Elmasri & Navathe

2. Data Model
A Data Model is a set of concepts that can be used to describe the structure of a database.
By structure of a database, we mean the data types, relationships, and constraints that should hold for the data.
Existing database models:
Hierarchical model : Represents the data in a database with a tree
structure consisting of progressive parent-child relations.
Network model : Represents the data in a database as interconnected
nodes
Relational model : represents the data in a database as a
collection of relations / tables
Object-Oriented model: represents the data, as well as operations, in
a database
In this lecture, we will focus on the most prominent data model: the Relational model. More than 90% of current database applications are built on relational database systems which utilise the relational model as their underlying data model.
Topic 2 : Database Models

3. Relational Model Introduced by C F Codd in 1970
The most widely used database model
Simple and uniform data model
Rests on a firm mathematical foundation (Relational Algebra)
Topic 2 : Database Models

4. Relational Model a) Data Structure (structural part)
There are 3 major aspects of a relational data model
a) Data Structure (structural part)
Consists of n-ary two dimensional (attributes, tuples) tables/relations whose attributes’ domains are of atomic types.
b) Data Integrity (integrity part):
Consists of two general integrity rules, namely entity integrity and referential integrity.
c) Data Manipulation (manipulative part):
Consists of a set of algebraic operators for data manipulations.
(This will be discussed in Topic 5)
Topic 2 : Database Models

5. A. Data Structure

6. Example: Tram Database
Data Structure
Example: Tram Database
Many different types of data are involved in running trams.
Vehicle: number, type, capacity, status, maintenance record, current depot, . . .
Route: number, start, end, tracks, . . .
Track: streets, sections, . . .
Driver: name, rating, personal details, . . .
Shift: driver, tram, route, times, . . .
Timetable: routes and times

7. The tram database as relations (simplified)
Data Structure
The tram database as relations (simplified)
VEHICLE
ROUTE
No.
Type
Seats
181 W 66
182 64
622 LR
102
No.
Start
End 69
Hawthorn
St Kilda 75
City
East Burwood 48
Pt Melbourne
North Balwyn
DRIVER
SHIFT
Name
Rating
Adams A1
Bernard C1
Driver
Route
Tram
Day
Bernard 69
181
Wed
Thu
Adams 48
622

8. Data Structure
The Tram Database
Information about each kind of thing is presented as a table. These tables need more columns to be realistic.
Some consistency rules apply, for example:
Suburb entries should be valid suburbs, Day entries should be days of the week, . . .
It is implicit that driver names are unique, or the data won't make sense.
A tram entry in the Shift table should correspond to a row in the Vehicle table.

9. Data Structure
The relational model is based on three fundamental concepts derived from set theory.
(1) Domains :
To define the original sets of data values used to model data. E.g. The domain of day shift is the set of all possible days : {Mon, Tue, Wed …}, the domain of salary is the set of all floating-point numbers greater than 0 and less than 200,000 (say).
(2) Relation :
A subset of the Cartesian product of a list of domains characterised by a name. A relation is composed of tuples. These are represented by the rows in a table.
Each tuple must have a primary key which can uniquely identify the tuple.
(3) Attribute :
A column of a relation designated by name. The name associated should be meaningful.
Topic 2 : Database Models

10. Data Structure
Keys
It is often desirable to extract a particular tuple from a relation. For example, with a bank database each client wants the balance of a particular account. That is, there must be some way of uniquely identifying each tuple. This is usually achieved by defining some attribute to be a key, or unique label. In the “tram” database, the route number is a key - different routes have different numbers. In banks, each account number is a key. Name and address is not a key - there can be more than one person of the same name at the same address. Keys are by definition unique, so no two tuples have the same key. More generally, a set of attributes can be a key. For example, {Start, End} is a key for Route.
Topic 2 : Database Models

11. Data Structure Primary keys The “tram” model can be now be written:
Vehicle(No., Type, Seats)
Route(No., Start, End)
Driver(Name, Rating)
Shift(Driver, Route, Tram, Day)
The attributes that make up the keys are
underlined.
Primary Key
VEHICLE
No.
Type
Seats
181 W 66
182 64
622 LR
102
Topic 2 : Database Models

12. Foreign Keys Data Structure
Attribute values for one relation can be drawn from another relation.
For example, Shift:Tram values must be from Vehicle:No. (but not vice versa – vehicles are not necessarily scheduled to a shift).
Shift:Tram is an example of a foreign key.
Foreign Key
VEHICLE
SHIFT
No.
Type
Seats
181 W 66
182 64
622 LR
102
Driver
Route
Tram
Day
Bernard 69
181
Wed
Thu
Adams 48
622
Topic 2 : Database Models

13. B. Data Integrity
Topic 2 : Database Models

14. Data Integrity
The data models in application systems need to include certain integrity rules with the purpose of reflecting the reality of certain constraints in the real world.
Most of the integrity rules are specific, in the sense that they apply to one specific application only. For example, a Student ID must be an integer and not null.
Two integrity rules are applicable to any application: The Entity and Referential integrity constraints.
Topic 2 : Database Models

15. Data Integrity Entity Integrity Constraint: Primary Key
no primary key value can be null
the primary key must not be duplicated
Primary Key
VEHICLE
No.
Type
Seats
181 W 66
182 64
622 LR
102
Topic 2 : Database Models

16. Data Integrity Referential Integrity Constraint:
A constraint that is specified between two relations and is used to maintain consistency among tuples of the two relations.
Ensuring Referential Integrity is done by defining the columns that uniquely identify table rows (primary key) and columns within the table which refer to other tables (foreign key). Appropriate actions should be taken by the system if the referenced row is deleted/updated.
Foreign Key
VEHICLE
SHIFT
No.
Type
Seats
181 W 66
182 64
622 LR
102
Driver
Route
Tram
Day
Bernard 69
181
Wed
Thu
Adams 48
622
Topic 2 : Database Models

17. Data Integrity Referential Integrity Constraint (cont..)
On update or delete of the target of a foreign key reference (using the vehicle-shift example), an attempt to update / delete a vehicle for which there exists at least one matching shift can be dealt with in the following ways:
CASCADE: The update / delete operation cascades to those matching shifts also.
RESTRICTED: The update / delete operation is restricted to the case where there are no such matching shifts (it is rejected otherwise).
NULLIFIES: The foreign key is set to null in all such matching shifts and the vehicle is then updated / deleted.
Topic 2 : Database Models

18. Data Integrity Referential Integrity Constraint (Example) –
when to Cascade, Restrict or Nullify?
LECTURER
DEPARTMENT
Topic 2 : Database Models

19. ENTITY RELATIONSHIP MODEL
DATABASE MODELLING
USING
ENTITY RELATIONSHIP MODEL
[E-R MODEL]

20. Database Design ANALYSIS Problem Domain DESIGN IMPLEMENTATION TOPIC 2
The Process of Database Design
Problem
Domain
ANALYSIS
Data Modeling
(eg. Using E-R Model
TOPIC 3
DESIGN
Relational Logical
Model
IMPLEMENTATION
Relational
DBMS
TOPIC 6
TOPIC 7

21. Database Design The Process of Database Design
In previous lectures, we have discussed:
The Relational Model which is the foundation of Relational DBMS,
Data Structure and Data Integrity
The problem that we haven’t solved :
Given a problem description:
How do we know what tables and how many tables need to be
implemented ?
How do we establish the relationships / connections among
the tables ?
We will solve the above problems using a data modelling technique called
E-R Modelling.

22. ER Model
The ER model is well­suited to data modelling for databases.
It is fairly abstract, and is easy to discuss and explain.
ER models are readily translated to relations.
ER modelling is based on two concepts:
Entities, that is, things.
Relationships, that is, associations or interactions between entities.
ER models (or ER schemas) are represented by ER diagrams.

23. Entities and Attributes
A central element of the ER model is the concept of an entity, which is usually an object or event in the real world: an employee, subject, account, video, receipt, public holiday, …
An entity is represented by a name in a box.
EMPLOYEE
SUBJECT
ACCOUNT

24. Entities and Attributes
Each entity is associated with a set of attributes that describe it. For example, in a chain of video shops an employee has a name, address, age, and salary.
EMPLOYEE
salary
name
address
age
Each attribute is represented by an oval and is associated with a domain of legal values.

25. Entities and Attributes
A particular entity, or instance of an entity, has a value for each of its attributes.
Thus some employee entity might have name “Fred”, address “Clayton”, and so on.
These values are not the entity itself, but they do identify the entity: they are values that can correspond to one item in the real world.
Primary Key attribute (which uniquely identifies an entity) is indicated by underlining.

26. Types of Attributes SIMPLE or ATOMIC Attributes
eg: “Database”; “3083”; “Bundoora”
COMPOSITE Attributes
eg: Address may consist of Number, Street, and Suburb
“5”+ “Plenty Road”+ “Bundoora”
MULTIVALUED Attributes
eg: Degrees of a person : “BCS”, “MIT”, “PhD”
DERIVED Attributes
eg: Derived a person’s age from attribute date of birth

27. Composite Attributes
Most attributes are atomic, or simple eg. name, age, salary. Attributes can be composite; eg. address has several components.
EMPLOYEE
salary
name
age
address
number
street
suburb

28. Multi-Valued Attributes
Most attributes are single­valued.
Attributes can be multi­valued; a video can have several actors, for example. Multi­valued attributes are represented with a double oval.
name
actors
VIDEO
number
studio

29. Association between two (or more) entities.
Relationships
Association between two (or more) entities.
primary key
Relationship
ENTITY
ENTITY
attribute
attribute

30. Degree of Relationship
SUBJECT
prerequisite N M
UNARY
One entity set, recursive.
Example
BINARY
STUDENT
SUBJECT
enrols in M N
Two entity sets linked (mostly used).
TERNARY
RENTAL SHOP
VIDEO
owns M N
BORROWER 1
Three entity sets linked.

31. Attributes of Relationships
result
enrols in
name
title N ID M
SUBJECT
STUDENT
code
address
Relationships can have attributes.

32. Constraints on Relationships
CARDINALITY
The number of entity instances in a relationship instance consist of three types.
1 TO 1 : one-to-one association
1 TO N : one-to-many association
M TO N : many-to-many association
It is sometimes necessary to use a more precise method in expressing cardinality.
An alternative notation is to use a pair of integer numbers (min, max) with each participation of an entity in a relationship, where
0  min  max, and
max  1
(0,N)
teach
(1,1)
LECTURER
SUBJECT N 1

33. Participation
To specify whether the existence of an entity depends on its being associated with another entity via the relationship.
Two Types
1. TOTAL Participation
The existence of an entity is totally dependent on the other entity.
2. PARTIAL Participation
The existence of an entity is partially dependent on the other entity.
Example
LECTURER
SUBJECT
teach 1 N
(0,N)
(1,1)
PARTIAL
TOTAL

34. Weak Entity
Existence depends on the existence of one or more other entities.
Primary key partially or totally derived from the ‘owner’ entity.
In the following example, EMPLOYEE is the ‘owner’ entity, and
DEPENDENT is the weak entity.
Note that both the weak entity and the relationship between the
weak entity and the ‘owner’ entity are represented using double -
lined rectangular/diamond.
Example
employee no
employee no
dependent name
has
(0,N)
(1,1)
EMPLOYEE
DEPENDENT 1 N

35. E-R Diagram The steps to draw an E-R diagram
Identify entities in the required system
Represent the entities graphically by a rectangle.
Entity
Name
Search for relationships between the entities and represent them graphically by a diamond.
( Note : Check for unary, binary OR ternary relationships).
Relationship
name

36. E-R Diagram Identify constraints on relationships
Cardinality : Use 1, N or M and (min, max)
Participation : Total Participation is shown with double lines, Partial
participation is shown with a single line.
Total
Partial
Identify all attributes, underline primary key attributes.

37. E-R Diagram
Properties are rented by tenants. Each tenant is assigned a unique number by the agency. Data held about each tenant includes family name, first name, contact address, phone number and property rented. A tenant may rent more than one property at any given time.
Properties are owned by owners. Each property is assigned a unique building number. The agency only encourages a single owner for any of the properties it handles. The owner, address and value are recorded for each property. In addition, the lease period and bond, are recorded for each property rented. An owner may own several properties.
Regular property maintenance is also recorded. The property, date, type of maintenance and cost are stored. Maintenance costs are charged to the property owner.
Tenants pay accounts to the agency for each property they rent. These consists of date of payment, tenant, property, type of account (rental, Bond or damage) and the amount.

38. E-R Diagram
Properties are rented by tenants. Each tenant is assigned a unique number by the agency. Data held about each tenant includes family name, first name, contact address, phone number and property rented. A tenant may rent more than one property at any given time.
Properties are owned by owners. Each property is assigned a unique building number. The agency only encourages a single owner for any of the properties it handles. The owner, address and value are recorded for each property. In addition, the lease period and bond, are recorded for each property rented. An owner may own several properties.
Regular property maintenance is also recorded. The property, date, type of maintenance and cost are stored. Maintenance costs are charged to the property owner.
Tenants pay accounts to the agency for each property they rent. These consists of date of payment, tenant, property, type of account (rental, Bond or damage) and the amount.

39. E-R Diagram Solution

40. Relational Database Design
Next Lecture …
Relational Database Design
Readings : Chpts 3 & 7, Elmasri & Navathe