Cours 4: Optimisation & Normalisation Tuanloc NGUYEN Miage de Paris 12

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

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

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

Rappel sur lalgèbre relationnel Normalisation Normalisation –Forme conjonctive (p11 ν p12 v…v p1n) Λ (pm1 ν pm2 v…v pmn) –Forme disjonctive (p11 Λ p12 Λ … Λ p1n) v (pm1 Λ pm2 Λ…Λ pmn) (souvent disjonctive)

Exemple: schéma de la base de données pour les étudiants de la MIAGE Paris 12

Conjonctive SELECT ENSEIGNANTS.nom, ENSEIGNANTS.prenom, MATIERES.nommat FROM MATIERES INNER JOIN (ENSEIGNANTS INNER JOIN ENSEIGN_MAT ON ENSEIGNANTS.codens = ENSEIGN_MAT.codens) ON MATIERES.codemat = ENSEIGN_MAT.codemat WHERE (((ENSEIGNANTS.nom)="NGUYEN") AND ((MATIERES.nommat)="ACCESS" Or (MATIERES.nommat)="BASE DE DONNEES"));

Disjonctive SELECT ENSEIGNANTS.nom, ENSEIGNANTS.prenom, MATIERES.nommat FROM MATIERES INNER JOIN (ENSEIGNANTS INNER JOIN ENSEIGN_MAT ON ENSEIGNANTS.codens = ENSEIGN_MAT.codens) ON MATIERES.codemat = ENSEIGN_MAT.codemat WHERE ( ( (ENSEIGNANTS.nom)="NGUYEN" AND (MATIERES.nommat)="BASE DE DONNEES") OR ( (MATIERES.nommat)="ACCESS" AND (MATIERES.nommat)="BASE DE DONNEES"));

Normalisation de requête 1. p1 Λ p2 p2 Λ p1 2. p1 v p2 p2 v p1 (commutativité) 3. p1Λ(p2 Λ p3) p1Λp2Λp3 4. p1v(p2 v p3) p1vp2vp3 (associativité) 5. p1Λ(p2vp3) (p1Λp2)v(p1Λp3) 6. p1v(p2Λp3) (p1vp2) Λ(p1vp3) 7. !(p1 Λ p2) !p1 v !p2 8. !!(p) p

Exercice SELECT Title FROM Emp WHERE (Not (Title=linux) AND (Title=linux OR Title=windows) AND Not (Title = unix)) OR Ename = Toward Linus; On suppose: p1 = Title=linux p2 = Title=windows p3 = Ename = Toward Linus

Forme normale (!p1 Λ (p1 v p2) Λ !p2) v p3 Disjonctive: Disjonctive: [(!p1 Λ p1) v (!p1 Λp2)] Λ !p2) v p3 [(!p1 Λ p1) v (!p1 Λp2)] Λ !p2) v p3 (!p2 Λ [(!p1 Λ p1) v (!p1 Λp2)]) v p3 (!p2 Λ [(!p1 Λ p1) v (!p1 Λp2)]) v p3 (!p2Λ(!p1 Λ p1))v(!p2Λ(!p1Λp2)) v p3 (!p2Λ!p1Λp1)v(!p2Λ!p1Λp2) v p3 (!p2Λ!p1Λp1)v(!p2Λ!p1Λp2) v p3 (!p2 Λfalse) v (!p1 Λ false) v p3 (!p2 Λfalse) v (!p1 Λ false) v p3 false v false v p3 false v false v p3 p3 p3

Requête finale SELECT Title From Emp WHERE Ename =Toward Linus;

Règle de transformation Commutativité: Commutativité: R x S Ξ S x R R |x| S Ξ S |x| R R U S Ξ S U R Associativité Associativité ( R x S ) x T = R x ( S x T) ( R |x| S ) |x| T = R |x| ( S |x| T) Idempotence Idempotence ΠA (ΠA(R) ) = ΠA(R) (avec A dans A) ΠA (ΠA(R) ) = ΠA(R) (avec A dans A)…

Analyse Mise de la requête en forme normale Mise de la requête en forme normale Analyse lexical et syntaxique Analyse lexical et syntaxique –Type incorrect ou inexistant (schéma de la relation)

Simplification 1. p Λ p p 2. p v p p 3. p Λ true p 4. p v false p 5. p Λ false false 6. p v true true 7. p Λ !p false 8. p v !p true 9. p1 Λ (p1 v p2) p1 10. P1 v (p1 Λ p2) p1

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

Implémentation Sélection Sélection –Parcours séquentiel –Parcours avec index (hachage,arbre B) Projection Projection Jointure: T = R |x| S 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 lordre de lexécution des opérations algébriques (élaboration du plan logique) Objectif: choisir lordre de lexécution des opérations algébriques (élaboration du plan logique) –Conversion en arbre algébrique –Transformation de larbre (optimisation) Appliquer les règles de transformation Appliquer les règles de transformation Estimation du coût des opérations (taille) Estimation du coût des opérations (taille) Ordre des jointures (coûte le plus cher) 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=20 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=20

Optimisation Elaborer des plans Elaborer des plans –Arbre algébrique, restructuration, ordre dévalution Estimer les coûts Estimer les coûts –Temps dexécution –Coût I/O, CPU, poids entre I/O – CPU: Nombre dinstructions et daccès au disque Nombre dinstructions et daccès au disque Choisir le meilleur plan Choisir le meilleur plan –Algorithme de recherche: Heuristique –Coût de chaque plan est différent –Ordre des jointures est très important –Optimisation despace de recherche Stratégie 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 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=20 Nom,Prénom,Note,gentil

Conclusion Très important pour administrateur de base de données: 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 1NF 2NF 2NF 3NF 3NF BCNF BCNF 4NF 4NF Données non-normalisation 1 NF 2 NF 3 NF BCNF 4 NF5 NF

Pourquoi normalisation ?

Première forme normale 1NF Une relation est dite normalisée ou en première forme normale si : 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.

Exemple: 1NF R(code_etudiant,nom,prénom,…code_ mat1,code_mat2,code_mat3,code_m at4,code_mat5) -> ce nest pas bien 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

Problème: Problème: –Ajouter S6 pas de produit ? –Changer nom S1 a en x: Changer tous S1 Changer tous S1 Changer 1 enregistrement: conflit Changer 1 enregistrement: conflit->redondance –Supprimer S3: perde dinfo S3

Sections de données répétées imbriquées Première forme normale (1NF) 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 : 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. 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é 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 : 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. 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. Permet autant que possible de minimiser l'occurence d'attributs indépendants à valeur mutiple. Une relation est de la 4NF si : 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. 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 Dépendances fonctionnelles cachées Exemple: Exemple: –Employee-Specialty(E#, Specialty, Manager) –Est en 3NF. Rêgle dentreprise – Business rules. Rêgle dentreprise – Business rules. –Un employé peut avoir plusieurs spécialités. –Chaque spécialité a plusieurs managers. –Chaque managera 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é. Le problème est dans la dépendance fonctionnelle caché entre manager et spécialité. –Besoin dune table séparée pour manager. –But then we dont need to repeat specialty. Dans monde réel, la duplication serait probablement acceptée (spécialité dans les 2 tables. 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 Annexe: Normalisation

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

Objets de la BD Vidéo Clients Clients –Clé: Assignation de CustomerID –Propriétés Nom Nom Adresse Adresse Téléphone Téléphone Vidéos Vidéos –Clé: Attribution dun noVidéo –Propriétés Titre Titre PrixLocation PrixLocation Cote Cote Description Description TransactionLocation TransactionLocation –Relation/Événement –Clé: Attribution dun noTransaction –Propriétés noClient Date VidéosLoués 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 lusager Recueillir les formulaires de lusager Noter les propriétés Noter les propriétés Trouver les sections de données répétées Trouver les sections de données répétées Noter les clés potentielles Noter les clés potentielles Identifier les propriétés calculées 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. 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 (…) Autre idée: Mémoriser les données sur la largeur (…) –Allocation despace –Combien? Ne peut être petit Ne peut être petit Perte despace Perte despace e.g., Combien de vidéo seront loué ? e.g., Combien de vidéo seront loué ? Une meilleure définition élimine ces problèmes. 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 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#,...) 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) 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 1NF division en groupe Encore des problèmes Encore des problèmes –Redondance –Dépendance fct cachée: –Si un vidéo na 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. Chaque champ non clé doit être fonctionnellement dépendant de la clé entière. –Sapplique que sur les clés à plusieurs champs –Diviser et créer une nouvelle table avec ces champs. Dépendance fonctionnelle (définition) 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 Tître dépend seulement du VideoID –Chaque VideoID ne peut avoir quun seul tître Le champ Rent est dépendant de VideoID Le champ Rent est dépendant de VideoID –Rêgle dentreprise. –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é. 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 Même en 2NF, certain problèmes persistent –Redondance –Dépendance fonctionnelle cachée –Si un client nouveau client na pas encore loué de vidéo, où mémorise- t-on ces données personnelles ? Solution: divisé. 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é. 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) 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 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 Diviser les sections de données répétées –Avec les clés parentales appropriées pour que linformation mémorisé puisse être recombiné. Vérifier les clés 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é, quentièrement de la clé et que seulement de la clé. Vérifier que chaque colonne non-clé ne dépend que de la clé, quentiè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. 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. Dans certain cas il y a des dépendances fonctionnelles cachées entre les colonnes clés. Exemple: Exemple: –EmployeeTasks(E#, Specialty, Task#) –Est en 3FN (BCNF) maintenant. Rêgle d'entreprise - "Business Rules" 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. 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 Dépendances fcts cachées Exemple: Exemple: –Employee-Specialty(E#, Specialty, Manager) –Est en 3FN. Rêgle dentreprise – Business rules. Rêgle dentreprise – Business rules. –Un employé peut avoir plusieurs spécialités. –Chaque spécialité a plusieurs managers. –Chaque managera 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é. Le problème est dans la dépendance fonctionnelle caché entre manager et spécialité. –Besoin dune table séparée pour manager. –But then we dont need to repeat specialty. Dans monde réel, la duplication serait probablement acceptée (spécialité dans les 2 tables. 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