Bases de Donn´ ees Avanc´ ees Introduction & Rappel Conception et Mod´ elisation Thierry Hamon Bureau H202 Institut Galil´ ee - Universit´ e Paris 13 & LIMSI-CNRS [email protected]https://perso.limsi.fr/hamon/Teaching/P13/BDA-INFO2-2018-2019/ INFO2 – BDA 1/63
63
Embed
Bases de Donn ees Avanc ees · · 2019-02-19Pr esentation du cours Objectif du cours (4 s eances de 3h) : Notions avanc ees en BD : Conception, PL/SQL, UML, SQL2/3, structures complexes
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Implantation de Bases de DonneesRelationnel-etendu, Oriente Objet (de UML a SQL2/3, JDBC,Java, PL/SQL J...)Optimisation de Requetes, Evaluation de RequetesArchitecture de SGBD, Administration de BD
Autres (Bases de Donnees, Entrepots de donnees, XML)Gros volumes de donnees / Entrepots de donnees / DonneesMultiDimensionnellesDonnees Homogenes & Heterogenes,Donnees Reparties/Web, Donnees de type documents, ...
3/63
Des bases de donneesaux Entrepots de donnees
4/63
HistoriqueGenerations de SGBD
Volu
me
de
don
née
s
Typ
e d
e d
on
née
s
Ind
épen
dan
ce p
hysi
qu
e
Port
ab
ilit
é
Hiérarchies, Réseaux
SGBD 1
1960 − 1970 − 1980
1970 − 1980 − 1990
Relationnels
SGBD 2
SGBD 3
1980 − 1990 − 2000
Avancés
Avancés
SGBD4/5
2004/5 − 2010
2010 − 2020?
Big Data
Puissance
Cohérence
Performance
5/63
HistoriqueApplications BD, ED, FD, ...
Entrepôts de Données
Intégration de Données
Bases de Données
Applications : Paie, Marketing, Financière
(50 tables de quelques milliers de lignes) 50 Mo
Fouille de données
(Analyse du comportement des clients, etc.)
Intégration de plusieurs systèmes d’information nationaux et internationnaux)
Entrepôts de données (grosses masses de données)
(milliers de tables de quelques millions de lignes) > 100 Go
Applications : Gestion des risques, Analyse des ventes
→ Une des taches essentielles des developpeurs de bases dedonnees
Objectif : structuration du domaine d’application afin de
de le representer sous forme de types et de tables
d’accompagner ces structures de contraintes sur les donneesafin de tirer plus de semantique
17/63
Conception du schema des bases
La representation doit etre :
juste pour eviter les erreurs semantiques, notamment dans lesreponses aux requetes ;
complete pour permettre le developpement des programmesd’application souhaites ;
evolutive afin de supporter la prise en compte rapide denouvelles demandes.
18/63
Etapes de conception
Demarche de conception traditionnelle :
par abstractions successives
en descendant depuis les problemes de l’utilisateur vers leSysteme de Gestion de Bases de Donnees.
Cinq etapes :
1 Perception du monde reel et capture des besoins
2 Elaboration du schema conceptuel
3 Conception du schema logique
4 Affinement du schema logique
5 Elaboration du schema physique
19/63
Remarques
Etape 1 : plutot relative au domaine du genie logiciel
Etapes 2, 3, 4 et 5 : relative au domaine des bases de donnees
20/63
Etape 1Perception du monde reel et capture des besoins
Etude des problemes des utilisateurs
Comprehension de leurs besoins
→ Mise en place d’entretiens, d’analyses des flux d’information etdes processus metier
Difficulte : comprehension du probleme dans son ensemble
→ Realisation des etudes de cas partiels par les concepteurs
Resultat : ensemble de vues ou schemas externes devant etreintegres dans l’etape suivante
Vues exprimees dans un modele de de donnees : de typeentite-association ou objet, selon la methode choisie
21/63
Etape 2
Elaboration du schema conceptuel
Integration des schemas externes obtenus a l’etape precedente
Chaque composant est un schema conceptuel : diagrammeentite-association ou diagramme de classes
Resultat : modele de probleme representant une partie del’application
Difficulte : integration de toutes les parties dans un schemaconceptuel global complet, non redondant et coherent
NB : des allers et retours avec l’etape precedente sont souventnecessaires
22/63
Etape 3Conception du schema logique
Transformation du schema conceptuel en structures de donneessupportees par le systeme choisi : le schema logique.
Avec un SGBD relationnel : passage a des tables.
Avec un SGBD relationnel-objet : Generation de types et detables,NB : les types sont reutilisables
Avec un SGBD objet : generation de classes et de associations
NB : Cette etape peut etre completement automatisee.
23/63
Etape 4Affinement du schema logique
Verification : le schema logique est-il un � bon � schema ?
Definition en premiere approximation : un � bon schema� est un schema sans oublis ni redondances d’informations
Plus precisement : un schema est � bon � si le modelerelationnel associe respecte au moins la troisieme formenormale et la forme normale de Boyce-Codd (voir plus loin)
Objectif en relationnel : regrouper ou decomposer les tablesde maniere a representer fidelement le monde reel modelise
24/63
Etape 5
Elaboration du schema physique
Etape necessaire pour obtenir de bonnes performances
Prise en compte de toutes les transactions concernant lesapplications traiteesPermet de determiner les acces frequents
Choix des bonnes structures physiques : groupement oupartitionnement de tables, index, etc.point essentiel pour obtenir de bonnes performances
25/63
Elaboration du schema conceptuel
Modelisation du probleme en utilisant les specifications des besoinsobtenues a l’etape 1 (capture des besoins)
Deux possibilites :
utilisation du formalisme Entite Relation (ou EntiteAssociation)→ production d’un diagramme ER/EA
utilisation du formalisme UML→ production de classe
Independance du modele conceptuel par rapport au schemaphysique
26/63
Phases d’elaboration duschema conceptuel
Identification des entites ou classes
Identification des associations
Identification des attributs pour chacune des entites ou classes
Definition des identifiants
27/63
Identification des entites ou classes
Entites : element abstrait ou concret (objet, evenement, etc.)reconnu distinctementExemples : Jean Dupont, Michel Durant
Type-entites : Ensemble des entites ayant les memescaracteristiquesExemple : Personne(nom, prenom)
NB : Par abus de langage, on parle souvent d’entites a laplace de type-entites
Dans l’etape 1, il s’agit de la description des elements
28/63
Identification des associations
Association : Lien logique entre deux entites
Type-Association : Ensemble d’association ou de relationspossedant les memes caracteristiques.
Association/type-association : meme abus de langage
A l’etape 1 : une phrase simple reliant deux entitesExemple : un professeur est en charge de cours (lien entreles entites professeur et cours)
Plusieurs types d’association existent
29/63
Types d’association
unaire : relation au sein d’une meme entiteExemple : un employe supervise un employe
binaire : relation entre deux entites (differentes)Exemple : un client passe plusieurs commandes
ternaire : relation entre trois entites (differentes)Exemple : un internaute note un film a differentes date (onveut conserver l’historique des notes)
30/63
Cardinalite d’un type-association
Cardinalite : nombre minimal et maximal de fois qu’une entitepeut intervenir dans une association de ce type
Exemple : un client peut commander 1 a n produits
Remarques :
la cardinalite minimal doit etre inferieure a la cardinalitemaximalela cardinalite doit etre associee a chaque extremite de larelation
31/63
Cardinalite minimale/maximale
Cardinalite minimale :
0 : une entite peut exister tout en etant impliquee dansaucune association1 : une entite ne peut exister que si elle est impliquee dans aumoins une associationn : une entite ne peut exister que si elle est impliquee dansplusieurs associations (cas rare,a eviter car cela pose desproblemes)
Cardinalite maximale :
0 : une entite ne peut pas etre impliquee dans une association(normalement inexistant sinon probleme de conception)1 : une entite peut etre impliquee dans au maximum uneassociationn : une entite peut etre impliquee dans plusieurs associations
32/63
Identification des attributs
Attribut : caracteristique associee a une entiteExemples : nom, prenom, age
Domaine associe a un attribut : ensemble des valeurs possibles
Chaque attribut doit posseder une valeur compatible avec sondomaine
Remarque : Eviter absolument les attributs calcules.Toujours utiliser des donnees primaires – les attributs quiservent a les calculer
33/63
Definition de l’identifiant
Identifiant : liste des attributs devant avoir une valeur uniquechaque entite
Exemple : numero d’immatriculation d’une voiture, numero desecurite sociale
Remarques :
On utilise plutot le terme cle que identifiantChaque type doit posseder un identifiant (forme d’un ouplusieurs attributs)L’identifiant d’une association est la concatenation desidentifiants des entites liesNB : on peut definir un identifiant plus naturel
34/63
Remarques sur la conception
Un attribut ne peut etre partage entre deux entites ouassociations (probleme de redondance)
En cas de difficulte a choisir entre entite et association (parexemple, mariage) : utiliser le contexte pour y repondre
En cas de difficulte a trouver un identifiant pour untype-entite : ne s’agirait-il pas une association ?
Association dont toutes les extremites ont une cardinalite 1,1 :l’association et les entites liees ne correspondraint-ils pas aune seule entite ?
35/63
Entite-relation et UML
Formalisme ER :
Formalisme UML :
36/63
Retour sur les cardinalitesInterpretation – Formalisme ER
(une des cardinalites est volontairement absente)
Tout etudiant participe au moins une fois a l’association est inscrit.Tout etudiant est inscrit dans au moins une formation
Autrement dit : une instance d’etudiant peut etre associee aplusieurs formations
37/63
Retour sur les cardinalitesGeneralisation
Formalisme ER :
Interpretations :
A est lie 0 a n fois a B
La connaissance de B permet de definir A
La cle de B definit l’instance de A
Formalisme UML :
38/63
ER ou UML ?
Si conception de bases de donnees : utilisation du modeleentite/relationOn met l’accent sur le systeme d’information (stockage,traitement, reception, diffusion de l’information)
Si conception objet et programmation : utilisation de UML(2 – incluant l’heritage)On met l’acent sur les structures de donnees et laprogrammation
39/63
Elaboration du schema logique
Transformation du modele conceptuel en une structure de donneesbasee sur un modele de donnees specifique (par exemple, modelerelationnel)
Realisation de la transformation a l’aide de regles formelles→ Possibilite d’automatisation de cette etape (Objecteering,Rational Rose)
Independant de la couche physique
Resultat : modele logique de la base de donnees
40/63
Passage au relationnel
Implementation des entites et associations sous forme detables
Les attributs correspondent aux colonnes des tables
le nom de l’attribut est le nom de la colonnel’ensemble des valeurs possibles est le domaine
Une relation est en deuxieme forme normale si et seulement si :
elle est en premiere forme normale
tout attribut non cle est totalement dependant de toute la cleAutrement dit, une des trois conditions doit etre respectee :
La cle primaire n’est formee que d’un seul attributLa cle primaire contient tous les attributs de la tableSi la cle a plus d’un attribut, une dependance fonctionnelle nedoit jamais exister entre une partie seulement de la cle et unautre attribut de la table.
Extension plus rigide de la troisieme forme normale (definiepar R.F. Boyce et E.F. Codd – en partant du constat que la3FN comportait certaines anomalies)Une relation est en forme normale de Boyce-Codd si etseulement si :aucun attribut faisant partie de la cle ne depend d’un at-tribut ne faisant pas partie de la cle primaire
Remarques :
Un modele relationnel en FNBC est considere comme etant dequalite suffisante pour une l’implantationLes cas de relations en 3FN qui ne sont pas deja en FNBCsont tres rares
51/63
Forme normale de Boyce-Codd(BCNF)
Exemple 1 :
R(A, B*, C*, D)
Avec les dependances : B,C → A ; B,C → D ; D → B,(ce qui entraine de nombreuses redondances)On propose les relations :
Indexer, denormaliser, grouper, partitionner les tables
Resultat : modele physique optimise de la base de donnees
54/63
ExempleSchema relationnel
COURS ( NUM COURS∗ , NOMC, NBHEURES, ANNEE )
PROFESSEURS ( NUM PROF∗ , NOMP, SPECIALITE , DATE ENTREE ,DER PROM, SALAIRE BASE , SALAIRE ACTUEL )
CHARGE( NUM PROF∗ , NUM COURS∗ )
55/63
Schema physique (SQL2)
c r e a t e t a b l e COURS(NUM COURS NUMBER( 2 ) NOT NULL ,NOMC VARCHAR( 2 0 ) NOT NULL ,NBHEURES NUMBER( 2 ) ,ANNE NUMBER( 1 ) ,c o n s t r a i n t PK COURS pr imary key (NUM COURS) ) ;
c r e a t e t a b l e PROFESSEURS(NUM PROF NUMBER( 4 ) NOT NULL ,NOMP VARCHAR2( 2 5 ) NOT NULL ,SPECIALITE VARCHAR2( 2 0 ) ,DATE ENTREE DATE,DER PROM DATE,SALAIRE BASE NUMBER,SALAIRE ACTUEL NUMBER,c o n s t r a i n t PK PROFESSEURS pr imary key (NUM PROF) ) ;
56/63
Schema physique (SQL2)
c r e a t e t a b l e CHARGE(NUM PROF NUMBER( 4 ) NOT NULL ,NUM COURS NUMBER( 4 ) NOT NULL ,c o n s t r a i n t PK CHARGE pr imary key (NUM COURS, NUM PROF) ) ;
a l t e r t a b l e CHARGEadd c o n s t r a i n t FK CHARGE COURS
f o r e i g n key (NUM COURS)r e f e r e n c e s COURS (NUM COURS ) ;
a l t e r t a b l e CHARGEadd c o n s t r a i n t FK CHARGE PROFESSEUR
f o r e i g n key (NUM PROF)r e f e r e n c e s PROFESSEURS (NUM PROF ) ;
57/63
Schema physique (SQL2)Ajout de contraintes
c r e a t e t a b l e COURS(NUM COURS NUMBER( 2 ) ,NOMC VARCHAR( 2 0 ) ,NBHEURES NUMBER( 2 ) ,ANNE NUMBER( 1 ) ,c o n s t r a i n t PK COURS pr imary key (NUM COURS) ,c o n s t r a i n t NN COURS NOMC check (NOMC I S NOT NULL ) ) ;
c r e a t e t a b l e PROFESSEURS(NUM PROF NUMBER( 4 ) ,NOMP VARCHAR2( 2 5 ) ,SPECIALITE VARCHAR2( 2 0 ) ,DATE ENTREE DATE,DER PROM DATE,SALAIRE BASE NUMBER,SALAIRE ACTUE NUMBER,c o n s t r a i n t PK PROFESSEURS pr imary key (NUM PROF) ,c o n s t r a i n t NN PROFESSEURS NOMP check (NOMP I S NOT NULL ) ) ;
58/63
Schema physique (SQL2)Ajout de contraintes
c r e a t e t a b l e CHARGE(NUM PROF NUMBER( 4 ) ,NUM COURS NUMBER( 4 ) , ,c o n s t r a i n t PK CHARGE pr imary key (NUM COURS, NUM PROF) ) ;
a l t e r t a b l e CHARGEadd c o n s t r a i n t FK CHARGE COURS
f o r e i g n key (NUM COURS)r e f e r e n c e s COURS (NUM COURS ) ;
a l t e r t a b l e CHARGEadd c o n s t r a i n t FK CHARGE PROFESSEUR
f o r e i g n key (NUM PROF)r e f e r e n c e s PROFESSEURS (NUM PROF ) ;
59/63
Schema relationnel-objetvoir plus tard en detail
COURS ( NUM COURS, NOMC, NBHEURES, ANNEE )
PROFESSEURS ( NUM PROF, NOMP, SPECIALITE , DATE ENTREE ,DER PROM, SALAIRE BASE , SALAIRE ACTUEL ,Ensemble−de (COURS) )
60/63
Schema physique SQL3voir plus tard en detail
c r e a t e t y p e c o u r s t y p e as o b j e c t( num cours number ( 2 ) , nomc v a r c h a r 2 ( 2 0 ) , n b h e u r e s number ( 2 ) ,
annee number ( 1 ) )/c r e a t e t y p e l e s c o u r s t y p e as t a b l e o f c o u r s t y p e/c r e a t e t y p e p r o f e s s e u r t y p e as o b j e c t( num prof number ( 4 ) , nom v a r c h a r 2 ( 2 5 ) , s p e c i a l i t e v a r c h a r 2 ( 2 0 ) ,
c o u r s l e s c o u r s t y p e . . . )/c r e a t e t a b l e p r o f e s s e u r o f p r o f e s s e u r t y p e( pr imary key ( num prof ) )n e s t e d t a b l e c o u r s s t o r e as tabemp/
61/63
Bilan
Rappels sur
les langages de definition des donnees, de manipulation desdonnees (et du controle des donnees)
la bonne modelisation et la bonne conception d’une base dedonnees (des differents schemas)
A venir :
utilisation d’un langage procedural sur le BD (PL-SQL)
BD/SQL relationnel-objet et oriente-objet
62/63
Sources des transparents
M.P. Dorville/F. Goasdoue, LRI, Universite Paris Sud