Discussion :

[yrichi]

Bonjour ,


je souhaiterais modélisé une GED donc une l'organisation un ensemble d’éléments à travers une arborescence de dossier et de fichier liés a un utilisateur
voici donc mon ébauche de MCD



donc le client est forcement un User et l'admin est un User avec le champ typeuser avec une valeur différente des clients ( il y a 3 types d'user , ceux n’ayant aucun droit , ceux ayant un droit de lecteur seul et pour finir l'admin qui a tous les droits )

ensuite je lie les entités Dossier et Fichier a l'user ( ici le champ nivhierachique me facilitera l'affichage sur le site web notamment la représentation des dossiers et sous dossiers ainsi que les Fichiers )
et le champ CheminFichier me permet donc de liée l'entité de Fichier a son emplacement "réel"

L’entité DossierComposition permet de lier des fichiers à un dossier ( j'hésite entre cette entité ou l'utilisation du champ NomdossierAncetre de l’entité fichier qui pourrait permettre d'identifié le dossier qui contient l'élément .)

et pour finir, je ne sais pas comment représenter le fait qu'un dossier est contenu dans un autre dossier

voila je suis conscient que j'en demande beaucoup et je vous remercie de l'attention accordée a mon post .



modification :

[fsmrel]

Bonsoit yrichi,



Un point de détail : votre 1er diagramme n’est pas un MCD, mais un MLD, car dans un MCD, le concept de clé étrangère (FK) n’existe pas : disons que la clé étrangère du MLD est la traduction d’une association à cardinalité maximale 1 du MCD.

La notation que vous utilisez pour ce 1er diagramme est du genre IDEF1X, laquelle se trouve être très rarement utilisée dans ce forum (en plus les associations sont colorisées, cela joue-t-il un rôle formel ?) Aussi serait-il bon en l’occurrence que vous rédigiez en français les règles de gestion des données, par exemple :

(RG1) Un utilisateur a de zéro à plusieurs dossiers ;

(RG2) Un dossier appartient à au moins et au plus un utilisateur ;

Etc.

Cela dit, dans votre 2e diagramme (qui est un MCD), l’association APPARTIENT est une ternaire avec des cardinalités 1,1, ce qui n’est pas conseillé : conservez les deux binaires de votre 1er diagramme.


Association USER - CLIENT :

Ce que j’écris fait référence à la 1re version de votre message. Depuis vous avez changé la règle du jeu, mais je conserve quand même mes commentaires :





En utilisant une loupe, la lunule verte collée à CLIENT donne l’impression qu’un utilisateur est associé de zéro à plusieurs clients. Qu’en est-il ? Quoi qu’il en soit, l’emploi du verbe « être » dans la phrase « donc le client est forcément un User » est erroné : à la limite, un utilisateur peut représenter (merci de choisir le verbe sémantiquement pertinent) plusieurs clients, mais qu’un utilisateur soit plusieurs clients, ça n’a pas de sens. L’emploi du verbe « être » ne serait légitime que si un utilisateur ne représentait qu’un seul client (injection ou bijection).


En passant, de mon côté je renomme USER en UTILISATEUR, car on peut avoir des surprises en passant au niveau SQL : USER fait partie des mots réservés de ce langage (définis par la norme). A noter que si deux utilisateurs ne peuvent pas avoir le même login, alors l’attribut login devra faire l’objet d’un identifiant alternatif (clé candidate alternative au stade SQL), même remarque concernant les dossiers et les fichiers : pour un utilisateur donné, deux dossiers ne devraient pas avoir le même nom et deux fichiers ne devraient pas non plus avoir le même nom. Si en fait pour un utilisateur donné, deux fichiers peuvent avoir le même nom, l’identifiant alternatif sera la paire Cheminfichier, Nomfichier. Ci-dessous, je me suis limité à l’unicité du nom du fichier.


Contrainte de chemin

Selon votre diagramme, rien n’empêche, comme ci-dessous, d’associer les dossiers d’un utilisateur à ceux d’un autre utilisateur dans la table DOSSIER_COMPOSITION(les clés primaires sont soulignées) :

Table UTILISATEUR

IdUser    login    Mdp    ...
------         
     1    tototo   ****   ...
     2    loulou   ****   ...

Table DOSSIER

IdDossier    IdUser    NomDossier
---------     
        1         1    dossier 47
        2         1    dossier 85
        3         2    dossier 12
        4         2    dossier 85

Table FICHIER

IdFichier    IdUser    NomFichier
---------
        1         1    fichier 01
        2         1    fichier 05
        3         2    fichier 10
        4         2    fichier 01

Table DOSSIER_COMPOSITION

IdDossier    IdFichier
---------    ---------
        1            1
        1            2
        2            4

Pour éviter ce genre d’anomalie, il faut mettre en œuvre une contrainte dite de chemin. Pour cela, soit vous développez un trigger, soit vous utilisez l’identification relative, c'est-à-dire en faisant participer l’attribut IdUser à la clé primaire des tables DOSSIER, FICHIER et DOSSIER_COMPOSITION. Les valeurs prises par les attributs IdDossier et IdFichier ne sont plus absolues, mais relatives à l’attribut IdUser.

Exemple de script SQL avec PostgreSQL en ce sens (avec MySQL, remplacer « SERIAL » par « INT NOT NULL AUTO_INCREMENT », et avec SQL Server, remplacer par «INT NOT NULL IDENTITY ») :

Table UTILISATEUR

CREATE TABLE UTILISATEUR
(
        IdUser         SERIAL
      , Login          VARCHAR(50)  NOT NULL
      , Mdp            VARCHAR(50)  NOT NULL 
    , CONSTRAINT UTILISATEUR_PK PRIMARY KEY (IdUser)
    , CONSTRAINT UTILISATEUR_AK UNIQUE (Login) 
) ;

Table DOSSIER

CREATE TABLE DOSSIER
(
        IdUser         INT          NOT NULL
      , IdDossier      INT          NOT NULL
      , NomDossier     VARCHAR(50)  NOT NULL 
    , CONSTRAINT DOSSIER_PK PRIMARY KEY (IdUser, IdDossier)
    , CONSTRAINT DOSSIER_AK UNIQUE (IdUser, NomDossier)
    , CONSTRAINT DOSSIER_UTILISATEUR_FK FOREIGN KEY (IdUser) 
          REFERENCES UTILISATEUR (IdUser)
) ;

Table FICHIER

CREATE TABLE FICHIER
(
        IdUser         INT          NOT NULL
      , IdFichier      INT          NOT NULL
      , NomFichier     VARCHAR(50)  NOT NULL 
    , CONSTRAINT FICHIER_PK PRIMARY KEY (IdUser, IdFichier)
    , CONSTRAINT FICHIER_AK UNIQUE (IdUser, NomFichier)
    , CONSTRAINT FICHIER_UTILISATEUR_FK FOREIGN KEY (IdUser) 
          REFERENCES UTILISATEUR (IdUser)
) ;

TABLE DOSSIER_COMPOSITION

CREATE TABLE DOSSIER_COMPOSITION
(
        IdUser         INT          NOT NULL
      , IdDossier      INT          NOT NULL
      , IdFichier      INT          NOT NULL
    , CONSTRAINT DOSSIER_COMPOSITION_PK PRIMARY KEY (IdUser, IdDossier, IdFichier)
    , CONSTRAINT DOSSIER_COMPOSITION_DOSSIER_FK FOREIGN KEY (IdUser, IdDossier) 
          REFERENCES DOSSIER (IdUser, IdDossier)
    , CONSTRAINT DOSSIER_COMPOSITION_FICHIER_FK FOREIGN KEY (IdUser, IdFichier) 
          REFERENCES FICHIER (IdUser, IdFichier)
) ;

Notez dans la table DOSSIER_COMPOSITION l’absence de l’attribut non essentiel Id_Dossier_Composition.


Un micro jeu d’essai :

Table UTILISATEUR

INSERT INTO UTILISATEUR (Login, Mdp) VALUES ('tototo', '*****') ;
INSERT INTO UTILISATEUR (Login, Mdp) VALUES ('loulou', '*****') ;

Table DOSSIER

INSERT INTO DOSSIER (IdUser, IdDossier, NomDossier)  
    SELECT (SELECT IdUser FROM UTILISATEUR WHERE Login = 'tototo')
         , (SELECT COALESCE(MAX(IdDossier) + 1, 1)  
            FROM DOSSIER AS x JOIN UTILISATEUR AS y on x.IdUser = y.IdUser
            WHERE Login = 'tototo')  
      , 'dossier 47' ;

INSERT INTO DOSSIER (IdUser, IdDossier, NomDossier)  
    SELECT (SELECT IdUser FROM UTILISATEUR WHERE Login = 'tototo')
         , (SELECT COALESCE(MAX(IdDossier) + 1, 1)  
            FROM DOSSIER AS x JOIN UTILISATEUR AS y on x.IdUser = y.IdUser
            WHERE Login = 'tototo')  
      , 'dossier 85' ;

INSERT INTO DOSSIER (IdUser, IdDossier, NomDossier)  
    SELECT (SELECT IdUser FROM UTILISATEUR WHERE Login = 'loulou')
         , (SELECT COALESCE(MAX(IdDossier) + 1, 1)  
            FROM DOSSIER AS x JOIN UTILISATEUR AS y on x.IdUser = y.IdUser
            WHERE Login = 'loulou')  
      , 'dossier 12' ;

INSERT INTO DOSSIER (IdUser, IdDossier, NomDossier)  
    SELECT (SELECT IdUser FROM UTILISATEUR WHERE Login = 'loulou')
         , (SELECT COALESCE(MAX(IdDossier) + 1, 1)  
            FROM DOSSIER AS x JOIN UTILISATEUR AS y on x.IdUser = y.IdUser
            WHERE Login = 'loulou')  
      , 'dossier 85' ;

Au résultat :

IdUser    IdDossier    NomDossier
------    --------- 
     1            1    dossier 47
     1            2    dossier 85
     2            1    dossier 12
     2            2    dossier 85

Table FICHIER

INSERT INTO FICHIER (IdUser, IdFichier, NomFichier)
    SELECT (SELECT IdUser FROM UTILISATEUR WHERE Login = 'tototo')
         , (SELECT COALESCE(MAX(IdFichier) + 1, 1)  
            FROM FICHIER AS x JOIN UTILISATEUR AS y ON x.IdUser = y.IdUser
            WHERE Login = 'tototo')  
         , 'fichier 01' ;    
 
INSERT INTO FICHIER (IdUser, IdFichier, NomFichier)    
    SELECT (SELECT IdUser FROM UTILISATEUR WHERE Login = 'tototo')
         , (SELECT COALESCE(MAX(IdFichier) + 1, 1)  
            FROM FICHIER AS x JOIN UTILISATEUR AS y on x.IdUser = y.IdUser
            WHERE Login = 'tototo')  
        , 'fichier 05' ;   
  
INSERT INTO FICHIER (IdUser, IdFichier, NomFichier)    
    SELECT (SELECT IdUser FROM UTILISATEUR WHERE Login = 'loulou')
         , (SELECT COALESCE(MAX(IdFichier) + 1, 1)  
            FROM FICHIER AS x JOIN UTILISATEUR AS y on x.IdUser = y.IdUser 
            WHERE Login = 'loulou')  
        , 'fichier 10' ;    
   
INSERT INTO FICHIER (IdUser, IdFichier, NomFichier)    
    SELECT (SELECT IdUser FROM UTILISATEUR WHERE Login = 'loulou')
         , (SELECT COALESCE(MAX(IdFichier) + 1, 1)  
            FROM FICHIER AS x JOIN UTILISATEUR AS y on x.IdUser = y.IdUser 
            WHERE Login = 'loulou')  
        , 'fichier 01' ;     

Au résultat :

IdUser    IdFichier    NomFichier
------    ---------
     1            1    fichier 01
     1            2    fichier 05
     2            1    fichier 10
     2            2    fichier 01

Table DOSSIER_COMPOSITION

INSERT INTO DOSSIER_COMPOSITION (IdUser, IdDossier, IdFichier)
     SELECT (SELECT IdUser 
             FROM   UTILISATEUR 
             WHERE  Login = 'tototo')
          , (SELECT IdDossier 
             FROM   DOSSIER AS x JOIN UTILISATEUR AS y ON x.IdUser = y.IdUser 
             WHERE  Login = 'tototo' AND NomDossier = 'dossier 47')
          , (SELECT IdFichier 
             FROM   FICHIER AS x JOIN UTILISATEUR AS y ON x. IdUser = y.IdUser 
             WHERE  Login = 'tototo' AND NomFichier = 'fichier 01') ;
        
INSERT INTO DOSSIER_COMPOSITION (IdUser, IdDossier, IdFichier)
     SELECT (SELECT IdUser 
             FROM   UTILISATEUR 
             WHERE  Login = 'tototo')
          , (SELECT IdDossier 
             FROM   DOSSIER AS x JOIN UTILISATEUR AS y ON x. IdUser = y.IdUser 
             WHERE  Login = 'tototo' AND NomDossier = 'dossier 47')
          , (SELECT IdFichier
             FROM   FICHIER AS x JOIN UTILISATEUR AS y ON x. IdUser = y.IdUser 
             WHERE  Login = 'tototo' AND NomFichier = 'fichier 05') ;
        
INSERT INTO DOSSIER_COMPOSITION (IdUser, IdDossier, IdFichier)
     SELECT (SELECT IdUser 
             FROM   UTILISATEUR 
             WHERE  Login = 'tototo')
          , (SELECT IdDossier    
             FROM   DOSSIER AS x JOIN UTILISATEUR AS y ON x. IdUser = y.IdUser 
             WHERE  Login = 'tototo' AND NomDossier = 'dossier 85')
          , (SELECT IdFichier 
             FROM   FICHIER AS x JOIN UTILISATEUR AS y ON x.IdUser = y.IdUser 
             WHERE  Login = 'tototo' AND NomFichier = 'fichier 05') ;
        
INSERT INTO DOSSIER_COMPOSITION (IdUser, IdDossier, IdFichier)
     SELECT (SELECT IdUser 
             FROM   UTILISATEUR 
             WHERE  Login = 'loulou')
          , (SELECT IdDossier 
             FROM   DOSSIER AS x JOIN UTILISATEUR AS y ON x. IdUser = y.IdUser
             WHERE  Login = 'loulou' AND NomDossier = 'dossier 85')
          , (SELECT IdFichier 
             FROM   FICHIER AS x JOIN UTILISATEUR AS y ON x.IdUser = y.IdUser 
             WHERE  Login = 'loulou' AND NomFichier = 'fichier 01') ;   

Au résultat :

IdUser    IdDossier    IdFichier
------    ---------    ---------
     1            1            1
     1            1            2
     1            2            2
     2            2            2

Les INSERT que j’ai codés peuvent paraître compliqués, mais j’ai préféré accéder aux données à la façon de l’utilisateur, c'est-à-dire au moyen des clés « naturelles » : Login, nom du dossier, nom du fichier. On s’y fait assez rapidement...

je ne sais pas comment représenter le fait qu'un dossier est contenu dans un autre dossier.

Votre 2e diagramme est correct. Votre association donne lieu au script SQL suivant :

CREATE TABLE DOSSIER_HIERARCHIE
 (
        IdUser           INT          NOT NULL
      , IdDossier        INT          NOT NULL
      , IdDossierParent  INT          NOT NULL
    , CONSTRAINT DOSSIER_HIERARCHIE_PK PRIMARY KEY (IdUser, IdDossier)
    , CONSTRAINT DOSSIER_HIERARCHIE_DOSSIER_FK FOREIGN KEY (IdUser, IdDossier)
          REFERENCES DOSSIER (IdUser, IdDossier)
    , CONSTRAINT DOSSIER_HIERARCHIE_DOSSIER_PARENT_FK FOREIGN KEY (IdUser, IdDossierParent)
          REFERENCES DOSSIER (IdUser, IdDossier)
) ;

A propos de votre 1er diagramme, vous écrivez : « le champ nivhierachique me facilitera l'affichage ». Vous injectez une redondance, ce qui est malsain. Vous pouvez le faire, mais à condition lors de chaque INSERT, UPDATE, DELETE touchant à la table DOSSIER, de contrôler par un trigger que la valeur prise par cet attribut (et pas champ, concept ayant trait aux fichiers) est valide par rapport à la réalité.

Cette remarque vaut aussi pour l’attribut NomDossierAncetre (table FICHIER).



Quel est votre SGBD ?

[yrichi]

Je tiens d'abord à vous remercier pour votre réponse détaillée et du temps accordé, je comprends un peu mieux certaines de mes erreurs et je vais d'abord prendre compte de vos remarques avant de revenir avec un MCD corrigée.
j'utilise le SGBD MySql 5.0

[yrichi]

Bonjour,

Voici les Règles de Gestion du projet :

RG 1 : un utilisateur a 0 ou plusieurs fichiers
RG 2 : un utilisateur a 0 ou plusieurs dossiers
RG 3 : un Dossier a 0 ou plusieurs fichiers
RG 4 : un fichier a un seul dossier
RG 5 : un fichier a un seul utilisateur
RG 6 : un dossier a un seul utilisateur
RG 7 : Un client est un utilisateur
RG 8 : Un utilisateur peut être un client ou pas ( 0...1 )
RG 9 : Un dossier a 0 ou plusieurs dossiers
RG 10 : Un dossier est dans un seul autre dossier

Ensuite pour éviter les redondances j'ai supprimé tous les attributs non nécessaires et j'ai utilisé la notion d’héritage afin d’éviter de répéter les mêmes attributs dans les Tables Fichier et Dossier.
J’ai ensuite mis en identifiant ( pour éviter les doublons ) les login et nomSociete mais pour les noms de Dossier et de Fichier , j’ai un petit problème car si les éléments se trouve dans le même dossier alors nous somme pas sensée pouvoir avoir deux fichiers ou deux dossiers ayant le même nom mais si ils se trouvent dans des dossiers différents alors cette contrainte n’existe plus .
Je dois donc placer une contrainte lié au dossier contenant les 2 éléments ( fichiers ou dossiers) mais ne sais pas comment représenter cette contrainte dans un MCD

est ce que cette nouvelle représentation est correct ?

[fsmrel]

Bonsoir yrichi,



Avec les règles de gestion des données, on y voit plus clair.

Une petite remarque quand même à ce sujet. Quand vous écrivez :

« RG4 - un fichier a un seul dossier »

Pour ne laisser planer aucun doute, il est préférable d’insister lourdement, en écrivant « au moins un et au plus un » :

« un fichier appartient à au moins et au plus un dossier »

Dans cette série, vous avez utilisé une cardinalité 0,1 pour la patte connectant l’entité-type ELEMENT et l’association APPARTIENT : si les règles de gestion des données 5 et 6 sont dans le principe du « au moins un et au plus un », alors la cardinalité 0,1 est à remplacer par 1,1. Si c’est la cardinalité 0,1 qui est valide, alors au moins une des deux règles ne va pas dans le sens du principe dont je viens de faire mention. Qu’en est-il ?


De la redondance

Selon la règle RG4, un fichier détermine un dossier. Selon la règle RG6, un dossier détermine un utilisateur, en vertu de quoi un fichier détermine transitivement un utilisateur : la règle RG5 est donc une conséquence logique des règles RG4 et RG6 : elle n’est pas essentielle, elle peut disparaître sans qu’on perde de l’information.

Cela veut dire aussi que, dans votre dernier MCD, ça n’est pas l’entité-type (surtype) ELEMENT qui est associée à l’entité-type UTILISATEUR, mais l’entité-type DOSSIER.

J’ai ensuite mis en identifiant ( pour éviter les doublons ) les login et nomSociete

Cela devrait apparaître dans le MCD. Pour cela il faudrait que vous effectuiez la manip suivante avec PowerAMC :

Barre de menus : OUTILS > « Préférences d’affichage » > « Contenu » > « Entité » , et cocher la case « Indicateurs d’identifiant ».

Maintenant, si deux clients ont réellement même nom de société, que ferez-vous ? C’est peut-être l’occasion de faire figurer un attribut pour le numéro SIREN (ou SIRET) des entreprises, et là, avec une clé alternative, pas de problème de doublons.

si les éléments se trouve dans le même dossier alors nous somme pas sensée pouvoir avoir deux fichiers ou deux dossiers ayant le même nom mais si ils se trouvent dans des dossiers différents alors cette contrainte n’existe plus .
Je dois donc placer une contrainte lié au dossier contenant les 2 éléments ( fichiers ou dossiers) mais ne sais pas comment représenter cette contrainte dans un MCD.

Si deux fichiers d’un même dossier ne peuvent pas avoir le même nom, dans un MCD merisien vous ne pouvez pas représenter cette contrainte (a fortiori avec PowerAMC), car en Merise les contraintes ont lieu entre des entités-types et/ou des associations, mais pour les attributs participant à des entités-types distinctes, c’est cuit...

Dans ces conditions (hors héritage), vous pouvez rattraper le coup dans le MLD.

Exemple :




La table DOSSIER a pour clé primaire {IdDossier} et pour clé alternative {IdUser, NomDossier}.

La table FICHIER a pour clé primaire {IdFichier} et pour clé alternative {IdDossier, NomFichier}.


Par contre, dans le contexte de la généralisation des entités-types DOSSIER et FICHIER en un surtype ELEMENT, c’est cuit pour cette technique, car les ingrédients (par exemple NomFichier, IdDossier) ne sont pas dans la même table, et il faudra en passer par des triggers au stade SQL.




N.B. Attention aux homophones : « sensé » et « censé » ne veulent pas dire la même chose...