Datenbank Design

Datenbank Design ist die Organisation von Daten nach a Datenbankmodell. Der Designer bestimmt, welche Daten gespeichert werden müssen und wie sich die Datenelemente miteinander in Verbindung bringen. Mit diesen Informationen können sie beginnen, die Daten in das Datenbankmodell anzupassen.^[1] Das Datenbankverwaltungssystem verwaltet die Daten entsprechend.

Datenbankdesign beinhaltet die Klassifizierung von Daten und die Identifizierung von Wechselbeziehungen. Diese theoretische Darstellung der Daten wird als eine genannt Ontologie. Die Ontologie ist die Theorie hinter dem Design der Datenbank.

Daten bestimmen, die gespeichert werden sollen

In den meisten Fällen ist eine Person, die die Gestaltung einer Datenbank durchführt, eine Person mit Fachwissen im Bereich des Datenbankdesigns, anstatt in der Domäne, aus der die zu gespeicherten Daten zu speichern sind, z. Finanzinformationen, biologische Informationen usw. Daher müssen die in der Datenbank gespeicherten Daten in Zusammenarbeit mit einer Person ermittelt werden, die in dieser Domäne über Fachwissen verfügt und der weiß, welche Daten im System gespeichert werden müssen.

Dieser Prozess wird allgemein als Teil von als Teil von angesehen Anforderungsanalyseund erfordert die Fähigkeiten des Datenbankdesigers, um die erforderlichen Informationen von denen mit dem zu ermitteln Fachwissen. Dies liegt daran, dass diejenigen mit dem erforderlichen Domänenwissen häufig nicht klar ausdrücken können, welche Systemanforderungen für die Datenbank sind, da sie in Bezug auf die diskreten Datenelemente, die gespeichert werden müssen, nicht an das Denken gewöhnt sind. Zu gespeicherte Daten können durch Anforderungsspezifikation bestimmt werden.^[2]

Datenbeziehungen bestimmen

Sobald sich ein Datenbankdesigner der Daten, die in der Datenbank gespeichert werden sollen, bekannt sind, müssen sie dann bestimmen, wo sich die Abhängigkeit innerhalb der Daten befindet. Manchmal, wenn Daten geändert werden, können Sie andere Daten ändern, die nicht sichtbar sind. In einer Liste von Namen und Adressen unter der Annahme einer Situation, in der mehrere Personen dieselbe Adresse haben können, ist beispielsweise die Adresse von dem Namen abhängig. Wenn ein Name und die Liste angegeben werden, kann die Adresse eindeutig bestimmt werden; Das Inverse gilt jedoch nicht - wenn eine Adresse und die Liste angegeben werden, kann ein Name nicht eindeutig bestimmt werden, da mehrere Personen an einer Adresse wohnen können. Da eine Adresse durch einen Namen bestimmt wird, wird eine Adresse als abhängig von einem Namen angesehen.

(Hinweis: Ein weit verbreitetes Missverständnis ist, dass die Relationales Modell wird so genannt, weil die Beziehungen zwischen Datenelementen darin angegeben sind. Das ist nicht wahr. Das relationale Modell wird so benannt, weil es auf den mathematischen Strukturen basiert Beziehungen.))

Logisch strukturieren Daten

Sobald die Beziehungen und Abhängigkeiten zwischen den verschiedenen Informationen festgelegt wurden, ist es möglich, die Daten in eine logische Struktur zu ordnen, die dann in die von der unterstützten Speicherobjekte abgebildet werden kann Datenbankverwaltungssystem. Im Falle des relationale Datenbanken Die Speicherobjekte sind Tische welche Daten in Zeilen und Spalten speichern. In einem (n Objektdatenbank Die Speicherobjekte entsprechen direkt den von den verwendeten Objekten Objektorientierte Programmiersprache Wird verwendet, um die Anwendungen zu schreiben, die die Daten verwalten und zugreifen. Die Beziehungen können als Attribute der beteiligten Objektklassen oder als Methoden definiert werden, die an den Objektklassen arbeiten.

Die Art und Weise, wie diese Zuordnung im Allgemeinen durchgeführt wird, ist so, dass jeder Satz verwandter Daten, der von einem einzelnen Objekt abhängt, ob real oder abstrakt, in eine Tabelle platziert wird. Die Beziehungen zwischen diesen abhängigen Objekten werden dann als Verbindungen zwischen den verschiedenen Objekten gespeichert.

Jede Tabelle kann eine Implementierung eines logischen Objekts oder einer Beziehung darstellen, die eine oder mehrere Instanzen eines oder mehrerer logischer Objekte verbindet. Die Beziehungen zwischen Tabellen können dann als Links gespeichert werden, die Kindertische mit den Eltern verbinden. Da komplexe logische Beziehungen selbst Tabellen sind, haben sie wahrscheinlich Links zu mehr als einem Elternteil.

ER-Diagramm (Entitätsbeziehungsmodell)

Datenbankdesigns umfassen auch ER (Entitätsbeziehungsmodell) Diagramme. Ein ER -Diagramm ist ein Diagramm, mit dem Datenbanken effizient gestaltet werden können.

Attribute in ER -Diagrammen werden normalerweise als Oval mit dem Namen des Attributs modelliert, das mit der Entität oder Beziehung verbunden ist, die das Attribut enthält.

ER -Modelle werden üblicherweise im Design des Informationssystems verwendet. Beispielsweise werden sie verwendet, um Informationsanforderungen und / oder die Arten von Informationen zu beschreiben, die während der konzeptionellen Struktur -Designphase in der Datenbank gespeichert werden sollen.^[3]

Ein Entwurfsprozessvorschlag für Microsoft Access

1. Bestimmen Sie den Zweck der Datenbank - Dies hilft, sich auf die verbleibenden Schritte vorzubereiten.
2. Finden und organisieren Sie die erforderlichen Informationen - Sammeln Sie alle Arten von Informationen, die in der Datenbank aufgezeichnet wurden, z. B. Produktname und Bestellnummer.
3. Teilen Sie die Informationen in Tabellen auf - Informationsgegenstände in Großeinheiten oder Themen wie Produkte oder Bestellungen unterteilen. Jedes Thema wird dann zu einer Tabelle.
4. Verwandeln Sie Informationenelemente in Spalten - Entscheiden Sie, welche Informationen in jeder Tabelle gespeichert werden müssen. Jedes Element wird zum Feld und wird als Spalte in der Tabelle angezeigt. Beispielsweise kann eine Mitarbeitertabelle Felder wie Nachname und Mietdatum enthalten.
5. Geben Sie Primärschlüssel an - Wählen Sie den Primärschlüssel jeder Tabelle. Die Primärschlüssel ist eine Spalte oder eine Reihe von Spalten, mit denen jede Zeile eindeutig identifiziert wird. Ein Beispiel kann eine Produkt -ID oder die Bestell -ID sein.
6. Richten Sie die Tabellenbeziehungen ein - Schauen Sie sich jede Tabelle an und entscheiden Sie, wie die Daten in einer Tabelle mit den Daten in anderen Tabellen zusammenhängen. Fügen Sie Tabellen Felder hinzu oder erstellen Sie neue Tabellen, um die Beziehungen nach Bedarf zu klären.
7. Verfeinern Sie das Design - Analysieren Sie das Design auf Fehler. Erstellen Sie Tabellen und fügen Sie einige Datensätze von Beispieldaten hinzu. Überprüfen Sie, ob die Ergebnisse wie erwartet aus den Tabellen kommen. Nehmen Sie nach Bedarf Anpassungen am Design vor.
8. Wende an Normalisierungsregeln - Wenden Sie die Datennormalisierungsregeln an, um festzustellen, ob Tabellen korrekt strukturiert sind. Nehmen Sie nach Bedarf Anpassungen an den Tabellen vor.

^[4]

Normalisierung

Auf dem Gebiet der relationale Datenbank Entwurf, Normalisierung ist ein systematischer Weg, um sicherzustellen, dass eine Datenbankstruktur für allgemeine Abfragen geeignet ist und von bestimmten unerwünschten Eigenschaften frei Datenintegrität.

Eine Standardanleitung für Datenbankdesign ist, dass der Designer ein vollständig normalisiertes Design erstellen sollte. selektiv Denormalisierung kann anschließend durchgeführt werden, aber nur für Leistung Gründe dafür. Der Kompromiss ist der Speicherplatz gegen Leistung. Je normalisierter das Design ist, desto weniger Datenreduktion gibt es (und daher benötigt es weniger Platz zum Speichern). Allerdings benötigen gemeinsame Datenabrufmuster komplexe Verknüpfungen, Verschmelzungen und Sorten - was mehr Daten aufnimmt Lesen Sie und berechnen Sie Zyklen. Einige Modellierungsdisziplinen wie die Dimensionsmodellierung Herangehensweise an Data Warehouse Design, explizit nicht ormalisierte Designs empfehlen, d. H. Entwürfe, die zum großen Teil nicht an 3NF haften. Die Normalisierung besteht aus normalen Formen, die 1NF, 2NF, 3NF, Boyce-Codd NF (3,5NF), 4NF und 5NF sind

Dokumentdatenbanken verfolgen einen anderen Ansatz. Ein Dokument, das in einer solchen Datenbank gespeichert ist, enthält normalerweise mehr als eine normalisierte Dateneinheit und häufig auch die Beziehungen zwischen den Einheiten. Wenn alle Dateneinheiten und die fraglichen Beziehungen häufig zusammen abgerufen werden, optimiert dieser Ansatz die Anzahl der Abrufe. Es vereinfacht auch, wie Daten repliziert werden, da es jetzt eine eindeutig identifizierbare Dateneinheit gibt, deren Konsistenz in sich geschlossen ist. Eine weitere Überlegung ist, dass das Lesen und Schreiben eines einzelnen Dokuments in solchen Datenbanken eine einzelne Transaktion erfordern - was eine wichtige Überlegung in a sein kann Microservices die Architektur. In solchen Situationen werden Teile des Dokuments häufig über eine API aus anderen Diensten abgerufen und aus Effizienzgründen lokal gespeichert. Wenn die Dateneinheiten über die Dienste aufgeteilt werden, dann benötigt ein Lesen (oder Schreiben), um einen Dienstverbraucher zu unterstützen, möglicherweise mehr als einen Serviceanruf, und dies kann zu einer Verwaltung mehrerer Transaktionen führen, die möglicherweise nicht bevorzugt werden.

Konzeptionales Schema

Physisches Design

Das physische Design der Datenbank gibt die physische Konfiguration der Datenbank in den Speichermedien an. Dies beinhaltet eine detaillierte Spezifikation von Datenelemente, Datentypen, Indizierung Optionen und andere Parameter, die sich in den DBMs befinden Datenwörterbuch. Es ist das detaillierte Design eines Systems, das Module und die Hardware- und Softwarespezifikationen der Datenbank des Systems enthält. Einige Aspekte, die auf der physischen Schicht behandelt werden:

• Sicherheit - Endbenutzer sowie administrative Sicherheit.
• Replikation - Welche Datenstücke werden in eine andere Datenbank kopiert und wie oft. Gibt es mehrere Meister oder eine einzige?
• Hochverfügbarkeit-Ob die Konfiguration aktiv-passiv oder aktiv ist, das Topologie, das Koordinationsschema, die Zuverlässigkeitsziele usw. müssen definiert werden.
• Partitionierung - Wenn die Datenbank verteilt ist, wie werden die Daten für eine einzelne Entität unter allen Partitionen der Datenbank verteilt und wie berücksichtigt ein Partitionsfehler.
• Sicherungs- und Wiederherstellungsschemata.

Auf Anwendungsebene können andere Aspekte des physischen Designs die Notwendigkeit des Definierens gespeicherter Verfahren oder materialisierter Abfrageansichten umfassen. Olap Würfel usw.

Siehe auch

Verweise

Weitere Lektüre

• S. Lightstone, T. Teorey, T. Nadeau, „Physikalische Datenbankdesign: Der Leitfaden des Datenbankprofis zur Nutzung von Indizes, Ansichten, Speicher und mehr“, Morgan Kaufmann Press, 2007. ISBN0-12-369389-6
• M. Hernandez, "Datenbankdesign für bloße Sterbliche: Ein praktischer Leitfaden für relationale Datenbankdesign ", 3. Auflage, Addison-Wesley Professional, 2013. ISBN0-321-88449-3

Externe Links

• [1]
• [2]
• Datenbanknormalisierung Grundlagen von Mike Chapple (about.com)
• Datenbanknormalisierung Intro, Teil 2
• "Eine Einführung in die Datenbanknormalisierung". Archiviert von das Original Am 2011-06-06. Abgerufen 2012-02-25.
• "Normalisierung". Archiviert von das Original Am 2010-01-06. Abgerufen 2012-02-25.
• Datenbank Design bei Curlie