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 Profilederzeit als Synonym für verstanden wird Person.
- An
Organizationist ein Freund von eins zu vielen Profiles .
- An
Organizationist ein Freund von eins zu vielen Organizations .
- An
Organizationist Mitglied von Eins-zu-Viele Organizations .
- A
Profileist Mitglied von Eins-zu-VieleOrganizations .
- A
Profileist ein Freund von eins zu vielen Profiles .
- A
Profileist Mitglied von Eins-zu-Viele Profiles .
Standorte und Adressen
- Ein
Organizationbesitzt eins zu viele Locations .
- A
Locationwird nach Eins-zu-Viele klassifiziert LocationTypes( zu einem bestimmten Zeitpunkt nur einer ).
- A
Locationkann 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 Addressdurch gehalten werden eins-zu-viele Profiles oder, anders ausgedrückt, eine Profilehält eine Eins-zu-viele Addresses .
Eine spezifische Addresskann verwendet werden , indem eine Eins-zu-viele Profiles (wie dient Physicalfür einen Profile , für die verwendeten Billingdurch einen anderen , etc.). Also Addressfunktioniert ein in ähnlicher Weise für Locationsund Profiles.
- Somit kann eine einzelne
Addresssein kann, zur gleichen Zeit , des Typs Physical, Shipping und Billing .
Standorte und Rollen
- A
Locationöffnet eins zu viele Roles .
- A
Rolekann in Eins-zu-Viele durchgeführt werden Locations .
- A
Profile(nachdem sie als gesetzt worden ist Memberein Organization) kann durchführt eine Eins-zu-viele Roles , in einer Eins-zu-viele Locations (aber nur eine bestimmten Rolein jedem Locationzu 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 Profilein 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 Organizationund PersonSubtypen 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 Telephoneund 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 Locationzu fest ist genau ein Address von der Art Physical, ist das richtig?
Ist es möglich , dass ein Locationdurch geteilt werden eins-zu-viele unterschiedliche Organizations oder sonst eine Locationvon owned werden kann nur ein Organization ?
Sie haben über Kommentare erklärt, dass die Tatsache, a Memberund a zu sein, Frienddieselbe 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 Organizationund 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 Organizationandere Auswirkungen hat als die Aussage a Profile (or Person) is a Member of an Organizationbezüglich der aufgerufenen Entität Location.
- Wie Sie im Datenmodell sehen können, denke ich, dass das
Roleof Ownernur für ein Organizationund für mich das gültige Rolesfür ein Profile(oder Person) innerhalb eines Locationare Adminund 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) Rolesinnerhalb desselben anders spielen Location? dh sie kann eine Personsein, zugleich die Adminund auch ein Membervon der gleichen Location? Was sind die Regeln in dieser Hinsicht?
Ich denke, dass das gleiche Profile(oder Person) Rolesin 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 Locationeine andere hat LocationTypes, oder ist eine Person Locationfest entschlossen, genau eine zu halten LocationType?
Stellt das Attribut Organization.Websitedie 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 Rolein einem LocationBesitz von Profile"2" ausführt ? Ich denke, dass solche Szenarien nur für die Beziehungen zwischen a Organizationund 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 Rolein einer Locationvon Organization"2" gehaltenen Ausführung ausführt ? Auch hier denke ich, dass diese Art von Szenarien nur für die Beziehungen zwischen a Organizationund a gültig Member Personist. 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 Organizationsund betreffen Persons, und wir können definieren:
- (a) Die Beziehung zwischen an
Organizationund a Personals " Membership".
- (b) Die Beziehung zwischen a
Personund einem anderen unterscheidet sich Personals " Friendhip".
- (c) Wir müssen noch einen aussagekräftigen Namen finden , um die Beziehung zwischen einem Individuum
Organizationund 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 Organizationsgleichzeitig ist? Oder es ist nur möglich, dass ein Organizationnur 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
Profileist entweder ein Organization oder ein Person. [2]
- A
Profilekann der Opferfreund von Eins-zu-Viele sein FriendProfiles , und A Profilekann der akzeptierende Freund von Eins-zu-Viele sein FriendProfiles . [3]
- A
Locationkann 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 AddressUnternehmen können verschiedene Arten von Verbindungen mit anderen Einheiten, eine mit Profileund 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 AddressEntität eines der Dinge, die meiner Meinung nach mehr Aufmerksamkeit erfordern, da ich denke, dass die Beziehung zwischen a Profileund a mittels der Entität gehandhabt werden Address könnteLocation (aufgrund der Tatsache, dass jede Locationmindestens eine physische haben muss Address), also wir könnten die entlassen ProfileAddressassoziative 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 AddressUnternehmen bin ich mir nicht sicher, ob die Rolesvon einem bestimmten Unternehmen Profilebestimmten Locationfür ein Organizationoder ein Unternehmen äquivalent sind Person. Aus meiner Sicht muss Personzuerst ein mit einem verknüpft werden Organization, und dann Organizationwürde dies dazu bestimmt , ein bestimmtes Personauszufü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 , undRoleLocationOrganizationProfileLocationIch 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 ( Organizationoder Person) mit jedem (wieder Organizationoder 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 Profileund dargestellt habe Address, entfernt, da ein gegebenes Profilebereits über sein Eigentum mit Eins-zu-Viele in Beziehung steht .AddressesLocations
Eine weitere Änderung, die in diesem neuen Fortschritt veranschaulicht wird, ist die Tatsache, dass sie jetzt die Möglichkeit beinhaltet, dass eine gegebene LocationPerson eins zu viele gehören kann Profiles . Folglich habe ich die geändert LocationPRIMARY KEY (durch Abweisung LocationOwnerProfileIdAttribut) und dann ein assoziatives Entität (hinzugefügt many-to-many ) , das bezieht sich Profilemit 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 .