Navigation

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

Schéma Discussion :

entité Date ou attribut date


Sujet :

Schéma

  1. #1
    Membre averti
    entité Date ou attribut date
    Bonjour,
    J’ai remarqué que dans certains modèles, on prend le choix de considérer une entité Date en relation avec d’autres entités qui en ont besoin. Je ne vois pas du tout l’utilité d’une telle considération ; c’est plutôt une table de plus à gérer !
    Personnellement, si j’ai besoin d’une date, je fais appel tout simplement à un attribut de type date.
    Je me trompe certainement pour ce choix, et j’aimerais trouver mon erreur.
    Merci à vous
    L'immortalité existe, elle s'appelle connaissance

  2. #2
    Expert confirmé
    Bonjour Wafiwafi,

    Eh bien, comme souvent, il n'y a pas de vérité universelle (ou alors elle est ailleurs...).

    Je pense que, généralement, nous avons besoin d'une entité Date, quand l'usage d'un calendrier se fait sentir (planning, jours fériés/ouvrés/ouvrables, ...). Nous parlons donc, dans ce cas, d'une entité Calendrier.

    Effectivement, si c'est pour stocker une date "simple" (date d'inscription, date du dossier, ...), il est inutile de créer une entité à part entière : un attribut de type Date (donc contrôlé par le système) suffit largement. En fait, dans ce cas, c'est le système qui possède une entité Calendrier et qui nous en fait profiter via le type de champ Date.
    Dis-nous et à bientôt,
    Richard.
    ----------------------------------------------------------------------------------------------
    En cas de résolution, et afin de faciliter la tâche des bénévoles, merci de cliquer sur .
    et permettent aux forumeurs de cibler leur recherche dans une discussion : n'hésitez pas à voter !

  3. #3
    Expert éminent sénior
    Une légende à détruire...
    Bonsoir,


    Citation Envoyé par wafiwafi Voir le message

    J’ai remarqué que dans certains modèles, on prend le choix de considérer une entité Date en relation avec d’autres entités qui en ont besoin. Je ne vois pas du tout l’utilité d’une telle considération ; c’est plutôt une table de plus à gérer !
    Personnellement, si j’ai besoin d’une date, je fais appel tout simplement à un attribut de type date.
    Je me trompe certainement pour ce choix, et j’aimerais trouver mon erreur.
    Vous êtes piégé par le sophisme qui part de la prémisse (évidemment fausse) selon laquelle toute entité-type d’un MCD merisien donne lieu à une table du MLD.


    Prenez le cas des règles de gestion suivantes :
    A une date donnée, un fournisseur donné peut fournir plusieurs produits,

    A une date donnée, un produit donné peut être fourni par plusieurs fournisseurs,

    Un fournisseur donné peut fournir un produit donné à des dates différentes.

    Considérez maintenant le MCD ci-dessous dans lequel Merise impose la mise en œuvre d'une entité-type DATE du fait de la présence d'une association ternaire, elle-même conséquence des règles de gestion :



    Je demande à mon AGL — PowerAMC en l’occurrence — de produire le MLD correspondant, mais sans table DATE :




    Ceci a été rendu possible parce que l’AGL offre la possibilité de ne pas produire une table pour chaque entité-type :




    Bref, encore une légende à détruire...
    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 »)

    Je ne réponds pas aux questions techniques par MP. Les forums sont là pout ça.
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  4. #4
    Membre averti
    Il n'ya rien à ajouter
    Très pertinent et convainquant.
    Merci à vous
    L'immortalité existe, elle s'appelle connaissance

  5. #5
    Rédacteur

    Bonjour.

    J'ai comme vous l'habitude de représenter, au niveau conceptuel, une entité Date (ou autre) lorsque celle-ci doit participer à la clef de la relation issue de l'association.

    Voici d'ailleurs ce que j'avais écris à ce sujet : http://ineumann.developpez.com/tutor...rise/#LIII-C-2

    Cependant, je suis déjà tombé sur une écriture différente avec laquelle on se contente d'ajouter une propriété date à l'association en la soulignant pour indiquer qu'elle fait partie de l'identifiant de cette dernière. Je me demande si cette écriture est valide, qu'en pensez-vous ?

    Merci.

    Cordialement,
    Idriss

  6. #6
    Expert confirmé
    Bonjour Ok.Idriss,

    Citation Envoyé par Ok.Idriss
    Cependant, je suis déjà tombé sur une écriture différente avec laquelle on se contente d'ajouter une propriété date à l'association en la soulignant pour indiquer qu'elle fait partie de l'identifiant de cette dernière. Je me demande si cette écriture est valide, qu'en pensez-vous ?
    ==> personnellement, c'est ce que je fais : cela permet de ne pas "alourdir" un MCD (parfois déjà bien dense).

    Mais, c'est vrai, l'opinion des "merisiens de naissance" concernant ce formalisme serait précieuse.
    Dis-nous et à bientôt,
    Richard.
    ----------------------------------------------------------------------------------------------
    En cas de résolution, et afin de faciliter la tâche des bénévoles, merci de cliquer sur .
    et permettent aux forumeurs de cibler leur recherche dans une discussion : n'hésitez pas à voter !

  7. #7
    Modérateur

    OK.Idriss, lorsque l'entité type fictive Date participe à la clé primaire, il est peut-être plus propre de la faire figurer.

    Mais imaginons que la propriété portée par l'association, et qui doit participer à son identification, ne soit plus une date mais par exemple un simple code sur une lettre.
    Si on crée une entité type pour ce code, mais qu'à cette lettre ne soit affilié aucun libellé explicatif, cela ferait créer une table des codes ne contenant qu'une seule colonne et de 26 lignes (si l'on s'en tient à notre alphabet français bien entendu !). Certes, cela aurait pour mérite de fixer les valeurs acceptables pour ce code mais c'est quand même un peu luxueux.

    On peut même imaginer que la propriété serait un simple booléen, autorisant ainsi le couple d'entités types associées à figurer deux fois dans l'association. On ne créerait alors pas d'entité type pour ce booléen.

    Dans la pratique, je penche moi aussi en direction de l'allègement du MCD et je préfère faire figurer la propriété de date dans l'association.

    fsmrel aura peut-être un avis plus rigoureux sur la question ?
    Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole. Autoentrepreneur.
    Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  8. #8
    Expert éminent sénior
    Bonsoir tous,


    Citation Envoyé par ok.Idriss Voir le message

    Voici d'ailleurs ce que j'avais écris à ce sujet : http://ineumann.developpez.com/tutor...rise/#LIII-C-2

    J’avais complètement oublié votre article sur lequel il y a des choses à dire. Par exemple, en ce qui concerne la date, vous devriez modifier la teneur du paragraphe III-A-2-a. Règle 1 - conversion d'une entité, préciser que la règle n’est pas absolue et y faire figurer un renvoi au paragraphe III-C-2.


    Citation Envoyé par ok.Idriss Voir le message
    Je suis déjà tombé sur une écriture différente avec laquelle on se contente d'ajouter une propriété date à l'association en la soulignant pour indiquer qu'elle fait partie de l'identifiant de cette dernière. Je me demande si cette écriture est valide, qu'en pensez-vous ?
    J'espère qu'en tombant vous ne vous êtes pas fait trop mal...

    Pour le reste, je ne suis pas un spécialiste de Merise, je ne fais pas autorité, mais je fais le constat suivant :

    Dans les ouvrages de référence, par exemple La méthode Merise, Tome 1 Principes et outils de H. Tardieu, A. Rochfeld, R. Colletti (5e impression de l’ouvrage, 1991), je note que le paragraphe 4.4.5. « Formalisme graphique » fournit une grammaire, et selon celle-ci une association (relation-type dans l’ouvrage) n’a pas d’identifiant.

    Dans un autre ouvrage de référence : Ingénierie des systèmes d'information : Merise, deuxième génération de D. Nanci et B. Espinasse, il est écrit en toutes lettres (cf. paragraphe « Identification d’une relation type ») :
    Une relation type n’a pas d’identifiant propre.

    Remontons le temps, et venons-en à l’époque à laquelle naquit MERISE ; faisons référence à l’ensemble des documents officiels « Méthode de définition d’un système d’information », émis par le centre technique informatique (CTI) du Ministère de l’Industrie (Mission à l’informatique). Faisons référence plus précisément au fascicule 4, « Guide pratique pour l’élaboration des modèles de données et de traitements », daté de juin 1979. On y lit (page 9) :


    Pardon pour la qualité de la photo...

    Maintenant, si vous prenez la précaution de rappeler la définition donnée par le CTI de l’identifiant de l’association et d’avertir que vous utilisez une définition étendue, je ne vois pas pour quelle raison un gardien du temple vous interdirait la représentation suivante en ce qui concerne les livraisons des produits par les fournisseurs (évolution, oui, révolution, non) :




    A titre d’exemple, un AGL comme DB-MAIN le permet (avec une notation un peu différente) :




    D’où le MLD :




    Citation Envoyé par Richard_35 Voir le message
    L'opinion des "merisiens de naissance" concernant ce formalisme serait précieuse.
    Je pense que le document du CTI est la référence incontournable, mais que l’évolution est possible (et même souhaitable). Dans cet esprit, avec DB-MAIN la possibilité d’agir sur l’identifiant d’une relation permet de se dispenser des CIF et autres DF merisiennes :

    Par exemple, dans un monde non quantique, lors d’une course hippique un jockey ne peut monter qu’un seul cheval, un cheval ne peut être monté que par un seul jockey et être porteur d’un seul numéro. Ces 3 règles de gestion peuvent être prises en compte ainsi avec DB-MAIN :



    Je vous laisse modéliser (représentation graphique) ceci en Merise « classique » avec respect des 3 règles de gestion ci-dessus.
    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 »)

    Je ne réponds pas aux questions techniques par MP. Les forums sont là pout ça.
    __________________________________
    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

    Re bonsoir.

    Citation Envoyé par fsmrel Voir le message
    vous devriez modifier la teneur du paragraphe III-A-2-a. Règle 1 - conversion d'une entité, préciser que la règle n’est pas absolue et y faire figurer un renvoi au paragraphe III-C-2.
    Je suis d'accord. La façon dont c'est formulé "Toute entité devient une relation[...]" laisse penser que cette règle est absolue alors qu'elle est contredite quelques paragraphes plus loin

    Bon en ce moment j'ai un peu moins le temps de rédiger, j'avais un article sur l'optimiser et l'algèbre relationnel en suspend que je n'ai toujours pas pris le temps de continuer ... mais pour cette mise à jour, j'essayerai de la faire prochainement.

    Et merci pour les explications de qualité comme toujours

    Idriss

  10. #10
    Expert éminent sénior
    Citation Envoyé par fsmrel Voir le message
    Je vous laisse modéliser (représentation graphique) ceci en Merise « classique » avec respect des 3 règles de gestion ci-dessus.
    J'espère qu'il n'y a pas de confusion, en disant cela, je ne m'adresse pas particulièrement à Richard, mais à tous

    Par contre, si Richard veut bien noter les copies...
    [Correcteur] -- 0,N ---- (Noter) ---- 1,1 -- [Copie]
    Espérons que N ne restera pas à 0...
    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 »)

    Je ne réponds pas aux questions techniques par MP. Les forums sont là pout ça.
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  11. #11
    Modérateur

    Je vous laisse modéliser (représentation graphique) ceci en Merise « classique » avec respect des 3 règles de gestion ci-dessus.
    Compte tenu de la contrainte d'unicité pour une course sur le numéro porté par le jockey et par son cheval, je transformerais "PARTICIPER" en entité type associative "PARTICIPATION" identifiée relativement au couple {jockey, cheval} et avec la propriété Numéro qui participe à l'identification de l'entité associative.

    Avec Open Modelsphere, ça donne ce MCD :

    Et ce diagramme Entité / association :

    EDIT :
    À la relecture, je constate quand même un défaut à mon schéma : Un couple {jockey, cheval} ne peut pas participer à deux courses avec le même numéro !

    Si j'ajoute la course à l'identification de la participation - ce qui reviendrait à rétablir l'association ternaire de départ - un couple {jockey, cheval} peut participer avec plusieurs numéros à la même course !

    À ce stade de ma réflexion, je ne ferais finalement pas participer le numéro à l'identification de l'association et je mettrais une contrainte sur l'unicité du numéro pour une course.
    Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole. Autoentrepreneur.
    Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  12. #12
    Expert confirmé
    Bonjour à tous,

    J'allais le dire, Philippe !... avec une petite nuance.

    En décomposant la réflexion, avec BlocNote , cela donnerait ceci :

    1°/ Idée brute (dans les deux sens...) :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
                   Course
                     |
                    0,n
                     |
                [Participer]
                     |
                    0,n
                     |
    Jockey -0,n---[Monter]---0,n- Cheval
    2°/ Si l'association entre deux associations n'est pas permise, décomposition de la relation n,n (comme indiqué par Philippe) :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
                                      Course
                                        |
                                       0,n
                                        |
                                   [Participer (N°)]
                                        |
                                       0,n
                                        |
    Jockey -0,n---[Monter]---1,1- Jockey_Cheval -1,1---[Etre monté]---0,n- Cheval
    3°/ Ou encore, dans le même esprit :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
                                      Course
                                        |
                                       0,n
                                        |
                                   [Participer]
                                        |
                                       1,1
                                        |
                                   Participation
                                        |
                                       1,1
                                        |
                                   [Participer]
                                        |
                                       0,n
                                        |
    Jockey -0,n---[Monter]---1,1- Jockey_Cheval -1,1---[Etre monté]---0,n- Cheval
    4°/ Donnant, en final :
    Jockey(IdJockey, Nom, ...)
    Cheval(IdCheval, Nom, ...)
    Course(IdCourse, Nom, ...)

    Jockey_Cheval(#IdJockey, #IdCheval, ...)
    Participation(#IdCourse, #IdJockey, #IdCheval, NumeroParticipant, ...) ==> index unique #IdCourse/#IdJockey/#IdCheval/NumeroParticipant
    Citation Envoyé par Fsmrel
    Par contre, si Richard veut bien noter les copies...
    ==> hum... je me garderai bien de noter quoi que ce soit, n'étant pas "merisien de naissance" !... juste quelques avis à partager. En revanche, les conseils des "merisiens de naissance" sont toujours précieux.
    Dis-nous et à bientôt,
    Richard.
    ----------------------------------------------------------------------------------------------
    En cas de résolution, et afin de faciliter la tâche des bénévoles, merci de cliquer sur .
    et permettent aux forumeurs de cibler leur recherche dans une discussion : n'hésitez pas à voter !

  13. #13
    Modérateur

    Participation(#IdCourse, #IdJockey, #IdCheval, NumeroParticipant, ...) ==> index unique #IdCourse/#IdJockey/#IdCheval/NumeroParticipant
    L'index unique est insuffisant. Je peux avoir ceci dans la table :

    #IdCourse, #IdJockey, #IdCheval, NumeroParticipant
    1, 12, 5, 1
    1, 3, 6, 1

    La clé primaire est unique, l'index unique aussi !
    Il faut que le numéro soit unique pour la course. Je ne vois pas comment modéliser ça autrement qu'en indiquant une contrainte.
    Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole. Autoentrepreneur.
    Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  14. #14
    Expert confirmé
    : exact, Philippe.

    Ce pourrait être :
    Participation(#IdCourse, #IdJockey, #IdCheval, NumeroParticipant, ...) ==> index unique #IdCourse/NumeroParticipant
    Dis-nous et à bientôt,
    Richard.
    ----------------------------------------------------------------------------------------------
    En cas de résolution, et afin de faciliter la tâche des bénévoles, merci de cliquer sur .
    et permettent aux forumeurs de cibler leur recherche dans une discussion : n'hésitez pas à voter !

  15. #15
    Modérateur

    Je pense que ça colle mais au niveau modélisation (MCD) on ne peut pas représenter les contraintes d'unicité je crois.
    À part avec les logiciels de modélisation modernes peut-être ?
    Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole. Autoentrepreneur.
    Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  16. #16
    Expert confirmé
    @Fsmrel
    Citation Envoyé par Fsmrel
    Par contre, si Richard veut bien noter les copies...
    [Correcteur] -- 0,N ---- (Noter) ---- 1,1 -- [Copie]
    Espérons que N ne restera pas à 0...
    ==> . Le but du forum doit rester :
    [Correcteur] -- 1,N ---- (Noter) ---- 1,N -- [Copie]
    fichu N,N !...
    Dis-nous et à bientôt,
    Richard.
    ----------------------------------------------------------------------------------------------
    En cas de résolution, et afin de faciliter la tâche des bénévoles, merci de cliquer sur .
    et permettent aux forumeurs de cibler leur recherche dans une discussion : n'hésitez pas à voter !

  17. #17
    Expert éminent sénior
    A propos des contraintes d'unicité
    'soir à tous,


    J’ai proposé avant-hier un MCD réalisé avec DB-MAIN, voici le MLD correspondant produit par l’AGL :



    Ce qui correspond sous forme textuelle à ceci :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    COURSE {CourseId, CourseNom, CourseDate}
        KEY {CourseId} ;
    
    CHEVAL {ChevalId, ChevalNom, DateNaissance}
        KEY {ChevalId} ;
    
    JOCKEY {JockeyId, JockeyNom, JockeyPrenom}
        KEY {JockeyId} ;
    
    PARTICIPER {CourseId, ChevalId, JockeyId, Numero, Poids}
        KEY {CourseId, ChevalId}
        KEY {CourseId, JockeyId}
        KEY {CourseId, Numero}
        FOREIGN KEY {CourseId} REFERENCES COURSE
        FOREIGN KEY {ChevalId} REFERENCES CHEVAL
        FOREIGN KEY {JockeyId} REFERENCES JOCKEY ;


    A toutes fins utiles, voici le code SQL généré par DB-MAIN :

    Code SQL :Sélectionner tout -Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    create table CHEVAL (
         ChevalId numeric(4) not null,
         ChevalNom varchar(48) not null,
         DateNaissance date not null,
         constraint ID_CHEVAL_ID primary key (ChevalId));
     
    create table COURSE (
         CourseId numeric(4) not null,
         CourseNom varchar(48) not null,
         CourseDate date not null,
         constraint ID_COURSE_ID primary key (CourseId));
     
    create table JOCKEY (
         JockeyId numeric(4) not null,
         JockeyNom varchar(48) not null,
         JockeyPrenom varchar(48) not null,
         constraint ID_JOCKEY_ID primary key (JockeyId));
     
    create table PARTICIPER (
         CourseId numeric(4) not null,
         ChevalId numeric(4) not null,
         JockeyId numeric(4) not null,
         Numero numeric(32) not null,
         Poids numeric(3,2) not null,
         constraint ID_PARTICIPER_ID primary key (CourseId, ChevalId),
         constraint SID_PARTICIPER_1_ID unique (CourseId, JockeyId),
         constraint SID_PARTICIPER_ID unique (CourseId, Numero));
     
    alter table PARTICIPER add constraint REF_PARTI_JOCKE_FK
         foreign key (JockeyId)
         references JOCKEY;
     
    alter table PARTICIPER add constraint REF_PARTI_COURS
         foreign key (CourseId)
         references COURSE;
     
    alter table PARTICIPER add constraint REF_PARTI_CHEVA_FK
         foreign key (ChevalId)
         references CHEVAL;



    Citation Envoyé par Richard_35 Voir le message
    @Fsmrel
    ==> . Le but du forum doit rester :
    [Correcteur] -- 1,N ---- (Noter) ---- 1,N -- [Copie]
    Soit ! Autrement dit, plein de gens vont corriger plein de copies : pas de problème, plus on est de fous, plus on !


    Citation Envoyé par CinePhil Voir le message
    À ce stade de ma réflexion, je ne ferais finalement pas participer le numéro à l'identification de l'association et je mettrais une contrainte sur l'unicité du numéro pour une course.


    Hum... Le défi est de prendre en compte les règles de gestion seulement au niveau MCD. Est-il bien sous-entendu que cette contrainte fait partie du MCD ?

    Quoi qu’il en soit, vous aurez au moins plus de contrôle sur l’intégrité de la base de données que ne l’ont ceux qui on modélisé les équipes de la NBA, avec par exemple deux joueurs des Blazers qui portent le numéro 23 (parmi les choses bizarres, je remarque à cette occasion que le pauvre Nicolas Batum ne doit pas avoir grand-chose à manger...)




    Citation Envoyé par Richard_35 Voir le message

    Participation(#IdCourse, #IdJockey, #IdCheval, NumeroParticipant, ...) ==> index unique #IdCourse/NumeroParticipant
    Il s’agit là d’une intervention manuelle au niveau physique (le concept d’index est inconnu au niveau logique, en conséquence de quoi il ne fait pas partie de la norme SQL, pour qui la technologie physique reste sous le capot). Comme je viens de le préciser, le défi est déjà de prendre en compte les règles de gestion seulement au niveau MCD...


    Citation Envoyé par CinePhil Voir le message
    Au niveau modélisation (MCD) on ne peut pas représenter les contraintes d'unicité je crois.
    À part avec les logiciels de modélisation modernes peut-être ?
    La Bentley WinDesign permet de le faire contrairement à la Rolls PowerAMC. La FAQ Merise comporte un paragraphe à ce sujet : CIF (ou dépendance fonctionnelle) de A à Z (pour une Matière, un Candidat ne compose que dans une Salle).


    Je vais essayer maintenant de représenter les contraintes sans sortir du moule Merise, en essayant de suivre à cet effet ce qui est écrit dans le document de référence :
    afcet - Le formalisme de données Merise - Extensions du pouvoir d’expression - Journée d’étude organisée par le Groupe de Travail 135 « Conception des systèmes d’information (Collège AFCET-GID) - Jeudi 15 novembre 1990, Paris.

    Les CIF, DF et plus généralement les contraintes d’unicité y sont définies ainsi que les règles à respecter pour les représenter :





    A noter que le terme « rôle » y est défini ainsi :
    Expression de la sémantique portée par la patte d’une relation.

    Mais j’avoue que cette purée de marron me laisse perplexe et si quelqu’un a le courage de la remettre forme de façon claire, sinon lumineuse, il aura ma gratitude... je suis peut-être délinquant en représentant les choses comme je le fais ci-dessous car je ne dispose pas de WinDesign, donc si quelqu’un l’a sous la main, qu’il n’hésite surtout pas à faire part du verdict de l’AGL.

    Au passage, je rappelle s’il est besoin, que contrairement à ce qui se passe avec DB-MAIN, on ne peut pas en Merise classique faire figurer dans une association quelque attribut que ce soit qui participe à l’identification d’icelle : de l’attribut Numero on est donc obligé de faire une pseudo entité-type :



    A la lecture du document afcet, il me semble que la CIF (contrainte d’intégrité fonctionnelle) de la figure 2 est conforme. Elle exprime la contrainte selon laquelle pour une course et un cheval, il n’y a qu’un jockey :



    Si la contrainte CIF1 est conforme, alors il doit en aller de même pour la CIF de la figure 3 :



    Par référence aux axiomes d’Armstrong (plus particulièrement la règle d'union), je n’hésite pas à remplacer CIF1 et CIF2 par leur union (mais j’accepte d’être contesté, je ne suis pas merisement très orthodoxe ), on gagne ainsi en densité :



    De la même façon, on signifie que pour une course et un jockey, il y a un seul cheval et un seul numéro :



    Enfin, pour une course et un numéro, il y a un seul cheval et un seul jockey :



    On a donc 6 CIF (compactées en 3) pour exprimer les contraintes d’unicité. Je ne me sens pas l’envie de les faire figurer toutes à la fois, dans un seul diagramme...

    Peu importe. Je retiens en tout cas que ce malheureux Nicolas Batum peut laisser tomber le basket et devenir jockey.
    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 »)

    Je ne réponds pas aux questions techniques par MP. Les forums sont là pout ça.
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  18. #18
    Modérateur

    Hum... Le défi est de prendre en compte les règles de gestion seulement au niveau MCD. Est-il bien sous-entendu que cette contrainte fait partie du MCD ?
    Oui, je pensais simplement à l'ajout d'une note pointant vers l'association (ou l'entité type associative) qui préciserait la contrainte, ne sachant pas comment la représenter.

    Tu as trouvé le moyen de définir complètement la contrainte sous forme de 3 CIF multiples.
    Je ne sais pas si ce formalisme serait accepté par les pères de Merise mais il me convient.

    Cependant, n'y aurait-il pas, dans la théorie relationnelle, quelle axiome, théorème ou autre tambouille qui permettrait de réduire l'ensemble de CIF suivantes en une seule ?
    COURSE x CHEVAL --> JOCKEY, NUMERO
    COURSE x JOCKEY --> CHEVAL, NUMERO
    COURSE x NUMERO --> CHEVAL, JOCKEY

    Ça me fait penser à un système d'équations que l'on essaierait de résoudre.
    Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole. Autoentrepreneur.
    Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  19. #19
    Membre chevronné
    Pour en revenir aux dates...
    Bonjour à tous,

    Pour éviter la modélisation d'une entité Date quand ce n'en est pas une, certains auteurs (au moins André FLORY en 82 repris par José MOREJON en 95) proposent la modélisation d'une "propriété spatio-temporelle". Il s'agit d'une simple propriété conceptuelle, la plupart du temps liée au temps ou à la localisation spatiale (d'où son nom), et entrant dans la composition d'une association. Elle se représente graphiquement dans un rectangle simple (ce n'est pas une entité).

    L'avantage est double.
    1) Elle participe à l'association et par conséquent participe à la composition de l'identifiant de l'association, respectant la règle qui veut qu'une association n'ait pas d'identifiant propre ni même une partie de cet identifiant.
    2) Elle ne génère pas de table lors de la transformation du MCD en MLD puisqu'elle n'est pas une entité.

    L'inconvénient est que, comme pour tous les concepts Merise "avancés" (après Merise/2), aucun AGL de modélisation n'intègre la propriété saptio-temporelle. La procédé de modélisation le plus proche de ce concept reste celui proposé par fsmrel (post #3) : créer une entité Date et ne pas générer la table.
    N'oubliez pas de consulter les Cours Merise et la F.A.Q. Merise
    _______________________________________________________

    Les Règles du Club Developpez.com
    Vous avez votre réponse ? Merci de cliquer sur

  20. #20
    Expert éminent sénior
    Citation Envoyé par JPhi33 Voir le message
    Pour éviter la modélisation d'une entité Date quand ce n'en est pas une, certains auteurs (au moins André FLORY en 82 repris par José MOREJON en 95) proposent la modélisation d'une "propriété spatio-temporelle".


    C’est vrai, et j’ai oublié d’en faire mention alors que vous aviez déjà signalé cette possibilité ici.


    Cela dit, d’après vous, WinDesign accepte-t-il les CIF : CIF1 et CIF2 que j’ai représentées dans mon message précédent ? Le doute que je peux avoir vient du fait que, par exemple dans le cas de DIF1, l’entité-type NUMERO est branchée sur PARTICIPER, mais ne fait pas partie de la « source » (Unicité incomplète).


    Citation Envoyé par CinePhil Voir le message
    n'y aurait-il pas, dans la théorie relationnelle, quelle axiome, théorème ou autre tambouille qui permettrait de réduire l'ensemble de CIF suivantes en une seule ?
    COURSE x CHEVAL --> JOCKEY, NUMERO
    COURSE x JOCKEY --> CHEVAL, NUMERO
    COURSE x NUMERO --> CHEVAL, JOCKEY
    En mettant à contribution l’ensemble des axiomes d’Armstrong, on aboutit à la conclusion que ce trio est irréductible (c’est son côté gaulois...), on est passé de 6 représentations de CIF à 3 et on ne peut pas faire mieux. Désolé...
    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 »)

    Je ne réponds pas aux questions techniques par MP. Les forums sont là pout ça.
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench