Modélisation relationnelle : Quelles sont les règles d'or pour concevoir un bon MCD ?
Le 2009-08-08 09:05:50, par wafiwafi, Membre averti
on m'a été posée et j'aimerais avoir votre avis sur la réponse que j'ai fournie.
Quelles sont les règles d'or pour concevoir un bon MCD ?
Ma réponse : on ne peut parler d'un bon MCD que si on évoque les applications qui vont l'accompagner et l'étude de la complexité du programme pour minimiser les lectures et écritures sur disques sans parler du problème de la recherche des objets dans le cas d'une grande quantité d'informations dans les bases...
Pour moi, une règle de base à respecter est de bien s'assurer que le modèle construit de façon bien réfléchie, répond au cahier des charges fixé au départ. Parler de règle d'or au stade d'un MCD me parait prématuré ; en résumé, on ne peut juger un bon MCD qu'à partir de ce que vous voulez en faire par la suite.
En essayant de réduire les classes au maximum par exemple, cela voudrait il dire qu'on a amélioré le MCD ? Pour moi, ce n'est pas forcement le cas. Certaines personnes le font de façon automatique mais non réfléchie.
Des règles à respecter existent, elles ne sont pas d'or mais imposées pour respecter la construction.
À travers vos diverses expériences, vous pouvez agir. Qui sait peut être des règles d'or existent réellement à ce stade.
Quelles sont les règles d'or pour concevoir un bon MCD ?
Ma réponse : on ne peut parler d'un bon MCD que si on évoque les applications qui vont l'accompagner et l'étude de la complexité du programme pour minimiser les lectures et écritures sur disques sans parler du problème de la recherche des objets dans le cas d'une grande quantité d'informations dans les bases...
Pour moi, une règle de base à respecter est de bien s'assurer que le modèle construit de façon bien réfléchie, répond au cahier des charges fixé au départ. Parler de règle d'or au stade d'un MCD me parait prématuré ; en résumé, on ne peut juger un bon MCD qu'à partir de ce que vous voulez en faire par la suite.
En essayant de réduire les classes au maximum par exemple, cela voudrait il dire qu'on a amélioré le MCD ? Pour moi, ce n'est pas forcement le cas. Certaines personnes le font de façon automatique mais non réfléchie.
Des règles à respecter existent, elles ne sont pas d'or mais imposées pour respecter la construction.
À travers vos diverses expériences, vous pouvez agir. Qui sait peut être des règles d'or existent réellement à ce stade.
-
fsmrelExpert éminent séniorBonsoir,
Merci de préciser quel est ce schéma qui ne trouve pas grâce à vos yeux. Si d’aventure c’est celui de vivicente, vous avez sans doute oublié qu’il débute dans la modélisation. Il ne vous est pas interdit de suivre l’exemple de CinePhil, qui n’hésite pas à montrer au débutant ce qui ne va pas, point par point, et comment apprendre à construire un MCD qui tienne la route (« Il aide, lui », Jean in Les Tontons flingueurs).
Et merci de respecter l’orthographe, vous ne facilitez pas la lecture.
Veuillez présenter les arguments vous permettant de pointer les défauts que vous relevez et ne pas vous contenter de dénigrer gratuitement. Présentez des solutions d’amélioration visant à l’enrichissement et à l’évolutivité du MCD.
Que sont un composant ainsi qu’une logique de composants dans le contexte de l’élaboration de cette abstraction qu’est un MCD (Modèle Conceptuel de Données), objet de la discussion ? S’il s’agit des composants au sens UML (programme source, compilé, fichier de données, etc.) cet inventaire à la Prévert est hors sujet. C’est à la Direction de la Production informatique de l’entreprise de prendre ces choses en charge, en collaboration avec les équipes de développement. Un MCD ne traite que de l’univers du discours (l’entreprise).
Encore une affirmation gratuite. Qu’est-ce qu’une conception pure ? Une conception naïve? Quel rapport existe-t-il entre ces deux concepts ?
Qu’est ce qu’un objet ?
1) Si un objet est quelque chose qui évolue qui dans le temps, alors c’est une variable au sens des langages de programmation, au même titre que la variable X, déclarée dans un programme P : au fil du temps, si X est par exemple du type entier, alors cette variable accueille successivement des valeurs qui sont des nombres entiers 1, 2, 3, etc. Ces nombres ne se situent ni dans le temps ni dans l’espace, mais on les fait apparaître par le truchement de X qui joue le rôle de médium.
2) Si un objet est une valeur, alors à l’instar d’un nombre entier il ne si situe ni dans le temps ni dans l’espace, c’est une constante et donc par définition il n’« évolue » pas.
A son tour, une entité-type E est une abstraction, en l’occurrence un type. Lors du passage au MLD (disons dans le cadre du Modèle Relationnel de Données), à cette entité-type on fera correspondre une variable relationnelle (relvar) E qui sera du type RELATION {A1 T1, A2 T2, ..., An Tn} (où Ai est un nom d’attribut et Ti le type de cet attribut) et qui prendra des valeurs de relations de ce type (relations pour abréger, êtres mathématiques fort intéressants qui bien entendu ne se situent ni dans le temps ni dans l’espace, puisque ce sont des constantes). Et bien entendu, le type RELATION {A1 T1, A2 T2, ..., An Tn} hérite de tous les opérateurs de l’algèbre relationnelle.
Pour l’abstraction, voyez ce qui précède. Que vient faire ici le concept « objet » ? Celui de « composant » ? Qu’est-ce qu’un « raisonnement objet » ? Et, rebelote, un « raisonnement composant » ?
Quant au relationnel, c'est-à-dire la théorie relationnelle, commencez par l’étudier avant de parler de ses limites (à moins que vous ne soyez en mesure de les énumérer ici, de façon claire et objective). A toutes fins utiles, je vous renvoie à l’ouvrage de Date et Darwen : Databases, Types, and the Relational Model The Third Manifesto. Attention, il s’agit d’une étude très formelle, ramassée dans plus de 500 pages. Cela dit, que veut dire « penser en relationnel », sinon raisonner sur des ensembles (au sens de la théorie des ensembles), tant du point de vue structurel qu’algébrique ? Ou encore raisonner sur des prédicats, au moyen de la logique du 1er ordre et du calcul relationnel de tuples (ou de domaines) ?
MPD est l’abréviation de « Modèle Physique des Données ». Le MPD traite de ce qui se passe dans la soute (organisation des espaces physiques, des index, etc.) Je suppose donc que vous avez voulu écrire « à quel MPD le MLD correspond » ou encore « à quel MLD ce MCD correspond ».
Dans le 1er cas, au nom de l’iindépendance physique, il n’y a pas de correspondance à établir entre les objets physiques et les entités mathématiques que sont le relations de la théorie relationnelle. Ainsi, entre une variable relationnelle (une table pour parler informellement) et un fichier il n’y a pas bijection : les relations (les valeurs prises par la variable relationnelle) peuvent être hébergées par plusieurs fichiers et un fichier peut héberger plusieurs relations de types différents. Cela reste sous le capot. De même, un n-uplet d’une relation n’a pas à correspondre à un enregistrement physique dans un fichier. Un n-uplet est lui aussi un être mathématique qui n’a pas à être contraint par l’organisation sous le capot. Ne cherchons pas à établir une quelconque correspondance entre la logique du 1er ordre et le fer à souder.
Dans le 2e cas, la production d’un MLD à partir d’un MCD est de préférence confiée à un AGL, mais elle est à vérifier et compléter par le DBA : opportunité de la mise en œuvre de variables relationnelles dans le cas des cardinalités 0,1 (notamment en ce qui concerne les associations-types réflexives), complétude des clés candidates d’une variable relationnelle, des dépendances fonctionnelles et multivaluées, des dépendances de jointure (y compris les dépendances de jointure généralisées), normalisation en cinquième forme normale (voire sixième dans le cas des données temporelles), définition des tables virtuelles (vues), définition des contraintes de base de données, de relation, d’attribut, de type. Etc. De même, certaines entités-types du MCD n’ont pas à faire l’objet de variables relationnelles, par exemple l’entité-type DATE qui ne fait que l’objet d’attributs de type DATE ou TIME, ou TIMESTAMP, etc. Quant à chercher une correspondance 1:1 entre un MCD et un MLD, on ne la trouvera pas, sauf peut-être dans des cas de figure simples.
Qu’entendez-vous par « élément du modèle » ?
Par ailleurs, le pilotage des événements ne concerne pas le MCD (c'est-à-dire le QUOI), mais le MCT (c'est-à-dire le COMMENT, le QUAND, les conditions de déclenchement et toutes ces sortes de choses). Un MCD décrit l’univers su discours, c’est un ensemble de prédicats au sens de la logique du 1er ordre.
L’architecture distribuée est étrangère au sujet. Là encore, d’un point de vue MCD et MLD, on ne voit qu’un univers du discours pour le 1er, une base de données pour le 2e, même si dans ce 2e cas, d’un point de vue opérationnel, tout cela repose en fait, de façon transparente, sur plusieurs bases de données, gérées par plusieurs SGBD sur plusieurs machines. Encore une confusion des genres.
Quand on modélise un univers du discours (l'entreprise), il n’y a pas deux écoles. Chronologiquement, une fois que le SI a été urbanisé en [sous-]domaines, la direction de projet en partenariat avec la maîtrise d’œuvre (tant qu’à faire) produit un dossier de conception générale pour formaliser l’univers du discours avec un certain recul : pour chaque domaine (Référentiel Personnes, Contrats, Catalogue produits, etc.), on y trouve des MCD représentant les concepts, à grosse maille. Ensuite, à maille fine, toujours par [sous-]domaine, il y a production d’un dossier de conception détaillée dans lequel le MCD est muet quant au MLD et a plus forte raison quant au MPD. En ce qui concerne SQL, n’oublions pas que la direction de projet ignore tout de ce langage, ou à la longue, en a une idée plus ou moins précise, sans pour autant que cela vienne interférer avec la modélisation.
Par la suite, le concepteur du MCD et le DBA affecté au domaine (voire une équipe de DBA) ont un certain nombre d’entretiens avant que celui-ci ne produise le MLD (puis le MPD). Suite aux observations du DBA, le MCD utilisé pou la dérivation peut subir des modifications : révision des identifiants (qui ne doivent être composés que d’attributs artificiels ad-hoc, je vous renvoie une fois de plus à l’ouvrage de Tabourier, De l’autre côté de MERISE, page 81), typage des données, normalisation en BCNF, vérification des associations-types ternaires (et plus), pour voir si elles ne violent pas la quatrième forme normale, recherche des contraintes (notamment temporelles) qui peuvent être sous-traitées au SGBD, mise en œuvre des tables virtuelles (vues) en relation avec la spécialisation des entités-types, etc. Quant à prendre en compte le langage SQL quand débute la conception, c’est non. Ça n’est que lorsqu’on en arrive aux entretiens avec le DBA que celui-ci peut attirer l’attention sur les conséquences des choix de modélisation et ainsi faire réfléchir le directeur de projet qui peut revenir sur tel ou tel choix. Il arrive que certains aient la double casquette : concepteur et DBA, mais ça n’est pas pour autant qu’en tant que concepteur il faille s’adresser aux autres membres des équipes de conception en termes relationnels, tout en ayant en tête la théorie relationnelle qui permet d’éviter certaines erreurs de conception. A titre d’exemple, quand j’ai fait des remarques au débutant, je lui suggérais de normaliser en quatrième forme normale, mais sans le lui dire brutalement.
Quant à dire que le MPD (ou plutôt le MLD) « est la représentation technologique du MCD », c’est un peu court. Cette représentation « technologique » est à valider, évaluer à l’aune de la théorie relationnelle et la faire évoluer en conséquence.
Si le MCD complet comporte par exemple mille entités-types, la direction du projet aura pris la précaution d’urbaniser l’univers du discours en domaines (référentiels) sous-domaines et sous-sous-domaines, comme je l’ai déjà plus ou moins évoqué. Ainsi, on aura décomposé le projet en référentiels : Personnes, Contrats, Cotisations, Catalogue produits, Prospection de masse, Éditique, etc., peut-être une vingtaine, voire plus. Au niveau le plus fin, la représentation graphique doit tenir — de façon claire et lisible — sur un ensemble de pages au format (disons) A3, chaque page constituant une vue suffisante pour qu’un développeur n’ait pas à avoir sur son bureau un tombereau de diagrammes.
Quant aux événements (au sens fonctionnel), s’ils doivent eux aussi faire l’objet d’un domaine, pourquoi pas, mais si leur traitement peut être complexe, cela ne doit pas avoir d’incidence sur le MCD, sinon ça n’est pas un MCD. Que l’on prenne en compte — suite à événements — les modifications portant sur une entité-type (par exemple le changement de dénomination d’une entité juridique, son changement de NAF, de régime fiscal, de catégorie juridique, etc.) ceci reste simple à représenter dans le MCD quand on sait distinguer les données actives des données historisées et qu’on ne fourre pas tout dans le même sac. (En cela, la connaissance de la sixième forme normale n’est pas inutile).
Merci de ne pas sortir une phrase de son contexte pour en dénaturer le sens. Comme je l’ai déjà dit, les règles de gestion des données préexistent, elles sont consignées dans le dossier de conception détaillé. Par exemple, quand il est écrit qu’une facture comporte au moins une ligne de facture, cela se traduit dans le MCD par une cardinalité minimum 1. Si l’on remplace cette cardinalité par 0, alors il y a bien dénaturation d’une règle de gestion des données. C’est le reproche que je faisais à hegros qui préconise, je cite, de « Prendre en compte uniquement la partie maximum pour les cardinalités ».
Quant à « l’anémie » des MCD et de leur « risque d’adhérence élevé », les participants et les visiteurs de ce forum doivent se perdre en conjectures, sauf peut-être s’ils s’appellent Sganarelle. Isn't it a little fuzzy?
Il est vrai que certains « top models » paraissent anémiés et que certains modèles de pneumatiques peuvent manquer d’adhérence au sol, mais à part cela...
Ça présente bien, mais je ne vois pas ce que vous appelez une « dépendance logique polymorphique » (ça s’appelle peut-être encore autrement ?) Je ne vois pas non plus ce que les relations ternaires ont à voir avec ça. Quant à l’aspect polymorphique proprement dit, voulez-vous signifier qu’il s’agit du polymorphisme de type, au sens UML ou du Modèle Relationnel de Données ? Si oui, cela est abondamment traité dans la théorie relationnelle (cf. par exemple les chapitres 12 à 16 de l’ouvrage déjà cité, Databases, Types, and the Relational Model The Third Manifesto).
Conclusion : il vous reste donc plus qu’une seule chose à faire : vous retirer (sur la pointe des pieds).
Là encore, vous sortez une phrase de son contexte, pour partir ailleurs. J’ai expliqué à hegros que transformer une cardinalité minimum 1 en 0 revenait à confondre la quantification universelle et la quantification existentielle, donc affirmer que les deux énoncés « Tous les hommes sont mortels », « Quelques hommes sont mortels » sont équivalents, ce qui est évidemment une erreur logique très grave. Si vous voulez en savoir plus, je vous conseille par exemple la lecture de l’ouvrage de Quine méthodes de logique, « Énoncés catégoriques » et là vous apprendrez que le 1er énoncé est du type A (universelle affirmative) et le 2e du type I (Particulière affirmative).
Qu’entendez-vous par « logique » d’un MCD ? Et une fois de plus, par « MCD anémique » ?
Si les règles de gestion des données ne sont pas bonnes, c’est que le chef de projet n’a pas su accoucher la maîtrise d’œuvre. Et si le projet échoue, il en portera la responsabilité. Si les règles de gestion des données sont incomplètes et si le MCD est bien construit, on le fera évoluer en conséquence.
Ceci dit, quelle alternative proposez-vous à la validation des dossiers ? Que faire pour s’assurer que les règles de gestion des données soient réputées valides ? Merci de nous éclairer de vos lumières (qui pour le moment éteignent).
Si le MCD est parfois trop pauvre c’est parce qu’il ne prend pas en compte des concepts tels que l’héritage, la composition, l’agrégation, les contraintes d’inclusion, exclusion et autres : il faut donc le faire évoluer en ce sens (je vous renvoie à la FAQ Merise).
Cela dit, un MCD est malgré tout un excellent moyen de communication, et comme je l’écrivais dans un message précédent :
« Le MCD doit être crédible et clair, au point que la MOE et les équipes de développement décident d’afficher au mur les vues qui les concernent, plutôt que de s’en servir comme de ballons de basket, la poubelle jouant le rôle de panier. »Maintenant, si le MCD ne suffit pas, on peut se référer à ses compagnons, le MCT (Modèle Conceptuel de Traitement) et le MCC (Modèle Conceptuel de Communication).
Merci de démontrer en quoi le formalisme MCD est techniquement dépassé. Quant à sa relation avec SQL, sachez que les SGBD utilisant ce langage ont été mis sur le marché seulement quelques années après que l’on a commencé à produire des MCD. Merise date de la fin des années soixante-dix et, en France, les entreprises ont commencé à vraiment utiliser les SGBDR en production une dizaine d’années plus tard.
Une fois de plus vous mélangez complètement les niveaux, vous amalgamez abstraction (modélisation des données) et réalisation (SQL).
Grand bien vous fasse. J’espère que l’efficience de votre modélisation s’accompagne de la validité des résultats obtenus.
Qu’y a-t-il d’effrayant à ce que la Maîtrise d’ouvrage organise des réunions pour s’assurer que les équipes du projet et la Maîtrise d’œuvre sont bien toujours en phase ? Pour s’assurer qu’il n’y a pas eu de dérive ? Pour mettre à plat les points à revoir ? Certes, en début de projet, les équipes du projet (les informaticiens) et la Maîtrise d’œuvre sont pratiquement en permanence ensemble, mais ensuite les informaticiens modélisent à partir des résultats des travaux effectués en commun. C’est la moindre des choses que la MOA surveille ses troupes et l’avancement du projet (domaine par domaine).
Je rappelle une fois de plus qu’on urbanise un univers du discours en domaines, sous-domaines, etc. Un projet de refonte du SI d’une entreprise importante (je sais de quoi je parle) entraîne nécessairement l’urbanisation, donc la modélisation de plusieurs domaines, ce qui a notamment pour objet d’éviter une réalisation complexe et lourde qui se traduirait par la mort du projet. Et cela a pour effet que l’on constitue des équipes homogènes, de taille raisonnable, tant côté informatique que MOE.
C’est bien pour cela que l’on urbanise les projets d’une certaine ampleur. Pour chaque domaine, il y a un chef de projet et son équipe, même principe côté Maîtrise d’œuvre. Si un chef de projet tombe malade, son adjoint assure l’intérim, etc.
Rassurez-vous tout cela fait largement plus que seulement deux personnes connaissant le sujet...
Je suppose que par « design » vous voulez dire modélisation. Si vous vous situez au niveau de la modélisation des données, que vient faire le SGBD ? Quant à codifier les clés (en fait les identifiants), je répète pour la nième fois ce qu’à écrit Yves Tabourier (De l’autre côté de MERISE page 81) :
« ... 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.Tabourier a tiré les leçons du passé et nous demande quelque part d’avoir en mémoire ce que Goethe, Winston Churchill, George Santayana, Thomas Mann, et d'autres ont écrit :
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... »
Ceux qui ont oublié le passé sont condamnés à le revivre.
Je répète pour ma part qu’au niveau MCD, la plaque d’immatriculation (qui correspond à une propriété naturelle) ne peut faire l’objet que d’un identifiant alternatif (donc d’une clé alternative lors du passage au niveau base de données) et que l’identifiant d’une entité-type (donc la clé primaire d’une table au niveau base de données) ne décrit rien. L’utilisateur ne doit connaître que les propriétés naturelles, l’identifiant lui est caché. La plaque d’immatriculation ne figure qu’une fois dans l’univers du discours, donc dans la base de données qui en sera inférée. En ce qui le concerne, une fois traduit sous forme de clé primaire, l’identifiant sera propagé autant de fois qu’il y aura de contraintes référentielles dans lesquelles il est impliqué. C’est une question de bon sens que de ne lui associer aucune signification quelconque. Sa mission sera de garantir l’intégrité de la base de données (intégrité d’entité, intégrité référentielle), pas de décrire.
Ensuite, au niveau de la base de données, qu’un attribut participant à une clé primaire soit du type entier (séquentiel ou haché), timestamp (séquentiel ou haché), CHAR, VARCHAR, INTERVAL, etc., ceci est parfaitement orthogonal (indépendant) par rapport à la modélisation. Le choix définitif de ce type relève de la compétence du DBA et certainement pas du concepteur ou du développeur, qui sont plus concernés par l’aspect fonctionnel des choses.
Voyez encore http://www.developpez.net/forums/d79...d/#post4635515
J’espère que vous ne vous ne traitez pas ici des identifiants du niveau conceptuel, mais de propriétés disons naturelles (quitte à ce qu’elles fassent l’objet d’identifiants alternatifs).
Là encore, le choix du type des attributs est un problème de réalisation, pas de modélisation. Mais si, au niveau modélisation, vous avez malgré tout de très bonnes raisons de retenir le type VARCHAR plutôt que INTEGER, CHAR, ou ... NŒUD, vous aurez à convaincre le DBA (qui généralement n’est pas favorable à VARCHAR pour typer une clé).le 25/09/2009 à 16:42 -
JPhi33Membre chevronnéBonjour,
Le MCD (Modèle Conceptuel de Données) a pour objet la représentation (l'abstraction) d'une réalité. Son invariant est le métier : le "QUOI".
Par conséquent le reste est variable : organisations, fonctions, technologies, etc. Ce qui signifie que le MCD doit être indépendant de ces variables : il ne doit pas tenir compte de l'organisation de l'entreprise, ni des applications qui vont utiliser la ou les bases de données résultantes, encore moins des technologies d'implémentation.
Donc, s'il devait y avoir une règle d'or (ou règle de base ou règle essentielle) pour la modélisation conceptuelle, ce serait, à mon avis : Un bon MCD est celui qui modélise correctement 100% des règles de gestion du cahier des charges (ce qui transparait dans la citation de wafiwafi ci-dessous).le 16/08/2009 à 1:15 -
fsmrelExpert éminent séniorBonjour,
Pour confirmer ce que dit JPHi33, on ne traite pas des accès au disque quand on est sur la dunette (c'est-à-dire au niveau conceptuel) : « minimiser les lectures et écritures sur disques » fait l’objet d’une étude distincte de la modélisation conceptuelle des données. Descendons dans la soute, pour que vous compreniez bien pourquoi.
Cette étude suppose en effet que l’on ait connaissance du SGBD qui sera utilisé. Elle pourra être appelée « prototypage des performances » et devra être menée par un spécialiste, un DBA (administrateur des bases de données) qui construira son prototype suite aux entretiens qu’il aura eus avec le chef de projets, afin d’identifier les traitements les plus sensibles (disons le top 10). Dans ce genre d’exercice, il ne s’agit pas de programmer, mais de façon pragmatique — à partir d’un jeu de tables ayant à peu de choses près la structure de celles qui seront dérivées du MCD, avec une volumétrie suffisante pour les mesures —, construire un ensemble de requêtes (disons SQL) qui ne sont jamais que des brouillons, mais qui suffisent pour connaître la performance globale, bien avant que ne démarrent les véritables développements, lesquels tiendront évidemment compte du verdict du prototype.
Maintenant, il est vrai que les résultats fournis par le prototype, peuvent avoir quelques retombées sur le MCD lui-même, telles que l’utilisation de l’identification relative — plutôt qu’absolue —, qui normalement est une conséquence de la sémantique des données (par exemple, une ligne de facture est à identifier relativement à une facture). Mais normalement, cela ne remet pas en cause le MCD lui-même (ou alors c’est que le concepteur n’a pas fait vraiment son travail).
De même que lorsque vous bâtissez un MCD vous ne vous focalisez pas sur les accès au disque, de même vous ne vous mêlez pas d’autres problèmes sensibles qui ne sont pas de votre ressort et auxquels vous n’aurez pas songé (heureusement, sinon vous ne dormiriez pas), par exemple : les étreintes fatales et autres verrous mortels, dus à une trop forte concurrence des utilisateurs lors des opérations de mises à jour. Là encore, c’est le prototype qui devra permettre de mettre en évidence ces phénomènes, d’anticiper quant à l’organisation de la structure physique des tables afin d’éliminer ce genre de problèmes.
Ou encore, vous ne vous préoccupez pas des droits des utilisateurs sur les données, sauf à élaborer un MCD annexe à cet effet. Là encore, chaque chose en son temps, comme dit l’autre « the right man in the right place, at the right time ».
Ce qui signifie encore : indé-pen-dan-ce.
Bref, pendant que le DBA construit son prototype, assurez-vous déjà auprès du chef de projets que le cahier des charges est à peu près complet, sinon vous-même, le chef de projets — et finalement tout le monde, y compris la Maîtrise d’ouvrage — connaîtriez bien de bien cruelles désillusions.le 18/08/2009 à 16:26 -
fsmrelExpert éminent sénior
Hum... Avec un MCD, on modélise la finalité, donc si selon le cahier des charges un service doit comporter au moins un employé, le schéma
Employé -1,1----Affecter----0,n- Service
dénature la représentation de l’information.
Ça n’est qu’au niveau logique que vous déciderez d’affaiblir les règles de gestion des données, selon que vous déciderez de mettre en œuvre la contrainte ou pas, en accord évidemment avec qui de droit.
A titre d'information, vous utiliseriez un SGBD conforme au Modèle Relationnel de Données, vous n’auriez pas d’état d’âme, la cardinalité 1,N n’aurait pas à être altérée pour des motifs de commodité d’utilisation de triggers et considérations du même tabac. En effet, le problème de l’oeuf et de la poule se résout très simplement : les INSERT qui servent à créer un service et son premier employé, sont empaquetés dans une liste (dont la fin est marquée par un point-virgule, tandis que les INSERT sont eux-mêmes séparés des virgules au sein de la liste. Le SGBD n’effectue ses contrôles qu’après détection du point-virgule, marqueur de fin de liste.
(N.B. Ci-dessous, « EmployeId EmployeId 3 » se lit ainsi : l’attribut EmployeId est du type EmployeId et sa valeur est 3).Code : 1
2
3
4
5
6
7
8
9
10
11INSERT Employe RELATION {TUPLE { EmployeId EmployeId 3, ServiceId ServiceId 1, Matricule Matricule 103', }} , /* virgule : séparateur d’opérations */ INSERT Service RELATION {TUPLE { ServiceId ServiceId 1, EmployeId EmployeId 3, ... ... ... }} ; /* point-virgule : fin de liste */
le 20/08/2009 à 17:29 -
wafiwafiMembre avertiBonjour 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.le 21/08/2009 à 10:53 -
wafiwafiMembre avertiBonjour,
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 à vousle 09/09/2009 à 18:43 -
Luc OrientMembre expertle 09/09/2009 à 22:43
-
f-lebResponsable Arduino et Systèmes Embarquésbonsoir,
je suis un peu étonné de voir ces "règles d'or pour concevoir un bon MCD"
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 ?
j'évite les ternaires si les règles de gestion le permettent:
Code : 1
2
3
4
5
6CONTACT----0,n----exercer----0,n-----FONCTION | 0,n | ORGANISME
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.
EMPLOYE---0,n---rémunérer---1,1---ELEMENTPAYE
règle de gestion: un employé peut travailler "au black"le 10/09/2009 à 23:19 -
CinePhilModérateurOn 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.
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.le 11/09/2009 à 1:01 -
f-lebResponsable Arduino et Systèmes Embarqués
Envoyé par f-leb
"@hegros: je suis un peu étonné de voir tes "règles d'or pour concevoir un bon MCD"Envoyé par hegros Envoyé par hegros Envoyé par f-leb Envoyé par hegros le 11/09/2009 à 1:25