IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
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 :

De MCD a MLD: Que deviennent les contraintes entre associations


Sujet :

Schéma

  1. #1
    Invité
    Invité(e)
    Par défaut De MCD a MLD: Que deviennent les contraintes entre associations
    Bonjour,
    Je suis entrain d'essayer de comprendre la modelisation MERISE et j'ai a peu pres tout compris des conversions de MCD vers MLD mais il y a des choses qui m'echappent. Le sort des contraintes inter-associations. D'apres ce que j'ai compris sur les contraintes d'integrite fonctionnelle (qui ne sont pas celle qu'on appelle contraintes entre relation mais qui sont tout de meme des contraintes) est que lors du passage du MCD au model relationnel, celles-ci bien que non represente doivent etre prise en compte (on va dire note dans un coin de la page) car elle seront utiles lors de creation des relations dans un SGBD. Arrete moi si j'ai tort mais, si j'ai bien compris le cours, elle ne sont pas represente dans le model relationnel et elle ne seront en fait prises en compte qu'au moment de la creation du systeme d'information finale (dans l'application par exemple en empechant certaine valeur non autorise ou autre). Donc je me demandais si c'etait le cas des contraintes entre association ou sont elles represente dans le MLD et si tel est le cas quelle est la marche a suivre. Quelqu'un pourrait-il m'aider sur la question? Merci d'avance!!
    Dernière modification par JPhi33 ; 28/06/2014 à 15h29. Motif: tag

  2. #2
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 002
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

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

    Informations forums :
    Inscription : Septembre 2006
    Messages : 8 002
    Points : 30 905
    Points
    30 905
    Billets dans le blog
    16
    Par défaut A propos des CIF
    Bonsoir sci-ripper,


    Citation Envoyé par sci-ripper
    D'après ce que j'ai compris sur les contraintes d'intégrité fonctionnelle (qui ne sont pas celle qu'on appelle contraintes entre relation mais qui sont tout de même des contraintes) est que lors du passage du MCD au model relationnel, celles-ci bien que non représente doivent être prise en compte (on va dire note dans un coin de la page) car elles seront utiles lors de création des relations dans un SGBD.
    Vous faites références aux CIF (contraintes d’intégrité fonctionnelle). Leur traduction automatique au niveau tabulaire est effective avec un AGL comme WinDesign (payant) ou DB-MAIN (gratuit). Sinon, avec PowerAMC, qui est beaucoup plus utilisé dans ce forum (payant, avec une version d’évaluation), c’est à nous de pallier et surtout de ne pas oublier ces fameuses CIF, car non seulement c’est « utile », mais c’est surtout obligatoire, car elles expriment des règles de gestion...

    Prenons l’exemple des instituteurs traité ici :



    La CIF est symbolisée par une flèche rouge (il y a des représentations graphiques plus compliquées...) et traduit la règle suivante :

    Au cours d’une année donnée, une classe donnée est sous la responsabilité d’un seul instituteur


    J’ai utilisé PowerAMC (donc la flèche rouge a été ajoutée à la main) : je serai obligé d’agir au niveau du MLD pour faire respecter la règle. En effet, le MLD produit par l’AGL est le suivant :



    — La flèche rouge est toujours présente, mais ajoutée manuellement, histoire d’attirer l’attention...

    — Pour que la contrainte soit respectée, l’attribut InstitId doit dégager de la clé (pk) de la table Est_chargé_de.

    — Pour peaufiner le travail, on supprime carrément la table ANNEE qui n’a aucune valeur ajoutée, au contraire c’est un boulet à traîner, car à chaque fois qu’on crée une ligne dans la table, il faut s’assurer que l’intégrité référentielle est respectée (c'est-à-dire que la valeur prise par l’attribut Anne de la table Est_chargé_de existe bien dans la table ANNEE).

    Une fois bricolé, le MLD devient le suivant :




    Avec DB-MAIN, pas besoin de bricoler.


    MCD :



    Dans ce MCD, Annee est seulement un attribut porté par l’association Est_chargé_de, mais il participe à l’identification de celle-ci, en compagnie de CLASSE, tandis qu’INSTITUTEUR n’y participe pas.


    MLD :




    Le code SQL produit par DB-MAIN est conforme à ce qu’on attend, la clé primaire de la table Est_charge_de est bien la paire {ClasseId, Annee} :
    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
    create table INSTITUTEUR (
         InstitiId int not null,
         InstitNom varchar(32) not null,
         constraint ID_INSTITUTEUR_ID primary key (InstitiId));
     
    create table CLASSE (
         ClasseId int not null,
         ClasseNom varchar(32) not null,
         constraint ID_CLASSE_ID primary key (ClasseId));
     
    create table Est_charge_de (
         ClasseId int not null,
         Annee int not null,
         InstitiId int not null,
         constraint ID_Est_charge_de_ID primary key (ClasseId, Annee));
     
     
    alter table Est_charge_de add constraint FKEst_INS_FK
         foreign key (InstitiId)
         references INSTITUTEUR (InstitiId);
     
    alter table Est_charge_de add constraint FKEst_CLA
         foreign key (ClasseId)
         references CLASSE (ClasseId);


    Voilà un début. Il se fait tard, on poursuivra demain...
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, 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 »)

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

  3. #3
    Invité
    Invité(e)
    Par défaut Quelques precisions necessaires
    Bonsoir fsmrel,
    Déjà je vous remercie de m'avoir répondu et désole pour le retard. Il m'a fallu relire le cours car je ne comprenais pas votre exemple et il s'avère que je n'avais pas complètement compris le concept et la représentation de CIF (dans le cours il l'on représenté par un cercle avec "CIF" écrit a l'intérieur et je pensai que c'était toujours représenté ainsi) De plus d'après le cours que j'ai lu il est écris "Quand la cardinalité maximale entre l’association et l’entité est égale à 1, on a à faire à une association particulière que l’on appelle Contrainte d’intégrité Fonctionnelle." or dans votre exemple aucune cardinalité maximale n'est à 1. Heureusement la FAQ sur merise à dissiper les doutes sur le sujet.Maintenant j'aimerai avoir quelques précisions sur les représentations par PowerAMC car elles troublent ma compréhension.

    -Pourquoi la cardinalité maximale entre la relation Est_chargé_de et l'entité CLASSE est n alors qu'une classe donnée est sous la responsabilité d’un seul instituteur?
    -Si pk est une clé (primaire) donc primary key alors fk serai une clé étrangère?
    -Si la réponse a la question précédente est oui pourquoi l'entité Instituteur possède une clé primaire qui est à la fois une clé étrangère?
    -Par quel procédé avez-vous pris la décision de retirer de la clé de la table Est_chargé_de l'attribut InstitId (je ne considère personnellement pas que sa présence dans la clé nuit au respect de la contrainte car on considère qu'une classe donnée est sous la responsabilité d’un seul instituteur).
    -Y a-t-il des étapes (un algorithme) générales à suivre et permettent de toujours décider de ce qui est bon à garder ou non dans la clé?

    Encore merci pour votre réponse.

  4. #4
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 002
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

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

    Informations forums :
    Inscription : Septembre 2006
    Messages : 8 002
    Points : 30 905
    Points
    30 905
    Billets dans le blog
    16
    Par défaut
    Bonsoir sci-ripper,


    Citation Envoyé par sci-ripper
    dans le cours il l'on représenté par un cercle avec "CIF" écrit à l'intérieur
    C’est une façon de procéder parmi d’autres et il m’arrive de le faire, voyez par exemple le cas du jockey qui ne peut évidemment monter qu’un seul cheval au cours d’une course.

    Vous y trouverez à cette occasion la définition de la contrainte d’unicité (donc de la CIF), telle qu’elle a été proposée par le Groupe de Travail 135 de l’Afcet qui a fait du beau travail.



    Citation Envoyé par sci-ripper
    Pourquoi la cardinalité maximale entre la relation Est_chargé_de et l'entité CLASSE est N alors qu'une classe donnée est sous la responsabilité d’un seul instituteur?
    Parce que d’une année à l’autre, une classe peut changer d’instituteur :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    Classe    Année    Instituteur
    ------    -----
    C1        2012     Fernand
    C1        2013     Raoul
    C1        2014     Fernand
    Ainsi, la classe C1 a eu plus d’un instituteur, d’où la cardinalité N, par contre, au cours d’une année, une classe n’a qu’un instituteur, d’où la clé {Classe, Année}.



    Citation Envoyé par sci-ripper
    Si pk est une clé (primaire) donc primary key alors fk serait une clé étrangère?
    « pk » est un symbole signifiant « primary key » (clé primaire) et « fk » un autre symbole, signifiant « foreign key » (clé étrangère »). Cela dit, une clé primaire peut être en même temps clé étrangère, dans le 1er cas elle permet de garantir l’intégrité d’entité, dans le2e cas elle permet de garantir l’intégrité référentielle.



    Citation Envoyé par ripper
    Si la réponse à la question précédente est oui pourquoi l'entité Instituteur possède une clé primaire qui est à la fois une clé étrangère?
    Reprenons le code produit par DB-MAIN, dans lequel je me contente de renommer les contraintes :

    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
    CREATE TABLE INSTITUTEUR (
         InstitId int NOT NULL,
         InstitNom varchar(32) NOT NULL,
         constraint INSTITUTEUR_PK PRIMARY KEY (InstitId));
     
    CREATE TABLE CLASSE (
         ClasseId int NOT NULL,
         ClasseNom varchar(32) NOT NULL,
         constraint CLASSE_PK PRIMARY KEY (ClasseId));
     
    CREATE TABLE Est_charge_de (
         ClasseId int NOT NULL,
         Annee int NOT NULL,
         InstitId int NOT NULL,
         constraint Est_charge_de_PK PRIMARY KEY (ClasseId, Annee));
     
     
    ALTER TABLE Est_charge_de ADD constraint Est_charge_de_INSTITUTEUR_FK
         FOREIGN KEY (InstitId)
         REFERENCES INSTITUTEUR (InstitId);
     
    ALTER TABLE Est_charge_de ADD Est_charge_de_CLASSE_FK
         FOREIGN KEY (ClasseId)
         REFERENCES CLASSE (ClasseId);

    La table INSTITUTEUR est dotée d’une clé primaire {InstitId} ¹.

    La table Est_charge_de est dotée d’une clé primaire {ClasseId, Annee} et de deux clés étrangères, dont {InstitId} qui sert à faire respecter la contrainte d’intégrité référentielle qui veut qu’une classe fasse référence à un instituteur appartenant à la table INSTITUTEUR. Si l’on ne procédait pas ainsi, une classe pourrait se retrouver avec un prétendu professeur, inconnu de la base de données.



    Citation Envoyé par ripper
    Par quel procédé avez-vous pris la décision de retirer de la clé de la table Est_chargé_de l'attribut InstitId
    La contrainte CK1 selon laquelle une classe a un seul professeur au cours d’une année donne lieu au niveau relationnel à une dépendance fonctionnelle attachée à la table Est_charge_de :

    {ClasseId, Annee} -> {InstitId}

    Si j’avais conservé l’attribut InstitId dans la clé primaire de la table, j’aurais été délinquant au regard de la dépendance fonctionnelle donc de la contrainte CK1.

    Je rappelle à cette occasion qu’une clé candidate (ou clé tout court, la clé primaire n’étant qu’un cas particulier qui a été évacué de la théorie relationnelle, pour cause d’absence de valeur ajoutée) est un sous-ensemble K d’attributs (ou colonnes) de l’en-tête (ensemble des attributs) d’une table T, vérifiant les deux contraintes suivantes :

    Unicité. Deux tuples (ou lignes) de T ne peuvent avoir simultanément même valeur de K.

    Irréductibilité. Il n’existe pas de sous-emble strict K’ de K vérifiant lui aussi la contrainte d’unicité.


    S’il se trouve que le triplet {ClasseId, Annee, InstitId} vérifie la propriété d’unicité, il ne vérifie pas celle d’irréductibilité, alors que la paire {ClasseId, Annee} vérifie les deux (il est facile de vérifier qu’elle est irréductible).



    Citation Envoyé par ripper
    Y a-t-il des étapes (un algorithme) générales à suivre et permettent de toujours décider de ce qui est bon à garder ou non dans la clé?
    Oui. Le travail consiste à recenser les règles de gestion qui donnent lieu à des dépendances fonctionnelles, puis à mettre en œuvre l’algorithme du seau. Mais ceci suppose une connaissance objective et non fantaisiste des dépendances fonctionnelles et avoir étudié les axiomes d’Armstrong. On n’a rien sans rien...

    __________________________
    ¹ Les accolades sont là pour montrer que les éléments qui en font l’objet sont des ensembles au sens de la théorie des ensembles.
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, 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 »)

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

Discussions similaires

  1. Que deviennent les tables temporaires ?
    Par mapmip dans le forum PostgreSQL
    Réponses: 1
    Dernier message: 04/04/2013, 14h26
  2. que deviennent les rapports après integration à WSS
    Par Pietr_Alekseievitch dans le forum SharePoint
    Réponses: 1
    Dernier message: 27/10/2008, 07h53
  3. [MLD]Modifier les contraintes issues du MCD
    Par forum2000 dans le forum Schéma
    Réponses: 2
    Dernier message: 16/05/2007, 09h24
  4. Réponses: 2
    Dernier message: 27/02/2007, 13h50
  5. Les différences entre association et dépendance ?
    Par sephile dans le forum Diagrammes de Classes
    Réponses: 3
    Dernier message: 12/01/2005, 13h43

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