1. #1
    Membre averti

    Profil pro
    Inscrit en
    janvier 2010
    Messages
    453
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : janvier 2010
    Messages : 453
    Points : 340
    Points
    340
    Billets dans le blog
    9

    Par défaut Le typage une alternative à l'héritage ?

    Bonjour à tous,

    Pour illustrer ma question l'exemple suivant

    Une personne peut être prospect ou client -> exclusivité totale

    On pourrait donc créer l'entité personne et deux autres entités filles
    Prospect
    Client
    Qui hériteraient de personne.

    Donc un fine dans le MPD, il y aurait 3 entités

    L'alternative ne pourrait-elle pas être une entité personne et une entité typeClient avec pour cet exemple deux itérations
    Prospect
    Client

    Merci par avance pour toute contribution
    Bonjour chez vous

  2. #2
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    6 083
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 6 083
    Points : 20 111
    Points
    20 111
    Billets dans le blog
    16

    Par défaut

    Bonsoir informer,

    L’héritage, ou plutôt la spécialisation / généralisation des entités-types permet de doter telle sous-entité-type d’attributs (propriétés) qui lui sont propres, et d’entretenir avec d’autres entités-types des relations sans objet pour toute autre sous-entité-type soeur. Ainsi, CLIENT a des propriétés telles que les conditions tarifaires, la date de signature du contrat, etc. que n’a pas sa sœur PROSPECT, et elle entretient avec COMMANDE, FACTURE, etc. des relations qui ne concernent pas PROSPECT. De même, si PROSPECT est en relation avec MODE_DE_PROSPECTON, il est évident que c’est sans objet pour CLIENT.

    Au stade SQL, mieux vaut trois tables propres, avec des colonnes NOT NULL, qu’une seule table bien engraissée de NULL nuisibles (notamment dans le cas des clés étrangères !) ou de « blancs » inutiles et coûteux.
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    De grâce, pas de questions techniques par MP, ma boîte de réception explose !
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  3. #3
    Membre averti

    Profil pro
    Inscrit en
    janvier 2010
    Messages
    453
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : janvier 2010
    Messages : 453
    Points : 340
    Points
    340
    Billets dans le blog
    9

    Par défaut

    Bonjour fsmrel

    Merci pour ta réponse.

    Tu pointes les limites de la deuxième solution. Mais imaginons maintenant le cas suivant concernant une entité générique matériel et ses entités filles
    Clavier
    Écran
    Souris
    Si je modélise avec un héritage j'ai donc 4 tables.

    Quels sont les impacts sur le code SQL si je dois ajouter une nouvelle entité pour clé wifi par exemple et à chaque fois que j'ajoute un matériel?

    Dans le cas 2 d'une table bien dodue, certes elle deviendra encore plus dodue mais fondamentalement les requêtes ne changeront pas puisqu'il y a simple ajout d'une valeur pour l'attribut de typage pour chaque nouveau matériel et d'attributs particuliers à chaque matériel dans la même table, la bien nommée dodue?
    Dans ce cas la 2FN n'est effectivement pas respectée

    Pour le cas avec un héritage, il aura création d'autant de tables que de matériel et ça peut vite devenir lourd (centaines de tables) et je subodore que cela sera beaucoup plus impactant sur les requêtes SQL?

    Encore une question, comment modéliser un relation réflexive avec un héritage ? Cas d'un matériel composé d'autres matériels ?

    Merci pour ta réponse
    Bonjour chez vous

  4. #4
    Expert éminent

    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    3 402
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 3 402
    Points : 7 565
    Points
    7 565
    Billets dans le blog
    1

    Par défaut

    Dans le cas où les déclinaisons de sous-type sont nombreuses, et le nombre d'attributs communs au sur-type faible, il est préférable d'envisager une métamodélisation

    Voyez ICI

  5. #5
    Membre averti

    Profil pro
    Inscrit en
    janvier 2010
    Messages
    453
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : janvier 2010
    Messages : 453
    Points : 340
    Points
    340
    Billets dans le blog
    9

    Par défaut

    Merci beaucoup escartefigue pour ce lien dont l'exemple est très didactique et qui illustre les limites de l'héritage dans un SGBDR.

    Pour clore le post voici ce que Power*AMC apporte comme réponses. On notera que la dernière solution correspond à celle du typage (dite table dodue)


    Nom : PowerAMC_heritage1.jpg
Affichages : 66
Taille : 1,03 Mo
    Bonjour chez vous

  6. #6
    Membre averti

    Profil pro
    Inscrit en
    janvier 2010
    Messages
    453
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : janvier 2010
    Messages : 453
    Points : 340
    Points
    340
    Billets dans le blog
    9

    Par défaut

    Continuons sur l’exemple de la personne prospect ou client qui est traitée par un héritage

    Si j’ai bien compris il y aura 3 tables mais cela ne complexifie-t-il pas les traitements SQL?

    Par exemple pour connaître le statut de la personne, ne faut-il par obligatoirement pas

    • des jointures entre la table père et les deux fils
    • du traitement dans le SQL voire des procs stocks


    Ce n’entraîne pas
    • Du code source d’erreur
    • Des jointures source de temps machine


    Merci
    Bonjour chez vous

  7. #7
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    6 083
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 6 083
    Points : 20 111
    Points
    20 111
    Billets dans le blog
    16

    Par défaut

    Bonsoir informer,


    Citation Envoyé par informer Voir le message
    Continuons sur l’exemple de la personne prospect ou client qui est traitée par un héritage
    Si j’ai bien compris il y aura 3 tables mais cela ne complexifie-t-il pas les traitements SQL?
    Non. Faites une vue PERSONNE_CLIENT et une vue PERSONNE_PROSPECT, voire une vue PERSONNE_CLIENT_PROSPECT pour encapsuler les jointures (ou les unions), vous pourrez ainsi manipuler des tables virtuelles structurellement simples, tout comme si c’était des tables réelles.


    Citation Envoyé par informer Voir le message
    Par exemple pour connaître le statut de la personne, ne faut-il par obligatoirement pas

    • des jointures entre la table père et les deux fils
    • du traitement dans le SQL voire des procs stocks
    Utilisez les vues évoquées ci-dessus.


    Citation Envoyé par informer Voir le message
    Ce n’entraîne pas
    • Du code source d’erreur
    Une fois de plus, utilisez les vues.


    Citation Envoyé par informer Voir le message
    Ce n’entraîne pas
    • Des jointures source de temps machine
    J’ai une vue de 90 jointures (internes/externes), la table principale — appelons-la MOUVEMENT — comportant 100 000 lignes : 250 ms pour accéder aux données via la vue et récupérer une centaine de lignes (mouvements et données jointes). J’utilise PostgreSQL sur mon modeste PC. Il y a trente ans, même sur un mainframe hébergeant DB2, je n’aurais pas osé, mais on n'est plus en 1988...

    Je vous engage à vous retrousser les manches et effectuer vos propres tests (en utilisant l’identification relative au stade conceptuel et en plaçant correctement les index sur les tables en jeu).
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    De grâce, pas de questions techniques par MP, ma boîte de réception explose !
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  8. #8
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    6 083
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 6 083
    Points : 20 111
    Points
    20 111
    Billets dans le blog
    16

    Par défaut PowerAMC et héritage

    Bonsoir à nouveau, informer,


    Citation Envoyé par informer Voir le message
    Pour clore le post voici ce que Power*AMC apporte comme réponses.
    PowerAMC (sans astérisque) a apporté ces réponses il y a au moins 25 ans, du temps où l’AGL était français (SDP, 8, allée de l’ancien Pont - 92150 Suresnes) et était nommé AMC*Designor (avec astérisque cette fois-ci).

    Photo de la couverture de la version 4 (copyright 1990-1993) :




    Comme sur la couverture ça n’est pas très lisible, voici la partie du MCD qui nous concerne :



    Quand PowerSoft a racheté l’AGL (1995) on a eu droit à un Guide de l’utilisateur version papier, épais (plus de 500 pages), qui m’est toujours utile, parce que c’est quand même plus confortable de tourner les pages d’un bouquin doté d'un bon index que de crapahuter dans la toile.

    Bien entendu, sont décrits dans ce guide (en 1995, je le rappelle) les différents modes de génération des tables auxquels vous faites allusion (1, 2, ou 3 tables) :




    Mais les auteurs de Merise avaient déjà décrit tout ça dans les années quatre-vingts. Voyez par exemple d’A. Rochfeld et J. Morejon, La Méthode MERISE. Tome 3. Gamme opératoire (Les Éditions d'organisation, 1989), pages 194-197.


    Citation Envoyé par informer Voir le message
    On notera que la dernière solution correspond à celle du typage (dite table dodue)
    Vous avez bien raison, c’est un fait qu’il serait absurde de tout fourrer dans une seule table car, entre autres inconvénients (tendance à l’obésité par exemple), le bonhomme NULL se régalerait et, ce que l’on sait moins, il démolit le théorème de Heath et inhibe l’optimiseur des SGBD relationnels.

    Ne générer que les tables dérivées des sous-entités-types (CLIENT et FOURNISSEUR pour reprendre l’exemple ci-dessus, avec absorption des attributs de l’entité-type générique ORGANISME) peut se défendre quand elles sont exclusives l’une de l’autre, mais au prix du doublement des associations branchées sur l’entité-type générique.

    Clairement, dans la majorité des cas, générer une table pour l’entité-type générique (ORGANISME) et une table par sous-entité-type (CLIENT, FOURNISSEUR) s’impose. Le bonhomme NULL ne pourra pas ficher la patouille, et au moyen de vues, il est possible de reproduire les deux cas précédents, sans altérer les tables.
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    De grâce, pas de questions techniques par MP, ma boîte de réception explose !
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  9. #9
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    6 083
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 6 083
    Points : 20 111
    Points
    20 111
    Billets dans le blog
    16

    Par défaut

    A titre de complément :

    Héritage ou pas héritage ?
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    De grâce, pas de questions techniques par MP, ma boîte de réception explose !
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  10. #10
    Membre averti

    Profil pro
    Inscrit en
    janvier 2010
    Messages
    453
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : janvier 2010
    Messages : 453
    Points : 340
    Points
    340
    Billets dans le blog
    9

    Par défaut

    Merci fsmrel pour toute ces informations.

    Il n’y a pas de lois gravées dans le marbre mais bien des stratégies possibles en fonction d’un besoin.
    Bonjour chez vous

Discussions similaires

  1. une alternative à Enterprise Manager ???
    Par Ekimasu dans le forum MS SQL-Server
    Réponses: 1
    Dernier message: 04/08/2005, 15h35
  2. Exite-t-il une alternative à SELECT ... INTO?
    Par Ditch dans le forum MS SQL-Server
    Réponses: 6
    Dernier message: 19/04/2005, 09h52
  3. Une alternative à XCloseDisplay(Display *dpy) ?
    Par Michaël dans le forum Applications et environnements graphiques
    Réponses: 6
    Dernier message: 10/02/2005, 09h32
  4. Une alternative a ... ?
    Par Crapouille dans le forum OpenGL
    Réponses: 3
    Dernier message: 13/08/2004, 13h51
  5. Une alternative à glut
    Par davcha dans le forum GLUT
    Réponses: 3
    Dernier message: 11/07/2004, 09h19

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo