Bases de données relationnelles

Nguyen Tuan Loc

2

Résumé du cours précédent

3

Chirurgie

Psychiatrie

Systèmes de fichiers Caractéristiques

Comptabilité

Consultations

Problèmes

4Format des fichiers CaractéristiquesPlusieurs applications plusieurs formats

plusieurs langages

Problèmes Difficultés de gestion

DupontSymptomes : yTurlututu : sqjSymptomes : yTurlututu : sddAnalyses : xxx

DupondTurlututusqjskSymptom: yyyy Analyses xxxx

TurlututudhjsdAnalyses :xx

DuipontTurlututu : sq

Symptomyyyy Analysesxxxx

Turlututudhjsd

Duhpon

Symptomes : yy Analyses : xxxx

Symptomes : yy

5Redondance (données) CaractéristiquesPlusieurs applications plusieurs formats

plusieurs langages

Redondance de données

Problèmes Difficultés de gestion Incohérence des données

DupontSymptomes : yTurlututu : sqjSymptomes : yTurlututu : sddAnalyses : xxx

DupondTurlututusqjskSymptom: yyyy Analyses xxxx

TurlututudhjsdAnalyses :xx

DuipontTurlututu : sq

Symptomyyyy Analysesxxxx

Turlututudhjsd

Duhpon

Symptomes : yy Analyses : xxxx

Symptomes : yy

6Interrogations CaractéristiquesPlusieurs applications plusieurs formats

plusieurs langages

Redondance de données

Pas de facilité d’interrogation Question développement

Problèmes Difficultés de gestion Incohérence des données Coûts élevés Maintenance difficile

DupontSymptomes : yTurlututu : sqjSymptomes : yTurlututu : sddAnalyses : xxx

DupondTurlututusqjskSymptom: yyyy Analyses xxxx

TurlututudhjsdAnalyses :xx

DuipontTurlututu : sq

Symptomyyyy Analysesxxxx

Turlututudhjsd

Duhpon

Symptomes : yy Analyses : xxxx

Symptomes : yy

Ch

iru

Sof

t

Con

sultS

oft Psy

chia

Sof

t

Com

ptaS

oft

7Pannes ??? CaractéristiquesPlusieurs applications plusieurs formats

plusieurs langages

Redondance de données

Pas de facilité d’interrogation Question développement

Redondance de code

Problèmes Difficultés de gestion Incohérence des données Coûts élevés Maintenance difficile Gestion de pannes ???

DupontSymptomes : yTurlututu : sqjSymptomes : yTurlututu : sddAnalyses : xxx

DupondTurlututusqjskSymptom: yyyy Analyses xxxx

TurlututudhjsdAnalyses :xx

DuipontTurlututu : sq

Symptomyyyy Analysesxxxx

Turlututudhjsd

Duhpon

Symptomes : yy Analyses : xxxx

Symptomes : yy

Ch

iru

Sof

t

Con

sultS

oft Psy

chia

Sof

t

Com

ptaS

oft

8Partage de données CaractéristiquesPlusieurs applications plusieurs formats

plusieurs langages

Redondance de données

Pas de facilité d’interrogation Question développement

Redondance de code

Problèmes Difficultés de gestion Incohérence des données Coûts élevés Maintenance difficile Gestion de pannes ??? Partage des données ???

DupontSymptomes : yTurlututu : sqjSymptomes : yTurlututu : sddAnalyses : xxx

DupondTurlututusqjskSymptom: yyyy Analyses xxxx

TurlututudhjsdAnalyses :xx

DuipontTurlututu : sq

Symptomyyyy Analysesxxxx

Turlututudhjsd

Duhpon

Symptomes : yy Analyses : xxxx

Symptomes : yy

Ch

iru

Sof

t

Con

sultS

oft Psy

chia

Sof

t

Com

ptaS

oft

9Confidentialité CaractéristiquesPlusieurs applications plusieurs formats

plusieurs langages

Redondance de données

Pas de facilité d’interrogation Question développement

Redondance de code

Problèmes Difficultés de gestion Incohérence des données Coûts élevés Maintenance difficile Gestion de pannes ??? Partage des données ??? Confidentialité ???

DupontSymptomes : yTurlututu : sqjSymptomes : yTurlututu : sddAnalyses : xxx

DupondTurlututusqjskSymptom: yyyy Analyses xxxx

TurlututudhjsdAnalyses :xx

DuipontTurlututu : sq

Symptomyyyy Analysesxxxx

Turlututudhjsd

Duhpon

Symptomes : yy Analyses : xxxx

Symptomes : yy

Ch

iru

Sof

t

Con

sultS

oft Psy

chia

Sof

t

Com

ptaS

oft

10

L’approche ‘‘Bases de données’’ (1)

• Modélisation des données Eliminer la redondance de données Centraliser et organiser correctement les données Plusieurs niveaux de modélisation Outils de conception

• Logiciel «Système de Gestion de Bases de Données»Factorisation des modules de contrôle des applications

- Interrogation, cohérence, partage, gestion de pannes, etc…

Administration facilitées des données

11L’approche ‘‘Bases de données’’ (2)

BDVIII - Concurrence d’accès

VII - Gestion des pannes

I- Indépendance Physique

IX - Gestion de la confidentialité

II- Indépendance Logique

VI - Gestion de la cohérence

X - Standards

V - Optimisation des questions

III – Langage de manipulation

IV - Gestion des vues

12

Réel

Modèle conceptuel

• Indépendant du modèle de données

• Indépendant du SGBD

Modèle logique

• Dépendant du modèle de données

• Indépendant du SGBD

Codasyl Relationnel Objet XML

Modèle Physique

• Dépendant du modèle de données

• Dépendant du SGBD

• Organisation physique des données

• Structures de stockage des données

• Structures accélératrices (index)

Modélisation du réel

Médecin effectue Visite

13

Champs, attributs, colonnes

Champs, attributs, colonnes

Champs, attributs, colonnes

Modélisation Relationnelle (1)

Id-D Nom Prénom

1 Dupont

Pierre

2 Durand Paul

3 Masse Jean

…. …….. ……

Relation ou table

Tuples, lignes ou n-uplets

Tuples, lignes ou n-uplets

Tuples, lignes ou n-uplets

Tuples, lignes ou n-uplets

14

Modélisation Relationnelle (2)

DocteursId-D Nom Prénom

1 Dupont

Pierre

2 Durand Paul

3 Masse Jean

…. …….. ……

VisitesId-D Id-P Id-V Date Prix

1 2 1 15 juin 250

1 1 2 12 août 180

2 2 3 13 juillet

350

2 3 4 1 mars 250

PatientsId-P Nom Prénom Ville

1 Lebeau Jacques Paris

2 Troger Zoe Evry

3 Doe John Paris

4 Perry Paule Valenton

…. ……. ……. …….

PrescriptionsId-V Ligne Id-M Posologie

1 1 12 1 par jour

1 2 5 10 gouttes

2 1 8 2 par jour

2 2 12 1 par jour

2 3 3 2 gouttes

…. …. …. …………

MédicamentsId-M Nom Description

1 Aspegic 1000

……………………………..

2 Fluisédal ……………………………..

3 Mucomyst ……………………………..

…. …….. ……………………………..

15

I - Indépendance Physique

• Indépendance des programmes d'applications vis à vis du modèle physique :

– Possibilité de modifier les structures de stockage (fichiers, index, chemins d'accès, …) sans modifier les programmes;

– Ecriture des applications par des non-spécialistes des fichiers et des structures de stockage;

– Meilleure portabilité des applications et indépendance vis à vis du matériel.

16

II - Indépendance Logique

Les applications peuvent définir des vues logiques de la BD

…………..….

PrénomNomId-D

JeanMasse3

PaulDurand2

PierreDupont1

Docteur

…………..….

PrénomNomId-D

JeanMasse3

PaulDurand2

PierreDupont1

Docteur

Visites

2

2

1

1

Id-D

1 mars

13 juillet

12 août

15 juin

Date

250

350

180

250

Prix

4

3

2

1

Id-V

3

2

1

2

Id-P

Visites

2

2

1

1

Id-D

1 mars

13 juillet

12 août

15 juin

Date

250

350

180

250

Prix

4

3

2

1

Id-V

3

2

1

2

Id-P

…….…….….

PaulePerry4

PrénomNomId-P

JohnDoe3

ZoeTroger2

JacquesLebeau1

Patients

…….…….….

PaulePerry4

PrénomNomId-P

JohnDoe3

ZoeTroger2

JacquesLebeau1

Patients

…………….….….

2 gouttes332

12

8

5

12

Id-M

1 par jour

2 par jour

10 gouttes

1 par jour

Posologie

2

1

2

1

Ligne

2

2

1

1

Id-V

Prescription

…………….….….

2 gouttes332

12

8

5

12

Id-M

1 par jour

2 par jour

10 gouttes

1 par jour

Posologie

2

1

2

1

Ligne

2

2

1

1

Id-V

Prescription

……………………………..……..….

DescriptionNomId-M

……………………………..Mucomyst3

……………………………..Fluisédal2

……………………………..Aspegic 10001

Médicament

……………………………..……..….

DescriptionNomId-M

……………………………..Mucomyst3

……………………………..Fluisédal2

……………………………..Aspegic 10001

Médicament

Gestion des médicaments Cabinet du Dr. Masse

Visites

2

1

Id- D

1 mars

15 juin

Date

250

250

Prix

4

1

Id- V

3

2

Id-P

Visites

2

1

Id- D

1 mars

15 juin

Date

250

250

Prix

4

1

Id- V

3

2

Id-P

…….…….….

PrénomNomId-P

ZoeTroger2

JacquesLebeau1

Patients

…….…….….

PrénomNomId-P

ZoeTroger2

JacquesLebeau1

Patients

…………….….….

5

12

Id- M

10 gouttes

1 par jour

Posologie

2

1

Ligne

1

1

Id-V

Prescription

…………….….….

5

12

Id- M

10 gouttes

1 par jour

Posologie

2

1

Ligne

1

1

Id-V

Prescription

……………………………..……..….

DescriptionNomId -M

……………………………..Mucomyst3

……………………………..Fluisédal2

……………………………..Aspegic 10001

Médicament

……………………………..……..….

DescriptionNomId -M

……………………………..Mucomyst3

……………………………..Fluisédal2

……………………………..Aspegic 10001

Médicament

Nombre_Médicaments

Id-M Nom Description Nombre

1 Aspegic 1000 …………………………….. 30

2 Fluisédal …………………………….. 20

3 Mucomyst …………………………….. 230

…. …….. …………………………….. …..

17

Avantages de l’indépendance logique

• Possibilité pour chaque application d'ignorer les besoins des autres (bien que partageant la même BD).

• Possibilité d'évolution de la base de données sans réécriture des applications :– ajout de champs, ajout de relation, renommage de champs.

• Possibilité d'intégrer des applications existantes sans modifier les autres.

• Possibilité de limiter les conséquences du partage : Données confidentielles.

18

III - Manipulation aisée

• La manipulation se fait via un langage déclaratif

– La question déclare l’objectif sans décrire la méthode

– Le langage suit une norme commune à tous les SGBD

– SQL : Structured Query Langage

• Syntaxe (aperçu !)

Select <Liste de champs ou de calculs à afficher>

From <Liste de relations mises en jeu>

Where <Liste de prédicats à satisfaire>

Group By <Groupement éventuel sur un ou plusieurs champs>

Order By <Tri éventuel sur un ou plusieurs champs>

19

Exemple de question SQL (1)

• Nom et description des médicaments de type aspirine

Select Nom, Description

From Médicaments

Where Type = ‘Aspirine’

20

Exemple de question SQL (2)

• Patients parisiens ayant effectués une visite le 15 juin

Select Patients.Nom, Patients.Prénom

From Patients, Visites

Where Patients.Id-P = Visites.Id-P

and Patients.Ville = ’Paris’

and Visites.Date = ’15 juin’

21

Exemple de question SQL (3)

• Dépenses effectuées par patient trié par ordre décroissant

Select Patients.Id-P, Patients.Nom, sum(Prix)

From Patients, Visites

Where Patients.Id-P = Visites.Id-P

GroupBy Patients.Id-P, Patients.Nom

OrderBy sum(Prix) desc

22

IV – Gestion des vues• Les vues permettent d’implémenter l’indépendance

logique en permettant de créer des objets virtuels

• Vue = Question SQL stockée

• Le SGBD stocke la définition et non le résultat

• Exemple : la vue des patients parisiens

Create View Parisiens as (

Select Nom, Prénom

From Patients

Where Patients.Ville = ’Paris’ )

23

Gestion des vuesLe SGBD transforme la question sur les vues en question sur les relations de base

Question Q sur des vues

Définition des vues

Gestionnaire de Vues

Question Q’ sur les relations

de base

24

V –Exécution et Optimisation

• Traduction automatique des questions déclaratives en programmes procéduraux : Utilisation de l’algèbre relationnelle

• Optimisation automatique des questions Utilisation de l’aspect déclaratif de SQL Gestion centralisée des chemins d'accès (index, hachages, …) Techniques d’optimisation poussées

• Economie de l'astuce des programmeurs– milliers d'heures d'écriture et de maintenance de logiciels.

25

Sélection

Patients de la ville de Paris

PatientsId-P Nom Prénom Ville

1 Lebeau Jacques Paris

2 Troger Zoe Evry

3 Doe John Paris

4 Perry Paule Valenton

PatientsId-P Nom Prénom Ville

1 Lebeau Jacques Paris

2 Troger Zoe Evry

3 Doe John Paris

4 Perry Paule Valenton

26

Projection

PatientsId-P Nom Prénom Ville

1 Lebeau Jacques Paris

2 Troger Zoe Evry

3 Doe John Paris

4 Perry Paule Valenton

Nom et prénom des patients

PatientsId-P Nom Prénom Ville

1 Lebeau Jacques Paris

2 Troger Zoe Evry

3 Doe John Paris

4 Perry Paule Valenton

27

JointurePatients

Id-P Nom Prénom Ville

1 Lebeau Jacques Paris

2 Troger Zoe Evry

3 Doe John Paris

4 Perry Paule Valenton

VisitesId-D Id-P Id-V Date Prix

1 2 1 15 juin 250

1 1 2 12 août 180

2 2 3 13 juillet

350

2 3 4 1 mars 250

Id-P Nom Prénom Ville Id-D Id-P Id-V Date Prix

1 Lebeau Jacques Paris 1 1 2 12 août 180

2 Troger Zoe Evry 1 2 1 15 juin 250

2 Troger Zoe Evry 2 2 3 13 juillet

350

3 Doe John Paris 2 3 4 1 mars 250

Patients et leurs visites

28

Exemple de plan d’exécution

Select Patients.Nom, Patients.Prénom

From Patients, Visites

Where Patients.Id-P = Visites.Id-P

and Patients.Ville = ’Paris’

and Visites.Date = ’15 juin’

Patients Visites

29

Plan d’exécution optimisé

Patients Visites

Visites

Patients

30

VI - Intégrité Logique

• Objectif : Détecter les mises à jour erronées

•  Contrôle sur les données élémentaires – Contrôle de types: ex: Nom alphabétique

– Contrôle de valeurs: ex: Salaire mensuel entre 5 et 50kf

• Contrôle sur les relations entre les données– Relations entre données élémentaires:

• Prix de vente > Prix d'achat

– Relations entre objets:• Un électeur doit être inscrit sur une seule liste électorale

31

Contraintes d’intégrité

• Avantages :– simplification du code des applications– sécurité renforcée par l'automatisation– mise en commun des contraintes

• Nécessite :– un langage de définition de contraintes d'intégrité– la vérification automatique de ces contraintes

32

Exemples de contrainte• Contraintes d’intégrité référentielles

DocteursId-D Nom Prénom

1 Dupont

Pierre

2 Durand Paul

3 Masse Jean

…. …….. ……

VisitesId-D Id-P Id-V Date Prix

1 2 1 15 juin 250

1 1 2 12 août 180

2 2 3 13 juillet

350

2 3 4 1 mars 250

PrescriptionsId-V Ligne Id-M Posologie

1 1 12 1 par jour

1 2 5 10 gouttes

2 1 8 2 par jour

2 2 12 1 par jour

2 3 3 2 gouttes

…. …. …. …………

33

VII - Intégrité Physique• Motivations : Tolérance aux fautes

– Transaction Failure : Contraintes d'intégrité, Annulation– System Failure : Panne de courant, Crash serveur ...– Media Failure : Perte du disque– Communication Failure : Défaillance du réseau

• Objectifs :– Assurer l'atomicité des transactions– Garantir la durabilité des effets des transactions commises

• Moyens :– Journalisation : Mémorisation des états successifs des données– Mécanismes de reprise

34

Transaction

Etat cohérent Etat cohérentIncohérence possible...

Begin Commit

Transaction

Begin CEpargne = CEpargne - 3000 CCourant = CCourant + 3000Commit T1

35

Atomicité et Durabilité

ATOMICITE

Begin CEpargne = CEpargne - 3000 CCourant = CCourant + 3000Commit T1

Annuler le débit !!

Panne

DURABILITE

Begin CEpargne = CEpargne - 3000 CCourant = CCourant + 3000Commit T1

S’assurer que le virement a été fait !

Crash disque

36

VIII - Partage des données

BD

• Accès concurrent aux mêmes données

Conflits d’accès !!

37

VIII - Partage des données

BD

• Le SGBD gère les accès concurrents

Chacun à l’impression d’être seul (Isolation)

Cohérence conservée (Verrouillage)

38

IX – Confidentialité• Objectif : Protéger les données de la BD contre des

accès non autorisés

• Deux niveaux :– Connexion restreinte aux usagers répertoriés (mot de passe)

– Privilèges d'accès aux objets de la base

• Usagers : Usager ou groupe d’usagers

• Objets : Relation, Vue, autres objets (procédures, etc.)

39

Puissance des droits SGBD

Id-E Nom Prénom Poste Adresse Ville Salaire

1 Ricks Jim 5485 ………. Paris 230

2 Trock Jack 1254 ………. Versailles 120

3 Lerich Zoe 5489 ………. Chartres 380

4 Doe Joe 4049 ………. Paris 160

Id-E Nom Prénom Poste

1 Ricks Jim 5485

2 Trock Jack 1254

3 Lerich Zoe 5489

4 Doe Joe 4049

Nombred’employés

MasseSalariale

4 890

Service des ressources humaines

Employés(intranet)

Public(internet)

40

X - Standardisation• L’approche bases de données est basée sur plusieurs

standards– Langage SQL (SQL1, SQL2, SQL3)

– Communication SQL CLI (ODBC / JDBC)

– Transactions (X/Open DTP, OSI-TP)

• Force des standards– Portabilité

– Interopérabilté

– Applications multisources…

Architecture des SGBD

Les architectures physiques de SGBD sont très liées au mode de répartition.

— BD centralisée

— BD client/serveur

— BD client/multi-serveurs

— BD répartie

— BD hétérogène

— BD mobile

Le challenge se déplace des Péta-bases aux Pico-bases.

— Péta-bases => parallélisme et grandes mémoires

— Pico-bases => faible empreinte et forte sécurité

42

Architecture centralisée

Terminaux passifs

Mainframe

SGBD

Appli 1 Appli 2 Appli n

réseau

données

Architecture client-serveur

Clients intelligents

serveur

SGBD

Appli 1Appli 2

Appli n réseau

donnéescode

44

Architecture Client-Multiserveurs

SGBD 2

donnéescode

ODBC ODBC

SGBD 1

donnéescode

Appli 1

SQL SQL

SQLSQL

Architecture répartie

SGBD 1

donnéescode

SGBD 2

donnéescode

Appli 1Appli 2

Appli n

Architecture hétérogène

Source 1 : SGBD

donnéescode

Source 2 : serveur Web

donnéescode

Appli 1 Appli 2 Appli n

Médiateur

Architecture mobile

Clients intelligents mobiles

serveur

SGBD

Réseau sans fil

donnéescode

Données répliquées et/ou personnelles

48

Intelligence dans l’architecture x-tiers

Application to application(B2B/ B2C)

Web services

Web services

XML/SOAP

Architecture “n-tiers”

Evolution de l’architecture

Person to person(C2C)

Data echange

PC

PC

Architecture 1-tier

Application to person (B2C)

Web server

Web browser HTTP/HTML

Architecture 2-tiers Architecture 3-tiers

Web browser

Application to person+

(B2C)

HTTP/HTML

Web server

Databases

49

Applications traditionnelles des SGBD

• OLTP (On Line Transaction Processing)– Cible des SGBD depuis leur existence

– Banques, réservation en ligne ...

– Très grand nombre de transactions en parallèle

– Transactions simples

• OLAP (On Line Analytical Processing)– Entrepôts de données, DataCube, Data Mining …

– Faible nombre de transactions

– Transactions très complexes

50

Applications émergentesdes SGBD (1)

• BD et WEB – Serveurs Web dynamiques, sites marchands ...

– Plusieurs profils (OLTP, publication d’informations en ligne, hébergement de données …)

• Challenges majeurs– Gestion de données XML

– Fédération de sources de données hétérogènes

– Grilles de données

– Sécurité des données en ligne

51

Applications émergentesdes SGBD (2)

• BD personnelles ou PME– Comptabilité– Agenda, comptes bancaires, carnet d’adresses, dossiers portables– BD embarquées sur calculateurs ultra-légers (PDA, téléphones

cellulaires, cartes à puce …)

• Challenges majeurs– Gérer la mobilité – S’adapter aux contraintes matérielles du calculateur hôte– Assurer la durabilité des données– Assurer la confidentialité des données

52

Evolution des BD

BD d’entreprise

BD personnelles

BD ‘light’(PDA / Tél.)

PicoDBMScarte à puce

Capacité

Prix

Nombre