Vous êtes sur la page 1sur 29

Contenu

Objectifs généraux ............................................................................................... 4

PARTIE 1 : Gouvernance des systèmes d'information ................................... 4

Objectifs pédagogiques .......................................................................................................... 4

Objectifs spécifiques .............................................................................................................. 4

Compétences à acquérir ......................................................................................................... 5

1. Introduction aux bases de données .................................................................................. 6

1.1. Notion de base de données ....................................................................................... 6

1.2. Avantages d'une base de données ............................................................................ 7

2. Système de gestion de base de données (SGBD) ............................................................ 8

2.1. Définition d'un SGBD .............................................................................................. 8

2.2. Structure d'un SGBD................................................................................................ 8

2.3. Les fonctions et objectifs d'un SGBD ...................................................................... 8

2.4. Les principaux SGBD connus et utilisés................................................................ 10

3. Cycles de développement des bases de données ........................................................... 10

4. Structure d'une base de données .................................................................................... 10

4.1. Notion de table ....................................................................................................... 10

4.2. Notion de colonne .................................................................................................. 12

4.3. Notion de ligne ....................................................................................................... 12

Page 1 sur 29
4.3.1. Définition ........................................................................................................... 12

4.4. Notion de clé primaire ........................................................................................... 13

4.4.1. Définition ........................................................................................................... 13

4.4.2. Caractéristiques .................................................................................................. 13

5. Liens entre les tables ..................................................................................................... 13

5.1. Lien de type 1,n ...................................................................................................... 13

5.2. Lien de type n,n ...................................................................................................... 14

6. Notion de contrainte d'intégrité ..................................................................................... 14

7. Représentation de la structure d'une base de données ................................................... 15

7.1. La représentation textuelle ou logique: ..................................................................... 15

7.2. La représentation graphique ...................................................................................... 16

8. « Métiers » des bases de données .................................................................................. 16

8.1. Consultants/analystes ............................................................................................. 16

8.2. Concepteurs de la base ........................................................................................... 17

8.3. Administrateurs de base de données (DBA : Database Administrator) ................. 17

8.4. Utilisateurs standard et programmeurs d’applications ........................................... 17

9. Travaux dirigés – problématique des bases de données ................................................ 18

9.1. Travaux Dirigés 1 – Sensibilisation à la problématique des bases de données ..... 18

9.2. Travaux Dirigés 2 – Critique d’une gestion de données par fichier ...................... 23

9.3. Travaux Dirigés 3 – Démarche de la création d'une base de données ................... 24


Page 2 sur 29
10. Correction des Travaux dirigés .................................................................................. 26

Travaux Dirigés 2 – Critique d’une gestion de données par fichier ................................. 26

Travaux Dirigés 3 – Démarche de la création d'une base de données ............................. 28

Page 3 sur 29
COURS SYSTEME D'INFORMATION ET MODELISATION DES DONNEES

Filière Comptabilité et Gestion des Entreprise (CGE) et Audit et Contrôle de Gestion (ACG)

Niveau : MASTER 1

Objectifs généraux

Parce qu’il doit recourir aux sciences dans la conduite des organisations, le gestionnaire
utilise de l’informatique : science du traitement rationnel de l’information considérée comme
le support des connaissances humaines, l’informatique fournit au gestionnaire des outils
répondant à ses besoins. Aussi ce cours apporte-il au gestionnaire les réponses aux questions
qu’il se pose et lui offre la possibilité de mettre en œuvre les concepts et outils de
l’informatique de gestion. A la fin de cours, le gestionnaire devra maîtriser les différentes
notions et implications nécessaires à la gouvernance des systèmes d'information et
l’utilisation d’un tableur et d’une base de Données.

PARTIE 1 : Gouvernance des systèmes d'information

Objectifs pédagogiques

 La finalité de ce cours est de former les étudiants à la gouvernance des systèmes


d’information afin qu'ils soient en mesure de :
 Appréhender les concepts du management des systèmes d'information
d'entreprises.
 Positionner la fonction informatique dans une entreprise.
 Comprendre la nécessité d'associer au système d'information d’une entreprise des
structures de prise de décision.

Objectifs spécifiques

 Définir une qu'une donnée


 Définir une information
 Définir un fichier
 Citer les limites les limites du système de fichiers

Page 4 sur 29
 Définir une base de données
 Citer les avantages de la base de données
 Définir un SGBD
 Décrire le rôle d'un SGBD
 Citer au moins trois (03) : propriétaires et libres SGBD
 Citer les fonctions d'un SGBD
 Déduire la structure d’une B.D. à partir d’un énoncé décrivant un domaine donné.
 Détecter les anomalies dans la structure des tables.
 Citer les différentes compétences nécessaires, différentes qui interviennent dans le
processus de conception d’une base de données.

Compétences à acquérir

Comprendre les concepts fondamentaux et le vocabulaire associés aux systèmes


d'information.

Page 5 sur 29
1. Introduction aux bases de données

1.1. Notion de base de données

1.1.1. Définition de base données

Il est difficile de donner une définition exacte de la notion de base de données. Ce cours parle
des base de données relationnelles. Une définition très générale pourrait être :

Base de données : Un ensemble organisé d’informations avec un objectif commun.

Peu importe le support utilisé pour rassembler et stocker les données (papier, fichiers, etc.),
dès lors que des données sont rassemblées et stockées d’une manière organisée dans un but
spécifique, on parle de base de données.

Plus précisément, on appelle base de données un ensemble structuré et organisé permettant le


stockage de grandes quantités d’informations afin d’en faciliter l’exploitation (ajout, mise à
jour, recherche de données). Bien entendu, dans le cadre de ce cours, nous nous intéressons
aux bases de données informatisées.

1.1.2. Base de données informatisée

Base de données informatisée : Une base de données informatisée est un ensemble structuré
de données enregistrées sur des supports accessibles par l’ordinateur, représentant des
informations du monde réel et pouvant être interrogées et mises à jour par une communauté
d’utilisateurs.

Le résultat de la conception d’une base de données informatisée est une description des
données. Par description on entend définir les propriétés d’ensembles d’objets modélisés dans
la base de données et non pas d’objets particuliers. Les objets particuliers sont créés par des
programmes d’applications ou des langages de manipulation lors des insertions et des mises à
jour des données.

Cette description des données est réalisée en utilisant un modèle de données. Ce dernier est un
outil formel utilisé pour comprendre l’organisation logique des données.

Page 6 sur 29
La gestion et l’accès à une base de données sont assurés par un ensemble de programmes qui
constituent le Système de gestion de base de données (SGBD). Un SGBD est caractérisé par
le modèle de description des données qu’il supporte (hiérarchique, réseau, relationnel, objet,
etc.). Les données sont décrites sous la forme de ce modèle, grâce à un Langage de
Description des Données (LDD). Cette description est appelée schéma.

Une fois la base de données spécifiée, on peut y insérer des données, les récupérer, les
modifier et les détruire. C’est ce qu’on appelle manipuler les données. Les données peuvent
être manipulées non seulement par un Langage spécifique de Manipulation des Données
(LMD) mais aussi par des langages de programmation classiques.

Une donnée est description élémentaire d'une information.

1.1.3. Définitions d'une information

(1) Plusieurs données regroupées et se rapportant à un même contexte donnent naissance a


l'information.

(2) L'information est tout renseignement, écrit, sonore, visuel ou audiovisuel, code
susceptible d'être stocke ou transmis, en vue de déclencher ou de modifier le comportement
d'un processus.

1.2. Avantages d'une base de données

a. Centralisation : les données peuvent être utilisées par plusieurs programmes et


plusieurs utilisateurs.
b. Indépendance entre données et programmes :dans une BD les données sont décrites
indépendamment des programmes. Ce qui n'est pas le cas avec les fichiers.
c. Intégration des liaisons entre les données : pas besoin d'un programme pour retrouver
les liens entre les données.
d. Intégrité des données : ce sont des règles de sécurité assurant la cohérence des
données:
 Unicité des enregistrements.
 Interdiction de la suppression des données utilisées par d'autres données.
e. Concurrence d'accès : plusieurs utilisateurs peuvent accéder simultanément à la BDD.

Page 7 sur 29
2. Système de gestion de base de données (SGBD)

2.1. Définition d'un SGBD

Un Système de Gestion de Base de Données(SGBD) est un logiciel qui permet de : décrire,


modifier, interroger et administrer les données d'une base de données.

La gestion et l’accès à une base de données sont assurés par un ensemble de programmes qui
constituent le Système de gestion de base de données (SGBD). Un SGBD doit permettre
l’ajout, la modification et la recherche de données. Un système de gestion de bases de
données héberge généralement plusieurs bases de données, qui sont destinées à des logiciels
ou des thématiques différents.

Actuellement, la plupart des SGBD fonctionnent selon un mode client/serveur. Le serveur


(sous-entendu la machine qui stocke les données) reçoit des requêtes de plusieurs clients et
ceci de manière concurrente. Le serveur analyse la requête, la traite et retourne le résultat au
client. Le modèle client/serveur est assez souvent implémenté au moyen de l’interface des
sockets (voir le cours de réseau) ; le réseau étant Internet.

2.2. Structure d'un SGBD

Un SGBD est constitué de deux composantes principales :

 le moteur
 l'interface

2.3. Les fonctions et objectifs d'un SGBD

Des objectifs principaux ont été fixés aux SGBD dès l’origine de ceux-ci et ce, afin de
résoudre les problèmes causés par la démarche classique. Ces objectifs sont les suivants :

a. La définition des données

Le SGBD nous permet de créer et de décrire les objets de la base de données (table, liens,
utilisateur…), grâce au Langage de Description de Données (LDD).

Page 8 sur 29
b. La manipulation des données

La manipulation des données peut être :

 la recherche
 la lecture
 la suppression
 la modification
 l'ajout

Le SGBD nous offre un Langage de Manipulation de Données (LMD)

c. L'intégrité des données

C'est l'ensemble des opérations de contrôle que le SGBD effectue pour préserver la cohérence
des données.

Exemple : Vérification de la validité de la valeur d'un champ.

d. La gestion des accès concurrents

Le SGBD gère l'accès simultané des utilisateurs à la base de données.

e. La confidentialité

Tous les utilisateurs d'une base de données ne sont pas supposés pouvoir consulter toutes les
informations. Des sous schémas de la base permettent de résoudre ce problème en plus des
mots de passes et droits d'accès.

f. La sécurité de fonctionnement et résistance aux pannes


 Faire une copie de sauvegarde de la base.
 Remise en marche de la base en cas de panne.

Que se passe-t-il si une panne survient au milieu d’une modification, si certains fichiers
contenant les données deviennent illisibles ? Il faut pouvoir récupérer une base dans un état «
sain ». Ainsi, après une panne intervenant au milieu d’une modification deux solutions sont

Page 9 sur 29
possibles : soit récupérer les données dans l’état dans lequel elles étaient avant la
modification, soit terminer l’opération interrompue.

2.4. Les principaux SGBD connus et utilisés

Il existe de nombreux systèmes de gestion de bases de données, en voici une liste non
exhaustive :

PostgreSQL : http ://www.postgresql.org/ – dans le domaine public ;


MySQL : http ://www.mysql.org/ – dans le domaine public ;
Oracle : http ://www.oracle.com/ – de Oracle Corporation ;
IBM DB2 : http ://www-306.ibm.com/software/data/db2/
Microsoft SQL : http ://www.microsoft.com/sql/
Sybase : http ://www.sybase.com/linux
Informix : http ://www-306.ibm.com/software/data/informix/

3. Cycles de développement des bases de données

Niveau externe : Analyse de l'existant


Niveau conception : Modélisation des entités du mode réel
Niveau interne : Création de la base de données.

4. Structure d'une base de données

4.1. Notion de table

4.1.1. Définition

Une table est un ensemble de données relatives à une même entité, structurée sous forme d'un
tableau (liste). Une table peut être appelée aussi "Relation".

Page 10 sur 29
Exemple : Cas d'une entreprise.

LIEU/VILLE

FONCTION

DEPARTEMENT

EMPLOYE

4.1.2. Remarques

 Les données d'une table peuvent être stockées sur un ou plusieurs fichiers.
 Une table peut être considérée comme un ensemble mathématique. Ainsi, on pourra
faire l'union ou l'intersection de deux tables.

Page 11 sur 29
4.2. Notion de colonne

4.2.1. Définition

Une colonne (champ) représente une propriété élémentaire de l'entité décrite par cette table.

4.2.2. Caractéristiques d'un champ

 Nom
 Type de données (Chaine, Numérique, Date)
 Taille éventuelle
 Obligatoire (oui/non)
 Valeur par défaut
 Valide si : on peut créer une règle indiquant les valeurs utilisées.

Exemple de la table Departement

4.3. Notion de ligne

4.3.1. Définition

Une ligne (enregistrement) représente une occurrence du sujet représenté par la table.

Exemple : cas de la table Lieu. Elle est constituée de cinq (05) enregistrements

Page 12 sur 29
4.4. Notion de clé primaire

4.4.1. Définition

La clé primaire d'une table est un champ ou un ensemble de champs permettant d'identifier de
manière unique chaque enregistrement de la table.

4.4.2. Caractéristiques

Unique + non nul.

5. Liens entre les tables

5.1. Lien de type 1,n

Dans un contexte relationnel, les entités d'un système d'information admettent des relations
entre elles. On peut formuler ces relations comme suit :

Cas des tables DEPARTEMENT et LIEU :

 Un lieu peut avoir un ou plusieurs départements.


 Un département est situé dans un et un seul lieu.

Dans ce cas on parle de lien de type un à plusieurs (1,n) et il y'aura naissance d'une clé
étrangère qui assurera la relation entre les deux tables.

Définition

Un lien entre deux tables A (Lieu) et B (Dept) se traduit par l'ajout dans la table B d'un
nouveau champ correspondant à la clé primaire de la table A. Ce champ est appelé clé
étrangère.

Dans ce cas A (Lieu) est une table mère, B (Dept) est une table fille.

Page 13 sur 29
5.2. Lien de type n,n

On peut aussi parler de liens plusieurs à plusieurs (n, n)

Cas des tables Emp et Dep.

 Un employé travaille dans un ou plusieurs départements.


 Un département accueille un ou plusieurs employés.

6. Notion de contrainte d'intégrité

Une contrainte d'intégrité est une règle appliquée à un champ ou à une table et qui doit être
toujours vérifiée.

Page 14 sur 29
1. Les contraintes de domaines : (valide si)

Ce sont des contraintes appliquées à des colonnes. Elles permettent de fixer le caractère
obligatoire ou pas d'une colonne et les règles de validité des valeurs qui peuvent être prises
par cette colonne.

Exemple : La note doit être comprise entre 0 et 20.

2. Les contraintes d'intégrité de tables : (clé primaire)

Elles permettent d'assurer que chaque table a une clé primaire.

3. Les contraintes d'intégrité référentielles :


 Champ clé étrangère ne peut contenir qu'une valeur déjà existante dans la clé primaire
correspondante.
 La suppression d'un enregistrement d'un table mère A utilisé par une table fille B est
interdit.

7. Représentation de la structure d'une base de données

Le schéma base de données est une représentation des différentes structures de la base. Cette
représentation peut être faite selon deux formalismes :

7.1. La représentation textuelle ou logique:

La représentation textuelle consiste a affecter les colonnes au différentes tables et rajouter le


symbole dièse (#) dans la table fille s’il y’en a une liaison entre deux tables.

Lieu (NumL, NomL)


Fonction (NumF, NomF)
Dept (NumD, NomD, NumL#)
Emp (NumE, NomE, NumS, Embauche, Salaire, Comm, NumD#, NumF#)

Page 15 sur 29
7.2. La représentation graphique

8. « Métiers » des bases de données

Comme on peut le constater lorsque l’on considère les différentes étapes de la conception
d’une base de données, des acteurs aux compétences très diverses interviennent dans ce
processus.

8.1. Consultants/analystes

Ils prennent en charge la première étape qui consiste en l’analyse des activités et des flux
d’information mis en jeu dans le monde réel à modéliser. Le profil de ces acteurs n’est pas
toujours purement technique, puisque cette phase nécessite parfois beaucoup de dialogues et
de psychologie pour parvenir à faire exprimer leurs besoins réels par les futurs utilisateurs.

La gageure est de parvenir à faire exprimer correctement les besoins d’informatisation par les
utilisateurs du système d’information, afin de proposer un modèle conceptuel de données le
plus juste possible.

Page 16 sur 29
8.2. Concepteurs de la base

Ce sont les personnes qui s’occupent de traduire le modèle précédent en un modèle logique
exploitable par le SGBD. Le concepteur est un spécialiste des bases de données qui prépare
les tables, les vues, les schémas d’accès. C’est lui qui renseigne les utilisateurs et
programmeurs pour la définition des requêtes. Il n’a pas, en principe, à être spécialisé sur un
SGBD particulier, mais en pratique les éléments qu’il manipule sont liés au SGBD qui sera
employé. C’est ordinairement lui qui crée les éléments nécessaires à la base de données
(tables, vues…) en collaboration avec l’administrateur de la base. C’est parfois la même
personne qui est en charge de la partie analyse et de la conception, ce qui peut induire une
vision un peu trop orientée techniquement – comme celle d’un programmeur qui écrirait le
cahier des charges d’une application. Par contre, le concepteur peut aussi être administrateur
du SGBD, ce qui ne pose pas de problèmes particuliers d’approche.

8.3. Administrateurs de base de données (DBA : Database Administrator)

L’administrateur a la responsabilité du fonctionnement général du SGBD. Il crée les


ressources (bases, comptes) à la demande. Il donne les droits d’accès et gère les personnes qui
accèdent au système. Il vérifie que les ressources sont suffisantes (taille du disque, puissance
de la machine), effectue les sauvegardes, vérifie les failles de sécurité. Pour ces opérations, il
est en relation avec l’administrateur système et réseau de la structure. Ce métier est
extrêmement lié au SGBD employé. Il n’y a pas vraiment de normalisation pour les
opérations d’administration des SGBD qui sont spécifiques au SGBD et à la version utilisés.

8.4. Utilisateurs standard et programmeurs d’applications

Ce sont eux qui utilisent le système d’information. Ils y ont accès grâce aux vues définies par
le concepteur de la base. Ils utilisent les schémas déterminés aux deux premières étapes de la
conception. Ils n’ont pas besoin théoriquement d’être spécialisés sur le SGBD employé. En
pratique il est préférable, surtout pour les développeurs d’applications, d’avoir de bonnes
connaissances du fonctionnement du SGBD. Par exemple, pour optimiser les performances, la
manière d’écrire les requêtes peut être assez différente suivant le SGBD employé.

Page 17 sur 29
9. Travaux dirigés – problématique des bases de données

9.1. Travaux Dirigés 1 – Sensibilisation à la problématique des bases de données

9.1.1. Introduction

Objectifs

L’objectif de ce TD est de se faire une idée de l’intérêt de toute la théorie sur la conception
des bases de données et de l’intérêt de l’utilisation des systèmes de gestion de base de
données. En d’autres termes, nous allons essayer d’apporter des éléments de réponse à la
question : « Pourquoi dois-je m’embêter avec toute cette théorie et ces connaissances à
assimiler alors que je sais très bien manipuler un fichier, y stocker des informations et les y
retrouver avec mon langage de programmation favoris ? »

Contexte

Supposons que vous ayez à développer une application de gestion d’une bibliothèque. Tous
les livres de la bibliothèque possèdent un numéro de livre, un titre, un ou plusieurs auteurs et
un éditeur. Lorsqu’une personne emprunte un livre, il faut mémoriser son nom, son prénom,
son numéro de téléphone, son adresse, la date de l’emprunt et la date de retour une fois ce
dernier réalisé. Toutes les informations doivent être conservées pour garder un historique des
emprunts.

9.1.2. Approche naïve

Une solution simple et naïve . . .

Certains d’entre vous ont une expérience des bases de données (il s’agit vraiment de quelque
chose d’incontournable aujourd’hui) ou une expérience importante en développement logiciel.
Dans le cadre de cet exercice, oubliez toutes vos connaissances et vos réflexions sur le sujet.

1. Votre application va devoir stocker toutes les informations mentionnées dans


l’introduction (section Contexte), et de manière persistante, donc en utilisant un
fichier. Quelle est la solution de stockage des données la plus naïve et la plus naturelle
venant immédiatement à l’esprit ?

Page 18 sur 29
. . . mais pas sans conséquences

Supposons que nous adoptions la solution naïve et naturelle suivante :

 nous créons un fichier texte comportant à l’origine une ligne par livre.
 dans chaque ligne, on trouve les informations titre, auteur, éditeur, numéro du livre
séparées par une tabulation.
 quand une personne emprunte un livre, on complète la ligne du livre en question par
les champs nom, prénom, téléphone, adresse et date-emprunt toujours en séparant ces
informations par une tabulation.
 lorsqu’une personne retourne un livre, il suffit d’ajouter un dernier champ date-retour
sur la ligne du livre en question.
 Quand un livre est emprunté une nouvelle fois, on crée une nouvelle ligne avec toutes
les informations concernant le livre et la personne qui l’emprunte. Bien entendu, le
bibliothécaire ne ressaisit pas tout, l’application va chercher la plupart de ces
informations dans le fichier.

En fait, on peut voir ce fichier texte comme un tableau de chaînes de caractères dont l’entête
des colonnes serait les suivantes :

Titre Auteur Éditeur N°Livre Nom Prénom Téléphone Adresse Date-emprunt Date-retour

Supposons que l’application de gestion de bibliothèque fonctionne correctement et stocke


toutes ses données dans un fichier comme celui que nous venons de décrire. Nous allons nous
pencher sur les inconvénients et les conséquences inhérentes à une telle approche.

L’application fonctionne maintenant depuis 10 ans. Le nombre de personnes inscrites à la


bibliothèque est relativement constant (bien que l’on constate un roulement) et de 5000
personnes en moyenne par an. Un abonné emprunte en moyenne 5 livres par mois.

2. Quel est, approximativement, le nombre de lignes du fichier des données ?


3. Quelle est la taille approximative du fichier sachant que chaque caractère occupe 1
octet et qu’une ligne contient, en moyenne, 150 caractères ?
4. Lorsqu’un abonné emprunte un livre, le bibliothécaire saisit simplement le numéro du
livre et le nom et le prénom de l’abonné. L’application se charge alors de parcourir le
Page 19 sur 29
fichier pour rechercher les informations manquantes concernant le livre et l’abonné
afin d’écrire, à la fin du fichier, la nouvelle ligne concernant l’emprunt. Dans le pire
des cas, l’application doit parcourir tout le fichier. Supposons qu’un accès au fichier
coûte 10ms, qu’une lecture de ligne coûte 6ms et qu’une recherche sur la ligne pour
trouver le numéro du livre ou le nom et le prénom de l’abonné coûte 1ms. Quel est,
dans le pire des cas, le temps mis par l’application pour compléter les informations
saisies par le bibliothécaire ?
5. Supposons qu’une personne est abonnée depuis l’origine de l’application. Elle
prévient le bibliothécaire que son prénom est mal orthographié. Combien de lignes,
approximativement, doivent être modifiées pour corriger cette erreur dans tout le
fichier de données ?
6. Lors de cette correction d’un prénom mal orthographié, comment distinguer les
homonymes ?
7. Supposons que la base de données contienne plusieurs exemplaires de deux livres
distincts du même auteur, Michel Tournier, chez le même éditeur, Poche, et portant le
même titre : Vendredi ou la vie sauvage. Le bibliothécaire s’aperçoit que l’un des
deux livres n’est pas édité par la maison d’édition Poche, mais par Broché. Comment
corriger le problème dans la base ?
8. Énumérez ou résumez tous les problèmes que la représentation des données choisie
(le fichier de données) semble poser.

9.1.3. Affinement de la solution

Il est évident que la solution naïve décrite dans la section précédente pose de nombreux
problèmes. Elle est totalement inacceptable pour une application sérieuse bien qu’elle soit
encore largement employée dans des cas de petite taille.

Un premier affinage de la solution de la section précédente consiste à utiliser non pas un


fichier unique mais quatre fichiers distincts :

 un premier fichier est dédié au stockage des informations concernant les livres de la
bibliothèque.
 un second fichier est dédié au stockage des informations concernant les abonnés.

Page 20 sur 29
 les informations stockées dans le troisième fichier vont permettre de faire la
correspondance entre les deux premiers pour signifier qu’un livre donné est en cours
de prêt par un abonné donné depuis une date donnée.
 enfin, un dernier fichier va permettre de stocker l’historique des prêts. Il est similaire
au troisième fichier, mais il comporte en plus une information relative à la date de
retour du livre.
9. précisez le format et les informations stockées dans chacun de ces quatre fichiers.
10. quels sont les avantages de cette nouvelle solution ?
11. intéressons-nous au premier fichier (celui concernant les livres). Quels problèmes
diagnostiquez-vous dans ce fichier ?
12. le format de ce fichier permet-il de prendre en compte des livres co-écrits par plusieurs
auteurs ?
13. quelle solution proposez-vous ?
14. supposons la situation suivante. M. Grato Jean-Batiste et son fils, Jean-Batiste également,
ont tous les deux emprunté un exemplaire de deux livres différents :
 Vendredi ou la vie sauvage de Michel Tournier chez Poche et
 Vendredi ou la vie sauvage de Michel Tournier chez Poche

Lorsqu’ils viennent rendre leur livre, le Père précise que le prénom de son fils est Jean-
Batiste Junior, et non pas Jean-Batiste. Il remarque également que le livre qu’il (le
père)vient d’emprunter n’est pas écrit par Michel Tournier mais qu’il est co-écrit par
Michel Tournier et Gérard Franquin. Le père et le fils possèdent chacun leur carte
d’abonné où figure leur N°Abonné et chacun des exemplaires emprunté possède un
autocollant où figure le N°Exemplaire. Montrez que ces corrections ne posent pas de
problème pour notre nouvelle base de données.

9.1.4. Que retenir de ce TD?

Les problèmes les plus courants rencontrés dans des bases de données mal conçues peuvent
être regroupés selon les critères suivants :

Redondance des données – Certains choix de conception entraînent une répétition des
données lors de leur insertion dans la base. Cette redondance est souvent la cause d’anomalies
provenant de la complexité des insertions.

Page 21 sur 29
C’est, par exemple, le cas de la première organisation proposée : dès qu’un abonné emprunte
un livre, il faut dupliquer toutes les informations concernant l’abonné et le livre emprunté !
Au contraire, dans la deuxième solution, seuls les numéros indispensables à la distinction d’un
livre et d’un abonné sont répétés dans le cas d’un emprunt.

Incohérence en modification – La redondance de l’information entraîne également des risques


en cas de modification d’une donnée car on oublie fréquemment de modifier toutes ses
occurrences.

Anomalie d’insertion – Une mauvaise conception peut parfois empêcher l’insertion d’une
information, faute de connaître la valeur de tous ses champs. Pour remédier à ce problème,
certains SGBD introduisent une valeur non typée qui signifie que la valeur d’un attribut est
inconnue ou indéterminée. Cette valeur (appelée usuellement NULL) indique réellement une
valeur inconnue et non une chaîne de caractères vide ou un entier égal à zéro.

Dans la première solution proposée, insérer un nouvel abonné qui n’a jamais emprunté de
livre peut poser des problèmes. Une solution serait d’insérer des champs vides (suite de
tabulations consécutives) au début de la ligne.

Anomalie de suppression – Enfin, une mauvaise conception peut entraîner, lors de la


suppression d’une information, la suppression d’autres informations, sémantiquement
distinctes, mais indissociables dans la modélisation adoptée.

Par exemple, dans la première solution proposée, si l’on désire supprimer toutes les traces
d’un livre dans le fichier de données, on fera complètement disparaître tous les abonnés qui
n’ont emprunté que ce livre.

Bien d’autres enjeux, que ceux que nous avons abordés, sont inhérents aux bases de données.

Ces enjeux ont été survolés dans la section 2.3 et concernent la gestion des bases de données :
indépendance physique, indépendance logique, accès aux données, administration centralisée
des données, cohérence des données, partage des données, sécurité des données, résistance
aux pannes, etc.

Page 22 sur 29
La conception des bases de données est donc un problème complexe. La gestion de ces bases
constitue également un problème complexe. Or, ces deux problèmes sont extrêmement
récurrents puisque les bases de données se trouvent aujourd’hui au cœur de tous les systèmes
d’information. C’est pourquoi tous ces problèmes ont été largement étudiés et des solutions
fiables et éprouvées ont été trouvées. De nombreux travaux ont ainsi permis de mettre au
point une théorie permettant la conception de bases de données bien formées. C’est la
problématique que nous avons abordé dans le chapitre 2. La problématique de la gestion des
bases de données trouve une solution dans l’utilisation d’un SGBD.

Pour toutes ces raisons, j’espère que l’intérêt la théorie sur la conception des bases de données
ainsi que l’intérêt de l’utilisation des systèmes de gestion de base de données deviennent
évidant pour vous.

9.2. Travaux Dirigés 2 – Critique d’une gestion de données par fichier

Pour décrire les employés d’une entreprise et leur répartition entre les différents services la
table suivante a été créée.

Questions

1. Identifier les anomalies de cette structure.


2. Donner la nouvelle structure.

Page 23 sur 29
9.3. Travaux Dirigés 3 – Démarche de la création d'une base de données

Une agence "LV" de location de voitures gère manuellement son parc, composé d'une
centaine de véhicules à partir d'un paquet de fiches cartonnées.

Ci-après, un exemple de fiche de voiture :

Le responsable de la société "LV" décide d'implanter une base de données pour améliorer la
gestion de son parc de voitures.

Après étude, une voiture est décrite par le numéro d'immatriculation comme identifiant, une
marque, un type, une puissance, un kilométrage, un âge de voiture, un prix par jour et un type
de carburant.

Chaque locataire est identifié par un numéro locataire et chacun a un nom et une adresse.

A chaque location un enregistrement sera effectué : Le numéro d'immatriculation de la


voiture, le numéro du locataire et la date de location.

Le kilométrage de retour et la date de retour (date fin location) seront enregistrés au retour de
la voiture.

Questions

Page 24 sur 29
1. Etablir la liste des entités
2. Identifier et affecter à partir de l’énoncé les noms des propriétés de chaque entité.
3. Etablir une association entre les différentes entités retenues.
4. Affecter à chacune des branches situées entre une entité et une association, les cardinalités
nécessaires.
5. Préciser les clés primaires de chaque entité.
6. Etablir la liste des relations nécessaires
7. Représenter la structure de cette base de données sous forme graphique.

Page 25 sur 29
10. Correction des Travaux dirigés

Travaux Dirigés 2 – Critique d’une gestion de données par fichier

1. Identification des anomalies de cette structure


 Incohérence de données :
 On remarque que le service N°10, le nom du service n'est pas le même pour les
employés N°2,5 et 7 (Administratif, Administrative).
 Pour ce même service, la date de création diffère entre les employés N°2,5 et 7
(01/01/1975).
 Redondance de données
On remarque que lorsqu'il y a plusieurs employés appartenant au même
service, les informations relatives) ce dernier sont dupliquées ce qui a entraîner
les incohérences précédentes.
2. La nouvelle structure

Nous proposons d'éclater la table actuelle en deux tables ; donc en deux relations:

Service (Num_serv, Nom_serv, Date_creat_serv)


Employe (Num_emp, Nom_emp, Prenom_emp, Date_naiss_emp, Num_serv#)
Les tables ci-dessous sont issus de ces deux relations

Page 26 sur 29
Page 27 sur 29
Travaux Dirigés 3 – Démarche de la création d'une base de données

1. Etablissons la liste des entités

Nom entité Description


Voiture Regroupe de l'ensemble des voitures de la
société
Locataire Regroupe les personnes qui louent des voitures
de la société
Location Stocke l'historique des locations de voitures
Type_Carburant Regroupe de l'ensemble des types de
carburant pour voiture
Type_Voiture Regroupe de l'ensemble des types de voiture
existant dans la société
Marque Regroupe de l'ensemble des marques de
voiture existant dans la société
Couleur Regroupe de l'ensemble des couleurs de
voiture existant dans la société

2. Identifions et affectons à partir de l’énoncé les noms des propriétés de chaque entité.

Nom entité Propriétés Description


numV Numéro auto incrémenté
immatV Numéro d'immatriculation
puissanceV Puissance de la voiture
Voiture
kilometreV Le kilométrage indiqué par le compteur
ageV Age de la voiture
Prix_par_jourV Prix de location par jour
numLoc Numéro de locataire
Locataire nomLoc Nom de locataire
adresseLoc Adresse de locataire
kilometrage_depart
kilometrage_retour
Location
date_retour
date_loc

Page 28 sur 29
Type_Carburant numTypeC Numéro auto incrémenté
nomTypeC
numTypeV Numéro auto incrémenté
Type_Voiture
nomTypeV
numM Numéro auto incrémenté
Marque
nomM
numC Numéro auto incrémenté
Couleur
nomC

3. Etablissons une association entre les différentes entités retenues.

A faire représenter en séance

4. Affectons à chacune des branches situées entre une entité et une association, les
cardinalités nécessaires.

A faire représenter en séance

5. Précisons les clés primaires de chaque entité.

A faire représenter en séance

6. Etablissons la liste des relations nécessaires

Couleur (numC, nomC)


Marque (numM, nomM)
Type_Voiture (numTypeV, nomTypeV)
Type_Carburant (numTypeC, nomTypeC)
Voiture (numV, immatV, puissanceV, kilometreV, ageV, Prix_par_jourV, numM#, numC#,
numTypeV#, numTypeC#)
Locataire (numLoc, nomLoc, adresseLoc)
Location (numV, numLoc, kilometrage_depart, kilometrage_retour, date_retour, date_loc)

Page 29 sur 29