Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Schéma Discussion :

Demande avis sur mon MCD


Sujet :

Schéma

  1. #1
    Membre habitué
    Demande avis sur mon MCD
    Bonjour,

    Je suis en train de faire un MCD dans le cadre de ma formation et je voudrai savoir si mon MCD convient ou si il y a des choses à revoir.

    Contexte :

    C'est un site de vente de voiture qui mettra en relation par l'intermédiaire du propriétaire du site M. X des professionnels et des particulier.

    M. X souhaiterait une plateforme permettant aux professionnels de mettre à disposition des voitures d’occasions sous forme d’annonce.

    - Le site possédera une barre de recherche (marque, modèle, carburant, etc) et une liste d'annonce.
    - Le particulier devra contacter M. X si il est intéressé par une voiture.
    - Les professionnels ne pourront pas créer de compte par eux-mêmes ils enverront les info nécessaire Nom, prénom, Adresse mail, téléphone, siret.
    - Chaque professionnel pourra avoir plusieurs garage avec nom, adresse, téléphone.
    - Chaque garage pourra avoir aucune ou plusieurs annonces.
    - Une annonce aura : photos, titre, description, année de mise en circulation, kilométrage, prix modèle, carburant.
    - L'année, la marque, modèle ou carburant seront des listes déroulantes.

    Là ou j'ai un doute c'est pour l'héritage et la connexion adresse civilité pour le garage.
    Voilà merci pour votre aide.

    Voici mon MCD :

  2. #2
    Expert éminent sénior
    Bonjour hbx360,

    Observation E1

    L’association DETENIR entre GARAGE et CIVILITE est louche. En effet, sauf l’adresse électronique et le téléphone, les attributs de CIVILITE ne concernent en rien les garages...


    Observation E2

    Pour le garage g1, via l’association DETENIR entre GARAGE et CIVILITE g1 détermine la civilité c1. Via les associations APPARTENIR et AVOIR, g1 peut déterminer la civilité c2, ce qui est fâcheux, c’est du trapèze sans filet.


    Observation E3

    L’entité-type CARACTERISTIQUE n’est porteuse d’aucune propriété naturelle : sémantiquement parlant, l’héritage dont elle est la source n’apporte rien. En plus il faudra programmer la contrainte XT.

    Je regarderai tout ça de plus près, tandis que le Capitaine Escartefigue et Paprick auront certainement pas mal de choses à dire (si ce n'est déjà fait).

    Par ailleurs, vous aurez à générer le code SQL correct de création des tables, aussi je vous engage vivement à utiliser l’excellent AGL Looping.
    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 »)

    Je ne réponds pas aux questions techniques par MP. Les forums sont là pout ça.
    __________________________________
    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
    Expert éminent sénior
    Quelles informations, quelles fonctionnalités perdriez-vous en supprimant l’association DETENIR entre GARAGE et CIVILITE ?

    D’autre part, la cardinalité 1,N portée par l’association AVOIR fait que le tuple (ligne)

    <estHomme='vrai', nom='Martin', prenom='Pierre', email='p.martin@machin.fr', telephone='0123456789'>

    est applicable à plus d’un client, ce qui doit quand même être plutôt rare. Bref, quel inconvénient à rapatrier les attributs de CIVILITE dans CLIENT ?
    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 »)

    Je ne réponds pas aux questions techniques par MP. Les forums sont là pout ça.
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  4. #4
    Membre éclairé
    Bonjour,
    En complément des remarques déjà formulées à juste titre par fsmrel, voici quelques points qui me paraissent discutables :
    • Comme déjà noté, le choix de l'héritage autour de "Caractéristique" ne me parait pas judicieux : en effet, surtout avec la contrainte de partition XT, cela signifierait que le véhicule à soit des portes, soit une boite de vitesse, soit du Co2, soit... bref, toutes ces rubriques caractérisent un modèle de véhicule, je pense que le MCD gagnerait à être réalisé bien plus simplement en ce sens.
    • Vouloir regrouper les nom, prénom, email et téléphone au sein d'une même classe d'entités concernant clients professionnels, particuliers et garages n'est pas forcément une bonne idée : en effet, le fait que certaines classes d'entités aient des rubriques similaires ne signifie pas forcément que ces rubriques doivent être regroupées... Le nom d'un garage n'a rien à voir avec le nom d'un client, même si les deux sont des noms. Y-a-t-il un intérêt à avoir toutes ces informations dans la même classe... j'en doute...
    • Même doute pour la classe d'entités "Adresse"...

    Bref, je pense que vous devriez réfléchir en termes d'entités présentes dans le SI (client, garage, annonce, ...) et simplifier considérablement votre MCD, même si vous aurez parfois l'impression (à tord) que certaines rubriques sont redondantes.
    Petite curiosité personnelle : quel logiciel avez-vous utilisé pour réaliser ce MCD ? Je vois que vous pouvez utiliser plusieurs fois le même nom d'association... certes, avec ces cardinalités, elles ne génèreront pas de tables pour le schéma relationnel, mais cela reste tout de même cavalier...
    Bonne continuation, et suivez attentivement les conseils de fsmrel.
    Patrick Bergougnoux - Professeur des Universités au Département Informatique de l'IUT de Toulouse III
    La simplicité est la sophistication suprême (Léonard de Vinci)
    LIVRE : Modélisation Conceptuelle de Données - Une Démarche Pragmatique
    Looping - Logiciel de modélisation gratuit et libre d'utilisation

  5. #5
    Expert éminent sénior
    Citation Envoyé par Paprick Voir le message
    quel logiciel avez-vous utilisé pour réaliser ce MCD ?


    Il s’agit de JMerise, qui a rendu pas mal de services au niveau MCD, mais qui est défaillant lors de la génération SQL.
    Vois par exemple JFreesoft dans le forum Merise.
    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 »)

    Je ne réponds pas aux questions techniques par MP. Les forums sont là pout ça.
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  6. #6
    Expert éminent sénior
    Adresses :

    hbx360, selon votre MCD, un client, qu’il soit professionnel ou particulier, habite au moins et au plus à une adresse. Soit.
    Par ailleurs, à une adresse habite au moins un client : si c’est l’adresse d’un garage, il se peut effectivement qu’un professionnel (disons le patron du garage) y habite, ou encore un ou plusieurs particuliers, mais il se peut aussi qu’aucun client n’habite à l’adresse de ce garage : logiquement, la cardinalité 1,N de la patte connectant ADRESSE et HABITER doit devenir 0,N.
    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 »)

    Je ne réponds pas aux questions techniques par MP. Les forums sont là pout ça.
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  7. #7
    Membre habitué
    Merci beaucoup à tout le monde pour votre aide je vais revoir mon MCD.
    Oui c'est bien jMerise mais c'est vrai qu'il est limité.

  8. #8
    Membre habitué
    Suivant vos recommandation j'ai modifier mon MCD :



    J'aurai quelques questionnements concernant :

    - L'entité caractéristique :
    J'ai fait l'héritage comme vue dans mon 1er MCD en me basant sur un exo qu'on avait fait. Comme sa ressemblais, je me suis dit que je pouvais faire pareil ; c'est l'entité composant (en haut à gauche).
    Je vous montre la correction de celui-ci :



    On voit qu'il y a un XT j'ai repris cette contrainte dans mon MCD.

    Paprick dit :

    Comme déjà noté, le choix de l'héritage autour de "Caractéristique" ne me parait pas judicieux : en effet, surtout avec la contrainte de partition XT, cela signifierait que le véhicule à soit des portes, soit une boite de vitesse, soit du Co2, soit... bref, toutes ces rubriques caractérisent un modèle de véhicule, je pense que le MCD gagnerait à être réalisé bien plus simplement en ce sens.
    Dans composant c'est bien pareille n'a-t-on pas soit un processeur, soit un barette de RAM, etc.
    Mais comme on parle d'un composant et qu'un ordinateur peut avoir 1 ou plusieurs composant sa me semblais logique ?
    Parce que, si on avait tout mis dans composant, sa aurait voulu dire qu'un composant est constitué de plusieurs éléments et donc la cardinalité (1,N) du côté ordinateur n'aurait pas été bonne non ?
    Sa voudrait dire que un ordinateur peut avoir 1 ou plusieurs composants qui sont eux-même constitués d'un processeur, carte, lecteur RAM etc qu'en pensez-vous ? Donc on pourrait avoir un ordinateur avec 2 lecteurs, 2 processeurs, 2 cartes mères, 2 carte PCI, etc ?

    - Pour l'entité adresse je l'ai mis en entité car j'ai lu que sa pouvais évité d'avoir la même adresse est-ce judicieux ?
    voir le cours https://sqlpro.developpez.com/cours/...tion/heritage/ ou il est dit :

    Enfin, pour résoudre la problématique des adresses multiples, rien ne nous empêche d'externaliser les adresses dans une table à part :
    - Concernant les cardinalités je rencontre des difficultés car c'est suivant notre interprétation. Ex : un propriétaire peut avoir 1 ou plusieurs chien mais un chien peut avoir un seul et un seul propriétaire, mais on pourrait le voir aussi de cette façon : un chien peut avoir un ou plusieurs propriétaires dans sa vie. Donc comment savoir quel cardinalité mettre ? Si on parle de propriétaire il est naturellement évident qu'il à automatiquement un chien donc on à 1 en cardinalité on ne peut pas mettre 0 non ?

    - Quand on dit une adresse peut avoir 0 ou plusieurs clients est-ce que sa veut dire qu'a la même adresse on a plusieurs client ? Ou bien cela veut-il dire que pour une infinité d'adresse on a une infinité de clients ?
    J'ai du mal avec ce type d'association à bien savoir quoi mettre car pour moi j'aurai tendance à mettre 1 adresse = 1 client et un client = 1 adresse ce qui obligerait à tout mettre dans la même entité mais dans le même cours cité plus haut au chapitre 3 il mette en cardinalité : personne 0,N possède 0,N adresse.

    - Si on doit mettre pour les associations un seul verbe comment on fait si on a plusieurs dizaine d'association ? Je trouve qu'on est assez limité en verbe non ?

  9. #9
    Expert éminent sénior
    Bonjour,

    hbx360, la 2e version de votre MCD a l'air d'être correcte. Attention toutefois à la production du code SQL de création des tables, puisque JMerise est souvent défaillant à ce stade. Prenez calmement le temps de reprendre ça avec Looping, histoire de vous rassurer, dans la série ceinture, bretelles et épingle à nourrice...

    Je ne reprends pas ici tout ce que écrivez dans votre post, mais je fais quand même une mise au point quant aux cardinalités, sources de certaines difficultés pour vous. Je vous cite :

    Citation Envoyé par hbx360 Voir le message
    Concernant les cardinalités je rencontre des difficultés car c'est suivant notre interprétation. Ex : un propriétaire peut avoir 1 ou plusieurs chien mais un chien peut avoir un seul et un seul propriétaire, mais on pourrait le voir aussi de cette façon : un chien peut avoir un ou plusieurs propriétaires dans sa vie. Donc comment savoir quel cardinalité mettre ? Si on parle de propriétaire il est naturellement évident qu'il à automatiquement un chien donc on à 1 en cardinalité on ne peut pas mettre 0 non ?


    Dans cet exemple, puisqu’un chien a pu avoir plus d’un maître dans sa vie, il faut prendre en compte la dimension temporelle. D’une façon générale, on sépare la partie historique (DEPUIS telle date le toutou a tel maître, et auparavant, DURANT telle période, il a eu tel maître). Je détaille ce distinguo DEPUIS / DURANT dans le paragraphe 6.4 « Données actives et données historisées » de mon article Bases de données relationnelles et normalisation : de la première à la sixième forme normale.

    En admettant les règles de gestion suivantes :

    RG01 : à une date donnée un toutou a exactement (c’est-à-dire au moins et plus) un maître ;

    RG02 : à une date donnée un maître peut avoir plusieurs toutous (il peut hélas ne plus en avoir, c’est la vie...) ;

    Le MCD correspondant est le suivant, avec une CIF (contrainte d’intégrité fonctionnelle) exprimant la contrainte d’unicité de la règle RG01 (en notant par ailleurs qu’un maître peut ne plus posséder de toutou) :



    Génération SQL par Looping (notez la clé primaire de la table POSSEDER) :

    CREATE TABLE LA_DATE
    (
       laDate DATE,
       CONSTRAINT LA_DATE_PK PRIMARY KEY(laDate)
    );
    
    CREATE TABLE TOUTOU
    (
       toutouId INT,
       CONSTRAINT TOUTOU_PK PRIMARY KEY(toutouId)
    );
    
    CREATE TABLE MAITRE
    (
       maitreId INT,
       CONSTRAINT MAITRE_PK PRIMARY KEY(maitreId)
    );
    
    CREATE TABLE POSSEDER(
       toutouId INT,
       laDate DATE,
       maitreId INT NOT NULL,
       CONSTRAINT POSSEDER_PK PRIMARY KEY(toutouId, laDate),
       CONSTRAINT POSSEDER_DATE_FK FOREIGN KEY(laDate) REFERENCES LA_DATE(laDate),
       CONSTRAINT POSSEDER_TOUTOU_FK FOREIGN KEY(toutouId) REFERENCES TOUTOU(toutouId),
       CONSTRAINT POSSEDER_MAITRE_FK FOREIGN KEY(maitreId) REFERENCES MAITRE(maitreId)
    ; 


    Ce code SQL est une conséquence du MCD merisien, dans lequel je n’ai pas fait le distinguo traité dans mon article, ce dont on peut se dispenser ici.

    Sinon, si l’on tient à mettre le passé en évidence pour un toutou qui a son maître à lui :



    code SQL généré par Looping :

    CREATE TABLE MAITRE
    (
       maitreId INT,
       CONSTRAINT MAITRE_PK PRIMARY KEY(maitreId)
    );
    
    CREATE TABLE TOUTOU
    (
       toutouId INT,
       maitreId INT NOT NULL,
       CONSTRAINT TOUTOU_PK PRIMARY KEY(toutouId),
       CONSTRAINT TOUTOU_MAITRE_FK FOREIGN KEY(maitreId) REFERENCES MAITRE(maitreId)
    );
    
    CREATE TABLE JADIS
    (
       toutouId INT,
       dateDebut DATE,
       dateFin DATE NOT NULL,
       maitreId INT NOT NULL,
       CONSTRAINT JADIS_PK PRIMARY KEY(toutouId, dateDebut),
       CONSTRAINT JADIS_TOUTOU_FK FOREIGN KEY(toutouId) REFERENCES TOUTOU(toutouId),
       CONSTRAINT JADIS_MAITRE_FK FOREIGN KEY(maitreId) REFERENCES MAITRE(maitreId)
    );
    
    Il y a pas mal à dire quant aux périodes, car le type correspondant n’est guère disponible qu’avec PostgreSQL, mais bon...
    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 »)

    Je ne réponds pas aux questions techniques par MP. Les forums sont là pout ça.
    __________________________________
    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 habitué
    Merci pour ta réponse fsmrel.
    Comme c'est ok pour mon MCD alors je vais passer par looping car effectivement si je ne prends pas la version payante de jMerise je vais être très limité.
    J'aurai tout à refaire mais bon pas grave.

  11. #11
    Expert éminent sénior
    Bonjour hbx360,

    Tout à refaire, soit, mais le jeu en vaut la chandelle. Et puis si vous rencontrez des difficultés, vous pouvez toujours compter sur l'aide de Paprick, celle du Capitaine Escartefigue et la mienne.

    Bonne route !
    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 »)

    Je ne réponds pas aux questions techniques par MP. Les forums sont là pout ça.
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  12. #12
    Membre éclairé
    Bonjour,
    Citation Envoyé par hbx360 Voir le message
    J'aurai tout à refaire mais bon pas grave.
    Rassurez-vous, la reprise de votre MCD sous Looping ne devrait vous prendre que quelques dizaines de minutes, qui seront largement rentabilisées lors du passage au MLD et aux requêtes SQL de création de la base de données.

    Bonne continuation !
    Patrick Bergougnoux - Professeur des Universités au Département Informatique de l'IUT de Toulouse III
    La simplicité est la sophistication suprême (Léonard de Vinci)
    LIVRE : Modélisation Conceptuelle de Données - Une Démarche Pragmatique
    Looping - Logiciel de modélisation gratuit et libre d'utilisation

  13. #13
    Expert éminent sénior
    Bonsoir,

    hbx360, une partie qui reste à éclaircir...

    Citation Envoyé par hbx360 Voir le message
    Quand on dit qu’une adresse peut avoir 0 ou plusieurs clients est-ce que ça veut dire qu'à la même adresse on a plusieurs clients ?


    Cela veut dire qu’à une adresse donnée, disons a1, à n’importe quel moment, peuvent résider 0 client, 1 ou 2 ou 3 ou N clients. La liste de ces clients peut évoluer dans le temps, du fait des changements d’adresse des clients, de la prise en compte de nouveaux clients, de leur suppression, etc.

    Exemple, situation à la date t1

    ADRESSE
    idAdresse
    a1
    a2
    a3
    a4
    a5
    a6
    a7
    
    CLIENT
    idClient    idAdresse  
    c1          a5 
    c2          a2
    c3          a1
    c4          a2
    c5          a6
    c6          a5
    c7          a2
    c8          a6
    c9          a4
    
    Dans cet instantané pris à la date t1, on constate que seul le client c3 réside à l’adresse a1, 3 clients résident à l’adresse a2, aucun client ne réside à l’adresse a3, seul le client c9 réside à l’adresse a4, 2 clients résident à l’adresse a5, 2 clients résident à l’adresse a6, aucun client ne réside à l’adresse a7.


    Citation Envoyé par hbx360 Voir le message
    Ou bien cela veut-il dire que pour une infinité d'adresses on a une infinité de clients ?


    Pour une infinité d’adresses, à la date t, on peut avoir 0 client, 1 client, 2 client, une infinité de clients (si tant est que le terme « infinité » ait ici un sens...) On sort du contexte de Merise et de celui du modèle relationnel de données pour entrer dans celui de la théorie des ensembles, voyez à cette occasion l’exemple de l’Hôtel de Hilbert, hôtel hébergeant une infinité de clients, tandis qu’arrive un car bourré d’une infinité de nouveaux clients à héberger eux aussi).


    Citation Envoyé par hbx360 Voir le message
    J'ai du mal avec ce type d'association à bien savoir quoi mettre
    A propos des règles de gestion des données

    L’essentiel est de commencer par rédiger les règles de gestion des données de telle sorte qu’elles répondent de façon précise à ce veut l’utilisateur. Dans l’élaboration des MCD, c’est l’étape déterminante, celle dans laquelle il ne faut pas se rater et où il faut donc consacrer un maximum de rigueur et de temps.

    (U1) Si pour l’utilisateur, la règle de gestion est

    Un client peut ne pas avoir d’adresse, et s’il en a une, c’est au plus une


    alors la patte connectant l’entité-type CLIENT et l’association RESIDER est porteuse d’une cardinalité 0,1 :

    [CLIENT]----0,1----(RESIDER)----


    (U2) Si pour l’utilisateur, la règle de gestion est

    Un client réside à au moins et au plus une adresse

    alors la patte connectant l’entité-type CLIENT et l’association RESIDER est porteuse d’une cardinalité 1,1 :

    [CLIENT]----1,1----(RESIDER)----


    (U3) Si pour l’utilisateur, la règle de gestion est

    Un client peut ne pas avoir d’adresse, mais il peut très bien en avoir plusieurs


    alors la patte connectant l’entité-type CLIENT et l’association RESIDER est porteuse d’une cardinalité 0,N :

    [CLIENT]----0,N----(RESIDER)----


    (U4) Si pour l’utilisateur, la règle de gestion est

    Un client a au moins une adresse et au plus plusieurs


    alors la patte connectant l’entité-type CLIENT et l’association RESIDER est porteuse d’une cardinalité 1,N :

    [CLIENT]----1,N----(RESIDER)----


    En les adaptant, ces règles de gestion ont leur pendant concernant la patte connectant l’entité-type CLIENT et l’association RESIDER.

    Ainsi, il ne doit y avoir aucune ambiguïté quant aux règles de gestion des données et chaque cardinalité portée par une patte d’association doit nécessairement être la conséquence d’une règle.

    Je vous engage à lire ce qu’écrivent D. Nanci (RIP) et B Espinasse Ingénierie des systèmes d'information : Merise deuxième génération (4e édition, 2001), au chapitre 7 (« Modélisation conceptuelle des données », paragraphe « Les cardinalités d’une entité type dans une relation type », pages 104 et suivantes.


    Citation Envoyé par hbx360 Voir le message
    j'aurai tendance à mettre 1 adresse = 1 client et un client = 1 adresse ce qui obligerait à tout mettre dans la même entité
    Remontez impérativement aux règles de gestion. Dans votre cas, l’une d’elles doit explicitement préciser qu’un client réside à au moins et au plus une adresse et une autre règle doit explicitement préciser qu’à une adresse réside au moins et au plus un client. Ce qui implique la représentation merisienne :

    [CLIENT]----1,1----(RESIDER)----1,1----[ADRESSE]


    En l’occurrence, il y a une magnifique bijection, et si mathématiquement parlant il n’y a pas de problème, dans le contexte des bases de données relationnelles on doit être particulièrement vigilant car la bijection est très sournoise

    Passons en effet au stade relationnel. L’usage veut qu’on mette en oeuvre des clés étrangères pour assurer la cohérence des références entre les tables issues des objets du MCD (entités-types et associations). Dans le cas de la bijection, les clés étrangères sont aussi efficaces que des cautères sur des jambes de bois. Elles n’empêchent pas des infractions comme celle-ci-dessous, bien que selon les règles (le règlement...), le client c3 réside seulement à l’adresse a1, qu’à l’adresse a1 ne réside que le seul client c3, que le client c9 réside seulement à l’adresse a4, et qu’à l’adresse a4 ne réside que le seul client c9 :


    CLIENT                                 ADRESSE
    +-----------+-----------+             +-----------+----------+
    | idClient  | idAdresse |             | idAdresse | idClient |
    |-----------+-----------|             |-----------+----------|
    |       c3  |        a1 |             |        a1 |       c9 |
    |       c9  |        a4 |             |        a4 |       c3 |
    +-----------+---- ------+             +-- --------+----------+ 
     


    La table CLIENT est conforme au règlement, mais la table ADRESSE est pourrie de tuples délinquants.

    Et voilà pourquoi, prudence oblige, l’usage en SQL est que la table CLIENT absorbe la table ADRESSE, même principe au stade MCD, les propriétés de l’entité-type ADRESSE sont évacuées dans l’entité-type CLIENT et cette entité-type ADRESSE disparaît du MCD. De loin ça ressemble à la fusion (coalescence) de deux trous noirs, à ceci près que la fusion d’entités-types ne donne quand même pas lieu à l’émission d’ondes gravitationnelles...

    Dans le cadre du modèle relationnel de données, contrairement aux SGBD de type SQL, on n’éprouve aucunement le besoin pressant de fusionner les structures des tables (pardon, des variables relationnelles), la bijection ne pose pas de problème, il suffit de déclarer une contrainte remplaçant les clés étrangères inefficaces et bonnes pour la poubelle :

    CONSTRAINT RESIDER_CHK01
            CLIENT {idClient, idAdresse} = ADRESSE {idClient, idAdresse} ; 


    Pour en savoir un peu plus, voyez mon billet « Merise : cardinalités 1,1 ---- 1,1 => intégrité référentielle = cautère sur jambe de bois  », ainsi que les commentaires qu’en fait CinePhil.


    Citation Envoyé par hbx360 Voir le message
    dans le même cours cité plus haut au chapitre 3 il met en cardinalité : personne 0,N possède 0,N adresse.
    Je n’ai pas lu ce cours, mais les cardinalités mentionnées doivent être impliquées par les règles de gestion :

    RGx - Un client peut avoir plusieurs adresses (et il est possible qu’il n’en ait aucune) ;

    RGy - A une adresse donnée on peut avoir plusieurs clients (et il est possible qu’il n’y ait personne).
    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 »)

    Je ne réponds pas aux questions techniques par MP. Les forums sont là pout ça.
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  14. #14
    Expert éminent sénior
    Bonsoir à nouveau,

    Citation Envoyé par hbx360 Voir le message
    Si on doit mettre pour les associations un seul verbe comment on fait si on a plusieurs dizaine d'association ? Je trouve qu'on est assez limité en verbe non ?


    L’utilisation par le concepteur d’un même nom pour deux associations rend pénible le travail du relecteur ou de celui qui analyse les MCD, sans parler de la tâche de l’AGL chargé par exemple de produire le code SQL. Evidemment si de manière naturelle le verbe « avoir » a tendance à proliférer, et une fois qu’on a usé des synonymes « appartenir », « posséder », « détenir », « contenir », comme disait Béru, « comment est-ce que fait-on ensuite ? » Investir dans un gros dictionnaire des synonymes ? Remplacer à l’occasion un verbe par le substantif qui va bien (« possession », « détention », etc.) Evidemment on cherchera plutôt à utiliser des verbes qui se trouvent souvent plus appropriés au plan sémantique, mais la panne sèche peut quand même se produire, et le découragement à force de tourner en rond. Quand je sèche ou suis pris par le temps, quitte à me faire incendier par les merisiens purs et durs, je n’y vais pas par quatre chemins, comme ici, où fleurissent les doux noms d’associations tels que PFC_P, PFC_C, PFC_V, etc. et que vous ne trouverez pas dans les dictionnaires.
    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 »)

    Je ne réponds pas aux questions techniques par MP. Les forums sont là pout ça.
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  15. #15
    Membre habitué
    @fsmrel : merci beaucoup pour ton aide et tes conseils et le temps que tu as passé à me répondre c'est beaucoup plus compréhensible maintenant.

    @Paprick : oui je vais y faire tranquillement.

  16. #16
    Expert éminent sénior
    Merci hbx360, et n'oubliez pas de liker les posts qui ont pu vous éclairer...
    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 »)

    Je ne réponds pas aux questions techniques par MP. Les forums sont là pout ça.
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

###raw>template_hook.ano_emploi###