Nochmals zur Wiederholung: FHTW Berlin Datenbanken Prof. Dr. Zschockelt Nochmals zur Wiederholung: Das generelle Ziel der Datenmodellierung besteht darin, Informationen über die reale (betriebswirtschaftliche) Welt zu erfassen und zu ordnen, um daraus Maßnahmen zur Steuerung der Prozesse der realen Welt abzuleiten. Deshalb muss man Einen Teilbereich der Realität auf Grund des Bedeutungsinhaltes definieren und mit einem Namen identifizieren (Objektbildung) Die essentiellen Merkmale des Objektes als Attribut definieren und die Wertebereiche (Domänen) festlegen. Die Zweckbestimmung der Attribute definieren. Die Struktur der Attribute analysieren. Die Beziehungen zwischen den Objekten beschreiben. Da jedes Datenmodell im Endeffekt auf ein realisierbares formales Datenmodell ab-gebildet werden soll, beeinflussen insbesondere die Struktur der Attribute und der Beziehungen bereits frühe Phasen der Datenmodellierung.
Die semantische Datenmodellierung FHTW Berlin Datenbanken Prof. Dr. Zschockelt Die semantische Datenmodellierung … stellt sich das Ziel, aus semantischer Sicht (also in unserem Falle aus betriebswirt- schaftlich/wirtschaftsinformatorischer Sicht) gute (3NF) Datenmodelle zu erstellen. Es wird also folgender Teil der Datenmodellierung behandelt
Konzeptuelles Datenmodell Physisches Datenmodell FHTW Berlin Datenbanken Prof. Dr. Zschockelt Reale betriebliche Datenstrukturen Top-Down-Analyse Bottom-Up-Analyse Gesamtsicht spezielle Nutzersichten Semantische Datenmodelle Formale Datenmodelle formale Ebene (deskriptive Regeln) z. B. Hierarchisches DM, Netzwerk-DM, Relationales DM z. B. Entity-Relationship-Modell (ERM) methodische Ebene (Qualitätsverbesserung der Datenmodelle der semantischen Ebene) - Klassifizierung - Generalisierung/Spezialisierung - Aggregation Normalisierung Semantische Ebene (reales Datenmodell für einen Anwendungsfall) Konzeptuelles Datenmodell Physisches Datenmodell ( D a t e n b a n k ) Datenbasis eines betrieblichen Informationssystems
Das Entity-Relationship-Modell (ERM FHTW Berlin Datenbanken Prof. Dr. Zschockelt Das Entity-Relationship-Modell (ERM (nach CHEN: The Entity-Relationship Model – Toward a Unified Viewe of Data, 1976 – sekun-där u. a. Ferstl/Sinz: Softwarekonzepte der WI; Kempler/Eickler: Datenbanksysteme) Elemente: Entities (abgrenzbare Objekte) Entity Set Entity-Typ Relationship (Beziehung Relationship Set zwischen Entities) Relationship-Typ Entity-Name RS-Name Attribute (beschreiben Entities und RS) Beziehungstypen: 1:1 bijektive funktionale Beziehung n:1 funktionale Beziehung n:m nichtfunktionale Beziehung
Entity-Relationship-Modell Verwendungszweck von Attributen FHTW Berlin Datenbanken Prof. Dr. Zschockelt Entity-Relationship-Modell Verwendungszweck von Attributen Attribute beschreiben die essentiellen Merkmale eines Entitys aus der Sicht der späteren Nutzung des Datenmodells für einen betriebswirtschaftlich sinnvollen Zweck. Verwendungszweck Bemerkungen Identifikation F Eindeutigkeit unabdingbar (Constraint) F für Join erforderlich Klassifizierung F ermöglicht Selektion F für Gruppierung unabdingbar Systematisierung F ermöglicht Selektion F Beschreibung keine sinnvolle Selektion, (Deskription) Gruppierung und Join möglich
Entity-Relationship-Modell Wertigkeit von Attributen FHTW Berlin Datenbanken Prof. Dr. Zschockelt Entity-Relationship-Modell Wertigkeit von Attributen Attribute können sein einwertig oder mehrwertig Beispiel Personaldaten-Modell eines Unternehmens: - Personalnummer, - Name, - Geburtsdatum, - Geschlecht - Qualifikationen Art Fachrichtung Abschlussjahr - Forschungsgebiete Themen Patente Nur einwertige Attribute können ein Kandidat zur Objektidentifikation werden. Problem: Das relationale Datenmodell als formales Ziel-Datenmodell kann in einer Relation (Tabelle) nur einwertige Attribute darstellen (1NF).
Entity-Relationship-Modell Typen semantischer Beziehungen (1) FHTW Berlin Datenbanken Prof. Dr. Zschockelt Entity-Relationship-Modell Typen semantischer Beziehungen (1) Fahrer Kraftfahrzeug fährt Alfred Bruno Johann Max Siegfried ... Ford Fiesta BMW VW Golf I VW Golf II Renault Grad: 1 : 1 Verbindlichkeit: obligatorisch für beide Seiten ("muss") Jeder Fahrer (eines Fuhrparkes) fährt immer nur genau ein Kraftfahrzeug und jedes Kraftfahrzeug wird von genau einem Fahrer gefahren.
Entity-Relationship-Modell Typen semantischer Beziehungen (2) FHTW Berlin Datenbanken Prof. Dr. Zschockelt Entity-Relationship-Modell Typen semantischer Beziehungen (2) Mitarbeiter Funktion Dekan Studienberater SG-Sprecher ... führt aus Alfred Bruno Johann Max Siegfried Grad: 1 : 1 Verbindlichkeit: obligatorisch ("muss") nur für eine Seite (Funktion) Jede Funktion (eines Fachbereiches) wird durch genau einen Mitarbeiter ausgeführt. Ein Mitarbeiter darf höchstens eine Funktion haben, aber nicht jeder Mitarbeiter muss eine Funktion haben.
Entity-Relationship-Modell Typen semantischer Beziehungen (3) FHTW Berlin Datenbanken Prof. Dr. Zschockelt Entity-Relationship-Modell Typen semantischer Beziehungen (3) besitzt Mitarbeiter Leserausweis Alfred Bruno Johann Max Siegfried ... 020102 982721 876222 022233 ... Grad: 1 : 1 Verbindlichkeit: nichtobligatorisch ("kann") für beide Seiten. Jeder Mitarbeiter (einer Hochschule) kann genau einen Leserausweis für die Bibliothek besitzen. Jeder Leserausweis wird genau an eine Person vergeben. Leserausweise der Bibliothek können (müssen aber nicht unbedingt nur) an Mitarbeiter vergeben werden.
Entity-Relationship-Modell Typen semantischer Beziehungen (4) FHTW Berlin Datenbanken Prof. Dr. Zschockelt Entity-Relationship-Modell Typen semantischer Beziehungen (4) enthält Lager Artikel Mehl Salz Zucker Seife Zahnpaste Lebensmittel Chemie … Grad: 1 : n Verbindlichkeit: obligatorisch ("muss") für die n-Seite (Artikel). In jedem Lager können mehrere Artikel gelagert werden. Artikel werden immer gelagert, aber nur in genau einem Lager.
Entity-Relationship-Modell Typen semantischer Beziehungen (5) FHTW Berlin Datenbanken Prof. Dr. Zschockelt Entity-Relationship-Modell Typen semantischer Beziehungen (5) leiht Student Bücher Alfred Bruno Johann ... 12234556 12345566 23456789 23456777 65543312 34442112 ... Grad: 1 : n Verbindlichkeit: nichtobligatorisch ("kann") für die n-Seite (Bücher). Jeder Student kann mehrere Bücher leihen. Jedes Buch kann nur genau an einen Studenten ausgeliehen werden (muss aber nicht ausgeliehen sein).
Entity-Relationship-Modell Typen semantischer Beziehungen (6) FHTW Berlin Datenbanken Prof. Dr. Zschockelt Entity-Relationship-Modell Typen semantischer Beziehungen (6) enthält Lager Artikel Mehl Salz Zucker Seife Zahnpaste ... Südstadt Nordstadt Hafen ... Grad: n : m Verbindlichkeit: ohne Bedeutung, im Beispielfall nichtobligatorisch. In jedem Lager können mehrere Artikel gelagert werden. Artikel können in mehreren Lagern gelagert werden.
Entity-Relationship-Modell Auflösung mehrwertiger Attribute FHTW Berlin Datenbanken Prof. Dr. Zschockelt Entity-Relationship-Modell Auflösung mehrwertiger Attribute Beispiel Personaldaten-Modell eines Unternehmens: - Personalnummer, - Name, - Geburtsdatum, - Geschlecht - Qualifikationen Art Fachrichtung Abschlussjahr - Forschungsgebiete Themen Patente Person Qualifikation besitzt 1 n Themen Forschungs-gebiet Gruppen mehrwertiger Attribute werden als eigenes Entity mit einer 1:n-Bezie-hung zum (Master-) Objekt formuliert. Diese Art der Beziehung wird als Master-Detail-Beziehung bezeichnet.
Entity-Relationship-Modell Darstellung dynamischer Domänen FHTW Berlin Datenbanken Prof. Dr. Zschockelt Entity-Relationship-Modell Darstellung dynamischer Domänen Beispiel: Eine Artikelnummernsystematik soll als Domäne für die Relation "ARTIKEL" eines Unternehmens dienen. n hat Domäne 1 Artikel Artikelsystematik Domänen (Wertevorrat eines Attributes) werden bei großen Wertemengen und/oder hoher Änderungsfrequenz sinnvoll als eigene Entität dargestellt.
FHTW Berlin Datenbanken Prof. Dr. Zschockelt Präzisierung der Beziehungen im ERM durch Veränderung der Notationsform Einbeziehung der Verbindlichkeit (Optionalität) einerBeziehung wie folgt: Grad obligatorisch nicht obligatorisch 1 : 1 (1,1) (0,1) 1 : n (1, (0, * ) Beispiel: Deutung: Ein Auftrag muss aus einer (1) bis n () Position(en) bestehen. Eine Position muss immer genau einem Auftrag zugeordnet sein.
Beispiel eines einfachen ERM FHTW Berlin Datenbanken Prof. Dr. Zschockelt Beispiel eines einfachen ERM Rechnungslegung für eine Lieferung Kunde Power-Designer (Sybase) (0, ) * erhält (1,1) (1, ) * (1,1) Rechnung besteht aus Positionen Deutung: Ein Kunde erhält (für vorausgegangene Lieferungen) Rechnungen. Nicht jeder Kunde muss mindestens eine Rechnung erhalten. Jede Rechnung ist aber genau nur einem Kunden zugeordnet. Eine Rechnung besteht aus n Positionen, mindestens aber einer Posi-tion. Jede Rechnungsposition gehört nur exakt einer Rechnung an.
Entity-Relationship-Modell Darstellung rekursiver Beziehungen FHTW Berlin Datenbanken Prof. Dr. Zschockelt Entity-Relationship-Modell Darstellung rekursiver Beziehungen Beispiel Stückliste Bauteil * (1, ) * (1, ) besteht aus Wird verwendet in Struktur Neues Bezeichnungselement: Rolle
Zusammenfassender Überblick zum ERM FHTW Berlin Datenbanken Prof. Dr. Zschockelt Zusammenfassender Überblick zum ERM Entity-Typen dualen Typ rekursiven Typ können Beziehungen eingehen vom … bilden sachlogische Zusammenhänge ab zwischen … den Instanzen zweier unterschiedlicher Entity-Sets. den Instanzen des gleichen Entity-Sets. Diese können modifiziert (in mehrere Enty-Typen zerlegt) werden, infolge … Dadurch werden Rollen notwendig. mehrwertiger Attribute. Relationships mit Attributen. dynamischer Domänen. Rollen können vergeben werden, sind jedoch in der Regel nicht notwendig.
Qualitätsverbesserung von ER-Modellen FHTW Berlin Datenbanken Prof. Dr. Zschockelt Qualitätsverbesserung von ER-Modellen Mit dem Ziel der Erstellung qualitativ guter ERM werden die Konstruktions-operatoren Klassifizierung, Aggregation und Generalisierung/Spezialisierung (auch Vererbung bzw. Inheritance) benutzt. Von besonderer Bedeutung für die praktische Modellierung ist die Generalisierung/Spezialisierung. Beispiel: Das Personal eines Unternehmens besteht aus Arbeitern und Angestellten. Diese besitzen gemeinsame Attribute, unterscheiden sich jedoch auch bei den speziellen Attributen zur Lohn- bzw. Gehaltsberechnung Generalisierung Arbeitnehmer Angestellter Arbeiter Spezialisierung
Methodik der ER-Modellierung Wo ist der Anwender gefragt? FHTW Berlin Datenbanken Prof. Dr. Zschockelt Methodik der ER-Modellierung Wo ist der Anwender gefragt? Umfeld bestimmen (z. B. Abteilung Beschaffung). Wesentliche Objekte als Entity-Kandidaten wählen (z. B. Lieferanten, Artikel, Bestellungen). Prüfen, ob gewählte Objekte Entity-Sets sind. Wenn ja: Objekt wird Entity. Attribute zur Beschreibung des Entity ermitteln. Sind Attribute mehrwertig (z. B. Konten eines Lieferanten), wird die Gruppe mehrwertiger Attribute ein eigenes Entity (z. B. Bankverbindung). Sollen Attributswerte eines Entity-Sets aus einer Systematik gewählt werden (dynamische Domäne), wird die Systematik ein Entity (z. B. Bankleitzahlenverzeichnis). Beziehungen (Relationships) zwischen den Entities nach Grad (Cardinality) und Verbindlichkeit (Mandatory, Dependent) bestimmen. Sonderfall Vererbung (Inheritance) erkennen. Tools zur Datenmodellierung: http://www.datenmodelle.de/software.php