Die Anzahl der Entitäten auf jeder Seite der Beziehung wird aufgerufen. Entity-Relationship-Datenmodell. Attribut-Checkliste

Eines der beliebtesten Mittel zur formalisierten Darstellung des Themenbereichs von Systemen, die sich auf die Verarbeitung von Fakteninformationen konzentrieren, ist das "Entity-Relationship" -Modell, das die Grundlage für eine erhebliche Anzahl kommerzieller CASE-Produkte bildet, die den gesamten Entwicklungszyklus von Datenbanksystemen oder deren einzelnen Phasen unterstützen. Gleichzeitig unterstützen viele von ihnen nicht nur die Phase des konzeptionellen Entwurfs des zu entwickelnden Themenbereichs des Systems, sondern ermöglichen auch die Phase des logischen Entwurfs auf der Grundlage des von ihren Tools erstellten Modells, indem automatisch ein konzeptionelles Datenbankschema für das ausgewählte DBMS generiert wird, z. B. ein Datenbankschema für einige SQL -Server oder Objekt DBMS.

Die Domänenmodellierung basiert in diesem Fall auf der Verwendung grafischer Diagramme, die eine relativ kleine Anzahl von Komponenten enthalten, und vor allem: konstruktionstechnologiesolche Diagramme.

Die semantische Basis des ER-Modells basiert auf folgenden Annahmen:

dieser Teil der realen Welt (eine Reihe miteinander verbundener Objekte), über den Informationen in die Datenbank gestellt werden sollen, kann sein präsentiert alsaggregat entitäten;

jede Entität verfügt über charakteristische Eigenschaften (Attribute), die sie von anderen Entitäten unterscheiden und zulassen zu identifizieren;

entitäten können nach Entitätstypen klassifiziert werden: Jede Entitätsinstanz (die ein Objekt darstellt) kann klassifiziert werden zuklasse - art der Entitätenjede Instanz hat gemeinsame Eigenschaften und unterscheidet sie von Entitäten anderer Klassen.

die klassenbasierte Systematisierung der Repräsentation impliziert im Allgemeinen eine hierarchische Abhängigkeit der Typen: die Entität des Typs UND ist ein subtypentitäten BEIM,wenn jede Instanz des Typs UND ist eine Instanz einer Entität vom Typ BEIM;

die Beziehung von Objekten kann dargestellt werden als beziehungen - Entitäten,die dazu dienen, die gegenseitige Abhängigkeit von zwei oder mehr Entitäten zu fixieren (darzustellen).

Hier ist noch einmal der informative Charakter des Konzepts hervorzuheben wesenund seine Beziehung zu materiellen oder imaginären Objekten des Subjektbereichs. Jedes Objekt des Themenbereichs hat Eigenschaften, von denen einige als charakteristisch unterschieden werden - vom Standpunkt des angewandten Problems aus signifikant. Zur gleichen Zeit, zum Beispiel bei der Analyse und Systematisierung des Themenbereichs, klassen -eine Reihe von Objekten mit denselben Eigenschaften, die im Formular angegeben sind attributmengen(Die Werte von Attributen für Objekte derselben Klasse können natürlich abweichen.) Dementsprechend entspricht auf der Ebene der Darstellung des Subjektbereichs (d. H. Seines infologischen Modells) ein Objekt, das als Konzept betrachtet wird (ein Objekt im menschlichen Bewusstsein), dem Konzept wesen;ein Objekt als Teil der materiellen Welt (und unabhängig vom Bewusstsein eines Menschen existierend) entspricht dem Konzept eine Instanz einer Entität;objektklasse entspricht dem Konzept entitätstyp.

Da das infologische Modell im Folgenden nicht einzelne Instanzen von Objekten, sondern Klassen berücksichtigt, werden wir im Folgenden nicht zwischen den entsprechenden Konzepten dieser beiden Ebenen unterscheiden, d. H. Wir werden die Identität der Konzepte annehmen ein Objektund entität, Eigenschaft eines Objektsund eigentum des Unternehmens.

ER-Modell,als Beschreibung des Themenbereichs müssen Objekte und die Beziehung zwischen ihnen definiert werden, dh die folgenden zwei Arten von Beziehungen hergestellt werden.

1. Beziehungen zwischen Objekten und Mengen charakteristischer Eigenschaften und definieren Sie somit die Objekte selbst.

2. Verbindungen zwischen Objekten, die die Art und Funktionsweise ihrer gegenseitigen Abhängigkeit definieren.

Wie bereits erwähnt, basiert die ER-Modellierung der Domäne auf der Verwendung grafischer Diagramme als einfache (vertraute), visuelle und gleichzeitig informative und vielfältige Art der Anzeige von Projektkomponenten. Daher wird die Darstellung der wichtigsten Bestimmungen des ER-Modells anhand des Materials des in Abb. 1 gezeigten Beispiels des ER-Diagramms veranschaulicht. 5.4.

Wesen.Die Essenz, mit deren Hilfe eine Klasse von Objekten des gleichen Typs modelliert wird, wird definiert als „ein Objekt, das eindeutig identifiziert werden kann“. So wie jedes Objekt eindeutig durch eine Reihe von Eigenschaftswerten gekennzeichnet ist, muss eine Entität definiert seindamit eine Reihe von Attributen,dies würde es ermöglichen, zwischen einzelnen Instanzen einer Entität zu unterscheiden. Jede Instanz einer Entität muss von jeder anderen Instanz derselben Entität unterscheidbar sein (diese Anforderung ähnelt der Anforderung, dass in relationalen Tabellen keine doppelten Tupel vorhanden sind). Um beispielsweise jede Instanz der Entität "Mitarbeiter" eindeutig zu identifizieren, wird das Attribut "Personalnummer" eingeführt, das aufgrund seiner Art immer vorhanden ist einzigartiger Wert innerhalb des Unternehmens. Das heißt, eine eindeutige Kennung einer Entität kann ein Attribut, eine Kombination von Attributen, eine Kombination von Beziehungen oder eine Kombination von Beziehungen und Attributen sein, die eine Entitätsinstanz eindeutig von anderen Entitätsinstanzen desselben Typs unterscheidet.

Das Unternehmen hat name,einzigartig innerhalb des Modells. Dabei entitätsname -das modellname,und nicht eine bestimmte Instanz.

Entitäten sind unterteilt in starkund schwach.Eine Entität ist schwach, wenn ihre Existenz von einer anderen Entität abhängt, die gegen sie stark ist. Zum Beispiel ist die untergeordnete Entität in Bezug auf schwach zuentität "Mitarbeiter": Wenn ein Datensatz gelöscht wird, der einem bestimmten Mitarbeiter mit Untergebenen entspricht, sollten auch die Informationen über die Unterordnung gelöscht werden.

Eigenschaften.Die Art der Immobilie ist wie art der Kommunikationeigenschaften mit einer Entität (einem Objekt) können unterschiedlich sein. Betrachten wir die Haupttypen von Eigenschaften.

Eigentum kann sein plural-oder single -das heißt, ein Attribut, das eine Eigenschaft definiert, kann mehrere Werte gleichzeitig haben oder dementsprechend nur einen. Zum Beispiel kann ein Mitarbeiter mehrere Spezialitäten haben, aber die einzige Bedeutung ist "Personalnummer".

Eigentum kann sein einfach(unter dem Gesichtspunkt der angewandten Probleme nicht weiter unterteilt) oder verbund -wenn sein Wert aus einfachen Eigenschaftswerten besteht. Beispielsweise ist die Eigenschaft "Geburtsjahr" einfach und die Eigenschaft "Adresse" komplex, da sie die Werte der einfachen Eigenschaften "Stadt", "Straße", "Haus" enthält.

In einigen Fällen ist es nützlich zu unterscheiden basicund derivateeigenschaften. Ein Lieferant verfügt beispielsweise möglicherweise über die Eigenschaft Total Parts Supplied, die durch Summieren der Anzahl der von einem Projekt gelieferten Teile berechnet wird.

Wenn das Vorhandensein einer Eigenschaft für alle Instanzen einer Entität nicht erforderlich ist, wird eine solche Eigenschaft aufgerufen bedingt.Zum Beispiel haben nicht alle Mitarbeiter einen fortgeschrittenen Abschluss.

Eigenschaftswerte können konstant sein - statischoder dynamisch,das heißt, im Laufe der Zeit ändern. Beispielsweise ist die Eigenschaft "Personalnummer" statisch und die Eigenschaft "Adresse" dynamisch. Eigentum kann sein unsicher,wenn es dynamisch ist, aber noch nicht auf den aktuellen Wert eingestellt wurde.

Die Eigenschaft kann als gedacht werden schlüssel,wenn sein Wert eindeutig und möglicherweise in einem bestimmten Kontext ist, wird die Entität eindeutig identifiziert. Zum Beispiel ein Untergebener eines bestimmten Mitarbeiters.

Verbindungen.Zusätzlich zu Verknüpfungen zwischen einem Objekt und seinen Eigenschaften spiegelt das infologische Modell Verknüpfungen zwischen Objekten verschiedener Klassen wider. BEIM verbindungist definiert als "eine Assoziation, die mehrere Entitäten zusammenbringt". Diese Zuordnung kann immer zwischen verschiedenen Entitäten oder zwischen einer Entität und sich selbst bestehen (rekursive Beziehung).

Wie die Essenz ist eine Bindung typischkonzept, dh alle Instanzen der zu bindenden Entitäten befolgen die Regeln der Typbindung. Der prinzipielle Unterschied zwischen den Arten von Beziehungen zwischen Typen und Instanzen wird durch die in Abb. 1 gezeigten ER-Diagramme für Typen und Instanzen veranschaulicht. 5.5.

Die durch eine Verbindung verbundenen Entitäten werden aufgerufen teilnehmer. Kommunikationsgradwird durch die Anzahl der Kommunikationsteilnehmer bestimmt.

Wenn jede Instanz einer Entität an mindestens einer Instanz einer Beziehung teilnimmt, wird eine solche Beteiligung dieser Entität aufgerufen komplett(oder verpflichtend);sonst - unvollständig(oder optional).

Der quantitative Charakter der Beteiligung von Entitätsinstanzen (eine oder mehrere) wird festgelegt art der Verbindung(oder kommunikationskraft),Folgende Typen sind möglich: "eins zu eins"(1:1), Eins zu viele(1 M), Viele zu einem(M: 1), "Viel zu viel"(M: M).

Es ist zu beachten, dass das Link-Tool ein Mittel zur Darstellung ist komplexe Objekte,jedes davon kann als eine Reihe von in irgendeiner Weise miteinander verbundenen betrachtet werden einfache Objekte.Die Unterteilung in einfache und komplexe Objekte sowie die Art der Beziehung ist bedingt und wird durch die Besonderheiten der Analyse des Themenbereichs bestimmt, dh letztendlich durch die Art der Verwendung dieser Objekte bei den angewandten Problemen, die gelöst werden. Gleichzeitig ist das DETAIL beispielsweise aus Sicht eines Konstruktors ein komplexes Objekt und aus Sicht des Lieferanten einfach.

Unter den vielen Arten von Beziehungen sind Beziehungen eines hierarchischen Typs wie "Teil - Ganzes", "Gattung - Art" am häufigsten.

Die Teil-Ganz-Beziehung wird zur Darstellung verwendet zusammengesetzte Objekte.Zum Beispiel bestehen MASCHINEN aus TEILEN, EINHEITEN aus TEILEN. Hier sind beide Beziehungen möglich "Eins zu viele",so und Viel zu viel.

Gattung - Artenbeziehung - zu repräsentieren generische Objekte... Zum Beispiel werden MITARBEITER von Beruf in DESIGNER, PROGRAMMIERER, ARBEITNEHMER unterteilt. PROGRAMMIERER - auf ANGEWANDTEN PROGRAMMIERERN und SYSTEMPROGRAMMIERERN. Hierarchische Beziehungen und insbesondere "gattungsspezifisch" werden normalerweise als Grundlage für die Klassifizierung von Objekten nach Mengen charakteristischer Merkmale verwendet. Darüber hinaus sind die "Arten" Objekte erbeneigenschaften von "generisch".

Eine andere weit verbreitete Art von Beziehung ist die Aggregation, bei der einfache Objekte nach dem Prinzip ihrer Zugehörigkeit zu komplexen Objekten kombiniert werden. einheitoder ihre gemeinsame Teilnahme an einem Prozess. Die Aggregation, die hier als allgemeinerer Fall hierarchischer Beziehungen betrachtet wird, vereint Objekte unterschiedlicher Natur mit einer einzigen gemeinsamen Eigenschaft der "gemeinsamen Teilnahme". Aggregierte Objekte werden normalerweise mit verbalen Substantiven benannt, z. "Komposition":UNTERTEILUNG besteht ausANGESTELLTE; "Liefern":DER ZULIEFERER lieferungenEINZELHEITEN.

Supertypen und Subtypen.Eine Entität kann in zwei oder mehr sich gegenseitig ausschließende Einheiten aufgeteilt werden untertypen,jedes davon enthält gemeinsame Attribute und / oder Beziehungen. Diese gemeinsamen Attribute und / oder Beziehungen werden auf einer höheren Ebene einmal explizit definiert. Subtypen können ihre eigenen Attribute und / oder Beziehungen definieren. Grundsätzlich kann die Untertypisierung auf niedrigeren Ebenen fortgesetzt werden, in den meisten Fällen sind jedoch zwei oder drei Ebenen ausreichend.

Die Entität, auf deren Grundlage Subtypen definiert werden, wird aufgerufen supertyp.Subtypen müssen einen vollständigen Satz bilden, dh jede Instanz eines Supertyps muss zu einem Subtyp gehören. Manchmal ist es zur Vollständigkeit des Satzes erforderlich, einen zusätzlichen Untertyp zu definieren, z. B. ANDERE.

Ein Subtyp erbt Eigenschaften und Beziehungen von einem Supertyp. Zum Beispiel der Entitätstyp PROGRAMMIERERist ein Subtyp einer Entität MITARBEITER.Programmierer haben alle Eigenschaften von Mitarbeitern und nehmen an allen Beziehungen teil, aber das Gegenteil ist nicht der Fall.

Ein Entitätstyp, seine Untertypen, Untertypen dieser Untertypen usw. bilden sich entitätstyp-Hierarchie,ein Beispiel dafür ist in Abb. 5.6.

Beim eigentlichen Entwurf der Datenbankstruktur wird eine Methode verwendet - die sogenannte semantische Modellierung... Semantische Modellierung ist die Modellierung einer Datenstruktur basierend auf der Bedeutung dieser Daten. Als semantisches Modellierungswerkzeug werden verschiedene Optionen verwendet entity-Relationship-Diagramme(ER - Entity-Relationship).

Die erste Version des Entity-Relationship-Modells wurde 1976 von Peter Ping-Sheng Chen vorgeschlagen. Später entwickelten viele Autoren ihre eigenen Versionen solcher Modelle (Martin-Notation, IDEF1X-Notation, Barker-Notation usw.). Darüber hinaus verschiedene softwaredie dieselbe Notation implementieren, können sich in ihren Fähigkeiten unterscheiden. Tatsächlich basieren alle Varianten von Entity-Relationship-Diagrammen auf einer Idee - ein Bild ist immer klarer als eine Textbeschreibung. Alle diese Diagramme verwenden grafik Domänenentitäten, ihre Eigenschaften (Attribute) und Beziehungen zwischen Entitäten.

Wir werden die Arbeit mit ER-Diagrammen in der Nähe von Barkers Notation als ziemlich einfach beschreiben, um die Grundideen zu erfassen. Dieses Kapitel ist eher eine Illustration semantischer Modellierungstechniken als eine vollständige Einführung in diesen Bereich.

Grundlegende Konzepte von ER-Diagrammen

Definition 1: Die Essenzist eine Klasse von Objekten des gleichen Typs, deren Informationen im Modell berücksichtigt werden müssen.
Jede Entität muss ein Substantiv im Singular haben. Beispiele für Entitäten können Objektklassen wie "Lieferant", "Mitarbeiter", "Rechnung" sein. Jede Entität im Modell wird als Rechteck mit dem Namen dargestellt:

Zahl: 1

Definition 2: Entitätsinstanzist ein spezifischer Vertreter dieser Einheit.
Ein Vertreter der Entität "Mitarbeiter" kann beispielsweise "Mitarbeiter Ivanov" sein. Instanzen von Entitäten müssen unterscheidbar sein, d.h. Entitäten müssen einige Eigenschaften haben, die für jede Instanz dieser Entität eindeutig sind.

Definition 3: Entitätsattributist ein benanntes Merkmal, das eine Eigenschaft einer Entität ist.
Der Name des Attributs sollte im Singular Nomen ausgedrückt werden (möglicherweise mit charakterisierenden Adjektiven). Beispiele für Attribute der Entität "Mitarbeiter" können Attribute wie "Personalnummer", "Nachname", "Vorname", "Patronym", "Position", "Gehalt" usw. sein. Attribute werden innerhalb des entitätsdefinierenden Rechtecks \u200b\u200bgezeichnet:

Zahl: 2

Definition 4: Entitätsschlüsselist ein nicht redundanter Satz von Attributen, deren Werte für jede Instanz einer Entität kollektiv eindeutig sind. Die Nichtredundanz liegt in der Tatsache, dass das Entfernen eines Attributs aus einem Schlüssel dessen Eindeutigkeit verletzt. Eine Entität kann mehrere verschiedene Schlüssel haben. Die wichtigsten Attribute sind im Diagramm unterstrichen dargestellt:

Zahl: 3

Definition 5: Kommunikationist eine Art Assoziation zwischen zwei Entitäten. Eine Entität kann einer anderen Entität oder sich selbst zugeordnet werden.
Mithilfe von Beziehungen kann eine Entität andere damit verbundene Entitäten finden. Zum Beispiel können Beziehungen zwischen Entitäten durch die folgenden Ausdrücke ausgedrückt werden: "EIN MITARBEITER kann mehrere KINDER haben", "Jeder MITARBEITER muss in genau einer ABTEILUNG aufgeführt sein". Die Beziehung wird grafisch durch eine Linie dargestellt, die zwei Entitäten verbindet:

Zahl: 4

Jeder Link hat zwei Enden und einen oder zwei Namen. Der Name wird normalerweise in einer unbestimmten Verbform ausgedrückt: "haben", "gehören" usw. Jeder der Namen bezieht sich auf ein anderes Ende des Links. Manchmal werden Namen nicht geschrieben, weil sie offensichtlich sind.

Jeder Link kann einen der folgenden haben arten der Kommunikation:

Zahl: fünf

Verbindungstyp eins zu einsbedeutet, dass eine Instanz der ersten Entität (links) einer Instanz der zweiten Entität (rechts) zugeordnet ist. Eine Eins-zu-Eins-Beziehung zeigt meistens an, dass wir tatsächlich nur eine Entität haben, die fälschlicherweise in zwei geteilt ist.

Verbindungstyp eins zu vielebedeutet, dass eine Instanz der ersten Entität (links) mehreren Instanzen der zweiten Entität (rechts) zugeordnet ist. Dies ist die am häufigsten verwendete Art der Kommunikation. Die linke Entität (von der "einen" Seite) wird aufgerufen elternteil, rechts (von der Seite "viele") - tochtergesellschaft... Ein typisches Beispiel für eine solche Verbindung ist in Abb. 1 dargestellt. 4.

Verbindungstyp viel zu vielbedeutet, dass jede Instanz der ersten Entität mehreren Instanzen der zweiten Entität zugeordnet werden kann und jede Instanz der zweiten Entität mehreren Instanzen der ersten Entität zugeordnet werden kann. Ein Viele-zu-Viele-Beziehungstyp ist ein temporärer Beziehungstyp, der zu Beginn der Entwicklung eines Modells gültig ist. In Zukunft muss diese Art von Beziehung durch zwei Eins-zu-Viele-Beziehungen ersetzt werden, indem eine Zwischenentität erstellt wird.

Jede Bindung kann eine von zwei haben kommunikationsmodalitäten:

Zahl: 6

Modalität " kann"bedeutet, dass eine Instanz einer Entität einer oder mehreren Instanzen einer anderen Entität zugeordnet sein kann oder keiner Instanz zugeordnet sein darf.
Modalität " sollte"bedeutet, dass eine Instanz einer Entität mindestens einer Instanz einer anderen Entität zugeordnet sein muss.
Die Verbindung kann an verschiedenen Enden unterschiedliche Modalitäten aufweisen (wie in Abb. 4). Die beschriebene grafische Syntax ermöglicht das eindeutige Lesen von Diagrammen mit dem folgenden Phrasenkonstruktionsschema:

<Каждый экземпляр СУЩНОСТИ 1> <МОДАЛЬНОСТЬ СВЯЗИ> <НАИМЕНОВАНИЕ СВЯЗИ> <ТИП СВЯЗИ> <экземпляр СУЩНОСТИ 2>

Jeder Link kann von links nach rechts oder von rechts nach links gelesen werden. Der Link in Abb. 4 liest sich so:

Von links nach rechts: "Jeder Mitarbeiter kann mehrere Kinder haben."
Von rechts nach links: "Jedes Kind muss genau einem Mitarbeiter gehören."

Ein Beispiel für die Entwicklung eines einfachen ER-Modells

Bei der Entwicklung von ER-Modellen sollten wir folgende Informationen zum Themenbereich erhalten:

1. Liste der Domänenentitäten.
2. Liste der Entitätsattribute.
3. Beschreibung der Beziehungen zwischen Entitäten.

ER-Diagramme sind praktisch, da der Prozess der Identifizierung von Entitäten, Attributen und Beziehungen iterativ ist. Nachdem wir die erste ungefähre Version der Diagramme entwickelt haben, verfeinern wir sie durch Befragung von Fachexperten. In diesem Fall sind die Dokumentation, in der die Ergebnisse der Gespräche aufgezeichnet werden, die ER-Diagramme selbst.

Nehmen wir an, wir stehen vor der Aufgabe, ein Informationssystem zu entwickeln, das von einem Großhändler in Auftrag gegeben wurde. Zunächst müssen wir den Themenbereich und die darin ablaufenden Prozesse untersuchen. Dazu befragen wir die Mitarbeiter des Unternehmens, lesen die Dokumentation, studieren die Bestellformen, Rechnungen usw.

Während eines Gesprächs mit einem Verkaufsleiter stellte sich beispielsweise heraus, dass er (der Manager) der Ansicht ist, dass das projizierte System die folgenden Aktionen ausführen sollte:

• Kundeninformationen speichern.
• Drucken Sie Rechnungen für freigegebene Waren.
• Überwachen Sie die Verfügbarkeit von Waren im Lager.

Lassen Sie uns alle Substantive in diesen Sätzen auswählen - dies sind potenzielle Kandidaten für Entitäten und Attribute - und sie analysieren (wir werden unverständliche Begriffe mit einem Fragezeichen hervorheben):

• Der Käufer ist ein klarer Kandidat für das Unternehmen.
• Die Rechnung ist ein klarer Kandidat für ein Unternehmen.
• Produkt ist ein klarer Kandidat für Entität
• (?) Lager - Wie viele Lager hat das Unternehmen im Allgemeinen? Wenn es mehrere gibt, ist dies ein Kandidat für eine neue Entität.
• (?) Die Verfügbarkeit eines Produkts ist höchstwahrscheinlich ein Attribut, aber ein Attribut welcher Entität?

Es entsteht sofort eine offensichtliche Verbindung zwischen Unternehmen: "Käufer können viele Waren kaufen" und "Waren können an viele Käufer verkauft werden". Die erste Version des Diagramms sieht folgendermaßen aus:

Zahl: 7

Nachdem wir dem Manager zusätzliche Fragen gestellt hatten, stellten wir fest, dass das Unternehmen über mehrere Lager verfügt. Darüber hinaus kann jedes Produkt in mehreren Lagern gelagert und von jedem Lager aus verkauft werden.

Wo sollen die Entitäten "Rechnung" und "Lager" platziert und womit verknüpft werden? Fragen wir uns, in welcher Beziehung diese Entitäten zueinander und zu den Entitäten "Käufer" und "Produkt" stehen. Käufer kaufen Waren, während sie Rechnungen erhalten, die Daten über Menge und Preis der gekauften Waren enthalten. Jeder Kunde kann mehrere Lieferscheine erhalten. Jede Rechnung muss für einen Käufer ausgestellt werden. Jede Rechnung muss mehrere Waren enthalten (es gibt keine leeren Rechnungen). Jeder Artikel kann wiederum über mehrere Lieferscheine an mehrere Kunden verkauft werden. Darüber hinaus muss jede Rechnung von einem bestimmten Lager aus ausgestellt werden, und viele Rechnungen können von jedem Lager aus ausgestellt werden. Nach der Klarstellung sieht das Diagramm also folgendermaßen aus:

Zahl: 8

Es ist Zeit, über Entitätsattribute nachzudenken. Im Gespräch mit den Mitarbeitern des Unternehmens haben wir Folgendes herausgefunden:

• Jeder Käufer ist juristische Person und hat einen Namen, eine Adresse, Bankdaten.
• Jedes Produkt hat einen Namen, einen Preis und ist auch durch Maßeinheiten gekennzeichnet.
• Jeder Frachtbrief hat einzigartige Nummer, Datum der Abrechnung, Warenliste mit Mengen und Preisen sowie Gesamtrechnungsbetrag. Der Frachtbrief wird von einem bestimmten Lager und an einen bestimmten Kunden ausgestellt.
• Jedes Lager hat einen eigenen Namen.
• Schreiben wir noch einmal alle Substantive auf, die potenzielle Attribute sein werden, und analysieren sie:
• Juristische Person ist ein rhetorischer Begriff, mit dem wir nicht arbeiten einzelpersonen... Nicht aufpassen.
• Name des Käufers - explizite Eigenschaft Käufer.
• Die Adresse ist ein klares Merkmal des Käufers.
• Bankdaten sind ein klares Merkmal des Käufers.
• Der Name des Produkts ist ein klares Merkmal des Produkts.
• (?) Produktpreis - es sieht so aus, als ob dies ein Merkmal des Produkts ist. Unterscheidet sich diese Funktion vom Preis auf der Rechnung?
• Eine Maßeinheit ist ein explizites Merkmal eines Produkts.
• Die Rechnungsnummer ist ein eindeutiges Merkmal der Rechnung.
• Das Rechnungsdatum ist ein explizites Merkmal der Rechnung.
• (?) Warenliste in der Rechnung - Die Liste kann kein Attribut sein. Wahrscheinlich müssen Sie diese Liste in eine separate Entität aufteilen.
• (?) Die Menge der Waren in der Rechnung ist ein offensichtliches Merkmal, aber das Merkmal von was? Dies ist ein Merkmal nicht nur von "Waren", sondern von "Waren in der Rechnung".
• (?) Der Preis der Waren in der Rechnung - auch dies sollte nicht nur ein Merkmal der Waren sein, sondern auch die Merkmale der Waren in der Rechnung. Aber der Preis des Produkts wurde bereits höher erreicht - ist es das gleiche?
• Der Rechnungsbetrag ist ein explizites Merkmal der Rechnung. Diese Eigenschaft ist nicht unabhängig. Der Rechnungsbetrag entspricht der Summe der Werte aller in der Rechnung enthaltenen Waren.
• Der Name des Lagers ist ein explizites Merkmal des Lagers.

In einem zusätzlichen Gespräch mit dem Manager konnten verschiedene Preiskonzepte geklärt werden. Es stellte sich heraus, dass jedes Produkt einen bestimmten aktuellen Preis hat. Dies ist der Preis, zu dem der Artikel derzeit verkauft wird. Natürlich kann sich dieser Preis im Laufe der Zeit ändern. Der Preis desselben Produkts in verschiedenen Rechnungen, die zu unterschiedlichen Zeiten ausgestellt wurden, kann unterschiedlich sein. Somit gibt es zwei Preise - den Preis der Waren in der Rechnung und den aktuellen Preis der Waren.

Mit dem aufkommenden Konzept der "Liste der Waren in der Rechnung" ist alles ziemlich klar. Die Entitäten Rechnung und Produkt sind durch eine Viele-zu-Viele-Beziehung miteinander verbunden. Eine solche Beziehung muss, wie bereits erwähnt, in zwei Eins-zu-Viele-Beziehungen aufgeteilt werden. Dies erfordert eine zusätzliche Entität. Diese Entität ist die Entität "Liste der Waren in der Rechnung". Die Verbindung mit den Entitäten "Rechnung" und "Produkt" ist durch die folgenden Ausdrücke gekennzeichnet: "Jede Rechnung muss mehrere Einträge aus der Warenliste in der Rechnung enthalten", "jeder Eintrag aus der Warenliste in der Rechnung muss in genau einer Rechnung enthalten sein", "jedes Produkt kann enthalten sein In mehreren Datensätzen aus der Warenliste in der Rechnung "muss" jeder Datensatz aus der Warenliste in der Rechnung genau einem Artikel zugeordnet sein ". Die Attribute "Anzahl der Waren in der Rechnung" und "Preis der Waren in der Rechnung" sind Attribute der Entität "Liste der Waren in der Rechnung".

Machen wir dasselbe mit der Beziehung, die die Entitäten Warehouse und Product verbindet. Lassen Sie uns eine zusätzliche Entität "Waren auf Lager" einführen. Das Attribut dieser Entität ist "Menge der Waren auf Lager". Somit wird die Ware in jedem Lager aufgelistet und die Menge in jedem Lager ist unterschiedlich.

Jetzt können Sie all dies zum Diagramm hinzufügen:

Zahl: neun

Konzeptionelle und physikalische ER-Modelle

Das oben entwickelte ER-Diagrammbeispiel ist ein Beispiel konzeptdiagramm... Dies bedeutet, dass das Diagramm die Besonderheiten eines bestimmten DBMS nicht berücksichtigt. Aus diesem konzeptionellen Diagramm können Sie erstellen physikalisches Diagramm, die bereits Merkmale des DBMS wie zulässige Typen und Namen von Feldern und Tabellen, Integritätsbeschränkungen usw. berücksichtigen. Die physikalische Version des in Abb. 9 könnte so aussehen:

Zahl: zehn

In diesem Diagramm ist jede Entität eine Datenbanktabelle, jedes Attribut wird zu einer Spalte der entsprechenden Tabelle. Bitte beachten Sie, dass in vielen Tabellen, z. B. "CUST_DETAIL" und "PROD_IN_SKLAD", die den Entitäten "Rechnungslistensatz" und "Waren auf Lager" entsprechen, neue Attribute vorhanden sind, die nicht vorhanden waren konzeptmodell sind die Schlüsselattribute der übergeordneten Tabellen. migriertin untergeordnete Tabellen, um Verknüpfungen zwischen Tabellen über Fremdschlüssel bereitzustellen.

Es ist leicht zu erkennen, dass sich die resultierenden Tabellen sofort in 3NF befinden.

Schlussfolgerungen

Das eigentliche Werkzeug zur Datenmodellierung ist keine formale Methode zur Normalisierung von Beziehungen, sondern die sogenannte semantische Modellierung.

Als semantisches Modellierungswerkzeug werden verschiedene Optionen verwendet entity-Relationship-Diagramme(ER - Entity-Relationship).

Mit Entity-Relationship-Diagrammen können Sie visuelle grafische Symbole verwenden, um Entities und ihre Beziehungen zu modellieren.

Unterscheiden konzeptionellund physischER-Diagramme. Konzeptdiagramme berücksichtigen nicht die Besonderheiten bestimmter DBMS. Physikalische Diagramme basieren auf konzeptionellen Diagrammen und stellen den Prototyp einer bestimmten Datenbank dar. Im konzeptionellen Diagramm definierte Entitäten werden zu Tabellen, Attribute werden zu Tabellenspalten (dies berücksichtigt die Datentypen und Spaltennamen, die für das angegebene DBMS zulässig sind), Verknüpfungen werden von implementiert migrationenschlüsselattribute übergeordneter Entitäten und Erstellen von Fremdschlüsseln.

Mit der korrekten Definition von Entitäten werden die resultierenden Tabellen sofort in 3NF angezeigt. Der Hauptvorteil der Methode besteht darin, dass das Modell nach der Methode der sukzessiven Verfeinerung der Anfangsdiagramme erstellt wird.

In diesem Kapitel, in dem ER-Modellierungstechniken erläutert werden, werden die komplexeren Aspekte des Diagramms nicht behandelt, z. B. Untertypen, Ausschlussrollen, nicht tragbare Beziehungen, Identifizieren von Beziehungen usw.

Logisches Modell Die (intrinsischen) Daten sind eine unabhängige logische Darstellung von Daten.

Physikalisches Modell Die (tabellarischen) Daten enthalten Definitionen aller realisierbaren Objekte in einer bestimmten Datenbank für ein bestimmtes DBMS.

Modelle sind der Eckpfeiler des Designs. Ingenieure müssen ein Modellauto bauen, alle Details herausarbeiten, bevor sie es in Produktion bringen. Ebenso entwickeln Systemingenieure zunächst Modelle, um Geschäftslogik zu erlernen und die Struktur der Datenbank besser zu verstehen.

In der letzten Vorlesung haben wir die IDEF0- und DFD-Methoden kennengelernt, mit denen wir die im Informationssystem ablaufenden Geschäftsprozesse beschreiben können. Im DFD-Modell haben wir ein Element betrachtet - einen Datenspeicher, der die Arten von Informationen anzeigt, mit denen das System arbeitet. Diese Methode soll jedoch nicht die Struktur gespeicherter Informationen beschreiben. Hierfür eignen sich besser verschiedene Entity Relationship-Diagramme (Entity-Diagramme), deren Zweck darin besteht, die Struktur der gespeicherten Daten und die Beziehungen zwischen ihnen zu beschreiben. Es wurden Techniken entwickelt, mit denen solche Daten in eine Reihe von Befehlen umgewandelt werden können, mit denen die erforderlichen Speicher (Tabellen) in der Datenbank des Informationssystems erstellt werden.

ER-Modellierung

BEIM informationssystemeah, die Daten sind in verschiedene Kategorien oder Entitäten unterteilt. Schließlich erinnern wir uns, dass eine Datenbank eine Reihe strukturierter Daten ist. Daten verschiedene Typen separat gelagert. Die Aufgabe des ER-Modells ist es zu zeigen, welche Arten von Informationen im System gespeichert sind, wie sie aufgebaut sind und wie sie miteinander verbunden sind. Das ER-Modell basiert auf der durchgeführten Geschäftsanalyse (erstelltes DF-Diagramm). Gleichzeitig wird zunächst jeder Speicher im DF-Diagramm zu einer Entität im ER-Diagramm. Im Zuge der weiteren Analyse können sie in Bestandteile aufgeteilt werden. Es ist erwähnenswert, dass ER-Modelle gegenüber Änderungen in der Geschäftsstruktur widerstandsfähiger sind als DF-Diagramme. Geschäftsprozesse können sich ändern, aber die Informationen, die für ihre Implementierung benötigt werden, bleiben häufig gleich.

Die Hauptvorteile von ER-Modellen:

• Ein genaues und verständliches Format zur Dokumentation der Informationsstruktur.
• Hier können Sie die Anforderungen für Daten und die Beziehungen zwischen ihnen angeben.
• Ermöglicht die visuelle Darstellung der Struktur des Repositorys, um das Datenbankdesign zu vereinfachen.
• Es gibt Methoden zum Zuordnen von ER-Modellen zu Datenbanktabellen und umgekehrt.
• Legen Sie den Grundstein für die Integration in andere Anwendungen.

Die wichtigsten Objekttypen im ER-Diagramm:

• Entität - die Art der Objekte, deren Informationen in der Datenbank gespeichert werden. Zum Beispiel: Abteilungen, Mitarbeiter, Waren, Rechnungen.
• Attribut - die Elemente, aus denen die Entität besteht. Beispielsweise können für die Entität "Waren" Attribute "Name", "Beschreibung", "Menge", "Preis" und andere sein, abhängig von den Anforderungen des Informationssystems. Abhängig von der Notation des ER-Diagramms geben Sie neben dem Attribut zusätzlich zu seinem Namen den Typ und die erforderliche Füllung an. Die Folie zeigt ein ER-Diagramm in Information Engineering-Notation, nach dem das Attribut einen Namen, einen Typ und einen externen und / oder primären Aufruf erhält.
• Beziehungen zeigen Beziehungen zwischen Entitäten. Ein Mitarbeiter arbeitet beispielsweise in einer Abteilung, in der "Abteilung" und "Abteilung" Entitäten sind.

Eine Entität ist eine Reihe von Objekten der realen Welt, von denen jedes die folgenden Eigenschaften aufweist:

• Einzigartig (kann auf irgendeine Weise von allen anderen getrennt werden)
• Spielen eine bestimmte Rolle im simulierten System
• Kann durch ein oder mehrere Informationselemente (Attribute) beschrieben werden

Beispiel: Personen, Mitarbeiter, Veranstaltungen, Bestellungen, Verkäufe, Kunden, Lieferanten

Das Attribut beschreibt einige der Eigenschaften der Entität. Eine Entität kann viele Attribute haben, aber nur diejenigen, die für das System wichtig sind, werden ausgewählt. Attribute werden in Schlüssel (Entity Keys) und beschreibende (Entity Descriptors) unterteilt. Schlüsselattribute müssen Entitätsinstanzen eindeutig identifizieren. Für jedes Attribut muss eine Domäne (Typ, Themenbereich) angegeben werden.

Die Folie zeigt, wie Entitäten und Attribute in verschiedenen ER-Modellnotationen geschrieben werden. In allen Notationen ist eine Entität ein rechteckiges Objekt mit dem Entitätsnamen oben. Die Attribute werden unter dem Entitätsnamen aufgelistet.

Schauen wir uns die wichtigsten Attribute genauer an. Dies ist wichtig, um die Arten von Beziehungen zwischen Entitäten zu verstehen.

Grundbegriffe

Das relationale Modell kann, falls erforderlich, in mathematischer Sprache beschrieben werden, dh in dem genauesten, das der Mensch erfunden hat. Nachfolgend finden Sie lose Definitionen einiger Konzepte im relationalen Modell.

• "Datentyp" (Typ, domean - domain) ist eine Reihe zulässiger Werte ("scope") und Operationen. Es gibt Vergleichs- und Zuweisungsoperationen für alle Typen. Es ist Mengen nicht untersagt, beispielsweise eine Struktur eines Objekts zu haben.
• "Relation" (Relation) - eine Reihe von Attributen: eindeutige Namen mit Angabe des Datentyps; plus viele "Wertesätze" ("Zeilen"), die den Attributen entsprechen. Die Werte in den Mengen können nur durch einzelne Werte der Typen dargestellt werden, die den Attributen entsprechen, dh sie können Skalare sein ("1. Normalform").
• "Schlüssel" (Schlüssel) - eine Gruppe von Attributen, deren Werte sich in allen Mengen in Bezug auf unterscheiden, aber keine der Untergruppen dieser Attribute besitzt bereits eine solche Eigenschaft (die Eigenschaft der "Minimalität" des Schlüssels). Insbesondere kann eine Gruppe aus einem einzelnen Attribut bestehen. Es muss immer einen Schlüssel in einer Beziehung geben, und wenn es mehrere davon gibt, muss einem von ihnen "primär" zugewiesen werden.
• "Fremdschlüssel" ist eine Gruppe von Attributen, deren Werte in jedem Wertesatz der Beziehung mit den Werten des Schlüssels einer möglicherweise anderen Beziehung übereinstimmen müssen. Fremdschlüssel in einer Beziehung sind optional und werden für Modellierungsanforderungen angekündigt.
• "Operationen" (Operation) - eine Reihe allgemeiner Aktionen für Beziehungen, die wiederum zu einer Beziehung führen ("geschlossene Operationen"). Sie werden verwendet, um neue Beziehungen in den Anforderungen der nachfolgenden Modellierung oder beim Extrahieren der erforderlichen Daten aus der Datenbank zu erhalten. Die Liste der Operationen kann auf verschiedene Arten definiert werden. In den ersten Sätzen des Modells wurden acht Operationen (Projektion, Verbinden, Auswählen usw.) als Kompromiss zwischen fehlender Redundanz und Benutzerfreundlichkeit angegeben, die keine minimale Menge mehr sind.
• " Relationale Datenbank" (relationale Datenbank) - eine Reihe von Beziehungen.

Der "Datentyp" wird manchmal als "Domäne" bezeichnet, manchmal ist die "Domäne" nur der "Umfang" der Mengen. "Eine Reihe von Werten" (Tupel) auf Russisch wird auch als "Tupel" oder "n-koy" bezeichnet.

Der Einfachheit halber werden Beziehungen häufig in Form von Tabellen dargestellt, obwohl eine solche Darstellung unzulässig ist (in der Beziehung ist im Gegensatz zu einer Tabelle weder die Reihenfolge der Attribute noch die Reihenfolge der Wertesätze definiert). In SQL, auf dessen Grundlage das Oracle DBMS erstellt wird, wurde das Konzept der "Beziehungen" als Modellierungswerkzeug durch "Tabelle" ersetzt. Eine andere Darstellung der Beziehungsdaten kann ein Hypercube sein, und es ist manchmal auch zweckmäßig, sie zu verwenden, wenn über die vorhandene Datenbank nachgedacht wird.

Wenn wir das definitive Verfolgungswort "relational" aufgeben, kann der Begriff "relationale DB" als "DB der Beziehungen" übersetzt werden (genauer gesagt "DB erstellt" durch Beziehungen "; Beziehungen als Werkzeug, nicht als Objekt der Modellierung: andernfalls wäre der ursprüngliche Begriff eine Beziehungsdatenbank. In ähnlicher Weise kann der Begriff" relationales Modell "als" Beziehungsmodell "übersetzt werden, dh als" System von Konzepten zum Aufbau eines Beziehungen. "Aus einer Reihe von Gründen, einschließlich der historischen und sprachlichen Natur, wurde dies nicht auf einmal getan.

Alle Datenbeziehungen werden beschrieben deutlich und nur Werte in Mengen (in anderen Ansätzen zur Modellierung können sie unterschiedlich sein). Es gibt keine "impliziten" Abhängigkeiten (auch auf der Ebene der Programmlogik), mit Ausnahme der durch die Variablen formulierten Beziehungen. Der relationale Ansatz unterscheidet zwischen der Beschreibung der Daten und der der Anwendung beiliegenden Programmlogik (im Gegensatz zum Beispiel zum Objektansatz).

Die gegebene Ansicht einer relationalen Datenbank (eine Reihe von Beziehungen und Operationen) ist typisch für relationale Algebra... Dies ist nicht der einzige Gesichtspunkt. Jeder Satz von Mengen in einer Beziehungsvariablen kann als wahre Aussage ("Prädikat") verstanden werden: Es gibt einen solchen und einen solchen Mitarbeiter mit solchen und solchen Eigenschaften; so und so eine Abteilung und so weiter. Somit ist eine relationale Datenbank zu jedem Zeitpunkt eine Reihe wahrer Aussagen über den Themenbereich, die durch Beziehungen formuliert werden. Tatsächlich bildet eine Reihe von Anweisungen in Variablen von Beziehungen das Modell des von der Datenbank dargestellten Themenbereichs. Diese Ansicht einer relationalen Datenbank ist typisch für beziehungsrechnung... Beide Ansichten des relationalen Modells wurden gut untersucht und es wurde gezeigt, dass sie ausdrücklich gleichwertig sind.

Es gibt informelle Entsprechungen für die auf der vorherigen Folie aufgeführten Begriffe, um das Verständnis und die Erinnerung an ihre Bedeutung zu erleichtern:

• Verhältnis -\u003e Tabelle
• Tupel -\u003e String, aufnehmen
• Kardinalität -\u003e Anzahl der Zeilen
• Attribut -\u003e Spalte, Feld
• Grad -\u003e Anzahl der Spalten
• Primärschlüssel -\u003e Id
• Domain -\u003e Gültiger Bereich

Schlüsselfelder

Einige der Attribute einer Beziehung sind Schlüssel oder Schlüssel. Es gibt verschiedene Arten von Schlüsseln:

• Ein einfacher Schlüssel besteht aus einem Attribut, ein zusammengesetzter Schlüssel aus mehreren.
• Möglicher Schlüssel - ein Attribut oder eine Reihe von Attributen, die jedes der Beziehungstupel identifizieren können. Zum Beispiel in Bezug auf das Passamt ("Passnummer") und ("Vollständiger Name" und "Geburtsdatum") - potenzielle Schlüssel, mit denen Sie jede Person eindeutig identifizieren können.
• Jede Beziehung kann nur einen Primärschlüssel haben - ein Attribut oder eine Reihe von Attributen, deren Werte jeden Datensatz eindeutig identifizieren. Wenn mehrere Sätze von Attributen solche Eigenschaften haben, wird einer von ihnen als primär und alle anderen als Alternative ausgewählt.
• Fremdschlüssel - Geschäfte wert der Primärschlüssel einer anderen Beziehung. Fremdschlüssel werden zur Kommunikation zwischen Beziehungen verwendet.

Primärschlüssel

• Jede relationale Beziehung hat nur einen Primärschlüssel, alle anderen sind Alternativen.
• Der Wert aller Attribute des Primärschlüssels nicht kann sein nicht definiert. In einer Beziehung werden beispielsweise Informationen zu den Einwohnern einer Stadt gespeichert. Primärschlüssel - zusammengesetzt (NAME, NACHNAME, Geburtsdatum). Das Informationssystem wurde in Island installiert, wo keine Nachnamen verwendet werden. Dies bedeutet, dass das Attribut "Nachname" für die meisten Tupel leer ist. Trotzdem identifiziert der zusammengesetzte Primärschlüssel weiterhin jedes der Tupel eindeutig. Es ist jedoch nicht akzeptabel, dass alle Primärschlüsselattribute gleichzeitig leer sind.
• Der Primärschlüsselwert hat keinen Einfluss auf die Anordnung der Tupel in der Tabellenansicht der Beziehung. Selbst wenn der Primärschlüsselwert eine Zahl ist (z. B. 1,2,3 ...), garantiert dies im allgemeinen Fall nicht, dass Tupel in der Datenbank in derselben Reihenfolge gespeichert und in derselben Reihenfolge angezeigt werden. Im Allgemeinen bedeutet dies, dass manchmal aufgrund der Besonderheiten eines bestimmten DBMS Zeilen nach Primärschlüssel sortiert gespeichert werden können, dies ist jedoch eher eine Ausnahme. Bei der Ausgabe der Ergebnisse einer Abfrage müssen wir explizit die Reihenfolge angeben, in der die Zeilen ausgegeben werden sollen, wenn eine solche Reihenfolge wichtig ist. Die Ergebnisse der Abfrage "Gib mir die ersten 5 Personen" sind unvorhersehbar, wenn wir nicht angeben, nach welchem \u200b\u200bKriterium sie "zuerst" sein sollen.
• Der Primärschlüssel hat keinen Einfluss auf den Zugriff auf die Attribute des Tupels. In Bezug auf "Passamt" wird beispielsweise die Registrierungsadresse der Person zusammen mit dem Namen und dem Geburtsdatum gespeichert. Wir können die Datenbank bitten, alle Adressen zu extrahieren, ohne den vollständigen Namen und das Geburtsdatum zu kennen.

Externer Schlüssel

Ein Fremdschlüssel wird verwendet, um Verknüpfungen zwischen Beziehungen herzustellen. Nehmen wir zum Beispiel zwei Beziehungen "Eigentümer" (Primärschlüssel "Passnummer") und "Immobilien". Um festzustellen, wem die einzelnen Eigenschaften gehören, verknüpfen wir diese Beziehungen mit dem Wert des Attributs "Passnummer". Im Gegensatz zum Primärschlüssel kann der Fremdschlüsselwert undefiniert sein (Zeile 4 auf der Folie). Wenn wir den Eigentümer der Eigenschaft nicht kennen, geben wir ihn nicht an. Im Gegensatz zum Primärschlüssel kann der Fremdschlüsselwert wiederholt werden (Zeilen 1,3 auf der Folie) - ein Eigentümer kann mehrere Immobilienobjekte haben. Die Tatsache, dass das Attribut "Passnummer" in der Beziehung "Eigenschaft" ein Fremdschlüssel zum Primärschlüssel der Beziehung "Eigentümer" ist, garantiert jedoch, dass der Wert des Attributs "Pastorennummer" nur Werte aus dem Primärschlüssel sein kann. Wir können nicht als Attributwert die Pastorennummer einer Person angeben, die noch nicht in der Eigentümerbeziehung existiert (Zeile 5).

Durch Festlegen eines Fremdschlüssels können Sie das Verhalten des DBMS explizit festlegen, wenn Sie den Wert des Primärschlüssels ändern oder ein Tupel löschen. Die Regel "Es werden jedoch nur Werte im Fremdschlüssel gespeichert, die sich im Primärschlüssel befinden, oder ein undefinierter Wert (NULL)".

Beim Entwerfen einer Datenbank wird normalerweise ein Fremdschlüssel zwischen Beziehungen angegeben. Es kann jedoch jederzeit entfernt oder neu installiert werden, wenn das Hinzufügen dieser Einschränkung den Fremdschlüsseleigenschaften nicht widerspricht. Das Entfernen / Festlegen von Fremdschlüsseln erfolgt normalerweise beim Einfügen sehr großer Datenmengen, um diesen Prozess zu beschleunigen. Das DBMS kann keine inkonsistenten (falschen, fehlerhaften) Daten speichern und überprüft daher beim Einfügen jeder Zeile jede Einschränkung.

ER-Modelle: Verbindungen

In ER-Modellen werden Fremdschlüssel als Beziehungen angezeigt.

Jede Verbindung ist durch 4 Eigenschaften gekennzeichnet - Stärke, Kraft, Grad und Beteiligung der Entität an der Verbindung.

Werfen wir einen Blick auf diese Eigenschaften.

Entitätsbeteiligung an einer Beziehung

Es wird auf der Verbindung durch eine Querlinie oder einen Kreis angezeigt.

Kreuzlinie bedeutet obligatorisch (verpflichtend) Beteiligung des Unternehmens an der Verbindung und des Kreises - optional (optional).

Im Falle der obligatorischen Teilnahme eines Unternehmens an einer Beziehung wird das Verb " sollte". Bei optionaler Teilnahme verwendet die Entität das Verb" kann".

In der Abteilung kann Mehrere Mitarbeiter arbeiten. Mitarbeiter sollte arbeiten in einer der Abteilungen.

Der Grad der Verbindung ( beziehung grad) gibt die Anzahl der zugeordneten Entitäten an... Binäre Verbindung ( binär beziehung) beschreibt die Assoziationen zweier Entitäten. Ternäre Verbindung (ternär beziehung) tritt auf, wenn drei Entitäten verknüpft sind. Unäre Bindung (einstellig beziehung) beschreibt Assoziationen innerhalb einer einzelnen Entität.

Am häufigsten sind binäre Links - sie verbinden zwei verschiedene Einheiten ("Abteilung" - "Mitarbeiter", "Bestellung" - "Produkte", "Kurs" - "Vorlesungen", "Gruppe" - "Studenten"). Weniger verbreitet, aber immer noch häufig verwendet, sind unäre Bindungen. Sie werden normalerweise verwendet, um die Verschachtelungsrelation für Objekte desselben Typs festzulegen (die Relation "Details" - wir können angeben teil von Was für ein Detail ist das, die Beziehung "Mitarbeiter" - wir können angeben, welcher der Mitarbeiter der Chef dafür ist).

Die Kardinalität einer Beziehung gibt an, wie viele Instanzen einer Entität Instanzen einer anderen Entität zugeordnet sind.

Macht kann sein:

• eins zu eins (1: 1) - In einer Gruppe von Studenten gibt es einen Schulleiter.
• eins zu viele (1: N) - viele Mitarbeiter arbeiten in einer Abteilung;
• viel zu viel (M: N) - Ein Kunde hat viele Produkte gekauft, viele Kunden haben Produkte gekauft.

Beziehungsstärke: Identifizieren der Beziehung

Eine untergeordnete Entität kann ohne ein übergeordnetes Element nicht existieren. (Es gibt keine Antwort ohne Frage; es befindet sich kein Produkt im Warenkorb des Benutzers, wenn der Warenkorb selbst nicht vorhanden ist.)

In diesem Fall wird der Primärschlüssel von der übergeordneten Entität zur untergeordneten Entität migriert, wo er Teil des Primärschlüssels wird.

Im Diagramm wird eine starke Verbindung als durchgehende Linie zwischen Entitäten angezeigt.

Verbindungsstärke: Nicht identifizierende Beziehung

Das Elternteil und das Kind sind verwandt, aber das Kind kann früher erstellt werden. (Die Ladung gehört zur Bestellung, die Ladung befindet sich jedoch möglicherweise im Lager, bevor die Bestellung erstellt wird.)

Der Primärschlüssel wird von der übergeordneten Entität zur untergeordneten Entität migriert und ist nicht Teil des Primärschlüssels (er wird nur zu einem Fremdschlüssel).

Im Diagramm ist eine starke Beziehung mit einer gestrichelten Linie zwischen Entitäten dargestellt.

Rekursiver Link (unärer Link)

Wird am häufigsten zum Erstellen von Hierarchien verwendet.

Der Lieferant kann mit NULL oder MEHR Kunden (id_Customer) arbeiten.

Der Kunde MUSS mit einem Lieferanten zusammenarbeiten (id_Sup).

Der Lieferant und der Kunde - dies ist eine Firma oder eine Organisation - sind jedoch Objekte des gleichen Typs und werden daher in derselben Beziehung gespeichert.

Viele-zu-viele-Beziehung.

Beispiel: Lieferanten können viele Arten von Waren liefern. Verschiedene Lieferanten können die gleichen Arten von Waren liefern.

Viele-zu-viele-Beziehungen sind im Hinblick auf das ER-Modell gültig, können jedoch nicht direkt in Bezug auf die relationale Algebra widergespiegelt werden.

Die Mehrdeutigkeit der Beziehung wird durch die Einführung vorübergehender Entitäten behoben, wie auf der Folie gezeigt.

ER-Modelle und Realität

Bei näherer Betrachtung einer Eins-zu-Eins-Beziehung stellt sich fast immer heraus, dass A und B tatsächlich unterschiedliche Teilmengen derselben Sache oder unterschiedliche Sichtweisen sind, nur unterschiedliche Namen und unterschiedlich beschriebene Beziehungen und Attribute.

Stellen wir uns vor, A ist ein Lieferant, B ist ein Produkt.

Obligatorisch-obligatorisch.Für das auf der Folie gezeigte Beispiel bedeutet diese Beziehung, dass jeder Lieferant sollte liefern nur eine einzigartig Warensatz (Rechnung). Aus theoretischer Sicht ist hier alles in Ordnung. In der Praxis ist dies nicht zulässig: Niemand wird nach einem neuen Lieferanten suchen, wenn der von Ihnen überprüfte Lieferant mehrere Waren liefern kann. Und nun zu den Emotionen, die der Bediener erleben wird, wenn er versucht, Daten über einen neuen Lieferanten einzugeben. Er kann keine Daten in eine der Tabellen eingeben. So wird das gesamte Gepäck der obszönen Sprache an Ihre Adresse gesendet.

Optional-obligatorisch. Ein Beispiel für eine Verbindung ist auf der Folie dargestellt. Wie Sie sehen, geht es dem Bediener jetzt gut: Er kann Daten eingeben. Das Unternehmen hat erneut ein Problem: Es muss nach einem neuen Lieferanten suchen, auch wenn der von Ihnen überprüfte Lieferant möglicherweise mehrere Waren liefert. Braucht das Geschäft Probleme? Nein. Es muss funktionieren. Wie kann man das Geschäft befriedigen? Die Antwort ist einfach. Beim Entwerfen einer Datenbank müssen Sie über die Normalisierung nachdenken. Wenn der Lieferant eine Entität ist, verwenden Sie Links vom Typ optional-obligatorisch (obligatorisch-optional) oder optional-optional. Meistens sind Eins-zu-eins-Beziehungen ein Fehler.

Optional-optional. Wie Sie sehen, geht es dem Betreiber wieder gut, aber das Geschäft hat wieder ein Problem. Lassen Sie uns für eine Eins-zu-Eins-Beziehung zusammenfassen. Wenn Unternehmen an einer Verbindung teilnehmen als: - obligatorisch-obligatorisch, hat eine solche Verbindung kein Recht auf Leben; - optional-obligatorisch (obligatorisch-optional) oder optional-optional, dann ist der geschäftliche Support problematisch.

Eine Eins-zu-Viele-Beziehung zwischen Pflicht und Pflicht ist ein ziemlich starkes Konstrukt, bei dem davon ausgegangen wird, dass ein Vorkommen der Entität B nicht erstellt werden kann, ohne gleichzeitig mindestens ein zugehöriges Vorkommen einer Entität A zu erstellen. Dies ist meistens eine falsche Beziehung.

Eine Eins-zu-Viele-Beziehung zwischen obligatorisch und optional ist die häufigste Form der Kommunikation. Es wird davon ausgegangen, dass jedes Vorkommen von Entität A nur im Zusammenhang mit einem (und nur einem) Vorkommen von Entität B existieren kann. Das Vorkommen von B kann wiederum sowohl im Zusammenhang mit Vorkommen von A als auch ohne dieses Vorkommen existieren.

Eins-zu-viele-Beziehung optional-optional - Sowohl A als auch B können ohne Beziehung zwischen ihnen existieren.

In Bezug auf die vorherige Folie können diese Diagramme anhand der folgenden Beispiele veranschaulicht werden.

Eins-zu-viele-Beziehungen. Diese Beziehungen setzen voraus, dass ein Datensatz in einer Tabelle logisch mit mehreren Datensätzen in einer anderen Tabelle verknüpft werden kann.

Obligatorisch-obligatorisch.Für das auf der Folie gezeigte Beispiel bedeutet diese Beziehung, dass jeder Lieferant (A) einen oder mehrere Warensätze (B) liefern muss. Aus theoretischer Sicht ist hier alles in Ordnung. In der Praxis kann der Bediener jedoch keine Daten in eine der Tabellen eingeben, da Datensätze erforderlich sind gleichzeitig in beide Tabellen eingeben.

Optional-obligatorisch.In diesem Fall geht es dem Bediener jetzt gut: Er kann Daten eingeben, aber das Unternehmen kann Probleme haben. Der Punkt ist, dass die optional-obligatorische Beziehung davon ausgeht, dass der Anbieter (A) sollte einen oder mehrere Warensätze (B) liefern, während B. kann gehören dem Lieferanten. Mit anderen Worten, Waren können ohne einen Lieferanten existieren, während ein Lieferant Waren hat. Jene. Mögliches unkontrolliertes Geschäftsverhalten: Wer hat die Ware geliefert? Wen soll man fragen? Braucht das Geschäft Probleme? Nein. Er muss profitabel sein. In diesem Fall ist es besser, obligatorisch-optional zu verwenden: Der Lieferant kann einen oder mehrere Warensätze liefern, während die Ware dem Lieferanten gehören muss. Mit anderen Worten, das Produkt hat einen Lieferanten, und die Daten über die Lieferanten, die das Produkt einmal geliefert haben, werden gespeichert. Und die Schafe sind in Sicherheit und die Wölfe sind voll - der Bediener kann Daten eingeben und der Geschäftsmann ist beschäftigt.

Optional-optional.Wie wir sehen können, ist für den Betreiber alles in Ordnung, aber das Unternehmen hat ein Problem - mangelnde Kontrolle: Ein Produkt kann ohne Lieferanten und ein Lieferant ohne Produkt existieren.
Lassen Sie uns die Eins-zu-Viele-Beziehung zusammenfassen. Wenn Unternehmen an einer Beziehung teilnehmen als: - obligatorisch-obligatorisch, hat eine solche Beziehung kein Recht auf Leben, da es unmöglich ist, Datensätze gleichzeitig in beide Tabellen einzutragen; - optional-optional, dann ist der Business-Support problematisch.

Viele-zu-viele-Beziehungen sind in ER-Diagrammen akzeptabel. Bei der Konvertierung in eine Tabellenansicht wird die Beziehung jedoch durch eine Zwischenentität ersetzt.

Viele-zu-viele obligatorisch-obligatorisch - diese Konstruktion tritt häufig zu Beginn der Analysephase auf und bedeutet eine Beziehung - entweder nicht vollständig verstanden und erfordert eine zusätzliche Erlaubnis oder spiegelt eine einfache kollektive Beziehung wider - eine bidirektionale Liste.

Viele-zu-viele obligatorisch-optional - selten verwendet. Solche Links unterliegen immer weiteren Einzelheiten.

Rekursive Links. Diese Beziehungen setzen voraus, dass die Datensätze in der Tabelle logisch verknüpft werden können.

Optional-optional eins zu eins. Für das auf der Folie gezeigte Beispiel bedeutet diese Beziehung, dass jeder Mann (Frau) mit einer Frau (Mann) verheiratet sein kann. Diese Verbindung ist praktisch, um die Geschichte der Ehepartner zu verfolgen: Zum ersten Mal wieder ... Mit anderen Worten, eine alternative Art von Beziehung.

Optional-optional eins zu viele. Ein Beispiel für eine Verbindung ist auf der Folie dargestellt. Dies ist eine klassische Hierarchie (Baumstruktur). Die auf der Folie gezeigte Beziehung kann beispielsweise wie folgt interpretiert werden: Jeder Mitarbeiter kann nur einem Manager untergeordnet sein, während ein Manager einen oder mehrere Mitarbeiter verwalten kann.

Optional-optional M: M. Ein Beispiel für die Kommunikation ist in Folie 3 dargestellt. Dies ist eine Netzwerkstruktur.

Entitäts-Checkliste

• Entspricht der Name der Entität der Essenz dieses Objekts?
• Gibt es keinen Schnittpunkt mit anderen Entitäten?
• Gibt es mindestens zwei Attribute?
• Nicht mehr als acht Attribute insgesamt?
• Gibt es Synonyme / Homonyme für diese Entität?
• Ist die Entität vollständig definiert?
• Gibt es eine eindeutige Kennung?
• Gibt es mindestens eine Verbindung?
• Gibt es mindestens eine Funktion zum Erstellen, Suchen, Anpassen, Löschen, Archivieren und Verwenden eines Entitätswerts?
• Gibt es eine Geschichte von Veränderungen?
• Gibt es eine Übereinstimmung mit den Grundsätzen der Datennormalisierung?
• Gibt es nicht dieselbe Entität in einem anderen Anwendungssystem, möglicherweise unter einem anderen Namen?
• Ist die Essenz zu allgemein?
• Ist der darin enthaltene Verallgemeinerungsgrad ausreichend?

Attribut-Checkliste:

• Ist der Name des Attributs ein singuläres Substantiv, das die Essenz der durch das Attribut angegebenen Eigenschaft widerspiegelt?
• Enthält der Attributname nicht den Namen der Entität (sollte es nicht sein)?
• Hat das Attribut jeweils nur einen Wert?
• Fehlen doppelte Werte (oder Gruppen)?
• Sind das Format, die Länge, zulässige Werte, Algorithmus usw. erhalten?
• Könnte dieses Attribut eine fehlende Entität sein, die für ein anderes Anwendungssystem (bereits vorhanden oder vorgeschlagen) nützlich wäre?
• Könnte es eine verpasste Verbindung sein?
• Gibt es irgendwo einen Verweis auf das Attribut als "Projektfunktion", der verschwinden sollte, wenn Sie zur Anwendungsebene wechseln?
• Ist eine Änderungshistorie erforderlich?
• Hängt seine Bedeutung nur von einer bestimmten Entität ab?
• Wenn ein Attributwert erforderlich ist, ist er immer bekannt?
• Muss für dieses und ähnliche Attribute eine Domain erstellt werden?
• Hängt seine Bedeutung nur von einem Teil der eindeutigen Kennung ab?
• Hängt sein Wert von den Werten einiger Attribute ab, die nicht in der eindeutigen Kennung enthalten sind?

Das Entity-Attribut-Relationship-Modell wurde 1976 von Peter Ping-Shen Chenov vorgeschlagen moderne Ansätze zum Entwurf von Datenbanken (hauptsächlich relational). Die Domänenmodellierung basiert auf der Verwendung grafischer Diagramme, die eine kleine Anzahl unterschiedlicher Komponenten enthalten. Aufgrund der visuellen Darstellung konzeptioneller Datenbankschemata werden ER-Modelle häufig in CASE-Systemen verwendet, die den automatisierten Entwurf relationaler Datenbanken unterstützen.

Die Grundkonzepte des ER-Modells sind Entität, Attribut und Beziehung.

Die Essenz Ist ein reales oder imaginäres Objekt, dessen Informationen von Interesse sind. In ER-Modelldiagrammen wird eine Entität als Rechteck dargestellt, das den Entitätsnamen enthält. In diesem Fall ist der Name der Entität der Name des Typs und nicht eines bestimmten Objekts - einer Instanz dieses Typs. Jede Instanz einer Entität muss von jeder anderen Instanz derselben Entität unterscheidbar sein.

Eine Beziehung ist eine grafische Zuordnung zwischen zwei Entitäten. Diese Zuordnung ist immer binär und kann zwischen zwei verschiedenen Entitäten oder zwischen einer Entität und sich selbst bestehen (rekursive Beziehung). In jeder Beziehung werden zwei Enden unterschieden (gemäß einem Paar assoziierter Entitäten), von denen jedes den Namen des Endes der Beziehung, den Grad des Endes der Beziehung (wie viele Instanzen dieser Entität verbunden sind), die obligatorische Beziehung (d. H. Ob eine Instanz dieser Entität teilnehmen sollte) angibt diese Verbindung).

Die Verbindung wird als eine Linie dargestellt, die zwei Entitäten verbindet oder von einer Entität zu sich selbst führt. Gleichzeitig wird an dem Punkt, an dem die Verbindung mit der Entität „angedockt“ ist, ein Dreipunkteintrag in das Entitätsrechteck verwendet, wenn viele Instanzen der Entität für diese Entität in der Verbindung verwendet werden können, und ein Einzelpunkteintrag, wenn nur eine Entitätsinstanz an der Verbindung teilnehmen kann. Das erforderliche Ende der Verknüpfung wird mit einer durchgezogenen Linie und das optionale Ende mit einer gestrichelten Linie angezeigt.

Wie eine Entität ist eine Beziehung ein typisches Konzept. Alle Instanzen beider Entitätspaare, die verknüpft sind, unterliegen den Assoziationsregeln. In Abb. 1. zeigt ein Beispiel für Bilder von Entitäten und die Beziehung zwischen ihnen. Dieses Diagramm kann wie folgt interpretiert werden:

Jeder STUDENT studiert in nur einer GRUPPE;

Jede GRUPPE besteht aus einem oder mehreren STUDENTEN.

Zahl: 1. Beziehung zwischen Entitäten

In Abb. 2 zeigt die HUMAN-Entität mit einer rekursiven Verknüpfung, die sie mit sich selbst verbindet. Die lakonische mündliche Interpretation des gezeigten Diagramms ist wie folgt:

Jeder MANN ist der Sohn eines und nur eines MANNES;

Jede PERSON kann Vater eines oder mehrerer MENSCHEN sein („PERSONEN“).

Zahl: 2. Rekursive Kommunikation

Ein Attribut einer Entität ist ein Detail, das dazu dient, den Status einer Entität zu klären, zu identifizieren, zu klassifizieren, zu quantifizieren oder auszudrücken. Attributnamen werden in das Rechteck eingegeben, das die Entität unter dem Entitätsnamen darstellt, und in kleinen Buchstaben dargestellt:

Die eindeutige Kennung einer Entität ist ein Attribut, eine Kombination von Attributen, eine Kombination von Beziehungen oder eine Kombination von Beziehungen und Attributen, die eine Entitätsinstanz eindeutig von anderen Entitätsinstanzen desselben Typs unterscheidet. Dies sind die wichtigsten Konzepte des ER-Datenmodells. Komplexere Elemente des Modells umfassen Folgendes.

Viele-zu-viele-Beziehungen. Manchmal ist es notwendig, Entitäten so zu verknüpfen, dass an beiden Enden der Beziehung mehrere Instanzen der Entität vorhanden sein können (z. B. besitzen alle Mitglieder der Genossenschaft gemeinsam das Eigentum der Genossenschaft). Hierzu wird eine Art Viele-zu-Viele-Beziehung eingeführt.

Klare Verbindungsgrade. Manchmal ist es hilfreich, die mögliche Anzahl von Entitätsinstanzen zu bestimmen, die an einer bestimmten Beziehung beteiligt sind (z. B. darf ein Mitarbeiter an nicht mehr als drei Projekten gleichzeitig teilnehmen). Um diese semantische Einschränkung auszudrücken, darf am Ende des Links der maximale oder obligatorische Grad angegeben werden.

Kaskadierendes Löschen von Entitätsinstanzen. Einige Beziehungen sind so stark (natürlich im Fall einer Eins-zu-Viele-Beziehung), dass Sie beim Löschen der Referenzentitätsinstanz (entsprechend dem Ende der einen Beziehung) auch alle Entitätsinstanzen löschen müssen, die dem Ende der vielen Beziehungen entsprechen. Die entsprechende Anforderung zum kaskadierenden Löschen kann in der Entitätsdefinition formuliert werden.

Domänen. Wie beim relationalen Datenmodell kann es nützlich sein, einen potenziell gültigen Wertesatz für ein Entitätsattribut (Domänenattribut) zu definieren.

Diese und andere komplexere Elemente des Entity-Relationship-Datenmodells machen es leistungsfähiger, erschweren jedoch gleichzeitig die Verwendung. Wenn Sie ER-Diagramme für das Datenbankdesign verwenden, müssen Sie sich natürlich mit allen Möglichkeiten vertraut machen.

In der Praxis wird die ER-Modellierung am häufigsten in der ersten Phase des Datenbankdesigns verwendet. Das Ergebnis ist in der Regel ein konzeptionelles Modell der Domäne, ausgedrückt als ER-Modell.

Beim Übergang zur nächsten Stufe - der Modellierung des Datenbankschemas - steht der Entwickler vor dem Problem, das konzeptionelle Modell der Domäne in Form des angewendeten Datenmodells (z. B. relational) auszudrücken. Es gibt drei Ansätze zur Lösung dieses Problems.

Erste Ansatz besteht in der manuellen Transformation des konzeptionellen Modells des Themenbereichs in ein Datenbankschema, das nach Methoden durchgeführt wird, bei denen alle Phasen einer solchen Transformation ganz klar festgelegt sind.

Im zweiten Ansatz Die automatisierte Kompilierung des konzeptionellen Modells der Domäne in das Datenbankschema (meist relational) wird implementiert. Es sind zwei Arten von Ansätzen bekannt:

ein Ansatz, der auf der expliziten Darstellung des konzeptionellen Modells der Domäne als Eingabe für die Kompilierung basiert;

ein Ansatz, der sich auf den Aufbau integrierter Entwurfssysteme mit automatisierter Erstellung eines konzeptionellen Domänenmodells auf der Grundlage von Interviews mit Domänenexperten konzentriert.

In beiden Fällen ist das Ergebnis ein relationales Datenbankschema in dritter Normalform.

Schließlich, dritter Ansatz -es ist eine direkte Arbeit mit der Datenbank im semantischen Modell, d.h. Anwendung von DBMS basierend auf semantischen Datenmodellen. Dies berücksichtigt wiederum zwei Optionen.

Die erste Option ist die Bereitstellung benutzeroberfläche basierend auf einem semantischen Datenmodell mit automatischer Abbildung von Strukturen in ein relationales Datenmodell (dies ist eine Aufgabe von ungefähr der gleichen Komplexität wie die automatische Kompilierung eines konzeptionellen Modells einer Domäne in ein Datenbankschema).

Die zweite Option ist eine direkte Implementierung des DBMS basierend auf einer Art semantischem Datenmodell.

Der zweiten Option am nächsten kommt das moderne objektorientierte DBMS, dessen Datenmodelle in vielerlei Hinsicht semantischen Modellen ähnlich sind (obwohl sie in einigen Aspekten leistungsfähiger und in anderen schwächer sind). Obwohl im Allgemeinen gesagt werden kann, dass dieser Ansatz noch nicht über Forschungs- und experimentelle Projekte hinausgegangen ist.

Derzeit auf dem Markt software Es sind eine ganze Reihe universeller (nicht an ein bestimmtes DBMS gebundener) computergestützter Datenbankentwurfspakete erschienen, die eine konzeptionelle Modellierung der Domäne ermöglichen. Fast alle Systeme dieser Art basieren auf der einen oder anderen Interpretation des ER-Modells. Solche Systeme sind die Implementierung des zweiten der obigen Ansätze. Eines der beliebtesten Softwareprodukte in diesem Bereich ist ERwin von Platinum.

Datenmodelle

Die Art und Weise, wie Entitäten, Attribute und Beziehungen Datenstrukturen zugeordnet werden, wird vom Datenmodell bestimmt. Es gibt 4 Hauptdatenmodelle - Listen, relationale Datenbanken, hierarchische und Netzwerkstrukturen. Betrachten wir sie genauer.

Der einfachste Typ ist eine Liste - eine Datenstruktur in Form einer linearen Sequenz.

Baumhierarchische Strukturen sind in alltäglichen menschlichen Aktivitäten weit verbreitet. Hierarchische Datenmodelle basieren auf der Verwendung von grafischen und tabellarischen Formen der Datenpräsentation. In einem grafischen Diagramm eines Datenbankschemas wird der obere Rand des Diagramms verwendet, um die Entitätstypen zu interpretieren, und die Bögen werden verwendet, um die Arten von Beziehungen zwischen den Entitätstypen zu interpretieren. Bei der Implementierung werden die Scheitelpunkte durch Tabellen mit Beschreibungen von Entitätsinstanzen des entsprechenden Typs dargestellt. In Abb. 3 zeigt ein Beispiel einer hierarchischen Baumstruktur einer Datenbank.

Zahl: 3. Hierarchische Baumstruktur der Datenbank

Die wichtigsten internen Einschränkungen des hierarchischen Datenmodells sind folgende:

- Alle Arten von Links müssen funktionsfähig sein, d. H. 1: 1, 1: M, M: 1;

- Die Struktur der Links sollte baumartig sein.

Das Ergebnis dieser Einschränkungen ist eine Reihe von Merkmalen des Prozesses der Strukturierung von Daten in einem hierarchischen Modell.

Baumstruktur oder holz, - Es ist ein verbundener ungerichteter Graph, der keine Zyklen enthält. Wenn Sie mit einem Baum arbeiten, wird normalerweise ein bestimmter Scheitelpunkt ausgewählt, der als definiert ist wurzel Bäume und werden separat betrachtet - keine einzige Kante tritt in diesen Scheitelpunkt ein. In diesem Fall wird der Baum ausgerichtet. Die Orientierung wird normalerweise von der Wurzel aus bestimmt.

Ein Stammbaum als gerichteter Graph kann wie folgt definiert werden:

- Es gibt einen einzigen speziellen Scheitelpunkt, der als Wurzel bezeichnet wird und keine Kante enthält.

- Nur eine Kante tritt in alle anderen Eckpunkte ein, und es entsteht eine beliebige Anzahl von Kanten.

- keine Zyklen.

Die von der Wurzel aus orientierte hierarchische Baumstruktur erfüllt die folgenden Bedingungen:

- Die Hierarchie beginnt immer am Wurzelknoten.

- Nur der Wurzelknoten kann sich auf der ersten Ebene der Hierarchie befinden.

- Auf den unteren Ebenen sind generiert von (abhängige) Knoten;

- Jeder gespawnte Knoten auf Stufe L. , nur mit einem direkt verbunden original einen Knoten (direkt neben dem übergeordneten Knoten), der sich auf der oberen (L - 1) -ten Ebene der Baumhierarchie befindet;

- Jeder Quellknoten kann einen oder mehrere direkt generierte Knoten haben, die aufgerufen werden ähnlich;

- Der Zugriff auf jeden gespawnten Knoten erfolgt über seinen unmittelbaren Quellknoten.

- Es gibt nur einen hierarchischen Zugriffspfad zum Knoten, der von der Wurzel des Baums ausgeht (Abb. 4).

Zahl: 4. Hierarchischer Pfad des Zugriffs auf den Knoten

Mit anderen Worten ist ein hierarchisches Wissensrepräsentationsmodell (oder ein hierarchischer Baum) eine Datenstruktur, in der jeder Knoten nur ein "Elternteil" hat, d.h. ein dominanter Knoten (mit Ausnahme des obersten Knotens) und eine unbegrenzte Anzahl von "Kindern", dh Knoten, über die dieser Knoten dominiert.

Netzwerkdatenmodelle basieren auch auf der Verwendung einer grafischen Datendarstellung. Die Eckpunkte des Diagramms werden verwendet, um die Arten von Entitäten zu interpretieren, und die Bögen werden verwendet, um die Arten von Verknüpfungen zu interpretieren. Netzwerkmodell Wissensrepräsentation - eine Datenstruktur, in der jedes Objekt im Gegensatz zur hierarchischen Repräsentation mehr als einen dominanten Knoten haben kann (Abb. 5).

Zahl: fünf. Netzwerkstruktur

In den 70er Jahren wurde die theoretische Forschung aktiv betrieben relationales Datenmodell. Mit dem Aufkommen von PCs dominierten relationale Modelle den Markt für Informationssysteme. Relationale Wissensrepräsentation- Repräsentation von Wissen in Form von Beziehungen.

Gemäß relationales Modell Daten werden die Daten in Form einer Reihe von Tabellen dargestellt, über die Operationen ausgeführt werden können, formuliert in Bezug auf relationale Algebra oder relationale Rechnung.

Logisches Design

In der vorgeschlagenen Datenbankentwurfsmethode ist der gesamte Entwicklungsprozess in drei Hauptphasen unterteilt: konzeptionelles, logisches und physisches Design. Logisches Datenbankdesign Ist der Prozess der Erstellung eines allgemeinen Informationsmodells eines Unternehmens basierend auf einzelnen Benutzerdatenmodellen, das unabhängig von den Merkmalen des tatsächlich verwendeten DBMS und anderen physischen Bedingungen ist.

In der vorherigen Phase wurde eine Reihe lokaler konzeptioneller Datenmodelle erhalten, die die Wahrnehmung der Benutzer der Subjektumgebung widerspiegeln. Diese Modelle können jedoch einige Datenstrukturen enthalten, die in gängigen DBMS-Typen nur schwer zu implementieren sind. In dieser Phase werden solche Datenstrukturen in eine Form umgewandelt, die keine Schwierigkeiten verursacht, wenn sie in der Umgebung eines vorhandenen DBMS implementiert werden. Es ist zu beachten, dass diese Aktionen nicht Teil des logischen Entwurfs der Datenbanken sind. Das vorgeschlagene Verfahren zwingt den Entwickler jedoch dazu, die Bedeutung jedes Datenelements genauer zu überlegen, was sich positiv auf die Genauigkeit der Anzeige der Merkmale eines bestimmten Unternehmens im Modell auswirkt. In dieser Phase werden die folgenden Aktionen ausgeführt:

1. Entfernen von Links vom Typ M.:N..

2. Komplexe Links entfernen.

3. Rekursive Links entfernen.

4. Entfernen von Links mit Attributen.

5. Mehrere Attribute entfernen.

6. Überprüfung von 1: 1-Links erneut.

7. Entfernen redundanter Verbindungen.

1. Entfernen von Links vom Typ M: N.Wenn das konzeptionelle Modell Beziehungen wie enthält M.:N. ("Viele-zu-viele"), dann sollten sie durch Definieren einer Zwischeneinheit beseitigt werden. Verbindungstyp M.:N. wird durch zwei Links vom Typ 1 ersetzt: M.mit der neu erstellten Entität installiert.

Betrachten Sie als Beispiel Folgendes M.:N. Kommunikation: Die Zeitung druckt Anzeigen von Mietobjekten (Abb. 6).

Zahl: 6. M: N. Verbindung

Um diese Beziehung zu beseitigen, definieren wir eine Zwischenentität DECLARATION und erstellen zwei neue Beziehungen vom Typ 1: M.... Als Ergebnis eine Beziehung wie M.:N. wird durch zwei Links ersetzt (Abb. 7).

Zahl: 7. Links vom Typ 1: M.

2. Komplexe Links entfernen.Eine komplexe Beziehung ist eine Beziehung, die zwischen drei oder mehr Arten von Entitäten besteht. Wenn das konzeptionelle Modell eine komplexe Beziehung enthält, sollte diese mit einer Zwischeneinheit beseitigt werden. Eine komplexe Verknüpfung wird durch die erforderliche Anzahl von Binärverbindungen vom Typ 1 ersetzt: M.mit der neu erstellten Entität installiert. Beispielsweise spiegelt die dreifache Beziehung „Zu vermieten“ (als Diamant dargestellt) die Beziehung wider, die zwischen dem Mitarbeiter des Unternehmens, der den Mietvertrag ausstellt, dem Grundstück und dem Mieter besteht (Abbildung 8).

Zahl: 8. Komplexe Verbindung

Diese komplexe Beziehung kann vereinfacht werden, indem eine neue Entität eingeführt und binäre Beziehungen zwischen ihr und jeder der ursprünglichen Entitäten der komplexen Beziehung definiert werden.

In unserem Beispiel kann die Beziehung „Zu vermieten“ durch Einführung einer neuen schwachen Einheit namens Vereinbarung entfernt werden. Die neu erstellte Entität wird den ursprünglichen Entitäten mit drei neuen binären Beziehungen zugeordnet (Abb. 9).

Zahl: 9. Vereinfachung der komplexen Kommunikation

3. Rekursive Links entfernen.Rekursive Links sind solche, bei denen eine Entität eines bestimmten Typs mit sich selbst interagiert. Wenn das konzeptionelle Modell rekursive Beziehungen enthält, müssen diese durch Definieren einer Zwischenentität beseitigt werden. Um beispielsweise eine Situation anzuzeigen, in der einer der Mitarbeiter eine Gruppe anderer Mitarbeiter führt, eine rekursive Beziehung vom Typ „Eins-zu-Viele“ (1: M.).

4. Entfernen von Links mit Attributen.Wenn das konzeptionelle Modell Beziehungen mit eigenen Attributen enthält, müssen diese durch Erstellen einer neuen Entität transformiert werden. Stellen Sie sich beispielsweise eine Situation vor, in der die Anzahl der Arbeitsstunden von Zeitarbeitskräften in den einzelnen Abteilungen des Unternehmens aufgezeichnet werden muss. Die Beziehung "Arbeiten in" hat ein Attribut mit dem Namen "Arbeitsstunden". Lassen Sie uns die Beziehung "Arbeiten in" in eine Entität mit dem Namen "Verteilung nach Abteilung" umwandeln, der wir das Attribut "Arbeitsstunden" zuweisen, und dann zwei neue Beziehungen vom Typ 1 erstellen: M..

5. Mehrere Attribute entfernen.Mehrere Attribute können mehrere Werte für dieselbe Entitätsinstanz gleichzeitig haben. Wenn das konzeptionelle Modell mehrere Attribute enthält, sollte es durch Definieren einer neuen Entität transformiert werden. Um beispielsweise eine Situation darzustellen, in der dieselbe Niederlassung eines Unternehmens mehrere Telefonnummern hat, wurde im konzeptionellen Modell ein Mehrfachattribut definiert. Telefonnummer”, Bezogen auf das Unternehmen“ Niederlassung des Unternehmens ”. Dieses Mehrfachattribut sollte entfernt werden, indem eine neue Entität "Telefon" mit einem einzigen einfachen Attribut "Telefonnummer" definiert und eine neue Beziehung vom Typ 1 erstellt wird.

6. Überprüfen Sie die Typverknüpfungen erneut1:1. Beim Definieren von Entitäten können zwei verschiedene Entitäten erstellt werden, die tatsächlich dasselbe Objekt in der Anwendungsdomäne darstellen. Beispielsweise könnten zwei Entitäten "Abteilung" und "Abteilung" erstellt worden sein, die tatsächlich denselben Objekttyp darstellen. Mit anderen Worten, der Name "Abteilung" ist gleichbedeutend mit dem Namen "Abteilung". In diesem Fall sollten Sie diese beiden Entitäten zu einer kombinieren. Wenn die Primärschlüssel der zusammengeführten Entitäten unterschiedlich sind, wählen Sie einen von ihnen als Primärschlüssel aus und geben Sie den anderen als Alternativschlüssel an.

7. Entfernen redundanter Verbindungen.Eine Verbindung ist redundant, wenn ein und dieselbe Information nicht nur über sie, sondern auch mit Hilfe einer anderen Verbindung erhalten werden kann. Sie sollten immer danach streben, minimale Datenmodelle zu erstellen. Wenn redundante Links nicht eindeutig erforderlich sind, sollten sie entfernt werden. Es ist ganz einfach festzustellen, dass zwischen zwei Entitäten mehr als eine Beziehung besteht. Es folgt jedoch noch nicht, dass eine der beiden Verbindungen notwendigerweise redundant ist, da beide unterschiedliche Assoziationen darstellen können, die tatsächlich in der Organisation existieren.

Bei der Beseitigung von Redundanz beim Zugriff ist das Timing wichtig. Stellen Sie sich beispielsweise eine Situation vor, in der die Beziehungen zwischen den Entitäten "Mann", "Frau" und "Kind" modelliert werden müssen. Offensichtlich gibt es zwei Arten des Zugriffs zwischen den Entitäten "Mann" und "Kind": eine über eine direkte Verbindung “ Ist der Vater “und der andere durch Verbindungen “ Verheiratet mit “und„ Ist eine Mutter “. Auf den ersten Blick scheint die Verbindung “ Ist der Vater “ist überflüssig. Diese Aussage kann jedoch aus zwei Gründen falsch sein. Erstens kann ein Vater Kinder aus einer früheren Ehe haben, und wir modellieren nur die aktuelle Ehe des Vaters (durch eine 1: 1-Beziehung). Zweitens können der Vater und die Mutter überhaupt nicht verheiratet sein, oder der Vater kann mit einer Frau verheiratet sein, die nicht die Mutter des Kindes ist (oder die Mutter kann mit einem Mann verheiratet sein, der nicht der Vater des Kindes ist). Daher können nicht alle bestehenden Beziehungen ohne die Verwendung der Beziehung „Ist der Vater“ modelliert werden (Abb. 10).

Zahl: 10. Beziehung zwischen Entitäten "Mann", "Frau", "Kind"

Ähnliche Informationen.