Discussion: MCD Gestion pme

  1. #1
    Candidat au Club
    Homme Profil pro
    Étudiant
    Inscrit en
    novembre 2014
    Messages
    13
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 29
    Localisation : Belgique

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : novembre 2014
    Messages : 13
    Points : 4
    Points
    4

    Par défaut MCD Gestion pme

    Bonjour,
    Dans le cadre de mon tfe, j’ai obtenu le projet d’un développement logiciel de gestion d’un parc canin. Ce parc canin possède un magasin duquel est demandé une gestion de stock/facture/fournisseur.

    Le parc canin est divisé en plusieurs parcs :
    récréation
    Gardiennage (supplément monétaire)
    Agility (supplément monétaire)
    Labyrinthe
    Point d’eau
    Excercice de rappel (supplément monétaire, disponible après quelques jours si bon comportement du chien (représenté par chien.IsGentil))

    L’entrée au parc est facturée 10euro mais les clients ont la possibilité de payer un abonnement de 10 entrée qui réduit le cout pour chaque entrée. Il est également possible de nettoyer son chien, de l’héberger ainsi que de participer à des cours d’éducation. Y participer induit un coût supplémentaire. Ces cours d’éducation sont disponibles sur réservation ou non. Aucun acompte n’est demandé.

    Concernant la gestion de stock, ma cliente désire une automatisation des commandes fournisseurs lorsque le stock descend en dessous d’un certain seuil ainsi que la conservation des documents qui y sont liés.

    Concernant les chiens, un document d’assurance est signé entre les deux parties. En effet en cas de dégât, les clients propriétaire du chien concerné, doivent rembourser les dégâts liés au matériel mis a disposition. Le parc est filmé h24 et un historique est conservé concernant le comportement du chien. Le carnet de vaccination du chien est également demandé lors de l’inscription.

    Enfin les clients peuvent obtenir une carte de fidélité pour obtenir réduction/autres personnalisées sur les produits qu’ils achètent.

    Merci d’avance,
    Miniboom

    ps: je pense ajouter une relation avec produit au niveau des réservations clients mais que pensez vous de la gestion de stock? et des différentes relations d'héritages? est ce que cela vous semble ok?

    Nom : McdJpgCanin.png
Affichages : 77
Taille : 125,3 Ko

  2. #2
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    6 217
    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 217
    Points : 20 905
    Points
    20 905
    Billets dans le blog
    16

    Par défaut

    Il y a de la matière...

    Déjà pour y voir plus clair (c'est écrit en tout petit, j’ai énormément de mal à lire le nom des objets...), utilisez pour l’héritage le symbolisme en usage. On peut supposer que le logiciel que vous utilisez est JMerise. S’il en est ainsi, considérons le cas des contacts. Un client est un contact : cliquez sur l’icône « Nouveau lien » puis tirez un lien directement entre CLIENT et CONTACT. Pour FOURNISSEUR, tirez un lien depuis FOURNISSEUR jusqu’au triangle symbolisant l’héritage. Ne définissez pas d’attribut idClient et idFournisseur, les entités-types spécialisées CLIENT et CONTACT hériteront de idContact en tant qu’identifiant (puis clé primaire et clé étrangère au stade MLD et SQL).
    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
    Candidat au Club
    Homme Profil pro
    Étudiant
    Inscrit en
    novembre 2014
    Messages
    13
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 29
    Localisation : Belgique

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : novembre 2014
    Messages : 13
    Points : 4
    Points
    4

    Par défaut

    Comme je n'ai pas activé la version payante de jmerise, je ne peux faire qu'un printscreen mais je peux le décortiquer pour bénéficier d'un meilleur zoom?
    sinon en l'ouvrant dans une fenetre a part c'est un peu mieux et je suis ouvert a toute proposition d'amélioration. Sinon je reposterai les modif dans la soirée

    merci pour toutes ces indications sinon j'ai modifié toutes mes relations d'héritage

  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 217
    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 217
    Points : 20 905
    Points
    20 905
    Billets dans le blog
    16

    Par défaut

    Bonsoir miniboom,

    Le mieux est de se focaliser sur le cœur du MCD, disons les contacts, donc de zoomer sur cette partie quitte à ne pas afficher le MCD en entier, mais au moins que j’arrive à lire...

    On verra le reste domaine par domaine, un peu à la façon d’aras-vbo, mais sans tout afficher bien sûr...

    Pensez à réduire la longueur de certains liens, quitte à aérer le diagramme à nouveau plus tard.
    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
    Candidat au Club
    Homme Profil pro
    Étudiant
    Inscrit en
    novembre 2014
    Messages
    13
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 29
    Localisation : Belgique

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : novembre 2014
    Messages : 13
    Points : 4
    Points
    4

    Par défaut

    Comme ceci peut-être?

    Nom : ContactHeritage.png
Affichages : 49
Taille : 73,3 Ko

  6. #6
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    6 217
    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 217
    Points : 20 905
    Points
    20 905
    Billets dans le blog
    16

    Par défaut

    Bonjour miniboom,


    J’y vois mieux !

    Entité-type CONTACT. Spécialisation des contacts

    L’entité-type CONTACT est spécialisée en CLIENT et FOURNISSEUR : d’accord. Cela dit, le triangle symbolisant l’héritage devrait être porteur d’une contrainte de partitionnement (XT), car un contact est soit un client soit un fournisseur, c'est-à-dire au moins l’un, mais pas les deux à la fois. S’il se trouve que le fournisseur Volfoni est aussi un client, il est sain de séparer les deux rôles, car par exemple l’adresse « fournisseur » de M. Volfoni est le plus souvent différente de son adresse « client », même chose pour les téléphones, etc.


    Entité-type CARTE_FIDELITE

    Utilisez un lien relatif pour la carte de fidélité. En effet, cette carte n’est jamais qu’une propriété facultative (donc à externaliser comme vous l’avez très bien fait). Cette entité-type n’a pas d’identifiant propre, elle hérite de l’identifiant de CLIENT (donc transitivement de CONTACT).


    Entité-type COMMANDE

    Vous ne souhaitez pas descendre au niveau de ligne de commande ? Comment harmonisez vous les quantités commandées et la gestion des stocks ? Je vous renvoie à Ingénierie des systèmes d'information : Merise deuxième génération (4e édition, 2001), par exemple page 422.

    Normalement une quantité commandée fait référence à un article, mais COMMANDE est seulement en relation avec STOCK, alors que STOCK est composé de l’ensemble des articles : il y a un problème.


    Attention au type des données !

    Entité-type CONTACT, attribut NumeroRue : vous utilisez le type INT, qui ne convient pas pour les gens qui habitent au 123 bis ou 123 ter ou 123 quater, ou encore au 123-125...

    Attribut CodePostal : VARCHAR(50) est excessif, disons qu’il y a au moins le zéro en trop... Reportez-vous par exemple à liste des codes postaux belges.

    Concernant le type FLOAT (virgule flottante) :

    Remplacez-le d’urgence par le type DECIMAL (virgule fixe).

    En effet :

    Citation Envoyé par SQL Server
    Floating point data is approximate; therefore, not all values in the data type range can be represented exactly.

    Citation Envoyé par PostgreSQL
    Les types de données real et double précision sont des types numériques inexacts de précision variable. En pratique, ils sont généralement conformes à la norme IEEE 754 pour l'arithmétique binaire à virgule flottante (respectivement simple et double précision), dans la mesure où les processeurs, le système d'exploitation et le compilateur les supportent.
    Ainsi, je vois mal les clients acheter des produits pour des montants approximatifs, et j’imagine la tête de votre comptable à la lecture du journal des ventes...

    Bref, revoyez soigneusement le type de chaque attribut.

    A suivre !
    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
    Candidat au Club
    Homme Profil pro
    Étudiant
    Inscrit en
    novembre 2014
    Messages
    13
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 29
    Localisation : Belgique

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : novembre 2014
    Messages : 13
    Points : 4
    Points
    4

    Par défaut

    salut fsmrel,

    tout d'abord mille merci pour le temps que tu prends pour m'aider, c'est vraiment très enrichissant. J'ai consulté ce que tu m'as dit mais je ne sais pas si ce que j'ai fait est correct mais c'est au minimum moins mauvais je ne sais pas trop ou faire ma gestion de stock dans la mesure ou mes articles ne sont que dans un stock et donc pas de table de relation au contraire de l'exemple et de ce que l'on m'avait déjà conseillé.

    Nom : GestionStockMCD.png
Affichages : 37
Taille : 48,1 Ko

  8. #8
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    6 217
    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 217
    Points : 20 905
    Points
    20 905
    Billets dans le blog
    16

    Par défaut

    Cas du stock.

    Dans l’exemple fourni à la page 422 de l’ouvrage que j’ai précédemment cité, le stock est tenu par dépôt et par article :



    D’où le MLD (modèle logique des données) :



    Le prédicat de STOCKER_DEPOT se lit ainsi :

    Le dépôt depotId stocke la quantité stockQuantite de l’article articleId.

    Par contre, selon le MLD dérivé de votre MCD, les quantités font l’objet d’attributs de l’entité-type DEPOT, et QteActuelleEnStock représente la somme des quantités en stock, tous articles confondus, ce qui n’a évidemment pas de sens...



    A la limite, vous auriez pu modéliser ainsi :



    D’où le MLD :


    Où cette fois-ci, la pertinence des attributs QteActuelleEnStock, QteMin et QteMax est avérée.

    En conséquence la notion de dépôt ne présente plus d’intérêt, et au nom du rasoir d’Ockham dans le MCD on supprime l’entité-type DEPOT :

    « Pluralitas non est ponenda sine necessitate » (Autrement dit, ce qui ne sert à rien : exit !)


    Citation Envoyé par miniboom Voir le message
    c'est vraiment très enrichissant
    Alors, ne pas hésiter à voter avec le bon pouce, celui qui est levé (à l’attention des daltoniens )

    Je vais continuer à regarder la partie du MCD que vous avez fait figurer dans votre message.
    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

  9. #9
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    6 217
    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 217
    Points : 20 905
    Points
    20 905
    Billets dans le blog
    16

    Par défaut

    Bonsoir miniboom,

    Entités-types Commande, LigneCommande

    Vous êtes en phase avec ce qui est proposé à la page 422 de l’ouvrage que j’ai précédemment cité, cette fois-ci la commande est bien composée de lignes de commande, chacune d’elles faisant référence à un article (du magasin). Comme dans l’ouvrage cité, l’entité-type LigneCommande est identifiée relativement à l’entité-type Commande : parfait.

    En ce qui concerne son identification, l’entité-type Commande est doté de l’attribut IdCommande : comme cet attribut donne lieu à l’identifiant {IdCommande} de Commande, il est purement artificiel, invariant (non modifiable), donc sans signification, non porteur d’information, et normalement c’est le SGBD qui en calcule ja valeur (disons par auto-incrémentation). Si vous créez vous aussi des numéros de commande (au moyen par exemple d’un logiciel ad-hoc), vous aurez peut-être intérêt à définir un attribut NumeroDeCommande, qualifié de naturel (du point de vue de la modélisation, par opposition à artificiel), ce nouvel attribut faisant l’objet d’un identifiant alternatif (notez en passant les commentaires concernant JMerise).



    Entité-type ArticleMagasin

    Je note que l’entité-type ArticleMagasin est porteuse d’un attribut PUAchat, mais si pour un article on peut avoir plus d’un fournisseur, alors on ne peut pas savoir à quel fournisseur précis associer le prix d’achat d’un article. Qu’en est-il ?


    Entité-type Facture

    Selon votre MCD, une commande fait l’objet d’au moins une facture. Si donc on a effectivement plus d’une facture pour une commande on ne sait pas pour autant quels articles sont concernés pour une facture donnée, voire plus précisément quelles lignes de facture correspondent à quelles lignes de commande. Cette connaissance sort-elle du champ de la modélisation ?

    L’attribut ReferenceFacture correspond-il au numéro de la facture établi par le fournisseur ?


    Entité-type DocumentFournisseur

    La patte d’association connectant l’entité-type DocumentFournisseur et l’association Associe est porteuse d’une cardinalité 0,1 : il y aurait donc des documents relatifs à des fournisseurs, mais inconnus, puisque pour savoir à quel fournisseur ce type de document fait référence, il faut passer par la commande. Ça n’est pas très sain...
    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
    Candidat au Club
    Homme Profil pro
    Étudiant
    Inscrit en
    novembre 2014
    Messages
    13
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 29
    Localisation : Belgique

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : novembre 2014
    Messages : 13
    Points : 4
    Points
    4

    Par défaut

    Re,

    désolé de mon absence des événements personnels m'ont écarté de la sphère informatique cette dernière semaine mais je suis de retour je poste des modifs sans tarder

  11. #11
    Candidat au Club
    Homme Profil pro
    Étudiant
    Inscrit en
    novembre 2014
    Messages
    13
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 29
    Localisation : Belgique

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : novembre 2014
    Messages : 13
    Points : 4
    Points
    4

    Par défaut

    Bonsoir,

    Voila je reposte le mcd complet avec les modif suggérées

    Nom : mcdComplet.png
Affichages : 12
Taille : 109,8 Ko

  12. #12
    Expert éminent

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

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 3 673
    Points : 8 327
    Points
    8 327
    Billets dans le blog
    1

    Par défaut

    Bonjour,

    Le MCD est difficile à lire, les éléments sont trop petits et j'ai du mal à déchiffrer

    Quelques remarques

    Entité-type ARTICLEMAGASIN
    Le choix d'identifier un article relativement au type article est surprenant : l'article n'est pas une entité-type faible contrairement à la ligne de commande qui ne saurait exister sans la commande à laquelle elle se rapporte
    Vous n'avez pas qualifié le type d'héritage
    Les quantités doivent être de type DECIMAL et non INTEGER
    Si la quantité annuelle en stock est une quantité à l'inventaire, alors c'est une notion à date, à évacuer de l'entité-type


    Entité-type TYPE-ARTICLE
    En général, les typologies possèdent un code et un libellé (en plus de l'identifiant technique bien sur).


    Entité-type FACTURE
    Le prix est un attribut de la ligne facture et non de la facture (sauf à considérer que vous ne faites que des factures mono-article, très peu probable...) et il manque l'ET ligne-facture.


    Entité-type COMMANDE et LIGNE-COMMANDE
    Positionner la date de livraison dans commande signifie qu'une commande est toujours livrée en une seule fois, est-ce bien le cas ?
    Les quantités doivent être de type DECIMAL et non INTEGER


    Entité-type CONTACT
    Sauf si tout contact a (et aura toujours) un et un seul téléphone, un et un seul courriel, une et une seule adresse etc... il faut externaliser les média et les adresses comme suit
    CONTACT 1,n --- résider --- (1,1) ADRESSE
    CONTACT 0,n --- posséder ---(1,1) MEDIA 1,1 --- typer --- 0,n TYPE_MEDIA


    Entité-type CHIEN
    Peut être faut il renommer en "ANIMAL" si vous avez d'autres espèces que les chiens ?
    L'âge étant une donnée calculée il ne faut pas la stocker. Stockez la date de naissance et calculez l'âge à chaque fois que c'est nécessaire
    Le sexe devrait être externalisé. Créez une ET "SEXE" et une relation entre l'animal et cette ET


    Entité-type DEPART et relation CAUSE
    A expliquer

  13. #13
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    6 217
    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 217
    Points : 20 905
    Points
    20 905
    Billets dans le blog
    16

    Par défaut

    Bonjour miniboom,

    Bon, ça s’améliore.

    Je voulais vous répondre hier soir, mais j'ai différé histoire de procéder à un examen un peu plus approfondi. Entre-temps, le Capitaine (escartefigue) est venu participer et nos remarques peuvent redonder mais en gros se complètent. Je ne retouche donc pas à ce que j’ai rédigé.

    Voici ce que j’ai écrit :

    Je reviens sur l’identification des entités-types. J’avais noté :

    Citation Envoyé par fsmrel Voir le message
    Entités-types Commande, LigneCommande

    Vous êtes en phase avec ce qui est proposé à la page 422 de l’ouvrage que j’ai précédemment cité, cette fois-ci la commande est bien composée de lignes de commande, chacune d’elles faisant référence à un article (du magasin). Comme dans l’ouvrage cité, l’entité-type LigneCommande est identifiée relativement à l’entité-type Commande : parfait.

    En ce qui concerne son identification, l’entité-type Commande est doté de l’attribut IdCommande : comme cet attribut donne lieu à l’identifiant {IdCommande} de Commande, il est purement artificiel, invariant (non modifiable), donc sans signification, non porteur d’information, et normalement c’est le SGBD qui en calcule la valeur (disons par auto-incrémentation). Si vous créez vous aussi des numéros de commande (au moyen par exemple d’un logiciel ad-hoc), vous aurez peut-être intérêt à définir un attribut NumeroDeCommande, qualifié de naturel (du point de vue de la modélisation, par opposition à artificiel), ce nouvel attribut faisant l’objet d’un identifiant alternatif (notez en passant les commentaires concernant JMerise).

    Entité-type Contact

    A son tour, l’entité-type Contact est dotée d’un attribut idContact, lequel doit lui aussi être artificiel, non modifiable et sans signification. L’utilisateur, appelons-le Albert, ne devrait pas y avoir accès, mais il faut quand même lui donner les moyens d’accéder aux données... Vous pouvez arranger cela en mettant en oeuvre un attribut naturel, du genre code, matricule, etc. dont Albert pourra avoir la maîtrise, mais faisant toutefois l’objet d’un identifiant alternatif (doublons interdits). Cet identifiant est son sésame pour accéder aux données et ne figure nulle part ailleurs. Au stade SQL, pour naviguer dans la base de données, on se servira seulement de idContact dans les requêtes ad-hoc, et cet attribut reste caché, privé, « encapsulé », Albert n’est pas au courant de son existence.

    Je rappelle encore que l’identifiant principal idContact ne peut être un attribut naturel, et à cette occasion je cite Yves Tabourier qui écrit à la page 80 de son remarquable ouvrage (De l’autre côté de MERISE, Les Éditions d’organisation, 1986), ce qui constitue une règle d’or valant pour les identifiants des entités-types florissant dans les MCD merisiens (règle d’or trop souvent méconnue, hélas ! Et comme disent Goethe et Cie, « ceux qui ont oublié le passé sont condamnés à le revivre... ») :

    « ... la fonction d’une propriété est de décrire les objets (et les rencontres), alors que l’identifiant ne décrit rien. Son rôle fondamental est d’être sûr de distinguer deux jumeaux parfaits, malgré des descriptions identiques.
    L’expérience montre d’ailleurs que l’usage des “identifiants significatifs” (ou “codes significatifs”) a pu provoquer des dégâts tellement coûteux que la sagesse est d’éviter avec le plus grand soin de construire des identifiants décrivant les objets ou, pis encore, leurs liens avec d’autres objets... »


    Entité-type Facture :

    Il n’y a pas d’entité-type pour les lignes de facture. Une ligne de facture = une ligne de commande ? Qu’en pense votre comptable ?


    Association Possede entre TypeDocument et Document :

    Vous avez utilisé l’identification relative, ce qui sémantiquement signifie que l’entité-type Document est une propriété multivaluée de l’entité-type TypeDocument : si ce sens sémantique est avéré par exemple pour la facture en relation avec ses lignes, tel n’est pas le cas pour un document, qui ne fait qu’être rangé dans une catégorie : du point de vue de la modélisation, l’entité-type Document désigne, fait référence à un type de document. Si l’on suivait l’idée de l’identification relative, en toute logique et du point de vue du métabolisme des données, la suppression d’un type de document devrait entraîner la suppression de tous les documents s’y rattachant, de même que changer le rattachement d’un document n’aurait pas de sens non plus (par analogie, songez au remplacement du rattachement d’une ligne de facture à une autre facture, quel sens cela pourrait avoir ?) Bref, ne pas identifier Document relativement à TypeDocument...


    Association Possede entre TypeArticle et ArticleMagasin :

    Même remarque, pas d’identification relative...


    Entité-type Tarif

    Il n’y a qu’un attribut naturel, lequel devrait en principe être absorbé par l’entité-type Produit.


    Association Achete :

    Au vu de cette association, on comprend que deux clients, disons Fernand et Raoul on pu acheter le même produit, le même jour, mais pour un montant différent. En outre, ce montant peut être sans rapport avec le prix de vente en magasin (entité-type ArticleMagasin, attribut PUVente). La quantité d’un article donné acheté est absente de l’association : pourriez-vous préciser les règles du jeu : quantité = Montant / PUVente ? Cette partie du modèle me paraît branli-branlante...


    Entité-type Chien

    L’attribut Age gagnerait à être remplacé par un attribut Date (ou Année) de naissance, sinon il faudra que vous programmiez un automate mettant à jour une fois par an l’âge de Zaza et Cie...


    Entités-types Education, Toilettage, Hebergement

    Education, Toilettage, Hebergement sont des produits, soit. Mais pourriez-vous en dire plus sur le rôle de la date qui y est présente ?


    Utilisation du type FLOAT

    Suite à mes observations, vous avez fait le ménage, mais le type FLOAT a parfois échappé à votre vigilance. L’attribut Taille de l’entité-type Document peut être du type INT, et celui de l’attribut Tarif de l’entité-type Document peut être du type DECIMAL.


    J’aurais d’autres questions, concernant par exemple les réservations.
    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

Discussions similaires

  1. [MCD]Gestion de Référencement de Produits
    Par shinrei dans le forum Schéma
    Réponses: 9
    Dernier message: 24/07/2006, 16h19
  2. [MCD] Gestion d'acces a des applications
    Par Tibler dans le forum Schéma
    Réponses: 12
    Dernier message: 25/04/2006, 18h10
  3. [BEST_PRACTICE][Merise] MCD & gestion de date
    Par Seb7 dans le forum Schéma
    Réponses: 5
    Dernier message: 10/01/2006, 05h49
  4. [MCD] [MCD] Gestion des dates
    Par brionne dans le forum Schéma
    Réponses: 3
    Dernier message: 30/05/2003, 13h01

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