• 20 heures
  • Moyenne

Ce cours est visible gratuitement en ligne.

course.header.alt.is_video

course.header.alt.is_certifying

J'ai tout compris !

Mis à jour le 03/09/2019

Appréhendez les objets et le modèle relationnel

Connectez-vous ou inscrivez-vous gratuitement pour bénéficier de toutes les fonctionnalités de ce cours !

Les bases de données servent à la collecte et à l'enregistrement d'informations. Avant de commencer à enregistrer, vous devez décider quoi enregistrer : c'est le domaine fonctionnel de votre projet !

Comme je l'ai évoqué dans l'introduction, nous allons organiser votre ensemble de données de manière structurée et qui plus est, en utilisant le vocabulaire du domaine fonctionnel de votre projet.

Pour cela, nous adoptons une approche orientée objet (AOO). Un objet représente un concept ou une entité du monde "réel". Le domaine fonctionnel est vu comme une composition de ces objets.

Afin de modéliser la composition d'objet de votre domaine fonctionnel, nous allons utiliser un langage spécifique et particulièrement bien adapté : UML.

Bien qu'UML soit destiné à décrire l'organisation d'un système avec une approche orientée objet (AOO), et non une base de données relationnelle, il peut servir de base à sa conception en modélisant le domaine fonctionnel (grâce au diagramme de classes).

C'est cette démarche que nous allons voir maintenant.

Que va-t-on enregistrer dans la base de données ?

Tout d'abord, vous devez définir ce que va stocker votre base de données et c'est là qu'UML entre en scène !

Grâce au diagramme de classes UML, vous allez décrire ce que vous pensez devoir enregistrer comme information mais aussi comment l'enregistrer (la structuration de l'information).

Avant d'entrer dans le vif du sujet, il est utile de comprendre quelques concepts de base de l'approche orientée objet (AOO) et leur "traduction" dans une base de données relationnelle.

Les notions manipulées en objet

La notion d'objet

Un objet est un élément autonome. Il peut être identifié comme un élément physique « réel » (un crayon, une voiture...) ou comme un élément abstrait ou conceptuel (un ensemble, une liste...).

L'objet possède plusieurs caractéristiques, entre autres :

  • un nom : nom commun unique, il donne le type de l'objet (ex. : voiture)

  • des attributs : ce sont les propriétés de l'objet (ex. : couleur, masse à vide, longueur...)

La notion de classe

Une classe est le modèle abstrait d'un objet. Elle définit les attributs et les opérations de cet objet. C'est à partir de ce modèle que seront créés les objets « concrets » possédant des valeurs particulières pour leurs attributs.

Ainsi la classe définit les caractéristiques de tous les objets de cette classe (nom, liste des attributs).

La notion d'instance

L'instanciation est l'action de création d'un objet à partir d'une classe. Le résultat de cette création est une instance de la classe. Les instances d'une classe sont les occurrences d'objets correspondant à cette classe (ex. : la voiture de mon voisin).

Les notions manipulées par la base de données

Comme nous l'avons vu plus haut, une base de données relationnelle est un ensemble de tableaux (appelés « tables »). Ces tables correspondent globalement aux classes en AOO.

Chaque colonne d'une table représente un attribut.

Chaque ligne (appelée tuple ou n-uplet) représente une instance donnant ainsi la valeur de chaque attribut de l'objet.

Une base de données relationnelle est donc composée d'un ensemble de tables, pouvant être liées entre elles. Cette manière d'organiser les éléments s'appuie sur ce que l'on appelle un modèle relationnel.

Maintenant que nous avons vu les notions essentielles, nous allons commencer la modélisation de notre domaine.

Décrire vos premières classes

Voici un exemple de classe en UML (nous allons voir cela plus en détail juste en dessous) :

La classe « Restaurant »
La classe « Restaurant »

Dans un diagramme de classes, une classe est représentée par une boîte rectangulaire, comprenant plusieurs parties séparées par des traits horizontaux :

  • dans la partie haute : le nom de la classe

  • dans la partie en dessous : la liste des attributs.

Nous voyons ici que dans notre domaine fonctionnel nous manipulons des Restaurants (via la classe Restaurant) et les attributs de la classes (nomcuisineadressenote) sont les informations que nous voulons enregistrer pour chaque restaurant.

Si nous traduisons cela en base de données, nous allons créer une table restaurant qui contiendra les colonnes nomcuisineadressenote (chaque attribut devient une colonne). Chaque instance de restaurant sera représentée par une ligne dans cette table :

nom

cuisine

adresse

note

Chez Luigi

Italien

1 Rue d'Issy

4

Burger quid

Fast food

2 Chai Watt

1

La cuisine au beurre

Terroir

Le Faubourg Ville

3

Au lit on dort

Asiatique

10B Rue Seully

3

La mère Michelle

Fruits de mer

Port Salle Hutte

5

Sur le même principe, voici une autre table listant les informations relatives à un groupe d'amis :

id

prenom

nom

couleur_yeux

1

Chandler

Bing

bleu

2

Phoebe

Buffay

vert

3

Monica

Geller

bleu

4

Ross

Geller

marron

5

Rachel

Green

bleu

6

Joey

Tribbiani

marron

7

Phoebe

Abbott

bleu

Nous avons dans la table 7 tuples qui correspondent à 7 instances de la classe Ami.

Voici la classe Ami qui correspond à cette table, avec en précision supplémentaire le type de donnée de chaque attribut (String ce qui correspond à du texte) :

La classe « Ami »
La classe « Ami »

Nous observons d'ores et déjà des différences entre la représentation des données à l'aide de classes UML et leur structuration dans la base de données. Cela est tout à fait normal, car nous représentons l'information de points de vue légèrement différents.

Mais rassurez-vous, nous allons voir comment passer de l'une à l'autre, en introduisant un nouveau type de schéma : le modèle physique de données.

Passez du diagramme de classes au modèle physique de données

Dis-moi à quoi ressemble ta base de données...

Vous vous dites peut-être qu'autant avec un diagramme de classes on a bien une représentation schématique de l'organisation de l'information, autant la description des tables n'a rien de très synthétique. Et si ma base de données doit contenir plusieurs tables, ça va vite être illisible ! C'est pas faux !

C'est ici qu'intervient un autre type de schéma : le modèle physique de données (ou MPD) .

Voyons comment est représentée la table ami dans un MPD :

Modèle physique de données ‒ Table « ami »
Modèle physique de données ‒ Table « ami »

Avouez que cela ressemble beaucoup à la représentation de la classe Ami. Nous avons ici 3 parties :

  1. celle du haut contient le nom de la table

  2. les deux suivantes contiennent les attributs (colonnes de la table). Ne vous préoccupez pas de la séparation des colonnes en deux parties distinctes pour l'instant.

Comme dans le diagramme de classes, nous précisions le type de données de chaque attributs (VARCHAR, ce qui correspond à du texte, comme nous le verrons plus tard).

Quelle démarche adopter ?

OK. C'est bien joli tout ça, mais je fais quoi moi, concrètement, devant ma feuille blanche ?

Effectivement, nous avons vu tout un tas de notions, et il est temps de voir comment s'en servir.

La démarche est assez simple en réalité, comme nous l'avons vu, vous vous basez sur une approche orientée objet :

  1. Vous commencez par identifier les concepts ou entités de votre domaine fonctionnel.
    => Vous listez ainsi les classes.

  2. Pour chaque classe, vous identifiez ensuite les informations à enregistrer et leur type (texte, nombre...).
    => Vous obtenez ainsi un diagramme de classes avec leurs attributs.

  3. Vous créez le modèle physique de données à partir du diagramme de classes en :

    1. créant une table pour chaque classe ;

    2. créant, dans chaque table, une colonne pour chaque attribut de la classe correspondante.

Une dernière chose avant d'entrer plus dans le détail de la conception d'une base de données, mais qui a toute son importance : quels noms donner aux différents éléments (classes, tables, attributs...) ?

C'est ce que nous allons voir maintenant.

Bien nommer les choses

Guitariste, Musicien, Personne ou Légende... ?

Prenons Mark Knopfler (ou Robert Johnson, Jimmy Page, Jimi Hendrix, Jack White, Matthieu Chedid...), suivant l'information que vous souhaitez enregistrer et le domaine fonctionnel dans lequel vous vous inscrivez, vous pouvez dire que ce sont des guitaristes ou bien des musiciens ou simplement des personnes ou même des légendes !

Choisir un nom demande réflexion !

Les noms sont l'appellation des éléments constitutifs des systèmes complexes. Si les noms ne sont pas appropriés, le système peut rapidement être inintelligible.

Si les noms sont clairs, bien choisis et partagés par tous les membres de l'équipe projet, alors la communication sera bien plus efficace !

Puisqu'une base de données permet de sauvegarder des informations afin de modéliser la manière dont un système fonctionne, choisir de bons noms et créer un modèle précis d'un système nécessite de parler aux différents acteurs concernés. Différentes personnes peuvent avoir des point de vues différents sur un système.

Un diagramme UML est un excellent outil pour cette discussion. Et grâce à cette discussion, vous développerez un modèle qui commencera à refléter la façon dont son système fonctionne.

Cela nécessitera peut-être plusieurs versions successives de diagrammes UML et plusieurs conversations avant d'arriver à une image claire du système. Mais croyez-moi, si les composants d'un système sont nommés avec précision, le modèle que vous créerez sera clair à la fois pour vous et pour vos clients.

Regardez le diagramme de classes ci-dessous, vous êtes en train de concevoir une base de données pour un tourneur (organisateur de concerts) :

Diagramme de classes UML ‒ Concert

Votre client ne connaît peut-être pas comment fonctionne une base de données, mais il sera en mesure de voir comment vous appelez les choses et comprendre à peu près comment les différents éléments du domaine fonctionnel sont représentés et liés.

Si quelque chose le dérange, il pourra discuter avec vous sur le lexique employé ou la logique à laquelle vous pensez.

Trouver des noms pertinents

Choisir les bons noms est important pour le schéma d'une base de données. La précision dans la dénomination conduit à une communication précise pendant le projet, dans l'entreprise, mais aussi dans votre code source.

Il est tout à fait normal de ne pas trouver les bon termes du premier coup. Mais voici quelques pistes pour vous aider.

Est-ce un nom trop général ou trop spécifique ?

Vous devez choisir des noms qui ne soient ni trop spécifiques ni trop généraux.

Par exemple, si vous avez une classe représentant ce que vous vendez dans une boulangerie, vous pouvez l'appeler Pain (baguette, gâche, boule de campagne...).

Si c'est tout ce qui est vendu, ça peut être un bon nom. Mais si en plus le boulanger vend des viennoiseries le terme Pain devient bien plus discutable.

A contrario, si vous choisissez un nom trop général comme Article et que votre boulanger fait aussi traiteur et distribue le journal local, vous allez peut-être mélanger les torchons avec les serviettes (ou plutôt les miches avec les canards) ! Dans ce cas, avoir trois classes ArticleBoulangeriePlatAEmporter et Journal permettrait d'avoir une organisation plus claire.

Un exemple plus concret

Vous êtes en train de modéliser une base de données pour la gestion d'une entreprise.

Vous aller probablement créer une table contenant les informations sur le personnel de l'entreprise. Vous pourriez l'appeler employe.

Mais imaginez que cette table contienne en fait les informations de toutes les personnes travaillant pour l'entreprise comme les intérimaires, les consultants... alors le nom employe sera confus.

Un autre programmeur de votre équipe peut ne pas comprendre que la table employe contienne plus que des employés. Potentiellement, il ou elle créerait une autre table pour les informations sur les « travailleurs externes » (intérimaires, consultants) en reproduisant partiellement votre table employe.

Si vous aviez compris que le client voulait mettre toutes les informations sur le personnel (interne ou externe) dans la même table, vous auriez probablement dû choisir un nom plus général que « Employé ». Si vous aviez nommé la table travailleur ou main_d_oeuvre par exemple, la confusion aurait probablement été évitée.

Donc, après avoir créé le diagramme de classes UML, révisez-le avec vos clients. Leur retour sur vos choix de noms et votre organisation de l'information sera très utile à la fois pour la compréhension du système mais aussi pour le développement d'un modèle précis, cohérent et adapté au contexte.

Conventions de nommage

Les conventions de nommage sont un peu comme les règles de grammaire et d'orthographe. Vous choisissez le lexique, mais les règles d'orthographe vous indiquent comment écrire.

Il n'y a pas de règles absolues, mais voici celles qui sont généralement observées :

  • En UML :

    • Pour le nom des classes :

      • au singulier

      • avec des lettres non accentuées

      • commençant par une majuscule

      • utilisant la notation chameau (une majuscule au début de chaque mot suivant)

      Ex : PierrePrecieuse

    • Pour les attributs :

      • au singulier

      • avec des lettres non accentuées

      • commençant par une minuscule

      • utilisant la notation chameau (une majuscule au début de chaque mot suivant)

      Ex : couleurYeux

  • Dans le MPD :

    • Pour le nom des tables et des attributs :

      • au singulier

      • avec des lettres non accentuées

      • en minuscules

      • les mots étant séparés par des underscores (_)

      Ex : pierre_precieusecouleur_yeux

Le but de ces règles est de réduire les possibles erreurs de typographie et d'être compatible avec leur mise en œuvre tant dans le code de l'application que dans la base de données.

Dans le prochain chapitre, nous examinerons comment les classes peuvent interagir et comment modéliser les liens qui existent entre elles.

Exemple de certificat de réussite
Exemple de certificat de réussite