IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
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 :

Gestion d'un parc canin


Sujet :

Schéma

  1. #1
    Membre à l'essai
    Homme Profil pro
    Étudiant
    Inscrit en
    Novembre 2014
    Messages
    21
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : Belgique

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Novembre 2014
    Messages : 21
    Points : 20
    Points
    20
    Par défaut Gestion d'un parc canin
    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 : 1710
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
    8 001
    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 : 8 001
    Points : 30 905
    Points
    30 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).
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, 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 »)

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

  3. #3
    Membre à l'essai
    Homme Profil pro
    Étudiant
    Inscrit en
    Novembre 2014
    Messages
    21
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : Belgique

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Novembre 2014
    Messages : 21
    Points : 20
    Points
    20
    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
    8 001
    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 : 8 001
    Points : 30 905
    Points
    30 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.
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, 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 »)

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

  5. #5
    Membre à l'essai
    Homme Profil pro
    Étudiant
    Inscrit en
    Novembre 2014
    Messages
    21
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : Belgique

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Novembre 2014
    Messages : 21
    Points : 20
    Points
    20
    Par défaut
    Comme ceci peut-être?

    Nom : ContactHeritage.png
Affichages : 1668
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
    8 001
    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 : 8 001
    Points : 30 905
    Points
    30 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 !
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, 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 »)

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

  7. #7
    Membre à l'essai
    Homme Profil pro
    Étudiant
    Inscrit en
    Novembre 2014
    Messages
    21
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : Belgique

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Novembre 2014
    Messages : 21
    Points : 20
    Points
    20
    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 : 1985
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
    8 001
    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 : 8 001
    Points : 30 905
    Points
    30 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.
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, 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 »)

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

  9. #9
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 001
    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 : 8 001
    Points : 30 905
    Points
    30 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...
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, 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 »)

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

  10. #10
    Membre à l'essai
    Homme Profil pro
    Étudiant
    Inscrit en
    Novembre 2014
    Messages
    21
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : Belgique

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Novembre 2014
    Messages : 21
    Points : 20
    Points
    20
    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
    Membre à l'essai
    Homme Profil pro
    Étudiant
    Inscrit en
    Novembre 2014
    Messages
    21
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : Belgique

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Novembre 2014
    Messages : 21
    Points : 20
    Points
    20
    Par défaut
    Bonsoir,

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

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

  12. #12
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 134
    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 : 10 134
    Points : 38 557
    Points
    38 557
    Billets dans le blog
    9
    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
    8 001
    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 : 8 001
    Points : 30 905
    Points
    30 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.
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, 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 »)

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

  14. #14
    Membre à l'essai
    Homme Profil pro
    Étudiant
    Inscrit en
    Novembre 2014
    Messages
    21
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : Belgique

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Novembre 2014
    Messages : 21
    Points : 20
    Points
    20
    Par défaut
    merci cinephil d'avoir déplacé mon sujet dans un endroit plus approprié

    Bonjour fsmrel, escartefigue

    donc voici les modifications suite a vos remarques concernant la gestion de stock
    J'ai vu beaucoup de mcd passer par une entité mouvement pour l'inventaire je ne sais pas trop si en utilisant cette table de relation c'est suffisant du coup.
    Les quantités doivent être de type DECIMAL et non INTEGER
    Je ne comprends pas bien la raison du type decimal, un client n’achète pas un demi jouet ou un demi sachet de croquette ^^

    Nom : gestionStockCouleur.png
Affichages : 1476
Taille : 68,8 Ko

    Association Achete :
    je la retravaille maintenant mais je pensais peut etre faire un genre de panier par cette table de relation.
    edit:
    Nom : PanierAchat.png
Affichages : 2081
Taille : 12,5 Ko

    est ce que comme ca je conserve bien un historique de qui achète quoi? une idée etait sortie de faire des promotions individuelles en fonction des achats les plus fréquents des clients.

    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 ?
    La date est mal mise mais j'aimerais tracer quoi est utilisé quand mais je retrouve probablement déjà cette date ailleurs je regarde a ca aussi

    concernant par exemple les réservations.
    Moi aussi j'ai des questions mais je vais commencer par la modifier. Je l'ai mise pour la spécifier mais je ne sais pas bien comment la manipuler

    J'aurais encore une autre question, le fait que j'aurai parfois des clients qui ne seront pas enregistré et donc qui n'auront donné aucun renseignement concernant leur adresse etc. est ce un problème? car du coup je vais me retrouver avec une ribambelle de champ inutile dans leur cas :/ je peux supposer qu'il ne seront pas beaucoup dans ce cas tout comme supposer qu'il y en aura.

  15. #15
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 001
    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 : 8 001
    Points : 30 905
    Points
    30 905
    Billets dans le blog
    16
    Par défaut
    Bonsoir miniboom et le Capitaine,


    Pour aujourd’hui...


    Citation Envoyé par miniboom Voir le message
    Je ne comprends pas bien la raison du type decimal, un client n’achète pas un demi jouet ou un demi sachet de croquette ^^
    Je suis parti du principe très général qu’il y a des produits qu’on peut par exemple acheter au kilo, donc 3,7 kg n’et pas aberrant. Mais si aucun de vos produit n’est susceptible d’être vendu autrement qu’en un tout indivisible, le type INTEGER peut faire l’affaire. Attention à l’emploi que vous faites du type DECIMAL. Par exemple, le taux de TVA est bien de ce type, mais pensez aux chiffres après la virgule : en l’occurrence utilisez DECIMAL(4,2).


    Citation Envoyé par miniboom Voir le message
    le fait que j'aurai parfois des clients qui ne seront pas enregistré et donc qui n'auront donné aucun renseignement concernant leur adresse etc. est ce un problème? car du coup je vais me retrouver avec une ribambelle de champ inutile dans leur cas :/ je peux supposer qu'il ne seront pas beaucoup dans ce cas tout comme supposer qu'il y en aura.
    Ça n’est pas bien grave. Vous renseignerez les attributs avec la valeur '', ainsi ces clients ne seront pas encombrants.


    Citation Envoyé par miniboom Voir le message
    J'ai vu beaucoup de mcd passer par une entité mouvement pour l'inventaire je ne sais pas trop si en utilisant cette table de relation c'est suffisant du coup.
    Je ne sais pas de quelle table de relation vous parlez. En passant, le terme table ne fait pas partie du vocabulaire au stade MCD, mais seulement après (MLD, puis code SQL). Quoi qu’il en soit, vous faites figurer dans votre MCD une entité-type INVENTAIRE, en relation avec l’entité-type ARTICLE_MAGASIN et comportant notamment un attribut QteActuelle, mais que peut-elle nous apprendre ? Uniquement la quantité totale de tous les articles confondus, ce qui ne correspond évidemment pas à la bonne maille, il faut qu’on puisse disposer plus finement de l’information, c'est-à-dire par article.

    Vous pourriez partir de ceci :

    [ARTICLE_MAGASIN]--1,N--------(COMPTER)--------<1,1>--[INVENTAIRE {anneeInventaire, qte, ...}]


    Association ACHETE

    Selon le diagramme ci-dessous, dans le cas des articles en magasin, l’attribut Tarif est redondant avec l’attribut PUVente, il va falloir évacuer la redondance...

    Nom : PanierAchat.png
Affichages : 2081
Taille : 12,5 Ko


    L’attribut MontantTotal de l’entité-type PANIER est calculable, mais évidemment au prix d’une gymnastique faisant intervenir le temps (évolution des prix, de la TVA...), sachant que l’attribut Tarif fournit le prix (PU ?) d’un produit aujourd’hui. Si vous conservez l’attribut MontantTotal, il y aura des contrôles à effectuer du fait de la redondance inévitable.


    TVA, historisation et Cie

    Vous avez fait figurer la TVA, mais uniquement pour les factures. Le prix TCC des articles en magasin sort-il du champ de votre application ? S’il faut le prendre en compte, alors il y aura historisation des PU par article et du taux de TVA par catégorie d’article, comme dans ce qui suit, où il n’y a rien de définitif, ce sont plutôt des pistes à suivre. Je me suis servi d’AMC pour les diagrammes.

    Avant de traiter de la TVA, tentons déjà de régler le problème du tarif doublonnant avec le prix de vente en magasin. Ainsi, remontons le prix de vente unitaire (attribut PUVente) dans PRODUIT.

    On met en oeuvre un attribut PUVenteDepuis (du type DATE), permettant de connaître la date la plus récente à laquelle est appliqué le prix de vente unitaire (prix en vigueur) :


    A noter que l’attribut CodeBarre de l’entité-type ARTICLE_MAG fait l’objet d’une clé alternative {CodeBarre}.


    Historisation du prix de vente unitaire

    On définit une entité-type PU_VENTE_HISTO identifiée relativement à l’entité-type PRODUIT. C’est l’attribut PUVenteDurant qui sert d’identifiant relatif. Il est du type INTERVAL (date début, date fin). Ce type (bien pratique pour traiter des historiques) est proposé par le SGBD PostgreSQL, mais je ne l’ai pas vu dans la doc SQL Server et il n’existe pas chez MySQL (au fait, quel est/sera votre SGBD ?) A défaut, on met en oeuvre une date de début et une date de fin et on se coltine les calculs à la main...

    Pour résumer, le prix de vente en vigueur pour un produit (donc, par héritage, d’un article en magasin) est connu grâce à l’attribut PUVente de l’entité-type PRODUIT. Les prix de vente précédents de ce produit sont connus grâce à l’entité-type PU_VENTE_HISTO.



    TVA en vigueur

    Au stade SQL, pour éviter d’avoir à modifier tous les taux présents, disons dans la table PRODUIT (passage par exemple de 19,6 % à 20 %), on disposera d’une table CATEGORIE_TVA qui supportera le choc des changements de TVA (dans le cas du passage de 19,6 % à 20 % : une seule ligne à modifier). Au niveau conceptuel, le diagramme est le suivant :


    L’entité-type CATEGORIE_TVA (donc la table éponyme) est dotée d’un attribut tvaDepuis (de type DATE), permettant de connaître la date d’entrée en vigueur de la tva à appliquer à un produit.


    TVA historisée

    Supposons que le produit P1 soit actuellement soumis à une tva de 20%. Antérieurement, sa tva avait été de 19,6% voire 18,6%, etc. Connaissant son prix de vente dans le passé (cf. entité-type PU_VENTE_HISTO), on peut savoir quel était le taux appliqué à l’époque : P1 relève de la catégorie définie par l’association RELEVER_DE, et l’intersection de l’attribut PUVenteDurant et de l’attribut tvaDurant (tous deux du type INTERVAL) permet de récupérer le taux de tva alors applicable à P1.



    Voilà pour cette fois-ci, en espérant ne pas vous avoir traumatisé et m’être fourvoyé : la prise en compte du temps est rarement quelque chose de simple, il y a plein de chausse-trappes...
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, 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 »)

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

  16. #16
    Membre à l'essai
    Homme Profil pro
    Étudiant
    Inscrit en
    Novembre 2014
    Messages
    21
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : Belgique

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Novembre 2014
    Messages : 21
    Points : 20
    Points
    20
    Par défaut
    Bonjour fsmrel,

    Merci pour toutes tes précision mais je vais laisser tomber l'aspect TVA pour l'instant, l'échéance du travail approchant il me faut faire quelques concessions en gardant à l'esprit d'y revenir par la suite donc nous rediscuterons de cet aspect plus tard a n'en pas douter. Je ne m'attendais simplement pas à ce que ce soit si complexe, je n'ai pas souvenir d'une telle réflexion au cours des différents exercices scolaires sur la question.

    bref,
    concernant l'inventaire si je fais
    [ARTICLE_MAGASIN]--1,N--------(COMPTER)--------<1,1>--[INVENTAIRE {anneeInventaire, qte, ...}]
    je ne peux pas y faire ma gestion de stock, ou alors en creant un idInventaire et un identifiant alternatif lastUpdate qui récupère la date de précise de modification du stock?
    Nom : Inventaire.png
Affichages : 1250
Taille : 11,8 Ko
    et en utilisant un lien relatif, je comprends que je supprime l'inventaire d'un article si l'article est supprimé. Hors pour la comptabilité ne dois je pas conserver l'inventaire d'un article meme en cas de suppression de celui ci?


    concernant les réservation j'ai modifié comme suit:
    Nom : reservationn.png
Affichages : 1482
Taille : 25,9 Ko

    Enfin concernant le code sql de la relation d'héritage du Contact/Clientfournisseur j'éprouve aussi quelques difficultés :/. Voici les tables SQL (Sql server)
    Nom : SQLHeritage.png
Affichages : 1249
Taille : 13,3 Ko

    En parcourant la doc j'ai atterri sur ceci :
    https://sqlpro.developpez.com/cours/...tion/heritage/

    mais ca ne fonctionne pas, de plus dans l'exemple en question les attribut commun ne sont pas repris dans les tables filles uniquement leurs attributs perso, du coup je me pose la question si ma modélisation des données est correcte d'ou le schéma ci dessus.

    merci d'avance,
    miniboom

  17. #17
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 001
    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 : 8 001
    Points : 30 905
    Points
    30 905
    Billets dans le blog
    16
    Par défaut
    Bonsoir miniboom,

    Citation Envoyé par miniboom Voir le message
    je ne peux pas y faire ma gestion de stock, ou alors en créant un idInventaire et un identifiant alternatif lastUpdate qui récupère la date de précise de modification du stock ?
    Vous pouvez effectivement mettre en oeuvre l’identifiant (relatif) idInventaire et un identifiant (relatif) alternatif lastUpdate (à renommer en dateInventaire pour rester dans un contexte francophone...), lequel peut du reste sans risque être l’identifiant (relatif) à la place de IdInventaire.


    Citation Envoyé par miniboom Voir le message
    en utilisant un lien relatif, je comprends que je supprime l'inventaire d'un article si l'article est supprimé.
    Pour que la suppression d’un article déclenche celle de ses inventaires, il faut le déclarer au stade du code SQL. Cela se passe au niveau des clés étrangères. Exemple :


    CREATE TABLE PRODUIT 
    (
          idProduit                INT                      NOT NULL,
          nomProduit               VARCHAR(64)              NOT NULL,
          PUVenteDepuis            DATETIME                 NOT NULL,
          PUVente                  DECIMAL(8,2)             NOT NULL,
       CONSTRAINT PRODUIT_PK PRIMARY KEY (idProduit)
    ) ;
    
    CREATE TABLE ARTICLE_MAG 
    (
          idProduit                INT                      NOT NULL,
          codeBarre                VARCHAR(48)              NOT NULL,
       CONSTRAINT ARTICLE_MAG_PK PRIMARY KEY (idProduit),
       CONSTRAINT ARTICLE_MAG_AK UNIQUE (codeBarre),
       CONSTRAINT ARTICLE_MAG_PRODUIT_FK FOREIGN KEY (idProduit)
          REFERENCES PRODUIT  (idProduit) ON DELETE CASCADE
    ) ;
    CREATE TABLE INVENTAIRE 
    (
          idProduit                INT                      NOT NULL,
          dateInventaire           DATETIME                 NOT NULL,
          quantite                 INT                      NOT NULL,
       CONSTRAINT INVENTAIRE_PK PRIMARY KEY (idProduit, dateInventaire),
       CONSTRAINT INVENTAIRE_ARTICLE_MAG_FK FOREIGN KEY (idProduit)
          REFERENCES ARTICLE_MAG  (idProduit) ON DELETE CASCADE
    ) ;
    
    Dans cet exemple, il y a une contrainte référentielle ARTICLE_MAG_PRODUIT_FK par laquelle la table ARTICLE_MAG fait référence à la table PRODUIT, et pour laquelle on a codé « ON DELETE CASCADE », ce qui se lit ainsi :

    A l’occasion d’une tentative de suppression du produit P1 (qui est un article magasin) appliquée à la table PRODUIT, il y a envoi d’un stimulus de la part de cette table, à destination de la table ARTICLE_MAG, et à cause du mot magique CASCADE, cette dernière est d’accord pour que l’article en magasin P1 qu’elle contient soit supprimé aussi chez elle.

    Puisque la table ARTICLE_MAG est d’accord pour que P1 y soit supprimé, elle envoie à son tour un stimulus à destination de la table INVENTAIRE et, à nouveau, à cause du mot magique CASCADE, celle-ci est d’accord pour que ce qui concerne P1 soit supprimé chez elle.

    Mais ceci contrevient à ce que vous avez écrit :

    Citation Envoyé par miniboom Voir le message
    Pour la comptabilité ne dois je pas conserver l'inventaire d'un article même en cas de suppression de celui-ci ?
    Dans ces conditions, dans la déclaration de la table INVENTAIRE, on remplace le mot magique CASCADE par NO ACTION :

    CREATE TABLE INVENTAIRE 
    (
          idProduit                INT                      NOT NULL,
          dateInventaire           DATETIME                 NOT NULL,
          quantite                 INT                      NOT NULL,
       CONSTRAINT INVENTAIRE_PK PRIMARY KEY (idProduit, dateInventaire),
       CONSTRAINT INVENTAIRE_ARTICLE_MAG_FK FOREIGN KEY (idProduit)
          REFERENCES ARTICLE_MAG (idProduit)  ON DELETE NO ACTION  
    ) ;
    
    Certes, la table ARTICLE_MAG est d’accord pour que P1 soit supprimé chez elle, mais quand elle envoie à son tour un stimulus à destination de la table INVENTAIRE, à cause du mot magique NO ACTION, celle-ci refuse que ce qui concerne P1 soit supprimé. En relationnel, on marche par tout ou rien : en l’occurrence la tentative de suppression est rejetée non seulement pour la table INVENTAIRE, mais aussi pour les tables émettrices des stimuli, à savoir PRODUIT et ARTICLE_MAG.

    P1 ne pourra donc être supprimé dans les tables PRODUIT et ARTICLE_MAG que lorsqu’il n’y aura plus rien pour lui dans l’inventaire.

    En attendant, vous pouvez marquer P1 comme « logiquement » supprimé en définissant un attribut de type booléen en ce sens dans l’en-tête de la table PRODUIT.

    Autre solution : monter une usine à gaz pour conserver la mémoire des données portées par les tables PRODUIT, ARTICLE_MAG, INVENTAIRE et toutes celles qui vivent par elles, mais je ne vais pas me lancer dans ce montage. CinePhil, escartefigue, JPhi33 ont peut-être de meilleures solutions...

    N.B. L’association COMPREND est à débarrasser de ses attributs.


    Citation Envoyé par miniboom Voir le message
    concernant le code sql de la relation d'héritage du Contact/Clientfournisseur j'éprouve aussi quelques difficultés :/. Voici les tables SQL (Sql server)
    Hum... On doit avoir ceci, quand même moins redondant :



    Mais mieux vaut présenter le code SQL, quand même plus complet, par exemple (je n’ai pas mis tous les attributs) :

    CREATE TABLE CONTACT 
    (
            idContact            INT  IDENTITY   NOT NULL
          , NumeroContact        VARCHAR(8)      NOT NULL
          , NomContact           VARCHAR(8)      NOT NULL
          , Email                VARCHAR(64)     NOT NULL
        , CONSTRAINT CONTACT_PK PRIMARY KEY (idContact)
        , CONSTRAINT CONTACT_NUMERO_AK UNIQUE (NumeroContact)
    ) ;
    
    CREATE TABLE CLIENT 
    (
            idContact            INT             NOT NULL
        , CONSTRAINT ARTICLE_PK PRIMARY KEY (idContact)
        , CONSTRAINT CLIENT_CONTACT_FK FOREIGN KEY (idContact)
    	      REFERENCES CONTACT (idContact) ON DELETE CASCADE
    ) ;
    
    CREATE TABLE FOURNISSEUR 
    (
            idContact            INT             NOT NULL
          , NoSiret              CHAR(14)        NOT NULL
        , CONSTRAINT FOURNISSEUR_PK PRIMARY KEY (idContact)
        , CONSTRAINT FOURNISSEUR_SIRET_AK UNIQUE (NoSiret)
        , CONSTRAINT FOURNISSEUR_CONTACT_FK FOREIGN KEY (idContact)
    	      REFERENCES CONTACT (idContact) ON DELETE CASCADE
    ) ;
    

    Pour les réservations, je regarderai un peu plus tard.

    Bon courage !
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, 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 »)

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

  18. #18
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 001
    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 : 8 001
    Points : 30 905
    Points
    30 905
    Billets dans le blog
    16
    Par défaut
    Au sujet de l’héritage mettant en jeu les entités-types CONTACT, CLIENT et FOURNISSEUR, et les problèmes que cela vous pose au stade SQL, avez-vous utilisé le code SQL généré par JMerise ? Si oui, avez-vous lu ce que j’ai écrit à ce propos ?

    Citation Envoyé par fsmrel Voir le message
    Dans « Paramètres & Configuration » > « Configuration des paramètres » > « Contraintes MCD », paramètre « Importer tous les attributs (non clés primaires) de l’entité mère » : je ne sais pas quelle est l’option par défaut : case cochée ? décochée ? Pour les novices, il est évident que la case doit être décochée, sinon avec le MCD ci-dessus, le MLD devient :

    Concernant le contenu du panier

    La présence de l’attribut DatePanierProduit dans l’association AJOUTE signifie que dans le même panier, deux produits différents P1 et P2 peuvent avoir des valeurs différentes pour l’attribut DatePanierProduit. Est-ce bien ce que vous voulez ? Par exemple, ci-dessous, selon la table AJOUTE, dans le panier 1, pour le produit 1 et le produit 2 les dates sont respectivement le '2018-08-07' et le '2018-08-08' :

    PRODUIT {idProduit    codeProduit    Nom        Tarif}          PANIER {idPanier    idContact}
             1            P1             Produit 1     10                   1           128    
             2            P2             Produit 2     20   
    
    AJOUTE {idProduit    idPanier    Quantite    MontantTotal    DatePanierProduit}
            1            1                 15             150    2018-08-07
            2            1                  4              80    2018-08-08
            1            2                  5              50    2018-08-07
    

    Plutôt que de stocker « en dur » la valeur pour la colonne MontantTotal (une erreur de saisie est toujours possible), il sera préférable de mettre en oeuvre une fonction effectuant le calcul MontantTotal = Tarif X Quantite.

    Exemple :

     
    ----------------------------------------------------------------------------
    -- Calcul du montant total d’un article dans le panier: Tarif * Quantite
    ----------------------------------------------------------------------------
    GO
    CREATE FUNCTION CalcMtPanier(@leProduit INT, @laQuantite INT)
    RETURNS INT
    AS
        BEGIN
            RETURN (@laQuantite * (SELECT tarif FROM PRODUIT WHERE idProduit = @leProduit))
        END
    GO
    
    Les tables (notez la colonne « calculée » MontantTotal) :

     
    CREATE TABLE PRODUIT 
    (
            idProduit            INT  IDENTITY   NOT NULL
          , codeProduit          VARCHAR(8)      NOT NULL
          , Nom                  VARCHAR(48)     NOT NULL
          , Tarif                INT             NOT NULL
         , CONSTRAINT PRODUIT_PK PRIMARY KEY (idProduit)
         , CONSTRAINT PRODUIT_CODE_AK UNIQUE (codeProduit)
     ) ;
    
    CREATE TABLE CONTACT 
    (
            idContact            INT  IDENTITY   NOT NULL
          , NumeroContact        VARCHAR(8)      NOT NULL
          , NomContact           VARCHAR(48)     NOT NULL
          , Email                VARCHAR(64)     NOT NULL
        , CONSTRAINT CONTACT_PK PRIMARY KEY (idContact)
        , CONSTRAINT CONTACT_NUMERO_AK UNIQUE (NumeroContact)
    ) ;
    
    CREATE TABLE CLIENT 
    (
            idContact            INT             NOT NULL
        , CONSTRAINT ARTICLE_PK PRIMARY KEY (idContact)
        , CONSTRAINT CLIENT_CONTACT_FK FOREIGN KEY (idContact)
              REFERENCES CONTACT (idContact) ON DELETE CASCADE
    ) ;
    
    CREATE TABLE PANIER 
    (
            idPanier             INT  IDENTITY   NOT NULL
          , idContact            INT             NOT NULL
        , CONSTRAINT PANIER_PK PRIMARY KEY (idPanier)
        , CONSTRAINT PANIER_CLIENT_FK FOREIGN KEY (idContact)
              REFERENCES CLIENT (idContact) ON DELETE NO ACTION
    ) ;
    
    CREATE TABLE AJOUTE 
    (
            idProduit            INT             NOT NULL
          , idPanier             INT             NOT NULL
          , Quantite             INT             NOT NULL
          , MontantTotal AS dbo.CalcMtPanier(idProduit, Quantite)  ---- Appel à la fonction CalcMtPanier
          , DatePanierProduit    DATE            NOT NULL
        , CONSTRAINT AJOUTE_PK PRIMARY KEY (idPanier, idProduit)
        , CONSTRAINT AJOUTE_PANIER_FK FOREIGN KEY (idPanier)
              REFERENCES PANIER (idPanier) ON DELETE CASCADE
        , CONSTRAINT AJOUTE_PRODUIT_FK FOREIGN KEY (idProduit)
              REFERENCES PRODUIT (idProduit) ON DELETE NO ACTION
     ) ;
    
    Un jeu de test :

     
    INSERT INTO PRODUIT (codeProduit, Nom, Tarif) VALUES ('P1', 'Produit 1', 10) ;
    INSERT INTO PRODUIT (codeProduit, Nom, Tarif) VALUES ('P2', 'Produit 2', 20) ;
    
    INSERT INTO CONTACT (NumeroContact, NomContact, Email) VALUES ('K1', 'Contact 1', 'Cont1@machin.org') ;
    INSERT INTO CONTACT (NumeroContact, NomContact, Email) VALUES ('K2', 'Contact 2', 'Cont1@machin.org') ;
    
    INSERT INTO CLIENT (idContact) SELECT idContact FROM CONTACT ;
    
    INSERT INTO PANIER (idContact) VALUES (1) ;
    INSERT INTO PANIER (idContact) VALUES (2) ;
    
    INSERT INTO AJOUTE (idProduit, idPanier, Quantite, DatePanierProduit) VALUES (1, 1, 15, '2018-08-07') ;
    INSERT INTO AJOUTE (idProduit, idPanier, Quantite, DatePanierProduit) VALUES (2, 1, 4, '2018-08-08') ;
    INSERT INTO AJOUTE (idProduit, idPanier, Quantite, DatePanierProduit) VALUES (1, 2, 5, '2018-08-07') ;
    
    SELECT * FROM AJOUTE ;
    
    =>

    idProduit    idPanier    Quantite    MontantTotal    DatePanierProduit
    1            1           15          150             2018-08-07
    2            1           4           80              2018-08-08
    1            2           5           50              2018-08-07
    

    Entité-type RESERVATION

    Vous ne prévoyez pas d’attribut pour la quantité réservée ?
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, 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 »)

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

  19. #19
    Membre à l'essai
    Homme Profil pro
    Étudiant
    Inscrit en
    Novembre 2014
    Messages
    21
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : Belgique

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Novembre 2014
    Messages : 21
    Points : 20
    Points
    20
    Par défaut
    Bonjour,

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    Au sujet de l’héritage mettant en jeu les entités-types CONTACT, CLIENT et FOURNISSEUR, et les problèmes que cela vous pose au stade SQL, avez-vous utilisé le code SQL généré par JMerise ? Si oui, avez-vous lu ce que j’ai écrit à ce propos ?
    J'avais lu en diagonale la conversation de ce sujet et j'avais loupé ce détail pour le moins important. Effectivement, ça fonctionne mieux à présent. Je l'ai refait à la main hier (les modif sql) et mon trigger fonctionne à présent.

    Est-ce bien ce que vous voulez ?
    Non en effet ce n'est pas ce que je désire je souhaite conserver la date a laquelle un client a acheté un/des produit(s) et donc je suppose que je dois plutôt stocker la date directement dans l'entité panier.

    fonction effectuant le calcul MontantTotal = Tarif X Quantite
    Je ne pensais pas la saisir manuellement et écrire une fonction similaire côté client mais votre version est bien meilleure. Mes lacunes en SQL sont nombreuses tout comme en analyse en générale mais j'apprends beaucoup grâce à vous, merci beaucoup. Par contre, jmerise me permet-il de le spécifier ne fut ce que pour la lecture d'autrui?

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    Vous ne prévoyez pas d’attribut pour la quantité réservée ?
    A la base je pensais ne permettre de réserver qu'un produit a la fois, les réservation portant uniquement sur les produit qui ne sont pas de type articleMagasin et peut être est il préférable, comme on me l'a deja suggéré, d'anticiper la possibilité de pouvoir tout réserver et en n'importe quel quantité.

  20. #20
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 001
    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 : 8 001
    Points : 30 905
    Points
    30 905
    Billets dans le blog
    16
    Par défaut
    Bonjour miniboom,


    Citation Envoyé par miniboom Voir le message
    Non en effet ce n'est pas ce que je désire je souhaite conserver la date a laquelle un client a acheté un/des produit(s) et donc je suppose que je dois plutôt stocker la date directement dans l'entité panier.
    Effectivement, la date doit disparaître de AJOUTE et renaître dans PANIER. En termes relationnels, on dit que l’on normalise en 2e forme normale : l’attribut DatePanierProduit ne doit pas dépendre que d’une partie de la clé {idPanier, idProduit} de la table AJOUTE, d’où la migration nécessaire de cet attribut vers PANIER.


    Citation Envoyé par miniboom Voir le message
    jmerise me permet-il de le spécifier ne fut ce que pour la lecture d'autrui?
    Oui, en utilisant l’icône « Commentaire », que vous reliez aux entités-types et associations parties prenantes (en utilisant l’icône « Nouveau lien »). Le résultat est plutôt sobre, mais au moins l’oeil est correctement sollicité... :



    Citation Envoyé par miniboom Voir le message
    j'apprends beaucoup grâce à vous
    Si donc j’ai pu vous aider...
    N’oubliez pas que pour les médailles en chocolat qui font toujours plaisir, si vous avez deux minutes, c’est ici.
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, 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 »)

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

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. [MCD] [MCD] Gestion des dates
    Par brionne dans le forum Schéma
    Réponses: 3
    Dernier message: 30/05/2003, 13h01
  4. [BEST_PRACTICE][Merise] MCD & gestion de date
    Par Seb7 dans le forum Schéma
    Réponses: 4
    Dernier message: 16/04/2003, 17h07

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