Catalogue | Portail Achat | Intranet | Plan du site

Rechercher

Recherche avance Accueil > L'institut > Units de recherche & units de service

Chapitre I Le modle relationnel

I-1 Introduction * I-2 La modlisation relationnelle * I-3 Normalisation du modle : les formes normales d'un modle relationnel * o I-3-1 Premire forme normale * o I-3-2 Deuxime forme normale * o I-3-3 Troisime forme normale : * o I-3-4 Quatrime forme normale * o I-3-5 Conclusion de la normalisation * I-4 Les contraintes d'intgrit * I-5 Algbre relationnelle et langage SQL * o I-5-1 Oprations ensemblistes * I-5-1-1 Union * I-5-1-2 Intersection * I-5-1-3 Diffrence * I-5-1-4 Produit cartsien * o I-5-2 Oprations relationnelles * I-5-2-1 Projection * I-5-2-2 Restriction ou slection * I-5-2-3 Composition ou jointure * I-5-2-4 Jointures internes et externes * o I-5-3 criture des oprations relationnelles en SQL * I-5-3-1 la projection : * I-5-3-2 la restriction : * I-5-3-3 la jointure (par dfaut elle est interne) : * I-5-3-4 les jointures externes * I-5-3-5 oprateur union * I-5-3-6 agrgats * o I-5-4 Autres fonctions de SQL * I-5-4-1 fonctions de mise jour : * I-5-4-2 fonctions de gestions de la base : * o I-5-5 Exemples d'oprations * I-5-5-1 sur les relations "tudiants" et tudes" * I-5-5-2 sur les relations "individus", "vehicules", "modele" * I-6 Les extensions du modle relationnel et les modles objets *

Quelques rfrences bibliographiques

Comprendre les A.Mesguish Bases de B.Normier

Masson 1981

Donnes Thorie et pratique Bases de donnes et systmes relationnels Bases de donnes : Les Systmes et leurs langages Relational Databases and Knowledge Bases C.Delobel M.Adiba Dunod 1982

G.Gardarin

Eyrolles 1983

G.Gardarin P.Valduriez

Addison 1989 Wesley

SGBD avancs G.Gardarin Bases de P.Valduriez donnes objets, dductives, rparties Les bases de donnes avances. Du modle relationnel au modle orient objet

Eyrolles 1991

ouvrage Herms 1992 collectif coordonnateur Imad Saleh

I-1 Introduction
Le modle relationnel a t dfini par E.F Codd dans les annes 70 et de nombreux chercheurs ont contribu son dveloppement. Les premiers systmes de gestion de base de donnes (SGBD ou DBMS en anglais) btis sur ce modle ont t SQL/DS et DB2 de IBM, d'o est n le langage de manipulation de bases relationnelles, SQL (Structured Query Language). Bien d'autres implmentations ont suivi et, actuellement, la plupart des SGBD commercialiss, aussi bien sur micros que sur grands systmes, se rclament du modle relationnel. L'explication d'un tel succs tient dans les avantages que ce modle apporte, par rapport ses prdcesseurs de type "hirarchique", "rseau" ou Codasyl et C.J Date, un des spcialistes fondateurs du relationnel en donne un rsum en un seul mot : "la simplicit". Simplicit tout d'abord pour l'utilisateur dans la conception, la dfinition, l'installation de la base de donnes. En reprenant la dmonstration de Date sur la "simplicit" du modle relationnel, on peut mettre en vidence la simplicit de la structure des donnes, la simplicit

des oprateurs, l'indpendance entre les donnes et les applications.

Simplicit de la structure des donnes :

Une base relationnelle est compose de tables et est perue par l'utilisateur comme un ensemble de tables et rien d'autre. Il faut prendre table au sens de tableau deux dimensions et, effectivement, le concept de rangement de donnes dans de tels tableaux est aussi simple et comprhensible que suffisant pour reprsenter toutes les formes de donnes ! Dans une table, une ligne (ou range) correspond un enregistrement et une colonne un champ de cet enregistrement.1

Simplicit des oprateurs :

Toute opration relationnelle sur une table gnre une nouvelle table, c'est--dire fonctionne sur un ensemble de donnes sans que l'on ait se proccuper de traiter successivement chacune des donnes rcupres par l'opration. Les oprateurs relationnels, ceux du langage SQL, permettent de dcrire le rsultat que l'on veut obtenir sans avoir dcrire la procdure ncessaire pour arriver au rsultat : on dit que le langage relationnel est "non procdural". Par exemple, la slection de l'ensemble de lignes d'une table dont les valeurs rpondent un critre donn se traduit par une seule opration, en utilisant l'oprateur "select...from...where..." L'utilisateur disposera donc en relationnel d'un langage de manipulation des donnes simple, d'apprentissage facile.

Indpendance des applications vis vis de l'implantation physique des donnes, grce la sparation entre le niveau logique et le niveau physique de la base : la description logique de la base par son modle relationnel suffit dfinir les applications qui l'utiliseront, sans avoir connatre son implantation et sa structure physique.

Pour terminer cette introduction au modle relationnel, nous rappellerons la dfinition et les caractristiques d'un SGBD. Un SGBD est un outil logiciel qui permet, selon un modle de base de donnes particulier, de grer ces donnes en offrant les fonctionnalits suivantes :

un langage de dfinition des donnes (LDD), c'est--dire un langage de dfinition du modle, la dcomposition en tables pour le modle relationnel et la structure de ces tables, avec, selon les systmes, des outils supplmentaires d'organisation physique des donnes pour les rglages de performances; un langage de manipulation des donnes (LMD) pour ajouter, modifier, retrouver, supprimer des donnes; la gestion des rgles assurant l'intgrit des donnes; la gestion de la confidentialit des donnes; la gestion des conflits d'accs simultans aux donnes; la scurit de fonctionnement, avec des outils de sauvegardes et reprises de

la base. L'administrateur de la base, c'est--dire celui qui la cre, la gre et la maintient fera appel toutes ces fonctionnalits du SGBD. L'utilisateur final n'accdera gnralement qu'au langage de manipulation des donnes, soit directement en utilisant le langage standard SQL, soit au travers d'outils plus volus offerts par le SGBD lui-mme ou dvelopps par l'administrateur. Classiquement, une base de donnes peut tre reprsente en trois niveaux :

le niveau externe, qui offre l'utilisateur final un schma externe particulier, travers lequel il voit la base, le niveau conceptuel, celui o le monde rel a t traduit par le crateur de la base en un schma conceptuel, ou modle, le niveau interne, celui du schma physique gr par le SGBD.

L'administrateur aura pour rle la conception du modle partir du monde rel reprsenter, le rglage du schma physique pour certaines optimisations de performances, le maintien de la base de donnes physique, enfin la description des schmas externes l'usage des utilisateurs finaux.

I-2 La modlisation relationnelle

La relation, au sens mathmatique, est un sous-ensemble du produit cartsien d'un certain nombre de domaines, un domaine tant lui-mme dfini comme un ensemble de valeurs : R=(D1 X D2 X D3) est la relation R dfinie sur les domaines D1, D2, D3. La ralisation (l'extension) de cette relation est reprsente par une table 3 colonnes D1, D2, D3, dont les lignes seront concrtises par les diffrentes valeurs possibles prises dans les domaines D1, D2, D3 : R

D1 d1,1 d2,1

D2 d1,2 d2,2

D3 d1,3 d2,3

Le modle relationnel consiste reprsenter par une relation, ou table, chaque type d'objet ou entit du monde rel, en prenant pour colonnes les constituants caractristiques de l'objet. Chaque colonne de la table a un identificateur, ou nom de colonne, ou "attribut", qui reprsente un des constituants de l'entit.

Par exemple, pour modliser l'entit "personne", on prendra comme constituants son nom, son prnom, sa date de naissance, sa ville, son dpartement et on dfinira la table "personne" avec ses colonnes : personne (nom , prnom , date-naissance , ville , dpartement). Les domaines correspondant aux identificateurs de colonnes peuvent tre dfinis par les ensembles de valeurs suivants : nom : chane de 1 30 caractres alphabtiques prnom : chane de 1 30 caractres alphabtiques date-naissance : ensemble des dates depuis le 1er janvier 1900 jusqu'au 1er janvier 1994 ville : ensemble des noms de villes (ou chane de 1 40 caractres) dpartement : entier compris entre 1 et 98 Les personnes relles que nous voudrons introduire dans cette table seront constitues chacune par une ligne de la table, par exemple :

Dupont Hache

Jean Arthur

27/2/49 13/8/68

Pontoise Paris

78 75

Les noms de colonnes (columns en anglais), constituants de l'objet, sont encore appels attributs (attributes en anglais). Les lignes de la tables, ou ranges, (rows en anglais), sont encore appeles n-uplets (ou tuples en anglais), selon la terminologie relationnelle. Pour dfinir une table du modle, il faut :

donner un nom de table, donner le nom des colonnes et leurs domaines de valeurs.

Exemple de cration de table en langage SQL : create table personne (nom char(30), prenom char(30), date-naissance date, ville char(40), departement integer);

I-3 Normalisation du modle : les formes normales d'un modle relationnel

Partant des donnes que l'on veut grer, plusieurs choix de modles relationnels sont possibles. La dcomposition du monde rel modliser en entits ou objets est intuitivement assez vidente, mais il faut galement pouvoir exprimer par le modle les liens logiques qui existent entre ces objets et le choix n'est pas toujours trivial. Par exemple, en plus des donnes de personnes que nous avions prvues ci-dessus, nous pouvons avoir grer galement des donnes relatives au transport, par exemple le ou les vhicules que possde chaque personne. Faut-il ajouter la relation individus les attributs correspondant aux vhicules ou faut-il en faire une autre relation ? Ce type de choix peut et doit tre men selon les rgles de normalisation tablies pour le modle relationnel. Ces rgles ont pour but de constituer un modle vitant les redondances inutiles de donnes et facilitant la gestion, la mise jour des donnes. Elles dfinissent des "formes normales", dont nous allons voir les 4 premiers niveaux.

I-3-1 Premire forme normale

Une relation est en premire forme normale si tout attribut contient une valeur atomique. Les attributs occurrence multiple sont interdits. Le respect de cette rgle est obligatoire dans un SGBD rellement relationnel : les colonnes d'une table ne peuvent tre multivalues. Donc, pour reprsenter les voitures appartenant aux personnes, il n'est pas possible de constituer une colonne "type de voiture" dans la table personne, le nombre de voitures possdes pouvant tre variable. Nous devrons crer une deuxime table "voiture-possde" o le type sera une colonne valeur simple. Pour que le modle ait un sens, il faudra bien entendu tenir compte de l'association entre la voiture et son propritaire et garder, dans la table "voiture-possde" les colonnes faisant rfrence la personne propritaire. exemple : personne( nom, prnom, date-naissance, ville, departement) voiture-possde( nom, prnom, type, date-achat, marque, couleur) Ceci introduit un concept essentiel du modle relationnel : la cl d'une relation. Toute relation, ou table, en relationnel strict, doit comporter, parmi l'ensemble de ses colonnes, un sous-ensemble formant une cl unique : dire, par exemple, que le couple (c1, c2) est la cl de la relation R signifie que les valeurs des autres colonnes c3,...cn de R sont dtermines de faon unique par la valeur du couple (c1, c2).

Dans la table "personne", on pourrait dire que le couple (nom, prnom) forme la cl, condition que l'on ne puisse avoir deux personnes ayant mme nom et mme prnom. C'est cette cl de la table personne qui doit tre rappele dans la table "voiture-possde" pour faire l'association entre les deux tables. On dit que le couple (nom, prnom) dans la table "voiture-possde" est une cl trangre (foreign key en anglais), lie la cl primaire (nom, prnom) de la table "personne". Dans la table "voiture-possde", la cl primaire peut tre constitue par les trois colonnes nom, prnom, type ( condition qu'une personne ne puisse possder plus d'une voiture d'un type donn). Il est parfois ncessaire de redfinir la structure d'une table pour assurer qu'elle contient une cl primaire : par exemple, dans le cas de la table "personne", il est sans doute prfrable d'avoir une colonne d'identification de la personne dont on est sr qu'elle est unique, par exemple son code INSEE, pour viter le cas o nom et prnom ne seraient pas discriminants. De mme, on peut ajouter une colonne "rang" la table "voiture-possde" pour tre sr de constituer une cl unique. Ce qui donne le schma suivant : personne (insee, nom, prenom, date-naissance, ville, departement) voiture-possde (insee, rang, type, date-achat, marque, couleur) nb : les colonnes cls sont soulignes. La dsignation de la cl de la relation, ou cl primaire est obligatoire dans certains SGBD relationnels. Elle ne l'est pas dans INGRES mais la dfinition de cette cl doit tre prsente l'esprit de celui qui conoit le modle car elle conditionne, comme on va le voir, la normalisation des tables. Les tapes suivantes de normalisation des relations vont consister en une dcomposition des tables de faon respecter certaines rgles de dpendances entre les colonnes cls et les colonnes non cls, ce qui permettra d'liminer les redondances de donnes et les problmes de mise jour.

I-3-2 Deuxime forme normale

On a vu que, dans la premire forme normale, toute valeur d'une colonne dpend de la valeur de la cl. Une relation est en deuxime forme normale si et seulement si :

elle est en premire forme normale, toute colonne qui n'appartient pas une cl dpend pleinement de la cl et ne peut se dduire d'un sous-ensemble de cette cl.

Considrons par exemple la table "commande" suivante : commande (nom-fournisseur, adresse-fournisseur, article, quantit, prix) La cl primaire est constitue par le couple (nom-fournisseur, article). Or, l'adresse du fournisseur ne dpend que de son nom. Cette table n'est donc pas en 2FN (2me forme normale) et devra tre dcompose en deux tables : fournisseur (nom-fournisseur, adresse) commande (nom-fournisseur, article, quantit, prix) On vite ainsi des redondances et des problmes de mise jour si l'adresse du fournisseur change.

I-3-3 Troisime forme normale :

Une relation est dite 3FN, en troisime forme normale, si et seulement si :

elle est en deuxime forme normale, une valeur de colonne n'appartenant pas la cl ne dpend pas d'une colonne non cl.

La table "voiture-possde" ne rpond pas cette rgle, car la marque de la voiture ne dpend que de son type. Pour respecter la troisime forme normale, il faudra dcomposer cette relation en deux nouvelles relations : voiture-possde (insee, rang, type, date-achat, couleur) marque-voiture (type, marque) On voit l encore l'intrt de la normalisation pour les mises jour et l'limination des redondances : on peut mettre jour les voitures possdes sans toucher la relation marque-voiture, la marque de voiture n'est pas rpte dans chaque ligne de voiture-possde ayant mme type.

I-3-4 Quatrime forme normale

Le respect de la rgle de 3FN est encore insuffisant pour liminer les redondances et les anomalies de mises jour. Supposons que, pour un mme type de voiture, le modle existe en plusieurs couleurs, rouge, vert, bleu, et en plusieurs versions : normale, dcapotable, break. Par exemple :

un type R18 a un modle en version normale et un modle en version break, un type AX a un modle en version normale et un modle en version dcapotable; le type R18 existe en couleur rouge et bleu, le type AX existe en couleur rouge et vert. On pourrait constituer une table "choix_modle" de la faon suivante : choix_modle( type, couleur, version) La table choix-modle contiendrait les lignes suivantes :

R18 R18 R18 R18 AX AX AX AX

rouge rouge bleu bleu rouge rouge vert vert

normale break normale break normale dcapotable normale dcapotable

Pour une valeur de type, on a toutes les valeurs possibles de couleur et, pour chacune de ces valeurs, toutes les valeurs possibles de version, mais couleur et version sont indpendantes entre elles : on dit que l'on a une dpendance multivalue entre la colonne "type" et la colonne "couleur" et une dpendance multivalue entre la colonne "type" et la colonne "version". On voit l'inconvnient de cette forme puisque, si l'on supprime une valeur possible de la colonne "version", par exemple dcapotable pour le type AX, il faut supprimer toutes les lignes o apparaissent AX et dcapotable. Pour viter ce genre de problmes, il faut passer la quatrime forme normale, qui se dfinit thoriquement ainsi : Une relation est en quatrime forme normale si et seulement si les seules dpendances multivalues lmentaires sont celles dans lesquelles une cl dtermine la valeur d'une colonne. Ici, les colonnes sur lesquelles portent des dpendances multivalues font partie de la cl, donc la table n'est pas en 4FN et il faut la dcomposer en deux tables : choix_couleur( type, couleur) choix_version( type, version)

I-3-5 Conclusion de la normalisation

Plus le degr d'une forme normale est lev, moins les anomalies lies aux oprations de mises jour se produisent, ceci parce que les constituants lmentaires du schma se trouvent tre de plus en plus indpendants les uns des autres. Toutefois, il arrive que l'on ne poursuive pas au maximum la normalisation du modle car elle peut dgrader les performances l'interrogation. En effet, la dcomposition d'une table en plusieurs autres peut conduire scruter plusieurs tables pour une recherche donne (on dit faire une jointure), ce qui peut tre pnalisant en temps de recherche.

I-4 Les contraintes d'intgrit

Le modle d'une base de donnes relationnelle implique, par sa conception, un certain nombre de contraintes d'intgrit qui traduisent les proprits smantiques des donnes : - la contrainte de cl primaire d'une relation implique la non duplication des lignes, c'est--dire que chaque objet du monde rel peut tre enregistr sans ambigut par une seule ligne, un seul "tuple"; - la contrainte de domaine restreint les valeurs possibles d'une colonne un ensemble de valeurs prdfinies; - on peut ajouter une colonne la contrainte de non-nullit qui implique que cette colonne ne peut pas avoir de valeur nulle, c'est--dire ne peut pas tre indfinie ou inutilisable; - la contrainte d'intgrit rfrentielle spcifie les liens qui doivent exister entre deux tables, par la correspondance d'une ou plusieurs colonnes communes ces deux tables, cette ou ces colonnes constituant ce qui est appele une cl trangre. Avec INGRES, la contrainte de cl primaire n'est pas obligatoire et n'a pas tre donne lors de la cration de la table, mme s'il est bon de l'avoir dfinie dans la conception du modle car elle est ncessaire au processus de normalisation. Les contraintes de domaine et de non-nullit sont gres en langage SQL, lors de la cration de la table. Le domaine est dfini par le type de la colonne, soit dans INGRES :

integer smallint float8(float) float4 decimal (dec,

entier long, entier court, rel long, rel court, rel virgule fixe,

numeric) char(n) varchar(n) date byte chane de n caractres, chane de n caractres maximum, de longueur variable, date donnes binaires

Une autre contrainte d'intgrit sur les donnes peut tre ajoute pour spcifier une condition que doit respecter la valeur d'une colonne. Ce qui signifiera qu'une mise jour de la colonne ne respectant pas cette contrainte sera rejete. exemple : create integrity on employe is salaire >= 6000 ; La dfinition de contraintes d'intgrit rfrentielles n'est pas prise en compte dans le standard SQL, ni dans INGRES de faon directe. Elle est possible dans INGRES par le biais de rgles de gestion (ou triggers). La contrainte d'intgrit rfrentielle est, par exemple, de dire qu'une ligne d'une table voiture-possde ne peut exister si la personne laquelle elle se rapporte n'existe pas. Avec INGRES et son extension base de connaissances, on peut dfinir des rgles qui sont des mcanismes par lesquels on invoque une procdure spcifique chaque fois qu'une condition est vraie : par exemple, on fera en sorte de supprimer toutes les lignes de voiture-possde se rfrant une personne si cette personne est enleve de la base : create rule maj afterdeletefrom personne execute procedure del_voitures (insee = old.insee);

I-5 Algbre relationnelle et langage SQL

L'algbre relationnelle, invente par Codd, est une collection d'oprations formelles sur les relations (ou tables). Une opration relationnelle conduit construire une nouvelle relation (ou table), rsultat d'une opration sur une ou plusieurs relations (ou tables) oprandes. L'algbre relationnelle comprend les oprations classiques de la thorie des ensembles : union, intersection, diffrence.

I-5-1 Oprations ensemblistes

I-5-1-1 Union l'union (R U S) de deux tables R et S ayant mme schma, c'est--dire mmes lignes, est une table T contenant l'ensemble des lignes appartenant R et des lignes appartenant S I-5-1-2 Intersection l'intersection (R n S) de deux tables R et S de mme schma est une table T contenant les lignes communes R et S I-5-1-3 Diffrence la diffrence (R - S) de deux tables R et S de mme schma est une table T contenant les lignes de R n'appartenant pas S I-5-1-4 Produit cartsien On dfinit le produit cartsien (T = R * S) de deux tables R et S par la table T constitue par la concatnation une par une de chaque ligne de S chaque ligne de R. exemple : R= tudiant ( nom, prenom) S= tudes (bac, filire) R

nom Dupont Perec Fort S

prenom Alain Georges Paul

bac A B C D

filire littraire conomie sciences sciences T=R*S

nom

prenom

bac

filire

Dupont Dupont Dupont Dupont Perec Perec Perec Perec Fort Fort Fort Fort

Alain Alain Alain Alain Georges Georges Georges Georges Paul Paul Paul Paul

A B C D A B C D A B C D

littraire conomie sciences sciences littraire conomie sciences sciences littraire conomie sciences sciences

I-5-2 Oprations relationnelles

Les oprations relationnelles comportent la projection et la restriction, qui sont des oprations unaires, et la composition ou jointure, qui est un produit cartsien suivi d'une restriction. I-5-2-1 Projection la projection consiste crer une table T partir d'une table R, en ne gardant qu'un certain nombre de colonnes de la table R. exemple : la projection de R sur le nom donne une table ne contenant que la colonne "nom"; les doubles, s'ils existent, sont limins.

nom Dupont Perec Fort I-5-2-2 Restriction ou slection la restriction consiste slectionner les lignes d'une table R pour lesquelles une colonne vrifie une certaine proprit. exemple : la restriction de R pour la condition "prnom de plus de 4 lettres" donne les 2 premires lignes. R

nom prenom Dupont Alain Perec Georges I-5-2-3 Composition ou jointure Cette opration, essentielle en relationnel, consiste combiner 2 (ou plus) tables pour obtenir une table rsultat, en concatnant 2 2 les lignes des deux tables

initiales (c'est le produit cartsien) et en ne gardant (restriction) que les lignes dont 2 colonnes (ou plus) dans les tables initiales vrifient une certaine proprit. exemple : le produit cartsien vu ci-dessus donne toutes les possibilits d'tudes pour chacun des tudiants; supposons maintenant que les tudiants enregistrs aient pass leur bac et que l'on ait l'attribut "bac" dans la relation "tudiants", ce qui donnerait : R2

nom Dupont Perec Fort

prenom Alain Georges Paul

bac C A A

On peut crer la table T2 donnant les filires possibles pour chaque tudiant en fonction du bac, en faisant la jointure de la table R2 avec la table S, sur la proprit : le bac de l'tudiant est le mme que le bac de la table "tudes". Donc, du produit cartsien prcdent, on ne garde que les lignes suivantes : T2

nom prenom bac filire Dupont Alain C sciences Perec Georges A littraire Fort Paul A littraire I-5-2-4 Jointures internes et externes On peut dfinir des types de jointures dits internes et externes correspondant diffrentes faons de faire la slection du produit cartsien. La jointure interne est la jointure classique vue ci-dessus : on combine toutes les lignes de R toutes les lignes de S pour lesquelles la valeur de l'attribut "bac" est identique dans les deux tables. Si la table R contenaient des lignes dont la valeur de l'attribut "bac" n'existait pas dans la table S, ces lignes n'apparatraient pas dans la jointure interne. De mme si la table S contenaient des lignes dont la valeur de l'attribut "bac" n'existait pas dans la table R, ces lignes n'apparatraient pas dans la jointure interne.

exemple : R3 nom Dupont Perec Truche Fort S3 bac A B C D E rsultat de la jointure interne : T3-interne prenom Alain Georges Paul

prenom Alain Georges Jacques Paul filire littraire conomie sciences sciences conomie

bac C A X A

nom Dupont Perec Fort

bac C A A

filire sciences littraire littraire

La jointure externe donne une table rsultat comprenant des lignes qui ne sont pas en correspondance entre les deux tables origines. Elle est dite "externe gauche" si on prend toutes les lignes de la table de gauche de l'opration de jointure, par exemple T3-gauche = R3*S3

nom Dupont Perec Truche Fort

prenom Alain Georges Jacques Paul

bac C A X A

filire sciences littraire littraire

Elle est dite "externe droite" si on prend toutes les lignes de la table de droite de l'opration de jointure, par exemple T3-droite = R3*S3

nom Dupont Perec

prenom Alain Georges

bac C A

filire sciences littraire

Fort

Paul

A E

littraire conomie

Elle est dite "externe complte" si on prend toutes les lignes des deux tables de l'opration de jointure, par exemple T3-externe-complte = R3*S3

nom Dupont Perec Truche Fort

prenom Alain Georges Jacques Paul

bac C A X A E

filire sciences littraire littraire conomie

I-5-3 criture des oprations relationnelles en SQL

Le langage SQL standard permet les oprations suivantes : I-5-3-1 la projection : select col_1, col_2,...col_n from table_t ; I-5-3-2 la restriction : select col_1,... from table_t where qualification ; avec tri des rsultats : select * from table_t where qualification order by col_1, col_2...; avec qualification = expression conj expression... avec expression = attribut_i op valeur conj est un oprateur de connexion ( and, or) op est un oprateur de comparaison ( =, <, >, <>, != , <=, >= ) * est une convention pour slectionner toutes les colonnes. I-5-3-3 la jointure (par dfaut elle est interne) : select t1.col_1, t1.col_n, t2.col_1, t2.col_n from table_1 t1, table_2 t2 where t1.col_i = t2.col_j ;

[-------------------] qualification multi-colonnes t1 et t2 sont des abrviations, synonymes de table_1 et table_2. autre forme de jointure : select col_1,... from table_1 where col_i in (select col_j from table2) Dans cet exemple de jointure, comme dans la plupart des cas, les deux colonnes mises en correspondance doivent tre gales : on dit que l'on fait une qui-jointure. On peut galement envisager tout type d'oprateur de comparaison entre les colonnes mises en jointure. On peut aussi faire une jointure sur plus de deux colonnes appartenant aux deux tables. Enfin, on est parfois amen faire la jointure d'une table sur elle-mme (autojointure). I-5-3-4 les jointures externes select t1.col_1, t1.col_n, t2.col_1, t2.col_n from table_1 t1 left join table_2 t2 on t1.col_i = t2.col_j ; ou select t1.col_1, t1.col_n, t2.col_1, t2.col_n from table_1 t1 right join table_2 t2 on t1.col_i = t2.col_j ; ou select t1.col_1, t1.col_n, t2.col_1, t2.col_n from table_1 t1 full join table_2 t2 on t1.col_i = t2.col_j ; I-5-3-5 oprateur union l'oprateur union permet de faire l'union de deux tables rsultats dont les schmas sont identiques :

exemple : select nom from personne union select nom from employe I-5-3-6 agrgats Dans un ordre select, on peut utiliser des fonctions de calculs d'agrgats qui s'appliquent, sur une colonne, un ensemble ou des sous-ensembles de lignes : count comptage de lignes rsultats sum avg max min somme de valeurs moyenne maximum minimum

exemple : on fait le calcul des moyennes de salaires, par catgorie : select categorie, avg(salaire) from employe group by categorie

I-5-4 Autres fonctions de SQL

I-5-4-1 fonctions de mise jour : insert, delete, update sont des fonctions respectivement d'insertion, de suppression, de modification. I-5-4-2 fonctions de gestions de la base : Ces fonctions permettent de grer les tables, les contraintes d'intgrit, les vues qui sont des reprsentations des donnes sous forme de tables construites partir des tables de la base. create table create integrity create view ... Toutes ces fonctions sont dveloppes dans le chapitre SQL.

I-5-5 Exemples d'oprations

I-5-5-1 sur les relations "tudiants" et tudes" tudiants ( nom, prenom, bac) tudes ( bac, filire) slection des tudiants ayant un bac A : select * from tudiants where bac = "A" ; recherche des filires possibles pour chaque tudiant : select r.nom, s.filiere from tudiants r, tudes s where r.bac = s.bac ; I-5-5-2 sur les relations "individus", "vehicules", "modele" individus ( insee, nom, prenom, date_naissance, departement) vehicules ( insee, rang, type, age) modele ( type, marque, puissance) slection des individus ayant plus d'un vhicule : select distinct insee from vehicules where rang > 1 ; recherche des dpartements des individus ayant plus d'un vhicule : select distinct i.departement from individus i, vehicules v where i.insee = v.insee and v.rang > 1 ; recherche de l'age et de la puissance des vhicules de rang 2 : select v.age, m.puissance from vehicules v , modele m where v.rang = 2 and v.type = m.type ; recherche de l'age et de la puissance des vhicules appartenant aux individus du dpartement "78" : select v.age, m.puissance from vehicules v, modele m, individus i where v.insee = i.insee and i.departement =

"78" and v.type = m.type ; recherche des deux types de vhicules de rang 1 et 2 appartenant au mme individu : (il s'agit ici de faire une auto-jointure de la relation "vehicules") select v1.type, v2.type from vehicules v1, vehicules v2 where v1.insee = v2.insee and v1.rang = 1 and v2.rang = 2 ;

I-6 Les extensions du modle relationnel et les modles objets

Les SGBD relationnels rpondent mal certaines applications grant des objets complexes (textes, graphiques, cartes, images, donnes multi-dimensionnelles) et des objets dynamiques. Un autre problme important soulev par le relationnel est celui du langage de requtes qui dlivre des ensembles de donnes (tuples) aux programmes d'application qui, eux, doivent relire et traiter ces tuples un par un. Ces limites du modle relationnel ont conduit de nombreuses recherches sur de nouveaux modles de bases de donnes et, actuellement, deux types d'alternatives sont proposs : les modles relationnels tendus et les modles orients objets. Dans les deux cas, l'enrichissement du modle relationnel est fait par l'approche "objet", tire des concepts des nouveaux langages de programmation dits "orients objets". Le modle relationnel tendu va ajouter des fonctionnalits de type objets aux SGBD relationnels classiques. Le modle orient objet va conduire de nouveaux SGBD, dits SGBD orients objets ou SGBD-OO, s'appuyant sur la programmation objet en lui intgrant des fonctionnalits de SGBD. Dans les modles relationnels tendus, on trouve de nouvelles possibilits de dfinition et de manipulation des constituants des tables : on peut crer ses propres types de donnes, appels ADT (types de donnes abstraits ou Abstract Data Types). Ces types d'objets dfinissent la fois les domaines de valeurs des objets et les

oprations que l'on peut leur appliquer, c'est le concept d' "encapsulation" des objets. A ces nouvelles fonctionnalits il faut adjoindre des extensions du langage de requtes. INGRES, dans sa dernire version offre des fonctionnalits tendues aux objets. L'autre approche, celle des SGBD-OO, consiste proposer un nouveau modle de base "orient objet" qui puisse tre gr par un systme de type SGBD. Plusieurs systmes sont d'ores et dj sur le march (O2, ONTOS, VERSANT, GEMSTONE,...). Il n'existe pas, contrairement au modle relationnel, de fondement formel et thorique permettant de donner une dfinition universelle du modle objet et chaque systme offre une solution spcifique. Toutefois, il existe des concepts communs que l'on doit retrouver dans tout modle orient objet, que l'on peut rsumer ainsi :

un objet est une collection d'lments de donnes structurs identifi par une rfrence unique : cette rfrence est l'"OID" (Object IDentifier); elle assure la possibilit de partage entre composants d'objets diffrents; les objets sont caractriss par des "proprits" : une proprit est une caractristique d'un objet dsigne par un nom, pouvant correspondre un attribut, une fonction ou un sous-objet composant; l'encapsulation fait que les donnes et les oprations, ou mthodes, portant sur elles sont modlises en mme temps; les types ou classes permettent de dfinir des ensembles d'objets ayant mmes caractristiques (le type tant utilis la compilation, pour la dfinition a priori des objets, alors que la classe est utilise l'excution pour l'instanciation des objets); les types et classes peuvent tre dfinis de faon hirarchique; l'hritage permet une classe d'objets de partager des oprations communes aux objets de la classe suprieure; une proprit d'un objet, hrite de la classe suprieure peut tre "surcharge" par la redfinition de cette proprit pour la classe de l'objet.

Les SGBD-OO apportent sans aucun doute de nombreux avantages par rapport aux SGBD relationnels classiques : facilits de manipulation d'objets complexes, extensibilit des types de donnes, mme formalisme de stockage des donnes et des programmes, hirarchie des classes d'objets et mcanisme d'hritage. En revanche, ils n'ont plus la simplicit du modle relationnel, le principe de la manipulation non procdurale des donnes, et l'avantage de la standardisation. C'est pourquoi, dans la grande majorit des applications actuelles, le relationnel reste la meilleure solution et les extensions "objets" du relationnel sont un bon palliatif ses lacunes. La migration vers un SGBD-OO ne s'impose que pour des applications

particulires o les performances du relationnel, aussi bien en temps machine qu'en temps de dveloppement seraient inacceptables

Contact | Mentions lgales | Copyright INRETS 2010 | Crdits