Ders # 2

VER TABANI DERS NOTLARI data modeling with ER References ER section from Elmasri, Navathe, Fund. of Database Systems, 5th ed., Addison Wesley

Outline

Overview of Database Design Process Example Database Application (COMPANY) ER Model Concepts Entities and Attributes Entity Types, Value Sets, and Key Attributes Relationships and Relationship Types Weak Entity Types Roles and Attributes in Relationship Types ER Diagrams - Notation ER Diagram for COMPANY Schema EER modelling (Spacification/Generalization, Superclass/ Subclass, Hierarcies, Lattices) Alternative Notations UML class diagrams, others

Overview of Database Design Process

Two main activities:

Database design Applications design

Use Data-flow, sequence diagrams or scenarios

Applications design focuses on the programs and interfaces that access the database

ER

Generally considered part of software engineering

ER Model Concepts- Entities, Attributes

Entities and Attributes

Entities are specific objects or things in the mini-world that are represented in the database.

For example the EMPLOYEE John Smith, the Research DEPARTMENT, the ProductX PROJECT For example an EMPLOYEE entity may have the attributes Name, SSN, Address, Sex, BirthDate For example a specific employee entity may have Name='John Smith', SSN='123456789', Address ='731, Fondren, Houston, TX', Sex='M', BirthDate='09-JAN-55

Attributes are properties used to describe an entity.

A specific entity will have a value for each of its attributes.

Each attribute has a value set (or data type) associated with it e.g. integer, string, subrange, enumerated type,

ER Model Concepts -Entity Types and Key Attributes

Entities with the same basic attributes are grouped or typed into an entity type. ( EMPLOYEE and PROJECT are entity types)

an entity type is displayed in a rectangular box in ER diagram.

An attribute of an entity type for which each entity must have a unique value is called a key attribute of the entity type.

Attributes are displayed in ovals, and is connected to its entity type Each key is underlined in ER model

For example, SSN of EMPLOYEE.

A key attribute may be composite. (At the next slide, VehicleTagNumber is a

key of the CAR entity type with components (Number, State).)

An entity type may have more than one key. (At the next slide, VehicleIdentificationNumber (popularly called VIN), VehicleTagNumber (Number, State), aka license plate number.)

Types of attribute: Simple, Composite, Multivalued Simple: Each entity has a single atomic value for the attribute. (SSN or
DateofBirth)

Composite: composition of several components. Address(Apt#, House#,

Street, City, State, ZipCode, Country), or Name(FirstName, MiddleName, LastName). Multi-valued: existence of multiple values for that attribute. (For example, Color of a CAR or PreviousDegrees of a STUDENT. (Denoted as {Color} or

{PreviousDegrees}. )

ER Model Concepts-

EXAMPLE: Entity Type CAR with two keys and a corresponding Composite Entity Set
attribute

Entity Set

Entity set is the collection of entities stored in the database Previous slide shows three CAR entity instances in the entity set for CAR Same name (CAR) used to refer to both the entity type and the entity set Entity set is the current state of the entities of that type that are stored in the database

A key

A key Multivalued attr.

three CAR entity instances in the entity set for CAR

ER Model Concepts :Relationships, Relationship Types and

Relationship Set

A relationship relates two or more distinct entities with a specific meaning.

For example, EMPLOYEE John Smith works on the ProductX PROJECT, or EMPLOYEE Franklin Wong manages the Research DEPARTMENT.

Relationships of the same type are grouped or typed into a relationship type.Identifies the

relationship name participating entity types, degree of a relationship, cardinality ratio, existence dependency)

Relationship Set: The current state of a relationship type.

Example COMPANY Database

We need to create a database schema design based on the following (simplified) requirements of the COMPANY Database: The company is organized into DEPARTMENTs. Each department has a name, number and an employee who manages the department. We keep track of the start date of the department manager. A department may have several locations. Each department controls a number of PROJECTs. Each project has a unique name, unique number and is located at a single location. We store each EMPLOYEEs social security number, address, salary, sex, and birthdate. Each employee works for one department but may work on several projects. We keep track of the number of hours per week that an employee currently works on each project. We also keep track of the direct supervisor of each employee. Each employee may have a number of DEPENDENTs. For each dependent, we keep track of their name, sex, birthdate, and relationship to the employee.

Initial Design of COMPANY DB

Based on the requirements, we can identify four initial entity types in the COMPANY database:

DEPARTMENT, PROJECT, EMPLOYEE and DEPENDENT

The initial attributes shown are derived from the requirements description

In the refined design, some attributes from the initial entity types are refined into relationships:

Manager of DEPARTMENT -> MANAGES Works_on of EMPLOYEE -> WORKS_ON Department of EMPLOYEE -> WORKS_FOR Controlling_Department of PROJECT CONTROLS Supervisor of EMPLOYEE SUPERVISION Dependent_name of DEPENDENT DEPENDENTS_OF

In general, more than one relationship type can exist between the same participating entity types(MANAGES and WORKS_FOR are distinct relationship types between EMPLOYEE and DEPARTMENT (Different meanings and different relationship instances.)

COMPANY DB ER DIAGRAM

Recursive relationship

Recursive relationship type In a recursive relationship type.

Both participations are same entity type in different roles. In ER diagram, we need to display role names to
distinguish participations.

For example, SUPERVISION relationships between EMPLOYEE (in role of supervisor or boss) and (another) EMPLOYEE (in role of subordinate or worker).
In following figure, first role participation labeled with 1 and second role participation labeled with 2.

Another Entity Type: Weak

Entity Types

An entity that does not have a key attribute A weak entity must participate in an identifying relationship type with an owner or identifying entity type Weak Entities are identified by the combination of: A partial key of the weak entity type The particular entity they are related to in the identifying entity type Example: A DEPENDENT entity is identified by the dependents first name, and the specific EMPLOYEE with whom the dependent is related Name of DEPENDENT is the partial key DEPENDENT is a weak entity type EMPLOYEE is its identifying entity type via the identifying relationship type DEPENDENT_OF

Weak entity types can be represented as complex (composite, multivalued) attributes. How to decide? Different structures may occur s.a.:

>1 number of levels of weak entity types >1 number of identifying entity type >1 degree of identifying relationship

Attributes and Constraints of Relationships

A relationship type can have attributes: (HoursPerWeek of WORKS_ON )

A value of HoursPerWeek depends on a particular (employee, project) combination Most relationship attributes are used with M:N relationships In 1:N relationships, they can be transferred to the entity type on the Nside of the relationship Cardinality Ratio (eleman says oran) (specifies maximum participation) :

(1:1),(1:N) or (N:1), (M:N)

Shown by placing appropriate numbers on the relationship edges. Existence Dependency (varolma bamll) Constraint (specifies minimum

participation, called participation constraint : TOTAL or PARTIAL )

PARTIAL: zero (optional participation, not existence-dependent) TOTAL: one or more (mandatory participation, existencedependent)
Total shown by double line, partial by single line. ( Look at the COMPANY ER diagram for examples..)

Summary of notation for ER diagrams

Relationships of Higher Degree

Relationship types of degree 3 are called ternary and of degree n are called n-ary relationship which is not equivalent to n binary relationships.

If needed, the binary and n-ary relationships can all be included in the schema design Determining the cardinalities depends on the scenario.

Which one conveys more information? (s,j,p) (s,p) (j,p) (s,j) One more step further: If we do not want to use weak entity type, how to design?

Redundancy in n-ary relationships

If a particular binary relationship can be derived from a higherdegree relationship at all times, then it is redundant

the TAUGHT_DURING binary relationship in figure below can be derived from the ternary relationship OFFERS (based on the meaning of the relationships) the OFFERED_DURING binary relationship in figure below can be derived from the ternary relationship OFFERS (based on the meaning of the relationships)
Redundant!

In case CAN_TEACH is 1-1 relationship; what do you think about OFFERS relationship?

Redundant!

Constraint on Ternary relationships

It is usually hard to determine the constraints.. An M or N indicates no constraint.. A 1 indicates that an entity can participate in at most one relationship instance that has a particular combination of the other participating entities

1 N

Determine the key of SUPPLY..?

1 1

Determine the key of SUPPLY..?

Redundancy / dependency problem in ER (in general)

N 1
se N ENROLL N

1
DEPT

STUDENT 1 N 1 PERMIT
1 1 N

GRADE 1

N 1
1

1
N

PROF
1

PLATE

MODEL

YEAR
1

SECTION N

1 N
cs

COURSE

1 GPA
1
MAJOR _GPA

N
STUDENT

1 DEPT GPA

N
STUDENT

DEPT 1 N
STUDENT _MAJOR

GPA 1
MAJOR _GPA

N
STUDENT

N
DEPT

N Dependency problem

1 MAJOR_ GPA

18

Redundancy problem in ER (in general)

STUDENT 1 se N

EId ENROLL N

GRADE

1 SECTION
cs 1 COURSE

renci ayn SECTIONa ok defalar kayt olup her kayd iin farkl notlar alabilir. Buna engel olmak; yani renci bir SECTIONa bir kez kayt olabilir. koulunu emaya nasl dahil edebiliriz..?

renci bir COURSEa bir kez kayt olabilir. koulunu sorudaki emaya nasl dahil edebiliriz..

19

Some refinements after design

Attributes relationships
another entity type)

(if attribute refers to

Attributes entity types

several entity types)

(if an attribute exists in

entity type attribute

(if an entity type has a single attribute and has only 1 relationship)

Choices concerning the degree of relationships. Top-down&bottomup refinements are defined for large-scale designs.

Example-1

ehirler, lkeler ve nehirleri gsteren bir veritaban tasarm.

ehir R lke

1
S

M
Nehir

Nehirlerin hangi ehirlerden getiini tutmak istersek?

ehir

N N

lke

Nehir

Example-2
Bir irketteki blmler ve personel bilgilerini tutan Blm-Personel veri tabann dnelim.

Her blm ok sayda personele sahiptir ve her personel en fazla bir blme baldr. Bir blmn sadece bir yneticisi (mutlaka) vardr. Blm iin Bid, personel iin Pid anahtardr.

Buna gre aadaki durumlar birbirinden bamsz olarak cevaplaynz Bir blmn yneticisi ancak o blme bal bir personel olabiliyor ise, Nasl bir ER modeli izilebilir?
1 bid B Y? N P pid

Bir blmn yneticisi herhangi bir personel olabiliyor ise, Nasl bir ER modeli izilebilir?
1 B N y 1 N P

Example-3
SATI FORMU
SatNO: 12 Birim Fiya t Tarih: 11.06.2009

SatrNo 1 2
3

ParaNo

Parasim

Tanm
Spor,basketbol

Miktar 1 2

Toplam 110 160

23645 ayakkab 12674 gomlek

...

110 80

klasik tarz
...

GenelTopl am:

880

Yukarda sat bilgileri tutan rnek bir sat formu ierii grlmektedir. Buna karlk gelen veri taban, SATI, PARA ve SATIR olmak zere 3 varlk setinden olumaktadr. (Ayn ParaNolu paralar farkl satrlarda tekrar edebilir.) Bu varlk setlerini, zeliklerini ve aralarndaki ilikileri gsteren ER diyagramn iziniz.

satno tarih

geneltoplam Sat 1 ss N

Birim fiyat parano pisim Para tanm 1 toplam ps N satrno miktar

Not: satrno, partial key oluyor.

Satr

Example-4
Trafik sigorta irketine ait srcler ve yaplan kazalar hakknda bilgi saklayan bir veri taban tasarm:

Her srcnn ehliyet no, isim Her aracn plakas Her kaza iin kaza_no, tarih ve yer bilgisi Bir ara bir src zerine kaytlyken, bir srcnn ok sayda arac olabilir. Srcnn hangi ara ile hangi trafik kazasn yaptn ve kazann masraf GPS konum plaka tarih 1 N ehliyetno
src sahip

ara

kaza

isim

yapt

kaza_no

Bir kazada, birden ok araba varsa, yer alan arabalarin bulunmas yukardaki haliyle ancak ayn tarihli(yl/gn/saat/saniye) ve ayn yerdeki kazalarn bulunmas ile tretilebilir. Bu Mantksal (ilikisel model) aamada sorgu ile yaplabilir.. Bu bilgiyi kavramsal aamaya, ERa, tamak farkl yollar ile olabilir: 1. Ayn kaza iersinde yer alan arabalara ait olan kazalara ayn kaza_no verelim. Bunu salamak KAZA varlk setinin zayf olmas ile olabilir; kaza_no zerinden o numarali kazadaki aralara veya srclere ulaabiliriz.. Her araca ait masraf bilgisi tutlabilir.. 2. ARA ile KAZA arasnda N-N lik bir bant tanmlayabiliriz. Bu bantya tarih ve yer bilgisi ekleriz. Her araca ait masraf bilgisi tutlabilir.. 3. ARA-ARA arasnda N-Nlik bir bant tanmlarz.Burda bir kaza_no olmad iin; tarih nitelii multi-value olmas gerekir.. Her araca ait masraf bilgisi tutulamaz..

N
src sahip

plaka
ara
yapt

GPS konum masraf tarih

src

kaza

sahip

ara
N

N
kaza

isim

1
N
src

N
1

kaza_no

tarih

plaka
ara
yapt

GPS konum

sahip

kaza tarih N
kaza_no masraf

isim

Example-5

Birden ok oyuncu ieren takmlar arasnda, iki takm ieren oyunlar ile ilgili bilgiler tutulmak isteniyor. (Oyuncu en fazla bir takmn eleman olabilir. ) her oyunda hangi takmlarn yer ald (hangi takm ev sahibi hangisi misafir olduu) ve oyunun tarihi ve sonucu gibi bilgiler tutuluyor. her oyunda takmn hangi oyuncularnn yer ald bilgisi takip ediliyor.
N
oyuncu ait

takm
1 1
misafir ev

M
oynar

skor

N oyun
PK tarih sonu

skor

Example-6

Bir banka hesabna ait ilemler hakknda ilem zaman(gn,saat), ilem tipi ve miktar bilgileri tutuluyor.bu olay takip eden ER diyagram:

1
hesap ait ait

miktar

ilem
GS gn saat

tip

Not: gn,saat partial key oluyor.

Farkl hesaplarda ayn saat iinde ayn miktar ve tip ilem olabilir!!!

Yukardaki zm, bir hesap zerinde ayn saat iinde ilem yaplmamas durumunda geerlidir. Bu koul kalkt zaman, tasarm ilem zaman olarak sistem zamann saklamaldr;
1
hesap ait ait

miktar

ilem
GSS gn saat

tip

Not: gn,saat,saniye partial key oluyor.

saniye

Farkl hesaplarda ayn saniye iinde ayn miktar ve tip ilem olabilir!!!

Example-7
(x1,y1)

(x2,y2)

c isimliizgi geometrik nesnesi, ekilde grld gibi (x1,y1), (x2,y2) noktalar ile tanmlanmaktadr. Sadece nokta ve izgi varlklarn tutan bir veri taban tasarlanmak isteniyor. (NOT: varlklarn ismi, zellikleri, ilikilerin cardinality deerlerini belirmeyi unutmayn.., izgilerin yn yok!)
N
NOKTA
izgi

1.yol:
xy x y

isim

N
sim, partial key oluyor

2.yol:
x y
NOKTA1
izgi

isim

ZG
N N

1
izgi

x
NOKTA2

Example-8

Dnya zerindeki gemi limanlar ve gemi hareketlerini tutan bir veri taban tasarm. Limanlarn hangi lkede hangi okyanusta olduu saklanyor. Limanlarn sadece isimleri saklanyor. Farkl lkelerde ayn isimde limanlar olabilir. Gemilerin tipleri (denizalt, yolcu, tekne, sava gemisi gibi.) var, hangi tiplerin varolduu listelenebilmeli.. Her geminin bal olduu bir liman vardr. Bir geminin bir liman ziyaret ile ilgili sadece giri ve k tarihleri saklanmal. Gemi ayn limana ok defalar urayabilir. Gemi hareketleri, geminin tarihesi ile tutulmal. Bu tarihe bilgisi geminin hangi gn va zamanda hangi enlem boylamda bulunduu bilgilerinden rnekler saklamaktadr. Gemi tabiki ayn noktada farkl zamanlarda bulunabilir.

FIGURE 7.7 from Elamsri/Navathe An ER schema for a SHIP_TRACKING database.

timestamp
Ship_movement

long.

latt. N
history
sname

owner

SHIP

N
T_giri

gemi
ziyaret

T_k

N Liman

gemi
ziyaret

Bir geminin ziyarete balama tarihi sadece bir liman iin olabilir. O zaman VISITS varlk setinin bal olduu gl varlk seti SHIP yeterli.

Tarih(Giri)

T_k

1 Liman

Example-9 Figure 3.17, Elmasri/Navathe book

Example 10

Adaylarn irketler ile yaptklar grme ve teklif edilen i pozisyonunu takip etmek istiyoruz.
Aday bir irketin birden ok blm ile grme yapabilir ve her blmden farkl pozisyon teklifler alabilir; bir blmden ancak 1 pozisyon teklifi alabilir. Teklif edilen pozisyonun maasi, zellikleri gibi bir takm zellikler daha tutulmak isteniyor.. Grmenin yapld gn (yl/ay/gn) bilgisi tutluyor. Ayn blm ile grme ancak farkl bir gnde olabiliyor. Gerek aday isimleri gerek irket isimleri sistemde biricik olduunu varsayabiliriz.. Blm hakknda bir bilgi tutulmuyor.

isim
ADAY

pozisyon
N
mlakat

N
BLM

isim
RKET

isim
yapt

Tarih(gn)

N
isim
RKET

isim

ADAY

grme

Tarih(gn) Blm
BT

N
MLAKAT

isim
POZSYON

teklif

maa

......

31