Anda di halaman 1dari 133
Introduction 1 2009 Jean Yves CHIESA Université de Rouen 10/07/2009 [Tapez un texte]
Introduction
1
2009
Jean Yves CHIESA
Université de Rouen
10/07/2009
[Tapez un texte]
Introduction 1 2009 Jean Yves CHIESA Université de Rouen 10/07/2009 [Tapez un texte] Cours Bases de

Cours Bases de Données

10/07/2009

2
2

Cours Bases de Données

Introduction

3
3

Introduction

  • 1. ...................................................................................................................................................

4

  • 2. Le modèle Entité-Association

15

Le modèle UML

  • 3. ...........................................................................................................................................

27

  • 4. Le Modèle Relationnel

................................................................................................................................

32

  • 5. Le langage de définition de données

49

 

Création de table

49

53

Suppression de table

53

53

Renommage

  • 6. Langage de contrôle des données

55

 

Priviléges d'accés

55

  • 7. Le langage d'interrogation des données

57

 

Consultation des

57

Insertion de données

70

Suppression de données

72

...................................................................................................................................

73

Mise à jour de données

  • 8. SQL - Programmation

75

 

ORACLE Triggers, procédures, fonctions et packages

75

Oracle PL/SQL

84

97

MySQL Langage de Programmation

102

SQL et JAVA

105

SQL et L3G (C)

123

  • 9. 08Normalisation

134

Formes Normales

39

Normalisation d'une relation

43

10.

09MethodesDeConception

144

11.

10StockageSurDisque ...........................................................................................................................

145

12.

Indexation

146

Création d'index

146

147

Suppression d'index

147

13.

12ConceptTraitementTransactions

148

Position du

148

Méthodes

150

Exclusion

151

Propriétés ACID

151

152

Les niveaux d’isolation

153

Les

Verrous

154

14.

13BasesDistribuées

156

10/07/2009

4
4

Cours Bases de Données

C O N C E P T

D E

B A S E S

D E

D O N N E E S

Pourquoi des bases de données ?

1. Introduction

Le concept de bases de données n'est pas apparu tout d'un coup par magie dans le monde de l'informatique, mais il était "en l'air" depuis longtemps. Dès les premiers fichiers sur bande magnétique, on s'était rendu compte des difficultés qu'il y avait à utiliser des informations séparées, réparties, voire même disséminées, sur plusieurs supports.

Dans une entreprise, chaque programme possède son propre ensemble de données sur lequel porte le traitement. Tant que ces ensembles ne se recouvrent pas, tout va bien. Mais ce n'est pratiquement jamais le cas et une ou plusieurs informations sont fréquemment présentes sur plusieurs fichiers. On trouvera ainsi habituellement des informations relatives à la clientèle à la fois dans la chaîne de traitement de la gestion commerciale (commandes, facturation, règlement), dans la chaîne de traitement de la comptabilité (comptabilité, gestion de trésorerie, banque), voire dans la gestion des produits. Le "gaspillage" des ressources matérielles (duplication du stockage) et humaines (re-saisie de l'information) est alors patent.

4 Cours Bases de Données C O N C E P T D E B A

Figure 1

De plus, par le simple fait des mises à jour, ces informations ont de fortes chances de ne jamais être au même niveau d'actualité. Ainsi, une même information est souvent présente sur un site informatique avec des valeurs différentes.

Introduction

5
5

Ces problèmes dits de la cohérence de l'information et de la redondance de l'information n'avaient bien entendu pas échappés aux utilisateurs des débuts de l'informatique de gestion, et de nombreuses tentatives d'homogénéisation des fichiers étaient mises en place dans la plupart des centres informatiques. Vont dans ce sens la plupart des systèmes de pointeurs entre les fichiers ou les mécanismes de mise à jour en mode "lot" (batch) voire les différentes routines d'extraction/intégration souvent présentes dans les logiciels de gestion.

Il paraît évident de dire que, pour chercher une information, il est essentiel de savoir où elle se trouve ! En informatique traditionnelle, on est souvent amené à se poser la question à cause des nombreux

fichiers physiques mis en œuvre. Une des idées qui a présidé à l'émergence des bases de données est de

chercher avant tout à privilégier la non redondance des informations. L'objectif est de réduire à UN le nombre de représentation physiques identiques d'une même donnée 1 .

Introduction 5 Ces problèmes dits de la cohérence de l'information et de la redondance de l'information

Figure 2

1 La vérité oblige à préciser qu'il s'agit du nombre de représentations "vues" par les utilisateurs, et non du nombre réel d'occurrences en mémoire ou sur un support disque. En effet, les SGBD sont parfois amenés à dupliquer physiquement certaines informations afin d'optimiser les moyens d'accès et donc les performances.

Ceci n'est cependant pas en contradiction avec le principe de base, car cette duplication est réalisée par le système lui-même, avec toutes les précautions nécessaires

6
6

Cours Bases de Données

Q U E L Q U E S

D E F I N I T I O N S

Base de données (BD) et Système de gestion de bases de données (SGBD)

Une base de données (BD) représente l’ensemble (cohérent, intégré, partagé, sécurisé, structuré) des informations nécessaires au fonctionnement d’une entreprise, ensemble dont la gestion est assurée par un logiciel appelé système de gestion de base de données(SGBD). (1)

On entend ici par entreprise toute collectivité d’individus travaillant en coordination à la réalisation d’un objectif commun.

Exemples de bases de données : celle qui permet la gestion des personnels, étudiants, cours,

inscriptions,

...

d’une

université ou école, celle du

système de réservation de places d’avion des

compagnies aériennes, celle qui permettent la gestion des comptes clients des sociétés bancaires, ...

Banque de données

Une base de données est développée au sein d’une entreprise pour son propre fonctionnement.

Inversement, une banque de données est un ensemble de données, propres à un domaine d’application, que des « producteurs » réunissent pour ensuite en commercialiser l’usage vers le public extérieur. Exemples : les banques de données juridiques, économiques, médicales, des brevets, des propriétés des

matériaux,

...

La

constitution et l’exploitation des banques de données font appel à des techniques

spécifiques (télématique, par exemple), différentes des techniques bases de données.

On peut citer comme exemple des renseignements de bibliographie, de linguistique de justice, de chimie, d'architecture, de cinématographie, de biologie, d'astronomie, de géographie, de médecine ou de jeu. La banque de données est souvent équipée d'un moteur de recherche. Elle repose sur une ou des bases de données.

Fichier

Dans une entreprise, il convient de faire appel à l’approche base de données lorsque les données à gérer

sont de natures diverses (exemple : étudiants, cours, enseignants, salles,

)

et possèdent de nombreux

.. liens entre elles (exemple : un étudiant suit un cours, un cours est assuré par un enseignant,

..

).

Il existe des cas où les données à gérer, bien qu’importantes en volume, sont homogènes : les abonnés

d’une revue, le personnel d’une entreprise, les produits vendus par un magasin,

...

Dans ce cas,

on

parlera de fichier (le fichier des abonnés,

...

)

et l’on utilisera un système de gestion de fichiers (SGF),

moins complexe qu’un SGBD. Toutefois, le prix décroissant et la facilité d’utilisation croissante des

SGBD sur micro-ordinateurs tendent à faire disparaître progressivement ces pratiques. Elles ne

subsistent plus aujourd’hui que pour des application déjà existantes.

Tout système d’exploitation d’un ordinateur contient un SGF spécifique. Toutefois, pour les

applications, on fait plutôt appel à des progiciels du commerce ( dBase, Filemaker, simple et offrant des fonctionnalités plus élaborées.

..

),

d’un usage plus

Il est à noter que l’implantation physique d’une base de données sur les mémoires secondaires se fait via

la notion de fichier. Le choix de ceux-ci, toutefois, reste de la compétence du SGBD et est invisible à

l’utilisateur.

Introduction

7
7

F O N C T I O N S

D U N

SG B D

 

Persistance des données sur disque

Partage des données (gestion des conflits d’accès)

Intégrité (respect de contraintes de cohérence)

Sûreté de fonctionnement (reprises après panne)

Confidentialité (attribution de droits d’accès)

Archivage sur support externes (back-up)

MO D E L E S

D E

D O N N E E S

E T

S C H E M A S

Au cours des différentes phases de la vie d'une base de données, plusieurs descriptions sont successivement élaborées, chacune d'elle répondant à un objectif déterminé et complémentaire. Dans

l'état actuel de l'art, ces descriptions ne peuvent être faites avec le langage naturel, celui-ci étant trop ambigu et trop difficile à comprendre pour un ordinateur. On fait donc appel à des langages formels,

basés sur un petit nombre de concepts bien établis (les objets, les liens, les propriétés, …)

On appelle modèle de données l'ensemble des concepts qui permettent la description en langage formel d'une base et les règles d'utilisation de ces concepts (leur grammaire). On appelle schéma d'une base de données l'expression de la description de la base obtenue en employant un modèle de donnée.

Lors de la conception d'une base de données, on passe en général par plusieurs étapes, chacune d'elles pouvant être plus ou moins informatisée. Dans le cas général d'un projet d'une certaine envergure, on peu distinguer au moins les phases de conception, d'implantation, de chargement des données, d'utilisation. Dans le cas de petites bases de données simples, certaine de ces phases sont absentes voire dans certains cas imposées par le SGBD.

Conception d'une base de données.

C'est la phase d'analyse du réel qui conduit à déterminer le contenu futur de la base. Le premier problème à résoudre est de déterminer les informations qu'il convient de stocker dans la base.

Dans cette phase, il s'avère nécessaire que les utilisateurs puissent échanger avec les informaticiens du contenu de leurs besoins. Il faut qu'ils puissent exprimer ceux-ci sous forme d'une description, éventuellement partielle, de la future base. Dans cette phase, il est important de déterminer quelles sont les informations nécessaires à la vie de l'entreprise, indépendamment de la solution technique qui sera retenue. La description de ces informations s'appuie ne général sur un ensemble de concepts qui ne font pas référence à l'informatique. Les modèles utilisés sont dits "conceptuels".

La description ainsi obtenue est dite modèle conceptuel des besoins. Un tel modèle comprend en général deux parties, le modèle statique, permettant de décrire la structure des données et le modèle dynamique, description des opérations sur les données.

De plus, quelque soit le modèle conceptuel choisi, il n'est pas possible de décrire toute la connaissance que l'on possède sur le fonctionnement de l'entreprise, notamment les règles de gestion. On complète donc le modèle en énonçant des descriptions explicites de contraintes supplémentaires, dites contraintes d'intégrité.

Cette activité est peut être une des plus délicates qui puissent exister dans le domaine des bases de données. C’est pourquoi de nombreuses méthodes d’analyse existent. Actuellement, celle dont on parle le plus (mais est elle réellement la plus utilisée ?) est la méthode UML, conçue au départ comme une méthode d’analyse des applications en général, mais qui a très vite étendu son domaine aux bases de données. En France, la méthode Merise continue à être très appliquée dans les projets d’une certaine envergure.

8
8

Cours Bases de Données

Implantation d'une base de données.

La phase suivante, celle d'implantation, demande que les données du schéma conceptuel soient traduites dans les concepts du modèle utilisé par le SGBD choisi. On appelle modèle logique (ou modèle machinable) le modèle sur lequel est construit un SGBD actuel.

Il existe aujourd'hui plusieurs modèles logiques, certains étant massivement prédominants (hiérarchique, réseau, relationnel, objet). Le schéma obtenu en traduisant le modèle conceptuel des données sera appelé le schéma logique des données.

Quelques SGBD prennent en compte la totalité de la notion de schéma.

Chargement de la base

Le chargement de la base de données avec la version initiale nécessite que soient fixés les choix en matière de structuration des données sur le disque (quels type(s) de fichier(s), quels index ?). Ces choix ne sont pas faits par les utilisateurs, mais par les administrateurs de base de données qui, en fonction de leur analyse des traitements qui seront effectués sur la base, fixent les paramètres effectifs pour l'implantation de la base de données dans le SGBD.

L'ensemble de ces choix sera consigné dans ce qu'on appelle le schéma interne de la base. Cette description fait appel à un nouveau modèle, appelé modèle interne, où les concepts clés seront ceux de fichier, organisation, index, chemin d'accès, clé, …

Seuls les SGBD de haut de gamme permettent la mise en place de tels schémas. La plupart des SGBD sur micro-ordinateur sont eux totalement pré-configurés.

Utilisation de la base

Au cours de la phase d'utilisation de la base de données, d'autres schémas sont élaborés pour répondre aux besoins spécifiques des utilisateurs. La plupart de ceux ci n'ont pas besoin de connaître l'ensemble du contenu de la base. Chaque utilisateur n'a que des exigences limitées (il n'est intéressé que par certaines informations) et particulières (il souhaite une représentation qui lui convienne des informations).

A ces utilisateurs, on peut associer un schéma, dit schéma externe, qui définit le sous ensemble de la base auquel il a accès.

8 Cours Bases de Données Implantation d'une base de données. La phase suivante, celle d'implantation, demande

Figure 3

Introduction

9
9

Ce choix d’architecture a pour objectif d’accroître le niveau d’indépendance entre les données et les

traitements, a savoir :

l’indépendance physique,

l’indépendance logique,

l’indépendance vis-à-vis des stratégies d’accès.

L’indépendance physique consiste à rendre l’utilisation des données indépendante de leur organisation physique (support de stockage et méthodes d’accès). La modification de l’organisation physique des

données ne doit pas entraîner, par exemple, la réécriture de programmes accédant à ces données.

L’indépendance logique consiste à rendre l’utilisation des données indépendante de la structure logique

globale. La modification du schéma conceptuel ne doit pas entraîner la modification des programmes

d’application. Une modification des schémas externes est cependant nécessaire dans ce cas.

L’indépendance vis-à-vis des stratégies d’accès n’intervient qu’au moment de la manipulation des données. Un programme d’application n’a pas à préciser comment accéder à telle ou telle donnée mais uniquement ce qu’il désire (le « quoi » et non pas le « comment »). C’est le SGBD qui doit déduire le meilleur chemin d’accès aux données.

S T R U C T U R E

T Y P E S

D E

D O N N E E S

Nous allons présenter dans cette section quelques représentations de l’organisation et de l’accès aux données utilisés en base de données. Certaines n’ont plus qu’un intérêt historique ou sont éventuellement utilisées dans des applications spécialisées (hiérarchique, réseau). D’autres sont en concurrence difficile avec le modèle relationnel, qui a envahi l’ensemble de l’espace et ne rencontre aujourd’hui plus aucune résistance.

Historique sommaire

Recherche

Concepts

Produits

  • 1950 Structure hiérarchique : les données sont représentées sous forme d’une arborescence

1960

  • 1960 Structure réseau : les données sont représentées sous forme d’un graphe quelconque

1970

  • 1970 Structure relationnelle : les données sont représentées sous forme de tables

1980

  • 1980 Modèle objet : représentation sous forme d’objet et relationnel objet : représentation relationnelle et extensions afin de stocker les méthodes.

1990

Structure hiérarchique

Ce modèle est capable de créer et de gérer des bases de données dont les relations entre les divers éléments logiques sont du type communément appelé "un à n".

Prenons l'exemple des cartes grises des automobiles.

Pour décrire une carte grise, il faut un fichier contenant le nom de la personne, la marque du véhicule, le numéro d'immatriculation. Une personne pouvant posséder plus d'un véhicule, on admettra que la partie relative à celui ci, marque et numéro d'immatriculation, est présente de "une" à "n" fois. On voit donc qu'il existe dans ce fichier deux types de relations entre les données : d'une part des relations "1 à

10
10

Cours Bases de Données

n" entre une personne et les véhicules qui lui appartiennent et d'autre part une relation "1 à 1" entre un véhicule et son propriétaire.

La décomposition hiérarchique de ce fichier est illustrée par la figure qui met en évidence les divers ensembles et sous ensembles de données.

A partir de cette décomposition, il est possible de représenter schématiquement l'arborescence de la base de données (figure ) : un nom d'individu "pointe" sur un sous-ensemble d'informations relatives à un véhicule, ce sous ensemble étant présent "n" fois, c'est-à-dire autant de fois que l'individu possède de véhicules. On peut constater que cette décomposition en ensembles et sous ensembles n'est pas réservée à une approche du problème par les bases de données ; une solution classique de fichier aurait eu recours à la même structure de données. Cependant, dans ce cas, tout choix d'organisation était définitif, à cause de la dépendance entre l'organisation physique des données et les techniques de programmation.

Une réalisation sous forme de base de données permettra en partie de s'affranchir de cette contrainte, mais en partie seulement. En effet, il est obligatoire de définir, au moment de la création de la base, l'ensemble des liens logiques à créer (figure).

Un des principaux inconvénients d'un tel système réside dans sa relative rigidité. Il faudra veiller à organiser la base selon un schéma correspondant aux accès les plus courants. En effet, dans un tel modèle, les éléments terminaux ne peuvent être atteints que par les éléments racines. Un problème majeur intervient lorsque les questions posées sont du type : "Donne moi tous les éléments pères possédant des racines de tel type".

Un parcours intégral de la base sera alors nécessaire et, si ces parcours sont nombreux, l'utilisation de la base sera alors aussi onéreuse que celle d'un bête fichier séquentiel.

De plus, le parcours obligé de la structure d’arbre pour accéder aux données provoque forcément une redondance des données. Or la redondance créant l’incohérence …

Structure en réseau

Dans les années 1970 commence la définition d’un nouveau type de gestionnaire de bases de données, destiné à pallier toutes les faiblesses citées du modèle hiérarchique. C’est en 1971 que sort le rapport

d’un groupe de travail réunissant fabricants d’ordinateurs et utilisateurs, connu sous le nom de « Codasyl Data Base Task Group Report ». Ce rapport reprenait, en les développant, les idées qui

venaient d’être mises en œuvre par C. Bachman dans la conception du SGBD IDS. Ce rapport eut un

retentissement suffisant pour que très rapidement se répandent des SGBD de type réseau, « aux normes Codasyl ».

Fournisseur ... ... Type Article ... ... Article Figure 4
Fournisseur
...
...
Type Article
...
...
Article
Figure 4

Une des idées de base est de permettre l’accès aux informations par différents liens, de s’affranchir de la relation parents/enfants qui est contenue dans une structure hiérarchique. Considérons l’exemple

suivant : une entreprise a un certain nombre de fournisseurs. Chaque fournisseur propose des articles regroupés suivant différents « type articles » (chaudronnerie, électricité, gros-œuvre, charpente, …).

Introduction

11
11

Chaque article est caractérisé par une référence chez le fournisseur et un prix. Cette réalité est facilement mise en œuvre par le diagramme hiérarchique de la Figure 4. Cependant il arrive fréquemment que plusieurs fournisseurs proposent le même article. Si alors on souhaite effectuer une recherche sur les différents prix des articles similaires, on imagine facilement que le parcours de la base hiérarchique va devenir d’une complexité importante. Le principe d’une base réseau est de permettre de créer des liens entre des éléments sans dépendance de type parents/enfants entre eux, comme les articles dans notre cas.

Fournisseur ... ... Type Article Article
Fournisseur
...
...
Type Article
Article
Fournisseur ... ... Type Article Article
Fournisseur
...
...
Type Article
Article
   

...

 

...

   
   

...

 

...

   
Introduction 11 Chaque article est caractérisé par une référence chez le fournisseur et un prix. Cette

Figure 5

Bien entendu, la complexité d’une telle base va croître très vite en fonction du nombre de liens supplémentaires que l’on va vouloir mettre en œuvre. Partant, les temps d’accès vont aussi croître et il faudra souvent étudier sérieusement les coûts comparés d’un accroissement du nombre de liens par rapport à des redondances (nous retrouverons d’ailleurs ces mêmes problématiques sous une forme

légèrement différente dans le modèle relationnel). Il faut également noter que dans les deux modèles de

bases de données hiérarchique et réseau, la souplesse apparente liée à la possibilité de faire créer par le système tous les pointeurs désirés est en pratique limitée par la nécessité de définir, au moment de la

création de la base, l’ensemble des pointeurs et des chemins d’accès voulus. Toute modification ultérieure implique souvent une refonte de la base et (et des programmes d’exploitation).

Structure relationnelle

Face à cet ensemble de difficultés se sont progressivement imposées sur le marché les bases de données

relationnelles, dans lesquelles ces contraintes de navigation par des pointeurs prédéterminés n’existent plus. Ces dernières fonctionnent sur le principe selon lequel « c’est le contenu de la question qui va déterminer les chemins d’accès à établir ». Les liens ne sont plus fixés une fois pour toutes dans le SGBD, c’est le système qui les fabriquent dynamiquement selon les besoins. Le système agit par

« déduction » à partir de la question. Lorsque celle ci implique la consultation des fichiers W et X, les

liens entre ces fichiers seront réalisés entre ceux ci en fonction des noms de zones communs à ces

fichiers. Il sera possible à tout moment d’ajouter ou de supprimer des fichiers dans la base de données.

PAIE

 

HISTORIQUE

 

EMPLOYES

Matricule

Matricule

Matricule

Date

Date d'entrée

Date entrée

Montant

Ancienneté

Nombre enfants

...

...

...

Figure 6

La Figure 6 montre le principe du regroupement en tables des données appartenant à des fichiers différents d’une base relationnelle. Lors d’une interrogation portant sur le montant de la paie et l’ancienneté de l’employé, les deux tables PAIE et HISTORIQUE seront chaînés pour trouver la réponse. Si la donnée nombre d’enfants est aussi mentionnée, la table EMPLOYES sera aussi connectée

12
12

Cours Bases de Données

logiquement et physiquement pour participer à la recherche. Il va de soit que la donnée commune matricule doit figurer dans chacune des tables, sinon tout chaînage serait impossible.

Bases de données objet

La technologie orientée objet est un domaine à la situation un peu floue dans le domaine de la gestion

des données. L’augmentation du niveau d’abstraction introduit par les concepts d’objet, de classes, de

méthodes, de messages entre les objets a prouvé sa valeur dans le domaine de la programmation. Il était

donc naturel que la communauté des bases de données tente d’appliquer ces concepts. De plus, à partir

du moment ou les informaticiens manipulaient des objets, il était naturel que se pose la question de la

persistance des données, autrement dit du stockage de ces données. Et là, les bases de données relationnelles, avec la pauvreté de leur structure, apparaissaient nettement défavorisées.

Après un moment de confusion, ou certains ont pu prédire la fin du modèle relationnel, la situation est actuellement relativement claire.

D’un côté, de nouveaux concepts de bases de données, purement objet, permettent de développer des produits dont l’objectif essentiel est de prolonger les développements objets dans le domaine du stockage. C’est le cas de J2EE qui propose depuis longtemps un modèle de composants prédéfinis (les

EJB Entities) conçu pour faciliter la mise au point de cette couche de persistance. Certaines sociétés ont également tenté l’aventure de produits commerciaux, avec plus ou moins de bonheur. Il semble que le problème des performances soit difficile à régler.

D’autre part, les grands éditeurs de bases de données relationnelles prolongent maintenant leurs produits avec des extensions orientées objet, permettant de continuer l’utilisation des concepts relationnels, en les étendant si nécessaire. C’est le cas d’Oracle ou de Postgres par exemple.

S G B D

:

LE S

A C T E U R S

D U

M A R C H E

La théorie est une chose, la réalité commerciale en est une autre. Il existe des centaines de bases de données (sans parler des prototypes universitaires ou autres). Cependant il faut avoir conscience que,

dans la réalité des entreprises, le marché se partage entre quelques grands acteurs. Essayons d’en

donner un rapide panorama. Je ne dirai rien des SGBD de type bureautique comme Access, FoxPro,

FileMaker, 4D, Omnis. Non pas qu’ils ne soient pas intéressants, mais la plupart, pour des raisons

diverses, sont trop loin des concepts qui caractérisent un SGBD.

Les bases de données relationnelles commerciales

Editeur

 

Version et OS

 

Remarques

Oracle

Tous OS

Acteur historique du marché. Faible marketing, mais

sans cesse à l’affût de compléments et de nouveautés.

Peu facile à utiliser …

IBM

DB2

L’éléphant a du mal à danser face à Microsoft. Mais

Tous OS

reste un acteur incontournable et mène un combat impitoyable, en se défendant pied à pied face à son challenger.

Microsoft

SQL Serveur

Ultra facile à utiliser et administrer. Nombreuses

extensions intéressantes (data mining, replication, …).

Sybase

Uniquement Windows Quasiment tous OS

Informix

Unix Like et Windows

Un acteur historique, récemment racheté par IBM. La

fin d’une histoire ?

Introduction

13
13

Les bases de données relationnelles Open Source

Editeur

Version et OS

Remarques

MySQL

Linux, Windows,

Optimisé pour la vitesse, pèche encore par de

Mac OS X

nombreux manques sur des concepts relationnels

 

comme les transactions ou l’intégrité référentielle (qui

devraient être introduites dans la version 5)

PostgreSQL

Linux, Unix, MacOS X et

C’est l’antithèse de MySQL. Implémentation de la

Windows

plupart des concepts relationnels, au détriment de la

 

vitesse disent certains…

SAP

Linux, Unix, MacOS X et

A ne pas confondre avec l’ERP du même nom. Semble

Windows

actuellement (Février 2003) en processus de fusion

 

avec MySQL …

Borland

Linux, Windows, Solaris Le produit s’appelle Interbase. Il est surtout

commercialisé avec les outils de développement de

 

l’éditeur (Delphi, C++, Kilyx, …)

Four Thought

Windows, Linux

Sleepycat Software

Windows , Linux, Solaris

Le produit s’appelle Berkeley DB …

Tous systèmes (développement en Java)

Les bases de données « objet »

Editeur

Version et OS

Remarques

Matisse

Windows, Unix

Stockage direct d’objets provenant de Java, C#, VB,

Delphi, Eiffel, Smalltalk, Perl, Python, PHP

Objectivity

Windows, Unix

Versant

Solaris, Windows

Stockage direct des objets de J2EE

Les bases de données « XML »

Avec la généralisation de l’engouement pour XML, il était fatal que les SGBD s’y collent. Deux approches existent actuellement. Chez Oracle ou IBM, le principe est de fournir une surchouche de procédures permettant de stocker et de retrouver de manière transparente des données XML dans une base de données relationnelle. Une autre approche consiste à stocker directement les données sous forme XML. C’est un peu celle de Microsoft dans le projet « Yukon », future version de SQL Server. Certains éditeurs tentent aussi le pari. Peu de commentaires, j’avoue peu connaître ce domaine.

Editeur

Version et OS

Remarques

Wolfgang Meyer

eXist 0.9.2

sous Java

Apache

Apache Xindice 1.0

Windows, Linux

Software AG

Tamino 4.1.4

Windows, Solaris, Unix

Ipedo

Windows, Unix

IxiaSoft

Windows, Unix

14
14

Cours Bases de Données

Répartition du marché

Les chiffres suivants concernent l’année 2006 (source http://www.journaldunet.com (2)) :

Taille du marché: 16,45 milliards de dollars (revenus des licences)

 

PDM 2006

PDM 2004

PDM 2002

PDM 2001

(source IDC)

IBM

21,2 %

34,1%

36,2%

33,9%

Oracle

44,4 %

33,7 %

33,9%

39,7%

Microsoft

18,6 %

20 %

18,0%

14,3%

NCR

2,8 %

2,9 %

2,7%

2,4%

Autres

   

9,2%

9,7%

Si IBM se taille la part du lion (mais son offre est très diversifiée sur plusieurs gammes de machines, du poste individuel au serveur départemental, avec différents types de bases de données), on constate que la lutte se situe essentiellement entre Oracle, créateur historique de la base de données relationnelle, et Microsoft, challenger encore handicapé par son approche mono plate forme (Windows exclusivement).

Les parts de marché d’Oracle décroissent continuellement au profit de Microsoft, en raison

essentiellement d’une politique de prix extrêmement agressive de la part de Microsoft, mais aussi de la montée en puissance de Windows Server, avec lequel SQL Server est de plus en plus proposé comme produit de « Back Office ». Microsoft essaye avec ce produit de rejouer « le coup de l’intégration » qui avait tellement bien réussi avec Internet Explorer. Ces chiffres ne font cependant pas apparaître que, en production, Oracle reste le support de bases de données nettement plus volumineuses et complexes que SQL Server.

Dans le monde de l’Open Source, MySQL se taille la part du lion …

Parts de marché des SGBD Open Source parmi les développeurs de bases de données qui en utilisent au moins un

Région

Part de marché 2004

MySQL

52,9%

FireBirdSQL

51,6%

PostgreSQL

14,8%

Sleepycat's Berkeley DB

4,1%

GNU SQL

3,3%

SAP DB

1,2%

Source : Evans Data

 

Le marché des SGBDR dans le monde en 2006

 
 

(en millions de dollars)

 
           

Acteur

CA 2004

CA 2005

CA 2006

PdM 2006

         

Variation 2005 / 2006

Oracle

6

003

6

376

7

312

44,4%

+14,7%

IBM

2

923

3

113

3

483

21,2%

+11,9%

Microsoft

2

013

2

442

3

052

18,6%

+25,0%

Sybase

 

471

 

503

 

524

3,2%

+4,3%

NCR

 

390

 

423

 

457

2,8%

+8,0%

Autres

1

495

1

542

1

624

9,9%

+5,3%

Total

13 296

14 398

16 451

100,0%

+14,3%

Source : IDC

Le modèle Entité-Association

15
15

2. Le modèle Entité-Association

C O N C E P T S

D E

B A S E

E T

D I A G R A M M E S

EA

Le modèle entité-association (EA, appelé aussi entité-relation) est un modèle de données de type conceptuel. Il est actuellement utilisé par la plupart des méthodes et outils d’aide à la conception

(MERISE,

...

).

C'est un modèle limité à la description statique : son but est de permettre la description des

structures de données exclusivement, sans préjuger des traitements qui s'effectueraient sur ces structures.

L’idée fondamentale de ce modèle est de retenir comme concepts de base les concepts génériques (objets, liens, propriétés) utilisés dans le processus d’abstraction qui conduit de l’observation d’une

réalité à sa description. On suppose que la perception d'une situation observée se fait naturellement sur la base de l'identification des objets présents (concrets ou abstraits), des liens entre ces objets et des propriétés observables de ces objets.

Afin de distinguer le discours sur la réalité (fait en termes d'objets, de liens et de propriétés) du discours sur la représentation de la réalité, le modèle EA renomme ces mêmes trois concepts avec une terminologie particulière :

Entité

OBJET

ENTITE

LIEN

ASSOCIATION

PROPRIETE

ATTRIBUT

objet du monde réel (concret ou abstrait), à propos duquel on veut enregistrer des informations et qui a une existence propre. Une

entité existe indépendamment du fait qu’elle est liée à d’autres

Type d’entité (TE)

objets de la base de données.

Exemples : Mme Dupont, Mr. Durand, la cafetière X32, l’atelier de fabrication A22, le service Comptabilité, ...

représentation d’une classe d’entités perçues comme similaires et

ayant les mêmes caractéristiques.

Exemples : employés (représentation de la classe des employés), produit, atelier de fabrication, service, ...

16
16

Cours Bases de Données

Association

lien entre plusieurs entités où chacune d’elles joue un certain rôle. Si l’association lie deux (ou plus) entités du même type, elle est

dite « cyclique » et, dans ce cas, la spécification du rôle de chaque entité est indispensable pour supprimer les ambiguïtés possibles.

Exemples : l’atelier de fabrication A22 fabrique la cafetière X32; l’employé Durand travaille dans le service Comptabilité; Mr Durand, époux, est marié avec Mme Dupont, son épouse, ...

Type d’association (TA)

représentation d’un ensemble d’associations similaires ayant les

mêmes caractéristiques (liant des entités de même type avec les

Attribut

mêmes rôles, et possédant les mêmes propriétés).

Exemples : fabrique lie un

atelier

de

fabrication à

un

produit; travaille lie un employé à un service; est marié avec lie une personne, l’époux à une personne, l’épouse, ..

propriété associée à un TE, ou à un TA, ou participant à la

composition d’un autre attribut.

Exemples : nom, prénoms, salaire sont des attributs du TE employé; quantité-en-fabrication est un attribut du TA fabrique; date-de-mariage est un attribut du TA est marié avec; jour, mois, année sont des attributs composant un attribut date, ...

On appelle occurrence d’un TE (TA) la représentation dans la base de données d’une entité (association) appartenant à la classe décrite par le TE (TA). On appelle population d’un TE (TA) l’ensemble des occurrences du TE (TA). La base de données décrite par le schéma EA est l'ensemble des populations des TE et TA apparaissant dans le schéma

Une occurrence de TE est constituée d’un ensemble de valeurs : une valeur pour chaque attribut du TE (NB : il est possible que la valeur d’un attribut soit en fait une absence de valeur ou un ensemble de valeurs).

Une occurrence de TA est constituée d’un ensemble de valeurs (éventuellement vide) et d’un ensemble d’occurrences de TE : une valeur pour chaque attribut du TA, (s’il en existe), et, pour chaque rôle du TA, une occurrence du TE qui joue ce rôle.

Il faut remarquer que les termes type, population, occurrence sont génériques (ne sont pas propres au modèle EA).

Le modèle EA permet une représentation graphique assez lisible d’un schéma d’une base de données. Dans cette représentation, appelée diagramme EA, les types d’entités sont représentés par des rectangles; les types d’associations sont représentés par des losanges ou autre symbole similaire (ellipse,

hexagone, rectangle arrondi,

).

Les attributs sont soit rattachés au TE (TA) par des traits, soit listés à

... l’intérieur du rectangle TE (losange TA), au dessous du nom du TE (TA) et séparés de celui-ci par une

barre (voir diagrammes MERISE, par exemple).

Le modèle Entité-Association

17
17

Par exemple, le diagramme EA suivant illustre un schéma possible pour la gestion d'un supermarché :

sup Nom NomF Sal Adresse Employé chef Fournisseur inf E F livraison emploi A R Quantité
sup
Nom
NomF
Sal
Adresse
Employé
chef
Fournisseur
inf
E
F
livraison
emploi
A
R
Quantité
R
NomR
NomA
Etage
Type
Rayon
vente
Article
R
A

Quantité

Dans ce diagramme, sont représentés quatre types d’entités :

Employé, d’attributs nom et sal,

Rayon, d’attributs nomR et étage,

Article, d’attributs nomA et type,

Fournisseur, d’attributs nomF et adresse.

Ces types d’entité sont reliés par les types d’association suivants :

Livraison, d’attribut quantité, liant Fournisseur (avec le rôle F), Article (avec le rôle A) et Rayon

(avec le rôle R), Vente, d’attribut quantité, liant Rayon (avec le rôle R) et Article (avec le rôle A),

Emploi, liant Employé (avec le rôle E) et rayon (avec le rôle R),

Chef, cyclique, liant Employé (avec le rôle Inf) et Employé (avec le rôle Sup).

G E N E R A L I S A T I O N

/

SP E C I A L I S A T I O N

Un type entité représente une classe d’objets du monde réel perçus comme similaires et ayant les mêmes caractéristiques. Or, il arrive parfois qu’un même ensemble d’objets soit perçu d’un certain point de vue comme une seule classe, mais en même temps perçu d’un autre point de vue, comme plusieurs classes, différentes malgré l’existence de caractéristiques communes.

Exemple : dans le diagramme du paragraphe précédent, le TE Article regroupe tous les articles vendus, quels qu’ils soient; certains traitements doivent pouvoir accéder de façon uniforme à tous les articles : inventaire, recherche des caractéristiques d’un article dont on connaît le code, ...

Pour d’autres usages, on peut néanmoins vouloir séparer les articles en plusieurs classes

(alimentation, habillement, Hi-Fi, hygiène,

..

).

Par exemple, la gestion des ventes promotionnelles

n’aura pas les mêmes critères suivant la catégorie, les articles d’alimentation doivent être retirés

des rayons lorsque la date limite de vente est dépassée. Chaque classe peut avoir des

caractéristiques qui lui sont propres, par exemple : date limite de vente (alimentation), taille et couleur (habillement), ...

On sera donc amené à décrire, en plus du TE générique Article, des TE plus spécialisés, représentant les classes « intéressantes » (celles sur lesquelles on a effectivement quelque chose de particulier à faire). Par exemple, un TE « Article alimentaire », un TE « Article d’habillement » et un TE « Article Hi-Fi ».

Ceci, toutefois, introduit une situation atypique : celle où les mêmes objets sont représentés par deux TE

(le TE générique et l’un des TE spécialisés), alors que normalement les populations de deux TE représentent des classes d’objets disjointes.

18
18

Cours Bases de Données

Pour décrire une telle situation, les modèles de données récents incluent le concept de généralisation/spécialisation : un lien, orienté, d’un TE spécialisé (ou spécifique) vers un TE générique. La sémantique de ce lien est que toute occurrence du TE spécifique est également occurrence du TE générique. Graphiquement, ce lien est représenté par une flèche orientée du TE spécifique vers le TE générique.

Pour l’exemple de l’hypermarché, cela donne le diagramme suivant pour la représentation des articles :

Article
Article
18 Cours Bases de Données Pour décrire une telle situation, les modèles de données récents incluent
Art. Alimentaire
Art. Alimentaire
Art. Habillement
Art. Habillement
Art Hi-Fi
Art Hi-Fi

Les liens de généralisation/spécialisation sont souvent appelés liens « est-un »; on dit que « Article alimentaire est-un Article ». On dit généralement que le TE spécifique est un sous-type du TE générique qui lui est un sur-type du TE spécifique.

Par convention, les attributs communs au TE générique et aux TE spécialisés ne sont décrits, dans le schéma, que comme attributs du TE générique. Néanmoins, ils sont implicitement inclus dans les attributs des TE spécifiques : on dit que ces derniers « héritent » des attributs du TE générique. En plus des attributs hérités, les TE spécifiques peuvent avoir des attributs propres.

Ce qui a été dit pour les attributs s’applique également aux TA (description, héritage). Par exemple, le

TE « Article Hi-Fi », comme les autres TE spécifiques, est implicitement lié par les TA Vente et Livraison, hérités du TE Article. Il pourrait, en plus être lié par un TA Réparation à un TE Service après- vente (tel type d’article est réparé par tel service après-vente). Ce dernier TA n’est défini alors que pour les articles du TE Article Hi-Fi.

Un diagramme plus complet pour l’exemple hypermarché est donc :

Livraison Marque NomA Type N°code Vente Article Quantité en stock Article Article Article Habillement Hi-Fi Puissance
Livraison
Marque
NomA
Type
N°code
Vente
Article
Quantité en stock
Article
Article
Article
Habillement
Hi-Fi
Puissance
Alimentaire
limite vente
Tailles
Couleurs
Réparation
Service
Après-Vente

Le modèle Entité-Association

19
19

Il n’est pas nécessaire que les TE spécifiques représentent, dans leur ensemble, tous les objets

représentés par le TE générique. Ainsi, dans l’exemple, les articles d’hygiène, de bricolage, constituent pas d’autres classes spécifiques et sont donc uniquement représentés par le TE Article.

..

ne

Un TE générique peut à son tour être sous-type d’un autre TE : on dit alors que l’on a une hiérarchie de généralisations.

On parle de généralisation multiple lorsqu'un TE est sous-type de plusieurs autres TE. C'est le cas dans cet exemple du chargé de cours, qui est à la fois thésard et vacataire. La généralisation multiple pose des problèmes liés à l'héritage : éviter d'hériter deux fois d'un ancêtre commun, éviter d'avoir des conflits d'héritage (par exemple sur des problèmes d'attributs de même nom).

Section

Le modèle Entité-Association 19 Il n’est pas nécessaire que les TE spécifiques représentent, dans leur ensemble,
Etudiant Thésard
Etudiant
Thésard

Sujet

N°matricule Personne Nom Prénom Classe de Employé Traitement Enseignant Technicien Administratif
N°matricule
Personne
Nom
Prénom
Classe de
Employé
Traitement
Enseignant
Technicien
Administratif
Vacataire
Vacataire
Professeur Laboratoire
Professeur
Laboratoire

D E S C R I P T I O N

D U N

S C H E M A

EA

Un TE est décrit par les spécifications suivantes :

le nom du type d’entité;

le nom du sur-type d’entité, s’il existe;

une définition libre (commentaire) précisant la population exacte du type d’entité,

la description des attributs du TE

Exemple : description du TE « Employé » nom : Employé définition : « toute personne salariée par l’entreprise en ce moment » attributs : nom, salaire (avec leurs description)

Remarques :

- deux TE différents ne peuvent avoir le même nom;

20
20

Cours Bases de Données

- la définition libre est une partie très importante de la description d’un TE. C’est elle qui permet de définir exactement, de façon non ambiguë, la population du TE. Elle inclut notamment la spécification

temporelle (soulignée dans l’exemple), qui permet de savoir si le contexte modélisé couvre uniquement la situation actuelle ou aussi l’historique (les situations antérieures) et/ou la prospective (situation à venir).

Un TA est décrit par les spécifications suivantes :

le nom du type d’association;

une définition libre (commentaire) précisant la population exacte du type d’association;

les noms des TE participant au TA, avec leur rôle;

pour chaque rôle, ses connectivités (souvent appelées cardinalités) : c’est une information supplémentaire exprimant la règle de participation des entités dans les associations (au niveau des occurrences). Les connectivités consistent en deux nombres, min et max, spécifiant le nombre

minimal et le nombre maximal d’occurrences du TA qui peuvent, à un instant donné, lier par ce

rôle une occurrence déterminée du TE en question. min et max sont deux entiers tels que maxmin, min0, max1; - la description des attributs du TA, s’il en existe.

Exemple : description du TA « Emploi » nom : Emploi définition : « lie un employé au rayon dans lequel cet employé travaille aujourd’hui » TE participants : <Employé, E>, <Rayon, R>

connectivités : E: min=0, max=1

R: min=0, max=n;

attributs : ---

Les connectivités possibles pour un rôle (ici, E de Emploi) et leur signification sont les suivantes :

min=0

:

un employé peut ne travailler dans aucun rayon

min=1

:

un employé doit travailler dans au moins un rayon

max=1

:

un employé ne peut travaiiler dans plus d’un rayon

max=n :

un employé peut travailler dans plusieurs rayons

Conventions graphiques :

min=0, max=1 sont représentés par un trait unique discontinu min=1, max=1 sont représentés par un trait unique continu min=0, max=n sont représentés par deux traits discontinus

min=1, max=n sont représentés par deux traits l’un continu et l’autre discontinu.

Une autre façon de faire est de représenter les connectivités par deux chiffres (min,max ou min:max) au voisinage du trait continu représentant le lien correspondant :

 

0,n

Parent

 
est parent de est parent de
est parent de
est parent de

2,2

 
 

Enfant

Signification des connectivités dans ce diagramme : un parent peut avoir de 0 à n enfants; un enfant a toujours (dans cette base de données) deux parents.

Le modèle Entité-Association

21
21

Cas particuliers des TA cycliques : un TA est dit cyclique s’il lie plusieurs fois le même type d’entité (avec des rôles différents). Dans ce cas , le nom des rôles est essentiel et il faut, dans un diagramme, les noter sur les pattes de TA.

Exemples : les produits sont composés d’autres produits

est composé de
est composé de

quantité

Composition
Composition
Produit
Produit

est composant de

Si l’on enregistre dans la base de données la composition du produit 10001 : 5 unités de produit 512 et 3 unités de produit 123, on obtiendra les occurrences suivantes :

TE

Produit

produit

123

 

produit

512

produit

10001

TA

Composition

est composé de

est composant de

quantité

 

produit 10001

produit 123

3

produit 10001

produit 512

5

Les produits peuvent à leur tour apparaître dans le TA composition avec le rôle « est composé de », si ce ne sont pas des produits de type matière première.

Un attribut est décrit par les spécifications suivantes :

nom de l’attribut

  définition libre (libellé en clair) connectivités : min et max, spécifiant combien de valeurs de cet attribut sont autorisées (au minimum, au maximum) dans une occurrence du TE (TA), si l’attribut est directement rattaché au TE (TA), dans une valeur de l’attribut dont il est composant sinon (voir ci-dessous); si l’attribut n’est pas composé d’autres attributs : domaine de valeurs associé, spécifiant quel ensemble des valeurs est autorisé pour l’attribut; si l’attribut est composé d’autres attributs : description des attributs composants.

Exemple 1 : description de l’attribut « nom » du TE Employé

nom :

nom

définition : « nom de l’employé, nom de jeune fille pour une femme » connectivités : min=1, max=1 (tout employé a un nom et un seul) domaine de valeurs : l'ensemble des chaînes de caractères de longueur inférieure à 15.

22
22

Cours Bases de Données

Exemple 2 : description d’un attribut « date de naissance » d’un TE Personne nom : date de naissance définition : « date de naissance de la personne » connectivités : nim=1, max=1 composition :

nom : jour définition : « jour de naissance de la personne » connectivités : nim=1, max=1 domaine de valeurs : les entiers de l’intervalle [1,31]

nom : mois définition : « mois de naissance de la personne » connectivités : nim=1, max=1 domaine de valeurs : les entiers de l’intervalle [1,12]

nom : année définition : « année de naissance de la personne » connectivités : nim=1, max=1 domaine de valeurs : les entiers de l’intervalle [1870,2001]

TE R M I N O L O G I E

On appelle

attribut simple : un attribut qui n’est pas décomposé en d’autres attributs. Ses valeurs sont atomiques. Un domaine lui est associé.

Exemple : salaire, téléphone

attribut complexe : un attribut qui est décomposé en d’autres attributs. Ses valeurs sont des valeurs composées.

Exemple : adresse composée de rue, ville, code postal.

attribut monovalué : un attribut qui ne peut prendre qu’une seule valeur par occurrence (connectivité

max=1)

Exemple : nom, date de naissance

attribut multivalué : un attribut qui peut prendre plusieurs valeurs par occurrence (connectivité max>1)

Exemples : prénoms, téléphones

attribut obligatoire : un attribut qui doit prendre une valeur au moins par occurrence (connectivité

min=1)

Le modèle Entité-Association

23
23

Exemple : nom, prénoms

attribut facultatif : un attribut qui peut ne pas prendre de valeur dans une occurrence (connectivité

min=0)

Exemple : salaire, téléphone

CL E S

D E S

TE

E T

TA

Une clé, ou un identifiant, d’un TE (TA) est un ensemble minimum d’attributs tel qu’il n’existe pas deux occurrences du TE (TA) qui ont la même valeurs pour ces attributs.

Un TE (TA) peut avoir plusieurs clés.

Exemple : n°employé et (nom+prénoms) sont deux clés du TE Employé, si dans cette entreprise il

n’y a jamais deux employés ayant les mêmes noms et prénoms.

Une clé peut être désignée sur un diagramme en la soulignant.

Clé d’un TA

Nom

....

Sexe

Etat-civil

0:1

Epoux

date

Mariage
Mariage
Le modèle Entité-Association 23 Exemple : nom, prénoms attribut facultatif : un attribut qui peut ne
Personne
Personne
Epouse
Epouse

0:1

Exemple : une occurrence du TA mariage est un triplet :

Si l’on admet

< un époux, une épouse, une date> que l’attribut nom est la clé de Personne, la clé de mariage est : époux.nom, ou

épouse.nom.

Cette définition n’est valable que si la population du TA Mariage ne contient que les mariages en cours (on ne garde pas l’historique). si le TA mariage conservait l’historique (les mariages passés),

les connectivités des deux rôles seraient 0,n et la clé du TA serait :

époux.nom + date ou épouse.nom + date

car il n’est pas exclu que les deux mêmes personnes se remarient une deuxième fois après avoir divorcé.

Un TA dont tous les rôles ont une connectivité maximum supérieure à 1, a, en général, une clé

constituée de l’ensemble des clés des TE liés.

Exemple : soit un TA Contrôle, avec une occurrence (donc une moyenne, et un ensemble de notes) par étudiant et par matière suivie.

24
24

Cours Bases de Données

 

1,n

Contrôle
Contrôle

1,n

   

Etudiant

   

Matière

N°carte

Notes

Moyenne

Coef

NumMat

En supposant que les clés de TE soient comme indiqué sur le diagramme, la clé du TA Contrôle est :

Etudiant.N°carte + Matière.NumMat

Néanmoins, il n’est pas toujours vrai que la clé d’un TA soit constitué de l’ensemble des clés des TE

liés. Si l’un des rôles du TA a une connectivité maximum égale à 1, la clé du TE associé à ce rôle est

une clé du TA. Exemple : soit le TA suivant :

   

NomA

 

1,n

 
Assure
Assure
 
 

0,n

1,1

 

Personne

   

Voiture

NomP

NumV

La clé du TA Assure n'est pas Personne.NomP + CieAssurance.NomA + Voiture.NumV

car ce triplet ne constitue pas un ensemble minimal. En effet, l’attribut Voiture.NumV suffit à lui seul, pour identifier une occurrence d’Assure. Ceci est dû à la connectivité 1,1 du rôle de Voiture dans le TA, qui garantit que pour une valeur de numV il n’y aura jamais qu’une seule occurrence d’Assure avec cette valeur de NumV.

Règle : si le TA a une connectivité maximum égale à 1 pour un de TE liés, alors toute clé de ce TE est une clé du TA

Une autre règle peut être établie pour les cas où plusieurs occurrences du TA lient les mêmes occurrences de TE. Dans l’exemple ci-dessous, plusieurs commandes peuvent être passées par un même client pour un même produit à des dates différentes. Dans ce cas l’identifiant de TA contient au moins un attribut du TA.

0,n 0,n Produit Commande Client N°produit N°commande N°client Date Quantité
0,n
0,n
Produit
Commande
Client
N°produit
N°commande
N°client
Date
Quantité

Le TA Commande a ici deux clés :

N°produit + N°client + Date ou N°commande

Clé d’un TE faible

Un TE faible est un TE dont aucun sous-ensemble d’attributs ne constitue une clé (il n’y a pas de clé qui lui soit interne), et qui est lié par un TA binaire de connectivité (1,1) à un autre TE dont il dépend.

Dans l’exemple ci-dessous, Exemplaire (qui représente un exemplaire d’un livre) est un TE faible (N° ex n’est pas une clé) dépendant du TE Livre.

Le modèle Entité-Association

25
25
 

1:n

est un
est un

1:1

 

Livre

   

Exemplaire

ISBN

Titre

N°ex

Etat

La clé d’un TE faible (qui est la même que celle du TA) est constituée de la clé du TE dont il dépend et d’un (ou plusieurs) attribut du TE faible.

La clé de Exemplaire (et de « est un ») est

: ISBN + N°ex

Clé d'un TE sous-type

Soit E un TE sous-type d'un TE E', alors tout identifiant de E' est aussi clé de E. E n'a pas nécessairement de clé qui lui soit propre. Dans l'exemple déjà cité du supermarché, Article Alimentaire, Article Hi-Fi et Article Habillement ont tous trois comme clé la clé de Article.

C O N T R A I N T E S

D I N T E G R I T E

Les concepts d’entité, d’association, attribut et sous-type ne suffisent pas à décrire tout ce qui caractérise les données d’un schéma EA.

Soit, par exemple, le diagramme suivant :

0:1

Epoux date Nom .... Sexe Personne Mariage Etat-civil Epouse
Epoux
date
Nom
....
Sexe
Personne
Mariage
Etat-civil
Epouse

0:1

Une règle connue mais non exprimée par ce diagramme est : si une personne participe à l’association Mariage, alors son état civil doit être « marié ».

En l’état actuel des SGBD, ces règles ne peuvent être vérifiées que par des programmes ad hoc, établis lors de la programmation des applications.

D’autres règles possibles s’appliquant à cet exemple sont :

si une personne participe à l’association Mariage, dans le rôle « époux », alors son sexe doit être

‘M’; si une personne participe à l’association Mariage, dans le rôle « épouse », alors son sexe doit être ‘F’;

De telles règles, définissant les états possibles de la base de données et qui peuvent ne pas être décrites avec les concepts du modèle, sont appelées contraintes d’intégrité. Si les valeurs de la base de données ne les satisfont pas, il y a une « erreur » dans la base; on dit qu’elle est incohérente.

26
26

Cours Bases de Données

Contraintes d'intégrité sur les attributs

Les contraintes d’intégrité les plus fréquentes limitent les valeurs possibles d’un attribut à certaines

valeurs du domaine sous-jacent.

Dans le cas le plus simple, elles sont du type : age[0,130].

Il s’agit ici d’une limitation définissant de façon fixe une fourchette pour toutes les valeurs de l’attribut.

Ces contraintes disparaissent si le modèle permet une définition précise des domaines de valeurs.

Les limitations peuvent être définies en fonction du contexte (valeur d’un autre attribut, participation à une association, ) ...

Exemples :

si mois[4,6,9,11] alors jour[1,30], sinon si mois=2 alors jour[1,29] sinon jour[1,31] état-civil = « marié » si ....

une femme marié avant 1986 a pour premier nom, le nom de son mari, une femme mariée après 1986 a pour premier nom son nom de jeune fille.

Contraintes d'intégrité sur les cardinalités

D’autres types de contraintes d’intégrité limitent les cardinalités des TE, des TA, des rôles des TA, ou

des valeurs des attributs.

Exemples : On suppose, dans le diagramme Parent-Enfant, que les attributs du type d’entité Parent sont les suivants : nom, prenoms, adresse, nombre-enfants. Il existe la contrainte d’intégrité :

nombre-enfants = nombre d’occurrences du TA « est parent de » qui lient ce Parent.

Contraintes d'intégrité sur les généralisations / spécialisations

Dans une hiérarchie de généralisation / spécialisation, il est fréquent de trouver des contraintes d'intégrité décrivant le partage de population entre les différents sous-types d'un même sur-type :

Contrainte de couverture pour spécifier que l'union des populations des TE spécifiques d'un même TE générique est égale à la population du TE générique.

Contrainte de disjonction, pour spécifier que les populations des TE spécifiques d'un même TE générique n'ont aucune occurrence en commun.

Contrainte de partition, pour spécifier que la population d'un TE générique se subdivise complètement et sans intersection entre certains de ses TE spécifiques.

C O N C L U S I O N

Un schéma conceptuel ENTITE / ASSOCIATION est un ensemble de descriptions de types d'entités et de types d'associations, de leur attributs, des liens de spécialisation / généralisation entre types d'entités et des contraintes d'intégrité associées.

EA = ( {TE} , {TA} , {CI} )

Le modèle Objet

27
27

3. Le modèle Objet

C O N C E P T

D E

B A S E

O B J E T

E T

S C H E M A S

UML

Objet :

Objet du monde réel (concret ou abstrait), à propos duquel on veut enregistrer des informations et qui a une existence propre. Un objet existe indépendamment du fait qu’il est liée à d’autres objets de la base de données. Le modèle objet est intéressant en ce qu’il permet de décrire simplement les objets du

monde réel et de les gérer sous une forme « naturelle » dans laquelle les données et les procédures les manipulant sont regroupées dans une même unité sémantique.

L’objet se caractérise par sa structure (les valeurs portées par les attributs), son comportement (sa façon d’agir ou de réagir) et les liens qu’il partage avec d’autres objets, grâce à son identifiant unique (OID).

CONSTRUCTEUR :BOITE :MOTEUR :VOITURE
CONSTRUCTEUR
:BOITE
:MOTEUR
:VOITURE
CONSTRUCTEUR :BOITE :MOTEUR :VOITURE Entité MONDE REEL ABSTRACTION ABSTRACTION VENDEUR :VOITURE Object ABSTRACTION : MODELE

Entité

MONDE REEL
MONDE REEL
ABSTRACTION ABSTRACTION
ABSTRACTION
ABSTRACTION
VENDEUR :VOITURE Object ABSTRACTION : MODELE
VENDEUR
:VOITURE
Object
ABSTRACTION : MODELE

Encapsulation

L’encapsulation est le fait de regrouper dans un seul élément des attributs (données) et des opérations (fonctions, méthodes, comportements …).

L’encapsulation est un principe de l’approche objet grâce auquel les données et les comportements associés de l’objet sont cachés (partie privée) pour ne laisser visible que leur interface (partie publique).

Le fonctionnement interne de l’objet est ainsi caché des autres parties du programme qui utilisent cet

objet.

28
28

Cours Bases de Données

:VOITURE (V1.0)

:Conducteur

:VOITURE (V1.1)

Prendre Prendre de Rouler de Rouler l'essence l'essence Niveau Niveau Compteur Compteur essence essence Niveau huile
Prendre
Prendre
de
Rouler
de
Rouler
l'essence
l'essence
Niveau
Niveau
Compteur
Compteur
essence
essence
Niveau huile
Interface : Propriétés
Implémentation :
accessibles par
Propriétés masquées,
d'autres objets
accessibles seulement

par l'objet

En s’intéressant plus aux interfaces qu’au fonctionnement interne de l’objet, l’encapsulation

permet de réaliser des modules indépendants les uns des autres.

Le masquage des informations permet de protéger l’objet contre des modifications indésirables.

l’encapsulation permet de modifier l’implémentation de l’objet (son fonctionnement interne) sans affecter les autres objets qui l’utilisent.

Classes

Une classe est une représentation abstraite d’un concept qui existe dans le domaine modélisé.

Monde réel Modèle : classe VOITURE + / Compteur + / Niveau essence + / Niveau
Monde réel
Modèle : classe
VOITURE
+ / Compteur
+ / Niveau essence
+ / Niveau huile
...
}
attributs
Rouler
Prendre essence
}
opérations
Vendre
...

Les concepts d’objet et de classe sont indépendants. Un objet existe en tant qu’instance (membre) d’une

classe. La classe décrit des objets qui partagent le même comportement (opérations) et les mêmes attributs (donnés).

La classe décrit une liste de relations (associations) que les objets pourront partager avec d’autres objets.

Les valeurs portées par les attributs de l’objet caractérisent ce dernier.

Diagramme des classes

La représentation graphique utilisée avec la méthode objet pour mettre en évidence la structure des classes et les différents liens d’associations entre les classes est le diagramme des classes UML. A la différence d’autres modélisations (entité-association, ou Merise), le diagramme des classes ne fait

Le modèle Objet

29
29

aucune séparation entre la modélisation des données et des traitements éventuels qui pourront

s’appliquer sur ces données.

L’objet d’une classe est une instance. L’instanciation est le mécanisme qui permet de créer les objets d’une classe. Le système est constitué des classes et de leurs associations.

Les objets de base du modèle sont la classe, l’association et la classe d’association.

Classe Banque Association Rôle Manager Compagnie managée 1 0 .. 1 Personne Compagnie + / estMarié
Classe
Banque
Association
Rôle
Manager
Compagnie managée
1
0
..
1
Personne
Compagnie
+ / estMarié : bool
+ / nom : chaîne
+ / estEmployé : bool
+ / nombreEmployés: entier
Mari
Employés
Employeur
+ / nom : chaîne
0
..
1
+ prixAction : entier
+ / prénom : chaîne
*
*
+ / sexe : énumération(M,F)
age () : entier
revenu(Date) : entier
Epouse
Emploi
0
..
1
Attribut
+ titre : chaîne
+ dateDébut: date
Opération
+ salaire : entier
Mariage
+ lieu : chaîne
+ date: date

Modélisation des associations

Classe

d'association

Les liens de multiplicité indiquent combien d’objets de chaque classe peuvent être liés à un objet de l’autre classe. Les multiplicités les plus usuelles sont :

1

1

ou 1 : un et un seul

0

1

: de zéro à un

0

*

ou *

: de zéro (aucun) à n (plusieurs).

1 ..

*

: de 1 (obligatoire) à n (plusieurs).

X

Y

: de X à Y (cas rare …)

La sémantique d’une association peut être exprimée le cas échéant par le rôle joué par chaque classe dans l’association :

 

Propriétaire

Propriété

*

Personne

0 1 ..

 

...

 

...

 
30
30

Cours Bases de Données

La navigation précise le sens dans lequel une association peut être parcourue. Par défaut, la navigation est possible dans les deux sens. Lorsqu’elle n’est possible que dans un seul sens, celui ci est indiqué par

une flèche.

 

Pays

Pays Personne
 

Personne

 

...

 

...

...

 

L’agrégation est une forme particulière d’association entre classes dans laquelle des objets complexes (agrégats) sont construits à partir d’objets élémentaires (composants). Chacun des composants pourrait exister sans l’agrégat.

Véhicule Agrégat ... Agrégation Composant 0 1 .. 0 .. 1 0 .. 1 0 ..
Véhicule
Agrégat
...
Agrégation
Composant
0 1 ..
0
..
1
0
..
1
0
..
4
Moteur
Chassis
Roue
...
...
...

La composition est une agrégation qui spécifie une forte relation de propriété. Le composant ne peut appartenir qu’à un seul agrégat à un instant donné. Le composant ne peut pas exister indépendamment de l’agrégat.

La composition impose des contraintes sur le cycle de vie des composants : les composants peuvent être

crées et retirés avant la destruction de l’agrégat, mais si l’agrégat est détruit, alors tous les composants le

sont aussi.

Personne Agrégat ... Composition Composant 1 0 .. 2 0 .. 2 1 Bras Jambes Tête
Personne
Agrégat
...
Composition
Composant
1
0
..
2
0
..
2
1
Bras
Jambes
Tête
...
...
...

On remarquera qu’alors que l’agrégation (relation plutôt « faible » entre classes) est symbolisée par un losange vide, la composition (relation « forte ») est symbolisée par un losange plein.

Le modèle Objet

31
31

L’héritage permet au modèle de « factoriser » des attributs et / ou des comportements communs à différentes classes. Une classe « généraliste » agit alors comme ancêtre commun à plusieurs classes, qui

sont des variations de la classe ancêtre. L ‘héritage est essentiellement un moyen de gérer la complexité et la réutilisation de ce qui est déjà écrit. On verra qu’il pose un problème pour la modélisation des données, le modèle relationnel ne disposant d’aucun moyen simple de le gérer.

La représentation commune de l’héritage dans un langage de programmation est basée sur des pointeurs ou éventuellement des OID (Object ID : identifiant d’objet).

Chaque objet maintient une forme de lien avec lequel il peut localiser, ou recréer si nécessaire l’objet parent.

Insistons sur le fait que l’héritage est une

notion bien plus complexe que cette présentation trop sommaire. Le lecteur se reportera à la bibliographie pour réfléchir aux différents cas de modélisation de

Personne ... une classe généraliste (Personne) de laquelle les autres classes (Parent et Enfant) sont dérivées.
Personne
...
une classe généraliste
(Personne) de laquelle les
autres classes (Parent et
Enfant) sont dérivées.
Parent
Enfant
...
...

l’héritage (héritage multiple, problèmes liés à la covariance, aux différents choix de placement possibles des classes dans la hiérarchie, …).

32
32

Cours Bases de Données

D E F I N I T I O N

D U N E

R E L A T I O N

4. Le Modèle Relationnel

Une relation est un sous ensemble du produit cartésien d’une liste de domaines (ensembles de valeurs ou encore, types au sens des langages de programmation).

Le nombre de domaines de la relation est son arité. Elle est représentée sous la forme d’une table, où les lignes correspondent aux tuples, et les colonnes aux composantes.

Exemple :

 
  • 136 Dupont

Jean

19

  • 253 Aubry

Annie

20

  • 101 Duval

André

20

  • 147 Dupont

Marc

21

Cet exemple représente une relation (ou table) décrivant des étudiants. La première et la dernière colonne ont pour domaine les entiers et les deux autres les chaînes de caractères.

La population d'une relation est constituée de l'ensemble des tuples (lignes) de la relation. Contrairement à ce que la représentation sous forme de table pourrait induire, il n'y a pas d'ordre (les nouveaux tuples sont rajoutés à la fin)

On donne un nom différent à chaque colonne, pour les distinguer. On appelle attribut d’une relation un couple <nom, domaine>, et schéma de la relation, le nom de la relation suivi de la liste de ses attributs.

Exemple : la relation ci-dessus a pour schéma :

Etudiant ( N°Etud : entier; Nom : Chaîne(30); Prénom : Chaîne(20); Age : entier(0 120);)

..

Pour simplifier, nous omettrons en général les domaines; ils sont déduits implicitement des noms des attributs.

Il est usuel de souligner l’attribut, ou les attributs, qui constitue(nt) la clé de la relation. Si un attribut est une clé d’une autre relation, il est appelé clé externe.

Notion de domaine

Un domaine est un ensemble nommé de valeurs que peut prendre un attribut. C'est le domaine de définition d'un ou plusieurs attributs.

Exemple :

Dnom : chaînes de caractères de longueur 30.

Dnum : entiers entre 0 et 99999

Dcouleurs : "bleu", "vert", "jaune"

Le Modèle Relationnel

33
33

Cette notion de domaine, proche de la notion de type de données en programmation, est importante

lorsqu’elle peut être contrôlée par le SGBD utilisé. Elle permet alors de renforcer les contraintes

d'intégrité à respecter par la base de manière automatique. Le SGBD refusera ainsi automatiquement l'entrée d'une donnée qui n'est pas "bien formée" pour le domaine, ce qui diminue d'autant les contrôles de cohérences à réaliser par le programmeur.

D E S

S C H E M A S

EA

A U X

S C H E M A S

R E L A T I O N N E L S

Les attributs du modèle relationnel sont tous simples et monovalués; toute valeur prise par un attribut est atomique (non décomposable par le SGBD) et unique. Les notions d'attributs complexes, multivalués ou facultatifs n'existent pas dans ce modèle.

Partant d’un schéma entité-association, on peut construire un ensemble de schémas de relations. L’idée consiste à représenter les types d’entités et leurs attributs par une relation, chaque tuple de la relation étant associée à une entité. Les types d’associations sont également transformés en relations constituées, en général, des clés des types d’entités associés, complétés par les attributs de l’association, si elle en a.

Exemple :

Etudiant

 

N°Etud

Nom

Prénom

Age

 

136

Dupont

Jean

 

19

253

Aubry

Annie

20

101

Duval

André

20

 

Cours

 

NomC

Horaire

Prof

   
 

Algo

Lundi 10-12

Duval

 

Système

Mardi 16-18

Malin

 

Suit

N°Etud

NomC

Note

 
  • 253 Algo

12

  • 136 Système

08

  • 253 Système

15

On remarque que la relation « Suit » (qui traduit un type d’association) a pour attributs les clés des deux précédentes relations (qui traduisent des types d’entités) et l’attribut de l’association.

Quelques règles :

Constitution de la relation :

La relation associée à un TA est constituée des clés des TE associés, et de ses propres attributs.

Si un TE est faible (sans clé) il faut y mettre l’ensemble de ses attributs.

La clé de la relation :

En général, elle est constituée par l’ensemble des clés des TE associés.

Lorsqu’il y a un TE faible, il faut ajouter un attribut du TE,

Lorsqu’il y a plusieurs jeux de valeurs possibles pour un même ensemble de valeur sur les clés externes,

il faut ajouter un des attributs du TA.

Lorsque la connectivité d’un des rôles est 1:1, la clé est celle du TE (non faible) associé.

34
34

Cours Bases de Données

Attributs facultatifs du modèle EA :

La plupart des SGBDR gèrent une valeur spéciale, appelée valeur nulle et notée NULL. Cette valeur peut être prise par tout attribut (sauf si dans le schéma on a spécifié le contraire). Elle signifie alors que le tuple n'a pas de valeur pour cet attribut. Ainsi un étudiant dont on ne connaît pas l'âge serait représenté par le tuple (123, DUMOND, NULL).

Cette valeur spéciale implique souvent un traitement particulier dans les langages de manipulation de données et dans les programmes.

Attributs complexes du modèle EA :

L'exemple classique est l'attribut adresse : N° rue, Nom Rue, Ville, Code Postal.

Solution 1 : On utilise l'attribut adresse avec pour domaine les chaînes de caractères. Dans ce cas, l'utilisateur devra lire l'adresse et chercher lui même le nom de la ville dans celle ci. Il ne pourra pas poser de question au SGBD concernant la ville.

Solution 2 : On scinde l'adresse en 4 attributs : N° rue, Nom Rue, Ville, Code Postal… Dans ce cas, le SGBD est capable de recherche élaborées sur chacun des attributs, mais il ne connaît pas la notion d'adresse globale. Pour éditer une étiquette par exemple, on est obligé de réaliser des concaténations.

Attributs multivalués du modèle EA :

L'exemple classique est la liste des prénoms

Solution 1 : Avoir dans la relation Etudiants plusieurs attributs : Prénom1, Prénom2, … Mais combien mettre d'attributs de prénom ? Et comment poser une question sur un prénom (on est obligé de poser autant de questions que d'attributs déclarés).

Solution 2 : On garde dans la relation étudiant uniquement le n° d'étudiant, le nom et l'age et on crée une relation supplémentaire (n° étudiant, prénom).

(Reprendre les exemples du chapitre 2)

L A

N O T I O N

D E

S C H E M A

D E

R E L A T I O N

Le schéma d’une relation donne la signification ou l’interprétation de la relation. Elle est constituée d’un ensemble de tuples vérifiants une certaine sémantique. Les valeurs d’un tuple doivent en général vérifier un certain nombre de contraintes.

Un schéma de relation est défini par :

- son nom

- la liste de ses attributs : couples (nom:domaine)

- sa (ses) clé(s) et ses clés externes

- sa définition (phrase en français)

- la liste des contraintes

Parmi les contraintes que peut imposer un schéma relationnel, les dépendances fonctionnelles sont une catégorie importante, car elles sont liées à la notion intuitive de clé.

Définition : Soit R(A 1 , A 2 ,

...

,A

n ) un schéma de relation, et X et Y deux sous ensembles de {A 1 , A 2 ,

...

,A

n },

on dit qu’il a dépendance fonctionnelle de Y sur X, et on écrit XY, si quel que soit un exemplaire acceptable r de R, tous les tuples u et v de r qui ont les mêmes composantes dans X, ont aussi les mêmes composantes dans Y.

Le Modèle Relationnel

35
35

Une dépendance fonctionnelle est une propriété imposée à priori, provenant du monde réel, et qui doit

être définie à partir de la signification des attributs. Il ne faut pas tenir compte des dépendances

constatées sur un exemplaire particulier de la relation.

Exemple :

La relation Etudiant :

N°Etud(Nom, Prénom, Age)

La relation Cours :

NomC(Horaire, Prof)

La relation Suit :

(N°Etud, NomC) Note; un étudiant a une note par cours.

Il est évident que la notion de clé d’une relation entraîne la dépendance de tous les attributs de la

relation sur la clé. Inversement, la notion de dépendance permet de préciser cette notion de clé.

Définition : Soit R(A 1 , A 2 ,

...

,A

que X est une clé pour R si :

n ) un schéma de relation, et X un sous ensemble de {A 1 , A 2 ,

...

,A

n }. On dit

1- XA 1 A 2

...

A n ;

2- YX, si YA 1 A 2 ...

A

n , alors X=Y.

Lorsqu’il y a plusieurs clés possibles pour une relation, on peut en choisir une, dite clé primaire, les

autres étant des clés candidates.

Une clé peut être composée de un ou plusieurs attributs. Une relation peut avoir une ou plusieurs clés.

Une relation a nécessairement une clé. Par convention, l'attribut (ou les attributs) constituant la clé est

souligné sur les schémas graphiques.

Exemple :

Etudiant (N° Etud, nom, prénom, age)

Il n'y a pas deux étudiants qui peuvent avoir le même numéro

On ne peut pas avoir de valeur inconnue pour une clé. En effet si on entrait deux tuples sans valeur

pour la clé, alors il existerait deux tuples ayant même valeur (inconnue) pour la clé, ce qui est impossible

d'après la définition de la clé.

Si les dépendances liées aux clés sont naturelles, les autres conduisent à quelques difficultés. pour les

éviter, il faut pouvoir transformer un ensemble de relations, tout en conservant les dépendances

fonctionnelles, puisqu’il s’agit de contraintes vérifiées par le monde réel.

On appellera schéma relationnel, un ensemble de schémas de relations et son ensemble de contraintes

d’intégrité.

CLE EXTERN E (OU CLE

ETRANG ERE )

Certains attributs référencent des tuples d’une autre relation (ou parfois la même); c’est-à-dire que leur

valeur est nécessairement égale à celle de la clé d’un tuple existant dans l’autre relation.

Par exemple, la relation Suit(NomC, N°Etud, Note) possède une clé (NomC+N°Etud), et deux clés

externes : NomC et N°Etud. En effet, NomC ‘référence’ un Cours, c’est à dire que si une valeur

NomC existe dans Suit, alors il doit nécessairement exister un cours de ce nom là dans la relation

Cours. de même, N°etud ‘référence’ un Etudiant.

36
36

Cours Bases de Données

Le schéma d’une relation comprend donc, en plus de la définition du nom de la relation et de ses

attributs et domaines associés, la définition de de sa (ses) clé(s), et celle de ses clés externes, s’il en existe.

Les clés externes sont déclarées de la façon suivante :

Suit(N°etud ; Dnum, NomC : Dnom)

Clés externes :

N°Etud référence un Etudiant

NomC référence un Cours

Définition : Soient deux relations R1(X, Y) et R2(V, W), où X, Y, V, W, désignent des attributs ou des

ensembles d’attributs, et où X est la clé de R1, on dit que W est une clé externe sur R1 (ou que W

référence R1) si pour tout tuple de R2, la valeur prise par W est nécessairement la valeur de X pour un

tuple existant de R1.

Autrement dit, à tout instant, l’ensemble des valeurs prises par W est compris dans l’ensemble des

valeurs prises par X.

Cette vérification est automatiquement assurée par le SGBD : une fois déclarée la clé externe W de R2

sur R1, le SGBD vérifie toutes les insertions dans R2 (il vérifie que la valeur de W existe dans R1); il

vérifie de la même façon les modifications de W. Il vérifie toutes les suppressions de tuples de R1 (il

vérifie qu’il n’existe pas de tuple dans R2 référencant ce tuple à supprimer). Le SGBD assure ainsi, l’intégrité de

référence (ou intégrité référentielle) de la base de données.

E X E M P L E

D E

D E C L A R A T I O N

D U N

S C H E M A

R E L A T I O N N E L

Domaines :

Dnom : chaîne de caractères de longueur inférieure à 30;

Dch100 : chaînes de caractères de longueur inférieure à 100;

Dannée : [1970:1990];

Dnote : [0.0:20.0];

Ddate : [1:31]/[1:12]/[1920:2000];

Nous ne ferons apparaître que les DF non triviales.

Relation : Personne

Attributs :

N°P : entier sans valeur nulle;

Nom : Dnom sans valeur nulle;

Prénom : Dnom sans valeur nulle;

Adr : Dch100 sans valeur nulle;

Clé : (N°P)

Définition : Tout étudiant et tout enseignant de la composante.

Le Modèle Relationnel

37
37

Relation : Etudiant

Attributs :

N°P : entier sans valeur nulle;

N°E : entier sans valeur nulle;

DateN : Ddate sans valeur nulle;

Clés : (N°E), (N°P);

Clés externe : N°P référence une Personne;

Définition : Tout individu qui est actuellement inscrit dans la composante, ou qui a déjà passé avec

succès un des cours de la comosante;

Relation : EtudiantEtudes

Attributs :

N°E : entier sans valeur nulle;

Année : Dannée sans valeur nulle;

Diplôme : Dnom sans valeur nulle;

Clé : (N°E+Année);

Clé externe : N°E référence un Etudiant;

Définition : études antérieures d’un étudiant;

Relation : Enseignant

Attributs :

N°P : entier sans valeur nulle;

Statut : Dnom sans valeur nulle;

Département : Dnom sans valeur nulle;

Clé : (N°P)

Clé externe : N°P référence une Personne;

Définition : tout individu assurant actuellement un ou plusieurs cours dans la composante;

38
38

Cours Bases de Données

Relation : Inscrit

Types d’entités liés : Etudiant (0:n), Cours (1:n);

Attributs :

N°E : entier sans valeur nulle;

NomC : Dnom sans valeur nulle;

Note : Dnote;

Clé : (N°E+NomC)

Clés externes :

N°E référence un Etudiant

NomC référence un Cours;

Définition : actuellement, l’étudiant N°E est inscrit au cours NomC;

Relation : Prérequis

Types d’entités liés : Cours : est-un (0:n), Cours : a-pour (0,n);

Attributs :

NomC : Dnom sans valeur nulle;

NomCprérequis : Dnom sans valeur nulle;

Clé : (NomC+NomCprérequis)

Clés externes :

NomC référence un Cours;

NomCprérequis référence un Cours;

Définition : le cours NomCprérequis est un prérequis pour le cours NomC.

Normalisation d’un schéma relationnel

39
39

5. Normalisation dun schéma relationnel

F O R M E S

NO R M A L E S

PREMIERE ET DEUXIEME FORMES NORMALES

Définition : Une relation est en première forme normale (1FN) si tous ses attributs sont simples et

monovalués.

Définition : Une relation est en deuxième forme normale (2FN) si elle est en première forme normale et

si chaque attribut qui ne fait pas partie d’une clé dépend d’une clé entière.

Pour une relation R munie de l’ensemble de df F, on a

AClé (AClé (Clé) CléAF + )

Exemple : Soit une relation qui est en 1FN, mais pas en 2FN :

Fournisseur1 (NF, Adr, Tel, NomProduit, Prix)

Une telle relation pose des problèmes :

Redondances : s’il existe 100 produits pour un fournisseur on va répéter 100 fois le nom,

l’adresse et le téléphone du fournisseur.

Problème de mise à jour pour les insertions : quand on veut rajouter un produit, il faut

rentrer à nouveau l’adresse et le téléphone du fournisseur.

Problème pour les suppressions : si on supprime (momentanément) la liste des produits

d’un fournisseur, alors on supprime aussi le fournisseur.

Problème de mise à jour des tuples : si un fournisseur change d’adresse ou de téléphone, il

faut faire cette mise à jour sur tous les 100 tuples !

Cette relation n’est pas en 2FN. Le graphe minimum des df de Fournisseur 1 est :

NomProduit Prix NF Adr Tel
NomProduit
Prix
NF Adr
Tel

On décompose Fournisseur1 en deux relations de la façon suivante : pour chaque source de DF, on

crée une relation ayant pour attributs la source et tous les attributs des dF directes de cette source,

en s’assurant qu’une (au moins) des deux sources est entièrement contenue dans les attributs

communs aux deux relations ainsi créées (cf théorème de Heath). On obtient ainsi :

Fournisseur(NF, Adr, Tel);

Catalogue(NF, NomProduit, Prix);

qui sont en 2FN (et même plus).

Cette décomposition est

sans perte d’information

sans perte de dépendance fonctionnelle : les

DF sont soit dans

l’une ou

l’autre des

deux

relations.

40
40

Cours Bases de Données

TROISIEME FORME NORMALE

Définition : Une relation est en troisième forme normale si elle est en première forme normale et si

chaque attribut qui ne fait pas partie d’une clé, dépend directement d’une clé entière.

Pour une relation R muni de l’ensemble de df F, on a :

AClé (AClé  Clé (Clé