Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
[Article] Initiation à la conception de bases de données relationnelles avec MERISE
Je vous présente mon cours intitulé : initiation à la conception de bases de données relationnelles avec MERISE
N'hésitez pas à laisser vos impressions ici.Ce cours est conçu pour ceux qui souhaitent s'initier rapidement à la conception d'une base de données relationnelle à l'aide de la méthode d'analyse MERISE. Il est en rapport direct avec le programme de certaines formations d'études supérieures comme le BTS Informatique de Gestion ou encore le DUT informatique.
Il est inutile de suffixer chaque attribut par le nom de l'entité dans laquelle il se trouve (ou la première lettre comme dans votre exemple).
Je pense que c'est une mauvaise pratique, car par définition l'attribut se rapporte à son entité.
Bonsoir.
Je ne suis pas d'accord. Même si les SGBDR le permettent dans la pratique, cela est proscrit par MERISE au niveau conceptuel (comme ça que j'ai appris) ... libre à vous d'appliquer vos préférences en matière de normes mais pour ce tuto j'essaye de respecter au maximum les exigences de MERISE.
Dans ce cours, j'essaye de montrer qu'on déduit les entités et associations à partir de leur propriété et des DF existant entre elles (même si cette demarche devient instinctive par la suite). D'un point de vue pedagogique je pense qu'il est donc important de différencier.
Cordialement,
Idriss
D'accord avec ok.Idriss sur le pré ou post fixage du nom des propriétés des entités qui deviendront des colonnes des tables. Cela évite, entre autres avantages, de se demander si le nom que l'on donne à une propriété ne serait pas par hasard un mot réservé du langage SQL.
Il est important de se définir une norme de nommage, comme celle que propose SQLPro par exemple. Cela facilitera par la suite l'écriture et la lecture des requêtes.
Quelques remarques sur le contenu de l'article...
1) Dictionnaire de données - Code postal
Je crois que c'est faux. Au hasard, j'ai cherché le code postal de Bastia et ce site m'a affiché 20200.Le code postal peut parfois être composé de lettres, en Corse notamment.
Par contre, c'est peut-être vrai à l'étranger.
2) Dictionnaire de données
Tu y fais figurer les identifiants qui ne font pas partie des propriétés figurant explicitement dans les règles de gestion. Ce dictionnaire de données est donc déjà une réflexion sur la structure technique de la future BDD. Pourquoi alors n'avoir pas externalisé la ville, ce qui devrait être aussi une adaptation des règles de gestion ?
3) Type date
La taille du type Date me semble inutile puisque c'est le SGBD qui va décider de quelle façon ce type est implémenté. Par contre, distinguer les types Date, Heure et Date/heure me semblerait utile.
4) Taille du nom
15 caractères pour un nom, c'est un peu juste !
Je me souvient d'une très jolie camarade de classe au collège nommée "Charles de la Blandinière", soit 25 caractères et d'une autre nommée "Dubuisson-Dupplessis". Avec la multiplication des femmes qui souhaitent conserver leur nom de jeune fille accolé à celui de leur époux, les noms dépassent de plus en plus souvent les 15 caractères.
D'après l'article de SQLPro sur les données et les normes, la Poste autorise jusqu'à 38 caractères par ligne d'adresse. Dans ce cas, en tenant compte de l'abréviation de la civilité, une longueur de 32 caractères pour le nom semble plus raisonnable.
Dans le même ordre d'idée, 20 caractères pour la ville est insuffisant et 40 caractères pour une adrel risque de l'être également, ainsi que 50 caractères pour le titre d'un livre, nom d'un pays...
5) Identifiant d'un type de livre
Pourquoi ne pas avoir appelé cette propriété "id_t" puisqu'il s'agit d'un identifiant ?
Idem pour l'identifiant de l'édition, identifiant de l'emprunt...
6) Édition d'un livre
Il y a une légère ambiguïté dans la signification du terme "édition".
S'agit-il d'une référence à l'éditeur du livre ou du numéro de l'édition chez l'éditeur du livre ? Un livre peut en effet connaître plusieurs éditions, au sens de parution, au fil des ans, chez le même éditeur, parfois avec des mises à jour ("nouvelle édition revue et augmentée par l'auteur").
7) Données calculées
La raison pour laquelle le montant d'une commande doit être enregistré est que les montant des éléments constitutifs de la commande (les produits et services vendus) peuvent changer après émission de la commande. Si j'achète un produit à 10 euros HT et qu'on me le facture 10,50 euros parce que prix a évolué entre le moment de la commande et la date de livraison, je ne vais pas être d'accord ! Il peut, de plus, y avoir des remises accordées pour une commande, ce qui fait qu'on ne peut pas retrouver le montant de la commande à partir du prix tarif des produits achetés.Cependant, il existe quelques cas où il s'avère pertinent de conserver, pour des raisons d'optimisation, une donnée calculée, le montant d'une commande par exemple.
Mais la commande est un bon exemple de donnée calculée à stocker.
8) Donnée chiffrée
Je dirais plutôt une "donnée numérique" Et je préciserais avec des exemples : Code postal ou tout autre code numérique, références, numéros d'ordre, de série, de chapitre...Lorsque l'on n'effectue jamais de calcul sur une donnée chiffrée,
D'où l'importance de ne pas nommer "num" un identifiant technique.
9) Dépendances fonctionnelles
Ce n'est pas ma tasse de thé et, à vrai dire, je ne les utilise jamais.
Leur syntaxe est toujours demeurée pour moi confuse mais il me semble avoir compris que P1 → P2 signifie "P1 détermine P2", ce qui m'a semblé plus simple que "P1 et P2 sont reliées par une dépendance fonctionnelle".
Mais je préfère sauter ce chapitre avant de (continuer à ?) dire des bêtises.
10) Terme "relation"
Tu dis d'abord, à la fin du chapitre "II-D-1. Les entités" :
Puis dès le début du chapitre suivant :la table d'occurrence peut être comparée à l' instance d'une relation (implantation relationnelle d'une entité ou association) à un moment donné. Nous reviendrons sur cette notion de relation dans la partie III.
J'évite absolument le terme "relation" pour signifier une association entre deux entités, afin d'éviter toute confusion avec les relations de la théorie relationnelle.Une association définit une relation (ou un lien) sémantique entre une ou plusieurs entités.
11) Entité Pays
Je ne l'avais pas remarqué dans le dictionnaire de données mais pourquoi n'y a t-il pas d'identifiant à l'entité Pays ? D'après le schéma, c'est le nom du pays qui sert de clé et c'est une mauvaise clé !
12) Faute dans le MCD
Juste une petite faute d'orthographe : il n'y a qu'un R à "paraître"
13) Erreur de MLD
Dans le MCD, l'association est la suivante :Voici un exemple de relation associative issu de l'association «Correspondre» de notre MCD :
Correspondre ( num_l #, ref_e # )
livre -0,n----correspondre----1,1- exemplaire
Il n'y a donc pas de table associative ici.
Oui, je suis vraiment fâché avec terme "relation" !
14) Cardinalités 1,1
Je suis d'accord avec le fait que des cardinalités 1,1 de chaque côté de l'association binaire n'entraînent pas obligatoirement la fusion des entités, notamment pour des raisons sémantiques. Par contre, cette structure :
signifie pour moi qu'elle est issue de ce MCD :Pays ( nom_p )
Auteur ( id_a , nom_a, prenom_a, date_naissance_a)
EtreOriginaireDe ( id_a # , nom_p #)
Auteur -0,1----être_originaire_de----0,n- Pays
En clair, on ne connaît pas obligatoirement le pays d'origine de l'auteur.
Voici ce que j'ai écrit dans mon blog à ce sujet :
15) Chapitre III-A-2-d. Règle 4 -Cas 06) A -1,1----associer----1,1- B
Lorsque les deux couples de cardinalités sont à 1,1, on doit se demander si on peut fusionner les deux entités. Si elles représentent des choses sémantiquement différentes ou si on les conserve pour une raison technique (ajout de table à une BDD existante, amélioration des performances par séparation de données importantes en volume mais rarement lues...), on a le choix de la table qui accueillera la clé étrangère.
fsmrel va probablement sortir sa sulfateuse contre le bonhomme NULL.
Voici ce que j'ai écrit dans mon blog à ce sujet :
16) Passage au SQLCas 04) A -0,1----associer----1,n- B
La clé étrangère ne peut pas aller dans B puisque un B peut être associé à plusieurs A. Mais elle ne peut pas non plus aller dans A puisque un A peut ne pas être associé à un B. Il faut donc une table associative. Et comme un A sera associé au maximum une seule fois à un B, la clé primaire de la table associative sera la clé étrangère référençant A.
Cas 03) A -0,1----associer----0,n- B
Aucune des deux entités n'est systématiquement associée à l'autre (cardinalités minimales à 0). Il faut donc une table associative dont la clé primaire sera, pour la même raison que dans le cas 04, la clé étrangère référençant A.
Cas 01) A -0,1----associer----0,1- B
Pour la même raison que dans le cas 03, il faut une table associative. Et pour la même raison que dans le cas 06, on a le choix de la clé étrangère qui sera également clé primaire, l'autre clé étrangère devant être munie d'une contrainte d'unicité.
Les longueurs des VARCHAR ne correspondent pas aux longueurs de ton dictionnaire de données !
Et cette fois, elles sont pour la plupart un peu longues !
17) Association d'association
Je sais que ça a déjà été discuté et qu'il y a plusieurs manières de représenter ce phénomène d'association pointant vers une association.
Personnellement, je préfère faire l'effort de transformer l'association en entité associative. Ainsi, ton second schéma du chapitre "IV-D. Les CIF(s) et agrégations" deviendrait pour moi celui-ci :
Librairie -1,n----proposer----(1,1)- LivreEnVente -(1,1)----concerner----1,n- Livre
Client -0,n----acheter----0,n-----------------|
Chez moi, pointer une association sur une association est interdit ! Cela oblige à réfléchir à la pertinence de l'association existante sur laquelle est pointée une nouvelle association.
Le cas classique étant celui des lignes de commande ou de facture.
En première approche :
Commande -1,n----comprendre----0,n- Produit
Si on souhaite gérer les livraisons ou la facturation partielles de la commande, on transforme l'association "comprendre" en entité associative "ligne_commande" :
Commande -1,n----comprendre----(1,1)- ligne_commande -(1,1)----concerner----0,n- Produit
La ligne de commande a bien une existence réelle au sein de la commande et peut être gérée en tant que tel lors des livraisons partielles ou reprise comme élément de facture. La première association "comprendre" était une représentation incomplète de la réalité.
Si on veut en rester à la représentation qui autorise à faire pointer une association sur une association, je préfère alors la représentation qui entoure l'association pointée d'un rectangle, comme dans les schémas fournis dans cette discussion par dark123.
18) Une dernière remarque
Pour le MLD, il existe aussi un schéma, que personnellement je n'aime pas beaucoup, qui symbolise les liens entre les tables (non je n'aime pas le terme de "relation" !) par des flèches. C'est du moins celui qui m'a été enseigné au CNAM pour la méthode Merise.
Je lui préfère le schéma "entity/relationship" que l'on trouve notamment en standard dans MySQL Workbench, mais aussi dans Open Modelsphere lorsque l'on génère le MLD à partir du MCD.
J'assimile plus la représentation en liste de tables avec leurs colonnes, comme tu le pratiques dans cet article, au MPD, même s'il y manque les types des colonnes.
==================
Dommage que je n'ai pas vu cet article avant, lors de sa soumission pour lecture critique. Mais globalement, et malgré toutes mes remarques, il est assez complet et d'un bon niveau tout en restant simple et clair ; bravo pour ce bon boulot !
Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole, en retraite... mais toujours Autoentrepreneur à l'occasion.
Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
« Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
À la maison comme au bureau, j'utilise la suite Linux Mageïa !
Bonjour CinePhil.
Merci à toi pour toutes ces remarques pertinentes. J'essayerai de faire une prochaine version qui en tient compte (quand j'aurais un peu de temps).
Alors ça a peut être changé depuis mais on m'a appris qu'on avait 2A et 2B pour les Corses nord et sud et qu'on avait des codes-postaux de type 2A005 ... on m'a peut être raconté n'importe quoiJe crois que c'est faux. Au hasard, j'ai cherché le code postal de Bastia et ce site m'a affiché 20200.
Par contre, c'est peut-être vrai à l'étranger.. Il est possible aussi que cela ait été simplifié par la suite (comme le cas du 75016 et 75116 à Paris
). Bref, j'évincerai la remarque sur la Corse vu que ce n'est pas non plus le but du tutoriel.
En effet le dictionnaire des données à aussi pour vocation à servir au différents mainteneurs d'une base ... il est donc préférable qu'il conserve toutes le données y compris les données nécessaires comme les id mais qui ne sont pas explicitement mentionnée par les RGM.Tu y fais figurer les identifiants qui ne font pas partie des propriétés figurant explicitement dans les règles de gestion. Ce dictionnaire de données est donc déjà une réflexion sur la structure technique de la future BDD.
C'est faisable, j'y ai pensé, mais bon par soucis de simplicité (et non de pertinencePourquoi alors n'avoir pas externalisé la ville, ce qui devrait être aussi une adaptation des règles de gestion ?
Oui, j'essayerai de refaire une passe là dessusLa taille du type Date me semble inutile puisque c'est le SGBD qui va décider de quelle façon ce type est implémenté. Par contre, distinguer les types Date, Heure et Date/heure me semblerait utile.
En effet, il s'agit de l'éditeur ou la maison d'édition. Pour éviter toute ambigüité, je le remplacerai par "éditeur"Il y a une légère ambiguïté dans la signification du terme "édition".
S'agit-il d'une référence à l'éditeur du livre ou du numéro de l'édition chez l'éditeur du livre ? Un livre peut en effet connaître plusieurs éditions, au sens de parution, au fil des ans, chez le même éditeur, parfois avec des mises à jour ("nouvelle édition revue et augmentée par l'auteur").
adrel = adresse E-mail ?[...]Dans le même ordre d'idée, 20 caractères pour la ville est insuffisant et 40 caractères pour une adrel risque de l'être également, ainsi que 50 caractères pour le titre d'un livre, nom d'un pays...)
Sinon oui, j'adapterai les tailles. (50 pour la villes, 100 pour l'E-mail par exemple et 30 pour les noms/prenoms).
Oui souvent je me sert de id_... ou num_... pour désigner un identifiant. Ceci dit, mieux vaut rester homogène, donc à adapter également (faudra refaire tout les MCD5) Identifiant d'un type de livre
Pourquoi ne pas avoir appelé cette propriété "id_t" puisqu'il s'agit d'un identifiant ?
Idem pour l'identifiant de l'édition, identifiant de l'emprunt...
En effet, je voulais aussi au départ parler du taux de TVA (pour un montant TTC) qui risque de varier, ce genre de chose. Je me suis dit que c'était un peu trop rentrer dans le détail. Ceci dit tu as parfaitement raison, la raison évoquée est largement prioritaire à l'optimisation ... donc j'adapterai ma remarque.La raison pour laquelle le montant d'une commande doit être enregistré est que les montant des éléments constitutifs de la commande (les produits et services vendus) peuvent changer après émission de la commande. Si j'achète un produit à 10 euros HT et qu'on me le facture 10,50 euros parce que prix a évolué entre le moment de la commande et la date de livraison, je ne vais pas être d'accord ! Il peut, de plus, y avoir des remises accordées pour une commande, ce qui fait qu'on ne peut pas retrouver le montant de la commande à partir du prix tarif des produits achetés.
Mais la commande est un bon exemple de donnée calculée à stocker.
Vu de cet angle, tu as tout à fait raisonJe dirais plutôt une "donnée numérique" Et je préciserais avec des exemples : Code postal ou tout autre code numérique, références, numéros d'ordre, de série, de chapitre...
D'où l'importance de ne pas nommer "num" un identifiant technique.
C'est exactement ça , d'où la définition du tuto :Leur syntaxe est toujours demeurée pour moi confuse mais il me semble avoir compris que P1 → P2 signifie "P1 détermine P2"
Ce qui revient à dire "détermine"Envoyé par tutoriel
Quand on a l'habitude, elles sont instinctives. Leur notation "algébrique" n'est pas indispensable donc aucun soucis à te faire la dessus.Ce n'est pas ma tasse de thé et, à vrai dire, je ne les utilise jamais.
C'est vrai, je crois que je vais simplement garder le terme "lien sémantique".J'évite absolument le terme "relation" pour signifier une association entre deux entités, afin d'éviter toute confusion avec les relations de la théorie relationnelle.
En effet, le VARCHAR permet, à ma connaissance, de n'allouer en mémoire que ce dont il a besoin (corriges moi s'il le fautLes longueurs des VARCHAR ne correspondent pas aux longueurs de ton dictionnaire de données !
Et cette fois, elles sont pour la plupart un peu longues !
EDIT : Instinctivement, je pensait la même chose mais cela peut être aussi une traduction de la cardinalité 1,1 même si l'intérêt est réduit (cela permet notamment d'avoir des données portées par une association ayant une cardinalité de type 0/1,N même si ça ne se fait pas tropJe suis d'accord avec le fait que des cardinalités 1,1 de chaque côté de l'association binaire n'entraînent pas obligatoirement la fusion des entités, notamment pour des raisons sémantiques. Par contre, cette structure :
signifie pour moi qu'elle est issue de ce MCD :Pays ( nom_p )
Auteur ( id_a , nom_a, prenom_a, date_naissance_a)
EtreOriginaireDe ( id_a # , nom_p #)
Auteur -0,1----être_originaire_de----0,n- Pays
Je me suis préparé psychologiquement à sa venue en écrivant cette partiefsmrel va probablement sortir sa sulfateuse contre le bonhomme NULL.). C'est pourquoi j'ai essayé de trouver un compromis entre les deux.
Bref, je l'ai quand même souligné
Je n'avais pas rencontré cette notation jusqu'à maintenant. Sinon, bien que je présente les deux notations, je ne suis pas fan non plus des agrégations et préfère les représenter sous forme de CIF (mais comme ça existe, je préfère en parler).Si on veut en rester à la représentation qui autorise à faire pointer une association sur une association, je préfère alors la représentation qui entoure l'association pointée d'un rectangle, comme dans les schémas fournis dans cette discussion par dark123.
Je suis comme toi, j'ai appris à le faire de manière textuelle. Et je préfère cette notation car elle se rapproche plus des CREATE TABLE en SQL. J'avais toutefois écrit cette remarque :Pour le MLD, il existe aussi un schéma, que personnellement je n'aime pas beaucoup, qui symbolise les liens entre les tables (non je n'aime pas le terme de "relation" ! ) par des flèches. C'est du moins celui qui m'a été enseigné au CNAM pour la méthode Merise.
Je lui préfère le schéma "entity/relationship" que l'on trouve notamment en standard dans MySQL Workbench, mais aussi dans Open Modelsphere lorsque l'on génère le MLD à partir du MCD.
J'assimile plus la représentation en liste de tables avec leurs colonnes, comme tu le pratiques dans cet article, au MPD, même s'il y manque les types des colonnes.
J'ai préféré ne pas rentré dans le détail, ne maitrisant pas bien ces modèles graphique bien que je les comprends en les voyants.
Merci beaucoupDommage que je n'ai pas vu cet article avant, lors de sa soumission pour lecture critique. Mais globalement, et malgré toutes mes remarques, il est assez complet et d'un bon niveau tout en restant simple et clair ; bravo pour ce bon boulot !.
Cordialement,
Idriss
EDIT 2 : Une partie des remarques ont été prises en compte, je m'occuperai de la suite plus tard. Encore merci
Bonjour,
Le paragraphe III-B sur les formes normales ne donne pas les définitions exactes des 1NF, 2NF et 3NF.
Je préconise de renommer ce paragraphe "Règle de vérification et de normalisation".
Ces termes sont ceux utilisés à l'origine de Merise. Seul deux règles étaient énoncées à l'époque, une pour la vérification, et une pour la "normalisation".
Tel que c'est formulé dans votre cours ok.Idriss, vous mélangez Merise et le MRD. Mieux vaut ne pas parler de relation, attribut, forme normale, etc.
Trop d'abus ont été fait en la matière dans le passé, à tel point que notre jargon est aujourd'hui imprécis (une relation est une association ou une table ??).
On peut constater dans la littérature spécialisée que cette erreur est commise depuis des lustres. Il serait de bon ton de ne pas refaire les erreurs du passé.
Par ailleurs, concernant l'héritage, je pense avoir trouvé une coquille. Tel que c'est formulé, les héritages X et XT sont les mêmes.
§ IV-B-1. L'héritage par disjonction :
En fait, certaines occurrences du sur-type peuvent ne pas être présentes dans les sous-types.Toutes les occurrences du sur-type ne peuvent se trouver que dans un et un seul sous-type.
Ainsi, dans votre exemple, une personne peut-être un "Inscrit" ou un "Auteur" ou une autre personne.
Et dernière chose, je trouve dommage de parler d'entité au lieu d'entité-type. Ce n'est pas la même chose, et même si notre jargon mélange ces deux termes, il serait souhaitable de modifier nos mauvaises habitudes. Je peux comprendre qu'à l'orale on simplifie notre vocabulaire, mais dans un cours hébergé sur un site professionnel, cela me gène.
Personnellement je peux m'en accommoder, mais un étudiant qui débute en informatique risque d'être perturber.
Une entité est une occurrence d'entité-type.
Et au sens propre, les occurrences d'une entité, ça n'existe pas.
Cordialement,
En effet, de plus, le format de date (JJJJ-MM-AA par exemple) n'a pas de sens au niveau SGBD, c'est un choix de présentation, hors dictionnaire de données donc
D'accord sur le principe, mais pas pour le choix de l'exemple, car le nom marital et le nom de naissance sont bien deux données atomiques différentes qu'il convient de stocker dans 2 colonnes de base de données différentes
On parle de plus en plus de "nom d'usage", plutôt que de "nom marital" et il est de plus en plus fréquent que des personnes, même non mariées - des enfants de concubins par exemple - aient un nom d'usage composé du nom de leurs deux parents.D'accord sur le principe, mais pas pour le choix de l'exemple, car le nom marital et le nom de naissance sont bien deux données atomiques différentes qu'il convient de stocker dans 2 colonnes de base de données différentes
Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole, en retraite... mais toujours Autoentrepreneur à l'occasion.
Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
« Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
À la maison comme au bureau, j'utilise la suite Linux Mageïa !
Répondre avec citation
Partager