Discussion :

[fsmrel]

Bonsoir,

J’ai noté que vous n’aimiez pas trop les clés multi-attributs, notamment parce que les jointures vous paraissaient bien lourdes ...
Avec la clé primaire de la table Livraison, on n’en est pas loin... Mais un DBA se fera un plaisir de créer les vues occultant tout ça.

Dans votre exemple, je serai curieux d'avoir un aperçu de ces vues ?

Pour que l’on soit en phase, je joins le MCD (l’AGL est Power AMC) :





Ainsi que le MLD dérivé par Power AMC :




Et les instructions de création des tables (toujours avec Power AMC) :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
/*==============================================================*/
/* Table : Client                                               */
/*==============================================================*/
CREATE TABLE Client (
   ClientId             INT                  NOT NULL,
   ClientNom            VARCHAR(48)          NOT NULL,
   ClientSiret          CHAR(14)             NOT NULL,
   CONSTRAINT Client_PK PRIMARY KEY  (ClientId),
   CONSTRAINT Client_AK1 UNIQUE (ClientSiret)
) ;
/*==============================================================*/
/* Table : Camion                                               */
/*==============================================================*/
CREATE TABLE Camion (
   CamionId             INT                  NOT NULL,
   CamionImmat          VARCHAR(12)          NOT NULL,
   CamionStatut         CHAR(2)              NOT NULL,
   CONSTRAINT Camion_PK PRIMARY KEY  (CamionId),
   CONSTRAINT Camion_AK1 UNIQUE (CamionImmat)
) ;
/*==============================================================*/
/* Table : Article                                              */
/*==============================================================*/
CREATE TABLE Article (
   ArticleId            INT                  NOT NULL,
   ArticleNom           VARCHAR(48)          NOT NULL,
   CONSTRAINT Article_PK PRIMARY KEY  (ArticleId)
) ;
/*==============================================================*/
/* Table : Commande                                             */
/*==============================================================*/
CREATE TABLE Commande (
   ClientId             INT                  NOT NULL,
   CommandeId           SMALLINT             NOT NULL,
   CommandeNo           CHAR(12)             NOT NULL,
   CommandeDate         CHAR(10)             NOT NULL,
   CommandeStatut       CHAR(2)              NOT NULL,
   CONSTRAINT Commande_PK PRIMARY KEY  (ClientId, CommandeId),
   CONSTRAINT Commande_AK1 UNIQUE (CommandeNo),
   CONSTRAINT Commande_Client_FK FOREIGN KEY (ClientId)
      REFERENCES Client (ClientId)
) ;
/*==============================================================*/
/* Table : LigneCommande                                        */
/*==============================================================*/
CREATE TABLE LigneCommande (
   ClientId             INT                  NOT NULL,
   CommandeId           SMALLINT             NOT NULL,
   LigneCommandeId      SMALLINT             NOT NULL,
   ArticleId            INT                  NOT NULL,
   Quantite             INT                  NOT NULL,
   CONSTRAINT LigneCommande_PK PRIMARY KEY  (ClientId, CommandeId, LigneCommandeId),
   CONSTRAINT LigneCommande_Commande_FK FOREIGN KEY (ClientId, CommandeId)
      REFERENCES Commande (ClientId, CommandeId)
          ON DELETE CASCADE,
   CONSTRAINT LigneCommande_Article_FK FOREIGN KEY (ArticleId)
      REFERENCES Article (ArticleId)
) ;
/*==============================================================*/
/* Table : Engagement                                           */
/*==============================================================*/
CREATE TABLE Engagement (
   ClientId             INT                  NOT NULL,
   CommandeId           SMALLINT             NOT NULL,
   LigneCommandeId      SMALLINT             NOT NULL,
   EngagementId         SMALLINT             NOT NULL,
   EngagementType       CHAR(2)              NOT NULL,
   EngagementQte        INT                  NOT NULL,
   CONSTRAINT Engagement_PK PRIMARY KEY  (ClientId, CommandeId, LigneCommandeId, EngagementId),
   CONSTRAINT Engagement_LigneCommande_FK FOREIGN KEY (ClientId, CommandeId, LigneCommandeId)
      REFERENCES Lignecommande (ClientId, CommandeId, LigneCommandeId)
          ON DELETE CASCADE
) ;
/*==============================================================*/
/* Table : Livraison                                            */
/*==============================================================*/
CREATE TABLE Livraison (
   ClientId             INT                  NOT NULL,
   CommandeId           SMALLINT             NOT NULL,
   LigneCommandeId      SMALLINT             NOT NULL,
   EngagementId         SMALLINT             NOT NULL,
   LivraisonId          SMALLINT             NOT NULL,
   CamionId             INT                  NOT NULL,
   LivraisonDate        CHAR(10)             NOT NULL,
   LivraisonStatut      CHAR(2)              NOT NULL,
   CONSTRAINT Livraison_PK PRIMARY KEY  (ClientId, CommandeId, LigneCommandeId, EngagementId, LivraisonId),
   CONSTRAINT Livraison_Engagement_FK FOREIGN KEY (ClientId, CommandeId, LigneCommandeId, EngagementId)
      REFERENCES Engagement (ClientId, CommandeId, LigneCommandeId, EngagementId)
          ON DELETE CASCADE,
   CONSTRAINT Livraison_Camion_FK FOREIGN KEY (CamionId)
      REFERENCES Camion (CamionId)
) ;

Supposons maintenant que le DBA ait créé la vue qui permet de tout savoir sur les livraisons chez les clients :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
CREATE VIEW Livraison_V (Client, Siret, LivraisonStatut, LivraisonDate, CamionImmat)
 AS
    SELECT  a.ClientNom, a.ClientSiret, b.LivraisonStatut, b.LivraisonDate, c.CamionImmat
    FROM    Client AS a 
                        JOIN Livraison AS b
               ON a.ClientId = b.ClientId
                        JOIN Camion AS c
               ON b.CamionId = c.CamionId
;

Pour savoir quels sont les camions qui livreront le client Tartempion (de Siret 12345678901234) pour qui les livraisons ont le statut Y3 :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
SELECT  Client, CamionImmat
FROM    Livraison_V
WHERE   Siret = '12345678901234'
  AND   LivraisonStatut = 'Y3' ;

Maintenant, si le DBA doit faire participer toutes les tables, parce que l’on n’a pas utilisé l’identification relative, la vue ressemblerait à ceci :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
CREATE VIEW Livraison_V (Client, Siret, LivraisonStatut, LivraisonDate, CamionImmat)
 AS
    SELECT  a.ClientNom, a.ClientSiret, e.LivraisonStatut, e.LivraisonDate, f.CamionImmat
    FROM    Client AS a 
                        JOIN Commande AS b
               ON a.ClientId = b.ClientId
                        JOIN LigneCommande AS c
               ON b.CommandeId = c.CommandeId
                        JOIN Engagement AS d
               ON c.LigneCommandeId = d.LigneCommandeId
                        JOIN Livraison AS e
               ON d.EngagementId = e.EngagementId
                        JOIN Camion AS f
               ON e.CamionId = f.CamionId ;

_

[fsmrel]

Bonsoir,

j'aimerais François, que vous expliquiez cette partie de votre dernier message :

Je m’arrête un moment pour traiter de l’organisation de l’index « primaire » la table Client. Cet index a pour clé {ClientId}. Supposons que l’on soit dans le contexte d’une saisie de commandes intense. Si le prototype montre que plus les utilisateurs entrent en concurrence (disons aux heures de pointe, après la pause café-cigarette), plus les phénomènes de contention se manifestent, alors il faudra hacher ClientId plutôt que le valoriser séquentiellement. Par exemple, si pour le dix-millième client, la procédure de hachage fournit la valeur '5246901' pour la clé {ClientId} et la valeur '314' pour le client suivant, il est très probable que ces clients se retrouveront dans des pages (enregistrements) physiques éloignées (table space et index), d’où élimination des contentions. J’ai eu à traiter ce genre de problème pour un de mes clients, qui par la suite a commercialisé son application : très logiquement, plus la base de données de ses propres clients était réduite en volume et plus les problèmes de contention refaisaient surface...

Cela signifie t-il que :
- si des clients sont créés en série lors d'une période courte de temps,
- et si les clients sont identifiés séquentiellement (identifiant auto-incrémenté),
la construction de l'index fera que c'est potentiellement la même page d'index qui sera mise à jour et que cela va créer une sorte de bouchon comme aux péages des autoroutes du sud le premier week-end de juillet, chaque créateur de client devant "attendre" que cette page soit disponible pour que son client puisse être totalement enregistré par le SGBD ?

Dans le principe, chaque créateur de client devra effectivement « attendre » que la page dans laquelle il veut écrire soit disponible pour que le client puisse être enregistré par le SGBD. Cela fait partie des propriétés ACID (Atomicity, Correctness, Isolation, Durability) des transactions. Je vous renvoie au chapitre 16 « Concurrency » de l’ouvrage de Chris Date à ce sujet (An Introduction to Database Systems. La lecture de ce chapitre est indispensable pour vraiment comprendre les enjeux.

En fait, dans le cas qui nous intéresse, ce ne sont pas les clients qui poseront des problèmes, on n’en crée pas des rafales à la seconde. Ce sont plutôt les commandes, lignes de commandes, etc. qui sont à surveiller, dès lors que les lignes correspondantes sont auto-incrémentées dans l'absolu.

Les problèmes de contention ont beaucoup fait transpirer les éditeurs de SGBD. Pour parler un peu de technique, je me situe à nouveau dans un contexte DB2, SGBD qui doit beaucoup ès matière à Jim Gray (Turing Award en 1998), du temps où il était chez IBM. Concernant l’index, il fut une époque où effectivement ça bouchonnait ferme, à cause de bons et gros verrous. Pour se donner du mou, on pouvait ne verrouiller qu'une partie seulement des pages index (par exemple un seizième de page, soit 256 octets au lieu de 4 KB). On parlait alors d’index de type 1. Au milieu des années quatre-vingt-dix, pour améliorer les choses, IBM proposa un nouveau type d’index, pour lequel DB2 posait des « loquets » d’une durée de vie beaucoup plus réduite que les gros verrous. Je cite (Locking in DB2 for MVS/ESA Environment) :

« Probably the most common locking problem with Type 1 indexes is the contention on the last leaf page because of an ascending key. This problem is practically eliminated with Type 2 indexes: with isolation CS, the leaf pages are only latched, and not locked. The duration of a latch is likely to be less than one millisecond. Thus, it would take more than 100 inserting transactions per second to make the last leaf page hot, that is, the leaf page is locked for more than 10% of the time. »

(isolation CS veut dire Cursor Stability, c'est-à-dire qu’une page est déverrouillée dès qu’on la quitte, sous-entendu : on n’a pas l’intention d’y revenir).

Évidemment, le système de verrouillage s’est raffiné depuis. Disons qu’avec DB2, on n’a pas trop de soucis avec les index, mais il reste le cas des pages de données. Là encore, du temps de l’époque héroïque, le granule le plus fin de verrouillage était la page, puis sous la pression des utilisateurs, IBM offrit la possibilité de verrouiller au niveau de la ligne : it was a good news. The bad news : en cas de forte activité concurrentielle, des piles et des piles de verrous à gérer par DB2, et bien des DBA ont fait machine arrière (si un tas de pages contenant chacune 250 lignes sont en cours de verrouillage pour cause de mise à jour, ça finit par coûter). Mais vu le nombre de paramètres permettant d’améliorer les choses, ce qui vaut chez l’un ne vaut peut-être pas chez l’autre : vous pourriez demander l’avis de Luc Orient.

En tout cas, des transactions peuvent effectivement finir en « Time out ». Le risque est d’autant plus grand que le nombre de transactions concurrentes est élevé (quand deux cents utilisateurs s’acharnent en même temps à provoquer des inserts dans la même table, ça peut craindre), Dans un contexte batch, on a l’exclusivité des tables et l’on peut auto-incrémenter à tout va. Dans le cas du transactionnel, je pense qu’un prototypage s’impose, à moins que votre SGBD ne pose pas les problèmes que j’ai évoqués. Pour ma part, je frémis en pensant aux risques (clauses de pénalité) que j'aurais fait prendre à mon entreprise si je n'avais pas été vigilant.

[wafiwafi]

Bonjour fsmrel
Je ne suis pas un spécialiste des bases de données mais j'arrive à te comprendre et c'est agréable de lire tes citations.
Néanmoins, j'ai une question simple à te poser malgré tout ce que tu as dis et qui reflète ta position claire sur le sujet.
N'as tu jamais personnellement pensé à éviter un choix de solutions lors de ton MCD parce que tu sais d'avance qu'il te posera problème par la suite (implémentation)?
(NB: l'exemple qui a suscité le débat est juste un cas particulier. Ne généralisons pas).

ta réponse m'intéresse surtout que tu dois avoir une vue beaucoup plus élargie tant à la conception qu'aux solutions d'implémentation.

[Luc Orient]

... Dans le principe, chaque créateur de client devra effectivement « attendre » que la page dans laquelle il veut écrire soit disponible pour que le client puisse être enregistré par le SGBD.

Désolé de vous contredire très cher collégue, mais il me semble que dans le cas d'un ordre INSERT, et je parle de DB2 z/OS bien sûr, le SGBD ne vas pas attendre que la page se libère, mais va passer à une autre page voisine mais disponible, quitte à accepter un certain taux de désorganisation. Bien entendu, c'est un cas différent de l'UPDATE ou là on est bien obligé d'attendre que la page qui contient la ligne soit libérée.

Si le taux d'insertion est particulièrement élevé, on peut même créer ou modifier le TABLESPACE en MEMBER CLUSTER ( toujours DB2 z/OS ) et là DB2 ira écrire là où il y a de la place.

MEMBER CLUSTER
Specifies that data inserted by the INSERT statement is not clustered by the implicit clustering index (the first index) or the explicit clustering index. Instead, DB2 chooses where to locate the data in the table space based on available space

Plan for batch inserts: If your application does sequential batch insertions, excessive contention on the space map pages for the table space can occur. This problem is especially apparent in data sharing, where contention on the space map means the added overhead of page P-lock negotiation. For these types of applications, consider using the MEMBER CLUSTER option of CREATE TABLESPACE. This option causes DB2 to disregard the clustering index (or implicit clustering index) when assigning space for the SQL INSERT statement

[fsmrel]

Bonsoir,

Dans le principe, chaque créateur de client devra effectivement « attendre » que la page dans laquelle il veut écrire soit disponible pour que le client puisse être enregistré par le SGBD.

Désolé de vous contredire très cher collégue, mais il me semble que dans le cas d'un ordre INSERT, et je parle de DB2 z/OS bien sûr, le SGBD ne vas pas attendre que la page se libère, mais va passer à une autre page voisine mais disponible, quitte à accepter un certain taux de désorganisation. Bien entendu, c'est un cas différent de l'UPDATE ou là on est bien obligé d'attendre que la page qui contient la ligne soit libérée.

Vous avez tout à fait raison et je suis navré de n’avoir pas été assez précis. En fait, je ne me situais pas dans le cas particulier du SGBD qui nous est cher, mais dans le cas général (« dans le principe » comme je disais). Néanmoins J’aurais dû ensuite apporter la précision dont vous faites mention, car il y a fort longtemps que — fort opportunément — DB2 procède ainsi. Je n’ai pas retrouvé mes vieux manuels (je me souviens quand même qu’en V1.2, — il y a 23 ans... — DB2 cherchait à insérer dans une autre page si la page cible était verrouillée), mais déjà dans le Diagnosis de la V4, on pouvait lire par exemple :

« Locks for Inserts on Segmented Table Spaces : After a candidate page is found, DB2 conditionally requests an exclusive, commit duration page lock. If the lock is not immediately available, DB2 looks for another candidate page. »
(DATABASE 2 for MVS/ESA Version 4, Diagnosis Guide and Reference - page 282)

Encore désolé. Je crois qu'il est temps que je repasse à IDMS (ou à Total)...

[fsmrel]

Bonsoir,

Je ne suis pas un spécialiste des bases de données mais j'arrive à te comprendre et c'est agréable de lire tes citations.
Néanmoins, j'ai une question simple à te poser malgré tout ce que tu as dis et qui reflète ta position claire sur le sujet.
N'as tu jamais personnellement pensé à éviter un choix de solutions lors de ton MCD parce que tu sais d'avance qu'il te posera problème par la suite (implémentation)?
(NB: l'exemple qui a suscité le débat est juste un cas particulier. Ne généralisons pas).

ta réponse m'intéresse surtout que tu dois avoir une vue beaucoup plus élargie tant à la conception qu'aux solutions d'implémentation.

Merci pou la remarque au sujet des citations. Certaines peuvent être hermétiques (cf. mon précédent message), mais n’y prêtez pas trop attention, car plus on descend dans la soute, plus ça devient glauque...

Il est évident que j’ai appris à identifier les choses à ne pas faire en modélisation. Quand on a de très nombreuses années d’expérience des bases de données dans tous les secteurs, ça serait quand même malheureux qu’il en fut autrement...

Je ne retiens donc que les solutions qui me paraissent viables, éprouvées, mais je sais que je ne suis jamais à l’abri d’une erreur d’appréciation : c’est pourquoi je tiens à bâtir un prototype pour vérifier que ce que je produis fonctionne (au moins pour les parties sensibles) et en ayant procédé ainsi, à chaque fois bien m’en a pris. Par exemple, telle certitude que j’avais acquise dans les Bouches-du-Rhône ne valait plus dans l’Eure, et tout était à refaire parce qu’un paramètre changeait, alors que le sujet était le même. Comme disait le Nicolas : « Vingt fois sur le métier remettez votre ouvrage... » Ou le Blaise : « Vérité en deçà des Pyrénées, erreur au-delà ».

Je répète que j’ai passé mon temps à engager mon entreprise en ce qui concerne les performances : je n’avais pas le droit à l’erreur. Et j’ai appris sur le terrain à voir l’impact d’une modélisation approximative, en arrivant en catastrophe chez tel ou tel de mes clients pour réparer les dégâts provoqués par l’incompétence de prétendus concepteurs. Quand vous voyez que la durée d’un certain traitement batch quotidien est de 240 heures, alors qu’elle avait été initialement prévue à 8 heures, vous n’avez qu’une envie, aller vérifier le MCD (à défaut de distribuer des paires de claques). Vérification que j'ai effectuée dans ce cas très particulier : c’était accablant (après que je l’ai eu cuisiné pendant une journée, l’auteur du méfait finit par avouer : « J’aurais dû me faire accompagner d'un technicien » (sic)). Des comme ça, j’en ai des pelletées et vous comprendrez pourquoi je suis chatouilleux et vigilant.

Quoi qu’il en soit, un MCD peut paraître irréprochable, le MLD itou, on m’appelle encore pour sauver tel traitement qui devrait durer 8 heures et que je diagnostique comme en ayant encore pour quinze jours. Cherchez l’I/O bound (cf. un de mes précédents messages)...

[benwit]

Quand vous voyez que la durée d’un certain traitement batch quotidien est de 240 heures, alors qu’elle avait été initialement prévue à 8 heures, vous n’avez qu’une envie, aller vérifier le MCD (à défaut de distribuer des paires de claques). Vérification que j'ai effectuée dans ce cas très particulier : c’était accablant (après que je l’ai eu cuisiné pendant une journée, l’auteur du méfait finit par avouer : « J’aurais dû me faire accompagner d'un technicien »

Juste par curiosité et pour voir le ratio, ce batch de 240 heures a été ramené à combien par l'homme de l'art ?

[fsmrel]

A l’époque, j’avais pas mal de fers au feu et je ne me suis pas occupé de la remise en état. Mais cela a occupé deux ingénieurs pendant quelques mois, pour arriver à moins de 8 heures.

Comme disait Eluard « Le passé est un oeuf cassé, l'avenir est un oeuf couvé». On a cassé les 240 heures, mais nos deux lascars ont dû couver un bon moment pour que ce qui avait été prévu soit enfin réalisé.

[wafiwafi]

J'en conclu que les règles d'or existent mais liées à des contextes; On ne peut donc les généraliser. Dommage!!!
Il y a tout de même une que je retiendrai, c'est de ne valider mon MCD qu'après l'avis de l'implanteur.

Mais alors, si l'implanteur est moi même, j'aurai tendance à dire que pendant l'étape de la conception, je ne pourrais pas m'empêcher à me concerter avec moi même et donc anticiper des problèmes d'implémentation. Je vais forcément établir une relation.

En fait, je ne sais plus où j'en suis; je vais plutôt attendre des réactions et peu être je trouverai la lumière.
Disons qu'avec tout ce qui a été dit, je ne dois pas être loin.

En tout cas, j'ai appris beaucoup de choses et je remercie tous les intervenants.

[B.AF]

La seule vraie règle d'or c'est :
- De comprendre et de connaitre exhaustivement le métier; c'est une condition nécessaire à l'abstraction et à tout travail de modélisation
C'est "con comme la lune", mais je n'ai jamais vu un modéle intelligent sortir d'une vision technologique.
- De chercher le niveau de dépendance minimal entre les différents éléments
- De maitriser les récursivités
- De toujours s'appuyer sur un expert technique pour vérifier sa qualité technique
- De gérer dès le commencement les problèmatiques...
De versioning des données (audit, log)
D'audit des événements sur les données
De visualisation (reconstruction des données)


Il est surtout inutile de commencer par des considérations techniques.

[wafiwafi]

mais je n'ai jamais vu un modéle intelligent sortir d'une vision technologique.

D'après ta citation, il faut d'abord et surtout penser métier, métier et métier .
En rendant compte de façon complète du métier, on pourrait ensuite établir une corrélation avec un avis technique d'après ta citation :

De toujours s'appuyer sur un expert technique pour vérifier sa qualité technique

Dans presque toutes les interventions, le modèle conceptuel est maintenant sans doute lié à l'implémentation.

[B.AF]

D'après ta citation, il faut d'abord et surtout penser métier, métier et métier .
En rendant compte de façon complète du métier, on pourrait ensuite établir une corrélation avec un avis technique d'après ta citation :

Dans presque toutes les interventions, le modèle conceptuel est maintenant sans doute lié à l'implémentation.

Ben fondamentalement, je ne vois pas comment fournir de la conception et de l'abstraction sur un sujet que je ne connais pas...Par contre, je peux faire des éléments SQL ou des objets aussi qui n'ont aucune utilité métier, mais seront techniquement parfaitement viables.

Combien de développeur on voit encore aujourd'hui créer des tables TBL_PERSONNE, TBL_CLIENT , TBL_CONTACT,etc,etc...Ce qui est d'une débilité absolue !
Et après de créer moults relations en pensant que c'est la panacée absolue du MCD

Je ne veux vexer personne, mais les MCD mis en exemples dans ce post sont d'une naïveté effarante et loin du niveau de ce qui fait une application d'entreprise.

Aucun audit, aucune logique évenementielle, aucune logique multilingue...

Je veux aussi dire par là qu'un jour j'ai bossé sur un truc simple :
Appli client / serveur, tout en SP, gui en Java. Bref, du basic.
On a demandé à traduire les items, sachant que le dictionnaire devait être défini par l'utilisateur.
Le produit contenait 350 tables. Le super concepteur a simplement doublé.
Pour chaque table, elle disposait de son équivalent en libéllé est en traduction.

Alors qu'il suffisait d'une table pour gérer l'ensemble des traductions, chose démontrée plus tard.
Moralité, 2 mois de perdus, 250 tables pour rien et un problème simple pas résolu.

A cause d'un simple approche techno qui pensait qu'il suffisait de faire ça et de générer du code.

C'est un travail de traduction : si tu veux dire quelquechose en allemand, la seule façon qu'un traducteur te mette dans la bonne voie, c'est d'être capable de lui donner un texte prècis à traduire.

Le MCD c'est pareil. Le sql c'est un finalité, mais absolument pas une fin. C'est une hypothése technologique qui ne garanti pas l'adéquation du modèle avec le business concerné.

[wafiwafi]

Bonjour,
En lisant ces lignes, Tu viens de me confirmer l'hypothèse qui m'a poussé à poster; l'existence de règle d'or; je t'en remercie.
L'exemple que tu as donné et fortement intéressant et qui représente la preuve indiscutable de la liaison conception / implémentation. Tu as parlé de finalité et non de fin; c'est superbement exposé. En tout cas, je parle pour moi et du sentiment que je dois creuser pour remplir davantage mon dictionnaire de règles me permettant d'éviter les erreurs. Et oui, à travers cette discussion, j'en ai relevé peut être pas des règles mais surement quelques points d'or.
Merci à vous

[Luc Orient]

...
Aucun audit, aucune logique évenementielle, aucune logique multilingue...

Et c'est quoi concrètement une logique événementielle appliquée à un MCD ?

[fsmrel]

Bonsoir,

La seule vraie règle d'or c'est :
De comprendre et de connaitre exhaustivement le métier; c'est une condition nécessaire à l'abstraction et à tout travail de modélisation

S’il s’agit de connaître le métier de la conduite de projets ou de celui de la modélisation, c’est la moindre des choses quand on entreprend les travaux de modélisation.
S’il s’agit de comprendre le métier de l’utilisateur, oui, c’est une condition nécessaire mais non suffisante. Par contre, connaître exhaustivement ce métier, est généralement utopique. Il est de loin préférable que le concepteur sache renifler, s’assurer de la complétude et de la pertinence des règles de gestion des données établies en relation avec la Maîtrise d’œuvre. Au final, produire un dossier de conception détaillée digne de nom (Verba volant, scripta manent). Je parle en connaissance de cause.

C'est "con comme la lune", mais je n'ai jamais vu un modéle intelligent sortir d'une vision technologique.

Qu’entendez-vous par « modèle intelligent » ? « vision technologique » ?
Par exemple, l’utilisation de l’identification relative est-elle visée ? La normalisation des données ? L’agrégation des données ? L’héritage des données ? Les contraintes entre les données ? (Liste non exhaustive).

La seule vraie règle d'or c'est :
- De chercher le niveau de dépendance minimal entre les différents éléments

Obscur. Merci de définir avec précision les concepts de « dépendance minimale » et d’ « élément », puis d'établir la relation entre ces concepts.

- De maitriser les récursivités

Je suppose que vous voulez dire que le concepteur doit savoir ce qu’est une association-type réflexive : un point parmi bien d’autres. Si vous parlez d’autre chose merci de préciser ce dont il s'agit. Par ailleurs, puisque vous en parlez au pluriel, veuillez décliner les différentes « récursivités » auxquelles vous faites allusion, ça pourrait intéresser pas mal de monde.

- De toujours s'appuyer sur un expert technique pour vérifier sa qualité technique

Vague. Un expert « technique » en quoi ? Que signifie « qualité technique » ?

- De gérer dès le commencement les problèmatiques...
De versioning des données (audit, log)

Au niveau du MCD ? Justifiez.

[...] D'audit des événements sur les données.

Au niveau du MCD ? Justifiez.

De visualisation (reconstruction des données)

Plaît-il ?

Il est surtout inutile de commencer par des considérations techniques.

Considérations techniques de quel ordre ? Comment représenter les entités-types et leurs relations ? Merci de donner des exemples.

Combien de développeur on voit encore aujourd'hui créer des tables TBL_PERSONNE, TBL_CLIENT , TBL_CONTACT,etc,etc...Ce qui est d'une débilité absolue !

Le rôle des développeurs est de développer, pas de modéliser les données, chacun son métier. Est-ce bien le message que vous voulez faire passer ?

Je ne veux vexer personne, mais les MCD mis en exemples dans ce post sont d'une naïveté effarante et loin du niveau de ce qui fait une application d'entreprise.

Apprenez que sur ce forum il ne s'agit pas d'expertiser des modèles d’entreprise complets et compliqués à souhait, mais de répondre avec des exemples simples aux interrogations de ceux qui cherchent à comprendre ou approfondir tel ou tel aspect de la modélisation des données.

Cela dit, considérons mon exemple des livraisons : il est peut-être d'une naïveté effarante, mais il est extrait d’un cas réel, développé en France pour un leader mondial dans sa partie. La modélisation a été expertisée à tous les étages (MCD, MLD, MPD). L’application a été mise en production (il y a vingt ans), puis avoir fait ses preuves, a été promue comme référentiel européen de l’entreprise, puis comme référentiel mondial. Et ça tourne comme une horloge.

Le MCD c'est pareil. Le sql c'est un finalité, mais absolument pas une fin. C'est une hypothése technologique qui ne garanti pas l'adéquation du modèle avec le business concerné.

Qui a dit le contraire ?

Veuillez noter en passant que l’expression « Le sql c'est un finalité mais absolument pas une fin » est ambiguë, voire contradictoire et nécessite donc des explications. Quoi qu'il en soit, SQL est un langage de description des structures des données (le Quoi), des contraintes d’intégrité (encore le Quoi) et de manipulation des données (le Comment), selon une approche ensembliste et non pas procédurale. Ce langage (normalisé ISO) est un moyen de concrétiser par le truchement d’une base de données (qui se situe dans le temps et dans l’espace) l’abstraction exprimée par le MCD (le Quoi à nouveau), abstraction qui ne se situe ni dans le temps ni dans l’espace.

Conclusion : Je vous conseille de lire de l'ouvrage de D. Nanci et B. Espinasse Ingénierie des systèmes d'information Merise, ou celui de Michel Diviné, Parlez-vous Merise ?, ouvrages épatants pour apprendre à réaliser des modèles conceptuels de données.


De grâce, justifiez et commentez vos propos qui sont le plus souvent bien flous.

[hegros]

Voilà quelques règles d'or pour moi


-Ne jamais fournir un MCD sans les règles de gestion et un dictionnaire de données
-Modélisez en couvrant l'aspect offre, tarification et tiers
-Ne pas mettre de clé primaire auto-incrémenté comme #id_voiture pour une entité voiture
-Évitez les relations ternaires et plus, ramenez toujours à une relation binaire
-Prendre en compte uniquement la partie maximum pour les cardinalités
-Respectez les formes normales
-Nommez toujours les associations entre entité




Par rapport au lien entre la conception et l'implémentation il y a un risque de prendre en considération trop tôt la technique dans le modèle. Je préférerais dans ce cas avoir 2 modèles bien distincts car ces considérations pour moi interviennent plus tard dans le MPD ou MLD

-Modèle conceptuel épuré de toute considération technique, c'est à dire juste le métiers
-Modèle conceptuel qui prends en considération la technique pour l'optimisation


Pourquoi ? Tout simplement parce que vous ne savez pas qui va le lire. Un modèle qui prends en compte la technique va forcément être plus difficilement lisible par un fonctionnel et un modèle l'ignorant risque de ne pas être pertinent pour un technicien. Tandis que le modèle épuré de la technique fonctionnel et technicien y trouve leur compte aussi ils peuvent plus facilement communiquer

[f-leb]

bonsoir,

je suis un peu étonné de voir ces "règles d'or pour concevoir un bon MCD"

-Ne pas mettre de clé primaire auto-incrémenté comme #id_voiture pour une entité voiture

Déjà je ne suis pas sûr que parler de "clé primaire auto-incrémenté" soit pertinent au niveau conceptuel où on parle plutôt d'identifiant (à confirmer).
Sinon, vous préconisez quoi comme identifiant pour une voiture ? N° immatriculation? N° de châssis? autre chose ?

-Évitez les relations ternaires et plus, ramenez toujours à une relation binaire

j'évite les ternaires si les règles de gestion le permettent:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
CONTACT----0,n----exercer----0,n-----FONCTION
                     |
                    0,n
                     |
                 ORGANISME

si un contact peut exercer la même fonction dans plusieurs organismes
si une fonction dans un organisme peut être exercée par plusieurs contacts
si un contact peut avoir plusieurs fonctions dans un même organisme,

je ne vois pas comment je pourrais renoncer à la ternaire.

-Prendre en compte uniquement la partie maximum pour les cardinalités

EMPLOYE---0,n---rémunérer---1,1---ELEMENTPAYE

règle de gestion: un employé peut travailler "au black"

[hegros]

je suis un peu étonné de voir ces "règles d'or pour concevoir un bon MCD"

Cela ressemble à ce que l'on appelle plus couramment les bonnes pratiques que cela existe pour un MCD n'a rien d'étonnant.

Déjà je ne suis pas sûr que parler de "clé primaire auto-incrémenté" soit pertinent au niveau conceptuel où on parle plutôt d'identifiant (à confirmer).
Sinon, vous préconisez quoi comme identifiant pour une voiture ? N° immatriculation? N° de châssis? autre chose ?

On voit beaucoup de MCD avec dedans un attribut "numéro auto-incrémenté" ou identifiant automatique peu importe comment on l'appelle, c'est courant, ce que je dis c'est que c'est inutile dans le MCD en plus d'être complètement superficiel. Il faut soit avoir une véritable clefs primaire soit ne pas en mettre du tout. Rajoutez des #id_machin superficiel n'a rien de pertinent dans le modèle.

Pour ta question, s'il n'y en a pas pour voiture alors dans le mcd je n'en mets pas tout simplement par contre je rajoute la clef automatique dans le MLD ou le MPD.

j'évite les ternaires si les règles de gestion le permettent:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
CONTACT----0,n----exercer----0,n-----FONCTION
                     |
                    0,n
                     |
                 ORGANISME

si un contact peut exercer la même fonction dans plusieurs organismes
si une fonction dans un organisme peut être exercée par plusieurs contacts
si un contact peut avoir plusieurs fonctions dans un même organisme,
je ne vois pas comment je pourrais renoncer à la ternaire.

Il y a toujours quelques cas exceptionnel qui font qu'il n'y a pas d'autres choix cependant c'est une question de conception en passant par des entités de gestion on devrait pouvoir éviter les ternaires et le plus souvent on arrive à les remplacer en binaire, ton cas n'est donc pas non plus une généralité et ce qu'on retrouve le plus.

EMPLOYE---0,n---rémunérer---1,1---ELEMENTPAYE

règle de gestion: un employé peut travailler "au black"

[/QUOTE]

Je ne vois pas où tu veux en venir.

[CinePhil]

On voit beaucoup de MCD avec dedans un attribut "numéro auto-incrémenté" ou identifiant automatique peu importe comment on l'appelle, c'est courant, ce que je dis c'est que c'est inutile dans le MCD en plus d'être complètement superficiel. Il faut soit avoir une véritable clefs primaire soit ne pas en mettre du tout. Rajoutez des #id_machin superficiel n'a rien de pertinent dans le modèle.

Pour ta question, s'il n'y en a pas pour voiture alors dans le mcd je n'en mets pas tout simplement par contre je rajoute la clef automatique dans le MLD ou le MPD.

Comme il a été dit plus haut je crois dans la discussion, si on fait le MCD à l'aide d'un logiciel de modélisation, et si, comme tu le préconises, il vaut mieux ne pas mettre de clé à une entité plutôt qu'une mauvaise clé (numéro d'immatriculation d'une voiture), alors quand on va demander au logiciel de modélisation de générer le MLD, il va sans doute hurler.

Donc moi je mets systématiquement des identifiants anonymes du genre 'id' aux entités dès le MCD.
Et je vais même plus loin puisque, toujours dans le cas de l'utilisation du logiciel de modélisation, celui-ci générera aussi les requêtes SQL pour fabriquer physiquement la base de données alors autant régler au plus vite le typage des attributs qui deviendront des colonnes de tables.
Ce qui est fait n'est plus à faire.
Ceci n'empèche pas bien sûr de vérifier la qualité du MCD puis du MLD généré avant d'implémenter la BDD.

[hegros]

Ce sont des préoccupations techniques et une fois de plus c'est un modèle qui s'adresse dans ce cas plus à des techniciens, normalement les outils permettent de masquer les attributs car cela dépend avec qui le MCD est réalisé ou à qui il est présenté.


Imagine toi que demain ton patron te demande de présenter le résultat de ta conception pour une étude d'un besoin ou d'un système existant : tu choisis la modélisation avec le MCD et devant par exemple 20 personnes il n'y a que 5% qui comprends ton jargon sur une clé technique du coup on est en droit de se poser la question de la pertinence de sa présentation pour le public concerné.


Pour les techniciens aussi cela ne doit pas forcément être commode, imagine qu'on souhaite imprimer et afficher le modèle sur un mur beh toutes ces clefs automatique qui n'ont aucune sémantique vont prendre de la place et on pourra montrer moins de choses utiles, un exemple typique de la non pertinence dans ce cas.