Modélisez vos bases de données

Dans cette seconde partie du cours, vous verrez la première des trois étapes de la modélisation d’une base relationnelle. Cette première étape, c’est le modèle conceptuel des données (MCD).

Comme son nom l’indique, vous allez représenter les concepts présents dans vos données, et vous allez aussi chercher les associations qui existent entre ces concepts.

À vous de jouer

Voici ce que je vous propose. À partir des données des lieux de tournage (que je vous réaffiche plus bas), il faut que vous dégagiez les concepts principaux, ainsi que leurs caractéristiques.

Je vous propose de faire des petits rectangles divisés en trois parties. Dans la partie haute, vous mettrez le nom du concept, dans la partie centrale la liste des caractéristiques. Et pour la partie basse, un peu de patience, je vous en parle un peu plus loin dans le chapitre.

Ça y est ?

C’est bien ! Il n’y a pas de bonne ou de mauvaise réponse à cet exercice : si votre réponse diffère un peu de la mienne, ce n’est pas très grave. Certes, deux modélisations ne se valent pas toujours, mais c’est avec l’expérience que vous acquerrez les automatismes de modélisation.

Voici une réponse possible :

• J’ai ici volontairement ignoré la colonne « identifiant du lieu », car vous verrez la notion d’identifiant un peu plus tard.

• La colonne   Producteur    a été représentée sur ce diagramme par la caractéristique   nom  du concept   SocieteDeProduction    .

• La colonne   Réalisateur_ice  a été représentée sur ce diagramme par la caractéristique   nom  du concept   Realisateur_ice  .

• Les colonnes   Coordonnée en X  et   Coordonnée en Y   ont été respectivement transformées en   longitude  et   latitude  .

Formalisez vos concepts en classes

Sans le savoir, vous venez de dessiner un diagramme de classes UML. Dans ce diagramme, vous avez formalisé tous nos concepts sous forme de classes : vous avez les classesFilm,   Lieu de tournage, etc.

Sur ce diagramme, chaque classe est représentée par un rectangle, dont le nom figure sur la partie haute.

Une classe, c’est un peu comme un moule : elle donne la forme générale des instances qui seront créées à partir d’elle. À partir d’un moule à gaufre, vous pouvez fabriquer autant de gaufres que vous souhaitez. Le moule, c’est la classe, et vos gaufres, ce sont les instances.

De même, la classeFilmdéfinit la forme générale des instances issues de cette classe. Ainsi, OSS 117 : Alerte rouge en Afrique noire, est une instance de la classeFilm, tout comme 120 Battements par minute, ou bien Tanguy 2.

Caractérisez vos classes avec les attributs et les méthodes

Les attributs

Dans la partie centrale de notre rectangle, nous indiquons les attributs. Un attribut, c’est une caractéristique de la classe.

Un attribut doit être typé, c’est-à-dire que l’on sait à l’avance quels types de valeurs il peut contenir :

• Valeurs numériques (un nombre entier, un nombre décimal, etc.) ;

• Du texte ;

• Une date ;

• Etc.

Pour définir un domaine, vous pouvez le faire soit en énumérant toutes les valeurs possibles (définition en extension), soit en donnant les caractéristiques des valeurs, comme par exemple « ce doit être un nombre entier » (définition en intention).

Par exemple :

• Définition en extension :

  • domaine de l’attributtypeDeTournage  :   ["Long métrage", "Téléfilm", "Série TV", "Série web"]

• Définition en intention :

  • domaine dedateDeDebut: date ;

  • domaine decodePostal: nombre entier compris entre 1 000 et 99 999.

On peut définir des attributs composites : ils sont composés de plusieurs valeurs (dont le nombre est fixe) qui ne sont pas forcément du même type. Par exemple, un attributadresseest souvent composé de :

• Un numéro de voie (nombre entier supérieur à 0) ;

• Un libellé de voie (du texte) ;

• Un code postal (nombre entier) ;

• Un nom de ville (texte) ;

• Etc.

On peut définir aussi des attributs multivalués : cela signifie que l’attribut peut prendre zéro, une ou plusieurs valeurs du même type (ou même domaine), sans que l’on sache à l’avance combien il y en aura. Ce serait par exemple le cas d’un attributnuméro(s) de téléphoned’une classe   Personne  , car une personne peut avoir zéro, un, ou de multiples numéros de téléphone.

Enfin, on dit qu’un attribut est dérivé, lorsqu’il peut être déterminé à partir d’autres attributs. Dans votre cas,anneeDuTournagepeut être déterminé à partir dedateDeDebut.

C’est pour cela que l’on préfère ne pas stocker en mémoire la valeur d’un attribut dérivé, mais plutôt sa méthode de calcul.

Tout à fait ! C’est pour cela qu’il y a une 3e partie dans les rectangles que vous avez dessiné : elle sert à accueillir les méthodes.

Les méthodes

Les méthodes se programment soit dans le code de l’application qui va utiliser le SGBD, soit dans le SGBD lui-même lorsque celui-ci le permet. Mais dans les deux cas, vous ne verrez pas cela dans ce cours. En effet, la programmation de méthodes dans un SGBD est trop spécifique au SGBD en question pour être abordé ici.

Une méthode est un enchaînement d'opérations destiné :

• Soit à modifier les attributs ;

• Soit à calculer un résultat à partir des attributs ;

• Soit les deux en même temps. 

En fait, les méthodes définissent le « comportement » de votre classe, c’est-à-dire les actions qu’elle est capable de réaliser.

Dans votre cas, vous pouvez donc créer une méthode qui s’appelle   determinerAnneeDeTournage(), qui déterminera l’année de tournage à partir de   dateDeDebut.

Dialoguez avec les développeurs logiciel grâce à l’UML

Dialoguez grâce au diagramme de classes

Vous avez déjà entendu parler de la programmation « orientée objet » ?

Dans un langage de programmation orientée objet, le développeur définit des objets. Un objet, c’est un concept, une idée ou une chose du monde réel. Chaque objet possède des attributs (ce sont ses caractéristiques) ainsi qu’un ensemble de comportements possibles.

Oui, mais avouez que la description que je viens de vous donner est quand même très proche de ce que vous venons de voir : des classes caractérisées par des attributs et dont les méthodes définissent un comportement.

En fait, le diagramme de classes UML est aussi utilisé par les développeurs qui codent avec des programmes orientés objet : Python, PHP, C++, Java, etc. Et c’est bien plus pratique comme ça !

L'utilisation du diagramme de classes UML pour la modélisation de la base de données s'est généralisée avec la croissance de la programmation objet.

Certains langages orientés objet proposent même des fonctionnalités qui permettent de créer automatiquement la structure de la base de données relationnelle à partir du code informatique écrit en ce langage. On appelle cela des ORM pour Object-Relational Mapping.

Par exemple, si on suppose que NeoNomade est programmé en Python, alors ce code Python contiendra quelque part la définition d’une classeTournage, écrite de cette manière :

class Tournage(BaseDeDonnees):

    [...]

    dateDeDebut = Column(Date)
    dateDeFin = Column(Date)

    [...]

    def determinerAnneeDeTournage(self):
        return self.dateDeDebut.year

Distinguez le diagramme de classe des autres diagrammes UML

Le diagramme de classes que vous avez dessiné est bien adapté à votre problème, car il décrit la structure de votre future BDD. Cette structure est statique, elle ne varie pas dans le temps. En effet, la structure d’une base de données ne change uniquement que lorsque le logiciel qui l’utilise est mis à jour sous une nouvelle version. 

Conclusion, pour une BDD, le diagramme de classe UML est suffisant. Il est aussi très utile pour les développeurs qui vont représenter les classes de leur programme. Même si pour eux, quelque chose de statique reste insuffisant. Le langage UML prévoit alors aussi d’autres types de diagrammes permettant par exemple de représenter le comportement du programme dans le temps.

En résumé

Représentation d’une classe en UML  se fait comme ceci :

Maintenant que vous avez identifié toutes les classes de votre modèle, il va falloir créer du lien entre elles !