2.5.2 Primärschlüssel

Transkript

1

2 Relationale Datenbanken Primärschlüssel Jeder Datensatz einer Tabelle muss eindeutig identifizierbar sein. So muss beispielsweise jede Person in der Tabelle tbperson zweifelsfrei erkennbar sein. Da Namen und auch Vornamen mehrfach auftreten können, sind diese nicht eindeutig. Es wird ein zusätzliches Feld eingeführt, dessen Wert für jeden Datensatz in der Tabelle eindeutig ist: die Personen-Identifikationsnummer (PID). In Abbildung 2.7 auf Seite 33 ist der Feldwert»1«des Felds PID in der Tabelle tbperson eindeutig. Mittels dieses Werts kann der Datensatz des Dozenten Weiss eindeutig gefunden werden. In vielen Fällen des alltäglichen Lebens ist man bereits daran gewöhnt, dass alles eine Nummer bekommt: Personalausweise, Artikel, Rechnungen, Fahrgestelle, Flüge, Versicherungspolicen sind nur einige Beispiele. Diese Nummern werden vergeben, weil die Unternehmen ihre Informationen in Datenbanken abspeichern. In diesen Datenbanken müssen die einzelnen Datensätze eindeutig identifizierbar und unterscheidbar sein. Dies geschieht mit sogenannten Schlüsseln oder genauer Primärschlüsseln (manchmal auch Identifizierungsschlüssel genannt). Ein Primärschlüssel (Primary Key) ist ein Feld, über dessen Wert jeder Datensatz eindeutig in einer Tabelle identifizierbar ist. Für jeden Primärschlüssel in einer Datenbank gilt: Er muss eindeutig jeden Datensatz in der Datenbank identifizieren. Er wird sofort bei der Anlage eines Datensatzes vergeben. Er darf sich während der Existenz des Datensatzes niemals ändern (oder es müssen bestimmte besondere Regeln beachtet werden). Primärschlüssel können für den Anwender erkennbare und interpretierbare Informationen enthalten, beispielsweise Anfangsbuchstaben von Kunden, Unterscheidungen von privaten und geschäftlichen Kunden, Geschäftsstellen und andere Angaben, die Mitarbeitern weiterhelfen. Man spricht in diesen Fällen von sprechenden Schlüsseln. Dies ist aber für die Datenbank nicht zwingend notwendig, da die Nummern im Wesentlichen der automatischen Suche in der Datenbank dienen. Oft existieren auch sprechende Schlüssel neben den in der Datenbank verwendeten Primärschlüsseln, die für die Anwender dann nie sichtbar werden. Primärschlüssel Sprechende Schlüssel Manchmal ergibt sich der für eine Tabelle sinnvolle Primärschlüssel auf natürliche Weise, beispielsweise die Fahrgestellnummer für die Identifizierung eines Autos, die EAN (Europäische Artikelnummer) als Primärschlüssel der Artikel aus dem Sortiment eines Handelsunternehmens oder die Bestimmung der Lage eines Orts mittels seines Längen- und Breitengrads. Oft sind aber diese natürlichen Schlüssel gar nicht vorhanden oder sie sind vorhanden, aber zu umständlich (Beispiel: Fahrgestellnummer), nicht eindeutig für das gesamte Sortiment eines Warenhauses (Beispiel: EAN nicht für alle Artikel vorhanden) oder sie sind einfach unhandlich. Wer weiß schon, welche Künstliche Schlüssel 35

3 Kapitel 2 SQL der Standard relationaler Datenbanken Längen- und Breitengradangaben der Palmstraße 6 in Hannover entsprechen? Und wenn Sie es wüssten, würden Sie es auf die fünfte oder sechste Dezimale genau eingeben wollen oder können? In diesen Fällen werden bei der Gestaltung der Datenbank künstliche Primärschlüssel eingeführt, also Felder, deren Werte nur der Identifizierung der Datensätze in einer Tabelle dienen. Sie besitzen in der realen Welt keine weitergehende Bedeutung. In der Kursdatenbank sind schon zwei solcher Fälle aufgetreten. In Abbildung 2.7 auf Seite 33 sehen Sie die PID (Personen-Identifikationsnummer), die in der Tabelle tbperson dem eindeutigen Auffinden jedes Personendatensatzes dient. Die Werte haben keine interpretierbare Bedeutung. Entsprechendes gilt auch für die DID (Dozenten-Identifikationsnummer) in der Tabelle tbdozent (siehe Abbildung 2.6 auf Seite 32). Warum nimmt man nicht einfach den Namen einer Person als Primärschlüssel? Wir könnten Herrn Weiss doch auch eindeutig finden? Gut, oben wurde schon behauptet, dass der nicht eindeutig ist, und man sieht es bereits in Abbildung 2.7. Aber wenn das nicht reicht, weil der Name»Weiss«nicht eindeutig ist, könnte man doch den Vornamen dazu nehmen. Aber was ist, wenn das auch nicht ausreichend ist? Gut, auch dieses Problem sieht man in Abbildung 2.7. Wenn man die Datensätze mit den PID»1«und»6«betrachtet, würde die Kombination der Datenfelder Name und Vorname gerade noch reichen, um jeden Datensatz eindeutig zu identifizieren. Spätestens beim Datensatz mit der PID»7«reicht das aber auch nicht mehr aus. Jetzt müsste man ein weiteres Feld beispielsweise die Strasse dazunehmen. Aber reicht das wirklich in allen Fällen aus? Wer weiß, wer da nächsten Monat noch einzieht? Dieses Verfahren ist sehr unsicher. Aber nicht nur das, es ist auch umständlich und verkompliziert später die Realisierung der Beziehungen zwischen den Tabellen. Es ist daher naheliegend, einen künstlichen Primärschlüssel, in diesem Fall die PID, zu vergeben, der beim Aufbau der Datenbank mit Sicherheit eindeutig ist. Beziehung Beziehungen Das grundlegende Strukturierungsmerkmal einer relationalen Datenbank sind also Tabellen, beispielsweise für Personen, Dozenten, Kunden, Artikel und Bestellungen. Nun wäre es sehr unbefriedigend, wenn man zwar feststellen könnte, welche Kunden man hat, aber nicht, welcher Kunde welche Bestellung getätigt hat oder welcher Lieferant welche Artikel liefert oder welcher Dozent in welcher Straße wohnt. Daher dürfen die Tabellen nicht isoliert betrachtet werden, sondern müssen miteinander in Beziehung gebracht werden können. Erst diese Beziehungen ermöglichen übergreifende Auswertungen mit den entsprechenden Informationen. Eine Beziehung (Relation) ist eine (mögliche) Kombination von Datensätzen aus zwei Tabellen. Ein Sonderfall sind rekursive Beziehungen, die eine Tabelle mit sich selbst in Beziehung setzen. 36

4 Relationale Datenbanken Bei einer Beziehung werden aus den beiden Tabellen diejenigen Datensätze als zusammenpassend angesehen, die in bestimmten Feldern denselben Wert haben. In einer der beiden Tabellen wird dazu zumeist der Primärschlüssel ausgewählt. In der zweiten Tabelle wird ein Feld bestimmt, dessen Werte mit den Werten des Primärschlüssels der anderen Tabelle übereinstimmen müssen. Dieses Feld wird als Fremdschlüssel bezeichnet. Ein Fremdschlüssel ist ein Feld, dessen Werte mit den Werten des Primärschlüssels einer anderen Tabelle übereinstimmen. Dadurch werden diejenigen Datensätze beider Tabellen in Beziehung zueinander gesetzt, deren Werte im Primärschlüsselfeld und im Fremdschlüsselfeld übereinstimmen. Aus jeweils einem Datensatz beider Tabellen entsteht so virtuell ein gemeinsamer Datensatz mit allen Feldwerten aus beiden Tabellen. Die Abbildung 2.8 zeigt den Zusammenhang am Beispiel der beiden Tabellen tbperson und tbdozent. Fremdschlüssel Abbildung 2.8 Beziehung zwischen den Tabellen tbdozent und tbperson über den Fremdschlüssel PID Sie erkennen, dass der Dozent mit der DID»812«die PID»1«hat. Da dies in der anderen Tabelle dem Datensatz mit dem Primärschlüssel PID mit dem Wert»1«entspricht, ist klar, dass in Hannover in der Palmstraße 6 ein Peter Weiss wohnt, der als der entsprechende Dozent seit dem für einen Stundensatz von 17,00 E unterrichtet, selbstständig und Informatiker ist. Mehrere Primärschlüsselfelder In der Praxis ergibt sich immer wieder die Problematik, dass Tabellen mehr als ein Primärschlüsselfeld aufweisen. In diesem Fall muss natürlich auch eine bestimmte Anzahl von Fremdschlüsselfeldern vorhanden sein, die paarweise den Primärschlüsselfeldern entsprechen. Im Prinzip müssen zum Aufbau einer Fremdschlüsselbeziehung immer alle Primärschlüsselfelder der entsprechenden Tabelle, zu der die Beziehung aufgebaut werden soll, kopiert und eine entsprechende Anzahl passende Fremdschlüsselfelder angelegt werden. Exkurs Jetzt könnte hier noch ein SQL-Beispiel für die Abfrage über eine Beziehung hinweg stehen. Aber das würde dann doch zu viele Erklärungen erfordern. Wenn Sie wollen, können Sie aber schon einmal in Kapitel 4 unter dem Stichwort JOIN»spicken«, bevor es im folgenden Kapitel mit den realen Datenbanken weitergeht. 37

5

6 Die Beispieldatenbanken Bevor wir uns jetzt den ersten realen SQL-Befehlen im Detail zuwenden, sollen noch die beiden Grundlagen betrachtet werden, die Sie für die Beispiele dieses Buchs benötigen. Zum einen sind dies die Beispieldatenbanken, auf die sich die meisten SQL-Beispiele dieses Buchs beziehen. Zum anderen soll auch die Installation der Datenbankmanagementsysteme MySQL, PostgreSQL, Microsoft SQL Server, Microsoft Access, OpenOffice.org Base, Oracle und Firebird beschrieben werden, die Sie für die Bearbeitung der Beispiele nutzen können. In diesem Buch finden Sie Beispiele für alle sieben Systeme. Insbesondere sind für sämtliche Übungsaufgaben Lösungen für alle Systeme erstellt, soweit dies sinnvoll möglich ist. Die Lösungen finden Sie auf der Internetseite zum Buch. Bei Microsoft Access werden Abbildungen aus Access 2003 und Access 2010 verwendet. Grundsätzlich funktionieren alle Beispiele in beiden Systemen sowie auch in Access 2007, sofern nicht anders angegeben. Dieses Kapitel hat zwei Funktionen. Es soll Ihnen zum einen helfen, eine Beispielumgebung für die Arbeit mit den Beispielen dieses Buchs bereitzustellen. Es soll Ihnen zum anderen aber auch ein wenig Hintergrundwissen zu den Beispielen und der Handhabung der Umgebungen liefern. Für diejenigen, die sich nur für die Beispiele interessieren und die Datenbankinstallation bereits kennen bzw. durchgeführt haben, genügt es, die Abschnitte 3.1 und 3.2 zu lesen. Für die anderen Leser werden im weiteren Verlauf des Kapitels Hinweise zu den Sie interessierenden Datenbanken gegeben. Ausführlichere Hinweise, insbesondere zur Installation finden Sie auch auf der zugehörigen Internetseite 39