Einführung in die Datenbank-Design

Dieser Artikel / Tutorial werden die Basis von relationalem Datenbank-Design lehren und erklären, wie ein gutes Datenbank-Design zu machen. Es ist ein ziemlich langer Text, aber wir raten, alles zu lesen. Entwerfen einer Datenbank ist in der Tat ziemlich einfach, aber es gibt ein paar Regeln zu kleben. Es ist wichtig zu wissen, was diese Regeln sind, aber noch wichtiger ist, zu wissen, warum diese Regeln existieren, sonst werden Sie neigen dazu, Fehler zu machen!

Standardisierung macht Ihr Datenmodell flexibel und das macht Arbeit mit Ihren Daten viel einfacher. Bitte nehmen Sie die Zeit, um diese Regeln zu erlernen und anzuwenden sie! Die Datenbank in diesem Artikel verwendet wird mit unserem Datenbank-Design und Modellierungs-Tool DeZign für Datenbanken entwickelt.

Ein gutes Datenbank-Design beginnt mit einer Liste der Daten, die Sie in Ihrer Datenbank aufnehmen mögen und was Sie wollen später mit der Datenbank tun können. Dies kann alles in Ihrer eigenen Sprache geschrieben werden, ohne SQL. In dieser Phase müssen Sie versuchen, nicht in Tabellen oder Spalten zu denken, aber man denke nur: „Was muss ich wissen“ Seien Sie nicht zu leicht nehmen dies, denn wenn man später feststellen, dass Sie etwas vergessen haben, in der Regel müssen Sie von vorne anfangen. Hinzufügen Dinge zu Ihrer Datenbank ist vor allem eine Menge Arbeit.

Identifizierung von Entities

Die Arten von Informationen, die in der Datenbank gespeichert sind, werden ‚Einheiten‘ genannt. Diese Einheiten bestehen in vier Arten: Menschen, Dinge, Ereignisse und Orte. Alles, was Sie in einer Datenbank setzen passt in eine dieser Kategorien wünschen könnte. Wenn die Informationen, die Sie aufnehmen möchten, nicht in diese Kategorien passen, als es wahrscheinlich keine Einheit, sondern eine Eigenschaft eines Unternehmens, ein Attribut.

Aber welche andere Dinge geschehen, wenn ein Produkt verkaufen? Ein Kunde kommt in den Laden, nähert sie den Anbieter, stellt eine Frage und bekommt eine Antwort. „Verkäufer“ auch teilnehmen, und da Verkäufer Menschen sind, brauchen wir einen Anbieter Einheit.

Identifizierung von Beziehungen

Der nächste Schritt ist es, die Beziehungen zwischen den Einheiten zu bestimmen, und die Mächtigkeit jeder Beziehung zu bestimmen. Die Beziehung ist die Verbindung zwischen den Entitäten, genau wie in der realen Welt: Was bedeutet eine Einheit mit dem anderen zu tun, in welcher Beziehung stehen sie zueinander? Zum Beispiel kaufen Kunden Produkte, Produkte an Kunden verkauft werden, ein Verkaufsprodukt umfasst, geschieht ein Verkauf in einem Geschäft.

Die Mächtigkeit zeigt, wie viel von einer Seite der Beziehung der anderen Seite der Beziehung zu wie viel gehört. Zuerst müssen Sie für jede Beziehung sagen, wie viel von einer Seite gehört zu genau 1 von der anderen Seite. Zum Beispiel: Wie viele Kunden gehören 1 Verkauf an ?; Wie viele Verkäufe gehören zu 1 Kunden ?; Wie viele Verkäufe finden in 1 shop?

Sie erhalten eine Liste wie diese: (bitte beachten Sie, dass ‚Produkt‘ eine Art von Produkt darstellt, kein Auftreten eines Produkts)

  • Kunden -> Vertrieb; 1 Kunde kann etwas mehrmals kaufen
  • Verkauf -> Kunden; 1 Verkauf wird immer von 1 Kunden zum Zeitpunkt gemacht
  • Kunden -> Produkte; 1 Kunden können mehrere Produkte kaufen
  • Produkte -> Kunden; 1 Produkt kann durch mehrere Kunden gekauft werden
  • Kunden -> Shops; 1 Kunden können in mehreren Geschäften kaufen
  • Shops -> Kunden können 1 shop mehrere Kunden erhalten
  • Shops -> Produkte; in 1 Geschäft gibt es mehrere Produkte
  • Produkte -> Shops; 1 Produkt (Typ) kann in mehreren Geschäften verkauft werden
  • Shops -> Vertrieb; in 1 shop mehrere Vertrieb kann ich gemacht
  • Verkauf -> Shops; 1 Verkauf nur in 1 Geschäft zum Zeitpunkt gemacht werden,
  • Produkte -> Vertrieb; 1 Produkt (Typ) kann in mehr Vertrieb gekauft werden
  • Verkauf -> Produkte; 1 Verkauf kann aus mehreren Produkten bestehen

Haben wir schon erwähnt, alle Beziehungen? Es gibt vier Einheiten und jede Einheit hat eine Beziehung mit jeder anderen Einheit, so dass jedes Unternehmen muss drei Beziehungen hat, und auch am linken Ende der Beziehung dreimal erscheinen. Oben wurden 12 Beziehungen erwähnt, die 4 * 3 ist, so können wir alle Beziehungen erwähnt schließen, dass.

Jetzt werden wir die Daten zusammengestellt, die Mächtigkeit der ganzen Beziehung zu finden. Um dies zu tun, werden wir die Mächtigkeiten pro Beziehung entwerfen. Um dies einfach zu tun, werden wir die Notation ein wenig anpassen, mit der Feststellung der ‚backward'-Verhältnis umgekehrt:

  • Kunden -> Vertrieb; 1 Kunde kann etwas mehrmals kaufen
  • Verkauf -> Kunden; 1 Verkauf wird immer von 1 Kunden zum Zeitpunkt gemacht

Die zweite Beziehung, die wir umdrehen, so dass es die gleiche Einheit, um als erstes hat. Bitte beachten Sie den Pfeil, der nun in die andere Richtung konfrontiert!

  • Kunden, Vertrieb; 1 Kunde kann etwas mehrmals kaufen; 1: N.
  • Kunden, Vertrieb; -> 1: N
  • Kunden -> Produkte; -> M: N
  • Kunden -> Shops; -> M: N
  • Verkauf -> Produkte; -> M: N
  • Shops -> Vertrieb; -> 1: N
  • Shops -> Produkte; -> M: N
So haben wir zwei '1-zu-viele' Beziehungen und vier 'many-to-many' Beziehungen.

Die Beziehungen Verkauf -> Kunden und Vertrieb -> Produkte sind obligatorisch, aber umgekehrt ist dies nicht der Fall ist. Ein Kunde kann ohne Verkauf vorhanden ist, und auch ein Produkt ohne Verkauf bestehen. Dies ist von Bedeutung für den nächsten Schritt.

rekursive Relationships

Manchmal bezieht sich ein Unternehmen an sich selbst zurück. Denken Sie zum Beispiel einer Arbeits Hierarchie: ein Mitarbeiter einen Chef hat; und der bosschef ist auch Mitarbeiter. Das Attribut ‚Chef‘ des Unternehmens ‚Arbeitnehmer‘ bezieht sich auf die Einheit "Mitarbeiter zurück.

In einem ERD (siehe nächstes Kapitel) ist diese Art der Beziehung eine Linie, die aus dem Unternehmen geht und kehrt mit einer schönen Schleife zu derselben Einheit.

redundante Beziehungen

Manchmal in Ihrem Modell finden Sie eine ‚redundante Beziehung‘ bekommen. Dies sind Beziehungen, die bereits durch andere Beziehungen angezeigt, wenn auch nicht direkt.

Im Fall unseres Beispiels gibt es eine direkte Beziehung zwischen Kunden und Produkten. Aber es gibt auch Beziehungen von Kunden zu Umsatz und aus dem Verkauf von Produkten, so indirekt bereits eine Beziehung zwischen Kunden und Produkten durch den Verkauf. Die Beziehung ‚Kunden Produkte‘ wird zweimal gemacht, und einer von ihnen ist daher überflüssig. In diesem Fall werden die Produkte nur durch einen Verkauf erworben haben, so können die Beziehungen der Kunden, Produkte 'gelöscht werden. Das Modell wird dann wie folgt aussehen:

Lösen von Many-to-Many Beziehungen

Viele-zu-viele-Beziehungen (M: N) sind nicht direkt möglich, in einer Datenbank. Was für ein M: N Beziehung sagt, ist, dass eine Reihe von Datensätzen aus einer Tabelle in eine Anzahl von Datensätzen aus einer anderen Tabelle gehört. Irgendwo müssen Sie speichern, welche Datensätze diese sind, und die Lösung ist, um die Beziehung zu spalten in zwei Eins-zu-viele-Beziehungen.

Dies kann durch die Schaffung einer neuen Einheit erfolgen, die zwischen den verbundenen Unternehmen ist. In unserem Beispiel gibt es eine viele-zu-viele-Beziehung zwischen Vertrieb und Produkten. Verkaufsprodukte: Dies kann durch die Schaffung einer neuen Einheit gelöst werden. Diese Einheit hat eine viele-zu-eins-Beziehung mit Sales, und eine viele-zu-eins-Beziehung mit Produkte. In der logischen Modellen ist dies eine assoziative Einheit und in der physikalischen Datenbank Begriffen genannt wird dies eine Verknüpfungstabelle oder Verknüpfungstabelle bezeichnet.

Im Beispiel gibt es zwei many-to-many-Beziehungen, die gelöst werden müssen: ‚Produkte Vertrieb‘ und ‚Produkte Shops‘. Für beide Situationen braucht es eine neue Einheit geschaffen werden, aber was ist das Unternehmen?

Für die Produkte Vertrieb Beziehung beinhaltet jeder Verkauf mehr Produkte. Die Beziehung zeigt den Inhalt des Verkaufs. Mit anderen Worten, es gibt Details über den Verkauf. So ist das Unternehmen 'Sales Details genannt. Sie könnten nennen es ‚verkauft Produkte‘ auch.

Die Produkte Shops Beziehung zeigt, welche Produkte verfügbar sind, in denen die Geschäfte, die auch als ‚Lager‘ bekannt. Unser Modell aussehen würde nun wie folgt aus:

identifizierenden Attribute

Die Datenelemente, die Sie für jede Entität gespeichert werden soll heißen ‚Attribute‘.

Über die Produkte, die Sie verkaufen, Sie wissen wollen, zum Beispiel, was der Preis ist, was der Name des Herstellers ist, und was die Typennummer ist. Über den Kunden wissen, dass Sie ihre Kundennummer, ihren Namen und Adresse. Über die Geschäfte kennen Sie den Standortcode, den Namen, die Adresse. Von dem Umsatz wissen, wann sie passiert ist, in dem Geschäft, welche Produkte verkauft wurden, und die Summe des Verkaufs. Des Anbieters kennen Sie seine Mitarbeiter Nummer, Name und Adresse. Was genau enthalten sein wird, ist nicht von Bedeutung noch; es ist immer noch nur über das, was Sie speichern möchten.

abgeleitete Daten

Abgeleiteten Daten sind Daten, die von den anderen Daten abgeleitet wird, die Sie bereits gespeichert haben. In diesem Fall ist die ‚Summe‘ ist ein klassischer Fall von abgeleiteten Daten. Sie wissen genau, was verkauft wurde und was jedes Produkt Kosten, so dass Sie immer berechnen, wie viel die Summe der Verkäufe ist. Also eigentlich ist es nicht notwendig, die Summe zu speichern.

Also warum ist es hier gespeichert? Nun, weil es ein Verkauf, und der Preis des Produktes kann im Laufe der Zeit variieren. Ein Produkt kann bei 10 Euro heute und für 8 Euro im nächsten Monat festgesetzt werden und für Ihre Verwaltung müssen Sie wissen, was es zum Zeitpunkt des Verkaufs kosten, und der einfachste Weg, dies zu tun, ist es hier zu speichern. Es gibt eine Menge von elegantere Wege, aber sie sind zu tief für diesen Artikel.

Presenting Entitäten und Beziehungen: Entity-Relationship-Diagramm (ERD)

Das Entity-Relationship-Diagramm (ERD) gibt einen grafischen Überblick über die Datenbank. Es gibt verschiedene Arten und Typen von ER-Diagramme. Eine viel verwendete Schreibweise ist die ‚crowfeet‘ Notation, in denen Unternehmen als Rechtecke dargestellt sind, und die Beziehungen zwischen den Entitäten als Linien zwischen den Entitäten dargestellt. Die Zeichen am Ende der Linien zeigen die Art der Beziehung. Die Seite der Beziehung, die zwingend für die andere wird existieren auf der Linie, die durch einen Bindestrich angegeben werden. Nicht zwingend Einheiten sind durch einen Kreis dargestellt. „N“ wird durch eine ‚crowfeet‘ angedeutet; de Beziehung-Linie teilt in drei Linien.

In diesem Artikel stellen wir die Verwendung von DeZign für Datenbanken zu entwerfen und zu unserer Datenbank zu präsentieren.

Eine 1: 1-Beziehung zwingend ist wie folgt dargestellt:

A 1: N obligatorische Beziehung:

Zuweisen von Keys

Fremdschlüssel

Wenn wir alle Link-Einheiten setzen, PK und FK ist in der ERD, bekommen wir das Modell wie unten gezeigt. Bitte beachten Sie, dass das Attribut ‚Produkte‘ sind nicht mehr notwendig, in ‚Verkauf‘, weil ‚verkaufte Produkte‘ jetzt in der Link-Tabelle enthalten ist. In der Link-Tabelle wurde ein weiteres Feld hinzugefügt, ‚Menge‘, die angibt, wie viele Produkte verkauft wurden. Das Mengenfeld wurde auch in der Lager-Tabelle hinzugefügt, um anzuzeigen, wie viele Produkte noch im Geschäft ist.

Definition der Datentyp des Attributs

Nun ist es Zeit, um herauszufinden, welche Datentypen für die Attribute werden müssen, verwendet. Es gibt viele verschiedene Datentypen. Einige sind standardisiert, aber viele Datenbanken haben ihre eigenen Datentypen, die alle ihre eigenen Vorteile haben. Einige Datenbanken offerthe Möglichkeit, eigene Datentypen zu definieren, falls die Standardtypen, die Dinge nicht tun können, die Sie benötigen.

Die Standard-Datentypen, die jede Datenbank kennt, und am meisten verwendet werden, sind: CHAR, VARCHAR, TEXT, FLOAT, DOUBLE und INT.

Text:
  • CHAR (Länge) - umfasst Text (Buchstaben, Zahlen, Satzzeichen.). CHAR hat als Eigenschaft, dass es immer eine festgelegte Menge an Positionen speichert. Wenn Sie eine CHAR (10) definieren, können Sie bis zu zehn Positionen maximal sparen, aber wenn man nur zwei Positionen verwendet die Datenbank noch 10 Positionen speichern. Die übrigen acht Positionen wird durch Leerzeichen gefüllt werden.
  • VARCHAR (Länge) - umfasst Text (Buchstaben, Zahlen, Satzzeichen.). VARCHAR ist die gleiche wie CHAR, ist der Unterschied, dass VARCHAR nur so viel Platz wie nötig braucht.
  • TEXT - können große Mengen an Text enthalten. Je nach Art der Datenbank kann dies bis zu Gigabyte hinzufügen.
Nummern:
  • INT - enthält eine positive oder negative ganze Zahl. Viele Datenbanken haben Variationen des INT, wie TINYINT, SMALLINT, MEDIUMINT, BIGINT, INT2, INT4, INT8. Diese Varianten unterscheiden sich von dem INT nur in der Größe der Figur, die in sie passt. Eine regelmäßige INT ist 4 Byte (INT4) und paßt Zahlen von -2147483647 bis 2147483646, oder wenn Sie es als UNSIGNED von 0 bis 4294967296. Die INT8 definieren oder BIGINT, kann sogar noch größer in Größe, 0-18446744073709551616, aber nimmt zu 8 Byte Speicherplatz, auch wenn es in ihm nur eine kleine Zahl ist.
  • FLOAT, DOUBLE - Die gleiche Idee wie INT, kann aber auch Store Gleitkommazahlen. Sie beachten Sie, dass dies nicht immer perfekt funktioniert. Zum Beispiel in MySQL mit diesem Gleitkommazahlen Berechnung ist nicht perfekt, (1/3) * 3 mit MySQLs Schwimmern in 0,9999999 führen, nicht mehr als 1.
Andere Arten:
  • BLOB - für binäre Daten wie files.INET - für IP-Adressen. Auch verwendbar für netmasks.

Für unser Beispiel sind die Datentypen wie folgt:

Normalisierung

Normalisierungs macht Ihr Datenmodell flexibel und zuverlässig. Es dauert einige Overhead erzeugen, weil Sie in der Regel mehr Tabellen, aber es ermöglicht es Ihnen, viele Dinge mit Ihrem Datenmodell zu tun, ohne es anpassen zu müssen.

Normalisierungs, die erste Form

Was ist das falsch ist, dass jetzt nur noch drei Produkte verkauft werden können. Wenn Sie 4 Produkte verkaufen würden, als Sie einen zweiten Verkauf beginnen würde oder Ihr Datenmodell anpassen, indem Sie das Hinzufügen ‚product4‘ Attribute. Beide Lösungen sind unerwünscht. In diesen Fällen sollten Sie immer eine neue Entität erstellen, die Sie mit dem alten Link über eine Eins-zu-viele-Beziehung.

Normalisierungs, die zweite Form

Diese Einheit ist die zweite Normalisierungsform nicht nach, weil um in der Lage sein, den Zeitpunkt eines Verkaufs zu sehen, muss ich das einzige, was ich wissen muss nicht wissen, was verkauft wird (Produktnr), ist die Verkaufsnummer. Dies wurde durch Aufspaltung der Tabellen in den Verkauf und die Sales_details Tabelle zu lösen:

Jetzt jedes Attribut der Entitäten ist abhängig von der gesamten PK des Unternehmens steht. Das Datum ist abhängig von der Verkaufsnummer und die Menge ist abhängig von der Verkaufsnummer und der verkauften Ware.

Normalisierungs, die dritte Form

In diesem Fall wird der Preis eines losen Produkts ist abhängig von der Bestellnummer und die Bestellnummer ist abhängig von der Produktnummer und der Verkaufsnummer. Dies ist nicht gemäß der dritten Form der Normalisierung. Dies wiederum löst die Tabellen Aufspaltung.

Normalisierungs, Weitere Formulare

Es gibt mehr Normalisierungsformen als die drei oben genannten Formen, aber die sind nicht von großen Interesse für die durchschnittlichen Benutzer. Diese anderen Formen sind für bestimmte Anwendungen sehr spezialisiert. Wenn Sie mit den Design-Regeln und die Normalisierung bleiben in diesem Artikel erwähnt, werden Sie ein Design erstellen, die für die meisten Anwendungen funktionieren gut.

Normalisierte Datenmodell

Wenn Sie die Normalisierungsregeln anwenden, werden Sie feststellen, dass die ‚Hersteller‘ in de Produkttabelle auch eine separate Tabelle sein sollten:

Attribute - detaillierte Daten über ein Unternehmen, wie Preis, Länge, Name

Cardinality - die Beziehung zwischen zwei Entitäten, in Zahlen. Zum Beispiel kann eine Person mehrere Aufträge vergeben.

Entities - abstrakte Daten, die Sie in einer Datenbank speichern. Zum Beispiel: Kunden, Produkte.

Normalisierungs - Ein flexibles Datenmodell muss bestimmte Regeln folgen. Anwendung dieser Regeln wird Normalisieren bezeichnet.

Lernen
  • DeZign für Datenbanken. Erfahren Sie mehr über DeZign für Datenbanken.
  • Erste Schritte mit DeZign für Datenbanken gestartet. Starten Sie ein Datenmodell direkt zu machen.
  • Display-Datentypen in einem Diagramm. Erfahren Sie, wie Datentyp angezeigt werden und / oder info-Domain in den Entity-Box in Ihrem Diagramm.
Erhalten Sie Produkte und Technologien
  • Bauen Sie Ihr nächstes Datenmodell mit DeZign für Datenbanken Testsoftware, zum Herunterladen von direkt Datanamic Download-Sektion.

In Verbindung stehende Artikel