Cours 5 6 Optimisation de requtes Normalisation de

  • Slides: 48
Download presentation
Cours 5, 6: Optimisation de requêtes & Normalisation de bases de données Tuanloc NGUYEN

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

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

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

Architecture SGBD ANALYSEUR CONTROLE Schéma Vue Autorisation Intégrité Ordonnancement META-BASE Traitement Élaboration/ Optimisation EXECUTABLE

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

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

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

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

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

Implémentation u Sélection u Projection u Jointure: T = R |x| S – Parcours

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

Restructuration u Objectif: choisir l’ordre de l’exécution des opérations algébriques (élaboration du plan logique)

Restructuration u 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) u Appliquer les règles de transformation u Estimation du coût des opérations (taille) u Ordre des jointures (coûte le plus cher)

SELECT ENSEIGNANTS. nom, ENSEIGNANTS. prenom, MATIERES. nommat, ENSEIGNANTS. note, ENSEIGNANTS. gentil FROM MATIERES INNER

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 MATIERES. codemat =ENSEIGN_MAT. codemat WHERE ENSEIGNANTS. note=5 AND ENSEIGNANTS. gentil="top" AND (nommat="ADMIN BASE DE DONNEES"OR nommat="ACCESS");

Arbre algébrique RESULTAT Nom, Prénom, Note, gentil nommat="ADMIN BASE DE DONNEES"OR nommat="ACCESS" ENSEIGNANTS. gentil="top"

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

Optimisation u Elaborer des plans u Estimer les coûts – Arbre algébrique, restructuration, ordre

Optimisation u Elaborer des plans u Estimer les coûts – Arbre algébrique, restructuration, ordre d’évalution – Temps d’exécution – Coût I/O, CPU, poids entre I/O – CPU: u u u 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 u Pour optimiser, il y a une technique simple: descendre les opérateurs de

Optimisation u 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

Arbre optimisé RESULTAT nommat="ADMIN BASE DE DONNEES"OR nommat="ACCESS" ENSEIGNANTS. gentil="top" ENSEIGNANTS. note=5 ENSEIGN_MAT. Codemat

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

Conclusion u Optimisation des requêtes est très important pour administrateur de base de données:

Conclusion u 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 u 1 NF u 2 NF u 3 NF u BCNF u 4

Normalisation u 1 NF u 2 NF u 3 NF u BCNF u 4 NF Données non-normalisation 1 NF 2 NF 3 NF 5 NF BCNF 4 NF

Pourquoi normalisation ? -Réduire Null -Redondance de données -Eviter le coding (trigger, procédure stocké,

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, rerche). Nombre d’index par table

Première forme normale 1 NF (First Normal Form) u Une relation est dite normalisée

Première forme normale 1 NF (First Normal Form) u Une relation est dite normalisée ou en première forme normale si : – aucun attribut qui la compose n'est luimê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.

1 NF Atomicité (emails, téléphone, adresses IP) u Chaque entité a le même nombre

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

Exemple: 1 NF R(code_etudiant, nom, prénom, …, code _mat 1, code_mat 2, code_mat 3,

Exemple: 1 NF R(code_etudiant, nom, prénom, …, code _mat 1, code_mat 2, code_mat 3, co de_mat 4, code_mat 5) -> ce n’est pas bien (non 1 NF) S#: code de fournisseur sname: nom de fournisseur status: statut de fournisseur p#: produit R(s#, p#, sname, city, status, qty)

R(s#, p#, sname, city, status, qty) S 1 S 1 S 2 S 1

R(s#, p#, sname, city, status, qty) S 1 S 1 S 2 S 1 S 3 S 4 S 5 P 1 P 2 P 3 P 4 P 1 P 2 A A B B C D E C 1 C 1 C 1 C 2 C 3 1 1 1 2 2 3 10 20 25 30 15 40 5 35 7

1 NF u Problèmes sur 1 NF: – Ajouter S 6 pas de produit

1 NF u Problèmes sur 1 NF: – Ajouter S 6 pas de produit ? – Changer nom S 1 a en x: u Changer tous S 1 u Changer 1 enregistrement: conflit ->redondance – Supprimer S 3: perde d’info S 3

Sections de données répétées imbriquées Table (Key 1, . . . (Key 2, .

Sections de données répétées imbriquées Table (Key 1, . . . (Key 2, . . . (Key 3, . . . ) ) ) Table 1(Key 1, . . . ) Table. A (Key 1, Key 2. . . (Key 3, . . . ) ) Table 2 (Key 1, Key 2. . . ) u Table 3 (Key 1, Key 2, Key 3, . . . ) Première forme normale (1 NF) – Table 1(Key 1, – Table 2(Key 1, – Table 3(Key 1, aaa. . . ) Key 2, bbb. . ) Key 2, Key 3, ccc. . . )

Deuxième forme normale 2 NF u Une relation est dite en deuxième forme normale

Deuxième forme normale 2 NF u 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. u Avec cette forme, les problèmes de redondance ne sont pas entièrement résolus.

Exemple: 2 NF R(s#, p#, sname, city, status, qty) R 1(s#, p#, sname, city,

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

S 1 P 1 10 S 1 P 2 20 S 1 P 3

S 1 P 1 10 S 1 P 2 20 S 1 P 3 25 S 1 P 4 30 S 2 P 1 15 S 1 P 2 40 S 3 P 1 5 S 4 P 1 35 S 5 P 2 7 2 NF PAS DE PROBLEMES

Troisième forme normale 3 NF u Une relation est en troisième forme normale si

Troisième forme normale 3 NF u Une relation est en troisième forme normale si et seulement si : – elle est en 2 NF; – et chaque attribut non-clé primaire dépend directement de la clé primaire. u La 3 NF est adéquate pour la majorité 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 3 NF.

Exemple 3 NF R 11(city, status) 3 NF R 12(s#, sname, city) 3 NF

Exemple 3 NF R 11(city, status) 3 NF R 12(s#, sname, city) 3 NF R R 2 (s#, p#, qty) 3 NF : T={R 11, R 12, R 2} Solution: sname 1) s# city X status 2) R 121 R 122 Enlever s# ->status

u u u Quatrième forme normale 4 NF Permet autant que possible de minimiser

u u u Quatrième forme normale 4 NF Permet autant que possible de minimiser l'occurence d'attributs indépendants à valeur mutiple. Une relation est de la 4 NF si : – elle satisfait la 3 NF – 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 4 NF est des plus optimales quoiqu'il soit possible de généraliser cette dernière afin d'obtenir la 5 NF.

Boyce-Codd Normal Form (BCNF) u u u Dépendances fonctionnelles cachées Employee-Specialty(E#, Specialty, Manager) Exemple:

Boyce-Codd Normal Form (BCNF) u u u Dépendances fonctionnelles cachées Employee-Specialty(E#, Specialty, Manager) Exemple: – Employee-Specialty(E#, Specialty, Manager) – Est en 3 NF. Employee(E#, Manager) Rêgle d’entreprise – “Business rules”. – Un employé peut avoir plusieurs spécialités. Manager(Manager, Specialty) – 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é. Employee(E#, Specialty, Manager) – Besoin d’une table séparée pour “manager”. – But then we don’t need to repeat specialty. Manager(Manager, Specialty) Dans monde réel, la duplication serait ble a t p e probablement acceptée (spécialité dans les 2 acc tables.

Annexe: Normalisation

Annexe: Normalisation

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

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

Objets de la BD Vidéo u u Clients – Clé: Assignation de Customer. ID

Objets de la BD Vidéo u u Clients – Clé: Assignation de Customer. ID – Propriétés u Nom u Adresse u Téléphone Vidéos – Clé: Attribution d’un no. Vidéo – Propriétés u Titre u Prix. Location u Cote u Description u u Transaction. Location – Relation/Événement – Clé: Attribution d’un no. Transaction – Propriétés u no. Client u Date Vidéos. Loués – Événement/Liste – Clés: no. Transaction + no. Vidéo – Propriétés u no. Copie. Vidéo

Formulaire initial BD vidéo Rental. Form(Trans. ID, Rent. Date, Customer. ID, Phone, Name, Address,

Formulaire initial BD vidéo Rental. Form(Trans. ID, Rent. Date, Customer. ID, Phone, Name, Address, City, State, Zip. Code, (Video. ID, Copy#, Title, Rent ) ) u u u 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.

Problèmes avec les sections de données répétées Rental. Form(Trans. ID, Rent. Date, Customer. ID,

Problèmes avec les sections de données répétées Rental. Form(Trans. ID, Rent. Date, Customer. ID, Phone, Name, Address, City, State, Zip. Code, (Video. ID, Copy#, Title, Rent ) ) Beaucoup de problèmes seraient provoqués par cette structure. Section de données répétées Provoque des duplications Trans. ID 1 1 2 2 2 3 3 3 4 4 Rent. Date 4/18/02 4/30/02 4/18/02 4/18/02 Customer. ID 3 3 7 7 7 8 8 8 3 3 Last. Name Washington Lasater Jones Washington Phone 502 -777 -7575 615 -888 -4474 615 -452 -1162 502 -777 -7575 Address 95 Easy Street 67 S. Ray Drive 867 Lakeside Drive 95 Easy Street Video. ID 1 6 8 2 6 9 15 4 3 8 13 17 Copy# 2 3 1 1 1 1 1 Title 2001: 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 Rent $1. 50 $2. 00 $1. 50 $2. 00 $2. 50 $2. 00 $1. 50 $2. 00

Problèmes avec les sections de données répétées u u u Autre idée: Mémoriser les

Problèmes avec les sections de données répétées u u u Autre idée: Mémoriser les données sur la largeur (…) – Allocation d’espace – Combien? u Ne peut être petit u Perte d’espace e. g. , Combien de vidéo seront loué ? Une meilleure définition élimine ces problèmes. Name Phone Address City State Zip. Code Customer Rentals Video. ID Copy# Title 1. 6 1 Clockwork Orange 2. 8 2 Hopscotch 3. {Unused Space} 4. 5. Rent 1. 50 Pas en première forme normale

Première forme normale Rental. Form(Trans. ID, Rent. Date, Customer. ID, Phone, Name, Address, City,

Première forme normale Rental. Form(Trans. ID, Rent. Date, Customer. ID, Phone, Name, Address, City, State, Zip. Code, (Video. ID, Copy#, Title, Rent ) ) Rental. Form 2(Trans. ID, Rent. Date, Customer. ID, Phone, Name, Address, City, State, Zip. Code) Rental. Line(Trans. ID, Video. ID, Copy#, Title, Rent ) u u 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 Rental. Line(Trans. ID, Video. ID, Copy#, . . . ) – Chaque transaction peut avoir plusieurs vidéos (clé Video. ID) – Chaque vidéo peut être loué dans plusieurs transactions

Sections de données répétées imbriquées Table (Key 1, . . . (Key 2, .

Sections de données répétées imbriquées Table (Key 1, . . . (Key 2, . . . (Key 3, . . . ) ) ) Table 1(Key 1, . . . ) Table. A (Key 1, Key 2. . . (Key 3, . . . ) ) Table 2 (Key 1, Key 2. . . ) u Table 3 (Key 1, Key 2, Key 3, . . . ) Première forme normale (1 NF) – Table 1(Key 1, – Table 2(Key 1, – Table 3(Key 1, aaa. . . ) Key 2, bbb. . ) Key 2, Key 3, ccc. . . )

Problèmes de la 1 NF Trans. ID 1 2 3 4 Rent. Date 4/18/02

Problèmes de la 1 NF Trans. ID 1 2 3 4 Rent. Date 4/18/02 4/30/02 4/18/02 Cust. ID 3 7 8 3 Phone 502 -777 -7575 615 -888 -4474 615 -452 -1162 502 -777 -7575 Last. Name Washington Lasater Jones Washington u 1 NF division en groupe u Encore des problèmes – Redondance – Dépendance fct cachée: – Si un vidéo n’a pas été loué, quel est son titre? First. Name Elroy Les Charlie Elroy Trans. ID 1 1 2 2 2 3 3 3 4 4 Address 95 Easy Street 67 S. Ray Drive 867 Lakeside Drive 95 Easy Street Video. ID 1 6 8 2 6 9 15 4 3 8 13 17 Copy# 2 3 1 1 1 1 1 City Smith's Grove Portland Castalian Springs Smith's Grove State KY TN TN KY Zip. Code 42171 37148 37031 42171 Title 2001: 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 Rent $1. 50 $2. 00 $1. 50 $2. 00 $2. 50 $2. 00 $1. 50 $2. 00

Définition de la 2 ième forme normale Dépend sur Trans. ID ET Video. ID

Définition de la 2 ième forme normale Dépend sur Trans. ID ET Video. ID Rental. Line(Trans. ID, Video. ID, Copy#, Title, Rent) u Chaque champ non clé doit être fonctionnellement dépendant de la clé entière. – S’applique sur les clés à plusieurs champs – Diviser et créer une nouvelle table avec ces champs. Dépend seulement sur Video. ID u 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.

Exemple: 2 NF Rental. Line(Trans. ID, Video. ID, Copy#, Title, Rent) Videos. Rented(Trans. ID,

Exemple: 2 NF Rental. Line(Trans. ID, Video. ID, Copy#, Title, Rent) Videos. Rented(Trans. ID, Video. ID, Copy#) Videos(Video. ID, Title, Rent) u u u Tître dépend seulement du Video. ID – Chaque Video. ID ne peut avoir qu’un seul tître Le champ Rent est dépendant de Video. ID – 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é.

Exemple 2 NF (Données) Videos. Rented(Trans. ID, Video. ID, Copy#) Trans. ID 1 1

Exemple 2 NF (Données) Videos. Rented(Trans. ID, Video. ID, Copy#) Trans. ID 1 1 2 2 2 3 3 3 4 4 Video. ID 1 6 2 6 8 4 9 15 3 8 13 17 Copy# 2 3 1 1 1 1 1 Videos(Video. ID, Title, Rent) Video. ID 1 2 3 4 5 6 7 8 Title 2001: A Space Odyssey Apocalypse Now Blues Brothers Boy And His Dog Brother From Another Planet Clockwork Orange Gods Must Be Crazy Hopscotch Rent $1. 50 $2. 00 $2. 50 $2. 00 $1. 50 (non modifié) Rental. Form 2(Trans. ID, Rent. Date, Customer. ID, Phone, Name, Address, City, State, Zip. Code)

Exemple 2 NF: Problèmes Rental. Form 2(Trans. ID, Rent. Date, Customer. ID, Phone, Name,

Exemple 2 NF: Problèmes Rental. Form 2(Trans. ID, Rent. Date, Customer. ID, Phone, Name, Address, City, State, Zip. Code) Trans. ID 1 2 3 4 Rent. Date 4/18/02 4/30/02 4/18/02 u u Cust. ID 3 7 8 3 Phone 502 -777 -7575 615 -888 -4474 615 -452 -1162 502 -777 -7575 Last. Name Washington Lasater Jones Washington First. Name Elroy Les Charlie Elroy Address 95 Easy Street 67 S. Ray Drive 867 Lakeside Drive 95 Easy Street City Smith's Grove Portland Castalian Springs Smith's Grove Même en 2 NF, 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émoriset-on ces données personnelles ? Solution: divisé. State KY TN TN KY Zip. Code 42171 37148 37031 42171

Définition de la 3 ième forme normale Dépend du Trans. ID Rental. Form 2(Trans.

Définition de la 3 ième forme normale Dépend du Trans. ID Rental. Form 2(Trans. ID, Rent. Date, Customer. ID, Phone, Name, Address, City, State, Zip. Code) Dépend seulement du Customer. ID u 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.

Exemple 3 NF Rental. Form 2(Trans. ID, Rent. Date, Customer. ID, Phone, Name, Address,

Exemple 3 NF Rental. Form 2(Trans. ID, Rent. Date, Customer. ID, Phone, Name, Address, City, State, Zip. Code) Rentals(Trans. ID, Rent. Date, Customer. ID ) Customers(Customer. ID, Phone, Name, Address, City, State, Zip. Code ) u Les attributs du client ne dépendent que du numéro de client (Customer. ID) – Solution: diviser et créer une nouvelle table (Customer) – En laissant le Customer. ID dans la table principale. u La 3 NF est souvent plus facile à voir si les objets principaux ont déjà été identifiés

Exemple 3 NF Données Rentals(Trans. ID, Rent. Date, Customer. ID ) Trans. ID 1

Exemple 3 NF Données Rentals(Trans. ID, Rent. Date, Customer. ID ) Trans. ID 1 2 3 4 Rent. Date 4/18/02 4/30/02 4/18/02 Customer. ID 3 7 8 3 Customers(Customer. ID, Phone, Name, Address, City, State, Zip. Code ) Customer. ID 1 2 3 4 5 6 7 8 9 10 Phone 502 -666 -7777 502 -888 -6464 502 -777 -7575 502 -333 -9494 502 -4746 615 -373 -4746 615 -888 -4474 615 -452 -1162 502 -222 -4351 502 -444 -2512 Last. Name First. Name Johnson Martha Smith Jack Washington Adams Samuel Rabitz Victor Steinmetz Susan Lasater Les Jones Charlie Chavez Juan Rojo Maria Address 125 Main Street 873 Elm Street Elroy 746 Brown Drive 645 White Avenue 15 Speedway Drive 67 S. Ray Drive 867 Lakeside Drive 673 Industry Blvd. 88 Main Street (non modifié) Videos. Rented(Trans. ID, Video. ID, Copy#) Videos(Video. ID, Title, Rent) City State Zip. Code Alvaton KY 42122 Bowling Green KY 42101 95 Easy Street Smith's Grove KY Alvaton KY 42122 Bowling Green KY 42102 Portland TN 37148 Castalian Springs TN 37031 Caneyville KY 42721 Cave City KY 42127 42171

Tables en 3 NF Rentals(Trans. ID, Rent. Date, Customer. ID ) Customers(Customer. ID, Phone,

Tables en 3 NF Rentals(Trans. ID, Rent. Date, Customer. ID ) Customers(Customer. ID, Phone, Name, Address, City, State, Zip. Code ) Videos. Rented(Trans. ID, Video. ID, Copy#) Videos(Video. ID, Title, Rent)

Procédure pour obtenir la 3 NF u u u Diviser les sections de données

Procédure pour obtenir la 3 NF u u u 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 4 NF u u u Employee. Tasks(E#, Specialty, Task#) Techniquement, si

Définition de la 4 NF u u u Employee. Tasks(E#, Specialty, Task#) Techniquement, si toutes les colonnes sont clé alors la devrait être en 3 FN. Dans certain cas il y a des dépendances fonctionnelles cachées entre les colonnes clés. Exemple: – Employee. Tasks(E#, Specialty, Task#) – Est en 3 FN (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. Employee. Specialty(E#, Specialty) Specialty(Specialty, Task#) Employee. Tasks(E#, Specialty, Task#) Specialty(Specialty, Task#) le e acc b pta

u u u Boyce-Codd Normal Form (BCNF) Dépendances fcts cachées Employee-Specialty(E#, Specialty, Manager) Exemple:

u u u Boyce-Codd Normal Form (BCNF) Dépendances fcts cachées Employee-Specialty(E#, Specialty, Manager) Exemple: – Employee-Specialty(E#, Specialty, Manager) – Est en 3 FN. Employee(E#, Manager) Rêgle d’entreprise – “Business rules”. – Un employé peut avoir plusieurs spécialités. Manager(Manager, Specialty) – 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é. Employee(E#, Specialty, Manager) – Besoin d’une table séparée pour “manager”. Manager(Manager, Specialty) – But then we don’t need to repeat specialty. Dans monde réel, la duplication serait ble a t p e probablement acceptée (spécialité dans les 2 acc tables.