+ Répondre à la discussion Actualité déjà publiée
Page 1 sur 2 12 DernièreDernière
  1. #1
    Rédacteur

    Avatar de ok.Idriss
    Homme Profil pro
    IS Consultant
    Inscrit en
    février 2009
    Messages
    5 081
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 26
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : IS Consultant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2009
    Messages : 5 081
    Points : 18 276
    Points
    18 276

    Par défaut [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

    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.
    N'hésitez pas à laisser vos impressions ici.


  2. #2
    Membre confirmé
    Inscrit en
    octobre 2007
    Messages
    210
    Détails du profil
    Informations forums :
    Inscription : octobre 2007
    Messages : 210
    Points : 450
    Points
    450

    Par défaut

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

  3. #3
    Rédacteur

    Avatar de ok.Idriss
    Homme Profil pro
    IS Consultant
    Inscrit en
    février 2009
    Messages
    5 081
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 26
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : IS Consultant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2009
    Messages : 5 081
    Points : 18 276
    Points
    18 276

    Par défaut

    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

  4. #4
    Modérateur
    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    14 746
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2006
    Messages : 14 746
    Points : 28 272
    Points
    28 272
    Billets dans le blog
    1

    Par défaut

    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
    Le code postal peut parfois être composé de lettres, en Corse notamment.
    Je 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.

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

    8) Donnée chiffrée
    Lorsque l'on n'effectue jamais de calcul sur une 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...
    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" :
    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.
    Puis dès le début du chapitre suivant :
    Une association définit une relation (ou un lien) sémantique entre une ou plusieurs entités.
    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.

    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
    Voici un exemple de relation associative issu de l'association «Correspondre» de notre MCD :

    Correspondre ( num_l #, ref_e # )
    Dans le MCD, l'association est la suivante :
    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 :
    Pays ( nom_p )
    Auteur ( id_a , nom_a, prenom_a, date_naissance_a)
    EtreOriginaireDe ( id_a # , nom_p #)
    signifie pour moi qu'elle est issue de ce MCD :
    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 :
    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.
    15) Chapitre III-A-2-d. Règle 4 -
    fsmrel va probablement sortir sa sulfateuse contre le bonhomme NULL.
    Voici ce que j'ai écrit dans mon blog à ce sujet :
    Cas 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é.
    16) Passage au SQL
    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. Autoentrepreneur.
    Mon blog sur la conception des BDD, le langage SQL, le PHP...
    « 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 !

  5. #5
    Rédacteur

    Avatar de ok.Idriss
    Homme Profil pro
    IS Consultant
    Inscrit en
    février 2009
    Messages
    5 081
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 26
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : IS Consultant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2009
    Messages : 5 081
    Points : 18 276
    Points
    18 276

    Par défaut

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

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

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

    Pourquoi alors n'avoir pas externalisé la ville, ce qui devrait être aussi une adaptation des règles de gestion ?
    C'est faisable, j'y ai pensé, mais bon par soucis de simplicité (et non de pertinence ) je préfère dire qu'on a une adresse qui est une propriété de l'inscrit mais qui doit être décomposée en données élémentaires dans cette entité.

    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.
    Oui, j'essayerai de refaire une passe là dessus

    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").
    En effet, il s'agit de l'éditeur ou la maison d'édition. Pour éviter toute ambigüité, je le remplacerai par "éditeur"

    [...]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...
    adrel = adresse E-mail ? (je ne connaissais pas le terme )

    Sinon oui, j'adapterai les tailles. (50 pour la villes, 100 pour l'E-mail par exemple et 30 pour les noms/prenoms).

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

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

    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...
    D'où l'importance de ne pas nommer "num" un identifiant technique.
    Vu de cet angle, tu as tout à fait raison

    Leur syntaxe est toujours demeurée pour moi confuse mais il me semble avoir compris que P1 → P2 signifie "P1 détermine P2"
    C'est exactement ça , d'où la définition du tuto :

    Citation Envoyé par tutoriel
    Soit deux propriétés (ou données) P1 et P2. On dit que P1 et P2 sont reliées par une dépendance fonctionnelle (DF) si et seulement si une occurrence (ou valeur) de P1 permet de connaître une et une seule occurrence de P2.
    Ce qui revient à dire "détermine"

    Ce n'est pas ma tasse de thé et, à vrai dire, je ne les utilise jamais.
    Quand on a l'habitude, elles sont instinctives. Leur notation "algébrique" n'est pas indispensable donc aucun soucis à te faire la dessus.

    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.
    C'est vrai, je crois que je vais simplement garder le terme "lien sémantique".

    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 !
    En effet, le VARCHAR permet, à ma connaissance, de n'allouer en mémoire que ce dont il a besoin (corriges moi s'il le faut ). C'est pour ça que j'ai pris des grandes tailles. Ceci dit, bien qu'étant un détail d'implémentation, je pense aussi qu'il vaut mieux les faire correspondre au dictionnaire des données.

    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 :

    Pays ( nom_p )
    Auteur ( id_a , nom_a, prenom_a, date_naissance_a)
    EtreOriginaireDe ( id_a # , nom_p #)
    signifie pour moi qu'elle est issue de ce MCD :
    Auteur -0,1----être_originaire_de----0,n- Pays
    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 trop ). On en avait parlé avec fsmrel dans ce sujet.

    fsmrel va probablement sortir sa sulfateuse contre le bonhomme NULL.
    Je me suis préparé psychologiquement à sa venue en écrivant cette partie ... il y a deux écoles, j'ai appris de l'autre façon et je sais que c'est la moins propre. L'une d'elle contredit une DF qui est une règle de gestion, l'autre prévoit des clefs étrangères aux valeurs potentiellement NULL (mais pourquoi tant de haine ). C'est pourquoi j'ai essayé de trouver un compromis entre les deux.

    Citation Envoyé par tutoriel
    Cependant même si les SGBD le permettent (avec la valeur NULL par défaut), il n'est normalement pas permis d'avoir une clef étrangère sans valeur pour laquelle on retrouverait l'occurrence dans la relation sur laquelle on fait référence.
    Bref, je l'ai quand même souligné

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

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

    Citation Envoyé par tutoriel
    Ce premier MLD est représenté de manière textuelle. C'est notamment cette représentation que l'on retrouve dans beaucoup de formations d'études supérieures. Il existe toutefois une représentation graphique équivalente.
    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.

    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 !
    Merci beaucoup .

    Cordialement,
    Idriss

    EDIT 2 : Une partie des remarques ont été prises en compte, je m'occuperai de la suite plus tard. Encore merci

  6. #6
    Membre actif
    Profil pro
    Inscrit en
    mai 2010
    Messages
    170
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mai 2010
    Messages : 170
    Points : 281
    Points
    281

    Par défaut

    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 :
    Toutes les occurrences du sur-type ne peuvent se trouver que dans un et un seul sous-type.
    En 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.


    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,

  7. #7
    Rédacteur

    Avatar de ok.Idriss
    Homme Profil pro
    IS Consultant
    Inscrit en
    février 2009
    Messages
    5 081
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 26
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : IS Consultant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2009
    Messages : 5 081
    Points : 18 276
    Points
    18 276

    Par défaut

    Bonjour.

    Pour l'héritage par disjonction :

    En 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.
    Tout à fait . Il est vrai que ma formulation peut involontairement laisser entendre qu'il n'y a pas d'autres sous-type possible. Je vais donc essayer de clarifier cela dès que possible.

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

    Personnellement je peux m'en accommoder, mais un étudiant qui débute en informatique risque d'être perturber.
    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.

    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 ). Entité et occurrences ou instance c'est plus parlant, il faut rester clair et simple. Je ne pense pas que les termes employés actuellement dans le tuto puissent perturber les étudiants alors que rentrer dans ces détails, là oui on risque de les perdre. Cela ferait trop de répétitions confuses ...

    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 peux comprendre qu'à l'orale on simplifie notre vocabulaire, mais dans un cours hébergé sur un site professionnel, cela me gène.
    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.

    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

  8. #8
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    5 971
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 5 971
    Points : 18 789
    Points
    18 789
    Billets dans le blog
    15

    Par défaut

    Bonsoir,


    Citation Envoyé par ok.Idriss Voir le message
    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).
    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.


    Citation Envoyé par ok.Idriss Voir le message
    tout les termes employé dans ce tuto ne prêteront pas à confusion.
    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.


    Citation Envoyé par ok.Idriss Voir le message
    On retrouve toujours les termes d'entités / associations au niveau conceptuel
    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 ».


    Citation Envoyé par ok.Idriss Voir le message
    il faut rester clair et simple. Je ne pense pas que les termes employés actuellement dans le tuto puissent perturber les étudiants alors que rentrer dans ces détails, là oui on risque de les perdre. Cela ferait trop de répétitions confuses
    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 « a a » 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.


    Citation Envoyé par ok.Idriss Voir le message
    Pour les formes normales pareil, il s'agit simplement de les introduire et non d'en faire une définition exacte.
    Ç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 :

    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.
    Serait-ce si difficile à comprendre de la part des néophytes ?

    Au besoin, quand vous voulez être plus formel, voyez ici : Pour conclure avec la première forme normale.


    Citation Envoyé par ok.Idriss Voir le message
    Citation Envoyé par MacFly58 Voir le message
    Je peux comprendre qu'à l'orale on simplifie notre vocabulaire, mais dans un cours hébergé sur un site professionnel, cela me gène.
    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).
    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.

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


    Citation Envoyé par ok.Idriss Voir le message
    En plus Merise est largement moins rependu qu'UML
    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.
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    De grâce, pas de questions techniques par MP, ma boîte de réception explose !
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  9. #9
    Rédacteur

    Avatar de ok.Idriss
    Homme Profil pro
    IS Consultant
    Inscrit en
    février 2009
    Messages
    5 081
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 26
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : IS Consultant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2009
    Messages : 5 081
    Points : 18 276
    Points
    18 276

    Par défaut

    Bonjour fsmrel et merci de votre réponse.

    Tout d'abord, je retiens à préciser que je ne met 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 :

    à moins que vous ne considériez Merise comme une mauvaise habitude
    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 souhaitez 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 parles en général, je me doute que ce n'est pas votre cas ).

    On retrouve toujours les termes d'entités / associations au niveau conceptuel
    Faux.
    Dans leur ouvrage de référence (La méthode Merise, tome 1, principes et outils), Tardieu Rochfeld et Colletti[...]
    Ah mais je ne parlais pas des ouvrages de référence ... je parles simplement des supports de cours actuel (dans les universités ou autre). 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 :

    Citation Envoyé par tutoriel
    Au niveau relationnel, on devrait plutôt parler de clef candidate qui permet d'identifier sans ambiguïté une occurrence de la relation pour les clefs primaires. De même, on devrait désigner une clef étrangère par une contrainte d'inclusion vers une clef candidate. Par souci de simplicité, on gardera les termes de clefs primaires et étrangères.
    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 [...]
    La partie sur les FN ne donne pas de définitions, mais donne simplement un aperçut 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 (), je vais adapter cette partie à peu près de cette façon :

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

    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.
    Là j'espère que ce ne sera plus perçut comme des définitions ...

    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.

    Le MLD est une représentation textuelle ou graphique de la structure des relations (tables en SQL)
    C'est exactement ce qui est fait dans le cours.

    MacFly parle de modifier les mauvaises habitudes.
    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.

    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.
    ce sera intégré dans la prochaine version.

    Bref merci à vous deux

  10. #10
    Membre actif
    Profil pro
    Inscrit en
    mai 2010
    Messages
    170
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mai 2010
    Messages : 170
    Points : 281
    Points
    281

    Par défaut

    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.

    - Adapter le contenu à peu près comme ceci :

    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.
    Là j'espère que ce ne sera plus perçut comme des définitions ...
    Ne vous en déplaise, ce sont bel et bien des définitions, et elles sont fausses.
    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.

    Pour ma part, je souhaitais rester en rapport avec ce qui est globalement enseigné aujourd'hui.
    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.

    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 ?

    Je vais encore murir ma réflexion
    Ouf

    je pense qu'en l'état le cours est "acceptable" et praticable
    Il est praticable mais pas acceptable.
    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.

  11. #11
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    5 971
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 5 971
    Points : 18 789
    Points
    18 789
    Billets dans le blog
    15

    Par défaut

    Bonsoir,


    Citation Envoyé par ok.Idriss Voir le message
    je ne met 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.
    Une bonne raison pour tenir compte de nos observations.


    Citation Envoyé par ok.Idriss Voir le message
    Je souhaitez 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 parles en général
    Rien compris.


    Citation Envoyé par ok.Idriss Voir le message
    Ah mais je ne parlais pas des ouvrages de référence ... je parles simplement des supports de cours actuel (dans les universités ou autre). Je suis parfaitement conscient que le terme exact est "entité-type", "association-type".
    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.


    Citation Envoyé par ok.Idriss Voir le message
    Citation Envoyé par tutoriel
    Au niveau relationnel, on devrait plutôt parler de clef candidate qui permet d'identifier sans ambiguïté une occurrence de la relation pour les clefs primaires. De même, on devrait désigner une clef étrangère par une contrainte d'inclusion vers une clef candidate. Par souci de simplicité, on gardera les termes de clefs primaires et étrangères.
    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 [...]
    Ç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).


    Citation Envoyé par ok.Idriss Voir le message
    Là j'espère que ce ne sera plus perçut comme des définitions ...
    Bien sûr que si.


    Citation Envoyé par ok.Idriss Voir le message
    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.
    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 :
    Citation Envoyé par Tutoriel
    Le modèle logique de données (MLD) est composé uniquement de ce que l'on appelle des relations .

    Citation Envoyé par ok.Idriss Voir le message
    Je vais encore murir ma réflexion, bien que je pense qu'en l'état le cours est "acceptable" et praticable.
    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 »...
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    De grâce, pas de questions techniques par MP, ma boîte de réception explose !
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  12. #12
    Rédacteur

    Avatar de ok.Idriss
    Homme Profil pro
    IS Consultant
    Inscrit en
    février 2009
    Messages
    5 081
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 26
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : IS Consultant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2009
    Messages : 5 081
    Points : 18 276
    Points
    18 276

    Par défaut

    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 :

    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.
    Pour les entités-type j'ai également ajouté une petite remarque :

    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.
    C'est pas encore figé mais au moins, ça sera peut être plus acceptable comme ça dans un premier temps

    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 .

  13. #13
    Membre émérite
    Avatar de alassanediakite
    Homme Profil pro
    Recherche, formation, développement
    Inscrit en
    août 2006
    Messages
    1 415
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : Mali

    Informations professionnelles :
    Activité : Recherche, formation, développement

    Informations forums :
    Inscription : août 2006
    Messages : 1 415
    Points : 2 961
    Points
    2 961
    Billets dans le blog
    6

    Par défaut

    Salut
    François, si je peux me permettre....
    Citation Envoyé par MacFly58 Voir le message
    Ne vous en déplaise, ce sont bel et bien des définitions, et elles sont fausses.
    Si vous les appelez règles 1, 2 et 3, alors ce passage devient acceptable.
    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".
    Citation Envoyé par MacFly58 Voir le message
    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.
    ... et les éditeurs de logiciels de conceptions (poweramc, win'design, openmodelsphere...). Croyez-vous qu'il est possible d’arrêter cette épidémie?
    Citation Envoyé par MacFly58 Voir le message
    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 ?
    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.

    Citation Envoyé par MacFly58 Voir le message
    Concernant le terme entité....
    bien dit
    J'ai un peu chercher à comprendre ce problème et voici une conclusion que j'ai trouvé sur wikipedia...
    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.
    que google traduit par...
    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.
    Citation Envoyé par MacFly58 Voir le message
    PS : Je n'ai pas lu tout votre document, et je dois avouer que j'hésite à le faire.
    du courage et fais nous profiter de tes remarques.
    Le monde est trop bien programmé pour être l’œuvre du hasard…
    Mon produit pour la gestion d'école: www.logicoles.com

  14. #14
    Membre éprouvé Avatar de GeoTrouvePas
    Homme Profil pro
    Contrôleur de gestion
    Inscrit en
    juin 2010
    Messages
    152
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Drôme (Rhône Alpes)

    Informations professionnelles :
    Activité : Contrôleur de gestion
    Secteur : Industrie

    Informations forums :
    Inscription : juin 2010
    Messages : 152
    Points : 974
    Points
    974

    Par défaut

    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.
    Apprends comme si tu devais vivre pour toujours et vis comme si tu devais mourir ce soir.
    Le monde ne sera pas détruit par ceux qui font le mal mais par ceux qui les regardent sans rien faire.

  15. #15
    Rédacteur

    Avatar de ok.Idriss
    Homme Profil pro
    IS Consultant
    Inscrit en
    février 2009
    Messages
    5 081
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 26
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : IS Consultant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2009
    Messages : 5 081
    Points : 18 276
    Points
    18 276

    Par défaut

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

    ... et les éditeurs de logiciels de conceptions (poweramc, win'design, openmodelsphere...). Croyez-vous qu'il est possible d’arrêter cette épidémie?
    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 ).

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

    Cordialement,
    Idriss

  16. #16
    Membre actif
    Profil pro
    Inscrit en
    mai 2010
    Messages
    170
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mai 2010
    Messages : 170
    Points : 281
    Points
    281

    Par défaut

    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,

  17. #17
    Modérateur
    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    14 746
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2006
    Messages : 14 746
    Points : 28 272
    Points
    28 272
    Billets dans le blog
    1

    Par défaut

    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 ?
    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.
    Je trouve d'ailleurs le texte proposé par ok.idriss tout à fait acceptable :
    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.
    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" ?

    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.
    Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole. Autoentrepreneur.
    Mon blog sur la conception des BDD, le langage SQL, le PHP...
    « 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 !

  18. #18
    Rédacteur

    Avatar de ok.Idriss
    Homme Profil pro
    IS Consultant
    Inscrit en
    février 2009
    Messages
    5 081
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 26
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : IS Consultant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2009
    Messages : 5 081
    Points : 18 276
    Points
    18 276

    Par défaut

    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

  19. #19
    Membre actif
    Profil pro
    Inscrit en
    mai 2010
    Messages
    170
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mai 2010
    Messages : 170
    Points : 281
    Points
    281

    Par défaut

    Bonsoir,

    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" ?
    Frigo et réfrigérateur, c'est la même chose.

    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,

  20. #20
    Rédacteur

    Avatar de ok.Idriss
    Homme Profil pro
    IS Consultant
    Inscrit en
    février 2009
    Messages
    5 081
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 26
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : IS Consultant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2009
    Messages : 5 081
    Points : 18 276
    Points
    18 276

    Par défaut

    Bonjour.

    Citation Envoyé par MacFly58 Voir le message
    La profession à besoin d'un vrai document de référence, au moins pour les quelques termes de base.,
    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

Discussions similaires

  1. Réponses: 7
    Dernier message: 30/11/2015, 14h25
  2. Réponses: 0
    Dernier message: 28/05/2015, 08h39

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo