1. Ziel des Datenbankentwurfs

Save this PDF as:
 WORD  PNG  TXT  JPG

Größe: px
Ab Seite anzeigen:

Download "1. Ziel des Datenbankentwurfs"

Transkript

1 1. Ziel des Datenbankentwurfs Ziel ist der Aufbau eines Modells eines Teilbereiches der wahrnehmbaren Realität und Abbildung dieses Bereichs in Form von Daten, so dass diese nach verschiedensten Kriterien ausgewertet werden können. 1.1 Ein Beispiel Als Beispiel wollen wir ein (reales) Reisekostenformular betrachten und überlegen, wie wir dieses optimal speichern können. Zu unterscheiden sind Datenfelder und Daten: Im unausgefüllten Zustand besteht das Formular aus Datenfeldern Im ausgefüllten Zustand besteht das Formular aus Daten in Datenfeldern Beachten Sie: Viele Datenfelder bleiben hier leer

2 Es gibt Datenfelder, die in obigem Formular nur einmal auftreten (z. B. Rechnungsnummer und Name), und Datenfelder, die mehrmals auftreten. Als Kostenart gibt es z. B. "Tagegeld", "Übernachtung" und "Fahrtkosten". Das Datenfeld "Kostenart" taucht also mehrfach auf. Eine Gruppe von mehrfach auftretenden Datenfeldern nennt man Wiederholungsgruppe. Im Beispiel bilden also "Kostenart", "Anzahl", "Einzelvergütung" und "Gesamtvergütung" eine Wiederholungsgruppe 1.2 Abbildung in Form von Daten Eine Möglichkeit besteht darin, alle Daten einer bestimmten Rechnungsnummer in einer langen Zeile einer Tabelle einzutragen. Weitere Zeilen können Daten anderer Reisekostenabrechnungen enthalten. Reisekosten Datum Name Vorname Straße PLZ Ort Summe -> Rechnungsnummer Kelz Andreas Barerstr München <- Anzahl Tagegeld Einzelvergütung Tagegeld Gesamtvergütung Tagegeld Anzahl Übernachtung Einzelvergütung Übernachtung -> <- Gesamtvergütung Übernachtung Anzahl Fahrtkosten Einzelvergütung Fahrtkosten Gesamtvergütung Fahrtkosten Anzahl -> Sonstiges 1 <- Einzelvergütung Gesamtvergütung Sonstiges Sonstiges

3 Beachten Sie: Die Tabelle enthält nur die reinen Daten sowie die Bezeichnung der Datenfelder. Sie enthält keine Informationen über das Aussehen des ursprünglichen Formulars. Das Formular ist eine von vielen optischen Darstellungsmöglichkeiten der Daten in Tabellen Bei einer langen Wiederholungsgruppe wird die Tabelle sehr breit und es bleiben viele Datenfelder leer Wenn die Wiederholungsgruppe sehr viele verschiedene Werte enthalten kann, etwa Posten aus einem Versandkatalog mit Artikeln, wird die Tabelle in dieser Form sehr unhandlich Der Inhalt zweier Zeilen darf nicht identisch sein (jede Reisekostenabrechnung gibt es nur einmal) Eine zweite Möglichkeit bestünde darin, mehrere Zeilen für eine einzige Reisekostenabrechnung vorzusehen, die bis auf die Spalten der Wiederholungsgruppe identisch sind. Dabei werden nur die Teile der Wiederholungsgruppe eingetragen, die auch Daten enthalten. Reisekosten Datum Name Vorname Straße PLZ Ort Summe -> Rechnungsnummer Kelz Andreas Barerstr München Kelz Andreas Barerstr München 70 <- Kostenart Anzahl Einzelvergütung Gesamtvergütung Tagegeld Sonstiges Beachten Sie:

4 Dies reduziert die Anzahl leerer Datenfelder, führt aber dazu, dass zur Darstellung der gesamten Reisekostenabrechnung mehrere Zeilen berücksichtigt werden müssen Der Inhalt zweier Zeilen darf auch hier nicht identisch sein Eine dritte Möglichkeit besteht darin, die Wiederholungsgruppe von den anderen Daten zu trennen und in einer zweiten Tabelle unterzubringen. Reisekosten Datum Name Vorname Straße PLZ Ort Summe Rechnungsnummer Kelz Andreas Barerstr München 70 Positionen Rechnungsnummer Kostenart Anzahl Einzelvergütung Gesamtvergütung Tagegeld Sonstiges Beachten Sie: In der Tabelle "Positionen" wird die Rechnungsnummer nochmals wiederholt, um eine eindeutige Zuordnung der Positionen zu einer Reisekostenabrechnung zu erreichen Wie man die ermittelten Datenfelder systematisch und ideal auf Tabellen aufteilt, werden wir in Abschnitt 4 näher beleuchten. Als Grundlage der Betrachtungen werden wir dort die zweite der oben vorgestellten Möglichkeiten wählen, da die erste Möglichkeit bei einer Wiederholungsgruppe ein grundsätzlich falscher Ansatz ist (für jede Erweiterung der Wiederholungsgruppe muss die Struktur der Tabelle geändert werden!). Wir werden außerdem sehen, dass sich die dritte Möglichkeit zwangsläufig aus der zweiten ergibt.

5 2. Wieso Abbildung in Tabellenform? Folge des zunächst rein mathematischen Modells Relationale Datenbank Es gibt auch ganz andere Datenbankmodelle, z. B. das Hierarchische Modell das Netzwerkmodell das Objektorientierte Modell Das relationale Modell wurde entwickelt, nachdem man erkannte, dass die Struktur einer Datenbank nicht wie beim Hierarchischen Modell und beim Netzwerkmodell fast starr sein darf. Nur bei einer flexiblen Struktur kann die Datenbank auch nach vielen Jahren den aktuellen Bedürfnissen ohne grundlegende Systemänderungen angepasst werden. Das Objektorientierte Modell ist ein neueres Konzept. Praktischer Nutzen: Relationale Datenbanken sind enorm flexibel, z. B. können Daten in verschiedenen Tabellen (sogenannten Relationen) auf verschiedene Arten miteinander verknüpft werden, um Informationen zu erhalten. Beispiel: Lohntabelle Name Lohn Meier 4500 Müller 5100 Arbeitnehmer Name Straße PLZ Ort Meier Am Weg Rheinfelden

6 Müller Hinze-Str München Mit diesen zwei Tabellen können viele verschiedene Aufgaben erledigt werden, z. B. Durschnittslohn der Arbeitnehmer berechnen (1. Tabelle) Adressetiketten für Einladungen zur Personalversammlung drucken (2. Tabelle) Lohnbescheide, bestehend aus Lohn und Adresse, zusenden ( Tabelle) Beachten Sie: Die Software, die die Datenbank verwaltet, das Database Management System (DBMS), kann mehrere Datenbanken verwalten, also z. B. eine Reisekostendatenbank und eine Literaturdatenbank. Jede dieser Datenbanken kann aus mehreren, miteinander verknüpften Tabellen bestehen 3. Entwurf einer Datenbank 3.1 Zweck der Datenbank festlegen Hier als Beispiel: Reisekostenabrechnung erstellen 3.2 Felder der Tabelle festlegen Legen Sie alle aufzunehmenden Datenfelder der Tabelle fest (siehe Abschnitt 1.1). Die Namen der Datenfelder müssen eindeutig sein.

7 3.3 Überflüssige Felder entfernen Felder, die aus anderen Feldern berechnet werden, sind überflüssig und benötigen zusätzlichen Speicherplatz. Diese Felder können jederzeit neu berechnet werden. Sie werden daher normalerweise nicht in die Tabelle aufgenommen. Am Beispiel der Reisekostenabrechnung: Gesamtvergütung = Anzahl x Einzelvergütung Summe = Summe der Gesamtvergütungen Damit wird die Tabelle kürzer: Reisekosten Datum Name Vorname Straße PLZ Ort -> Rechnungsnummer <- Kostenart Anzahl Einzelvergütung Beachten Sie: Die Tabelle enthält während des Datenbankentwurfs keine Daten, sondern nur Datenfelder. Daten werden erst bei "Inbetriebnahme" der Datenbank eingefügt Unterscheiden Sie zwischen Tabellen-Spalten und Tabellen-Zeilen Obwohl die Tabelle keine Datenfelder für Gesamtvergütungen und Summe enthält, kann aus dieser Tabelle das Reisekostenformular erstellt werden. Die Beträge werden dann einfach bei Bedarf aus den Daten der Tabelle berechnet.

8 Dies verdeutlicht noch einmal den Unterschied zwischen Tabelle und Formular! 3.4 Aufteilung der Tabelle in mehrere Tabellen Die Tabelle wird in mehrere Tabellen aufgeteilt, so dass möglichst keine unerwünschten Nebeneffekte auftreten. Damit wird die Datenbank flexibel. Diese Aufteilung erfolgt mit dem Verfahren der Normalisierung (Abschnitt 4). Zunächst einige Beispiele für unerwünschte Nebeneffekte, die in obiger Tabelle auftauchen: Redundanz (Wiederholung von Information) Zahlreiche Daten werden mehrfach gespeichert. Für jede Rechnung wird z. B. die komplette Adresse des Reisenden gespeichert. Dabei wird u. a. unnötig Speicherplatz belegt Änderungs (Update)-Anomalien Das Verfahren, bei jeder Rechnung die komplette Adresse zu speichern, ist sehr fehleranfällig beim Eintippen sowie bei Adreßänderungen, da eine neue Adresse an vielen Stellen geändert werden muß Einfüge (Insert)-Anomalien Eine Person kann in dieser Datenbank nicht eingefügt werden, wenn sie noch keine Reise gemacht hat, d. h. die Datenbank ist nur für Reisekostenabrechnungen zu gebrauchen und z. B. nicht gleichzeitig als Adreßdatei Lösch (Delete)-Anomalien Werden alle Reisekostenabrechnungen einer Person gelöscht, geht auch die Information über die Adresse dieser Person verloren. Die Adresse könnte aber noch benötigt werden 3.5 Einige Fachbegriffe Eine Relation ist eine zweidimensionale Tabelle, die eine Entität (ein 'Ding', das von anderen unterscheidbar ist, z. B. Reisekosten) beschreibt Die Tabelle enthält Tupel (Zeilen)

9 Jedes Tupel enthält Werte für eine Reihe von Attributen (Spalten), die Eigenschaften einer Entität beschreiben (z. B. "Rechnungsnummer" und "Datum" bei der Reisekostentabelle). Ein Tupel wird auch als Instanz einer Relation bezeichnet Die Menge der möglichen Werte eines Attributes wird als Domäne (Domain) bezeichnet. So könnte z. B. der Wertebereich (rot, grün, blau) die Domäne des Attributs "Farbe" sein 4. Der Königsweg: Normalisierung 4.1 Grundlagen Was ist Normalisierung? Überführung komplexer Beziehungen (Tabellen) in einfache Beziehungen durch Aufteilung der Attribute einer Tabelle auf mehrere Tabellen. Ziel sind stabile und flexible Datenstrukturen, die bei Erweiterungen möglichst wenig geändert werden müssen. Die Normalisierung erfolgt in mehreren Schritten: Nullte Normalform Erster Normalform (1NF) Zweite Normalform (2NF) Dritte Normalform (3NF) Boyce-Codd Normalform (BCNF) Vierte Normalform (4NF) Fünfte Normalform (5NF)

10 Wir werden im folgenden als Beispiel die Reisekostentabelle aus Abschnitt 3 betrachten. Wir werden auch aufzeigen, in welche Tabelle die berechneten Datenfelder "Gesamtvergütung" und "Summe" (siehe Formular in Abschnitt 1) aufzunehmen sind, wenn sie nicht entfernt werden Das Schlüsselkonzept Ein Schlüssel ist eine Menge von Attributen (also eines oder mehrere), die eine Datenzeile (Tupel) einer Tabelle eindeutig identifiziert Ein Schlüsselkandidat ist ein Schlüssel mit minimaler Anzahl Attribute Eine Relation kann mehrere Schlüsselkandidaten haben Ein Primärschlüssel ist ein beliebig ausgewählter Schlüsselkandidat, der zur eindeutigen Identifizierung jeder Zeile benutzt wird. Besteht der Primärschlüssel aus mehreren Attributen (dies ist dann der Fall, wenn ein Attribut zur eindeutigen Identifizierung nicht ausreicht), wird er als zusammengsetzter Primärschlüssel bezeichnet. Ein Schlüsselattribut ist ein Attribut, das Teil mindestens eines Schlüsselkandidaten ist. Alle anderen Attribute sind Nicht-Schlüsselattribute Beispiel: In der Reisekostentabelle ist der zusammengesetzte Schlüssel aus "Rechnungsnummer" und "Kostenart" der einzige Schlüsselkandidat und damit Primärschlüssel. Die Rechnungsnummer alleine genügt nicht als Primärschlüssel, da zu jeder Rechnungsnummer mehrere Kostenarten gehören können. Zusammengesetzte Primärschlüssel tauchen also typischerweise in Tabellen auf, die eine Wiederholungsgruppe enthalten. Reisekosten Datum Name Vorname Straße PLZ Ort Kostenart Anzahl Einzelvergütung Rechnungsnummer Fettgedruckte Attribute: Primärschlüssel 4.2 Nullte Normalform

11 Die Datenelemente der realen Welt werden als Tabelle aufgelistet und berechnete Datenfelder möglichst entfernt. Die Reisekostentabelle ist in der Nullten Normalform, d. h. unnormalisiert. 4.3 Erste Normalform (1NF) Definition Eine Relation ist in der Ersten Normalform, wenn jeder Attributwert atomar ist Erklärung Ein Attributwert ist atomar, wenn er nicht aus mehreren Werten zusammengsetzt ist. So wäre z. B. der Attributwert (Klaus Müller, Elsenheimerstr. 7, München) nicht atomar, da er eine vollständige Adresse enthält, die in mehrere Attribut aufgeteilt werden kann. Abhilfe: Attribute mit Nicht-atomaren-Attributwerten werden in mehrere Attribute aufgeteilt. Eine Wiederholungsgruppe wird aus der Tabelle entfernt und in einer eigenen Tabelle untergebracht. Unsere Reisekostentabelle enthält keine nicht-atomaren Attributwerte, ist also bereits in der ersten Normalform. 4.4 Zweite Normalform (2NF) Definition Eine Relation ist in der Zweiten Normalform, wenn sie in der Ersten Normalform ist und jedes Nicht-Schlüsselattribut von jedem Schlüsselkandidaten vollständig funktional abhängig ist Erklärung Ein Attribut Y ist von einem Attribut X funktional abhängig, wenn es zu jedem X genau ein Y gibt. Vollständig funktional abhängig bedeutet, daß das Nicht-Schlüsselattribut nicht nur von einem Teil der Attribute eines zusammengesetzten Schlüsselkandidaten funktional abhängig ist, sondern von allen Teilen. Beispiel: In der Reisekostentabelle sind die Attribute "Datum", "Name", "Vorname", "Straße", "PLZ" und "Ort" nur funktional abhängig vom Attribut "Rechnungsnummer" und völlig unabhängig vom Attribut "Kostenart". Das Attribut "Einzelvergütung" ist dagegen nur funktional abhängig von der "Kostenart" und

12 hat nichts mit der "Rechnungsnummer" zu tun. Lediglich das Attribut "Anzahl" ist vom zusammengesetzten Primärschlüssel voll funktional abhängig. Abhilfe: Datenfelder, die von einem Schlüsselkandidaten (hier nur der Primärschlüssel) nicht vollständig funktional abhängig sind, werden in weiteren Tabellen untergebracht. Der Teil des Schlüsselkandidaten, von dem ein ausgelagertes Datenfeld funktional abhängig ist, wird Primärschlüssel der neuen Tabelle. Als Ergebnis erhalten wird die drei folgenden Tabellen. Reise Rechnungsnummer Datum Name Vorname Straße PLZ Ort Positionen Rechnungsnummer Kostenart Anzahl Kostenarten Kostenart Einzelvergütung Fettgedruckte Attribute: Primärschlüssel Das berechnete Attribut "Summe" wäre hier in der Tabelle "Reise" zu führen. Das berechnete Attribut "Gesamtvergütung" kann nicht in "Positionen" geführt werden, da es nur von der "Anzahl" und der "Kostenart" funktional abhängig ist, aber nicht von der Rechnungsnummer. Das Attribut "Gesamtvergütung" könnte dann in einer weiteren Tabelle "Vergütung" mit den Attributen "Kostenart", "Anzahl" und "Gesamtvergütung" ("Kostenart" und "Anzahl" wären dann zusammengesetzter Primärschlüssel) untergebracht werden. Die berechneten Datenfelder verbleiben, falls sie mitgeführt werden, auch bei den folgenden Normalisierungen in den genannten Tabellen. Beachten Sie: Besteht der Primärschlüssel nur aus einem einzigen Attribut (ist er also nicht zusammengesetzt), so ist ein Datensatz in Erster Normalform bereits automatisch in Zweiter Normalform Verbindung zwischen Tabellen Jede Rechnungsnummer der Tabelle "Reise" kann in ein oder mehreren Zeilen der Tabelle "Positionen" auftauchen. Dies ist der Fall, wenn bei einer Rechnungsnummer mehrere

13 Kostenarten zu berücksichtigen sind. Man sagt: Zwischen den Tabellen "Reise" und "Positionen" besteht eine 1 : n Beziehung (sprich: eins zu n, eins zu viele). Zwischen den Tabellen "Kostenarten" und "Positionen" besteht ebenfalls eine 1:n Beziehung, da jede in "Kostenarten" aufgeführte Kostenart mehrfach in der Tabelle "Positionen" erscheinen kann (nämlich bei verschiedenen Rechnungsnummern). Dagegen besteht zwischen den Tabellen "Reise" und "Kostenarten" gar keine Beziehung, da sie kein gemeinsames Attribut aufweisen. Wir werden in Abschnitt 5 näher auf Beziehungen zwischen Tabellen eingehen. 4.5 Dritte Normalform (3NF) Definition Eine Relation ist in der Dritten Normalform, wenn Sie in der Zweiten Normalform ist und jedes Nicht-Schlüssel-Attribut von keinem Schlüsselkandidaten transitiv abhängig ist Erklärung Transitive Abhängigkeit: Seien X, Y und Z Attribute. Ist Y von X funktional abhängig und Z von Y, so ist Z von X funktional abhängig. Diese Abhängigkeit ist transitiv. Beispiel: In der Tabelle "Reise" sind die Attribute "Vorname", "Straße" und "PLZ" abhängig vom Attribut "Name", nicht vom Primärschlüssel. Außerdem ist "Ort" abhängig von "PLZ" (X=Rechnungsnummer, Y=PLZ, Z=Ort; zu jeder Rechnungsnummer gehört eine PLZ und zu jeder PLZ ein Ort, also zu jeder Rechnungsnummer ein Ort). Abhilfe: Die transitiv abhängigen Datenfelder werden in weitere Tabellen ausgelagert, da sie nicht direkt vom Schlüsselkandidaten abhängen, sondern nur indirekt. Da ein Name nicht eindeutig ist, wird jedem Angestellten eine Personalnummer zugeordnet. Diese ist Primärschlüssel der neuen Tabelle "Personal". Alternativ könnte ein zusammengesetzter Primärschlüssel aus Name, Vorname und Geburtsdatum benutzt werden (dieser sollte hinreichend eindeutig sein). Reise Rechnungsnummer Datum Personalnummer

14 Personal Personalnummer Name Vorname Straße PLZ PLZ PLZ Ort Fettgedruckte Attribute: Primärschlüssel Wiederum besteht zwischen den Tabellen "Personal" und "Reise" sowie zwischen "PLZ" und "Personal" eine 1:n Beziehung, da ein Mitarbeiter mit einer bestimmten Personalnummer mehrere Dienstreisen machen kann und mehrere Mitarbeiter dieselbe Postleitzahl haben können. Nach der dritten Normalisierung ergeben sich also folgende Tabellen, Datenfelder und Beziehungen:

15 Beachten Sie: Bei der Festlegung der Beziehungen kommt es auf die Reihenfolge der Tabellen an: Die Tabelle "PLZ" steht in einer 1:n Beziehung zur Tabelle "Personal", die Tabelle "Personal" dagegen in einer n:1 Beziehung (und nicht 1:n) zur Tabelle "PLZ" Eine Relationale Datenbank speichert nicht nur die Daten der Tabellen sondern auch die Beziehungen zwischen den Tabellen Die in Abschnitt 3.4 beschriebenen Beschränkungen der ursprünglichen Form der Reisekostentabelle sind nun überwunden, z. B. kann ein Angestellter in der Tabelle "Personal" bereits existieren, ohne jemals eine Reise gemacht zu haben

16 Die drei folgenden Normalformen (BCNF, 4NF, 5NF) werden nur in seltenen Fällen benötigt. Die bisher betrachtete Reisekostendatenbank erfüllt bereits die Kriterien dieser Normalformen 4.6 Boyce-Codd Normalform (BCNF) Definition Eine Relation ist in Boyce-Codd Normalform, wenn jeder Determinant ein Schlüsselkandidat ist Erklärung Ein Determinant ist eine Attributmenge, von der ein anderes Attribut vollständig funktional abhängig ist. Die Boyce-Codd-Normalform ist eine Weiterentwicklung der Dritten Normalform. In der Dritten Normalform kann es vorkommen, daß ein Teil eines (zusammengesetzten) Schlüsselkandidaten funktional abhängig ist von einem Teil eines anderen Schlüsselkandidaten. Die Boyce-Codd-Normalform verhindert dies. Beispiel: Der Tabelle "Positionen" wird das Attribut "Kostenartnummer" hinzugefügt. Dieses Attribut ist eindeutig für jede "Kostenart". Dann sind "Rechnungsnummer" und "Kostenart" sowie "Rechnungsnummer" und "Kostenartnummer" zusammengesetzte Schlüsselkandidaten. Positionen Rechnungsnummer Kostenar t Kostenartnumme r Anzahl Fettgedruckte Attribute: Primärschlüssel Kursiv gedruckte Attribute: weiterer Schlüsselkandidat Die Relation "Positionen" ist in Erster Normalform, da sie keine Wiederholungsgruppe hat und in Zweiter Normalform, da "Anzahl" als einziges Nicht-Schlüsselattribut von beiden Schlüsselkandidaten voll funktional abhängig ist. Sie ist auch in Dritter Normalform, da es außer "Anzahl" keine weiteren Nicht-Schlüsselattribute gibt. Offensichtlich gibt es aber eine funktionale Abhängigkeit von "Kostenart" und "Kostenartnummer", die nichts mit der Rechnungsnummer zu tun hat. Die Relation ist nicht in Boyce-Codd Normalform. Das Attribut "Kostenartnummer" ist Determinant, da "Kostenart" funktional abhängig von "Kostenartnummer" ist. Der Determinant ist aber nicht Schlüsselkandidat, sondern nur Teil eines Schlüsselkandidaten.

17 Abhilfe: Aufteilung der Tabelle "Positionen" in die zwei folgenden Tabellen. Geht man von der ursprünglichen Reisekostendatenbank aus, so würde die Tabelle "Kostenarten" noch das Feld "Einzelvergütung" enthalten. Positionen Rechnungsnummer Kostenart Anzahl Kostenarten Kostenart Kostenartnummer Beachten Sie: Jede Relation in Boyce-Codd-Normalform ist auch in Dritter Normalform Einen Unterschied zwischen Dritter Normalform und Boyce-Codd Normalform gibt es nur, wenn es mehrere Schlüsselkandidaten mit überlappenden Attributen gib 4.7 Vierte Normalform (4NF) Definition Eine Relation ist in Vierter Normalform, wenn sie in Boyce-Codd Normalform ist und für jede mehrwertige Abhängigkeit einer Attributmenge Y von einer Attributmenge X gilt: - Die mehrwertige Abhängigkeit ist trivial ist oder - X ist ein Schlüsselkandidat der Relation Mehrwertige Abhängigkeit (Multivalued Dependency, MVD) Wir betrachten die folgende Tabelle Personalnummer Haustier Die Personalnummer bestimmt unter Umständen nicht nur ein einziges Haustier, sondern eine ganze Liste verschiedener Haustiere. Hier liegt eine mehrwertige Abhängigkeit (im Gegensatz zur funktionalen Abhängigkeit) vor. Eine mehrwertige Abhängigkeit einer Attributmenge Y von einer Attributmenge X ist trivial, wenn Y Teil von X ist oder die Relation nur aus X und Y besteht. Im Beispiel ist Y=Haustier, X=Personalnummer und die Relation besteht nur aus X und Y. Anschaulich: die mehrwertige Abhängigkeit ist trivial, wenn sich die Tabelle nicht weiter zerlegen läßt.

18 4.7.3 Erklärung Probleme mit mehrwertigen Abhängigkeiten gibt es dann, wenn mehrere mehrwertige Abhängigkeiten in einer Tabelle auftreten: Personalnummer Haustier Fahrzeugtyp Zwischen Personalnummer und Haustier sowie zwischen Personalnummer und Fahrzeugtyp gibt es eine mehrwertige Abhängigkeit. Zwischen Haustier und Fahrzeugtyp gibt es keinerlei Abhängigkeit, so daß zu jeder Personalnummer alle Kombinationen dieser beiden Attribute auftauchen können. Die Relation ist in Boyce-Codd-Normalform, da es keine funktionale Abhängigkeit zwischen Attributen gibt. Die Personalnummer alleine ist aber kein Schlüsselkandidat der Relation. Wie soll aber z. B. in dieser Tabelle eine Personalnummer gespeichert werden, zu der zwei Haustiere und zwei Fahrzeuge gehören? Mögliche Varianten: Personalnummer Haustier Fahrzeugtyp Hund Porsche Katze BMW Personalnummer Haustier Fahrzeugtyp Hund Porsche Katze Porsche Hund BMW Katze BMW Personalnummer Haustier Fahrzeugtyp Hund NULL Katze NULL NULL Porsche NULL BMW NULL repräsentiert einen nicht vorhandenen Wert. Auf den ersten Blick ist die letzte Variante die sinnvollste, da hier klar hervorgeht, das zwischen "Haustier" und "Fahrzeugtyp" keinerlei Abhängigkeit besteht. Die sogenannte Existentielle Integrität verlangt aber, daß kein Schlüsselattribut einen NULL-Wert hat. Abhilfe: Aufteilung der Tabelle in zwei Tabellen:

19 Personalnummer Haustier Personalnummer Fahrzeugtyp Dann liegen nur noch triviale mehrwertige Abhängigkeiten vor und die Relationen sind in Vierter Normalform. 4.8 Fünfte Normalform (5NF) Definition Eine Relation R ist in Fünfter Normalform (oder Project-Join-Normalform), wenn sie in Vierter Normalform ist und für jede Join-Abhängigkeit (R1, R2,..., Rn) gilt: - Die Join-Abhängigkeit ist trivial oder - Jedes Ri aus (R1, R2,..., Rn) ist Schlüsselkandidat der Relation Die Fünfte Normalform wird auch als Project Join Normalform (PJNF) bezeichnet Join-Abhängigkeit (Join Dependency) Zum Begriff "Join" siehe Abschnitt Hier ist der Natural Join gemeint. Eine Relation R genügt der Join-Abhängigkeit (R1, R2,..., Rn) genau dann, wenn R gleich dem Join von R1, R2,..., Rn ist. Die R1, R2,... sind Teilmengen aller Attribute von R. Eine Join-Abhängigkeit ist trivial, wenn ein Ri aus (R1, R2,..., Rn) gleich R ist Beispiel: Personalnummer Haustier Fahrzeugtyp Hund Porsche Katze Porsche Hund BMW Katze BMW Da jede Kombination von Haustier und Fahrzeugtyp auftaucht, ist die Relation R= (Personalnummer, Haustier, Fahrzeugtyp) gleich dem Join von R1=(Personalnummer, Haustier) und R2=(Personalnummer, Fahrzeugtyp). Also genügt R der Join-Abhängigkeit (R1, R2).

20 4.8.3 Erklärung Beispiel für eine Relation, die nicht in Fünfter Normalform ist: Fach Kurs Name Mathematik Mathe1 Physik Mathematik Mathe1 Mathematik Mathe2 Müller PhysikA Müller Huber Jedes Fach bietet verschiedene Kurse an, die von verschiedenen Teilnehmern besucht werden. Kein Teilnehmer besucht alle Kurse und kein Kurs wird von allen Teilnehmern besucht. Also sind alle drei Attribute wichtig, um die nötige Information darzustellen. Im Gegensatz zum obigen Beispiel bei der vierten Normalform gibt es keine mehrwertigen Abhängigkeiten, da "Kurs" und "Name" nicht unabhängig sind, sondern die Paarungen wichtige Information enthalten. Kelz Die Relation enthält redundante Information, läßt sich aber nicht als Join von R1=(Fach, Kurs) und R2=(Fach, Name) darstellen (es tauchen überflüssige Zeilen auf). Die Relation genügt also nicht der Join-Abhängigkeit (R1, R2). Eine Aufteilung der Tabelle in die zwei Tabellen R1 und R2 ist nicht sinnvoll. R1 Fach Kurs Mathematik Mathe1 Physik PhysikA Mathematik Mathe2 R2 Fach Name Mathematik Müller Physik Müller Mathematik Huber Mathematik Kelz JOIN von R1 und R2 Fach Kurs Name Mathematik Mathe1 Müller Mathematik Mathe1 Huber Mathematik Mathe1 Kelz Physik PhysikA Müller

21 Mathematik Mathe2 Mathematik Mathe2 Mathematik Mathe2 Müller Huber Kelz Wichtig: Obwohl wir hier mehr Zeilen haben als vorher, haben wir plötzlich weniger Informationen, da die Information über die wirklichen Kombinationen von "Kurs" und "Name" teilweise verlorengeht. Interessanterweise genügt die Relation aber zwei anderen Join-Abhängigkeiten, nämlich der trivialen Join-Abhängigkeit R=R1=(Fach, Kurs, Name) sowie der Join-Abhängigkeit R1= (Fach, Kurs), R2=(Fach, Name) und R3=(Kurs, Name). Wie man leicht nachprüft, ist R gleich dem Join von R3 mit dem Join von R1 und R2: R3 Kurs Name Mathe1 Müller PhysikA Müller Mathe1 Huber Mathe2 Kelz Join von R3 mit (Join von R1 mit R2) Fach Kurs Name Mathematik Mathe1 Physik Mathematik Mathe1 Mathematik Mathe2 Müller PhysikA Müller Huber Kelz Ist die Relation dann in Fünfter Normalform? Nein, da weder R1, R2 oder R3 Schlüsselkandidaten sind. Der einzige Schlüsselkandidat besteht aus allen drei Attributen "Fach", "Kurs" und "Name". Abhilfe: Aufteilung der Tabelle in die drei folgenden Tabellen (für die es dann nur noch triviale Join- Abhängigkeiten gibt): Fach Kurs

22 Fach Name Kurs Name Relationen in Fünfter Normalform lassen sich nicht weiter aufteilen. 5. Weitere wichtige Begriffe 5.1 Beziehungen zwischen Tabellen 1:1 Beziehung: Einem Datensatz einer Tabelle ist genau ein Datensatz einer anderen Tabelle zugeordnet. 1:n Beziehung: Siehe obige Beispiele, z. B. Abschnitt n:m Bezeihung: Viele zu viele (n zu m) Beziehung. Einem Datensatz der einen Tabelle sind, wie bei der 1:n Beziehung, viele Datensätze einer anderen Tabelle zugeordnet. Umgekehrt sind aber auch jedem Datensatz der zweiten Tabelle viele Datensätze der ersten Tabelle zugeordnet. Z. B. kann bei einer Produktdatenbank ein Lieferant viele Produkte liefern. Gleichzeitig kann dasselbe Produkt von vielen Lieferanten geliefert werden.

23 Problem: n:m Beziehungen sind komplex und in dieser Form kaum zu verwalten. Abhilfe: Aufschlüsseln der n:m Beziehung in zwei 1:n Beziehungen durch Einfügen einer dritten Tabelle. Der Primärschlüssel der neuen Tabelle ist meist ein zusammengesetzter Schlüssel aus den Primärschlüseln der Ausgangstabellen. 5.2 Fremdschlüssel Ein Datenfeld (Attribut) einer Tabelle, das nicht Primärschlüssel dieser Tabelle, aber Schlüsselfeld einer anderen Tabelle ist. Bei den zwei folgenden Tabellen ist das Feld "Personalnummer" der Tabelle "Reise" ein Fremdschlüssel, da es gleichzeitig Primärschlüssel der Tabelle "Personal" ist. Reise Rechnungsnummer Datum Personalnummer Personal

24 Personalnummer Name Vorname Straße PLZ 5.3 Referentielle Integrität (Beziehungsintegrität) Jeder Wert (im Sinne von Inhalt) eines Fremdschlüssels muß auch als Wert des zugehörigen Primärschlüssels vorhanden sein. Beispiel in obigen Tabellen: Wenn in der Tabelle "Reise" die Personalnummer 510 eingetragen wird, muß diese Personalnummer auch als Primärschlüssel in der Tabelle "Personal" auftauchen, da nur in der Personaltabelle erfaßte Angestellte Reisen machen können. Aus dieser Forderung ergeben sich die referentiellen Integritätsbedingungen für bestimmte Vorgänge: Einfügen oder Ändern eines Wertes des Fremdschlüssels Es muß darauf geachtet werden, daß dieser zuerst in das zugehörige Primärschlüssel- Feld eingetragen wird. Ist dies nicht der Fall, muß die Einfügungs/Änderungsanweisung zurückgewiesen werden Löschen eines Wertes des Primärschlüssels für den es einen Fremdschlüssel gibt: Die Löschanweisung kann zurückgewiesen werden, oder alle entsprechenden Datensätze, bei denen der Wert eines Fremdschlüssels mit dem gelöschten Wert des Primärschlüssels übereinstimmt, werden komplett gelöscht, oder alle entsprechenden Werte des Fremdschlüssels, die mit dem gelöschten Wert des Primärschlüssels übereinstimmen, werden durch einen Null-Wert oder einen voreingestellten Wert (Default) ersetzt Beachten Sie: Eine relationale Datenbank speichert neben Daten (Tabelleninhalte) auch Beziehungen zwischen Tabellen. Dazu gehören bei Bedarf auch referentielle Integritätsbedingungen. Inhaltsverzeichnis Andreas Kelz Kapitel 6 (enthält Infos zu SQL)

Design Theorie für relationale Datenbanken

Design Theorie für relationale Datenbanken Design Theorie für relationale Datenbanken Design von relationalen Datenbanken alternativen Datenabhängigkeiten Normalisierung Ziel: automatisches Datenbankdesign IX-1 Schlechtes Datenbank Design Frage:

Mehr

Fachbereich Wirtschaftswissenschaften Campus Sankt Augustin

Fachbereich Wirtschaftswissenschaften Campus Sankt Augustin Hochschule Bonn-Rhein-Sieg Fachbereich Wirtschaftswissenschaften Campus Sankt Augustin Prüfung Probeklausur SoSe 2015 mit Lösung Teil 3: Jacobsen/Pieters Aufgabe 1: Abfragen Die Tabelle zeigt einen Auszug

Mehr

9. Einführung in Datenbanken

9. Einführung in Datenbanken 9. Einführung in Datenbanken 9.1 Motivation und einführendes Beispiel 9.2 Modellierungskonzepte der realen Welt 9.3 Anfragesprachen (Query Languages) 9.1 Motivation und einführendes Beispiel Datenbanken

Mehr

Relationale Datenbanken Datenbankgrundlagen

Relationale Datenbanken Datenbankgrundlagen Datenbanksystem Ein Datenbanksystem (DBS) 1 ist ein System zur elektronischen Datenverwaltung. Die wesentliche Aufgabe eines DBS ist es, große Datenmengen effizient, widerspruchsfrei und dauerhaft zu speichern

Mehr

Einführung Datenbanken: Normalisierung

Einführung Datenbanken: Normalisierung Einführung Datenbanken: Normalisierung Für die Kursverwaltung einer VHS hat der Datenbank-Programmierer ein ER-Modell entworfen: Entitätstyp Entitäten Attribute Attributsausprägungen Kurse Teilnehmer Dozenten

Mehr

Wirtschaftsinformatik - 1.Tutorium im WS 11/12

Wirtschaftsinformatik - 1.Tutorium im WS 11/12 Wirtschaftsinformatik - 1.Tutorium im WS 11/12 Organisatorisches Planung, Realisierung und Einführung von Anwendungssystemen Analyse und Gestaltung inner- und zwischen-betrieblicher Abläufe: ARIS Ereignisgesteuerte

Mehr

4.2.2.2 Funktionale Abhängigkeiten

4.2.2.2 Funktionale Abhängigkeiten Funktionale Abhängigkeiten 4.2.2.2 Funktionale Abhängigkeiten 2002 Prof. Dr. Rainer Manthey Informationssysteme 1 Spezielle Formen von FDs Ist die linke Seite einer FD nicht mehr verkleinerbar (reduzierbar),

Mehr

Tag 4 Inhaltsverzeichnis

Tag 4 Inhaltsverzeichnis Tag 4 Inhaltsverzeichnis Normalformen Problem Formen (1-4) Weitere Formen Transaktionen Synchronisationsprobleme Überblick Autocommit Locking Savepoints Isolation levels Übungen RDB 4-1 Normalformen Problematik

Mehr

In diesem Thema lernen wir die Grundlagen der Datenbanken kennen und werden diese lernen einzusetzen. Access. Die Grundlagen der Datenbanken.

In diesem Thema lernen wir die Grundlagen der Datenbanken kennen und werden diese lernen einzusetzen. Access. Die Grundlagen der Datenbanken. In diesem Thema lernen wir die Grundlagen der Datenbanken kennen und werden diese lernen einzusetzen. Access Die Grundlagen der Datenbanken kurspc15 Inhaltsverzeichnis Access... Fehler! Textmarke nicht

Mehr

Übungen Teil 1: Normalisierung. Dozent: Stefan Maihack Dipl. Ing. (FH)

Übungen Teil 1: Normalisierung. Dozent: Stefan Maihack Dipl. Ing. (FH) Übungen Teil 1: Normalisierung Dozent: Stefan Maihack Dipl. Ing. (FH) 1. Übung: Normalisierung Eine Tabelle zur Verwaltung von Personalinformationen soll bis in die 3. Normalform überführt werden. Angelegt

Mehr

Ein Schlüssel ist eine Menge von Attributen (also eines oder mehrere), die eine Datenzeile (Tupel) einer Tabelle eindeutig identifiziert

Ein Schlüssel ist eine Menge von Attributen (also eines oder mehrere), die eine Datenzeile (Tupel) einer Tabelle eindeutig identifiziert Maika Büschenfeldt Datenbanken: Skript 1 1. Was ist eine relationale Datenbank? In Datenbanken können umfangreiche Datenbestände strukturiert abgelegt werden. Das Konzept relationaler Datenbanken soll

Mehr

In die Zeilen würden die Daten einer Adresse geschrieben werden. Das Ganze könnte in etwa folgendermaßen aussehen:

In die Zeilen würden die Daten einer Adresse geschrieben werden. Das Ganze könnte in etwa folgendermaßen aussehen: 1 Einführung in Datenbanksysteme Fast jeder kennt Excel und hat damit in seinem Leben schon einmal gearbeitet. In Excel gibt es Arbeitsblätter, die aus vielen Zellen bestehen, in die man verschiedene Werte

Mehr

ICT Power-User und Supporter SIZ 2010 Modul 432: Datenbank mit Access 2010. Tanja Bossert, Andrea Weikert. 1. Ausgabe, November 2011

ICT Power-User und Supporter SIZ 2010 Modul 432: Datenbank mit Access 2010. Tanja Bossert, Andrea Weikert. 1. Ausgabe, November 2011 ICT Power-User und Supporter SIZ 2010 Modul 432: Tanja Bossert, Andrea Weikert 1. Ausgabe, November 2011 Datenbank mit Access 2010 SIZ-432-ACC2010 2 ICT Power-User und Supporter SIZ 2010 - Modul 432 2

Mehr

Übungsblatt 4. Aufgabe 7: Datensicht Fachkonzept (Klausur SS 2002, 1. Termin)

Übungsblatt 4. Aufgabe 7: Datensicht Fachkonzept (Klausur SS 2002, 1. Termin) Übungsblatt 4 Aufgabe 7: Datensicht Fachkonzept (Klausur SS 2002, 1. Termin) Die Saartal Linien beauftragen Sie mit dem Entwurf der Datenstrukturen für ein Informationssystem. Dieses soll zur Verwaltung

Mehr

Relationale Entwurfstheorie. Kapitel 5 201 / 510

Relationale Entwurfstheorie. Kapitel 5 201 / 510 Kapitel 5 Relationale Entwurfstheorie 201 / 510 Relationale Entwurfstheorie Ein schlecht entworfenes Schema führt zu folgenden Anomalien Updateanomalien: bei Änderungen eines Fakts müssen viele Tupel angefaßt

Mehr

3. Prinzipien und Nutzung von relationalen Datenbanksystemen

3. Prinzipien und Nutzung von relationalen Datenbanksystemen 3. Prinzipien und Nutzung von relationalen Datenbanksystemen Inhalt: Dateien vs. Datenbanken Datenbanken: Tabellen, Attribute und Datentyp Datenmodellierung und Normalformen einer Datenbank Structured

Mehr

ACCESS das Datenbankprogramm. (Einführung) DI (FH) Levent Öztürk

ACCESS das Datenbankprogramm. (Einführung) DI (FH) Levent Öztürk ACCESS das Datenbankprogramm Vom Microsoft (Einführung) DI (FH) Levent Öztürk Inhalt Grundlagen einer Datenbank Planung einer Datenbank Programm starten Datenbank Anlegen Tabellen anlegen Tabellen Verknüpfen

Mehr

U8: SQL Datenbank Daniel Baron 1

U8: SQL Datenbank Daniel Baron 1 U8: SQL Datenbank Daniel Baron 1 Allgemein Eine SQL Datenbank ist eine meist serverseitige Software, die Daten speichern und verwalten kann. Dabei werden diese Daten in Tabellen abgelegt und indiziert.

Mehr

Tag 4 Inhaltsverzeichnis

Tag 4 Inhaltsverzeichnis Tag 4 Inhaltsverzeichnis Normalformen Problem Formen (1-4) Weitere Formen Transaktionen Synchronisationsprobleme Überblick Autocommit Locking Savepoints Isolation levels Übungen RDB 4-1 Normalformen Problematik

Mehr

Software-Engineering Einführung

Software-Engineering Einführung Software-Engineering Einführung 7. Übung (04.12.2014) Dr. Gergely Varró, gergely.varro@es.tu-darmstadt.de Erhan Leblebici, erhan.leblebici@es.tu-darmstadt.de Tel.+49 6151 16 4388 ES Real-Time Systems Lab

Mehr

Aufgaben zur fachwissenschaftlichen Prüfung Modul 3 Daten erfassen, ordnen, verarbeiten und austauschen: Schwerpunkt Datenbanken

Aufgaben zur fachwissenschaftlichen Prüfung Modul 3 Daten erfassen, ordnen, verarbeiten und austauschen: Schwerpunkt Datenbanken Aufgaben zur fachwissenschaftlichen Prüfung Modul 3 Daten erfassen, ordnen, verarbeiten und austauschen: Schwerpunkt Datenbanken 30 Wozu dient ein Primärschlüssel? Mit dem Primärschlüssel wird ein Datenfeld

Mehr

Kapitel 7: Formaler Datenbankentwurf

Kapitel 7: Formaler Datenbankentwurf 7. Formaler Datenbankentwurf Seite 1 Kapitel 7: Formaler Datenbankentwurf Die Schwierigkeiten der konzeptuellen Modellierung sind zu einem großen Teil dadurch begründet, dass sich die relevanten Strukturen

Mehr

ABTEILUNGS- ABTEILUNGS- LEITER NAME

ABTEILUNGS- ABTEILUNGS- LEITER NAME Übungsaufgaben Übungsaufgabe 1 - Normalisierung - Gegeben ist folgende unnormalisierte Relation, die Daten über Mitarbeiter und deren Abteilungszughörigkeit enthält. Weiterhin sind die Beteiligung(en)

Mehr

Datenbankentwurf. 4.2 Logischer Entwurf. Kapitel 4. ER-Modell. Umsetzung. Entwurfsdokumentation. relationales Modell. Verbesserung

Datenbankentwurf. 4.2 Logischer Entwurf. Kapitel 4. ER-Modell. Umsetzung. Entwurfsdokumentation. relationales Modell. Verbesserung 4.2 Logischer Entwurf Datenbankentwurf 4.2 Logischer Entwurf 2002 Prof. Dr. Rainer Manthey Informationssysteme Logischer Entwurf: Einordnung Entwurfsdokumentation logische Strukturen "auf dem Papier" konzeptueller

Mehr

Inhaltsverzeichnis. 1. Fragestellung

Inhaltsverzeichnis. 1. Fragestellung Inhaltsverzeichnis 1. Fragestellung... 1 2. Herleitung zum Thema... 1 3. Das Entity Relationship Modell (ERM)... 2 4. Praktisches Beispiel zum ERM... 7 5. Anhang...Fehler! Textmarke nicht definiert. 1.

Mehr

1 Datenbank-Grundlagen

1 Datenbank-Grundlagen Datenbank-Grundlagen 1 Datenbank-Grundlagen Eine Datenbank ist eine Sammlung von Daten aus der Realität. 1.1 Arten von Datenbanken 1.1.1 Sequenzieller Zugriff Älteres Datenzugriffsverfahren (Speicherung

Mehr

ER-Modell. Entity-Relationship-Model

ER-Modell. Entity-Relationship-Model + ER-Modell Entity-Relationship-Model + Was ist ein Modell? Worte/Zitat aus einem Physikbuch: "Modelle sind also Vorstellungshilfen und Wirklichkeitshilfen, nicht die Wirklichkeit selbst." (Metzler Physik).

Mehr

Christian-Weise-Gymnasium Zittau Fachbereich Informatik M. Hans. Datenmodellierung 1. Inhaltsverzeichnis

Christian-Weise-Gymnasium Zittau Fachbereich Informatik M. Hans. Datenmodellierung 1. Inhaltsverzeichnis Datenmodellierung 1 Inhaltsverzeichnis 1. Informationsstruktur ermitteln...2 2. Datenstruktur modellieren...3 2.1 Elemente des ER-Modells...3 2.1.1 Entities...3 2.1.2 Beziehungen zwischen Entities...4

Mehr

Einführung in Datenbanken - Wiederholung Normalformen - Philipp Cimiano AG Semantische Datenbanken und Wissensverarbeitung

Einführung in Datenbanken - Wiederholung Normalformen - Philipp Cimiano AG Semantische Datenbanken und Wissensverarbeitung Einführung in Datenbanken - Wiederholung Normalformen - Philipp Cimiano AG Semantische Datenbanken und Wissensverarbeitung 1 Überblick Normalformen 2NF 3NF BCNF 2 Zweite Normalform (2NF) Definition (zweite

Mehr

3. Spezielle ER-Modelle und Tabellenableitung. Transformation von ER-Diagrammen in Relationen

3. Spezielle ER-Modelle und Tabellenableitung. Transformation von ER-Diagrammen in Relationen 3. Spezielle ER-Modelle und Tabellenableitung Spezialfälle von ER-Modellen Grundlage, was sind Relationen Transformation von ER-Diagrammen in Relationen 56 Lesebeispiel Access (Realisierungmodell!) 57

Mehr

Kapitel 06 Normalisierung von Relationen. 6 Die Normalisierung von Relationen

Kapitel 06 Normalisierung von Relationen. 6 Die Normalisierung von Relationen Kapitel 06 Normalisierung von Relationen 6 Die Normalisierung von Relationen 6 Die Normalisierung von Relationen...1 6.1 Die Problemstellung...4 6.2 Die unnormalisierte Form...5 6.3 Die 1. Normalform...7

Mehr

Datenbanken: Relationales Datenbankmodell RDM

Datenbanken: Relationales Datenbankmodell RDM Das RDM wurde in den 70'er Jahren von Codd entwickelt und ist seit Mitte der 80'er Jahre definierter Standard für Datenbanksysteme! Der Name kommt vom mathematischen Konzept einer Relation: (Sind A, B

Mehr

Entwurf von Datenbanken

Entwurf von Datenbanken Bisher: was sind Datenbanken? Wie funktionieren sie? Im Folgenden: wie entwickle ich eine Datenbank? Was ist eine gute Datenbank? Der Datenbankentwurfsprozess Das Entity Relationship (ER) Modell Abbildung

Mehr

Views in SQL. 2 Anlegen und Verwenden von Views 2

Views in SQL. 2 Anlegen und Verwenden von Views 2 Views in SQL Holger Jakobs bibjah@bg.bib.de, holger@jakobs.com 2010-07-15 Inhaltsverzeichnis 1 Wozu dienen Views? 1 2 Anlegen und Verwenden von Views 2 3 Schreibfähigkeit von Views 3 3.1 Views schreibfähig

Mehr

Informatik II Datenorganisation Datenbanken

Informatik II Datenorganisation Datenbanken Informatik II Datenorganisation Datenbanken Studiengang Wirtschaftsingenieurwesen (2. Semester) Prof. Dr. Sabine Kühn Tel. (0351) 462 2490 Fachbereich Informatik/Mathematik skuehn@informatik.htw-dresden.de

Mehr

Handbuch ECDL 2003 Basic Modul 5: Datenbank Grundlagen von relationalen Datenbanken

Handbuch ECDL 2003 Basic Modul 5: Datenbank Grundlagen von relationalen Datenbanken Handbuch ECDL 2003 Basic Modul 5: Datenbank Grundlagen von relationalen Datenbanken Dateiname: ecdl5_01_00_documentation_standard.doc Speicherdatum: 14.02.2005 ECDL 2003 Basic Modul 5 Datenbank - Grundlagen

Mehr

4. Relationen. Beschreibung einer binären Relation

4. Relationen. Beschreibung einer binären Relation 4. Relationen Relationen spielen bei Datenbanken eine wichtige Rolle. Die meisten Datenbanksysteme sind relational. 4.1 Binäre Relationen Eine binäre Relation (Beziehung) R zwischen zwei Mengen A und B

Mehr

1 Übungen zu Datenbank-Kategorien

1 Übungen zu Datenbank-Kategorien 1 Übungen zu Datenbank-Kategorien Übung 1.1 Betrachten Sie anhand der grafischen Darstellung im Skript den Unterschied zwischen einer Desktop Datenbank und einer Client-Server Datenbank. Geben Sie für

Mehr

Im Fall einer Personaldatenbank würde eine Relation beispielsweise wie folgt aussehen:

Im Fall einer Personaldatenbank würde eine Relation beispielsweise wie folgt aussehen: Grundwissen zu relationalen Datenbanken Die Funktion einer relationalen Dankbank besteht in der elektronischen Verwaltung von Daten in Computersystemen. Die Basis für relationale Datenbanken bildet das

Mehr

Als logisches Datenmodell wird hier das Relationenmodell vorgestellt, das heute den Standard für relationale Datenbanken darstellt.

Als logisches Datenmodell wird hier das Relationenmodell vorgestellt, das heute den Standard für relationale Datenbanken darstellt. Das Relationenmodell Logische Datenmodell Das Entity Relation Modell wird in ein logisches Datenmodell umgesetzt. Welches logische Datenmodell gewählt wird, hängt von dem verwendeten Datenbanksystem ab.

Mehr

Einführung in Datenbanksysteme. H. Wünsch 01.2001

Einführung in Datenbanksysteme. H. Wünsch 01.2001 Einführung in Datenbanksysteme H. Wünsch 01.2001 H. Wünsch 01/2001 Einführung Datenbanken 2 Was sind Datenbanken? Datenbanken sind Systeme zur Beschreibung, Speicherung und Wiedergewinnung von Datenmengen.

Mehr

Einleitung Projektion Selektion Join Mengenop. Vollst.keit. Einleitung Projektion. Selektion Join. Vollst.keit. Einleitung Projektion Selektion Join

Einleitung Projektion Selektion Join Mengenop. Vollst.keit. Einleitung Projektion. Selektion Join. Vollst.keit. Einleitung Projektion Selektion Join Parsen der Anfrage (SQL) Transformation in eine Standardform (Relationenalgebra) Logische Optimierung Transformation in alternative Zugriffspläne, Physische Optimierung Ausführung des gewählten Zugriffsplans

Mehr

Klassifikation von Integrationskonflikten

Klassifikation von Integrationskonflikten Klassifikation von Integrationskonflikten Christiane Telöken 1 Inhaltsverzeichnis 1. Was bedeutet Integration? 2. Strukturelle Heterogenitätskonflikte 2.1 Konflikte bei bilateralen Korrespondenzen 2.2

Mehr

Semantische Integrität (auch: Konsistenz) der in einer Datenbank gespeicherten Daten als wichtige Anforderung

Semantische Integrität (auch: Konsistenz) der in einer Datenbank gespeicherten Daten als wichtige Anforderung 6. Datenintegrität Motivation Semantische Integrität (auch: Konsistenz) der in einer Datenbank gespeicherten Daten als wichtige Anforderung nur sinnvolle Attributwerte (z.b. keine negativen Semester) Abhängigkeiten

Mehr

Teil 7: Einführung in den logischen Entwurf

Teil 7: Einführung in den logischen Entwurf 7. Einführung in den logischen Entwurf 7-1 Teil 7: Einführung in den logischen Entwurf Literatur: Elmasri/Navathe:Fundamentals of Database Systems, 3. Auflage, 1999. Chapter 3, Data Modeling Using the

Mehr

Datenbanken 1. Kapitel 3: Relationenmodell WURDE_VERKAUFT INTEGER PRODNR. PRODNR = PRODNR SHOPID = SHOPID SHOPID INTEGER INTEGER

Datenbanken 1. Kapitel 3: Relationenmodell WURDE_VERKAUFT INTEGER PRODNR. <pk,fk1> <pk,fk2> PRODNR = PRODNR SHOPID = SHOPID SHOPID INTEGER INTEGER Datenbanken 1 Kapitel 3: Relationenmodell WURDE_VERKAUFT PRODNR = PRODNR PRODNR SHOPID ANZAHL INTEGER INTEGER INTEGER SHOPID = SHOPID PRODUKT SHOP PRODNR BEZEICHNUNG PREIS INTEGER VARCHAR2(20)

Mehr

Normalformen. Datenmodellierung, Datenbanksysteme. Ingo Claÿen, Martin Kempa, Peter Morcinek. Hochschule für Technik und Wirtschaft Berlin

Normalformen. Datenmodellierung, Datenbanksysteme. Ingo Claÿen, Martin Kempa, Peter Morcinek. Hochschule für Technik und Wirtschaft Berlin Normalformen Datenmodellierung, Datenbanksysteme Ingo Claÿen, Martin Kempa, Peter Morcinek Hochschule für Technik und Wirtschaft Berlin Nichtnormalisierte Tabelle Update-Anomalie MNR Name ANR AbtBez 11

Mehr

Informations- und Wissensmanagement

Informations- und Wissensmanagement Übung zur Vorlesung Informations- und Wissensmanagement (Übung 1) Frank Eichinger IPD, Lehrstuhl für Systeme der Informationsverwaltung Zur Person Beruflicher Hintergrund Studium an der TU Braunschweig

Mehr

4.3 Dateneingabe in Tabellen

4.3 Dateneingabe in Tabellen DATENERFASSUNG 4 Tabellen 4.3 Dateneingabe in Tabellen Mit Access 2010 können neue Daten direkt in die eingegeben werden, wenn eine Tabelle in der Datenblattansicht geöffnet ist. Sie können hier aber auch

Mehr

Vorlesung Datenbanken II A Klausur

Vorlesung Datenbanken II A Klausur Prof. Dr. Stefan Brass 11. Juli 2006 Institut für Informatik MLU Halle-Wittenberg Vorlesung Datenbanken II A Klausur Name: Matrikelnummer: Studiengang: Aufgabe Punkte Max. Punkte Zeit 1 (Entwurf im ER-Modell)

Mehr

Datenbanken. Einführung

Datenbanken. Einführung Datenbanken Einführung Einsatzbereiche von Datenbanken Unterstützung von Routinearbeiten Mehrfachnutzung von Daten Bewältigung der Informationsflut Fehlervermeidung Änderungen vornehmen Verbesserung der

Mehr

Handbuch für Redakteure

Handbuch für Redakteure Handbuch für Redakteure Erste Schritte...2 Artikel erstellen... 3 Artikelinhalt bearbeiten... 4 Trennen der Druck- und Online-Version...5 Budget-Anzeige...5 Artikel bearbeiten... 6 Artikel kopieren...6

Mehr

6.1 Datenbanksysteme. WS 2012 LV Informatik-I für Verkehrsingenieure. Dr. rer.nat. D. Gütter

6.1 Datenbanksysteme. WS 2012 LV Informatik-I für Verkehrsingenieure. Dr. rer.nat. D. Gütter Fakultät Informatik Institut Systemarchitektur Professur Rechnernetze WS 2012 LV Informatik-I für Verkehrsingenieure 6.1 Datenbanksysteme Dr. rer.nat. D. Gütter Mail: WWW: Dietbert.Guetter@tu-dresden.de

Mehr

Datenbanken Kapitel 2

Datenbanken Kapitel 2 Datenbanken Kapitel 2 1 Eine existierende Datenbank öffnen Eine Datenbank, die mit Microsoft Access erschaffen wurde, kann mit dem gleichen Programm auch wieder geladen werden: Die einfachste Methode ist,

Mehr

Kapitel 3: Datenbanksysteme

Kapitel 3: Datenbanksysteme LUDWIG- MAXIMILIANS- UNIVERSITY MUNICH DEPARTMENT INSTITUTE FOR INFORMATICS Skript zur Vorlesung: Einführung in die Informatik: Systeme und Anwendungen Sommersemester 2009 Kapitel 3: Datenbanksysteme Vorlesung:

Mehr

3. Das Relationale Datenmodell

3. Das Relationale Datenmodell 3. Das Relationale Datenmodell Das Relationale Datenmodell geht zurück auf Codd (1970): E. F. Codd: A Relational Model of Data for Large Shared Data Banks. Comm. of the ACM 13(6): 377-387(1970) DBMS wie

Mehr

IT-Kompaktkurs. Datenbanken Skript zur Folge 5. Prof. Dr. Georg Herde Fachhochschule Deggendorf

IT-Kompaktkurs. Datenbanken Skript zur Folge 5. Prof. Dr. Georg Herde Fachhochschule Deggendorf IT-Kompaktkurs Skript zur Folge 5 Prof. Dr. Georg Herde Fachhochschule Deggendorf Semantisches Datenmodell, Entity-Relationship, Normalformen Bei der Entwicklung einer Datenbank wird das Ziel angestrebt,

Mehr

KUNERT BRANDSCHUTZDATENTECHNIK

KUNERT BRANDSCHUTZDATENTECHNIK WARTUNGS- VERWALTUNGS- UND ABRECHNUNGSSYSTEME Modul: Kleiderkammer KUNERT BRANDSCHUTZDATENTECHNIK email: kunert@feuerwehrsoftware.de URL: http://www.feuerwehrsoftware.de Inhaltsverzeichnis 1.0 Programmstart

Mehr

Übung Datenbanksysteme

Übung Datenbanksysteme Übung Datenbanksysteme Martin Reifberger Übungsaufgabe 1 Sachverhalt: Ein mittelständiges Industrieunternehmen möchte sein Auftragswesen datenbankbasiert organisieren, da die tägliche Flut auflaufender

Mehr

Normalformen: Sinn und Zweck

Normalformen: Sinn und Zweck Normalformen: Sinn und Zweck Redundanz und Inkonsistenz vermeiden Anomalien vermeiden Verlustlose Zerlegungen finden Abhängigkeiten bewaren NF2 und NF3 behandeln das Verhältnis zwischen Schlüsselund Nichtschlüssel-

Mehr

Mathematik für Studierende der Biologie und des Lehramtes Chemie Wintersemester 2013/14. Auswahl vorausgesetzter Vorkenntnisse

Mathematik für Studierende der Biologie und des Lehramtes Chemie Wintersemester 2013/14. Auswahl vorausgesetzter Vorkenntnisse UNIVERSITÄT DES SAARLANDES FACHRICHTUNG 6.1 MATHEMATIK Dipl.-Math. Kevin Everard Mathematik für Studierende der Biologie und des Lehramtes Chemie Wintersemester 2013/14 Auswahl vorausgesetzter Vorkenntnisse

Mehr

Inhaltsverzeichnis. jetzt lerne ich

Inhaltsverzeichnis. jetzt lerne ich Inhaltsverzeichnis jetzt lerne ich Einführung 15 1 Erste Schritte 21 1.1 Datenbanken und Datenbank-Managementsysteme 21 1.2 Zugriff auf Datenbanken 22 1.3 Was der Großvater noch wusste... 22 1.4 Einordnung

Mehr

Access Kapitel 12 Lernzielkontrolle Access 2016 Beantworten Sie die folgenden 18 Fragen

Access Kapitel 12 Lernzielkontrolle Access 2016 Beantworten Sie die folgenden 18 Fragen www.computertraining4you.eu Schnell und einfach fit am P ccess Kapitel 12 Lernzielkontrolle ccess 2016 eantworten Sie die folgenden 18 Fragen Im Ordner 12_kapitel lernzielkontrolle finden Sie alle notwendigen

Mehr

1 Architektur, Modellierung und Entwurf

1 Architektur, Modellierung und Entwurf 1 1 Architektur, Modellierung und Entwurf Dieses erste Kapitel richtet sich an Datenbankneulinge und an alle, denen die Grundlagen relationaler Datenbanksysteme, die Techniken zur Datenmodellierung oder

Mehr

2) Nennen Sie die Namen der 3 Ebenen des 3-Ebenen-Modells, und geben Sie an, was in jeder Ebene dargestellt wird.

2) Nennen Sie die Namen der 3 Ebenen des 3-Ebenen-Modells, und geben Sie an, was in jeder Ebene dargestellt wird. Übungen und Lösungen 1. Einführung Datenbanken 1) Welche Datenbanktypen kennen Sie? Wodurch sind sie gekennzeichnet? Hierarchische Datenbanken: Zwischen den Datensätzen besteht eine untergeordnete Rangfolge.

Mehr

Inhalte: -Datenbanken und DBMS - Grundlagen -Einstieg in MS Access 2007:

Inhalte: -Datenbanken und DBMS - Grundlagen -Einstieg in MS Access 2007: Kursleiter: David Niegisch Inhalte: -Datenbanken und DBMS - Grundlagen -Einstieg in MS Access 2007: -Tabellen -Abfragen -Formulare -Berichte -Kursbegleitende Übungen Kursaccounts: Benutzer: zkknn01 - zkknn20

Mehr

Lehrlings- und Fachausbildungsstelle. EDV-Prüfungsprogramm

Lehrlings- und Fachausbildungsstelle. EDV-Prüfungsprogramm Lehrlings- und Fachausbildungsstelle EDV-Prüfungsprogramm Bedienungsanleitung DI Friedrich Koczmann Seite 1 02.09.09 Inhaltsverzeichnis 1 Allgemeines...4 1.1 Voraussetzungen...4 1.2 Funktionen des Programms...4

Mehr

DATENBANKEN SQL UND SQLITE VON MELANIE SCHLIEBENER

DATENBANKEN SQL UND SQLITE VON MELANIE SCHLIEBENER DATENBANKEN SQL UND SQLITE VON MELANIE SCHLIEBENER INHALTSVERZEICHNIS 1. Datenbanken 2. SQL 1.1 Sinn und Zweck 1.2 Definition 1.3 Modelle 1.4 Relationales Datenbankmodell 2.1 Definition 2.2 Befehle 3.

Mehr

3. Übung. Einführung MS Access. TU Dresden - Institut für Bauinformatik Folie-Nr.: 1

3. Übung. Einführung MS Access. TU Dresden - Institut für Bauinformatik Folie-Nr.: 1 WP3-13 Bauinformatik-Vertiefte Grundlagen 3. Übung Einführung MS Access Folie-Nr.: 1 Allgemeines Microsoft Access ist ein Datenbank-Management-System (DBMS) zur Verwaltung von Daten in Datenbanken und

Mehr

Datenbanken: ER-Modell

Datenbanken: ER-Modell Beispiel: Lastenheft: Für eine Hochschule soll eine Verwaltungssoftware geschrieben werden, die alle relevanten Daten in einem relationalen Datenbanksystem speichert. Zu diesen Daten zählen die Stamm-

Mehr

Einführung in Datenbanken

Einführung in Datenbanken Einführung in Datenbanken Dipl.-Inf. Michael Wilhelm Hochschule Harz FB Automatisierung und Informatik mwilhelm@hs-harz.de aum 2.202 Tel. 03943 / 659 338 1 Inhalt 1. Grundlegende Begriffe der Datenbanktechnologie

Mehr

Kapitel 33. Der xml-datentyp. In diesem Kapitel: Der xml-datentyp 996 Abfragen aus xml-datentypen 1001 XML-Indizierung 1017 Zusammenfassung 1023

Kapitel 33. Der xml-datentyp. In diesem Kapitel: Der xml-datentyp 996 Abfragen aus xml-datentypen 1001 XML-Indizierung 1017 Zusammenfassung 1023 Kapitel 33 Der xml-datentyp In diesem Kapitel: Der xml-datentyp 996 Abfragen aus xml-datentypen 1001 XML-Indizierung 1017 Zusammenfassung 1023 995 996 Kapitel 33: Der xml-datentyp Eine der wichtigsten

Mehr

Datenbanken 16.1.2008. Die Entwicklung der Datenbanksysteme ist eng an die der Hardware gekoppelt und wird wie jene in Generationen eingeteilt:

Datenbanken 16.1.2008. Die Entwicklung der Datenbanksysteme ist eng an die der Hardware gekoppelt und wird wie jene in Generationen eingeteilt: Datenbanksysteme Entwicklung der Datenbanksysteme Die Entwicklung der Datenbanksysteme ist eng an die der Hardware gekoppelt und wird wie jene in Generationen eingeteilt: 1. Generation: In den fünfziger

Mehr

Kapitel 8: Physischer Datenbankentwurf

Kapitel 8: Physischer Datenbankentwurf 8. Physischer Datenbankentwurf Seite 1 Kapitel 8: Physischer Datenbankentwurf Speicherung und Verwaltung der Relationen einer relationalen Datenbank so, dass eine möglichst große Effizienz der einzelnen

Mehr

Klausur zur Vorlesung Datenbanken I im Wintersemester 2011/12

Klausur zur Vorlesung Datenbanken I im Wintersemester 2011/12 Prof. Dr. Lutz Wegner, Dipl.-Math. Kai Schweinsberg 21.03.2012 Klausur zur Vorlesung Datenbanken I im Wintersemester 2011/12 Name:... Vorname:... Matr.Nr.:... Studiengang:... Hinweis: Bearbeiten Sie alle

Mehr

1. DATENBANKDESIGN RELATIONALES DATENBANKMODELL

1. DATENBANKDESIGN RELATIONALES DATENBANKMODELL 1. DATENBANKDESIGN Access ist die führende relationale Datenbank im Desktop-Bereich. Die Einfachheit in der Bedienung täuscht oft etwas darüber hinweg, dass eine Datenbank doch etwas ist, was nicht in

Mehr

Datenorganisation. Normalisierung... 5 Zweck der Normalisierung... 5 Unnormalisierte Form... 5 1. Normalform... 5. Beispiel 3. NF...

Datenorganisation. Normalisierung... 5 Zweck der Normalisierung... 5 Unnormalisierte Form... 5 1. Normalform... 5. Beispiel 3. NF... Datenorganisation Datenbank-Entwurf... 2 Datenbanksystem DBS... 2 DBMS... 2 Funktionen DBMS... 2 Architektur DBMS... 2 DB-Entwurfsphasen... 2 Realitätsanalyse... 2 Semantisches Datenmodell... 3 Zielsetzung

Mehr

Grundlagen von Datenbanksystemen

Grundlagen von Datenbanksystemen Ramez Elmasri Shamkant B. Navathe Grundlagen von Datenbanksystemen 3., überarbeitete Auflage ein Imprint der Pearson Education Deutschland GmbH Inhaltsverzeichnis Vorwort 9 Über die Autoren 13 Teil 1 Grundkonzepte

Mehr

SQL: statische Integrität

SQL: statische Integrität SQL: statische Integrität.1 SQL: statische Integrität Im allgemeinen sind nur solche Instanzen einer Datenbank erlaubt, deren Relationen die der Datenbank bekannten Integritätsbedingungen erfüllen. Integritätsbedingungen

Mehr

Datenbanken für Online Untersuchungen

Datenbanken für Online Untersuchungen Datenbanken für Online Untersuchungen Im vorliegenden Text wird die Verwendung einer MySQL Datenbank für Online Untersuchungen beschrieben. Es wird davon ausgegangen, dass die Untersuchung aus mehreren

Mehr

SQL- & NoSQL-Datenbanken - Speichern und Analysen von großen Datenmengen

SQL- & NoSQL-Datenbanken - Speichern und Analysen von großen Datenmengen SQL- & NoSQL-Datenbanken - Speichern und Analysen von großen Datenmengen Lennart Leist Inhaltsverzeichnis 1 Einführung 2 1.1 Aufgaben einer Datenbank...................... 2 1.2 Geschichtliche Entwicklung

Mehr

7. Übung - Datenbanken

7. Übung - Datenbanken 7. Übung - Datenbanken Informatik I für Verkehrsingenieure Aufgaben inkl. Beispiellösungen 1. Aufgabe: DBS a Was ist die Kernaufgabe von Datenbanksystemen? b Beschreiben Sie kurz die Abstraktionsebenen

Mehr

Einführung Datenbank

Einführung Datenbank Einführung Datenbank Einführung Datenbank Seite 2 Einführung in die Arbeit mit einer Datenbank Grundbegriffe: Datenbank - Datenbankmanagementsystem Eine Datenbank ist eine systematische strukturierte Sammlung

Mehr

4. Datenabfrage mit QBE 11

4. Datenabfrage mit QBE 11 Informationsbestände analysieren Datenabfrage mit QBE 4. Datenabfrage mit QBE 11 4.1. QBE vs. SQL Relationale Datenbanken haben schon früh den Anspruch gestellt, auch für Nicht- Informatiker nutzbar zu

Mehr

KUNERT BRANDSCHUTZDATENTECHNIK

KUNERT BRANDSCHUTZDATENTECHNIK WARTUNGS- VERWALTUNGS- UND ABRECHNUNGSSYSTEME Modul: Inventarisierung KUNERT BRANDSCHUTZDATENTECHNIK email: kunert@feuerwehrsoftware.de URL: http://www.feuerwehrsoftware.de Inhaltsverzeichnis 1.0 Programmstart

Mehr

Modul 8: Verwalten von Kunden, Artikeln und mehr - Datenlisten

Modul 8: Verwalten von Kunden, Artikeln und mehr - Datenlisten Excel 2003 - Grundkurs 85 Modul 8: Verwalten von Kunden, Artikeln und mehr - Datenlisten Wofür kann ich Datenlisten einsetzen? Worin liegt der Unterschied zu einer Datenbank? Wie gebe ich rationell Daten

Mehr

Datenbankmodelle 1. Das Entity-Relationship-Modell

Datenbankmodelle 1. Das Entity-Relationship-Modell Datenbankmodelle 1 Das Entity-Relationship-Modell Datenbankmodelle ER-Modell hierarchisches Modell Netzwerkmodell relationales Modell objektorientierte Modelle ER Modell - 2 Was kann modelliert werden?

Mehr

Kapitel DB:III. III. Konzeptueller Datenbankentwurf

Kapitel DB:III. III. Konzeptueller Datenbankentwurf Kapitel DB:III III. Konzeptueller Datenbankentwurf Einführung in das Entity-Relationship-Modell ER-Konzepte und ihre Semantik Charakterisierung von Beziehungstypen Existenzabhängige Entity-Typen Abstraktionskonzepte

Mehr

DV-Organisation und Anwendungsentwicklung. 4. Klausur

DV-Organisation und Anwendungsentwicklung. 4. Klausur MUSTERLÖSUNG WADV 1b 29.04.2005 120 Min. 1 DV-Organisation und Anwendungsentwicklung 4. Klausur A1 A2 A3 SUMME Maximale Punktzahl 20 15 25 60 Erreichte Punktzahl NOTE: MUSTERLÖSUNG WADV 1b 29.04.2005 120

Mehr

Datenbankmodelle 1. Das Entity-Relationship-Modell. Prof. Dr. Bernhard Schiefer 2-1

Datenbankmodelle 1. Das Entity-Relationship-Modell. Prof. Dr. Bernhard Schiefer 2-1 Datenbankmodelle 1 Das Entity-Relationship-Modell Prof. Dr. Bernhard Schiefer 2-1 Datenbankmodelle ER-Modell hierarchisches Modell Netzwerkmodell relationales Modell objektorientierte Modelle Prof. Dr.

Mehr

Synchronisation der EVAL2000 Arbeitsplatzevaluierungsdatenbank mit externen Tabellen

Synchronisation der EVAL2000 Arbeitsplatzevaluierungsdatenbank mit externen Tabellen Synchronisation der EVAL2000 Arbeitsplatzevaluierungsdatenbank mit externen Tabellen Inhalt Datenbank zum Bearbeiten vorbereiten... 2 Festlegen, in welche Datenbank die Abfragen eingebaut werden sollen...

Mehr

Fundamentals of Software Engineering 1

Fundamentals of Software Engineering 1 Folie a: Name Fundamentals of Software Engineering 1 Grundlagen der Programmentwurfstechnik 1 Sommersemester 2012 Dr.-Ing. Stefan Werner Fakultät für Ingenieurwissenschaften Folie 1 Inhaltsverzeichnis

Mehr

Datenbanktechnologie mit praktischen Übungen in MySQL und PHP

Datenbanktechnologie mit praktischen Übungen in MySQL und PHP Datenbanktechnologie mit praktischen Übungen in MySQL und PHP Übung, Sommersemester 2013 29. April 2013 - MySQL 2 Sebastian Cuy sebastian.cuy@uni-koeln.de Aufgaben Anmerkungen Best practice: SQL Befehle

Mehr

Verwandt, logisch kohärent, zweckspezifisch, an reale Welt orientiert. Entität kann in einer oder mehreren Unterklassen sein

Verwandt, logisch kohärent, zweckspezifisch, an reale Welt orientiert. Entität kann in einer oder mehreren Unterklassen sein 1 Definitionen 1.1 Datenbank Verwandt, logisch kohärent, zweckspezifisch, an reale Welt orientiert Integriert, selbstbeschreibend, verwandt 1.2 Intension/Extension Intension: Menge der Attribute Extension:

Mehr

FinishWeb 3 Shop-Verwaltung

FinishWeb 3 Shop-Verwaltung FinishWeb 3 Shop-Verwaltung rhone.ch GmbH FinishWeb 3 Shop-Verwaltung Informationen zum Dokument Versionierung Version Datum Status Änderungen und Bemerkungen Autor 0.1.0 22.05.07 Draft Erste Version Iwan

Mehr

EDV-GESTÜTZTES ENTWERFEN, BERECHNEN UND KONSTRUIEREN IM BAUINGENIEURWESEN Prof. Dr.-Ing. Klaus Wassermann MODULPRÜFUNG

EDV-GESTÜTZTES ENTWERFEN, BERECHNEN UND KONSTRUIEREN IM BAUINGENIEURWESEN Prof. Dr.-Ing. Klaus Wassermann MODULPRÜFUNG EDV-GESTÜTZTES ENTWERFEN, BERECHNEN UND KONSTRUIEREN IM BAUINGENIEURWESEN Prof. Dr.-Ing. Klaus Wassermann MODULPRÜFUNG Bachelorstudiengang Facility Management Informatik am 26. September 2007 Name, Vorname

Mehr

Historische Lagerbestände / Lagerbewertung

Historische Lagerbestände / Lagerbewertung Desk Software & Consulting GmbH Historische Lagerbestände / Lagerbewertung Erweiterung zur Sage Office Line Warenwirtschaft Benjamin Busch DESK Software & Consulting GmbH DESK Software und Consulting GmbH

Mehr

Aufgabe 1: Erstellen Sie auf Basis des folgenden Anwendungsfalls ein Konzeptuelles Modell.

Aufgabe 1: Erstellen Sie auf Basis des folgenden Anwendungsfalls ein Konzeptuelles Modell. Aufgabe 1: Erstellen Sie auf Basis des folgenden Anwendungsfalls ein Konzeptuelles Modell. Sie lesen in der Zeitung, dass die Firma Facebook nach Meinung der Investment Banker von Goldman und Sachs - mittlerweile

Mehr

ACCESS das Datenbankprogramm. (Aufbau) DI (FH) Levent Öztürk

ACCESS das Datenbankprogramm. (Aufbau) DI (FH) Levent Öztürk ACCESS das Datenbankprogramm Vom Microsoft (Aufbau) DI (FH) Levent Öztürk Inhalt Projektentwicklung Planung einer Datenbank Implementierung einer Datenbank Testen der Datenbank Formulare Berichte SQL-Abfragen

Mehr

Distribution Group. Anlegen und Administrieren

Distribution Group. Anlegen und Administrieren Distribution Group Anlegen und Administrieren Einleitung: Als Ablösung der vorhandenen (Global/Domain lokal) Gruppen, wird ab sofort nur noch der Gruppentyp Distribution Groups/Security angelegt und benutzt.

Mehr