Konzeptionelle ERD Multi-Tabelle viele zu viele oder möglicherweise rekursiv?


11

Ich erstelle ein konzeptionelles Diagramm [ja, ich weiß, dass ich Attribute und Schlüssel eingefügt habe - aber dies ist nur für mich, um zu konsolidieren, was ich während des Lernens mache] - also behandeln Sie es bitte als konzeptionell mit dem Fokus auf Beziehungen und Tabellen und nicht wie man Diagramme erstellt;)

Meine geistige Hürde ist: Ich versuche herauszufinden, wie ich die Beziehungen zwischen Profil, Standort und Organisation am besten modellieren kann.

Zunächst einmal REGELN:

  • Ein oder mehrere Profile können Mitglieder / Freunde einer oder mehrerer Organisationen sein . und umgekehrt.
  • Ein oder mehrere Profile können Mitglieder / Freunde anderer Profile sein.
  • Eine oder mehrere Organisationen können Mitglieder / Freunde anderer Organisationen sein.

Geben Sie hier die Bildbeschreibung ein

Freund und Mitglied unterscheiden sich darin, dass Freunde schreibgeschützt sind und Mitglieder [je nach Stufe] vollen Zugriff haben, um Änderungen vorzunehmen.

Um die Sache noch weiter zu verkomplizieren, haben Standorte ihre eigenen "weiteren" verfeinerbaren Regeln, z. B. Eine Organisation besitzt zwei Standorte . Abhängig von den Standortregeln kann ein Mitglied [ Profil ] dieser Organisation an einem Standort vollen Zugriff haben, jedoch nur eingeschränkten Zugriff auf den Standort andere. [Entschuldigung: Sie müssen das Bild höchstwahrscheinlich in einem anderen Fenster öffnen, um eine bessere Anzeigegröße zu erzielen.]

Geben Sie hier die Bildbeschreibung ein

Wie Sie sehen können, ist das Konzept von Profilen und Organisationen sehr ähnlich, ebenso wie das noch zu modellierende Konzept von Freunden und Mitgliedern [..., von dem ich mir vorstelle, dass es ähnlich wie die aktuellen Zwischentabellen mit der Einstellung Eigentümer / behandelt wird Admin / Mitglied / Freund usw. im Datensatz]. Deshalb denke ich an folgendes Konzept:

Siehe Option 2 im obigen Bild: Dadurch werden die aktuellen Tabellen " Organisation" und " Organisationsorte" und ihre Beziehungen entfernt und durch die Organisationstabelle "Option 2" als etwas rekursive Beziehung zu " Profil" ersetzt .

Ich nehme an, der Kern der Sache ist, ob ich zu programmatisch auf Polymorphismus bedacht bin oder nicht, zum Nachteil der Einfachheit und Flexibilität, was mich völlig verwirrt;)

Vielen Dank für Ihre Gedanken im Voraus, sehr geschätzt - M :).

Überarbeitetes Diagramm: https://i.imagestash.io/kDoqKQyOme.jpg

Als Antwort auf die Fragen von MDCCL:

  1. Ja, das Profil besteht aus einer Person und hat dieselbe Bedeutung - obwohl Ihre Begründung lautet - ich glaube, Sie haben Recht: Organisation und Person könnten Untertypen des Profils sein ; Daher besteht ein Profil entweder aus einer Person oder einer Organisation.
  2. Eine E-Mail-Adresse pro Profil.
  3. Ja. Wie oben sollte die Organisation mindestens eine E-Mail-Adresse haben.
  4. Richtig, eine feste Adresse.
  5. Es ist eine Möglichkeit, aber eine Seltenheit - obwohl nach dem, was ich lerne - sollte man dies für zukünftige Langlebigkeit usw. modellieren, und nur um zu bestätigen, dass ein Standort daher mehr als einer Person gehören könnte.
  6. Die Lage ist definitiv die integrale Einheit zwischen den meisten anderen. Vielleicht werde ich kurz und bündig klären, was hier kurz und bündig getan werden kann, und Sie dann meine anderen Antworten durchlesen lassen, die hoffentlich zuerst nützliche Ergänzungen zu dieser Frage beinhalten [ siehe dann meine Antwort auf # 6 am Ende ];) Re: The Role Owner. An **Organization** can be an Owner of zero or more **Locations**. A Person can be an owner of zero of more Locations[daher, wie Sie zuvor vermutet haben; Einfach ausgedrückt kann ein Profil Eigentümer von null oder mehr Standorten sein.

  7. Ja, ein Profil , das eines ist Besitzer eines Standorts übernimmt alle Rollenberechtigungen [super user]; Ein Profil , das ein Administrator ist, kann bestimmte Details des Standorts ändern , hilft / bearbeitet jedoch hauptsächlich die Details / Daten, die über alle anderen Profile bereitgestellt werden. Dies wird hauptsächlich von "Basismitgliedern" des Standorts / der Standorte bereitgestellt . Dadurch bleibt das Basismitglied übrig , das alle zugehörigen Standortdetails schreibgeschützt und Daten bereitstellen kann, die von einem Administrator / Eigentümer überprüft werden müssen . Darüber hinaus jedes Profil[Organisation / Person] ist ähnlich wie ein Basis - Mitglied ‚read-only‘ - lassen Sie sich Begriff ihnen einen Gast - aber nur , wenn die Lage so eingestellt ist öffentliches [und nicht Privat ], obwohl sie nicht Eingang wie ein liefern Basis - Mitglied kann .

  8. Richtig.
  9. Ihre Intuition ist unglaublich! Ja, it is foreseen that a single Location could contain one to many LocationTypesum die Sache noch komplizierter zu machen, wird erwartet, dass diese einzelnen Standorttypen unterschiedliche Berechtigungen für Profile haben, die dem übergeordneten Standort zugeordnet sind. Davon würden Berechtigungen vom Speicherort auf den Standorttyp / die Standorttypen heruntergefiltert [ähnlich wie Sicherheitsberechtigungen für Betriebssystemordner]. Ich stelle über Ihr Diagramm fest, dass Sie sich möglicherweise eher auf Typ als Beschreibung beziehen.
  10. Ja.
  11. Siehe 12.
  12. Richtig, die Fähigkeit von Profil1 [Person oder Organisation], auf Standorte im Besitz von Profil2 [Person oder Organisation] zu reagieren [wenn sie Freunde / Mitglieder mit korrekten Berechtigungen sind], ist von größter Bedeutung.
  13. Sehr vernünftig - a) zustimmen. b) zustimmen. c) Ja, hmm? ... Vielleicht sollte es ähnlich sein wie Profil [Person] zu Profil [Person] = Freunde . Unabhängig von der Beschreibung, wäre es umkreisen Lage , als Organisation / s auf andere handelt Organisation Ort / s; Obwohl semantisch, bezweifle ich, dass eine Organisation als "Mitglied" der Organisation dieses Standorts unterwürfig erscheinen möchte, um dies zu tun, "egal wie gut die Sache ist".

[6]. Das ist für mich immer noch ein bisschen grau, aber hier ist es ... Zu meinem Nachteil ist die Ähnlichkeit zwischen den Beziehungen zwischen Mitgliedern und Freunden so eng, dass ich dachte, sie zu kombinieren. Im Nachhinein mit Ihrem Diagramm und Ihrer Interpretation scheint es richtig zu sein, sie getrennt zu halten [ Ich wollte die einzelne Beziehung über die Eigenschaft enum unterscheiden: Eigentümer / Administrator / Mitglied / Freund ]. Ihr Konzept als z. B.: Ein Standort, der einer Organisation gehört, hat null bis viele Profile [Person oder Organisation], obwohl es einen klaren Unterschied geben sollte, wie die Profile über ihre Beziehung [Mitglied oder Freund] auf den Standort wirken ] durch Rollen bezeichnet.So perhaps, the default relation between any Profile is Friend [much like Guest at Answer#7], enabling them to view the read-only Location data and msg/email the Location Owner/Admin - but not allow them to receive Location updates, news, etc., as a Member would.


Mit welcher Software haben Sie Ihre ERD-Beispiele erstellt?
Elias

Microsoft Visio;)
MVC Newbie

Antworten:


14

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:

  1. 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?

  2. Kann ein Profile(oder Person) eigene one-to-many EmailAddresses , oder eine Profile(oder Person) auf feste genau ein EmailAddress ?

  3. 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?

  4. Ich gehe davon aus, dass ein Locationzu fest ist genau ein Address von der Art Physical, ist das richtig?

  5. Ist es möglich , dass ein Locationdurch geteilt werden eins-zu-viele unterschiedliche Organizations oder sonst eine Locationvon owned werden kann nur ein Organization ?

  6. 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.
  7. 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?

  8. 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?

  9. Ist es möglich, dass eine bestimmte Person gleichzeitig Locationeine andere hat LocationTypes, oder ist eine Person Locationfest entschlossen, genau eine zu halten LocationType?

  10. Stellt das Attribut Organization.Websitedie Website-Adresse einer bestimmten Organisation dar, z. B. "dba.stackexchange.com"?

  11. 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?

  12. 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?

  13. 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.
  14. 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 .


7
Bitte beachten Sie meine überarbeitete Frage, die Antworten auf Ihre Fragen enthält. Ich weiß, dass persönliche Korrespondenz von dba missbilligt wird - aber ich hoffe, sie können mich verwöhnen, wenn ich sage: "Ihre Antwort ist die kompetenteste und hilfreichste Ergänzung, die ich je zu einer Frage erhalten habe" - also ein herzliches Dankeschön für alle Ihre bisherigen Bemühungen, ich bin wirklich demütig und dankbar! [... und wenn dies vielen anderen Mitgliedern jetzt und in Zukunft nicht hilft, werde ich meine Tastatur essen;)]
MVC Newbie

4

Ich denke, Sie versuchen, Konzepte aus der Objektmodellierung und Konzepte aus der Datenmodellierung auf eine Weise zu kombinieren, die Ihnen nicht hilft, Ihr eigenes Verständnis des Problems zu klären. Ich hoffe, ich kann die Unordnung ein wenig beseitigen, ohne zu viel zu streifen.

Das relationale Modell als solches unterstützt keine Vererbung, egal wie Polymorphismus. Dies bedeutet, dass bei der Modellierung einer realen Situation, die durch Vererbung und Polymorphismus in einem Objektmodell leicht zu handhaben ist, ein eher spezialisiertes Entwurfsmuster verwendet werden muss. Mehr dazu später.

Als das ER-Modell zum ersten Mal entwickelt wurde, sollte es eine implementierungsunabhängige Alternative zur relationalen Modellierung sein. Anfangs hatte es auch nichts Vergleichbares. In den 1980er oder 1990er Jahren wurde das Modell jedoch erweitert, um einige der Ausdrucksmöglichkeiten zu bieten, die Sie bei der Vererbung erhalten. Dies war als "erweitertes ER-Modell" bekannt, aber für alle praktischen Zwecke enthält das heutige ER-Modell EER-Funktionen.

Eine EER-Funktion trägt den Namen "Generalisierung / Spezialisierung". Sie können dieses Konzept im Web suchen und nachlesen. Gen-spec bietet fast die gleiche Ausdrucksfähigkeit wie Klassen und Unterklassen in einem Objektmodell. Gen-spec befasst sich jedoch nicht mit den Problemen beim Entwurf relationaler Tabellen für eine Gen-spec-Situation. Dazu später mehr.

Bei der ER-Modellierung sind an einer Beziehung immer dieselben Entitäten beteiligt. Daher ist die Freundschaftsbeziehung zwischen einer Organisation und einem Profil nicht dasselbe wie die Freundschaftsbeziehung zwischen einem Profil und einem anderen Profil. Die beiden Beziehungen benötigen unterschiedliche Namen. Sie werden sich nur in Knoten binden, wenn Sie diese Regel nicht befolgen.

Entweder das, oder Sie müssen eine verallgemeinerte Entität erstellen, deren Spezialisierungen Organisationen, Profile und möglicherweise Standorte sind. Ich verstehe Ihren Fall nicht gut genug, um Ihnen dabei zu helfen.

Im weiteren Verlauf stelle ich fest, dass Sie Ihr relationales Modell und Ihr ER-Modell zu einem einzigen Modell kombinieren. Die meisten erfahrenen Datenbankarchitekten tun dies. Ich rate Ihnen jedoch, die beiden Modelle getrennt zu halten (obwohl sie miteinander in Einklang stehen), bis Sie Ihre Kenntnisse erworben haben.

Wie entwirft man schließlich relationale Tabellen, die eine Gen-Spec-Situation darstellen? Versuchen Sie, diese beiden Entwurfsmuster "Klassentabellenvererbung" und "Einzeltabellenvererbung" nachzuschlagen. Es gibt zwei Tags für diese in Stackoverflow. Es gibt auch einige ziemlich gute Präsentationen der Muster im Web. Ich mag besonders die Behandlung von Martin Fowler. Er scheint zu wissen, wie Objektmodellierer denken. Hoffe das hilft.


Vielen Dank für Ihre Zeit und die großartige Antwort - Ok, diese Konzepte scheinen sich meiner Option zuzuwenden: 2. Siehe überarbeitetes Diagramm in Frage. Die Kernentitäten sind Profil und Standort - Organisation ist eigentlich nur ein Profil mit einigen erweiterten Attributen. Ich habe auch entschieden, dass Freund / Mitglied auch gleich sind. * Viele Profile / Organisationen können viele Profile / Organisationen als Mitglieder haben. * An vielen Standorten können viele Profile / Organisationen zugeordnet sein - die Art der Zuordnung. wird höchstwahrscheinlich von enum behandelt: Eigentümer / Administrator / Mitglied. Wäre das mit meinem überarbeiteten Diagramm vergleichbar?
MVC Newbie

AFAICT, die Tabelle Profile_Members repräsentiert eine rekursive Viele-zu-Viele-Beziehung zwischen einem Profil und einem anderen. So weit bin ich gekommen.
Walter Mitty
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.