Diagramme entité-relation. Comment la relation IS A se traduit-elle en tableaux?
Je me demandais simplement comment une relation ISA dans un diagramme ER se traduirait en tables dans une base de données.
Y aurait-il 3 tables? Un pour la personne, un pour l'étudiant et un pour le professeur?
Ou y aurait-il 2 tables? Un pour l'élève et un pour l'enseignant, chaque entité ayant les attributs de personne + les leurs?
Ou y aurait-il un tableau avec les 4 attributs et certains des carrés du tableau étant nuls selon qu'il s'agissait d'un élève ou d'un enseignant dans la rangée?
REMARQUE: j'ai oublié d'ajouter ceci, mais il y a une couverture complète pour la relation ISA, donc une personne doit être un étudiant ou un enseignant.
En supposant que la relation est obligatoire (comme vous l'avez dit, une personne a pour être un élève ou un enseignant) et disjointe (une personne est soit un élève ou un enseignant, mais pas les deux), la meilleure solution est avec 2 tables, une pour les étudiants et une pour les professeurs.
Si la participation est plutôt facultative (ce qui n'est pas votre cas, mais disons-le pour être complet), alors l'option 3 tables est la voie à suivre, avec une table Person (PersonID, Name) et ensuite les deux autres tables qui feront référence la table Person, par exemple Étudiant (PersonID, GPA), PersonID étant PK et FK faisant référence à Person (PersonID).
L'option 1 table n'est probablement pas la meilleure façon ici, et elle produira plusieurs enregistrements avec des valeurs nulles (si une personne est un élève, les attributs réservés aux enseignants seront nuls et vice-versa).
Si la disjonction est différente, alors c'est une autre histoire.
il y a 4 options que vous pouvez utiliser pour mapper cela dans une ER,
option 1
- Personne ( PÉCHÉ , nom)
- Étudiant ( SIN , GPA)
- Enseignant ([[# #]] sin [~ # ~], Salaire)
option 2 Puisqu'il s'agit d'une relation de couverture, l'option 2 n'est pas une bonne correspondance.
- Étudiant ( SIN , Nom, GPA)
- Enseignant ([[# #]] sin [~ # ~], nom, salaire)
option
- Personne ( SIN , Nom, GPA, Salary, Person_Type) le type de personne peut être étudiant/enseignant
option 4
- Personne ( SIN , Nom, GPA, Salary, Student, Teacher) Student and Teacher sont des champs de type bool, il peut être oui ou non, une bonne option pour le chevauchement
Étant donné que les sous-classes n'ont pas beaucoup d'attributs, l'option 3 et l'option 4 sont mieux pour mapper cela dans un ER
Cette réponse aurait pu être un commentaire mais je la mets ici pour la visibilité.
Je voudrais aborder quelques points que la réponse choisie n'a pas abordés - et peut-être élaborer un peu sur les conséquences de la conception "à deux tables".
La conception de votre base de données dépend de l'étendue de votre application et du type de relations et de requêtes que vous souhaitez effectuer. Par exemple, si vous avez deux types d'utilisateurs (étudiant et enseignant) et que vous avez beaucoup de relations générales que tous les utilisateurs peuvent prendre, quel que soit leur type, la conception des deux tables peut se retrouver avec beaucoup de "doublons". relations (comme les utilisateurs peuvent s'abonner à différentes newsletters, au lieu d'avoir une table de relations M2M entre les "utilisateurs" et les newsletters, vous aurez besoin de deux tables distinctes pour représenter cette relation). Ce problème s'aggrave si vous avez trois types d'utilisateurs différents au lieu de deux, ou si vous avez une couche supplémentaire d'IsA dans votre hiérarchie (étudiants à temps partiel vs étudiants à temps plein).
Un autre problème à considérer - les types de contraintes que vous souhaitez implémenter. Si vos utilisateurs ont des e-mails et que vous souhaitez maintenir une contrainte unique à l'échelle de l'utilisateur sur les e-mails, l'implémentation est plus délicate pour une conception à deux tables - vous devrez ajouter un table supplémentaire pour chaque unique contrainte.
Un autre problème à considérer est généralement les doublons. Si vous souhaitez ajouter un nouveau champ commun aux utilisateurs, vous devrez le faire plusieurs fois. Si vous avez des contraintes uniques sur ce champ commun, vous aurez également besoin d'une nouvelle table pour cette contrainte unique.
Tout cela ne veut pas dire que la conception à deux tables n'est pas la bonne solution. Selon le type de relations, de requêtes et de fonctionnalités que vous créez, vous pouvez choisir une conception plutôt qu'une autre, comme c'est le cas pour la plupart des décisions de conception.
Cela dépend entièrement de la nature des relations.
SI la relation entre une personne et un étudiant est de 1 à N (un à plusieurs), la bonne façon serait de créer une relation de clé étrangère, où l'étudiant a une clé étrangère renvoyant à la colonne de clé primaire de l'ID de la personne. Même chose pour la relation Personne à Enseignant.
Cependant, si la relation est de M à N (plusieurs à plusieurs), vous souhaiterez alors créer une table distincte contenant ces relations.
En supposant que votre ERD utilise des relations 1 à N, la structure de votre table devrait ressembler à ceci:
CREATE TABLE Person (sin bigint, nom du texte, PRIMARY KEY (sin));
CREATE TABLE Student (flottant GPA, fk_sin bigint, FOREIGN KEY (fk_sin) REFERENCES Person (sin));
et suivez le même exemple pour la table Enseignant. Cette approche vous amènera à la 3e forme normale la plupart du temps.