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

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

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

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

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

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 +

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)

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");

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

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

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

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

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

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

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

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.

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

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

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

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

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,...)

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.

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é

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

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.

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:

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.

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

Annexe: Normalisation

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

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

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 ) )

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/023Washington Easy Street122001: A Space Odyssey$ /18/02 3Washington Easy Street63Clockwork Orange$ /30/02 7Lasater S. Ray Drive81Hopscotch$ /30/02 7Lasater S. Ray Drive21Apocalypse Now$ /30/02 7Lasater S. Ray Drive61Clockwork Orange$ /18/028Jones Lakeside Drive91Luggage Of The Gods$ /18/02 8Jones Lakeside Drive151Fabulous Baker Boys$ /18/02 8Jones Lakeside Drive41Boy And His Dog$ /18/023Washington Easy Street31Blues Brothers$ /18/02 3Washington Easy Street81Hopscotch$ /18/02 3Washington Easy Street131Surf Nazis Must Die$ /18/023Washington 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.

Problèmes avec les sections de données répétées Name Phone Address City State ZipCode VideoIDCopy#TitleRent 1. 61Clockwork Orange Hopscotch {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

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

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,...)

Problèmes de la 1NF TransIDRentDateCustIDPhoneLastNameFirstNameAddressCityStateZipCode 14/18/ WashingtonElroy95 Easy StreetSmith's GroveKY /30/ LasaterLes67 S. Ray DrivePortlandTN /18/ JonesCharlie867 Lakeside DriveCastalian SpringsTN /18/ WashingtonElroy95 Easy StreetSmith's GroveKY42171 TransIDVideoIDCopy#TitleRent : A Space Odyssey$ Clockwork Orange$ Hopscotch$ Apocalypse Now$ Clockwork Orange$ Luggage Of The Gods$ Fabulous Baker Boys$ Boy And His Dog$ Blues Brothers$ Hopscotch$ Surf Nazis Must Die$ Witches 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?

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

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)

Exemple 2NF (Données) TransIDVideoIDCopy# 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é)

Exemple 2NF: Problèmes TransIDRentDateCustIDPhoneLastNameFirstNameAddressCityStateZipCode 14/18/ WashingtonElroy95 Easy StreetSmith's GroveKY /30/ LasaterLes67 S. Ray DrivePortlandTN /18/ JonesCharlie867 Lakeside DriveCastalian SpringsTN /18/ WashingtonElroy95 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é.

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

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 )

Exemple 3NF Données TransIDRentDateCustomerID 14/18/ /30/ /18/028 44/18/023 CustomerIDPhoneLastNameFirstNameAddressCityStateZipCode JohnsonMartha125 Main StreetAlvatonKY SmithJack873 Elm StreetBowling GreenKY WashingtonElroy95 Easy StreetSmith's GroveKY AdamsSamuel746 Brown DriveAlvatonKY RabitzVictor645 White AvenueBowling GreenKY SteinmetzSusan15 Speedway DrivePortlandTN LasaterLes67 S. Ray DrivePortlandTN JonesCharlie867 Lakeside DriveCastalian SpringsTN ChavezJuan673 Industry Blvd.CaneyvilleKY RojoMaria88 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)

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

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.

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

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