Datenbank Modellierung - Einführung

1
Datenbank Modellierung - Einführung
AnPr
Name
Datum
Klasse
Die Notwendigkeit von Datenbanksystemen
Den Begriff „Datenbank“ haben viele schon mal gehört – auch wenn man nicht aus dem IT-Fach kommt. Wir
verbinden mit diesem Begriff stets eine Ansammlung von Informationen, welche wir in irgendeiner Form
abfragen, bzw. nutzen können. Die meisten gehen auch davon aus, dass die Informationen „irgendwie“ in
Tabellen abgelegt sind. Den Begriff „Tabellen“ kennen viele aus sogenannten „Tabellenkalkulationsprogrammen“, von denen bspw. Microsoft Excel oder OpenOffice Calc bekannte Vertreter sind.
Die Frage ist, warum Excel und Co. nicht für alle datenrelevanten Anwendungen genutzt werden. Schließlich
kann man Daten in derartige Programme doch sehr einfach eintragen und wieder auslesen! Das Problem ist,
dass man mit diesen Programmen einige Nachteile in Kauf nehmen muss:
•
•
•
•
•
•
•
•
•
Sie manipulieren oft die Daten bei Eingabe, da sie eingabezentriert sind.
Die Verknüpfungsfunktionen sind umständlich.
Die Verknüpfungen sind inperformant.
Die Datenmenge ist begrenzt.
Es gibt keine Möglichkeit der Indizierung.
Es gibt kein durchgängiges Usermanagment.
Der parallele Zugriff ist nur bedingt möglich.
Sie sind nicht skalierbar.
Usw. usf.
„Wenn ein Tabellenkalkulationsprogramm ein Schweizer Taschenmesser ist,
dann ist eine Datenbank eine Fabrik.“
Streng genommen handelt es sich bei einem Tabellenkalkulationsprogramm
auch um eine Datenbank, wenngleich
der Ansatz von einem klassischen Datenbanksystem sich in wesentlichen Teilen unterscheidet. Hier nochmal ein
Vergleich der beiden Ansätze:
Eigenschaft:
Hauptziel
Dateneingabe
Datenausgabe
Datenstrukturierung
Usermanagement
Datenvolumen
1
Tabellenkalkulation:
Einfache Nutzung und schnelle Anpassungen.
Direkt in das File über GUI
Über GUI oder via Skripte auf Textfiles
Über GUI in einzelnen Tabs, Spalten
und Zeilen. Datenfelder können individuell typisiert werden.
In der Regel über Passwortvergabe
auf einzelne Bereiche. Userzugriffssteuerung meist nur auf Fileebene.
Wenige 1000 Datensätze sind noch
performant verwaltbar – im Bereich
von zweistelligen Megabytes, wobei
Datenverknüpfungen sehr langsam
sind.
Datenbank:
Kurze Zugriffszeiten.
Über SQL1
Über SQL
Über Tabellenstrukturen via SQL (DDL),
wobei die Typisierung auf Spaltenebene,
nicht auf Feldebene durchgeführt wird.
Je nach Hersteller können Userzugriffsrechte bis auf Datensatzebene gesetzt
werden. Über Views beliebig einstellbar.
Millionen von Datensätzen sind handlebar – im Bereich von mehreren Terrabytes.
Structured Query Language
DB_ModellierungEinfuehrung_v01.docx
Seite 1
Datenbank Modellierung - Einführung
Eigenschaft:
Flexibilität
Nutzung
Architektur
AnPr
Tabellenkalkulation:
Datenbank:
Sehr hoch – es können jederzeit Än- Eher gering. Strukturelle Anpassungen
derungen eingebracht werden.
erfolgen über SQL, wobei diese meist
über Softwareprojekte laufen müssen.
Meist nur durch einen User gleichzei- Die Steuerung von parallelen Zugriffen
tig. Parallele Zugriffe sind möglich, erfolgt durch das Datenbank Manageführen jedoch oft zu Inkonsistenzen.
ment System.
Fat Client.
Client Server.
Wir sehen also, für größere Systeme ist ein Tabellenkalkulationsprogramm nicht geeignet. Hier sind wir auf
Datenbanksysteme DBMS angewiesen.
2
Definition der Grundbegriffe
Da es verschiedene Ansätze gibt, Datenbanken zu konzipieren, sei hier nochmal kurz auf diese eingegangen.
Historisch gesehen können diese Ansätze in einer Reihenfolge genannt werden:
Hierarchische Datenbanken.
Hier werden die Daten in einer Baumstruktur abgelegt. Jedes Element (bis auf das
Wurzelelement) besitzt genau ein Elternelement und 0 bis viele Kindelemente. Die
Organisation der Files auf unserem Rechner würde einem solchen System entsprechen. Die hierarchischen Datenbanken wurden früher genutzt, als die Verzögerungszeit beim Zugriff auf verschiedene Datensätze recht hoch war. Heute findet man
derartige Systeme nur noch selten – wobei man neuere XML Datenbanken durchaus als hierarchisch bezeichnen kann. Lediglich bei Verzeichnisdiensten, welche mit LDAP angesprochen werden können finden sich noch
derartige Systeme.
Relationale Datenbanken.
Bei der Relationalen Datenbank werden die Daten in Tabellen abgelegt, welche wiederum in Beziehung zueinander stehen. Die einzelnen Datensätze bilden die Zeilen
in den Tabellen, die Attribute(Eigenschaftstypen) werden durch die Spalten abgebildet. Über die Attribute werden auch Beziehungen zwischen den Tabellen darstellbar.
Diese Art der Datenorganisation ist derart flexibel, dass die allermeisten laufenden
Datenbanksysteme als Relationale Datenbanken aufgebaut sind. Aus diesem Grund wird sich der Unterricht
auch hierauf exklusiv konzentrieren.
Objektorientierte Datenbanken.
In der Programmierung gilt der objektorientierte Ansatz oftmals als gesetzt. Relationale Datenbanken können
jedoch den objektorientierten Ansatz nicht 1:1 abbilden. Einfachstes Beispiel wäre die Abbildung von Methoden innerhalb der Objekte, welche durch ein relationales Modell nicht ohne weiteres darstellbar ist. Um dieses
Problem zu lösen, wurden objektorientierte Datenbanken geschaffen. Da sie jedoch sehr speziell auf das vorhin
genannte Problem zugeschnitten sind, finden sie in der Praxis nur sehr selten Anwendung.
Objekrelationale Datenbanken.
Hierunter versteht man die Erweiterung einer relationale Datenbank um objektorientierte Komponenten. Im
Wesentlichen geht es darum, die Datenhaltung einer Datenbank mit der Datenhaltung eines Objektes möglichst
effizient zu synchronisieren. Da die Technologie auf einer relationalen Datenbank aufsetzt und somit existierende Systeme weitergenutzt werden können, ist die Akzeptanz von objektrelationalen Datenbanken im Vergleich zu rein objektorientierten Datenbanken sehr viel höher.
Seite 2
AnPr
Datenbank Modellierung - Einführung
NoSQL Datenbanken.
Hierunter versteht man alle nicht relationalen Datenbankansätze neuerer Generation. NoSQL steht für „Not
only SQL“ und soll die Abgrenzung zu den relationalen Ansätzen wiederspiegeln. Streng genommen können
die objektorientierten Datenbanken bereits unter NoSQL geführt werden. NoSQL ist durchaus als Trend zu
sehen, da bspw. der relationale Ansatz bei extrem großen Datenmengen aufgrund der JOINS zu sehr langsamen
Responsezeiten führt und somit Alternativen gefunden werden mussten. Diese NoSQL Ansätze sind zumeist
sehr speziell auf gewisse Problemstellungen ausgerichtet. Insofern wundert es nicht, dass entsprechend viele
NoSQL Konzepte existieren. Einen guten Überblick kann man sich über die Seite http://nosql-database.org/
verschaffen.
Ganz allgemein müssen Datenbanken folgende Aufgaben bewältigen können:




Der User muss Zugriff auf die Daten haben, ohne dass er die dahinter liegende Organisationsstruktur
kennen muss.
Das System muss in der Lage sein, die Zugriffe zu kontrollieren und unberechtigte Zugriffe zu verhindern.
Das Programm, welches auf die Daten zugreift sollte von der Datenstruktur entkoppelt sein, so dass
interne Änderungen auf der Datenbank nicht zwingend zu Anpassungen des Programms führen.
Das System muss dem User ermöglichen, die Daten strukturiert zu verwalten – also Daten einfügen,
ändern und löschen.
Eine Datenbank ist ein System zur Datenorganisation
mit dem Zweck, die Daten dauerhaft, sicher und flexibel zu verwalten.
Aus diversen anderen Softwareprogrammen kennen wir bereits die Trennung von Daten und Programm. Dies
gilt für Datenbanksysteme genauso. Neben dieser Aufteilung können wir noch weitere Komponenten voneinander unterscheiden:
Datenbankverwaltungssystem (DBMS)
Das „DatenBank Mangament System“ ist der eigentliche Kern unseres
Systems – das Programm, welches die Aktivtäten zur Datenverwaltung
übernimmt. Üblicherweise finden wir das DBMS auf einem Server wieder. Das DBMS wiederum verwaltet 1 bis mehrere Datenbanken.
Datenbankclient
Um auf die Daten in der Datenbank zugreifen zu können, bedarf es einen Client. Dieser ist für den Entwickler
und Administrator im Regelfall ein Tool um SQL Statements zu erzeugen und zum DBMS zu senden. Für den
Enduser ist der Client fast immer eine Software, in der die SQL Statements bereits gespeichert sind. Der User
bekommt somit nichts davon mit, dass seine Daten in einer Datenbank gespeichert sind. Programme müssen
über geeignete Schnittstellen (bspw. ODBC) mit der Datenbank kommunizieren.
Datenbanksprache
Relationale Datenbanken werden in aller Regel mit SQL (Structured Query Language) angesprochen. Die
Kommunikation der Clients mit dem DBMS erfolgt ausschließlich über SQL. Hierbei können vier wesentliche
Aufgabenbereiche definiert werden:
 Datendefinition – hier wird der Aufbau der einzelnen Tabellen festgelegt. Oftmals wird das Subset
von SQL für die Datendefinition auch als Data Definition Language oder kurz DDL bezeichnet.
 Datenmanipulation – dies dient zum erzeugen, ändern und löschen von Datensätzen. Dieser Teil von
SQL wird auch als Data Manipulation Language oder kurz DML bezeichnet.
Seite 3
Datenbank Modellierung - Einführung

Datenabfrage – was statistisch den Hauptteil der SQL Aktionen im DBMS ausmacht. Hier werden die
Daten aus der Datenbank ausgelesen. In Anlehnung an DDL und DML hat man hier den Begriff Data
Retrieval Language bzw. DRL geschaffen, was jedoch selten in der Praxis verwendet wird.
Datenschutz – hiermit wird der Schutz von Daten gegenüber unberechtigten Zugriffen bezeichnet. Der
Begriff für diesen Teilbereich ist Data Security Language.

3
AnPr
Datenmodellierung
In den folgenden Kapiteln werden wir uns damit beschäftigen, wie wir Daten sinnvoll modellieren. Sehen wir
uns zuerst eine beispielhafte Definition des Begriffs an (diesen habe ich aus http://wirtschaftslexikon.gabler.de/Definition/datenmodellierung.html):
Datenmodellierung ist die formale Beschreibung der Informationsobjekte eines zu entwerfenden Informationssystems. Ziel ist die eindeutige Definition und Spezifikation der in einem Informationssystem zu verwaltenden Objekte, ihrer für die Informationszwecke erforderlichen Attribute und der Zusammenhänge zwischen verschiedenen Informationsobjekten, um so einen Überblick über die Datensicht des Informationssystems erhalten zu können. Ergebnis des Modellierungsprozesses ist ein sog. Datenschema, das zumeist grafisch* visualisiert wird.
(* als ER Modell)
Das klingt schon mal recht kompliziert. Gehen wir aber die wichtigsten Schlüsselbegriffe mal durch:
Begriff:
Informationssystem
Objekt
Attribut
Zusammenhänge
Datenschema
ER Modell
Erklärung:
Sämtliche zusammenhängenden Applikationen mitsamt Usern, wobei wir für
uns das physische Datenmodell in den Fokus stellen und somit „nur“ die Tabellen betrachten werden.
Das, was wir tatsächlich in unserer Datenbank verwalten wollen, also die Daten. Dies muss nicht zwingend ein reales Objekt sein, sondern kann auch etwas
rein virtuelles sein.
Eigenschaftstyp eines einzelnen Objektes, so dass die verschiedenen Objekte
voneinander unterscheidbar sind.
Beziehungen zwischen den Objekten (und streng genommen auch innerhalb
der Objekte). Diese werden über die Attribute modelliert.
Formale Beschreibung der Datenstrukturen – in der Datenmodellierung meist
als „ER – Diagramm“. Hieraus können die eigentlichen Tabellen erzeugt werden.
Grafische Beschreibung eines Datenmodells bzw. Datenschemas. Es wurde ursprünglich von Peter Chen vorgestellt und seitdem mehrfach erweitert.
Wir beschäftigen uns also damit, wie wir reale Zusammenhänge in einer für Datenbanken optimierten Form
dargestellt werden können.
Es gibt durchaus eine gewisse Verwirrung, was die Begrifflichkeiten angehen. Dies kommt oftmals von der
unterschiedlichen Sichtweise der Akteure. Im Wesentlichen finden wir den Datenmodellierer, welcher die
Konzeption festhält und den Techniker vor, welcher die Modelle in ein physisches Modell umsetzt. Die meisten Bücher fokussieren sich auf die konzeptionelle Sichtweise, wobei wir im Regelfall die technische „Brille“
aufhaben. Insofern hier nochmal die wichtigsten Begriffe, welche uns beschäftigen werden:
Entität (Entity, Objekt):
Das ist das Objekt, was gespeichert werden soll. Es kann sich um ein reales „Ding“ handeln, wie ein Auto in
einer Verkaufsdatenbank, um reale Personen wie etwa in einer Kundendatenbank oder auch etwas Abstraktes
wie ein Konto, oder einfach nur ein Zustand, wie bspw. der Kontostand. Technisch ist dies in aller Regel ein
Datensatz in einer Tabelle, ein sogenanntes Tupel. Eine Entität hat folgende Eigenschaften:


Seite 4
Tatsächliches Objekt der realen Welt oder unserer Vorstellung.
Eindeutig bestimmbar und somit von anderen Objekten unterscheidbar.
AnPr

Datenbank Modellierung - Einführung
Besitzt Attributsausprägungen, welche zur eindeutigen Bestimmung der Entität verwendet werden
können. Sind von zwei Entitäten alle Attributsausprägungen identisch, so sind sie nicht voneinander
zu unterscheiden.
Entitätstyp (Entitätsklasse, Relation, Tabelle):
Gleichartige Entitäten werden als Entitätstypen bezeichnet. Hierbei entscheidet der Datenmodellierer, welche
Eigenschaftstypen relevant sind. So sind bspw. für einen Automechaniker der Motorentyp und die Antriebsart
für wichtig – der Lackierer hingegen ist eher an der Farbe interessiert. Insofern würden bei der Modellierung
einer Datenbank für Automechaniker andere Kriterien gelten, als bei der Modellierung einer Datenbank für
Autolackierer, obwohl in beiden Entitätstypen Autos gespeichert werden würden. Technisch wird ein Entitätstyp üblicherweise in einer Tabelle münden, welche in der Datenmodellierung auch als „Relation“ bezeichnet
wird. Ein Entitätstyp hat folgende Eigenschaften:



Klassifikation aller Entitäten mit gleichen Attributen.
Entitäten eines Entitätstyps „gehören zusammen“.
Besitzt Attribute.
Entitätsmenge (Entity-Set):
Eine Entitätsmenge ist eine Zusammenfassung von Entitäten gleichen Entitätstyps. In einer realen Applikation
wären das bspw. alle Kunden eines Unternehmens. Dies würde somit der Tabelleninhalt der Kundentabelle
sein. Mitunter wird als Entitätsmenge auch eine Untermenge einer Tabelle gewertet – also alle Kunden aus
dem PLZ Bereich XYZ eines Unternehmens.

Sammlung von Entitäten mit gleichen Entitätstyp
Attribut (Eigenschaftstyp):
Attribute sind die Informationsträger, welche die Eigenschaften der Entitäten abbilden. In der technischen
Gestaltung sind dies die Spalten der Tabellen. Die Summe der Attribute definiert den Entitätstyp. Folgende
Punkte sind hierbei wichtig:





Attributsausprägungen definierten die Eigenschaft einer Entität
Attribute haben einen Wertebereich, der auch als „Domain“ bezeichnet wird.
Attribute, welche zur eindeutigen Identifikation einer Entität aus der gesamten Entitätsmenge herangezogen werden können nennt man Schlüsselattribut – oder kurz „Schlüssel“
Werden Schlüsselattribute dediziert zur Identifikation der Entitäten vom DB Designer ausgewiesen,
so nennt man sie Primärschlüssel. Diese dürfen während der gesamten Lebensdauer der Entität nicht
mehr geändert werden.
Oftmals wird ein technisch erzeugtes Attribut als Primärschlüssel verwendet – man spricht hier von
einem „künstlichen Schlüssel“ (oder auch „sprechender Schlüssel“ bzw. „Surrogatschlüssel“), im Gegensatz zu einem „natürlichen Schlüssel“ (oder auch „sprechender Schlüssel“), der als Attribut der
realen Entität bereits existiert (bspw. Fahrgestellnummer eines KFZ).
Beziehungen (Relationships, Assoziationen):
Die einzelnen Entitäten stehen in einer bestimmten Beziehung zueinander. Bspw. kann man zu jedem Konto
ein Eigentümer zugeordnet werden. Diese Beziehungen werden durch die Attribute und ggf. eigene Tabellen
modelliert. Folgendes ist hierbei zu wissen:



Beziehungen können zwischen 2 bis n Entitäten auftreten (wobei es meistens „nur“ zwischen 2 ist)
Die Anzahl, wie viele Entitäten einer Entitätsklasse zu den Entitäten einer anderen Entitätsklasse existieren können wird Kardinalität genannt.
Ohne die Beziehungen können die einzelnen Informationen nicht verknüpft werden.
Seite 5
Datenbank Modellierung - Einführung

AnPr
In relationalen Datenbanken werden die Beziehungen über Schlüssel (und ggf. zusätzliche Tabellen)
realisiert. Hierbei werden Primärschlüsselwerte einer Tabelle in einem eigenen Feld einer anderen
Tabelle eingetragen – welches als „Fremdschlüssel“ bezeichnet wird.
3.1 Elemente des ER Diagramms
Die folgenden Kapitel befassen sich mit der grafischen Notation der Strukturen. Hierbei orientieren wir uns an
den (modifizierten) Vorschlägen von Peter Chen, der den Grundstein der grafischen Datenmodellierung gelegt
hat.
Wird eine Datenbank designed, geht man (wie in der Informatik üblich) strukturiert vor2:
 Bestimmung der Entitäten
 Bestimmung der Beziehungen zwischen den Entitäten
 Festlegung der Kardinalitäten der Beziehungen
 Festlegung der Attribute der Entitäten
 Definition der Wertebereiche der Attribute
 Identifikation von (sprechenden) Schlüsseln der Entitäten
 Zeichnen des ER Diagramms
 Definition der Primär- und Fremdschlüssel
Hierbei läuft das Datenmodell verschiedene Level durch:
Konzeptionelles Datenmodell: Lediglich die Eintitätsnamen und die Relationen werden modelliert.
Logisches Datenmodell: Es kommen die Attribute und die Schlüssel (Primär- und Fremd-) hinzu.
Physisches Datenmodell: Es werden nur noch die technischen Elemente berücksichtigt. Hierbei können sich
die Namen der Attribute noch ändern, wenn gewisse technische Restriktionen gegen den logischen Namen
sprechen.
Hier ein kurzer Vergleich3:
Was:
Entitätsname
Beziehungen
Attribute
Primärschlüssel
Fremdschlüssel
Tabellennamen
Spaltennamen
Datentypen
Konzept:
ja
ja
Logik:
ja
ja
ja
ja
ja
Physik:
ja
ja
ja
ja
ja
Der zentralste Punkt ist die Realisierung des ER Diagramms (Entity Relationship Diagramm). Hierbei wird
eine grafische Entsprechung der späteren Implementierung geschaffen. Wie der Name schon nahelegt, werden
hierbei die Entitäten und deren Beziehungen modelliert, wobei wir nicht die eigentlichen Entitäten eintragen
(dies sind ja die einzelnen Datensätze), sondern die Entitysets oder Entiätsklassen.
3.1.1 Entity-Sets im ER Diagramm
Das Entity-Set wird durch ein benamtes Rechteck dargestellt. Attribute wiederum als Kreise, welche mittels Linien
mit dem Entity-Set verbunden sind. Primärschlüssel werden
unterstrichen dargestellt.
Wenn man davon ausgeht, dass in größeren Systemen die
Tabellen 20 und mehr Attribute haben kann man sich vorstellen, dass die Attribute nicht zur Übersicht beitragen und
oftmals weggelassen werden.
2
3
Orientiert an den Vorschlägen von Peter Chen
http://www.1keydata.com/
Seite 6
AnPr
Datenbank Modellierung - Einführung
3.1.2 Beziehungen im ER Diagramm
Die Beziehungen zwischen zwei Entity-Sets werden als Rauten visualisiert. In die Rauten kommt
ein Begriff, welcher die Beziehungsart spezifiziert.
Hierbei ist darauf zu achten, dass die Bezeichnungsart dem Leser weiterhilft („haben“ passt zwar
fast immer, hilft aber leider selten weiter).
Zusätzlich werden die Kardinalitäten eingetragen.
Im rechten Bild finden wir die drei Grundtypen:
1:1 bedeutet hierbei, dass der Kunde in genau einer
Adresse wohnt und in einer Adresse exakt ein
Kunde.
1:n zeigt an, dass ein Kunde n (also mehrere) Aufträge erstellen kann, ein Auftrag jedoch immer nur von einem
Kunden erstellt werden kann.
n:m heißt, ein Auftrag kann von m (mehreren) Sachbearbeitern bearbeitet werden, ein Sachbearbeiter kann
aber auch n (mehrere) Aufträge bearbeiten.
Es gibt Situationen, in denen die Beziehungen auch Attribute erhalten können
(also eigene Attribute besitzen). Ein solcher Fall wäre bspw. in der Beziehung
zwischen dem Auftrag und dem Sachbearbeiter – hier könnte das Datum der
letzten Bearbeitungsaktivität stehen. Diese Attribute würden ebenfalls als
Kreissymbol dargestellt werden.
Aber auch hier gilt, dass die Attribute zugunsten der Übersichtlichkeit oftmals
weggelassen werden.
3.2 Alternativen zur Chen Notation
Die in den vorausgegangenen Kapiteln vorgestellte Notationsform wird für konzeptionelle Zwecke sehr oft
eingesetzt (genauso wie für IHK Prüfungen). Trotzdem findet man noch eine sehr große Anzahl von weiteren
Notationsformen, welche sich mehr auf das logische bzw. physische Datenmodell konzentrieren. UML4 hat
natürlich eine Lösung parat, wobei in der Praxis zumeist die „Krähenfußnotation“ bzw. Crows Foot Notation
genutzt wird. Wer mit MySQL Workbench die grafische Datenmodellierung nutzt, wird ebendiese Notation
vorfinden.
Entitäten:
Entitäten werden als Rechteck dargestellt. Die oberste Zeile ist (meist) farblich abgesetzt und
trägt den Entitätsnamen. Beim physischen Datenmodell finden wir dort den Tabellennamen.
Der untere Block ist beim konzeptuellen Datenmodell leer, beim logischen und physischen
Datenmodell sind die Attribute aufgelistet, wobei die Primärschlüssel unterstrichen sind.
Im physischen Datenmodell sind zusätzlich noch die Datentypen hinterlegt, indem sie rechts
neben den Attributsnamen eingetragen werden.
4
UML: Unified Modeling Language
Seite 7
Datenbank Modellierung - Einführung
Beziehungen:
Der Darstellungsform der Beziehungen verdankt die
Crows Foot Notation ihren Namen. Mit Hilfe von den
„Krähenfüßen“ werden die Kardinalitäten vorgestellt.
Hierbei kann auch festgelegt werden, ob eine Beziehung vorhanden sein muss (also mindestens 1) oder
nicht (also kann 0 sein).
AnPr
Symbol:
Beziehung:
1 und genau 1.
1 oder 0.
1 oder n (also mehrere)
Eine 1:n Beziehung zwischen Kunden und Auftrag
wird also wie folgt dargestellt:
0 oder n (also mehrere)
Ein Kunde kann keinen Auftrage, einen oder mehrere erstellt haben. Ein Auftrag wurde aber immer von genau
einem Kunden erstellt.
Die Beziehungsart als Text über der Linie wird in der Praxis mitunter weggelassen, da das Ziel der Notation
meist die physische Umsetzung ist.
Seite 8
AnPr
4
Datenbank Modellierung - Einführung
Lizenz
Diese(s) Werk bzw. Inhalt von Maik Aicher (www.codeconcert.de) steht unter einer
Creative Commons Namensnennung - Nicht-kommerziell - Weitergabe unter gleichen
Bedingungen 3.0 Unported Lizenz.
Seite 9