Modellentitätsverbindung Universitätsbibliothek. Entity-Relationship-Modell

Modell „Entität – Verbindung“

Vollständiger Name

Bayramov Alexander Mavleevich

Arbeitsplatz

MBOU-Sekundarschule Nr. 6, Vyazma, Region Smolensk

Berufsbezeichnung

Artikel

Informatik und IKT

Auf dieser Seite wird die Verwendung des Entity-Relationship-Modells beschrieben und veranschaulicht, das 1976 von Peter Chen eingeführt wurde. In diesem Artikel legte Chen den Grundstein für ein Modell, das seitdem von Chen selbst und vielen anderen erweitert und modifiziert wurde. Darüber hinaus wurde das Entity-Relationship-Modell in viele CASE-Tools integriert, die ebenfalls zu seiner Weiterentwicklung beigetragen haben. Heutzutage gibt es keinen einzigen allgemein akzeptierten Standard für das Entity-Relationship-Modell, aber es gibt eine Reihe allgemeiner Konstrukte, die den meisten Varianten dieses Modells zugrunde liegen. Dieses Kapitel widmet sich der Beschreibung dieser allgemeinen Strukturen und der Demonstration ihrer Anwendung. Die zur grafischen Darstellung des Entity-Relationship-Modells verwendeten Symbole sind sehr unterschiedlich. Wir werden nicht nur traditionelle Symbole diskutieren, sondern auch Symbole der UML (Unified Model Language), einem Design-Tool, das bei OOP-Programmierern immer beliebter wird und das Entity-Relationship-Modell umfasst.

Die Schlüsselelemente des Entity-Relationship-Modells sind:

    Wesen

    Attribute

    Bezeichner

    Kommunikation

Entitäten

Eine Entität ist ein in der Arbeitsumgebung des Benutzers identifizierbares Objekt, das der Benutzer gerne beobachten möchte. Beispiele für Entitäten sind MITARBEITER Mary Doe, KUNDE 12345, BESTELLUNG 1000, VERKÄUFER John Smith oder PRODUKT A4200. Entitäten desselben Typs werden in Entitätsklassen gruppiert. Somit ist die Entitätsklasse EMPLOYEE die Sammlung aller EMPLOYEE-Entitäten. Im Buchtext werden Entitätsklassen mit Großbuchstaben bezeichnet.

Es ist wichtig, den Unterschied zwischen einer Entitätsklasse und einer Entitätsinstanz zu verstehen. Eine Entitätsklasse ist eine Sammlung von Entitäten und wird durch die Struktur oder das Format der Entitäten beschrieben, aus denen die Klasse besteht. Eine Entitätsinstanz stellt eine bestimmte Entität dar, z. B. CLIENT 12345; es wird durch die Werte der Attribute einer bestimmten Entität beschrieben. Normalerweise enthält eine Entitätsklasse viele Instanzen einer Entität. Beispielsweise enthält die Klasse CLIENT viele Instanzen, eine für jeden Kunden, für den es einen Datensatz in der Datenbank gibt. Ein Beispiel für eine Entitätsklasse und zwei Entitätsinstanzen ist in Abb. dargestellt. 1.

Reis. 1. KUNDE: Beispielentität

Attribute

Entitäten verfügen über Attribute oder Eigenschaften, wie sie manchmal genannt werden, die die Eigenschaften der Entität beschreiben. Beispiele für Attribute sind EmployeeName, HireDate und QualificationID. Im Text dieser Website werden Attribute sowohl in Groß- als auch in Kleinbuchstaben angegeben. Das Entitätsbeziehungsmodell geht davon aus, dass alle Instanzen einer bestimmten Entitätsklasse dieselben Attribute haben.

Die ursprüngliche Definition des Entity-Relationship-Modells umfasst:zusammengesetzt zusammengesetzte Attribute undpolysemantisch Attribute (mehrwertige Attribute).

Ein Beispiel für ein zusammengesetztes Attribut ist das Adressattribut, das aus einer Gruppe von Attributen (Straße, Stadt, Bundesland, Postleitzahl) besteht. Ein Beispiel für ein mehrwertiges Attribut ist das ProxyName-Attribut der CLIENT-Entität, das die Namen mehrerer Proxys für einen bestimmten Client enthalten kann.

Das Attribut kann gleichzeitig seinsowohl zusammengesetzt als auch mehrwertig - Beispielsweise kann das zusammengesetzte Attribut „Telefon“, das aus einer Gruppe von Attributen (Vorwahl, Ortsnummer) besteht, mehrwertig sein, sodass Sie mehrere Telefonnummern derselben Person in der Datenbank haben können. Die meisten Implementierungen des Entitätsbeziehungsmodells ignorieren einwertige zusammengesetzte Attribute und erfordern die Umwandlung mehrwertiger Attribute (ob zusammengesetzt oder nicht) in Entitäten, wie unten erläutert.

Identifikatoren

Entitätsinstanzen haben Bezeichner – Attribute, durch die diese Instanzen benannt oder identifiziert werden. Beispielsweise können Instanzen von Entitäten der EMPLOYEE-Klasse anhand der Attribute Sozialversicherungsnummer, Mitarbeiter-Personalnummer oder Mitarbeitername identifiziert werden. Attribute wie Salary oder HireDate dienen wahrscheinlich nicht als Bezeichner für Instanzen von Entitäten der EMPLOYEE-Klasse, da diese Attribute normalerweise nicht zur eindeutigen Identifizierung eines bestimmten Mitarbeiters verwendet werden. Ebenso können Entitäten der Klasse CLIENT durch die Attribute CustomerNumber oder CustomerName und Entitäten der Klasse ORDER durch das Attribut OrderNumber identifiziert werden.

Ein Entitätsinstanzbezeichner besteht aus einem oder mehreren Entitätsattributen. Die ID kann seineinzigartig (einzigartig) odernicht einzigartig (nicht eindeutig).

Wenn der Bezeichner eindeutig ist, verweist sein Wert auf eine und nur eine Instanz der Entität.

Wenn der Bezeichner nicht eindeutig ist, verweist sein Wert auf eine Reihe von Instanzen. EmployeePersonnelNumber ist höchstwahrscheinlich eine eindeutige Kennung, während EmployeeName eine nicht eindeutige Kennung ist (es kann beispielsweise mehrere Mitarbeiter mit dem Namen John Smith geben).

Es werden Bezeichner aufgerufen, die aus mehreren Attributen bestehenzusammengesetzt zusammengesetzte Bezeichner. Beispiele hierfür sind Sammlungen der Form (Regionalcode, Ortsnummer), (Projektname, Aufgabenname) und (Vorname, Nachname, Nebenstellentelefonnummer).

Verbindungen

Die Beziehungen zwischen Entitäten werden durch Beziehungen ausgedrückt. Das Entity-Relationship-Modell umfasst Beziehungsklassen und Beziehungsinstanzen. Beziehungsklassen sind Beziehungen zwischen Entitätsklassen und Beziehungsinstanzen sind Beziehungen zwischen Entitätsinstanzen. Beziehungen können Attribute haben.

Eine Beziehungsklasse kann mehrere Entitätsklassen umfassen. Die Anzahl der an einer Beziehung beteiligten Entitätsklassen wird als Beziehungsgrad bezeichnet. In Abb. dargestellt. 2, und die Beziehung VERKÄUFER-AUFTRAG hat den Grad 2, da es sich um zwei Klassen von Entitäten handelt: VERKÄUFER und BESTELLER. Die PARENT-Verbindung in Abb. 2; b hat den Grad 3, da es sich um drei Klassen von Entitäten handelt: MUTTER, VATER und KIND. Beziehungen vom Grad 2 sind sehr verbreitet und werden oft als binäre Beziehungen bezeichnet.

Abb.2. Verschiedene Verbindungsgrade: a - Verbindung vom Grad 2; b - Verbindung von Grad 3

Drei Arten von binären Bindungen

In Abb. Abbildung 3 zeigt drei Arten von Binärbindungen. In einer 1:1-Beziehung („Eins-zu-eins“) ist eine einzelne Instanz einer Entität eines Typs mit einer einzelnen Instanz einer Entität eines anderen Typs verknüpft. In Abb. 3 und die Beziehung EMPLOYEE_VEHICLE verbindet eine einzelne Entität der EMPLOYEE-Klasse mit einer einzelnen Entität der CAR-Klasse. Gemäß dieser Tabelle ist keinem Mitarbeiter mehr als ein Fahrzeug und kein Fahrzeug mehr als einem Mitarbeiter zugeordnet.

Reis. 3. Drei Arten von Binärbindungen: a – Binärbindung 1:1; b – binäre Bindung 1:N; c – binäre Bindung N:M; d – Darstellung der Kommunikation mithilfe von Zweigen

In Abb. 3, b zeigt die zweite Art der Verbindung, 1:N („eins zu N“ oder „eins zu viele“). In dieser Beziehung namens DORMS-RESIDENT ist eine einzelne Instanz einer Entität der Klasse HOSTEL mit vielen Instanzen einer Entität der Klasse STUDENT verknüpft. Nach diesem Bild leben viele Studenten in einem Wohnheim, aber jeder Student wohnt nur in einem Wohnheim.

Die Position, an der die 1 und das N erscheinen, ist von Bedeutung. Die Einheit steht auf der Seite des Anschlusses, auf der sich das HOSTEL befindet, und N steht auf der Seite des Anschlusses, auf der sich der STUDENT befindet. Wenn 1 und N vertauscht wären und die Beziehung als N:l geschrieben würde, würde dies dazu führen, dass ein Student in einem Wohnheim lebt und jeder Student in mehreren Wohnheimen lebt. Das stimmt natürlich nicht.

In Abb. 3, c zeigt die dritte Art der binären Beziehung, N:M (sprich „N zu M“ oder „viele zu viele“). Diese Beziehung wird STUDENT-CLUB genannt und verknüpft Instanzen von Entitäten der Klasse STUDENT mit Instanzen von Entitäten der Klasse CLUB. Ein Student kann Mitglied in mehreren Clubs sein und ein Club kann viele Studenten haben.

Die Zahlen innerhalb der Raute, die die Verbindung darstellt, stellen die maximale Anzahl von Entitäten auf jeder Seite der Verbindung dar. Diese Einschränkungen werden als maximale Kardinalitätszahlen bezeichnet, und die Menge zweier solcher Einschränkungen für beide Seiten der Verbindung wird als maximale Kardinalität der Verbindung bezeichnet. Zum Beispiel über die in Abb. gezeigte Verbindung. 3, b sagen sie, dass es eine maximale Kardinalität von 1:N hat. Kardinalzahlen können andere Werte als nur 1 und N haben. Beispielsweise könnte die Beziehung zwischen den Entitäten BASKETBALL_TEAM und PLAYER eine Kardinalität von 1:5 haben, was uns sagt, dass eine Basketballmannschaft nicht mehr als fünf Spieler haben kann.

Die Verbindungen der drei in Abb. dargestellten Typen. 3 werden manchmal als HAS-A-Beziehungen bezeichnet. Dieser Begriff wird verwendet, weil eine Entität eine Beziehung zu einer anderen Entität hat. Zum Beispiel: Ein Angestellter hat ein Auto, ein Student hat ein Wohnheim, ein Verein hat Studenten.

Die in Abb. 3 werden als Entity-Relationship-Diagramme oder ER-Diagramme bezeichnet. Solche Diagramme sind standardisiert, aber nicht zu starr. Nach diesem Standard werden Entitätsklassen durch Rechtecke, Beziehungen durch Rauten und die maximale Kardinalzahl jeder Beziehung innerhalb der Raute angezeigt. Der Entitätsname erscheint innerhalb des Rechtecks ​​und der Beziehungsname erscheint neben der Raute. Obwohl einige ER-Diagramme den Beziehungsnamen innerhalb der Raute enthalten, kann das resultierende Diagramm hässlich aussehen, da die Rauten groß und unmaßstäblich gemacht werden müssen der Beziehungsname. Um dies zu vermeiden, werden Linknamen manchmal über der Raute geschrieben. Wenn ein Name innerhalb oder über einer Raute platziert wird, wird die Kardinalität der Beziehung durch die Zweige auf den Linien dargestellt, die die Entität (oder Entitäten) mit der multiplen Seite der Beziehung verbinden. In Abb. 3, d zeigt die HOSTEL-RESIDENT- und STUDENT-CLUB-Verbindungen mit solchen Zweigstellen.

Wie wir bereits gesagt haben, zeigt die maximale Kardinalität die maximale Anzahl von Entitäten an, die an einer Beziehung teilnehmen können. Die obigen Diagramme geben keinen Aufschluss über die Mindestanzahl solcher Einheiten. Zum Beispiel Abb. 3, b zeigt, dass ein Student maximal in einem Wohnheim wohnen kann, es geht daraus jedoch nicht klar hervor, ob der Student verpflichtet ist, in einem Wohnheim zu wohnen.

Es gibt mehrere Möglichkeiten, die Mindestkardinalität anzugeben. Eine davon, dargestellt in Abb. 4.

Reis. 4. Zusammenhang mit der angegebenen Mindestkardinalität

Diese Methode ist wie folgt: Um zu zeigen, dass die Entität zur Teilnahme an der Verbindung verpflichtet ist, wird eine senkrechte Linie auf die Verbindungslinie gelegt, und um zu zeigen, dass die Entität zur Teilnahme an der Verbindung beitragen kann (aber nicht verpflichtet ist), wird ein Oval platziert wird auf die Verbindungslinie gelegt. Dementsprechend Abb. 4 zeigt, dass die Entität HOSTEL mit mindestens einer Entität STUDENT verknüpft sein muss, die Entität STUDENT jedoch nicht mit der Entität HOSTEL verknüpft sein muss. Der gesamte Satz an Einschränkungen, die der Beziehung auferlegt werden, besteht darin, dass DORMS eine minimale Kardinalität von eins und eine maximale Kardinalität von „vielen“ STUDENT-Entitäten aufweist. STUDENT hat eine minimale Kardinalzahl von Null und eine maximale Kardinalzahl von einer Instanz der HOSTEL-Entität.

Es kann eine Beziehung zwischen Entitäten derselben Klasse bestehen. Beispielsweise kann für Entitäten der Klasse STUDENT die Beziehung ROOM NEIGHBOR definiert werden. Dieser Zusammenhang ist in Abb. dargestellt. 5, a und in Abb. Abbildung 5b zeigt Instanzen von Entitäten, die von dieser Beziehung abgedeckt werden. Beziehungen zwischen Entitäten derselben Klasse werden manchmal als rekursive Beziehungen bezeichnet.

Abb.5 Rekursive Kommunikation

Beim eigentlichen Datenbankstrukturdesign wird eine Methode verwendet – die sogenannte Semantische Modellierung. Semantische Modellierung ist die Modellierung der Datenstruktur basierend auf der Bedeutung dieser Daten. Als semantisches Modellierungswerkzeug kommen verschiedene Optionen zum Einsatz Entity-Relationship-Diagramme(ER – Entity-Relationship).

Die erste Version des Entity-Relationship-Modells wurde 1976 von Peter Ping-Sheng Chen vorgeschlagen. Anschließend entwickelten viele Autoren eigene Versionen ähnlicher Modelle (Martin-Notation, IDEF1X-Notation, Barker-Notation usw.). Darüber hinaus können sich verschiedene Softwaretools, die dieselbe Notation implementieren, in ihren Fähigkeiten unterscheiden. Tatsächlich basieren alle Varianten von Entity-Relationship-Diagrammen auf der gleichen Idee – eine Zeichnung ist immer klarer als eine Textbeschreibung. Alle diese Diagramme verwenden eine grafische Darstellung von Domänenentitäten, ihren Eigenschaften (Attributen) und Beziehungen zwischen Entitäten.

Wir werden die Arbeit mit ER-Diagrammen, die der Barker-Notation nahe kommen, als relativ einfach beschreiben, um die Grundideen zu verstehen. Dieses Kapitel ist eher eine Veranschaulichung semantischer Modellierungstechniken als eine vollständige Einführung in das Fachgebiet.

Grundkonzepte von ER-Diagrammen

Definition 1: Wesen ist eine Klasse von Objekten desselben Typs, deren Informationen im Modell berücksichtigt werden müssen.
Jede Entität muss einen Namen haben, der durch ein Substantiv im Singular ausgedrückt wird. Beispiele für Entitäten können Objektklassen wie „Lieferant“, „Mitarbeiter“ und „Rechnung“ sein. Jede Entität im Modell wird als Rechteck mit einem Namen dargestellt:

Reis. 1

Definition 2: Entitätsinstanz ist ein spezifischer Vertreter einer bestimmten Entität.
Ein Vertreter der Entität „Mitarbeiter“ kann beispielsweise „Mitarbeiter Ivanov“ sein. Entitätsinstanzen 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ätsattribut ist ein benanntes Merkmal, das eine Eigenschaft einer Entität ist.
Der Name des Attributs muss als Substantiv im Singular ausgedrückt werden (ggf. mit charakterisierenden Adjektiven). Beispiele für Attribute der Entität „Mitarbeiter“ können Attribute wie „Personalnummer“, „Nachname“, „Vorname“, „Vatername“, „Position“, „Gehalt“ usw. sein. Attribute werden in einem Rechteck dargestellt, das die Entität definiert:

Reis. 2

Definition 4: Entitätsschlüssel ist ein nicht redundanter Satz von Attributen, deren Werte zusammen für jede Instanz einer Entität eindeutig sind. Nicht-Redundanz bedeutet, dass das Entfernen eines Attributs aus einem Schlüssel seine Einzigartigkeit beeinträchtigt. Eine Entität kann mehrere unterschiedliche Schlüssel haben. Die wichtigsten Attribute sind im Diagramm unterstrichen dargestellt:

Reis. 3

Definition 5: Verbindung- Dies ist eine Verbindung zwischen zwei Entitäten. Eine Entität kann mit einer anderen Entität oder mit sich selbst verbunden sein.
Beziehungen ermöglichen es einer Entität, andere mit ihr verbundene Entitäten zu finden. Verbindungen zwischen Entitäten können beispielsweise durch die folgenden Sätze ausgedrückt werden: „Ein MITARBEITER kann mehrere KINDER haben“, „Jeder MITARBEITER muss in genau einer ABTEILUNG eingeschrieben sein“. Grafisch wird die Beziehung durch eine Linie dargestellt, die zwei Entitäten verbindet:

Reis. 4

Jeder Link hat zwei Enden und einen oder zwei Namen. Der Name wird normalerweise in einer unbestimmten verbalen Form ausgedrückt: „haben“, „zugehören“ usw. Jeder Name bezieht sich auf sein eigenes Ende der Verbindung. Manchmal werden Namen nicht geschrieben, weil sie offensichtlich sind.

Jeder Link kann eine der folgenden Eigenschaften haben Arten der Kommunikation:

Reis. 5

Kommunikationstyp eins zu eins bedeutet, dass eine Instanz der ersten Entität (links) mit einer Instanz der zweiten Entität (rechts) verknüpft ist. Eine Eins-zu-Eins-Beziehung weist meistens darauf hin, dass wir tatsächlich nur eine Entität haben, die fälschlicherweise in zwei Teile geteilt ist.

Kommunikationstyp eins-zu-viele bedeutet, dass eine Instanz der ersten Entität (links) mit mehreren Instanzen der zweiten Entität (rechts) verknüpft ist. Dies ist die am häufigsten verwendete Kommunikationsart. Die linke Entität (auf der „einen“ Seite) wird aufgerufen elterlich, rechts (von der „vielen“-Seite) - Tochtergesellschaft. Ein typisches Beispiel für eine solche Verbindung ist in Abb. dargestellt. 4.

Kommunikationstyp viele-zu-viele bedeutet, 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. Der Viele-zu-Viele-Beziehungstyp ist ein temporärer Beziehungstyp, der in den frühen Phasen der Modellentwicklung akzeptabel ist. Zukünftig muss diese Art von Beziehung durch die Schaffung einer Zwischeneinheit durch zwei Eins-zu-viele-Beziehungen ersetzt werden.

Jede Verbindung kann eine von zwei haben Kommunikationsmodalitäten:

Reis. 6

Modalität" Vielleicht„bedeutet, dass eine Instanz einer Entität mit einer oder mehreren Instanzen einer anderen Entität verknüpft sein kann oder nicht.
Modalität" muss„bedeutet, dass eine Instanz einer Entität mit mindestens einer Instanz einer anderen Entität verknüpft sein muss.
Die Verbindung kann an verschiedenen Enden unterschiedliche Modalitäten haben (wie in Abb. 4). Die beschriebene grafische Syntax ermöglicht Ihnen das eindeutige Lesen von Diagrammen anhand der folgenden Phrasenstruktur:

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

Jeder Link kann entweder von links nach rechts oder von rechts nach links gelesen werden. Verbindung 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 müssen wir folgende Informationen zum Themengebiet einholen:

  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. Gleichzeitig sind die ER-Diagramme selbst die Dokumentation, in der die Ergebnisse der Gespräche festgehalten werden.

Nehmen wir an, wir stehen vor der Aufgabe, ein Informationssystem für ein bestimmtes Großhandelsunternehmen zu entwickeln. Zunächst müssen wir das Fachgebiet und die darin ablaufenden Prozesse untersuchen. Dazu befragen wir Mitarbeiter des Unternehmens, lesen Dokumentationen, studieren Auftragsformulare, Rechnungen usw.

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

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

Wählen wir alle Substantive in diesen Sätzen aus – das sind potenzielle Kandidaten für Entitäten und Attribute – und analysieren wir sie (unklare Begriffe markieren wir mit einem Fragezeichen):

  • Der Käufer ist ein klarer Kandidat für das Unternehmen.
  • Die Rechnung ist ein klarer Kandidat für eine Entität.
  • Das Produkt ist ein klarer Kandidat für die Entität
  • (?)Lager – wie viele Lager hat das Unternehmen im Allgemeinen? Wenn es mehrere gibt, handelt es sich um einen Kandidaten für eine neue Einheit.
  • (?) Die Verfügbarkeit eines Produkts ist höchstwahrscheinlich ein Attribut, aber ein Attribut welcher Entität?

Es entsteht sofort ein offensichtlicher Zusammenhang zwischen den Entitäten: „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:

Reis. 7

Nachdem wir dem Manager weitere 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 soll ich die Entitäten „Rechnung“ und „Lager“ platzieren und womit soll ich sie verknüpfen? Stellen wir uns die Frage, in welcher Beziehung diese Entitäten zueinander und zu den Entitäten „Käufer“ und „Produkt“ stehen? Käufer kaufen Waren und erhalten Rechnungen mit Angaben zu Menge und Preis der gekauften Waren. Jeder Käufer kann mehrere Rechnungen erhalten. Jede Rechnung muss an einen Käufer ausgestellt werden. Jede Rechnung muss mehrere Waren enthalten (es gibt keine leeren Rechnungen). Jedes Produkt kann wiederum über mehrere Rechnungen an mehrere Käufer 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. Somit sieht das Diagramm nach der Klärung wie folgt aus:

Reis. 8

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

  • Jeder Käufer ist eine juristische Person und verfügt über einen Namen, eine Adresse und eine Bankverbindung.
  • Jedes Produkt hat einen Namen, einen Preis und ist außerdem durch Maßeinheiten gekennzeichnet.
  • Jede Rechnung verfügt über eine eindeutige Nummer, ein Ausstellungsdatum, eine Warenliste mit Mengen und Preisen sowie den Gesamtbetrag der Rechnung. Die Rechnung wird von einem bestimmten Lager aus und an einen bestimmten Käufer ausgestellt.
  • Jedes Lager hat seinen eigenen Namen.
  • Schreiben wir noch einmal alle Substantive auf, die potenzielle Attribute sein könnten, und analysieren wir sie:
  • „Rechtsperson“ ist ein rhetorischer Begriff; wir arbeiten nicht mit Einzelpersonen. Wir achten nicht darauf.
  • Der Name des Käufers ist ein eindeutiges Merkmal des Käufers.
  • Die Adresse ist ein eindeutiges Merkmal des Käufers.
  • Die Bankverbindung ist ein eindeutiges Merkmal des Käufers.
  • Der Name des Produkts ist ein klares Merkmal des Produkts.
  • (?) Der Preis des Produkts – es scheint, dass dies ein Merkmal des Produkts ist. Weicht dieses Merkmal vom Preis auf der Rechnung ab?
  • Eine Maßeinheit ist ein eindeutiges Merkmal eines Produkts.
  • Die Rechnungsnummer ist ein eindeutiges eindeutiges Merkmal der Rechnung.
  • Das Rechnungsdatum ist ein eindeutiges Merkmal der Rechnung.
  • (?) Warenliste in der Rechnung – die Liste darf kein Attribut sein. Sie müssen diese Liste wahrscheinlich in eine separate Einheit aufteilen.
  • (?) Die Warenmenge in der Rechnung ist ein offensichtliches Merkmal, aber ein Merkmal wovon? Dies ist nicht nur ein Merkmal eines „Produkts“, sondern eines „Produkts in der Rechnung“.
  • (?) Der Preis des Produkts in der Rechnung – auch dies sollte nicht nur eine Eigenschaft des Produkts sein, sondern eine Eigenschaft des Produkts in der Rechnung. Aber der Preis des Produkts wurde oben bereits gesehen – ist es dasselbe?
  • Der Rechnungsbetrag ist ein explizites Merkmal der Rechnung. Dieses Merkmal ist nicht unabhängig. Der Rechnungsbetrag entspricht der Summe der Kosten aller in der Rechnung enthaltenen Waren.
  • Der Name des Lagers ist ein klares Merkmal des Lagers.

In einem weiteren Gespräch mit dem Geschäftsführer konnten verschiedene Preiskonzepte geklärt werden. Es stellte sich heraus, dass jedes Produkt einen bestimmten aktuellen Preis hat. Dies ist der Preis, zu dem das Produkt derzeit verkauft wird. Natürlich kann sich dieser Preis im Laufe der Zeit ändern. Der Preis desselben Produkts kann in verschiedenen Rechnungen, die zu unterschiedlichen Zeitpunkten ausgestellt wurden, unterschiedlich sein. Somit gibt es zwei Preise – den Warenpreis auf der Rechnung und den aktuellen Warenpreis.

Mit dem aufkommenden Konzept „Warenliste in der Rechnung“ ist alles ganz 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. Bei dieser Entität handelt es sich um die Entität „Liste der Waren in der Rechnung“. Sein Zusammenhang mit den Entitäten „Rechnung“ und „Produkt“ wird durch die folgenden Formulierungen charakterisiert: „Jede Rechnung muss mehrere Einträge aus dem Warenverzeichnis der Rechnung enthalten“, „jeder Eintrag aus dem Warenverzeichnis der Rechnung muss enthalten sein.“ in genau einer Rechnung“, „Jedes Produkt kann in mehreren Einträgen des Warenverzeichnisses der Rechnung enthalten sein“, „Jeder Eintrag des Warenverzeichnisses der Rechnung muss genau einem Produkt zugeordnet sein.“ Die Attribute „Warenmenge in der Rechnung“ und „Preis der Ware in der Rechnung“ sind Attribute der Entität „Warenliste in der Rechnung“.

Das Gleiche machen wir mit der Verbindung, die die Entitäten „Lager“ und „Produkt“ verbindet. Lassen Sie uns eine zusätzliche Entität „Artikel im Lager“ einführen. Das Attribut dieser Entität lautet „Warenmenge auf Lager“. Somit wird das Produkt in jedem Lager gelistet und seine Menge in jedem Lager ist unterschiedlich.

Jetzt können Sie das alles in einem Diagramm zusammenfassen:

Reis. 9

Konzeptionelle und physikalische ER-Modelle

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

Reis. 10

In diesem Diagramm stellt jede Entität eine Datenbanktabelle dar, jedes Attribut wird zu einer Spalte der entsprechenden Tabelle. Bitte beachten Sie, dass in vielen Tabellen, zum Beispiel „CUST_DETAIL“ und „PROD_IN_SKLAD“, die den Entitäten „Rechnungslistendatensatz“ und „Artikel im Lager“ entsprechen, neue Attribute aufgetaucht sind, die nicht im konzeptionellen Modell enthalten waren – das ist der Schlüssel Attribute der übergeordneten Tabellen, migriert in untergeordnete Tabellen, um mithilfe von Fremdschlüsseln Beziehungen zwischen Tabellen herzustellen.

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

Schlussfolgerungen

Das eigentliche Mittel der Datenmodellierung ist nicht die formale Methode zur Normalisierung von Beziehungen, sondern die sogenannte Semantische Modellierung.

Als semantisches Modellierungswerkzeug kommen verschiedene Optionen zum Einsatz Entity-Relationship-Diagramme(ER – Entity-Relationship).

Entity-Relationship-Diagramme ermöglichen Ihnen die Verwendung visueller grafischer Notationen zur Modellierung von Entitäten und ihren Beziehungen.

Unterscheiden konzeptionell Und körperlich ER-Diagramme. Konzeptuelle Diagramme berücksichtigen nicht die spezifischen Merkmale bestimmter DBMS. Physische Diagramme basieren auf konzeptionellen Diagrammen und stellen einen Prototyp einer bestimmten Datenbank dar. In einem konzeptionellen Diagramm definierte Entitäten werden zu Tabellen, Attribute zu Tabellenspalten (unter Berücksichtigung der für ein bestimmtes DBMS zulässigen Datentypen und Spaltennamen), Verbindungen werden von implementiert Migration Schlüsselattribute übergeordneter Entitäten und Erstellen von Fremdschlüsseln.

Wenn Entitäten korrekt definiert sind, liegen die resultierenden Tabellen sofort in 3NF vor. Der Hauptvorteil der Methode besteht darin, dass das Modell durch sukzessive Verfeinerungen der Ausgangsdiagramme erstellt wird.

In diesem Kapitel, das ER-Modellierungsmethoden veranschaulicht, werden komplexere Aspekte der Diagrammerstellung wie Subtypen, Rollen, exklusive Beziehungen, nicht übertragbare Beziehungen, identifizierende Beziehungen usw. nicht behandelt.

Das Entitäts-Attribut-Beziehungsmodell wurde 1976 von Peter Ping-Shen Chenow vorgeschlagen. Die meisten modernen Ansätze zum Datenbankdesign (hauptsächlich relational) basieren auf der Verwendung von Variationen des ER-Modells. Die Domänenmodellierung basiert auf der Verwendung grafischer Diagramme, die eine kleine Anzahl heterogener Komponenten umfassen. Aufgrund der klaren Darstellung konzeptioneller Datenbankdiagramme 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.

Wesen– ist ein reales oder imaginäres Objekt, dessen Informationen von Interesse sind. In ER-Modelldiagrammen wird eine Entität als Rechteck dargestellt, das den Namen der Entität 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 grafisch dargestellte Verbindung zwischen zwei Entitäten. Diese Assoziation ist immer binär und kann zwischen zwei verschiedenen Entitäten oder zwischen einer Entität und sich selbst bestehen (rekursive Beziehung). In jeder Verbindung werden zwei Enden identifiziert (entsprechend dem Paar verbundener Entitäten), von denen jedes den Namen des Endes der Verbindung und den Grad des Endes der Verbindung angibt (wie viele Instanzen dieser Entität sind verbunden). , die obligatorische Natur der Verbindung (d. h. ob eine Instanz dieser Entität an dieser Verbindung teilnehmen muss).

Eine Verbindung wird als Linie dargestellt, die zwei Entitäten verbindet oder von einer Entität zu sich selbst führt. In diesem Fall wird an dem Punkt, an dem die Verbindung mit der Entität „vereinigt“ wird, ein Dreipunkteintritt in das Entitätsrechteck verwendet, wenn für diese Entität in der Verbindung viele Instanzen der Entität verwendet werden können, und ein Einzelpunkt Eintrag, wenn nur eine Instanz der Entität an der Verbindung teilnehmen kann. Das erforderliche Ende der Verbindung ist mit einer durchgezogenen Linie dargestellt, das optionale Ende mit einer gestrichelten Linie.

Eine Beziehung ist wie eine Entität ein generisches Konzept; alle Instanzen beider Paare verwandter Entitäten unterliegen den Assoziationsregeln. In Abb. 1. Es wird ein Beispiel für ein Bild von Entitäten und der Beziehung zwischen ihnen gegeben. Dieses Diagramm kann wie folgt interpretiert werden:

Jeder STUDENT studiert nur in einer GRUPPE;

Jede GRUPPE besteht aus einem oder mehreren STUDENTEN.

Reis. 1. Beziehung zwischen Entitäten

In Abb. 2 zeigt das Wesen von MAN mit einer rekursiven Verbindung, die es mit sich selbst verbindet. Eine lakonische mündliche Interpretation des dargestellten Diagramms lautet wie folgt:

Jede PERSON ist der Sohn einer und nur einer PERSON;

Jede PERSON kann der Vater einer oder mehrerer PERSONEN („PERSONEN“) sein.

Reis. 2. Rekursive Kommunikation

Ein Entitätsattribut ist jedes Detail, das dazu dient, den Zustand der Entität zu klären, zu identifizieren, zu klassifizieren, zu quantifizieren oder auszudrücken. Attributnamen werden in einem Rechteck, das die Entität darstellt, unter dem Entitätsnamen eingegeben und in Kleinbuchstaben dargestellt:

Der eindeutige Bezeichner einer Entität ist ein Attribut, eine Kombination von Attributen, eine Kombination von Beziehungen oder eine Kombination von Beziehungen und Attributen, die jede Instanz der Entität eindeutig von anderen Instanzen desselben Entitätstyps unterscheidet. Dies sind die wichtigsten Konzepte im ER-Datenmodell. Zu den komplexeren Elementen des Modells gehören die folgenden.

Viele-zu-viele-Beziehungen. Manchmal ist es notwendig, Entitäten so zu verknüpfen, dass es an beiden Enden der Verbindung mehrere Instanzen der Entität geben kann (z. B. besitzen alle Mitglieder einer Genossenschaft gemeinsam das Eigentum der Genossenschaft). Dazu wird eine Art „Many-to-many“-Beziehung eingeführt.

Vorgebbare Verbindungsgrade. Manchmal ist es sinnvoll, die mögliche Anzahl der an einer bestimmten Beziehung beteiligten Entitätsinstanzen zu definieren (ein Mitarbeiter darf beispielsweise an nicht mehr als drei Projekten gleichzeitig teilnehmen). Um diese semantische Einschränkung auszudrücken, ist es zulässig, am Ende der Verbindung ihren maximalen oder obligatorischen Grad anzugeben.

Kaskadierende Löschungen von Entitätsinstanzen. Einige Beziehungen sind so stark (natürlich im Fall einer Eins-zu-viele-Beziehung), dass Sie beim Löschen der Referenz-Entitätsinstanz (entsprechend dem „einen“ Ende der Beziehung) auch alle entsprechenden Entitätsinstanzen löschen müssen zum „vielen“ Ende der Beziehung. Die entsprechende Anforderung zur „kaskadierenden Löschung“ kann bei der Definition einer Entität formuliert werden.

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

Diese und andere komplexere Elemente des Entity-Relationship-Datenmodells machen es leistungsfähiger, machen es aber auch etwas schwieriger zu verwenden. Wenn Sie ER-Diagramme tatsächlich 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 eingesetzt. Das Ergebnis ist in der Regel ein konzeptionelles Modell des Fachgebiets, ausgedrückt im ER-Modell.

Beim Übergang zur nächsten Stufe – der Datenbankschemamodellierung – steht der Entwickler vor dem Problem, das konzeptionelle Modell der Domäne anhand des angewandten Datenmodells (z. B. relational) auszudrücken. Zur Lösung dieses Problems gibt es drei Ansätze.

Erster Ansatz besteht aus der manuellen Konvertierung eines konzeptionellen Modells eines Themenbereichs in ein Datenbankschema, die nach Methoden durchgeführt wird, in denen alle Phasen einer solchen Konvertierung klar spezifiziert sind.

Im zweiten Ansatz Es wird eine automatisierte Kompilierung des konzeptionellen Modells des Themenbereichs in ein Datenbankschema (meistens relational) implementiert. Es gibt zwei Arten von Ansätzen:

ein Ansatz, der auf der expliziten Darstellung des konzeptionellen Modells des Fachgebiets als Ausgangsinformation für die Zusammenstellung basiert;

Ein Ansatz, der sich auf den Aufbau integrierter Designsysteme mit automatisierter Erstellung eines konzeptionellen Modells eines Themenbereichs auf der Grundlage von Interviews mit Fachexperten konzentriert.

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

Endlich, dritter Ansatz - Dies ist eine direkte Arbeit mit der Datenbank im semantischen Modell, d.h. Verwendung von DBMS basierend auf semantischen Datenmodellen. Auch hier werden zwei Optionen in Betracht gezogen.

Die erste Option besteht darin, eine Benutzeroberfläche bereitzustellen, die auf einem semantischen Datenmodell mit automatischer Zuordnung von Konstrukten zu einem relationalen Datenmodell basiert (dies ist eine Aufgabe von ungefähr der gleichen Komplexität wie die automatische Kompilierung eines konzeptionellen Domänenmodells in ein Datenbankschema).

Die zweite Option ist eine direkte Implementierung eines DBMS, basierend auf einem semantischen Datenmodell.

Der zweiten Option am nächsten kommen moderne objektorientierte DBMS, deren Datenmodelle in vielerlei Hinsicht semantischen Modellen ähneln (obwohl sie in einigen Aspekten leistungsfähiger und in anderen schwächer sind). Obwohl allgemein gesagt werden kann, dass dieser Ansatz noch nicht über Forschung und experimentelle Projekte hinausgegangen ist.

Derzeit sind auf dem Softwaremarkt zahlreiche universelle (nicht an ein bestimmtes DBMS gebundene) computergestützte Datenbankdesignpakete erschienen, die eine konzeptionelle Modellierung des Themenbereichs ermöglichen. Fast alle Systeme dieser Art basieren auf der einen oder anderen Interpretation des ER-Modells. Solche Systeme sind eine Umsetzung des zweiten der oben diskutierten 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 durch das Datenmodell bestimmt. Es gibt 4 Hauptdatenmodelle: Listen, relationale Datenbanken, hierarchische und Netzwerkstrukturen. Schauen wir sie uns genauer an.

Der einfachste Typ ist eine Liste – eine Datenstruktur in Form einer linearen Folge.

Baumhierarchische Strukturen werden häufig in alltäglichen menschlichen Aktivitäten verwendet. Hierarchische Datenmodelle basieren auf der Verwendung grafischer und tabellarischer Formen der Datendarstellung. In einem grafischen Datenbankschemadiagramm wird der Scheitelpunkt des Diagramms zur Interpretation der Entitätstypen und die Bögen zur Interpretation der Beziehungstypen zwischen Entitätstypen verwendet. Bei der Implementierung werden Scheitelpunkte durch Tabellen mit Beschreibungen von Instanzen von Entitäten des entsprechenden Typs dargestellt. In Abb. Abbildung 3 zeigt ein Beispiel einer hierarchischen Baumstruktur einer Datenbank.

Reis. 3. Hierarchische Baumstruktur der Datenbank

Die wichtigsten internen Einschränkungen des hierarchischen Datenmodells sind die folgenden:

– Alle Arten von Verbindungen müssen funktionsfähig sein, d. h. 1:1, 1:M, M:1;

– Die Struktur der Verbindungen sollte baumartig sein.

Das Ergebnis dieser Einschränkungen sind eine Reihe von Merkmalen des Prozesses der Datenstrukturierung in einem hierarchischen Modell.

Baumstruktur, oder Baum, - Es handelt sich um einen zusammenhängenden ungerichteten Graphen, der keine Zyklen enthält. Wenn man mit einem Baum arbeitet, wählt man normalerweise einen bestimmten Scheitelpunkt aus und definiert ihn als Wurzel Baum und werden speziell berücksichtigt - keine einzige Kante geht in diesen Scheitelpunkt. In diesem Fall wird der Baum ausgerichtet. Die Ausrichtung wird normalerweise von der Wurzel aus bestimmt.

Ein Wurzelbaum als gerichteter Graph kann wie folgt definiert werden:

– es gibt einen einzigen speziellen Scheitelpunkt, die Wurzel genannt, in den keine Kante eintritt;

– nur eine Kante tritt in alle anderen Eckpunkte ein und eine beliebige Anzahl von Kanten tritt aus;

– keine Zyklen.

Eine hierarchische Baumstruktur, die von der Wurzel aus orientiert ist, 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(abhängige) Knoten;

– jeder gespawnte Knoten befindet sich auf Ebene L , nur mit einem direkt verbunden Original ein Knoten (direkt der übergeordnete Knoten), der sich auf einer höheren (L – 1) Ebene der Baumhierarchie befindet;

– Jeder Quellknoten kann einen oder mehrere direkt generierte Knoten, genannt, haben ähnlich;

– Der Zugriff auf jeden untergeordneten Knoten erfolgt über seinen unmittelbaren Quellknoten.

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

Reis. 4. Hierarchischer Pfad zum Zugriff auf einen Knoten

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

Netzwerkdatenmodelle basieren auch auf der Verwendung einer grafischen Form der Datendarstellung. Die Scheitelpunkte des Diagramms werden zur Interpretation der Entitätstypen und die Bögen zur Interpretation der Beziehungstypen verwendet. Das Netzwerkmodell der Wissensrepräsentation ist eine Datenstruktur, in der jedes Objekt im Gegensatz zu einer hierarchischen Repräsentation mehr als einen dominanten Knoten haben kann (Abb. 5).

Reis. 5. Netzwerkstruktur

In den 70er Jahren begann die aktive theoretische Forschung relationales Datenmodell. Mit dem Aufkommen von Personalcomputern begannen relationale Modelle den Markt für Informationssysteme zu dominieren. Relationale Darstellung von Wissen– Darstellung von Wissen in Form von Beziehungen.

Gemäß dem relationalen Datenmodell werden Daten als eine Reihe von Tabellen dargestellt, auf denen in Begriffen formulierte Operationen ausgeführt werden können relationale Algebra oder relationale Analysis.

Logisches Design

In der vorgeschlagenen Datenbankentwurfsmethodik ist der gesamte Entwicklungsprozess in drei Hauptphasen unterteilt: konzeptioneller, logischer und physischer Entwurf. Logisches Datenbankdesign ist der Prozess der Erstellung eines allgemeinen Informationsmodells eines Unternehmens auf der Grundlage individueller Benutzerdatenmodelle, das unabhängig von den Merkmalen des tatsächlichen DBMS und anderen physischen Bedingungen ist.

In der vorherigen Phase wurde eine Reihe lokaler konzeptioneller Datenmodelle erhalten, die das Verständnis der Benutzer für die Themenumgebung widerspiegeln. Allerdings können diese Modelle einige Datenstrukturen enthalten, die in herkömmlichen DBMS-Typen nur schwer zu implementieren wären. In diesem Stadium werden solche Datenstrukturen in eine Form umgewandelt, die bei der Implementierung in der Umgebung vorhandener DBMS keine Schwierigkeiten bereitet. Es sei darauf hingewiesen, dass diese Aktionen nicht Teil des logischen Designs von Datenbanken sind. Das vorgeschlagene Verfahren zwingt den Entwickler jedoch dazu, sorgfältiger über die Bedeutung jedes Datenelements nachzudenken, was sich positiv auf die Genauigkeit der Modelldarstellung der Merkmale eines bestimmten Unternehmens auswirkt. In dieser Phase werden die folgenden Aktionen ausgeführt:

1. Typverknüpfungen entfernen M:N.

2. Komplexe Verbindungen entfernen.

3. Entfernen rekursiver Verbindungen.

4. Entfernen von Links mit Attributen.

5. Mehrere Attribute entfernen.

6. 1:1-Verbindungen erneut prüfen.

7. Entfernen redundanter Verbindungen.

1. M:N-Verbindungen entfernen. Wenn das konzeptionelle Modell Verbindungen enthält wie M:N(„many-to-many“), dann sollten sie durch die Definition einer Zwischeneinheit eliminiert werden. Kommunikationstyp M:N wird durch zwei Verbindungen vom Typ 1 ersetzt: M, installiert mit der neu erstellten Entität.

Betrachten Sie als Beispiel Folgendes M:N Kommunikation: Die Zeitung druckt Anzeigen über Mietobjekte (Abb. 6)

Reis. 6. M:N Verbindung

Um diese Beziehung aufzulösen, definieren wir eine Zwischenentität ANNOUNCEMENT und erstellen zwei neue Beziehungen vom Typ 1: M. Dadurch entsteht eine Verbindung wie M:N durch zwei Bindungen ersetzt (Abb. 7).

Reis. 7. Anschlüsse vom Typ 1: M

2. Komplexe Verbindungen entfernen. Eine komplexe Beziehung besteht zwischen drei oder mehr Arten von Entitäten. Wenn im konzeptionellen Modell eine komplexe Beziehung besteht, sollte diese mithilfe einer Zwischeneinheit gelöst werden. Die komplexe Verbindung wird durch die erforderliche Anzahl binärer Verbindungen vom Typ 1 ersetzt: M, installiert mit der neu erstellten Entität. Beispielsweise spiegelt die Dreifachbeziehung „Zu vermieten“ (dargestellt durch eine Raute) die Beziehung wider, die zwischen dem Mitarbeiter des Unternehmens, der den Mietvertrag vermittelt, dem Grundstück und dem Mieter besteht (Abb. 8).

Reis. 8. Komplexe Kommunikation

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

In unserem Beispiel kann die Beziehung „Zu vermieten“ durch die Einführung einer neuen schwachen Entität namens „Vereinbarung“ beseitigt werden. Die neu erstellte Entität wird durch drei neue binäre Links mit den ursprünglichen Entitäten verbunden (Abb. 9).

Reis. 9. Vereinfachen Sie komplexe Kommunikation

3. Entfernen rekursiver Verbindungen. Rekursive Beziehungen 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 die Definition einer Zwischeneinheit aufgelöst werden. Um beispielsweise eine Situation darzustellen, in der einer der Arbeiter eine Gruppe anderer Arbeiter verwaltet, kann eine rekursive Eins-zu-viele-Beziehung erstellt werden (1: M).

4. Entfernen von Links mit Attributen. Wenn es im konzeptionellen Modell Beziehungen gibt, die über eigene Attribute verfügen, müssen diese durch die Schaffung einer neuen Entität transformiert werden. Stellen Sie sich beispielsweise eine Situation vor, in der es erforderlich ist, die Anzahl der Arbeitsstunden zu erfassen, die von Zeitarbeitskräften in jeder Abteilung des Unternehmens geleistet werden. Die Beziehung „Arbeitet in“ hat ein Attribut namens „Gearbeitete Stunden“. Lassen Sie uns die Beziehung „Arbeitet in“ in eine Entität namens „Verteilung nach Abteilung“ umwandeln, der wir das Attribut „Arbeitsstunden“ zuweisen, und erstellen Sie dann zwei neue Beziehungen vom Typ 1: M.

5. Mehrere Attribute entfernen. Mehrere Attribute sind solche, die mehrere Werte für dieselbe Instanz einer Entität haben können. Wenn im konzeptionellen Modell ein Mehrfachattribut vorhanden ist, sollte es durch Definition einer neuen Entität konvertiert werden. Um beispielsweise eine Situation darzustellen, in der dieselbe Unternehmensniederlassung mehrere Telefonnummern hat, definierte das konzeptionelle Modell ein Mehrfachattribut „Telefonnummer“, das sich auf die Entität „Firmenniederlassung“ bezieht. Dieses Mehrfachattribut sollte entfernt werden, indem eine neue Telefonentität definiert wird, die über ein einzelnes einfaches Telefonnummernattribut verfügt, und eine neue Beziehung vom Typ 1 erstellt wird.

6. Überprüfen Sie die Typverbindungen erneut 1:1. Der Entitätsdefinitionsprozess hat möglicherweise zwei verschiedene Entitäten erstellt, die tatsächlich dasselbe Objekt in der Anwendungsdomäne darstellen. Beispielsweise könnten zwei Entitäten „Abteilung“ und „Abteilung“ erstellt werden, die eigentlich denselben Objekttyp repräsentieren. Mit anderen Worten: Der Name „Abteilung“ ist gleichbedeutend mit dem Namen „Abteilung“. In einem solchen Fall sollten diese beiden Einheiten zu einer Einheit zusammengefasst werden. Wenn die Primärschlüssel der zusammenzuführenden Entitäten unterschiedlich sind, wählen Sie einen davon als Primärschlüssel aus und geben Sie den anderen als Alternativschlüssel an.

7. Entfernen redundanter Verbindungen. Eine Verbindung ist redundant, wenn dieselben Informationen nicht nur über sie, sondern auch über eine andere Verbindung erhalten werden können. Sie sollten immer danach streben, minimale Datenmodelle zu erstellen. Daher sollte die redundante Kopplung entfernt werden, wenn sie nicht eindeutig erforderlich ist. Die Feststellung, dass zwischen zwei Entitäten mehr als eine Beziehung besteht, ist recht einfach. Daraus folgt jedoch noch nicht, dass eine der beiden Verbindungen zwingend redundant ist, da beide unterschiedliche, tatsächlich in der Organisation existierende Assoziationen repräsentieren können.

Bei der Eliminierung von Zugriffsredundanz ist das Timing von großer Bedeutung. Stellen Sie sich beispielsweise eine Situation vor, in der es notwendig ist, die Beziehungen zwischen den Entitäten „Mann“, „Frau“ und „Kind“ zu modellieren. Es ist offensichtlich, dass es zwischen den Entitäten „Mensch“ und „Kind“ zwei Zugangswege gibt: Der eine führt über die direkte Kommunikation Ist der Vater“ und das andere – durch Verbindungen „Verheiratet mit“ und „Ist Mutter“. Auf den ersten Blick scheint es einen Zusammenhang zu geben 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, wir modellieren jedoch nur die aktuelle Ehe des Vaters (über eine 1:1-Beziehung). Zweitens können Vater und 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 „Ist der Vater“-Beziehung modelliert werden (Abb. 10).

Reis. 10. Beziehung zwischen den Entitäten „Mann“, „Frau“, „Kind“


Verwandte Informationen.


VORTRAG

Entity-Relationship-Modell.

Grundkonzepte: Essenz, Eigenschaften, Beziehungen.

Darstellung von Entitäten, Eigenschaften, Beziehungen

9.1. Modell „Entity-Relationship“

Das gebräuchlichste Mittel zur Modellierung des Themenbereichs von Systemen, die sich auf die Verarbeitung von Sachinformationen konzentrieren, ist das „Entity-Relationship“-Modell ( Entität – Beziehungsmodell – ER M), erstmals 1976 von Peter Ping-Sheng Chen vorgeschlagen. Dieses Modell wird traditionell in der Strukturanalyse und im Design verwendet, implementiert jedoch im Wesentlichen einen objektbasierten Ansatz zur Domänenmodellierung.

Das Entity-Relationship-Modell ist die Grundlage für eine beträchtliche Anzahl kommerzieller CASE-Produkte, die den gesamten Entwicklungszyklus von Datenbanksystemen oder seine einzelnen Phasen unterstützen. Gleichzeitig unterstützen viele von ihnen nicht nur die Phase der konzeptionellen Gestaltung des Themenbereichs des zu entwickelnden Systems, sondern ermöglichen auch die Durchführung der logischen Entwurfsphase auf Basis des mit ihren Mitteln erstellten Modells durch automatische Generierung ein konzeptionelles Datenbankschema für das ausgewählte DBMS, beispielsweise ein Datenbankschema für einen SQL-Server oder ein Objekt-DBMS.

Die Modellierung des Themenbereichs basiert in diesem Fall auf der Verwendung grafischer Diagramme, die eine relativ kleine Anzahl von Komponenten umfassen (Folie 2) und vor allem – Bautechnik solche Diagramme.

Semantische Basis ER -Modelle gehen von folgenden Annahmen aus:

- Der Teil der realen Welt (eine Menge miteinander verbundener Objekte), über den Informationen in die Datenbank aufgenommen werden sollen, kann sein präsentiert als Gesamtheit Entitäten;

- Jede Entität verfügt über charakteristische Eigenschaften (Attribute), die sie von anderen Entitäten unterscheiden und dies ermöglichen identifizieren;

- Entitäten können nach Entitätstypen klassifiziert werden: Jede Instanz einer Entität (die ein Objekt darstellt) kann einer Klasse zugewiesen werden – Typ Entitäten, von denen jede Instanz gemeinsame Eigenschaften hat und sie von Entitäten anderer Klassen unterscheidet;

- Die klassenbasierte Darstellungssystematisierung geht im Allgemeinen von einer hierarchischen Abhängigkeit von Typen aus: der Typentität A Ist Untertyp WesenB, wenn jede Instanz vom Typ A ist eine Instanz einer Entität vom TypB;

- Beziehungen zwischen Objekten können dargestellt werden als Kommunikation– Entitäten, die dazu dienen, die gegenseitige Abhängigkeit zweier oder mehrerer Entitäten aufzuzeichnen (darzustellen).

Hier ist noch einmal der informative Charakter des Konzepts hervorzuheben Wesen und seine Beziehung zu materiellen oder imaginären Objekten des Themenbereichs. Jedes Subjektdomänenobjekt verfügt über Eigenschaften, von denen einige als charakteristisch – aus Sicht der angewandten Aufgabe bedeutsam – unterschieden werden. In diesem Fall beispielsweise im Prozess der Analyse und Systematisierung eines Themengebiets, Klassen– eine Sammlung von Objekten, die über denselben Satz von Eigenschaften verfügen, die im Formular angegeben sind Attributsätze(Attributwerte für Objekte derselben Klasse können natürlich unterschiedlich sein). Dementsprechend entspricht auf der Ebene der Darstellung des Themenbereichs (d. h. seines infologischen Modells) ein als Konzept betrachtetes Objekt (ein Objekt im menschlichen Geist) dem Konzept Wesen; Ein Objekt als Teil der materiellen Welt (und unabhängig vom menschlichen Bewusstsein existierend) entspricht dem Konzept Entitätsinstanz; die Klasse der Objekte entspricht dem Konzept Entitätstyp.

Da das infologische Modell nicht einzelne Instanzen von Objekten, sondern Klassen betrachtet, werden wir im Folgenden nicht zwischen den entsprechenden Konzepten dieser beiden Ebenen unterscheiden, d. h. wir gehen von der Identität der Begriffe aus Objekt Und Wesen, Objekteigenschaft Und Entitätseigentum.

An Folie 3 Dies ist ein Beispiel für eine Entitätsdarstellung, die nicht vollständig ist und nicht den Anspruch erhebt, einer Version der Konstruktion von ER-Diagrammen exakt zu entsprechen.

Das ER-Modell als Beschreibung des Themenbereichs muss Objekte und Beziehungen zwischen ihnen definieren, d.h. Stellen Sie Verbindungen der folgenden zwei Arten her:

1. Verbindungen zwischen Objekten und Mengen charakteristischer Eigenschaften und definieren somit die Objekte selbst;

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

Wie bereits erwähnt, basiert die ER-Modellierung eines Themenbereichs auf der Verwendung grafischer Diagramme als einfache (vertraute), visuelle und gleichzeitig informative und mehrdimensionale Möglichkeit zur Darstellung von Projektkomponenten.

Wesen. Eine Entität, durch die eine Klasse ähnlicher Objekte modelliert wird, wird als „ein Objekt, das eindeutig identifiziert werden kann“ definiert. So wie jedes Objekt durch eine Reihe von Eigenschaftswerten eindeutig gekennzeichnet ist, muss auch eine Entität dies tun bestimmt werden so was Satz von Attributen, was es ermöglichen würde, 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 sein dürfen). Um beispielsweise jede Instanz der Entität „Mitarbeiter“ eindeutig zu identifizieren, wird das Attribut „Tab.Nummer“ eingeführt, das aufgrund seiner Natur immer einen eindeutigen Wert innerhalb des Unternehmens hat. Das heißt, ein eindeutiger Bezeichner einer Entität kann ein Attribut, eine Kombination von Attributen, eine Kombination von Beziehungen oder eine Kombination von Beziehungen und Attributen sein, die jede Instanz einer Entität eindeutig von anderen Instanzen einer Entität desselben Typs unterscheidet.

Die Entität hat Name, einzigartig innerhalb des Modells. Gleichzeitig Entitätsname- Das Typname und nicht eine bestimmte Instanz.

Entitäten sind unterteilt in stark Und schwach. Eine Entität ist schwach, wenn ihre Existenz von einer anderen Entität abhängt – stark im Verhältnis zu ihr. Beispielsweise ist die Entität „Untergeordneter“ im Vergleich zur Entität „Mitarbeiter“ schwach: Wenn ein Datensatz gelöscht wird, der einem Mitarbeiter mit Untergebenen entspricht, müssen auch die Informationen über die Unterordnung gelöscht werden.

Eigenschaften( Folie 4)

Die Art der Immobilie, wie Art der Verbindung Eigenschaften mit einer Entität (Objekt) können unterschiedlich sein. Schauen wir uns die wichtigsten Arten von Eigenschaften an.

Die Immobilie kann sein mehrere oder einzel– d.h. Ein Attribut, das eine Eigenschaft angibt, kann gleichzeitig mehrere Werte oder dementsprechend nur einen haben. Beispielsweise kann ein Mitarbeiter mehrere Fachgebiete haben, aber der einzige Wert ist „Tab. Nummer".

Die Immobilie kann sein einfach(unter dem Gesichtspunkt der angewandten Aufgaben keiner weiteren Aufteilung unterworfen) oder zusammengesetzt– wenn sein Wert aus den Werten einfacher Eigenschaften besteht. Beispielsweise ist die Eigenschaft „Geburtsjahr“ einfach und die Eigenschaft „Adresse“ zusammengesetzt, weil umfasst die Werte einfacher Eigenschaften „Stadt“, „Straße“, „Haus“.

In manchen Fällen ist es sinnvoll, zu unterscheiden Basic Und Derivate Eigenschaften. Beispielsweise könnte ein „Lieferant“ über die Eigenschaft „Gesamtzahl der gelieferten Teile“ verfügen, die durch Summierung der Anzahl der Teile berechnet wird, die er für ein Projekt liefert.

Wenn das Vorhandensein einer Eigenschaft für alle Instanzen einer Entität nicht zwingend erforderlich ist, wird eine solche Eigenschaft aufgerufen bedingt. Beispielsweise verfügen nicht alle Mitarbeiter über die Eigenschaft „akademischer Abschluss“.

Immobilienwerte können konstant sein – statisch, oder dynamisch, d.h. sich im Laufe der Zeit ändern. Beispielsweise ist die Eigenschaft „Tab. „Nummer“ ist statisch und „Adresse“ ist dynamisch. Die Immobilie kann sein unsicher, wenn es dynamisch ist, aber sein aktueller Wert noch nicht festgelegt wurde.

Die Immobilie kann als betrachtet werden Schlüssel, wenn seine Bedeutung einzigartig ist und möglicherweise in einem bestimmten Kontext die Entität eindeutig identifiziert. Zum Beispiel ein Untergebener eines bestimmten Mitarbeiters.

Verbindungen Zusätzlich zu den Verbindungen zwischen einem Objekt und seinen Eigenschaften spiegelt das infologische Modell die Verbindungen zwischen Objekten verschiedener Klassen wider. Verbindung ist definiert als „eine Vereinigung, die mehrere Einheiten vereint.“ Diese Assoziation kann immer zwischen verschiedenen Entitäten oder zwischen einer Entität und sich selbst bestehen (rekursive Beziehung).

Wie die Essenz ist auch die Verbindung Typ neues Konzept, d.h. Alle Instanzen verknüpfter Entitäten unterliegen Typbindungsregeln. Der grundlegende Unterschied zwischen den Arten der Beziehungen zwischen Typen und Instanzen wird in veranschaulicht Folien.

Entitäten, die durch eine Beziehung verbunden sind, werden genannt Teilnehmer. Grad der Verbindung bestimmt durch die Anzahl der Kommunikationsteilnehmer.

Wenn jede Instanz einer Entität an mindestens einer Instanz einer Beziehung teilnimmt, wird diese Beteiligung dieser Entität aufgerufen vollständig(oder obligatorisch); ansonsten - unvollständig(oder optional).

Die quantitative Art der Beteiligung von Entitätsinstanzen (einer oder mehrerer) wird angegeben Art der Verbindung(oder Kommunikationskraft). Folgende Typen sind möglich: „eins zu eins“(1:1), „eins zu viele“(1: M) , „viele zu eins“(M:1) , „viele zu viele“(MM) (Folien 5, 6, 7).

Es ist zu beachten, dass es sich bei dem Link-Tool um ein Mittel zur Darstellung handelt komplexe Objekte, von denen jedes als eine Menge von etwas miteinander verbundenen betrachtet werden kann einfache Objekte. Die Einteilung in einfache und komplexe Gegenstände sowie die Art der Beziehung sind bedingt und werden durch die Besonderheiten der Analyse des Fachgebiets bestimmt, d.h. letztendlich - durch die Art der Verwendung von Daten über Objekte bei gelösten angewandten Problemen. Darüber hinaus ist ein TEIL beispielsweise aus Sicht eines Designers ein komplexes Objekt, aus Sicht eines Lieferanten jedoch ein einfaches.

Unter den vielen Arten von Beziehungen sind die hierarchischen Beziehungen am häufigsten, z. B. „Teil-Ganzes“, „Gattung-Art“.

Zur Darstellung werden Teil-Ganzes-Beziehungen verwendet zusammengesetzte Objekte. Beispielsweise bestehen MASCHINEN aus EINHEITEN, EINHEITEN aus TEILEN. Beziehungen sind hier möglich „eins zu viele“ so und „viele zu viele“.

Gattungs-Art-Beziehung – zur Darstellung verallgemeinerte Objekte. Beispielsweise werden MITARBEITER nach Beruf in ENTWICKLER, PROGRAMMIERER, ARBEITNEHMER eingeteilt; PROGRAMMIERER – in ANWENDUNGSPROGRAMMIERER und SYSTEMPROGRAMMIERER. Hierarchische Beziehungen und insbesondere „ gattungsspezifisch„werden üblicherweise als Grundlage für die Klassifizierung von Objekten nach charakteristischen Merkmalssätzen verwendet. Darüber hinaus „Art“-Objekte erben„generische“ Eigenschaften.

Ein weiterer weit verbreiteter Beziehungstyp ist die Aggregation – die Kombination einfacher Objekte zu komplexen Objekten auf der Grundlage des Prinzips ihrer Zugehörigkeit Einheit oder ihre gemeinsame Teilnahme an einem Prozess. Aggregation, die hier als ein allgemeinerer Fall hierarchischer Beziehungen betrachtet wird, kombiniert Objekte unterschiedlicher Natur mit der einzigen gemeinsamen Eigenschaft der „gemeinsamen Teilnahme“. Aggregierte Objekte werden normalerweise durch Verbalsubstantive benannt, zum Beispiel: "Verbindung": ABTEILUNG besteht aus MITARBEITER; " Liefern": ANBIETER Lieferungen DETAILS.

Supertypen und Untertypen. Eine Entität kann in zwei oder mehr sich gegenseitig ausschließende Einheiten aufgeteilt werden Untertypen, die jeweils gemeinsame Attribute und/oder Beziehungen enthalten. Diese gemeinsamen Attribute und/oder Beziehungen werden einmalig auf einer höheren Ebene explizit definiert. Subtypen können ihre eigenen Attribute und/oder Beziehungen definieren. Grundsätzlich kann die Subtypisierung auf niedrigeren Ebenen fortgesetzt werden, in den meisten Fällen reichen jedoch zwei oder drei Ebenen aus.

Die Entität, auf deren Grundlage Subtypen bestimmt werden, wird aufgerufen Supertyp. Subtypen müssen einen vollständigen Satz bilden, d. h. Jede Instanz eines Supertyps muss zu einem Subtyp gehören. Manchmal ist es zur Vervollständigung des Satzes erforderlich, einen zusätzlichen Untertyp zu definieren, beispielsweise OTHERS.

Der Subtyp erbt die Eigenschaften und Beziehungen des Supertyps. Beispielsweise ist der Entitätstyp PROGRAMMER ein Untertyp der Entität EMPLOYEE. Programmierer haben alle Eigenschaften von Mitarbeitern und nehmen an der gesamten Kommunikation teil, aber das Gegenteil ist nicht der Fall.

Ein Entitätstyp, seine Untertypen, Untertypen dieser Untertypen usw. bilden Entitätstyphierarchie, ein Beispiel dafür ist in gegeben Folie 8.

9.2. ER-Diagramm

Wie bereits erwähnt, besteht eines der Hauptziele der semantischen Modellierung darin, sicherzustellen, dass die Ergebnisse der Analyse des Themenbereichs in einer relativ einfachen, visuellen, aber gleichzeitig formalisierten und ausreichend informativen Form wiedergegeben werden.

In diesem Sinne ist das ER-Diagramm eine sehr gute Lösung. Es kombiniert Funktions- und Informationsansätze, wodurch es möglich ist, sowohl die Menge der ausgeführten Funktionen als auch die durch Datenstrukturen spezifizierten Beziehungen zwischen Systemelementen darzustellen. Gleichzeitig ermöglicht Ihnen die grafische Form, die Typologie und Eigenschaften von Entitäten und Beziehungen in kompakter Form (aufgrund visueller Symbole) darzustellen, und die den ER-Diagrammen zugrunde liegenden Formalismen ermöglichen Ihnen im nächsten Schritt die Verwendung eines strikten Normalisierungsapparats der Gestaltung der logischen Struktur der Datenbank.

Entitäten.Jeder Entitätstyp in ER-Diagrammen wird als Rechteck dargestellt, das den Namen der Entität enthält. Als Namen werden meist Substantive (oder Phrasen eines Substantivs) im Singular verwendet. Um Entitäten schwacher Typen darzustellen, werden Rechtecke verwendet, deren Seiten mit Doppellinien gezeichnet sind. Zum Beispiel in dem hier vorgestellten Folie 9 Im ER-Diagramm ist SUBJECT eine Entität eines schwachen Typs.

Eigenschaften.Eigenschaften dienen dazu, den Zustand einer Entität oder Beziehung zu verdeutlichen, zu identifizieren, zu charakterisieren oder auszudrücken. Eigenschaften werden als Ellipsen angezeigt, die den Eigenschaftsnamen enthalten. Die Ellipse ist durch eine Linie mit der entsprechenden Entität oder Beziehung verbunden.

Wichtige Eigenschaftsnamen sind unterstrichen. Zum Beispiel die Eigenschaft „Tischnummer“ der Entität EMPLOYEE.

Der Umriss der Ellipse wird mit einer Doppellinie gezeichnet, wenn die Eigenschaft mehrwertig ist. Zum Beispiel die Eigenschaft „Spezialität“ der Entität EMPLOYEE.

Der Umriss der Ellipse wird mit einer gestrichelten Linie gezeichnet, wenn die Eigenschaft abgeleitet ist. Zum Beispiel die Eigenschaft „Menge“ der Entität LIEFERANT.

Die Ellipse wird durch eine gepunktete Linie verbunden, wenn die Eigenschaft bedingt ist. Beispielsweise ist die Eigenschaft „In.

Wenn eine Eigenschaft zusammengesetzt ist, werden ihre konstituierenden Eigenschaften durch andere Ellipsen angezeigt, die mit der zusammengesetzten Ellipse verbunden sind. Beispielsweise besteht die Eigenschaft „Adresse“ der Entität MITARBEITER aus den einfachen Eigenschaften „Stadt“, „Straße“ und „Haus“.

VerbindungenEine Beziehung ist eine grafisch dargestellte Verbindung zwischen Entitäten. Jede Art von Verbindung ER -Das Diagramm wird als Raute mit dem Namen der Verbindung darin angezeigt. Als Namen werden meist Verbalsubstantive verwendet.

Die Seiten der Raute werden mit doppelten Linien gezeichnet, wenn es sich um eine Verbindung zwischen einer Entität eines schwachen Typs und der Entität, von der sie abhängt, handelt. Zum Beispiel die Beziehung „Unterordnung“, die eine Entität des schwachen Typs SUBORDINATE mit der Entität EMPLOYEE verbindet, von der sie abhängt.

Kommunikationsteilnehmer werden über Leitungen mit der Kommunikation verbunden. Die Doppellinie bezeichnet die vollständige Beteiligung der Entität im Zusammenhang mit dieser Seite. Zum Beispiel die Beziehung „Unterordnung“ von Seiten der SUBJECT-Entität.

Die Beziehung kann durch Angabe einer Rolle geändert werden. Für die rekursive Verbindung „Komposition“ werden beispielsweise die Rollen angegeben: „Teil besteht aus...“ und „Teil enthalten enthalten …».

Der Verbindungstyp wird durch die Indizes „1“ oder „M“ über der entsprechenden Zeile angezeigt. Beispielsweise ist die „Management“-Beziehung eine Eins-zu-Viele-Beziehung: Ein Mitarbeiter kann viele Projekte verwalten; Die „Beteiligung“-Beziehung ist vom Typ Viele-zu-Viele: Ein Mitarbeiter kann an vielen Projekten teilnehmen, und viele Mitarbeiter können an einem Projekt teilnehmen.

Ein Beispiel für eine normalisierte Form eines ER-Diagramms ist in dargestellt Folie 10.

Eine Variante des Entity-Relationship-Modells wird in der IDEF1X-Notation verwendet, die Teil der IDEF-Standardfamilie ist.

Die grafische Sprache des Modells und ein Beispieldiagramm werden unter vorgestellt Folie 11 .

Optionale Beziehungen zwischen Entitäten Abteilung Und Mitarbeiter, Mitarbeiter Und Untergeordnet haben eine Eins-zu-Viele-Kardinalität (das Ende der „Viele“-Beziehung wird durch einen fetten Punkt angezeigt) und eine verbindliche Beziehung zwischen Entitäten Mitarbeiter Und Projekt hat eine Viele-zu-Viele-Kraft.

Grafische Elemente der Hauptnotationen des Entity-Relationship-Modells werden in dargestellt Folie 12 .


Diese Definition einer Verbindung als Entität besonderer Art spiegelt das Wesen des relationalen Ansatzes wider, der durch eine einheitliche Darstellung von Entitäten aller Art, einschließlich Verbindungen, durch Beziehungsvariablen gekennzeichnet ist.

Nach den Bestimmungen des relationalen Modells ist eine „richtige“ Beziehung nur eine Beziehung vom Typ „ viele zu viele“, da für deren Implementierung eine eigene Relationsvariable erstellt wird. Verbindungen „eins zu eins“, „eins zu viele“ kann immer mit einem Fremdschlüsselmechanismus von einem von dargestellt werden Beziehungsvariablen.

Fachgebiet und zu lösende Aufgaben. Daher ist es im relationalen Datenmodell, das wir im „Relationalen Datenmodell“ untersuchen werden, unmöglich, andere deklarative Integritätsbeschränkungen als Primär-, Eindeutigkeits- und Fremdschlüssel festzulegen. Die Beschreibung verfahrensrechtlicher Einschränkungen liegt in der Regel außerhalb dieses Modells.

Das im Folgenden diskutierte Entity-Relationship-Modell (ER-Diagramm, ER-Modell) ist ein Sonderfall semantischer Datenmodelle. Damit können Sie Semantiken beschreiben, die für den menschlichen Gebrauch bestimmt sind. Das heißt, Sie können Beschreibungen eingeben, die nicht in der Software implementiert sind. Andererseits werden die Metadaten und Integritätsbeschränkungen aufgezeichnet, die zum Erstellen von Skripten verwendet werden, die das Datenbankschema generieren.

2.1 Semantische Modelle und kognitiver Aspekt

2.1.1 Semantische Datenmodelle

Was speichern Datenbanken? Natürlich Daten. Doch auch bei der Organisation der Datenspeicherung muss man die damit verbundenen Bedeutungen berücksichtigen. Im vorherigen Abschnitt wurde beispielsweise ein Primärschlüssel beschrieben, der doppelte Datensätze in einem Satz verhindert. Diese Eigenschaft definiert die private Bedeutung eines Recordsets mit einem Primärschlüssel. Datentypen, Domänen, Metadaten definieren andere Bedeutungen der gespeicherten Daten.

Aber wenn nur Daten in der Datenbank gespeichert sind, wie werden dann die Bedeutungen gespeichert? Bedeutungen sind zunächst einmal auch Daten, die mit den Daten verknüpft sind, deren Bedeutung sie darstellen.

Lassen Sie uns die folgenden Arten von Bedeutungen hervorheben:

  • Bedeutungen, die nur für Menschen bestimmt sind. Sie können in Informationssystemen (IS) gespeichert werden, sind aber passiv, also für das System unzugänglich, und haben daher keinen Einfluss auf dessen Verhalten. Kann nur von Menschen geborgen werden
  • IS-interne Bedeutungen. Sie sind aktiv, das heißt, sie verändern oder schaffen neues Verhalten des IS. Typische Beispiele: Schlüssel, Datentypen, Metadaten.
  • Externe Bedeutungen im Zusammenhang mit Systemen oder Aufgaben außerhalb des IS oder, genauer gesagt, der Datenbank. Diese Bedeutungen sind auch aktiv.

Wie manifestiert sich die Aktivität innerer Bedeutungen? Es soll einen Primärschlüssel geben. Sie möchten einen Datensatz in ein Set schreiben. Allerdings wird das DBMS zunächst das tun, was Sie nicht verlangt haben – es prüft die Gültigkeit des eingegebenen Schlüsselwerts – und schreibt nur dann einen Datensatz, wenn dieser Wert fehlt.

Ein Beispiel für die dritte Bedeutungsart: Es gibt eine Tabelle mit den Noten aller Studierenden aller Fachrichtungen. Ist es möglich, die durchschnittliche Punktzahl zu berechnen? Sicherlich. Wenn Sie sich jedoch mit Messskalen auskennen, wissen Sie, dass Leistung anhand einer Ordnungsskala gemessen wird. Darin hat die durchschnittliche Punktzahl keine Aussagekraft bzw. ist im offiziellen Sprachgebrauch eine unzureichende Statistik.

In der Anfangsphase der Erstellung einer Anwendung (Geschäftsanalyse) ist ein Domänenmodell erforderlich, das eine informelle Beschreibung aller wesentlichen Merkmale des Problems liefert, die dem Designer bekannt sind. Gleichzeitig kann das Verwerfen von Details, die nicht in die in der Projektumsetzungsphase verwendeten Datenmodelle passen, zu einer erheblichen Verzerrung der Problemstellung führen. In der Analysephase sollte die Vollständigkeit der Informationen der Möglichkeit ihrer formalen Beschreibung vorgezogen werden.

Semantische Modelle werden im Allgemeinen als Modelle bezeichnet, die eine Darstellung der Semantik von Daten liefern. Wie andere Modelle können sie strukturelle, manipulative und ganzheitliche Teile umfassen. Da jedoch in jedem Modell eine Art Semantik vorhanden ist, können Modelle, die mehr Semantik enthalten, als semantisch betrachtet werden als „nicht-semantische“ Modelle, die wenig Semantik enthalten. Diese Pseudodefinition ist sehr vage. Aber das reicht uns vorerst.

Innerhalb des semantischen Modells wird ein konzeptionelles Datenbankschema erstellt, das normalerweise manuell oder automatisch (aber nicht automatisch) in ein Datenbankschema umgewandelt wird, das im Rahmen von Datenmodellen gültig ist, die in den folgenden Phasen des Projektlebenszyklus implementiert werden – Design, Entwicklung und Wartung.

Die Datensemantik wird in der Vorlesung „Datenbanksemantik“ des Lehrbuchs ausführlich besprochen.

Das bekannteste semantische Entity-Relationship-Modell (ER) wurde 1976 von Peter Chen vorgeschlagen.

2.1.2 Kognitiver Aspekt

Semantische Modelle werden in Form von für Menschen lesbaren Diagrammen implementiert. In der modernen Wissenschaft im Allgemeinen und in der Informatik im Besonderen wird den kognitiven Aspekten große und verdiente Aufmerksamkeit geschenkt. Im Kontext von Datenbanken bedeutet dies, die beiden Hauptakteure – Menschen und Programme – zu identifizieren und natürliche, menschenfreundliche Modelle, Sprachen, Schnittstellen und Algorithmen für das Benutzererlebnis zu entwickeln. Selbstverständlich ist die berufliche Vorausbildung des Nutzers zu berücksichtigen, die neben dem Alltagswissen die mentale Welt eines Menschen, die Menge an Bildern (Gestalten), mit denen er operiert, bestimmt. Warum erwarten wir ein Kopfmenü oben im Fenster? Nur weil uns die Entwickler einiger erfolgreicher Softwareprodukte dies beigebracht haben.

2.1.3 Modellebenen

In Anlehnung an Peter Chens bahnbrechende Arbeit zu Entity-Relationship-Diagrammen unterscheiden wir vier Ebenen der Datenmodelldarstellung mit leicht modifizierten Definitionen:

  1. Informationen über Objekte und Beziehungen der Domäne (Software), ausgedrückt in Softwarebegriffen (konzeptionelles Modell).
  2. Strukturierte Informationen über Software, dargestellt in Bezug auf Informationssysteme (logisches Modell).
  3. Datenstrukturen, die unabhängig von der Zugriffsmethode sind, also keinen Bezug zu Datenstrukturen, Suche, Indizierung usw. haben (physikalisches Modell).
  4. Datenstrukturen abhängig von der Zugriffsmethode (Hardware-Level-Modell).

Mit Blick auf die Zukunft stellen wir fest, dass sich das relationale Modell auf die Ebenen 2 und 3 bezieht. Die Netzwerk- und hierarchischen Modelle, wie sie vor 20 Jahren existierten, funktionieren hauptsächlich auf den Ebenen 3 und 4. UML umfasst die Ebenen 1, 2 und 3, aber UML geht weit über die Beschreibung von Daten hinaus. Das Entity-Relationship-Modell funktioniert auf den Ebenen 1 und 2.



Aktie