Ich versuche, ein Entity-Relationship-Diagramm für eine Transportunternehmensdatenbank zu erstellen. Diese Datenbank sollte Informationen über Briefe , Lieferungen , das Verschieben von Briefen von einem Lager in ein anderes und historische Informationen speichern . Es sollte die Verfolgung von Briefen ermöglichen , z. B. die Überprüfung, welche Briefe zu einem bestimmten Zeitpunkt in einem bestimmten Lager waren .

Der Prozess, den ich modellieren möchte, sieht folgendermaßen aus:

• Brief wird vom Absender abgeholt und geht ins Lager ,
• dann könnte es zwischen Lagern übertragen werden ,
• endlich Brief wird geliefert an Empfänger .

Geschäftsregeln

• Briefe werden von Personen gesendet und empfangen , ein Brief kann von einer bestimmten Person gesendet und auch von einer bestimmten Person empfangen werden .
• Es können sich viele Personen in der Datenbank befinden. Wenn eine Person in der Datenbank gespeichert ist, muss sie Absender oder Empfänger eines Briefes sein .
• Transporte werden zwischen verschiedenen Lagern durchgeführt und müssen aus vielen Briefen bestehen . Briefe können Teil mehrerer Transporte sein (zu unterschiedlichen Terminen ).
• In Lagern werden mehrere Briefe gespeichert
• Ein Brief kann in einigen verschiedenen gespeichert werden Lager auf verschiedenen Daten (auf '01 .11' ist es in ‚Lager A‘, und auf '02 .11' in ‚Lager B‘)
• DateStorage - enthält Informationen darüber, wann ein Brief in einem bestimmten Lager eingetroffen ist
• Transporte werden an einem bestimmten Datum durchgeführt , sie verlassen ein Lager und gehen zu einem anderen.
• Briefe können an Empfänger zugestellt werden. Wenn der Zustellversuch fehlschlägt, kann es zu weiteren Versuchen kommen.

Aktuelles Diagramm

Dies ist das Datenbankdiagramm, das ich bisher erstellt habe:

Die Beziehung zwischen Briefen und Lagern bedeutet, dass Briefe, die per Kurier abgeholt werden, in dieses Lager gebracht werden.

Fragen und aktuelle Überlegungen

Ist dieses Diagramm korrekt, was könnte ich verbessern?

Ist es in Ordnung, dass es eine Beziehung zwischen Transporten und Lagern gibt (von der aus früheren Transporten und dem ursprünglichen Lager des Briefes abgeleitet werden könnte)?

Obwohl Sie angegeben haben, dass die in Ihrem Diagramm dargestellte Struktur Teil eines Universitätsprojekts ist, sollte das Ziel darin bestehen, es so realistisch wie möglich zu gestalten. Daher denke ich, dass die Durchführung eines Interviews (oder einer Reihe von Interviews) mit den Experten einer Korrespondenz Unternehmen könnte sehr hilfreich sein (vielleicht unverzichtbar).

Auf diese Weise würde die Erstellung eines vollständigen und genauen Entity-Relationship-Diagramms (oder eines seiner Derivate) für diese Art von Geschäftsdomäne eine viel eingehendere Prüfung (und damit eine sehr lange Reihe von Aufgaben und) erfordern Das Ziel dieser Antwort ist es, Sie in Bezug auf die technischen Methoden, die Sie möglicherweise anwenden müssen, in die richtige Richtung zu weisen und eine Expository-Analyse zu präsentieren, die meinen ersten Entwurf eines IDEF1X-Modells enthält, das aus Elementen besteht, die machbar erscheinen , damit Sie es als Referenz verwenden können, um die Bedeutung eines realen Szenarios zu erfassen .

Zentrale Aspekte

So wie ich es sehe, sind die Aspekte der Geschäftsbereichsanalyse, die besondere Aufmerksamkeit erfordern, die Ereignisse, an denen ein Brief beteiligt sein könnte; Daher werde ich im Folgenden einen hypothetischen Kontext detailliert beschreiben , der aus einigen vermuteten Ereignistypen besteht , die relevant erscheinen (aber natürlich sollten Sie alle besprochenen Punkte selbst bestätigen, ändern oder verwerfen).

Überlegungen

Ich habe die Elemente aufgelistet (die in dem Vortrag über den Chat angesprochen wurden ), die ich für besonders hilfreich halte, um an der Weiterleitung der Situation zu arbeiten:

• [A] Ich würde jederzeit gerne wissen, wo sich der Brief befindet - egal ob er sich in einem Lagerhaus befindet oder transportiert wird.
• In meinem Design ist der Absender nur der ursprüngliche Absender eines Briefes (Kunde des Unternehmens) und der Empfänger (Empfänger) eine Person, an die Briefe gerichtet sind - es gibt immer einen Absender und einen Empfänger für einen Brief.
• [F] oder ein Transport kann es nur einen Kurier geben.
• Ein Brief kann in bis zu 10 Lagern aufbewahrt werden. Die Anzahl aller Lager ist jedoch viel höher - wenige Hundert (oder vielleicht sogar Tausende).
• Meine Idee war es, jeden Kunden (Absender / Empfänger) in einer Datenbank zu speichern. Wenn also eine Person mindestens einen Brief gesendet oder empfangen hat, befindet sich dieser […] in der Datenbank (wenn eine Person jedoch mehr Briefe sendet / empfängt, befindet er sich nur einmal in der Datenbank).

Geschäftsregeln

Dann habe ich basierend auf (a) solchen Elementen, (b) dem Inhalt Ihrer Frage und (c) einigen Schätzungen und Annahmen, die als realisierbar erscheinen , die folgenden Formulierungen geschrieben, die die vorläufigen Wechselbeziehungen zwischen den hypothetischen Entitätstypen von Bedeutung beschreiben (d. H. ein wesentlicher Teil der Geschäftskontextregeln , die dem Zweck dienen, das entsprechende konzeptionelle Modell zu definieren):

Person, Brief und Adresse

• Ein Brief wird von genau einer Person gesendet (die die Rolle des Absenders spielt )
• Eine Person sendet null, eins oder viele Briefe
• Ein Brief spricht genau eine Person an (die die Rolle des Adressaten wahrnimmt )
• Eine Person (die die Rolle des Adressaten ausübt ) wird in null-eins-oder-vielen Briefen angesprochen
• Eine Person behält null, eins oder viele Adressen
• Eine Adresse wird von null, eins oder vielen Personen geführt
• Eine Adresse lokalisiert den Absender von null, eins oder vielen Briefen
• Eine Adresse findet den Adressaten von null, eins oder vielen Buchstaben

Brief und Ereignis

• Ein Brief ist an Eins-zu-Viele- Veranstaltungen beteiligt
• Ein Ereignis wird von genau einem klassifiziert Eventtype
• Ein Ereignis ist
  • entweder ein Versand ¹
  • oder ein Ausgang ²
  • oder ein Transport ³
  • oder ein HalfwayStorage ⁴
  • oder ein DeliveryAttempt ⁵
  • oder ein Empfang ⁶

_{¹ Versand . Das Ereignis , das auftritt, wenn eine bestimmte Person einen bestimmten Brief in einem bestimmten Lager hinterlässt , damit sie an einem Transportprozess teilnehmen kann.}

_{² Beenden . Das Ereignis , das auftritt, wenn ein bestimmter Brief ein bestimmtes Lager verlässt , um den Transport zu starten.}

_{³ Transport . Das Ereignis , das auftritt, wenn ein bestimmter Brief während des Transports zwischen verschiedenen Lagern verschoben wird.}

_{⁴ Lagerung auf halbem Weg . Das Ereignis , das auftritt, wenn ein konkreter Brief mitten im Transport in einem genauen Lager aufbewahrt wird.}

_{⁵ Lieferversuch . Das Ereignis , das auftritt, wenn eine bestimmte Person (die die Rolle des Kuriers spielt ) versucht, einen bestimmten Brief an die Person zu senden, die darin angesprochen wurde.}

_{⁶ Empfangen . Das Ereignis , das auftritt, wenn ein bestimmter Brief in der Adresse eingeht, in der sich die Person befindet , die in diesem Brief angesprochen wurde .}

_{Hinweis: Einige dieser Ereignistypen (oder Ereignistypen ) können in Bezug auf einen bestimmten Brief mehrmals auftreten (z. B. kann ein Brief während eines gesamten Transportprozesses an mehreren Transportereignissen beteiligt sein). Andere Arten von Ereignissen scheinen auf ein eindeutiges Ereignis in Bezug auf einen konkreten Transportprozess beschränkt zu sein (z. B. Versand und Empfang ). Andererseits kann eine echte Geschäftsdomäne mehr Ereignistypen beinhaltenund diejenigen, die in dieser Antwort besprochen werden, treffen möglicherweise einfach nicht zu oder weisen unterschiedliche Merkmale auf. Deshalb ist es von größter Bedeutung, eine Analyse selbst durchzuführen. Darüber hinaus sind die Begriffe, die ich hier verwende, lediglich erklärend, da sie möglicherweise nicht denen entsprechen, die in einer realen Organisation verwendet werden.}

Warehouse und die verschiedenen Subtypen des Ereignisses: Dispatch, Exit und HalfwayStorage

• In einem Lagerhaus werden null, eins oder viele Sendungen abgelegt
• Ein Warehouse ist der Ursprung von Null-Eins-oder-Viele- Exits
• Ein Warehouse ist das Ziel von Zero-One-or- Many - Exits
• Ein Warehouse bietet null, eins oder viele HalfwayStorages

Fahrzeug und die verschiedenen Subtypen des Ereignisses: Exit, Transport und DeliveryAttempt

• Ein Fahrzeug wird in Null-Eins-oder-Viele- Ausgängen verwendet
• Ein Fahrzeug wird in Null-Eins-oder-Viele- Transporten eingesetzt
• Ein Fahrzeug wird in Null-Eins-oder-Viele- Lieferversuchen verwendet

Person und die Subtypen des Ereignisses: Transport, Zustellversuch und Empfang

• Eine Person (die die Rolle des Kuriers spielt ) befördert null, eins oder viele Transporte
• Eine Person (die die Rolle des Kuriers spielt ) übermittelt null, eins oder viele Zustellversuche
• Eine Person (die die Rolle des Kuriers spielt ) nimmt an Eins-Eins-Eins-Eins- Empfängen teil

Illustratives IDEF1X-Modell

Folglich baute ich ein IDEF1X ^ein Modell in Bezug auf alle Punkte oben erläutert. Es ist in Abbildung 1 dargestellt (klicken Sie auf den Link, damit Sie ihn mit einer höheren Auflösung betrachten können):

_{^eine Definition Integration für Information Modeling ( IDEF1X ) ist eine sehr empfehlenswerte Datenmodellierungstechnik, die als etabliert wurde Standard im Dezember 1993 von den Vereinigten Staaten National Institute of Standards and Technology (NIST). Es basiert fest auf (a) einigen theoretischen Arbeiten, die vom Urheber des relationalen Modells verfasst wurden , dh Dr. EF Codd ; zu (b) der von Dr. PP Chen entwickelten Entity-Relationship-Sichtweise ; und auch auf (c) der Logical Database Design Technique, erstellt von Robert G. Brown.}

Ereignis und seine Untertypen

Wie in diesem Modell gezeigt, entsteht eine Supertyp-Subtyp- Beziehung

• zwischen Event(dem Supertyp ) und
• Dispatch, Exit, Transport, HalfwayStorage, DeliveryAttemptUnd Receiving(die Subtypen ).

Der EventSuperentitätstyp besitzt die Eigenschaften, die allen seinen Subtypen gemeinsam sind, dh LetterNumberund DateTime(als zusammengesetzter PRIMARY KEY [PK der Kürze halber] verfügbar gemacht ), zusammen mit einem Diskriminator , dh EventTypeCode, der die genaue Art der Subtypinstanz angibt, die sein muss jedes EventVorkommen ergänzen .

Die PKs von Dispatch, Exit, Transport, HalfwayStorage, DeliveryAttemptund Receivingist, zur gleichen Zeit, Fremdschlüssel (FKs), die auf das EventPK.

Jeder dieser Untertypen zeigt die Eigenschaften (oder Attribute) an, die ausschließlich für jeden von ihnen gelten, und einige dieser Eigenschaften sind FKs, die die Beziehungen veranschaulichen, die solche Untertypen zu einigen der anderen im Modell enthaltenen Entitätstypen haben.

In dieser Hinsicht könnten Sie meine Antworten auf Hilfe finden

• „Modellierung eines Szenarios, in dem jeder Musikkünstler entweder eine Gruppe oder ein Solist ist“ ;

• "Wie modelliere ich einen Entitätstyp, der verschiedene Sätze von Attributen haben kann?" ;;

• "Modellierung einer Datenbankstruktur für mehrere Benutzertypen und deren Kontaktinformationen" ;

• und die Antworten gruppiert von der Untertypen Etikett.

Datenproben

Sie haben nicht geklärt, ob das Diagramm als konzeptionelle Plattform zum Erstellen einer logischen Datenbankstruktur (mit geeigneten Tabellen, Spalten, Spaltentypen und Einschränkungen) für ein bestimmtes SQL-Datenbankverwaltungssystem verwendet werden soll. Einige Datenbeispiele in Tabellenform werden dies jedoch tun helfen, eine rundere Antwort zu liefern, die weitere Möglichkeiten einführt.

Eine EventType-Tabelle

Eine Tabelle, die für den EventTypeEntitätstyp steht, würde eine Nachschlagerolle erfüllen und kann die folgenden Zeilen umfassen:

 + -—————————————- + -————————————————- +-————————————— ——- +
 | EventTypeCode | Name              | Beschreibung      |
 + -—————————————- + -————————————————- +-————————————— ——- +
 | D | Versand | Das Ereignis, dass… |
 + --------------- + ------------------ + -------------- --- +
 | E | Beenden | Das Ereignis, dass… |
 + --------------- + ------------------ + -------------- --- +
 | T | Transport | Das Ereignis, dass… |
 + --------------- + ------------------ + -------------- --- +
 | H | Auf halbem Weg Lagerung | Das Ereignis, dass… |
 + --------------- + ------------------ + -------------- --- +
 | D | Lieferversuch | Das Ereignis, dass… |
 + --------------- + ------------------ + -------------- --- +
 | R | Empfangen | Das Ereignis, dass… |
 + --------------- + ------------------ + -------------- --- +

Beachten Sie, dass die EventTypeCodeSpalte, die als PK eingeschränkt werden muss, aussagekräftige Werte enthält (und daher aus Sicht des Endbenutzers gut lesbar ist), wodurch ihre Verwendung verbessert wird, wenn auf Spalten mit FK-Einschränkungen verwiesen wird. Da sich die oben genannten Werte physikalisch leicht sind (hinsichtlich ihrer Größe in Bytes), verhalten sie sich in Bezug auf Datenabrufprozesse recht schnell und optimieren den Speicherplatzverbrauch (hauptsächlich, wenn von FKs darauf hingewiesen wird).

Eine Ereignistabelle

Nehmen wir dann an, dass eine Tabelle, die den genannten Entitätstyp angibt Event, die Datenpunkte enthält, die für den Buchstaben folgen, der hauptsächlich durch die Nummer 1750 gekennzeichnet ist :

 + -————————————- + -—————————————————————— +-——————— ——————- +
 | LetterNumber | RegisteredDateTime       | EventTypeCode |
 + -————————————- + -—————————————————————— +-——————— ——————- +
 | 1750 | 2016-11-12 16: 58: 12.000 | D |
 + -------------- + ------------------------- + -------- ------- +
 | 1750 | 2016-11-15 09: 12: 05.000 | E |
 + -------------- + ------------------------- + -------- ------- +
 | 1750 | 2016-11-15 10: 12: 05.000 | T |
 + -------------- + ------------------------- + -------- ------- +
 | 1750 | 2016-11-15 11: 12: 05.000 | T |
 + -------------- + ------------------------- + -------- ------- +
 | 1750 | 2016-11-15 12: 12: 05.000 | T |
 + -------------- + ------------------------- + -------- ------- +
 | 1750 | 2016-11-15 12: 46: 01.000 | H |
 + -------------- + ------------------------- + -------- ------- +
 | 1750 | 2016-11-17 06: 24: 07.000 | T |
 + -------------- + ------------------------- + -------- ------- +
 | 1750 | 2016-11-17 07: 24: 07.000 | T |
 + -------------- + ------------------------- + -------- ------- +
 | 1750 | 2016-11-17 08: 24: 07.000 | T |
 + -------------- + ------------------------- + -------- ------- +
 | 1750 | 2016-11-17 09: 10: 13.000 | H |
 + -------------- + ------------------------- + -------- ------- +
 | 1750 | 2016-11-18 08: 01: 01.000 | T |
 + -------------- + ------------------------- + -------- ------- +
 | 1750 | 2016-11-18 09: 01: 01.000 | T |
 + -------------- + ------------------------- + -------- ------- +
 | 1750 | 2016-11-18 09: 27: 12.000 | H |
 + -------------- + ------------------------- + -------- ------- +
 | 1750 | 2016-11-19 11: 16: 08.000 | D |
 + -------------- + ------------------------- + -------- ------- +
 | 1750 | 2016-11-19 11: 48: 03.000 | R |
 + -------------- + ------------------------- + -------- ------- +

Wie gezeigt, würde diese Tabelle eine Folge aller Ereignisse enthalten, an denen der Buchstabe Nr. 1750 während eines Transports beteiligt war . Natürlich würde es alle Ereignisse mit allen relevanten Briefen in Verbindung halten , aber ich habe nur einige hypothetische Zeilen dargestellt, die sich auf einen vermuteten Buchstaben Nummer 1750 beziehen , um das Beispiel zu vereinfachen. Die in dieser Tabelle enthaltene Art der „chronologischen“ Datenstruktur wird üblicherweise als Zeitreihe bezeichnet .

Die Event.EventTypeCodeSpalte, die als FK eingeschränkt werden sollte, enthält Werte, die die Art des registrierten Ereignisses angeben (auf benutzerfreundliche Weise gemäß den im vorherigen Abschnitt genannten Punkten).

Anwendungsprogramme, die Daten aus Tabellen gemeinsam nutzen, die die Untertypen darstellen

Eine Tabelle mit Teilereignisinformationen (wie die zuvor berieten) kann in beispielsweise eine Seite eines Web - Anwendungsprogramm angezeigt werden , die einen Link sieht vor, dass Umleitungen auf den folgenden Seiten auf Basis von (a) dem Ereignistyp , (b) der Brief Nummer und (c) Datum und Uhrzeit des Ereignisses von Interesse.

Auf den folgenden Seiten werden wiederum die vollständigen Ereignisinformationen angezeigt. ZB wenn

• das EventTypeCodeist D ,
• das LetterNumberist 1750 und
• das DateTimeist 2016-11-12 16: 58: 12.000 ,

dann muss die Umleitung zu einer Seite führen, die die vollständige DispatchZeile enthält, z.

 + -————————————- + -——————————————————————- + -———————— ————————- +
 | LetterNumber | RegisteredDateTime       | WarehouseNumber |
 + -————————————- + -——————————————————————- + -———————— ————————- +
 | 1750 | 2016-11-12 16: 58: 12.000 |               x |
 + -------------- + ------------------------- + -------- --------- +

Für den Fall, dass

• das EventTypeCodeist T ,
• das LetterNumberist 1750 und
• das DateTimeist 2016-11-15 10: 12: 05.000 ,

Die Umleitung sollte zu einer Seite führen, auf der die Informationen der gesamten TransportZeile aufgeführt sind:

 + -————————————- + -——————————————————————- + -———————— ———————- + -—————————- + -————————- + -—————————- +
 | LetterNumber | RegisteredDateTime       | Fahrzeugnummer | CourierId | Breitengrad | Längengrad |
 + -————————————- + -——————————————————————- + -———————— ———————- + -—————————- + -————————- + -—————————- +
 | 1750 | 2016-11-12 16: 58: 12.000 |              w |         x |        y |         z |
 + -------------- + ------------------------- + -------- -------- + ----------- + ---------- + ----------- +

Integrität, Konsistenz und Ableitbarkeit

Offensichtlich ist eine Datenbankstruktur mit diesen Merkmalen mit einer Reihe von Einschränkungen verbunden, die zum Schutz der Integrität der Daten festgelegt werden müssen, um ihre Konsistenz mit den auf konzeptioneller Ebene festgelegten Regeln zu gewährleisten (z. B. den Kardinalitäten der Beziehungen zwischen Entitätstypen /). Entitätstypinstanzen).

Einige dieser Einschränkungen können deklarativ über PK- und FK-Definitionen konfiguriert werden, andere erfordern jedoch einen prozeduralen Ansatz - aufgrund von Einschränkungen in den deklarativen Funktionen, die von den wichtigsten SQL-Datenbankverwaltungssystemen bereitgestellt werden.

Zu den Regeln, die prozessual durchgesetzt werden müssen, gehört das Merkmal, dass (1) jede Event Zeile jederzeit durch (2) das jeweilige Gegenstück in genau einer der Tabellen ergänzt werden muss, die die Untertypen darstellen , denen (3) „entsprechen“ muss. Der in der Event.EventTypeCodeSpalte enthaltene Wert - steht für den Diskriminator -, sodass die Verwendung von ACID TRANSACTIONS zweckmäßig ist, um sicherzustellen, dass diese Umstände immer erfüllt sind. Eine andere Möglichkeit wäre der Einsatz von TRIGGERS, aber sie neigen dazu, die Dinge chaotisch zu machen.

Und ja, es wäre praktisch, mehrere Abfragen auszudrücken und zu korrigieren, die Daten aus einigen oder allen zugehörigen Tabellen „kombinieren“, um beispielsweise die entsprechende Datenableitung zu vereinfachen.