[modélisation] Mersise-Type de documents?

Mersise-Type de documents? [modélisation] - SQL/NoSQL - Programmation

Marsh Posté le 03-11-2003 à 09:53:16    

Bonjour,
 
j'essaie de faire un modèle pour une bibliothèque.
 
Nous avons identifié plusieurs types de documents : lettres, livres, brochures.
 
Chacun de ces types ayant des options particulières (Nbre de pages, couleur, type d'impression etc...)
 
Le problème est que je ne sais pas modélisé ceci. Je pensais au départ à une entité "Document" mais cela ne prendrais pas en compte le fait que chaque type de documents à des options propres.
 
De plus j'aimerais que les formulaires de saisies prennent en compte le type de document pour afficher les bons champs pour les options (en nombre et en qualité).
 
Je bloque :/
 
qq'un aurait une piste?
Je souhaite modélisé de manière rigoureuse.(j'ai déjà trouvé des solutions de contournement mais c'est pas top top.)
 
j'aurais du mieux m'interesser aux cours de modélisation à l'époque je reconnais :)
 
merci pour une piste.

Reply

Marsh Posté le 03-11-2003 à 09:53:16   

Reply

Marsh Posté le 03-11-2003 à 10:48:04    

Mouais, je ne suis pas sur que Merise te serves à quelque-chose pour faire une modélisation ausi basique, surtout si tu n'y connais rien. A mon avis tu ferais mieux d'utiliser Access pour construire un modèle de ta base.

Reply

Marsh Posté le 03-11-2003 à 13:06:32    

yop,
je connais bien merise.
 
Je bute juste sur une bétise j'en suis sur.
 
Je cherche à faire un modèle (MCD ;) ) RAF d'ACCESS, merci :)
 

Reply

Marsh Posté le 03-11-2003 à 13:29:47    

baggins a écrit :

Mouais, je ne suis pas sur que Merise te serves à quelque-chose pour faire une modélisation ausi basique, surtout si tu n'y connais rien. A mon avis tu ferais mieux d'utiliser Access pour construire un modèle de ta base.


Tu sais combien ça coûte Access? :heink:
et sous Linux tu feras comment?


---------------
Whichever format the fan may want to listen is fine with us – vinyl, wax cylinders, shellac, 8-track, iPod, cloud storage, cranial implants – just as long as it’s loud and rockin' (Billy Gibbons, ZZ Top)
Reply

Marsh Posté le 03-11-2003 à 14:30:42    

rational rose pour faire le model physique

Reply

Marsh Posté le 03-11-2003 à 15:43:19    

En vitesse :
 
Entité DOCUMENT.
Propriétés :
- #ISBN
- Titre
- Auteur
- ETC.
- Type de document
 
Entité BROCHURE
#ISBN
Propriétés propres à une brochure
 
Entité LIVRE
#ISBN
...
 
etc.
 
C'est ce qu'il y a de plus simple.
 
Il existe aussi la notion de descripteurs :
 
Entité DOCUMENT
#ISBN
 
Entité DOC_ATTRIBUT
#ISBN
ATTRIBUT_NAME
ATTRIBUT_VALUE
 
Avec une relation 0,n entre DOCUMENT et ATTRIBUT
 
Attention : Ces deux modèles ont chacun leurs points forts. Le premier a pour particularité qu'il nécessite une jointure conditionnelle en foinction du type de document, avec la table correspondant au type de document. C'est le modèle le plus "propre" d'un point de vue analyse, mais le plus complexe au niveau implémentation.
Le second quand à lui va faire hurler tout professeur d'analyse, car il est "sale" d'un point de vue analyse.
Par contre, c'est ce qu'il y a de plus évolutif, car il est extrêment générique (principe de base des descripteurs).
Niveau performances, il est inférieur à l'autre système, et niveau contrôle de la cohérence des données, il ne dispose d'aucun mécanisme permettant de le garantir. Par contre, tu peux créer à la volée de nouveaux types de documents et des attributs sans modifier une ligne de code.
 
Généralement, pour permettre une pseudo garantie de la cohérence des données, on couple cette implémentation avec une table qui va contenir la description des attributs pour chaque type de document, d'où la nom "descripteur". En fait, il s'agit d'un modèle d'implémentation stocké de façon dynamique dans une table, et qui sert de référence lors de l'insertion d'une nouvelle donnée. Chais pas si je suis très clair :D
Si tu veux plus d'explications, je t'en donnerai ce soir, ou plus tard. Pour le moment, y'a mon chef de projet qui regarde par dessus mon épaule et qui se demande bien ce que je fout ;)

Reply

Marsh Posté le 03-11-2003 à 16:07:47    

Nickel Magic, c'est exactement ce à quoi je pensais.
Sans être capable néanmoins de dire lequel était le plus "juste".
merci beaucoup ;)

Reply

Marsh Posté le 03-11-2003 à 16:26:04    

Personnellement, je préfère le second, car d'un niveau pratique dans la vie en entreprise il est bien plus adapté aux besoins réels de la vie active (ne pas avoir à retoucher un programme dès qu'on identifie un nouveau besoin).
Par contre, d'un point de vue analyse, et donc d'un point de vue scolaire, cette méthode ne vaut rien. (en réfléchissant bien, tu peux modéliser n'importe quelle chose avec ce système, et on mélange les petits poids et les carrottes... "table poubelle" quoi...)
 
Je te conseille donc d'opter pour la première solution, qui pourtant est "moins bonne". Par contre, tu peux t'amuser à détailler la seconde, et indiquer les avantages de chacune des deux implémentations, je pense qu'un prof pourrait aimer une telle chose... Et d'un point de vue purement personnel, j'aimerais bien savoir ce qu'un prof pense de ce système, qu'on trouve plusque courrament dans le ssystèmes experts, nécessitant une grande généricité, à côté d'autres bidouilles pas vraiment mieu (ni vraiment pire :D) qui ne vallent pas un clou niveau analytique, mais qui sont pourtant les solutions les mieu adaptées aux besoins les plus complexes.

Reply

Marsh Posté le 03-11-2003 à 16:46:27    

Pour savoir ce qu'en penses un prof, je ne pourrais te le dire... Je les ais déjà quittés...
 
Sinon à terme un système de gestion de bibliothèque associative va en découler. J'ai du temps, je vais donc creuser chacune des deux possibilités. J'en profites pour faire proprement et me rappeler ce que j'ai appris, ce qui n'est pas le cas au boulot.
 
merci pour la grosse piste ;)

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed