Transcript Dias nummer 1 - Webstorage

Modellering og diagrammer
Jesper Tørresø
DAB1 E08
17. september 2008
Lektion i dag
• Primære fokus på ERD diagrammer for at
koble udviklingsarbejdet til en
Relationsdatabase
• De samme begreber og teknikker kan
også bruges i forbindelse med UML
diagrammer, som vi ”kun” ser på
summarisk
• Modelleringsprincipperne er i fokus!!
Udviklingsforløb
Model
• A data model is a precise description of
information content
• Types of data models
– Conceptual: in terms that users will understand
– Logical: in terms that a relational database system will
understand
– Physical: in terms of the underlying computer
hardware and operating system
• Database schemas
– Schema is another word for model that implies that it
adheres to a particular strategy for defining models
Schema (Short hand form)
• A Schema is a data model that is intended to be used
with a database system
– External schemas are defined for the users of a database
– Logical schema defines the representation as a collection of
tables that are stored in a database server
– Internal schema defines the representation used by the
database server to store the tables in memory or files
External schema 1
Database
tables
External schema 2
External schema 3
External lev el
Logical to external mappings
Logical schema
Logical lev el
Internal to logical mapping
disk
Internal schema
Internal lev el
Modeldiagrammer
• Model kan vises med et eller flere
diagrammer:
– Entity Relationsship Diagram, ”Chen
notation”. Udviklet til Databaser og
”imødekommer” kravene fra en RDB
– ”Crows-Foot”
– IDEF1X
– UML (Scott Amber Agiledata.org)
ER Diagram komponeter
Generalisering /Specialisering
Aggregering
From time to time used..
SW-product
A
Program
User’s Guide
Ternary relationship
Ternary relationship
Ternary relationship
• Assertion 1: One engineer, working under
one mananger, could be working on many
projects
• Assertion 2: One project, under direction
of one manager, could have many
engineers
• Assertion 3: One engineer, working on
one project, must have only one manager.
FD (EmpId, ProjectName -> ManagerID)
N
Manager
1
Assigned to
N
Engineer
Project
Ternary relationship
Note on Ternary
In general, for a n-ary relationship, each
entity considered to be ”one” has its key
appering on the right side of exactly one
functional dependency (FD). No entity
considerede ”many” ever has its key
appear on the right side of an FD.
N
Manager
1
Assigen to
N
Project
Engineer
FD (EmpId, ProjectName -> ManagerID)