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
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