L'option (obligatoire, facultative) et la participation (totale, partielle) sont-elles les mêmes?
Comme je sais, le caractère facultatif signifie la cardinalité minimale d'une relation qui est désignée comme facultative à facultative, obligatoire à facultative, obligatoire à obligatoire.
Et la participation est indiquée par une ligne en gras et une ligne normale.
Sur Internet, certains considèrent la participation comme la dépendance de l'entité à la relation qui ressemble également à une relation d'identification et de non-identification.
et certains l'appellent la cardinalité minimale
Quelles sont les définitions correctes de ces relations et quelle est la différence.
Commençons par des définitions et des exemples de chacun des concepts:
Participation totale et partielle:
La participation totale (indiquée par une ligne d'association double ou épaisse) signifie que toutes les entités d'un ensemble d'entités doivent participer à la relation. La participation partielle (indiquée par une seule ligne mince) signifie qu'il peut y avoir des entités dans l'ensemble d'entités qui ne participent pas à la relation.
Medicine participe totalement à la relation Produce, ce qui signifie que Medicine ne peut exister que si Produced par un Laboratory. En revanche, un Laboratory peut exister sans ProducingMedicine - Laboratory participe partiellement à la relationip Produce.
Rôles obligatoires et facultatifs:
Dans une relation, les rôles peuvent être facultatifs ou obligatoires. Cela affecte si une instance de relation peut exister sans entité dans un rôle donné. Les rôles obligatoires sont indiqués par une ligne d'association solide, les rôles facultatifs sont indiqués par une ligne pointillée.
Les rôles ne sont pas souvent mentionnés dans les didacticiels de base de données, mais ils sont un concept important. Considérez un mariage - une relation avec deux rôles obligatoires remplis par le même ensemble d'entités. Dans la plupart des relations, les ensembles d'entités définissent également les rôles, mais lorsqu'un ensemble d'entités apparaît plusieurs fois dans une même relation, nous les distinguons dans des rôles différents.
Dans l'exemple ci-dessus, un Patient peut PurchaseMedicine avec ou sans Prescription. Un Purchase ne peut exister sans un Patient et Medicine, mais un Prescription est facultatif (dans l'ensemble, bien qu'il puisse être requis dans des cas spécifiques).
Relation d'identification/entité faible:
Une entité faible est une entité qui ne peut pas être identifiée par ses propres attributs et possède donc la clé d'une autre entité comme faisant partie de la sienne. Une relation d'identification est la relation entre une entité faible et son entité parent. La relation d'identification et l'entité faible sont indiquées par des doubles frontières. Les ensembles d'entités faibles doivent nécessairement participer totalement à leur relation d'identification.
Dans cet exemple, un Prescription contient LineItems qui sont identifiés par la clé de Prescription et un numéro de ligne. En d'autres termes, la table LineItems aura une clé composite (Prescription_ID, Line_Number).
Pour des exemples de relations non identifiantes, voir les exemples précédents. Alors que Medicine participe totalement à la relation Produce, il a sa propre identité (par exemple une clé de substitution, bien que je ne l'ai pas indiquée). Notez que les clés de substitution impliquent toujours des entités régulières.
Participation obligatoire/facultative vs participation totale/partielle
Les rôles obligatoires ou facultatifs indiquent si un certain rôle (avec son ensemble d'entités associé) est requis pour que la relation existe. La participation totale ou partielle indique si une certaine relation est requise pour qu'une entité existe.
Participation partielle obligatoire: Voir ci-dessus: Un Laboratory peut exister sans produire de médicament, mais Medicine ne peut pas être Produced sans un Laboratory.
Participation totale obligatoire: Voir ci-dessus: Medicine ne peut exister sans être Produced, et un Laboratory ne peut pas Produce quelque chose de non spécifié.
Participation partielle facultative: Voir ci-dessus: Un Prescription peut exister sans être Purchased, et un Purchase peut exister sans un Prescription.
Cela laisse une participation totale facultative, à laquelle j'ai dû réfléchir un peu pour trouver un exemple:
Certains PatientsDie d'un inconnu Cause, mais un Cause de décès ne peut exister sans un PatientDying de celui-ci.
Participation totale/partielle vs relations d'identification/non-identification
Comme je l'ai déjà dit, les ensembles d'entités faibles participent toujours totalement à leur relation d'identification. Voir ci-dessus: un LineItem doit être Contained dans un Prescription, son identité et son existence en dépendent. La participation partielle à une relation d'identification n'est pas possible.
La participation totale n'implique pas une relation d'identification - Medicine ne peut exister sans être Produced par un Laboratory mais Medicine est identifié par ses propres attributs.
La participation partielle à une relation non identificatrice est très courante. Par exemple, Medicine peut exister sans être Purchased et Medicine est identifié par ses propres attributs.
Relations obligatoires/facultatives vs identifiantes/non identifiantes
Il est inhabituel qu'une relation ait moins de deux rôles obligatoires. Les relations d'identification sont des relations binaires, donc les rôles parent et enfant seront obligatoires - la relation Contain entre Prescription et LineItem ne peut exister sans les deux entités.
Les rôles facultatifs ne se trouvent généralement que dans les relations ternaires et supérieures (bien que voir l'exemple de patients mourant de causes) et ne sont pas impliqués dans l'identification. Une alternative à un rôle facultatif est une relation sur une relation:
En transformant Purchase en une entité associative, nous pouvons la faire participer à une relation Fill avec Prescription. Pour conserver la même sémantique que ci-dessus, j'ai spécifié qu'un Purchase ne peut que Fill un Prescription.
Modélisation physique
Si nous traduisons du modèle conceptuel au modèle physique (en ignorant la modélisation logique/une normalisation supplémentaire), en créant des tableaux séparés pour chaque entité et relation, les choses semblent assez similaires, bien que vous deviez savoir comment lire les indicateurs de cardinalité sur les lignes de clé étrangère pour récupérer le Sémantique ER.
Cependant, il est courant de dénormaliser des tables avec les mêmes clés primaires, ce qui signifie que les relations un-à-plusieurs sont combinées avec la table d'entités du côté plusieurs:
Une relation est physiquement représentée comme deux ou plusieurs clés d'entité dans une table. Dans ce cas, les clés d'entité - patient_id et cause_of_death_id se trouvent tous les deux dans la table Patient. Beaucoup de gens pensent que la ligne de clé étrangère représente la relation, mais cela vient de la confusion du modèle de relation d'entité avec l'ancien modèle de données de réseau.
C'est un point crucial - pour comprendre les différents types de relations et les contraintes sur les relations, il est essentiel de comprendre ce que sont les relations en premier. Les relations dans ER sont des associations entre les clés, pas entre les tables. Une relation peut avoir n'importe quel nombre de rôles de différents ensembles d'entités, tandis que les contraintes de clé étrangère imposent une contrainte de sous-ensemble entre deux colonnes d'un ensemble d'entités. Maintenant, armé de cette connaissance, relisez toute ma réponse. ;)
J'espère que ça aide. Sentez-vous libre de poser des questions.