Je crée un diagramme conceptuel [oui, je sais que j'ai inclus des attributs et des clés - mais c'est juste pour moi de consolider ce que je fais tout en apprenant] - alors veuillez le traiter comme conceptuel en mettant l'accent sur les relations et tableaux et non comment schématiser;)

Mon obstacle est: j'essaie de déterminer la meilleure façon de modéliser les relations de profil, de lieu et d'organisation.

Tout d'abord, RÈGLES:

• Un ou plusieurs profils peuvent être membres / amis d'une ou plusieurs organisations ; et vice versa.
• Un ou plusieurs profils peuvent être membres / amis d'autres profils.
• Une ou plusieurs organisations peuvent être membres / amis d'autres organisations.

Ami et membre diffèrent, en ce sens que les amis sont en lecture seule et que les membres [selon le niveau] ont un accès complet pour modifier les choses.

Pour les choses compliquer encore, lieux ont leur propre ensemble de « nouvelles » règles raffinables de Une organisation possède deux emplacements , mais selon les règles emplacement, un membre [ profil ] de cette organisation peut avoir accès à un endroit, mais l' accès restreint au autre. [Désolé: vous devrez très probablement ouvrir l'image dans une autre fenêtre pour une meilleure taille d'affichage.]

Donc, comme vous pouvez le voir, le concept de profils et d'organisations est à peu près le même, ainsi que ce concept encore à modéliser d'amis et de membres [... qui, j'imagine, sera traité un peu comme les tableaux intermédiaires actuels avec le paramètre Propriétaire / Administrateur / Membre / Ami, etc. dans le dossier]. Par conséquent, pourquoi je pense au concept suivant:

Voir Option.2 dans l'image ci-dessus: qui supprimerait les tables Organization et Organization_Locations actuelles et leurs relations, en les remplaçant par la table d'organisation Option.2 en tant que relation quelque peu récursive avec Profile .

Je suppose que le nœud du problème est de savoir si je suis trop orienté programmatiquement vers le polymorphisme au détriment de la simplicité et de la flexibilité, me déroutant entièrement dans le processus;)

Merci pour vos réflexions à l'avance, très apprécié - M :).

Diagramme révisé:

En réponse aux questions de MDCCL:

1. Oui, le profil est composé d'une seule personne et a la même signification - bien que là où votre raisonnement se dirige - je pense que vous avez raison: l' organisation et la personne peuvent être des sous-types de profil ; par conséquent, un profil est composé d'une personne ou d'une organisation.
2. Une adresse e-mail par profil.
3. Oui. Comme ci-dessus, les organisations doivent au moins avoir une adresse e-mail.
4. Correct, une adresse fixe.
5. C'est une possibilité, mais une rareté - bien que d'après ce que j'apprends - il faut donc modéliser un tel pour la future longévité, etc., et juste pour confirmer, un emplacement pourrait donc appartenir à plus d'une personne.

6. L'emplacement est définitivement l'entité intégrale entre la plupart des autres. Je vais peut-être clarifier ce qui peut être fait succinctement ici, puis vous laisser lire mes autres réponses qui, espérons-le, concerneront d'abord les ajouts bénéfiques à cette question [ puis voir ma réponse au n ° 6 à la fin ];) Re: Le propriétaire du rôle. An **Organization** can be an Owner of zero or more **Locations**. A Person can be an owner of zero of more Locations[donc, comme vous l'avez supposé précédemment; Autrement dit, un profil peut être propriétaire de zéro ou plusieurs emplacements.

7. Oui, un profil qui est un propriétaire d'un emplacement assume tous les rôles des autorisations [super - utilisateur]; un profil qui est un administrateur peut modifier certains détails de l' emplacement , mais aide / modifie principalement les détails / données fournis via tous les autres profils - cela sera principalement fourni par les «membres de base» desdits emplacement (s); ce qui laisse le membre de base , qui peut lire uniquement tous les détails relatifs à l' emplacement et fournir des données qui doivent être contrôlées par un administrateur / propriétaire . Au-delà, tout profil[Organisation / Personne] ressemble beaucoup à un membre de base "en lecture seule" - appelons-les invité - mais uniquement si l'emplacement est défini comme public [et non privé ], bien qu'ils ne puissent pas fournir d'entrée comme un membre de base peut .

8. Correct.
9. Votre intuition est incroyable! Oui, it is foreseen that a single Location could contain one to many LocationTypes- pour compliquer encore les choses - il est prévu que ces LocationTypes individuels pourraient avoir différentes autorisations pour les profils associés à l'emplacement «parent»; dont les autorisations filtreraient de l'emplacement vers le / les LocationType [un peu comme les autorisations de sécurité du dossier du système d'exploitation]. Je note via votre diagramme que vous pourriez faire référence à taper plus comme description?
10. Oui.
11. Voir 12.
12. Corriger, la possibilité pour Profil1 [personne ou organisation] pour agir sur Profile2 [personne ou organisation] appartenant lieux [si elles sont amis / membres avec des autorisations correctes] est primordiale.
13. Très raisonnable - a) d' accord. b) d' accord. c) Oui, hmm? ... Peut - être qu'il devrait être la même que le profil [personne] au profil [personne] = Amis . Quelle que soit la description, elle tournerait autour de l' emplacement , car les organisations agiront sur les autres emplacements de l' organisation ; bien que sémantiquement, je doute que n'importe quelle organisation veuille paraître subalterne en tant que «membre» de l'organisation de cet emplacement pour pouvoir le faire, «peu importe la qualité de la cause».

[6]. C'est encore un peu gris pour moi, mais voilà ... À mon grand détriment, la similitude entre les relations Membre / Ami est si proche que j'ai pensé à les combiner; avec le recul de votre diagramme et de votre interprétation, il semble que vous ayez raison de les séparer [ j'allais différencier la relation unique via la propriété enum: Owner / Admin / Member / Friend ]. Votre concept, par exemple: un emplacement appartenant à une organisation aura zéro à plusieurs profils [personne ou organisation], mais il devrait y avoir une différence claire entre la façon dont les profils agissent sur l'emplacement via sa relation [membre ou ami ] désigné par les rôles.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.

C'est formidable que vous preniez le temps de comprendre, classer et modéliser les données avec lesquelles vous traitez, car, d'après mon expérience personnelle, tout cela rend le processus de développement plus facile et très flexible pour les changements futurs. Et je suis certain que vous en êtes déjà conscient.

Modèle de données préliminaire et règles métier supposées

J'ai défini une liste de règles métier que j'ai assumée après avoir lu votre question et examiné de près vos schémas, afin de décrire ma compréhension de vos spécifications. Après avoir défini une telle liste, j'ai dérivé un modèle de données IDEF1X ^[1] que j'ai décidé de télécharger en tant que document .PDF dans une plate-forme externe (Dropbox), car en raison de son format, ce modèle de données ne s'intègre pas bien dans une image intégrée. Ces deux instruments vont être utiles comme références pour certains points importants que j'énumère ci-dessous dans la section intitulée Aspects à résoudre afin d'avancer .

Voici d'abord le…

• Modèle de données préliminaire des organisations et des profils .

Puisque ce n'est que cela, préliminaire, le considérer comme un moyen de nous aider à réaliser le modèle de données final souhaité.

Règles commerciales supposées

Ce modèle de données préliminaire est dérivé d'un ensemble de règles métier (déduit de votre question) que j'énumérerai comme suit:

Organisations et profils

Notez que cela Profileest actuellement compris comme synonyme de Person.

• An Organizationest un ami d' un à plusieurs Profiles .
• An Organizationest un ami d' un à plusieurs Organizations .
• An Organizationest membre d' un à plusieurs Organizations .
• A Profileest membre d' un à plusieursOrganizations .
• A Profileest un ami d' un à plusieurs Profiles .
• A Profileest membre d' un à plusieurs Profiles .

Lieux et adresses

• Un Organizationpossède un à plusieurs Locations .
• A Locationest classé par un à plusieurs LocationTypes ( un seul à un moment donné).
• A Locationpeut avoir un à plusieurs Addresses ( un Physical , un pour Shipping, l' un pour Billing, ou un qui sert tous ces buts, ou un qui combine deux buts et une autre qui sert seulement un d'entre eux).

• Un Addresspeut être conservé par un-à-plusieurs Profiles ou, autrement dit, un Profileconserve un-à-plusieurs Addresses .

• Un particulier Addresspeut être utilisé par un à plusieurs Profiles (servant Physicalpour un Profile , utilisé pour Billingpar un autre , etc.). Ainsi, un Addressfonctionne de manière similaire pour Locationset Profiles.

  • Ainsi, un individu Addresspeut être, en même temps , de type Physical, Shipping et Billing .

Lieux et rôles

• A Locationouvre un à plusieurs Roles .
• Un Rolepeut être effectué en un à plusieurs Locations .
• Un Profile(une fois qu'il a été défini comme Memberd'un Organization) peut effectuer un à plusieurs Roles , en un à plusieurs Locations (mais un seul spécifique Roleà chacun Locationà un moment donné, c'est-à-dire jamais deux ou plus Roles en même temps ).

Aspects à résoudre pour aller de l'avant

Afin de continuer à progresser dans la résolution de votre modèle de données, voici une liste de points pertinents qui, une fois que nous les aurons élaborés, nous aideront à atteindre cet objectif:

1. J'ai supposé que le terme Profiledans votre contexte a une signification similaire (ou la même) que celle de Person, mais il pourrait être un peu différent. De cette façon, diriez-vous que, dans votre scénario, les entités Organizationet Personles sous-types de Profile?

2. Un Profile(ou Person) peut-il posséder un à plusieurs EmailAddresses , ou un Profile(ou Person) est-il fixé à exactement un EmailAddress ?

3. Souhaitez-vous donner la possibilité à un Organizationd'être contacté via Telephoneet Email, ou souhaitez-vous restreindre cela pour qu'il ne soit possible que pour un Profile(ou Person)?

4. Je suppose que a Locationest fixé à exactement l'un Address des types Physical, est-ce correct?

5. Est-il possible que a Locationsoit partagé par un à plusieurs différents Organizations ou , sinon, un Locationpeut appartenir à un seul Organization ?

6. Vous avez déclaré via des commentaires que le fait d'être un Memberet un Friendest le même. Comme vous pouvez le voir dans mon modèle de données préliminaire proposé, je vous ai suivi les spécifications d'origine et décrit toutes les combinaisons possibles d'appartenance et d'amitié entre Organizationet Profile(ou Person) dans différentes entités car je pense que cela peut être utile dans l'effort de définir le meilleur possible structure pour cette partie de votre scénario. Dans ce sens:

   • Je suppose que la déclaration an Organization is a Member of another Organizationa des effets différents de la déclaration a Profile (or Person) is a Member of an Organizationconcernant l'entité appelée Location.
   • Comme vous pouvez le voir dans le modèle de données, je pense que le Rolede Ownern'est valable pour un Organizationet, pour moi, le valide Rolespour un Profile(ou Person), à l' intérieur d' un Locationsont Adminet Member. Que pensez-vous de tout cela? Puisque vous êtes en contact direct avec les règles commerciales applicables à votre situation, vous devez me dire si mes hypothèses sont correctes.

7. Un Profile(ou Person) peut-il jouer différent Rolesà l'intérieur d'un même Location? c'est-à-dire, un peut-il Personêtre en même temps le Adminet aussi un Memberdu même Location? Quelles sont les règles à cet égard?

8. Je pense que le même Profile(ou Person) peut jouer différemment Rolesdans différents Locations. Par exemple: Un Profile(ou Person) spécifique est "Admin" dans Location"1", et ce même Profile(ou Person) est un " Member" dans Location"2", en même temps. Ai-je raison?

9. Est-il possible pour un particulier Locationd'avoir différents LocationTypesen même temps, ou un individu est-il Locationfixé pour en tenir exactement un LocationType?

10. L'attribut Organization.Websitereprésente- t-il l' adresse du site Web d'une organisation particulière, telle que «dba.stackexchange.com»?

11. Si Profile«1» (compris comme Person) est un Member(ou Friend) de Profile«2», est-il possible pour Profile«1» d'effectuer un Roledans une Locationpropriété de Profile«2»? Je considère que de tels scénarios ne sont valables que pour les relations entre un Organizationet un Member Persondonc, qu'en pensez-vous?

12. De la même manière, si Organization«1» est un Member(ou Friend) de Organization«2», est-il possible pour Organization«1» de réaliser un Roledans une Locationpropriété de Organization«2»? Encore une fois, je pense que ce genre de scénarios ne sont valables que pour les relations entre un Organizationet un Member Person, est-ce correct?

13. À cet égard - pendant que j'écris ces questions - je pense qu'il serait raisonnable de dire qu'il n'y a que trois types de relations différentes impliquant Organizationset Persons, et nous pouvons définir:

    • a) La relation entre un Organizationet un en Persontant que « Membership».
    • (b) La relation entre un Personet un autre différent Personde « Friendhip».
    • (c) Nous n'avons pas encore trouvé de nom significatif pour décrire la relation entre un individu Organizationet un autre différent Organization.
    • Alors, faites-moi savoir ce que vous pensez des points a), b) et c).

14. Est-il possible pour un Organizationd'être un Friend(ou un Member) d' un à plusieurs différent Organizationsen même temps? Ou il est seulement possible pour un Organizationd'avoir seulement une relation avec exclusivement un autreOrganization?

Modèle de données successives illustrant la première avancée

En tenant compte de vos réponses et résolutions aux aspects en suspens que j'ai énumérés ci-dessus, j'ai créé ce qui suit…

• Organisations et profils Modèle de données préliminaire - First Advance .

Bien que je ne me sente pas encore très à l'aise avec lui, ce nouveau modèle de données exprime les règles commerciales suivantes:

• A Profileest soit un, Organization soit un Person. ^[2]
• Un Profilepeut être l'ami offrant d' un à plusieurs FriendProfiles , et un Profilepeut être l'ami qui accepte d' un à plusieurs FriendProfiles . ^[3]
• Un Locationpeut être composé d' un à plusieurs Locations . ^[4]

Réponses à vos commentaires spécifiques ultérieurs

C'est vraiment intéressant pour moi de noter / aggraver la séparation des préoccupations [par exemple LocationAddress et ProfileAddress] - car je voulais évidemment me précipiter et les maintenir toutes sans les bonnes relations [drôle, cela ne me semblait pas bien avec mon ERD d'origine].

Oui, c'est une bonne comparaison, bien que je n'appellerais pas cela une séparation des préoccupations (qui est, certainement, un principe fondamental de la programmation et de la conception d'applications), car ce terme se rapporte généralement à la phase de développement d'applications et nous nous trouvons actuellement dans le stade de compréhension des données et de conception de leur structure logique.

D'après mon expérience personnelle, je considère que cette phase a à voir avec la mise des choses significatives dans leur contexte entier, elle a à voir avec les associations qui existent entre les différentes entités qui sont pertinentes dans le scénario d'intérêt particulier, puis illustrant ces éléments dans un modèle de données. Dans le cas spécifique sur lequel vous commentez, l' Addressentité peut avoir différents types de connexions avec d'autres entités, une avec Profileet une autre avec Location.

Et, oui, quand quelque chose ne se sent pas bien ou naturel , cela peut bien être un signe qu'il faut faire plus d'efforts pour comprendre les données pertinentes. De cette manière, l' Addressentité est l'une des choses que je considère comme nécessitant plus d'attention, car je pense que la relation entre un Profileet un Address pourrait être gérée au moyen de l' Locationentité (du fait que chacun Locationdoit avoir au moins un physique Address), nous pourrions donc rejeter l' ProfileAddressentité associative représentée dans le dernier modèle, mais vous devez continuer à analyser ces points et me faire part de vos idées.

De plus, est-il courant dans IDEF1X de modifier les dénotions PK / FK dans les entités pour une meilleure lisibilité [par exemple, ProfileId - LocationOwnerProfileId]?

Oui, c'est une remarque très intelligente de votre part, car IDEF1X recommande l'utilisation de noms de rôles pour dénommer les CLÉS ÉTRANGÈRES, afin de saisir la signification de ces attributs en fonction de l'entité dans laquelle ils sont utilisés. Il convient également de noter que cela est également fortement lié au concept de migration des clés primaires . En fait, l'utilisation des noms de rôle précède IDEF1X, car il a été initialement présenté par le Dr EF Codd dans son texte fondateur de 1970. De cette manière, on peut clairement voir la fidélité que la norme IDEF1X garde envers le modèle relationnel .

Je serais intrigué d'apprendre ce que vous n'aimez pas particulièrement / sentez-vous que cela ne modélise pas, avec / dans la solution?

Outre les détails déjà décrits ci-dessus à propos de l' Addressentité, je ne sais pas si les Rolesfaits effectués par un donné Profiledans un particulier Locationsont équivalents pour un Organizationou un Person. De mon point de vue, un Personpremier doit être associé à un Organization, et ensuite ce Organizationserait nommé Personpour effectuer un Roledans un particulier Location, mais vous connaissez mieux le scénario, donc ces règles peuvent être inutiles. À cet égard, je vais insister sur le fait qu'il serait très utile pour moi de savoir la description contextuelle ou sens que les futurs utilisateurs de cette structure de données donnent à Organization, ProfileetLocation, mais je comprends que cela peut être considéré comme une information confidentielle, ce serait donc une limitation.

Avec la structure actuelle, il semble que tout le monde ( Organizationou Person) peut être lié à n'importe qui (encore une fois, Organizationou Person) et peut être / faire n'importe quoi ( Role) n'importe où ( Location) mais, perharps, c'est précisément ce que vous et les utilisateurs attendez de cette base de données , pour lesquels vous fournirez bien entendu des contraintes bien définies. Si tel est le cas, nous fournissons presque une solution finale. Puisque, naturellement, votre opinion est décisive dans cette situation, vous devez également analyser ces idées et me faire part de vos conclusions afin que nous puissions prendre les dernières mesures.

Deuxième avance réalisable

Malheureusement, la communication s'est arrêtée il y a quelques semaines, je suppose à cause des engagements de travail que vous devez respecter, ce qui est tout à fait raisonnable. J'aurais été beaucoup plus content si nous avions développé un modèle plus stable et robuste mais, en raison de nos interactions précédentes, je peux supposer que j'ai pu vous orienter dans la bonne direction.

En plus de ce qui a déjà été présenté dans ce processus de questions et réponses, je considère que fournir une nouvelle progression à partir des modèles de données précédents peut être utile pour d'autres chercheurs ayant un problème similaire. J'ai donc créé le…

Modèle de données préliminaire des organisations et des profils - Deuxième avancée

Comme on peut le voir dans un tel modèle de données, j'ai supprimé la relation plusieurs-à-plusieurs que j'ai décrite dans les modèles précédents entre Profileet Address, car une donnée Profileest déjà liée à un-à-plusieurs Addresses via sa propriété Locations.

Un autre changement qui est illustré dans cette nouvelle avancée est le fait qu'elle inclut désormais la possibilité qu'une donnée Locationpuisse appartenir à un à plusieurs Profiles . Par conséquent, j'ai changé la LocationCLÉ PRIMAIRE (en supprimant l' LocationOwnerProfileIdattribut), puis ajouté une entité associative ( plusieurs à plusieurs ) qui se rapporte Profileà Location.

Remarques

_{1. IDEF1X est une technique de modélisation de données hautement recommandable qui a été définie comme norme en décembre 1993 par le National Institute of Standards and Technology ( NIST ) des États-Unis .}

_{2. Il s'agit d'une occurrence d'un cluster (super) type-sous-type . Au cas où vous seriez intéressé, voici une réponse dans laquelle je traite de manière plus détaillée ce type de relations.}

_{3. Un exemple d'une relation hiérarchique plusieurs-à-plusieurs , et est très similaire à la structure qui a donné une solution définitive au «problème d'explosion des pièces» . Une telle solution a bien sûr été introduite par le Dr Edgar Frank Codd dans son article de 1970 extrêmement influent «Un modèle relationnel de données pour les grandes banques de données partagées» .}

_{4. En tant que tel, il s'agit d'un exemple de relation hiérarchique un-à-plusieurs (ou plusieurs-à-un) .}

Je pense que vous essayez de mélanger les concepts de la modélisation d'objets et les concepts de la modélisation des données d'une manière qui ne vous aide pas à clarifier votre propre compréhension du problème. J'espère que je pourrai effacer un peu l'encombrement sans trop de bavardage.

Le modèle relationnel, en tant que tel, ne prend pas en charge l'héritage, sans parler du polymorphisme. Cela signifie qu'un modèle de conception plutôt spécialisé doit être utilisé lors de la modélisation d'une situation réelle qui est facilement gérée par l'héritage et le polymorphisme dans un modèle d'objet. Plus d'informations sur ce modèle de conception spécial plus tard.

Lorsque le modèle ER a été développé pour la première fois, il était censé être une alternative indépendante de la mise en œuvre à la modélisation relationnelle. Au début, il n'avait rien d'héritage non plus. Mais dans le courant des années 1980 ou 1990, le modèle a été étendu pour fournir certaines des mêmes capacités expressives que celles que vous obtenez avec l'héritage. Ce modèle était connu sous le nom de «modèle ER étendu», mais à toutes fins pratiques, le modèle ER d'aujourd'hui comprend des fonctionnalités EER.

Une fonction EER porte le nom de "généralisation / spécialisation". Vous pouvez rechercher et lire ce concept sur le Web. Gen-spec fournit à peu près la même capacité d'expression que les classes et les sous-classes fournissent dans un modèle d'objet. Cependant, Gen-spec ne traite pas les problèmes liés à la conception de tables relationnelles pour une situation de type gen-spec. Plus sur cela plus tard.

Dans la modélisation ER, une relation implique toujours les mêmes entités. Par conséquent, la relation d'ami entre une organisation et un profil n'est pas la même chose que la relation d'ami entre un profil et un autre profil. Les deux relations ont besoin de noms différents. Vous allez simplement vous nouer si vous ne suivez pas cette règle.

Soit cela, soit vous devez trouver une entité généralisée dont les organisations, les profils et éventuellement les emplacements sont tous des spécialisations. Je ne comprends pas assez bien votre cas pour vous aider.

En passant, je remarque que vous combinez votre modèle relationnel et votre modèle ER en un seul modèle. La plupart des architectes de bases de données chevronnés le font. Mais je vous conseille de garder les deux modèles séparés (bien que réconciliés l'un avec l'autre) jusqu'à ce que vous ayez acquis des compétences.

Enfin, comment conçoit-on des tables relationnelles qui représentent une situation gen-spec? Essayez de rechercher ces deux modèles de conception "Class-table-inheritance" et "Single-Table-Inheritance". Il y a deux balises pour celles-ci dans Stackoverflow. Il existe également de très bonnes présentations des modèles sur le Web. J'aime particulièrement le traitement de Martin Fowler. Il semble savoir comment pensent les modélisateurs d'objets. J'espère que cela t'aides.