GED

Bonjour,

Dans mon application, un utilisateur peut créer des dossier et affecter d'autres utilisateurs à ces dossiers en leur limitant les droits d'accès(lecture, écriture), aussi il peut créer des fichiers à l'intérieur du dossier qu'il a créé ou d'un dossier auquel il a été affecté et où il a le droit d'écriture, lorsqu'un utilisateur modifie un fichier, on laisse la première version non modifiée et on crée un nouveau fichier (nouvelle version de notre fichier) dans le même dossier. En plus de ça, un utilisateur affecté à un dossier doit "valider" (marquer comme validé ou comme refusé) le fichier de ce dossier.
Et c'est l'utilisateur qualifié comme administrateur, qui crée les utilisateurs.

Pour cela, j'ai créé les tables suivantes (MCD):

Utilisateur (id_utilisateur, nom, prenom, identifiant, pass, adresse, telephone, mail, fonction, date_creation, admin(oui ou non) )

dossier (id_dossier, nom, date_creation)

fichier(id_fichier, nom date_creation)

relations:
utilisateur---creer-dossier
dossier---contenir---fichier
utilisateur---modifier---fichier
utilisateur---creer---fichier

Mais je ne suis pas sure si c'est la bonne conception, s'il me manque quelque chose...
Pour cela, je demande vos avis et aides
Merci d'avance

Un détail pour commencer : Dans un MCD, on ne parle pas de tables mais d'entités.

Ça semble pas mal dans l'ensemble. Il manque quand même la notion de version de fichier non ?

Merci pour votre réponse,
Pour les versions j'ai pensé à ajouté la propriété "num_version" à l'association modifier (entre les entités utilisateur et fichier)... Mais si vous avez une autre proposition elle serait la bienvenue.

Et si vous pouvez m'aider à sortir du "pas mal" vers le "bien" (par ce que moi même je pense que c'est moins du pas mal) en ajoutant autres choses pour enrichir le MCD ce serait très utile.

Merci infiniment

Comme les différentes versions des fichiers sont conservées dans les dossiers, chaque version est en fait un fichier physique avec sans doute un nom de fichier différent. Au niveau MCD, c'est donc la version qui est donc contenue dans le dossier et pas directement le fichier.

Dossier -0,n----contenir----1,1- Version -(1,1)----Se_rapporter_à----1,n- Fichier

Les cardinalités entre parenthèses signifient qu'on procédera à une identification relative de la version par rapport au fichier, ce qui veut dire que la version sera identifiée par le couple {id_fichier, num_version}.

Citation:

---

En plus de ça, un utilisateur affecté à un dossier doit "valider" (marquer comme validé ou comme refusé) le fichier de ce dossier.

---

Il suffit d'ajouter un attribut 'Etat_version' par exemple pour dire la version est valide, en attente de validation...
On peut utiliser ici un code externalisé dans une autre entité.

Version -1,1----Statuer----0,n- Etat_version

À propos, la fonction de l'utilisateur devrait elle aussi être externalisée dans une autre entité et une association établie entre la fonction et l'utilisateur.

Tu peux dessiner ton MCD complet avec un logiciel de modélisation tel que PowerAMC (la Rolls payante) ou OpenModelsphere (moins complet mais gratuit).

Propose ensuite le schéma ici afin de voir si c'est toujours du 'pas mal' ou du 'bien'.

Merci, merci beaucoup.

J'ai mis le MCD en join. J'ai aussi ajouté une entité "departement" (comme le cas de "fonction")...Qu'est ce que vous en pensez?

Edit: j'ai aussi pensé à ajouter aux entités "dossier, fichier et version" une propriété "chemin" qui contient le chemin complet sur le serveur pour qu'on puisse les localiser.

Ça me semble très bien tout ça !

Citation:

---

Envoyé par dark_meteor

J'ai mis le MCD en join. J'ai aussi ajouté une entité "departement" (comme le cas de "fonction")...Qu'est ce que vous en pensez?

---

Tu as compris le principe ! :ccool:

Citation:

---

Edit: j'ai aussi pensé à ajouter aux entités "dossier, fichier et version" une propriété "chemin" qui contient le chemin complet sur le serveur pour qu'on puisse les localiser.

---

Le chemin ne doit figurer que sur le dossier.
Puisque la version de fichier est dans un seul dossier, on trouve le chemin du de la version du fichier avec le chemin du dossier.

La date de création devrait elle aussi être dans l'entité Version à mon avis.

Il te reste à indiquer les identifiants des entités et à matérialiser l'identification relative de la version par rapport au fichier.

Je ne sais pas si j'ai réaliser "matérialiser l'identification relative de la version par rapport au fichier", car je n'ai pas bien compris exactement ce que vous voulez dire. (Si c'est le fait d'ajouter la clé étrangère de fichier vers version, c'est fait:))
Enfin, voici le MCD et MLD créés.
Et je vous remercie beaucouuuup pour l'aide que vous m'avez apporté.

Citation:

---

Envoyé par dark_meteor

Je ne sais pas si j'ai réaliser "matérialiser l'identification relative de la version par rapport au fichier", car je n'ai pas bien compris exactement ce que vous voulez dire. (Si c'est le fait d'ajouter la clé étrangère de fichier vers version, c'est fait:))

---

"Matérialiser l'identification relative", c'est, au niveau MCD, mettre la cardinalité 1,1 entre parenthèses, comme je l'avais fait plus haut :

Citation:

---

Version -(1,1)----Se_rapporter_à----1,n- Fichier

---

Au niveau MLD, cela entraîne le fait que l'identifiant du fichier est non seulement clé étrangère dans la table Version mais aussi participe à la clé primaire :
Version (fichier_id_fichier, num_version, dossier_id_dossier, etat_version_id_etat, date_creation)

Je ne sais plus comment on fait ça dans OpenModelsphere. Ça avait été expliqué je crois par fsmrel dans une autre discussion du même forum et de mémoire c'est assez tordu comme manip'. :? Une recherche dans le forum t'y conduira peut-être.

EDIT :
Voici la méthode pour l'identification relative dans OpenModelsphere.

Bonsoir,
Merci beaucoup et voici les nouveaux MCD et MLD.
Est ce que vous pensez que c'est bien présenté (coté MLD)? est ce que l'existence de la case: <1> clé primaire (num_version) est normal? et le fait que le champ "num_version" n'est pas souligné dans la table version ne pose pas de problème?

Et un grand merci pour votre aide :)
EDIT: J'ai ajouté une association "étre_affecté_à" entre les tables "utilisateur" et "dossier" car après avoir créer un dossier, on doit inviter d'autres utilisateurs à le voir... en leur limitant les droits d'accès 'lecture' ou 'ecriture' et alors dans l'association Utilisateur--0,N--étre_affecté_à--1,N--Dossier j'ai ajouté 2 propriétés booléenne "acces_lecture" et "acces_ecriture" mais j'ai un doute: j'ai autoriser une valeur nulle dans les deux propriétés par ce que normalement on donne à un utilisateur soit le droit de lecture soit le droit d'écriture mais je ne sais pas si c'est faisable. Alors qu'est ce que vous en pensez?

Merci d'avance

Citation:

---

Envoyé par dark_meteor

Est ce que vous pensez que c'est bien présenté (coté MLD)? est ce que l'existence de la case: <1> clé primaire (num_version) est normal? et le fait que le champ "num_version" n'est pas souligné dans la table version ne pose pas de problème?

---

Essaie de générer le script SQL et regarde si la clé primaire est bien composée des deux colonnes.
En tout cas, le schéma semble correspondre à ce que décrivait fsmrel dans un de ses messages. Perso, je n'ai jamais essayé.

Citation:

---

EDIT: J'ai ajouté une association "étre_affecté_à" entre les tables "utilisateur" et "dossier" car après avoir créer un dossier, on doit inviter d'autres utilisateurs à le voir... en leur limitant les droits d'accès 'lecture' ou 'ecriture' et alors dans l'association Utilisateur--0,N--étre_affecté_à--1,N--Dossier j'ai ajouté 2 propriétés booléenne "acces_lecture" et "acces_ecriture" mais j'ai un doute: j'ai autoriser une valeur nulle dans les deux propriétés par ce que normalement on donne à un utilisateur soit le droit de lecture soit le droit d'écriture mais je ne sais pas si c'est faisable. Alors qu'est ce que vous en pensez?

---

Je mettrais plutôt une seule colonne, clé étrangère vers une table de description des droits.

Ce qui fait que le MCD deviendrait :
Utilisateur -0,n----avoir----(1,1)- Affectation -(1,1)----concerner----1,n- Dossier
Droit -0,n----réglementer----1,1------|

Du fait de l'identification relative, l'affection est identifiée par le couple {id_utilisateur, id_dossier}, comme pour lune table associative issue de ton schéma ci-dessus. En fait, j'ai transformé l'association en entité.

On aurait donc les tables supplémentaires :
Droit (id_droit, id_libelle, id_description...)
Affectation (id_utilisateur, id_dossier, id_droit...)

D'accord j'ai bien compris votre proposition et elle me semble hyper bonne.
Alors il ne reste que dire un très très grand merci, je ne sais pas qu'est ce que j'aurais du faire sans votre aide
merci beaucouuuup

Après avoir relu votre réponse, j'ai encore une question si vous permettez, est ce que c'est accepté de créer l'entité Affectation sans identifiant dans le MCD? Je la laisse vide comme ça?

EDIT:
Est ce que le champ "id_droit" ne doit pas figurer dans la clé primaire de la table Affectation? (avec une identification relative) car je pense que même si on l'y ajoute, cela ne va pas donner une redondance au niveau de la clé primaire.

Merci d'avance

pouvez vous m'aider ? :pleure: