Créer une application de gestion de bandes dessinées

Maintenant que nous connaissons les besoins de l'application, comment les intégrer à notre base de données Access?

La première chose à faire est de créer les tables nécessaires au stockage des données.
Se pose alors une question : de quelles tables avons-nous besoin?.

S'il apparaît évident que nous avons besoin d'une table pour contenir le catalogue de bande dessinées, d'autres tables sont moins évidentes.
Par exemple : comment gérer les auteurs?
Doit-on créer une table par rôle : c'est-à-dire une table pour les scénaristes et une pour les dessinateurs?
Ou une seule table pour tous les rôles?
Comment faire pour lier le catalogue aux auteurs?
Est-il nécessaire de créer une table supplémentaire pour associer chaque bande dessinée à ses auteurs?

Pour nous aider à répondre à toutes ces questions, nous allons faire une analyse à l'aide de la méthode Merise.

Cette phase de conception est très importante : une bonne analyse facilite ensuite la création des objets (requêtes, formulaire, états, ...) et la maintenance.

Si vous n'avez pas le courage ou le temps de lire les tutoriels au sujet de Merise, voici un petit résumé du vocabulaire à connaître pour suivre ce tutoriel :

- Modèle conceptuel de données (MCD) : définitions des concepts de l'application;
- Modèle logique de données (MLD) : définitions des tables de l'application, sans cibler de système de base de données en particulier;
- Modèle physique de données (MPD) : définitions des tables de l'application, en prenant en compte les particularités d'un système de base de données.
- Entité : Elément de base du MCD (peut être une bande dessinées, un état , une personne, ...);
- Association : Lien entre plusieurs entités, définie souvent par un verbe (appartient à, est un, ...);
- Cardinalité : Nombre d'occurrences possibles d'une association (0-n, 1-n, ...);
- Attributs : Propriété d'une entité ou d'une association (un nom, un identifiant, un commentaire,...);

Nous verrons plus en détail ces notions durant notre analyse.

Nous allons utiliser l'application AnalyseSI.
Cet outil est gratuit et, même s'il n'est plus maintenu, nous aidera efficacement à faire notre analyse.

Téléchargez et décompressez le fichier de l'application AnalyseSI.
Exécutez ensuite le fichier analysesi.exe ou analysesi_opengl.exe.

L'outil s'ouvre sur une nouvelle analyse.

Les boutons en haut permettent les opérations habituelles (ouverture, sauvegarde, ...).

Le navigateur à gauche vous permet de changer de vue :

Nous allons créer directement les entités du MCD, et générer les entrées du dictionnaire au fur et à mesure.

Cliquez sur le bouton MCD à gauche.
Le MCD est pour l'instant vide, nous allons y ajouter les entités.

Les entités représentent les informations dont nous avons besoin.
Par exemple, une entité peut être une bande dessinée, un auteur, ...

Nous nous aidons de notre spécification fonctionnelle pour savoir quelles entités ajouter au modèle.

Pour ajouter une entité, cliquez sur le bouton Ajouter une entité en haut.

L'entité ajoutée est vide :



Double-cliquez sur l'entité pour l'éditer.

Notre première entité représente le catalogue de bandes dessinées; appelons la BDs en modifiant le nom en haut de la fenêtre d'édition.



Ajoutons maintenant les attributs de cet entité :
Chaque entité doit posséder un identifiant unique.
Nous ajoutons donc tout d'abord un attribut nommé id_bd de type uniqueidentifier.
Dans la fenêtre d'édition de l'entité, saisissez en bas le nom de l'attribut et son type de données.



Cliquez sur le bouton Ajout pour ajouter l'attribut au catalogue.

L'attribut est alors disponible dans la liste de gauche.
Cliquez sur le bouton Ajouter une nouvelle information (la flèche droite au milieu) pour ajouter cet attribut à l'entité.



L'attribut s'affiche alors dans la liste de droite.
Il disparaît de la liste de gauche car un attribut ne peut être utilisé qu'une seule fois dans le modèle.

Une bande dessinée doit également avoir un titre, ajoutons un attribut titre_bd.



Le titre est un varchar de taille 255, c'est à dire une chaînes de caractère de taille 255.
Comme il n'y a pas de lien direct entre AnalyseSI et Access, le type de données est saisi à titre informatif.

Notez qu'on nomme l'attribut titre_bd, ce qui permettra de le distinguer des autres titres du modèle.

De la même manière, on ajoute un attribut pour le commentaire, nommé commentaire_bd (type varchar 255 par exemple).
Puis un attribut note_bd de type bigint (entier long) qui contiendra la note donnée à la bande dessinée de 1 à 10.
Et enfin un attribut tome_bd de type varchar (10) pour le numéro de tome de la BD.
Ce tome est une chaîne de caractères, ce qui nous permet de saisir des numériques mais aussi des caractères, par exemple pour des hors-série : HS01, HS02, ...

Nous avons ajouté les attributs les plus simples :


Viennent ensuite dans la spécification les images affectées à la bande dessinée.

On a spécifié qu'on souhaitait pouvoir définir une ou plusieurs images.

Si on se limitait à une image unique par bande dessinée, il suffirait d'un attribut image_bd.
Pour ajouter plusieurs images, on pourrait imaginer plusieurs attributs image_bd1, image_bd2, ...

Ce modèle assez simpliste cache une grave erreur.
En effet si on a défini 2 attributs images et qu'on souhaite par la suite pouvoir en gérer 3, il faudrait revoir le modèle.
Ajouter un attribut est assez simple, mais implique de nombreuses modifications dans l'application :
- ajout d'un champ dans la table
- ajout de ce champ aux requêtes
- ajout de ce champ dans les formulaires d'affichage
- modification du code VBA si nécessaire
- ...

Ceci n'est pas envisageable, on ne doit donc pas créer plusieurs attributs porteurs d'une même information.

Il faut alors définir pour les images une autre entité.
Créez une nouvelle entité et nommez-la Images.
Pour cette entité, ajoutez un attribut id_image de type uniqueidentifier.
Cet attribut est la clé de l'image qui permet de l'identifier de manière unique.
Puis ajoutez, toujours à l'entité Images, un attribut chemin (de type varchar 255).

Nous voici donc munis de deux entités :



Il nous faut maintenant lier ces entités; c'est le rôle des associations.

Pour ajouter une association, cliquez sur le bouton Ajouter une association en haut.

Une association se traduit par un verbe : appartient à, est de type, ...
Ici par exemple, on traduit notre association par : A pour image de bd.

Double-cliquez sur l'association pour l'éditer et modifier son nom :



Ensuite il faut créer les liens entre l'association et les entités, ainsi que leur cardinalité.
Les cardinalités sont le nombre d'occurrences possible du lien.
Elles se définissent de chaque côté de l'association.
Par la suite, elle permettent de déduire le modèle logique de données (MLD).

Pour ajouter un lien, cliquez sur le bouton Ajouter un lien en haut.

Créez tout d'abord le lien entre l'entité Bds et l'association A pour image de bd.
Pour cela, après avoir cliqué sur le bouton Ajouter un lien, cliquez sur l'entité et faites glisser la souris jusque l'association sur laquelle vous relâchez la souris.
Ensuite, créez un lien entre l'entité Images et l'association A pour image de bd.

Par défaut la cardinalité des liens est 0,n.



Comment choisir les cardinalités?
Il faut faire des petites phrases, partant de l'entité :
- une BD peut avoir entre 0 et n images, donc une cardinalité 0,n entre Bds et A pour image de bd;
- une image peut être utilisée dans 0 à n bandes dessinées, donc une cardinalité 0,n entre Images et A pour image de bd;

Avec ces 2 petites phrases, on a donc décidé que :
- une bande dessinée pourra ne pas avoir d'images; si elle en a, elle pourra en avoir une ou plusieurs;
- une image pourra ne pas être utilisée, ou être utilisée par plusieurs bandes dessinées.

Notez que l'analyse ne permet pas de définir des cardinalités autres que 0,1 et n.
Si on souhaite limiter à 5 images par exemple, cela se fera plus tard lors de la conception de la base de données.

On se rend compte dès maintenant qu'il faudra gérer un catalogue d'images.

Les images étant maintenant gérées par l'association nouvellement créée, passons à la donnée suivante : la série à laquelle appartient la bande dessinée.

Ici encore nous n'allons pas ajouter un simple attribut pour la série.
La série n'est pas un champ texte libre.
Nous avons défini, dans les spécifications, l'utilisation d'un catalogue de séries.
Cela permettra de proposer une liste des séries pour faciliter la saisie et éviter les erreurs.

Nous allons donc créer une entité Séries.
Comme vu précédemment : créez une nouvelle entité, nommez-la Séries et ajoutez lui un attribut id_série de type uniqueidentifier.
Nous compléterons plus tard ces autres attributs.

Créez maintenant une nouvelle association nommée Appartient à la série.
Ajoutez un lien entre chacune des entités (Bds et Séries) et l'association.
Puis écrivons les phrases nous aidant à définir les cardinalités :
- une BD peut appartenir à 1 série au maximum, donc une cardinalité 0,1 entre Bds et Appartient à la série;
- une série peut être définie pour plusieurs BD, donc une cardinalité 0,n entre Séries et Appartient à la série;

En effet une bande dessinée peut n'appartenir à aucune série, et ne peut appartenir à plus d'une série à la fois.
Une série quant à elle peut contenir plusieurs bandes dessinées, voir aucune si on vient de définir la série et qu'on n'a pas encore créé les BD associées.

Modifiez le lien entre Bds et Appartient à la série afin de définir la cardinalité à 0,1.
(Double-cliquez sur un lien pour le modifier).



N'oublions pas que l'entité Séries n'est pas terminée.
Ajoutons lui comme défini dans la spécification :
- un attribut titre_série (varchar 255).
- un attribut commentaire_série (varchar 255).
- un attribut note_série (bigint).

Pour les images, on procède comme pour les images de bandes dessinées.
La même entité Images est utilisée.
Ainsi on pourra affecter la même image à une série et à une bande dessinée.

Nous créons par contre une nouvelle association nommée A pour image de série.
Créez un lien entre l'entité Séries et cette association, puis entre l'entité Images et cette association.
Les cardinalités de ces liens sont les mêmes que pour les images de BD : 0,n.



Nous avons ajouté toutes les informations spécifiées pour les séries, retournons à notre entité Bds.
Il nous reste une information complexe : les auteurs de la bande dessinée.

Comme nous avons spécifié l'utilisation d'un catalogue d'auteurs, il seront naturellement à choisir parmi ce catalogue.
Les auteurs ne seront pas des attributs de l'entité Bds, mais une association entre une entité Auteurs et l'entité Bds.

Menons une petite réflexion sur ces auteurs :
- nous avons défini 2 rôles : scénariste et dessinateur; il est possible qu'on souhaite par la suite ajouter de nouveaux rôles (coloriste par exemple) .
- un auteur peut être parfois scénariste, parfois dessinateur, et parfois les deux en même temps
- on peut également ne pas connaître l'auteur d'une bande dessinée (même si c'est écrit dessus, on n'a peut-être pas la BD sous la main)
- ou alors l'utilisateur peut tout simplement ne pas souhaiter gérer les auteurs, et nous ne souhaitons pas le forcer à le faire

Pour pouvoir facilement gérer les rôles, il nous faut une entité Roles.
Cette entité a pour attributs :
- un identifiant unique id_role (uniqueidentifier);
- un libellé libellé_role (varchar 50).

Les auteurs sont également une entité, nommée Auteurs avec comme attributs :
- un identifiant unique id_auteur (uniqueidentifier);
- un attribut nom_auteur (varchar 50).
- un attribut prenom_auteur (varchar 50).
- un attribut note_auteur (bigint).

Les auteurs sont liés au rôles par l'intermédiaire d'une association nommée Est un :
- un auteur doit avoir au moins un rôle, et peut en cumuler plusieurs, donc une cardinalité 1,n entre Auteurs et Est un;
- un rôle peut être défini pour plusieurs auteurs, donc une cardinalité 0,n entre Rôles et Est un;



Maintenant, il faut ajouter une association entre Bds et Auteurs.
On pourrait penser ajouter simplement une association pour chaque rôle, par exemple :
- une association Est dessiné par;
- une association Est scénarisé par.
Mais comment pourrait-on ajouter alors un nouveau rôle, par exemple le coloriste?
Il faudrait ajouter une nouvelle association, ce qui enfreint les règles.
On ne doit pas avoir à modifier le modèle de données pour ajouter une telle information.
Il faut ajouter une seule association, nommée Est réalisé par, qui sera liée à la fois aux auteurs et aux rôles.
On peut le faire avec une seule association, inutile donc d'en créer deux.

Créons cette association, nommée Est réalisé par.
Ajoutez un lien entre Bds et cette association.
Une bande dessinée peut être réalisée par plusieurs auteurs.
D'autre part, on souhaite que l'utilisateur puisse ne pas renseigner d'auteur.
Donc la cardinalité de ce lien est 0,n.

Ajoutez maintenant deux liens entre cette association et les entités Auteurs et Rôles.
- un auteur peut avoir réalisé entre 0 et n BDs, donc une cardinalité 0,n entre Auteurs et Est réalisé par;
- un rôle peut être associé à entre 0 à n BDs, donc une cardinalité 0,n entre Rôle et Est réalisé par;

Il peut paraître étrange de définir par exemple qu'un auteur peut n'avoir réalisé aucune bande dessinée, mais cela nous permettra de créer dans le catalogue des auteurs sans avoir besoin de créer tout de suite les bande dessinées associées.

A noter : il devrait y avoir une contrainte à ce niveau.
En effet le couple auteur + rôle choisi dans l'association Est réalisé par doit être couvert par l'association Est un.
Il ne doit pas être possible par exemple de définir en dessinateur d'un BD un auteur qui n'est que scénariste.
AnalyseSI ne permet pas de gérer ces contraintes, nous la gérerons par la suite lors de la conception.



A ce stade de l'analyse, nous avons défini : le catalogue de BD, les auteurs, les séries.
Tout est associé dans les règles, il nous reste maintenant à nous occuper du catalogue d'exemplaires possédés.

Le catalogue de bandes dessinées contient toutes les bandes dessinées ajoutées par l'utilisateur.
Quant à lui, le catalogue d'exemplaires possédés va permettre à l'utilisateur de définir quelles sont les BD du catalogue qu'il possède.
Une solution simple aurait été de rajouter un attribut dans le catalogue pour définir les BD possédées.
Ce serait très simple mais n'apporterait qu'une information binaire : je possède cette bande dessinée ou pas.
Nous souhaitons ajouter plus d'information : le format de la BD, son état , la date d'achat, ...
Et de plus il doit être possible de définir plusieurs exemplaires d'une même bande dessinée.

Pour cela créons un nouvelle entité nommée Exemplaires.
Premier attribut à ajouter à cet entité : un identifiant unique id_exemplaire (uniqueidentifier).
Ajoutez un deuxième attribut pour la date d'achat : date_achat de type datetime.

Pour gérer les formats et l'état, il nous faut de nouvelles entités nommées Formats et Etats.
Chacune de ces entités contient comme attribut :
- un identifiant unique (uniqueidentifier) : id_format et id_etat;
- un libellé (varchar 50) : libelle_format et libelle_etat;

On associe un exemplaire à un format avec une association nommée Est au format.
On associe un exemplaire à un état avec une association nommée Est dans l'état.

Un exemplaire peut être dans un seul état au maximum (il ne peut pas être en bon état et en mauvais état à la fois).
Un exemplaire peut être dans un seul format au maximum (il ne peut pas être en petit format et grand format à la fois).
Les états et formats peuvent être définis pour aucun ou plusieurs exemplaires.
On déduit de ces trois dernières phrases les cardinalités de nos liens entre les exemplaires et les états et formats.



Reste à associer les Bds aux Exemplaires avec une association Est un exemplaire de.
- un exemplaire n'est exemplaire que d'une seule bande dessinée (et au moins une), donc une cardinalité 1,1 entre Exemplaires et Est un exemplaire de;
- une bande dessinée peut être définie pour aucun ou plusieurs exemplaires, donc une cardinalité 0,n entre Bds et Est un exemplaire de;

Nous voici enfin arrivés à la fin de l'analyse : le MCD est terminé.



Vous pouvez télécharger le document d'analyse (HTTP) à ouvrir avec AnalyseSI

Pour générer le MLD automatiquement avec AnalyseSI, cliquez sur le bouton Construction en haut.
Les entités deviennent des tables dans le MLD.

En fonction des cardinalités définies dans le MCD, les associations sont représentées soit par une nouvelle table, soit par une clé étrangère (foreign key) :
Une table est nécessaire pour gérer une association multiple : par exemple les BDs qui peuvent être réalisées par plusieurs auteurs.
Une clé étrangère suffit pour une association simple : par exemple les BDS qui ne peuvent appartenir qu'à une seule série.
La clé étrangère est en fait un simple champ qui contient l'identifiant d'une table : par exemple un champ dans Bds qui contient l'identifiant de la série.

Cliquez sur le bouton MLD à gauche pour voir le MLD : Voici le MLD généré par AnalyseSI :



Ce modèle n'est toujours pas spécifique à Access, il est généré sans tenir compte de la base de données ciblée.

Nous découvrons, lors du passage du MCD au MLD, tout l'intérêt de cette analyse.
Ce qui peut paraître évident avec l'expérience apparaît dans le MLD, par exemple :
- pour la série d'appartenance d'une bande dessinée, il suffit d'un champ id_serie dans la table des bandes dessinées;
- par contre, pour les auteurs, une table supplémentaire est_realise_par est nécessaire pour pouvoir gérer plusieurs auteurs par BD.

Après le MCD et MLD, vient le MPD.
Ce modèle définit la structure de la base de données en tenant compte des spécificités de l'application utilisée.

Il peut donc y avoir des différences entre le MLD et le MPD.
Par exemple pour la gestion des images :
- pour une version Access antérieure à 2007, il faut gérer une table des images avec leur chemin vers un fichier.
- par contre à partir de la version 2007, on peut utiliser un champ pièce-jointe pour contenir les images; la table Images est alors supprimée du MPD.

Nous n'allons pas définir un MPD ici.
Tout d'abord parce que AnalyseSI ne propose pas d'interface pour le définir (hormis le catalogue d'attribut qui contient le type de données des champs).
Et ensuite parce que notre projet de petite taille ne nécessite pas ce travail : le MPD serait très proche du MLD.
Nous allons directement construire la base de données dans Access à partir du MLD.