1 Modèle Relationnel Witold Litwin

2 2 Le Rapport de Recherche qui a lancé les SGBDs Relationnels (publié uniquement en interne à IBM Almaden Research Center (CA) BD Relationnelle

3 3 Le Rapport de Recherche qui a lancé les SGBDs Relationnels (Résumé)

4 4 BD Relationnelle Le Rapport de Recherche qui a lancé les SGBDs Relationnels (Table des Matières)

5 Base de données relationnelle Fichier =tableourelation Donnée =ligneouattributatomique Opérations = transformations de tables en unetable Opération relationnelle

6 6 SQL: Select S#, SNAME, STATUS FROM S WHERE CITY = Paris Algèbre relationnelle : (S WHERE CITY = 'Paris') [S#, SNAME, STATUS] S Exemple

7 Base de données relationnelle u Une collection d'objets : u Relations réelles (tables de base) u Liens sémantiques u Contraintes d'intégrité (surtout référentielle) u intra-relationnelles u Mono-attribut et multi-attribut u inter-relationnelles u Intégrité référentielle surtout u Déclencheurs (ang. triggers) notamment pour maintenir l'intégrité u Autres (procédures stockées…) u Schéma conceptuel = Définition de la collection

8 Empl (E#, Nom, Prénom, Né, Rue, CodePost, Ville, Dep#) ; E# Counter ; Nom Text ; Né Date ; Dep# Int... :Syst-date - Né < 65* Contrainte de validation Dep# Not Null ; * Contrainte d'existence Taches (T#, Description) ; Planning (E#, T#, Date-fin, Avancement) ; Dep (Dep#, Name) ; Trigger on Empl On Insert Check-Ref-Int (Dep, Empl.Dep#) ; u Autres Déclencheurs utiles ? u Ce schéma est possible sous MsAccess, bien que exprimé différemment Schéma de BD Entreprise clé

9 Schémas Externes u Schéma (vue) externe = Collection de vues relationnels (tables virtuelles dérivées de relations réelles) u Un usager ne voit pas de différence entre une vue relationnelle et une table réelle u En principe ! Une vue relationnelle n'est pas une vue externe au sens ANSI-SPARC Celle-ci serait une base virtuelle

10 P

11 P P1 Create View P1 as select P#, PNAME, COLOR from P;

12 P P1 Create View P1 as select P#, PNAME, COLOR from P; P2 Create View P2 as select P#, PNAME, COLOR from P where CITY = 'London';

13 P

14 P P1 P2

15 Base relationnelle Tables réelles

16 Base relationnelle Tables réelles et vues

17 Relations u D i ; i = 1,2..n des ensembles dits domaines u Une relation R est un sous-ensemble de produit cartésien: R D i,1 x D i,2... x... D i,k k u Les D i,j sont les attributs de R ; les rôles de domaines (Codd) u Les éléments de R sont dit tuples u Il ny a pas de tuples égaux dans une relation

18 Relations u Dans une BD relationnelle, on na que des relations finies u En nombre dattributs et en nombre de tuples u Toute valeur dun d D i est atomique u Pas un ensemble u donc mono-valeur u donc indécomposable u sans perte de la sémantique u De telles relations sont dites normales u Autrement dit en 1 NF au moins

19 P1 P2 P3 P4 S1 S2 P1 P2 P3 P1 P2 P3 P4 P1 P2 P3 S1 S2 1 NF Relations 0 NF Attribut multi-valeur Attribut atomique

20 S1 S2 P1 P2 S1 S2 P1 P2 P3 P4 P1 P2 P3 S1 S2 1 NF Relations 0 NF Attribut multi-valeur Attribut atomique P3 S1 S2 P4S1 La même 1NF !

21 u Les noms R et D i,j constituent le schéma de la relation u Ce schéma et l'ensemble des éléments possibles de R constituent une intention de R. u Les éléments de R y présent à un moment donnée constituent une extension de R. u Une mise à jour modifie une extension et change l'état de la base Schéma d'une relation

22 Un état de la base S-P S P SP Intention de S Une extension de S

23 u Deux relations R et R' sont égales si elles diffèrent seulement par ordre : u d'attributs (colonnes) u de tuples (lignes) Egalité de relations

24 Une même relation S

25 u Une mise à jour est correcte si la nouvelle extension est dans l'intention de R u C'est le rôle des contraintes d'intégrité de ne permettre que les mises à jour correctes u Un changement de schéma de R est une restructuration MAJ / Restructuration

26 Emp (E#, Nom, Prénom, Age, Rue, CodePost, Ville, Dep#) ; Age < 65* Contrainte de validation Dep# Not Null ; * Contrainte d'existence Update Emp Set Age = 35 Where E# = '123' ; Update Emp Set Age = 75 Where E# = '456' ; Alter Emp Add Tel Integer ; SQL : MAJ / Restructuration ?

27 Opérations relationnelles u Une relation est un fichier qui supporte les opérations relationnelles u Une opération relationnelle transforme des relations arguments dans une relation résultat : u une relation temporaire n'appartenant pas au schéma de la base. u une relation de la base (mise à jour) u une vue

28 Opérations relationnelles u Pour une BD relationnelle, les opérations sont définies sur les relations normales u Celles basiques forment lalgèbre relationnelle u Définie par E. Codd u En pratique, il y a aussi des opérations additionnelles u Arithmétiques, agrégations…

29 Opérations relationnelles u Sélection : u Projection u Restriction u Jointure naturelle ou u Division u Agrégation u Opération suppl. u Mise à jour u Création d une vue Voir le cours sur lalgèbre relationnelle Op. ensemblistes: UNION, INTER, DIFF, TIMES

30 u R1 UNION R2 u R1 INTER R2 u R1 DIFF R2 u Elles sont union-compatibles u Même nombre dattribut u Types dattributs compatibles u Permettant dévaluer « = « sur les attributs u La définition de compatibilité dépend du SGBD u Même de sa version Op. ensemblistes UNION, INTER, DIFF

31 u Produit cartésien u R1 TIMES R2 u Pas de contraintes sur les types dattributs u Ni sur leur nombre u Opération très chère que lon évite à tout prix Op. ensemblistes TIMES

32 Base S-P S S [S#,SNAME] S [CITY] S WHERE CITY = Paris Villes de fournisseurs Ids et noms de fournisseurs

33 Jointure naturelle u La jointure A JOIN B de deux tables A (X, Y) et B (Z, Y) est la table C avec les attributs : C (X, Y, Z) et avec tous les tuples (X:x, Y:y, Z:z ) tels que (x, y) est dans A et (y, z) est dans B u pas dautres tuples u X, Y, Z peuvent être composés

34 Jointure naturelle Est-ce que la jointure naturelle est commutative et/ou associative ? Notamment \ une sélection ou une projection ? A JOIN B =? B JOIN A A JOIN B JOIN C = ? A JOIN (B JOIN C) A JOIN A JOIN A = ?

35 CS SC CS JOIN SC S S [STATUS, CITY] S [S#, CITY]

36 S#SNameStatusCity s1smith20London s2Jones10Paris s3Blake30Paris s4Clark20london s5Adams30Athens s#P#qty s1p1300 s1p2200 s1p3400 s1p4200 s1p5100 s1p6100 s2p1300 s2p2400 s3p2200 s4p2200 s4p4300 s4p5400 S JOIN SP S#SNameStatusCityP#qty s1smith20Londonp2200 s1smith20Londonp3400 s1smith20Londonp4200 s1smith20Londonp5100 s1smith20Londonp6100 s1smith20Londonp1300 s2Jones10Parisp1300 s2Jones10Parisp2400 s3Blake30Parisp2200 s4Clark20londonp2200 s4Clark20londonp4300 s4Clark20londonp5400 S SP Fournisseurs avec les fournitures

37 -jointure u Table C égale à : C = ( A TIMES B ) WHERE X Y est la jointure de tables A(X,...) et B (Y,...). TIMES est un produit cartesien X et Y sont non-composites La jointure est notée : C = A JOIN B ON X Y.

38 - jointure / Equi-jointure C = A JOIN B ON X Y est une equi-jointure. u A ne pas confondre avec la jointure naturelle u Où lattribut Y de jointure peut être de plus composite Est-ce que la jointure est commutative et/ou associative ?

39 Division u Table C ( X ) notée: A DIVIDEBY B est une division de tables A (X, Y) et B (Y) ssi C contient tous les tuples ( x ) tels que ( y ) B, ( x, y ) A S# P# S1 P1 S1 P2 S2 P1 S2 P3 P# P1 P2 S# S1 Tout fournisseur de pièces P1 et P2. DIVIDEBY est associatif ou commutatif ?

40 Requêtes algébriques à la base S-P u S JOIN SP WHERE P# = 'P2' [ SNAME] u S JOIN SP WHERE P# = 'P2' WHERE STATUS > 100 [SNAME] u P WHERE COLOR <> 'Red' [P#] JOIN SP [S#] JOIN S [SNAME] u P WHERE COLOR <> 'Red' [P#, PNAME] JOIN SP [S#, PNAME] JOIN S [SNAME] SP [S#, P#] DIVIDEBY P [P#] JOIN S [SNAME] SP [S#, P#] DIVIDEBY (( SP WHERE S# = 'S2') [P#])

41 Requêtes algébriques à la base S-P u [SCITY] UNION [PCITY] u S JOIN (SP WHERE P# = 'P2) INTER ( S JOIN SP ) WHERE P# = 'P3' [ SNAME] u S DIFF (S JOIN (SP WHERE P# = 'P2' [S#])) [ SNAME] u S TIMES SP WHERE P# = 'P2' WHERE STATUS > 100 [ SNAME]

42 Utilité de l'algèbre u Puissance expressive: u 8 opérateurs de Codd permettent d'exprimer toute expression logique de prédicat de 1-er ordre u note: seulement 5 sont primitives (lesquels ?) u La puissance expressive de l'algèbre dite complétude relationnelle constitue la mesure de la puissance minimale de tout LMD assertionnel digne de ce nom

43 Utilité de l'algèbre Technique de choix pour l'implémentation Il n'y a que 8 opérateurs Ces opérateurs sont faciles à implémenter Leur propriétés permettent de transformer les expressions en +efficaces à évaluer, en général Améliorations algébriques Moins de valeurs à lire ou écrire Moins de mémoire nécessaire pour ces valeurs Voir mon cours sur lalgèbre

44 Utilité de l'algèbre u Exemple (( S JOIN SP ) WHERE P# = 'P2' ) [SNAME] = ( S JOIN ( SP WHERE P# = 'P2' )) [SNAME] u La 2ème expression semble plus efficace ? u Règle Générale dAmélioration ? (A JOIN B WHERE A.a = C) (A WHERE a = C) JOIN B

45 Opérations relationnelles (SQL) Voit (Im#, Pref, Mod, Couleur) Amende (A#, I#, Nom, Addr, Payé) u Select * From Voit Where Couleur = 'rose'; u Select Mod From Voit u Select * From Voit, Amende u Select Nom, Addr From Amende, Voit Where Payé Is Null and Mod = 'Ferrari' and I# = Im# ;

46 Opérations relationnelles (SQL) Voit (Im#, Pref, Mod, Couleur) Amende (A#, I#, Nom, Addr, Payé) u Update Amende Set Payé = ' ' where A# = '123' ; u Create View En-instance As Select * From Amende, Voit Where Payé Is Null and Amende.I# = Voit.Im# ;

47 Complétude relationnelle de SQL expression algébrique, une expression équivalente de SQL et de QBE Schéma de preuve: opérateur algébrique, une expression équivalente de SQL composition d'opérateurs algébriques, une composition équivalente de SQL

48 u Une relation réelle est définie à partir des valeurs de ses attributs u Une relation virtuelle (vue) est dérivée (héritée) par une opération relationnelle à partir de relations réelles ou de vues Relations

49 u En général, une valeur dun domaine et donc dun attribut peut être un ensemble u XML, Access 2007 u Pour les opérations relationnelles dans les SGBD actuels, ils ne sont néanmoins en principe que des valeurs atomiques u Toute décomposition fait perdre la sémantique de la valeur u De telles relations sont dites normales Relations

50 P1 P2 P3 P4 S1 S2 P1 P2 P3 P1 P2 P3 P4 P1 P2 P3 S1 S2 Norm. O NF1 NF Toute valeur de S# et toute de P#Une ligne S#P#S#P# Contrainte très importante ! 9 valeurs14 valeurs

51 P1 P2 P3 P4 IBM HP P1 P2 P3 IBM IBN IMB HP S1 S2 Norm. O NF1 NF Toute valeur de S#, Name et toute valeur de P# Une ligne NameP#S#Name Redondances & Erreurs Peu acceptables en général S1 S2 S# P1 P2 P3 P4 P1 P2 P3 P# DF: S# -> Name 11 valeurs21 valeurs

52 P1 P2 S1 S2 P4 P5 P6 P7 P1 P2 P4 … S1 S2 … Norm. O NF 1 NF Toute valeur de (S#, P#, L#)Une ligne S#P# S#P# L1 L2 L3 L4 L5 L6 L# L1 L2 L3 L1 L2 L3 L4 L5 L6 … L# DM: S# ->> P# | L# Redondances multiples Inacceptables en général 14 valeurs54 valeurs

53 Normalization en 1-NF u Explosion combinatoire de la taille de la table ! u Etud (E#, Tel, Hobby, Dipl, Enfants, Voit) u Etudiant Dupont: u 3 tel, 5 hobbies, 3 diplômes, 3 enfants, 2 voitures u Un tuple due relation en 0-NF suffit u Il faut 3*5*3*3*2 = 270 tuples u Un tuple pour toute combinaison dun tél, un hobby, un dipl…. u Pour une relation en 1-NF avec 1 tuple seulement !

54 Normalization en 1-NF u Il faut 1620 valeurs en 1NF u Pour 17 valeurs seulement en 0NF u Sous peine de perte dinfo u Une requête pourrait alors donner le résultat faux u L tout est inacceptable en général u Et si on a aussi le nom pour chaque étudiant ?

55 Solutions pour la Conception u Alors comment faire ? u Décomposition sans perte de données en plusieurs tables sans anomalies ET (E#, Tel), EH (E#, Hobby) ED (E#, Dipl), EE (E#, Enfants) EV (E#, Voit) u Seulement 16 tuples au lieu de 270 u Seulement 32 valeurs au lieu de 1620

56 Solutions pour la Conception u Peut-on généraliser cette idée ? u Oui, mais ce nest pas simple u Deux voies principales 1. Empirisme et Expérience u Entity – Relationship u Merise u … u UML

57 Solutions pour la Conception 2. Démarche Formelle u Par les Maths u Normalisation en i-NF i 5 u Voir mon cours sur la normalisation pour + u En général 4 NF suffit u On fait la décomposition sans perte de données u Quand on peut, sans pertes de DFs aussi

58 Solutions pour la Conception u On élimine dabord les DMs u Génératrices danomalies les plus graves u Quand passe une table de 0 NF à 1 NF u Comme on a vu u La décomposition conduit aux plusieurs tables sans DMs

59 Solutions pour la Conception u Certaines tables peuvent avoir encore des DFs « anormales » u A lorigine danomalies aussi u Comme on a vu u Moins graves que celles de DMs u On décompose ces tables aussi u En se débarrassant des anomalies crées par ces DFs

60 Solutions pour la Conception u Lest tables résultantes sont alors en toutes en BCNF u A fortiori en 4NF u Le résultat est en général optimal pour le relationnel classique u Pas danomalies ou de redondances u Toute table est en 5NF u Voir le cours sur la normalisation

61 Solutions pour la Conception u Restent la présence de valeurs nulles u Elle peut créer des anomalies aussi u On y remédie par une décomposition sans perte aussi u Mais, avec la recomposition par jointures externes u On verra + tard

62 Solutions pour la Conception u Dans lensemble, pour progresser il nous faut un petit rappel sur: u Les clés u Les liens sémantiques u Les valeurs nulles u Ce que lon va faire très bientôt dans ce qui suit

63 Et la Manipulation ? u Le problème reste ouvert dans le relationnel classique: u SELECT E#, Tel, Hobby, Dipl., Enfants, Voit FROM ET, EH, ED, EE, EV WHERE ET. E# = ET. E# AND ET. E# = ED. E# … u Produit une relation virtuelle en 1-NF u Fera revenir les 270 tuples discutés u Une solution: la fonction agrégat LIST u Votre prof. & SQL Anywhere u Le cours sur SQL avancé

64 u Dans toute relation R il existe une combinaison C d'attributs dite clé telle que u dans tout tuple t d'intention de R, la valeur C(t) identifie t, u il n'y a pas de sous-combinaison de C avec cette propriété u Démontrez cette assertion ! u Exemples: N° SS, N° Étudiant, Nom de pays, (Nom, Prénom, Tel), Oid,... Clés

65 u Le choix de C est dicté par l'intention de R u Soit R = Pers (Nom, Prénom, SS#, Tel) u Dans une famille Pers (Nom, Prénom, SS#, Tel) /* Tout membre u A la SS Pers (Nom, Prénom, SS#, Tel) /* Assuré seuelement u A l'état civil Pers (Nom, Prénom, SS#, Tel) /* Toute personne u Les valeurs d'un attribut d'une extension peuvent à un moment donné être toutes différentes sans qu'il s'agisse d'une clé ! Clés

66 u C atomique consiste dun attribut u C composite en contient plusieurs u Tout attribut dune clé est dit attribut- clé u Tout autre attribut est un attribut non- clé u Cest une fonction de toute clé de la table u Cette propriété est la base dune définition du concept de la clé Clés

67 u Il ne faut pas confondre le concept de la clé avec celui dun attribut-clé u Ce dernier ne pas la clé dès que la clé est composite u Dans Pers (Nom, Prénom, SS#, Tel) u SS# est la clé et lattribut-clé u Dans Pers (Nom, Prénom, SS#, Tel) u Nom nest que lattribut-clé Clés

68 u Si C est clé de R, alors tout ensemble dattributs de R strictement incluant C est appelé sur-clé ou super-clé Dans notre base S-P, S# est une clé de S, donc (S#, SNAME) est une sur-clé de S. Et les attributs (SNAME, STATUS) ne sont même pas une sur-clé Relations

69 u R peut avoir plusieurs clés. Dans ce cas: u Une clé est arbitrairement choisie est dite primaire u Les autres deviennent clés candidates seulement u Une seule clé existante dans une table est formellement une clé candidate aussi u Pour certains, néanmoins, la clé primaire nest plus une clé candidate Relations

70 u R peut avoir plusieurs clés de cardinalités différentes. u La clé avec le plus petit nombre dattributs est dite alors minimale u A choisir de préférence Relations

71 u Une clé C d'une relation R peut être des attributs F d'une autre relation R' u F deviennent une clé étrangère dans R u F n'est pas en général une clé de R' Relations

72 u L'égalité C = F constitue le lien sémantique entre les relations correspondants u Entre C et F il peut exister la contrainte d'intégrité référentielle u Pas de F sans C u Pas de participant qui ne serait pas un étudiant connu u Dans un SGBD de 2-ème génération ces liens étaient les références implicites (pointeurs) u Dans UML aussi en principe Relations

73 Voit (Châssis#, Moteur#, Plaque#, Mod, Poids, Coul ) Clé primaire Clé candidate Etud (E#, Nom, Prénom, Tel, Adresse ) Participants (C#, E#, Note) Clé étrangère Clé candidate composée

74 u Les SGBD majeurs gèrent désormais des contraintes IR ainsi que les liens sémantiques u MSAccess : u IR 1:1 et 1:N entre deux tables u Sur un ou plusieurs attributs à la fois u Quelques bugs pour 1:1 u Voir la suite du cours u Jointures implicites ou automatiques à partir de liens sémantiques u Voir la suite du cours Relations

75 Intégrité référentielle Mari M# 1 1 Mari M# Femmes F# 1 N Amie A# M N PP#, PS# Produit Composé Produit P# Femme F# 11 N N Ami A# Comment faire ?

76 u Les clés C et F peuvent aussi être dans une même relation: Emp ( E#, Enom, Tel, Chef# ) Personne ( SS#, Nom, Mère#, Père#) u De tels liens génèrent les récurrences exigeant le calcul de fermetures transitives u Les opérations relationnelles ne permettent pas de calculer les fermetures transitives u Les SGBD en général ne gèrent pas de tels liens sémantiques Intégrité Référentielle

77 u Néanmoins MsAccess le fait u Dune manière limitée u Par la déclaration adéquate de relations u Pour lintégrité référentielle u Par la définition correcte de sous- feuille (sous-table) u On déclare la table elle-même comme sa propre sous-feuille (sous-table) u Pour voir en un clic les employés dun chef etc. Intégrité Référentielle

78 u Une valeur nulle est un abus de langage pour designer une absence de valeur dun attribut u On dit aussi un nul ou un null (ang. null) Valeurs nulles

79 u Valeur inconnue u Ville de fournisseur inconnue u Valeur inapplicable u Fournisseur connu pour être sans statut u Nom de jeune fille pour un monsieur u Cette distinction est rarement appliquée en pratique Types de nuls

80 Comment faire alors sil le faut ? Pour lattribut # TEL faut distinguer entre: # tel portable inconnu on relancera la personne pour connaître son numéro Personne sans téléphone portable Types de nuls

81 u Ce type de nul peut indiquer alors lexistence dune sous-classe u Etudiants dans Etud qui nont pas denfants u Il est souvent utile davoir une ou des tables dédiées à la sous-classe u Sous peine danomalies graves u On reverra ce problème Types de nuls

82 Pourquoi ? Une propriété qui peut sembler anodine En fait elle est dune importance capitale pour une base relationnelle conduit à la démarche dite de modélisation relationnelle notamment aux formes normales Le nul et la clé primaire Un attribut-clé de la clé primaire ne peut être nul

83 u Cette propriété est à lorigine de lanomalie dinsertion u Il s`agit de limpossibilité de linsertion dun tuple à cause dun attribut clé nul u Dans Etud en 1NF il pourrait sagir de tout attribut Etud (E#, Tel, Hobby, Dipl, Enfants, Voit) Le nul et la clé primaire

84 u P. ex. impossible dinsérer une donnée quelconque dun étudiant sans enfants u La décomposition sans perte peut être la solution u Voir Etud décomposé u Mais pas toujours Le nul et la clé primaire

85 u On peut interdire la présence dun nul pour un attribut Dans la définition de lextension de la relation Notamment dans MsAccess La théorie initiale du modèle relationnel ne prévoyait pas de tables avec des nuls Les nuls en perspective

86 Lintroduction de nuls a été faite par les « praticiens » Elle a crée de nombreux problèmes théoriques et pratique Beaucoup restent non-résolus Voir + dans le cours sur le site et dans le cours sur SQL Les nuls en perspective

87 Ex. MsAccess Deux nuls sont égaux pour Distinct et Group By Ils sont différents pour lequi-jointure Un nul est plus grand que tout non-nul Somme (nul, a) = a mais nul + a = nul Une requête peut générer une table avec tous les tuples entièrement nuls Vous avez dit bizarre ? Les nuls en pratique

88 Modélisation relationnelle u Passage du monde réel vers une base relationnelle u Le schéma conceptuel u Schémas de tables u Liens sémantiques & contraintes IR u Opérations permises u Les schémas externes

89 Modélisation relationnelle u Souvent fort simple u Lattrait de bases relationnelles u Exemples typiques commentés en cours u Fournisseurs et Pièces (Supplier Part DB) u Conseillers en assurances et Produits dAssurances u Etudiants et Cours

90 Modélisation relationnelle BDR

91 Modélisation relationnelle u Méthodes « grand-public » semi-formelles u ER u ERG u Merise… u UML u Le résultat peut être optimal u Méthode formelle u Le résultat optimal garanti

92 Démarche semi-formelle u Trois phases 1. Modélisation conceptuelle par spécifications fonctionnelles u Pas particulière au relationnel u Ni aux BDs même 2. Conceptuel – Relationnel u Transformation du modèle conceptuel en CS et ESs dune BD 3. Normalisation u Amélioration du CS par suppression des anomalies

93 Démarche formelle u Deux phases 1. Modélisation conceptuelle par spécifications fonctionnelles 2. Conceptuel –> Relationnel 1. Normalisé 2. Sans sous-classes cachées

94 Une base relationnelle n'est correctement définie que si son le graphe de références est un graphe connecté u Une BD relationnelle en général comporte plusieurs relations u Un graphe de références représente sa structure u Les nœuds sont des relations u Les arcs orientés sont les contraintes d'intégrité référentielle C -> F u 1:N ou 1:1 u Les autres sont les liens sémantiques Modélisation Relationnelle Graphe de références

95 u Graphe des références à nombre minimal de nœuds u Sous contraintes : u Dabsence danomalies u Dinsertion, suppression, MAJ u De minimisation de redondance globale de données u Par rapport à 0NF surtout u Les deux contraintes sont duales Résultat Attendu: Graphe de références optimal

96 u Graphe des références à nombre minimal de nœuds u Sous contraintes : u Préservation du max. de dépendances fonctionnelles (FDs) u Absence de dép. multivaluées (DMs) u Pas ou peu de valeurs nulles u Cette contrainte peut contredire celle sur les anomalies & redondances u Il faut alors exercer le bon sens Résultat Attendu: Graphe de références optimal

97 u Anomalie dinsertion u On ne peut pas insérer de valeurs quil faudrait u Soit la table S = (S#, Sname, Status, City, P#, Qty) u Fournisseur S1 ne fournit encore aucune pièce u On ne peut pas insérer ses données: u Fournisseur S1 est Smith, a le statut 20 et est à Londres Modélisation relationnelle : Anomalies

98 u Anomalie dinsertion u Il faut insérer une même donnée plus de fois que nécessaire u En idéal : une donnée nest insérée quune fois dans la base u Ex. 1 Revoir notre exemple illustrant 1NF u La conception en une table présente lanomalie Modélisation relationnelle : Anomalies

99 u Ex. 2 Dans S, si S1 fournit 5 pièces, alors on insère aussi Sname, City, Status 5 fois u Soit maintenant la conception en deux tables S = (S#, Sname, City, Statuts) SP (S#, P#, Qty) Modélisation relationnelle : Anomalies

100 u La conception est libre de deux aspects discutés de lanomalie u On peut insérer les données sur S1 même sil ne fournit rien actuellement u La base peut contenir davantage de données u On ninsère aussi Sname, City, Status quune fois Modélisation relationnelle : Anomalies

101 u En supposant quen général un fournisseur fournit plusieurs pièces, on diminue la redondance globale u Bien que lon laugmente nécessairement localement pour S# Modélisation relationnelle : Anomalies

102 u Ex. 3 Soit la table S' = (S#, Sname, Status, ZIP, City) u Pour chaque ZIP il ny a quune ville u Il faut répéter la ville inutilement quand plusieurs fournisseurs partagent un même code postal u La solution ? u Problème dit de 3NF Modélisation relationnelle : Anomalies

103 u Ex. 4 Soit notre table S S = (S#, Sname, Status, City, P#, Qty) u Supposons que S# et Sname sont deux clés candidates dans S (S#, Sname, Status, City) u S présente la même anomalie quavant u Une autre solution en plus de celle de la décomposition en tables S et SP déjà discutées? u Problème dit de BCNF Modélisation relationnelle : Anomalies

104 u Ex. 4 Soit la table P = (P#, Pname, E#, Sal, S#, Dipl, V#, Lab) u Une personne est en général soit un employé, soit un étudiant, soit un visiteur u Une insertion génère un général beaucoup de nuls u Une anomalie non considérée par le relationnel classique u On y reviendra + tard Modélisation relationnelle : Anomalies

105 u Enfin, supposons que lon conçoit au lieu de S trois tables S1 (S#, Sname), S2 (S#, City), S3 (S#, Status) u On insère S1 trois fois de trop, par rapport à S u Trop de tables conduit à lanomalie aussi Modélisation relationnelle : Anomalies

106 u Anomalie de MAJ u On MAJ plusieurs valeurs au lieu dune seule u Pour une bonne conception u Dans S, si S1 fournit 5 pièces et déménage à Paris, alors il faut mettre à jour 5 valeurs u Dans S, il suffit dune seule Modélisation relationnelle : Anomalies

107 u Anomalie de suppression u On supprime les valeurs quil ne faudrait pas u Dans S, si S1 fournit 5 pièces u Si lon supprime 4 fournitures, les données de S1 restent dans la base u Si lon supprime la dernière fourniture, on les perd u Pas si lon a la conception en S et SP Modélisation relationnelle : Anomalies

108 u Plusieurs relations u Chaque relation consistant u dune clé u de max dattributs identifiés chacun comme fonctions de la clé u On respecte aisément la condition nécessaire u Pas celle suffisante Modélisation relationnelle : Résultat général

109 u Détails dans les exercices vus en classe u Pas sur le Web u Dabord, on traduit les spécifications fonctionnelles en une seule relation u Relation universelle Démarche formelle

110 u Relation universelle est souvent notée U u U est un fourre-tout u Sans nuls u Selon le relationnel classique u Si U est sans anomalie et en 5NF on a fini u Cas très rare Démarche formelle

111 u Sinon on procède en deux étapes u On élimine les DMs u Par Th. de Fagin u On élimine des anomalies dues aux certaines DFs u Par Th. de Heath Démarche formelle

112 u Le Théorème de Fagin décompose sans pertes une table u En commençant par U u Chaque décomposition u Liquide une DM u Remplace une table R par deux projections R1 et R2 telles que R = R1 Join R2 Démarche formelle

113 u On continue récursivement pour toute table résultante u Jusquaux tables sans DMs u Nécessairement Démarche formelle

114 u Une table R sans une DM peut présenter encore des anomalies u En présence de DFs sur des attributs que ne seraient pas des clés u Déterminants (mono-valeur) u On passe alors a Etape 2 u Y compris peut-être pour U demblée Démarche formelle

115 u On applique récursivement le Th. de Heath u A chaque fois, on décompose une table sans pertes de données en deux projections u Lune contient seulement la DF max. pour un déterminant qui nest pas une clé u Avec tous les attributs cibles sur ce déterminant Démarche formelle

116 u On liquide à chaque décomp. une anomalie u Due à la DF max. mise dans sa table dédiée u Comme dans notre ex. de passage 0NF -> 1NF u Revoir aussi la def. de la BCNF u Il en résulte le schéma avec le minimum de tables sans anomalies dues à de telles DFs u En 4NF, vu lélimination des DM déjà Démarche formelle

117 u La décomposition doit chercher des projections indépendantes u Pour ne pas perdre de DFs u Ce nest pas toujours possible u Voir la discussion de la BCNF dans le cours sur la normalisation u On sarrête quand il ny a plus de table avec une anomalie due à une DF Démarche formelle

118 u Si les nuls sont permis, alors on passe à létape 3 u On suppose quune table R dans le résultat peut contenir de nuls non-clé u Contrairement aux relationnel classiques u Donc a la Théorie des NFs Démarche formelle

119 u On regarde si R na pas alors « trop » de nuls u Seul le bon sens dit si trop de nuls cest vraiment trop u Ces nuls peuvent indiquer des sous- classes u Sous-types Démarche formelle

120 u Il faut alors encore décomposer u Mais comment et sur quel base théorique ? u On ne peut plus employer de jointures naturelles (internes) u Le principe de la décomposition sans perte classique u Notamment des Etapes 1 et 2 Démarche formelle

121 u On peut néanmoins décomposer sans perte R alors en utilisant les jointures externes u Théorème de votre prof. u Détails dans les exercices Démarche formelle

122 u Ensuite, on crée récursivement entre les relations obtenues u Les liens sémantiques u Les contraintes dintégrité référentielle u Le tout selon lapplication u Entre les clés primaires ou candidates et les clés étrangères Modélisation relationnelle : Toute Démarche

123 u Enfin, on choisi pour chaque contrainte référentielle et chaque lien sémantique sa jointure implicite u Une jointure ajoutée automatiquement à la requête en mode QBE Modélisation relationnelle : Toute Démarche

124 u Requêtes courantes deviennent + simples u - procédurales, u + assertionnelles… u Cette possibilité dans les SGBDs commerciaux vient de MsAccess u Suivi par quelques autres SGBDs u SQL Server, DB2, Sybase (?)… Modélisation relationnelle : Toute Démarche

125 u En fait, les jointures implicite ont été proposées dans les 80 u Par votre prof. et son Thésard A. Abdellatif (INRIA) u Prof. à Tunis Modélisation relationnelle : Toute Démarche

126 u Développées avec Prof. G. Wiederhold u Ont donné lieu au Ph.D. de son étudiant B. Lee (Stanford) u Papiers sur la page Web de votre prof. Modélisation relationnelle : Toute Démarche

127 u Type de jointure implicite pour le lien sémantique (MsAccess) u Interne (défaut) u Produit seulement les tuples de deux tables ou les valeurs jointes sont égales Modélisation relationnelle : Toute Démarche

128 u Externe u Préserve toutes les tuples dune de deux tables u Au choix sous MsAccess u Mais pas les deux tables à la fois u Pas de jointure externe complète sous MsAccess Modélisation relationnelle : Toute Démarche

129 u On peut demander N°, nom, NomJF, tel, ville, en QBE u Sans spécifier les jointures u La réponse serait OK u Elle serait erronée pour les jointures internes u Pourquoi ? 300 Modélisation relationnelle : Toute Démarche

130 u Jointures externes sont mal supportées par MsAccess u Absence de la théorie cohérente u Bugs u Voir + dans le cours sur SQL u A nutiliser comme implicites que quand cest vraiment utile et testé Modélisation relationnelle : Toute Démarche

131 u Expérience dapplication u Les exercices u Voir ceux du cours u La pratique u Voir la vie autour u Dauphine, Votre entreprise, Facebook, Ecole de Conduite, vos CDs… Modélisation relationnelle : Démarche formelle

132 Spécifications fonctionnelles u Une entreprise a des fournisseurs S u Un fournisseur f a un ID, un nom, un statut, et est dans une ville u Un f fournit des fournitures SP de pièces P u Chaque fourniture fp comporte une certaine quantité d'une pièce p u Chaque p a un ID, un nom, un poids, une couleur u Une pièce p peut être l'objet de plusieurs fournitures fp Exemple canon

133 Schéma Conceptuel S S# Sname Status City P P# Pname Color Weight City SP P# S# Qty 1 * * 1

134 Jointure Implicite (S – SP) Choix de jointure interne (défaut)

135 Résultat pour une requête QBE SQL

136 Exemple canon S P SP

137 u Cas particulier u Tout employé a un et un seul poste tél, u Il y a aussi des postes non-assignés u Dans la base créée par la démarche générale on aurait que : Empl (E#, Nom, PosteTel,…) Modélisation relationnelle : Démarche générale

138 u On a une anomalie dinsertion u Laquelle ? u On ajoute la table Postes (PosteTel) u Avec une contrainte dintégrité u Laquelle ? Modélisation relationnelle : Démarche générale

139 u Cas particulier Pers (P#, Nom, Pnom, DNaiss, CP,…) CV (CP, Ville) u Que faire si lon sait que P1 est à Paris, mais lon ne connaît pas CP ? u Pas de problème par contre avec la conception dénormalisée Pers (P#, Nom, Pnom, DNaiss, CP, Ville) Modélisation relationnelle : Toute Démarche

140 u Cas particulier VRP (P#, Nom, Pnom,…) Planning (P#, Ville, JourSem) u Un VRP fait plusieurs villes avec des jours spécifiques pour chaque u Les deux attributs Ville et JourSem seraient multi-valeur par rapport à P# u On les met néanmoins dans la même table Modélisation relationnelle : Démarche générale

141 u La raison est quil sagit dune (plus rare) association ternaire u les valeurs de ces attributs ne sont pas indépendantes u VRP X visite Ville Y le JourSem Z u Le même principe sapplique à toute association de dégrée + élevé u Rares Modélisation relationnelle : Démarche générale

142 u Cas particulier Pers (P#, Nom, Pnom, Sex, Célib,…) PJf (P#, NJf) u NJf existe seulement pour les dames mariées u Si les Jeunes Filles sont rares, la conception normalisée est fortement redondante sur P# Modélisation relationnelle : Démarche générale

143 u En + il faut une jointure systématique pour voir NJf avec le reste du dossier u La conception dénormalisée na pas ceux problèmes Pers (P#, Nom, Pnom, Sex, Célib, NJf…) u Elle est alors préférable en pratique Modélisation relationnelle : Démarche générale

144 u En pratique u Un attribut seul avec nuls fréquents tel que NomJF reste en général dans « sa » table, p.ex., Pers u Attribut à quelques de valeurs, p.ex. N°Tels, donne lieu à un nombre fixe dattributs atomiques dans « sa » table u Tel_M, Tel_B, Tel_P u 1, 2, 3 Modélisation relationnelle : Démarche générale

145 u En pratique u On complète éventuellement la table par une « extension » pour les autres valeurs si besoin u Pers (P#, Tel_M, Tel_B, Tel_P…..) u AutresTels (P#, Tel) u Quel type de jointures implicite serait approprié alors ? Modélisation relationnelle : Démarche générale

146 u En pratique u On sécarte de la démarche générale par pas mal de raisons hors celle-ci, internes surtout u Coût de traitement de jointures u Coût mémoire des indexes pour rendre les jointures rapides u Problèmes théoriques avec jointures externes u …. Modélisation relationnelle : Démarche générale

147 u Conclusion u Il y a ceux et dautres cas spéciaux u Il faut commencer par la démarche générale u Après il faut exercer son bon sens u Selon les contraintes spécifiques de la base u Dénormaliser si utile Modélisation relationnelle : Démarche générale

148 Modèle Conceptuel An mille sept cent quatre-vingt-dix-neuf ? MDCCXCIX ? 1799 Votre modèle / standard préféré ? MDCCLXXXXVXXXX Modélisation Relationnelle Avancée

149 Modélisation Conceptuelle u Univers u Objets u Entités u Propriétés u Associations entre les objets u Fonctions… u Ensembles spécifiques dobjets u Types u Classes...

150 Modélisation Conceptuelle u Universal Modeling Language u Standard Intl. de OMG u Une variante de EER u Extended Entity Relationship Model u ER avait été proposé par Peter Chen u Prof. à U. de Baton Rouge (LU) u Il y a une trentaine dannées u Très populaire dans le temps u Un peu à tort peut-être

151 Passage UML - Relationnel u Entités et Associations doivent devenir u Tables du CS ou des ES u Liens sémantiques u Contraintes dIR u Opérations sur les tables

152 UML u Des diagrammes standard proposées par OMG u Données, Opérations, Messages… u Notamment pour les BDs u Une adaptation dans de dernier but du modèle ER u Une autre présentation de certains diagrammes u Les concepts OO u Composition, Agrégation

153 UML u Objet = Entité (Entity) ou Occurrence dentité u Entité faible u Identifiable seulement dans une autre entité (forte) u Type dobjets = Type ou classe u Propriété = Association (Relationship)

154 UML : Type dEntité Nom Attributs clé et non-clé Opérations

155 UML : Type dEntité Pour le relationnel Attributs atomiques ou dérivés seulement Tout attribut atomique est fonctionnellement dépendants sur la clé On note une dépendance fonctionnelle (FD) de B sur A comme A -> B Pas dattributs multivalués ou composés Attributs dérivés sont pour les schémas externes et les sous-tables (Access) Les spécifs des opérations sont rares

156 UML : Type dEntité Personne P# Nom Prénom Nom de famille Hobbies Amis Restaurants Valide pour XML Pas pour le relationnel Il faut mettre tout composite ou multivalué en type dentité séparé (en principe)

157 UML : Type dEntité Personne P# Nom Prénom Nom de famille Hobbies Hobby Amies Ami Restaurants Restaurant 1..* * *

158 UML Assuré Client# Produit dass.# Prix Prix/Prix total per client Valide pour le relationnel Mais réalisable seulement comme une table et une vue Attribut dérivé Prix total = Prix de tous les produits du client

159 UML Associations Modèle dune auto-école basé sur lex. de M. Manouvrier Lécole peut envoyer entre 0 et 8 étudiants à un exam Diagramme de note en UML Appartient à Rôle de lassocion (directionnelle) Nom de lassociation Abréviation de 0..* Exactement 6 séries / CD

160 UML : Association n-aire u Les patients P sont soignés par des médecins M, dans des services S u Un médecin peut être partagé entre plusieurs patients et services 1 P S Soin M Que disent les chiffres ?

161 UML : Association 1-aire Personne P# Nom Prénom Père Mère Ancêtre

162 UML u Concept de composition u Les entités composantes nont pas dexistence propre u Ex. Les salles dun bâtiment u La suppression de la composition supprime aussi les composantes u Contrainte dintégrité référentielle u Symbolisée par losange noir u Les entités composées peuvent être agrégées par ailleurs u Losange transparent Batiment Salle Conf 1 0..* Les cardinalités x..y sont des exemples

163 UML : Classe / Sous-classe u Concept de sous-classes u Spécialisation/généralisation u Symbolisées par la flèche u Mandatory/Optional u Tout membre de la classe est obligatoirement dans une sous-classe u And/Or u Il peut être dans plusieurs sous-classes ou pas Assurance Ass-maisonAss-voitureAss-maladie A# Montant Val-maison Bonus Complément Optional / OR

164 UML / Relationnel Client C# Prénom Nom de famille Ville CP … Acceptable pour le relationnel Mais une mauvaise conception Si statut, comme son nom lindique ne dépend que de C# Si CP implique la ville Assurance A# C# Statut du client Prime … 1 *

165 UML / Relationnel Acceptable pour le relationnel Mais une très mauvaise conception Personne P# Hobby Ami Restaurant Prénom Nom de famille

166 Passage UML - Relationnel u Entités et associations doivent devenir u Tables u Liens sémantiques et contraintes IR u Opérations sur les tables u Dans le modèle UML la représentation des associations nest pas spécifiée u Pourrait être les listes de pointeurs (références) u Manipulées alors différemment dans un langage de programmation que les valeurs directes de données u Principe rejeté par le modèle relationnel

167 Passage UML - Relationnel u Les associations sont les tables comme les autres ou existent entre les valeurs des attributs comme les autres (Codd) u Entre les clés primaire et étrangère en général u Associations triviales : une même valeur dattribut clé étrangère dune table que celle dune clé dune autre table indique un même objet réel u Doù lintroduction et limportance capitale du concept de la clé dans le modèle relationnel

168 Passage UML - Relationnel u Egalement important est le principe que la table est un ensemble donc tout tuple a nécessairement une clé u Constituée peut-être par tous les attributs, mais quand même u Pas une bonne idée u Résultat global: une même expression de manipulations de toutes les données dans la base (Codd) u Un énorme avantage pour le but de non- proceduralité

169 Réification (Etape 1) u Outil Fondamental de passage UML – Relationnel : u On réifie : u Toute classe dassociations en une classe dentités u Toute classe dentités deviendra plus tard une table relationnelle

170 Réification (Etape 1) u Une classe dassociations est peut-être réifiée en celle dentités avec ses classes dentités aux extrémités u Si lassociation est une bijection notamment u Autrement, on transforme une association en celle triviale entre les attributs des entités u Tout attribut structuré ou multivalué est réifié en une entité (séparée et associée par des clés étrangères)

171 Réification (Etape 2) u Toute entité réifiée devient une table relationnelle u Les associations triviales deviennent u Les liens sémantiques u Les contraintes dintégrité réferentielle

172 Réification u Le concept de réification est rarement explicité u La réification est en général manuelle u A lheure actuelle u Cest la principale limitation de lemploi dune BD relationnelle par un usager Tout-le-Monde

173 Réification : Principe Général A A# A1 …. B B# B1 …. C C1 …. A A# A1 …. B B# B1 …. C A# B# C1 …. Association triviale: les deux B# identifient la même entité. Cest une réification adaptée au relationnel pour éviter les anomalies Dautres réifications sont possible (ex. A et B et C en une entité commune) Relation universelle

174 Réification : Principe Général A A# A1 …. B B# B1 …. C A# B# C1 …. A A# A1 …. B B# B1 …. C A# B# C1 …. A lorigine, il ny avait pas de liens sémantiques explicites dans une BD Rel. Les associations triviales devenaient des liens implicites : légalité du nom de la clé primaire et celle étrangère

175 Réification : Principe Général A A# A1 …. B B# B1 …. C RoleA# RoleB# C1 …. Après, oui, notamment pour lintégrité référentielle en utilisant le nom de rôle (nom de lassociation, uni ou bidirectionnelle : ex. Prop._de_la_voiture_) A A# A1 …. B B# B1 …. C A# B# C1 ….

176 Réification & Pointeurs dans les Langages de Programmation u Une association triviale représente dune manière explicite un pointeur dune table vers une autre u La valeur dun pointeur est explicite u Contrairement en principe aux langages de programmation u Dans le modèle relationnel elle est celle dune attribut comme dautres u Presque, car il y a en général les contraintes référentielles à gérer u Un pointeur peut être alors manipulée comme toute autre donnée u Une des idées fondamentales de E.Codd u En fait le concept de la clé est une conséquence de cette idée u Une représentation à la fois compacte et explicite dun pointeur

177 Réification : Association n-aire 1 P S Soin M 1 P S M S# P# M# Soin

178 Réification : Attribut composé Personne P# Prénom Nom de famille Hobbies Amis Restaurants Nom Tel Personne P# Prénom Nom de famille Hobbies P# Hobby Amis P# Ami Restaurant P# Nom Tel Les cardinalités des associations ? Le processus est transitif pour une valeur composée dans un attribut

179 Réification : Attribut composé Personne P# Prénom Nom de famille Hobbies Amis Restaurants Nom Tel Personne P# Prénom Nom de famille P_H P# H# Amis P# Ami Restaurant P# Nom Tel Approche utile pour un entrepôt de données Peut faire gagner de la place en mémoire de stockage (encombrement de H# est souvent bien plus petit que celui du texte de Hobby) Hobbies H# Hobby

180 Réification : Entité Faible C# Client Cl# Conseiller Cl# Nom Cl# nest pas la clé C# Client Conseiller Cl# C# Nom 1 *

181 Réification : Entité Faible C# Client Cl# Conseiller Cl# Nom Cl# nest pas la clé La clé de Client si Conseiller est une entité faible aussi ? C# Client Conseiller ? …. Nom 1 *

182 Réification : Cas Spécifiques Bijection Mari M# A1 …. Femme F# B1 …. Mariés Date …. 1 1 Mariage M# ou F# F# ou M# Date A1 …. B1 ….. On réifie en une entité ( laquelle ?). Changement du modèle conceptuel. On gagne en en général en efficacité en éliminant une jointure Il nest plus possible dintroduire une Femme dont on ne connaît pas la Mari ou vice versa (pourquoi ?) Unique (un seul mariage, pas de personnes remariés ensemble)

183 Réification : Cas Spécifiques Bijection Client C# A1 …. Voiture V# B1 …. Accident Date …. 1 1 On mémorise tous les accidents dun client avec sa voiture Peut-on en général réifier comme auparavant ? Sinon pourquoi pas ?

184 Réification : Cas Spécifiques Injection Mari M# A1 …. Femme F# B1 …. Mariés Date … Femme Mariée ou pas F# M# Date A1 …. B1 ….. Changement du modèle conceptuel On gagne en souvent en efficacité en éliminant une jointure / à lapproche de base Unique (un seul mariage de personnes remariés ensemble)

185 Réification :Cas Spécifiques Mari M# A1 …. Femme F# B1 …. Mariés Date … Mari M# A1 …. Femme F# B1 …. Mariés M# F# C1 ….

186 Réification : Hiérarchie Mari M# A1 …. Femme F# B1 …. Mariés Date … Mari M# A1 …. Femme-m F# M# Date B1 …. On na que les femmes mariées (changement du modèle conceptuel) On élimine une jointure et une redondance/ à lapproche générale

187 Réification : Les Veuves ? Mari M# A1 …. Femme F# B1 …. Mariés Date … Votre Proposition ici

188 Réification : Classe / Sous-classe Assurance Ass-maison Ass-voitureAss-maladie A# Montant A# Val-maison A# Bonus A# Complément Assurance Ass-maisonAss-voitureAss-maladie A# Montant Val-maison Bonus Complément Optional / OR Les tables sont comme les entités réifiées. Comment faire pour lIR ?

189 Réification : Classe / Sous-classe Client HommeFemme C# Nom Mandatory/ OR Nom_JF Client C# Nom Nom_JF Sinon votre proposition ici OK ?

190 Réification : Classe / Sous-classe Schéma MsAccess

191 Réification : Classe / Sous-classe Schéma MsAccess u Le schéma permet daisément formuler les requêtes: u Toute donnée de personne P1 dans Pers et, sil y a lieu, ses données En tant quun employé En tant quun étudiant u MsAccess génère alors les jointures implicites externes u Cours SQL

192 Réification : Autres Cas u Le « jeu de clés » en général facile à voir de diagrammes UML u Agrégation u Composition u Associations 1-ères u Sauf celle dite Ancêtre u Calcul de la fermeture transitive u Peu performant dans les BDs Relationnelles

193 Réification : Cardinalités u 1 * ou 1 1 présent avant ou après la réification, se réifie en contrainte dintégrité référentielle clé primaire – clé étrangère u 0 * ou 0 1 se réifie en un lien sémantique u Autre cardinalités, p.ex. 1 6 nécessitent en général des déclencheurs u Pas une sinécure pour Mme/M Tout le Monde

194 Réification : Autres Cas u Lexemple dune Personne avec les Amies, Hobbies…? u Attributs dérivées ? u Il faut les mettre dans les vues Select Sum (Prix) as PrixTotal from Client Group By Client#

195 Après la Réification u Le résultat peut être OK u Exercice : Modèle relationnel de lauto- école u Mais il peut être pas bon du tout pour une BD relationnelle u A cause danomalies et de redondances u Doù la phase de normalisation u Peut-être appliquée à partir de la relation universelle directement u Par lanalyse des DFs et des DMs

196 Spécifications fonctionnelles: u Une entreprise a des fournisseurs S u Un fournisseur f a un ID, un nom, un statut, et est dans une ville u Un f fournit des fournitures SP de pièces P u Chaque fourniture fp comporte une certaine quantité d'une pièce p u Chaque p a un ID, un nom, un poids, une couleur u Une pièce p peut être l'objet de plusieurs fournitures fp Exemple canon

197 Exemple canon S S# Sname Status City P P# Pname Color Weight City SP Qty * *

198 Exemple canon S S# Sname Status City P P# Pname Color Weight City SP P# S# Qty 1 * * 1 Association triviale

199 Exemple canon S P SP

200 Pourquoi S-P est comme ça ? u Avantages : u Pas de duplicata de valeurs d'attributs entre les tables S, SP, et P u sauf le strict minimum (les clés) u Pas danomalies. u On verra cette notion dans le cours suivant. u Efficacité de stockage. u Pas dattribut-clé unique pour SP u Compare à la conception en une seule relation u Problèmes : u Comment trouver le Nom du fournisseur de pièces rouges ? u etc..

201 Solution u Opération relationnelle de jointure entre les relations u en SQL : SELECT SNAME FROM S, SP, P WHERE S.S# = SP.S# AND SP.P# = P.P# AND COLOR = 'RED' ;

202 Exemple Projet BD Assurance 07

203 UML -> XML 123 Jean Dupont Ski, Tennis, Voile Jean, Paul Sinbade, Café Court, Gargote Personne P# Nom Prénom Nom de famille Hobbies Amis Restaurants Plusieurs SGBD relationnels offrent les interfaces XML Type dentité UML Une entité XML (dite document)

204 Exercices (adaptez svp au programme de votre cours spécifique, voir aussi ceux des TDs) u Proposer les schémas relationnels pour les exemples en cours u Modéliser en UML et en relationnel un livre typique u Modéliser en UML et en relationnel laffectation de salles de cours à Dauphine. Justifiez le choix si plusieurs solutions sont possibles. Indiquez les clés primaires et candidates. u Modèle 1: Une réservation se définit par le n° de la salle, le nom du cours, la date, lheure début et lheure fin. (i) Un cours nest quune fois par jour dans la même salle. (ii) Alternativement, une répétition est possible. u Modèle 2 : On ajoute le type de la salle, si cest: lamphi, une salle équipée vidéo ou une salle TP u Modèle 3 : On ajoute le nom du prof enseignant le cours (i) Un enseignant par cours. (ii) Plusieurs.

205 Exercices u Modéliser une bibliothèque possédant un ou plusieurs exemplaires dun livre sur des rayons, en prêt ou en retour dun prêt mais pas encore sur les rayons. u Proposez une modélisation usuelle en UML dune personne ayant un ID, un nom, une mère et un père. Proposez ensuite un schéma relationnel. u Ce schéma satisfait-t-il: u Un DBA soucieux de lespace de stockage de la base. Sinon, que lui conseillez-vous ? u Un DBA voulant minimisant le temps de requêtes donnant pour certains chefs identifiés par leurs IDs, les IDs de tous leurs employés u Modéliser un certificat de naissance dun bébé en sachant que les parents peuvent ou pas être mariés u Modéliser les assurances proposées par une compagnie pour une personne : voiture, maison, resp. civile… u Voir les livres en BDs pour 1 millier dautres exercices du type : u Spécifs fonctionnelles -> UML -> réif. -> Schéma Rel.

206 Exercices u On crée le modèle pour la base des enfants. Pour chaque enfant on a le père et la mère. Proposez le modèle UML. Lenfant doit être modélisé comme une entité ou une association ? u On constitue une base de produits. Chaque produit a un ID et nom, une photo et appartient à plusieurs catégories de produits identifiées par leur noms. Plusieurs produits peuvent appartenir à une même catégorie. La photo comporte plusieurs produits agencés dune manière typique pour leur application. Plusieurs produits partagent une même photo. u Proposez la modélisation typique UML, puis la réification, enfin le schéma relationnel. u Le DBA sait en plus quil a en moyenne 100 produits par catégorie et autant par photo. Il y a 100 catégories et photos en tout. Le nom dune catégorie est un champ fixe de 50 octets. Une photo nécessite 1 MOctets. u Le DBA sait quil y a produits. Il souhaiterait minimiser lencombrement de la base. Est-ce que la modélisation typique minimise le satisfait ? u Sinon, proposez en UML et en relationnel une autre qui serait plus optimale. Evaluez le gain. u Un autre DBA a comme préoccupation principale de minimiser le temps dune requête demandant des noms de produits avec leurs catégories et les photos. Il veut minimiser le nombre de jointures. Quelle modélisation lui conseillez vous?

207 FIN Merci de votre attention W. Litwin

208