BD05eng

8/3/2019 BD05eng

1/49

These slides are for use with

Database SystemsConcepts, Languages and Architectures

Paolo Atzeni Stefano Ceri Stefano Paraboschi Riccardo Torlone McGraw-Hill 1999

To view these slides on-screen or with a projector use the arrow keys tomove to the next or previous slide. The return or enter key will also takeyou to the next slide. Note you can press the escape key to reveal themenu bar and then use the standard Acrobat controls including themagnifying glass to zoom in on details.

To print these slides on acetates for projection use the escape key toreveal the menu and choose print from the file menu. If the slides aretoo large for your printer then select shrink to fit in the print dialoguebox.

Press the return or enter key to continue . . .

8/3/2019 BD05eng

2/49

Chapter 5

Designtechniquesand models

??????????Click herefor help

8/3/2019 BD05eng

3/49

Database Systems

Chapter 5: Design techniques and models

McGraw-Hill 1999

Database design

Database design is just one of the many activities in the development

of an information system within an organization;

it should therefore be presented within the wider context of theinformation system life cycle.

8/3/2019 BD05eng

4/49

Database Systems


McGraw-Hill 1999

Feasibility study

Implementation

Operation

Collection & analysisof requirements

Design

Validation andtesting

Life cycle of an information system

8/3/2019 BD05eng

5/49

Database SystemsChapter 5: Design techniques and models

McGraw-Hill 1999

Phases of information system life cycle

Feasibility study. It serves to define the costs of the various possible

solutions and to establish the priorities for the creation of the various

components of the system.

Collection and analysis of requirements. It consists of the definition

and study of the properties and functionality of the information system.

Design. It is generally divided into two tasks: database designandoperational design.

Implementation. It consists of the creation of the information system

according to the characteristics defined in the design.

Validation and testing. This is to check the correct functioning andquality of the information system.

Operation. The information system becomes live and performs thetasks for which it was originally designed.

8/3/2019 BD05eng

6/49

Database Systems


McGraw-Hill 1999

Information systems and databases

The database constitutes only one of the components of an

information system, which also includes application programs, user

interfaces and other service programs.

However, the central role that the data itself plays in an information

system more than justifies an independent study of database design.

For this reason, we deal with only those aspects of information systemdevelopment that are closely of databases, focusing on data design

and on the related activities of collection and analysis of the

requirements.

8/3/2019 BD05eng

7/49

Database Systems


McGraw-Hill 1999

Methodologies for database design

We follow a structured approach to database design that can beregarded as a design methodology.

As such, it is presented by means of:

a decompositionof the entire design activity in successive steps,independent one from the other;

a series of strategiesto be followed in the various steps and somecriteriafrom which to choose in the case of there being options;

some reference modelsto describe the inputs and outputs of thevarious phases.

8/3/2019 BD05eng

8/49

Database Systems


McGraw-Hill 1999

A database design methodology

Within the field of databases, a design methodology has beenconsolidated over the years.

It is based on a simple but highly efficient engineering principle:

separate the decisions relating to what to represent in thedatabase, from those relating to how to do it.

This methodology is divided into three phases to be followed

consecutively.

8/3/2019 BD05eng

9/49

Database Systems


McGraw-Hill 1999

Applicationrequirements

Databasedesign

Logical design

Physical design

CONCEPTUAL SCHEMA

LOGICAL SCHEMA

PHYSICAL SCHEMA

Conceptual design

Database structure andrelated documentation

The phases of database design

8/3/2019 BD05eng

10/49

Database Systems


McGraw-Hill 1999

Phases of database design

Conceptual design. The purpose of this is to represent the informal

requirements of an application in terms of a conceptual schemathatrefers to a conceptual data model.

Logical design. This consists of the translation of the conceptualschema defined in the preceding phase, into the logical schemaof

the database that refers to a logical data model.

Physical design. In this phase, the logical schema is completed with

the details of the physical implementation (file organization andindexes) on a given DBMS. The product is called the physical

schemaand refers to a physical data model.

8/3/2019 BD05eng

11/49

Database Systems


McGraw-Hill 1999

Conceptual design

Logical design

Physical design

The products of the various phases of a relational

database with the E-R model

8/3/2019 BD05eng

12/49

Database Systems


McGraw-Hill 1999

The Entity Relationship model

The Entity-Relationship (E-R) model is a conceptualdata model,and as such provides a series of constructscapable of describing

the data requirements of an application in a way that is easy tounderstand and is independent of the criteria for the management

and organization of data on a database system.

For every construct, there is a corresponding graphicalrepresentation. This representation allows us to define an E-R

schema diagrammatically.

D t b S t

8/3/2019 BD05eng

13/49

Database Systems


McGraw-Hill 1999

Construct Graphical representation

Relationship

Entity

Simple attribute

Composite attribute

Cardinality of a (m1,M1) (m2,M2)

Cardinality of anattribute

(m,M)

Internal identifier

Generalization

External identifier

Subset

The constructs of the E-R model and

their graphical representation

8/3/2019 BD05eng

14/49

Database Systems


McGraw-Hill 1999

Entities

These represent classes of objects (facts, things, people, for example)that have properties in common and an autonomous existence.

CITY, DEPARTMENT, EMPLOYEE, PURCHASE and SALE are

examples of entities in an application for a commercial organization.

An occurrence of an entity is an object of the class that the entityrepresents.

Database Systems

8/3/2019 BD05eng

15/49

Database Systems


McGraw-Hill 1999

EMPLOYEE

DEPARTMENT

CITY

SALE

Examples of entity of the E-R model

8/3/2019 BD05eng

16/49

Database Systems


McGraw-Hill 1999

Relationships

They represent logical links between two or more entities.

RESIDENCE is an example of a relationship that can exist between

the entities CITY and EMPLOYEE; EXAM is an example of a

relationship that can exist between the entities STUDENT andCOURSE.

An occurrence of a relationship is an n-tuple made up of occurrences

of entities, one for each of the entities involved.

Database Systems

8/3/2019 BD05eng

17/49

Database Systems


McGraw-Hill 1999

S 1

S 2

S 5

S 3

S 4

Student Course

e1e2

e3

e4

e5

e6

C1

C2

C3

Example of occurrences of the EXAM relationship

Database Systems

8/3/2019 BD05eng

18/49

Database Systems


McGraw-Hill 1999

STUDENT EXAM COURSE

WORKPLACE

EMPLOYEE RESIDENCE CITY

Examples of relationships in the E-R model

Database Systems

8/3/2019 BD05eng

19/49

y


McGraw-Hill 1999

COLLEAGUE

EMPLOYEE

Predecessor Successor

SUCCESSION

SOVEREIGN

Examples of recursive relationships in the E-R model

Database Systems

8/3/2019 BD05eng

20/49

y


McGraw-Hill 1999

SUPPLIER

DEPARTMENT

PRODUCTSUPPLY

Example of a ternary relationship in the E-R model

Database Systems

8/3/2019 BD05eng

21/49


McGraw-Hill 1999

P1

P2

P5

S 1

S 2

S 3

P3

P4

ProductSupplier

s1

D1

D2D3

D4

Department

s2

s3

s4

S 4

Example of occurrences of the SUPPLY relationship

8/3/2019 BD05eng

22/49

Database Systems


McGraw-Hill 1999

Attributes

These describe the elementary properties of entities or relationships.

Surname, Salary and Age are possible attributes of the EMPLOYEE

entity, while Date and Mark are possible attributes for the relationshipEXAM between STUDENT and COURSE.

An attribute associates with each occurrence of an entity (or

relationship) a value belonging to a set known as the domain

of the attribute.

The domain contains the admissible values for the attribute.

Database Systems

8/3/2019 BD05eng

23/49


McGraw-Hill 1999

STUDENT EXAM COURSE

WORKPLACE

EMPLOYEE BIRTHPLACE CITY

Number

EnrolmentDate

Mark Date

Name

Year

Name

NumberOfInhabitantsDateOfBirth

Surname

Salary

Age

E-R schemas with relationships, entities and

attributes

Database Systems

Ch t 5 D i t h i d d l

8/3/2019 BD05eng

24/49


McGraw-Hill 1999

Address

Surname

Age

SexStreetHouseNumberPostCode

PERSON

An example of an entity with a composite attribute

Database Systems


8/3/2019 BD05eng

25/49


McGraw-Hill 1999

Code

Surname

Salary

Age

Name

Budget

ReleaseDate

PROJECT

EMPLOYEE

BRANCH

City

Phone

Name

Number

StreetPostCode

Address

StartDate

MANAGEMENT

MEMBERSHIP DEPARTMENT

COMPOSITIONStartDate

PARTICIPATION

An Entity-Relationship schema

8/3/2019 BD05eng

26/49

Database Systems


McGraw-Hill 1999

Cardinalities

They are specified for each entity participating in a relationship and

describe the maximum and minimum number of relationshipoccurrences in which an entity occurrence can participate.

They state therefore how many times in a relationship betweenentities an occurrence of one of these entities can be linked to

occurrences of the other entities involved.

Database Systems


8/3/2019 BD05eng

27/49


McGraw-Hill 1999

EMPLOYEE TASKASSIGNMENT(1,5) (0,50)

Cardinality of a relationship in the E-R model

8/3/2019 BD05eng

28/49

Database Systems


McGraw-Hill 1999

Values for cardinalities

In most cases, it is sufficient to use only three values for cardinalities:zero, one and the symbol N:

for the minimum cardinality, zero or one; in the first case we saythat the participation in the relationship is optional, in the second

we say that the participation is mandatory; for the maximum cardinality, one or many (N); in the first case

each occurrence of the entity is associated at most with a singleoccurrence of the relationship, while in the second case each

occurrence of the entity is associated with an arbitrary number ofoccurrences of the relationship.

Database Systems


8/3/2019 BD05eng

29/49


McGraw-Hill 1999

PERSON CITY

TOURIST

(0,1)

(1,1)

(1,N)

(1,1)

(0,N)

(0,N)

RESIDENCE

ORDER SALE

RESERVATION

INVOICE

VOYAGE

Examples of cardinality of relationships

8/3/2019 BD05eng

30/49

Database Systems


McGraw-Hill 1999

Cardinalities of attributes

They can be specified for the attributes of entities (or relationships)and describe the minimum and maximum number of values of the

attribute associated with each occurrence of an entity or arelationship.

In most cases, the cardinality of an attribute is equal to (1,1) and isomitted.

The value of a certain attribute can be null or there can existvarious values of a certain attribute associated with an entity

occurrence.

Database Systems


8/3/2019 BD05eng

31/49

p g q

McGraw-Hill 1999

PERSON

CarRegistration

Surname

LicenceNumber

(0,N)

(0,1)

Example of entity attributes with cardinality

8/3/2019 BD05eng

32/49

Database Systems


McGraw-Hill 1999

Identifiers

They are specified for each entity of a schema and describe theconcepts (attributes and/or entities) of the schema that allow the

unambiguous identification of the entity occurrences.

In many cases, an identifier is formed by one or more attributes of

the entity itself: in this case we talk about an internalidentifier (alsoknown as a key).

Sometimes, however, the attributes of an entity are not sufficient toidentify its occurrences unambiguously and other entities need to be

involved in the identification.This is called an externalidentifier.

Database Systems


8/3/2019 BD05eng

33/49

McGraw-Hill 1999

AUTOMOBILE

Registration

Model

Colour

PERSON

DateOf Birth

SurnameFirstName

Address

Examples of internal and external identifiers

Database Systems


8/3/2019 BD05eng

34/49

McGraw-Hill 1999

STUDENT ENROLMENT(1,1) (1,N)

UNIVERSITY

Registration

Year

Surname

NameCity

Address

Example of an external entity identifier

Database Systems

8/3/2019 BD05eng

35/49

Database Systems


McGraw-Hill 1999

General observations on identifiers

An identifier can involve one or more attributes, provided that each of

them has (1,1) cardinality;

an external identifier can involve one or more entities, provided thateach of them is member of a relationship to which the entity to identify

participates with cardinality equal to (1,1); an external identifier can involve an entity that is in its turn identified

externally, as long as cycles are not generated;

each entity must have one (internal or external) identifier, but can

have more than one. Actually, if there is more than one identifier, thenthe attributes and entities involved in an identification can be optional

(minimum cardinality equal to 0).

Database Systems


8/3/2019 BD05eng

36/49

McGraw-Hill 1999

Code

Surname

Salary

Age

Name

Budget

ReleaseDate

EMPLOYEE

BRANCH

City

Phone

Name

NumberStreet

PostCodeAddress

StartDate

MANAGEMENT

MEMBERSHIP DEPARTMENT

COMPOSITIONStartDate

PARTICIPATION

(0,N)

(0,1)

(0,1) (1,1)

(1,N)

(1,N)

(0,1)

(1,N)

(1,N)

(1,1)

PROJECT

A schema completed by identifiers and cardinality

Database Systems

8/3/2019 BD05eng

37/49

Database Systems


McGraw-Hill 1999

Generalizations

These represent logical links between an entity E, known as parent

entity, and one or more entities E1,...,En called childentities, of whichE is more general, in the sense that it comprises them as a particular

case.

In this situation we say that E is a generalizationof E1,...,En and that

the entities E1,...,En are specializationsof the E entity.

Database Systems


8/3/2019 BD05eng

38/49

McGraw-Hill 1999

PROFESSIONALPERSON Address

TaxCode

Surname

Age

Specialization

MAN WOMAN LAWYER ENGINEER DOCTOR

TaxCode

MaternityStatus

Examples of generalizations among entities

Database Systems

8/3/2019 BD05eng

39/49

y


McGraw-Hill 1999

Properties of generalizations

Every occurrence of a child entity is also an occurrence of the parententity.

Every property of the parent entity (attributes, identifiers, relationshipsand other generalizations) is also a property of a child entity. This

property of generalizations is known as inheritance.

Database Systems

8/3/2019 BD05eng

40/49

y


McGraw-Hill 1999

Classification of generalizations

A generalization is totalif every occurrence of the parent entity is alsoan occurrence of one of the child entities, otherwise it is partial;

A generalization is exclusiveif every occurrence of the parent entity isat most an occurrence of one of the child entities, otherwise it isoverlapping.

Database Systems


8/3/2019 BD05eng

41/49

McGraw-Hill 1999

TaxCode

Surname

Age

PEOPLE

WOMAN MAN

MaternityStatus

Salary

EMPLOYEE STUDENT

Number

ANALYSTPROGRAMMERMANAGER

LanguagePROJECT

MANAGER

Hierarchy of generalizations between entities

Database Systems


8/3/2019 BD05eng

42/49

McGraw-Hill 1999

BASICCONSTRUCTGENERALIZATION

Name

PARENT

CHILDENTITY

CONSTRUCT

ATTRIBUTE

COMPOSITE

ATTRIBUTE

COMPOSITION

(0,N)

(1,N)

(1,1)

(0,N)

(0,N)

PARTICIPATION

(1,1)

(0,1)

(1,N)

Name

MinimumCardinality

MaximumCardinality

(0,N) (2,N)

MinimumCardinality

MaximumCardinality

MEMBERSHIP

RELATIONSHIP

Number

Description of the E-R model using the E-R model

Database Systems


8/3/2019 BD05eng

43/49


McGraw-Hill 1999

Documentation of E-R schemas

An Entity-Relationship schema is rarely sufficient by itself to

represent all the aspects of an application in detail;

it is therefore indispensable to provide every E-R schema with

support documentation, which can facilitate the interpretation ofthe schema itself and describe properties of the data that cannot

be expressed directly by the constructs of the model;

a widespread documentation tool for conceptual schemas is thebusiness rule.

Database Systems


8/3/2019 BD05eng

44/49


McGraw-Hill 1999

Business rules

Business rules are one of the tools used by information systems

analysts to describe the properties of an application.

According to a widespread classification a business rule can be:

the description of a concept relevant to the application,

an integrity constraint on the data of the application,

a derivation, or rather a concept that can be obtained, by means ofan inference or an arithmetical calculation, by other concepts of

the schema.

Database Systems


8/3/2019 BD05eng

45/49


McGraw-Hill 1999

Documentation techniques

Descriptive business rules can be organized as a data dictionary. Thisis made up of two tables: the first describes the entities of the schema,

the others describes the relationships.

Business rules that describe constraints can be expressed in the

following form: must/must not

Business rules that describe derivations can be expressed in the

following form:

is obtained by

Database Systems


8/3/2019 BD05eng

46/49


McGraw-Hill 1999

Example of a data dictionaryEntity Description Attributes Identifier

EMPLOYEE Employee working in thecompany.

Code, Surname,Salary, Age

Code

PROJECT Company project on whichemployees are working.

Name, Budget,ReleaseDate

Name

.... .... .... ....

Relationship Description Entities involved Attributes

MANAGEMENT Associate a manager witha department.

Employee (0,1),Department (1,1)

MEMBERSHIP Associate an employeewith a department.

Employee (0,1)Department (1,N) StartDate

.... .... .... ....

Database Systems


8/3/2019 BD05eng

47/49


McGraw-Hill 1999

Example of business rules

Constraints

(BR1) The manager of a department must belong to that department.(BR2) An employee must not have a salary greater than that of the managerof the department to which he or she belongs.(BR3) A department of the Rome branch must be managed by an employeewith more than 10 years employment with the company.

(BR4) An employee who does not belong to a particular department must notparticipate in any project.....

Derivations

(BR5) The budget for a project is obtained by multiplying the sum of thesalaries of the employees who are working on it by 3.....


8/3/2019 BD05eng

48/49

McGraw-Hill 1999

Age

Name

County

State

CITY

Age

WOMANMAN

BIRTHPLACE

WORKER

Age

Height

MILITARYSERVICE

BIRTHPLACE

RESIDENCE

SERVICE

PERSONSurname

Firstname

An E-R schema with a few imprecisions


S h E R f E i 5 6

8/3/2019 BD05eng

49/49

McGraw-Hill 1999

Name

Surname

City

Region

REFEREE

REFEREEING

(1,N)

(1,1)

MATCH

Result

HOME

(1,1)

NEUTRALGROUND POSTPONED

DateCityReason

(1,N)

Number

PLACINGDAY

NumberSeries

Date

MonthDay Year

(1,N)(1,1)

POSITION

VISITING

TEAM

(1,1)

(1,N)

CONTRACT

(1,N)

PLAYER

(1,N)

(1,N)

PointsTrainer

City

Name

(1,1)

SSN

FirstNameSurnamePosition

BirthPlace

DateOfBirth

Day

Month

Year

PARTICIPATION(1,N)(0,N)

Position

Schema E-R for Exercise 5.6

BD05eng

Documents

Transcript of BD05eng