Datenbank Modellierung - Einführung

Transkript

1 Name Klasse Datum 1 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: Tabellenkalkulation: Datenbank: Hauptziel Einfache Nutzung und schnelle Anpassungen. Kurze Zugriffszeiten. Dateneingabe Direkt in das File über GUI Über SQL 1 Datenausgabe Über GUI oder via Skripte auf Textfiles Über SQL Datenstrukturierung Über GUI in einzelnen Tabs, Spalten und Zeilen. Datenfelder können individuell typisiert werden. Usermanagement Datenvolumen 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. Ü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. 1 Structured Query Language DB_ModellierungEinfuehrung_v01.docx Seite 1

2 Eigenschaft: Tabellenkalkulation: Datenbank: Flexibilität Sehr hoch es können jederzeit Änderungen Eher gering. Strukturelle Anpassungen eingebracht werden. erfolgen über SQL, wobei diese meist Nutzung Meist nur durch einen User gleichzeitig. Parallele Zugriffe sind möglich, führen jedoch oft zu Inkonsistenzen. Architektur Fat Client. Client Server. über Softwareprojekte laufen müssen. Die Steuerung von parallelen Zugriffen erfolgt durch das Datenbank Management System. 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

3 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 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

4 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 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 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: Tatsächliches Objekt der realen Welt oder unserer Vorstellung. Eindeutig bestimmbar und somit von anderen Objekten unterscheidbar. Seite 4

5 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

6 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 vor 2 : 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 Vergleich 3 : Was: Konzept: Logik: Physik: Entitätsname ja ja Beziehungen ja ja Attribute ja Primärschlüssel ja ja Fremdschlüssel ja ja Tabellennamen ja Spaltennamen ja Datentypen 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 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 Orientiert an den Vorschlägen von Peter Chen 3 Seite 6

7 Datenbank Modellierung - Einführung 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. UML 4 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

8 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). Eine 1:n Beziehung zwischen Kunden und Auftrag wird also wie folgt dargestellt: Symbol: Beziehung: 1 und genau 1. 1 oder 0. 1 oder n (also mehrere) 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

9 4 Lizenz Datenbank Modellierung - Einführung Diese(s) Werk bzw. Inhalt von Maik Aicher ( steht unter einer Creative Commons Namensnennung - Nicht-kommerziell - Weitergabe unter gleichen Bedingungen 3.0 Unported Lizenz. Seite 9