Verstehen von Datenbankbausteinen in SQL Server
Jedes Haus hat eine Küche, mindestens ein Badezimmer und ein Schlafzimmer, eine Haustür, ein Sanitärsystem und andere Dinge. Diese Dinge können auf verschiedene Arten und in unterschiedlicher Anzahl angeordnet werden, um verschiedene Häuser zu produzieren. So ist es mit Datenbanken. Es gibt bestimmte Dinge, die alle Datenbanken gemeinsam haben. In diesem Beitrag werde ich die Bausteine vorstellen, aus denen alle Datenbanken bestehen, und zeigen, wie sie zusammengesetzt sind. Ich werde auch drei Regeln diskutieren, die bei der Verwendung der Bausteine befolgt werden müssen.
Das in diesem Beitrag vorgestellte Material sollte für jeden von Wert sein, der irgendeine Art von Interaktion mit Datenbanken hat, aber es ist auf einer sehr elementaren Ebene. Eine umfassendere Diskussion des Datenbankdesigns finden Sie in meinem Artikel An Intuitive Approach to Database Design.
Mini-Welten.
Bevor wir zu den Bausteinen kommen, nehmen wir uns einen Moment Zeit, um den Begriff Mini-Welt zu verstehen, denn er wird uns helfen, die Bausteine zu verstehen.
Eine Datenbank ist ein Modell einer Mini-Welt. Eine Mini-Welt kann eine Arztpraxis, ein Einzelhandelsgeschäft, eine Bibliothek oder viele andere Dinge sein. Wenn wir Informationen über die Miniwelt wünschen, wenden wir uns an die Datenbank, die sie modelliert.
Angenommen, Sie gehen zum Arzt, um einen Termin zu vereinbaren. Wenn Sie der Rezeption mitteilen, dass Sie einen Termin haben, versucht die Rezeption, Ihren Termin im Modell (der Datenbank) zu finden. Wenn das Modell mit seiner Mini-Welt aktuell gehalten wurde, sollte es in der Lage sein zu bestätigen, dass Sie einen Termin haben. Wenn ein Unternehmen wissen möchte, welcher seiner Kunden mit hohem Volumen in den letzten 6 Monaten keine Bestellungen aufgegeben hat, kann es sich an das Modell seiner Mini-Welt wenden, wenn es mit dieser Mini-Welt auf dem neuesten Stand gehalten wurde.
Eine Mini-Welt kann ein ganzes Unternehmen oder ein Teil eines Unternehmens sein, z. B. eine Bankfiliale oder die Verkaufsabteilung.
Das erste, was ein Datenbankdesigner tut, ist, die Mini-Welt zu verstehen, denn die Aufgabe des Designers ist es, ein Modell dieser Mini-Welt zu entwerfen. Und um die Mini-Welt zu verstehen, beginnt der Designer mit der Identifizierung der Bausteine, die in die Zusammenstellung einer Datenbank einfließen.
Die Bausteine
1. Entitäten
Eine Entität ist etwas, das in der Mini-Welt existiert und das Eigenschaften hat, die für uns von Interesse sind. In einer Mini-Welt für die Einschulung von Schulen gibt es beispielsweise Schülerentitäten, Kursentitäten, Ausbilderentitäten und andere. Die Schüler haben Namen, Adressen, GPAs und andere Merkmale, die uns interessieren. Kurse haben Titel, Credits, Gebühren und andere. Und Ausbilder haben Namen, Adressen, Qualifikationen und andere. Entitäten sind einzigartig. Jeder Schüler ist eine einzigartige Einheit; es gibt John und Mary und so weiter. Jeder Kurs ist eine einzigartige Entität und jeder Instruktor ist eine einzigartige Entität.
Entitäten müssen keine physischen Dinge sein. Obwohl Sie eine Einschreibung nicht berühren, sehen oder riechen können, existiert sie dennoch in der Mini-Welt der Einschreibung und weist Merkmale auf, die für uns von Interesse sind, wie das Datum der Einschreibung, der Schüler, der sich eingeschrieben hat, der Kurs, in dem sich der Schüler eingeschrieben hat, und die erhaltene Abschlussnote. Verkäufe sind andere Beispiele für Unternehmen, die keine physische Komponente haben, aber Merkmale aufweisen, die für uns von Interesse sind (Verkaufsdatum, Kunde, Verkäufer, Bestellsumme, Versandart, Zahlungsbedingungen usw.).).
2. Entitätstypen
Entitäten desselben Typs gehören zu einem Entitätstyp. Ein Entitätstyp ist eine Menge von Entitäten dieses Typs. Der Student-Entitätstyp ist die Menge aller Studenten. Der Kursentitätstyp ist die Menge aller Kurse und der Kursleiterentitätstyp ist die Menge aller Kursleiter.
Entitätstypen sind das wichtigste Konzept in diesem Beitrag. Sie werden zu Tabellen in einer Datenbank.
3. Attribute
Die Attribute einer Entität sind die Eigenschaften dieser Entität, die für uns von Interesse sind. Wie bereits erwähnt, umfassen die Attribute der Schüler Name, Adresse, GPA und andere. Kurse haben Namen, Credits, Abteilungen, denen sie angehören, und andere. Und so weiter mit anderen Entitätstypen.
Zusammenbau der Bausteine
Wie werden diese Bausteine in der Datenbank dargestellt? Jeder Entitätstyp wird durch eine Tabelle in der Datenbank dargestellt. In dieser Tabelle sind die einzelnen Zeilen die eindeutigen Entitäten und die Spalten die Attribute. Hier ist ein Beispiel für eine Tabelle, die den Kreditkartenentitätstyp darstellt:
Bausteinregeln
Bei der Arbeit mit Bausteinen ist es wichtig, bestimmte Regeln zu befolgen, die nicht nur die Arbeit mit Datenbankobjekten erleichtern, sondern auch Datenanomalien verhindern (Datenanomalien gehen über den Rahmen dieses Beitrags hinaus, werden jedoch in meinem Artikel Ein intuitiver Ansatz für das Datenbankdesign ausführlich erläutert).
Regel 1: Jede Tabelle sollte einen und nur einen Entitätstyp darstellen.
Die Datenbank der Schuleinschreibung Mini-Welt, oben, benötigt die folgenden Tabellen: Student, Kurs, Dozent, Einschreibung und andere, eine für jeden Entitätstyp, der in dieser Mini-Welt identifiziert wurde. Die Datenbank der Mini-Welt der Arztpraxis benötigt einen Arzttisch, einen Patiententisch, einen Termintisch, einen Medikationstisch und andere. Eine Tabelle für jeden Entitätstyp.
Es gibt eine Ausnahme von dieser Regel. Mach dich bereit, hier kommt der Brain Twister: Wenn zwei Entitätstypen dieselben Attribute haben und eine Entität in einem der Entitätstypen auch eine Entität im anderen Entitätstyp ist (eine Entität ist Mitglied beider Entitätstypen), können die beiden Entitätstypen dargestellt werden in einer Tabelle. Hier ist es wieder: Ein Professor-Entitätstyp und ein Berater-Entitätstyp können beide in einer Tabelle dargestellt werden, da Berater auch Professoren sind und dieselben Attribute haben (Professor- / Beratername, Professor- / Beraterqualifikationen und andere). Und wieder: Ein Ordner-Entitätstyp und ein Unterordner-Entitätstyp können beide in einer Tabelle dargestellt werden, da alle Unterordner-Entitäten auch Ordnerentitäten sind und dieselben Attribute aufweisen (Ordnertitel, Ordnergröße, Anzahl der Elemente im Ordner, übergeordneter Ordner und andere). Nur noch eines: Die Entitätstypen Employee und Manager können beide in derselben Tabelle dargestellt werden, da employees und manager Entities dieselben Attribute haben und manager Entities auch employee Entities sind. Diese Ausnahme von der Regel wird in einem anderen Blog näher untersucht: SQL Server – Die Self Join-Abfrage.
Beachten Sie übrigens, dass diese Regel der Grund dafür ist, dass der richtige Weg, eine Tabelle zu benennen, im Singular liegt. Tabellen stellen einen einzelnen Entitätstyp dar.
Regel 2: Alle Spalten müssen atomar sein.
Haben Sie sich jemals gefragt, warum Datenbanktabellen Spalten für Stadt und Bundesland haben, aber nur eine Spalte für die Adresse? Vielleicht haben Sie sich gefragt, warum es keine Spalte für die Adressnummer gibt, eine andere für den Adress-Straßentyp (Blvd., Allee, etc.), eine andere für Wohnungsnummer, und so weiter. Warum werden diese Spalten normalerweise alle in einer einzigen Adressspalte zusammengefasst? Die Antwort auf all diese Fragen liegt im Verständnis der Atomarität.
Wenn wir sagen, dass eine Spalte atomar ist, meinen wir, dass sie nicht weiter unterteilt werden kann und dennoch Bedeutung behält. Lassen Sie uns eine Spalte erstellen und MegaAddress nennen, die eine Straßenadresse zusammen mit Stadt und Bundesland enthält.
Da wir jedoch Suchen, sortieren und andere Vorgänge für Teile dieser Spalte durchführen (nach Stadt suchen, nach Bundesland sortieren, nur den Teil der Straßenadresse ausdrucken usw.), können wir sagen, dass Unterteilungen dieser Spalte ihre eigene Bedeutung haben (streetAddress, City und State). MegaAddress ist also nicht atomar. Ein besserer Tisch wäre:
Was ist nun mit der Spalte streetAddress? Sollten wir das weiter in Straßennummer, Straßenname und Straßentyp unterteilen? Solange wir nichts Bedeutendes mit Unterteilungen davon tun — wenn wir nicht nach Straßennummern sortieren, nach allen Straßen oder Alleen suchen und so weiter — dann ist die Spalte atomar wie sie ist. Aber wenn wir diese Dinge tun, ist die Spalte nicht atomar und dann sollten wir sie wie beschrieben unterteilen.
Regel 3: Spalten können nicht mehrwertig sein.
Einige Entitätstypen enthalten mehrwertige Attribute oder ein Attribut, das mehr als einen Wert haben kann. In einer Kurstabelle kann es ein Attribut namens Voraussetzungen geben. Da eine Kursentität mehr als eine Voraussetzung haben kann, ist das erforderliche Attribut ein mehrwertiges Attribut. Wenn wir eine Tabelle für den Kursentitätstyp erstellen, können wir das erforderliche Attribut nicht als Spalte in der Tabelle darstellen. Um ein mehrwertiges Attribut richtig darzustellen, müssen wir eine weitere Tabelle dafür erstellen und sie mithilfe einer Eins-zu-Viele-Beziehung mit der Originaltabelle in Beziehung setzen (Beziehungen werden in den Kursen, die ich bei Interface Tachnical Training SQL100 unterrichte, ausführlich erläutert: Einführung in Transact-SQL und SQL250: Transact-SQL für Entwickler und in meinem Artikel Ein intuitiver Ansatz für das Datenbankdesign). Andere Beispiele für mehrwertige Attribute sind die Angehörigen eines Mitarbeiters, die Qualifikationen eines Arztes usw.
Regel 3 besagt, dass für eine bestimmte Entität (Zeile in einer Tabelle) in jeder Spalte nur ein Wert vorhanden sein kann.
Zusammenfassung
In diesem Beitrag wurde das Konzept der Mini-Welt als die Aspekte eines Unternehmens oder einer anderen Umgebung vorgestellt, die eine Datenbank modelliert. In dem Beitrag wurde auch beschrieben, dass eine Datenbanktabelle einen einzelnen Entitätstyp darstellt, in dem die Zeilen die einzelnen Entitäten desselben Typs enthalten und die Spalten die Attribute dieser Entitäten darstellen. Es wurden drei Regeln für Tabellen eingeführt. Regel 1 besagt, dass eine Tabelle einen einzelnen Entitätstyp darstellen sollte. Die Ausnahme von der Regel ist, wenn zwei Entitätstypen dieselben Attribute haben und Entitäten in einem Entitätstyp Mitglieder des anderen Entitätstyps sind. In diesem Fall können beide Entitätstypen in derselben Tabelle dargestellt werden. Regel 2 besagt, dass alle Spalten einer Tabelle atomar sein müssen, was bedeutet, dass eine Spalte nicht unterteilt werden kann und dennoch in der Mini-Welt eine Bedeutung behält. Schließlich besagt Regel 3, dass Spalten in einer Tabelle nicht mehrwertig sein können, was bedeutet, dass für eine bestimmte Entität (Zeile in einer Tabelle) nur ein Wert pro Spalte vorhanden sein kann.
Viel Spaß!
Peter Avila
SQL Server Instructor – Interface Technical Training
Phoenix, AZ
Attribute, Datenbanken, Entitätstypen, Mini-Welt, Unterordner, Werte
Leave a Reply