Es ist großartig, dass Sie sich die Zeit nehmen, die Daten, mit denen Sie sich befassen, zu verstehen, zu klassifizieren und zu modellieren, da dies nach meiner persönlichen Erfahrung den gesamten Entwicklungsprozess einfacher und sehr flexibel für zukünftige Änderungen macht. Und ich bin mir ziemlich sicher, dass Sie sich dessen auch schon bewusst sind.
Vorläufiges Datenmodell und angenommene Geschäftsregeln
Ich habe eine Liste von Geschäftsregeln definiert, die ich angenommen habe, nachdem ich Ihre Frage gelesen und Ihre Diagramme genau untersucht habe, um mein Verständnis Ihrer Spezifikationen zu beschreiben. Nachdem ich eine solche Liste definiert hatte, leitete ich ein IDEF1X [1] -Datenmodell ab, das ich als PDF-Dokument auf eine externe Plattform (Dropbox) hochladen wollte, da dieses Datenmodell aufgrund seines Formats nicht gut in ein eingebettetes Bild passt. Diese beiden Instrumente werden als Referenz für einige wichtige Punkte nützlich sein, die ich unten im Abschnitt mit dem Titel "Zu lösende Aspekte" aufführe, um weiter voranzukommen .
Hier ist zunächst die…
Da dies nur vorläufig ist, betrachten Sie es als ein Mittel, das uns hilft, das gewünschte endgültige Datenmodell zu erreichen.
Angenommene Geschäftsregeln
Das vorläufige Datenmodell wurde aus einer Sammlung von Geschäftsregeln abgeleitet (abgeleitet aus Ihrer Frage), die ich wie folgt aufzählen werde:
Organisationen und Profile
Beachten Sie, dass dies Profile
derzeit als Synonym für verstanden wird Person
.
- An
Organization
ist ein Freund von eins zu vielen Profiles
.
- An
Organization
ist ein Freund von eins zu vielen Organizations
.
- An
Organization
ist Mitglied von Eins-zu-Viele Organizations
.
- A
Profile
ist Mitglied von Eins-zu-VieleOrganizations
.
- A
Profile
ist ein Freund von eins zu vielen Profiles
.
- A
Profile
ist Mitglied von Eins-zu-Viele Profiles
.
Standorte und Adressen
- Ein
Organization
besitzt eins zu viele Locations
.
- A
Location
wird nach Eins-zu-Viele klassifiziert LocationTypes
( zu einem bestimmten Zeitpunkt nur einer ).
- A
Location
kann eine Eins-zu-viele Addresses
( eins Physical
, eins für Shipping
, eine für Billing
, oder eines , das alle genannten Zwecken dient, oder ein und verbindet zwei Zwecke und andere , die dazu dient nur einer von ihnen).
Ein Address
durch gehalten werden eins-zu-viele Profiles
oder, anders ausgedrückt, eine Profile
hält eine Eins-zu-viele Addresses
.
Eine spezifische Address
kann verwendet werden , indem eine Eins-zu-viele Profiles
(wie dient Physical
für einen Profile
, für die verwendeten Billing
durch einen anderen , etc.). Also Address
funktioniert ein in ähnlicher Weise für Locations
und Profiles
.
- Somit kann eine einzelne
Address
sein kann, zur gleichen Zeit , des Typs Physical
, Shipping
und Billing
.
Standorte und Rollen
- A
Location
öffnet eins zu viele Roles
.
- A
Role
kann in Eins-zu-Viele durchgeführt werden Locations
.
- A
Profile
(nachdem sie als gesetzt worden ist Member
ein Organization
) kann durchführt eine Eins-zu-viele Roles
, in einer Eins-zu-viele Locations
(aber nur eine bestimmten Role
in jedem Location
zu einem bestimmten Zeitpunkt, dh nie zwei oder mehr Roles
zur gleichen Zeit ).
Aspekte, die gelöst werden müssen, um weiter voranzukommen
Um die Auflösung Ihres Datenmodells weiter voranzutreiben, finden Sie hier eine Liste relevanter Punkte, die uns bei der Erarbeitung dieses Ziels helfen werden, dieses Ziel zu erreichen:
Ich habe angenommen, dass der Begriff Profile
in Ihrem Kontext eine ähnliche (oder dieselbe) Bedeutung hat wie der von Person
, aber er könnte etwas anders sein. Würden Sie auf diese Weise sagen, dass in Ihrem Szenario die Entitäten Organization
und Person
Subtypen von sind Profile
?
Kann ein Profile
(oder Person
) eigene one-to-many EmailAddresses
, oder eine Profile
(oder Person
) auf feste genau ein EmailAddress
?
Möchten Sie die Möglichkeit bieten, Organization
über Telephone
und kontaktiert zu werden Email
, oder möchten Sie einschränken, dass dies nur für ein Profile
(oder Person
) möglich ist?
Ich gehe davon aus, dass ein Location
zu fest ist genau ein Address
von der Art Physical
, ist das richtig?
Ist es möglich , dass ein Location
durch geteilt werden eins-zu-viele unterschiedliche Organizations
oder sonst eine Location
von owned werden kann nur ein Organization
?
Sie haben über Kommentare erklärt, dass die Tatsache, a Member
und a zu sein, Friend
dieselbe ist. Wie Sie in meinem vorgeschlagenen vorläufigen Datenmodell sehen können, habe ich Ihre ursprünglichen Spezifikationen befolgt und alle möglichen Kombinationen von Mitgliedschaft und Freundschaft zwischen Organization
und Profile
(oder Person
) in verschiedenen Entitäten dargestellt, da ich denke, dass dies hilfreich sein kann, um das bestmögliche zu definieren Struktur für diesen Teil Ihres Szenarios. In diesem Sinne:
- Ich gehe davon aus, dass die Aussage
an Organization is a Member of another Organization
andere Auswirkungen hat als die Aussage a Profile (or Person) is a Member of an Organization
bezüglich der aufgerufenen Entität Location
.
- Wie Sie im Datenmodell sehen können, denke ich, dass das
Role
of Owner
nur für ein Organization
und für mich das gültige Roles
für ein Profile
(oder Person
) innerhalb eines Location
are Admin
und gilt Member
. Was denkst du über all das? Da Sie in direktem Kontakt mit den für Ihre Situation geltenden Geschäftsregeln stehen, müssen Sie mir mitteilen, ob meine Annahmen korrekt sind.
Kann ein Profile
(oder Person
) Roles
innerhalb desselben anders spielen Location
? dh sie kann eine Person
sein, zugleich die Admin
und auch ein Member
von der gleichen Location
? Was sind die Regeln in dieser Hinsicht?
Ich denke, dass das gleiche Profile
(oder Person
) Roles
in verschiedenen unterschiedlich spielen kann Locations
. Zum Beispiel: Ein bestimmtes Profile
(oder Person
) ist der "Admin" in Location
"1", und dasselbe Profile
(oder Person
) ist gleichzeitig ein " Member
" in Location
"2". Habe ich recht?
Ist es möglich, dass eine bestimmte Person gleichzeitig Location
eine andere hat LocationTypes
, oder ist eine Person Location
fest entschlossen, genau eine zu halten LocationType
?
Stellt das Attribut Organization.Website
die Website-Adresse einer bestimmten Organisation dar, z. B. "dba.stackexchange.com"?
Wenn Profile
"1" (verstanden als Person
) eine Member
(oder Friend
) von Profile
"2" ist, ist es dann möglich, dass Profile
"1" eine Role
in einem Location
Besitz von Profile
"2" ausführt ? Ich denke, dass solche Szenarien nur für die Beziehungen zwischen a Organization
und a gelten Member
Person
. Was denken Sie?
In ähnlicher Weise ist es möglich , dass Organization
"1" , wenn "1" eine Member
(oder Friend
) von Organization
"2" ist Organization
, eine Role
in einer Location
von Organization
"2" gehaltenen Ausführung ausführt ? Auch hier denke ich, dass diese Art von Szenarien nur für die Beziehungen zwischen a Organization
und a gültig Member
Person
ist. Ist das richtig?
In dieser Hinsicht - während ich diese Fragen schreibe - halte ich es für vernünftig zu sagen, dass es nur drei verschiedene Arten von Beziehungen gibt, die Organizations
und betreffen Persons
, und wir können definieren:
- (a) Die Beziehung zwischen an
Organization
und a Person
als " Membership
".
- (b) Die Beziehung zwischen a
Person
und einem anderen unterscheidet sich Person
als " Friendhip
".
- (c) Wir müssen noch einen aussagekräftigen Namen finden , um die Beziehung zwischen einem Individuum
Organization
und einem anderen Menschen zu beschreiben Organization
.
- Lassen Sie mich wissen, was Sie über (a), (b) und (c) denken.
Ist es möglich Organization
, dass ein Friend
(oder ein Member
) von einem zu vielen verschiedenen Organizations
gleichzeitig ist? Oder es ist nur möglich, dass ein Organization
nur eine Beziehung zu ausschließlich einem anderen hatOrganization?
Aufeinanderfolgendes Datenmodell, das den ersten Fortschritt darstellt
In Anbetracht Ihrer Antworten und Beschlüsse zu den oben aufgeführten anstehenden Aspekten habe ich Folgendes erstellt:
Obwohl ich mich damit noch nicht ganz wohl fühle, drückt dieses neue Datenmodell die folgenden Geschäftsregeln aus:
- A
Profile
ist entweder ein Organization
oder ein Person
. [2]
- A
Profile
kann der Opferfreund von Eins-zu-Viele sein FriendProfiles
, und A Profile
kann der akzeptierende Freund von Eins-zu-Viele sein FriendProfiles
. [3]
- A
Location
kann aus Eins-zu-Viele bestehen Locations
. [4]
Antworten auf Ihre nachfolgenden spezifischen Kommentare
Es ist wirklich interessant für mich, die Trennung von Bedenken zu notieren / zu verschärfen [z. B. LocationAddress und ProfileAddress] - denn ich wollte sie offensichtlich alle ohne die richtigen Beziehungen aufnehmen und halten [komischerweise fühlte es sich bei meiner ursprünglichen ERD nicht richtig an].
Ja, das ist ein guter Vergleich, obwohl ich es nicht als Trennung von Bedenken bezeichnen würde (was sicherlich ein grundlegendes Prinzip bei der Programmierung und dem Design von Anwendungen ist), da dieser Begriff üblicherweise die Phase der Anwendungsentwicklung betrifft und wir uns derzeit in der Stadium des Verstehens der Daten und des Entwurfs ihrer logischen Struktur.
Aus meiner persönlichen Erfahrung denke ich, dass diese Phase damit zu tun hat, die wesentlichen Dinge in ihren gesamten Kontext zu stellen, und damit, die Assoziationen zu sehen, die zwischen den verschiedenen Entitäten bestehen, die für das jeweilige interessierende Szenario relevant sind, und dann Darstellung dieser Dinge in einem Datenmodell. Im konkreten Fall , auf dem Sie kommentieren, die Address
Unternehmen können verschiedene Arten von Verbindungen mit anderen Einheiten, eine mit Profile
und eine andere mit Location
.
Und ja, wenn sich etwas nicht richtig oder natürlich anfühlt , kann dies ein Zeichen dafür sein, dass man sich mehr anstrengen muss, um die relevanten Daten zu verstehen. Auf diese Weise ist die Address
Entität eines der Dinge, die meiner Meinung nach mehr Aufmerksamkeit erfordern, da ich denke, dass die Beziehung zwischen a Profile
und a mittels der Entität gehandhabt werden Address
könnteLocation
(aufgrund der Tatsache, dass jede Location
mindestens eine physische haben muss Address
), also wir könnten die entlassen ProfileAddress
assoziative Einheit in dem neuesten Modell dargestellt, aber Sie sollten analizing diese Punkte weiter und lassen Sie mich Ihre Ideen.
Ist es in IDEF1X auch üblich, die PK / FK-Bezeichnungen in Entitäten zu ändern, um die Lesbarkeit zu verbessern [z. B. ProfileId - LocationOwnerProfileId]?
Ja, das ist eine sehr kluge Bemerkung von Ihnen, da IDEF1X die Verwendung von Rollennamen für die Bezeichnung von AUSLÄNDISCHEN SCHLÜSSELN empfiehlt, um die Bedeutung solcher Attribute entsprechend der Entität zu erfassen , in der sie verwendet werden. Es ist auch erwähnenswert, dass dies auch stark mit dem Konzept der Migration von Primärschlüsseln zusammenhängt . Tatsächlich geht die Verwendung von Rollennamen IDEF1X voraus, da sie ursprünglich von Dr. EF Codd in seinem wegweisenden Text von 1970 vorgestellt wurde. Auf diese Weise kann man deutlich die Genauigkeit erkennen, die der IDEF1X-Standard gegenüber dem relationalen Modell beibehält .
Ich wäre neugierig zu erfahren, was Sie nicht besonders mögen / fühlen, dass es nicht modelliert, mit / in der Lösung?
Abgesehen von den oben bereits beschriebenen Details über das Address
Unternehmen bin ich mir nicht sicher, ob die Roles
von einem bestimmten Unternehmen Profile
bestimmten Location
für ein Organization
oder ein Unternehmen äquivalent sind Person
. Aus meiner Sicht muss Person
zuerst ein mit einem verknüpft werden Organization
, und dann Organization
würde dies dazu bestimmt , ein bestimmtes Person
auszuführen , aber Sie kennen das Szenario besser, sodass diese Regeln möglicherweise unnötig sind. In diesem Zusammenhang werde mich über die Tatsache betonen , dass es sehr hilfreich wäre für mich die kontextuelle Beschreibung oder weiß Bedeutung , dass die künftigen Nutzer dieser Datenstruktur geben zu , undRole
Location
Organization
Profile
Location
Ich verstehe jedoch, dass dies als vertrauliche Information angesehen werden kann, daher wäre dies eine Einschränkung.
Mit der aktuellen Struktur scheint es, als ob jeder ( Organization
oder Person
) mit jedem (wieder Organization
oder Person
) verwandt sein kann und alles ( Role
) überall ( Location
) tun kann ( ), aber perharps ist dies genau das, was Sie und die Benutzer von dieser Datenbank erwarten , für die Sie natürlich genau definierte Einschränkungen angeben. Wenn dies der Fall ist, bieten wir fast eine endgültige Lösung. Da in dieser Situation natürlich Ihre Meinung entscheidend ist, sollten Sie diese Ideen auch analysieren und mir dann Ihre Schlussfolgerungen mitteilen, damit wir die letzten Schritte unternehmen können.
Machbarer zweiter Vorschuss
Leider hat die Kommunikation vor ein paar Wochen aufgehört, ich denke wegen der Arbeitsverpflichtungen, die Sie erfüllen müssen, was völlig vernünftig ist. Ich wäre viel zufriedener gewesen, wenn wir ein stabileres und robusteres Modell entwickelt hätten, aber aufgrund unserer früheren Interaktionen kann ich davon ausgehen, dass ich Sie in die richtige Richtung weisen konnte.
Zusätzlich zu dem, was bereits in diesem Frage- und Antwortprozess vorgestellt wurde, halte ich es für hilfreich für andere Suchende mit einem ähnlichen Problem, eine neue Weiterentwicklung der vorherigen Datenmodelle bereitzustellen. Also habe ich die…
Organisationen und Profile Vorläufiges Datenmodell - Zweiter Fortschritt
Wie in einem solchen Datenmodell zu sehen ist, habe ich die Viele-zu-Viele- Beziehung, die ich in den vorhergehenden Modellen zwischen Profile
und dargestellt habe Address
, entfernt, da ein gegebenes Profile
bereits über sein Eigentum mit Eins-zu-Viele in Beziehung steht .Addresses
Locations
Eine weitere Änderung, die in diesem neuen Fortschritt veranschaulicht wird, ist die Tatsache, dass sie jetzt die Möglichkeit beinhaltet, dass eine gegebene Location
Person eins zu viele gehören kann Profiles
. Folglich habe ich die geändert Location
PRIMARY KEY (durch Abweisung LocationOwnerProfileId
Attribut) und dann ein assoziatives Entität (hinzugefügt many-to-many ) , das bezieht sich Profile
mit Location
.
Anmerkungen
1. IDEF1X ist eine sehr empfehlenswerte Datenmodellierungstechnik, dieim Dezember 1993 vom US-amerikanischen National Institute of Standards and Technology ( NIST )als Standard definiert wurde.
2. Dies ist ein Auftreten eines (Super-) Typ-Subtyp-Clusters . Falls Sie interessiert sind, finden Sie hier eine Antwort, in der ich mich eingehender mit dieser Art von Beziehungen befasse.
3. Ein Beispiel für eine hierarchische Beziehung von vielen zu vielen , die der Struktur sehr ähnlich ist, die die endgültige Lösung für die „Problem der Teileexplosion“ . Eine solche Lösung wurde natürlich von Dr. Edgar Frank Codd in seinem 1970 enorm einflussreichen Artikel „Ein relationales Datenmodell für große gemeinsam genutzte Datenbanken“ vorgestellt .
4. Als solches ist dies eine Instanz von a Eins-zu-Viele (oder Viele-zu-Eins) hierarchischen Beziehung .