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
    Candidat au Club
    Homme Profil pro
    Consultant communication & réseaux
    Inscrit en
    septembre 2019
    Messages
    3
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 26
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : Consultant communication & réseaux
    Secteur : High Tech - Matériel informatique

    Informations forums :
    Inscription : septembre 2019
    Messages : 3
    Points : 2
    Points
    2
    Par défaut 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.

    Nom : vehicules.PNG
Affichages : 53
Taille : 83,9 Ko

  2. #2
    Expert éminent sénior

    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    5 253
    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 : 5 253
    Points : 15 526
    Points
    15 526
    Billets dans le blog
    1
    Par défaut
    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
    Candidat au Club
    Homme Profil pro
    Consultant communication & réseaux
    Inscrit en
    septembre 2019
    Messages
    3
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 26
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : Consultant communication & réseaux
    Secteur : High Tech - Matériel informatique

    Informations forums :
    Inscription : septembre 2019
    Messages : 3
    Points : 2
    Points
    2
    Par défaut
    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.Nom : vehicules.PNG
Affichages : 41
Taille : 88,6 Ko
    Encore merci pour votre aide et le temps que vous m'accordez !

  4. #4
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    6 913
    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 913
    Points : 25 887
    Points
    25 887
    Billets dans le blog
    16
    Par défaut
    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

    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    5 253
    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 : 5 253
    Points : 15 526
    Points
    15 526
    Billets dans le blog
    1
    Par défaut
    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
    Candidat au Club
    Homme Profil pro
    Consultant communication & réseaux
    Inscrit en
    septembre 2019
    Messages
    3
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 26
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : Consultant communication & réseaux
    Secteur : High Tech - Matériel informatique

    Informations forums :
    Inscription : septembre 2019
    Messages : 3
    Points : 2
    Points
    2
    Par défaut
    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 :
    Nom : mdmd.PNG
Affichages : 31
Taille : 93,4 Ko

  7. #7
    Expert éminent sénior

    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    5 253
    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 : 5 253
    Points : 15 526
    Points
    15 526
    Billets dans le blog
    1
    Par défaut
    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

Discussions similaires

  1. recherche des etudes de cas merise
    Par amira2006 dans le forum Merise
    Réponses: 2
    Dernier message: 16/03/2007, 12h23
  2. [N-Tier] Etude de cas
    Par Ireza dans le forum Autres
    Réponses: 1
    Dernier message: 01/11/2006, 17h02
  3. Etude de cas : lancement d'un shell par web
    Par Loko dans le forum Réseau/Web
    Réponses: 4
    Dernier message: 09/06/2006, 17h53
  4. [UML] Etude de cas - Bibliothèque
    Par slim dans le forum UML
    Réponses: 10
    Dernier message: 21/03/2006, 10h16

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