Intro conceptionBDD

Introduction à la
conception des bases de

données relationnelles
Tous droits réservés à STUDI - Reproduction interdite

Table des matières
Stéphane Crozat
Table des matières

I. Contexte 3
II. Méthodologie générale de conception d'une base de données 3
III. Exercice : Appliquer la notion 6
IV. Éléments pour l'analyse de l'existant et des besoins 6
V. Exercice : Appliquer la notion 8
VI. Note de clarification 8
VII. Exercice : Appliquer la notion 9
VIII. Modélisation conceptuelle de données 11
IX. Exercice : Appliquer la notion 13
X. Modélisation logique de données 14
XI. Exercice : Appliquer la notion 15
XII. Qu'est ce qu'un bon modèle ? 15
XIII. Exercice : Appliquer la notion 17
XIV. Essentiel 18
XV. Auto-évaluation 19
A. Quiz final .....................................................................................................................................................................19
B. Exercice : Défi ..............................................................................................................................................................22
Solutions des exercices 23
Contenus annexes 33
2 Tous droits réservés à STUDI - Reproduction interdite

I. Contexte
Durée : 3h
Environnement de travail : DB Fiddle
Pré-requis : Aucun
Contexte
La conception d'une base de donnée est une tâche complexe. Réfléchissez à toutes les applications que vous
utilisez au quotidien : elles manipulent toutes des données, c'est même le cœur de leur fonctionnement. Éditeur
de texte, messagerie, navigateur web, agenda, etc.
Toutes ces données répondent à un modèle donné : si ce modèle est mauvais, alors l'ensemble de l'application
sera impacté.
Il est donc fondamental de prendre le temps de concevoir proprement la base de données, et pour ce faire il
existe des méthodologies qui décrivent toutes les phases, de l'idée de départ à l'implémentation effective.
Ce module présente la méthodologie générale en vigueur pour concevoir des bases de données et notamment les
étapes d'analyse de besoin, de modélisation conceptuelle et de modélisation logique relationnelle.
II. Méthodologie générale de conception d'une base de données
Objectifs
Connaître les quatre étapes de la conception d'une base de données relationnelle : analyse, MCD, MLD, SQL ;
Connaître l'importance des étapes d'analyse et de modélisation conceptuelle.
Mise en situation
Comment concevoir une base de données ? C'est une question vaste : on sent bien qu'il y a plusieurs étapes.
D'abord, il faut déterminer quelles données on veut stocker, par exemple en consultant le cahier des charges.
Ensuite, il faut se poser la question de la structure des données : comment les représenter ?
Enfin, il faut passer à la pratique : choisir un système de gestion de bases de données, et écrire du code SQL.
Dans ce module, vous allez découvrir une méthodologie plus formalisée pour vous guider dans la conception
d'une base de données.
Fondamental Étapes de la conception d'une base de données

1. Analyse de la situation existante et des besoins (clarification).
2. Création d'un modèle conceptuel de données (MCD) qui permet de représenter tous les aspects importants
du problème.
3. Traduction du modèle conceptuel en modèle logique de données (MLD) qui permet de traduire le problème
en structure relationnelle.
4. Implémentation d'une base de données en SQL dans un SGBD, à partir du modèle logique
Méthodologie générale de conception d'une base de données
Méthode
GraphiqueProcessus de conception d'une base de données

On distingue quatre étapes dans la conception d'une base de données :
L'analyse
Elle consiste à étudier le problème et à consigner dans un document, la note de clarification, les besoins, les
choix, les contraintes.
La modélisation conceptuelle
Elle permet de décrire le problème posé, de façon non-formelle (en générale graphique), en prenant des
hypothèses de simplification. Ce n'est pas une description du réel, mais une représentation simplifiée d'une
réalité.
La modélisation logique
Elle permet de décrire une solution, en prenant une orientation informatique générale (type de SGBD
typiquement), formelle, mais indépendante d'une solution technique spécifique.
L'implémentation
Elle correspond aux choix techniques, en terme de SGBD choisis et à leur mise en œuvre (programmation,
optimisation, etc.).
Fondamental
Bien analyser le problème posé en amont.
Bien modéliser le problème au niveau conceptuel avant de passer au niveau logique et à l'implémentation.
Conseil L'importance de l'étape d'analyse

La première étape de la conception repose sur l'analyse de l'existant et des besoins. De la qualité de la réalisation
de cette première étape dépendra ensuite la pertinence de la base de données par rapport aux usages. Cette
première étape est donc essentielle et doit être menée avec soin.

Méthodologie générale de conception d'une base de données
Si la première étape est fondamentale dans le processus de conception, elle est aussi la plus délicate. En effet,
tandis que des formalismes puissants existent pour la modélisation conceptuelle puis pour la modélisation
logique, la perception de l'existant et des besoins reste une étape qui repose essentiellement sur l'expertise
d'analyse de l'ingénieur.
Conseil L'importance de l'étape de modélisation conceptuelle

Étant donnée une analyse des besoins correctement réalisée, la seconde étape consiste à la traduire selon un
modèle conceptuel. Le modèle conceptuel étant formel, il va permettre de passer d'une spécification en langage
naturel, et donc soumise à interprétation, à une spécification non ambiguë. Le recours aux formalismes de
modélisation tels que E-A ou UML est donc une aide fondamentale pour parvenir à une représentation qui ne sera
plus liée à l'interprétation du lecteur.
La traduction d'un cahier des charges spécifiant l'existant et les besoins en modèle conceptuel reste néanmoins
une étape délicate, qui va conditionner ensuite l'ensemble de l'implémentation informatique. En effet les étapes
suivantes sont plus mécaniques, dans la mesure où un modèle logique est déduit de façon systématique du
modèle conceptuel et que l'implémentation logicielle est également réalisée par traduction directe du modèle
logique.
Remarque Les étapes de traduction logique et d'implémentation

Des logiciels spécialisés sont capables à partir d'un modèle conceptuel d'appliquer des algorithmes de traduction
qui permettent d'obtenir directement le modèle logique, puis les instructions pour la création de la base de
données dans un langage orienté données tel que SQL. L'existence de tels algorithmes de traduction montre que
les étapes de traduction logique et d'implémentation sont moins complexes que les précédentes, car plus
systématiques.
Néanmoins ces étapes exigent tout de même des compétences techniques pour optimiser les modèles logiques
(normalisation), puis les implémentations en fonction d'un contexte de mise en œuvre matériel, logiciel et
humain.
La réalisation d'une base de données est une tâche complexe, procéder en quatre étapes permet de gérer cette
complexité.
Conception en quatre étapes

L'idée générale est de ne pas mélanger la nature des tâches : typiquement, on ne veut pas en même temps se poser
des questions générales relatives aux besoins (ce que je veux faire) et des questions techniques très spécifiques
(comment représenter telle information).
Méthode
Conception en quatre étapes
Tous droits réservés à STUDI - Reproduction interdite 5

Exercice : Appliquer la notionsolution
L'approche est donc :

de « regarder à gauche » : on regarde le monde quand on clarifie, on regarde la note de clarification quand on
fait le MCD, on regarde le MCD quand on fait le MLD, on regarde le MLD quand on implémente ;
et « de ne pas regarder trop loin » : on anticipe déjà le MCD pendant la clarification, mais on ne se préoccupe
pas de questions d'implémentation ; quand on fait le MLD, on ne se pose plus de question sur le monde, la
clarification et le MCD ont dû déjà répondre ; quand on implémente on ne se pose plus de question de
modélisation, on s'occupe des programmes, de la machine.
Fondamental
On peut toujours revenir sur une étape, la conception est itérative, mais on ne doit pas tout le temps se poser tous
les problèmes en même temps.
Exercice : Appliquer la notion [solution n°1 p.25]
Mettre dans l'ordre les étapes de conception suivantes.
1. Création du code SQL pour un SGBDR
2. Modélisation conceptuelle en UML ou E-A
3. Analyse de la situation existante et des besoins
4. Élaboration du modèle logique en relationnel
Réponse :
IV. Éléments pour l'analyse de l'existant et des besoins
Objectif
Connaître quelques actions à mener pour mener une analyse de besoins.
Mise en situation
Avant de concevoir une base de données, il faut savoir à quels besoins on répond. Est-ce-qu'on remplace un système
pré-existant ? Est-ce-qu'on part de zéro ? Que faut-il pouvoir faire avec les données ?
La phase d'analyse de l'existant et des besoins est donc est une phase essentielle, qui peut se révéler complexe.
Elle doit aboutir à des spécifications générales qui décrivent en langage naturel les données manipulées, et les
traitements à effectuer sur ces données. Dans ce module, vous découvrirez une liste d'actions à mener pour rédiger
de telles spécifications.
Méthode L'analyse de documents existants

La conception d'une base de données s'inscrit généralement au sein d'usages existants. Ces usages sont
généralement, au moins en partie, instrumentés à travers des documents électroniques ou non (papier
typiquement). Il est fondamental d'analyser ces documents et de recenser les données qu'ils manipulent.

Éléments pour l'analyse de l'existant et des besoins
Exemple Exemples de document existants à analyser

Fichiers papiers de stockage des données (personnel, produits, etc.)
Formulaires papiers d'enregistrement des données (fiche d'identification d'un salarié, fiche de description
d'un produit, bon de commande, etc.)
Documents électroniques de type traitement de texte (lettres, mailing, procédures, etc.)
Documents électroniques de type tableurs (bilans, statistiques, calculs, etc.)
Bases de données existantes, à remplacer ou avec lesquelles s'accorder (gestion des salaires, de la
production, etc.)
Intranet d'entreprise (information, téléchargement de documents, etc.)
Etc.
Méthode Le recueil d'expertise métier

Les données que la base va devoir manipuler sont toujours relatives aux métiers de l'entreprise, et il existe des
experts qui pratiquent ces métiers. Le dialogue avec ces experts est une source importante d'informations. Il
permet également de fixer la terminologie du domaine.
Exemple Exemples d'experts à consulter

Praticiens (secrétaires, ouvrier, contrôleurs, etc.)
Cadres (responsables de service, contre-maîtres, etc.)
Experts externes (clients, fournisseurs, etc.)
Etc.
Méthode Le dialogue avec les usagers

La base de données concerne des utilisateurs cibles, c'est à dire ceux qui produiront et consommeront
effectivement les données de la base. Il est nécessaire de dialoguer avec ces utilisateurs, qui sont les détenteurs
des connaissances relatives aux besoins réels, liés à leur réalité actuelle (aspects de l'organisation fonctionnant
correctement ou défaillants) et à la réalité souhaitée (évolutions, lacunes, etc.).
Exemple Exemples d'utilisateurs avec qui dialoguer

Personnes qui vont effectuer les saisies d'information (à partir de quelles sources ? Quelle est leur
responsabilité ? etc.)
Personnes qui vont consulter les informations saisies (pour quel usage ? pour quel destinataire ? etc.)
Personnes qui vont mettre à jour les informations (pour quelles raisons ? comment le processus est
enclenché ? etc.)
Etc.
Méthode L'étude des autres systèmes informatiques existants

La base de données va généralement (et en fait quasi systématiquement aujourd'hui) s'insérer parmi un
ensemble d'autres logiciels informatiques travaillant sur les données de l'entreprise. Il est important d'analyser
ces systèmes, afin de mieux comprendre les mécanismes existants, leurs forces et leurs lacunes, et de préparer

l'intégration de la base avec ces autres systèmes. Une partie de ces systèmes seront d'ailleurs souvent également
des utilisateurs de la base de données, tandis que la base de données sera elle même utilisatrice d'autres
systèmes.
Exemple Exemples d'autres systèmes coexistants à étudier

Autres bases de données (les données sont elle disjointes ou partiellement communes avec celles de la base
à concevoir ? quelles sont les technologies logicielles sur lesquelles reposent ces BD ? etc.)
Systèmes de fichiers classiques (certains fichiers ont-ils vocations à être supplantés par la base ? à être
générés par la base ? à alimenter la base ? etc.)
Applications (ces applications ont elles besoins de données de la base ? peuvent-elles lui en fournir ? etc.)
Etc.
Complément Méthodes d'analyse

Il existe des outils et méthodes d'analyse en ingénierie comme l'analyse de la valeur, qui vise à mieux cerner le
problème initial et de proposer une solution permettant de le résoudre, et l'analyse fonctionnelle, qui vise à
caractériser les fonctions offertes par un produit pour satisfaire les besoins.
À quoi sert la récolte de documents existants dans le cadre de la conception des bases de données ?
 Comprendre les systèmes existants
 Comprendre le besoin des utilisateurs
 Comprendre l'usage des systèmes actuels
 Rédiger une documentation technique
VI. Note de clarification
Objectifs
Connaître l'utilité d'une note de clarification ;
Connaître les éléments indispensables d'une note de clarification.
Mise en situation
Imaginez que l'on vienne vous voir, et que l'on vous demande de développer une application de gestion de projet.
Sans information supplémentaire, c'est un peu léger : pour qui ? Pour quels besoins ? Avec quelle méthode de
gestion de projet ?
C'est le cahier des charges qui répond à ces questions et qui sert de référence aux développeurs.
Mais le cahier des charges est assez général, et garde des zones d'ombres sur les données à gérer, leur structure et
les traitements à effectuer.
Un cahier des charges est souvent accompagné d'une note de clarification, qui enrichit le cahier des charges,
précise des informations et vous aide à concevoir le modèle de la base de données.

Définition Note de clarification (NDC)

La note de clarification est une reformulation du cahier des charges, qui précise, ajoute et supprime des éléments
(en justifiant). C'est cette référence qui sera utilisée pour la suite du projet. Si le périmètre d'un projet est modifié,
la NDC doit être ajoutée en conséquence.
Méthode
Il existe plusieurs façons de réaliser une NDC. En base de données, on se focalisera sur l'explicitation des points
suivants :
Liste des objets qui devront être gérés dans la base de données ;
Liste des propriétés associées à chaque objet ;
Liste des contraintes associées à ces objets et propriétés ;
Liste des utilisateurs (rôles) appelés à modifier et consulter les données ;
Liste des fonctions que ces utilisateurs pourront effectuer.
On formulera explicitement les hypothèses qui ont permis de faire des choix.
Attention
La NDC est la reformulation du cahier des charges sur laquelle on se base pour réaliser le MCD, si aucune NDC
n'est associé à un MCD. Si aucune NCD n'est associée à un MCD, cela signifie que :
soit le CDC est réputé sans erreur et parfaitement clair (ce qui est rare) ;
soit on n'est pas capable de savoir à quoi se rapporte la modélisation.
Fondamental
On modélise toujours quelque chose dans un contexte, sur la base de ce qui est consigné dans la NDC. Si on ne
sait pas ce qui est modélisé, la validité du modèle n'est pas évaluable.
Méthode
Un NDC peut revêtir plusieurs formats, mais on privilégiera :
un document facile à mettre à jour (un projet évolue) et dont les versions sont traçables (on doit pouvoir
remonter des modifications pour retrouver des bifurcations dans les attendus) ;
un texte très clair, avec une rédaction minimaliste mais non ambiguë, des mots précis (par exemple on
utilisera un seul mot pour un seul concept, la répétition dans ce contexte étant toujours préférable à un
synonyme).
Vous avez comme projet de proposer un site de référencement de livres électroniques au format EPUB sous licence
libre.

Vous vous inspirerez en priorité du site similaire Framabook1, dont la

simplicité vous aidera à démarrer, mais vous pouvez chercher des
éléments complémentaires dans votre propre expérience, ou bien
sur d'autres sites similaires comme inlibroveritas.net2, sur des sites
commerciaux grands publics comme Amazon ou la Fnac, ou des sites
plus spécialisés comme C&F éditions3 ou Epagine4.
Ranger les éléments suivants afin d'initier une note de clarification.
Licence (obligatoire) L'éditeur peut ajouter de nouveaux livres
Le site permettra à l'internaute de naviguer entre les différentes catégories
Le site permettra à l'internaute de visualiser des livres « En vedette »
Catégories (Manuels, Essais, Romans, etc.) Auteurs
L'éditeur peut repérer un nombre non limité de livres qui sont considérés comme faisant partie de la catégorie
« En vedette » (qui apparaîtront sur le site dans un bandeau déroulant)
Le site permettra à l'internaute de faire une recherche par mots-clés dans les titres des livres
L'éditeur peut créer des catégories et ajouter des livres dans des catégories (un livre peut appartenir à
plusieurs catégories)
Nombre de pages (entier) Le site permettra à l'internaute de consulter la liste exhaustive de tous les livres
Livres Licences (cc-by-sa, Art Libre, GNU FDL, etc.) Titre (chaîne de caractères, obligatoire)
Internaute : consulte le site et télécharge les livres Résumé (texte)
Éditeur : ajoute les contenus sur le site
1 http://framabook.org/
2 http://www.inlibroveritas.net/
3 http://cfeditions.com
4 http://www.epagine.fr/

Modélisation conceptuelle de données
Objets Propriétés pour un livre Utilisateurs Fonctions
VIII. Modélisation conceptuelle de données
Objectifs
Savoir à quoi sert un MCD ;
Savoir citer les formalismes de MCD UML et E-A.
Mise en situation
Imaginez : vous lisez une note de clarification à propos d'une application web de stockage de fichiers : on vous parle
de fichiers, d'utilisateurs, de propriétaires, de partage, de contrôle de permission, de groupes, de dossiers, de
versions, etc.
Tous ces concepts se mélangent dans votre tête, vous avez du mal à vous représenter le lien entre les différentes
entités : est-ce-qu'un fichier peut être dans plusieurs dossiers à la fois ? Est-ce-qu'un document peut avoir plusieurs
propriétaires ?
C'est là que le modèle conceptuel de données, ou MCD, entre en jeu. C'est une sorte de schéma qui permet de
représenter tous ces éléments et leurs interactions sous forme graphique, synthétique et facile à comprendre.
Définition Modèle conceptuel de données

Un MCD est un dessin qui représente les données à gérer dans la base de données.
L'objectif du modèle conceptuel est de représenter le problème à l'aide de représentations graphiques et
partiellement formelles.
Fondamental
Les principales caractéristiques du modèle conceptuel sont :
Une représentation graphique simple.
Une puissance d'expression élevée pour un nombre de symboles raisonnable.
Une lecture accessible à tous et donc un bon outil de dialogue entre les acteurs techniques et non
techniques.
Une formalisation peu ambiguë et donc un bon outil de spécification détaillée.
Attention
Le modèle n'est pas encore formel, donc certaines représentations peuvent être équivoques, même si on a levé
de très nombreuses ambiguïtés.

Modélisation conceptuelle de données
E-A
La modélisation conceptuelle en bases de données relationnelle était à l'origine faite avec le formalisme E-A de la
méthode MERISE.
Exemple
Modèle E-A « gestion de projets »
UML
UML est un autre langage de modélisation, plus récent que E-A et couvrant un spectre plus large que les bases de
données. En tant que standard de l'OMG et en tant qu'outil très utilisé pour la programmation orientée objet, il a
supplanté la modélisation E-A.

Exemple Modélisation d'une gestion de projets par diagrammes UML
Modèle UML "gestion de projets"
Le schéma suivant représente les rencontres lors d'un tournoi de tennis. Quelles sont les assertions vraies selon ce
schéma ?
Joueur
nom: varchar
1..1 2..2
gagne participe
0..n 0..n
Terrain
Match se joue sur
numero: integer {unique}
date: datetime 0..n 1..1 surface: varchar
ImageMatch de tennis — Diagramme de classe

Modélisation logique de données
 On peut jouer des matchs de double.
 Il peut y avoir deux matchs sur le même terrain à la même heure.
 Connaissant un joueur, on peut savoir sur quels terrains il a joué.
X. Modélisation logique de données
Objectifs
Savoir ce qu'est un modèle logique de données ;
Comprendre la différence entre schéma en intention et schéma en extension.
Mise en situation
Vous développez un tout nouveau réseau social, qui permet de partager des images, des vidéos, des articles de blog,
et même des podcasts, depuis un seul endroit.
Pour vous aider à concevoir votre base de données, vous avez conçu un modèle conceptuel de données, c'est-à-dire
un schéma qui synthétise la structure de données à gérer : des utilisateurs qui peuvent se suivre, des partages, des
posts de différentes natures, etc.
Il est maintenant temps de créer votre base de données : comment transformer ce schéma sous une forme
compatible avec les bases de données, c'est-à-dire en un ensemble de relations, de tableaux ?
C'est justement le rôle du modèle logique de données, qui se rapproche de l'implémentation technique de la base
de données, et qui vient achever la modélisation.
Définition Modèle logique de données

Un modèle logique de données est une description, au moyen d'un langage formel, d'un ensemble de données.
Un schéma permet de décrire la structure d'une base de données, en décrivant l'ensemble des types de données
de la base. Une instance de base de données est constituée d'un ensemble de données qui respectent le schéma
de la base.
On parle aussi de schéma de données, ou de schéma.
Exemple Modèle logique de données relationnel

Un modèle logique de données relationnel permet de représenter une base de données relationnelles, c'est à
dire : des tables, des propriétés, des domaines, etc.
Exemple Schéma d'une relation

1 Espece (nom:chaîne, eucaryote:booléen, multicellulaire:booléen, propriété:chaîne)
Remarque Schéma en intention

On décrit un schéma logique de données en intention : on indique les différentes colonnes et leurs types.
Exemple Schéma d'une base de données défini en intention avec plusieurs relations
1 Etudiant (num:entier, nom:chaîne, ville:chaîne)
2 Module (num:entier, titre:chaîne)
3 Inscription (numetu:entier, nummod:entier, année:entier(4))

Exercice : Appliquer la notion
Remarque Table en extension

On décrit une table de données en extension : on indique les différentes colonnes, leurs types et énonce toutes
les valeurs existantes.
Exemple Instance de base de données
Complément Autres formalismes de modélisation logique
Le modèle CODASYL, antérieur au modèle relationnel est un modèle hiérarchique (Tardieu, 1983Tardieu83).
Le modèle relationnel (tabulaire) est le modèle dominant à la base des SGBDR.
Le modèle relationnel-objet (adaptation des modèles relationnels et objets au cadre des SGBD) est
actuellement en croissance.
D'autres modèles (document, graphe, etc.) se développent dans le cadre du mouvement NoSQL.
XI. Exercice : Appliquer la notion

Question [solution n°5 p.27]
Quel serait le modèle logique de la classe modélisée par le diagramme UML ci-dessous ?
Fruit
nom: varchar
couleur: varchar
calories: real
Diagramme de classe Fruit
XII. Qu'est ce qu'un bon modèle ?
Objectifs
Comprendre les différences entre modèle et réalité.

Qu'est ce qu'un bon modèle ?
Mise en situation
Lorsque vous concevez une base de données, vous modélisez un morceau de la réalité ; vous tentez de poser une
structure formelle sur une situation complexe.
Systématiquement, une question va se poser : jusqu'où pousser la modélisation ? Dans une application de vente en
ligne, jusqu'où faut-il décrire les articles ? Est-ce-que leur nom suffit, ou bien faut-il leurs dimensions, leurs poids,
leur matériau ? Leur couleur, leur pays d'origine, leur forme ?
Pourquoi pas, jusqu'où allez-vous aller ? Vous ne pourrez pas, quoi qu'il arrive, décrire exhaustivement la réalité. Il
faudra faire des simplifications, c'est-à-dire consentir à créer un modèle qui est une approximation.
Dans ce module, vous apprendrez les caractéristiques d'un bon modèle.
Fondamental Modèle
Un modèle est une représentation simplifiée de la réalité en vue de réaliser quelque chose.
Attention
Un modèle est une abstraction, une simplification de la réalité, ce n'est pas la réalité, il n'est jamais complètement
fidèle par construction.
Le seul modèle complètement fidèle à la réalité est la réalité elle-même, et ce n'est donc pas un modèle.
Exemple La carte et le territoire

Une carte est un modèle d'un territoire. Elle est une représentation simplifiée destiné à un usage particulier :
randonner à pied, en vélo ;
se diriger en voiture sur des grands axes, sur des axes secondaires ;
voler en avion de tourisme, en avion de ligne ;
naviguer sur fleuve, sur mer ;
étudier les frontières d'une région, d'un pays, de la terre ;
étudier la démographie, l'économie ;
etc.

Fondamental
À partir de cet exemple on notera que :
1. Un modèle est orienté par un usage.
Chacune de ces cartes est très différente selon ce que l'on veut faire.
2. Un modèle ne cherche pas à être proche de la réalité.
Chacune de ces cartes est très différente de la réalité qu'elle représente.
3. Un modèle adresse un niveau d'information qui existe mais qui n'est pas accessible dans la réalité.
Chacune de ces cartes permet quelque chose que ne permet pas l'accès direct à la réalité.
Le rasoir d'Ockham : Entre deux modèles donnés le meilleur modèle est-il toujours le plus fourni
Méthode
?
La méthode de raisonnement connue sous le nom de rasoir d'Ockham (du nom du philosophe éponyme) consiste
à préférer les solutions les plus simples aux plus complexes, lorsqu'elles semblent permettre également de
résoudre un problème donné ; entre deux théories équivalentes, toujours préférer la plus simple.
Ce principe s'applique très bien à la modélisation : étant donné un objectif et plusieurs modèles possibles, il ne
faut pas choisir a priori celui qui représente le plus de choses, mais préférer le plus simple dès qu'il couvre le
besoin.
C'est un principe d'économie (il coûte moins cher à produire) et d'efficacité (car les éléments inutiles du modèle
plus fourni nuiront à l'efficacité de la tâche).
Exemple
Ainsi, pour naviguer en voiture, il est plus simple de ne pas avoir sur la carte les chemins de randonnées qui ne
sont pas praticables en voiture.
Vous êtes en charge de la réalisation d'une base de données pour stocker les données d'un jeu vidéo nommé
Speedball.
Ce jeu oppose des équipes de Speedball dans un championnat. Chaque équipe a un nom unique dans le jeu. On
mémorise pour chaque rencontre la date. La gestion des scores et des victoires ne concerne pas cette application.
Chaque équipe est composée de plusieurs personnages (au moins cinq). Chaque personnage a obligatoirement un
nom unique, une immatriculation Speedball unique et un classement parmi tous les personnages de Speedball (il
n'y a aucune égalité possible). Les personnages ont un prix ; ils peuvent en effet être transférés d'une équipe à
l'autre.
Par exemple le personnage RazorBlade a l'immatriculation f070726c-486f-11e8-a39b-5f84bf907c60, il est classé
7ème pour le moment et il vaut 15 000 crédits. Il appartient à l'équipe des Brutal Deluxe.
Sélectionner tout ce qui est superflu par rapport aux besoins énoncés dans le modèle suivant.

Essentiel
XIV. Essentiel
Les données sont les éléments de base de la plupart des applications. La qualité de conception de la base de
données va donc impacter la qualité et la performance de l'ensemble de l'application, c'est pourquoi il est
important de prendre du temps pour la concevoir.
La première étape, c'est de modéliser la situation : quels acteurs, quelles interactions et quelles contraintes. Cette
modélisation se fait à travers la note de clarification, et définit à quel point le modèle essaye de se rapprocher de la
réalité. Pour ce faire, le concepteur doit mener une enquête auprès des personnes concernées, pour bien
comprendre les besoins et répertorier les systèmes existants.
Une fois ces éléments identifiés, le modèle conceptuel de données, ou MCD, est un schéma utile qui permet de
formaliser un peu plus la modélisation, sous forme graphique. Il rend compte, de manière synthétique, des
différents acteurs et des relations qu'il existe entre eux.
Le modèle logique de données, ou MLD, vient transformer le MCD de façon à se rapprocher de ce que comprennent
les bases de données relationnelles, c'est-à-dire des structures sous forme de tableau.
Enfin, le langage SQL permet de traduire directement le MLD et de l'implémenter dans les systèmes de gestion de
base de données relationnels.

Auto-évaluation
XV. Auto-évaluation
A. Quiz final
Exercice 1 [solution n°7 p.28]
Associer chaque terme avec sa définition.
Décrire le problème posé de façon graphique Faire la liste des besoins, choix et contraintes.
Écrire un programme informatique Décrire la solution visée dans une famille de SGBD
Analyse des besoins Modélisation Modélisation logique Implémentation

conceptuelle

Quelles formes seront adéquates pour établir une note de clarification ?
 Un document écrit en ligne
 Un échange de mail
 Des notes gardées pour soi
 Des formules mathématiques
 Du code informatique
Exercice
Un modèle est :
 générique, s'il est bien conçu, il fonctionne dans toutes les situations
 spécifique, il est adapté à une classe de situations
Exercice
Un modèle est :
 réaliste, il est le plus proche possible de la réalité
 schématique, il représente une abstraction de la réalité

Le service de gestion du personnel d'une entreprise désire s'équiper d'un outil lui permettant de gérer
informatiquement ses employés, leurs salaires et leurs congés. Les spécifications suivantes ont pu être mises en
exergue par une analyse des besoins réalisée auprès des utilisateurs du service du personnel.

Auto-évaluation
Généralités :
tout employé est décrit par un nom, un prénom et une date de naissance ;
pour chaque employé on gère la date d'embauche et la quotité (c'est à dire le pourcentage de temps travaillé
par rapport au temps plein, en cas de travail à temps partiel).
Gestion des salaires :
pour chaque employé on gère l'historique de ses salaires dans l'entreprise, chaque salaire étant affecté à une
période de temps ;
un salaire est composé d'un salaire brut, de cotisations patronales et de cotisations salariales.
Parmi les deux diagrammes ci-après, lequel est le plus adapté ?
remplit
1
Employé
1..*
nom: varchar
prénom: varchar Service Fonction
date_de_naissance: date 1 appartient 1..*
date_embauche: date nom: varchar nom: varchar
quotité: real
adresse: varchar
mail: varchar
1
reçoit
*
Salaire
debut: date
fin: date
brut: decimal
cotisations_patronales: decimal
cotisations_salariales: decimal
Gestion du personnel 1
Employé
nom: varchar
prénom: varchar
date_de_naissance: date
date_embauche: date
quotité: real
1
reçoit
*
Salaire
debut: date
fin: date
brut: decimal

Auto-évaluation
 Le diagramme 1
 Le diagramme 2

Larsen Mutin est une association étudiante qui organise des concerts.
Afin de préparer au mieux les événements à venir, l'association veut mettre en place une base de données qui
reprend les informations principales sur les membres de l'association, les groupes de membres et les instruments
qu'elle met à disposition.
Chaque groupe dispose d'un nom, d'une date de création et d'un nombre de concerts réalisés.
Chaque membre dispose d'un identifiant unique, d'un nom, d'un prénom, d'une adresse mail et d'un numéro
de téléphone.
Chaque membre peut emprunter des instruments à l'association pour les concerts.
Chaque instrument de musique dispose d'une dénomination propre donnée par le bureau.
Les membres se sont mis globalement d'accord sur le diagramme UML, mais ils sont en désaccord sur les
cardinalités des associations.
Sélectionnez le diagramme correct à partir des données fournies.
Membre
Groupe
identifiant : varchar {unique}
nom : varchar * appartient * nom : varchar
prenom : varchar date_creation : date
adresse_email : varchar nombre_concerts : integer
num_telephone : varchar
1
emprunte
*
Instrument
denomination : varchar {unique}
ImageLarsen 1
Membre
Groupe
nom : varchar 1 appartient 1 nom : varchar
*
emprunte
*
Instrument
ImageLarsen 2

Auto-évaluation
Membre
Groupe
nom : varchar * appartient 1 nom : varchar
*
emprunte
1
Instrument
ImageLarsen 3
 Diagramme Larsen 1
B. Exercice : Défi
Description du problème
Un laboratoire souhaite gérer les médicaments qu'il conçoit.
Un médicament est décrit par un nom, qui permet de l'identifier. En effet il n'existe pas deux médicaments avec le
même nom. Un médicament comporte une description courte en français, ainsi qu'une description longue en latin.
On gère aussi le conditionnement du médicament, c'est à dire le nombre de pilules par boîte (qui est un nombre
entier).
Par exemple un type de médicament est :
Nom : Chourix
Description courte : « Médicament contre la chute des choux »
Description longue : « Vivamus fermentum semper porta. Nunc diam velit, adipiscing ut tristique vitae, sagittis
vel odio. Maecenas convallis ullamcorper ultricies. Curabitur ornare. »
Conditionnement : 13
Ou encore :
Nom : Tropas
Description courte : « Médicament contre les dysfonctionnements intellectuels »
Description longue : « Suspendisse lectus leo, consectetur in tempor sit amet, placerat quis neque. Etiam luctus
porttitor lorem, sed suscipit est rutrum non. ».
Ce problème est un exemple très simple que l'on pourra modéliser avec une base de données relationnelle à une
seule table.
Tester vos instructions SQL dans un interpréteur.
Question 1 [solution n°12 p.32]
Proposer deux autres exemples de données.

Solutions des exercices

Dessiner un modèle conceptuel de données en UML qui modélise le problème. Il ne contient qu'une seule classe.
Indice :
Modélisation conceptuelle de données (cf. p.)
Proposer un modèle logique de données sous forme de schéma relationnel. Il ne contient qu'une seule relation.
Indice :
Modélisation logique de données (cf. p.)
Proposer une implémentation en SQL standard de votre modèle relationnel. Il ne contient qu'une seule instruction
CREATE TABLE.
Exécuter cette instruction dans un interpréteur.
Indice :
Langage de données : l'exemple du langage SQL (cf. p.33)
Écrire les instructions SQL permettant d'insérer ces données de test dans votre base de données.
Indice :
Écrire l'instruction SQL permettant d'afficher l'ensemble des données de la table.
Indice :

Exercice p. 6 Solution n°1

Mettre dans l'ordre les étapes de conception suivantes.
Analyse de la situation existante et des besoins Modélisation conceptuelle en UML ou E-A
Élaboration du modèle logique en relationnel Création du code SQL pour un SGBDR

À quoi sert la récolte de documents existants dans le cadre de la conception des bases de données ?
 Comprendre les systèmes existants
 Comprendre le besoin des utilisateurs
 Comprendre l'usage des systèmes actuels
 Rédiger une documentation technique

Vous avez comme projet de proposer un site de référencement de livres électroniques au format EPUB sous licence
libre.
Vous vous inspirerez en priorité du site similaire Framabook1, dont la

simplicité vous aidera à démarrer, mais vous pouvez chercher des
éléments complémentaires dans votre propre expérience, ou bien
sur d'autres sites similaires comme inlibroveritas.net2, sur des sites
commerciaux grands publics comme Amazon ou la Fnac, ou des sites
plus spécialisés comme C&F éditions3 ou Epagine4.
Ranger les éléments suivants afin d'initier une note de clarification.
Objets Propriétés Utilisateurs Fonctions

pour un livre
Livres L'éditeur peut ajouter de nouveaux livres
1 http://framabook.org/
2 http://www.inlibroveritas.net/
3 http://cfeditions.com
4 http://www.epagine.fr/

Auteurs Titre Éditeur : L'éditeur peut repérer un nombre non limité de livres qui
(chaîne de ajoute les sont considérés comme faisant partie de la catégorie
caractères, contenus sur « En vedette » (qui apparaîtront sur le site dans un
Catégories
obligatoire) le site bandeau déroulant)
(Manuels,
Essais,
Romans, Licence Internaute : L'éditeur peut créer des catégories et ajouter des livres
etc.) (obligatoire) consulte le dans des catégories (un livre peut appartenir à plusieurs
site et catégories)
télécharge les
Licences Nombre de
livres
(cc-by-sa, pages Le site permettra à l'internaute de consulter la liste
Art Libre, (entier) exhaustive de tous les livres
GNU FDL,
etc.)
Résumé Le site permettra à l'internaute de faire une recherche
(texte) par mots-clés dans les titres des livres
Le site permettra à l'internaute de naviguer entre les

différentes catégories
Le site permettra à l'internaute de visualiser des livres

« En vedette »

Le schéma suivant représente les rencontres lors d'un tournoi de tennis. Quelles sont les assertions vraies selon ce
schéma ?
Joueur
nom: varchar
1..1 2..2
gagne participe
0..n 0..n
Terrain
Match se joue sur
numero: integer {unique}
date: datetime 0..n 1..1 surface: varchar
ImageMatch de tennis — Diagramme de classe

 On peut jouer des matchs de double.
 Il peut y avoir deux matchs sur le même terrain à la même heure.
 Connaissant un joueur, on peut savoir sur quels terrains il a joué.

p. 15 Solution n°5
1 Fruit (nom:string, couleur:string, calories:float)

Vous êtes en charge de la réalisation d'une base de données pour stocker les données d'un jeu vidéo nommé
Speedball.
Ce jeu oppose des équipes de Speedball dans un championnat. Chaque équipe a un nom unique dans le jeu. On
mémorise pour chaque rencontre la date. La gestion des scores et des victoires ne concerne pas cette application.
Chaque équipe est composée de plusieurs personnages (au moins cinq). Chaque personnage a obligatoirement un
nom unique, une immatriculation Speedball unique et un classement parmi tous les personnages de Speedball (il
n'y a aucune égalité possible). Les personnages ont un prix ; ils peuvent en effet être transférés d'une équipe à
l'autre.
Par exemple le personnage RazorBlade a l'immatriculation f070726c-486f-11e8-a39b-5f84bf907c60, il est classé
7ème pour le moment et il vaut 15 000 crédits. Il appartient à l'équipe des Brutal Deluxe.
Sélectionner tout ce qui est superflu par rapport aux besoins énoncés dans le modèle suivant.

 Zone 1
Il est nécessaire de gérer la date.
 Zone 2
Les gestion des blessés et des buts n'est pas requise.
 Zone 3
Les équipes ont bien un nom, par exemple : Brutal Deluxe.
 Zone 4
La gestion des scores ne concerne pas l'application
 Zone 5
La gestion des scores ne concerne pas l'application
 Zone 6
RazorBlade a l'immatriculation f070726c-486f-11e8-a39b-5f84bf907c60, il est classé 7ème.
 Zone 7
Aucune indication des niveaux des personnages.
 Zone 8
La gestion des prix est requise.
 Zone 9
La gestion des postes n'est pas indiquée

Associer chaque terme avec sa définition.
Analyse des besoins Modélisation Modélisation logique Implémentation

conceptuelle
Faire la liste des besoins, Décrire la solution visée Écrire un
choix et contraintes. Décrire le problème dans une famille de SGBD programme
posé de façon graphique informatique

Quelles formes seront adéquates pour établir une note de clarification ?
 Un document écrit en ligne
 Un échange de mail
 Des notes gardées pour soi
 Des formules mathématiques
 Du code informatique

Exercice
Un modèle est :
 générique, s'il est bien conçu, il fonctionne dans toutes les situations
 spécifique, il est adapté à une classe de situations
Exercice
Un modèle est :
 réaliste, il est le plus proche possible de la réalité
 schématique, il représente une abstraction de la réalité

Le service de gestion du personnel d'une entreprise désire s'équiper d'un outil lui permettant de gérer
informatiquement ses employés, leurs salaires et leurs congés. Les spécifications suivantes ont pu être mises en
exergue par une analyse des besoins réalisée auprès des utilisateurs du service du personnel.
Généralités :
tout employé est décrit par un nom, un prénom et une date de naissance ;
pour chaque employé on gère la date d'embauche et la quotité (c'est à dire le pourcentage de temps travaillé
par rapport au temps plein, en cas de travail à temps partiel).
Gestion des salaires :
pour chaque employé on gère l'historique de ses salaires dans l'entreprise, chaque salaire étant affecté à une
période de temps ;
un salaire est composé d'un salaire brut, de cotisations patronales et de cotisations salariales.
Parmi les deux diagrammes ci-après, lequel est le plus adapté ?
remplit
1
Employé
1..*
nom: varchar
prénom: varchar Service Fonction
date_de_naissance: date 1 appartient 1..*
date_embauche: date nom: varchar nom: varchar
quotité: real
adresse: varchar
mail: varchar
1
reçoit
*
Salaire
debut: date
fin: date
brut: decimal

Employé
nom: varchar
prénom: varchar
date_de_naissance: date
date_embauche: date
quotité: real
1
reçoit
*
Salaire
debut: date
fin: date
brut: decimal
 Le diagramme 1
 Le diagramme 2
Le diagramme 2 est plus adapté pour cette situation.
Les deux diagrammes recouvrent l'ensemble des besoins exprimés, mais le diagramme 1 propose des
fonctions qui ne sont pas demandées, le modèle est donc trop complexe pour la situation visée.

Larsen Mutin est une association étudiante qui organise des concerts.
Afin de préparer au mieux les événements à venir, l'association veut mettre en place une base de données qui
reprend les informations principales sur les membres de l'association, les groupes de membres et les instruments
qu'elle met à disposition.
Chaque groupe dispose d'un nom, d'une date de création et d'un nombre de concerts réalisés.
Chaque membre dispose d'un identifiant unique, d'un nom, d'un prénom, d'une adresse mail et d'un numéro
de téléphone.
Chaque membre peut emprunter des instruments à l'association pour les concerts.
Chaque instrument de musique dispose d'une dénomination propre donnée par le bureau.
Les membres se sont mis globalement d'accord sur le diagramme UML, mais ils sont en désaccord sur les
cardinalités des associations.
Sélectionnez le diagramme correct à partir des données fournies.

Membre
Groupe
nom : varchar * appartient * nom : varchar
1
emprunte
*
Instrument
ImageLarsen 1
Membre
Groupe
nom : varchar 1 appartient 1 nom : varchar
*
emprunte
*
Instrument
ImageLarsen 2
Membre
Groupe
nom : varchar * appartient 1 nom : varchar
*
emprunte
1
Instrument
ImageLarsen 3

 Diagramme Larsen 1
Ce diagramme n'est pas correct car :
Un instrument ne peut pas être emprunté par plusieurs personnes.
Un groupe peut être composé de plusieurs personnes.
On peut supposer qu'un même membre peut faire partie de plusieurs groupes.
Ce diagramme n'est pas correct car :
Un instrument ne peut pas être emprunté par plusieurs personnes.
Un membre peut emprunter plusieurs instruments.
On peut supposer qu'un même membre peut faire partie de plusieurs groupes.
.
p. 22 Solution n°12
Nom : Queue de phénix

Description courte : « Ranime un allié KO »
Description longue : « Une plume de queue d'oiseau capable sauvant ceux qui sur le point d'embrasser les
précipices des ténèbres. ».
Conditionnement : 1
Et
Nom : Potion
Description courte : « Restaure une petite quantité de HP. »
Description longue : « Un mélange de magie qui soulage la douleur et guérit les blessures en un clin d'œil. ».
Medicament
nom: varchar {unique}
description: varchar
description_longue: varchar
conditionnement: integer
Medicament (#nom:varchar, description:varchar, description_longue:varchar,

conditionnement:number)

Contenus annexes
1 CREATE TABLE medicament (

2 nom VARCHAR(50) PRIMARY KEY,
3 description TEXT,
4 description_longue TEXT,
5 conditionnement INTEGER
6 );
Pour les exemples donnés en introduction, on a les requêtes suivantes :

1 INSERT INTO medicament (nom, description, description_longue, conditionnement)
2 VALUES ('Chourix','Médicament contre la chute des choux','Vivamus fermentum...',13);
3
4 INSERT INTO medicament (nom, description, description_longue, conditionnement)
5 VALUES ('Tropas','Médicament contre les dysfonctionnements intellectuels',' Suspendisse
lectus...',42);
Pour les exemples données en introduction, on a les requêtes suivantes :

1 SELECT *
2 FROM medicament
Contenus annexes
1. Langage de données : l'exemple du langage SQL
Objectifs
Connaître la notion de langage orienté donnée ;
Savoir tester une instruction en SQL.
Mise en situation
Imaginez : vous développez une bibliothèque musicale, et vous avez identifié la structure des données que vous
souhaitez gérer : les artistes d'un côté, les albums de l'autre, les playlists des utilisateurs, etc.
Au moment de passer à la pratique, vous vous demandez alors : comment expliquer cette structure au système de
gestion de base de données ? Comment insérer de nouvelles données ? Comment récupérer les données existantes
?
La réponse tient en trois mots : grâce à SQL. Ce langage est le couteau suisse des bases de données, et permet aux
développeurs de communiquer avec les SGBD.
Définition Langage de données

Un langage de données est un langage informatique permettant de décrire et de manipuler les schémas et les
données d'une BD.

Contenus annexes
Remarque Synonyme
On parle aussi de langage orienté données.
Fondamental SQL
SQL est le langage consacré aux SGBD relationnels et relationnels-objet.
Il permet de :
créer des tables, en définissant le domaine de chaque colonne ;
insérer des lignes dans les tables ;
lire les données entrées dans la base de données.
Exemple Création de table en SQL (définition du schéma de données)

1 CREATE TABLE student (
2 number INTEGER PRIMARY KEY,
3 name TEXT,
4 city TEXT
5 );
Cette instruction permet de créer une relation student comportant les propriétés number, name et city de
domaines, respectivement, entier, texte et texte (number est la clé primaire de la table, il servira à identifier les
enregistrements).
Exemple Insertion de ligne en SQL (création de données)

1 INSERT INTO student (number, name, city)
2 VALUES (1, 'Holmes', 'Londres');
Cette instruction permet de créer l'étudiant numéro 1, de nom Holmes qui habite la ville de Londres.
Exemple Manipulation de données en SQL (exploitation des données)

1 SELECT name
2 FROM student
3 WHERE city = 'Londres';
Cette instruction permet de rechercher les noms de tous les étudiants habitant la ville de Londres.
Complément Autres langages de données

XQuery est un langage de données mobilisé dans les bases de données arborescentes XML.
Les bases NoSQL proposent des langages de données spécifiques, souvent inspirés du SQL. Par exemple le
langage de MongoDB permet de manipuler une base de contenus JSON.

Intro conceptionBDD

Transféré par

Droits d'auteur :

Formats disponibles

Intro conceptionBDD

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Intro conceptionBDD

Transféré par

Droits d'auteur :

Formats disponibles

Introduction à la

conception des bases de

Tous droits réservés à STUDI - Reproduction interdite

Table des matières

II. Méthodologie générale de conception d'une base de données 3

III. Exercice : Appliquer la notion 6

IV. Éléments pour l'analyse de l'existant et des besoins 6

V. Exercice : Appliquer la notion 8

VI. Note de clarification 8

VII. Exercice : Appliquer la notion 9

VIII. Modélisation conceptuelle de données 11

IX. Exercice : Appliquer la notion 13

X. Modélisation logique de données 14

XI. Exercice : Appliquer la notion 15

XII. Qu'est ce qu'un bon modèle ? 15

XIII. Exercice : Appliquer la notion 17

Solutions des exercices 23

2 Tous droits réservés à STUDI - Reproduction interdite

II. Méthodologie générale de conception d'une base de données

Fondamental Étapes de la conception d'une base de données

GraphiqueProcessus de conception d'une base de données

Conseil L'importance de l'étape d'analyse

4 Tous droits réservés à STUDI - Reproduction interdite

Conseil L'importance de l'étape de modélisation conceptuelle

Remarque Les étapes de traduction logique et d'implémentation

Conception en quatre étapes

Conception en quatre étapes

Tous droits réservés à STUDI - Reproduction interdite 5

L'approche est donc :

Exercice : Appliquer la notion [solution n°1 p.25]

Mettre dans l'ordre les étapes de conception suivantes.

1. Création du code SQL pour un SGBDR

2. Modélisation conceptuelle en UML ou E-A

3. Analyse de la situation existante et des besoins

4. Élaboration du modèle logique en relationnel

IV. Éléments pour l'analyse de l'existant et des besoins

Méthode L'analyse de documents existants

6 Tous droits réservés à STUDI - Reproduction interdite

Exemple Exemples de document existants à analyser

Méthode Le recueil d'expertise métier

Exemple Exemples d'experts à consulter

Méthode Le dialogue avec les usagers

Exemple Exemples d'utilisateurs avec qui dialoguer

Méthode L'étude des autres systèmes informatiques existants

Tous droits réservés à STUDI - Reproduction interdite 7

Exemple Exemples d'autres systèmes coexistants à étudier

Complément Méthodes d'analyse

Exercice : Appliquer la notion [solution n°2 p.25]

 Comprendre le besoin des utilisateurs

 Comprendre l'usage des systèmes actuels

 Rédiger une documentation technique

VI. Note de clarification

8 Tous droits réservés à STUDI - Reproduction interdite

Définition Note de clarification (NDC)

Exercice : Appliquer la notion [solution n°3 p.25]

Tous droits réservés à STUDI - Reproduction interdite 9

Vous vous inspirerez en priorité du site similaire Framabook1, dont la

Ranger les éléments suivants afin d'initier une note de clarification.

Licence (obligatoire) L'éditeur peut ajouter de nouveaux livres