Notes de cours 2008 2009
10
pages
Français
Documents
Le téléchargement nécessite un accès à la bibliothèque YouScribe Tout savoir sur nos offres
10
pages
Français
Documents
Le téléchargement nécessite un accès à la bibliothèque YouScribe Tout savoir sur nos offres
Chapitre2Lemodèlerelationnel2.1 BasesdedonnéesrelationnellesLe Dr Codd, travaillant dans les laboratoires I.B.M. au cours des années 70, a mis au pointun système nouveau de description des données. Il aura fallu attendre plus de 15 ans avant queles premiers systèmes mettant en application ses théories puissent tourner de manière efficace.Le système de Codd se base sur la notion mathématique de relation. Les bases de donnéesactuelles ne sont donc pas relationnelles parce qu’elles établissent des relations entre les tables(il ne semble pas possible de créer une base de données sans forcément mettre des données enrelation les unes avec les autres), mais parce que les tables SONT des relations.2.1.1 Ensembles,couples,triplets,tuplesetautresanimauxétrangesLa théorie des ensembles, inventée par Peano à la fin du XIXe siècle, a profondémentmarqué l’histoire des mathématiques du XXe siècle. La notion d’ensemble est une primitive etse définit comme une collection d’objets, appelés éléments de l’ensemble. Parmi les propriétésremarquables d’un ensemble figure l’impossibilité qu’un même élément appartienne deux foisau même ensemble.La théorie des relations met en œuvre plusieurs ensembles et utilise les notions de couple,triplet et tuple. Un couple est un ensemble ordonné de deux éléments, cela signifie qu’uncouple comporte deux éléments et que chacun a sa place (le premier membre du couple et lesecond membre du couple). On peut aussi définir des triplets (à trois ...
Voir
Publié par
Langue
Français
Chapitre 2
Le modÈle relationnel
2.1
Bases de donnÉes relationnelles
Le Dr Codd, travaillant dans les laboratoires I.B.M. au cours des annes 70, a mis au point un systme nouveau de description des donnes. Il aura fallu attendre plus de 15 ans avant que les premiers systmes mettant en application ses thories puissent tourner de manire efficace. Le systme de Codd se base sur la notion mathmatique de relation. Les bases de donnes actuelles ne sont donc pas relationnelles parce qu’elles tablissent des relations entre les tables (il ne semble pas possible de crer une base de donnes sans forcment mettre des donnes en relation les unes avec les autres), mais parce que les tables SONT des relations.
2.1.1
Ensembles, couples, triplets, tuples et autres animaux Étranges
La thorie des ensembles, invente par Peano À la fin du XIXe sicle, a profondment marqu l’histoire des mathmatiques du XXe sicle. La notion d’ensembleest une primitive et se dfinit comme une collection d’objets, appelsÉlÉmentsde l’ensemble. Parmi les proprits remarquables d’un ensemble figure l’impossibilit qu’un mme lment appartienne deux fois au mme ensemble. La thorie des relations met en œuvre plusieurs ensembles et utilise les notions de couple, triplet et tuple. Un couple est un ensemble ordonn de deux lments, cela signifie qu’un couple comporte deux lments et que chacun a sa place (le premier membre du couple et le second membre du couple). On peut aussi dfinir des triplets (À trois lments ordonns) et des tuples Ànlments. Leproduit cartÉsiende deux ensembles est l’ensemble de tous les couples qu’il est pos-sible de former en prenant un lment dans le premier ensemble et un lment dans le second ensemble. On voit rapidement que le nombre d’lments d’un produit cartsien est gal au produit des nombres d’lments des deux ensembles. Quand une opration malencontreuse gnre un produit cartsien, on peut facilement bloquer la machine (deux tables de 1000 l-ments ne sont pas rares dans une base de donnes, mais leur produit cartsien possdent un million d’lments, une masse de donnes pnible À grer). Voici un exemple de produit cartsien de deux ensemblesHetF, qui comprend neuf couples (3x3).
H={a, b, c}
F={p, f, d}
(a, p), H×F= (b, p), (c, p),
17
(a, f), (b, f), (c, f),
(a, d), (b, d), (c, d)
18
CHAPITRE 2. LE MODèLE RELATIONNEL
Une relation entre deux ensembles est un sous-ensemble du produit cartsien de deux en-sembles, c’est-À-dire un ensemble form avec des lments choisis dans le produit cartsien. Les relationsR1etR2sont des relations entre les ensemblesHetF.
H={a, b, c}F={p, f, d} (a, p),(a, f),(a, d), H×F= (b, p),(b, f),(b, d), (c, p),(c, f),(c, d)
R1={(a, p),(b, f),(c, d)}
R1⊆H×F
R2={(a, f)}
R2⊆H×F
Le systme formel dfini par la notion de relation est en gnral mis en parallle avec une signification intressante pour les utilisateurs. Ainsi, si l’ensembleHreprsente l’ensemble des hommes dont il est question dans l’ditorial de la revuePoints de vue(Albert, Baudouin et Charles) etFl’ensemble des femmes mentionnes dans le mme article (Paola, Fabiola et Diana), les relations relationsR1etR2pourraient signifier respectivement « a pous » et « est beau-frre de ». Notons que l’interprtation est impossible À dterminer sur base de l’numration, ce qui signifie clairement que l’ordinateur qui manipule des relations n’aura jamais accs À lasignificationde ces relations. Nous avons examin des relations entre deux ensembles, qui sont constitues par des en-sembles de couples, mais nous pouvons gnraliser les relations À des ensembles de triplets constitus avec les lments de 3 ensembles, ou des ensembles detuplesconstitus avec des lments pris dansnensembles.
2.1.2
Des relations aux tables
En pratique, on reprsente les relations au moyen de tables.
H={a, b, c} F={p, f, d} R1={(a, p),(b, f),(c, d)}
Hommes Albert Baudouin Charles
Femmes Paola Fabiola Diana
Les ensembles participant À la relation deviennent desattributsoucolonnes, les tuples de-viennent deslignes. Chacun sait que les tables permettent de reprsenter des donnes, les en-sembles intervenant dans la relation tant la plupart du temps implicites. Si on veut reprsenter une srie de personnes, on va prendre l’ensemble des prnoms possibles, des noms possibles, des adresses possibles et des dates possibles. Le produit cartsien de ces quatre ensembles est gigantesque, mais on va y slectionner un sous-ensemble, une relation, qui se compose de tuples qui correspondent aux personnes qui nous intressent (membres d’un club, clients d’une entreprise ou tudiants d’une cole).
PrÉnom Jean Pierre Jasmine
Nom DUPONT DUMONT SAIDA
Adresse rue de l’Èglise rue de la gare rue des sapins
Date de naissance 1/5/1984 6/8/1944 4/8/1965
2.2. MODéLISATION RELATIONNELLE
19
2.1.3 AlgÈbre relationnelle Codd a repris des oprations mathmatiques et les a appliques À sa thorie des relations. Nous les verrons en dtail dans les prochains chapitres. Toutes ces oprations prsentent une caractristique commune : elles produisent toujours une nouvelle relation, qui peut servir de base À une autre opration et ainsi de suite... Opration Description UnionL’union consiste À prendre tous les tuples prsents dans deux relations et À les runir dans une nouvelle relation. Les doublons sont automatique-ment limins puisqu’un lment ne peut figurer deux fois dans un mme ensemble. IntersectionL’intersection ne gardera de deux relations que les tuples qui sont dans les deux relations (cet ensemble comportera prcisment les doublons qui seraient limins dans l’opration d’union). DiffÉrenceLa diffrence consiste À retirer d’une relation les tuples qui sont prsents dans une autre relation. La diffrence entre deux relations n’est pas sy-mtrique. ProjectionLa projection consiste À liminer un ou plusieurs attributs d’une relation (les colonnes d’une table). Nous verrons qu’un problme d’limination des doublons survient ici galement. RestrictionUne restriction ou slection ne garde que certains tuples d’une relation (lignes d’une table), en fonction d’un critre de choix. JointureLa jointure opre une jonction entre des relations en combinant des tuples de la premire avec des tuples de la seconde pour obtenir des tuples ayant plus d’lments que ceux des tables originales. La jointure se ralise sur base de critres prcis et s’accompagne souvent d’une projection pour liminer certains attributs jugs inutiles. Il y a en fait plusieurs types de jointures, un cas dgnr tant le produit cartsien qui combine tous les tuples d’une relation avec tous les tuples de l’autre. Ajoutons pour terminer la notion declÉ primairequi est un sous-ensemble d’attributs qui composent des tuples uniques. Comme tous les tuples de la relation sont par dfinition dif-frents, au pire, la cl primaire sera constitue de tous les attributs. Dans la plupart des cas, on trouve quand mme une liste d’attributs de dimension raisonnable (une, deux ou trois co-lonnes) ou on cre un attribut arbitrairement en lui donnant une valeur diffrente pour chaque tuple (c’est l’origine des numros nationaux et des codes clients). La connaissance de la cl primaire permet d’identifier facilement chaque ligne de la relation. Ainsi, chaque donne ato-mique dans une base de donnes peut tre dfinie et atteinte au moyen de trois paramtres : 1. le nom de la table 2. le nom de l’attribut ou de la colonne 3. la valeur de la cl primaire
2.2
ModÉlisation relationnelle
Nous avons vu dans le chapitre prcdent plusieurs manires de grer une petite facturation. La solution relationnelle va consister À essayer de crer une relation qui reprendrait les donnes pertinentes pour chaque facture. Notons que nous voudrions pouvoir profiter de notre base de donnes pour examiner nos donnes autrement qu’en partant des clients, par exemple, en effectuant des statistiques sur les ventes d’articles.
20
2.2.1 Mise en tableau Voici les donnes pour quatre factures :
CHAPITRE 2. LE MODèLE RELATIONNEL
Ce magnifique tableau ne constitue videmment pas une relation. Nous pouvons le consi-drer de deux manires : – soit la partie consacre aux articles prsente plusieurs valeurs simultanes (dans le cas de la premire facture, le marteau et la cl de 10, avec leur prix et la quantit achete) – soit on considre qu’il y a plusieurs lignes par facture, comme le suggre la mise en 1 page, et nos tuples potentiels ne sont pas complets . Nous allons privilgier la seconde hypothse et complter les tuples avec les valeurs qui manquent.
2.2.2
Mise en relation
Il serait possible de faire transformer ce tableau en relation, mais on constate encore plu-sieurs dfauts : – il n’existe pas de cl primaire convaincante, c’est-À-dire, un ensemble de tuples permet-tant d’identifier chaque ligne de manire unique – on peut raisonnablement douter de la pertinence des ensembles servant À dfinir les valeurs possibles pour les colonnes Client et Adresse. Pour parler savamment, on dira que les donnes ne sont pas atomiques. – le montant devrait pouvoir tre calcul automatiquement sur base des autres donnes. – enfin, et surtout, on remarque que de nombreuses donnes se rptent : l’adresse des clients, le prix des outils, la date des factures.
1 A titre d’anecdote, l’illustration propose dans cette page a t ralise À l’aide d’Oracle et il m’a fallu ruser pour afficher ces tuples incomplets et surtout les garder dans le bon ordre. Preuve que cette reprsentation n’est vraiment pas relationnelle.
2.2. MODéLISATION RELATIONNELLE
21
Nous allons tenter de remdier À ces diffrents problmes. Le but tant d’arriver À une repr-sentation des donnes sans redondances et avec des donnes atomiques.
2.2.3 PremiÈre forme normale Une relation est normalise si – aucun attribut n’est reprsent plusieurs fois et – aucun attribut n’est dcomposable en plusieurs (n’est lui mme une relation).
Pour parvenir À cette premire forme normale, nous allons devoir nous occuper du second critre (le premier a t corrig dans la sous-section prcdente). Nous allons clater les don-nes du client en un champ nom et un champ prnom. Notons que cette sparation peut se faire facilement gráce À notre connaissance de l’onomastique belge. Ce serait plus compliqu si nous avions affaire À des noms trangers. Ce qui est certain, c’est qu’aucun ordinateur ne sera capable de raliser cette opration spontanment. Nous procdons de mme pour l’adresse.
Il reste À trouver la cl primaire. Aprs un examen attentif, nous constatons que le couple form par le numro de la facture et la dsignation de l’article est le seul À tre unique (c’est vrai aussi actuellement du coupleId_Facture-PrixUnitaire, mais on conÇoit bien que deux articles pourraient avoir le mme prix). Notre ralit est profondment influence par l’informatique. Nous savons que les entre-prises utilisent des codes pour dsigner leurs articles et il n’est pas rare d’avoir des codes clients. Nous verrons que cela nous sera bien utile par la suite. Nous allons donc introduire ces deux notions (et au passage masquer les champsPrenom,Numero,CodePostaletLocalitequi n’apportent rien À la dmonstration).
La cl primaireId_Facture-Id_Articleest encore plus sÛre que celle que nous avions auparavant.
22
CHAPITRE 2. LE MODèLE RELATIONNEL
Le rsultat obtenu est insatisfaisant À bien des gards : – une mme donne est rpte plusieurs fois (par exemple, l’adresse de Schyns ou le prix du marteau) ; – si on complte la table, il est parfaitement possible d’encoder une nouvelle facture pour Comhaire en lui attribuant une adresse diffrente ; – si on supprime la facture d’un nouveau client, on risque de perdre les coordonnes de ce client.
2.2.4 DeuxiÈme forme normale Une relation est en deuxime forme normale si – elle est en premire forme normale et – toutes les dpendances issues de la cl sont lmentaires (c’est-À-dire qu’elles ont pour source la cl entire et non un de ses attributs).
On parle dedÉpendance fonctionnelleentre deux attributsAetBd’une relation lorsque pour tous les couples (Ai,Bj), obtenus par une projection de la relation sur les deux attributsA etB, on peut faire correspondre ncessairement À un mme lmentAiun mme lmentBj. L’attribut du premier lment s’appelle la source de la fonction, l’attribut du second le but. Dans la relation en premire forme normale, chaque fois que nous avons l’identifiant d’ar-ticle 1, la valeur deDÉsignationest ncessairement ’Marteau’. Examinons la relation. La cl complexe forme deid_FactureetidArticlespcifie une seule valeur de chacun des autres attributs. Mais on trouve d’autres dpendances fonctionnelles : – entre le numro de facture et soit la date, soit le numro du client, soit son nom, soit son adresse – entre le numro de l’article et soit sa dsignation, soit son prix.
Nous allons devoir les liminer. Pour liminer les dpendances fonctionnelles dcouvertes dans notre exemple, nous allons scinder notre relation initiale en deux autres relations. Nous allons liminer les dpendances fonctionnelles entre l’attributid_Factureet chacun des attributs de la relation en les regroupant
2.2. MODéLISATION RELATIONNELLE
23
dans une autre relation. La premire relation obtenue possde une cl primaire simple. Cette particularit fait qu’elle est automatiquement en deuxime forme normale.
La seconde relation ne conservera que les attributs qui ne dpendaient pas deid_Facture.
Ce qu’on pourrait appeler la table des commandes prsente encore des dpendances fonc-tionnelles entre une partie de la cl (id_Article) et des attributs qui ne sont pas membres de la cl. Il devient ncessaire de la scinder À nouveau en deux nouvelles relations.
24
2.2.5
TroisiÈme forme normale
CHAPITRE 2. LE MODèLE RELATIONNEL
Une relation est en troisime forme normale si : – elle est en deuxime forme normale – toutes les dpendances fonctionnelles issues de la cl sont directes
Toutes les dpendances n’ont pas encore t puises par notre normalisation. En effet, dans la relation des factures, on peut dire que le nom du client (ou son adresse) dpend de la cl primaire. Mais cette dpendance n’est pas directe. Le nom du client dpend du numro qui est lui-mme dpendant de la cl primaire. On parle alors de dpendance transitive. Cette dpendance entraïne À nouveau des risques d’incohrence. La solution consiste de nouveau À scinder la table.
2.2. MODéLISATION RELATIONNELLE
2.2.6
Reconstruction des donnÉes originales
25
A quoi peut bien servir de disposer d’une base de donnes, si nous voyons nos donnes se disperser dans des tables spares ? Il existe heureusement des oprations d’algbre rela-tionnelle qui permettent de recrer les relations originales, dont l’existence devient virtuelle, mais qu’on peut parfaitement exploiter pour afficher les donnes. Lorsque les applications doivent manipuler frquemment certaines de ces relations, il est possible d’en enregistrer les commandes dans unevue, qu’on peut employer sans connaïtre les commandes complexes per-mettant les jointures de tables.
SELECT * FROMFactures INNER JOINClientsUSING(id_Client) INNER JOINCommandesUSING(id_Facture) INNER JOINArticlesUSING(id_Article)
26
CHAPITRE 2. LE MODèLE RELATIONNEL
2.2.7 Les avantages de l’analyse Le processus de cration des tables que nous venons de dcrire insiste fortement sur les principes qui sous-tendent la dcomposition en relations (tables). En pratique, une telle d-marche risquerait de mener À des difficults insurmontables, ds qu’on dpasserait quatre ou cinq tables. Heureusement, il existe d’autres techniques qui permettent d’obtenir des schmas de base de donnes normaliss. Plusieurs mthodes d’analyse, dont la mthode Merise, pro-posent un diagramme entits/associations qui, bien construit, peut produire un schma de base de donnes normaliss de manire quasi automatique. Dans notre problme, nous allons distinguer trois entits, qui correspondent À des groupes d’objets du monde rel : les factures, les clients et les articles. Il est possible d’tablir deux associations entre ces entits : payer et commander. Il est capital À ce niveau de spcifier les « cardinalits » minimales et maximales des assocations : – une facture n’est paye que par un seul client (cardinalit 0,1) – un client peut se voir associer une ou plusieurs factures (cardinalit 1,N) – une facture peut se lier avec un ou plusieurs articles (cardinalit 1,N) – un article peut figurer dans 0, 1 ou plusieurs factures (cardinalit 0,N)
Le diagramme ci-dessus a t ralis avec le programme WinDesign. Un simple appui sur la touche Control-G nous permet d’obtenir le schma de la base de donnes et en appuyant À nouveau sur la mme touche, nous obtiendrions le script dans le dialecte SQL de notre choix.
Nous remarquons que ce schma est parfaitement conforme À celui que nous avons obtenu À l’aide de la normalisation.
