Est-il possible pour une entité faible, déjà liée à une entité forte, de se lier à une autre entité faible dans un diagramme ER?
J'ai une déclaration de problème (briefée),
Base de données pour un club de fitness -
Attributs du client : nom, adresse, numéro de téléphone.
Attributs du plan d'adhésion : Beg. date, sous. Frais, frais mensuels, durée
Attributs du formateur : ID, nom, salaire
Types de relations: Le client est ' inscrit dans ' un Mem. Plan, et Client ' Rencontre ' Formateurs
Inscrit : Le client a une participation totale pendant que Mem. Le plan ne fonctionne pas.
Répond : Client et formateur, les deux ont une participation totale.
Par Rencontre, cela signifie qu'une entité Client assiste à une session guidée par une entité Formateur.
Ainsi, Client & Mem. Le plan est un type d'entité faible et le formateur est un type d'entité fort.
Une fois converti en diagramme ER, Client & Mem. Le plan est lié les uns aux autres et le client est lié au formateur.
Est-il possible d'avoir un tel diagramme ER ou existe-t-il une autre façon de rectifier le même?
Edit: Ce diagramme ER représente ce que je pense qu'il devrait être (sans touches partielles) et considère les flèches dans le diagramme comme des lignes droites reliant deux blocs/formes.
N'hésitez pas à me corriger si je me trompe quelque part.
J'ai également une entité "Workout Session", qui a une relation avec le formateur. Une séance d'entraînement est menée par un seul formateur, mais le problème indique de ne conserver que les données des formateurs qu'un client rencontre, et non les sessions auxquelles il/elle assiste. Mais comme cela n'était pas lié à la question que je devais poser, je n'ai donc pas ajouté cette partie.
Je pense qu'il n'y a pas d'attribut unique du client ou du plan d'adhésion que je puisse utiliser pour distinguer leurs entités respectives, donc je pense que le client et le plan d'adhésion sont des types d'entités faibles.
J'ai fourni autant de détails que possible car je ne peux pas divulguer la déclaration complète pour certaines raisons.
En fonction de la quantité d'informations que vous avez fournies sur votre énoncé de problème, on peut affirmer que:
- Le formateur est une entité forte (il a un ID)
Ni le client ni le plan d'adhésion ne semblent être des entités faibles ou fortes.
Les deux pourraient être considérés comme des entités fortes à condition qu'une clé primaire y soit définie *; par exemple.
Client.(Name, Phone)etMembership Plan.("Beginning Date", Duration)
Dans votre diagramme Chen, Rencontre l'entité devrait avoir la participation totale aux deux extrémités, mais il y a une flèche entre Formateur et Répond ?
En dehors de cela, cela semble aller bien.
* Une entité forte est définie comme ayant une clé qui ne dépend d'aucune autre clé; a entité faible comme ayant une clé qui dépend d'une clé étrangère. Par exemple. Order possède une clé primaire order_id qui est indépendant, ce qui en fait une entité forte, tandis que Order_Detail possède une clé primaire order_detail_id et clé unique order_id, line_no, ce qui en fait une entité faible puisque order_detail_id ne fournit pas d'ID indépendant significatif et la clé unique dépend de la table Order. Voir entrée d'entité faible dans Wikipedia .
Ils sont indépendants des autres entités, donc ils sont candidats pour être considérés comme des entités fortes à condition qu'ils aient une clé primaire, ce qui n'est pas connu s'ils l'ont et il n'est pas clair s'ils le pourraient dans le définition.
Le client et le formateur sont tous deux des entités solides avec une relation plusieurs à plusieurs catagorisée par la réunion de l'entité faible.
Plan d'adhésion: semble être une faible entité avec une relation individuelle avec le client. Mais j'ajouterais une clé primaire et en ferais une entité solide avec une relation plusieurs à un avec le client. Cela permet des plans d'adhésion historiques, etc.
Plan d'adhésion actuel: entité faible avec une relation individuelle avec le client. Indiquant le plan d'adhésion actuellement actif pour le client.
Modifier .. vous avez ajouté le diagramme ..
Il semble que votre adhésion soit plus ce que j'appellerais MembershipType. C'est-à-dire la liste des plans disponibles à l'achat. Alors que le plan d'adhésion lié au client doit être l'instance du type d'adhésion qu'ils ont acheté.
La date de début, par exemple, variera selon le client pour l'instance.
Pour répondre à la question générale. "Une entité faible peut-elle être liée à une autre entité faible", je dirais non. Une entité faible n'a pas de clé primaire en soi, mais a une clé étrangère qui est liée au PK d'une autre entité. Ainsi, si vous avez deux entités faibles avec le même identifiant FK, elles sont en fait liées à la même entité forte plutôt que l'une à l'autre.