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

DATADATABASEBASE MODEL MODELSS&&

INTRODUCTION TO INTRODUCTION TO ENTITY RELATIONSHIP MODELLINGENTITY RELATIONSHIP MODELLING

Dr. Wenny RahayuDr. Wenny Rahayu

Readings : Chpts 5 & 3 Elmasri & Navathe

Data ModelData ModelData ModelData 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.

Topic 2 : Database Models

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.


Relational ModelRelational ModelRelational ModelRelational 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)

There are 3 major aspects of a relational data model

a) a) Data Structure (structural part)

Consists of n-ary two dimensional (attributes, tuples) tables/relations whose attributes’ domains are of atomic types.

Relational ModelRelational ModelRelational ModelRelational Model

b) b) Data Integrity (integrity part):

Consists of two general integrity rules, namely entity integrity and referential integrity.

c) c) Data Manipulation (manipulative part):

Consists of a set of algebraic operators for data manipulations.

(This will be discussed in Topic 5)


A. A. Data StructureData StructureA. A. Data StructureData 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

Data StructureData StructureData StructureData Structure


No. Type Seats

181 W 66

182 W 64

622 LR 102

No. Start End

69 Hawthorn St Kilda

75 City East Burwood

48 Pt Melbourne North Balwyn

Name Rating

Adams A1

Bernard C1

Driver Route Tram Day

Bernard 69 181 Wed

Bernard 69 181 Thu

Adams 48 622 Thu

The tram database as relations (simplified)

VEHICLE ROUTE

DRIVER SHIFT


• 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.



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.



• 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.



• 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.No. Type Seats

181 W 66

182 W 64

622 LR 102

VEHICLE

Primary Key



• Foreign Keys 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.

No. Type Seats

181 W 66

182 W 64

622 LR 102


Bernard 69 181 Wed

Bernard 69 181 Thu

Adams 48 622 Thu

VEHICLE SHIFT

Foreign Key


B. B. Data Data IntegrityIntegrityB. B. Data Data IntegrityIntegrity


Data IntegrityData IntegrityData IntegrityData 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.


Entity Integrity Constraint:Entity Integrity Constraint:

• no primary key value can be null

• the primary key must not be duplicated


No. Type Seats

181 W 66

182 W 64

622 LR 102

VEHICLE

Primary Key



• A constraint that is specified between two relations and is used to maintain consistency among tuples of the two relations.

Referential Integrity Constraint:Referential Integrity Constraint:

• 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.

No. Type Seats

181 W 66

182 W 64

622 LR 102


Bernard 69 181 Wed

Bernard 69 181 Thu

Adams 48 622 Thu

VEHICLE SHIFT

Foreign Key

Referential Integrity Constraint (cont..)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.



LECTURER

DEPARTMENT

Data IntegrityData IntegrityData IntegrityData IntegrityReferential Integrity Constraint (Example) – Referential Integrity Constraint (Example) – when to Cascade, Restrict or Nullify?when to Cascade, Restrict or Nullify?

Lecturer ID First Name Last Name Dept NumberL1 Wenny Rahayu D1L2 Daniel Hodges D2L3 Shaskia Ramanthan null

Dept Number Dept Name Mail NumberD1 Computer Science 39D2 Information Science 30D3 Physics 37D4 Chemistry 35

DATABASE MODELLING DATABASE MODELLING USINGUSING

ENTITY RELATIONSHIP MODELENTITY RELATIONSHIP MODEL[E-R MODEL][E-R MODEL]

Database DesignDatabase DesignDatabase DesignDatabase Design

The Process of Database Design

Problem Domain

ANALYSISData Modeling

(eg. Using E-R Model

DESIGNRelational Logical

ModelIMPLEMENTATIONRelational

DBMSTOPIC 6TOPIC 6

TOPIC 7TOPIC 7

TOPIC 3TOPIC 3

TOPIC 2TOPIC 2

Database DesignDatabase DesignDatabase DesignDatabase Design

The Process of Database Design

In previous lectures, we have discussed:

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.

• The Relational Model which is the foundation of Relational DBMS, Data Structure and Data Integrity

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:

o Entities, that is, things.

o Relationships, that is, associations or interactions between entities.

ER models (or ER schemas) are represented by ER diagrams.

ER ModelER ModelER ModelER Model

Entities and AttributesEntities and AttributesEntities and AttributesEntities 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.

EMPLOYEEEMPLOYEE

SUBJECTSUBJECT

ACCOUNTACCOUNT


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.

name salary

ageaddress

Each attribute is represented by an oval and is associated with a domain of legal values.

EMPLOYEEEMPLOYEE


• 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.

Types of AttributesTypes of AttributesTypes of AttributesTypes 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

Composite AttributesComposite AttributesComposite AttributesComposite Attributes

Most attributes are atomic, or simple eg. name, age, salary. Attributes can be composite; eg. address has several components.

namesalary

age

address

streetnumber suburb

EMPLOYEEEMPLOYEE

Multi-Valued AttributesMulti-Valued AttributesMulti-Valued AttributesMulti-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

number

studio

VIDEOVIDEO

RelationshipsRelationshipsRelationshipsRelationships

Association between two (or more) entities.

ENTITYENTITY RelationshipRelationship ENTITYENTITY

primary keyprimary key

attributeattribute

attributeattribute

Degree of RelationshipDegree of RelationshipDegree of RelationshipDegree of Relationship

UNARYOne entity set, recursive.Example

BINARYTwo entity sets linked (mostly used).

TERNARY

Three entity sets linked.

SUBJECTSUBJECT prerequisiteprerequisite

N

M

STUDENTSTUDENT SUBJECTSUBJECTenrols inenrols inM N

RENTAL SHOPRENTAL SHOP VIDEOVIDEOownsownsM N

BORROWERBORROWER

1

Attributes of RelationshipsAttributes of RelationshipsAttributes of RelationshipsAttributes of Relationships

Relationships can have attributes.

name

ID

address

enrols in

M

result

title

code

N

STUDENTSTUDENTSUBJECTSUBJECT

Constraints on RelationshipsConstraints on RelationshipsConstraints on RelationshipsConstraints on Relationships

CARDINALITYThe 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

LECTURERLECTURER SUBJECTSUBJECTteachteach

1 N

(0,N) (1,1)

ParticipationParticipationParticipationParticipation

To specify whether the existence of an entity depends on its being associated with another entity via the relationship.

Two Types

1. TOTAL ParticipationThe existence of an entity is totally dependent on the

other entity.

2. PARTIAL ParticipationThe existence of an entity is partially dependent on

the other entity.

Example

PARTIAL TOTAL

LECTURERLECTURER SUBJECTSUBJECTteachteach

1 N

(0,N) (1,1)

Weak EntityWeak EntityWeak EntityWeak 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

EMPLOYEEEMPLOYEE DEPENDENTDEPENDENThashas

(0,N) (1,1)

1 N

employee noemployee no

dependent namedependent name

employee noemployee no

E-R Diagram E-R Diagram E-R Diagram E-R Diagram

The steps to draw an E-R diagram

Identify entities in the required system

Represent the entities graphically by a rectangle.

Search for relationships between the entities and represent them graphically by a diamond.( Note : Check for unary, binary OR ternary relationships).

Relationshipname

Relationshipname

EntityNameEntityName


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.

Identify all attributes, underline primary key attributes.

TotalPartial


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.


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.

E-R Diagram Solution E-R Diagram Solution E-R Diagram Solution E-R Diagram Solution

Relational Database DesignRelational Database Design

Readings : Chpts 3 & 7, Elmasri & Navathe

Next Lecture … Next Lecture … Next Lecture … Next Lecture …

Documents

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