2

()?
... *! * ISO/IEC 12207:1995

Information Technology Software Life Cycle Processes , . , , , .

2

ISO 12207

 -...

 -...

 ...

Puzzle ... ...

. . . . .

; .

Levels of Abstraction

Views describe how users see the data.

Conceptual schema defines logical structure Physical schema describes the files and indexes used.

Users

View 1

View 2

View 3

Conceptual Schema Physical Schema

(sometimes called the ANSI/SPARC model)

DB

Example: University Database

Conceptual schema:

Students(sid: string, name: string, login: string, age: integer, gpa:real) Courses(cid: string, cname:string, credits:integer) View 1 Enrolled(sid:string, cid:string, grade:string)

View 2

View 3

External Schema (View):

Conceptual Schema Physical Schema

Course_info(cid:string, enrollment:integer)
Relations stored as unordered files. Index on first column of Students.

Physical schema:

DB

Data Independence

Applications insulated from how data is structured and stored. Logical data independence: Protection from changes in logical structure of data.

View 1

View 2

View 3

Conceptual Schema Physical Schema

Physical data independence: Protection from changes in physical structure of data. Q: Why are these particularly important for DBMS?

DB

Entity-Relationship Model " - "

" - ", ER . (entityrelationship diagram), . (entity set). - , -

15

Database design lifecycle

Requirements analysis

User needs; what must database do?

High-level description; often using E/R model Today

Conceptual design

Logical design

Translate E/R model into (typically) relational schema Check schema for redundancies and anomalies Consider typical workloads, and further optimise

Schema refinement

Physical design/tuning

16

Todays lecture

E/R modelling

Entities Attributes Relationships Constraints on relationships

Object ideas

Extended E/R modelling

17

Conceptual Design
What are the entities and relationships in the enterprise? What information about these entities and relationships should we store in the database? What are the integrity constraints (business rules) that hold? We can represent this information pictorially in E/R diagrams (and then map these to a relational schema later).

18

E/R basics

An entity is a real-world object that is distinguishable from other objects Each entity has attributes (with domains) A particular entity will have a value for each of its attributes An entity type defines a set of entities that have the same attributes An entity set is the collection of all entities of a particular entity type (at a particular point in time)
19

Entities and attributes

Entity types are drawn as rectangles, e.g.

Employees

Attributes are drawn as ovals, and attached to the entity sets with lines, e.g.
NI Name dob

Employees
20

ER Diagrams - Symbols

Summary of Symbols

Key attributes
A key attribute of an entity type is an attribute whose values are distinct for each entity Sometimes several attributes (a composite attribute) together form a key

NB: Such a composite should be minimal

Name

We underline key attributes

NI dob

Employees

23

Relationships

A relationship type among two or more entity types defines a set of associations between entities from those types

Mathematically, relationship type R R E1 En.

The set of instances of the relationship type is called the relationship set

24

Relationships in E/R
Relationship types are represented by diamonds They connect the participating entity types with straight lines, e.g.

NI
Name

dob

DID

dname

budget

Employees

Works_in

Departments

25

Relationship set diagrams

Sometimes its useful to represent the relationship set diagrammatically

e
1 e2

r1

d1

r2
r3 r4

d2
d3 d4

e3 e4

e5

d5

26

Relationship attributes

Relationships can also have attributes

NB: A relationship must be uniquely determined by the entities, without reference to the relationship attributes

NI

Name

dob

since

DID

dname

budget

Employees

Works_in

Departments

27

N-ary relationships

Although relatively rare, we can have nary relationships, e.g.

Name

NI

dob

since

DID

dname

budget

Employees

Works_in2

Department

address

Locations

capacity

28

Recursive relationships

Each entity type in a relationship plays a particular role, which is associated with a role name (this is usually suppressed) An recursive relationship is when an entity type plays more than one role in the relationship type In this case the role name is required

29

Recursive relationships in E/R

e.g.
NI Employees supervisor Reports-to subordinate name dob

30

Constraints on relationship types

For example:

An employee can work in many departments; a department can have many employees In contrast, each department has at most one manager

Thus we need to be able to specify the number of relationship instances that an entity can participate in. For binary relationships the possible ratios are: 1:1, 1:N, N:1, M:N

31

Cardinality ratios
1:1 1:N

M:N

32

Cardinality ratios in E/R

M:N
M N

N:1

1:1

Note: Sometimes this is written using different arrowheads

33

Types of Binary Relationships

Many-many

Many-one

One-one

Representation of Many-One

Many-one E/R: arrow pointing to one.

Participation constraints
Every department must have a manager This is an example of a participation constraint The participation of an entity set, E, in a relationship set R is said to be total if every entity in E participates in at least one relationship in R. (If not its participation is said to be partial)

35

Participation in E/R diagrams

Total participation is displayed as a bold line between the entity type and the relationship

NB. Sometimes this is written as a double line

NI

Name

dob

since

DID

dname

budget

Employees

Manages

Department

36

Weak entity types

An entity type may not have sufficient attributes to form a primary key Such an entity type is called a weak entity type A weak entity can only be identified uniquely by considering the primary key of another (owner) entity

37

Weak entity types cont.

Thus the owner and weak entity types must participate in a 1:N relationship Weak entity set must have total participation in this identifying relationship set.

NI Name Employees 1 Cost Policy N pName age

Dependents

38

Extended E/R modelling

What weve seen so far is classic E/R Over the years a number of features have been added to the model and the modelling process These features include:

Sub- and superclasses Specialisation Generalisation Categories

Higher/Lower-level entity sets Attribute inheritance Aggregation

39

ISA hierarchies
We can devise hierarchies for our entity types Name NI dob If we declare A ISA B, every Employees A entity is considered to be a B entity

rate
hours ISA cid

Temp_Emp

Contract_Emp
40

Attribute inheritance
As wed expect, attributes of superclasses are inherited by the subclasses. Thus: Temp_Emp also has attributes NI, Name and dob

In fact, subclasses inherit relationships too

41

Aggregation

Suppose we have an entity set of Projects and that each project is sponsored by one or more departments; thus
start PID budget

since
DID

dname budget

Projects

Sponsors

Departments

42

Aggregation cont.
Suppose that employees are assigned to monitor a sponsorship Monitors should be a relationship between Employees and the Sponsors relationship Aggregation allows us to indicate that a relationship set participates in another relationship set Use dashed box

43

Aggregation cont.
NI name

Employees

Monitors

until

PID

start

since budget DID

Sponsors

dname
budget

Projects

Departments

44

A Data Model from the European Bioinformatics Institute (EBI)

See http://intact.sourceforge.net/uml/intactCore.gif

45