Discussion :

[SpaceFrog]

Bonjour,

Je dois réaliser une bibliothèque de documents PDF.
Ces documents peuvent être des fiches techniques, des fiches de données de sécurité, des procès verbaux de classement, des formulaires, des manuels ...
Et dépendent des fournisseurs différents.
Et leur mise à jour est soumise à des droits de mise à

Chaque document possède plusieurs critères
L'arborescence classique est:
+-Fournisseur
|+- Fiche technique
|+- FDS
|+- PV

Mais on doit aussi pouvoir rechercher un document par d'autres critères ...
Date
Gamme
Produit
Marque
Nr
...

De plus il doit exister une relation de droits de consultation / modifiaction sur les documents avec une table de users


J'avoue ne pas vraiment voir le nombre et le contenu des tables ...

Merci de vos lumières ...

[Carabi]

Bonjour à toi,

Pour un début de solution, je verrais :

Une table Document(id, date, ..., typeDocument)
Une table TypeDocument(id, libelle)
Ici, tu peux chercher un document en fonction de son type (FT, FDS, PV)

Une table Fournisseur(id, nom, entreprise, marque, etc...)
Une table Produit(id, idFourn, idGamme, nom, etc...)
Une table Gamme(id, libelle)

Une composante de jointure DocumentationProduit(idProduit, idDocument)
Ici, pour retrouver tes documents en fonction du produit, de la gamme. Aussi, tu peux retrouver le fournisseur via l'idProduit.

Pour les droits :

Une table Utilisateur(id, nom, prenom, login, mdp, etc...)
Un utilisateur aura, je pense et j'espère, au moins des droits de consultation, sinon ça sert à rien d'être utilisateur. Donc tu peux faire :

Une table DroitModif(idDocument, idUtilisateur)
Pour autoriser ici un utilisateur à modifier un document. Sinon, on a la solution de l'index bitmap, qui travaille avec des codes binaires pour l'attribution des droits, mais tu n'en a que deux, donc ce n'est, je pense, pas la peine.


Voilà, en espérant t'avoir un peu aidé et t'avoir mis au moins sur la voix. Ce n'est qu'une ébauche, je viendrais sans doute éditer mon post pour de plus amples informations.

Bon courage surtout !

[SpaceFrog]

Ahhh...
je vois ...


Je ne pensais pas faire une table fournisseur masi un champs fournisseur dasn la table Document, car un document n'appartient qu'a un seul et unique fournisseur ...

Quelles sont les règles a respecter en la matière ... ?

[CinePhil]

un document n'appartient qu'a un seul et unique fournisseur

Donc on a l'association :
Document -1,1----Appartenir----0,n- Fournisseur

Ce qui donne :
Document(id, date, ..., typeDocument, FournisseurId)

[Carabi]

Je ne pensais pas faire une table fournisseur

Donc tu ne veux pas stocker les données concernant un fournisseur?

un document n'appartient qu'a un seul et unique fournisseur ...

Produit(id, idFourn, idGamme, nom, etc...)
Avec ça, un produit n'appartient qu'à un et un seul fournisseur.
Après libre à toi de mettre l'id d'un fournisseur dans la table Document ou Produit (dans les deux cas la règle est respectée grâce à celle suscitée). Je dis ça car pour moi, un document se rapporte tout d'abord à un produit plus qu'à un fournisseur...

"La doc JAVA concerne tout d'abord le langage JAVA, même si elle est écrite par SUN..."

On pourra toujours retrouver un document fait par un fournisseur, justement par le produit qu'il livre et auquel il est rattaché, mais bon, c'est une solution parmi tant d'autres !

J'espère avoir été assez clair, bon courage !