close

Anmelden

Neues Passwort anfordern?

Anmeldung mit OpenID

Die Europa-Universität Flensburg ist eine lebendige Universität in

EinbettenHerunterladen
V4 | Conceptual Data Modeling (ER-Model)!
1! | Housekeeping
Geo451 | Spatial Databases | HS14!
M. Tomko, R. Meile, Uni Zürich !
Deadlines!
Geo451 | HS14!
Universität Zürich!
4. Lecture Spatial Databases
Conceptual Data Modeling!
(Entity-Relationship-Model)!
Martin Tomko!
Dept. of Geography, University of Zürich!
!
Rolf Meile!
Eidg. Forschungsanstalt für Wald, Schnee und Landschaft!
!
Meysam Aliakbarian, Tutor!
Dept. of Geography, University of Zürich!
!
Simone Fuchs, Tutor!
Dept. of Geography, University of Zürich!
1
V4 | Conceptual Data Modeling (ER-Model)!
3! | Intro!
Geo451 | Spatial Databases | HS14!
M. Tomko, R. Meile, Uni Zürich !
Last week!
Phases of DB design!
– 
– 
– 
– 
Requirements analysis!
Conceptual DB design (e.g, ER-Model)!
Logical DB design (e.g., relational Model)!
Physical DB design (physical implementation)!
Requirements analysis!
–  Identification of user groups and application area!
–  Information gathering and structuring (use cases, interviews,
documentation…)!
–  Leads to conceptual design: identification of objects and attributes!
Intro to ER modeling!
– 
– 
– 
– 
Entities, Entity types, Entity sets!
Attributes und Attributte types!
Relationships, relationship types, relationship sets!
(Cardinality, Participation constraints)!
V4 | Conceptual Data Modeling (ER-Model)!
4!
Geo451 | Spatial Databases | HS14!
M. Tomko, R. Meile, Uni Zürich !
Different perspectives!
I see a green
amphibian with
a big mouth
2
V4 | Conceptual Data Modeling (ER-Model)!
http://www.infoworld.com/article/2611125/technology5!
consulting/state-dumping-ibm-after-it-project-runs-42months-late---60-million-over-budge.html
V4 | Conceptual Data Modeling (ER-Model)!
6!
Geo451 | Spatial Databases | HS14!
M. Tomko, R. Meile, Uni Zürich !
Geo451 | Spatial Databases | HS14!
M. Tomko, R. Meile, Uni Zürich !
http://en.wikipedia.org/wiki/
List_of_failed_and_overbudget_custom_software_projects
3
V4 | Conceptual Data Modeling (ER-Model)!
7!
Geo451 | Spatial Databases | HS14!
M. Tomko, R. Meile, Uni Zürich !
DB Design!
Real World!
Lecture 3!
Requirements Analysis!
Entities in the real world:!
Department head Müller,!
Employee Muster,!
Project ‘Budget 2014’!
Interview of users,
study of
documentation!
Database Requirements!
Lecture 4!
Written concise description of
requirements (data reqs and
functional [operations] reqs)!
Conceptual DB design!
Text analysis,!
Mental modeling!
ER-Model!
Lecture 5!
Lecture 5!
DBMS-independent!
DBMS-specific!
Logical DB design (data model
mapping)!
•  translation of model to
implementation!
•  Validation through
normalisation!
Entity types with attributes
and relationships!
DB-Schema!
(e.g. relational!
data model)!
Set of relations with attributes
(incl. data types + value
domains)!
Physical DB design!
Description of database
implementation (HW, indices, …)!
Database!
Implemented DB design,!
Tables (ordered) with rows and
columns!
Ü Elmasri & Navathe (2007): ch3.1, p.59f., part 3 (ch 10,11) !
V4 | Conceptual Data Modeling (ER-Model)!
8! | Intro!
Geo451 | Spatial Databases | HS14!
M. Tomko, R. Meile, Uni Zürich !
Conceptual DB design!
•  The construction of a model of
information stored in a database!
–  Conceptual representation of the DB!
–  Identification of the entities/Objects!
–  Identification odf the relationships
between the entities!
•  ER model (one possible
formalism)!
ER-Model “FIRMA”!
–  Others: UML ( for OR models),...!
4
V4 | Conceptual Data Modeling (ER-Model)!
9! | Einführung!
Geo451 | Spatial Databases | HS14!
M. Tomko, R. Meile, Uni Zürich !
Learning objectives 4!
ü  You will be able to create your own ER models!
ü  You will understand the relationship constraints!
ü  You will learn what are weak entity types!
ü  You will be able to model space in ER models!
ü  You will gain an understanding of entity integrity and
referential integrity!
V4 | Conceptual Data Modeling (ER-Model)!
10! |!
Geo451 | Spatial Databases | HS14!
M. Tomko, R. Meile, Uni Zürich !
Contents!
1.  Conceptual DB design
(ER-Model cont.)!
a. 
b. 
c. 
d. 
e. 
Relationship attributes!
Weak entity types and partial keys!
ER Diagram notation!
Refinement of the design of an ER-Diagram for DB „FIRMA“!
Modeling of spatial relationships!
2.  Intro Logical DB design
(DB schema in relational model)!
a.  Concepts of the relational model (Relation, Attribute, Tuple)!
b.  DB schema integrity !
i. 
ii. 
iii. 
iv. 
Constraints on value sets (domains)!
Key constraints!
Entity integrity!
Referential integrity!
5
V4 | Conceptual Data Modeling (ER-Model)!
11! | Relationship attributes
Geo451 | Spatial Databases | HS14!
M. Tomko, R. Meile, Uni Zürich !
Relationship attributes!
• 
Relationships can also have attributes!!
–  Attributes of 1:1 and 1:N relationships can be migrated to one of the
participating entity types.!
–  Attributes of M:N relationships must be specified as relationship attributes!
•  Can you move Start_Date to any entity below?!
Start_Date
N
EMPLOYEE
WORKS
_FOR
1
DEPARTMENT
Ü Elmasri & Navathe (2009): k3.4.4, p. 74f. !
V4 | Conceptual Data Modeling (ER-Model)!
12! | Relationship attributes
Geo451 | Spatial Databases | HS14!
M. Tomko, R. Meile, Uni Zürich !
Relationship attributes (1:1)!
•  Attributes of 1:1 relationships–
can be migrated to any entity.!
Start_Date1
–  E.g., Start date attribute for
relationship LEADS!
Start_Date3
LEADS_Start_Date3
LED_Start_Date3
LED_Start_date
LEADS_Start_Date
Start_date
EMPLOYEE
1
LEADS
1
DEPARTMENT
Ü Elmasri & Navathe (2009): k3.4.4, p. 74f. !
6
V4 | Conceptual Data Modeling (ER-Model)!
13! | Relationship attributes
Geo451 | Spatial Databases | HS14!
M. Tomko, R. Meile, Uni Zürich !
Relationship attributes (1:N)!
•  In case of 1:N relationships the
attribute can only be moved to
the entity on the N side.!
–  Start_Date for WORKS_FOR!
–  Each employee instance can
WORKS_FOR max one
DEPARTMENT. !
1
N
WORKS_FOR_Start_Date7
LEADS_Start_Date
Start_date
N
EMPLOYEE
WORKS
_FOR
1
DEPARTMENT
Ü Elmasri & Navathe (2009): k3.4.4, p. 74f. !
V4 | Conceptual Data Modeling (ER-Model)!
14! | Relationship attributes
Geo451 | Spatial Databases | HS14!
M. Tomko, R. Meile, Uni Zürich !
Relationship attributes (N:M)!
•  Attributes of M:N relationships
types must be specified as such.!
–  E.g.,: Attr. HOURS for relationship
WORKS_ON!
–  Number of hours that an
EMPLOYEE works on a given
PROJECT is determined through
an EMPLOYEE/PROJECT
combination
–  Note: Hours that an EMPLOYEE
worked on a PROJECT ≠ hours
that this EMPLOYEE worked in
total ≠ total man-hours of the
PROJECT !
M
N
HOURS
EMPLOYEE
N
WORKS
_ON
M
PROJECT
Ü Elmasri & Navathe (2009): k3.4.4, p. 74f. !
7
V4 | Conceptual Data Modeling (ER-Model)!
15! | Relationship attributes
Geo451 | Spatial Databases | HS14!
M. Tomko, R. Meile, Uni Zürich !
So what to do with relationship attributes ?!
EMPLOYEE
1:N
FNAME!
INITAL!
SURNAME!
ADRESS!
SEX!
STATUS!
AHV!
BDATE!
PK!
SUPERAHV! ANR!
WORKS_ON!
WORKS_ON_START_DATE!
DEPARTMENT
DEPTNAME!
N:M
DEPTNUMBER!
FK!
WORKS_ON
AHV!
PNAME!
PNR!
PNR!
HOURS!
FK!
PK!
PROJECT
PROJPLACE!
V4 | Conceptual Data Modeling (ER-Model)!
16! | Weak entity types and partial keys
DEPTNR!
Geo451 | Spatial Databases | HS14!
M. Tomko, R. Meile, Uni Zürich !
Room without building?!
BUILDING!
1!
IS_IN!
N!
ROOM!
Example: Room is in a building – if a
building is deleted from DB, all ROOMs
should also be discarded
8
V4 | Conceptual Data Modeling (ER-Model)!
17! | Weak entity types and partial keys
Geo451 | Spatial Databases | HS14!
M. Tomko, R. Meile, Uni Zürich !
Weak entity types!
• 
• 
• 
Weak entity types do not possess any own key attributes
(Entities with own key attributes = strong
entity types)!
An entity is weak if for its identification we
must refer to the key of another entity à
identifying or owner entity type (they have
an identifying relationship)!
Weak entities depend on the existence of
the owner entity (existence dependency) à total participation constraint!
Identifying
relationship
notation
BUILDING!
1!
IS_IN!
N!
Weak
entity type notation
V4 | Conceptual Data Modeling (ER-Model)!
18! | Weak entity types and partial keys
ROOM!
Geo451 | Spatial Databases | HS14!
M. Tomko, R. Meile, Uni Zürich !
Weak entity types!
Example of existential dependence of entity types:
BUILDING!
1!
IS_IN!
N!
ROOM!
EMPLOYEE!
1!
HAS_
DEPENDENT!
N!
DEPENDENT!
9
V4 | Conceptual Data Modeling (ER-Model)!
19! | Weak entity types and partial keys
Geo451 | Spatial Databases | HS14!
M. Tomko, R. Meile, Uni Zürich !
Total participation vs. weak entity type !
Quiz: Can you tell the difference between total participation and
a weak entity type?!
EMPLOYEE
!!
EMPLOYEE!
1!
1!
HAS_
DEPENDENT!
LEADS!
1!
N!
DEPARTMENT!
V4 | Conceptual Data Modeling (ER-Model)!
20! | Weak entity types and partial keys
DEPENDENT!
Geo451 | Spatial Databases | HS14!
M. Tomko, R. Meile, Uni Zürich !
Weak entity types!
Address
Beispiel – Entitätstyp ANGEHÖRIGER
mit Beziehung zu ANGESTELLTER
Department
Name
BUILDING
Capacity
1
IS_IN
N
ROOM
Name
Capacity
•  ROOM can only exist within a
building
•  Each ROOM depends on a
BUILDING with which it has a
relationship
•  Weak entities and their identifying
relationship are represented
through a double line
Type
10
V4 | Conceptual Data Modeling (ER-Model)!
21! | Weak entity types and partial keys
Geo451 | Spatial Databases | HS14!
M. Tomko, R. Meile, Uni Zürich !
Weak entity types!
Address
Example – Entity type ROOM with
relationship to BUILDING
Department
Name
BUILDING
Capacity
1
IS_IN
N
ROOM
Name
Capacity
•  A weak entity type has a partial
key:
•  An attribute is a partial key when
an attribute of the identifying
(owner) entity must be used in
combination to uniquely identify an
entity (instance)
•  Partial keys are highlighted by
underscoring with a dashed line
Type
V4 | Conceptual Data Modeling (ER-Model)!
22! | Weak entity types and partial keys
Geo451 | Spatial Databases | HS14!
M. Tomko, R. Meile, Uni Zürich !
Weak entity types!
Name
Type
Room
Address
Example – Entity type ROOM with
relationship to BUILDING
Department
Capacity
Name
BUILDING
Capacity
•  Weak entity types can be
sometimes modelled as complex
(multi-valued, composite) attributes
•  Better to model as standalone
entity type, in particular if it
participates in other relationships
•  Weak entities can own other weak
entities!
•  Y25 J80 - how many partial keys
do you see?
11
V4 | Conceptual Data Modeling (ER-Model)!
23! | Weak entity types and partial keys
Geo451 | Spatial Databases | HS14!
M. Tomko, R. Meile, Uni Zürich !
ER Diagram notations!
Entity type
Relationship type
Weak Entity type
Identifying relationsip
Attribute
Composite attribute
Key attribute
(partial)
Multi-valued
Attribute
Derived attribute
Total participation of E2 in R
E1
Cardinality ratio 1:N
for E1:E2 in R
E1
Structural constraint
(min, max) on participation of E in R
E2
R
1
R
R
V4 | Conceptual Data Modeling (ER-Model)!
24! | Refinement of the design of an ER-Diagram for DB „FIRMA“!
N
E2
(min, max)
E
Geo451 | Spatial Databases | HS14!
M. Tomko, R. Meile, Uni Zürich !
Excercise 4.1: ER design of the FIRMA DB (cont.)!
Draw the ER-Diagram for the FIRMA DB with 4 Entity types
and Attributes (still without relationships!) on your sheets
•  With pencil...
ABTEILUNG
Name, Nummer, {Standorte}, Manager, ManagerAnfangsdatum
PROJEKT
Name, Nummer, Standort, KontrollierendeAbteilung
ANGESTELLTER
Name (FName, MInit, LName), AHV, Geschlecht, Adresse, Gehalt,
Gdatum, Abteilung, Vorgesetzter, {ArbeitenAn(Projekt, Stunden)}
ANGEHÖRIGER
Angestellter, AngehörigerName, Geschlecht, Gdatum, Grad
12
V4 | Conceptual Data Modeling (ER-Model)!
25! | Refinement of the design of an ER-Diagram for DB „FIRMA“!
Geo451 | Spatial Databases | HS14!
M. Tomko, R. Meile, Uni Zürich !
Refinement of the DB FIRMA ER design!
FName
MInit
LName
Nummer
Adresse
Name
Geschlecht
Name
Gehalt
Standorte
AHV
Abteilung
ArbeitetAn
Projekt
Stunden
Vorgesetzter
ANGEHÖRIGER
Geschlecht
Gdatum
Manager
AnfangsDatum
ABTEILUNG
ANGESTELLTER
Gdatum
Manager
PROJEKT
Grad
Name
Kontrollierende
Abteilung
Standort
Nummer
Angestellter
AngehörigerName
V4 | Conceptual Data Modeling (ER-Model)!
26! | Refinement of the design of an ER-Diagram for DB „FIRMA“!
Geo451 | Spatial Databases | HS14!
M. Tomko, R. Meile, Uni Zürich !
Excercise 4.2: ER design of the FIRMA DB (relationships)!
We will analyse and design the relationships between the
entities...
•  With pencil...
13
V4 | Conceptual Data Modeling (ER-Model)!
27! | Refinement of the design of an ER-Diagram for DB „FIRMA“!
Geo451 | Spatial Databases | HS14!
M. Tomko, R. Meile, Uni Zürich !
Refinement of the DB FIRMA ER design!
1.  Die Firma ist in Abteilungen organisiert. Jede Abteilung hat eine eindeutige
1 und einen bestimmtem Bezeichnung, eine eindeutige Nummer
Angestellten, der die Abteilung leitet. Wir registrieren das Anfangsdatum, ab
dem dieser Angestellte die Leitung der Abteilung übernommen hat. Eine
Abteilung verfügt über mehrere Standorte.!
3
2.  Eine Abteilung kontrolliert eine Reihe von Projekten, die jeweils einen
eindeutigen Namen, eine eindeutige Nummer und einen einzigen Standort
haben.!
3.  Jeder Angestellte wird mit Namen, AHV-Nr., Adresse, Gehalt, Geschlecht
2
und Geburtsdatum gespeichert. 5 Ein Angestellter wird einer Abteilung zugewiesen, kann aber an
mehreren Projekten arbeiten, die nicht unbedingt alle von der gleichen
Abteilung kontrolliert werden. Wir verfolgen die Stundenzahl pro Woche, die
ein Angestellter an jedem Projekt arbeitet, und den unmittelbaren
Vorgesetzten jedes Angestellten.!
4
4.  Zu Versicherungszwecken sollen die 6
Familienangehörigen jedes Mitarbeiters mit Vorname, Geschlecht,
Geburtsdatum und Verwandtschaftsgrad zum jeweiligen Angestellten erfasst
werden.!
V4 | Conceptual Data Modeling (ER-Model)!
28! | Refinement of the design of an ER-Diagram for DB „FIRMA“!
Geo451 | Spatial Databases | HS14!
M. Tomko, R. Meile, Uni Zürich !
Refinement of the DB FIRMA ER design!
1.  Die Firma ist in Abteilungen organisiert. Jede Abteilung hat eine eindeutige
1 und einen bestimmtem Bezeichnung, eine eindeutige Nummer
Angestellten, der die Abteilung leitet. Wir registrieren das Anfangsdatum, ab
dem dieser Angestellte die Leitung der Abteilung übernommen hat. Eine
Abteilung verfügt über mehrere Standorte.!
2.  Eine Abteilung kontrolliert eine Reihe von Projekten, die jeweils einen
eindeutigen Namen, eine eindeutige Nummer und einen einzigen Standort
haben.!
3.  Jeder Angestellte wird mit Namen, AHV-Nr., Adresse, Gehalt, Geschlecht
und Geburtsdatum gespeichert. Ein Angestellter wird einer Abteilung zugewiesen, kann aber an
mehreren Projekten arbeiten, die nicht unbedingt alle von der gleichen
Abteilung kontrolliert werden. Wir verfolgen die Stundenzahl pro Woche, die
ein Angestellter an jedem Projekt arbeitet, und den unmittelbaren
Vorgesetzten jedes Angestellten.!
4.  Zu Versicherungszwecken sollen die Familienangehörigen jedes Mitarbeiters mit Vorname, Geschlecht,
Geburtsdatum und Verwandtschaftsgrad zum jeweiligen Angestellten erfasst
werden.!
14
V4 | Conceptual Data Modeling (ER-Model)!
29! | Refinement of the design of an ER-Diagram for DB „FIRMA“!
Geo451 | Spatial Databases | HS14!
M. Tomko, R. Meile, Uni Zürich !
Refinement of the DB FIRMA ER design!
FName
MInit
LName
Nummer
Adresse
Name
Geschlecht
Name
Gehalt
Standorte
AHV
Abteilung
ArbeitetAn
Projekt
Stunden
Vorgesetzter
ANGEHÖRIGER
Geschlecht
Gdatum
Manager
AnfangsDatum
ABTEILUNG
ANGESTELLTER
Gdatum
Manager
PROJEKT
Name
Grad
Kontrollierende
Abteilung
Standort
Nummer
Angestellter
AngehörigerName
V4 | Conceptual Data Modeling (ER-Model)!
30! | Refinement of the design of an ER-Diagram for DB „FIRMA“!
Geo451 | Spatial Databases | HS14!
M. Tomko, R. Meile, Uni Zürich !
Refinement of the DB FIRMA ER design!
1
FName
MInit
LName
Nummer
Adresse
Name
Geschlecht
Name
Gehalt
AHV
Standorte
Anfangsdatum
ANGESTELLTER
Gdatum
Abteilung
ArbeitetAn
1
LEITET
ABTEILUNG
1
Projekt
ANGEHÖRIGER
Gdatum
Manager
AnfangsDatum
Stunden
Vorgesetzter
Geschlecht
Manager
PROJEKT
Grad
Name
Kontrollierende
Abteilung
Standort
Nummer
Angestellter
AngehörigerName
15
V4 | Conceptual Data Modeling (ER-Model)!
31! | Refinement of the design of an ER-Diagram for DB „FIRMA“!
Geo451 | Spatial Databases | HS14!
M. Tomko, R. Meile, Uni Zürich !
Refinement of the DB FIRMA ER design!
FName
MInit
LName
Nummer
Adresse
Name
Geschlecht
Name
Gehalt
AHV
Standorte
Anfangsdatum
ANGESTELLTER
Gdatum
Abteilung
ArbeitetAn
1
LEITET
ABTEILUNG
1
Projekt
Stunden
Vorgesetzter
ANGEHÖRIGER
Geschlecht
Gdatum
PROJEKT
Grad
Name
Kontrollierende
Abteilung
Standort
Nummer
Angestellter
AngehörigerName
V4 | Conceptual Data Modeling (ER-Model)!
32! | Refinement of the design of an ER-Diagram for DB „FIRMA“!
Geo451 | Spatial Databases | HS14!
M. Tomko, R. Meile, Uni Zürich !
Refinement of the DB FIRMA ER design!
1.  Die Firma ist in Abteilungen organisiert. Jede Abteilung hat eine eindeutige
1 und einen bestimmtem Bezeichnung, eine eindeutige Nummer
Angestellten, der die Abteilung leitet. Wir registrieren das Anfangsdatum, ab
dem dieser Angestellte die Leitung der Abteilung übernommen hat. Eine
Abteilung verfügt über mehrere Standorte.!
2.  Eine Abteilung kontrolliert eine Reihe von Projekten, die jeweils einen
eindeutigen Namen, eine eindeutige Nummer und einen einzigen Standort
haben.!
3.  Jeder Angestellte wird mit Namen, AHV-Nr., Adresse, Gehalt, Geschlecht
2
und Geburtsdatum gespeichert. Ein Angestellter wird einer Abteilung zugewiesen, kann aber an
mehreren Projekten arbeiten, die nicht unbedingt alle von der gleichen
Abteilung kontrolliert werden. Wir verfolgen die Stundenzahl pro Woche, die
ein Angestellter an jedem Projekt arbeitet, und den unmittelbaren
Vorgesetzten jedes Angestellten.!
4.  Zu Versicherungszwecken sollen die Familienangehörigen jedes Mitarbeiters mit Vorname, Geschlecht,
Geburtsdatum und Verwandtschaftsgrad zum jeweiligen Angestellten erfasst
werden.!
16
V4 | Conceptual Data Modeling (ER-Model)!
33! | Refinement of the design of an ER-Diagram for DB „FIRMA“!
Geo451 | Spatial Databases | HS14!
M. Tomko, R. Meile, Uni Zürich !
Refinement of the DB FIRMA ER design!
2
FName
MInit
LName
Adresse
Name
Geschlecht
N
Gehalt
AHV
ARBEITET_FÜR
Nummer
1
Name
Standorte
Anfangsdatum
ANGESTELLTER
Gdatum
Abteilung
ArbeitetAn
1
LEITET
ABTEILUNG
1
Projekt
Stunden
Vorgesetzter
ANGEHÖRIGER
Geschlecht
Gdatum
PROJEKT
Name
Grad
Kontrollierende
Abteilung
Standort
Nummer
Angestellter
AngehörigerName
V4 | Conceptual Data Modeling (ER-Model)!
34! | Refinement of the design of an ER-Diagram for DB „FIRMA“!
Geo451 | Spatial Databases | HS14!
M. Tomko, R. Meile, Uni Zürich !
Refinement of the DB FIRMA ER design!
FName
MInit
LName
Adresse
Name
Geschlecht
N
Gehalt
AHV
ARBEITET_FÜR
Nummer
1
Name
Standorte
Anfangsdatum
ANGESTELLTER
Gdatum
ArbeitetAn
1
LEITET
Stunden
Vorgesetzter
ANGEHÖRIGER
Geschlecht
Gdatum
ABTEILUNG
1
Projekt
PROJEKT
Grad
Name
Kontrollierende
Abteilung
Standort
Nummer
Angestellter
AngehörigerName
17
V4 | Conceptual Data Modeling (ER-Model)!
35! | Refinement of the design of an ER-Diagram for DB „FIRMA“!
Geo451 | Spatial Databases | HS14!
M. Tomko, R. Meile, Uni Zürich !
Refinement of the DB FIRMA ER design!
1.  Die Firma ist in Abteilungen organisiert. Jede Abteilung hat eine eindeutige
1 und einen bestimmtem Bezeichnung, eine eindeutige Nummer
Angestellten, der die Abteilung leitet. Wir registrieren das Anfangsdatum, ab
dem dieser Angestellte die Leitung der Abteilung übernommen hat. Eine
Abteilung verfügt über mehrere Standorte.!
3
2.  Eine Abteilung kontrolliert eine Reihe von Projekten, die jeweils einen
eindeutigen Namen, eine eindeutige Nummer und einen einzigen Standort
haben.!
3.  Jeder Angestellte wird mit Namen, AHV-Nr., Adresse, Gehalt, Geschlecht
2
und Geburtsdatum gespeichert. Ein Angestellter wird einer Abteilung zugewiesen, kann aber an
mehreren Projekten arbeiten, die nicht unbedingt alle von der gleichen
Abteilung kontrolliert werden. Wir verfolgen die Stundenzahl pro Woche, die
ein Angestellter an jedem Projekt arbeitet, und den unmittelbaren
Vorgesetzten jedes Angestellten.!
4.  Zu Versicherungszwecken sollen die Familienangehörigen jedes Mitarbeiters mit Vorname, Geschlecht,
Geburtsdatum und Verwandtschaftsgrad zum jeweiligen Angestellten erfasst
werden.!
V4 | Conceptual Data Modeling (ER-Model)!
36! | Refinement of the design of an ER-Diagram for DB „FIRMA“!
Geo451 | Spatial Databases | HS14!
M. Tomko, R. Meile, Uni Zürich !
Refinement of the DB FIRMA ER design!
3
FName
MInit
LName
Adresse
Name
Geschlecht
N
Gehalt
AHV
ARBEITET_FÜR
Nummer
1
Name
Standorte
Anfangsdatum
ANGESTELLTER
Gdatum
ArbeitetAn
1
LEITET
ABTEILUNG
1
Projekt
1
Stunden
Vorgesetzter
KONTROLLIERT
N
ANGEHÖRIGER
Geschlecht
Gdatum
PROJEKT
Grad
Name
Standort
Nummer
Angestellter
AngehörigerName
Kontrollierende
Abteilung
18
V4 | Conceptual Data Modeling (ER-Model)!
37! | Refinement of the design of an ER-Diagram for DB „FIRMA“!
Geo451 | Spatial Databases | HS14!
M. Tomko, R. Meile, Uni Zürich !
Refinement of the DB FIRMA ER design!
FName
MInit
LName
Adresse
Name
Geschlecht
N
Gehalt
AHV
ARBEITET_FÜR
Nummer
1
Name
Standorte
Anfangsdatum
ANGESTELLTER
Gdatum
ArbeitetAn
1
LEITET
ABTEILUNG
1
Projekt
1
Stunden
Vorgesetzter
KONTROLLIERT
N
ANGEHÖRIGER
Geschlecht
Gdatum
PROJEKT
Grad
Name
Standort
Nummer
Angestellter
AngehörigerName
V4 | Conceptual Data Modeling (ER-Model)!
38! | Refinement of the design of an ER-Diagram for DB „FIRMA“!
Geo451 | Spatial Databases | HS14!
M. Tomko, R. Meile, Uni Zürich !
Refinement of the DB FIRMA ER design!
1.  Die Firma ist in Abteilungen organisiert. Jede Abteilung hat eine eindeutige
1 und einen bestimmtem Bezeichnung, eine eindeutige Nummer
Angestellten, der die Abteilung leitet. Wir registrieren das Anfangsdatum, ab
dem dieser Angestellte die Leitung der Abteilung übernommen hat. Eine
Abteilung verfügt über mehrere Standorte.!
3
2.  Eine Abteilung kontrolliert eine Reihe von Projekten, die jeweils einen
eindeutigen Namen, eine eindeutige Nummer und einen einzigen Standort
haben.!
3.  Jeder Angestellte wird mit Namen, AHV-Nr., Adresse, Gehalt, Geschlecht
2
und Geburtsdatum gespeichert. Ein Angestellter wird einer Abteilung zugewiesen, kann aber an
mehreren Projekten arbeiten, die nicht unbedingt alle von der gleichen
Abteilung kontrolliert werden. Wir verfolgen die Stundenzahl pro Woche, die
ein Angestellter an jedem Projekt arbeitet, und den unmittelbaren
Vorgesetzten jedes Angestellten.!
4
4.  Zu Versicherungszwecken sollen die Familienangehörigen jedes Mitarbeiters mit Vorname, Geschlecht,
Geburtsdatum und Verwandtschaftsgrad zum jeweiligen Angestellten erfasst
werden.!
19
V4 | Conceptual Data Modeling (ER-Model)!
39! | Refinement of the design of an ER-Diagram for DB „FIRMA“!
Geo451 | Spatial Databases | HS14!
M. Tomko, R. Meile, Uni Zürich !
Refinement of the DB FIRMA ER design!
4
FName
MInit
LName
Adresse
Name
Geschlecht
N
Gehalt
AHV
ARBEITET_FÜR
Nummer
1
Name
Standorte
Anfangsdatum
ANGESTELLTER
1
Gdatum
LEITET
ABTEILUNG
1
1
Projekt
ArbeitetAn
Vorgesetzter
KONTROLLIERT
Stunden
N
1
AUFSICHT
N
PROJEKT
Name
ANGEHÖRIGER
Geschlecht
Gdatum
Angestellter
Standort
Nummer
Grad
AngehörigerName
V4 | Conceptual Data Modeling (ER-Model)!
40! | Refinement of the design of an ER-Diagram for DB „FIRMA“!
Geo451 | Spatial Databases | HS14!
M. Tomko, R. Meile, Uni Zürich !
Refinement of the DB FIRMA ER design!
FName
MInit
LName
Name
Adresse
Geschlecht
N
Gehalt
AHV
ARBEITET_FÜR
Nummer
1
Name
Standorte
Anfangsdatum
ANGESTELLTER
1
Gdatum
LEITET
ABTEILUNG
1
1
Projekt
ArbeitetAn
KONTROLLIERT
Stunden
Vorgesetzter
1
Untergebener
AUFSICHT
N
N
PROJEKT
Name
ANGEHÖRIGER
Geschlecht
Gdatum
Angestellter
Standort
Nummer
Grad
AngehörigerName
20
V4 | Conceptual Data Modeling (ER-Model)!
41! | Refinement of the design of an ER-Diagram for DB „FIRMA“!
Geo451 | Spatial Databases | HS14!
M. Tomko, R. Meile, Uni Zürich !
Refinement of the DB FIRMA ER design!
1.  Die Firma ist in Abteilungen organisiert. Jede Abteilung hat eine eindeutige
1 und einen bestimmtem Bezeichnung, eine eindeutige Nummer
Angestellten, der die Abteilung leitet. Wir registrieren das Anfangsdatum, ab
dem dieser Angestellte die Leitung der Abteilung übernommen hat. Eine
Abteilung verfügt über mehrere Standorte.!
3
2.  Eine Abteilung kontrolliert eine Reihe von Projekten, die jeweils einen
eindeutigen Namen, eine eindeutige Nummer und einen einzigen Standort
haben.!
3.  Jeder Angestellte wird mit Namen, AHV-Nr., Adresse, Gehalt, Geschlecht
2
und Geburtsdatum gespeichert. 5 Ein Angestellter wird einer Abteilung zugewiesen, kann aber an
mehreren Projekten arbeiten, die nicht unbedingt alle von der gleichen
Abteilung kontrolliert werden. Wir verfolgen die Stundenzahl pro Woche, die
ein Angestellter an jedem Projekt arbeitet, und den unmittelbaren
Vorgesetzten jedes Angestellten.!
4
4.  Zu Versicherungszwecken sollen die Familienangehörigen jedes Mitarbeiters mit Vorname, Geschlecht,
Geburtsdatum und Verwandtschaftsgrad zum jeweiligen Angestellten erfasst
werden.!
V4 | Conceptual Data Modeling (ER-Model)!
42! | Refinement of the design of an ER-Diagram for DB „FIRMA“!
Geo451 | Spatial Databases | HS14!
M. Tomko, R. Meile, Uni Zürich !
Refinement of the DB FIRMA ER design!
FName
MInit
LName
Name
Adresse
Geschlecht
N
Gehalt
AHV
ARBEITET_FÜR
Nummer
1
Name
Standorte
Anfangsdatum
ANGESTELLTER
1
Gdatum
LEITET
ABTEILUNG
1
1
Projekt
ArbeitetAn
KONTROLLIERT
Stunden
Vorgesetzter
1
Untergebener
AUFSICHT
N
N
PROJEKT
Name
ANGEHÖRIGER
Geschlecht
Gdatum
Angestellter
Standort
Nummer
Grad
AngehörigerName
21
V4 | Conceptual Data Modeling (ER-Model)!
43! | Refinement of the design of an ER-Diagram for DB „FIRMA“!
Geo451 | Spatial Databases | HS14!
M. Tomko, R. Meile, Uni Zürich !
Refinement of the DB FIRMA ER design!
5
FName
MInit
LName
Adresse
Name
Geschlecht
N
Gehalt
AHV
ARBEITET_FÜR
Nummer
1
Name
Standorte
Anfangsdatum
ANGESTELLTER
1
LEITET
Gdatum
ABTEILUNG
1
1
Projekt
ArbeitetAn
KONTROLLIERT
Stunden
Vorgesetzter
1
Untergebener
AUFSICHT
Stunden
N
N
ARBEITET_AN
M
PROJEKT
N
Name
ANGEHÖRIGER
Geschlecht
Gdatum
Angestellter
Standort
Nummer
Grad
AngehörigerName
V4 | Conceptual Data Modeling (ER-Model)!
44! | Refinement of the design of an ER-Diagram for DB „FIRMA“!
Geo451 | Spatial Databases | HS14!
M. Tomko, R. Meile, Uni Zürich !
Refinement of the DB FIRMA ER design!
FName
MInit
LName
Name
Adresse
Geschlecht
N
Gehalt
AHV
ARBEITET_FÜR
Nummer
1
Name
Standorte
Anfangsdatum
ANGESTELLTER
1
LEITET
Gdatum
ABTEILUNG
1
1
KONTROLLIERT
Vorgesetzter
1
Untergebener
AUFSICHT
Stunden
N
N
M
ARBEITET_AN
PROJEKT
N
Name
ANGEHÖRIGER
Geschlecht
Gdatum
Angestellter
Standort
Nummer
Grad
AngehörigerName
22
V4 | Conceptual Data Modeling (ER-Model)!
45! | Refinement of the design of an ER-Diagram for DB „FIRMA“!
Geo451 | Spatial Databases | HS14!
M. Tomko, R. Meile, Uni Zürich !
Refinement of the DB FIRMA ER design!
1.  Die Firma ist in Abteilungen organisiert. Jede Abteilung hat eine eindeutige
1 und einen bestimmtem Bezeichnung, eine eindeutige Nummer
Angestellten, der die Abteilung leitet. Wir registrieren das Anfangsdatum, ab
dem dieser Angestellte die Leitung der Abteilung übernommen hat. Eine
Abteilung verfügt über mehrere Standorte.!
3
2.  Eine Abteilung kontrolliert eine Reihe von Projekten, die jeweils einen
eindeutigen Namen, eine eindeutige Nummer und einen einzigen Standort
haben.!
3.  Jeder Angestellte wird mit Namen, AHV-Nr., Adresse, Gehalt, Geschlecht
2
und Geburtsdatum gespeichert. 5 Ein Angestellter wird einer Abteilung zugewiesen, kann aber an
mehreren Projekten arbeiten, die nicht unbedingt alle von der gleichen
Abteilung kontrolliert werden. Wir verfolgen die Stundenzahl pro Woche, die
ein Angestellter an jedem Projekt arbeitet, und den unmittelbaren
Vorgesetzten jedes Angestellten.!
4
4.  Zu Versicherungszwecken sollen die 6
Familienangehörigen jedes Mitarbeiters mit Vorname, Geschlecht,
Geburtsdatum und Verwandtschaftsgrad zum jeweiligen Angestellten erfasst
werden.!
V4 | Conceptual Data Modeling (ER-Model)!
46! | Refinement of the design of an ER-Diagram for DB „FIRMA“!
Geo451 | Spatial Databases | HS14!
M. Tomko, R. Meile, Uni Zürich !
Refinement of the DB FIRMA ER design!
6
FName
MInit
LName
Name
Adresse
Geschlecht
N
Gehalt
AHV
ARBEITET_FÜR
Nummer
1
Name
Standorte
Anfangsdatum
ANGESTELLTER
1
LEITET
Gdatum
ABTEILUNG
1
1
KONTROLLIERT
Stunden
Vorgesetzter
1
AUFSICHT
N
N
M
ARBEITET_AN
PROJEKT
N
1
Angestellter
AngehörigerName
Name
ANGEHÖRIGE
_VON
Standort
Nummer
N
ANGEHÖRIGER
Geschlecht
Gdatum
Grad
23
V4 | Conceptual Data Modeling (ER-Model)!
47! | Refinement of the design of an ER-Diagram for DB „FIRMA“!
Geo451 | Spatial Databases | HS14!
M. Tomko, R. Meile, Uni Zürich !
Refinement of the DB FIRMA ER design!
FName
MInit
LName
Adresse
Name
Geschlecht
N
Gehalt
AHV
ARBEITET_FÜR
Nummer
1
Name
Standorte
Anfangsdatum
ANGESTELLTER
1
LEITET
Gdatum
ABTEILUNG
1
1
KONTROLLIERT
Stunden
Vorgesetzter
1
AUFSICHT
N
N
ARBEITET_AN
M
PROJEKT
N
1
Name
ANGEHÖRIGE
_VON
Standort
Nummer
N
ANGEHÖRIGER
AngehörigerName
Geschlecht
Gdatum
Grad
V4 | Conceptual Data Modeling (ER-Model)!
48! | Refinement of the design of an ER-Diagram for DB „FIRMA“!
Geo451 | Spatial Databases | HS14!
M. Tomko, R. Meile, Uni Zürich !
Refinement of the DB FIRMA ER design!
FName
MInit
LName
Name
Adresse
Geschlecht
N
Gehalt
AHV
ARBEITET_FÜR
Nummer
1
Name
Standorte
Anfangsdatum
ANGESTELLTER
1
LEITET
Gdatum
ABTEILUNG
1
1
KONTROLLIERT
Stunden
Vorgesetzter
1
AUFSICHT
N
N
M
ARBEITET_AN
PROJEKT
N
1
Name
ANGEHÖRIGE
_VON
N
Standort
HAT
Nummer
N
AngehörigerName
1
ANGEHÖRIGER
Geschlecht
Gdatum
STANDORT
Grad
Lookup-Liste
Stao_Id
Stao_Name
24
V4 | Conceptual Data Modeling (ER-Model)!
49! | Refinement of the design of an ER-Diagram for DB „FIRMA“!
Geo451 | Spatial Databases | HS14!
M. Tomko, R. Meile, Uni Zürich !
Refinement of the DB FIRMA ER design!
FName
MInit
LName
Name
Adresse
Geschlecht
N
Gehalt
AHV
ARBEITET_FÜR
Nummer
1
Name
Standorte
Anfangsdatum
ANGESTELLTER
1
LEITET
Gdatum
ABTEILUNG
1
1
M
KONTROLLIERT
Stunden
Vorgesetzter
1
AUFSICHT
HAT
N
N
N
M
ARBEITET_AN
PROJEKT
N
1
Name
ANGEHÖRIGE
_VON
N
Standort
HAT
Nummer
N
AngehörigerName
1
ANGEHÖRIGER
Geschlecht
Gdatum
V4 | Conceptual Data Modeling (ER-Model)!
50! | Refinement of the design of an ER-Diagram for DB „FIRMA“!
STANDORT
Grad
Lookup-Liste
Stao_Id
Stao_Name
Geo451 | Spatial Databases | HS14!
M. Tomko, R. Meile, Uni Zürich !
Alternatives for the ER Design!
•  In general, the ER design is an iterative process (refine,
refine, refine)!
•  The decision whether something is an entity, attribute, or
relationship type is a matter of choice and can change
during the process
!
25
V4 | Conceptual Data Modeling (ER-Model)!
51! | Refinement of the design of an ER-Diagram for DB „FIRMA“!
Geo451 | Spatial Databases | HS14!
M. Tomko, R. Meile, Uni Zürich !
Guidance for ER design!
1.  Concepts can first be modelled as an attribute and then be
refined as relationship if the attribute is later referred to by
another entity type!
2.  An attribute that is referred to by multiple entity types can
be turned into an entity type of its own!
– 
Example: Abteilung, Standort!
3.  ..and conversely, if an entity type ends up with a single
attribute and a single relationship, it should probably be
modelled as an attribute.!
!
V4 | Conceptual Data Modeling (ER-Model)!
52! | Modeling of spatial relationships!
Geo451 | Spatial Databases | HS14!
M. Tomko, R. Meile, Uni Zürich !
!
Modeling of spatial relationships 1!
•  Spatial entity types and relationship types!
–  ER modeling with spatial entities is not always possible!
–  WHY?!
•  Spatial entities are described through geometries
(amongst others) that are not simple data types, and
behave as objects!
•  The mathematical foundations of set theory are not
sufficient to model these relationship!
•  Spatial entity types have mutual topological relationships!
•  Spatial (incl. topological) relationships can be represented
in the ER diagram but not easily/directly translated into the
relational model and into the database !
•  Spatial entities can have both spatial and ordinary
relationships defined!!
BAUM
PARZELLE
26
V4 | Conceptual Data Modeling (ER-Model)!
53! | Modeling of spatial relationships!
Geo451 | Spatial Databases | HS14!
M. Tomko, R. Meile, Uni Zürich !
Spatial relationships!
If two entity types have a mutual spatial relationship, we have to decide
whether:!
–  Is the relationship in nature that of a „strong participation“ or a „part of“, in
which case we model it through the standard technique with cardinalities, PK,
FK... !
–  The realtionship is loosely spatial in the topological sense (e.g., lies in, close to,
adjacent to,...)
-> spatial relationship without cardinality!
–  both may be possible!
TreeType
! ParRefDat
Trigger
ParPoly
ParRefText
(Lecture 6)
TreeID
TreePoint
Stands on
PARCEL
TREE
1
M
Stands on
ParID
Primary key!
PARZELLE_PK!
Foreign key!
BAUM_PARZELLE_FK!
V4 | Conceptual Data Modeling (ER-Model)!
54! | Modeling of spatial relationships!
Geo451 | Spatial Databases | HS14!
M. Tomko, R. Meile, Uni Zürich !
Gemeinde Häggenschwil SG !
Ü 4 http://de.wikipedia.org/wiki/Häggenschwil!
27
V4 | Conceptual Data Modeling (ER-Model)!
55! | Modeling of spatial relationships!
Geo451 | Spatial Databases | HS14!
M. Tomko, R. Meile, Uni Zürich !
Spatial relationships!
–  Gemeinde ≠ Gemeinde polygon? Parcel ≠ Parcel polygon? Tree ≠ TreePoint?!
–  Modeling entities: a polygon of a Gemeinde can consist of multiple parts
(Häggenschwil SG)!
–  How do we model and store this relationship then?!
V4 | Conceptual Data Modeling (ER-Model)!
56! |!
Geo451 | Spatial Databases | HS14!
M. Tomko, R. Meile, Uni Zürich !
Summary 4.1: ER Modeling!
Conceptual ER models are represented through ER Diagrams. ER modelling
concerns the identification of:!
•  Entities, entity types and entiry sets!
–  Key attributes of the entity types!
• 
• 
Attributes are characterised by name, data type and value domain!
Attribute types:!
• 
Relationship types!
–  Simple, compound, multi-valued, complex!
–  Degree (recursive, binary, ternary, …)!
–  Structural constraints on relationship types!
•  Cardinality ratio constraint (1:1, 1:N, M:N for binary relationships)(max participation)!
•  Participation constraint (total, partial)(min participation)!
• 
Weak entity types !
–  A identifying entity must be referenced to identify a weak entity !
–  The primary key of an identifying entity together with a partial partial key together
uniquely identify a tuple.!
• 
Spatial relationship – compute relationship based on topological relationship!
28
V4 | Conceptual Data Modeling (ER-Model)!
57!
Geo451 | Spatial Databases | HS14!
M. Tomko, R. Meile, Uni Zürich !
DB Design!
Real World!
Lecture 3!
Requirements Analysis!
Entities in the real world:!
Department head Müller,!
Employee Muster,!
Project ‘Budget 2014’!
Interview of users,
study of
documentation!
Database Requirements!
Lecture 4!
Written concise description of
requirements (data reqs and
functional [operations] reqs)!
Conceptual DB design!
Text analysis,!
Mental modeling!
ER-Model!
Lecture 5!
Lecture 5!
DBMS-independent!
DBMS-specific!
Logical DB design (data model
mapping)!
•  translation of model to
implementation!
•  Validation through
normalisation!
Entity types with attributes
and relationships!
DB-Schema!
(e.g. relational!
data model)!
Set of relations with attributes
(incl. data types + value
domains)!
Physical DB design!
Description of database
implementation (HW, indices, …)!
Database!
Implemented DB design,!
Tables (ordered) with rows and
columns!
Ü Elmasri & Navathe (2007): ch3.1, p.59f., part 3 (ch 10,11) !
V4 | Conceptual Data Modeling (ER-Model)!
58! |!
Geo451 | Spatial Databases | HS14!
M. Tomko, R. Meile, Uni Zürich !
Contents!
1.  Conceptual DB design
(ER-Model cont.)!
a. 
b. 
c. 
d. 
e. 
Relationship attributes!
Weak entity types and partial keys!
ER Diagram notation!
Design of an ER-Diagram for DB „FIRMA“!
Modeling of spatial relationships!
2.  Intro Logical DB design
(DB schema in relational model)!
a.  Concepts of the relational model (Relation, Attribute, Tuple)!
b.  DB schema integrity !
i. 
ii. 
iii. 
iv. 
Constraints on value sets (domains)!
Key constraints!
Entity integrity!
Referential integrity!
29
V4 | Conceptual Data Modeling (ER-Model)!
59! | Logical DB Design!
Geo451 | Spatial Databases | HS14!
M. Tomko, R. Meile, Uni Zürich !
Intro to Logical DB Design!
FName
MInit
LName
Adresse
Name
Geschlecht
N
AHV
DB Schema of a relational model!
Nummer
1
ARBEITET_FÜR
Gehalt
Name
Standorte
Anfangsdatum
ANGESTELLTER
1
ABTEILUNG
1
LEITET
Gdatum
1
KONTROLLIERT
Stunden
1
AUFSICHT
N
N
M
ARBEITET_AN
PROJEKT
N
1
Name
ANGEHÖRIGE
_VON
Standort
Nummer
N
AngehörigerName
Geschlecht
ANGEHÖRIGER
Gdatum
Grad
“Key”!
“Relation”!
“Integrity”!
V4 | Conceptual Data Modeling (ER-Model)!
60! | Concepts!
“Tuple”!
“Attribute”!
Geo451 | Spatial Databases | HS14!
M. Tomko, R. Meile, Uni Zürich !
Relation!
• 
The relational model represents the DB as a collection of relations.!
– 
– 
– 
– 
Informally, a relation resembles a table, such as an Excel spreadsheet.!
Formally, a a row is called a Tuple, a column an Attribute, and the table a Relation.!
One tuple describes one entity or one relationship.!
Degree (= arity) of schema = number of attributes!
Describes the relation
Relation name
Attributes
(Columns)
Relation schema
Tuple
(rows)
Relation!
Ü Elmasri & Navathe (2009): k5.1, p.134f.!
30
V4 | Conceptual Data Modeling (ER-Model)!
61! | DB schema integrity!
Geo451 | Spatial Databases | HS14!
M. Tomko, R. Meile, Uni Zürich !
Consistency and integrity!
•  Consistency: a DB is consistent if it satisfies all constraints
specified in the model (implicit) or the schema (explicit) – the
DB is then free of data conflicts (valid state):!
–  No redundancy (multiplicity of storage)!
–  No conflicting entries!
•  Integrity constraints: rules ensuring the consistency of all
entries in the database - both data elements and
relationships!
–  E.g., Primary key cannot be NULL!
–  E.g., Age of an EMPLOYEE is above 16!
•  We now discuss the explicit (schema) constraints!
V4 | Conceptual Data Modeling (ER-Model)!
62! | DB schema integrity!
Geo451 | Spatial Databases | HS14!
M. Tomko, R. Meile, Uni Zürich !
i. Domain constraints!
•  Specifies, that within each tuple in a given relation, the value
of an attribute A is always from the domain dom(A) of the
attribute value domain.!
–  The data types usually associated with domains!
• 
• 
• 
• 
Numbers, e.g., number(n,m)!
Characters, e.g., varchar2(n)!
Date, time, currency!
Value subsets of a data type (Age 16-65, temperature units - oC)!
–  Enumerated data types (key-value pairs: 1=small, 2=medium,
3=large)!
31
V4 | Conceptual Data Modeling (ER-Model)!
63! | DB schema integrity!
Geo451 | Spatial Databases | HS14!
M. Tomko, R. Meile, Uni Zürich !
ii. Key constraints!
•  Key attributes must uniquely identify tuples in a relation
–  All tuples in a relation must be distinct - there cannot be two tuples with the same
value combination for all ist attributes
–  Key attributes are used for this
–  They can be used for linking tables (joins)
–  We will use the Oracle‘s ability to name keys: thus, Attribute name ≠ Key name
(naming convention)
ORT!
PLZ PERSON!
PERSNR Data level:!
NAME VORNAME ORTSCHAFT 6330 Cham PLZ 1 Von Gunten Reto 3000 2 Stofer Chris=an 6330 3 Stofer Silvia 6330 4 Ginzler Chris=an 9000 5 Burghardt Dirk 8001 9000 St. Gallen 8002 Zürich 6300 Zug 8400 Winterthur 8003 Zürich 3000 Bern Foreign key PERSON_ORT_FK!
8001 Zürich 8051 Zürich Primary key ORT_PK!
PERSON
Relational model:!
PERSNR!
ORT
NAME!
VORNAME!
V4 | Conceptual Data Modeling (ER-Model)!
64! | DB schema integrity!
PLZ!
PLZ!
ORTSCHAFT!
Geo451 | Spatial Databases | HS14!
M. Tomko, R. Meile, Uni Zürich !
iii. Entity integrity!
•  The Entity integrity constraint states, that no primary key
can be NULL!
EMPLOYEE!
ID!
Surname!
Department!
1!
Purves!
GIS!
2!
Schmid!
GIS!
3!
Reichenbacher!
GIVA!
Peters!
GIS!
10!
Peters!
11!
Schmid!
nicht möglich !!
GIS!
It is possible to not fill all the attributes in the table, but the primary
key must always be filled.!
32
V4 | Conceptual Data Modeling (ER-Model)!
65! | DB schema integrity!
Geo451 | Spatial Databases | HS14!
M. Tomko, R. Meile, Uni Zürich !
iv. Referential integrity!
•  Referential integrity constraints are specified between
two relations and maintain consistency between tuples in
the two relations!
•  Referential integrity
relates to the linkage of
the tables through
primary and foreign keys!
•  We can only select
foreign key values in
PERS (PERSON_ORT_FK)
from the set of existing
primary key values
(ORK_PK) in the referred
relation ORT!
ORT!
PLZ PERS!
•  The value domains of
the two keys must be
equal!
V4 | Conceptual Data Modeling (ER-Model)!
66! | Intro: Logical DB design!
PERSNR NAME VORNAME 1 Von Gunten Reto 3000 2 Stofer Chris=an 6330 3 Stofer Silvia 6330 4 Ginzler Chris=an 9000 5 Burghardt Dirk 8001 ORTSCHAFT 6330 Cham PLZ 9000 St. Gallen 8002 Zürich 6300 Zug 8400 Winterthur 8003 Zürich 3000 Bern Foreign key PERSON_ORT_FK!
8001 Zürich 8051 Zürich Primary key ORT_PK!
Geo451 | Spatial Databases | HS14!
M. Tomko, R. Meile, Uni Zürich !
Summary 4.3: Intro to Logical DB design!
•  The concepts of the relational model (Relation, Attribute,
Tuple, also see L1 – L3)!
•  Constraints on the DB Schema!
–  Value constraints!
–  Key constraints!
–  Entity integrity!
•  Each table must have a primary key to uniquely identify an entity!
•  Primary keys cannot be NULL!
–  Referential Integrity!
•  Specified between two relations – assures logical consistency between
relations (tables)!
•  Current foreign keys must always have values from the same domain as
the primary key of the referenced table!
•  The value of a FK in the current state of a relation R1 either occurs as a
value in the PK of the current state of a relation R2, or is NULL!
33
V4 | Conceptual Data Modeling (ER-Model)!
67!
Geo451 | Spatial Databases | HS14!
M. Tomko, R. Meile, Uni Zürich !
DB Design!
Real World!
Lecture 3!
Requirements Analysis!
Entities in the real world:!
Department head Müller,!
Employee Muster,!
Project ‘Budget 2014’!
Interview of users,
study of
documentation!
Database Requirements!
Lecture 4!
Written concise description of
requirements (data reqs and
functional [operations] reqs)!
Conceptual DB design!
Text analysis,!
Mental modeling!
ER-Model!
Lecture 5!
Lecture 5!
DBMS-independent!
DBMS-specific!
Logical DB design (data model
mapping)!
•  translation of model to
implementation!
•  Validation through
normalisation!
Entity types with attributes
and relationships!
DB-Schema!
(e.g. relational!
data model)!
Set of relations with attributes
(incl. data types + value
domains)!
Physical DB design!
Description of database
implementation (HW, indices, …)!
Database!
Implemented DB design,!
Tables (ordered) with rows and
columns!
Ü Elmasri & Navathe (2007): ch3.1, p.59f., part 3 (ch 10,11) !
V4 | Conceptual Data Modeling (ER-Model)!
68! | Summary!
Geo451 | Spatial Databases | HS14!
M. Tomko, R. Meile, Uni Zürich !
Resources!
•  Ramez A. Elmasri / Shamkant B. Navathe
(2009). Grundlagen von
Datenbanksystemen, Bachelorausgabe, 3.
aktualisierte Auflage.
Kapitel 3: Datenmodellierung mit Hilfe des
Entity-Relationship-Modells, 57-89. Kapitel 5.1, 5.2: Das relationale
Datenmodell, relationale
Einschränkungen und relationale
Algebra, 131-147.
34
Document
Kategorie
Kunst und Fotos
Seitenansichten
3
Dateigröße
3 290 KB
Tags
1/--Seiten
melden