Discussion :

[Chtouk]

Bonjout à tous je suis en train de travailler sur un modèle entité association et je me vois confronté au problème suivant:

2 entités distinctes qui ont des rôles différents partagent énormément d'attributs.
C'est donc tout naturellement que j'ai pensé à l'héritage.
Mais le problème c'est que du coup une des entités filles n'a plus d'attributs propre:

exemple simplifié; initialement :

attributs de l'Entité Etudiant :
nom,prénom,telephone EstBoursier,EstRedoublant (...)
attributs de l'Entité Responsable :
nom,prénom,telephone

avec l'héritage
attributs de l'Entité mère Universitaire :
nom,prénom,telephone
attributs de l'Entité fille Etudiant:
EstBoursier,EstRedoublant
attributs de l'Entité fille Responsable:
AUCUNE ??????


Bien sûr dans le modèle relationnel qui en découle on retrouverait les attributs de l'entité mère, mais est ce qu'un modèle d'entité association avec une entité fille sans attribut est correcte????
Merci d'avance!!!!

[JPhi33]

Bonjour Chtouk,

Pour répondre à ta question de manière simple : oui, c'est correct.

Mais est-ce justifié ? C'est ça la vraie question !

Si l'entité Responsable est en relation (association ou CIF) avec d'autres entités qui ne sont pas en relation avec Etudiant, c'est justifié de conserver cette entité spécialisée.
Et c'est même obligatoire. Sinon quelle entité mettrais-tu en relation ?
Etudiant ? Non, car ces entités ne doivent pas être en relation avec Etudiant (hypothèse de départ)
Universitaire ? Non, car Etudiant en hériterait.
Conclusion : tu as bien 2 entités spécialisées Etudiant et Responsable.

Si l'entité Responsable n'est pas en relation avec d'autres entités et qu'elle n'a pas de propriété particulière, rien ne distingue donc un Universitaire d'un Responsable.
Conclusion : Responsable n'est pas une entité spécialisée, elle n'a rien de "spécial". Dans ce cas, tu te retrouves avec un seul sous-ensemble d'occurrences spécialisées (Etudiant) et un ensemble d'occurrences généralisées comportant les Universitaires qui ne sont pas Etudiants, dont les Responsables.



JPhi33

[Chtouk]

Ton explication est très claire et extrêmement rapide merci beaucoup!!!!

Je dévie un peu du coup mais ma curiosité quelle est l'intérêt d'un héritage avec une seule entité spécialisée??Est ce pour un gain de d'espace?

Et autre question :est ce que le lien logique d'héritage doit nécessairement exister?

ex: en langage objet si une classe baleine hérite d'une classe mammifere qui elle meme herite d'une classe animal,
ce que j'appelle le lien logique est la relation qui dit que baleine est un mammifere , mammifere est un animal (et donc baleine est un animal)


Je demande cela car du coup je ne sais pas comment renomper mon entité générale, qui ne sera pas relié aux mêmes fonctions que mon entité spécialisée.

[JPhi33]

Je dévie un peu du coup mais ma curiosité quelle est l'intérêt d'un héritage avec une seule entité spécialisée??Est ce pour un gain de d'espace?

On parle d'entités, donc on se situe au niveau conceptuel. Le gain à envisager n'est certainement pas technique (même si ce gain se répercute effectivement au niveau technique).
Ici, il s'agit d'obtenir une meilleure représentation du monde réel (abstraction). Distinguer, parmi les Universitaires, une population d'Etudiants ayant des caractéristiques particulières (attributs, associations, DF, CIF), c'est obtenir une meilleure abstraction du monde réel. On gagne donc en clarté, en compréhension et en évolutivité ; même s'il n'y a qu'une seule entité spécialisée.

Pour parler du gain technique, il suffit d'un petit exemple.
U-2 et U-3 sont étudiants mais pas U-1 et U-4.
1) Sans spécialisation

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
Table UNIVERSITAIRE
Ref NomUniv PrenomUniv EstBoursier
--- ------- ---------- -----------
U-1 DUBOIS  Aline      Null
U-2 DUPONT  Bertrand   Non
U-3 DURAND  Charlène   Oui
U-4 MARTIN  Didier     Null

On a 2 valeurs Null, ce qui est à éviter à tout prix dans une base de données.

2) Avec spécialisation

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
Table UNIVERSITAIRE
Ref NomUniv PrenomUniv
--- ------- ----------
U-1 DUBOIS  Aline     
U-2 DUPONT  Bertrand  
U-3 DURAND  Charlène  
U-4 MARTIN  Didier    

Table ETUDIANT
Ref EstBoursier
--- -----------
U-2 Non
U-3 Oui

Les Null ont disparu.

Et autre question :est ce que le lien logique d'héritage doit nécessairement exister?
ex: en langage objet si une classe baleine hérite d'une classe mammifere qui elle meme herite d'une classe animal, ce que j'appelle le lien logique est la relation qui dit que baleine est un mammifere , mammifere est un animal (et donc baleine est un animal)

Oui il doit exister. C'est même lui qui donne naissance à la généralisation-spécialisation. C'est parce qu'on dit qu'un Etudiant est un Universitaire qu'on peut modéliser la géné-spec.

Je demande cela car du coup je ne sais pas comment renomper mon entité générale, qui ne sera pas relié aux mêmes fonctions que mon entité spécialisée.

L'entité générale c'est Universitaire, non ?


JPhi33

[Chtouk]

Merci pour toutes ces réponses et ces exemples particulièrement clairs!!!

Ne t'inquiète pas pour mes délires de re-nommage, ça doit être lié à l'heure à laquelle j'ai posté!!!!

Bonne soirée

[tavarlindar]

Question en lisant ce post :

Pourquoi est-ce mal de rajouter tout simplement un attribut EstEtudiant à la table universitaire avec oui ou non comme réponse possible.

De plus, pourquoi pas mettre "non" dans la colonne EstBoursier concernant U-1 et U-4 ? Pas de valeur Null.
Une seule table à gérer ... c'est à priori plus simple , non ?

Autre question pour mieux comprendre cette notion d'héritage.
si je comprends bien, la table universitaire est la table "mère" et la table "etudiant" la table fille.
Concernant cette dernière le "ref" (u-2 et u-3) peuvent donc être considérées comme des cles étrangères, non ?

[fsmrel]

Autre question pour mieux comprendre cette notion d'héritage.
si je comprends bien, la table universitaire est la table "mère" et la table "etudiant" la table fille.
Concernant cette dernière le "ref" (u-2 et u-3) peuvent donc être considérées comme des cles étrangères, non ?

La clé primaire de la table ETUDIANT hérite très naturellement de celle de la table UNIVERSITAIRE :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
Create Table UNIVERSITAIRE (
    Ref            Integer         Not Null
  , NomUniv        VarChar(32)     Not Null
  , PrenomUniv     VarChar(32)     Not Null
  , Primary Key (Ref)
) ;
Create Table ETUDIANT (
    Ref            Integer         Not Null
  , EstBoursier    Char(3)         Not Null
                      Check (EstBoursier IN ('oui', 'non'))
  , Primary Key (Ref)
  , Foreign Key (Ref) References UNIVERSITAIRE
) ;

L’attribut Ref de la table ETUDIANT participe à la clé primaire de celle-ci et à la clé étrangère référençant UNIVERSITAIRE. Ainsi, le verbe "pouvoir" doit être remplacé par le verbe "devoir".

[epsilon68]

d'un point de vue conceptuel super, mais en pratique se taper toujours les jointures c'est pas cool. Surement que cet exemple est trop simple mais complexifier juste pour rien, c'est inutile :-)

[tavarlindar]

fsmrel,
merci pour ta réponse.

En essayant de comprendre ta réponse, je viens de comprendre que je dois revoir toute ma base de données ! Merci !
Je n'utilisais pas de définition de clé étrangère dans ma base MySql.
Bref, tout un programme.

Cela étant dit, j'ai pour habitude de nommer mes clés primaires en reprenant le nom de la table précédé d'un id. Pour les clés étrangères j'inverse.

Donc ici plutôt que ref j'aurais mis id_universitaire comme clé primaire de la table Universitaire et universitaire_id comme nom de clé étrangère dans la table Etudiant.

Ce qui aurait donné :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
Table UNIVERSITAIRE
id_universitaire     NomUniv PrenomUniv
---------------    -------   ----------
U-1                     DUBOIS  Aline     
U-2                     DUPONT  Bertrand  
U-3                     DURAND  Charlène  
U-4                     MARTIN  Didier  

Table ETUDIANT
universitaire_id     EstBoursier
---                     -----------
U-2                     Non
U-3                     Oui

Ici, si je comprends bien, en fait, RIEN DE TOUT CELA;
on a id_universitaire dans les deux tables avec une particularité id_universitaire de la table Etudiant est aussi définit comme un clé étrangère par rapport à la table Universitaire [ via un constraint 'regle1' Foreign key ('id_universitaire') references univeristaire ('id_universitaire') . dans le cas de Mysql]

Est-ce bien cela ?

[fsmrel]

Bonsoir,

Je n'utilisais pas de définition de clé étrangère dans ma base MySql.
Bref, tout un programme.

Je vois bien votre prochain programme : rechercher les orphelins dans l’ensemble de vos tables...

Ainsi, pour reprendre l’exemple des étudiants, rechercher les étudiants qui ne sont pas universitaires :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
Select e.ref
From   ETUDIANT e
Where  Not Exists (Select *
                   From   UNIVERSITAIRE u
                   Where  e.ref = u.ref)

j'ai pour habitude de nommer mes clés primaires en reprenant le nom de la table précédé d'un id. Pour les clés étrangères j'inverse.

Chaque entreprise édicte ses propres normes quant à la façon de nommer les attributs, les tables, les index, etc. Maintenant, si vous êtes libre de choisir, imposez-vous votre propre discipline, faites comme vous estimez que cela doit être fait : ça n’est pas le problème du Modèle relationnel ou de SQL (lequel peut à l’occasion vous imposer une limite sur la taille des noms ou imposer des règles du genre (c'est SGBD dépendant) : pas de chiffre comme premier caractère d’un nom, etc.)

on a id_universitaire dans les deux tables avec une particularité id_universitaire de la table Etudiant est aussi définit comme un clé étrangère par rapport à la table Universitaire [ via un constraint 'regle1' Foreign key ('id_universitaire') references univeristaire ('id_universitaire') . dans le cas de Mysql]

Je ne connais pas MySQL. Ceci dit, par référence à ce que j’ai écrit ci-dessus : dans la table ETUDIANT, vous devriez pouvoir renommer id_universitaire en universitaire_id si vous en avez envie.


Une dernière précision : une base de données n’est pas décrite qu’en termes d’anatomie, il y a du métabolisme là-dedans. Autrement dit, pour supprimer l’étudiant tavarlindar, on écrit :

Delete From UNIVERSITAIRE Where NomUniv = 'tavarlindar' ;

et pour que le SGBD achève le travail au niveau de la table ETUDIANT, il faut ajouter le trigger qui va bien :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
Create Table ETUDIANT (
    Ref            Integer     Not Null
  , EstBoursier    Char(3)     Not Null    Check (EstBoursier IN ('oui', 'non'))
  , Primary Key (Ref)
  , Foreign Key (Ref) References UNIVERSITAIRE (Ref)
          On Delete Cascade
) ;

[fsmrel]

On parle d'entités, donc on se situe au niveau conceptuel. Le gain à envisager n'est certainement pas technique (même si ce gain se répercute effectivement au niveau technique).
Ici, il s'agit d'obtenir une meilleure représentation du monde réel (abstraction). Distinguer, parmi les Universitaires, une population d'Etudiants ayant des caractéristiques particulières (attributs, associations, DF, CIF), c'est obtenir une meilleure abstraction du monde réel. On gagne donc en clarté, en compréhension et en évolutivité ; même s'il n'y a qu'une seule entité spécialisée.

Comme le dit fort justement JPhi33 à propos de l'entité-type UNIVERSITAIRE, il peut très bien n’y avoir qu’une seule entité-type spécialisée, ETUDIANT en l’occurrence. Pour prendre un exemple de Chris Date concernant les figures géométriques (lesquelles sont connues de tous), et dont il se sert pour parler des types purs, FIGURE_PLANE est un surtype, qui a pour sous-types ELLIPSE et POLYGONE. A son tour, ELLIPSE se comporte en surtype par rapport au sous-type CERCLE et celui-là seul. En effet, un hypothétique sous-type ELLIPSE_NON_CERCLE n’apporterait aucune valeur ajoutée et devrait disparaître au nom du rasoir d’Ockham. L’intérêt de spécialiser ELLIPSE en CERCLE apparaît pleinement du fait des contraintes propres aux cercles (grand axe et petit axe de même longueur) et des opérateurs dédiés (calcul de la surface par exemple).
Pour en revenir aux universitaires, si on commençait à parler des salaires, alors on subodore que le sous-type ETUDIANT ne serait plus seul...

[tavarlindar]

Intéressant comme sujet ....
Bien que le sujet soit clos par son auteur, j'ai une nouvelle petite question au passage, question qui me vient après avoir parcouru la toile et lu de très nombreux post sur x forum.

Ma question porte sur les tables filles ou enfant si on ne veut pas mettre du sexe dans tout cela . ( je me lâche, j'ai la tête en compote ...)

Ma question porte sur la nécessité ou pas de définir une clé primaire propre à une table fille selon qu'elle est dernier enfant ou pas.
ici
on voit bien qu'une clé primaire est définie pour 'identTable2' (III-C)

Si une table fille n'a pas de relation autre qu'avec sa table mère, le fait de définir un id propre n'a que peu d'intérêt semble t-il. Par contre si la table fille en question a des relations avec d'autres tables, qu'est en sont les incidences ?

Suis-je clair ???

[fsmrel]

Si une table fille n'a pas de relation autre qu'avec sa table mère, le fait de définir un id propre n'a que peu d'intérêt semble t-il.

Questions du même tonneau : Faut-il multiplier des entités inutiles ? Si une hypothèse est inutile pour élaborer une théorie faut-il la formuler, etc.? Selon le rasoir d’Ockham, la réponse est évidemment négative. En effet :

Vous avez considéré que l’attribut id_universitaire était identifiant de l’entité-type UNIVERSITAIRE. Par ailleurs, un étudiant est un (is a) universitaire, en conséquence de quoi l’entité-type ETUDIANT hérite des propriétés de l’entité-type UNIVERSITAIRE, donc de son identifiant. Si l’on transpose cela au niveau logique, la table UNIVERSITAIRE a pour clé primaire {id_universitaire} et la table ETUDIANT a aussi pour clé primaire {id_universitaire}. Par ailleurs, il ne faut pas raisonner en termes de mère et fille, puisqu’un étudiant EST un universitaire et n’est pas sa propre fille...

on voit bien qu'une clé primaire est définie pour 'identTable2' (III-C)

Certes, puisque toute table doit être munie d’une clé (sinon c’est un sac, dans lequel les doublons sont légaux). Mais pour prendre l’exemple auquel vous faites référence, la relation entre laTable1 et laTable2 n’est pas une relation d’héritage. Par exemple, si vous remplacez laTable1 par ENTREPRISE et laTable2 par ETUDIANT, on peut intuiter qu’un étudiant effectue un stage dans une entreprise, mais certainement pas qu’une entreprise est un étudiant, puisqu'elle ne fait qu'accueillir. En tout état de cause, le lien entre l'étudiant et l'entreprise est défini par une contrainte d’intégrité référentielle, et la table ETUDIANT comporte une clé étrangère supplémentaire, référençant la table ENTREPRISE. A noter que {id_entreprise} ne peut pas être clé primaire de la table ETUDIANT, pour raison de doublons (une même entreprise est susceptible d'accueillir plus d'un étudiant).

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
Create Table ENTREPRISE (
    id_entreprise     Integer         Not Null
  , NomEntreprise     VarChar(32)     Not Null
  , Primary Key (id_entreprise)
) ;
Create Table UNIVERSITAIRE (
    id_universitaire  Integer         Not Null
  , NomUniv           VarChar(32)     Not Null
  , PrenomUniv        VarChar(32)     Not Null
  , Primary Key (id_universitaire)
) ;
Create Table ETUDIANT (
    id_universitaire    Integer     Not Null
  , EstBoursier         Char(3)     Not Null    
                                  Check (EstBoursier IN ('oui', 'non'))
  , id_entreprise       Integer     Not Null
  , Primary Key (id_universitaire)
  , Foreign Key (id_universitaire) References UNIVERSITAIRE 
          On Delete Cascade
  , Foreign Key (id_entreprise) References ENTREPRISE
          On Delete No action
) ;

[tavarlindar]

ok, merci pour cet éclaircissement.

au passage et à tout hasard saurais-tu répondre à cette question ?

[fsmrel]

J'ai répondu. J'utilise des triggers.