Discussion :

[Jéjé34]

Bonjour,

J'ai vu que si on souhaite simuler un héritage en relationnel, il existe deux solutions, par exemple:

Première solution :
Personne(idPersonne, nom, prenom)
Footballeur(idFootballeur, nbButs) avec idFootballeur qui reference idPersonne
Basketteur(idBasketteur, nbPaniers) avec idFootballeur qui reference idPersonne

Seconde solution :
Footballeur(idFootballeur, nom, prenom, nbButs)
Basketteur(idBasketteur, nom, prenom, nbPaniers)


La première solution va m'obliger a faire des jointures à chaque requête entre une "sous-table" et ma "super-table"
Tandis que la seconde implique de la redondance entre attributs.

Quelle est la meilleure solution selon vous?

[SQLpro]

La redondance étant interdite dans les SGBD relationnel par définition, la seule solution est la première !

A +

[CinePhil]

La seconde solution n'est d'ailleurs pas un héritage.
Le bon héritage, c'est la première solution.

Et ne vous affolez pas pour les jointures. Faites des vues et vous interogez les vues comme si c'étaient des tables. Les jointures sont dans les vues mais on s'en fout ; elles sont écrites une fois pour toutes.

[StringBuilder]

Une troisième solution serait :

Personne (id, nom, prenom)
Sport (id, nom)
Score (personne_id, sport_id, points)

Ainsi, si demain il y a à gérer du tennis, du volley ou du golf, pas besoin de démultiplier le nombre de tables.
Attention cependant, si on veut avoir ensuite avoir des données de types ou nombres différentes selon les sports, ce modèle à des limites.

[Jéjé34]

@CinePhil @SQLpro: merci pour vos réponses, ça a le mérite d'être clair.

@StringBuilder: j'ai pris le Sport juste pour l'exemple, mais ta méthode résout complètement le problème.

En réalité, j'ai les tables suivantes :
Utilisateur (idUtilisateur, nom, prenom, email, ...)
Etudiant (idEtudiant, numINE, promotion) avec idEtudiant = Utilisateur(idUtilisateur)
Enseignant (idEnseignant) avec idEnseignant = Utilisateur(idUtilisateur)
Tuteur (idTuteur, entreprise) avec idTuteur = Utilisateur(idUtilisateur)
Secrétaire (idSecretaire) avec idSecretaire = Utilisateur(idUtilisateur)

Sauf que qu'un enseignant, peut aussi être un tuteur. Est ce que ça pose pas de problème si il apparait dans les deux tables?
Autre question: est-ce que vous ne trouvez pas bizarre mes tables Enseignant et Secrétaire qui n'ont qu'un seul attribut?

En fait, je fais ça pour gérer l'affichage de mon site en fonction du "statut" de l'utilisateur.

[CinePhil]

L'héritage ne se justifie que s'il y a des propriétés ou des associations spéciales pour un type d'individu. S'il s'agit juste de typer l'individu pour lui accorder des droits à une application, cela se gère tout à fait autrement.

[Jéjé34]

Tu as des pistes ?

Au début, je pensais mettre tout simplement un attribut 'role' dans la table Utilisateur.
Mais étant donné qu'un utilisateur peut avoir plusieurs rôles (tuteur ET enseignant par exemple) ...

[CinePhil]

Et bien il faut une table des rôles et une table associative entre role et utilisateur.

Règle de gestion :
Un utilisateur a de un à plusieurs rôles et un rôle peut être attribué à plusieurs utilisateurs.

MCD :
utilisateur -1,n----attribuer----0,n role

Tables :
te_utilisateur_uti (uti_id, ...)
te_role_rol (rol_id, ...)
tj_uti_attribuer_rol_uar (uar_id_utilisteur, uar_id_role...)