La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

1 Modèle Relationnel 2013 - 14 Witold Litwin 2 2 Le Rapport de Recherche qui a lancé les SGBDs Relationnels (publié uniquement en interne à IBM Almaden.

Présentations similaires


Présentation au sujet: "1 Modèle Relationnel 2013 - 14 Witold Litwin 2 2 Le Rapport de Recherche qui a lancé les SGBDs Relationnels (publié uniquement en interne à IBM Almaden."— Transcription de la présentation:

1

2 1 Modèle Relationnel Witold Litwin

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

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

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

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

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

8 7 Base de données relationnelle u Une collection d'objets : u Relations réelles (tables de base) u Liens réferentiels 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

9 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é

10 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

11 10 P

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

13 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';

14 13 P

15 14 P P1 P2

16 15 Base relationnelle Tables réelles

17 16 Base relationnelle Tables réelles et vues

18 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 ou n-uplets u Il ny a pas de tuples égaux dans une relation

19 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

20 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

21 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 !

22 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

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

24 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

25 24 Une même relation S

26 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

27 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 ?

28 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

29 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…

30 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

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

32 31 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

33 32 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 = ?

34 33 CS SC CS JOIN SC S S [STATUS, CITY] S [S#, CITY]

35 34 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

36 35 -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.

37 36 - 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 ?

38 37 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 ?

39 38 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

40 39 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

41 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#]))

42 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' )) [ SNAME] u ((S TIMES SP ) WHERE P# = 'P2' ) WHERE STATUS > 100 ) [ SNAME]

43 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

44 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

45 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

46 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# ;

47 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# ;

48 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

49 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

50 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

51 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 !

52 51 P1 P2 P3 P4 IBM HP P1 P2 P3 IBM IBN IMB HP S1 S2 Norm. O NF1 NF Toute valeur de S# et toute 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#

53 52 P1 P2 S1 S2 P4 P5 P6 P7 P1 P2 P4 … S1 S2 … Norm. O NF1 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#

54 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 pour une relation en 1-NF ! u Un tuple pour toute combinaison dun tél, un hobby, un dipl…. u sous peine de perte dinfo u Inacceptable en général

55 54 Solutions pour la Conception u Empirisme et Expérience u UML u Théorie Mathématique u Normalisation en i-NF ; i > 1 et BCNF u Surtout BCNF et 4-NF u Comme on verra + loin u Détails dans le cours « Normalisation relationnelle »

56 55 Et la Manipulation ? u Le problème reste ouvert dans le relationnel de base u SELECT E#, Tel, Hobby, Dipl, Enfants, Voit FROM R1, R2…Rn WHERE… u Produit une relation virtuelle en 1-NF u Fera revenir les 270 tuples discutés u Une sortie: la Fonction LIST u SQL Anywhere & votre prof. u Le cours sur SQL avancé

57 56 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

58 57 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

59 58 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

60 59 u Il ne faut pas confondre le concept de la clé avec celui dun attribut-clé u Ce dernier nest 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

61 60 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

62 61 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

63 62 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

64 63 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

65 64 u L'égalité C = F constitue le lien référentiel 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

66 65 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

67 66 u Les SGBD majeurs gèrent désormais des contraintes IR ainsi que les liens réferentiels 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

68 67 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 ?

69 68 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

70 69 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

71 70 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

72 71 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

73 72 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

74 73 u Ce type de nul peut indiquer alors lexistence dune sous-classe u Personnes sans portable u Personnes à Dauphine qui sont des étudiants, ayant alors aussi lID E# etc. u Personnes à Dauphine qui sont des salariés ayant alors aussi lID S# etc. u On reverra ce problème + tard Types de nuls

75 74 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

76 75 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 nuls Les nuls en perspective

77 76 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 les cours sur SQL Les nuls en perspective

78 77 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 a 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

79 78 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

80 79 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

81 80 Modélisation relationnelle BDR

82 81 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 Un résultat optimal garanti

83 82 Modélisation relationnelle 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

84 83 Modélisation relationnelle formelle u Deux phases 1. Modélisation conceptuelle par spécifications fonctionnelles +- Informelles Une pièce à un nom, une couleur… 2. Conceptuel –> Relationnel 1. Normalisé a partir de la relation universelle 2. Sans sous-classes cachées u Détails + tard

85 84 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 arcs sont les liens référentiels Modélisation Relationnelle Graphe de références

86 85 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

87 86 u Graphe des références à nombre minimal de nœuds u Sous contraintes : u Préservation de dépendances fonctionnelles (DFs) 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

88 87 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

89 88 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

90 89 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

91 90 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

92 91 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

93 92 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

94 93 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

95 94 u Ex. 5 Revoir le diapo 52. Soit SPL (S#, P#, L#) la table en 1NF sur ce diapo. u Avec sa clé. u SPL présente une anomalie dinsertion. u P.ex. linsertion de la localisation L7 pour S2 implique la création de 4 tuples u Problème dit de BCNF u Solution intuitive et sa motivation ? Modélisation relationnelle : Anomalies

96 95 u Ex. 5 Revoir la table Etud du diapo 53. Etud (E#, Tel, Hobby, Dipl, Enfants, Voit) u Daccord / pas daccord avec la clé choisie ? u Etud présente une anomalie dinsertion insupportable en pratique. u Problème de BCNF aussi u Dans toute sa splendeur cette fois-ci u Votre solution intuitive ? u Sa motivation ? Modélisation relationnelle : Anomalies

97 96 u Ex. 6 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

98 97 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

99 98 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

100 99 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

101 100 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

102 101 u Assure la condition suffisante aussi u En général, mais pas toujours u 5 NF nest pas considérée u Apps particulières peuvent conduire à des adaptations spécifiques u Détails dans les exercices et exemples à la fin du cours et surtout dans : ur%20la%20conc-norm fonte-reduite.pdf Modélisation relationnelle : Démarche formelle

103 102 u On traduit les spécifications fonctionnelles en une seule relation u Dite relation universelle u Souvent notée U u Un fourre-tout u Sans nuls u Selon le relationnel classique Modélisation relationnelle : Démarche formelle

104 103 u Si U est sans anomalie et en 4NF on a fini u Cas très rare u Pour rappel U est en 4NF ssi pas de DM et en BCNF u U est en BCNF ssi il ny pas de déterminant fonctionnel qui ne serait pas une clé de U Modélisation relationnelle : Démarche formelle

105 104 u Sinon on procède en deux étapes u Dabord pour U u Puis pour toute table résultant la démarche 1. Elimination dune anomalie due à une DM éventuelle u Par Th. de Fagin ou dautres et règles dinférence de DMs Modélisation relationnelle : Démarche formelle

106 Quand une table na plus de DM, alors on élimine une DF éventuelle qui feraient que la table ne soit pas en BCNF u Par Th. de Heath u Maintenant + de détails Modélisation relationnelle : Démarche formelle

107 106 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 u La recomposition passe donc par la jointure naturelle Modélisation relationnelle : Démarche formelle

108 107 u On continue récursivement pour toute table résultante u Jusquaux tables sans DMs u Nécessairement Modélisation relationnelle : Démarche formelle

109 108 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 Modélisation relationnelle : Démarche formelle

110 109 u On applique récursivement le Th. de Heath u A chaque fois on remplace une table sans pertes de données par deux projections u En liquidant une DF maximale u Avec le max dattributs cibles sur un déterminant u Qui devient une clé dune de tables produites par la projection u Pour le schéma avec le minimum de tables Modélisation relationnelle : Démarche formelle

111 110 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 Modélisation relationnelle : Démarche formelle

112 111 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 u Contrairement aux relationnel classiques u Donc a la Théorie des NFs Modélisation relationnelle : Démarche formelle

113 112 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 Modélisation relationnelle : Démarche formelle

114 113 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 Modélisation relationnelle : Démarche formelle

115 114 u On peut néanmoins décomposer sans perte R alors en utilisant les jointures externes u Théorème de votre prof. u Suivant les travaux dautres, S. Jajodia & al notamment dans les années 90 u Détails dans les exercices Modélisation relationnelle : Démarche formelle

116 115 u Ensuite, on crée récursivement entre les relations obtenues u Les liens référentiels 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

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

118 117 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

119 118 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

120 119 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

121 120 u Type de jointure implicite pour le lien référntiel ou la contrainte dintégrité réf. (MsAccess, DB2…) u Interne (défaut) u Produit seulement les tuples de deux tables ou les valeurs jointes sont égales Modélisation relationnelle : Toute Démarche

122 121 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

123 122 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

124 123 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

125 124 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

126 125 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

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

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

129 128 Résultat pour une requête QBE SQL

130 129 Exemple canon S P SP

131 130 u Cas particulier u Tout employé E# a un et un seul poste tél et nom u Les postes (et les noms bien sûr) peuvent être partagés u Mais, 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 la table : Empl (E#, PosteTel, Nom) Modélisation relationnelle : Démarche générale

132 131 u On a une anomalie dinsertion u Laquelle ? u On ajoute la table Postes (PosteTel) u Avec une contrainte dintégrité u Laquelle ? u En fait cette table simule le domaine de PosteTel Modélisation relationnelle : Démarche générale

133 132 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

134 133 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 en DM avec P# ? u Il sont pourtant dans la même table Modélisation relationnelle : Démarche générale

135 134 u Il sagit dune 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

136 135 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

137 136 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

138 137 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 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

139 138 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

140 139 u En pratique u On sécarte de la démarche générale pour pas mal de raisons hors de 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

141 140 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

142 141 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

143 142 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...

144 143 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

145 144 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

146 145 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

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

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

149 148 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

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

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

152 151 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

153 152 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

154 153 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 ?

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

156 155 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

157 156 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

158 157 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 *

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

160 159 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

161 160 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

162 161 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é

163 162 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

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

165 164 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

166 165 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

167 166 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

168 167 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

169 168 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 ….

170 169 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

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

172 171 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

173 172 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

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

175 174 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 *

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

177 176 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 ?

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

179 178 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 ….

180 179 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

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

182 181 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 ?

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

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

185 184 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

186 185 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

187 186 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

188 187 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#

189 188 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

190 189 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

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

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

193 192 Exemple canon S P SP

194 193 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..

195 194 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' ;

196 195 Exemple Projet BD Assurance 07

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

198 197 Exercices (adaptez svp au programme de votre cours spécifique, voir aussi ceux des TDs) u La démarche formelle u Donc la conception optimale par des décompositions sans perte : u ample%20pour%20la%20conc-norm fonte-reduite.pdf ample%20pour%20la%20conc-norm fonte-reduite.pdf

199 198 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.

200 199 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.

201 200 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?

202 201 FIN Merci de votre attention W. Litwin

203 202


Télécharger ppt "1 Modèle Relationnel 2013 - 14 Witold Litwin 2 2 Le Rapport de Recherche qui a lancé les SGBDs Relationnels (publié uniquement en interne à IBM Almaden."

Présentations similaires


Annonces Google