Datenbanken 1 für Medieninformatiker. 2. Semantische Datenmodellierung 2.3. ERM-Modellierung 2.4. ERM-Erweiterungen

Größe: px

Ab Seite anzeigen:

Download "Datenbanken 1 für Medieninformatiker. 2. Semantische Datenmodellierung 2.3. ERM-Modellierung 2.4. ERM-Erweiterungen"

Edmund Weiss
vor 7 Jahren
Abrufe

1 Datenbanken 1 für Medieninformatiker 2. Semantische Datenmodellierung 2.3. ERM-Modellierung 2.4. ERM-Erweiterungen

2 ERM: Entität und Entitätstyp Patient Klaus Meier Station 53, Zi 227 Typ Patient: Geburtsdatum Aufnahme 227 Station 53, Zi 227 Typ Zimmer: Station ZiNr. (c)schmiedecke 06 DB1-4-ERM 2

3 ERM: Beziehung und Beziehungstyp liegt in Patient Klaus Meier Station 53, Zi 227 Belegung N Typ Patient: Geburtsdatum Aufnahme 227 Station 53, Zi Typ Zimmer: Station ZiNr. (c)schmiedecke 06 DB1-4-ERM 3

4 ERM-Modellelemente Entitätstyp näher definiert durch Stelligkeit und Typen (Attribute) Beziehungstyp näher definiert durch Stelligkeit, Kardinalität (Grad), Attribute u. ggf. Rollen Attribut Eigenschaft mit Wertebereich Rolle zusätzliche Spezifikation der Beteiligung einer Entity an einer Beziehung Achtung Falle: In der Relationenalgebra entspricht ein Entitätstyp einer Relation, nicht zu verwechseln mit Relationsship: Beziehung!!! (c)schmiedecke 06 DB1-4-ERM 4

5 Krankenhaus (c)schmiedecke 06 DB1-4-ERM 5

6 Entitytyp Bildung: Gleichartige Entities bilden einen Entitytyp Kriterium: Gleicher Sachverhalt, Gleiche Attribute Ein Schema enthält endlich viele Entitytypen Entitytypen müssen nicht disjunkt sein Beispiel: E1... Personen, E2... Studenten: E2 E1 Abgrenzung zu Attribut: Eigenständigkeit Relevante Merkmale (Eigenschaften) kontextabhängig Beispiel: Student, Fachbereich, Prüfungsfach, Note (c)schmiedecke 06 DB1-4-ERM 6

7 Semantik: Beziehungstyp: Anzahl der beteiligten Entitäten (Kardinalität) Wieviele Entities eines Entitytyps A können mit wievielen Entities eines Entitytyps B (oder A) in Beziehung stehen? Kardinalitäten (1,M,N-Notation): 1:1-Beziehung (Jedes Element von A steht mit genau einem Element von B in Beziehung und umgekehrt.) A 1 1 B 1:N-Beziehung (Jedes Element von A steht mit keinem, einem oder mehreren Element(en) von B in Beziehung. Ein Element von B steht mit einem Element von A in Beziehung.) A * 1 B M:N-Beziehung (Jedes Element von A steht mit keinem, einem oder mehreren Element(en) von B in Beziehung. Jedes Element von B steht mit keinem, einem oder mehreren Element(en) von A in Beziehung.) A * * B (c)schmiedecke 06 DB1-4-ERM 7

8 Beziehungstyp: Anzahl der beteiligten Entitätstypen rekursiv / unär M:N Teil (Stückliste Teil besteht aus Teilen) 1:N Abteilung (...gehört zu Abteilung) 1:1 Stellvertreter, Synonym binär "Normalfall" ternär,... n-när Lieferung (Teil, Lieferant, Produkt) Buchempfehlung (Dozent, LV, Buch) nicht ohne Informationsverlust in binäre Beziehungen aufbrechbar! (c)schmiedecke 06 DB1-4-ERM 8

9 Nochmal Krankenhaus Bett nach Entlassung entsorgen?? (c)schmiedecke 06 DB1-4-ERM 9

10 Modellierung geschieht unter bestimmten Aspekten UoD Universe of Discourse ist es relevant, dass ein Angehöriger auch einmal Patient war? ist es relevant, dass der Patient Arzt ist? Zeitpunkt / Zeitraumdarstellung soll die Datenbank jeweils nur den momentanen Zustand enthalten, oder auch vergangene?... (wir kommen darauf zurück) (c)schmiedecke 06 DB1-4-ERM 10

11 Modellierungsbeispiel Sales 1. Ein Unternehmen verkauft seine Artikel über ein Netz von Vertretern. 2. Vertreter sind hierarchisch jeweils einem Hauptvertreter unterstellt. Hauptvertreter müssen nicht unterstellt sein. 3. Jeder Vertreter betreut einen ihm zugewiesenen Kreis von Kunden. Ein Kunde wird genau von einem Vertreter betreut. 4. Kunden gehören zu einer Branche (z.b. EDV, Chemie, etc.) und werden in Abhängigkeit vom Auftragsvolumen einer Kundengruppe zugeordnet (Großabnehmer, Normalkunde, etc.). 5. Von den Kunden werden Aufträge entgegengenommen, die Artikel des Sortiments des Unternehmens in bestimmten Mengen umfassen. 6. Das Artikelsortiment des Unternehmens ist in verschiedene Produktgruppen unterteilt (Fahrzeuge, Ersatzteile, etc.). 7. Die Kundenaufträge werden je nach Bearbeitungsstand in 4 Status- Kategorien eingeordnet (erfasst, bestätigt, geliefert, fakturiert). Jeder Auftrag kann zu einem Zeitpunkt nur genau einen Status annehmen. (c)schmiedecke 06 DB1-4-ERM 11

12 ER-Modell Sales (c)schmiedecke 06 DB1-4-ERM 12

13 Modell-Diskussion Modellierung Vertreterhierarchie mehrstufige Hierarchie erfordert rekursive Beziehung Beziehung Auftrag-Status: Zeitpunkt / Zeitraum- Modell versch. Beziehungstypen Zeitraummodell erfordert zusätzliche Attribute (Zeiten) Beziehung zw. Artikel und Vertreter: es entsteht ein Zyklus redundant? ersetzbar durch einen (1,1) Navigationspfad (eindeutige Zuordnung)? - hier nicht Entität Aufpos in mat_inf weggelassen: aufgelöste m:n- Beziehung Eigenleben im konzeptuellen Modell nur durch zusätzliche Attribute, z.b. Teillieferungen, zu rechtfertigen. (c)schmiedecke 06 DB1-4-ERM 13

14 Sales II jetzt redundant? (c)schmiedecke 06 DB1-4-ERM 14

15 Modell-Diskussion Entitätstyp Auftragsposition: Eigenleben im konzeptuellen Modell durch zusätzliche Attribute, z.b. Teillieferungen, gerechtfertigt. Beziehung zw. Artikel und Vertreter: jetzt redundant? ja, ersetzbar durch einen eindeutigen Navigationspfad (c)schmiedecke 06 DB1-4-ERM 15

16 Sales III (c)schmiedecke 06 DB1-4-ERM 16

17 EERM - Beziehungstyp Kardinalität in (min,max)-notation Erweiterter Wertebereich: 0<= min <= 1 <= max <= * Mehrere Darstellungsvarianten, z.b.: (min,max) (1,1) (0,1) (1,*) (0,*) (1, c, m, mc) 1 c (Choice) m mc (Mult. Choice) Verwendung von Komplexitätsgraden neue Aussage: Für jeden in einer Beziehungstyp b auftretenden Entitytyp E gibt kgrad(e,b) an, mit wievielen Beziehungen des Typs b ein Entity e des Typs E minimal in Beziehung stehen muß und maximal in Beziehung stehen kann. Kgrad (E,b) = (min,max) (c)schmiedecke 06 DB1-4-ERM 17

18 Beziehungstyp Kardinalität, (min,max)-notation Achtung Seitentausch: 1,M,N-Notation A * 1 B hat Beziehung zu n... (min,max)-notation nimmt (0,n) mal teil A (1,1) (0,n) B (c)schmiedecke 06 DB1-4-ERM 18

19 SALES IV Achtung, Seitentausch!!! (c)schmiedecke 06 DB1-4-ERM 19

20 ERM-Modell SALES V (c)schmiedecke 06 DB1-4-ERM 20

21 SALES VI "Krähenfüße" (c)schmiedecke 06 DB1-4-ERM 21

22 Diskussion Existenzabhängigkeit Kardinalität (1,1) oder (1,n) bedeutet Kunde existenzabhängig von Vertreter Kunde existenzabhängig von Auftrag Auftrag existenzabhängig von Kunde Auftrag existenzabhängig von Status (c)schmiedecke 06 DB1-4-ERM 22

23 Gründe für Existenzabhängigkeiten Semantisch, entspricht dem UoD Kein Kunde ohne Auftrag Kein Auftrag ohne Status Temporär vielleicht sogar zulässig Formal - Entitätstyp ergänzt bestehenden Entitätstyp - Untertypen von Entitätstypen - Beispiel: allgemeiner Typ Person - Untertypen Vertreter, Kunde mit weiteren Attributen (c)schmiedecke 06 DB1-4-ERM 23

24 Is-a Attribute: Name Anschrift Telefon Attribute: Kd-Nr Branche Kundengruppe Umsatzerwartung Sonderkonditionen Attribute: MA-Nr Hauptvertreter Provision Eintrittsjahr (c)schmiedecke 06 DB1-4-ERM 24

25 Ableitung von Entitätstypen Is-A ist eine Ableitungsbeziehung Kann als Generalisierung oder Spezialisierung verstanden werden Unterscheidung T = total: Gesamtmenge wird Partitioniert P = partiell: nur Teilmenge partitioniert: es gibt nicht spezialisierte Elemente oder es gibt nicht modellierte Elemente Spezialisierung existenzabhängig von Obertyp (c)schmiedecke 06 DB1-4-ERM 25

26 Beispiel Tauschbörse Anforderungsdefinition Aufgabenstellung Zweck der Tauschboerse ist es, den Kunden ein Austausch ihrer Tauschobjekte, mit anderen Kunden zu ermöglichen. Anforderungen an die Benutzerinnen und Benutzer Das System ist Kunden zugänglich, die wenig oder mittlere EDV- Kenntnisse verfügen. Daher sind Bedienung und Bildschirme nach ergonomischen Gesichtspunkten benutzerfreundlich gestaltet. Die Tauschboerse ist im Netz der Berliner Schulen zu finden und zukünftig auch weltweit. Weiterhin wird ein Datenbankadmistrator festgelegt, der alle Rechte über die Tauschboerse hat und unqualifizierte Daten löschen kann. Quelle: Oberstufenzentrum Handel 1, Berlin (c)schmiedecke 06 DB1-4-ERM 26

27 Anforderungen an den Leistungsumfang Es zu jedem Tauschobjekt sind Daten einzugeben: Anbieter Eingliederung des Tauschobjektes in einen unserer 11 Bereiche: 1. Technik ( Bsp. Computer, Hifi, Elektro ) 2. Kleidung ( Anziehsachen, Schmuck ) 3. Möbel 4. Mobiles ( Bsp. Auto, Fahrrad, Motorrad ) 5. Dienstleistungen ( Bsp. schulische Hilfe, Partner ) 6. Rezepte 7. Medien ( Bsp. Video, Bücher, Zeitschriften ) 8. Sammlerobjekte ( Bsp. Briefmarken, Münzen ) 9. Musik ( Bsp. CD, Platten, MC, Minidisc, Konzertkarten ) 10. Fanartikel ( Bsp. Poster, T- Shirts ) 11. Sonstiges genaue Beschreibung ( z.b. erstes Album von Michael Jackson, Nike- Sweatshirt Größe 38 Farbe blau). Eingetragene Tauschobjekte können später noch bearbeitet werden. Für Verständigung zwischen den Tauschpartnern ist es notwendig, dass jeder Kunde seine -adresse angibt. Es können Tauschvorschläge angelegt werden, die bei erfolgtem Tausch gespeichert werden. (c)schmiedecke 06 DB1-4-ERM 27

28 Beurteilen Sie die Modellierung! (c)schmiedecke 06 DB1-4-ERM 28

29 ...nächstes Mal mehr: Attributerweiterungen Modellierungsbeispiel

30 (c)schmiedecke 06 DB1-4-ERM 30 Quelle: Jeckle, Datenbanken

Ähnliche Dokumente

3. Das Relationale Datenmodell

! " # $ # $ % # $ 3. Das Relationale Datenmodell 1. Datenstruktur und Integritätsbedingungen 2. Abbildung zwischen ERM und RDM 3. Implementierung in SQL 4. Anomalien und Normalformen des RDM 5. Relationenalgebra