Deja
Sie wurden beauftragt,
für einen mittelständischen
Hersteller eine Datenbank zur Verfolgung der Wartung mehrerer Maschinen
zu entwickeln
. Geplante Wartungsarbeiten sind unkompliziert,
aber wenn etwas schief geht, wird normalerweise ein Team von Mitarbeitern hinzugezogen, um das
Problem zu lösen
.
Maschinenwartung
Maschinen-ID: A202 Kaufdatum: 23. August 2002
Standort: Etage C Manager: Daniel Hugh
Adresse: 22 Castle Street, Luton Abteilung: Fertigung
Geplantes
Datum Zweck Arbeiter Kommentar
2. Januar Ölkontrolle Peter Wood Fein
5. Februar Fehlausrichtung Darren Hill Fein
9. Februar Radreparatur Peter Wood unvollständig
ungeplant
Datum Problem Worker Spezialität Beschreibung von Fix
13 Jan Instrumentenfehler John Smith Verschoben
Sie müssen die Tabelle in verknüpfte
relationale Tabellen normalisieren
, damit eine
Datenbank in Microsoft Access gemäß den normalisierten Tabellen entworfen werden kann.
A) Normalisieren Sie die Tabelle in relationale Tabellen (zur 3. Normalform); Listen Sie die
Attribute in jeder Tabelle auf.
Clotilde
Erste Normalform (1NF) legt die sehr grundlegenden Regeln für eine organisierte Datenbank fest:
* Eliminieren Sie doppelte Spalten aus derselben Tabelle.
* Erstellen Sie separate Tabellen für jede Gruppe verwandter Daten und identifizieren Sie jede Zeile mit einer eindeutigen Spalte (dem Primärschlüssel).
Was bedeuten diese Regeln für den praktischen Entwurf einer Datenbank? Es ist eigentlich ganz einfach.
Die erste Regel besagt, dass wir keine Daten innerhalb derselben Zeile einer Tabelle duplizieren dürfen. In der Datenbank-Community wird dieses Konzept als die Atomizität einer Tabelle bezeichnet. Tabellen, die dieser Regel entsprechen, werden als atomar bezeichnet. Lassen Sie uns dieses Prinzip anhand eines klassischen Beispiels untersuchen – einer Tabelle in einer Personaldatenbank, die die Beziehung zwischen Vorgesetzten und Untergebenen speichert. Für unser Beispiel legen wir die Geschäftsregel fest, dass jeder Vorgesetzte einen oder mehrere Untergebene haben kann, während jeder Untergebene nur einen Vorgesetzten haben darf.
Intuitiv könnten wir beim Erstellen einer Liste oder Kalkulationstabelle zum Nachverfolgen dieser Informationen eine Tabelle mit den folgenden Feldern erstellen:
* Manager
* Untergeordneter1
* Untergeordneter2
* Untergeordneter3
* Untergeordnet4
Erinnern Sie sich jedoch an die erste von 1NF auferlegte Regel: Eliminieren Sie doppelte Spalten aus derselben Tabelle. Die Spalten Untergeordnet1-Untergeordnet4 sind eindeutig dupliziert. Nehmen Sie sich einen Moment Zeit und denken Sie über die Probleme nach, die dieses Szenario aufwirft. Wenn ein Manager nur einen Untergebenen hat, sind die Untergeordneten2-Untergeordneten4-Spalten einfach verschwendeter Speicherplatz (ein kostbares Datenbankgut). Stellen Sie sich außerdem den Fall vor, dass eine Führungskraft bereits 4 Untergebene hat – was passiert, wenn sie einen anderen Mitarbeiter einstellt? Die gesamte Tabellenstruktur müsste geändert werden.
An dieser Stelle kommt Datenbank-Neulingen normalerweise eine zweite gute Idee: Wir wollen nicht mehr als eine Spalte haben und wir wollen eine flexible Menge an Datenspeicherung ermöglichen. Versuchen wir es so:
* Manager
* Untergebene
Wenn das Feld Untergebene mehrere Einträge in der Form "Mary, Bill, Joe" enthält
Diese Lösung ist näher, aber sie greift auch zu kurz. Die untergeordnete Spalte ist immer noch duplikativ und nicht-atomar. Was passiert, wenn wir einen Untergebenen hinzufügen oder entfernen müssen? Wir müssen den gesamten Inhalt der Tabelle lesen und schreiben. Das ist in dieser Situation keine große Sache, aber was wäre, wenn ein Manager hundert Mitarbeiter hätte? Außerdem verkompliziert es das Auswählen von Daten aus der Datenbank in zukünftigen Abfragen.
Hier ist eine Tabelle, die die erste Regel von 1NF erfüllt:
* Manager
* Untergeordneter
In diesem Fall hat jeder Untergeordnete einen einzigen Eintrag, aber Manager können mehrere Einträge haben.
Was ist nun mit der zweiten Regel: Identifizieren Sie jede Zeile mit einer eindeutigen Spalte oder einem Satz von Spalten (dem Primärschlüssel)? Sehen Sie sich die obige Tabelle an und schlagen Sie vor, die untergeordnete Spalte als Primärschlüssel zu verwenden. Tatsächlich ist die untergeordnete Spalte ein guter Kandidat für einen Primärschlüssel, da unsere Geschäftsregeln vorschreiben, dass jeder untergeordnete nur einen Manager haben darf. Aufgrund der Daten, die wir in unserer Tabelle speichern möchten, ist dies jedoch keine ideale Lösung. Was passiert, wenn wir einen anderen Mitarbeiter namens Jim einstellen? Wie speichern wir seine Manager-Untergeordnete-Beziehung in der Datenbank?
Verwenden Sie am besten eine wirklich eindeutige Kennung (z. B. eine Mitarbeiter-ID) als Primärschlüssel. Unsere Abschlusstabelle würde so aussehen:
* Manager-ID
* Untergeordnete ID
2. Normalform
Im letzten Monat haben wir uns verschiedene Aspekte der Normalisierung einer Datenbanktabelle angesehen. Zuerst haben wir die Grundprinzipien der Datenbanknormalisierung besprochen. Beim letzten Mal haben wir uns mit den Grundvoraussetzungen der ersten Normalform (1NF) beschäftigt. Lassen Sie uns nun unsere Reise fortsetzen und die Prinzipien der zweiten Normalform (2NF) behandeln.
Erinnern Sie sich an die allgemeinen Anforderungen von 2NF:
* Entfernen Sie Teilmengen von Daten, die für mehrere Zeilen einer Tabelle gelten, und platzieren Sie sie in separaten Tabellen.
* Erstellen Sie Beziehungen zwischen diesen neuen Tabellen und ihren Vorgängern durch die Verwendung von Fremdschlüsseln.
Diese Regeln lassen sich in einer einfachen Anweisung zusammenfassen: 2NF versucht, die Menge an redundanten Daten in einer Tabelle zu reduzieren, indem sie diese extrahiert, in neue Tabelle(n) platziert und Beziehungen zwischen diesen Tabellen herstellt.
Schauen wir uns ein Beispiel an. Stellen Sie sich einen Online-Shop vor, der Kundeninformationen in einer Datenbank verwaltet. Sie können eine einzelne Tabelle namens Customers mit den folgenden Elementen haben:
* CustNum
* FirstName
* LastName
* Address
* City
* State
* PLZ
Ein kurzer Blick auf diese Tabelle zeigt eine kleine Menge redundanter Daten. Wir speichern die Einträge "Sea Cliff, NY 11579" und "Miami, FL 33157" jeweils zweimal. Das mag in unserem einfachen Beispiel nicht nach zu viel zusätzlichem Speicher erscheinen, aber stellen Sie sich den verschwendeten Speicherplatz vor, wenn wir Tausende von Zeilen in unserer Tabelle hätten. Wenn sich außerdem die Postleitzahl von Sea Cliff ändern sollte, müssten wir diese Änderung an vielen Stellen in der Datenbank vornehmen.
In einer 2NF-konformen Datenbankstruktur werden diese redundanten Informationen extrahiert und in einer separaten Tabelle gespeichert. Unsere neue Tabelle (nennen wir sie ZIPs) könnte die folgenden Felder haben:
* PLZ
* Stadt
* Bundesland
Wenn wir sehr effizient sein wollen, können wir diese Tabelle sogar im Voraus füllen - die Post stellt ein Verzeichnis aller gültigen Postleitzahlen und deren Städte-Bundesland-Beziehungen zur Verfügung. Sicherlich haben Sie eine Situation erlebt, in der diese Art von Datenbank verwendet wurde. Jemand, der eine Bestellung entgegennimmt, hat Sie möglicherweise zuerst nach Ihrer Postleitzahl gefragt und kann dann die Stadt und das Bundesland kennen, aus denen Sie anrufen. Diese Art der Anordnung reduziert Bedienfehler und erhöht die Effizienz.
Nachdem wir nun die duplizierten Daten aus der Customers-Tabelle entfernt haben, haben wir die erste Regel der zweiten Normalform erfüllt. Wir müssen immer noch einen Fremdschlüssel verwenden, um die beiden Tabellen miteinander zu verbinden. Wir verwenden die Postleitzahl (den Primärschlüssel aus der ZIPs-Tabelle), um diese Beziehung zu erstellen. Hier ist unsere neue
Kundentabelle :
* CustNum
* Vorname
* Nachname
* Adresse
* ZIP
Wir haben jetzt die Menge an redundanten Informationen in der Datenbank minimiert und unsere Struktur ist in zweiter Normalform!
3RD-Normalform
Es gibt zwei Grundvoraussetzungen für eine Datenbank in der dritten Normalform:
* Erfüllen Sie bereits die Anforderungen von 1NF und 2NF
* Entfernen Sie Spalten, die nicht vollständig vom Primärschlüssel abhängig sind.
Stellen Sie sich vor, wir haben eine Tabelle mit Widget-Bestellungen, die die folgenden Attribute enthält:
* Bestellnummer
* Kundennummer
* Stückpreis
* Menge
* Gesamt
Denken Sie daran, unsere erste Anforderung ist, dass die Tabelle die Anforderungen von 1NF und 2NF erfüllen muss. Gibt es doppelte Spalten? Nein. Haben wir einen Primärschlüssel? Ja, die Bestellnummer. Daher erfüllen wir die Anforderungen von 1NF. Gibt es Teilmengen von Daten, die für mehrere Zeilen gelten? Nein, damit erfüllen wir auch die Anforderungen von 2NF.
Sind nun alle Spalten vollständig vom Primärschlüssel abhängig? Die Kundennummer variiert mit der Bestellnummer und scheint von keinem der anderen Felder abhängig zu sein. Was ist mit dem Stückpreis? Dieses Feld kann in einer Situation, in der wir jedem Kunden einen festen Preis berechnet haben, von der Kundennummer abhängen. Wenn man sich jedoch die obigen Daten ansieht, scheint es, dass wir dem gleichen Kunden manchmal unterschiedliche Preise berechnen. Daher ist der Stückpreis vollständig von der Bestellnummer abhängig. Die Menge der Artikel variiert auch von Bestellung zu Bestellung, also sind wir in Ordnung.
Was ist mit der Summe? Es sieht so aus, als könnten wir hier in Schwierigkeiten geraten. Die Gesamtsumme kann durch Multiplikation des Stückpreises mit der Menge abgeleitet werden und ist daher nicht vollständig vom Primärschlüssel abhängig. Wir müssen es vom Tisch entfernen, um der dritten Normalform zu entsprechen. Vielleicht verwenden wir die folgenden Attribute:
* Bestellnummer
* Kundennummer
* Stückpreis
* Menge
Jetzt ist unsere Tabelle in 3NF. Aber wie sieht es mit der Gesamtsumme aus? Dies ist ein abgeleitetes Feld und es ist am besten, es überhaupt nicht in der Datenbank zu speichern. Wir können es einfach "on the fly" berechnen, wenn wir Datenbankabfragen durchführen. Zum Beispiel könnten wir zuvor diese Abfrage verwendet haben, um Bestellnummern und Gesamtsummen abzurufen:
SELECT OrderNumber, Total
FROM WidgetOrders
Wir können jetzt die folgende Abfrage verwenden:
SELECT OrderNumber, UnitPrice * Quantity AS Total
FROM WidgetOrders
, um die gleichen Ergebnisse zu erzielen, ohne die Normalisierungsregeln zu verletzen.
Bevor wir mit der Erörterung der Normalformen beginnen, ist es wichtig darauf hinzuweisen, dass es sich nur um Richtlinien und Richtlinien handelt. Gelegentlich wird es notwendig, von ihnen abzuweichen, um praktische Geschäftsanforderungen zu erfüllen. Bei Variationen ist es jedoch äußerst wichtig, mögliche Auswirkungen auf Ihr System zu bewerten und mögliche Inkonsistenzen zu berücksichtigen.