Grundlagen der Datenbankentwurfsregeln

Einführung

Wie so oft muss ein Datenbankarchitekt eine Datenbank für eine bestimmte Lösung entwickeln.

An einem Freitagabend, im Zug von der Arbeit nach Hause, dachte ich darüber nach, wie ich einen Service für die Einstellung von Mitarbeitern für verschiedene Unternehmen schaffen würde. Schließlich können Sie mit keinem der vorhandenen Dienste schnell verstehen, wie geeignet ein Kandidat für Sie ist. Es ist nicht möglich, komplexe Filter zu erstellen, die bestimmte Fähigkeiten, Projekte oder Positionen einschließen oder ausschließen. Das Maximum, das Dienste normalerweise anbieten, sind Filter nach Unternehmen und teilweise nach Fähigkeiten.



In diesem Artikel werde ich mir erlauben, die strenge Darstellung des Materials ein wenig zu verwässern, indem ich technische Informationen mit nichttechnischen Beispielen aus dem Leben mische.



Lassen Sie uns zunächst die Erstellung einer Datenbank in MS SQL Server für den Jobsuchdienst analysieren.



Dieses Material kann auf ein anderes DBMS wie MySQL oder PostgreSQL übertragen werden.

Grundlagen der Entwurfsregeln

Um ein Datenbankschema zu entwerfen, müssen Sie sich an 7 formale Regeln und das Konzept der Normalisierung und Denormalisierung erinnern. Sie sind die Grundlage aller Gestaltungsregeln.



Lassen Sie uns 7 formale Regeln genauer beschreiben:

1. Eins-zu-eins-Beziehung:
   
   
   
   1.1) mit einer obligatorischen Verbindung:
   
   
   
   Ein Beispiel kann ein Bürger und sein Reisepass sein: Jeder Bürger muss einen Reisepass haben; ein Reisepass für jeden Bürger
   
   
   
   Diese Beziehung kann auf zwei Arten implementiert werden:
   
   
   
   1.1.1) in einer Einheit (Tabelle): Abb.1. Bürgerentität Hier ist die Citizen- Tabelle eine Bürgerentität, und das PassportData-Attribut (Feld) enthält alle Passdaten eines Bürgers und darf nicht leer sein (NICHT NULL). 2) in zwei verschiedenen Einheiten (Tabellen): Abb. 2. Beziehung zwischen Citizen- und PassportData-Entitäten
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   Hier ist die Citizen-Tabelle die Citizen-Entität, und die PassportData-Tabelle ist die Pass-Daten-Entität des Bürgers (der Pass selbst). Die Bürgerentität enthält ein PassportID-Attribut (Feld), das auf den Primärschlüssel der PassportData-Tabelle verweist. Die Passdatenentität enthält wiederum das Attribut (Feld) CitizenID, das sich auf den Primärschlüssel CitizenID der Citizen-Tabelle bezieht. Das PassportID-Feld der Bürgertabelle darf nicht leer sein (NICHT NULL). Es ist auch wichtig, die Integrität des CitizenID-Felds der PassportData-Tabelle aufrechtzuerhalten, um eine Eins-zu-Eins-Beziehung sicherzustellen. Mit anderen Worten, das PassportID-Feld der Citizen-Tabelle und das CitizenID-Feld der PassportData-Tabelle müssen auf dieselben Datensätze verweisen, als wäre es eine Entität (Tabelle), die in Abschnitt 1.1.1 dargestellt ist.
   
   
   
   1.2) mit einem optionalen Link:
   
   
   
   Ein Beispiel wäre eine Person mit oder ohne Reisepass für ein bestimmtes Land. Im ersten Fall wird er Staatsbürger des betreffenden Landes sein, im zweiten Fall nicht.
   
   
   
   Diese Beziehung kann auf zwei Arten implementiert werden:
   
   
   
   1.2.1) in einer Entität (Tabelle): Abb.3. Personenentität Die Personentabelle ist die Entität einer Person, und das PassportData-Attribut (Feld) enthält alle seine Passdaten und kann leer sein (NULL). 2) in zwei Einheiten (Tabellen): Abb. 4. Beziehung zwischen Personen- und PassportData-Entitäten
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   Die Personentabelle ist die Entität der Person, und die PassportData-Tabelle ist die Passdatenentität der Person (der Pass selbst). Die menschliche Entität enthält ein PassportID-Attribut (Feld), das auf den Primärschlüssel der PassportData-Tabelle verweist. Die Identität der Passdaten enthält wiederum das Attribut (Feld) PersonID, das sich auf den Primärschlüssel PersonID der Personentabelle bezieht. Das PassportID-Feld der Personentabelle kann NULL sein. Es ist auch wichtig, die Integrität des PersonID-Felds der PassportData-Tabelle aufrechtzuerhalten. Dies ist erforderlich, um eine Eins-zu-Eins-Kommunikation sicherzustellen. Das PassportID-Feld der Personentabelle und das PersonID-Feld der PassportData-Tabelle müssen auf dieselben Datensätze verweisen, als wäre es dieselbe Entität (Tabelle) wie in Abschnitt 1.2.1 gezeigt. Oder diese Felder müssen null sein, dh NULL enthalten.
   
   
2. :
   
   
   
   2.1) :
   
   
   
   . .
   
   
   
   :
   
   
   
   2.1.1) ():
   
   
   
   
   
   .5. Parent
   
   
   
   Parent , () ChildList . (NOT NULL). ChildList (NoSQL) XML, JSON .
   
   
   
   2.1.2) ():
   
   
   
   
   
   .6. Parent Child
   
   
   
   Parent , Child — . Child ParentID, ParentID Parent. ParentID Child (NOT NULL).
   
   
   
   2.2) :
   
   
   
   , .
   
   
   
   :
   
   
   
   2.2.1) ():
   
   
   
   
   
   .7. Person
   
   
   
   Parent , () ChildList . (NULL). ChildList (NoSQL) XML, JSON .
   
   
   
   2.2.2) ():
   
   
   
   
   
   .8. Person Child
   
   
   
   Parent , Child — . Child ParentID, ParentID Parent. ParentID Child (NULL).
   
   
   
   2.2.3) , () () :
   
   
   
   
   
   .9. Person
   
   
   
   () Person () ParentID, PersonID Person (NULL).
   
   
   
   « » .
   
   
3. :
   
   
   
   . , «» «», , . , , .
   
   
4. :
   
   
   
   : , . , .
   
   
   
   , NoSQL, , . , 3 ():
   
   
   
   
   
   .10. Person RealEstate
   
   
   
   Person RealEstate . () () PersonRealEstate. () PersonID RealEstateID PersonID Person RealEstateID RealEstate . , PersonRealEstate (PersonID; RealEstateID) PersonRealEstate.
   
   
   
   . , . , 1.1.2 1.2.2.
   
   

Eins-zu-Viele- und Viele-zu-Eins- Beziehungen können über mehr als zwei Entitäten implementiert werden. Dazu werden die notwendigen Attribute hinzugefügt, die sich auf die Primärschlüssel der notwendigen entsprechenden Entitäten beziehen. Diese Implementierung ähnelt den oben in den Absätzen 1.1.2 und 1.2.2 beschriebenen Beispielen.



Wo sind die sieben formalen Regeln?



Hier sind sie:

1. Ziffer 1 (Ziffer 1.1 und Ziffer 1.2) - die erste und zweite formale Regel
2. Abschnitt 2 (Abschnitt 2.1 und Abschnitt 2.2) - die dritte und vierte formale Regel
3. Klausel 3 (ähnlich wie Klausel 2) - die fünfte und sechste formale Regel
4. Punkt 4 - siebte formale Regel

Im obigen Text werden diese sieben formalen Regeln zu vier Funktionsblöcken zusammengefasst.



Wenn Sie über Normalisierung sprechen , müssen Sie deren Wesen verstehen. Die Normalisierung führt zu einer Verringerung der Wiederholbarkeit der Informationsspeicherung und damit zu einer Verringerung der Möglichkeit von Anomalien in den Daten. Die Normalisierung beim Aufteilen von Entitäten führt jedoch zu komplexeren Abfragekonstruktionen für die Datenmanipulation (Einfügen, Ändern, Auswählen und Löschen).



Der umgekehrte Normalisierungsprozess wird Denormalisierung genannt . Dies ist eine Vereinfachung des Erstellens von Datenzugriffsabfragen aufgrund der Aggregation und Verschachtelung von Entitäten (z. B. wie oben in den Abschnitten 2.1.1 und 2.2.1 unter Verwendung unvollständig strukturierter Daten (NoSQL) gezeigt).



Das ist der springende Punkt bei den Regeln für das Datenbankdesign.



Sind Sie sicher, dass Sie die Beziehung in sieben formalen Regeln verstehen? Hast du verstanden und nicht erkannt? Wissen und Verstehen sind schließlich zwei völlig unterschiedliche Konzepte.



Ich werde es genauer erklären. Fragen Sie sich, können Sie in wenigen Stunden ein Datenbankmodell für einen beliebigen Themenbereich und ein beliebiges Informationssystem skizzieren, wenn auch um Entitäten erweitert? (Feinheiten und Details können durch Fragen an Analysten und Kundenvertreter vervollständigt werden.) Wenn die Frage Sie überrascht und Sie denken, dass dies unmöglich ist, kennen Sie die sieben formalen Regeln, verstehen sie aber nicht.



Aus irgendeinem Grund ignorieren viele Quellen die Tatsache, dass diese Beziehungen nicht erfunden, sondern enthüllt wurden. Sie existieren in der realen Welt zunächst sowohl zwischen Subjekten als auch zwischen Subjekten und Objekten.



Auch diese Beziehung kann sich änderneins zu eins zu eins zu viele , viele zu eins oder viele zu viele . Die Kommunikationspflicht kann sich ändern oder unverändert bleiben.



Lassen Sie mich über einen Fall berichten, in dem ich aus Kenntnis der sieben formalen Regeln genau zum Verständnis dieser Beziehungen gekommen bin.



Zu einer Zeit war es mir peinlich, dass ich an der Universität diese sieben formalen Regeln kannte, aber in der industriellen Praxis (die Universität schickt Studenten zu verschiedenen Unternehmen, um Berufserfahrung zu sammeln) baute ich sehr lange Modelle von Grundlagen für verschiedene Fachbereiche. Ich dachte darüber nach und stellte fest, dass ich diese Beziehung nicht verstand.



Das Beobachten von Menschen half mir und die Essenz der Beziehung wurde in einem Traum offenbart. Ich werde diesen Traum in vereinfachter Form nacherzählen: Nur was Ihnen erlaubt, diese sieben formalen Regeln besser zu verstehen - ohne alles andere zu beschreiben.



Der Traum handelte von einer Familie mit Vater, Mutter und Kindern. Der Vater stirbt bei einem Autounfall, die Mutter beginnt zu trinken, und die Kinder werden schließlich ins Waisenhaus gebracht. Diese Kinder bleiben lange Zeit ohne Eltern. Dann haben einige Kinder Erziehungsberechtigte, es gibt auch einige von ihnen.



Haben Sie nachverfolgt, welche Art von Beziehungen zwischen den Subjekten bestehen und wie sich diese Beziehungen verändert haben?

Lass uns genauer hinschauen.

• Als die Familie mit mehreren Kindern vollständig war, war die Beziehung zwischen Eltern und Kindern viele zu viele .
• , . , , , , .
• .
• — .
• , : , ().

Die Beziehung zwischen Ehemann und Ehefrau ist eins zu eins mit einer obligatorischen Bindung in der formellen Ehe oder eins zu eins mit einer optionalen Bindung vor der Registrierung. Es kann nur eine Frau geben, genauso wie es nur einen Ehemann geben kann. Zumindest in Russland. Aber in einem anderen Land ist Polygamie möglich, und dann wird die Beziehung zwischen Ehemann und Ehefrau eins zu viele sein , und zwischen Ehefrauen und Ehemann - viele zu eins .



Hoffentlich sind Sie dem Verständnis dieser sieben formalen Regeln jetzt viel näher.



Es lohnt sich, ständig zu üben: Menschen zu beobachten und bestehende Beziehungen sowohl zwischen Subjekten als auch zwischen Subjekten und Objekten zu identifizieren. Das Obige beschrieb den Bürger und seinen Pass als eine Eins-zu-Eins- Beziehung mit einer obligatorischen Verbindung... Gleichzeitig ist ein Beispiel für eine Person und ihren Reisepass eine Eins-zu-Eins- Beziehung mit einem optionalen Link .



Nachdem Sie die sieben formalen Regeln verstanden haben, können Sie problemlos ein Datenbankmodell beliebiger Komplexität für jedes Informationssystem entwerfen.



Sie werden auch sehen, dass es viele Möglichkeiten gibt, eine Beziehung zu implementieren, und dass sich die Beziehung selbst ändern kann. Ein Datenbankmodell (Schema) ist eine Momentaufnahme der Beziehungen zwischen Entitäten zu einem bestimmten Zeitpunkt. Aus diesem Grund ist es wichtig, sowohl die Entitäten selbst zu bestimmen - Bilder von Objekten aus der realen Welt oder dem Themenbereich als auch ihre Beziehung zueinander, um Änderungen in der Zukunft zu berücksichtigen.



Ein gut gestaltetes Datenbankmodell, das sich ändernde Beziehungen in der Realität oder in der Domäne berücksichtigt, muss jahrelang oder sogar jahrzehntelang nicht geändert werden. Dies ist besonders wichtig für Data Warehouses, bei denen Änderungen das erneute Speichern großer Datenmengen (von mehreren Gigabyte auf viele Terabyte) erfordern.



Es ist wichtig, sich daran zu erinnern, dass Tabellen in einem relationalen Modell Entitätsbeziehungen sind und Zeilen (Tupel) Instanzen dieser Beziehungen sind. Zur Vereinfachung werden Tabellen jedoch häufig als Entitäten verstanden, und Tabellenzeilen sind Entitätsinstanzen. Ihre Beziehung wird durch Beziehungen in Form von Fremdschlüsseln ausgedrückt.

Entwerfen eines Datenbankschemas zum Finden von Bewerbern

Nachdem wir in Teil 1 die Grundlagen der Regeln für das Datenbankdesign behandelt haben, erstellen wir ein Datenbankschema für die Suche nach Arbeitssuchenden.



Lassen Sie uns zunächst definieren, was für Mitarbeiter des Unternehmens wichtig ist, die Kandidaten suchen:

1. für HR:
   
   
   
   1.1) das Unternehmen, in dem der Antragsteller gearbeitet hat
   
   1.2) die Positionen, die der Antragsteller zuvor in diesen Unternehmen innehatte
   
   1.3) Fähigkeiten und Fertigkeiten, die der Antragsteller in seiner Arbeit eingesetzt hat;
   
   sowie die Dauer der Tätigkeit des Bewerbers in jedem Unternehmen in jeder Position und die Dauer des Einsatzes jeder Fähigkeit und Fertigkeit
   
   
2. für einen technischen Spezialisten:
   
   
   
   2.1) Positionen des Antragstellers in diesen Unternehmen;
   
   2.2) Fähigkeiten und Fertigkeiten, die der Antragsteller in seiner Arbeit eingesetzt hat;
   
   2.3) Projekte, an denen der Antragsteller teilgenommen hat;
   
   sowie die Dauer der Arbeit des Bewerbers in jeder Position und in jedem Projekt, die Dauer des Einsatzes jeder Fähigkeit und Fähigkeit
   
   

Lassen Sie uns zunächst die erforderlichen Entitäten identifizieren:

1. Mitarbeiter
2. Unternehmen
3. Position (Position)
4. Projekt
5. Fertigkeit

• Unternehmen und Mitarbeiter sind wie viele zu viele , da ein Mitarbeiter in mehreren Unternehmen arbeiten kann und viele Menschen für das Unternehmen arbeiten.
• Positionen und Mitarbeiter sind in ähnlicher Weise miteinander verbunden: Mehrere Mitarbeiter können eine Position innerhalb eines oder mehrerer Unternehmen einnehmen.
• , , . , — .
• : .
• , .
• .

Da es sehr wichtig ist, aufzuzeichnen, wie lange ein Mitarbeiter in einer bestimmten Position in einem bestimmten Unternehmen sowie bei jedem Projekt gearbeitet hat, kann das Diagramm unserer Datenbank wie folgt aussehen: Abb. 11. Datenbankschema zum Finden von Bewerbern Hier fungiert die JobHistory-Tabelle als Entität des Jobverlaufs jedes Jobsuchenden. Das heißt, es ist ein Lebenslauf, der eine Viele-zu-Viele- Beziehung zwischen dem Mitarbeiter, dem Unternehmen, der Position und dem Projekt des Unternehmens einführt . Projekte und Fähigkeiten beziehen sich ebenso viele auf viele und kommunizieren daher über die ProjectSkill-Entität (Tabelle) miteinander.

















Wenn Sie die Beziehung zwischen Subjekten und zwischen Subjekten und Objekten verstehen - die bereits erwähnten sieben formalen Regeln -, kann dieses oder ein ähnliches Schema „auf dem Knie“ implementiert werden: auf einem Blatt Papier in weniger als einer Stunde. Und dies berücksichtigt auch die Müdigkeit nach einem fruchtbaren Arbeitstag.



Hier war es möglich, das Datenadditionsschema zu vereinfachen, wenn die "Fähigkeiten" durch unvollständig strukturierte Daten (NoSQL) in Form von XML, JSON in die Entität "Projekte" eingebettet wurden, oder einfach die Namen der Fähigkeiten durch Semikolons getrennt aufzulisten. Dies würde es jedoch schwieriger machen, nach Fertigkeiten zu probieren und nach Fertigkeiten zu filtern.



Ein ähnliches Modell ist das Herzstück der Geecko- Projektdatenbank .



Wie Sie sehen, ist der Entwurf von Informationssystemen im Hinblick auf den Datenbankentwurf nicht kompliziert. Dies ist nur eine Reflexion von Objekten und Subjekten aus der Realität, die auf die "Entitäten" des Datenbankschemas übertragen werden. Die Beziehung zwischen diesen Entitäten wird zu einem bestimmten Zeitpunkt festgelegt, wobei zukünftige Änderungen berücksichtigt werden.



Was genau wir aus der Realität nehmen und in das Wesentliche des Schemas einbauen und welche Beziehungen wir im Modell aufbauen, hängt davon ab, was wir hier und in Zukunft vom Informationssystem im Allgemeinen erwarten. Mit anderen Worten, welche Daten wir zum aktuellen Zeitpunkt und nach einer bestimmten Zeit in der Zukunft erhalten möchten.

Ein bisschen Text

Nachdem Sie das Modell in Betrieb genommen haben, halten Sie einen Moment inne und denken Sie: Es wurde gerade eine neue kleine Welt geschaffen. Es hat seine eigenen Entitäten aus der realen Welt und seine eigenen Beziehungen. Ja, dies ist eine digitale Welt, aber sie wird jetzt ihren eigenen Weg entwickeln. Es wird mit anderen Systemen (Welten) kommunizieren (sich integrieren), die ebenfalls nach ihren eigenen Regeln erstellt wurden. Daten fließen in diesen Systemen wie Blut in einem lebenden Organismus.



Und bevor Sie ins Bett gehen, denken Sie daran, dass die sieben formalen Regeln immer waren und uns überall umgeben. Nicht mehr und nicht weniger, immer sieben. Alle Beziehungen im wirklichen Leben können in diese sieben formalen Regeln zerlegt werden. Und wenn Sie denken oder träumen, wie verhalten sich die Entitäten zueinander - nicht nach denselben sieben formalen Regeln?



Im Allgemeinen bin ich sicher, dass diese Beziehung (sieben formale Regeln) von einem sehr guten Psychotherapeuten, möglicherweise einer Frau, offenbart wurde. Es ist sehr lange her, lange bevor das Konzept der Informationstechnologie auftauchte. Und das Interessanteste ist, dass diese Beziehungen außerhalb der Datenbank und der IT leben - letztere verwenden sie nur zur Modellierung von Informationssystemen.



Aber wir sind ein wenig vom Thema abgewichen. Ich fordere nur im Moment der Schaffung eines neuen Systems auf, diesen Prozess mit einer Seele anzugehen. Und dann glauben Sie mir, der Moment der Schöpfung wird eintreten. Das auf diese Weise entworfene System wird das lebendigste aller Lebewesen in der digitalen Welt sein.

Nachwort

Die Diagramme für die Beispiele wurden mit dem Datenbankdiagramm-Tool für SQL Server implementiert . DBeaver verfügt jedoch über ähnliche Funktionen .

Quellen

• Grundlagen des SQL-Datenbankdesigns mit Beispiel
• Geecko
• Microsoft SQL-Dokumentation
• SSMS
• Datenbankdiagramm-Tool für SQL Server