Discussion :

[Igou77]

Bonjour,

J'ai réalisé le modèle suivant dans le cadre d'un projet, j'aimerais avoir vos avis !
C'est basé sur la notation Barker's ERD.

Il s'agit de modéliser une base de donnée pour la gestion de:

• Clients
• fournisseurs
• Adresses
• Personnes
• Paiements

Un petit exemple, un client qui est une entreprise dont nous avons l'adresse ainsi que le détail des personnes qui travaillent pour lui, peut passer une commande qui contient des produits (kit) et des services (travaux d'ingénierie (spécification/développement/mise en service) = engineering work).

Les produits (kit) sont fabriqués à l'aide de pièce (Part). Ces pièces sont en stock. Ces pièces peuvent être commandées à des fournisseurs et ces fournisseurs sont des entreprises qui sont également répertoriées dans nos adresses.

Les services sont accomplis par des employés sous la supervision d'un chef (employé) et les heures passées pour réaliser ce travail sont décrites.

Voici ce que j'ai essayé de représenter, j'aimerais savoir si en lisant le diagramme vous arrivez à comprendre ma démarche.

D'avance merci pour votre aide ...

[fsmrel]

Bonjour,

Les attributs (sémantiquement intéressants) des entités-types ne sont pas renseignés, ce qui ne simplifie pas la lecture (notamment des surtypes et de leurs sous-types), outre la vérification de la normalisation. Ainsi, vous dites que les employés passent un certain temps à effectuer certains travaux : on peut supposer que l’entité-type JOB sert à cela, mais un doute peut toujours planer. Un en-tête d’entité-type représente quand même un prédicat dont l'interprétation permet de bien mieux comprendre le diagramme.

Votre notation (que je ne connaissais pas) permet-elle de prendre en compte l’identification relative ? Si ça n’était pas le cas, ça serait fort fâcheux.

Apparemment, il n’y a aucune cardinalité 0,N : par exemple, une commande d’un client serait-elle donc toujours accompagnée d’un règlement ? Tous les employés supervisent-ils des travaux ? Etc.

Au niveau conceptuel, on peut n'avoir qu'une seule entité-type Adresse. Au niveau de base de données, il est préférable d’avoir une entité-type Adresse de société et une entité-type Adresse de personne (à moins de démontrer l’intérêt de la conservation du pot commun).

De la même façon, il est préférable de séparer les règlements des clients de ceux des fournisseurs.

Vous mettez en oeuvre un surtype Personne. Soit. Par contre, y a-t-il une bonne raison de ne pas en faire autant pour l’entité-type Société vis-à-vis des entités-types Client et Fournisseur ?

L’entité-type Part List devrait être renommée en Composition (sous-entendu de kits). En effet les pièces (parts) sont décrites plus bas.

Je ne suis pas sûr de mon interprétation des paires de lunettes noires chevauchant les liens "is part of". S’agit-il de contraintes d’exclusion ?

[Igou77]

Bonjour Fsmrel,

Tout d'abord, je sais que la méthode utilisée n'est pas très courante, mais mon prof est un "senior" développeur oracle et cette méthode vient de chez
oracle UK. Le liens ci-dessous donne quelque renseignement sur son auteur :
http://en.wikipedia.org/wiki/Barker%27s_Notation

Le lien suivant répondra à vos question concernant la cardinalité et les "lunettes noirs" qui signifient l'un ou l'autre :
http://www.onto-med.de/de/lehre/ws20...-eng/VCase.ppt

En ce qui concerne les attributs, je vais les ajouter de suite, je devais de toute façon le faire.

Pouvez-vous svpl m'expliquer plus en détail votre commentaire suivant :"Au niveau conceptuel, on peut n'avoir qu'une seule entité-type Adresse. Au niveau de base de données, il est préférable d’avoir une entité-type Adresse de
société et une entité-type Adresse de personne (à moins de démontrer l’intérêt
de la conservation du pot commun).

De la même façon, il est préférable de séparer les règlements des clients de
ceux des fournisseurs.
" .
Je ne comprends pas ce que je dois faire, si je dois changer le modèle ou si vous me conseillez seulement de faire des tables distinctes lors de la réalisation ?
Merci d'avance.

En ce qui concerne la raison pour ne pas faire un super type société qui comprend fournisseur et client, c'est la façon la plus élégante que j'ai trouvé pour dire qu'une société peut être client et fournisseur à la fois.

Je vous remercie pour vos commentaires et je vais compléter mon modèle et j'espère que vous me ferez d'autres commentaires constructifs.

[fsmrel]

Bonsoir,


Concernant les "lunettes noires", j’ai bien parcouru le document dont vous faites mention. On y parle d’exclusion, mettant en jeu des "lignes droites" qui ne sont pas vos lunettes. Pour vous, est-ce la même chose ?

Quant à ma remarque relative aux cardinalités 0,N, je n'ai rien dit car là où votre MCD comporte des pointillés, mon imprimante m'a collé des traits pleins.

Pouvez-vous svpl m'expliquer plus en détail votre commentaire suivant :"Au niveau conceptuel, on peut n'avoir qu'une seule entité-type Adresse. Au niveau de base de données, il est préférable d’avoir une entité-type Adresse de société et une entité-type Adresse de personne (à moins de démontrer l’intérêt de la conservation du pot commun).

Je formule l’hypothèse suivante :

Les adresses sont, soit des adresses de sociétés qui sont les fournisseurs ou les clients de l’entreprise, soit celles des personnes de l’entreprise. Autrement dit, l’intersection de l’ensemble des adresses des sociétés et de l’ensemble des adresses des personnes est normalement l’ensemble vide.
En outre, une adresse n’a pas d’existence autonome, elle n’est qu’une propriété multivaluée d’une société, ou d’une personne. Si l’on n’avait qu’au plus une adresse de société, on aurait défini un attribut Adresse au sein de l’entité-type Company. Même principe pour les adresses des personnes. N’ayant pas d’existence autonome, les adresses d’une société disparaissent quand on supprime celle-ci, même chose pour les adresses d’une personne.
Certains attributs de l’entité-type Adresse ne concernent peut-être que les sociétés.

Autrement dit, quel intérêt a-t-on au niveau sémantique à amalgamer ces adresses ?

Au niveau opérationnel, cas de la base de données en production, il est préférable d’avoir deux tables, pour tout ce qui concerne les traitements batch et les tâches de service : il est plus efficace de sauvegarder, réorganiser, recharger, etc. deux tables en parallèle, qu’une seule table dont le volume est en gros la somme des volumes des deux tables. Dans les traitements transactionnels, il est préférable de réduire les concurrences d’accès en cas de mise à jour, et de ne pas avoir des index dont la hauteur des arbres hébergés est inutilement augmentée.
Peut-être peut-on aussi avoir à mettre en œuvre des index qui ne concernent que les adresses des sociétés.
En outre, les adresses d’une société ou d’une personne ont tout intérêt à être regroupées dans la même page physique, pour ne pas multiplier les entrées/sorties qui coûtent infiniment plus cher que les accès mémoire. C’est ce que l’on appelle en DB2 l’effet cluster, absolument déterminant pour la performance des applications. Le problème est que, si l’on n’a qu’une seule table Adresse, il faudra privilégier la table Company au détriment de la table Personne (ou inversement). Il est donc important d’avoir une table Adresse de société et une table Adresse de personne pour privilégier tout le monde. La contrepartie au niveau conceptuel : avoir deux entités-types et utiliser l’identification relative.

Concernant les règlements relatifs aux clients et aux fournisseurs, la réflexion est la même, toutes choses égales par ailleurs.

Au-delà du cas particulier des adresses et des règlements, il est bon de se poser la question dans le cas général.

Cela dit, on pourra me faire le reproche suivant : un MCD n’est pas concerné par des impératifs bassement matériels d’encombrement et de performances.
Je réponds : certes, mais la base données : oui ! Et pour un bon moment... Autant procéder aux aménagements en amont, pour ne pas avoir à tout casser ensuite. Autrement dit, on peut considérer qu’il y a facultativement un MCD "utilisateur" qui n’est pas forcément propre à être dérivée en MLD et nécessairement un MCD "informatique" avec lequel on est astreint à tenir compte de ce qui se passe dans la soute et donc avoir le cas échéant à casser des entités-types et toutes ces sortes de choses.

[Igou77]

Bonsoir fsmrel,

Citation :
Concernant les "lunettes noires", j’ai bien parcouru le document dont vous faites mention. On y parle d’exclusion, mettant en jeu des "lignes droites" qui ne sont pas vos lunettes. Pour vous, est-ce la même chose ?

Oui, c'est exactement la même chose, cela représente l'exclusion : (soit l'un, soit l'autre).

Pour ce qui est du reste, je vais donc faire 2 tables physiques pour les adresses et 2 tables physiques pour les paiements. Mais je ne ferai pas apparaître sur mon modèle pour ne pas l'alourdir, je me contenterai de mettre un commentaire. Mais je comprends tout à fait le raisonnement logique, mais un peu moins celui opérationnel.

Citation:
En outre, les adresses d’une société ou d’une personne ont tout intérêt à être regroupées dans la même page physique, pour ne pas multiplier les entrées/sorties qui coûtent infiniment plus cher que les accès mémoire.
Je ne comprends pas page physique, pouvez-vous m'expliquer ?

Je vous invite également à revoir le modèle avec les attributs.
J'aurais également besoin d'un peu d'inspiration pour nommer la liaison entre Task et engineering work ainsi que celle entre supplier odrer et payement.
Merci pour votre aide.

Bonne soirée et à bientôt

[fsmrel]

Je ne comprends pas page physique, pouvez-vous m'expliquer ?

A un moment donné, il faut bien que les données résident sur le disque. La page représente l’unité d’échange (en général de 512 K à 32 K) entre le disque et la mémoire gérée par le SGBD. Les pages lues depuis le disque filent à destination d’un pool de pages "mémoire" que l’on nomme par exemple buffer pool en DB2 for z/OS. Les pages sont lues et écrites à l’unité (accès sélectif minimal) ou par rafales quand le SGBD a détecté un traitement séquentiel des données. Retenez qu’une lecture / écriture (entrée/sortie) se compte non pas en nanosecondes, mais en millisecondes et c’est là que l’on peut tomber sur des temps d’attente fort préjudiciables, phénomène que j’appelle I/O bound. Il est rageant de voir que l’ordinateur se tourne les pouces, donnant l’effet d’être surdimensionné au niveau CPU, tout cela parce que l’on attend la fin des échanges de pages entre le disque et la mémoire vive allouée au SGBD.

Maintenant, imaginez qu’un client ait passé 100 commandes, à raison de 10 lignes de commande par commande.
Au pire, si les enregistrements sont éparpillés dans des pages sur disque elles-mêmes éloignées les unes des autres, on peut tabler sur 100 X 10 = 1000 lectures pour rassembler toutes les commandes et lignes de commande du client, par exemple dans le cadre d’un traitement batch. A 10 millisecondes l’entrée/sortie, cela représente 10 secondes. Si votre traitement batch doit répéter cela pour tous vos clients, l’addition est salée. En revanche, si les commandes d’un client tiennent dan une dizaine de pages contiguës (même chose pour les lignes de commande), le nombre de lectures sera ramené à une vingtaine, soit environ cinquante fois moins. En plus les lectures ne seront pas à 10 millisecondes, mais par effet balayage séquentiel à 3 ou 4 millisecondes. Je vous laisse calculer les gains correspondant à une réduction plus que sensible de l’effet I/O bound. J’ai pris un cas extrême, donc le ratio moyen ne sera pas de 1 à 50 mais au moins de 1 à 10.

L’optimisation au niveau physique a un impact au niveau conceptuel. En effet, pour que le rendement soit optimal, l’identifiant du client doit être propagé jusqu' aux tables des lignes de commande et des règlements des clients, par le mécanisme de l’identification relative (répercutée au niveau des index et des tables dans le modèle physique) :
Si Customer a pour identifiant {CustomerId}, Customer Order doit avoir pour identifiant {CustomerId, OrderId}, Customer Order Detail doit avoir pour identifiant {CustomerId, OrderId, DetailId} (ou {CustomerId, DetailId}, au choix). OrderId n’est pas un identifiant absolu, ses valeurs sont des entiers incrémentés de 1 en 1, qui repartent à 1 pour chaque première commande de chaque client. Le principe s’applique à DetailId, mutatis mutandis.

Je suis désolé de vous inciter à impacter le conceptuel par le physique, mais dans l’état actuel des technologies, c’est le prix à payer pour traiter les données au plus vite.

Au fait, votre outil permet-il de mettre en œuvre l’identification relative ?

Je vous invite également à revoir le modèle avec les attributs.

Customer Order Details ne fait pas mention d’une quantité commandée ? On marche à l’unité ? (Même chose pour la facture). Il n’y a pas de TVA ? Etc.

Les entités-types Customer et Supplier sont dépourvues de propriétés naturelles : au niveau tabulaire, Customer Order et Supplier Order seront directement branchées sur la table Company.

Sur votre modèle, les liens entre Address et Company sont de type M:1 (Mandatory to Mandatory) or certaines adresses sont celles de personnes : ça manque de pointillés (Mandatory to Optional).

De même, si j’ai bien compris la légende du document dont vous faites mention, les liens entre Payment et Customer Order devraient être M:1 (Optional to Optional), puisque certains règlements concernent seulement les factures, or j’ai comme l’impression que vous avez modélisé Mandatory to Optional, mais ça n’est qu’une impression...

[Igou77]

Bonsoir fsmrel,

encore une fois merci pour vos explications, gentillement, mais surement je commence à comprendre.

Je vais reporter vos commentaires sur mon MCD.

En ce qui concerne l'identification relative, je pense que ce n'est pas aussi clair que dans Merise (si j'ai bien suivi vos explications dans d'autres discussions) avec les parenthèses, mais je pense que l'exemple ci-dessous exprime une identification relative.

Bonne soirée et à bientôt

[fsmrel]

je pense que l'exemple ci-dessous exprime une identification relative

Il n'est pas interdit de le penser, mais ça n’est pas concluant. J'aimerais déjà voir le résultat de la dérivation au format SQL par l'outil. Pour le moment, on peut simplement penser que Détail commande est une association entre Commande et Article. Il n’y a vraiment identification relative stricto sensu que lorsque, après dérivation, au niveau MLD la clé de Détail Commande comporte le (ou les) attribut(s) composant la clé de Commande mais pas ceux qui composent la clé de Article, qui ne font alors que l’objet d’une clé étrangère.

Je peux donner l'impression de pinailler, mais il s'agit d'une fonctionnalité essentielle, cruciale.