R.Marti
4Datenbank-Entwurf
“ … leading inexorably toThe One Correct Data
Model“
InformationssystemefürIngenieureHerbstsemester 2016
4-1Entity-RelationshipModell
InformationssystemefürIngenieure(2016) – 4.1Datenbank-Entwurf(ERModell)R.Marti 2
ZieldesKapitels
• ErwerbenderFähigkeit,einenAusschnittderrealenWeltalskonzeptionellesDatenmodellzuformalisieren,unddiesenAusschnitt
– alsEntity-RelationshipModellgraphischdarzustellen
– ausdemEntity-RelationshipModelldieDeklarationderRelationen(bzw.Tabellen)abzuleiten
– die"Qualität"derDeklarationeinerRelationenaufgrundvonfunktionalenAbhängigkeitenzwischenAttributenauchohneEntity-RelationshipModellbeurteilenzukönnen(Normalisierungstheorie)
GrundfürdieVermittlungdiesesStoffs
• DaskonzeptionelleDatenmodellisteingeeignetesKommunikationsmittel– zwischenBenutzerCommunityund"BusinessAnalyst"einerseits
– zwischen"BusinessAnalyst"undDatenbank-Spezialistenbzw.Anwendungsporgrammierernandererseits
• DerDatenbank-EntwurfmitHilfedesEntity-RelationshipModellsführtohnevielTheorie(wieetwadieNormalisierungstheorie)zuqualitativgutenDatenbank-Strukturen
InformationssystemefürIngenieure(2016) – 4.1Datenbank-Entwurf(ERModell)R.Marti 3
EntwicklungszyklusvonSoftwareundDatenbanken
Bedarfs-analyse Entwurf Codierung Testen Deployment Betrieb
Daten-Bedarf
konzeptionellerEntwurf
logischerEntwurf
phyischerEntwurf
KonzeptionellesSchema
(DBMS-unabh.)
LogischesSchema
(DBMS-abh.)
PhysischesSchema
(DBMS-abh.)
(Tuning)
allgemeiner(traditioneller)SoftwareEntwicklungsprozess
EntwurfsprozessfürDatenbanken
“Deliverables”
Tablesetc
Indexesetc
➛ Entitytypes➛ Relationshiptypes
InformationssystemefürIngenieure(2016) – 4.1Datenbank-Entwurf(ERModell)R.Marti 4
Entity-Relationship(ER)Modell
• DasGegenstands-Beziehungs-Modell(Entity-Relationship Model,ER Model)isteinDBMS-unabhängigesDatenmodell,dasfürdenEntwurfderStruktureinerDatenbank,demkonzeptionellenSchema,verwendetwird.
• Die"Bausteine"derERModellssindallgemeinbekannteKonzepteunsererWelt,nichttechnischeodermathematischeKonzepte:
– Gegenständebzw.Objekte,diealsEntitäten (entities)bezeichnetwerden,indernatürlichenSprachemeistdurchSubstantiverepräsentiert
– Beziehungen (relationships)zwischenEntitäten,indernatürlichenSpracheoftdurchVerbenrepräsentiert.
• ImER-Modellkann"mehrBedeutung"(Semantik)repräsentiertwerdenalsimRelationenmodell(z.B.stehteineRelationfüreineEntitätodereineBeziehung),undmehrwertigeAttributesinderlaubt.
• ER Modelle(insbes.ER Diagramme)sindgeeignetfürKommunikationmitNutzern.
InformationssystemefürIngenieure(2016) – 4.1Datenbank-Entwurf(ERModell)R.Marti 5
Entität
EineEntität (entity) isteinkonkretesoderabstraktesObjekt (“Ding”)inderrealenWelt(odergarineinerVorstellungs-welt),welcheseindeutigidentifiziert werdenkann.
• die Person William Jefferson Clinton, US Präsident 1992 - 2000
• die Firma Zurich Insurance Group
• der Flug SR111 New York JFK nach Genf am 2./3. September 1998
• meine persönliche Kopie des Buchs“Loss Models: From Data to Decisions, 4th Ed.”
• Joe Doe’s Privatkonto 123-4567 bei UBS
• ...
Beispiele
Definition
InformationssystemefürIngenieure(2016) – 4.1Datenbank-Entwurf(ERModell)R.Marti 6
Attribut
EinAttribut isteineEigenschafteinerEntität.
EinAttribut istein“Behälter”füreinenAttributwert.
VerschiedeneEntitäten könnenverschiedeneWertefürdasgleicheAttributaufweisen.
• Family name ('Clinton', 'Gates', 'Hingis', … )
• Address ('Mythenquai 2, 8002 Zurich')
• Flight number ('SR111'), Flight date ('1998-09-02')
• ISBN ('0-471-21577-5'),Title ('Loss Models: From Data to Decisions, 4th Ed'), …
• Account number ('123-4567'), Account owner ('Joe Doe'),
• Balance ($987.65)
• ...
Beispiele
Definition
InformationssystemefürIngenieure(2016) – 4.1Datenbank-Entwurf(ERModell)R.Marti 7
Entitätstyp
• GleichartigeEntitäten,d.h.EntitätenmitdengleichenEigenschaften(Attributen,Teilnahmein➛Beziehungen,siehespäter),werdendurcheinenEntitätstyp(entitytype)E charakterisiert(vgl.SchemaeinerRelation).
• EineEntitätsmenge (entityset)ext(E) isteineMengevonEntitätendesTypsE (vgl.ExtensioneinerRelation)undstelltdenaktuellenZustandderDatenbankbezüglichdesEntitätstypsE dar.
• Person
• Organization
• Flight
• Book
• Account
BeispielevonEntitätstypen
Definition
InformationssystemefürIngenieure(2016) – 4.1Datenbank-Entwurf(ERModell)R.Marti 8
Identifikationsschlüssel
EinIdentifikationsschlüssel (identificationkey,identifier)bestehtauseinerMengevonAttributen,welchejedeEntitäteinesEntitätstyps innerhalbdiesesTypseindeutigidentifizieren.
• eineFlugnummer undeinDatum identifizierenzusammendie(effektiveodergeplante)Durchführung eines Flugs
• eineISBN identifizierteinenBuchtitel(nichtabereinindividuelles Buch imLaden/inpersönlichemBesitz!)
• EineKontonummer identifizierteinKonto(evt.abernurinnerhalbeinergegebenenBank)
OftsindzweiIdentifikationsmechanismennötig
• “natürliche”SchlüsselfürgelegentlicheBenutzer:Namen(Text-Datentyp)
• “künstliche”SchlüsselfürExpertenundinsbesonderedenComputer:Flugnummern,ISBNs,Kontonummern,Studentennummern,...EsistmeistenseineguteIdee,fürdenprimärenIdentifikationsschlüssel(oderTeiledavon)“künstliche”Identifikationsattributezuverwenden.
Beispiele
Definition
Bem.
InformationssystemefürIngenieure(2016) – 4.1Datenbank-Entwurf(ERModell)R.Marti 9
EntitätoderAttributwert?
• EineEntität hateineExistenz,dieunabhängigvonihrenEigenschaftenist.Siekannexplizit“erzeugt”undwieder“vernichtet”werden.
• EineEntität kannAttribute habenundin➛Beziehungen (siehespäter) teilnehmen.
• FürAttributwerte geltendieobigenEigenschaftennicht.
• LetztlichentscheidetderDatenbank-Designer,wasalsEntität undwasalsAttributwertaufgefasstwerdensoll.DieseEntscheidunghängtvomVerwendungszweckab.
Beispiel:Adresse
• Versand-Adressen:AdressealsAttributwert reichtimallgemeinenvöllig
• AdressenfürGrundbuchamt:ZusammenhängemitParzelle,Strasse,Besitzeretc.sindwichtigÞ AdressesolltealsEntität aufgefasstwerden
InformationssystemefürIngenieure(2016) – 4.1Datenbank-Entwurf(ERModell)R.Marti 10
GraphischeDarstellung:ER-Diagramm(Chen-Notation)
EntityType
MultiValAttr
IdAttribute
Symbole(Notationgem.Chen)
EntityType
Attribute
Attribute
Beispiele
Attribute
Attribute
StructAttr
AttributdesIdentifikations-schlüssels
mehrwertigesAttribut
strukturiertesAttribut
Entitätstyp(mitAttributen)
Entitätstyp
Department
DeptNo
DeptName
Rooms
Employee EmpNo
EmpName First
Last
Address
Bemerkung:Attributewerden– zumindestindieserForm– ininderPraxisseltenangezeigt,daDiagrammemitAttributenraschunübersichtlichwerden
z.B.NamenderAutoreneinesBuchs
z.B.Datum(Tag,Monat,Jahr)
InformationssystemefürIngenieure(2016) – 4.1Datenbank-Entwurf(ERModell)R.Marti 11
Beziehung,Beziehungstyp
• EineBeziehung (relationship)erstellteinenZusammenhangzwischenzweiodermehrerenEntitätenmiteinerspezifischenBedeutung.
• GleichartigeBeziehungenwerdenzueinemBeziehungstyp (relationshiptype)zusammengefasst,derdurchAngabederbeteiligtenEntitätstypen (sowieallfälligerRollennamen)definiertwird.
• Die Person 'Stuart A. Klugman' ist Autor des Buchs 'Loss Models: … , 4th Ed'
• Die Person 'Joe Doe' ist Eigentümer des Accounts 1234
• Die Person 'Tim Cook' (in der Rolle Vorgesetzter) ist Chef der Person 'Jonathan Ive' (in der Rolle Untergebener)
• EntitätenwerdentendentielldurchSubstantiverepräsentiert.BeziehungenwerdentendentielldurchVerben(z.B."schreibt")repräsentiert,allenfallsdurchAusdrückemit"ist"("istAutor")oder"hat"("hatAutor").
Beispiele
Definition(informell)
Bem.:
InformationssystemefürIngenieure(2016) – 4.1Datenbank-Entwurf(ERModell)R.Marti 12
Beziehung,Beziehungstyp,MengevonBeziehungen
• EineBeziehung zwischenEntitäten e1, ... , en (n ³ 2, oft n = 2)isteinn-Tupel < e1, ... , en > ,wobeijedesei eineEntität einesEntitätstyps Ei
(1 £ i £ n) ist.
• WennderselbeEntitätstyp ineinerBeziehungmehrfachauftritt(Ei und Ej mit i ¹ j),dannmüssendiesemehrfachauftretendenEntitätstypenmitHilfezusätzlicherRollennamen unterschiedenwerden.
• GleichartigeBeziehungenwerdenzueinemBeziehungstyp Rzusammengefasst,derdurchAngabederEntitätstypen E1, ... , En
undallfälligerRollennamen definiertwird.
EineMengevonBeziehungen (relationshipset)ext(R) zwischenEntitätenderEntitätstypenE1, ... , En isteineTeilmengedeskartesischenProduktsderbeteiligtenEntitätsmengen,ext(Ei) , 1 £ i £ n .SierepräsentiertdenaktuellenZustandderDatenbankbezüglicheinesBeziehungstyps.
Definition(formal)
Bem.:
InformationssystemefürIngenieure(2016) – 4.1Datenbank-Entwurf(ERModell)R.Marti 13
Beziehungstypen:AttributeundIdentifikationsschlüssel
• DieIdentifikationsattribute deraneinerBeziehung beteiligtenEntitätstypensindimpliziteAttribute einesBeziehungstyps.(DieseAttributewerdenaufER-Diagrammen nachChennichtgezeigt.)
• Beziehungstypen könnenzudemzusätzlicheexpliziteAttribute aufweisen.
• DasKonzeptdesIdentifikationsschlüssels kannfürBeziehungs-typen analogwiefürEntitätstypen definiertwerden:Er besteht aus einerMenge vonAttributen,welche jede Beziehung einesBeziehungstyps eindeutig identifiziert.
• Im ER-Modell nach Chen darf der IdentifikationsschlüsseldesBeziehungstypsnur aus Identifikationsattributen der ander Beziehung beteiligtenEntitätstypen gebildetwerden.
Bem.
InformationssystemefürIngenieure(2016) – 4.1Datenbank-Entwurf(ERModell)R.Marti 14
Beziehungstypen:ER-Diagramm(Chen-Notation)
EntityType
RelationshipType
Attribute
EntityType
Attribute
Employee manages Department
StartDate
Symbole
Beispiel
Bemerkung:EsgibtauchBeziehungstypenohne(explizite)Attribute.
expliziteAttribute
InformationssystemefürIngenieure(2016) – 4.1Datenbank-Entwurf(ERModell)R.Marti 15
Rekursiveundn-äre(n>2)Beziehungstypen
Employee
reportsto
Company
holds
OwnShipPct
Owner SubsidiarySubordinate Superior
Commodity
tradesSeller Buyer
RekursiverBeziehungstyp
TernärerBeziehungstyp
Quantity
Rollenname
InformationssystemefürIngenieure(2016) – 4.1Datenbank-Entwurf(ERModell)R.Marti 16
KardinalitätenbeibinärenBeziehungen
E R F E R F E R F1 1 M M1 M
1:1-Beziehungjedem e Î E darf immerhöchstens ein f Î F zugeordnetsein und jedem f Î F darf immerhöchstens ein e Î E zugeordnetsein
1:M-Beziehungjedem e Î E können mehrerefi Î F zugeordnet sein, aber jedemf Î F darf immer höchstens eine Î E zugeordnet sein
M:M-Beziehungjedem e Î E können mehrerefi Î F zugeordnet sein, und jedem f Î F können ebenfalls mehrereej Î E zugeordnet sein
InformationssystemefürIngenieure(2016) – 4.1Datenbank-Entwurf(ERModell)R.Marti 17
Angabe vonKardinalitäten bei Beziehungstypen:Beispiele
Employee
manages
Department
worksin
1
M
1
1
Employee
reportsto
Company
holds
OwnShipPct
Owner SubsidiarySubordinate Superior
M MM 1
InformationssystemefürIngenieure(2016) – 4.1Datenbank-Entwurf(ERModell)R.Marti 18
KardinalitätenbeiBeziehungenhöhererOrdnung
R
E1
En−1
1
Beieinemn-ärenBeziehungstyp stehtbeiEntitätstypEn danneine1,wennfürjedeWahl
vonEntitätene1, ... , en−1,wobeiei ElementdesEntitätstypsEi (1 £ i £ n−1) ist,höchstenseine Entitäten ausEn zugeordnetwerdenkann.
En
InformationssystemefürIngenieure(2016) – 4.1Datenbank-Entwurf(ERModell)R.Marti
KonsequenzendiesesDesigns(gemässklassischemER-Modell):
• DieBeziehungsmengeorders musseineTeilmengeallerPaarevonCustomer undProductsein
• DerIdentifikationsschlüsselvonorders besteht(maximal) aus{CusNo,PrdNo} – OrderDate(oderQty)darfnichtTeildesIdentifikationsschlüsselsein!
• MitanderenWorten:jederKunde dürfteeinProdukt nureinmalbestellen!(ausser"alte"Bestellungenwürdenüberschrieben)
19
EntitätoderBeziehung?(1)
Customer orders Product
OrderDate
M M
CusNo ... PrdNo ...
Alternative1: BestellungalsbinärerBeziehungstyp
Qty
InformationssystemefürIngenieure(2016) – 4.1Datenbank-Entwurf(ERModell)R.Marti
KonsequenzendiesesDesigns(gemässklassischemER-Modell):
• DerIdentifikationsschlüsselvonplacesbestehtaus{OrderNo}JederKunde kannbeliebigvieleOrdersplazieren.JedeOrderkannvongenaueinemKundengetätigtwerden.
• DerIdentifikationsschlüsselvoncomprisesbestehtaus{OrderNo,PrdNo}JedeOrder kannjedesProdukt enthalten,jedeseinmal(aberinbeliebigerQuantität)JedesProduktkannaufjederOrdererscheinen.
20
EntitätoderBeziehung?(2)
CusNo ...
Customer ProductOrder comprisesplacesM1 M M
OrderDate OrderNo ... PrdNo ...Qty
Alternative2: BestellungalsEntitätstyp
InformationssystemefürIngenieure(2016) – 4.1Datenbank-Entwurf(ERModell)R.Marti 21
EntitätoderBeziehung?(3)
CusNo ...
OrderDate
OrderNo
PrdNo ...
Qty
Alternative3: BestellungalsternärerBeziehungstyp
Customer
orders
ProductM M
M
Date
KonsequenzendiesesDesigns(gemässklassischemER-Modell):
• DieBeziehungsmengeorders musseineTeilmengeallerTripelvonCustomer,Product undDatesein
• DerIdentifikationsschlüsselvonorders bestehtaus{CusNo,PrdNo,OrderDate}.
• JederKunde darfeinProdukt proDatum nureinmalbestellen!(⇒ verwendeZeit!)
InformationssystemefürIngenieure(2016) – 4.1Datenbank-Entwurf(ERModell)R.Marti 22
EntitätoderBeziehung?(4)
Alternative3:
DiesesDesignwirdauchalsStarSchemabezeichnet.EsfindetvorallemimBereichDataWarehousing/ReportingAnwendung.
Customer
orders
ProductM M
M
TimePoint
InformationssystemefürIngenieure(2016) – 4.1Datenbank-Entwurf(ERModell)R.Marti 23
Umwandlung n-ärer Beziehungstypen inbinäre:Beispiel
M
Commodity
tradesSeller Buyer
M
Commodity
Seller BuyerTrade
comprises
buyssells
MM
1
M1 M 1
Rezept:Dern-äreBeziehungstyp wirdineinenEntitätstypumgewandelt,derübernbinäreBeziehungstypenmitdennursprünglichenEntitätstypen verbundenwird
InformationssystemefürIngenieure(2016) – 4.1Datenbank-Entwurf(ERModell)R.Marti 24
SchwacherEntitätstyp(1)
• EinEntitätstyp W heisstschwach (weak) wennzurIdentifikationder
Entitätenvon W derIdentifikationsschlüsseleinesanderen
EntitätstypsE beigezogenwerdenmuss.
• DerIdentifikationsschlüsseldesEntitätstypsDependentist
{Employee.EmpNo,DepName}
Definition
Chen-Notation Employee
ID
Employee
Dependent
kompakteVariante(ohneAttribute)
DepName
EmpNo
BirthDate
EmpName
IDID=Identifikation
DependentschwacherEntitätstyp
InformationssystemefürIngenieure(2016) – 4.1Datenbank-Entwurf(ERModell)R.Marti 25
SchwacherEntitätstyp(2)
• EntitäteneinesschwachenEntitätstypsW könnendemnachnur
abhängig voneinerEntität einesanderenEntitätstypsE existieren.WstehtineinerimplizitenM:1–Beziehung zuE undder
IdentifikationsschlüsselvonW enthältdenIdentifikations-schlüssel
vonE.
• [Kemper&Eickler2013]verwendenstattdessendiefolgendeNotation:
Definition
Bem.:
Employee
Dependent
relatesto
InformationssystemefürIngenieure(2016) – 4.1Datenbank-Entwurf(ERModell)R.Marti 26
Is-aBeziehung:GeneralisierungundSpezialisierung• EineGeneralisierung oderSupertypmehrererEntitätstypen
S1, ... , Sn isteinEntitätsstyp G,derallegemeinsamenEigenschaften(Attribute,TeilnahmeanBeziehungstypen)derEntitätstypenS1, ... , Sn
besitzt.DieEntitätstypenS1, ... , Sn auchalsSpezialisierung oderSubtyp desEntitätstypsG bezeichnet.
• DieEntitätstypenSi (1 £ i £ n) erben (inherit)dieEigenschaftendesgeneralisiertenEntitätstypsG.GeerbteAttribute (inkl.Identifikations-schlüssel)werdeninderDefinitionderSi nichtmehraufgeführt.
Definition
Employee
Person
Customer Supplier
Address
Name
Qual
Salary
Chen-Notation PersNo
SSN
BalanceDue
Rating
is-a
InformationssystemefürIngenieure(2016) – 4.1Datenbank-Entwurf(ERModell)R.Marti 27
Eigenschaftenvonis-aBeziehungen
• EineEntität e einesSubtyps S (1 ≤ i ≤ n) ist zwingendaucheine("isa")Entität desSupertyps G,d.h.e∈ S ⇒ e∈ G.
SomitgiltfürdieExtensionjedesSubtyps S desSupertypsG :ext(S) ⊆ ext(G)
• Füris-aBeziehungenS1, ... , Sn is-a G könnenzweiIntegritäts- bedingungenspezifiziertwerden:- Eineis-aBeziehungheisst disjunkt,wennfürjezweiverschiedeneSubtypenSi , Sj (1 ≤ i < j ≤ n) jederzeitgeltenmuss: ext(Si) Ç ext(Sj) = Æ .
- Eineis-aBeziehungheisst überdeckend fallsjederzeitgeltenmuss:È i=1
n ext(Si) = ext(G).
eSG
G
Sf
is-a
InformationssystemefürIngenieure(2016) – 4.1Datenbank-Entwurf(ERModell)R.Marti 28
Generalisierungshierarchien
• EskönnenGeneralisierungshierarchienaufgebautwerden:
Employee
Person
Customer Supplier
ContractorRegularEmp
is-a
is-a
InformationssystemefürIngenieure(2016) – 4.1Datenbank-Entwurf(ERModell)R.Marti 29
IntegrierteÜbung:EntwurfeinerhistorischenDBfürHurrikane
fürjedenPunktderTrajektorieeinesHurrikans:- Koordinaten- Datum+Zeit- Windstärke
fürjedenHurrikan:- Name- Jahr- totalerökonomischerSchaden- totalerVersicherungsschaden
InformationssystemefürIngenieure(2016) – 4.1Datenbank-Entwurf(ERModell)R.Marti 30
TransformationvonER-ModellenzuRelationen
• Grundidee
– 1Entitätstyp® 1Relation
– 1Beziehungstyp® 1Relation
• Ausnahmen (siehefolgendeFolien)
– JedesmehrwertigeAttributeinesEntitäts- oderBeziehungstypsergibteinezusätzlicheRelation
– EineRelationfüreinen1:M-BeziehungstypR zwischenEntitätstypenE undF kannallenfallsmitderRelationfürEntitätstypF (der"M-Seite")verschmolzenwerden,
sofernbeideRelationendengleichenPrimärschlüsselhaben.
• Primär- undFremdschlüsselkönnenausIdentifikationsschlüsseln undTeilnahmevonEntitätstypeninBeziehungstypenabgeleitetwerden
InformationssystemefürIngenieure(2016) – 4.1Datenbank-Entwurf(ERModell)R.Marti 31
VorgehenbeiTransformationER-Modell® Relationen
• Definition:Kern-Entitätstyp (kernelentitytype)EinEntitätstyp,dessenEntitätennichtvonderExistenzeinerEntitäteinesanderenEntitätstypsabhängen.
EinKern-EntitätstypistsomitwedereinschwacherEntitätstypnocheinSubtyp.
• VorgehenbeiTransformation
1. TransformiereKern-Entitätstypen
2. TransformiereSubtypen undschwacheEntitätstypen,dievonbereitstransformiertenEntitätstypenabhängen
3. TransformiereBeziehungstypen
InformationssystemefürIngenieure(2016) – 4.1Datenbank-Entwurf(ERModell)R.Marti 32
Transformationsregel1(Kern-Entitätstypen)
• E Kern-Entitätstyp mit- Identifikationsschlüssel K- einwertigem(Nicht-Identifikationsschlüssel-)Attribut A- mehrwertigeAttributewerdenvorerstignoriert
¯ Transformation
Relationenschema E({K, A}) mit- Primärschlüssel K- Fremdschlüssel--
• Bem.:Attributnamen(K fürPrimärschlüssel,A füreinwertigesAttributetc.)könnenauchfüreineMengevonAttributen(z.B.K = {K1, ... , Km})stehen
E K
A
M
wirdtransformiert
wirdnichttransformiert
InformationssystemefürIngenieure(2016) – 4.1Datenbank-Entwurf(ERModell)R.Marti 33
Transformationsregel2a(schwacheEntitätstypen)
• E einEntitätstypmit- Identifikationsschlüssel K
• W einschwacherEntitätstyp,- identifiziertdurchEntitätstyp EundIdentifikationsschlüsselattribut KW
- miteinwertigemAttribut A
¯ TransformationvonW
Relationenschema W({K, KW, A})- PrimärschlüsselK, KW
- FremdschlüsselW.K Í E.K
E
A
W KW
ID
wirdtransformiert
wirdnichttransformiert
M
K
InformationssystemefürIngenieure(2016) – 4.1Datenbank-Entwurf(ERModell)R.Marti 34
Transformationsregel2b(Subtypen)
• E einEntitätstyp mit- IdentifikationsschlüsselK
• S einSubtyp von EntitätstypE mit- einwertigem(nichtgeerbtem) AttributA
¯ TransformationvonS
Relationenschema S({K, A})- PrimärschlüsselK- FremdschlüsselS.K Í E.K
E K
AS
wirdtransformiert
wirdnichttransformiert
M
is-a
InformationssystemefürIngenieure(2016) – 4.1Datenbank-Entwurf(ERModell)R.Marti 35
Transformationsregel3(Beziehungstypen)
• E Entitätstypmit- IdentifikationsschlüsselKE
• F Entitätstypmit- IdentifikationsschlüsselKF
• R einBeziehungstypzwischenE undF mit- einwertigem,explizitemAttributA
¯ TransformationvonR
RelationenschemaR({KE, KF, A})- Primärschlüssel KE,KF (m:m-BeziehungzwischenE undF)
KF (1:m-BeziehungzwischenE undF)KE (m:1-BeziehungzwischenE undF)KE oderKF (1:1-BeziehungzwischenE undF)
- FremdschlüsselR.KE Í E.KE undR.KF Í F.KF
A
RE
KE
F
KF
wird transformiert
wird nichttransformiert
M
InformationssystemefürIngenieure(2016) – 4.1Datenbank-Entwurf(ERModell)R.Marti 36
Transformationsregel4(mehrwertigeAttribute)
• E Entitätstypmit- IdentifikationsschlüsselK- mehrwertigem,explizitemAttributM
¯ TransformationvonM
RelationenschemaEM({K, M})- PrimärschlüsselK, M- FremdschlüsselEM.K Í E.K
Bem.:FürjedesmehrwertigeAttributmusseineeigeneRelationerzeugtwerden– esseidenn,diemehrwertigenAttributegehörenlogischgesehenzusammen(wiez.B.eineAdressebestehendausAttributenStrassennameundHausnummer)
E K
M
wirdtransformiert
wirdnichttransformiert
InformationssystemefürIngenieure(2016) – 4.1Datenbank-Entwurf(ERModell)R.Marti 37
Transformationsprozess– einBeispiel
Employee
Departmentworks_inM 1reports_to
Subordinate
SuperiorM 1
KeyPosHolder Dependent
Department({DepNo, … })
Employee({EmpNo, … })
Dependent({EmpNo, DName, … })FK: Dependent.EmpNo Í Employee.EmpNo
KeyPosHolder({EmpNo, … })FK: KeyPosHolder.EmpNo Í Employee.EmpNo
WorksIn({EmpNo, DepNo, … })FK: WorksIn.EmpNo Í Employee.EmpNoFK: WorksIn.DepNo Í Department.DepNo
ReportsTo({SubordEmpNo, SuperiorEmpNo, … })FK: ReportsTo.SubordEmpNo Í Employee.EmpNoFK: ReportsTo.SuperiorEmpNo Í Employee.EmpNo
Projectassigned_toM M
Project({PrjNo, … })
AssignedTo({EmpNo, PrjNo, … })FK: AssignedTo.EmpNo Í Employee.EmpNoFK: AssignedTo.PrjNo Í Project.PrjNo
IDEmpNo ...
DepNo ...
PrjNo ...DName
is-a
InformationssystemefürIngenieure(2016) – 4.1Datenbank-Entwurf(ERModell)R.Marti 38
ResultatderTransformation
• DervorgestellteTransformationsprozesserzeugtRelationen,die"gutstrukturiert"sind,d.h.,diein→3.Normalform(3NF)sind (vgl.Unterkapitel4-2)
Ausnahme:FallsimER-ModellAttribute einem"falschen"Entitätstypzugeordnetsind (vgl.Unterkapitel4-2).
Beispiel:
• DieAnzahldervomTransformationsprozesserzeugten 3NF Relationenistjedochnichtminimal
– bei1:1-,1:m- sowiem:1-Beziehungen
– beiGeneralisierungen
SosindoftmehrJoinsnötig⇒ tendentiellhöhereKomplexität& schlecherePerformance.
• Der GraphdererzeugtenFremdschlüsselbedingungenistazyklisch.
Airport AptCode AptName CityName CountryCode
InformationssystemefürIngenieure(2016) – 4.1Datenbank-Entwurf(ERModell)R.Marti
Department
39
ZusammenlegenvonRelationen– 1:mBeziehungen(1)
Employee
works_inM 1
Employee({EmpNo, EmpName, Salary, … })
Diese Relationen haben den gleichen Schlüssel und können zusammengelegt werden:Employee({EmpNo, EmpName, Salary, DeptNo, … })
FK: Employee.DeptNo Í Department.DeptNo
WorksIn({EmpNo, DeptNo, … })FK: WorksIn.EmpNo Í Employee.EmpNoFK: WorksIn.DeptNo Í Department.DeptNo
Vorteile• weniger (LEFT OUTER) JOINs nötig ⇒ tendentiell geringere Komplexität, bessere Performance
Nachteile:• Es muss mit NULLs gearbeitet werden (Attribut Employee.DeptNo)• Datensätze "zusammengelegter" Relationen benötigen mehr Platz ⇒ evt schlechtere Performance• Falls die Beziehung von m:1 zu m:m wechselt, dann muss zur urprünglichen 3-Relationen-Lösung
zurückgekehrt werden.
InformationssystemefürIngenieure(2016) – 4.1Datenbank-Entwurf(ERModell)R.Marti 40
ZusammenlegenvonRelationen– 1:mBeziehungen(2)
Employee
Departmentworks_inM 1reports_to
Subordinate
SuperiorM 1
ReportsTo({SubordEmpNo, SuperiorEmpNo, … })FK: ReportsTo.SubordEmpNo Í Employee.EmpNoFK: ReportsTo.SuperiorEmpNo Í Employee.EmpNo
Employee({EmpNo, EmpName, Salary, DeptNo, … })FK: Employee.DeptNo Í Department.DeptNo
Auch Relation ReportsTo kann zur Relation Employee hinzugefügt werden:
Employee({EmpNo, EmpName, Salary, DeptNo, SuperiorEmpNo, … })FK: Employee.DeptNo Í Department.DeptNoFK: Employee.SuperiorEmpNo Í Employee.EmpNo
Vor- & Nachteile: vgl vorherige Folie
zusätzlicher Nachteil:• Der Graph der erzeugten Fremdschlüsselbedingungen wird zyklisch (Employee ® Employee).
Um das erste Tupel einfügen zu können, müssen Attribute im Fremdschlüssel (SuperiorEmpNo)NULLable sein.
InformationssystemefürIngenieure(2016) – 4.1Datenbank-Entwurf(ERModell)R.Marti 41
ZusammenlegungvonRelationen– Generalisierung(1)
Employee
Person
Customer Supplier
Address
Name
Qual
Salary
PersNo
SSN
BalanceDue
Rating
is-a
• Standard-TransformationergibtdieRelationen (undFKBedingungen)
Person({PersNo,Name,Address}) FK:--
Customer({PersNo,Rating,BalanceDue}) FK:Customer.PersNoÍ Person.PersNo
Supplier({PersNo}) FK:Supplier.PersNoÍ Person.PersNo
Employee({PersNo,SSN,Qual,Salary}) FK:Employee.PersNoÍ Person.PersNo
InformationssystemefürIngenieure(2016) – 4.1Datenbank-Entwurf(ERModell)R.Marti 42
ZusammenlegungvonRelationen– Generalisierung(2)
Employee
Person
Customer Supplier
Address
Name
Qual
Salary
PersNo
SSN
BalanceDue
Rating
is-a
Variante1:"Auflösen"derSubtypen(mitEinführungeinesSubtype-Attributs):
Person({PersNo,Name,Address,PersType, Subtype-Attribut (NOT NULL)Rating,BalanceDue, Customer Attribute(NULLable)SSN,Qual,Salary} ) Employee Attribute(NULLable)
AnwendungnurbeiRelationeneiner(a)disjunktenund(b)überlappenden
Generalisierung.
... andernfalls wäre PersType (a) mehrwertig und/oder (b) NULLable.
InformationssystemefürIngenieure(2016) – 4.1Datenbank-Entwurf(ERModell)R.Marti 43
ZusammenlegungvonRelationen– Generalisierung(3)
Employee
Person
Customer Supplier
Address
Name
Qual
Salary
PersNo
SSN
BalanceDue
Rating
is-a
• Variante2:"Auflösen"desSupertyps
Customer({PersNo,Name,Address,Rating,BalanceDue} )
Supplier({PersNo,Name,Address} )
Employee({PersNo,Name,Address,SSN,Qual,Salary} )
AnwendungnurbeiRelationeneiner(a)disjunktenund(b)überlappenden
Generalisierung.
... andernfalls (a) entsteht Redundanz und/oder (b) es könnten nicht alle Personenrepräsentiert werden.
InformationssystemefürIngenieure(2016) – 4.1Datenbank-Entwurf(ERModell)R.Marti 44
ZusammenlegungvonRelationen– Generalisierung(4)
• VorteilevonVarianten1und2
– JenachtypischenAnfragensindwenigerJoinsnötig
• NachteilevonVariante1(und,etwasweniger,Variante2)
– GewissereferentielleIntegritätsbedingungen(imBeispielinduziertdurchBeziehungstypenR1undR2)könnenaufderEbenederRelationennichtmehrpräzismodelliertwerden(PersonalsTeilnehmerinBeziehungR2stattausschliesslichEmployee)
Employee
Person
Customer Supplier
Address
Name
Qual
Salary
PersNo
SSN
BalanceDue
Rating
is-a
R1
R2
InformationssystemefürIngenieure(2016) – 4.1Datenbank-Entwurf(ERModell)R.Marti 45
WeitereOption:ReifizierteDarstellung(1)
Person
PersName
Person PersAttrValues PersAttr
AttrValue
Reifizierte Darstellung (auch Objekt-Attribut-Wert Tripel genannt):mit Attributen als Entitäten (res [lat] = Sache), Attributnamen als Attributwerte
FirstName Address BirthDatePersNo ⋅ ⋅ ⋅
PersNo AttrNo AttrName
3 ‘McNealy’ ‘Scott’ ‘Atherton’ 1954-11-13
3 ‘McNealy’ 1 ‘PersName’
3 1954-11-13 4 ‘BirthDate’
InformationssystemefürIngenieure(2016) – 4.1Datenbank-Entwurf(ERModell)R.Marti 46
WeitereOption:ReifizierteDarstellung(2)
• VorteilederreifiziertenDarstellung
– VeränderungendesSchemaseinerRelationsindsehreinfach
– TupelvonRelationensind"kleine",wasdieQuery-Performanceverbessert,wennnuraufeinAttributzugegriffenwird
– DieAnfrage"WelcheAttributehabenEntitätenderTypsT?"kanneinfachbeantwortetwerden.
• NachteilederreifiziertenDarstellung
– Anfragen,dien AttributwertevonEntitätenzurückgebensollen,sindkomplex(siebenötigenimwesentlichenn Joins)
InformationssystemefürIngenieure(2016) – 4.1Datenbank-Entwurf(ERModell)R.Marti 47
ER-Dialekte
EsexistierenverschiedeneDialektedesvorgestelltenER-Modells,teilweisemitErweiterungen,häufigaberauchmitEinschränkungen– letzteresinsbesonderebeiModellen,dieinderPraxiseingesetztwerden.
TypischeEinschränkungensind:
1. EssindnurBeziehungenzwischen2Entitätenzugelassen,nichtaberzwischenn (n > 2) Entitäten
2. Beziehungendürfenkeine„eigenen“Attributehaben
3. EssindkeinemehrwertigenAttributezugelassen
4. M:M-Beziehungstypensindnichtzugelassen
InformationssystemefürIngenieure(2016) – 4.1Datenbank-Entwurf(ERModell)R.Marti 48
EinschränkungaufbinäreBeziehungen
Commodity
tradesSeller Buyer
Commodity
Seller BuyerTrade
comprises
buyssells
Commodity
Seller BuyerTrade
n-äre Beziehungen werden als „assoziative“ Entität und n binärenBeziehungen dargestellt
Die Rhomben, welche die binären Beziehungen beschreiben, werden invielen Notationen weggelassen:
InformationssystemefürIngenieure(2016) – 4.1Datenbank-Entwurf(ERModell)R.Marti 49
Einschränkungauf(binäre)BeziehungenohneAttribute
Person Department
Person works-for Department
StartDate
Employment
Person Department
Employment
DeptIdEmpIdStartDate
ohne Attribute
mit Attributen
Beziehungen mit Attributen werden als „assoziative Entität“ dargestellt
InformationssystemefürIngenieure(2016) – 4.1Datenbank-Entwurf(ERModell)R.Marti 50
NotationenfürKardinalitäten
Jeder Entität e Î E
• ist höchstens eine Entität
• ist genau eine Entität
• sind beliebig viele Entitäten
• ist mindestens eine Entität
f Î F zugeordnet
E F
E F
E F
E F
CASE*Method Notation
InformationssystemefürIngenieure(2016) – 4.1Datenbank-Entwurf(ERModell)R.Marti 51
WeitereähnlicheNotationenfürKardinalitäten
Jeder Entität e Î E
• ist höchstens eine Entität
• ist genau eine Entität
• sind beliebig viele Entitäten
• ist mindestens eine Entität
f Î F zugeordnet
E F
E F
E F
E F
0..1
1..1
0..*
1..*
weitere Notationen:UML
InformationssystemefürIngenieure(2016) – 4.1Datenbank-Entwurf(ERModell)R.Marti 52
EinschränkungaufeinwertigeAttribute
Mehrwertige Attribute werden durch zusätzliche (schwache) Entitätendargestellt
Department DeptId
Name
Location
DeptLoc
DeptIdLocation
Department
DeptIdName
InformationssystemefürIngenieure(2016) – 4.1Datenbank-Entwurf(ERModell)R.Marti 53
Einschränkungauf1:m Beziehungen
Customer Product
Order
m:m Beziehungen werden als eine „assoziative Entität“ und zwei1:m Beziehungen dargestellt
Customer orders ProductM M
Customer ProductCompany
Owner Subsidiary
Company
holdsOwner Subsidiary
M M
Company
Ownership
Owner Subsidiary
InformationssystemefürIngenieure(2016) – 4.1Datenbank-Entwurf(ERModell)R.Marti 54
Zusammenfassung
DasER-ModellisteinetwasreichhaltigeresModellalsdasRelationenmodell,mitfolgendenBausteinen:
• Entitätstyp:legtdieCharakteristikgleichartigerEntitäten(Objekte)durchAttributeundTeilnahmeanBeziehungstypenfest("SchemafürEntitäten")
• Beziehungstyp:legtdieCharakteristikgleichartigerBeziehungenzwischenEntitätendurchAttribute,beteiligtenEntitätstypen,evtRollenundKardinalitätenfest("SchemafürBeziehungen")
• SpezielleArtenvonEntitätstypenundderenBeziehungenzuanderenEntitätstypen:- schwacheEntitätstypen,derenEntitätenvonanderenEntitätstypenabhängen- Subtypen,derenEntitätenEigenschaftenandererEntitätstypenerben
• DasER-Modellwirdvorallemverwendet- alsModellzumEntwurfvonDatenbank-Schemas- alsKommunikationsmittelmitdenBenutzern
Top Related