[MCD] Quelles sont les règles d'or pour concevoir un bon MCD? [Résolu]

[f-leb]

Envoyé par f-leb

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

Envoyé par hegros

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

Pardon, en effet j'aurais dû écrire:
"@hegros: je suis un peu étonné de voir tes "règles d'or pour concevoir un bon MCD"

Envoyé par hegros

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.

l'entité VOITURE sans identifiant ?????!!!!! Cette pratique ne me semble pas à mettre parmi les "règles d'or".

Dans ce cas, qu'entends-tu par "prendre en compte uniquement la partie maximum pour les cardinalités" ? que 0,n et 1,n c'est kifkif pareil ? que 0,1 et 1,1 c'est blanc bonnet et bonnet blanc ?

[hegros]

Envoyé par f-leb

Pardon, en effet j'aurais dû écrire:
"@hegros: je suis un peu étonné de voir tes "règles d'or pour concevoir un bon MCD"

Tu pourrais nous dire ce qui t'étonne parce que c'est plutôt creux là.

l'entité VOITURE sans identifiant ?????!!!!! Cette pratique ne me semble pas à mettre parmi les "règles d'or".

D'une part je ne travaille pas dans ce domaine donc les us/coutumes connaît pas et d'autre part j'ai toujours trouvé l'automobile en retard aussi sur l'immatriculation...Bref, je ne dis pas que voiture n'a pas d'identifiant (d'ailleurs est-ce que c'est le kart de mario ou la limousine de pretty woman?) j'en sais rien limite cela ne m'intéresse pas.


De plus cela argumente en ma faveur car si voiture a bien une véritable clef primaire alors un identifiant automatique sert à quoi ? C'est une considération technique ?

Dans ce cas, qu'entends-tu par "prendre en compte uniquement la partie maximum pour les cardinalités" ? que 0,n et 1,n c'est kifkif pareil ? que 0,1 et 1,1 c'est blanc bonnet et bonnet blanc ?

Il peut y avoir des entités où il est impératif pour bien conceptualiser de mettre aussi les cardinalités minimales, on ne parle pas dans l'absolu 100% des cas, mais la plupart du temps cela n'apporte aucune règle de gestion supplémentaire et j'attends que tu justifies la différence si c'est pas kiff-kiff pareil parce que qu'un oiseau puisse manger 0 ou N pomme ou qu'un oiseau puisse manger 1 ou N pomme qu'est qui change vraiment ?

D'ailleurs il me semble pas que cela soit utilisé dans la génération du mld dans les outils...

[fsmrel]

Bonsoir,


Je redonde avec certaines remarques faites par f-leb et CinePhil, mais tant pis, j’envoie.

Envoyé par hegros

Voilà quelques règles d'or pour moi

hegros, vous prenez vos responsabilités et c’est bien. Mais il m'arrive d'être en désaccord avec vous.

Envoyé par hegros

-Ne jamais fournir un MCD sans les règles de gestion et un dictionnaire de données

Exact. Ces éléments doivent faire partie du Dossier de Conception Détaillé (DCD), lequel doit faire l’objet d’une revue serrée, à laquelle participent le directeur de projet, ses collaborateurs concernés et les représentants de la Maîtrise d’Oeuvre, voire de la Maîtrise d’Ouvrage. Et comme au fil du temps les règles évolueront, ce dossier devra être maintenu, sinon il perdra de son crédit et restera confiné au fond d‘une armoire.

Envoyé par hegros

-Modélisez en couvrant l'aspect offre, tarification et tiers

Vous faires sans doute référence à un univers du discours particulier. Si l’univers que je modélise est celui de la philosophie, des pathologies, du cosmos ou des Schtroumfs, je ne vois pas le rapport.

Envoyé par hegros

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

Le concept de clé primaire est du niveau MLD et n’a donc pas à être mentionné dans le Dossier de Conception Détaillé. En revanche, celui-ci fait mention des identifiants des entités-types, car le concept d’identifiant est du niveau MCD. En passant, je rappelle à nouveau ce qu’a écrit l’excellentissime Yves Tabourier (De l’autre côté de MERISE page 81), et ça c’est une règle d’or, qui a plus de vingt ans :

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

Autrement dit, identifier une entité-type telle qu’un véhicule automobile par un numéro d’immatriculation ou autres informations portées sur une carte grise est à éviter. De la même façon identifier une entreprise par son numéro Siren est à prohiber dans un MCD. En effet, quand l’INSEE procède à une modification, ça peut être extrêmement pénalisant. A ce sujet voyez la discussion avec KristofNancy. Dans cette discussion, je me situe aux deux niveaux, MCD (je parle des identifiants) et MLD (je parle des clés), mais ce que j’ai écrit rejoint totalement ce qu’a écrit Y. Tabourier. En l’occurrence, comme dit mon ami Chris Date : Better prevent than cure...

Envoyé par hegros

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

Il est vrai que certaines ternaires et plus ne se justifient pas. J’extrais cette image d’une discussion au cours de laquelle le toujours serviable CinePhil a pris en charge vivicente (qui débute) pour lui montrer comment ramener ces n-aires à des binaires :





Mais :

Considérons les règles de gestion suivantes :

— Tel de nos ingénieurs a pu mettre en œuvre tel ou tel SGBD chez tel ou tel de nos clients ;
— Tel client a pu avoir besoin des services de tel et tel de nos ingénieurs pour mettre en œuvre tel et tel SGBD ;
— Etc.

Par exemple :

L’ingénieur Albert a mis en œuvre SQL Server et DB2 chez Dubicobit. Il a aussi mis en œuvre Oracle, Sybase et DB2 chez Yadupour.
L’ingénieur Bernard a mis en œuvre DB2 et IMS chez Dubicobit. Il a aussi mis en œuvre IDMS et Sybase chez Yaudpoil.

Le MCD correspondant est le suivant :



Mathématiquement parlant, la ternaire n’est pas réductible à des binaires (on démontre en effet qu’elle est en sixième forme normale). Je rappelle encore qu’une association-type correspond à un prédicat, en l’occurrence :

L’ingénieur x met en œuvre le SGBD y chez le client z

Ou à la façon ramassée des logiciens :

x met en œuvre y chez z

Et de façon encore plus ramassée :

Fxyz

Ceci ne date pas d’aujourd’hui, voyez G. Frege, le père de la logique moderne. Dans sa théorie générale de la quantification (voyez Methods of Logic), le Professeur Willard V.O. Quine (un des plus grands philosophes américains du XXe siècle) prend comme exemple le terme triadique « Gxyz » qui pourra signifier « x donne y à z ». Quine présente aussi le terme triadique « Hxyzw » qui pourra signifier « x paye y à z pour w ». Et Quine n’a aucunement l’intention (et pour cause !) de ramener un prédicat triadique ou tétradique à des prédicats dyadiques.

Pour en revenir au MCD, Y. Tabourier traite longuement des ternaires avec l’exemple (bien connu des cercles merisiens) des personnes qui garent des voitures dans des bâtiments, en notant qu’il est des cas où la décomposition est impossible.

Envoyé par hegros

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

Que nenni ! Une cardinalité minimale 0 exprime que la participation d’une entité à une association est facultative alors qu’une cardinalité minimale 1 exprime que la participation d’une entité à une association est obligatoire. Ne pas en tenir compte serait comme confondre la quantification existentielle et la quantification universelle (dire que « Tous les hommes sont mortels » ou « Quelques hommes sont mortels », c’est équivalent). D’un point de vue conceptuel ça serait affaiblir, dénaturer les règles de gestion correspondantes. Tiens, voilà une règle d’or :

le MCD ne doit pas engendrer une dénaturation des règles de gestion des données.

Envoyé par hegros

-Respectez les formes normales

Certainement. Toutefois, ce travail de vérification doit être poursuivi au niveau du MLD, car certaines dépendances fonctionnelles et clés candidates (identifiants candidats au niveau conceptuel) ne sont pas directement dérivables du MCD, elles sont inaccessibles parce que cachées par définition au sein des associations-types. A cette occasion, je rappelle que la deuxième forme normale, la troisième forme normale et la forme normale de Boyce-Codd mettent exclusivement en jeu dépendances fonctionnelles et clés candidates (voire surclés, mais je ne voudrais pas sortir du périmètre).

Envoyé par hegros

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

Tout dépend du sens que vous donnez au mot « technique ». S’il s’agit de l’auto-incrémentation des clés, des index, du partitionnement et autres éléments du niveau physique, vous avez parfaitement raison. Pour le reste, il faudrait que vous apportiez des précisions.

Cela dit, si votre MCD comporte mille entités-types, il doit être urbanisé en domaines, sous-domaines, sous-sous-domaines, de telle sorte que chaque vue correspondante tienne sur une page au format A3. A ce niveau, pour que l’utilisateur arrive à suive, il est préférable ne pas montrer les attributs (y compris les identifiants). Pour le reste : identification relative, agrégation, composition, héritage, et toutes ces sortes de raffinements, l’utilisateur non informaticien comprend vite ces techniques fort utiles, qui facilitent en fait la lecture des MCD et des diagrammes de classes UML. Quant à gérer deux MCD, tout dépend de leur taille et du temps dont vous disposez pour les réaliser (et les maintenir).

Envoyé par hegros

Modèle conceptuel qui prends en considération la technique pour l'optimisation

Qu’entendez-vous par optimisation ?

Envoyé par hegros

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

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.

Quant aux techniciens (les équipes de développement et les DBA qui leurs sont affectés), ils comprennent aussi très vite, et là encore le chef de projet et/ou le concepteur sont dans l’obligation de leur faire faire une visite guidée et approfondie du MCD.

Tiens, voilà une règle d’or : 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.

[fsmrel]

Envoyé par CinePhil

je mets systématiquement des identifiants anonymes du genre 'id' aux entités dès le MCD.

CinePhil, Tabourier, même combat !

Envoyé par hegros

D'une part je ne travaille pas dans ce domaine donc les us/coutumes connaît pas et d'autre part j'ai toujours trouvé l'automobile en retard aussi sur l'immatriculation...Bref, je ne dis pas que voiture n'a pas d'identifiant (d'ailleurs est-ce que c'est le kart de mario ou la limousine de pretty woman?) j'en sais rien limite cela ne m'intéresse pas.

Ce qui vaut pour l’entité-type VOITURE vaut pour toute entité-type quelle qu’elle soit, identifier est une règle universelle, j'ai envie de dire une méta-règle. L’entité-type VOITURE a un identifiant façon Tabourier, c'est-à-dire artificiel, donc non significatif et non maîtrisé par un système externe, CinePhil l’a bien rappelé. Le numéro d’immatriculation ou le numéro de châssis font l’objet d’identifiants alternatifs, respectant donc la contrainte d’unicité imposée aux identifiants quels qu’ils soient. Cela vaut pour les entreprises : elles aussi sont identifiées façon Tabourier, tandis que leur numéro Siren fait l’objet d’un identifiant alternatif. Nous-mêmes sommes soumis au même régime, nous sommes identifiés artificiellement et notre NIR est un identifiant alternatif (je parle au moins pour une caisse de retraite où j’ai beaucoup modélisé). Etc.

Envoyé par hegros

De plus cela argumente en ma faveur car si voiture a bien une véritable clef primaire alors un identifiant automatique sert à quoi ? C'est une considération technique ?

VOITURE n’a de clé primaire qu’au niveau logique (SQL). Au niveau conceptuel, voyez ci-dessus.

[hegros]

Envoyé par fsmrel

Vous faires sans doute référence à un univers du discours particulier. Si l’univers que je modélise est celui de la philosophie, des pathologies, du cosmos ou des Schtroumfs, je ne vois pas le rapport.

Disons que ce sont les aspects surtout de l'informatique de gestion mais tout de même à ma connaissance merise s'occupe uniquement de SI de gestion hors modéliser l'offre (connu aussi sous terme de métiers), les tiers/entité de gestion et tarification me semble faire en sorte qu'ainsi on ne risque rien d'oublier d'important.

D’un point de vue conceptuel ça serait affaiblir, dénaturer les règles de gestion correspondantes. Tiens, voilà une règle d’or :

le MCD ne doit pas engendrer une dénaturation des règles de gestion des données.

C'est intéressant mais pareil cela je le fais plutôt dans le MLD (cardinalité minimale) excepté s'il est vraiment important de le préciser sans quoi cela omettrait une règle ou une contrainte importante(qui à de la valeur), cela est souvent le cas avec les entités avec identifiant relatif justement.

A ce propos pour voiture le numéro de chassis est un identifiant relatif ce qui est différent d'une clef unique, à mon avis pour des raisons pratiques et de conception mondialiste qui font qu'avec la retape des numéros par les escrocs.... garantir l'unicité d'un chassis au niveau intergalactique est impossible, en fait cela dépend du contexte/univers que l'on modélise pour une voiture mariokart ce n'est probablement pas cela mais le numéro de kart par exemple ?

Tout dépend du sens que vous donnez au mot « technique ». S’il s’agit de l’auto-incrémentation des clés, des index, du partitionnement et autres éléments du niveau physique, vous avez parfaitement raison. Pour le reste, il faudrait que vous apportiez des précisions.

Sans aucune sémantique c'est à dire qui ne se rapporte pas à l'offre du SI. Un attribut qui s'auto-incrémente à chaque nouvel enregistrement cela nous donne une information pertinente à quel sujet ? Sinon partitionnement, index etc sont de bons exemples de ce que j'entends par technique.

Qu’entendez-vous par optimisation ?

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


Et merci pour toutes ces informations c'est vraiment très intéressant et instructif, les prédicats, les ternaires etc

[CinePhil]

Envoyé par hegros

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

[B.AF]

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.

Très pauvre, peu évolutif, aucune logique de composants.

Ca produira proablement du SQL propre avec les bonnes clefs, mais d'un point de vue de conception pure, c'est une conception complêtement naïve.

Ca viole même une règle fondamentale de tout objet en ce bas monde : tout objet est amené à évoluer dans le temps.

La principale qualité de l'abstraction est de tenir compte de cela.

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.


En même temps je dis ça, mais je serai asssez intéressé de voir à quel MPD ce MCD correspond, est-ce du 1:1 ?

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

En outre, il est aussi nécessaire de savoir où se positionnent les règles de gestion, et par nature, à moins de connaitre précisemment l'architecture de la solution, il est impossible d'avoir des positionnements hétérogénes, notamment si l'architecture est en couches.

Mais fondamentalement, là en se focalisant sur la modélisation SQL, on part sur des motifs de conception qui sont aujourd'hui lours, entrainent des erreurs de développements massives, peu enclinent aux politiques de tests. (Unit tests et Acceptance tests).

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.

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

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.

C'est aussi pour cela qu'il est nécessaire de choisir avec recul et simplicité ses outils.

Autant j'adhére au DDD, autant là je me sens en plein anachronisme.

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

Si dans mon Modèle je prévois :

Man
Name
Gender
CanDie

Mon modéle objet peut gérer cette association par héritage ou injection,
Mon modéle relation peut créer une relation ou pas :
- Table unique avec identification d'un statut
- Table avec héritage (mapping O/R)
- Composants techno

Mais ce n'est pas dans mon MCD que je vais définir
KillHim (man Man)
ou
MakeHimDead(man Man)

[hegros]

Envoyé par CinePhil

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 ?

Félicitations ! Mais à aucun moment je ne parle de comptabilité mais d'informatique de gestion, gestion de film cinéma ou pas l'offre c'est ce qu'on appelle aussi la partie "métiers", bon pour les bovins on va avoir des bouses et des vaches dans cette partie.

Tu ne risques aucune amende, Merise est une méthode complète ce n'est pas applicable à la lettre dans sa globalité quoique mais cela à un très grand coût du coût assez peu courant, ma pratique n'est ni plus une variante dérivé de mon expérience, la théorie et l'imagination ?

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.

C'est un jeu vidéo pourquoi tu parles de fusion d'entreprise ? Un numéro magique ou virtuel aurait plus de sens pour le contexte non ? Sinon ton analyse dans le cas décrit pourquoi pas à vrai dire la conception automobile me semble un peu à la traîne, cela ne veut pas dire que le modèle est faux

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.

[/QUOTE]

Il faut se poser de la question du contexte et la signification qu'on donne à cela et aussi de la volumétrie pour justifier une optimisation parce que là c'est tout sauf adaptable vous spécifier un niveau national et des concepts qui peuvent évoluer car en cours de réforme (le numéro de sécu par exemple)

De plus il nous manque un élément essentiel pour parler d'implémentation c'est la plateforme. Parce que mario kart c'est sûr DS que cela se joue et à vrai dire la base de données serait quoi un fichier XML ? Mince, incompatibilité entre Merise et une plateforme physique, XML ne connaît pas SQL il me semble comment on fait ?

Envoyé par B.AF

Mais fondamentalement, là en se focalisant sur la modélisation SQL, on part sur des motifs de conception qui sont aujourd'hui lours, entrainent des erreurs de développements massives, peu enclinent aux politiques de tests. (Unit tests et Acceptance tests).

Il existe des bibliothèques qui permettent d'écrire des Unit test pour du code SQL pourtant.

Sinon en même temps normal qu'il soit pauvre ce schéma, nous n'avons pas parler d'une implémentation spécifique de plus il nous manque 2/3 de la méthode, pour définir des composants il faut connaître des traitements ce que ne fournira jamais un MCD.

[B.AF]

Envoyé par hegros

Il existe des bibliothèques qui permettent d'écrire des Unit test pour du code SQL pourtant.

Sinon en même temps normal qu'il soit pauvre ce schéma, nous n'avons pas parler d'une implémentation spécifique de plus il nous manque 2/3 de la méthode, pour définir des composants il faut connaître des traitements ce que ne fournira jamais un MCD.

Oui c'est bien ce que j'en pense : l'intéressant est à priori du MCD pas à posteriori. Les bons usages ne viennent jamais des cas triviaux, ils viennent toujours de la confrontation d'une théorie excessive à une réalité brutale.

La difficulté de la conception est là; pas dans la sélection des attributs technologiques, puisque le nécessaire est capté. Il n'est pas impossible de faire n mcd et mpd pour trouver des solutions, expérimenter.

Le défaut de conception est indépendant du MCD qui n'est finalement qu'une des multiples formes descriptives possibles.

Un MCD "bien formé" peut tout à fait aboutir à un MPD parfait, alors que dans sa logique, il est anémique et inutile.

De la même façon que de 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.

Aucune méthode ne peut résoudre l'ambiguité structurelle entre l'utilisateur et le développeur. Elle peut rationaliser et contribuer à faire du management parapluie ("le machin est validé par titi toto et tata le x/y/zzzz à 14H56, donc c'est leur faute"), mais elle n'est aucunement la garantie que les hommes s'approprieront le sujet, fait malgrè plus important que la formalisation pour la réussite d'un projet de développement.

Avoir une méthode traduction ne fait pas qu'un russe puisse traduire pour un allemand les propos rapportés par un anglais.
En revanche, elle permettra d'essayer de comprendre pour le russe a échoué et que la guerre existe en l'allemagne et l'angleterre.

C'est là la grande illusion : la description est toujours facile car elle ne comporte jamais d'ambiguités structurelles.

[hegros]

Envoyé par B.AF

Oui c'est bien ce que j'en pense : l'intéressant est à priori du MCD pas à posteriori. Les bons usages ne viennent jamais des cas triviaux, ils viennent toujours de la confrontation d'une théorie excessive à une réalité brutale.

Je ne vois pas ce qui permet de dire que le MCD est le coeur de la conception d'un SI qui n'est qu'une vue statique du système final, il manque les composants au moins non ?

La difficulté de la conception est là; pas dans la sélection des attributs technologiques, puisque le nécessaire est capté. Il n'est pas impossible de faire n mcd et mpd pour trouver des solutions, expérimenter.

Quand on utilise les modèles pour la conception forcément on souhaite qu'il soit le plus portable du moins extensible le plus possible, ce qui ne rends pas l'idée idiote de garder un mcd métiers et un mcd, plutôt un mld/mpd à mon sens, pour la partie technologique. Nous nous rejoignons la dessus.

Un MCD "bien formé" peut tout à fait aboutir à un MPD parfait, alors que dans sa logique, il est anémique et inutile.

Si tu veux dire qu'un mcd est insuffisant nous sommes d'accord, on conçoit rarement données sans traitement, en tout cas d'un point de vue traitement informatique c'est insensé puisque des données on les exploite (create, update,...)


Une fois encore un MCD est un point de vue structurel sur les données pas sur les traitements ou autre chose comme l'architecture distribué ou technologie à la mode

Recouper à un MCT, MOD,MOT la méthode à l'avantage d'être très exhaustive et de couvrir un maximum de cas en faisant un minimum d'oubli et ne zappe pas l'architecture comme tu le laisses entendre

[B.AF]

Envoyé par hegros

Je ne vois pas ce qui permet de dire que le MCD est le coeur de la conception d'un SI qui n'est qu'une vue statique du système final, il manque les composants au moins non ?

Rien, ce n'est pas ce que j'ai dit. Je dis justement que le MCD est une vue partielle et en plus pas nécessairement efficiente.

Par rapport au SI le MCD est beaucoup trop pauvre pour être une formalisation utile.

Envoyé par hegros

Une fois encore un MCD est un point de vue structurel sur les données pas sur les traitements ou autre chose comme l'architecture distribué ou technologie à la mode

Recouper à un MCT, MOD,MOT la méthode à l'avantage d'être très exhaustive et de couvrir un maximum de cas en faisant un minimum d'oubli et ne zappe pas l'architecture comme tu le laisses entendre

Oui c'est bien là où je trouve l'utilité relative : un diagramme objet fait la même chose avec une utilité technique directe, et surtout une logique de composants plus forte. Le MCD pour moi est surtout un formalisme techniquement dépassé, beaucoup trop confiné au SQL.

Je trouve simplement qu'en 2009, le DDD est beaucoup plus productif et efficient. C'est d'ailleurs le parti qu'à pris microsoft avec M, quadrant et consors.

Quand je lis

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.

Désolé (ça oui, on peut l'être), mais ça fait vraiment les horreurs du passé que plus personne ne veut voir. Malheureusement pour la conception applicative, ce n'est pas dans les vieux pots que l'on fait la meilleure soupe. Notamment pour les aspects "bloated design".

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

[Luc Orient]

Envoyé par CinePhil

... 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'argument selon lequel une clé primaire de type entier sera plus performante me laisse toujours songeur. En effet, il faudra sûrement un deuxième index pour assurer les recherches sur l'identifiant "métier" écarté au profit de la clé numérique. On aura donc deux index au lieu d'un.

Oû est le gain en performances ?

Mais là j'avoue m'éloigner du MCD pour tomber dans le MLD voire dans le MPD ...

L'argument sur la stabilité est beaucoup plus recevable.

Dans le cas de la plaque d'immatriculation, on pourra noter que les nouvelles règles ( AA-000-AA) correspondent bien à un identifiant stable puisque la plaque d'immatriculation est désormais affecté au véhicule jusqu'à sa destruction.

[CinePhil]

Je ne me lasse pas de redonner le lien vers le blog de SQLPro au sujet des clefs auto-incrémentées.

Je cite quelques passages :

Plus modestement, un bonne clef serait donc d’un coût négligeable, par exemple une valeur numérique entière, bien entendu unique, au moins au sein du modèle qu’elle représente et enfin attribuée une fois pour toute durant la vie entière de l’objet qu'elle identifie.

Il semble donc évident que l’utilisation d’une clef naturelle est une fort mauvaise idée ! Et par voie de conséquence, un bon vieux numéro fait parfaitement l’affaire pour la plupart des cas.

Ensuite côté performances...
N'oublions pas que cette clé primaire sera utilisée comme clé étrangère dans d'autres tables de la BDD. Et la joiture entre deux (ou plus) entiers est plus rapide que la jointure entre deux colonnes de type VARCHAR(n), surtout si n est supérieur à 4.

Alors certes, le système va chercher dans l'index I_V_Immat de la table Vehicule le numéro d'immatriculation du véhicule mais ensuite pour donner à travers les Réservations enregistrées la liste des Personnes qui ont emprunté le véhicule, les jointure se feront avec des entiers et non pas avec un numéro d'immatriculation à au moins 8 caractères (sans les espaces pour les anciennes plaques françaises).

A partir d'un certain nombre d'emprunts enregistrés, la différence de temps de traitemetn peut devenir sensible.

[Luc Orient]

Envoyé par CinePhil

Je ne me lasse pas de redonner le lien vers le blog de SQLPro au sujet des ...

SQLPro, qui a des avis très tranchés sur tous ces sujets ne détient pas la vérité révélée et absolue ...

Moi j'ai tendance à dire ... ça dépend ...

Ensuite côté performances...
N'oublions pas que cette clé primaire sera utilisée comme clé étrangère dans d'autres tables de la BDD. Et la joiture entre deux (ou plus) entiers est plus rapide que la jointure entre deux colonnes de type VARCHAR(n), surtout si n est supérieur à 4.

L'argument sur les jointures est tout à fait recevable ...

Par contre j'évite absolument les clés primaires en VARCHAR ...

[B.AF]

Il y a un motif qui n'est pas valable de l'utilisation de clefs générées et ce quel que soit l'algorithme.

Il est important dans l'édition de logiciels, car souvent un éditeur à tendance à exposer une couche de paramètrages importante à l'utilisateur. L'utilisation de clefs auto-incrémentées gérée uniquement par le sgbd client pose de sérieux problèmes de standardisation et devient une vraie plaie.

En outre, le problème est aussi valable sur les stratégies de sharding ou de persistence hétérogénes : des éléments d'une base peuvent être ne relation avec des éléments stockés dans une autre base représentant un autre domaine, ou dans un autre support.

Donc fondamentalement ce n'est pas toujours une bonne idée.

[CinePhil]

Envoyé par Luc Orient

Par contre j'évite absolument les clés primaires en VARCHAR ...

On est bien d'accord là dessus !

[B.AF]

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

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.

Je pense qu'il ne faut pas avoir d'à priori, mais surtout utiliser la réponse appropriée à la question.

[hegros]

Envoyé par CinePhil

On est bien d'accord là dessus !

Théoriquement cela ne pose déjà aucun problème puisque nombre de clefs candidates peuvent être de ce type de données. C'est une contrainte technologique pour aujourd'hui mais est-ce là bien une règle qui va durer encore longtemps ?


J'ai vu et utilisé des clefs de type chaîne de caractère cryptée par exemple comme clef primaire cela n'a posé aucun problème particulier et il y a sûrement pleins d'exemples qui abondent aussi dans ce sens



Pour les identifiants automatique nous n'avons plus le choix puisque tout les sgbd le font automatiquement d'une manière ou d'une autre sans qu'on leur demande explicitement, cette clef technique n'a tout de même rien à faire dans un MCD dans un MLD/MPD ok et encore franchement elle n'a aucune valeur.


Immatriculation peut être une entité et pas un attribut type VARCHAR d'une voiture, le design est plus important que ces soucis de clé technique d'où ma règle d'or de ne pas la prendre en compte pendant la conception


Remarque, il n'est pas possible de faire des recherches ou appliquer un tri en utilisant un identifiant automatique dans ses requêtes SQL dans certains SGBD

[Luc Orient]

Envoyé par hegros

Théoriquement cela ne pose déjà aucun problème puisque nombre de clefs candidates peuvent être de ce type de données. C'est une contrainte technologique pour aujourd'hui mais est-ce là bien une règle qui va durer encore longtemps ? ...

Je me suis peut être mal fait comprendre et je vais donc préciser ma pensée.

Quand j'écrivais que j'évitais les types VARCHAR pour les colonnes des clés primaires, c'était en comparaison avec des colonnes en CHAR.

En aucun cas, je n'exclus les colonnes en CHAR pour définier des clés primaires.

[hegros]

Qu'est-ce que cela change ? varchar ce n'est pas une horreur c'est le contrôle ou la contrainte d'intégrité qui pose problème pour cet artifice de type caractère à taille variable ?

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