Telechargé par focus159

CONCEPTION Support de cours n 3 DE BASES DE DONNEES

publicité
CONCEPTION
DE BASES DE DONNEES
Support de cours n°3
Auteur: Raymonde RICHARD
PRCE – UBO
Page
PARTIE III. - LA DESCRIPTION LOGIQUE ET PHYSIQUE DES
DONNEES ...................................................................................... 2
A.
1.
2.
3.
4.
5.
6.
7.
Les concepts du modèle relationnel de données ........................................ 2
La relation (ou table) ......................................................................................................... 2
La relation universelle: ...................................................................................................... 2
La relation normalisée: ...................................................................................................... 2
La clé primaire .................................................................................................................. 3
La clé étrangère................................................................................................................. 3
La clé candidate ................................................................................................................ 3
Les clés secondaires .......................................................................................................... 3
B.
Le modèle relationnel................................................................................... 3
C.
Les règles de passage du MCD au MRD (ou MLD) ................................... 7
D.
, Le modèle physique de données................................................................. 8
E.
Conclusion sur la modèlisation des données............................................... 8
R. Richard - UBO
Conception de bases de données (Partie3)
1
PARTIE III. -
LA DESCRIPTION LOGIQUE ET PHYSIQUE DES
DONNEES
Les modèles conceptuels et organisationnels ont permis une bonne représentation des données
indépendamment des choix techniques.
Aujourd'hui, l'orientation technique la plus utilisée se tourne vers l'utilisation de bases de données
relationnelles.
Il existe d'autres types de bases de données (hiérarchiques ou réseau par exemple) qui sont
désormais obsolètes: en conséquence, sera uniquement étudié le modèle logique de données
relationnel qu'on peut encore appeler modèle relationnel de données (MRD) pour simplifier.
A. Les concepts du modèle relationnel de données
1. La relation (ou table)
Une relation représente un ensemble de données et sa description peut prendre la forme d'un
tableau dont les colonnes contiennent les valeurs prises par les attributs et les lignes représentent les
occurrences de la relation (ou tuples).
La relation s'écrit:
CIRCUITS(Code Circuit, Nom Circuit, Nom Pays, Organisateur Circuit, Tracé Circuit)
Nb: un relation peut être appelée aussi table dans la mesure où , au niveau physique de données,
une relation sera systématiquement représentée par un table.
2. La relation universelle:
Un système d'information pourrait être, a priori, mémorisé dans une seule relation qui présenterait
tous les attributs répertoriés dans le système (voir page suivante: Résultats F1 2005)
On constate alors que ce système est loin d'être optimal dans la mesure où de nombreuses données
sont redondantes. (ex: Date Course, Nationalité Pilote…)
3. La relation normalisée:
L'étude des dépendances fonctionnelles permet d'aboutir à une répartition des attributs dans
différentes relations dites normalisées idéales pour le système d'information puisqu'il n'y a plus de
redondance assurant ainsi une meilleure intégrité des données.
La relation normalisée est une relation qui ne comprend que des attributs simples tous dépendants
directement de l'identifiant de la relation.
La relation CIRCUITS (§1) est une relation normalisée.
R. Richard - UBO
Conception de bases de données (Partie3)
2
Ci-dessous, la relation RESULTATS COURSES(N° Course, Date , Nom Course, Code Circuit,
Nom Circuit, Tours, Longueur Tour, Classement, Code Pilote, Nom Pilote, Nationalité Pilote,
Abandon, Points attribués) , qui mémorise les résultats des pilotes à chaque Grand Prix de F1 pour
la saison 2005 est un exemple de relation universelle.
4. La clé primaire
La clé primaire de la relation est constituée par un ou plusieurs attributs afin de permettre
d'identifier chaque ligne de la relation. (Relation CIRCUITS: Code Circuit)
5. La clé étrangère
On appellera clé étrangère dans une relation un attribut qui est également clé primaire dans une
autre relation
6. La clé candidate
On appellera clé candidate un attribut qui n'est pas clé primaire mais qui est également apte à
assurer l'unicité d'une ligne. . (Relation CIRCUITS: Nom Pays)
7. Les clés secondaires
Elles correspondent aux attributs qui seront couramment sollicités pour effectuer des recherche
(opération de sélection) et sur lesquels, en conséquence, on créera un index (niveau physique) pour
faciliter ces consultations.
B. Le modèle relationnel
Une autre méthode de conception, appelé modèle relationnel, préconise l'élaboration d'une matrice
des dépendances fonctionnelles ou encore d'un graphe des dépendances fonctionnelles. L'avantage
principal de cette méthode est d'aboutir directement à la définition de relations normalisées adaptées
directement à la mise en place de la structure d'une base de données relationnelle.
R. Richard - UBO
Conception de bases de données (Partie3)
3
Résultats F1 Saison 2005.
Le SI, à mettre en œuvre, a pour objectif de déterminer le classement final des pilotes en fin de la
saison. Ce classement se détermine en accumulant les points obtenus par chaque pilote à chaque
grand prix.
a) Elaboration du dictionnaire de données
Il s'agit de définir tous les données qu'il faut prendre en considération afin d'abouir à l'objectif final:
dans notre exemple, pour simplifier la démarche, on se limitera à la liste des données présentée dans
la relation universelle précédente.
N° Course
Date
Nom Course
Code Circuit
Nom Circuit
Tours
Longueur Tour
Classement
Code Pilote
Nom Pilote
Nationalité Pilote
Abandon
Points attribués
b) Etude des dépendances fonctionnelles
Par observation de la relation universelle, on peut déduire principalement les DF suivantes:
N° Course
N° Course
N° Course
N° Course
N° Course
N° Course
Code Circuit
Code Pilote
Code Pilote
N° Course, Code Pilote
N° Course, Code Pilote
N° Course, Code Pilote
Classement
è
è
è
è
è
è
è
è
è
è
è
è
è
Date
Nom Course
Code Circuit
Nom Circuit
Tours
Longueur Tour
Nom Circuit
Nom Pilote
Nationalité Pilote
Classement
Abandon
Points attribués
Points attribués
Cependant, certaines DF ne sont pas directes dan la mesure où elles peuvent être remplacées par au
moins de 2 autres DF.
Ainsi, DF suivante:
N° Course
est équivalente à:
N° Course
Et la DF:
N° Course, Code Pilote
è
Nom Circuit
è
Code Circuit
è
Points attribués
è
Classement
è
Nom Circuit
è
Points attribués
est équivalente à:
N° Course, Code Pilote
R. Richard - UBO
Conception de bases de données (Partie3)
4
c) Le graphe des DF
En retenant uniquement les DF directes, le graphe des DF permet de mettre en évidence les
relations normalisées équivalentes à la relation universelles initiale.
N° Course, Code Pilote
Date
Nom
Course
Code Circuit
Tours
Nom Circuit
Longueur
Tour
Nom Pilote
Classement
Nationalité
Pilote
Abandon
Points attribués
En regroupant les DF partant des mêmes propriétés dans un même cadre, le graphe met en évidence,
dans le modèle relationnel final 5 relations normalisées:
COURSES (N° Course, Date, Nom Course, #Code Circuit, Tours, Longueur Tour)
CIRCUITS(Code Circuit, Nom Circuit)
PILOTES(Code Pilote, Nom Pilote, Natonalité Pilote)
RESULTATS(#N° Course, #Code Pilote, Classement, Abandon)
POINTS(Classement, Points attribués)
Le symbole # désigne les clefs étrangères dans les relations.
d) La matrice des DF
La matrice est mieux adaptée à la présentation des DF lorsque le SI à décrire est imposant et que, en
conséquence, le nombre de propriétés est important:
N° Nom Propriétés
1 N° Course
2 Date
3 Nom Course
4 Code Circuit
5 Nom Circuit
6 Tours
6 Longueur Tour
8 Classement
9 Code Pilote
10 Nom Pilote
11 Nationalité Pilote
12 Abandon
13 Points attribués
R. Richard - UBO
1
«
1
1
1
4
8
9
1+9
«
«
1
1
1
«
«
1
1
1
«
1
1
Conception de bases de données (Partie3)
5
Chaque propriété, énoncée dans la colonne 2, est numérotée (colonne 1).
Les en-têtes des colonnes suivantes contiennent les n° des propriétés émettrices des dépendances
fonctionnelles.
Le symbole « traduisent explicitement, en fait, les DF réflexives évidentes
(ex: N° Course è N° Course).
Le chiffre 1 indique l'existence d'une DF entre la propriété en entête de colonne et la propriétéen
entête de ligne (ex: N° Course è Nom Course).
La matrice étant achevée, chaque colonne fait l'objet d'une relation, qu'il convient de nommer, dans
le modèle relationnel final.
e) Modèle relationnel ou MCD
Le modèle relationnel présente une démarche inverse à celle utilisée avec le modèle Entité
Association: ici on identifie les plus petits éléments d'information (attributs) et on les regroupe pour
en faire des relations alors que, précédemment, on distinguait préalablement des ensembles
d'information (entités) puis on les décrivait (propriétés).
Par expérience, c'est la démarche Entité Association qui se révèle la plus facile à aborder et c'est
pour cette raison qu'elle a été présentée en premier. Cela nous amène maintenant à étudier les règles
de passage du MCD au MRD puisque le MCD, modèle conceptuel pur, ne correspond directement à
aucun modèle physique de données.
R. Richard - UBO
Conception de bases de données (Partie3)
6
C. Les règles de passage du MCD au MRD (ou MLD)
Elles sont au nombre de 3:
• Une entité devient une relation (ou table) et les propriétés de l'entité deviennent attributs
de la relation.
• Une association binaire portant une contrainte d'intégrité fonctionnelle (dite
fonctionnelle plus simplement et donc porteuse d'une 0,1 ou 1,1) se traduit en ajoutant à
la relation représentant l'entité Fils de l'association l'identifiant de l'entité Père
Nb: cet attribut devient une clé étrangère de la relation (à signaler par le caractère #)
• Une association non fonctionnelle (porteuse de part et d'autre de cardinalités 0,n ou 1,n)
fait l'objet d'une nouvelle relation dont l'identifiant sera constitué des identifiants des
entités associées et les attributs les propriétés de l'association.
Entité Pére de l'association: un
père peut avoir plusieur fils
CLIENTS
N° Client
Nom Client
Adresse 1 Client
Adresse 2 Client
CP Ville Client
Tel Client
CIF
(1,n)
Gestion commerciale
(1,1)
passe
COMMANDES
N° Commande
Date Commande
Délai Livraison
Lieu Livraison
(1,n)
Concerne
(0,n)
PRODUITS
Code Produit
Libellé Produit
Prix unitaire
Qté
commandée
Entité Fils de l'association:
un fils a un père et un seul!
F
Application de la règle n°1:
Pour les 3 entités du MCD, on obtient les 3 relations suivantes:
CLIENTS(N° Client, Nom Client, Adresse 1 Client, Adresse 2 Client, CP Ville Client, Tel Client)
COMMANDES(N° Commande, Date Commande, Délai Livraison, Lieu Livraison)
PRODUITS(Code Produit, Libellé Produit, Prix unitaire)
F
Application de la règle n°2:
L'association passe est porteuse d'une CIF (cardinalité 1,1). En conséquence, la relation
COMMANDES, qui représente l'entité Fils de l'association, est modifiée de la manière
suivante:
COMMANDES(N° Commande, Date Commande, Délai Livraison, Lieu Livraison, #N° Client)
F
Application de la règle n°3:
L'association concerne, non porteuse d'une CIF, entraine la création de la relation suivante:
DETAILS_COMMANDE(#N° Commande, #Code Produit, Qté)
Le MRD final est:
CLIENTS(N° Client, Nom Client, Adresse 1 Client, Adresse 2 Client, CP Ville Client, Tel Client)
COMMANDES(N° Commande, Date Commande, Délai Livraison, Lieu Livraison, #N° Client)
PRODUITS(Code Produit, Libellé Produit, Prix unitaire)
DETAILS_COMMANDE(#N° Commande, #Code Produit, Qté)
R. Richard - UBO
Conception de bases de données (Partie3)
7
D. , Le modèle physique de données
Il n'existe pas d'approche normalisée de description et de présentation du MPD: en effet, la
description physique des données est étroitement liée au choix technologique adopté concernant le
système de gestion de données.
Mais, on peut affirmer que le MRD autorise directement la définition physique de la structure de la
base de données requise avec un S.G.B.D. relationnel pour la bonne raison qu'il a été élaboré pour
cette technologie.
Les principaux systèmes de gestion de bases de données sont:
Ÿ DB2 (d'IBM)
Ÿ ORACLE (de ORACLE Corporation)
Ces systèmes concernent essentiellement les S.I. de grosses tailles par le volume de données et la
quantité de transactions de consultation ou mise-à-jour.
En micro-informatique, on utilisera:
Ÿ ACCESS (de Microsoft)
Ÿ 4D (de ACI - éditeur français)
Ÿ …
Cette partie est abordée en TD sous Access.
F
Mise en place de la base de données "Gestion commercial"e sous ACCESS:
La fenêtre des relations donne une représentation de la structure finale de la base.
Remarques:
Ÿ Chaque relation du MRD se traduit par une table.
Ÿ Chaque attribut fait l'objet d'un champ.
Ÿ Les identifiants des relations deviennent les clés primaires des tables (en gras).
Ÿ Les relations entre les tables sont établies en reliant les champs correspondant aux
étrangères aux champs correspondant aux clés primaires.
E. Conclusion sur la modèlisation des données
Il existe des logiciels dits AGL (pour Atelier de Génie Logiciel) qui facilitent grandement
l'élaboration de tous les modèles abordés.
L'un d'entre eux s'appelle Win'Design qui dispose d'un interface graphique sous Windows convivial
proposant ainsi un cadre de travail particulièrement adapté aux taches de modélisation.
R. Richard - UBO
Conception de bases de données (Partie3)
8
Outre les outils de type dessin nécessaires pour l'élaboration des graphiques (MCD…), Win'design
propose des dispositifs de contrôles immédiats lors de la construction des modèles, des dispositifs
de documentation (disctionnaire de données...).
Le MRD peut être généré automatiquement à partir du MCD.
Et, enfin, Win'Design permet la génération automatique du modèle physique de données en tenant
compte, bien évidemment, des contraintes spécifiques à chaque SGBD. Cette génération restitue un
script contenant les ordres SQL destinés à être exécuté par le SGDB aboutissant à la définition
automatique des tables.
R. Richard - UBO
Conception de bases de données (Partie3)
9
Téléchargement