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 de Données Witold Litwin 2 Base de données relationnelle Fichier =tableourelation Donnée =ligneouattributatomique Opérations = transformations.

Présentations similaires


Présentation au sujet: "1 Modèle Relationnel de Données Witold Litwin 2 Base de données relationnelle Fichier =tableourelation Donnée =ligneouattributatomique Opérations = transformations."— Transcription de la présentation:

1

2 1 Modèle Relationnel de Données Witold Litwin

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

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

5 4 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é

6 5 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

7 6 P

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

9 8 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';

10 9 P

11 10 P P1 P2

12 11 Base relationnelle Tables réelles

13 12 Base relationnelle Tables réelles et vues

14 13 Relations u D i ; i = 1,2..n des ensembles dits domaines u Une relation R est un sous-ensemble de produit cartésien: D i R D i,1 x D i,2... x... D i,k k n u Dans une BD relationnelle, on na que des relations finies u Les D i,j sont les attributs de R ; les rôles de domaines (Codd)

15 14 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

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

17 16 u Deux relations R et R' sont égales si elles diffèrent seulement par ordre : u d'attributs (colonnes) u de tuples (lignes) u Il n'y a pas de tuples égaux dans une relation Egalité de relations

18 17 Une même relation S

19 18 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

20 19 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 ; Alter Emp Drop Ville ; Create Table CP - V CodePost Int Ville Text Primary key (CodePost, Ville) ; u C'est une décomposition d'une relation SQL : MAJ / Restructuration ?

21 20 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 Opérations relationnelles

22 21 Opérations relationnelles u Sélection : u Projection u Restriction u Jointure u Division u Agrégation u Opération suppl. u Mise à jour u Création d une vue Voir aussi le cours sur lalgèbre relationnelle

23 22 Opérations relationnelles (SQL) Voit (Im#, Pref, Mod, Couleur) Amende (A#, I#, Nom, Addr, Payée) u Select * From Voit ; u Select Mod From Voit Where Couleur = 'rose' ; u Select Nom, Addr From Amende, Voit Where Payé Is Null and Mod = 'Ferrari' and I# = Im# ; 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# ;

24 23 u Une relation réelle est définie à partir 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

25 24 u En théorie, un domaine et donc un attribut peut être un ensemble u Dans les SGBD actuels, ils ne sont considérés pour les opérations relationnelles que comme des éléments (valeurs) atomiques u De telles relations sont dites normales Relations

26 25 P1 P2 P3 P4 S1 S2 P1 P2 P3 P1 P2 P3 P4 P1 P2 P3 S1 S2 Norm. O NF1 NF

27 26 Normalization en 1-NF u Contrainte très importante ! u Etud (E#, Tel, Hobbies, 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 Solution : normalisation en i-NF ; i > 1 u voir le cours sur la normalisation relationnelle

28 27 u Opérations relationnelles sont définies par les expressions : u d'algèbre relationnelle u de calcul de tuple (de prédicat) (QUEL, ALPHA) u de calcul de domaine (QBE) u les trois formalismes sont équivalents (Codd) u Un langage de base de données peut mélanger les types d'expression ci-dessus (SQL) u Calcul de tuple et algèbre Relations

29 28 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,... u C atomique consiste dun attribut u C composite en contient plusieurs Clés

30 29 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) u A la SS Pers (Nom, Prénom, SS#, Tel) u A l'état civil Pers (Nom, Prénom, SS#, Tel) 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

31 30 u La clé C définie comme auparavant peut- être appelée aussi clé minimale u Tout ensemble C' d'attributs de relation R incluant C est alors appelée clé u Alternativement, si C est appelé clé, alors tout C' est appelé super-clé Dans notre base S-P, S# est une clé (minimale) de S, donc (S#, SNAME) est une super-clé de S. Et les attributs (SNAME, STATUS) ne sont même pas une super-clé Relations

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

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

34 33 u L'égalité C = F constitue le lien sémantique entre les relations correspondants u Dans un SGBD de 2-ème génération ces liens étaient les références explicites (pointeurs) u Entre C et F il peut exister la contrainte d'intégrité référentielle u En général: pas de F sans C u pas de participant qui ne serait pas un étudiant connu u Les SGBD majeurs gèrent désormais de telles contraintes, u MSAccess : u L'intégrité ref. 1:1 et 1:N u Jointures implicites Relations

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

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

37 36 u Une valeur nulle est un abus de langage pour designer une absence de valeur dun attribut u On dit aussi un nul Valeurs nulles

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

39 38 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 Lutilisation dun nul pour un attribut peut être interdite Types de nuls

40 39 Pourquoi ? Peut-on néanmoins en pratique Sur MsAccess, Oracle, DB2… Autoriser une valeur nulle pour un attribut-clé ? Créer des relations sans clé ? Les nuls et les clés Un attribut-clé ne peut être nul

41 40 On peut interdire en pratique la présence dun nul pour un attribut Dans la définition de lextension 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 Les nuls en perspective

42 41 u Une base est un modèle d'une entreprise (ANSI- SPARC) u Une entreprise est une collection structurée u d'objets réels u éléments identifiables de l'univers de l'entreprise u un fournisseur, une pièce, une fourniture, un nom, une ville... u de types d'objet u ensembles d'objets ayant une intention commune u les fournisseurs, les pièces, les villes... u de propriétés des objets u applications de types d'objet en types d'objet u ville de fournisseur, fournitures d'un fournisseur... Modélisation relationnelle (démarche intuitive) Paris Villes Fournisseur

43 42 u Un objet sans propriétés est un objet atomique u Son OID est sa valeur u Nom, Poids, Un nombre entier… u Un objet avec les propriétés est un objet structuré u Il a un OID qui nest pas sa valeur u un fournisseur... Modélisation relationnelle (démarche intuitive) Nom S# Name City Status S Code postal Code postal

44 43 Modélisation relationnelle (démarche intuitive) u Une propriété u est nommée u SNAME, WEIGHT u peut être u fonctionnelle (non-transitive ou transitive) u elle évalue à une valeur atomique u nom d'un fournisseur... u non-fonctionnelle binaires 1:1, 1:N ou M:N u évalue à un ensemble de valeurs atomiques u père dune personne u fournitures d'un fournisseur u hobbies dune personne u pièces fournies par un fournisseur u non-fonctionnelle m-aires ; m > 2 u fournitures d'un fournisseur pour des projets u patients soignés dans des services et suivis par des médecins

45 44 u Identifie les objets, les types et les propriétés u pas de règles formelles u les propriétés non-fonctionnelles doivent être toute de type 1:N Un type T d'objets structurés O une relation R Un type d'objets atomiques un domaine D u Noms, Entier, Texte,... Une propriété fonctionnelle non-transitive de tout O un attribut de R u une application nommée d'un objet dans un domaine u SNAME, WEIGHT, COLOR... Modélisation relationnelle (Réel -> Schéma Conceptuel)

46 45 Un O une valeur d'une clé primaire C de R u un ou plusieurs attributs constituant une clé candidate de R u SS#, (Nom, Tel), E#... u un attribut nouveau dont la valeur constituera l'OID u si aucune clé candidate de R n'est un identifiant possible ou souhaitable pour O u il s'agit de OID au sens : valeur sans sémantique u définie automatiquement ou manuellement u S#, P#, SP# ? Modélisation relationnelle (clé primaire)

47 46 Une propriété non-fonctionnelle 1:N d'un objet O une référence à O dans la table de l'objet cible u une valeur de l'attribut qui constitue la clé étrangère F = C u C est la clé primaire de la table-source de la propriété u On verra plus tard les propriétés M:N u La cible peut être la source elle-même u Une relation peut être la cible de plusieurs propriétés u fonctionnelles ou pas u SP (S#, P#...) Modélisation relationnelle (clés étrangères) Pers (SS#,.. Propriétés (Pnom,SS#...

48 47 u Une propriété fonctionnelle de O peut se révéler transitive u Il s'agit en fait d'une propriété de O' qui est lui même une cible d'une propriété de O u SP' (S#, P#, QTY, PNAME, COLOR...) u QTY est une propriété non-transitive de SP u PNAME, COLOR sont des propriétés transitives de SP u car il sagit en fait de propriétés non transitives de P u Les propriétés transitives doivent être éliminées u elles donnent lieu aux duplications et anomalies de mise à jour u PNAME, COLOR sont inutilement répétés pour toute fourniture d une même pièce P# u on reverra ce concept en détail plus tard Modélisation relationnelle (propriétés transitives)

49 48 u Il faut mettre une telle propriété dans R où elle est directe (non-transitive) u SP (S#, P#,QTY) P (P#, PNAME, COLOR) u On retrouve la restructuration par décomposition u Et une référence 1:N P.P# -> SP>P# u On sépare "les torchons et les serviettes" u On fait intuitivement une normalisation relationnelle u formelle, en 2NF, 3NF et BCNF... Modélisation relationnelle (démarche intuitive)

50 49 u Une propriété P non-fonctionnelle de O peut s'avérer M:N u Les pièces fournies par un fournisseur quand une pièce peut avoir plusieurs fournisseur u S (S#, SNAME..P#, QTY..) u Alors, on a omis d'identifier un type d'objet tel que P correspond à deux (ou plus) propriétés 1:N u les fournitures SP, l'amitié… u peut avoir ses propres propriétés (QTY) Modélisation relationnelle (propriétés binaires M:N) AmisS P S P SP Amitié

51 50 u Ces règles sont en général suffisantes en pratique u Jusqu'à 4 NF (incluse) u Cependant, elle ne sont pas en général univoques u elles peuvent donner lieu à plusieurs schémas différents u elles ne sont pas non plus suffisantes pour tous les cas u Ex. mise en 1-O NF (à voir plus tard), puis 5NF u Il ne semble pas qu'il existe des réglés universelles Démarche intuitive (limites pratiques)

52 51 u Les SGBD relationnels n'ont que les domaines génériques u Char, Integer, Float, Counter, Memo... u En SQL-3 il y aura des domaines + spécifiques u Age, Ville... u En attendant, si besoin est on peut simuler les domaines spécifiques avec des relations unaires et les contraintes d'intégrité ref. u S ( S#, SNAME, Status...) STATUS (Status) /* Les statuts possibles Démarche intuitive (limites pratiques)

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

54 53 u Il faut minimiser le nombre de nœuds du graphe de références u Sous contraintes : u Dabsence danomalies u dinsertion, suppression, MAJ u De préservation de dépendances fonctionnelles Modélisation relationnelle : Conception dune BD relationnelle

55 54 u Plusieurs relations u Chaque relation consistant u dune clé u de max dattributs identifiés chacun comme une fonction atomique de la clé Modélisation relationnelle : Résultat typique

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

57 56 Exemple canon Fournisseurs Pièces Fournitures S# P# S#P#

58 57 Exemple canon S P SP

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

60 59 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' ;

61 60 1 u Graphe de références: u Clés primaires n'ont pas de sémantique u Jouent les rôles de OIDs définis à la main Les fournisseurs et les pièces sont en correspondance M : N ; 1 < M, N < u représentée en général comme ci-dessus par trois objets et deux relations 1:N Exemple canon S P SP 1 N N

62 61 Propriétés non-fonctionnelles m-aires u Représentées par un objet cible de m >2 liens référentiels u Base S-P-T: chaque pièce fournie est utilisée pour une tache T u SPT (S#, P#, T#, QTY) 1 S P SPT 1 N N T N 1

63 62 Base Hôpital u Les patients sont soignés par des médecins, dans des services u Un médecin peut être partagé entre plusieurs patients et services 1 P S SPM 1 N N M N 1 La vie est moins facile

64 63 u Un employé travaille dans un (seul) département ayant un nom et une localisation. u On fait une relation ? Emp (E#, Enom, D#, Dnom, Loc) u Ou deux ? Emp (E#, Enom, D#) D (D#, Dnom, Loc) u Et pourquoi pas les rel. atomiques Emp (E#), Empn (E#, Enom), Empd (E#, D#), D (D#), Dn (D#, Dnom), Dl (D#, Loc), L (Loc) u Pas de bonne réponse générale dans la théorie des bases relationnelles La vie est moins facile

65 64 u E# et Enom sont des clés candidates pour un étudiant. u Quel schéma choisir pour créer la base des notes des étudiants ? E (E#, Enom, C#, Note) ? E (E#, Enom, C#, Note) ? u ou peut-être : E (E#, C#, Note) et EN (E#, Enom) u ou enfin : E (Enom, C#, Note) et EN (E#, Enom) La vie est moins facile

66 65 u Un cour est donné par des profs et comporte une liste de livres u quelle base faut-il créer u Cours (C#, P#, Livre) ? u ou peut-être la base u Cours (C#, Livre) et CP (C#, P#) ? La vie est moins facile

67 66 u Si une personne a les diplômes, les voitures et les hobbies, alors peut-on dire formellement pourquoi le schéma (P#, Nom, Dipl, Voit, Hobby) n'est pas en général souhaitable ? La vie est moins facile

68 67 Solutions u Théorie formelle de la conception relationnelle u Fondée dans les années u Codd, Boyce, Fagin, Armstrong, Bancilhon, Spyratos, Delobel, Date, Ullman, Sagiv, Vardi... u Largement délaissée depuis u Mais il y a des contributions récentes u Date & Fagin, Krishnamourthy & Litwin...

69 68 FIN Merci de votre attention W. Litwin

70 69


Télécharger ppt "1 Modèle Relationnel de Données Witold Litwin 2 Base de données relationnelle Fichier =tableourelation Donnée =ligneouattributatomique Opérations = transformations."

Présentations similaires


Annonces Google