Discussion :

[almoha]

Bonjour,

Je réfléchis sur un MCD d’inventaire des livres (en langue française) que je possède dans ma bibliothèque.
Avant d’énoncer les règles de gestion, il est important d’expliciter ce que j’entends par les concepts nommés « œuvre » et « édition ».

Œuvre => regroupe toutes les formes d’expression écrites (hors journaux ou revues). Un roman, un recueil de nouvelles, une bibliographie, un essai, un document de référence, un manuel scolaire, une bande-dessinée sont considérés comme des œuvres.

Edition => une œuvre fait l’objet d’une édition que je possède physiquement dans ma bibliothèque. Concrètement il s’agit du livre sur mon étagère. Pour chaque livre il me revient de relever les caractéristiques de base. Notamment :

- Le titre
- Le ou les auteurs et les éventuels autres contributeurs (traducteur, illustrateur…)
- La date de publication
- Nombre de pages
- Le ou les genres
- …

Outre ces caractéristiques minimales que présente chaque livre, certaines éditions peuvent nécessiter la récolte de caractéristiques complémentaires.
Un exemple concret : je possède l’édition d’un roman en français au format poche, traduite à partir de l’œuvre originale en anglais. Je pars ici du postulat que ladite édition a été précédée d’une édition française en grand format (ce n'est pas toujours le cas). Les caractéristiques complémentaires sont alors les suivantes :

- Titre de l’édition originale anglaise, sa date de publication et le nom de son éditeur.
- Le nom de l’éditeur français ayant fait paraître l’édition en grand format et sa date de publication.

Je précise que ces éléments complémentaires des « éditions parentes » se limitent à ceux que je suis en mesure de recueillir dans l’édition entre mes mains (ils figurent sur la page qui précède le début du récit). Mon exemple décrit le cas où le maximum d’informations complémentaires est récolté.

Les « éditions parentes » ne se conçoivent pas en tant qu’éditions au sens où je l’entends (car je ne les possède pas), ce sont juste des éléments de « parenté » avec l’édition détenue qui doivent être restitués.

Vous l’avez compris, il n’existe pas « d’éditions parentes » dans le cas d’une première édition en grand format d’une œuvre française.


Les premières règles de gestion arrêtées sont les suivantes :

R001 : une œuvre littéraire paraît dans une à plusieurs éditions
R002 : une édition fait paraître une et une seule œuvre
R003 : une édition est éditée par un et un seul éditeur
R004 : un éditeur publie une à plusieurs éditions
R005 : une édition est possédée à un ou plusieurs exemplaires
R006 : un exemplaire concerne la possession d’une et une seule édition
R007 : un exemplaire présente un et un seul état (état : "comme neuf", "bon état"…)
R008 : un état est présenté par un ou plusieurs exemplaires
R009 : une œuvre est créée par un à plusieurs contributeurs
R0010 : un contributeur crée une à plusieurs œuvres.
R0011 : une œuvre est thématisée par un à plusieurs genres
R0012 : un genre thématise une à plusieurs œuvres

À partir de ces règles, j’ai conçu cette ébauche de MCD :



Arrivé à ce stade, j’éprouve de la peine à intégrer les caractéristiques « parentes » (éventuelles) évoquées plus haut (titre original, éditeur d’origine…). Il me semble qu’elles ne sauraient figurer en tant que rubriques dans l’entité « edition » (le bonhomme NULL pointant le bout de son nez). Pourriez-vous m’éclairer sur la meilleure façon de procéder ? Merci.

[escartefigue]

Bonjour Almoha et bienvenue dans ce forum

Le contexte est bien décrit, les règles de gestion sont fournies et identifiées, c'est parfait

Votre MCD me semble être une bonne base.

Pour les typologies comme les genres ou les états, il est recommandé de positionner une cardinalité minimale de zéro coté typologie. En effet, à un instant "t", il est possible de n'avoir aucune œuvre pour un genre ou aucun exemplaire pour un état.
L'état d'un livre pourrait être simplement un attribut du livre plutôt qu'un lien d'association vers une typologie. Cet attribut peut faire l'objet d'une contrainte "check" au stade SQL pour en vérifier la validité.

L'entité-type [ETAT]n'a d'intérêt que si on veut un libellé long associé à l'état ou qu'on veut historiser les différents états du livre (auquel cas il faut transformer l'association en ternaire en faisant intervenir une entité-type [DATE])

L'ISBN n'existe que pour les ouvrages parus depuis 1970, il faudra donc autoriser les ISBN marqués "null" dans certains cas

Pour ce qui concerne l'édition parente, une relation reflexive sur l'[edition] me semble appropriée.

EDIT : pensez aussi au fait que certains livres n'ont pas d'éditeur, c'est le cas des éditions à compte d'auteur.

Pour vous aider, vous pourrez peut-être vous inspirer d'un autre fil de discussion qui concerne une médiathèque ICI

[almoha]

Bonsoir,

Merci escartefigue pour vos réponses.

C'est entendu pour la cardinalité minimale de zéro coté typologie et la suppression de l'entité-type "Etat".

L'ISBN n'existe que pour les ouvrages parus depuis 1970, il faudra donc autoriser les ISBN marqués "null" dans certains cas

Je plussoie, un petit nombre de mes livres (mes plus anciens San Antonio par exemple) n'ont pas d'ISBN, les autres (95 % de mes quelque 3000 livres) en ont un. Au lieu d'autoriser le marquage NULL des ISBN, est-il envisageable de prévoir "NOT NULL" et par conséquent utiliser une valeur par défaut vide ? Cette réflexion me conduit à une autre du même ordre s'agissant des informations des éditions parentes : est-il concevable que ces dernières soient des attributs de l'entité-type [edition] de type "NOT NULL" avec une valeur par défaut vide ?

Si cela est possible et si je me projette : contrairement aux éditions que je possède, les éventuelles éditions parentes ne seraient pas des enregistrements dans la future table "edition". Partant de là, je me demande ce qu'il en est de la relation réflexive ...

pensez aussi au fait que certains livres n'ont pas d'éditeur, c'est le cas des éditions à compte d'auteur.

Tout à fait. J'opte néanmoins pour le postulat que dans ce cas l'auteur est l'éditeur (c'est l'option que je retiendrai par exemple pour le livre de Paprick que je viens de me procurer )
Merci pour le lien vers le fil de discussion concernant la médiathèque.
Au plaisir.

[escartefigue]

Bonjour Almoha

Au lieu d'autoriser le marquage NULL des ISBN, est-il envisageable de prévoir "NOT NULL" et par conséquent utiliser une valeur par défaut vide ? Cette réflexion me conduit à une autre du même ordre s'agissant des informations des éditions parentes : est-il concevable que ces dernières soient des attributs de l'entité-type [edition] de type "NOT NULL" avec une valeur par défaut vide ?

Pour l'ISBN, il n'y a de toute façon aucun doute : si la colonne ISBN est à blanc, on peut considérer qu'il n'y a pas d'ISBN. Par contre, l'inconvénient est qu'on ne pourra plus activer une contrainte UNIQUE, on risque donc de créer à tort des doublons d'ISBN sur cette colonne pour deux éditions différentes. Ou alors il faut mettre en œuvre un déclencheur.

Pour les éditions parentes, si l'on veut éviter les marqueurs "null", alors il faut générer une table à partir de l'association réflexive.
Dans Looping, ça se fait très simplement en cliquant sur l'association, puis en activant en bas la case à cocher "générer une table de correspondance"
Ainsi, plus de "null", mais l'intégrité référentielle reste vérifiée


Voici ce que ça donne avec Looping



Et le DDL généré ici décliné pour SQL server :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
CREATE TABLE EO_edition(
   EO_ident INT IDENTITY,
   EO_isbn CHAR(13),
   EO_date DATE NOT NULL,
   EO_resume VARCHAR(255) NOT NULL,
   PRIMARY KEY(EO_ident)
);
 
CREATE TABLE EP_parent(
   EO_ident_enfant INT,
   EO_ident_parent INT NOT NULL,
   PRIMARY KEY(EO_ident_enfant),
   FOREIGN KEY(EO_ident_enfant) REFERENCES EO_edition(EO_ident),
   FOREIGN KEY(EO_ident_parent) REFERENCES EO_edition(EO_ident)
);

Si cela est possible et si je me projette : contrairement aux éditions que je possède, les éventuelles éditions parentes ne seraient pas des enregistrements dans la future table "edition". Partant de là, je me demande ce qu'il en est de la relation réflexive ...

Je ne pense pas que ce soit une bonne idée de créer deux types d'entité, l'un pour les éditions possédées, l'autre pour les éditions parentes, si c'est bien de ça qu'il s'agit.
Ce serait une redondance.

[almoha]

Bonjour escartefigue,

Merci. Je comprend l’intérêt de la relation réflexive mise en place, à savoir retracer le fil qui relie une édition à une autre. Dans l’application (Access) que je souhaite mettre en place, le point d’entrée de l’affichage sera toujours et uniquement l’édition que je possède (l’affichage ne se fera donc jamais à partir d’une édition parente que je ne possède pas). Pour une édition française en grand format traduite à partir d’une œuvre anglaise, l’affichage sera du type :

La maison du sommeil
Jonathan COE (auteur)
Jean PAVANS (traducteur)
Editeur : Gallimard
Date publication : 1998
Titre VO : The house of sleep
Editeur VO : Viking Press
Date publication VO : 1997

Avec la relation réflexive, les rubriques des éditions parentes (titre original, éditeur d’origine…) devront-elles bien figurer dans l’entité [EO_edition] tout comme l’ISBN (donc possiblement marquées « null ») ?

Je ne pense pas que ce soit une bonne idée de créer deux types d'entité, l'un pour les éditions possédées, l'autre pour les éditions parentes, si c'est bien de ça qu'il s'agit.
Ce serait une redondance.

Nous sommes d'accord.

[escartefigue]

Une piste éventuelle serait d'utiliser l'héritage pour ne mettre dans le sur-type que les attributs obligatoires, et dans le sous-type ceux qui ne concernent que les éditions possédées.
On pourrait alors créer une vue pour consolider les éléments des éditions possédées.

[almoha]

J'ai transcrit la notion d'héritage de la sorte :



Le MLD généré par Looping :
editeur = (id_editeur, nom);
edition_possedee = (id_edition, isbn, date_publication, nb_pages, resume, #id_editeur, #id_oeuvre);
exemplaire = (id_exemplaire, etat, etagere, #id_edition);
edition_autre_VF = (#id_edition, editeur_ed_gd_format_vf, date_pub_ed_gd_format_vf);
edition_autre_VO = (#id_edition, titre_edition_vo, editeur_vo, date_pub_vo);

Je ne sais pas si ma démarche est la bonne...

[escartefigue]

Je voyais plutôt quelque chose comme ceci :



Une édition possédée [EP] est en association facultative avec une édition [EO], qui est le surtype de toute édition, avec des attributs à minima : identifiant et date d'édition.
Il faudra vérifier par une contrainte que l'identifiant du parent n'est pas le même que l'identifiant de l'édition possédée.

Cette édition possédée [EP] est acquise en 1 à plusieurs exemplaires [EX] possédant une date d'acquisition.
Chaque exemplaire est identifié relativement à l'édition possédée, au stade SQL, l'identifiant sera donc l'identifiant de l'édition EO_ident complété d'un chrono EX_seqn.

Chaque exemplaire [EX]est rangé à un instant "t" dans une étagère [ET], le fait qu'un exemplaire ne peut être situé que sur une seule étagère à un instant "t" se matérialise par la flèche pointant vers l'étagère (représentation simplifié de la contrainte).
La table associative issue de la ternaire RG_ranger aura donc pour identifiant {EO_ident, EX_seqn, CA_date} c'est à dire l'identifiant de l'exemplaire et la date.

J'ai coché la case "classe d'entité fictive" dans Looping pour que [CA_calendrier] ne devienne pas une table (d'où les parenthèses autour de son nom), elle n'est ici que pour sa participation à la ternaire.

Voici le script correspondant (sans la contrainte vérifiant que le parent est différent de l'exemplaire possédé, contrainte qu'il faudra donc ajouter) :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
CREATE TABLE ED_editeur(
   ED_ident COUNTER,
   ED_nom VARCHAR(128) NOT NULL,
   PRIMARY KEY(ED_ident)
);
 
CREATE TABLE ET_etagere(
   ET_ident COUNTER,
   PRIMARY KEY(ET_ident)
);
 
CREATE TABLE EO_edition(
   EO_ident COUNTER,
   EO_date DATE NOT NULL,
   ED_ident INT NOT NULL,
   PRIMARY KEY(EO_ident),
   FOREIGN KEY(ED_ident) REFERENCES ED_editeur(ED_ident)
);
 
CREATE TABLE EP_edition_possedee(
   EO_ident INT,
   EP_isbn CHAR(13) NOT NULL,
   EP_resume VARCHAR(255) NOT NULL,
   EO_ident_parent INT,
   PRIMARY KEY(EO_ident),
   FOREIGN KEY(EO_ident) REFERENCES EO_edition(EO_ident),
   FOREIGN KEY(EO_ident_parent) REFERENCES EO_edition(EO_ident)
);
 
CREATE TABLE EX_exemplaire(
   EO_ident INT,
   EX_seqn SMALLINT,
   EX_date_acq DATE NOT NULL,
   PRIMARY KEY(EO_ident, EX_seqn),
   FOREIGN KEY(EO_ident) REFERENCES EP_edition_possedee(EO_ident)
);
 
CREATE TABLE RG_ranger(
   EO_ident INT,
   EX_seqn SMALLINT,
   CA_date DATE,
   ET_ident INT NOT NULL,
   PRIMARY KEY(EO_ident, EX_seqn, CA_date),
   FOREIGN KEY(EO_ident, EX_seqn) REFERENCES EX_exemplaire(EO_ident, EX_seqn),
   FOREIGN KEY(ET_ident) REFERENCES ET_etagere(ET_ident)
);

[almoha]

Merci. J’avoue que cela se corse me concernant. Il me semble comprendre à peu près le raisonnement adopté. J’ai lancé le script (dans Access) pour créer les tables et relations afin d’effectuer des tests. J’arrive par exemple à ce type de résultat :



Mais j’éprouve des difficultés à me figurer comment le modèle permettrait de gérer les différents types d’édition en ma possession :

1- Edition en français en grand format d’une œuvre française (donc pas d’éditions parentes)
2- Edition en français en poche d’une œuvre française (donc édition parente en français grand format, dans la grande majorité des cas)
3- Edition en français en grand format d’une œuvre étrangère (donc édition parente étrangère)
4- Edition en français en poche d’une œuvre étrangère (donc deux éditions parentes : étrangère et en français grand format)

Je ne vois pas dans le modèle les rubriques telles que titre original, éditeur VO, date publication étrangère, date publication française grand format…

Un jeu d’essai couvrant les différents types d’édition me permettrait sans doute de mieux comprendre la logique du modèle. Mais c’est peut-être abuser de votre disponibilité pour ma problématique.

[escartefigue]

Désolé, j'avais oublié que le SGBD était Access et le script que j'ai fourni correspond à SQL server, je le renverrai au bon format quand j'aurai le temps si besoin (je ne suis pas sur le bon poste pour le faire).

Pour ce qui concerne le rattachement entre parent et enfant, on peut envisager un trigger de contrôle, mais sous réserve que les règles soient applicables systématiquement, or ce qui me gêne c'est le cas n°2

2- Edition en français en poche d’une œuvre française (donc édition parente en français grand format, dans la grande majorité des cas)

Et pour ce qui concerne les différentes colonnes, je n'ai proposé qu'un modèle minimal, il faut bien entendu l'enrichir des attributs manquants.
Le titre sera un attribut à ajouter dans le type d'entité [EO_edition], et du coup, le titre de la VO sera retrouvé grâce à l'association entre l'édition possédée [EP] et son ou ses édition(s) [EO] parente(s)
L'éditeur de la VO sera retrouvé grâce au lien d'association entre [EO] et [ED], tout comme l'éditeur de la VF du reste

[almoha]

J’ai créé dans Access chaque table séparément à partir du script fourni. Je n’ai pas eu d’erreur mais il se peut qu’il y ait néanmoins des anomalies. Je suis donc preneur du script idoine.

2- Edition en français en poche d’une œuvre française (donc édition parente en français grand format, dans la grande majorité des cas)

Dans de rares cas, certaines œuvres françaises paraissent directement en poche, donc il n'y a pas d'édition parente. Ce cas est donc comparable à une édition en français en grand format d’une œuvre française.

Merci de vos utiles précisions concernant l'attribut "titre" et la récupération des données parentes grâce aux liens d'association entre [EP] et [EO] et [EO] et [ED]. Se posera la question des requêtes correspondantes, mais chaque chose en son temps

[escartefigue]

Se posera la question des requêtes correspondantes, mais chaque chose en son temps

En effet


Et en relisant, je vois que les identifiants sont de type COUNTER, c'est donc bien un script ACCESS !

[almoha]

En examinant les tables générées avec le script, je me pose une question concernant la table [EP_edition_possedee]. Pour une édition que je possède en français traduite à partir de l'anglais, je testerais ainsi :







L'édition française que je possède a pour parent l'édition anglaise que je ne possède pas.
Mais en voulant tester avec une édition possédée sans édition parente (édition œuvre française en GF), je me rends compte que le champ "EO_ident_parent" de la table [EP_edition_possedee] ne serait pas valorisé … Quelque chose m'échappe sans doute

[escartefigue]

Il est tout à fait normal que l'identifiant du parent ne soit pas renseigné dans le cas où il n'y a pas de parent

Si vous avez coché la case "générer une table de correspondance" dans l'association (associer), alors vous n'aurez pas à gérer les marqueurs "null", il n'y aura tout simplement pas d'occurrence dans la table issue de (associer) dans ce cas

[almoha]

Merci pour votre remarque pertinente. J'ignorais cette possibilité de forcer la création d'une table de correspondance. Le script généré par Looping pour la table [associer] est le suivant :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
CREATE TABLE associer(
   EO_ident_enfant INT,
   EO_ident_parent INT NOT NULL,
   PRIMARY KEY(EO_ident_enfant),
   FOREIGN KEY(EO_ident_enfant) REFERENCES EP_edition_possedee(EO_ident),
   FOREIGN KEY(EO_ident_parent) REFERENCES EO_edition(EO_ident)
);

Je m'interroge sur ce script. Pourquoi, contrairement à [EO_ident_parent], [EO_ident_enfant] n'est-il pas noté "NOT NULL" ? Et surtout, pourquoi [EO_ident_enfant] est-il clé primaire ? Car dans ce cas, il est impossible de rattacher deux parents à une édition (une édition de poche peut avoir un parent VF grand format et un parent VO). Si j'enlève au champ sa propriété de clé primaire, il devient alors possible de rattacher deux parents. Ai-je commis une erreur en bâtissant le MCD ? Le voici ci-dessous :

[Paprick]

Bonjour,

Je m'interroge sur ce script. Pourquoi, contrairement à [EO_ident_parent], [EO_ident_enfant] n'est-il pas noté "NOT NULL" ? Et surtout, pourquoi [EO_ident_enfant] est-il clé primaire ?

Si [EO_ident_enfant] est clé primaire, il est forcément UNIQUE et NOT NULL : donc inutile de le préciser.
Par contre, je ne comprends pas très bien l'intérêt de lier simultanément les 2 classes d'entités avec, d'une part, l'héritage et, d'autre part, l'association...

[escartefigue]

@Paprick :
l'héritage permet de distinguer les éditions en général des éditions possédées. Seules les éditions possédées ont des attributs complets.
l'association est de type parent enfant : une édition possédée EP peut avoir une édition parente dans EO et une édition EO peut avoir plusieurs éditions filles dans EP. Cette parenté n'est gérée que pour les éditions possédées.


Pour rappel :

Mais j’éprouve des difficultés à me figurer comment le modèle permettrait de gérer les différents types d’édition en ma possession :

1- Edition en français en grand format d’une œuvre française (donc pas d’éditions parentes)
2- Edition en français en poche d’une œuvre française (donc édition parente en français grand format, dans la grande majorité des cas)
3- Edition en français en grand format d’une œuvre étrangère (donc édition parente étrangère)
4- Edition en français en poche d’une œuvre étrangère (donc deux éditions parentes : étrangère et en français grand format)

Sauf que je n'avais pas bien lu le 4^e exemple, du coup la cardinalité que j'ai proposée (0,1) ne convient pas puisqu'on peut avoir deux éditions parentes ! À corriger bien sûr


@Almoha :
Du coup, je complète la réponse de Paprick : vu qu'il faut modifier les cardinalités de l'association pour mettre 0,n de chaque coté, la clef primaire de la table associative va devenir le couple EO_ident_parent+EO_ident_enfant
Et comme l'indique justement Paprick, toute clef primaire étant par définition "not null", il n'est pas utile de le préciser dans le script, c'est implicite.

[SQLpro]

Quelques erreurs, ommissions et ajouts... :
1) une édition peut contenir plusieurs oeuvres (notamment les collections "Bouquins", "Omnibus"... les anthologies...) cardinalité à revoir
2) il faudrait une entité "localisation" (Pièce, bibliothèque (le meuble), rangée...)
3) au niveau du contributeur peut être rajouter la nature de la contribution : auteur / traducteur / organisation...)
4) il faudrait peut être un support (papier, fichier e-, ...)
5) il manque la notion de collection (la Pleiade, les cahiers de l'herne, Que sais-je ?, ...)


A +

[escartefigue]

@Frédéric : certes, mais ne brûlons pas les étapes, nous n'en sommes qu'au début
Certains des aspects que tu mentionnes comme la collection sont traités dans l'autre fil de discussion relatif à une médiathèque et dont j'ai communiqué le lien.
Concernant la localisation de l'étagère, deux cas de figure : l'étagère fixe et l'étagère d'un meuble, meuble qui peut changer de pièce. Nous verrons plus tard si besoin comment traiter ces points.

[almoha]

@Paprick & @escartefigue : c'est noté pour la clef primaire toujours implicitement UNIQUE et NOT NULL.

@escartefigue : c'est compris pour le changement des cardinalités de l'association [AS_associer].

@SQLpro : merci pour vos remarques pertinentes. Elles rejoignent pour la plupart des problématiques que j'avais gardées en réserve le temps d'y réfléchir (recueil, tome, collection…)

Commençons par la problématique liée aux fonctions exercées par le ou les contributeurs :

R0013 : chaque contributeur exerce une à plusieurs fonctions (à la fois auteur et illustrateur par ex.).
R0014 : chaque fonction est exercée par aucun, un ou plusieurs contributeurs.

La modélisation suivante est-elle correcte ?



Le script de la table [PA_participer] :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
CREATE TABLE PA_participer(
   OE_ident INT,
   CO_ident INT,
   FO_ident INT,
   PRIMARY KEY(OE_ident, CO_ident, FO_ident),
   FOREIGN KEY(OE_ident) REFERENCES oeuvre(OE_ident),
   FOREIGN KEY(CO_ident) REFERENCES CO_contributeur(CO_ident),
   FOREIGN KEY(FO_ident) REFERENCES FO_fonction(FO_ident)
);