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 :

Etude de cas : Concession - Noob


Sujet :

Schéma

  1. #1
    Futur Membre du Club
    Etude de cas : Concession - Noob
    Bonjour, la communauté je viens vers vous car j'ai quelque soucis dans la modélisation MCD de ma base de donnée.

    J'ai pour projet de créer un Db d'une concession de voiture (uniquement la vente de véhicule).

    Entant qu'un débutant je voudrais me tourner vers vous afin de vérifier si je part sur une bonne piste sur la réalisation de mes tables.

    Je voudrais de plus savoir si vous aviez des idées sur l'implantation d'une relation de type n-n car je ne vois pas ou je peux ajouter cella dans ma modélisation.

    Voici ci l'image du MCD. MERCIIII

    En vous remerciant de votre lecture et pour vos réponses.


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

    Tout d'abord, un point sur le vocabulaire.
    votre schéma est un MCD c'est à dire un Modèle Conceptuel des Données. Au niveau conceptuel, il n'y a pas de tables, mais des types d'entité (symbolisés par des rectangles) et des associations (symbolisées par des ovales)

    Ensuite, concernant votre question
    Je voudrais de plus savoir si vous aviez des idées sur l'implantation d'une relation de type n-n car je ne vois pas ou je peux ajouter cella dans ma modélisation.
    Les cardinalités doivent être le reflet exact des règles de gestion, règles de gestion à collecter auprès des donneurs d'ordre, la maîtrise d'ouvrage et à faire valider par celle-ci.
    Or vous n'avez mentionné aucune de ces règles de gestion. C'est pourtant le point de départ avant de commencer le MCD.

    quelques remarques par ailleurs
    • point le plus important, n'utilisez jamais d'attribut fonctionnel comme identifiant primaire d'un type d'entité
      par exemple, pour "véhicule" vous avez choisi d'utiliser l'immatriculation comme identifiant primaire. C'est tentant car unique.
      Mais...
      Si le véhicule change d'immatriculation (c'était le cas en France jusqu'à récemment lors du changement de propriétaire, c'est encore le cas pour les véhicules en WW me semble-t-il) alors il faudra mettre à jour cet identifiant dans la table résultante de l'entité-type "véhicule" mais aussi dans toutes les tables où cet identifiant est hérité comme clef étrangère (véhicule_loué par exemple)
      Ce phénomène de mise à jour en cascade peut être très pénalisant (il peut y avoir des milliers d'occurrences à modifier dans les tables où l'attribut est FK)
      Pour les identifiants primaires, utilisez de préférence un identifiant technique attribué par le SGBD, ces identifiants vous facilitent la vie et sont plus concis et donc plus performants.
      Les identifiants fonctionnels (immatriculation, n° de sécurité sociale, n° de SIREN...) peuvent bien sur être conservés comme identifiants alternatifs, uniques ou non, mais pas primaires
    • tel que vous avez positionné les cardinalités entre agence et employé par exemple, les règles de gestion sont les suivantes
      R001a : une agence emploie un et un seul employé
      R001b : un employé est employé par une à plusieurs agences
      or je suppose que c'est le contraire, du coup les cardinalités devraient être [AGENCE] 1,n --- (employer) --- 1,1 [EMPLOYE]
    • les noms des types d'entité doivent être au singulier : "employé" plutôt que "employés"
    • les cardinalités n,n coté "véhicule loué" signifient que tout véhicule est loué au moins deux fois ! :aie
    • au niveau de chaque type d'entité, il faut que tous les attributs dépendent fonctionnellement de leur identifiant.
      Or, pour l'entité-type "modèle" par exemple, ni la marque, ni la puissance ne dépendent du modèle.
      Il faudrait ici modéliser [MARQUE] 0,n --- (proposer) --- 1,1R [MODELE] 1,n --- (equiper) --- 1,n [MOTEUR]
      Dans l'entité type "marque", on trouve les attributs MA_ident (attribué par le SGBD), MA_code, MA_libellé...
      Dans l'entité type "modèle", on trouve les attributs MO_ident (attribué par le SGBD), MO_date_sortie, MO_libelle...
      Dans l'entité type "moteur", on trouve les attributs MT_ident (attribué par le SGBD), MT_reference, MT_puissance...
      note : le "R" positionné sur la cardinalité de la relation "équiper" mentionne que le modèle est identifié relativement à la marque. En effet, le modèle sans la marque n'a pas d'existence propre. C'est ce qu'on appelle une entité-type "faible". Il existe quelques cas d'homonymes d'ailleurs : Volkswagen Bora et Maserati Bora par exemple

  3. #3
    Futur Membre du Club
    Citation Envoyé par escartefigue Voir le message
    Bonjour,

    Tout d'abord, un point sur le vocabulaire.
    votre schéma est un MCD c'est à dire un Modèle Conceptuel des Données. Au niveau conceptuel, il n'y a pas de tables, mais des types d'entité (symbolisés par des rectangles) et des associations (symbolisées par des ovales)

    Ensuite, concernant votre question

    Les cardinalités doivent être le reflet exact des règles de gestion, règles de gestion à collecter auprès des donneurs d'ordre, la maîtrise d'ouvrage et à faire valider par celle-ci.
    Or vous n'avez mentionné aucune de ces règles de gestion. C'est pourtant le point de départ avant de commencer le MCD.

    quelques remarques par ailleurs
    • point le plus important, n'utilisez jamais d'attribut fonctionnel comme identifiant primaire d'un type d'entité
      par exemple, pour "véhicule" vous avez choisi d'utiliser l'immatriculation comme identifiant primaire. C'est tentant car unique.
      Mais...
      Si le véhicule change d'immatriculation (c'était le cas en France jusqu'à récemment lors du changement de propriétaire, c'est encore le cas pour les véhicules en WW me semble-t-il) alors il faudra mettre à jour cet identifiant dans la table résultante de l'entité-type "véhicule" mais aussi dans toutes les tables où cet identifiant est hérité comme clef étrangère (véhicule_loué par exemple)
      Ce phénomène de mise à jour en cascade peut être très pénalisant (il peut y avoir des milliers d'occurrences à modifier dans les tables où l'attribut est FK)
      Pour les identifiants primaires, utilisez de préférence un identifiant technique attribué par le SGBD, ces identifiants vous facilitent la vie et sont plus concis et donc plus performants.
      Les identifiants fonctionnels (immatriculation, n° de sécurité sociale, n° de SIREN...) peuvent bien sur être conservés comme identifiants alternatifs, uniques ou non, mais pas primaires
    • tel que vous avez positionné les cardinalités entre agence et employé par exemple, les règles de gestion sont les suivantes
      R001a : une agence emploie un et un seul employé
      R001b : un employé est employé par une à plusieurs agences
      or je suppose que c'est le contraire, du coup les cardinalités devraient être [AGENCE] 1,n --- (employer) --- 1,1 [EMPLOYE]
    • les noms des types d'entité doivent être au singulier : "employé" plutôt que "employés"
    • les cardinalités n,n coté "véhicule loué" signifient que tout véhicule est loué au moins deux fois ! :aie
    • au niveau de chaque type d'entité, il faut que tous les attributs dépendent fonctionnellement de leur identifiant.
      Or, pour l'entité-type "modèle" par exemple, ni la marque, ni la puissance ne dépendent du modèle.
      Il faudrait ici modéliser [MARQUE] 0,n --- (proposer) --- 1,1R [MODELE] 1,n --- (equiper) --- 1,n [MOTEUR]
      Dans l'entité type "marque", on trouve les attributs MA_ident (attribué par le SGBD), MA_code, MA_libellé...
      Dans l'entité type "modèle", on trouve les attributs MO_ident (attribué par le SGBD), MO_date_sortie, MO_libelle...
      Dans l'entité type "moteur", on trouve les attributs MT_ident (attribué par le SGBD), MT_reference, MT_puissance...
      note : le "R" positionné sur la cardinalité de la relation "équiper" mentionne que le modèle est identifié relativement à la marque. En effet, le modèle sans la marque n'a pas d'existence propre. C'est ce qu'on appelle une entité-type "faible". Il existe quelques cas d'homonymes d'ailleurs : Volkswagen Bora et Maserati Bora par exemple
    Bonjour et merci pour votre réponse et l'aide que vous m'apportez.

    [*] Le "MCD" à une forme inhabituelle car il est réalisé sur un logiciel en ligne de génération de MCD "MOCODO" et c'est une demande du professeur.
    [*] En ce qui concerne le cahier des charges c'est le suivant : Au minimum 10 tables avec 45 Attributs et avec différents types de variable et pour finir différents types de cardinalité dont la N,N.
    [*] Merci pour vos différentes remarques !!!!
    [*] Moi qui pensais avoir trouver ma relation N-N et bien ça tombe à l'eau, auriez vous une idée ? car je pense que la relation N-n est aussi fausse car si je suis le résonnement, il doit y avoir au moins 2 véhicules en stock or ce n'ai pas vrais dans tout les cas.
    Voici la V2.
    Encore merci pour votre aide et le temps que vous m'accordez !

  4. #4
    Expert éminent sénior
    Bonsoir Jugoz,


    Citation Envoyé par Jugoz Voir le message

    J'ai pour projet de créer un Db d'une concession de voiture (uniquement la vente de véhicule).

    Selon votre diagramme il s’agirait plutôt de location.


    Vous mettez la charrue avant les boeufs. Comme dit Escartefigue :

    Citation Envoyé par escartefigue Voir le message
    vous n'avez mentionné aucune de ces règles de gestion. C'est pourtant le point de départ avant de commencer le MCD.

    En l’absence des règles de gestion, tenter de recomposer celles-ci à partir de votre diagramme serait pour le moins illusoire ! Le résultat serait dénué de tout sens...

    Donnez aussi la définition en français des objets à modéliser (entités-types, associations) et leur rôle. Prenons par exemple le cas de l’association LOUE : un employé est-il locataire d’un véhicule ? Loueur ? Intuitivement on se doute de ce qu’il en est, mais ça va mieux en l’écrivant.

    Par ailleurs, à propos de l’entité-type EMPLOYE, un employé étant une personne physique, l’affubler d’un numéro SIREN est une erreur : l’attribut SIREN doit disparaître de l’entité-type EMPLOYE (c’est à l’occasion du passage au MLD que L’AGL fera naître l’attribut SIREN dans la table EMPLOYE, issue de l’entité-type EMPLOYE). En passant, dans un monde normal, un employé n’a qu’un matricule : le nom de l’attribut correspondant est à mettre au singulier.

    L’association DISPONIBLE est dotée de cardinalités maximales N sur chaque patte, cela demande d’être explicité et justifié par les règles de gestion. En l’état du MCD, un véhicule peut se trouver simultanément dans deux stocks, c’est de la bilocation ! Serait-on dans un monde quantique ? La patte connectant ENTREPOT et DISPONIBLE est porteuse d’une cardinalité N,N ce qui ne veut rien dire (sinon l’infini) et est à remplacer par 1,N. A la limite, si un entrepôt doit contenir par exemple au moins 15 véhicules, tentez 15,N...

    L’association LOUER est aberrante : littéralement elle signifie que le véhicule V1 de numéro de série S1 peut louer le VEHICULE_LOUE V2 de numéro de série S2, ainsi que le VEHICULE_LOUE V3 de numéro de série S3, etc. : en l’absence des règles de gestion on est censé ignorer ce que vous cherchez à modéliser.

    Selon l’association TYPE, un véhicule peut être de plus d’une marque, bizarre autant qu’étrange.

    Selon l’association DONNE_LIEU, une facture peut référencer plusieurs contrats : je dirais même plus, bizarre autant qu’étrange.

    L’entité-type LOCATION viole copieusement la règle de base de la construction des MCD selon laquelle un concept ne peut être utilisé qu’à un seul endroit (One fact one place). Je veux dire par là que les attributs Numéro_de_série, Numéro_Permis, Numéro_Contrat étant déjà affectés respectivement aux entités-types connectées VEHICULE, CLIENT, CONTRAT, il n’est pas permis de les reprendre dans l’entité-type LOCATION ! La présence dans cette entité-type des attributs SIREN et Matricule (manifestement récupérés des entités-types AGENCE et EMPLOYE) fait songer à un big mac, un grand fourre-tout, au mieux à une relation universelle à normaliser.

    =>

    Si vous voulez qu’on vous aide, fournissez les règles de gestion, elles permettront de construire un MCD pour le moins bien différent du vôtre, mais pertinent...


    Autre point technique :

    Comme l’a dit Escartefigue les identifiants ne doivent pas être des propriétés fonctionnelles (naturelles), c’est-à-dire sémantiques, porteuses de sens. Par exemple, vous identifiez un véhicule V1 par son numéro de série S1 (voir l’entité-type VEHICULE) : supposez que ce numéro V1 soit signalé un beau jour comme erroné : il faudra le remplacer par V2, avec les conséquences pénibles en cascade, justement dénoncées par Escartefigue. Un attribut utilisé pour identifier doit être dépourvu de signification, être du type disons ENTIER (INTEGER, SMALLINT, etc.), voire DATE, INTERVAL pour les données historisées. Le numéro de série doit n'être qu’un identifiant alternatif de l’entité-type VEHICULE (c’est-à-dire un attribut garantissant aussi l’unicité des occurrences de l’entité-type).
    Toutes choses égales, l’entité-type CLIENT doit être identifiée par un attribut non significatif, de type disons INTEGER et de nom du genre ClientId, tandis que Numero_de_Permis donne lieu à identifiant alternatif. Même principe pour les entités-types CONTRAT, VEHICULE. Espérons que votre AGL sache ce qu’est un identifiant alternatif...


    Citation Envoyé par Jugoz Voir le message
    et pour finir différents types de cardinalité dont la N,N.


    Dans le jargon merisien ce qu’on résume par N,N c’est ça :

    [A]----x,N---(R)----x,N----[B]


    Où A et B sont des entités-types, R est une association, et où x prend la valeur 0 ou 1 (voire 2, 3, 4, etc. dans des cas exotiques...)

    Pour comprendre ce que sont les cardinalités et leur rôle crucial dans un MCD, étudiez l’ouvrage de référence Ingénierie des systèmes d'information : Merise deuxième génération (4e édition, 2001), aux pages 104 et suivantes).

    Votre sujet est la location de véhicules. Vous a-t-il été imposé ? Ou bien est-ce vous qui l’avez choisi ? Dans ce 2e cas, comparez avec un exemple proche, aux pages 421 et suivantes de cet ouvrage de référence. Courage !

     
    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

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

    Citation Envoyé par Jugoz Voir le message
    En ce qui concerne le cahier des charges c'est le suivant : Au minimum 10 tables avec 45 Attributs et avec différents types de variable et pour finir différents types de cardinalité dont la N,N.
    Et bien ce cahier des charges est plutôt curieux et surtout sans aucun intérêt !
    Les points cruciaux pour bien réussir un MCD sont d'une part la collecte des règles de gestion et d'autre part la traduction de celles-ci sous forme de schéma.
    Vous donner pour seules consignes un nombre de tables (qui encore une fois n'existent pas dans un MCD) et d'attributs, c'est vraiment n'importe quoi .

    Au sujet d'une association de cardinalité maxi n de chaque côté, on peut prendre pour exemple le cas suivant

    Règles de gestion :
    R010a : un produit peut être livré par plusieurs fournisseur
    R010b : un fournisseur peut livrer plusieurs produits

    Dans ces règles de gestion, "peut" signifie que l'association est facultative, la cardinalité minimale est donc 0. Ca signifie que je peux tout à fait connaître un fournisseur, même si celui-ci, à un instant "t", ne me livrer aucun produit (fournisseur avec lequel je ne travaille pas encore, ou je ne travaille plus) et que je peux connaître un produit, même si à un instant "t", il n'est livré par aucun fournisseur (nouveau produit, produit que je fabrique moi-même...).
    Dans ces mêmes règles, plusieurs signifie que l'association peut concerner plusieurs occurrences de l'entité-type, la cardinalité maximale est donc n

    On a donc un schéma n-n comme souhaité :
    [FOURNISSEUR] 0,n --- (livrer) ---0,n [PRODUIT]

    Ce MCD produira les tables suivantes lors de la génération du MLD (Pk soulignées, FK suffixées par #) :
    FO_FOURNISSEUR(FO_id, FO_numéro, FO_SIREN, FO_CODE_NAF, ...)
    PR_PRODUIT(PR_id, PR_reference, PR_designation, PR_unite_mesure, ...)
    LI_LIVRER(PR_id#, FO_id#, ...) <-- dans le cas d'une association n-aire, l'association devient une table dont la PK est composée des PK des tables issues des entité-types concourant à l'association
    la PK de la table LI_LIVRER est donc composée de la PK de FO_FOURNISSEUR et de PR_PRODUIT

  6. #6
    Futur Membre du Club
    Citation Envoyé par escartefigue Voir le message
    Bonsoir,



    Et bien ce cahier des charges est plutôt curieux et surtout sans aucun intérêt !
    Les points cruciaux pour bien réussir un MCD sont d'une part la collecte des règles de gestion et d'autre part la traduction de celles-ci sous forme de schéma.
    Vous donner pour seules consignes un nombre de tables (qui encore une fois n'existent pas dans un MCD) et d'attributs, c'est vraiment n'importe quoi .

    Au sujet d'une association de cardinalité maxi n de chaque côté, on peut prendre pour exemple le cas suivant

    Règles de gestion :
    R010a : un produit peut être livré par plusieurs fournisseur
    R010b : un fournisseur peut livrer plusieurs produits

    Dans ces règles de gestion, "peut" signifie que l'association est facultative, la cardinalité minimale est donc 0. Ca signifie que je peux tout à fait connaître un fournisseur, même si celui-ci, à un instant "t", ne me livrer aucun produit (fournisseur avec lequel je ne travaille pas encore, ou je ne travaille plus) et que je peux connaître un produit, même si à un instant "t", il n'est livré par aucun fournisseur (nouveau produit, produit que je fabrique moi-même...).
    Dans ces mêmes règles, plusieurs signifie que l'association peut concerner plusieurs occurrences de l'entité-type, la cardinalité maximale est donc n

    On a donc un schéma n-n comme souhaité :
    [FOURNISSEUR] 0,n --- (livrer) ---0,n [PRODUIT]

    Ce MCD produira les tables suivantes lors de la génération du MLD (Pk soulignées, FK suffixées par #) :
    FO_FOURNISSEUR(FO_id, FO_numéro, FO_SIREN, FO_CODE_NAF, ...)
    PR_PRODUIT(PR_id, PR_reference, PR_designation, PR_unite_mesure, ...)
    LI_LIVRER(PR_id#, FO_id#, ...) <-- dans le cas d'une association n-aire, l'association devient une table dont la PK est composée des PK des tables issues des entité-types concourant à l'association
    la PK de la table LI_LIVRER est donc composée de la PK de FO_FOURNISSEUR et de PR_PRODUIT
    Bonjour donc j'ai essayer de détailler un peu plus mon cas :
    Le but étant ici de réaliser un site web d'un loueur de voiture qui à plusieurs agences de location de voiture que je vais détailler par la suite :
    Le client devra se connecter au site web avec des identifiants et au préalable s’être inscrit en renseignant ses informations (Nom,prénom,adresse,contact etc..)
    Il sélectionnera ensuite l'agence qu'il souhaite et aura ensuite un retour des véhicules disponibles a l'agence avec des spécifications (Marque;Modèle;Moteur)
    Une fois le véhicule validé il aura un contrat a signer avec la génération d'une facture récapitulative.
    Voici, une nouvelle version amélioré dans laquelle je pense avoir respecter mes conditions :

  7. #7
    Expert éminent sénior
    Ce que vous mentionnez est intéressant mais ne suffit pas à la schématisation du MCD, vous n'avez toujours pas formalisé les règles de gestion
    De plus votre schéma est petit et très peu contrasté, donc difficile à lire

    Quelques remarques :

    toutes les entité-type
    Comme mentionné précédemment, un identifiant primaire pour des raisons de stabilité, ne doit jamais avoir de sens fonctionnel.
    Et pour des raisons d'encombrement et de performance, on préférera un type integer à un type char ou encore pire varchar.
    Donc, remplacez le type de tous vos idenfifiants primaires


    CHRONOLOGIE
    Je ne sais pas ce que vous avez voulu représenter, mais la notion d'héritage est hors sujet ici.
    L'héritage c'est la généralisation (utilisation d'un sur-type) et la spécialisation(avec des sous-types). Exemple d'héritage, une personne (sur-type) peut être une personne physique (1er sous-type) ou morale (2ème sous-type), le surtype PERSONNE contient ce qui est commun aux personnes physiques et morale (l'identifiant primaire, la date de création...) les sous-types contiennent ce qui est spécifique (n° de sécu, nom, prénom... pour une personne physique ; SIRET, code NAF, raison sociale... pour une personne morale)


    CONTRAT
    Comment allez vous facturer avec un contrat aussi pauvre en attributs et liens avec le reste du modèle : on ne sait pas quel client ni quel véhicule est concerné par le contrat, ni combien de km sont prévus ou effectués...


    FACTURE
    Attention, la facturation est réglementée.
    Une facture doit non seulement comporter un n° unique, mais aussi un montant TTC, un montant HT, un ou plusieurs taux de TVA, le montant TVA pour chaque taux etc.
    À compléter après vous être renseignés sur ce sujet.


    CONTRAT et AGENCE
    Qu'une agence puisse créer plusieurs contrats, sans doute, mais qu'un même contrat soit créé par plusieurs agence, c'est douteux
    à confirmer ou infirmer au travers des règles de gestion


    AGENCE
    Le SIREN est normé, sa taille est de 9 caractères.
    Une agence partage son SIREN avec les autres agences de la même entreprise. Ce qui est spécifique à telle ou telle agence, c'est le NIC (5 caractères) qui, ajouté au SIREN, forme le SIRET.
    Donc il faut, au niveau de l'agence, stocker non pas le SIREN, mais le SIRET (voir le NIC seul, si le SIREN est unique pour toutes les agences)
    Et comme il s'agit d'une référence certes numérique, mais qui ne fait pas l'objet de calculs, il faut utiliser une zone CHAR(13).


    INFORMATION
    Là encore l'héritage est hors sujet (voir plus haut).
    Les adresses ne se stockent pas dans un seul attribut, mais dans plusieurs selon une norme.
    Pour la France, c'est la norme de la poste qui s'applique, elle est dispo gratuitement sur la toile.


    AGENCE et CLIENT
    Le verbe "demander" est inadapté un client ne demande pas d'agence pas plus qu'une agence ne demande un client.
    Il faut choisir un verbe qui corresponde à la relation qui existe entre ces deux acteurs et que vous aurez décrite préalablement dans les règles de gestion.


    VEHICULE et AGENCE
    Tel que modélisé, un véhicule est loué par au moins une agence et éventuellement plusieurs.
    N'y a -t-il pas des véhicules qui ne sont pas loués ?
    Un même véhicule peut il vraiment être loué par plusieurs agences ?


    VEHICULE, MARQUE et MODELE
    Le cheminement n'est pas le bon, le véhicule est d'un certain modèle, modèle lié à une marque.


    ENTREPOT
    Si un véhicule peut changer d'entrepôt selon les périodes, alors l'association doit être à date
    Si l'attribut nombre de véhicules est la capacité, alors OK, si c'est le nombre de véhicules dans l'entrepôt à un instant "t", alors il faut supprimer cet attribut, car il s'agit d'une valeur à calculer.


    On verra plus tard pour la suite, mais encore une fois, les règles de gestion d'abord

  8. #8
    Futur Membre du Club
    bonjour messieurs,
    tout d'abord je vous remercie de vos réponses.

    je reviens vers vous car je voudrais un peu d'aide je manque d'idées et voudrais savoir si quelqu'un aurait des idées pour une relation n:m.

    J'ai un doute sur la relation n:m qui est actuellement présente de mon mcd.

    Voir le mcd ci-joint.

    Merci

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

    Citation Envoyé par
    J'ai un doute sur la relation n:m qui est actuellement présente de mon mcd.

    Expliquez pourquoi vous doutez.

    Quoi qu’il en soit, en priorité, quelques observations :

    (1) Si votre entreprise fait l’acquisition d’un véhicule Ve, qui n’a donc jamais fait l’objet d’une location, comment savoir quelle agence possède Ve ?

    (2) Selon votre représentation, un véhicule Ve ne concerne qu’un seul contrat, c’est à la vie à la mort ! Etonnant !

    (3) Un contrat peut engendrer plusieurs factures. Où figure la date de facture ? Si on a besoin de savoir que telle facture concerne tel(s) véhicules(s), comment répondre à ce besoin ?

    (4) Un véhicule Ve est d’une certaine marque Ma, mais comment savoir quel est le modèle Mo dont relève Ve ? Comment savoir quelle est sa motorisation ?

     
    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
    Futur Membre du Club
    Citation Envoyé par fsmrel Voir le message
    Bonjour Jugoz,


    Expliquez pourquoi vous doutez.

    Quoi qu’il en soit, en priorité, quelques observations :

    (1) Si votre entreprise fait l’acquisition d’un véhicule Ve, qui n’a donc jamais fait l’objet d’une location, comment savoir quelle agence possède Ve ?

    (2) Selon votre représentation, un véhicule Ve ne concerne qu’un seul contrat, c’est à la vie à la mort ! Etonnant !

    (3) Un contrat peut engendrer plusieurs factures. Où figure la date de facture ? Si on a besoin de savoir que telle facture concerne tel(s) véhicules(s), comment répondre à ce besoin ?

    (4) Un véhicule Ve est d’une certaine marque Ma, mais comment savoir quel est le modèle Mo dont relève Ve ? Comment savoir quelle est sa motorisation ?

     
    J'ai un doute car un même véhicule ne peut pas être réservé par plusieurs client au même moment.

    (1)Excusez moi du manque d'information mais il n'y a qu'une seule agence avec plusieurs employés.
    (2)Oupss ^^ C'est donc une relation n:m.
    (3)Encore Oups.
    (4)C'est une question que je me suis aussi poser comment faire la liaison entre mes différentes tables, je ne sais pas bien comment je vais pouvoir définir cela dans mon script. Le problème étant que pour mon projet il était demandé de faire 10 tables, c'est pourquoi j'ai un peu décortiquer le véhicule mais bon au finale ça ne semble pas une bonne idée :/.

    Merci pour votre aide !

  11. #11
    Expert éminent sénior
    (Re)bonjour Jugoz,


    Citation Envoyé par Jugoz
    Merci pour votre aide !
    Alors likez les messages qui vous ont aidé.

    Citation Envoyé par Jugoz
    Le problème étant que pour mon projet il était demandé de faire 10 tables

    (1) Les c... ça ose tout ! Commencez par ne pas tenir compte de leur ânerie, puis on verra comment dégénérer le modèle, faire tenir les tables dans ce lit de Procuste à 10 places (par exemple virer la table AGENCE puisqu’il n’y a qu’une agence, faire absorber MODELE par MARQUE (viol de la deuxième forme normale), et autres astuces vaseuses).

    (2) En passant, comme vous l’a rappelé Escartefigue (post #2), dans un MCD on ne traite pas de tables mais d’entités-types (aka types d’entités, classes d’entités).

    (3) La patte d’association connectant VEHICULE et CONCERNER est porteuse d’une cardinalité 1,N : si un véhicule peut ne pas encore avoir été loué (par exemple parce qu’il vient tout juste d’être acquis par l’agence), alors la cardinalité doit être 0,N.

    (4) Ça n’est pas fondamental, mais vous pourriez renommer l’association CONCERNER en LOCATION (à moins de perdre des points en n’utilisant pas des verbes pour les associations, puisque les c... qui notent ça ose tout...) Dans ce qui suit, j’effectue ce changement de nom.

    Abordons le coeur du modèle, c’est-à-dire la partie sensible...

    (5) Si la période de location n’est pas nécessairement la même pour tous les véhicules concernés par un contrat, alors les attributs DATE_DEBUT_LOC et DATE_FIN_LOC doivent migrer dans LOCATION.

    (6) Il devrait probablement en aller de même concernant les attributs ETAT_VEHICULE_D, ETAT_VEHICULE_R.

    (7) Le tarif de location (attribut TARIF_LOC) est-il spécifique à un contrat ? Comment faites-vous si ce contrat concerne plus d’un véhicule, par exemple une Twingo et une Porsche Taycan Turbo S ?

    (8) Même observation concernant l’attribut CAUTION.

    (9) Que recouvre le montant total (attribut MONTANT_TOTAL) ? Quelle relation avec le montant porté par la facture ?

    (10) Normalement la facture doit comporter des lignes de facture, chaque ligne faisant référence à un véhicule : on devra en reparler quant aux conséquences sur la modélisation.

    (11) Par le chemin VEHICULE -> LOCATION -> CONTRAT -> CLIENT, on sait que le véhicule Ve est loué par le client Cl, au cours de la période Pe. D’un point de vue fonctionnel, l’association RESERVER est-elle strictement nécessaire ? Si oui, le MCD va en prendre un bon coup !

    (12) Remplacer le type FLOAT (virgule flottante) par DECIMAL (virgule fixe).

    Bon courage, persévérez !

     
    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
    Futur Membre du Club
    Citation Envoyé par fsmrel Voir le message
    (Re)bonjour Jugoz,


    Alors likez les messages qui vous ont aidé.


    (1) Les c... ça ose tout ! Commencez par ne pas tenir compte de leur ânerie, puis on verra comment dégénérer le modèle, faire tenir les tables dans ce lit de Procuste à 10 places (par exemple virer la table AGENCE puisqu’il n’y a qu’une agence, faire absorber MODELE par MARQUE (viol de la deuxième forme normale), et autres astuces vaseuses).

    (2) En passant, comme vous l’a rappelé Escartefigue (post #2), dans un MCD on ne traite pas de tables mais d’entités-types (aka types d’entités, classes d’entités).

    (3) La patte d’association connectant VEHICULE et CONCERNER est porteuse d’une cardinalité 1,N : si un véhicule peut ne pas encore avoir été loué (par exemple parce qu’il vient tout juste d’être acquis par l’agence), alors la cardinalité doit être 0,N.

    (4) Ça n’est pas fondamental, mais vous pourriez renommer l’association CONCERNER en LOCATION (à moins de perdre des points en n’utilisant pas des verbes pour les associations, puisque les c... qui notent ça ose tout...) Dans ce qui suit, j’effectue ce changement de nom.

    Abordons le coeur du modèle, c’est-à-dire la partie sensible...

    (5) Si la période de location n’est pas nécessairement la même pour tous les véhicules concernés par un contrat, alors les attributs DATE_DEBUT_LOC et DATE_FIN_LOC doivent migrer dans LOCATION.

    (6) Il devrait probablement en aller de même concernant les attributs ETAT_VEHICULE_D, ETAT_VEHICULE_R.

    (7) Le tarif de location (attribut TARIF_LOC) est-il spécifique à un contrat ? Comment faites-vous si ce contrat concerne plus d’un véhicule, par exemple une Twingo et une Porsche Taycan Turbo S ?

    (8) Même observation concernant l’attribut CAUTION.

    (9) Que recouvre le montant total (attribut MONTANT_TOTAL) ? Quelle relation avec le montant porté par la facture ?

    (10) Normalement la facture doit comporter des lignes de facture, chaque ligne faisant référence à un véhicule : on devra en reparler quant aux conséquences sur la modélisation.

    (11) Par le chemin VEHICULE -> LOCATION -> CONTRAT -> CLIENT, on sait que le véhicule Ve est loué par le client Cl, au cours de la période Pe. D’un point de vue fonctionnel, l’association RESERVER est-elle strictement nécessaire ? Si oui, le MCD va en prendre un bon coup !

    (12) Remplacer le type FLOAT (virgule flottante) par DECIMAL (virgule fixe).

    Bon courage, persévérez !

     
    (1) Je voulais récupérer ces informations pour mon bas de page de mon site php car nous devons aussi réaliser une interface.
    (2)(3)(4) Très bien, c'est fait
    (5)(6) Merci ^^
    (7)(8) C'est vrais que le prix d'une twingo et d'une porche n'est pas le même et c'est bien dommage ahaha
    (9) C'est vrais que l'un est l'autre son égaux.
    (10) Hum, j'attend de voir la suite
    (11) Non l'association n'est pas obligatoire, je la supprime de suite !!
    (12)Très bien.

    Voici une mise à jour du MCD avec vos remarques.



    Petite question : concernant l'attribut "PENALITE" ne doit-il pas migrer dans l’association "LOCATION" ?

    Encore merci pour votre aide !

  13. #13
    Expert éminent sénior
    Ça évolue dans le bon sens !


    Citation Envoyé par Jugoz Voir le message
    (1) Je voulais récupérer ces informations pour mon bas de page de mon site php car nous devons aussi réaliser une interface.

    (1) Dans ces conditions, si cela vous facilite la vie, vous pouvez en faire une entité-type, mais sans l’associer à quelque autre entité-type que soit.



    Citation Envoyé par Jugoz Voir le message
    C'est vrais que le prix d'une twingo et d'une porche n'est pas le même et c'est bien dommage ahahah
    (2) Je dirais même plus « ahahah », car ça fera cher pour la Twingo



    (3) La patte d’association connectant CONTRAT et LOCATION est maintenant porteuse d’une cardinalité 0,N : il y aurait donc des contrats sans location et pourtant avec des factures ? Sémantiquement parlant, pourquoi pas, mais j’ai des doutes sur la pertinence ici de la cardinalité 0,N.



    Citation Envoyé par Jugoz Voir le message
    (10) Hum, j'attends de voir la suite.

    (4) La suite dépend de votre position sur le point précédent : 0,N versus 1,N.



    (5) Je vois que l’entité-type VEHICULE a phagocyté l’entité-type MARQUE. C’est pour le moins minimaliste, mais du fait de la contrainte des 10 entités-types qui vous est imposée, d’accord. Sinon, concernant VEHICULE, MODELE et MARQUE on est bien d’accord sur la représentation qui suit, où il est implicite que MARQUE a tous ses attributs :


    [VEHICULE]--1,1--(R)--0,N--[MODELE]--1,1--(R’)--1,N--[MARQUE]



    (6) Question : pour un véhicule, a-t-on besoin de connaître les informations relative à sa motorisation (cf. entité-type MOTEUR) ? Voir par exemple à ce sujet F.4. L'identification relative au service de l'intégrité des données.



    (7) Concernant le type INTEGER(n) (INTEGER(10) dans votre modèle) : arrivé au stade SQL, il est d’usage de coder seulement INTEGER, ce qui représente une valeur maximale quand même confortable (2,147,483,647)...

    (8) En revanche, concernant le type DECIMAL, il faut préciser le nombre total de chiffres sans oublier ceux qui figurent éventuellement à la droite de la virgule. Exemple : 8 chiffres dont 2 après la virgule : DECIMAL(8,2).

    (9) Quel est votre SGBD ?

     
    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
    Futur Membre du Club
    Citation Envoyé par fsmrel Voir le message
    Ça évolue dans le bon sens !



    (1) Dans ces conditions, si cela vous facilite la vie, vous pouvez en faire une entité-type, mais sans l’associer à quelque autre entité-type que soit.




    (2) Je dirais même plus « ahahah », car ça fera cher pour la Twingo



    (3) La patte d’association connectant CONTRAT et LOCATION est maintenant porteuse d’une cardinalité 0,N : il y aurait donc des contrats sans location et pourtant avec des factures ? Sémantiquement parlant, pourquoi pas, mais j’ai des doutes sur la pertinence ici de la cardinalité 0,N.




    (4) La suite dépend de votre position sur le point précédent : 0,N versus 1,N.



    (5) Je vois que l’entité-type VEHICULE a phagocyté l’entité-type MARQUE. C’est pour le moins minimaliste, mais du fait de la contrainte des 10 entités-types qui vous est imposée, d’accord. Sinon, concernant VEHICULE, MODELE et MARQUE on est bien d’accord sur la représentation qui suit, où il est implicite que MARQUE a tous ses attributs :


    [VEHICULE]--1,1--(R)--0,N--[MODELE]--1,1--(R’)--1,N--[MARQUE]



    (6) Question : pour un véhicule, a-t-on besoin de connaître les informations relative à sa motorisation (cf. entité-type MOTEUR) ? Voir par exemple à ce sujet F.4. L'identification relative au service de l'intégrité des données.



    (7) Concernant le type INTEGER(n) (INTEGER(10) dans votre modèle) : arrivé au stade SQL, il est d’usage de coder seulement INTEGER, ce qui représente une valeur maximale quand même confortable (2,147,483,647)...

    (8) En revanche, concernant le type DECIMAL, il faut préciser le nombre total de chiffres sans oublier ceux qui figurent éventuellement à la droite de la virgule. Exemple : 8 chiffres dont 2 après la virgule : DECIMAL(8,2).

    (9) Quel est votre SGBD ?

     
    (1) Dacodac
    (3)(8) C'est modifé !
    (4) 1,N WIN !
    (5)J'ai supprimé l’entité marque j'ai intégré moteur dans véhicule
    (6) Non, pas forcement mais j'ai voulu ajouter des entités pour combler le vide .
    (7) tel un bon padawan j'ai suivi les consignes du grand jedi x)
    (9) la consigne étant d'utiliser le SGBDR Postgresql

  15. #15
    Expert éminent sénior
    Citation Envoyé par Jugoz
    C'est modifié !


    Sauf que je ne vois aucun changement ! le MCD est manifestement une copie du précédent

    Le SGBD étant PostgreSQL, vous pouvez remplacer les attributs DATE_DEBUT_LOC et DATE_FIN_LOC par le seul attribut DATE_PERIODE_LOC de type DATERANGE, et ainsi, au cas où deux clients n’auraient pas la possibilité de louer un véhicule donné le même jour, il devient facile d’empêcher les erreurs du type « recouvrement de période » : par exemple (on peut rêver...), « Il ne sera pas possible que MM. Jugoz et fsmrel louent la même Porsche le 27 janvier 2020 ». Mais s’il est possible que le premier loue la Porsche le matin et le second l’après-midi, on peut affiner les contrôles en remplaçant DATERANGE par TSRANGE.

     
    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

  16. #16
    Futur Membre du Club
    Citation Envoyé par fsmrel Voir le message
    Sauf que je ne vois aucun changement ! le MCD est manifestement une copie du précédent

    Le SGBD étant PostgreSQL, vous pouvez remplacer les attributs DATE_DEBUT_LOC et DATE_FIN_LOC par le seul attribut DATE_PERIODE_LOC de type DATERANGE, et ainsi, au cas où deux clients n’auraient pas la possibilité de louer un véhicule donné le même jour, il devient facile d’empêcher les erreurs du type « recouvrement de période » : par exemple (on peut rêver...), « Il ne sera pas possible que MM. Jugoz et fsmrel louent la même Porsche le 27 janvier 2020 ». Mais s’il est possible que le premier loue la Porsche le matin et le second l’après-midi, on peut affiner les contrôles en remplaçant DATERANGE par TSRANGE.

     
    Oups ^^ désolé c'est une erreur de ma part je n'ai pas upload la bonne image :/
    Voici la bonne !
    J'opte pour "DATERANGE"


  17. #17
    Expert éminent sénior
    Citation Envoyé par Jugoz Voir le message
    (7) tel un bon padawan j'ai suivi les consignes du grand jedi x)

    (1) A ceci près que INTEGER(10) est resté INTEGER(10) au lieu de devenir INTEGER tout court...


    Citation Envoyé par Jugoz Voir le message
    (5)J'ai supprimé l’entité marque j'ai intégré moteur dans véhicule

    (2) Sauf que l’attribut MARQUE est toujours présent dans VEHICULE, tandis que MOTEUR en est absent…

    En tout cas, selon votre dernier MCD, le modèle, par exemple "Clio 2 V6 Rs" n’appartient qu’à une seule voiture, disons celle de Fernand Naudin, autrement dit vous avez encore inversé les cardinalités. Quoi qu’il en soit, si vous conservez la motorisation, comme pour le moment vous respectez encore la contrainte débile des 10 entités-types, si MOTEUR sous-entend TYPE_DE_MOTEUR (et non pas l’exemplaire équipant votre propre voiture), il vaut mieux finalement en rester à :


    [VEHICULE]--1,1--(R)--0,N--[MOTEUR]--1,1--(R’)--1,N--[MODELE]--1,1--(R’’)--1,N--[MARQUE]



    (3) Selon votre dernier MCD, un contrat donne lieu au plus à une facture : ainsi, dès lors qu’il y a une nouvelle facture pour un client, il faudra établir un nouveau contrat, est-ce bien raisonnable ? En tout cas, s’il en est ainsi, alors FACTURE contient les élément « facultatifs » de CONTRAT (numéro de facture, montant, date de facture) sans qu’il soit besoin de mettre en oeuvre un identifiant spécifique FACTURE_ID : FACTURE hérite de l’identifiant CONTRAT_ID de CONTRAT, au moyen de l’identification relative. Est-ce dans les possibilités de votre outil de modélisation ? (au fait, quel est-il ?) Si tel n’est pas le cas voici au demeurant ce que cela donne avec l’excellent et gratuit Looping :



    (4) Code SQL correspondant :

    
    CREATE TABLE VEHICULE
    (
            VEHICULE_ID            INTEGER        NOT NULL
        , CONSTRAINT VEHICULE_PK PRIMARY KEY(VEHICULE_ID)
    );
    
    CREATE TABLE CLIENT
    (
            CLIENT_ID              INTEGER        NOT NULL 
        , CONSTRAINT CLIENT_PK PRIMARY KEY(CLIENT_ID)
    );
    
    CREATE TABLE CONTRAT
    (
            CONTRAT_ID             INTEGER        NOT NULL 
          , CLIENT_ID              INTEGER        NOT NULL 
        , CONSTRAINT CONTRAT_PK PRIMARY KEY(CONTRAT_ID)
        , CONSTRAINT CONTRAT_CLIENT_FK FOREIGN KEY(CLIENT_ID) 
              REFERENCES CLIENT(CLIENT_ID)
    );
    
    CREATE TABLE LOCATION
    (
            CONTRAT_ID             INTEGER        NOT NULL 
          , VEHICULE_ID            INTEGER        NOT NULL
        , CONSTRAINT LOCATION_PK PRIMARY KEY(CONTRAT_ID, VEHICULE_ID)
        , CONSTRAINT LOCATION_CONTRAT_FK FOREIGN KEY(CONTRAT_ID) 
              REFERENCES CONTRAT(CONTRAT_ID)
        , CONSTRAINT LOCATION_VEHICULE_FK FOREIGN KEY(VEHICULE_ID) 
              REFERENCES VEHICULE(VEHICULE_ID)
    );
    
    CREATE TABLE FACTURE
    (
            CONTRAT_ID             INTEGER        NOT NULL 
        , CONSTRAINT FACTURE_PK PRIMARY KEY(CONTRAT_ID)
        , CONSTRAINT FACTURE_CONTRAT_FK FOREIGN KEY(CONTRAT_ID) 
              REFERENCES CONTRAT(CONTRAT_ID)
    );
    
    CREATE TABLE LIGNE_FACTURE
    (
            CONTRAT_ID             INTEGER        NOT NULL 
          , LIGNE_FACTURE_ID       INTEGER        NOT NULL
          , VEHICULE_ID            INTEGER        NOT NULL
        , CONSTRAINT LIGNE_FACTURE_PK PRIMARY KEY(CONTRAT_ID, LIGNE_FACTURE_ID)
        , CONSTRAINT LIGNE_FACTURE_FACTURE_FK FOREIGN KEY(CONTRAT_ID) 
              REFERENCES FACTURE(CONTRAT_ID)
        , CONSTRAINT LIGNE_FACTURE_VEHICULE_FK FOREIGN KEY(VEHICULE_ID) 
              REFERENCES VEHICULE(VEHICULE_ID)
    );  
    (5) Il y a toutefois un hic : une ligne de facture peut en effet faire référence à un véhicule qui n’a rien à voir avec les locations associées aux contrats du client !

    Pour empêcher cela, soit on met en oeuvre un trigger SQL, soit on sophistique un peu le MCD, tandis qu’il n’y aura qu’une ligne à modifier dans le code SQL. On verra tout ça plus tard.


    (6) En attendant, restez-vous sur votre modélisation : au plus une facture par contrat, ou bien y va-t-on pour plusieurs ?


     
    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

  18. #18
    Futur Membre du Club
    Citation Envoyé par fsmrel Voir le message
    (1) A ceci près que INTEGER(10) est resté INTEGER(10) au lieu de devenir INTEGER tout court...



    (2) Sauf que l’attribut MARQUE est toujours présent dans VEHICULE, tandis que MOTEUR en est absent…

    En tout cas, selon votre dernier MCD, le modèle, par exemple "Clio 2 V6 Rs" n’appartient qu’à une seule voiture, disons celle de Fernand Naudin, autrement dit vous avez encore inversé les cardinalités. Quoi qu’il en soit, si vous conservez la motorisation, comme pour le moment vous respectez encore la contrainte débile des 10 entités-types, si MOTEUR sous-entend TYPE_DE_MOTEUR (et non pas l’exemplaire équipant votre propre voiture), il vaut mieux finalement en rester à :


    [VEHICULE]--1,1--(R)--0,N--[MOTEUR]--1,1--(R’)--1,N--[MODELE]--1,1--(R’’)--1,N--[MARQUE]



    (3) Selon votre dernier MCD, un contrat donne lieu au plus à une facture : ainsi, dès lors qu’il y a une nouvelle facture pour un client, il faudra établir un nouveau contrat, est-ce bien raisonnable ? En tout cas, s’il en est ainsi, alors FACTURE contient les élément « facultatifs » de CONTRAT (numéro de facture, montant, date de facture) sans qu’il soit besoin de mettre en oeuvre un identifiant spécifique FACTURE_ID : FACTURE hérite de l’identifiant CONTRAT_ID de CONTRAT, au moyen de l’identification relative. Est-ce dans les possibilités de votre outil de modélisation ? (au fait, quel est-il ?) Si tel n’est pas le cas voici au demeurant ce que cela donne avec l’excellent et gratuit Looping :



    (4) Code SQL correspondant :

    
    CREATE TABLE VEHICULE
    (
            VEHICULE_ID            INTEGER        NOT NULL
        , CONSTRAINT VEHICULE_PK PRIMARY KEY(VEHICULE_ID)
    );
    
    CREATE TABLE CLIENT
    (
            CLIENT_ID              INTEGER        NOT NULL 
        , CONSTRAINT CLIENT_PK PRIMARY KEY(CLIENT_ID)
    );
    
    CREATE TABLE CONTRAT
    (
            CONTRAT_ID             INTEGER        NOT NULL 
          , CLIENT_ID              INTEGER        NOT NULL 
        , CONSTRAINT CONTRAT_PK PRIMARY KEY(CONTRAT_ID)
        , CONSTRAINT CONTRAT_CLIENT_FK FOREIGN KEY(CLIENT_ID) 
              REFERENCES CLIENT(CLIENT_ID)
    );
    
    CREATE TABLE LOCATION
    (
            CONTRAT_ID             INTEGER        NOT NULL 
          , VEHICULE_ID            INTEGER        NOT NULL
        , CONSTRAINT LOCATION_PK PRIMARY KEY(CONTRAT_ID, VEHICULE_ID)
        , CONSTRAINT LOCATION_CONTRAT_FK FOREIGN KEY(CONTRAT_ID) 
              REFERENCES CONTRAT(CONTRAT_ID)
        , CONSTRAINT LOCATION_VEHICULE_FK FOREIGN KEY(VEHICULE_ID) 
              REFERENCES VEHICULE(VEHICULE_ID)
    );
    
    CREATE TABLE FACTURE
    (
            CONTRAT_ID             INTEGER        NOT NULL 
        , CONSTRAINT FACTURE_PK PRIMARY KEY(CONTRAT_ID)
        , CONSTRAINT FACTURE_CONTRAT_FK FOREIGN KEY(CONTRAT_ID) 
              REFERENCES CONTRAT(CONTRAT_ID)
    );
    
    CREATE TABLE LIGNE_FACTURE
    (
            CONTRAT_ID             INTEGER        NOT NULL 
          , LIGNE_FACTURE_ID       INTEGER        NOT NULL
          , VEHICULE_ID            INTEGER        NOT NULL
        , CONSTRAINT LIGNE_FACTURE_PK PRIMARY KEY(CONTRAT_ID, LIGNE_FACTURE_ID)
        , CONSTRAINT LIGNE_FACTURE_FACTURE_FK FOREIGN KEY(CONTRAT_ID) 
              REFERENCES FACTURE(CONTRAT_ID)
        , CONSTRAINT LIGNE_FACTURE_VEHICULE_FK FOREIGN KEY(VEHICULE_ID) 
              REFERENCES VEHICULE(VEHICULE_ID)
    );  
    (5) Il y a toutefois un hic : une ligne de facture peut en effet faire référence à un véhicule qui n’a rien à voir avec les locations associées aux contrats du client !

    Pour empêcher cela, soit on met en oeuvre un trigger SQL, soit on sophistique un peu le MCD, tandis qu’il n’y aura qu’une ligne à modifier dans le code SQL. On verra tout ça plus tard.


    (6) En attendant, restez-vous sur votre modélisation : au plus une facture par contrat, ou bien y va-t-on pour plusieurs ?


     
    (1) C'est modifié !

    (2) Je me suis mal exprimé, je voulais dire que j'ai supprimé l’entité moteur et que j'ai intégré celle-ci dans l’entité véhicule.
    je ne comprends pas bien comment cela est possible :
    [VEHICULE]--1,1--(R)--0,N--[MOTEUR]--1,1--(R’)--1,N--[MODELE]--1,1--(R’’)--1,N--[MARQUE]
    car un véhicule ne peut être équipé que d'un moteur non ?

    (3) Cela me paraissait plus logique de faire ainsi "un contrat donne lieu à une facture".
    Oui j'utilise un outil en ligne gratuit qui s'appelle "lucidchart.com" et c'est tout à fait possible car c'est une zone de texte éditable.

    Voici l'update du MCD :


    (5)Allons au plus simple xP

    (6) Je préfère faire un contrat / une facture

  19. #19
    Expert éminent sénior
    Bonjour Jugoz

    J'ai suivi cette conversation d'un peu loin, d'une part parce que François (FSMrel) a pris en charge et vous ne pouviez pas mieux tomber et aussi faute de temps.
    Quelques remarques toutefois

    • Vos schémas sont très peu lisibles, en tout cas pour moi, c'est écrit tout petit et très peu contrasté Si vous pouviez améliorer ça, le confort en serait amélioré
    • Le mode citation est utile mais ne conservez que les parties sur lesquelles vous réagissez pour éviter de surcharger inutilement les réponses
    • Pour éviter les confusions, vu que votre logiciel utilise des rectangles aussi bien pour les types d'entités que pour les associations, n'utilisez que des verbes pour nommer les associations.
      Par exemple "louer" plutôt que "location"


    Je vois que vous avez voulu utiliser l'héritage pour les clients et les employés, mais vous ne l'avez pas modélisé comme il faut.
    Le surtype nommé par exemple "personne" doit contenir tous les attributs communs aux clients et aux employés et c'est lui qui possède l'identifiant primaire, la PK.
    Chaque sous-type "client" et "employé" ne doit pas avoir d'identifiant propre, puisqu'il hérite de l'identifiant du surtype.

  20. #20
    Futur Membre du Club
    Citation Envoyé par escartefigue Voir le message
    Bonjour Jugoz

    J'ai suivi cette conversation d'un peu loin, d'une part parce que François (FSMrel) a pris en charge et vous ne pouviez pas mieux tomber et aussi faute de temps.
    Quelques remarques toutefois

    • Vos schémas sont très peu lisibles, en tout cas pour moi, c'est écrit tout petit et très peu contrasté Si vous pouviez améliorer ça, le confort en serait amélioré
    • Le mode citation est utile mais ne conservez que les parties sur lesquelles vous réagissez pour éviter de surcharger inutilement les réponses
    • Pour éviter les confusions, vu que votre logiciel utilise des rectangles aussi bien pour les types d'entités que pour les associations, n'utilisez que des verbes pour nommer les associations.
      Par exemple "louer" plutôt que "location"


    Je vois que vous avez voulu utiliser l'héritage pour les clients et les employés, mais vous ne l'avez pas modélisé comme il faut.
    Le surtype nommé par exemple "personne" doit contenir tous les attributs communs aux clients et aux employés et c'est lui qui possède l'identifiant primaire, la PK.
    Chaque sous-type "client" et "employé" ne doit pas avoir d'identifiant propre, puisqu'il hérite de l'identifiant du surtype.
    Bonjour Escartefigue ,
    Excusez moi pour la qualité des images mais c'est la qualité maximale que j'ai pu en tirer lors de l'exportation.
    C'est vrais que ça fait des gros pavé désolé.
    C'est modifié merci !

    Auriez-vous un exemple de code pour l'héritage ?

###raw>template_hook.ano_emploi###