Isi 04-1 Datenbank-Entwurf - ER-Modell -...

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


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


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.


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


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


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


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.


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


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)


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.:


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.:


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.


Beziehungstypen:ER-Diagramm(Chen-Notation)

EntityType

RelationshipType

Attribute

EntityType

Attribute

Employee manages Department

StartDate

Symbole

Beispiel

Bemerkung:EsgibtauchBeziehungstypenohne(explizite)Attribute.

expliziteAttribute


Rekursiveundn-äre(n>2)Beziehungstypen

Employee

reportsto

Company

holds

OwnShipPct

Owner SubsidiarySubordinate Superior

Commodity

tradesSeller Buyer

RekursiverBeziehungstyp

TernärerBeziehungstyp

Quantity

Rollenname


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


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


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



• DerIdentifikationsschlüsselvonplacesbestehtaus{OrderNo}JederKunde kannbeliebigvieleOrdersplazieren.JedeOrderkannvongenaueinemKundengetätigtwerden.

• DerIdentifikationsschlüsselvoncomprisesbestehtaus{OrderNo,PrdNo}JedeOrder kannjedesProdukt enthalten,jedeseinmal(aberinbeliebigerQuantität)JedesProduktkannaufjederOrdererscheinen.

20


CusNo ...

Customer ProductOrder comprisesplacesM1 M M

OrderDate OrderNo ... PrdNo ...Qty

Alternative2: BestellungalsEntitätstyp



CusNo ...

OrderDate

OrderNo

PrdNo ...

Qty

Alternative3: BestellungalsternärerBeziehungstyp

Customer

orders

ProductM M

M

Date


• DieBeziehungsmengeorders musseineTeilmengeallerTripelvonCustomer,Product undDatesein

• DerIdentifikationsschlüsselvonorders bestehtaus{CusNo,PrdNo,OrderDate}.

• JederKunde darfeinProdukt proDatum nureinmalbestellen!(⇒ verwendeZeit!)



Alternative3:

DiesesDesignwirdauchalsStarSchemabezeichnet.EsfindetvorallemimBereichDataWarehousing/ReportingAnwendung.

Customer

orders

ProductM M

M

TimePoint


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


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


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


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


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


Generalisierungshierarchien

• EskönnenGeneralisierungshierarchienaufgebautwerden:

Employee

Person

Customer Supplier

ContractorRegularEmp

is-a

is-a


IntegrierteÜbung:EntwurfeinerhistorischenDBfürHurrikane

fürjedenPunktderTrajektorieeinesHurrikans:- Koordinaten- Datum+Zeit- Windstärke

fürjedenHurrikan:- Name- Jahr- totalerökonomischerSchaden- totalerVersicherungsschaden


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


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


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


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


M

K


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


M

is-a


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


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



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


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


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.


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.


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



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.



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.



• 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


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’


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)


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


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:


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


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


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


EinschränkungaufeinwertigeAttribute

Mehrwertige Attribute werden durch zusätzliche (schwache) Entitätendargestellt

Department DeptId

Name

Location

DeptLoc

DeptIdLocation

Department

DeptIdName


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


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

Isi 04-1 Datenbank-Entwurf - ER-Modell -...

Documents

Transcript of Isi 04-1 Datenbank-Entwurf - ER-Modell -...