Your SlideShare is downloading. ×
Cours bda1
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Cours bda1

589

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
589
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
49
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Bases de Donn´es Avanc´es e e Introduction & Rappel Conception et Mod´lisation e Thierry Hamon Bureau H202 - Institut Galil´e e T´l. : 33 1.48.38.35.53 e Bureau 150 – LIM&BIO – EA 3969 Universit´ Paris 13 - UFR L´onard de Vinci e e 74, rue Marcel Cachin, F-93017 Bobigny cedex T´l. : 33 1.48.38.73.07, Fax. : 33 1.48.38.73.55 e thierry.hamon@univ-paris13.fr http://www-limbio.smbh.univ-paris13.fr/membres/hamon/BDA-20102011 INFO2 – BDA1/61
  • 2. Sources des transparents M.P. Dorville/F. Goasdou´, LRI, Universit´ Paris Sud e e V. Mogbil, LIPN, Universit´ Paris Nord e J. Ullman http://infolab.stanford.edu/~ullman/ C. Rouveirol, LIPN, Universit´ Paris Nord e F. Boufares, LIPN, Universit´ Paris Nord e2/61
  • 3. Pr´sentation du cours e Pr´sentation du cours e Objectif du cours (12 s´ances de 1h30) : e Des Bases de Donn´es aux Entrepˆts de Donn´es Exploitation e o e Intelligente des Donn´es e Travaux Pratiques (12 s´ances de 1h30) : e Mise en œuvre de concepts vus en cours (PL/SQL, UML → SQL2/3, int´grit´ des donn´es, etc.) e e e3/61
  • 4. Programme des enseignements Pr´sentation du cours e Rappels de SQL Conception & Mod´lisation de Bases de Donn´es e e M´ta-Mod´lisation, Formalismes utilis´s (ER, EER, UML, ...) e e e Expression & Coh´rence des contraintes (SQL2/3, PL/SQL, e OCL, ...) Implantation de Bases de Donn´es e Relationnel-´tendu, Orient´ Objet (de UML ` SQL2/3, JDBC, e e a Java, PL/SQL J...) Optimisation de Requˆtes, Evaluation de Requˆtes e e Architecture de SGBD, Administration de BD Autres (Bases de Donn´es, Entrepˆts de donn´es, XML) e o e Gros volumes de donn´es / Entrepˆts de donn´es / Donn´es e o e e MultiDimensionnelles Donn´es Homog`nes & H´t´rog`nes, e e ee e Donn´es R´parties/Web, Donn´es de type documents, ... e e e4/61
  • 5. Des bases de donn´es aux Entrepˆts de donn´es du cours e o eesentation Pr´5/61
  • 6. Historique Historique G´n´rations de SGBD e e Indépendance physique Volume de données SGBD4/5 Type de données Avancés 2004/5 − 2010 Portabilité SGBD 3 Avancés 1980 − 1990 − 2000 SGBD 2 Relationnels 1970 − 1980 − 1990 SGBD 1 Hiérarchies, Réseaux 1960 − 1970 − 1980 Puissance Performance Cohérence6/61
  • 7. Historique Historique Exemples de SGBD SGBD4/5 ORACLE 9i, 10g, 11 DB2, ... Indépendance physique Volume de données XML, ... Type de données SGBD 3 ORACLE 7/8, Portabilité INGRES, DB2, Sybase, Verssant Enjin (O2), ObjectStore, Orlent, MySQL, PostGreSQL, SGBD 2 SQLServer, ACCESS, ... ORACLE 5/6 INGRES, DB2, ... Bases de données SGBD 1 Entrepôts de données COADSYL, Intégration de Données SOCRATE, ... Puissance Performances Cohérence7/61
  • 8. Historique Historique Applications BD, ED, FD Volume de données Type de données Fouille de données (Analyse du comportement des clients, etc.) Entrepôts de données (grosses masses de données) Intégration de plusieurs systèmes d’information nationaux et internationnaux) (milliers de tables de quelques millions de lignes) > 100 Go Applications : Gestion des risques, Analyse des ventes (100 tables de quelques millions de lignes) 2 Go Bases de Données Entrepôts de Données Intégration de Données Applications : Paie, Marketing, Financière (50 tables de quelques milliers de lignes) 50 Mo Performance8/61
  • 9. Historique Historique Applications BD, ED, FD Volume de données Type de données Entrepôts de données (OLTP : < 10 secondes) (OLAP < 1 heure) ( MV : agrégation, ...) (Batch : Quotidien ou mensuel < 1h) Grosse volumétrie : travail d’optimisation et suivi des activités du DWh nécéssaire Par expérience, certains traitements ne se terminent pas au bout de quelques jours Nécessité de modifications techniques et fonctionnelles Applications : Gestion des risques, Analyse des ventes (Batch : < 1 heure) Bases de Données Entrepôts de Données Intégration de Données Applications : Paie, Marketing, Financière (OLTP: quelques secondes) (Batch : < 1 heure) Performance9/61
  • 10. Historique Historique Structure et type de donn´es e Relationnelle & objet Type de données Indépendance physique Volume de données COMPLEXE Type de données Relations Structure de données Portabilité TABULAIRE Hiérarchique Structure de données & Réseau en RESEAU Structure HIERARCHIQUE des données Puissance Performance Cohérence10/61
  • 11. Commandes SQL Plusieurs sortes de commandes SQL parmi lesquelles : LDD (langage de d´finition de donn´es), e e LMD (langage de manipulation des donn´es) c’est-`-dire du e a LMJ (langage de mise ` jour) et du LID (langage a d’interrogation des donn´es), e LCD (langage de contrˆle des donn´es). o e11/61
  • 12. Le Langage de D´finition de Donn´es (LDD)de Donn´es : LDD e Le e Langage de D´finition e e Ensemble de commandes qui d´finit une base de donn´es et e e les objets qui la composent la d´finition d’un objet inclut e sa cr´ation: CREATE e sa modification ALTER sa suppression DROP12/61
  • 13. Le langage de manipulation de donn´es manipulation de donn´es : LMD Le langage de : LMD e e Ensemble de commandes qui permet la consultation et la mise ` jour des objets cr´´s par le langage de d´finition de donn´es a ee e e Consultation : SELECT La mise ` jour inclut : a l’insertion de nouvelles donn´es : INSERT e la modification de donn´es existantes : UPDATE e la suppression de donn´es existantes : DELETE e13/61
  • 14. Le langage de manipulation de donn´es manipulation de donn´es : LMD Le langage de : LMD e e Exemple SELECT < l i s t e champ ( s )> FROM < l i s t e n o m t a b l e ( s )> [WHERE c o n d i t i o n ( s ) ] [ o p t i o n s ] ; INSERT INTO <n o m t a b l e > [( < l i s t e champ ( s ) >)] VALUES (< l i s t e v a l e u r s >); UPDATE <n o m t a b l e > SET <champ> = <e x p r e s s i o n > [WHERE < l i s t e c o n d i t i o n ( s )> ] ; DELETE FROM <n o m t a b l e > [WHERE < l i s t e c o n d i t i o n ( s )> ] ;14/61
  • 15. Le langage de contrˆle de donn´eslangage de contrˆle de donn´es : LCD o e Le : LCD o e Ensemble de commandes de contrˆle d’acc`s aux donn´es o e e Le contrˆle d’acc`s inclut : o e l’autorisation ` r´aliser une op´ration : GRANT a e e l’interdiction de r´aliser une op´ration : DENY e e Annulation d’une commande de contrˆle pr´c´dente : REVOKE o e e l’autorisation ` modifier des enregistrements : UPDATE a l’interdiction de modifier des enregistrements : READ (consultation en lecture seulement) l’autorisation ` supprimer des enregistrements : DELETE a15/61
  • 16. Conception, D´veloppement, Utilisation, Administration e Introduction 1 Etape conceptuelle : Conception et Mod´lisation de bases de e donn´es e Utilisation de M´thodes, Mod`les, Formalismes e e Mod`le Entit´-Association E/A / Mod`le Entit´-Association e e e e ´tendu e Mod`les Objet, Formalisme UML e Power AMC, Power Designer WinDev, Oracle Designer Rational Rose, ... 2 Etape logique : Implantation d’une base de donn´es e Mod`le Relationnel / Mod`le Objet-Relationnel / Mod`le e e e Objet Optimisation du sch´ma (Normalisation, D´normalisation ...) e e16/61
  • 17. Conception, D´veloppement, Utilisation, Administration e Introduction 3 Etape physique : SGBD Relationnel / SGBD Objet-Relationnel / SGBD Orient´ e Objet Langages ( SQL, PL/SQL, PRO*C, JDBC, Java, ...) Optimisations (Groupement, Index, ...) Administration Oracle, DB2, My SQL 4 Logiciels (SGBD, Interfaces, ...) & Mat´riels e17/61
  • 18. Conception du sch´ma des bases e Introduction → Une des tˆches essentielles des d´veloppeurs de bases de a e donn´es e Objectif : structuration du domaine d’application afin de de le repr´senter sous forme de types et de tables e d’accompagner ces structures de contraintes sur les donn´es e afin de tirer plus de s´mantique e18/61
  • 19. Conception du sch´ma des bases e Introduction La repr´sentation doit ˆtre : e e juste pour ´viter les erreurs s´mantiques, notamment dans les e e r´ponses aux requˆtes ; e e compl`te pour permettre le d´veloppement des programmes e e d’application souhait´s ; e ´volutive afin de supporter la prise en compte rapide de e nouvelles demandes.19/61
  • 20. Etapes de conception Introduction D´marche de conception traditionnelle : e par abstractions successives en descendant depuis les probl`mes de l’utilisateur vers le e Syst`me de Gestion de Bases de Donn´es. e e Cinq ´tapes : e 1 Perception du monde r´el et capture des besoins e 2 ´ Elaboration du sch´ma conceptuel e 3 Conception du sch´ma logique e 4 Affinement du sch´ma logique e 5 ´ Elaboration du sch´ma physique e20/61
  • 21. Remarques Introduction ´ Etape 1 : plutˆt relative au domaine du g´nie logiciel o e ´ Etapes 2, 3, 4 et 5 : relative au domaine des bases de donn´es e21/61
  • 22. Etape 1 : Perception du monde r´el et capture des besoins e Introduction Etude des probl`mes des utilisateurs e Compr´hension de leurs besoins e → Mise en place d’entretiens, d’analyses des flux d’information et des processus m´tier e Difficult´ : compr´hension du probl`me dans son ensemble e e e → R´alisation des ´tudes de cas partiels par les concepteurs e e R´sultat : ensemble de vues ou sch´mas externes devant ˆtre e e e int´gr´s dans l’´tape suivante e e e Vues exprim´es dans un mod`le de de donn´es : de type e e e entit´-association ou objet, selon la m´thode choisie e e22/61
  • 23. ´ Etape 2 : Elaboration du sch´ma conceptuel e Introduction Int´gration des sch´mas externes obtenus ` l’´tape pr´c´dente e e a e e e Chaque composant est un sch´ma conceptuel : diagramme e entit´-association ou diagramme de classes e R´sultat : mod`le de probl`me repr´sentant une partie de e e e e l’application Difficult´ : int´gration de toutes les parties dans un sch´ma e e e conceptuel global complet, non redondant et coh´rent e NB : des allers et retours avec l’´tape pr´c´dente sont souvent e e e n´cessaires e23/61
  • 24. Etape 3 : Conception du sch´ma logique e Introduction Transformation du sch´ma conceptuel en structures de donn´es e e support´es par le syst`me choisi : le sch´ma logique. e e e Avec un SGBD relationnel : passage ` des tables. a Avec un SGBD relationnel-objet : G´n´ration de types et de e e tables, NB : les types sont r´utilisables e Avec un SGBD objet : g´n´ration de classes et de associations e e NB : Cette ´tape peut ˆtre compl`tement automatis´e. e e e e24/61
  • 25. Etape 4 : Affinement du sch´ma logique e Introduction V´rification : le sch´ma logique est-il un e e bon sch´ma ? e D´finition en premi`re approximation : un bon sch´ma e e e est un sch´ma sans oublis ni redondances d’informations e Plus pr´cis´ment : un sch´ma est bon si le mod`le e e e e relationnel associ´ respecte au moins la troisi`me forme e e normale et la forme normale de Boyce-Codd (voir plus loin) Objectif en relationnel : regrouper ou d´composer les tables e de mani`re ` repr´senter fid`lement le monde r´el mod´lis´ e a e e e e e25/61
  • 26. ´ Etape 5 : Elaboration du sch´ma physique e Introduction Etape n´cessaire pour obtenir de bonnes performances e Prise en compte de toutes les transactions concernant les applications trait´es e Permet de d´terminer les acc`s fr´quents e e e Choix des bonnes structures physiques : groupement ou partitionnement de tables, index, etc. point essentiel pour obtenir de bonnes performances26/61
  • 27. ´ Elaboration du sch´ma conceptuel e ´ Elaboration du sch´ma conceptuel e Mod´lisation du probl`me en utilisant les sp´cifications des besoins e e e obtenues ` l’´tape 1 (capture des besoins) a e Deux possibilit´s : e utilisation du formalisme Entit´ Relation (ou Entit´ e e Association) → production d’un diagramme ER/EA utilisation du formalisme UML → production de classe Ind´pendance du mod`le conceptuel par rapport au sch´ma e e e physique27/61
  • 28. Phases d’´laboration du sch´ma conceptuel sch´ma conceptuel e e ´ Elaboration du e Identification des entit´s ou classes e Identification des associations Identification des attributs pour chacune des entit´s ou classes e D´finition des identifiants e28/61
  • 29. Identification des entit´s ou classes du sch´ma conceptuel e ´ Elaboration e Entit´s : ´l´ment abstrait ou concret (objet, ´v`nement, etc.) e ee e e reconnu distinctement Exemples : Jean Dupont, Michel Durant Type-entit´s : Ensemble des entit´s ayant les mˆmes e e e caract´ristiques e Exemple : Personne(nom, prenom) NB : Par abus de langage, on parle souvent d’entit´s ` la e a place de type-entit´s e Dans l’´tape 1, il s’agit de la description des ´l´ments e ee29/61
  • 30. Identification des associations Elaboration du sch´ma conceptuel ´ e Association : Lien logique entre deux entit´s e Type-Association : Ensemble d’association ou de relations poss`dant les mˆmes caract´ristiques. e e e Association/type-association : mˆme abus de langage e A l’´tape 1 : une phrase simple reliant deux entit´s e e Exemple : un professeur est en charge de cours (lien entre les entit´s professeur et cours) e Plusieurs types d’association existent30/61
  • 31. Types d’association ´ Elaboration du sch´ma conceptuel e unaire : relation au sein d’une mˆme entit´ e e Exemple : un employ´ supervise un employ´ e e binaire : relation entre deux entit´s (diff´rentes) e e Exemple : un client passe plusieurs commandes ternaire : relation entre trois entit´s (diff´rentes) e e Exemple : un internaute note un film ` diff´rentes date (on a e veut conserver l’historique des notes)31/61
  • 32. Cardinalit´ d’un type-association e ´ Elaboration du sch´ma conceptuel e Cardinalit´ : nombre minimal et maximal de fois qu’une entit´ e e peut intervenir dans une association de ce type Exemple : un client peut commander 1 ` n produits a Remarques : la cardinalit´ minimal doit ˆtre inf´rieure ` la cardinalit´ e e e a e maximale la cardinalit´ doit ˆtre associ´e ` chaque patte de la relation e e e a32/61
  • 33. Cardinalit´ minimale/maximaleElaboration du sch´ma conceptuel e ´ e Cardinalit´ minimale : e 0 : une entit´ peut exister tout en ´tant impliqu´e dans e e e aucune association 1 : une entit´ ne peut exister que si elle est impliqu´e dans au e e moins une association n : une entit´ ne peut exister que si elle est impliqu´e dans e e plusieurs associations (cas rare,` ´viter car cela pose des ae probl`mes) e Cardinalit´ maximale : e 0 : une entit´ ne peut pas ˆtre impliqu´e dans une association e e e (normalement inexistant sinon probl`me de conception) e 1 : une entit´ peut ˆtre impliqu´e dans au maximum une e e e association n : une entit´ peut ˆtre impliqu´e dans plusieurs associations e e e33/61
  • 34. Identification des attributs ´ Elaboration du sch´ma conceptuel e Attribut : caract´ristique associ´e ` une entit´ e e a e Exemples : nom, pr´nom, age e Domaine associ´ ` un attribut : ensemble des valeurs possibles ea Chaque attribut doit poss`der une valeur compatible avec son e domaine Remarque : Eviter absolument les attributs calcul´s. e Toujours utiliser des donn´es primaires – les attributs qui e servent ` les calculer a34/61
  • 35. D´finition de l’identifiant e ´ Elaboration du sch´ma conceptuel e Identifiant : liste des attributs devant avoir une valeur unique chaque entit´e Exemple : num´ro d’immatriculation d’une voiture, num´ro de e e s´curit´ sociale e e Remarques : On utilise plutˆt le terme cl´ que identifiant o e Chaque type doit poss`der un identifiant (form´ d’un ou e e plusieurs attributs) L’identifiant d’une association est la concat´nation des e identifiants des entit´s li´s e e NB : on peut d´finir un identifiant plus naturel e35/61
  • 36. Remarques sur la conception ´ Elaboration du sch´ma conceptuel e Un attribut ne peut ˆtre partag´ entre deux entit´s ou e e e associations (probl`me de redondance) e En cas de difficult´ ` choisir entre entit´ et association (par ea e exemple, mariage) : utiliser le contexte pour y r´pondre e En cas de difficult´ ` trouver un identifiant pour un ea type-entit´ : ne s’agirait-il pas une association ? e Association dont toutes les pattes ont une cardinalit´ 1,1 : e l’association et les entit´s li´es ne correspondraint-ils pas ` e e a une seule entit´ ? e36/61
  • 37. Entit´-relation et UML e ´ Elaboration du sch´ma conceptuel e Formalisme ER : Formalisme UML :37/61
  • 38. Retour sur les cardinalit´s e ´ Elaboration du sch´ma conceptuel e interpr´tation – Formalisme ER e (une des cardinalit´s est volontairement absente) e Tout ´tudiant participe au moins une fois ` l’association est inscrit. e a Tout ´tudiant est inscrit dans au moins une formation e Autrement dit : ` une instance d’´tudiant peut ˆtre associ´ ` a e e ea plusieurs formations38/61
  • 39. Retour sur les cardinalit´s e ´ Elaboration du sch´ma conceptuel e G´n´ralisation e e Formalisme ER : Interpr´tations : e A est li´ 0 ` n fois ` B e a a La connaissance de B permet de d´finir A e La cl´ de B d´finit l’instance de A e e Formalisme UML :39/61
  • 40. ER ou UML ? ´ Elaboration du sch´ma conceptuel e Si conception de bases de donn´es : utilisation du mod`le e e entit´/relation e On mets l’accent sur le syst`me d’information (stockage, e traitement, r´ception, diffusion de l’information) e Si conception objet et programmation : utilisation de UML(2 – incluant l’h´ritage) e On mets l’acent sur les structures de donn´es et la e programmation40/61
  • 41. ´ Elaboration du sch´ma logique e ´ Elaboration du sch´ma logique e Transformation du mod`le conceptuel en une structure de donn´es e e bas´e sur un mod`le de donn´es sp´cifique (par exemple, mod`le e e e e e relationnel) R´alisation de la transformation ` l’aide de r`gles formelles e a e → Possibilit´ d’automatisation de cette ´tape (Objecteering, e e Rational Rose) Ind´pendant de la couche physique e R´sultat : mod`le logique de la base de donn´es e e e41/61
  • 42. Passage au relationnel ´ Elaboration du sch´ma logique e Impl´mentation des entit´s et associations sous forme de e e tables Les attributs correspondent aux colonnes des tables le nom de l’attribut est le nom de la colonne l’ensemble des valeurs possibles est le domaine Exemple : Professeur(numProf, nom, prenom) Cours(nomCours, nom) Charge(numProf, numCours)42/61
  • 43. Passage au relationnel ´ Elaboration du sch´ma logique e Traduction des associations : R`gle de base : repr´sentation des associations par une table e e dont le sch´ma est le nom de l’association e la liste des cl´s des entit´s participantes suivie des attributs de e e l’association Am´lioration : Regrouper les associations 1..n avec la classe e cible Exemple : Voiture(numV, Marque, modele) Possede(numProp, numV, Date) → les deux tables peuvent ˆtre regroup´es si toutes les e e voitures n’ont qu’un et un seul propri´taire e43/61
  • 44. Affiner les requˆtes e Affinement des requˆtes e respecter les formes normales Pourquoi normaliser ? pour limiter les redondances de donn´es e pour limiter les pertes de donn´es e pour limiter les incoh´rences au sein des donn´es e e pour am´liorer les performances des traitements e44/61
  • 45. Formes normales Affinement des requˆtes e 8 formes normales : Formes normales 1 ` 3 a Forme normale de Boyce-Codd Formes normales de 4/5(/6) Forme normale de domaine-cl´ e Objectifs des trois premi`res formes normales : permettre la e d´composition de relations sans perdre d’informations e Une relation en forme normale de niveau N est forc´ment de forme e normale de niveau N − 145/61
  • 46. Premi`re forme normale (1FN) e Affinement des requˆtes e Une relation est en premi`re forme normale si tous ses attributs e contiennent des valeurs simples et non-d´composables (utiliser une liste ou une table e externe) non-r´p´titives e e constantes dans le temps (date de naissance plutˆt que l’ˆge) o a46/61
  • 47. Premi`re forme normale (1FN) e Affinement des requˆtes e Vol(NoVol*, CodeAeroDep, CodeAeroArr, HeureDep, HeureArr, Jours) devient Vol(NoVol*, CodeAeroDep, CodeAeroArr, HeureDep, HeureArr, Jour) Vol(NoVol*, Jour)47/61
  • 48. Deuxi`me forme normale (2FN) e Affinement des requˆtes e Une relation est en deuxi`me forme normale si et seulement si : e elle est en premi`re forme normale e tout attribut non cl´ est totalement d´pendant de toute la cl´ e e e Autrement dit, une des trois conditions doit ˆtre respect´e : e e La cl´ primaire n’est form´e que d’un seul attribut e e La cl´ primaire contient tous les attributs de la table e Si la cl´ a plus d’un attribut, une d´pendance fonctionnelle ne e e doit jamais exister entre une partie seulement de la cl´ et un e autre attribut de la table.48/61
  • 49. Deuxi`me forme normale (2FN) e Affinement des requˆtes e Avion(Constr*, Mod`le*, Conso, Capacit´, VitesseMax) e e → il y a une d´pendance fontionnelle entre Constr et Mod`le e e On divise la table en deux : Avion(Constr*, Mod`le*) e ModeleAvion(Mod`le*, Conso, Capacit´, VitesseMax) e e49/61
  • 50. Troisi`me forme normale (3FN) e Affinement des requˆtes e Une relation est en troisi`me forme normale si et seulement si : e elle est en deuxi`me forme normale e tout attribut n’appartenant pas ` une cl´ ne d´pend pas d’un a e e attribut non cl´ e → les d´pendances fonctionnelles entre deux attributs ordinaires e (ne faisant par partie de la cl´) ne sont pas autoris´es e e50/61
  • 51. Troisi`me forme normale (3FN) e Affinement des requˆtes e Exemple : Voiture(Modele, Couleur, Annee, Cote) → il y a une d´pendance entre l’ann´e et la cote e e devient Voiture(Modele, Couleur, Annee) Cote(Ann´e, Cote) e51/61
  • 52. Forme normale de Boyce-Codd (BCNF) Affinement des requˆtes e Extension plus rigide de la troisi`me forme normale (d´finie e e par R.F. Boyce et E.F. Codd – en partant du constat que la 3FN comportait certaines anomalies) Une relation est en forme normale de Boyce-Codd si et seulement si : aucun attribut faisant partie de la cl´ ne d´pend e e d’un attribut ne faisant pas partie de la cl´ primaire e Remarques : Un mod`le relationnel en FNBC est consid´r´ comme ´tant de e ee e qualit´ suffisante pour une l’implantation e Les cas de relations en 3FN qui ne sont pas d´j` en FNBC ea sont tr`s rares e52/61
  • 53. Forme normale de Boyce-Codd (BCNF) Affinement des requˆtes e Exemple : soit la relation Vins(Cru, Pays, R´gion) e Cru Pays R´gion e Chenas France Beaujolais Julienas France Beaujolais Morgon France Beaujolais Brouilly France Beaujolais Chablis Etats-Unis Californie Attention : de nombreuses redondances On propose les relations : Crus (Cru, R´gion) e R´gions (R´gion, Pays) e e53/61
  • 54. ´ Elaboration du sch´ma physique Elaboration du sch´ma physique e ´ e Objectifs : Rechercher de bonnes performances Prendre en compte les transactions Indexer, d´normaliser, grouper, partitionner les tables e R´sultat : mod`le physique optimis´ de la base de donn´es e e e e54/61
  • 55. Exemple ´ Elaboration du sch´ma physique e Sch´ma relationnel e 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/61
  • 56. Sch´ma physique (SQL2) e ´ Elaboration du sch´ma physique e 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 p r i m a r y 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 p r i m a r y key (NUM PROF) ) ;56/61
  • 57. Sch´ma physique (SQL2) e ´ Elaboration du sch´ma physique e 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 p r i m a r y key (NUM COURS, NUM PROF) ) ; a l t e r t a b l e CHARGE add 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 CHARGE add 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/61
  • 58. Sch´ma physique (SQL2) e ´ Elaboration du sch´ma physique e 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 p r i m a r y key (NUM COURS) , c o n s t r a i n t NN COURS NOMC c h e c k (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 p r i m a r y key (NUM PROF) , c o n s t r a i n t NN PROFESSEURS NOMP c h e c k (NOMP I S NOT NULL ) ) ;58/61
  • 59. Sch´ma physique (SQL2) e ´ Elaboration du sch´ma physique e 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 p r i m a r y key (NUM COURS, NUM PROF) ) ; a l t e r t a b l e CHARGE add 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 CHARGE add 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/61
  • 60. Sch´ma relationnel-objet e ´ Elaboration du sch´ma physique e COURS ( NUM COURS, NOMC, NBHEURES, ANNEE ) PROFESSEURS ( NUM PROF, NOMP, SPECIALITE , DATE ENTREE , DER PROM, SALAIRE BASE , SALAIRE ACTUEL , Ensemble−de (COURS) )60/61
  • 61. Sch´ma physique SQL3 e ´ Elaboration du sch´ma physique e create type c o u r s t y p e as o b j e c t ( n u m c o u r s number ( 2 ) , nomc v a r c h a r 2 ( 2 0 ) , n b h e u r e s number ( 2 ) , a n n e e number ( 1 ) ) / create type l e s c o u r s t y p e as t a b l e of c o u r s t y p e / create type p r o f e s s e u r t y p e as o b j e c t ( n u m p r o f 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 ) , cours lescours type . . . ) / create table professeur of professeur type ( p r i m a r y key ( n u m p r o f ) ) n e s t e d t a b l e c o u r s s t o r e a s tabemp /61/61

×