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 !
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,
Bonjour.
Pour l'héritage par disjonction :
Tout à faitEn fait, certaines occurrences du sur-type peuvent ne pas être présentes dans les sous-types.
Ainsi, dans votre exemple, une personne peut-être un "Inscrit" ou un "Auteur" ou une autre personne.
Pour le reste, étant donné qu'il s'agit d'un tutoriel d'initiation et que c'est aussi de cette façon que cela m'avait été enseigné, je ne préfère pas trop rentrer dans la distinction MLD / modèle relationnel (je trouve personnellement que ça n'a pas d'intérêt).
En effet, le cours à pour but de rendre opérationnel à la réalisation de bdd relationnel avec comme outil d'aide à la conception : Merise ... il ne s'agit pas d'un cours approfondis sur les différents modèles de Merise pour en devenir spécialiste.
Pour les mêmes raisons, j'en suis resté aux termes de clefs primaires et étrangères qui sont plus parlants ...
Pour avoir suivi des formations différentes (BTS IG, EICNAM SI, etc) et pour m'être renseigné sur d'autres contenu de cours récents sur différentes universités ou iut (on les retrouve sur Google), tout les termes employé dans ce tuto ne prêteront pas à confusion. On retrouve toujours les termes d'entités / associations au niveau conceptuel et relation au niveau relationnel ou logique ... c'est ce qui est le plus rependu.Personnellement je peux m'en accommoder, mais un étudiant qui débute en informatique risque d'être perturber.
Pour les termes d'entités et d'entités-types ... je trouve encore une fois que c'est faire beaucoup trop de zèle (on ne rédige pas un bouquin
Pour les formes normales pareil, il s'agit simplement de les introduire et non d'en faire une définition exacte. Il y a déjà un tutoriel détaillé sur les formes normale qui plus est (chacun sa finalité).
Je ne suis pas d'accord avec cette vision. Au contraire, on est beaucoup plus strict en conception ainsi que dans le jargon technique dans les grandes formation études (je ne parle pas des DUT/BTS ou L1/L2) que dans l'entreprise où l'aspect métier prime (et où l'informatique n'est qu'un outil au service de problématiques métiers). En plus Merise est largement moins rependu qu'UML dans le monde professionnel (si je l'ai choisit c'est parce que je le trouve plus adapté pour s'initier aux bdds relationnelles car elle met plus en avant les problématiques de contraintes d'intégrité et d'identifications, ce genre de choses). C'est un autre débat.Je peux comprendre qu'à l'orale on simplifie notre vocabulaire, mais dans un cours hébergé sur un site professionnel, cela me gène.
Bref, tout ceci est mon opinion ... et je ne met pas en doute la justesse de vos remarques.
EDIT : petite mise à jour pour la partie sur l'héritage X ...
Cordialement,
Idriss
Bonsoir,
Vous avez tort, la distinction doit être faite. Le MLD est une représentation textuelle ou graphique de la structure des relations (tables en SQL) et de certaines contraintes à respecter (clés, intégrité référentielle pour faire court). Le modèle relationnel (Relational Model) pour sa part est une théorie (une branche des mathématiques appliquées), sur laquelle repose la technologie relationnelle :
1. Une collection non limitée de types scalaires (dont notamment le type booléen (valeur de vérité)) ;
2. Un générateur de type Relation et l’interprétation attendue des types de relations générés par ce moyen ;
3. Les mécanismes pour définir des variables relationnelles du type de relation voulu ;
4. L’opération d’affectation relationnelle permettant d’affecter des valeurs de relations à ces variables ;
5. Une collection non limitée d’opérateurs relationnels génériques (« l’algèbre relationnelle »), pour produire des valeurs de relations à partir d’autres valeurs de relations.
Quand le MLD sera doté d’opérateurs et d’une algèbre, on pourra rediscuter de la distinction que vous trouvez aujourd'hui sans intérêt. A défaut, contentez-vous de parler du MLD.
Je suis d'accord, ce ne sont pas tous les termes qui prêtent à confusion dans votre article, mais seulement certains. Vous auriez eu intérêt à le faire relire.
Faux.
Dans leur ouvrage de référence (La méthode Merise, tome 1, principes et outils), Tardieu Rochfeld et Colletti parlent de types et rappellent qu'un type est une classe : ils mettent donc en évidence le type d’individu (ou entité-type), le type de relation (ou relation-type), le type de propriété (ou propriété-type).
D’autres grands, Nanci (un des pères de la méthode) et Espinasse parlent aussi d’entité type, de relation type et de propriété type (Ingénierie des systèmes d’information : Merise deuxième génération).
Dans son ouvrage majeur, De l’autre côté de Merise, le grand Yves Tabourier utilise lui aussi les expressions individu type et relation type. Incidemment, pour marquer la différence avec le modèle Entité/Relation de Chen, Tabourier traite du « formalisme individuel », d’où l’emploi du terme individu).
Si des auteurs de moindre importance et peu attentifs ont fait — ou entretenu — la confusion entre type d’entité et entité, ça n’est pas pour autant qu’il faille les imiter, même s’ils sont légion. La remarque reste valable quand il est arrivé à des ténors comme Tabourier et Nanci d'oublier à l’occasion d’accoler le terme « type ».
Rester clair et simple, oui, c’est la moindre des choses, mais entretenir la confusion, non. Un minimum de rigueur s’impose, même — et surtout — quand on ne cherche pas à entrer dans les détails. Ça n’est quand même pas compliqué de préfixer ou suffixer « entité » par « type » et donc utiliser par exemple le terme entité-type lequel, je le rappelle, correspond à la classe, alors qu'une entité n’est qu’une instance : une instance n’étant pas une classe, une entité n’est pas non plus une classe et n'est donc pas un type. Si l’on vous suivait, on pourrait écrire « aa » et, débouler dans le paradoxe de l’ensemble de tous les ensembles qui a fait si mal à Frege. Quant aux relations-types et propriétés-types, on peut abréger, a priori sans risque.
Ça n’est pas pour autant qu’il faille propager des définitions alambiquées ou fausses.
Quand je lis ceci :
La classification de ces trois premiers niveaux de normalisation repose sur les dépendances fonctionnelles entre la clef primaire de la relation et ses autres attributs.Vous n’êtes pas sans savoir qu’il faut remplacer (à la 1NF près) « la clé primaire » par « chaque clé candidate », ça n’est quand même pas sorcier. Quant à la définition de la 1NF, bien qu’i soit possible de se baser sur les DF, préférez reprendre ce que dit très simplement Chris Date dans ses nombreux écrits (idem pour Jeff Ullman), je traduis :Serait-ce si difficile à comprendre de la part des néophytes ?
Si l’on représente une relation sous forme tabulaire, à l’intersection d’une ligne et d’une colonne (c'est-à-dire dans une « cellule ») on a exactement une valeur.
Au besoin, quand vous voulez être plus formel, voyez ici : Pour conclure avec la première forme normale.
Désolé, mais c'est MacFly qui a raison. Quand on publie un article portant sur la conception des bases de données relationnelles, on se doit d’être rigoureux et éviter les imprécisions. En ce sens, quand on lit un ouvrage technique ou un roman, s'il y a trop de fautes d’orthographe et de syntaxe, on ne peut plus avoir une lecture suivie, fluide, on est agacé, le fil casse. A leur tour, vos imprécisions peuvent perturber le lecteur, l'agacer, et pire, l’induire en erreur.Je ne suis pas d'accord avec cette vision. Au contraire, on est beaucoup plus strict en conception ainsi que dans le jargon technique dans les grandes formation études (je ne parle pas des DUT/BTS ou L1/L2) que dans l'entreprise où l'aspect métier prime (et où l'informatique n'est qu'un outil au service de problématiques métiers).
Vous parlez du monde de l’entreprise : l’aspect métier prime, c’est normal ; par exemple un assureur parle d’assurance, l’informatique n’est pas son métier, mais il a besoin de l’informaticien (sinon on remet les compteurs à zéro et on revient en 1930).
L’informatique est un outil dites-vous, on est bien d’accord, mais quel outil ! Je suis informaticien, un « artisan » ayant passé près de quarante ans en entreprise, dans tous les secteurs d’activité, dont trente ans à modéliser à tous les niveaux et astreint à mettre en production le fruit de mon travail pour des applications exploitables de façon satisfaisante par les utilisateurs (sinon gare aux pénalités financières...) ; aussi ai-je toujours été très vigilant quant à la complétude et la validité des règles de gestion des données, exprimant les besoins de la maitrise d’œuvre des entreprises. Il est évident que l’aspect métier prime, mais si la maîtrise d’œuvre produit un travail incomplet, mal formulé (règles de gestion), que croyez-vous qu’il advient ? Garbage in, garbage out, l’échec est garanti, à répétition, et pour un bon moment (ça peut-être pour des années, j’en témoigne). Dans ce genre de situation, ce sont les artisans, à savoir les spécialistes de la modélisation et des bases de données qui doivent prendre le relais et aider les chefs de projet à arracher les règles de gestion correctes et complètes auprès de la MOE. Dans dix ans, la maturité et l’expérience aidant, vous finirez par être d’accord avec ce que j’écris aujourd’hui.
A propos des « grandes formations études » (quèsaco ?) et pour la petite histoire : je n’ai pas suivi de cours d'un tel niveau et pour cause, car par exemple les MIAGE ne sont nées qu’en 1969 et à l'époque je n'étais plus un perdreau de l'année, loin s’en faut... Au demeurant je suis un informaticien, quelque part un autodidacte de la modélisation et des bases de données, mais ça ne m’a jamais empêché de vouloir à tout prix éviter de transmettre — ne serait-ce que chez DVP aujourd'hui — des informations floues ou erronées, je fais mon possible pour rester rigoureux et suivre les bons auteurs, tout comme — ne serait-ce que par respect pour le lecteur — j’essaie de commettre le moins de fautes d’orthographe possible (d’expérience, on en trouvera encore et toujours dans ce que j’écris, mais bon).
MacFly parle de modifier les mauvaises habitudes. En relation avec ce qu'il écrit, votre appréciation (au demeurant non étayée) n'a rien à voir, à moins que vous ne considériez Merise comme une mauvaise habitude.
A propos de rigueur et Cie :
Page 2 de votre article (que j’ai survolé), par référence à cette partie de la FAQ Merise, vous pouvez déjà remplacer « ministère de l’intérieur » par « Ministère de l’Industrie » (avec les majuscules tant qu’à faire). Pour mémoire, cette partie a été rédigée par Dominique Nanci, l’un des pères de Merise, donc connaissant la méthode mieux que nous tous réunis.
Bonne continuation.
Bonjour fsmrel et merci de votre réponse.
Tout d'abord, je retiens à préciser que je ne mets pas en doute les dire de MacFly58 (et les vôtres bien sûr). Je suis parfaitement conscient que vous maitrisez 100 fois plus le sujet que moi.
Toutefois j'ai peur d'avoir été mal compris :
Non, je ne considère pas du tout Merise comme une mauvaise habitude. Au contraire je la trouve plus adaptée au niveau des schémas de bases de données. Je souhaitais simplement (et maladroitement peut être) faire comprendre que je trouve que c'est un peu exagéré d'en venir à dire que c'est "gênant" sur un site de professionnel (alors qu'au contraire on est plus rigoureux dans ce domaine, à titre exceptionnel dans les grandes formations d'étude... je parle en général, je me doute que ce n'est pas votre casà moins que vous ne considériez Merise comme une mauvaise habitude
Ah mais je ne parlais pas des ouvrages de référence... je parle simplement des supports de cours actuels (dans les universités ou autres). Je suis parfaitement conscient que le terme exact est "entité-type", "association-type". Je pense simplement qu'il n'est pas utile de rentrer dans ces détails. Comme la majorité semble contre, je vais donc adapter le cours quand j'aurais le temps, en mettant par exemple une remarque au début comme je l'ai fait pour les clefs primaires et étrangères :Faux.On retrouve toujours les termes d'entités / associations au niveau conceptuel
Dans leur ouvrage de référence (La méthode Merise, tome 1, principes et outils), Tardieu Rochfeld et Colletti[...]
Ce qui répond à ceci :
La partie sur les FN ne donne pas de définitions, mais donne simplement un aperçu technique permettant de vérifier la validité de notre conception. Je ne souhaitais pas faire un cours complet sur les FN, ne maîtrisant pas moi même le sujet à votre niveau. Pour ne pas trop vous décevoir (Vous n’êtes pas sans savoir qu’il faut remplacer (à la 1NF près) « la clé primaire » par « chaque clé candidate », ça n’est quand même pas sorcier [...]
- changer le titre "le formes normales" en "Règle de vérification des niveaux de normalisation" un peu comme ce qu'avait proposé MacFly58
- adapter le contenu à peu près comme ceci :
Là j'espère que ce ne sera plus perçu comme des définitions...Pour être en première forme normale (1FN ou 1NF) : les attributs d'une relation doivent être en dépendance fonctionnelle avec la clef primaire de cette dernière.
Pour être en deuxième forme normale (2FN ou 2NF) : il faut être en 1FN et que toutes les dépendances fonctionnelles entre la clef primaire et les autres attributs de la relation soient élémentaires. Autrement dit, les attributs doivent dépendre de la totalité de la clef.
Pour être en troisième forme normale (3FN ou 3NF) : il faut être en 2FN et que toutes les dépendances fonctionnelles entre la clef primaire de la relation et les autres attributs soient directes.
Pour ce qui du MLD vs MRD : je ne parle que du MLD avec un modèle textuel représentant relations et contraintes donc, je ne devrait pas à ce point faire une confusion.
C'est exactement ce qui est fait dans le cours.Le MLD est une représentation textuelle ou graphique de la structure des relations (tables en SQL)
Et c'est tout à fait honorable de sa part. Pour ma part, je souhaitais rester en rapport avec ce qui est globalement enseigné aujourd'hui.MacFly parle de modifier les mauvaises habitudes.
Je vais encore murir ma réflexion, bien que je pense qu'en l'état le cours est "acceptable" et praticable. Il s'agit encore une fois d'une initiation dont le but est atteint (être opérationnel au niveau de la conception et la réalisation de bdd) et qui n'a pas pour vocation à remplacer les ouvrages de référence... pardonnez mon manque de rigueur.
Page 2 de votre article (que j’ai survolé), par référence à cette partie de la FAQ Merise, vous pouvez déjà remplacer « ministère de l’intérieur » par « Ministère de l’Industrie » (avec les majuscules tant qu’à faire). Pour mémoire, cette partie a été rédigée par Dominique Nanci, l’un des pères de Merise, donc connaissant la méthode mieux que nous tous réunis.
Bref merci à vous deux
Bonsoir,
Vous souhaitez simplifier la modélisation, c'est louable, mais alors pourquoi s'obstiner à vouloir parler de formes normales ?
Les formes normales ne font pas partie de Merise. C'est vous qui compliquez les choses en utilisant un vocabulaire impropre.
Ne vous en déplaise, ce sont bel et bien des définitions, et elles sont fausses.- Adapter le contenu à peu près comme ceci :
Là j'espère que ce ne sera plus perçut comme des définitions ...Citation:
Pour être en première forme normale (1FN ou 1NF) : Les attributs d'une relation doivent être en dépendance fonctionnelle avec la clef primaire de cette dernière.
Pour être en deuxième forme normale (2FN ou 2NF) : Il faut être en 1FN et que toutes les dépendances fonctionnelles entre la clef primaire et les autres attributs de la relation soient élémentaires. Autrement dit, les attributs doivent dépendre de la totalité de la clef.
Pour être en troisième forme normale (3FN ou 3NF) : Il faut être en 2FN et que toutes les dépendances fonctionnelles entre la clef primaire de la relation et les autres attributs soient directes.
Si vous les appelez règles 1, 2 et 3, alors ce passage devient acceptable.
Si vraiment vous tenez absolument à parler de formes normales, alors veuillez préciser dans votre document que les définissions que vous en donnez sont inexactes.
Vous souhaitez répandre la parole admise par le plus grand nombre, je peux le comprendre, mais vous pourriez comprendre que le plus grand nombre à tord. Oui les enseignants et les universitaires ont tord, et je considère qu'il est du devoir de developpez.com de corriger ces erreurs.Pour ma part, je souhaitais rester en rapport avec ce qui est globalement enseigné aujourd'hui.
J'accepte qu'un étudiant (brillant) rédige un cours, mais n'a-t-il pas le devoir de le faire valider par ses pairs (fsmrel, pas moi) avant de le diffuser sur le net ?
OufJe vais encore murir ma réflexion
Il est praticable mais pas acceptable.je pense qu'en l'état le cours est "acceptable" et praticable
Quel est l'intérêt de faire croire à quelqu'un qu'il sait ce qu'est une forme normale alors qu'il ne le sait pas ?
Oui ce cours sur developez.com me gène (et ce n'est pas le seul).
Mais il est très facile de le rendre acceptable, donc pourquoi s'en priver. De plus ce cours sera simplifié. Le terme "forme normale" est bien barbare pour le néophyte, tandis que le terme "règle" est simple.
Concernant le terme entité, je tiens à dire une chose.
Vous savez que pour modéliser, surtout au début, nous avons besoin de réfléchir avec des occurrences (ou instances) d'entité-types, car cela rend les choses concrètes et plus simple.
Le terme entité ne vient pas de l'informatique mais du français, et si l'on demande à un étudiant de prendre une instance d'entité, logiquement il ne doit rien comprendre (s'il a deux sous de jugeote).
Par exemple, donnez-moi une occurrence de l'entité ok.Idriss ?
(en français, ok.Idriss est une entité, une personne prise en tant qu'individu)
N'est-ce pas incompréhensible pour une âme bien faite ??
A moins que vous ne souffriez d'un dédoublement de la personnalité, cela devrait vous sembler évident (je plaisante ici bien sur).
Voila mis en évidence le trouble qui se répand dans les esprits éclairés.
Et pour les étudiants qui ne s'intéressent pas trop aux cours, leurs parler d'entité ou d'entité-type revient au même vu qu'ils ne comprennent aucun de ces deux mots.
Enfin bref, si vous devez écrire un cours, ne suivez pas le troupeau, guidez le.
Bien cordialement,
PS : Je n'ai pas lu tout votre document, et je dois avouer que j'hésite à le faire.
Bonsoir,
Une bonne raison pour tenir compte de nos observations.
Rien compris.
Si les supports de cours actuels sont peccamineux, pourquoi reprendre et propager leurs erreurs ? Appuyez-vous sur les ouvrages de référence, en les citant pour ne pas vous attirer des reproches infondés.
Ça ne répond en rien. Une clé primaire pourrait avoir des propriétés en propre, non partagées par les clés alternatives. Par exemple, en SQL les attributs qui appartiennent à une clé alternative peuvent être marqués Null (horresco referens!), ce qui est interdit en ce qui concerne les attributs appartenant à une clé primaire. Si l’on vous suivait, tout ce qui vaut pour une clé primaire vaudrait aussi pour les clés alternatives, donc celles-ci ne pourraient pas être marquées Null (tout en notant que Null est hors-la-loi en relationnel pur).Ce qui répond à ceci :
Vous n’êtes pas sans savoir qu’il faut remplacer (à la 1NF près) « la clé primaire » par « chaque clé candidate », ça n’est quand même pas sorcier [...]
Bien sûr que si.
Pour éviter les confusions et amalgames, rappelez-vous que ce sont les bases de données relationnelles qui sont composées de relations, un MLD n’est composé que de schémas de relations, sous forme textuelle ou graphique. Une relation est une valeur qu’on affecte à une variable relationnelle. Il n’y a qu’avec le Sorry Query Language qu’on amalgame variable et valeur, sous le nom de table. En tout état de cause, je vous suggère de remplacer ci-dessous relation par schéma de relation :
Il y a certes du travail, c’est bien, mais tout le monde ne pense pas comme vous. Murissez et écoutez, une mise à niveau ne devrait pas vous coûter des efforts insurmontables.
N.B. Au paragraphe II-A n’hésitez pas à remplacer « science fixions » par « science fiction »...
Bonjour.
J'ai fait une première mise à jour prenant en compte les principales remarques (il me reste encore les noms des identifiants de certaines entités comme l'a fait remarqué CinePhil pour plus de cohérence).
J'ai fait mon possible pour faire comprendre qu'il ne s'agissez pas de définitions précises des FN en changeant le titre et en mettant un warning :
Pour les entités-type j'ai également ajouté une petite remarque :Il ne s'agit pas de définitions précises mais de simple règles de vérification des trois premiers niveaux de normalisation.
Pour plus de détails sur ces formes normales, vous pouvez consulter ce cours.
C'est pas encore figé mais au moins, ça sera peut être plus acceptable comme ça dans un premier tempsAu niveau conceptuel, on devrait plutôt parler d' entités-types et d' associations-types , les entités et associations étant en fait des instances des entités-types et associations-types. Par soucis de simplicité, on gardera les termes d'entités et associations tout au long du cours.
Sinon, concernant les remarques sur la relecture du tutoriel. L'article à bien été relu (et est resté longtemps en relecture, il n'y a qu'à lire la partie remerciements), simplement Merise n'est pas très à la mode chez les relecteurs actifs et ils n'ont pas forcement votre niveau dans ce domaine ... j'essayerai à l'avenir d'envoyer un MP à fsmrel et CinePhil si ça ne les déranges pas
Bon encore merci à vous deux
Salut
François, si je peux me permettre....
Je crois qu'il serait mieux de trouver une définition simple, proche de la vérité et acceptée par la majorité plutôt que de parler de "règle".
... et les éditeurs de logiciels de conceptions (poweramc, win'design, openmodelsphere...). Croyez-vous qu'il est possible d’arrêter cette épidémie?
Je suis d'accord avec cette propostion. Si on pouvait mettre en place une sorte de vote de cinq experts pour la validation des articles cela éviterait beaucoup de problèmes.
bien dit
J'ai un peu chercher à comprendre ce problème et voici une conclusion que j'ai trouvé sur wikipedia...
que google traduit par...
Code : Sélectionner tout - Visualiser dans une fenêtre à part An entity, strictly speaking, is an instance of a given entity-type. There are usually many instances of an entity-type. Because the term entity-type is somewhat cumbersome, most people tend to use the term entity as a synonym for this term.
Une entité, à proprement parler, est une instance d'une entité-type donnée. Il y a généralement de nombreux cas, d'une entité-type. Parce que le terme entité-type est un peu lourd, la plupart des gens ont tendance à utiliser la notion d'entité comme un synonyme de ce terme.du courage et fais nous profiter de tes remarques.
Bonjour et merci ok.Idriss pour ce tuto que je prendrais plaisir à lire sérieusement.
Je voulais juste apporter une petite précision sur les codes postaux Corses que je connais bien. La Corse n'utilise aucune lettre dans ses codes postaux. Ils sont bien au format 20 XXX que ce soit pour le nord ou pour le sud.
En revanche, le code INSEE des communes corses est bien au format 2A XXX ou 2B XXX. Pour ceux qui ne connaissent pas, il s'agit d'une liste annuelle de toutes les communes françaises établie par l'INSEE qui leur attribut un numéro unique. Cette liste est très souvent utilisée dans les administrations.
Bonsoir.
@ GeoTrouvePas : Merci de la précision. De toute façon j'ai retiré l'exemple de la Corse n'étant pas le sujet principal du cours ...
C'est en partie pour ça que j'étais réticent ... j'avais peur d'être trop marginal. Bien que je comprenne que ça provoque l'indignation des experts. Actuellement on crierai de la même façon si quelqu'un faisait la confusion entre objet (instance de classe) et classe. Mais bon pour les entités et associations, c'est rentré dans les usages et on voit même parfois des ambiguïtés avec les relations (non le tuto ne fait pas de confusion à ce niveau... et les éditeurs de logiciels de conceptions (poweramc, win'design, openmodelsphere...). Croyez-vous qu'il est possible d’arrêter cette épidémie?
Le processus de relecture est très bien tel qu'il est. De plus tout ceux qui ont rédigé quelque chose y ont accès (ce qui me parait normal). Pour le cas de cet article, il est également passé par cette étape dans les règles de l'art et a même été relus par des enseignants. Il faudrait donc arrêter de critiquer le processus de relecture simplement parce que quelques usages admis ne plaisent pas. Attention je ne dis pas qu'il ne faut pas donner son avis sur un article mais qu'il faut arrêter de remettre en cause l'équipe de rédaction. C'est un autre débat qui n'a pas lieu d'être ici.Je suis d'accord avec cette propostion. Si on pouvait mettre en place une sorte de vote de cinq experts pour la validation des articles cela éviterait beaucoup de problèmes.
Cordialement,
Idriss
Bonsoir,
Je ne peux décemment pas cautionner ce cours d'initiation tel qu'il est rédigé.
Merci de le modifier plus en profondeur.
J'ai volontairement supprimé la fin de cette contribution, car j'ai peur d'être trop percutant.
Bien cordialement,
Entité type ou entité
Pour la petite histoire, quand j'ai commencé à pratiquer le métier de qualiticien en 1992, nous appliquions encore la version 1987 de la famille des normes ISO 9000 et le terme qui y était alors employé était "entreprise". En cherchant un terme plus générique que "entreprise", j'avais adopté le terme "entité". Dans mon esprit il s'agissait alors d'une abstraction pour désigner aussi bien une entreprise qu'une administration ou une association. Ce n'est, si ma mémoire est bonne, qu'avec la version 2000 que le terme générique "organisme" a remplacé celui plus restrictif "entreprise" dans les normes ISO 9000.
Je pense que tout le monde sera d'accord pour dire que le terme le plus employé pour nommer ce qui est représenté par des rectangles dans les MCD est bien "entité" et non pas "entité-type".
Cependant, je comprends les arguments de fsmrel qui prêche la bonne parole et nous cite les références historiques en faveur de "entité-type". L'intégration dans le cours de ok.Idriss d'un texte inspiré de celui cité par alassanediakite ne pourrait-il pas réconcilier tout le monde ?
Je trouve d'ailleurs le texte proposé par ok.idriss tout à fait acceptable :Une entité, à proprement parler, est une instance d'une entité-type donnée. Il y a généralement de nombreux cas, d'une entité-type. Parce que le terme entité-type est un peu lourd, la plupart des gens ont tendance à utiliser la notion d'entité comme un synonyme de ce terme.
Nos frigos font aussi bien, sinon mieux, du froid que les anciens réfrigérateurs et cela fait bien longtemps que nous avons tous abrégé le cinématographe en cinéma. Est-ce donc si grave d'appeler "entité" ce qui devrait être appelé "entité-type" ?Au niveau conceptuel, on devrait plutôt parler d' entités-types et d' associations-types , les entités et associations étant en fait des instances des entités-types et associations-types. Par soucis de simplicité, on gardera les termes d'entités et associations tout au long du cours.
La confusion courante entre la relation du modèle relationnel et l'association du MCD est bien plus gênante !
Formes normales
Puisque ce cours s'annonce comme une initiation, il serait plus sage d'éviter ces notions quelque peu complexes et simplement mentionner l'existence de la théorie relationnelle, des formes normales, en citant l'encyclopédie de fsmrel pour ceux qui voudraient approfondir le sujet.
Je supprimerais également la partie sur les dépendances fonctionnelles.
Personnellement, je suis me passe de l'algèbre relationnelle et des définitions des formes normales et il me semble que les MCD que je propose dans nos forums ne sont pas pourtant généralement pas loin d'une normalisation optimale.
=================
Après une relecture rapide et partielle, il me semble tout de même qu'il reste des choses à corriger dont j'avais fait la remarque dans mon premier message et qui sont à mon sens plus ennuyeuses que le débat entité contre entité-type.
Bonjour CinePhil.
Merci de ta réponse. Oui je n'ai pas encore intégré toutes tes remarques mais c'est prévu comme je l'ai dit plus haut (il faut que je prenne le temps et ça nécessite une modification des schémas)
Pour la petite partie sur les DF, je pense quand même qu'il faut les introduire notamment pour expliquer certaines règles de conversions, la définitions des entités, les CIF, etc. Après oui une majorité d'entre elles sont instinctives et créer des MCD directement à partir des RGM devient un automatisme.
Sinon je trouve aussi que la remarque ajoutée est largement suffisante et que c'est très loin d'être ce qu'il y a de plus important dans ce cours.
Cordialement.
Idriss
Bonsoir,
Frigo et réfrigérateur, c'est la même chose.Nos frigos font aussi bien, sinon mieux, du froid que les anciens réfrigérateurs et cela fait bien longtemps que nous avons tous abrégé le cinématographe en cinéma. Est-ce donc si grave d'appeler "entité" ce qui devrait être appelé "entité-type" ?
Cinématographe et cinéma, ou même ciné, c'est la même chose.
Entité et entité-type, ce sont deux concepts différents qui sont utilisés dans Merise. Et vous préconisez de les mélanger pour faire comme tout le monde, super.
Si je suis votre raisonnement CinePhil, une ligne est un enregistrement, et une colonne est un champ. Le terme est couramment utilisé par certains...
Il m'avait semblé que vous militiez pour que les gens ne mélangent pas tout. Et vous avez raison les champs sont à la campagne et non dans les bases de données. Pourtant même Microsoft fait cette erreur dans Access.
Disposer d'un jargon avec des termes précis serait une avancée énorme dans notre profession. Actuellement, les termes entité et relation ne désignent rien de précis, c'est quand même ahurissant.
Beaucoup aiment publier des articles ou des cours sur developpez.com. Je vous propose de construire un article sur le jargon des bases de données. Pas un article sur le jargon du passé, mais sur celui de notre futur. Une association n'est pas une relation, une entité n'est pas une entité-type, un identifiant n'est pas une clé primaire, etc.
La profession à besoin d'un vrai document de référence, au moins pour les quelques termes de base.
Enfin bref, j'ai encore des tonnes d'arguments, mais je pense en avoir suffisamment dis sur cette affaire. Je m'éclipse.
Cordialement,
Bonjour.
C'est un projet tout à fait louable, séduisant et intéressant. Il ne tient qu'à vous de vous y investir. L'équipe de la rédaction serait ravis de publier une telle contribution à votre nom. Toutefois, je pense que ce n'est pas en dévalorisant le travail des autres que nous avancerons. Je ne parle pas du simple fait de faire des remarques sur la rigueur du vocabulaire employé (sachant que vos remarques sont justes encore une fois et que j'en ai tenu compte), je parle d'aller jusqu'à remettre en cause le processus de relecture de DVP, de dire que de nombreux articles "gênent", d'exiger une restructuration en profondeur, etc (je suis désolé mais ça, je ne l'ai pas bien pris). Bref, je pense aussi qu'il vaut mieux clore ici le débat.
Bon sinon j'ai fait une petite mise à jour tenant compte d'une correction de CinePhil sur la partie MLD (il en reste d'autres) : l'association correspondre qui était mal traduite (une de ses cardinalités sur le MCD avait changé en cours de route). Prochaine étape : mettre d'équerre les noms des identifiants utilisés pour chaque entité et renommer l'entité Type en TypeLivre pour éviter la confusion avec un mot clef reservé en SQL (ça à déjà été fait sur le MLD et le SQL). Après je referai encore une passe sur les différentes propositions émises, j'en ai peut être loupé quelques unes
Merci à tous de vos contributions.
Cordialement,
Idriss
Répondre avec citation
Partager