1 / 9

Bottom-Up-Analyse

FHTW Berlin Datenbanken Prof. Dr. Zschockelt. Reale betriebliche Datenstrukturen. Damit ist auf physischer Ebene die Modellierung einer DB möglich !. Bottom-Up-Analyse.

masato
Télécharger la présentation

Bottom-Up-Analyse

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. FHTW Berlin Datenbanken Prof. Dr. Zschockelt Reale betriebliche Datenstrukturen Damit ist auf physischer Ebene die Modellierung einer DB möglich ! Bottom-Up-Analyse spezielle Nutzersichten Formale Datenmodelle formale Ebene(deskriptive Regeln) z. B. Hierarchisches DM, Netzwerk-DM, Relationales DM methodische Ebene(Qualitätsverbesserung der Datenmodelle der semantischen Ebene) Normalisierung Physisches Datenmodell ( D a t e n b a n k ) Datenbasis eines betrieblichen Informationssystems

  2. - Klassifizierung - Generalisierung/Spezialisierung - Aggregation 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) 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

  3. Formalziele der Datenmodellierung FHTW Berlin Datenbanken Prof. Dr. Zschockelt 1. Redundanzfreiheit(möglichst nur einmalige Speicherung eines Datums im betrieblichen Informationssystem). 2. Integrität (innere Widerspruchsfreiheit (auch Konsistenz) der Datenbasis). 3. Integrationsfähigkeit der Daten. 4. Datenunabhängigkeit(Datenzugriff unabhängig von der Implementierung und physischen Datenstruktur). Die Präsentation der in der Datenbank gespeicherten Daten ist eine Aufgabe der relationalen Algebra.

  4. Anforderungen an Datenmodelle FHTW Berlin Datenbanken Prof. Dr. Zschockelt 1. Eignung, die Realität in Objekten und ihren Beziehungen zueinander abzubilden. 2. Erfassung der syntaktischen und semantischen Informationen über die Objekte und Beziehungen. 3. Ermöglichung einer Einzelobjektidentifikation und Mengenzugehörigkeit. 4. Formalisierbarkeit der Beschreibungsregeln des Modells.

  5. Grundmerkmale allgemeingültiger Datenmodelle FHTW Berlin Datenbanken Prof. Dr. Zschockelt 1. Struktur (structure):Modell muss Objekte, Attribute und Beziehungen darstellen können. 2. Bearbeitung (manipulation):Objekte und Attribute müssen änderbar (update), neuaufnehmbar (insert) und löschbar (delete) sein. 3. Integrität (integrity):Abhängigkeiten zwischen Objekten, Beziehungen und Attributen sowie Bedingungen für den Wertebereich (Domäne) der Attribute müssen darstellbar und überprüfbar sein.

  6. Das relationale Datenmodell Bezeichnung Lager Stückpreis Art_Nr ME Salz ( jodiert) 1 112 1,20 kg geschnitten) 2 kg 2,20 210 Brot ( 1 345 Zucker kg 1,40 897 Tonic "Bitterling“ kg 3 2,00 FHTW Berlin Datenbanken Prof. Dr. Zschockelt Die Tabelle (Relation) - Grundlage des relationalen Datenmodells Tabelle "ARTIKEL" Tabellenname = Relationenname Tabellenkopf = Relationenschema Relation ( Wertevorrat einer Spalte = Domäne ) Spalte = Attribut Zeile = Tupel Damit ist das Modell strukturell beschrieben, es folgt aber noch eine inhaltliche Ergänzung Primärer Schlüssel ( primary key )kann auch ein Verbund mehrerer Spalten sein Schreibweise als Relation: ARTIKEL(ART_NR,Bezeichnung,ME,Stückpreis,Lager)

  7. Das relationale Datenmodell FHTW Berlin Datenbanken Prof. Dr. Zschockelt Die Tabelle (Relation) - Grundlage des relationalen Datenmodells Charakteristische Relationeneigenschaftennach Codd sind: 1. Keine zwei Tupel einer Relation sind identisch, d. h. es existieren keine identischen Zeilen innerhalb einer Tabelle. 2. Die Reihenfolge der Tupel einer Relation ist ohne Belang, d. h. die Sortierfolge der Zeilen einer Tabelle ist ohne Bedeutung. 3. Die Reihenfolge der Attribute einer Relation ist ohne Belang, d. h. die Spalten einer Tabelle werden mit Namen und nicht mit ihrer Position bezeichnet. 4. Jeder Attributswert in der Relation ist elementar. Wertemengen innerhalb einer Spalte der Tabelle sind folglich nicht zulässig (siehe 1.NF).

  8. Das relationale Datenmodell FHTW Berlin Datenbanken Prof. Dr. Zschockelt Das Modell einer relationalen Datenbank (RDB) Das relationale Datenmodell (RDM) einer Datenbank entsteht durch die semantische Verknüpfung von n Relationen (Tabellen), z. B. Relation Dozent Relation Lehrveranstaltung Blau = primary key (Primärschlüssel) Rot = foreign key (Fremdschlüssel) Die Abhängigkeit eines Fremdschlüssels von einem Primär-schlüssel wird als referentielle Integrität bezeichnet.Z. B. ist die Relation Lehrveranstaltung referentiell abhängig von der Relation Dozent.

  9. Grundlegende Integritätsbedingungen desrelationalen Datenmodells FHTW Berlin Datenbanken Prof. Dr. Zschockelt Jede Relation muss einen (primären) Schlüssel besitzen, der einmalig innerhalb der Relation und nicht leer (not Null) ist  primary key. Jedes Objekt (Tupel) in einer Relation, das existentiell ab-hängig ist von einem Objekt in einer anderen Relation, muss auch in der Relation enthalten sein, welche die Menge der Objekte beinhaltet, auf die sich die Abhängigkeit bezieht (referentielle Integrität). Diese Beziehung wird über den foreign key geprüft. Beispiel: Eine Lehrveranstaltung kann vom Dozenten mit DozNr=102 nur gehalten werden, wenn ein Dozent mit DozNr=102 auch in der Relation DOZENT existiert.

More Related