Modèle Relationnel & UML 09 - 10 Witold Litwin

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

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

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

Base de données relationnelle Fichier = table ou relation Donnée = ligne ou attribut atomique Opérations = transformations de tables en une table Opération relationnelle

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

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

Schéma de BD Entreprise clé 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#) ; Autres Déclencheurs utiles ? Ce schéma est possible sous MsAccess, bien que exprimé différemment

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

P

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

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

P

P P1 P2

Base relationnelle Tables réelles

Base relationnelle Tables réelles et vues

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

Relations Dans une BD relationnelle, on n’a que des relations finies En nombre d’attributs et en nombre de tuples Toute valeur d’un d  Di est atomique Pas un ensemble De telles relations sont dites normales Aussi en 1 NF au moins

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

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

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

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

Une même relation S

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

SQL : MAJ / Restructuration ? 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 ;

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

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

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

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

Jointure naturelle 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 pas d’autres tuples X, Y, Z peuvent être composés Est-ce que la jointure naturelle est commutative et/ou associative ? A JOIN B =? B JOIN A A JOIN B JOIN C = ? A JOIN (B JOIN C)

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

Fournisseur avec les fournitures SName Status City s1 smith 20 London s2 Jones 10 Paris s3 Blake 30 s4 Clark london s5 Adams Athens S Fournisseur avec les fournitures S JOIN SP S# SName Status City P# qty s1 smith 20 London p2 200 p3 400 p4 p5 100 p6 p1 300 s2 Jones 10 Paris s3 Blake 30 s4 Clark london SP s# P# qty s1 p1 300 p2 200 p3 400 p4 p5 100 p6 s2 s3 s4

-jointure Table C égale à : C = ( A TIMES B ) WHERE X Y est la jointure de tables A(X,...) et B (Y,...). X et Y ne sont pas ici composites et   , <>, ,  ,  La jointure est notée : C = A JOIN B ON X  Y.

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

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

Requêtes algébriques à la base S-P (( S JOIN SP ) WHERE P# = 'P2' ) [ SNAME] (( S JOIN SP ) WHERE P# = 'P2' ) WHERE STATUS > 100 ) [ SNAME] (((P WHERE COLOR <> 'Red' ) [P#] JOIN SP ) [S#] JOIN S [SNAME] (((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#])

Utilité de l'algèbre Puissance expressive: 8 opérateurs de Codd permettent d'exprimer toute expression logique de prédicat de 1-er ordre note: seulement 5 sont primitives (lesquels ?) 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

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 l’algèbre

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

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

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

Relations Une relation réelle est définie à partir de ses attributs 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 En général, une valeur d’un domaine et donc d’un attribut peut être un ensemble XML , Access 2007 Pour les opérations relationnelles dans les SGBD actuels, ils ne sont néanmoins en principe que des valeurs atomiques Toute décomposition fait perdre la sémantique de la valeur De telles relations sont dites normales

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

Normalization en 1-NF Contrainte très importante ! Etud (E#, Tel, Hobby, Dipl, Enfants, Voit) Etudiant Dupont: 3 tel, 5 hobbies, 3 diplômes, 3 enfants, 2 voitures Un tuple d’ue relation en 0-NF suffit Il faut 3*5*3*3*2 = 270 tuples pour une relation en 1-NF ! Un tuple pour toute combinaison d’un tél, un hobby, un dipl…. sous peine de perte d’info Inacceptable en général

Solutions pour la Conception Empirisme et Expérience UML Théorie Mathématique Normalisation en i-NF ; i > 1 et BCNF Surtout BCNF et 4-NF Cours sur la normalisation relationnelle

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

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

Clés Le choix de C est dicté par l'intention de R Soit R = Pers (Nom, Prénom, SS#, Tel) Dans une famille Pers (Nom, Prénom, SS#, Tel) /* Tout membre A la SS Pers (Nom, Prénom, SS#, Tel) /* Assuré seuelement A l'état civil Pers (Nom, Prénom, SS#, Tel) /* Toute personne 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 C atomique consiste d’un attribut C composite en contient plusieurs Tout attribut d’une clé est dit attribut-clé Tout autre attribut est un attribut non-clé C’est une fonction de toute clé de la table Cette propriété est la base d’une définition du concept de la clé

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

Relations Si C est clé de R, alors tout ensemble d’attributs 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 R peut avoir plusieurs clés. Dans ce cas: Une clé est arbitrairement choisie est dite primaire Les autres deviennent clés candidates R peut avoir plusieurs clés de cardinalités différentes. La clé avec le plus petit nombre d’attributs est dite alors minimale A choisir de préférence

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

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

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

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

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

Intégrité Référentielle 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#) De tels liens génèrent les récurrences exigeant le calcul de fermetures transitives Les opérations relationnelles ne permettent pas de calculer les fermetures transitives Les SGBD en général ne gèrent pas de tels liens sémantiques

Valeurs nulles Une valeur nulle est un abus de langage pour designer une absence de valeur d’un attribut On dit aussi un nul

Types de nuls Valeur inconnue Valeur inapplicable Ville de fournisseur inconnue Valeur inapplicable Fournisseur connu pour être sans statut Cette distinction est rarement appliquée en pratique

Types de nuls Comment faire alors s’il le faut ? Pour l’attribut #TEL faut distinguer entre: # tel portable inconnu on relancera la personne pour connaître son numéro Personne sans téléphone portable L’utilisation d’un nul pour un attribut peut être interdite

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

Les nuls en perspective On peut interdire en pratique la présence d’un nul pour un attribut Dans la définition de l’extension de la relation La théorie initiale du modèle relationnel ne prévoyait pas de nuls Leur introduction (par les praticiens) a crée de nombreux problèmes beaucoup restent non-résolus voir les cours sur SQL

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

Modélisation relationnelle Souvent fort simple L’attrait de bases relationnelles Exemples typiques commentés en cours Fournisseurs et Pièces (Supplier Part DB) Conseillers en assurances et Produits d’Assurances Etudiants et Cours

Modélisation relationnelle BDR

Modélisation relationnelle On procède le plus souvent en trois étapes Modélisation conceptuelle Pas spécifique au relationnel Ni aux BDs même Conceptuel – Relationnel Transformation du modèle conceptuel en CS et ESs d’une BD Normalisation Amélioration du CS Spécifique au relationnel plat

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

Modélisation relationnelle : Conception d’une BD relationnelle Il faut minimiser le nombre de nœuds du graphe de références Sous contraintes : D’absence d’anomalies D’insertion, suppression, MAJ De minimisation de redondance globale de données Par rapport à 0NF surtout Les deux contraintes sont en fait duales

Modélisation relationnelle : Conception d’une BD relationnelle Il faut minimiser le nombre de nœuds du graphe de références Sous contraintes : Préservation de dépendances fonctionnelles (FDs) Pas ou peu de valeurs nulles Cette contrainte peut contredire celle sur les anomalies & redondances Il faut alors exercer son bon sens

Modélisation relationnelle : Conception d’une BD relationnelle Anomalie d’insertion On ne peut pas insérer de valeurs qu’il faudrait Soit la table S’ = (S#, Sname, Status, City, P#, Qty) Fournisseur S1 ne fournit encore aucune pièce On ne peut pas insérer ses données: Fournisseur S1 est Smith, a le statut 20 et est à Londres

Modélisation relationnelle : Conception d’une BD relationnelle Anomalie d’insertion Il faut insérer une même donnée plus de fois que nécessaire En idéal : une donnée n’est insérée qu’une fois dans la base Revoir notre exemple illustrant 1NF La conception en une table présente l’anomalie

Modélisation relationnelle : Conception d’une BD relationnelle Dans S’, si S1 fournit 5 pièces, alors on insère Sname, City, Status 5 fois Soit la conception en deux tables S = (S#, Sname, City, Statuts) SP (S#, P#, Qty) On n’insère ces valeurs qu’une fois

Modélisation relationnelle : Conception d’une BD relationnelle La conception est libre de deux aspects discutés de l’anomalie On peut insérer les données sur S1 même s’il ne fournit rien actuellement En supposant qu’en général un fournisseur fournit plusieurs pièces, on diminue la redondance globale Bien que l’on l’augmente nécessairement localement pour S#

Modélisation relationnelle : Conception d’une BD relationnelle Enfin, supposons que l’on conçoit au lieu de S trois tables S1 (S#, Sname), S2 (S#, City), S3 (S#, Status) On insère S1 deux fois de trop, par rapport à S Trop de tables conduit à l’anomalie aussi

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

Modélisation relationnelle : Conception d’une BD relationnelle Anomalie de suppression On supprime les valeurs qu’il ne faudrait pas Dans S’, si S1 fournit 5 pièces Si l’on supprime 4 fournitures, les données de S1 restent dans la base Si l’on supprime la dernière fourniture, on les perd Pas si l’on a la conception en S et SP

Modélisation relationnelle : Résultat générale Plusieurs relations Chaque relation consistant d’une clé de max d’attributs identifiés chacun comme fonctions de la clé On respecte aisément la condition nécessaire Pas celle suffisante

Modélisation relationnelle : Démarche générale On commence par modélisation d’un ensemble d’objets réels par une relation dite souvent universelle, soit R1 Les personnes Les fournisseurs Les produits On dit que toute BD modélise une entreprise (ANSI – SPARC)

Modélisation relationnelle : Démarche générale On cherche surtout des OIDs et, plus généralement, des déterminants Attributs (peut-être composés) sur lesquels d’autres attributs sont fonctionnellement dépendants Autrement dit, ces attributs sont une fonction du déterminant ou d’OID en particulier

Modélisation relationnelle : Démarche générale On trouve, ou on crée, un OID d’un objet P# identifiant une personne On trouve un ou des attribut(s), dits aussi attribut composé, que OID détermine Pers (P#, Nom, Pnom, DNaiss,…) Statut d’un fournisseur Poids, couleur d’une pièce commandée dans P

Modélisation relationnelle : Démarche générale On crée une nouvelle relation, soit R2, chaque fois que l’on rencontre: Un attribut (composé) à une liste de valeurs Les #Tel d’une personne, ses émails, diplômes… On répète dans R2 le OID ou le ou un déterminant de R1

Modélisation relationnelle : Démarche générale Dans notre exemple, on aurait PT (P#, Tél) PE (P#, Email) PD ((P#, Dipl) Il y aurait un tuple par élément de liste La décomposition sans perte d’info en 4NF par le Théorème Heath -Fagin

Modélisation relationnelle : Démarche générale On crée une nouvelle relation, soit R2, chaque fois que l’on rencontre: Un attribut (composé) D qui n’est pas une clé candidate, mais DF un autre Code postale (CP) -> Ville En supposant une seule ville par CP Indice -> Salaire de base On répète D dans R2

Modélisation relationnelle : Démarche générale Dans notre exemple, on aurait R1 = Pers (P#, Nom, Pnom, DNaiss, CP,…) R2 = CV (CP, Ville) Le tout est la décomposition sans perte d’info Par Théorème de Heath Dite en BCNF, 3NF… Voir mon cours sur la normalisation

Modélisation relationnelle : Démarche générale On crée une nouvelle relation, soit R2, chaque fois que l’on rencontre: Un attribut (composé) qui aurait crée souvent une valeur (composée) nulle Nom de jeune fille Personnes à Dauphine : Etudiants avec leur Form. NoteG… Employées avec #Emp, Sal… Visiteurs

Modélisation relationnelle : Démarche générale On répète dans R2 le déterminant de R1 Pers (P#, Nom, Sex, Célib… ) et PJf (P#, NJf) C’est l’extraction de sous-classes Méthodologie hors la normalisation relationnelle (FNs) Autres exemples plus loin

Modélisation relationnelle : Démarche générale On crée pour R2 sa clé selon le cas Union des déterminants de R1 et de R2 P#, Tel ; P#, Email ; Comme dans notre exemple Mais, il peut y avoir plusieurs choix Quand on a plusieurs clés et déterminants

Modélisation relationnelle : Démarche générale Le déterminant de la DF CP ; Indice… Comme dans notre exemple Notre démarche réalise en fait la décomposition en projections indépendantes Meilleure que celle dite en projections dépendantes Perdant les DFs

Modélisation relationnelle : Démarche générale Le déterminant de R1 ou, peut-être, de R2 Pour les personnes qui sont les étudiants R2 = Et (P#, Form, NoteGlob…) Ou, peut-être, on crée E# attribué aux étudiants seulement R2 = Et (P#, E#, Form, NoteGlob…) On continue le processus de décomposition pour R1 et R2 etc.

Modélisation relationnelle : Démarche générale On crée récursivement entre les relations obtenues Les liens sémantiques Les contraintes d’intégrité référentielle Le tout selon l’application Entre les déterminants Entre les clés et les clés étrangères

Modélisation relationnelle : Démarche générale Jointure implicite pour le lien sémantique MsAccess d’abord, suivi par quelques autres SGBDs Une jointure ajoutée automatiquement à la requête en mode QBE On ne spécifie que les attributs et agrégats Requêtes + simples - procédurales, + assertionnelles…

Modélisation relationnelle : Démarche générale Jointures implicite ont été proposées dans les 80 Par votre prof. et son Thésard A. Abdellatif (INRIA) Développées avec Prof. G. Wiederhold & son Thésard B. Lee (Stanford) Papiers sur la page Web de votre prof (CERIA)

Modélisation relationnelle : Démarche générale Type de jointure implicite pour le lien sémantique (MsAccess) Interne (défaut) Produit seulement les tuples de deux tables ou les valeurs jointes sont égale Signification des attributs en conséquence Attr. Nom dans Pers est le nom d’étudiant pour le lien Pers <-> Et C’est le nom d’employé pour P <-> Emp

Modélisation relationnelle : Démarche générale Type de jointure implicite pour le lien sémantique (MsAccess) Externe Préserve toutes les tuples d’une de deux tables, au choix Signification des attributs en conséquence Si l’on préserve P, alors Nom est le nom d’une personne pour tout lien P <-> Et, P <-> Emp, P <-> Vst,…

Modélisation relationnelle : Démarche générale Expérience d’application Les exercices Voir ceux du cours La pratique Voir la vie autour Dauphine, Votre entreprise, Facebook, Ecole de Conduite, vos CDs…

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

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

Jointure Implicite (S – SP) Choix de jointure interne

Résultat pour une requête QBE SQL

Exemple canon SP S P

Modélisation relationnelle : Démarche générale Cas spéciaux Pers (P#, Nom, Pnom, DNaiss, CP,…) CV (CP, Ville) Que faire si l’on sait que P1 est à Paris, mais l’on ne connaît pas CP ? Pas de problème par contre avec la conception dénormalisée Pers (P#, Nom, Pnom, DNaiss, CP, Ville)

Modélisation relationnelle : Démarche générale Cas spéciaux Pers (P#, Nom, Pnom, Sex, Célib,…) PJf (P#, NJf) Si les Jeunes Filles sont rares, la conception dénormalisée peut présenter – d’anomalies et redondance (sur P#) en moyenne Pers (P#, Nom, Pnom, Sex, Célib, NJf…) Etant donc globalement + avantageuse

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

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

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

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

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

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

UML Objet = Entité (Entity) ou Occurrence d’entité Entité faible Identifiable seulement dans une autre entité (forte) Type d’objets = Type ou classe Propriété = Association (Relationship)

UML : Type d’Entité Nom Attributs clé et non-clé Opérations

UML : Type d’Entité 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 d’attributs 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

UML : Type d’Entité Valide pour XML Pas pour le relationnel Personne <PK> P# Nom Prénom Nom de famille Hobbies 0..10 Amis 0..10 Restaurants 0..10 Valide pour XML Pas pour le relationnel Il faut mettre tout composite ou multivalué en type d’entité séparé (en principe)

UML : Type d’Entité Nom Personne 1 1..* <PK> Prénom <PK> Nom de famille <PK> P# 1..* 1..* 1..* Amies 0..10 <PK> Ami 0..10 0..10 Restaurants Hobbies <PK> Restaurant <PK> Hobby

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

UML Associations Modèle d’une auto-école Abréviation de 0..* Nom de l’association Diagramme de note en UML L’école peut envoyer entre 0 et 8 étudiants à un exam Exactement 6 séries / CD Modèle d’une auto-école basé sur l’ex. de M. Manouvrier Appartient à Rôle de l’associon (directionnelle)

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

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

UML Concept de composition Les entités composantes n’ont pas d’existence propre Ex. Les salles d’un bâtiment La suppression de la composition supprime aussi les composantes Contrainte d’intégrité référentielle Symbolisée par losange noir Les entités composées peuvent être agrégées par ailleurs Losange transparent Conf Batiment 1..7 1 0..* 1..4 Salle Les cardinalités x..y sont des exemples

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

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

UML / Relationnel Mais une très mauvaise conception Personne <PK> P# <PK> Hobby <PK> Ami <PK> Restaurant Prénom Nom de famille Un tuple identifie une personne avec un de ses hobbies, un de ses amis et un de ses restaurants. Pour chaque combinaison de ces valeurs il y un tuple. Outre le nombre prohibitif de tuples (1000 dans notre cas) il y a la redondance de Prénom et Nom (999 fois de trop). Acceptable pour le relationnel Mais une très mauvaise conception

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

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

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

Réification (Etape 1) Outil Fondamental de passage UML – Relationnel : On réifie : Toute classe d’associations en une classe d’entités Toute classe d’entités deviendra plus tard une table relationnelle

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

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

Réification Le concept de réification est rarement explicité La réification est en général manuelle A l’heure actuelle C’est la principale limitation de l’emploi d’une BD relationnelle par un usager Tout-le-Monde

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

Réification : Principe Général B <PK> A# <PK> B# C1 …. <PK> A# A1 …. <PK> B# B1 …. A C B <PK> A# <PK> B# C1 …. <PK> A# A1 …. <PK> B# B1 …. A l’origine, il n’y 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

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

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

Réification : Association n-aire 1 1..4 Soin 100 P 1 S 1..5 1 M Soin 1 <PK> S# <PK> P# <PK> M# 1..4 100 P 1 S 1..5 1 M

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

Réification : Attribut composé Personne Hobbies P_H Personne <PK> H# Hobby <PK> P# <PK> H# <PK> P# Prénom Nom de famille Hobbies Amis Restaurants Nom Tel <PK> P# Prénom Nom de famille Amis <PK> P# <PK> Ami 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) Restaurant <PK> P# Nom <PK> Tel Approche utile pour un entrepôt de données

Réification : Entité Faible Conseiller Conseiller <PK> C# <PK> C# Cl# 1 1 0..1 * Client Client Cl# Nom <PK> Cl# <PK> C# Nom Cl# n’est pas la clé

Réification : Entité Faible Conseiller Conseiller C# C# Cl# 1 1 0..1 * Client Client Cl# Nom <PK> ? …. Nom La clé de Client si Conseiller est une entité faible aussi ? Cl# n’est pas la clé

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

Réification : Cas Spécifiques Bijection Client Voiture 1 1 <PK> C# A1 …. <PK> V# B1 …. Accident Date …. On mémorise tous les accidents d’un client avec sa voiture Peut-on en général réifier comme auparavant ? Sinon pourquoi pas ? Ici un même couple client voiture peut avoir plusieurs accidents à des dates différentes. Donc la date devient l’attribut clé ou l’attribut multivalué.

Réification : Cas Spécifiques Injection Mari Femme 0..1 1 <PK> M# A1 …. <PK> F# B1 …. Mariés Date …. Unique (un seul mariage de personnes remariés ensemble) Femme Mariée ou pas On gagne en souvent en efficacité en éliminant une jointure / à l’approche de base <PK> F# M# Date A1 …. B1 ….. Changement du modèle conceptuel Nul ne peut pas pas être un att. clé

Réification :Cas Spécifiques Mari Femme 0..1 0..1 <PK> M# A1 …. <PK> F# B1 …. Mariés Date …. Mariés Mari Femme <PK> M# <PK> F# C1 …. <PK> M# A1 …. Nul ne peut pas pas être un att. clé <PK> F# B1 ….

Réification : Hiérarchie Mari Femme 1 0..4 <PK> M# A1 …. <PK> F# B1 …. Mariés On n’a que les femmes mariées (changement du modèle conceptuel) Date …. Mari Femme-m <PK> M# A1 …. <PK> F# M# Date B1 …. On élimine une jointure et une redondance/ à l’approche générale

Réification : Les Veuves ? Mari Femme 0..1 0..4 <PK> M# A1 …. <PK> F# B1 …. Mariés Date …. Votre Proposition ici

Réification : Classe / Sous-classe Assurance Assurance <PK> A# Montant <PK> A# Montant 1 1 1 Optional / OR 0..1 0..1 0..1 Ass-maison Ass-voiture Ass-maladie Ass-maison Ass-voiture Ass-maladie Val-maison IR veut dire Integrité Référentielle. Il faut s’assurer qu’une même assurance A# n’est pas dans deux sous-classes. Déclencheur est nécessaire. Bonus Complément <PK> A# Val-maison <PK> A# Bonus <PK> A# Complément Les tables sont comme les entités réifiées. Comment faire pour l’IR ?

Réification : Classe / Sous-classe Client Client OK ? <PK> C# Nom <PK> C# Nom Nom_JF Mandatory/ OR Sinon votre proposition ici Homme Femme Réification en une, ou deux ou trois entités. A justifier les avantages et inconvénients. Notamment pour les opérations (présence de nuls, jointure, count de personnes…) Nom_JF

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

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

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

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

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

Après la Réification Le résultat peut être OK Exercice : Modèle relationnel de l’auto-école Mais il peut être pas bon du tout pour une BD relationnelle A cause d’anomalies et de redondances D’où la phase de normalisation Peut-être appliquée à partir de la relation universelle directement Par l’analyse des DFs et des DMs

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

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

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

Exemple canon SP S P

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

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

Exemple Projet BD Assurance 07

Une entité XML (dite document) Plusieurs SGBD relationnels offrent les interfaces XML UML -> XML <Personne> <P_Id> 123 </ P_Id> <Nom> <Prenom> Jean </Prenom> <Nom de famille> Dupont </Nom de famille> </Nom> <Hobbies> Ski, Tennis, Voile </Hobbies> <Amis> Jean, Paul</Amis> <Restaurants> Sinbade, Café Court, Gargote </Restaurants> </Personne> Personne <PK> P# Nom Prénom Nom de famille Hobbies 0..10 Amis 0..10 Restaurants 0..10 Type d’entité UML Une entité XML (dite document)

Exercices Proposer les schémas relationnels pour les exemples en cours Modéliser en UML et en relationnel un livre typique Modéliser en UML et en relationnel l’affectation de salles de cours à Dauphine. Justifiez le choix si plusieurs solutions sont possibles. Indiquez les clés primaires et candidates. Modèle 1: Une réservation se définit par le n° de la salle, le nom du cours, la date, l’heure début et l’heure fin. Un cours n’est qu’une fois par jour dans la même salle. Alternativement, une répétition est possible. Modèle 2 : On ajoute le type de la salle, si c’est: l’amphi, une salle équipée vidéo ou une salle TP Modèle 3 : On ajoute le nom du prof enseignant le cours (i) Un enseignant par cours. (ii) Plusieurs.

Exercices Modéliser une bibliothèque possédant un ou plusieurs exemplaires d’un livre sur des rayons, en prêt ou en retour d’un prêt mais pas encore sur les rayons. Proposez une modélisation usuelle en UML d’une personne ayant un ID, un nom, une mère et un père. Proposez ensuite un schéma relationnel. Ce schéma satisfait-t-il: Un DBA soucieux de l’espace de stockage de la base. Sinon, que lui conseillez-vous ? 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 Modéliser un certificat de naissance d’un bébé en sachant que les parents peuvent ou pas être mariés Modéliser les assurances proposées par une compagnie pour une personne : voiture, maison, resp. civile… Voir les livres en BDs pour 1 millier d’autres exercices du type : Spécifs fonctionnelles -> UML -> réif. -> Schéma Rel.

Exercices 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. L’enfant doit être modélisé comme une entité ou une association ? 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 d’une manière typique pour leur application. Plusieurs produits partagent une même photo. Proposez la modélisation typique UML, puis la réification, enfin le schéma relationnel. Le DBA sait en plus qu’il a en moyenne 100 produits par catégorie et autant par photo. Il y a 100 catégories et photos en tout. Le nom d’une catégorie est un champ fixe de 50 octets. Une photo nécessite 1 MOctets. Le DBA sait qu’il y a 10 000 produits. Il souhaiterait minimiser l’encombrement de la base. Est-ce que la modélisation typique minimise le satisfait ? Sinon, proposez en UML et en relationnel une autre qui serait plus optimale. Evaluez le gain. Un autre DBA a comme préoccupation principale de minimiser le temps d’une 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?

Exercices suppl. Clic hors diaporama

Merci de votre attention W. Litwin FIN Merci de votre attention W. Litwin