Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Modélisation relationnelle : Quelles sont les règles d'or pour concevoir un bon MCD ?

Le , par wafiwafi

20PARTAGES

1  0 
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 main non réfléchie.
Des règles à respecter existent, elles ne sont pas d'or mais imposées pour respecter la construction.
A travers vos diverses expériences, vous pouvez agir. Qui sait peut être des règles d'or existent réellement à ce stade.

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de fsmrel
Expert éminent sénior https://www.developpez.com
Le 25/09/2009 à 16:42
Bonsoir,

Citation Envoyé par B.AF Voir le message
Au niveau conceptuel, le shéma est fabuleux
Il s'agit d'un shéma complêtement figé.
Voilà exactement l'exemple du MCD où de façon invariante on avancera que l'appli fonctionne, mais où malgrè moults arguments techniques, il est pauvre.

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.

Citation Envoyé par B.AF Voir le message
Très pauvre, peu évolutif

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.

Citation Envoyé par B.AF Voir le message
aucune logique de composants

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).

Citation Envoyé par B.AF Voir le message
d'un point de vue de conception pure, c'est une conception complêtement naïve

Encore une affirmation gratuite. Qu’est-ce qu’une conception pure ? Une conception naïve? Quel rapport existe-t-il entre ces deux concepts ?

Citation Envoyé par B.AF Voir le message
Ca viole même une règle fondamentale de tout objet en ce bas monde : tout objet est amené à évoluer dans le temps.

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.

Citation Envoyé par B.AF Voir le message
Là il n'y a aucune abstraction, aucun raisonnement objet, aucun raisonnement composant. C'est aussi en même temps la limite fondamentale de penser en relationnel.

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) ?

Citation Envoyé par B.AF Voir le message
je serai asssez intéressé de voir à quel MPD ce MCD correspond, est-ce du 1:1 ?

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.

Citation Envoyé par B.AF Voir le message
Quant aux règles de gestion, là encore, une règle de gestion n'est pas nécessairement associée à 1 élément du modèle, mais peut l'être à n éléments et surtout à n événements, dont le pilotage peut potentiellement être délégué à un élément technique externe au stockage de données (architectures distribuées).

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.

Citation Envoyé par B.AF Voir le message
J'ai l'impression en fait qu'il y a confrontation de deux écoles :
- Ceux qui modélisent une base de données, donc MCD et MPD sont très liés, et le SQL est pris en compte dès le MCD
- Ceux qui définissent un domaine et ses objets, donc MCD et MPD sont lâches, et le MPD est la représentation technologique du MCD.

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.

Citation Envoyé par B.AF Voir le message
Sur la lisibilité d'un modéle, là encore, c'est faisable si les domaines métiers traités sont triviaux. Il est normal que la complexité du métier (et donc non pas de description mais de ses événements et de ses workflows) influe sur le MCD.

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).

Citation Envoyé par B.AF Voir le message

Citation Envoyé par

le MCD ne doit pas engendrer une dénaturation des règles de gestion des données.
Je ne vois même pas comment on peut réaliser un MCD sans connaitre les règles de gestion à priori, sauf à modéliser des éléments triviaux dont la connaissance est supposée commune à tous. Donc le MCD ne peut être qu'une résultante de l'analyse exhaustive des règles métier. Sinon, il s'agit simplement d'un modéle anémique, inutile, et avec un risque d'adhérence élevé.

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...

Citation Envoyé par B.AF Voir le message
Pour la modélisation des relations ternaires, disons simplement que la logique relationnelle n'est pas adaptée à des "dépendances logiques polymorphiques".
Le modèle objet l'est.

Ç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).

Citation Envoyé par B.AF Voir le message
Autant j'adhére au DDD, autant là je me sens en plein anachronisme.

Conclusion : il vous reste donc plus qu’une seule chose à faire : vous retirer (sur la pointe des pieds).

Citation Envoyé par B.AF Voir le message

Citation Envoyé par
« Tous les hommes sont mortels » ou « Quelques hommes sont mortels »
C'est fondamentalement identique pour nous. Cela veut dire que tout ou partie des hommes au sens logique peut un jour faire l'objet d'un événement "mort".
La seule différence va être au sens technique. C'est dans la façon dont sera représenté physiquement la capacité à mourrir que sera gérée la différence.

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).

Citation Envoyé par B.AF Voir le message
Un MCD "bien formé" peut tout à fait aboutir à un MPD parfait, alors que dans sa logique, il est anémique et inutile.

Qu’entendez-vous par « logique » d’un MCD ? Et une fois de plus, par « MCD anémique » ?

Citation Envoyé par B.AF Voir le message
faire valider un cahier des charges n'a jamais signifié que les régles de gestion sont bonnes. C'est juste un transfert de responsabilités qui sert plus souvent d'excuse et de prétexte que de mesure de la qualité et de recensement.

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).

Citation Envoyé par B.AF Voir le message
Par rapport au SI le MCD est beaucoup trop pauvre pour être une formalisation utile.

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).

Citation Envoyé par B.AF Voir le message
Le MCD pour moi est surtout un formalisme techniquement dépassé, beaucoup trop confiné au SQL.

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).

Citation Envoyé par B.AF Voir le message
Je trouve simplement qu'en 2009, le DDD est beaucoup plus productif et efficient..

Grand bien vous fasse. J’espère que l’efficience de votre modélisation s’accompagne de la validité des résultats obtenus.

Citation Envoyé par B.AF Voir le message
Quand je lis
Citation Envoyé par
Je suis désolé, mais lors des séances de validation fonctionnelle d’un MCD, doivent être présents le chef de projet et/ou le concepteur (qui connaissent tous deux parfaitement le dossier), ainsi que l’équipe fonctionnelle de la Maîtrise d’Oeuvre qui, je le répète, comprend en général très vite le dossier et ce qui a été modélisé (sauf si le MCD ressemble à une toile d’araignée ou à un chef-d’œuvre d’art contemporain). A défaut, en l’absence de séances de relecture en commun, je ne donne pas cher du projet.
C'est effrayant, ça veut dire que la conception est un organisme mono cellulaire qui travaille en mode non collaboratif, que de facto, toute réalisation complexe et lourde est à proscrire.

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.

Citation Envoyé par B.AF Voir le message
La pire chance d'échec du projet c'est de n'avoir que 2 personnes qui connaissent parfaitement le sujet...Pas de révision, pas de droit à l'erreur, risques de sélection "dogmatiques".

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...

Citation Envoyé par B.AF Voir le message
En fait en rêgle de design aujourd'hui j'aurai plutôt tendance à

-Utiliser une clef technique (auto ou algo selon le sgbd) pour toutes les données sur lesquels je n'ai pas le décision de la norme
-Utiliser une clef codifiée pour toutes les données sur lesquels je défini leur norme

Si je dois identifier par exemple une plaque d'immatriculation, je considérerai que la norme de définition peut changer (d'ailleurs cas réel finalement) et j'utiliserai un identifiant automatique, et probablement une structure relationnelle pour identifier une immatriculation française avant 2008 ou après, us, belge,etc...

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.
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...
»
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 :
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

Citation Envoyé par B.AF Voir le message
Si par exemple, j'ai besoin pour x raison d'avoir un registre applicatif dans la base, j'utilise généralement une codification alphanumérique sur char(n), mais avec une validation du contenu (pas de blanc, caractères spéciaux)..
D'autant qu'il s'agit généralement de données cachées ou de paramètres applicatifs, l'impact en performance est complétement négligeable.

Parfois sur des besoins très particulier des séries temporelles longues avec des grosses volumétrie, j'utilise aussi des clefs binaires, mais davantage pour des motifs de tris, donc je peux être amené à le faire en char(n), mais c'est un cas très spécifique

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).

Citation Envoyé par hegros Voir le message
En prenant un autre modèle que le relationnel avec des tables et colonnes si vous prenez comme représentation un graphe avec par exemple les mib il me semble que chaque noeud est identifié par un varchar...
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é).
5  0 
Avatar de JPhi33
Membre chevronné https://www.developpez.com
Le 16/08/2009 à 1:15
Bonjour,

Citation Envoyé par wafiwafi Voir le message

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...
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).

Citation Envoyé par wafiwafi Voir le message

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.
3  0 
Avatar de fsmrel
Expert éminent sénior https://www.developpez.com
Le 18/08/2009 à 16:26
Bonjour,

Citation Envoyé par wafiwafi Voir le message
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 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.
2  0 
Avatar de fsmrel
Expert éminent sénior https://www.developpez.com
Le 20/08/2009 à 17:29
Citation Envoyé par CinePhil Voir le message
Un cas que je vois souvent dans les schémas proposés dans ce forum ou ailleurs : la cardinalité minimale à 1 de chaque côté d'une association.
Exemple :
"Un service comprend au moins un employé et un employé est affecté à un seul service."

De la règle de gestion ci-dessus, il découle le MCD :
Employé -1,1----Affecter----1,n- Service

Lorsque que je vais implanter ce schéma :
- Si je crée un nouvel employé, je devrai renseigner à quel service il est affecté. Comme il a été embauché pour un nouveau service qui n'existe pas encore dans la BDD, je ne peux pas.

Tant pis, je vais d'abord créer le service...
- Si je crée un service, je devrai renseigner en même temps au moins une personne de ce service. Comme c'est un nouveau service et que son chef vient d'être embauché et n'est pas encore enregistré dans la table des employés, je ne peux pas.

C'est le serpent qui se mord la queue à force de se demander qui de l'oeuf ou de la poule a commencé !

Bien sûr, un trigger pourra gérer ce cas mais il est plus simple de transformer la règle de gestion trop stricte en :
"Un service peut comprendre plusieurs employés et un employé est affecté à un seul service."

Ce qui donne le MCD :
Employé -1,1----Affecter----0,n- Service

Et là je peux créer tous les services de l'entreprise avant de leur affecter les employés, ce qui est quand même plus pratique et correspond davantage à la réalité d'un nouveau système d'information.


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 : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
 
INSERT 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 */
Tout cela est sous le capot et n'affecte donc pas le MCD...
2  0 
Avatar de Luc Orient
Membre expert https://www.developpez.com
Le 09/09/2009 à 22:43
Citation Envoyé par B.AF Voir le message
...
Aucun audit, aucune logique évenementielle, aucune logique multilingue...
Et c'est quoi concrètement une logique événementielle appliquée à un MCD ?
2  0 
Avatar de CinePhil
Modérateur https://www.developpez.com
Le 11/09/2009 à 1:01
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.
2  0 
Avatar de CinePhil
Modérateur https://www.developpez.com
Le 11/09/2009 à 10:57
Citation Envoyé par hegros Voir le message
à ma connaissance merise s'occupe uniquement de SI de gestion

J'ai modélisé à la maison une BDD concernant ma documentation cinéma. Pas de client, pas de prix, pas d'offre, pas de gestion comptable.

J'ai modélisé à l'INRA une base de données pour un logiciel de statistiques et une autre pour une étude sur les bovins sans aucune notion là non plus de gestion comptable ou commerciale.

Je risque quelle amende ?

A ce propos pour voiture le numéro de chassis est un identifiant relatif
J'appellerais ça plutôt une clé candidate, si on est sûr effectivement que ce numéro de chassis est unique pour toutes les voitures, ce qui devrait être le cas dans le parc automobile d'une entreprise.

pour une voiture mariokart ce n'est probablement pas cela mais le numéro de kart par exemple ?
On peut le penser...
Je numérote mes Karts de '01' à '99' et un jour je fusionne avec une autre entreprise qui a une codification différente et m'impose de renuméroter mes karts de 'K1' à Kn'.
Si j'ai choisi ce numéro de kart physiquement réel comme clé, ma clé change et donc elle n'est pas plus stable que le numéro d'immatriculation d'un véhicule.

Une clé anonyme attribuée par le système et que l'utilisateur n'a pas à connaître est la seule garantie de stabilité. Le véhicule numéroté 12 par le système gardera toujours ce numéro dénué de signification (hormis peut-être le fait que c'est le douzième véhicule enregistré dans le système mais on s'en fout), même si son immatriculation ou son numéro d'immobilisation comptable change.

Un attribut qui s'auto-incrémente à chaque nouvel enregistrement cela nous donne une information pertinente à quel sujet ?
Pertinence du choix de la future clé primaire au moins. En dehors, de ça, un identifiant n'est pas une information sémantique et n'a donc aucune pertinence sur ce plan là.

Augmentation des performances et diminution des coût sur les traitements et les données que se soit en vitesse, en espace mémoire etc...
Identifiant de type entier non nul non signé et auto-incrémenté : 4 octets
Numéro d'immatriculation française : au moins 8 caractères pour les anciennes plaques et au moins 7 pour les nouvelles, sans les espaces dans les deux cas.
Numéro de sécu : 15 caractères sans les espaces.
Là où je reconnais qu'on peut utiliser éventuellement une clé alphanumérique, c'est dans le cas de petites tables de référence telle que par exemple un type d'organisme (C = Client, F = Fournisseur, A = Administration, P = Prospect, il ne doit pas y avoir masse d'autres cas). Et encore, on peut choisir un identifiant de type TINY INT à 1 octet ou SMALL INT à 2 octets.
2  0 
Avatar de benwit
Rédacteur https://www.developpez.com
Le 19/08/2009 à 16:08
Citation Envoyé par fsmrel Voir le message

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).
Ok pour la sémantique.
Mais la clé relative nécessite une clé composé n'est-ce pas ?

Perso, j'ajoute systématiquement une clé "technique" qui est ma clé primaire. Cela évite à la fois le passage des x attributs composants la clé fonctionnelle et les lourdeurs lors d'évolution du schéma.
Cela n'empêche pas que les attributs de la clé "fonctionnelle" soient présents et de poser une contrainte d'unicité dessus.
1  0 
Avatar de CinePhil
Modérateur https://www.developpez.com
Le 19/08/2009 à 17:18
Effectivement, l'identification relative entraîne en principe une clé composée.

Exemple pour une chaîne d'hôtels et leurs chambres. Dans chaque hôtel, les chambres sont numérotées de 1 à n.

Il y a deux possibilités :
1) La "normalisée" :
Chambre -(1,1)----Situer----1,n- Hôtel

Hotel (H_Id, H_Nom...)
Chambre (Ch_IdHotel, Ch_Numero, ...)

Identification relative de la chambre par rapport à son hôtel, la chambre est identifiée par la clé composée (Ch_IdHotel, Ch_Numero).

2) La vôtre :
Chambre -1,1----Situer----1,n- Hôtel

Hotel (H_Id, H_Nom...)
Chambre (Ch_Id, Ch_IdHotel, Ch_Numero, ...)

Identifiant artificiel pour la chambre et obligation de mettre une contrainte UNIQUE sur le couple (Ch_IdHotel, Ch_Numero).

Dans un cas comme celui-ci où les chambres sont numérotées par des entiers, je préfère la solution normalisée.

Si par contre les hôtels ont donné un joli nom à leurs chambres à la place de numéros, je préfère l'identifiant artificiel car une colonne de type textuel dans une clé primaire, je n'aime pas car le nom de la chambre peut changer et bonjour les mises à jour dans toutes les tables dérivées, le modèle n'est alors pas solide.
1  0 
Avatar de fsmrel
Expert éminent sénior https://www.developpez.com
Le 19/08/2009 à 19:20
Citation Envoyé par benwit Voir le message
la clé relative nécessite une clé composé n'est-ce pas ?

Je suppose que par clé relative vous entendez l’homologue au niveau logique de l’identifiant relatif du modèle conceptuel de données (MCD). Toujours au niveau logique (disons SQL), prenons l’exemple du couple Commande (table Commande), Ligne de commande (table LigneCommande). Si la table Commande a pour clé primaire {CommandeId}, la table LigneCommande aura pour clé primaire {CommandeId, LigneCommandeIdRel}, LigneCommandeIdRel étant un séquenceur dont l’objet est de distinguer chaque ligne de commande d’une commande donnée et dont la valeur est égale à 1 pour la 1re ligne de commande de chaque commande, égale à 2 pour la 2e ligne, etc. (Il va de soi que la valorisation de chaque attribut entrant dans la composition d’une clé primaire est du ressort du système et en aucune façon l’utilisateur n’a son mot à dire : on lui laisse les propriétés naturelles).

La clé de la table LigneCommande n’est pas un singleton, mais une paire : c’est une « clé composée » pour reprendre votre expression. Y verriez-vous un quelconque inconvénient ?

Citation Envoyé par benwit Voir le message
j'ajoute systématiquement une clé "technique" qui est ma clé primaire

Reprenons l’exemple des deux tables Commande et LigneCommande et suivons votre recommandation : utilisons une clé primaire singleton {LigneCommandeIdAbs} pour la table LigneCommande. Si vous relisez avec attention ce que j’ai écrit dans mon message précédent, l’objet du prototype est, entre autres, de vérifier que la performance concernant les accès à cette table est acceptable. En fonction de son verdict, on pourra être amené à remplacer la clé primaire singleton {LigneCommandeIdAbs} par la paire {CommandeId, LigneCommandeIdRel}. Pour ma part, à chaque fois que j’ai prototypé, j’ai constaté que dans ce genre de scénario (relation entre une entité-type et ses propriétés multivaluées) c’était un bienfait pour les accès (réduction du nombre de pages à charger en mémoire donc des temps d'attente de fin de chargement). En conséquence, je suis amené à utiliser l’identification relative au niveau du MCD.

Citation Envoyé par benwit Voir le message
Cela évite à la fois le passage des x attributs composants la clé fonctionnelle et les lourdeurs lors d'évolution du schéma.

Je suppose que par « passage des x attributs », vous voulez dire qu’il y a de la redondance et que cela coûte cher en occupation mémoire ? En réalité, cette redondance est utilisée pour les opérations de jointure et elle est complètement contrôlée par le SGBDR (à condition évidemment de mettre en œuvre les contraintes d’intégrité référentielle qui sont les conséquences au niveau logique SQL des associations-types du MCD). Concernant l’occupation mémoire, un attribut tel que LigneCommandeIdRel coûte deux octets, contre quatre octets pour l’attribut LigneCommandeIdAbs (c'est-à-dire quand la table LigneCommande doit pouvoir contenir plus de 32767 lignes de commande).

Quant « aux lourdeurs lors d'évolution du schéma » (conceptuel ? logique ?) je ne vois rien qui puisse confirmer votre affirmation. Merci de fournir un exemple.
1  0