1. Cours 5,6: Optimisation de requêtes & Normalisation de bases de données Tuanloc NGUYEN Miage de Paris 12

2. Optimisation de requêtes  Algèbre relationnel  Décomposition de requêtes  Optimisation de requêtes

3. Architecture SGBD ANALYSEUR META-BASE CONTROLE Traitement EXECUTABLE Schéma Vue Autorisation Intégrité Ordonnancement Élaboration/ Optimisation Méthode d’accès (hachage,arbre B+,index) BD

4. Traitement d’une requête Normalisation Analyse Restructuration SQL Simplification Optimisation Processeur de requêtes Exécution des plans

5. Simplification  Plus une requête est simple, plus son exécution peut être efficace

6. Implémentation  Sélection –Parcours séquentiel –Parcours avec index (hachage,arbre B)  Projection  Jointure: T = R |x| S foreach tuple r Є R do foreach tuple s Є S do foreach tuple s Є S do if r==s if r==s T = T + T = T +

7. Restructuration  Objectif: choisir l’ordre de l’exécution des opérations algébriques (élaboration du plan logique) –Conversion en arbre algébrique –Transformation de l’arbre (optimisation)  Appliquer les règles de transformation  Estimation du coût des opérations (taille)  Ordre des jointures (coûte le plus cher)

8. SELECT ENSEIGNANTS.nom, ENSEIGNANTS.prenom, MATIERES.nommat, ENSEIGNANTS.note, ENSEIGNANTS.gentil FROM MATIERES INNER JOIN ENSEIGNANTS INNER JOIN ENSEIGN_MAT ON ENSEIGNANTS.codens=ENSEIGN_MAT.codens ON ENSEIGNANTS.codens=ENSEIGN_MAT.codens ON MATIERES.codemat =ENSEIGN_MAT.codemat ON MATIERES.codemat =ENSEIGN_MAT.codemat WHERE ENSEIGNANTS.note=5 AND ENSEIGNANTS.gentil="top" AND (nommat="ADMIN BASE DE DONNEES"OR nommat="ACCESS");

9. RESULTAT Nom,Prénom,Note,gentil ENSEIGN_MAT.Codemat MATIERES.Codemat = MATIERES ENSEIGNANTS.Codens ENSEIGN_MAT.Codens ENSEIGNANTS = ENSEIGN_MAT Arbre algébrique nommat="ADMIN BASE DE DONNEES"OR nommat="ACCESS" ENSEIGNANTS.gentil="top" ENSEIGNANTS.note=5

10. Optimisation  Elaborer des plans –Arbre algébrique, restructuration, ordre d’évalution  Estimer les coûts –Temps d’exécution –Coût I/O, CPU, poids entre I/O – CPU:  Nombre d’instructions et d’accès au disque  Choisir le meilleur plan –Algorithme de recherche: Heuristique –Coût de chaque plan est différent –Ordre des jointures est très important –Optimisation d’espace de recherche  Stratégie de recherche –Déterministe –Aléatoire : efficace avec beaucoup de relations, améliorer itinéraire

11. Optimisation  Pour optimiser, il y a une technique simple: descendre les opérateurs de sélection et projection le plus près possible des feuilles pour réduire les tables le plus possible

12. RESULTAT ENSEIGN_MAT.Codemat MATIERES.Codemat = MATIERES ENSEIGNANTS.Codens ENSEIGN_MAT.Codens ENSEIGNANTS = ENSEIGN_MAT Arbre optimisé nommat="ADMIN BASE DE DONNEES"OR nommat="ACCESS" ENSEIGNANTS.gentil="top" ENSEIGNANTS.note=5 Nom,Prénom,Note,gentil

13. Conclusion  Optimisation des requêtes est très important pour administrateur de base de données: améliorer les performances en réglant des paramètres pour optimiser des requêtes

14. Normalisation  1NF  2NF  3NF  BCNF  4NF Données non-normalisation 1 NF 2 NF 3 NF BCNF 4 NF5 NF

15. Pourquoi normalisation ? -Réduire Null -Redondance de données -Eviter le coding (trigger,procédure stocké,…) -Bien structurer des données -Optimisation de performance:.temps d’exécution(‘’thin table’’).Maximiser ‘’Clustered indexes’’ (trier,rercherche).Nombre d’index par table

16. Première forme normale 1NF (First Normal Form)  Une relation est dite normalisée ou en première forme normale si : –aucun attribut qui la compose n'est lui- même une relation, c'est-à-dire si tout attribut est atomique (non décomposable). –Cette forme n'utilise que les structures de base d'une relation, elle ne résout pas le problème de la redondance.

17. 1NF  Atomicité (emails, téléphone,adresses IP)  Chaque entité a le même nombre de valeurs. (noms,adresses)  Tuple est unique

18. Exemple: 1NF R(code_etudiant,nom,prénom,…,code _mat1,code_mat2,code_mat3,co de_mat4,code_mat5) -> ce n’est pas bien (non 1NF) fournisseur S#: code de fournisseur sname: nom de fournisseur status: statut de fournisseur R(s#,p#,sname,city,status,qty) p#: produit

19. R(s#,p#,sname,city,status,qty) S1P1AC1110 S1P2AC1120 S1P3AC1125 S1P4AC1130 S2P1BC1115 S1P2BC1140 S3P1CC225 S4P1DC2235 S5P2EC337

20. 1NF  Problèmes sur 1NF: –Ajouter S6 pas de produit ? –Changer nom S1 a en x:  Changer tous S1  Changer 1 enregistrement: conflit ->redondance –Supprimer S3: perde d’info S3

21. Sections de données répétées imbriquées  Première forme normale (1NF) –Table1(Key1, aaa...) –Table2(Key1, Key2, bbb..) –Table3(Key1, Key2, Key3, ccc...) Table (Key1,... (Key2,... (Key3,...) ) ) Table1(Key1,...)TableA (Key1,Key2...(Key3,...) ) Table2 (Key1, Key2...)Table3 (Key1, Key2, Key3,...)

22. Deuxième forme normale 2NF  Une relation est dite en deuxième forme normale si et seulement si : –Elle est en première forme normale ; –Chaque attribut est totalement dépendant de la clé primaire.  Avec cette forme, les problèmes de redondance ne sont pas entièrement résolus.

23. R(s#,p#,sname,city,status,qty) Exemple: 2NF R1(s#,p#,sname,city,status) R2(s#,p#,qty) Information de la société Activités de la société

24. S1P110 S1P220 S1P325 S1P430 S2P115 S1P240 S3P15 S4P135 S5P27 PAS DE PROBLEMES 2NF

25. Troisième forme normale 3NF  Une relation est en troisième forme normale si et seulement si : –elle est en 2NF; –et chaque attribut non-clé primaire dépend directement de la clé primaire.  La 3NF est adéquate pour la majorité des designs de BD mais elle n'élimine pas toutes les redondances et incohérences. Pour cela, Codd a pensé à BCNF qui est une forme plus stricte de 3NF.

26. Exemple 3NF R R1 R11(city, status) 3NF R12(s#, sname,city) 3NF R2 (s#,p#,qty) 3NF 1) s# sname city status X Enlever s# ->status 3NF : T={R11, R12, R2} 2) R12R121 R122 Solution:

27. Quatrième forme normale 4NF  Permet autant que possible de minimiser l'occurence d'attributs indépendants à valeur mutiple.  Une relation est de la 4NF si : –elle satisfait la 3NF –les données composant chaque attribut ne comportent aucune répétition inutile -> dans une même colonne, il faut minimiser les répétitions.  Une base qui est 4NF est des plus optimales quoiqu'il soit possible de généraliser cette dernière afin d'obtenir la 5NF.

28. Boyce-Codd Normal Form (BCNF)  Dépendances fonctionnelles cachées  Exemple: –Employee-Specialty(E#, Specialty, Manager) –Est en 3NF.  Rêgle d’entreprise – “Business rules”. –Un employé peut avoir plusieurs spécialités. –Chaque spécialité a plusieurs “managers”. –Chaque “manager”a seulement une spécialité. –Un employé a seulement 1 “manager” pour chaque spécialité.  Le problème est dans la dépendance fonctionnelle caché entre “manager” et spécialité. –Besoin d’une table séparée pour “manager”. –But then we don’t need to repeat specialty.  Dans monde réel, la duplication serait probablement acceptée (spécialité dans les 2 tables. Employee-Specialty(E#, Specialty, Manager) Employee(E#, Manager) Manager(Manager, Specialty) Employee(E#, Specialty, Manager) Manager(Manager, Specialty) acceptable

29. Annexe: Normalisation

30. Exemple: BD Video Section de données répétées Clé possible

31. Objets de la BD Vidéo  Clients –Clé: Assignation de CustomerID –Propriétés  Nom  Adresse  Téléphone  Vidéos –Clé: Attribution d’un noVidéo –Propriétés  Titre  PrixLocation  Cote  Description  TransactionLocation –Relation/Événement –Clé: Attribution d’un noTransaction –Propriétés  noClient  Date  VidéosLoués –Événement/Liste –Clés: noTransaction + noVidéo –Propriétés  noCopieVidéo

32. Formulaire initial BD vidéo  Recueillir les formulaires de l’usager  Noter les propriétés  Trouver les sections de données répétées  Noter les clés potentielles  Identifier les propriétés calculées  Résultat équivalent à un diagramme (modèle logique), mais va pouvoir être contenu sur un page ou deux. RentalForm(TransID, RentDate, CustomerID, Phone, Name, Address, City, State, ZipCode, (VideoID, Copy#, Title, Rent ) )

33. Problèmes avec les sections de données répétées RentalForm(TransID, RentDate, CustomerID, Phone, Name, Address, City, State, ZipCode, (VideoID, Copy#, Title, Rent ) ) TransIDRentDateCustomerIDLastNamePhoneAddressVideoIDCopy#TitleRent 14/18/023Washington502-777-757595 Easy Street122001: A Space Odyssey$1.50 14/18/02 3Washington502-777-757595 Easy Street63Clockwork Orange$1.50 24/30/02 7Lasater615-888-447467 S. Ray Drive81Hopscotch$1.50 24/30/02 7Lasater615-888-447467 S. Ray Drive21Apocalypse Now$2.00 24/30/02 7Lasater615-888-447467 S. Ray Drive61Clockwork Orange$1.50 34/18/028Jones615-452-1162867 Lakeside Drive91Luggage Of The Gods$2.50 34/18/02 8Jones615-452-1162867 Lakeside Drive151Fabulous Baker Boys$2.00 34/18/02 8Jones615-452-1162867 Lakeside Drive41Boy And His Dog$2.50 44/18/023Washington502-777-757595 Easy Street31Blues Brothers$2.00 44/18/02 3Washington502-777-757595 Easy Street81Hopscotch$1.50 44/18/02 3Washington502-777-757595 Easy Street131Surf Nazis Must Die$2.50 44/18/023Washington502-777-757595 Easy Street171Witches of Eastwick$2.00 Section de données répétées Provoque des duplications Beaucoup de problèmes seraient provoqués par cette structure.

34. Problèmes avec les sections de données répétées Name Phone Address City State ZipCode VideoIDCopy#TitleRent 1. 61Clockwork Orange1.50 2. 82Hopscotch1.50 3. 4. 5. {Unused Space} Pas en première forme normale  Autre idée: Mémoriser les données sur la largeur (…) –Allocation d’espace –Combien?  Ne peut être petit  Perte d’espace  e.g., Combien de vidéo seront loué ?  Une meilleure définition élimine ces problèmes. Customer Rentals

35. Première forme normale RentalForm(TransID, RentDate, CustomerID, Phone, Name, Address, City, State, ZipCode, (VideoID, Copy#, Title, Rent ) ) RentalForm2(TransID, RentDate, CustomerID, Phone, Name, Address, City, State, ZipCode) RentalLine(TransID, VideoID, Copy#, Title, Rent )  Enlever les sections de données répétées –Divisé en 2 tables –Transmettre les clés de la table principale à la nouvelle table  RentalLine(TransID, VideoID, Copy#,...) –Chaque transaction peut avoir plusieurs vidéos (clé VideoID) –Chaque vidéo peut être loué dans plusieurs transactions

36. Sections de données répétées imbriquées  Première forme normale (1NF) –Table1(Key1, aaa...) –Table2(Key1, Key2, bbb..) –Table3(Key1, Key2, Key3, ccc...) Table (Key1,... (Key2,... (Key3,...) ) ) Table1(Key1,...)TableA (Key1,Key2...(Key3,...) ) Table2 (Key1, Key2...)Table3 (Key1, Key2, Key3,...)

37. Problèmes de la 1NF TransIDRentDateCustIDPhoneLastNameFirstNameAddressCityStateZipCode 14/18/023502-777-7575WashingtonElroy95 Easy StreetSmith's GroveKY42171 24/30/027615-888-4474LasaterLes67 S. Ray DrivePortlandTN37148 34/18/028615-452-1162JonesCharlie867 Lakeside DriveCastalian SpringsTN37031 44/18/023502-777-7575WashingtonElroy95 Easy StreetSmith's GroveKY42171 TransIDVideoIDCopy#TitleRent 1122001: A Space Odyssey$1.50 163Clockwork Orange$1.50 281Hopscotch$1.50 221Apocalypse Now$2.00 261Clockwork Orange$1.50 391Luggage Of The Gods$2.50 3151Fabulous Baker Boys$2.00 341Boy And His Dog$2.50 431Blues Brothers$2.00 481Hopscotch$1.50 4131Surf Nazis Must Die$2.50 4171Witches of Eastwick$2.00  1NF division en groupe  Encore des problèmes –Redondance –Dépendance fct cachée: –Si un vidéo n’a pas été loué, quel est son titre?

38. Définition de la 2ième forme normale  Chaque champ non clé doit être fonctionnellement dépendant de la clé entière. –S’applique que sur les clés à plusieurs champs –Diviser et créer une nouvelle table avec ces champs.  Dépendance fonctionnelle (définition) –Si, pour une certaine valeur de clé X, on peut toujours déterminer la valeur du champ Y alors le champ Y est dit fonctionnellement dépendant de X. RentalLine(TransID, VideoID, Copy#, Title, Rent) Dépend seulement sur VideoID Dépend sur TransID ET VideoID

39. Exemple: 2NF  Tître dépend seulement du VideoID –Chaque VideoID ne peut avoir qu’un seul tître  Le champ Rent est dépendant de VideoID –Rêgle d’entreprise. –Pourrait être différent dans un autre club vidéo. –Certain club vidéo pourrait charger un loyé différent dépendant de la journée.  Chaque champ non clé est fonctionnellement dépendant de la clé et entièrement de la clé. RentalLine(TransID, VideoID, Copy#, Title, Rent) VideosRented(TransID, VideoID, Copy#) Videos(VideoID, Title, Rent)

40. Exemple 2NF (Données) TransIDVideoIDCopy# 112 163 221 261 281 341 391 3151 431 481 4131 4171 VideoIDTitleRent 12001: A Space Odyssey$1.50 2Apocalypse Now$2.00 3Blues Brothers$2.00 4Boy And His Dog$2.50 5Brother From Another Planet$2.00 6Clockwork Orange$1.50 7Gods Must Be Crazy$2.00 8Hopscotch$1.50 VideosRented(TransID, VideoID, Copy#) Videos(VideoID, Title, Rent) RentalForm2(TransID, RentDate, CustomerID, Phone, Name, Address, City, State, ZipCode) (non modifié)

41. Exemple 2NF: Problèmes TransIDRentDateCustIDPhoneLastNameFirstNameAddressCityStateZipCode 14/18/023502-777-7575WashingtonElroy95 Easy StreetSmith's GroveKY42171 24/30/027615-888-4474LasaterLes67 S. Ray DrivePortlandTN37148 34/18/028615-452-1162JonesCharlie867 Lakeside DriveCastalian SpringsTN37031 44/18/023502-777-7575WashingtonElroy95 Easy StreetSmith's GroveKY42171 RentalForm2(TransID, RentDate, CustomerID, Phone, Name, Address, City, State, ZipCode)  Même en 2NF, certain problèmes persistent –Redondance –Dépendance fonctionnelle cachée –Si un client nouveau client n’a pas encore loué de vidéo, où mémorise- t-on ces données personnelles ?  Solution: divisé.

42. Définition de la 3ième forme normale RentalForm2(TransID, RentDate, CustomerID, Phone, Name, Address, City, State, ZipCode)  Chaque champ non-clé doit être fct dépendant de la clé et seulement de la clé. –Solution: divisé. –Exemple: Les noms de client ne change pas à chaque transaction. Dépend seulement du CustomerID Dépend du TransID

43. Exemple 3NF  Les attributs du client ne dépendent que du numéro de client (CustomerID) –Solution: diviser et créer une nouvelle table (Customer) –En laissant le CustomerID dans la table principale.  La 3NF est souvent plus facile à voir si les objets principaux ont déjà été identifiés RentalForm2(TransID, RentDate, CustomerID, Phone, Name, Address, City, State, ZipCode) Rentals(TransID, RentDate, CustomerID ) Customers(CustomerID, Phone, Name, Address, City, State, ZipCode )

44. Exemple 3NF Données TransIDRentDateCustomerID 14/18/02 3 24/30/02 7 34/18/028 44/18/023 CustomerIDPhoneLastNameFirstNameAddressCityStateZipCode 1502-666-7777JohnsonMartha125 Main StreetAlvatonKY42122 2502-888-6464SmithJack873 Elm StreetBowling GreenKY42101 3502-777-7575WashingtonElroy95 Easy StreetSmith's GroveKY42171 4502-333-9494AdamsSamuel746 Brown DriveAlvatonKY42122 5502-474-4746RabitzVictor645 White AvenueBowling GreenKY42102 6615-373-4746SteinmetzSusan15 Speedway DrivePortlandTN37148 7615-888-4474LasaterLes67 S. Ray DrivePortlandTN37148 8615-452-1162JonesCharlie867 Lakeside DriveCastalian SpringsTN37031 9502-222-4351ChavezJuan673 Industry Blvd.CaneyvilleKY42721 10502-444-2512RojoMaria88 Main StreetCave CityKY42127 Rentals(TransID, RentDate, CustomerID ) Customers(CustomerID, Phone, Name, Address, City, State, ZipCode ) (non modifié) VideosRented(TransID, VideoID, Copy#) Videos(VideoID, Title, Rent)

45. Tables en 3NF Rentals(TransID, RentDate, CustomerID ) Customers(CustomerID, Phone, Name, Address, City, State, ZipCode ) VideosRented(TransID, VideoID, Copy#) Videos(VideoID, Title, Rent)

46. Procédure pour obtenir la 3NF  Diviser les sections de données répétées –Avec les clés parentales appropriées pour que l’information mémorisé puisse être recombiné.  Vérifier les clés –Est-ce que chaque ligne est uniquement identifiée par la clé primaire ? –Est-ce que les relations M:N sont bient décomposées ?  Vérifier que chaque colonne non-clé ne dépend que de la clé, qu’entièrement de la clé et que seulement de la clé. –Pas de dépendances fonctionnelles cachées.

47. Définition de la 4NF  Techniquement, si toutes les colonnes sont clé alors la devrait être en 3FN.  Dans certain cas il y a des dépendances fonctionnelles cachées entre les colonnes clés.  Exemple: –EmployeeTasks(E#, Specialty, Task#) –Est en 3FN (BCNF) maintenant.  Rêgle d'entreprise - "Business Rules" –Chaque employé a plusieurs spécialités. –Chaque spécialité a plusieurs tâche - "task". –Les tâches dépendent toujours des spécialités.  Encore une fois, dans monde réel, la duplication serait probablement acceptée. EmployeeTasks(E#, Specialty, Task#) EmployeeSpecialty(E#, Specialty) Specialty(Specialty, Task#) EmployeeTasks(E#, Specialty, Task#) Specialty(Specialty, Task#) acceptable

48. Boyce-Codd Normal Form (BCNF)  Dépendances fcts cachées  Exemple: –Employee-Specialty(E#, Specialty, Manager) –Est en 3FN.  Rêgle d’entreprise – “Business rules”. –Un employé peut avoir plusieurs spécialités. –Chaque spécialité a plusieurs “managers”. –Chaque “manager”a seulement une spécialité. –Un employé a seulement 1 “manager” pour chaque spécialité.  Le problème est dans la dépendance fonctionnelle caché entre “manager” et spécialité. –Besoin d’une table séparée pour “manager”. –But then we don’t need to repeat specialty.  Dans monde réel, la duplication serait probablement acceptée (spécialité dans les 2 tables. Employee-Specialty(E#, Specialty, Manager) Employee(E#, Manager) Manager(Manager, Specialty) Employee(E#, Specialty, Manager) Manager(Manager, Specialty) acceptable