Modélisation
Cours 01 – Modèle Relationnel brut et valorisé Contraintes d’intégrité
Bertrand LIAUDET
SOMMAIRE
SOMMAIRE 1
MODELE RELATIONNEL BRUT 4
1. Les 3 objectifs majeurs d’une BD et d’un SGBD 4
L’intégrité des données : altération et incohérence 4
La performance 4
La distinction entre données et traitements 4
2. La modélisation 5
3. Le modèle relationnel 6
Présentation 6
Table, tuple, attribut, clé primaire 6
Schéma de la BD 8
Définition d’une BD 8
Relations ensemblistes d’une table 8
4. Notion de clé étrangère 9
Présentation 9
Vocabulaire 11
Graphe des tables 11
Clé étrangère réflexive 12
Graphe des tables 14
Définition d’une BD et d’un SGBD 14
Relations ensemblistes entre 2 tables 14
5. Clé primaire concaténée : une difficulté du modèle relationnel 15
Cahier des charge 15
Modèle relationnel de la bibliothèque : les adhérents et les livres 15 Modèle relationnel de la bibliothèque : la table EMPRUNTER 17 2. Clé primaire concaténée : une difficulté du modèle relationnel 18
Quelle est la clé primaire de la table EMPRUNTER ? 18
Méthode pour déterminer la clé primaire quand on a plusieurs clés étrangères 18
3. Bilan de la modélisation 19
Schéma de la BD de la bibliothèque 19
Formalisme de l’écriture des tables en MR 19
4. Eléments de modélisation 20
Distinction entre table-nom et table-verbe 20
Relations ensemblistes entre table-verbe et tables-noms 20
Intérêt de la clé primaire concaténée 21
Syntaxe SQL 21
Clé clé secondaire concaténée 21
6. Clé étrangère concaténée 22
Principe 22
Exemple 22
Modèle relationnel 22
7. Attributs calculés 23
Définition 23
Attribut calculé et modèle relationnel brut 23
Exemple 23
Conséquences du choix d’un attribut calculé : les risques d’incohérence, gestion de trigger 24
8. Ontologie relationnelle : tous les cas de clé primaire 25 1 : Clé primaire simple : les « tables d’objets » et les « tables de types » 25 2 : Clé primaire simple et étrangère : les « tables-espèce » et les « tables de
compléments » 26
3 : Clé primaire concaténée avec un identifiant relatif : les « tables de
composants » 27
4 : Clé primaire concaténée avec une date : les « tables d’historiques » 28 5 : Clé primaire concaténée avec uniquement des clés étrangères : les « tables de
liaisons » 29
6 : Table complexe 30
7 : Synthèse 31
9. Évolutions d’un modèle 33
Présentation 33
Évolution par gestion de l’historique d’un attribut 33 Evolution par passage d’un attribut monovalué à un attribut multivalué 34
Evolution par transformation d’un attribut en type 34
10. Méthode : comment fabriquer un schéma de BD ? 35
Analyse du problème formulé 35
Les « tables-noms » : objets, types, espèces 35
Clés étrangères et « tables-verbes » 36
Autres types de table 36
Ni trop ni pas assez ! Rasoir d’Occam et formes normales de Codd 37
Le secret de la modélisation : être concret !!! 37
11. Eléments théoriques du modèle relationnel 38
Domaine 38
Relation (table) 38
Attribut 38
Clé 39
Dépendance fonctionnelle 40
Expression ultra-schématique d’un schéma 40
MODELE RELATIONNEL VALORISE – CONTRAINTES D’INTEGRITE 41
1. Contraintes d’intégrité des données 41
Présentation 41
Les 11 contraintes de base sur un attribut 41
Les contraintes d’intégrité référentielle 44
Contrainte d’intégrité référentielle pour les tables 44 Contrainte d’intégrité référentielle pour les tuples 44
2. Cycle de vie des tuples 46
Présentation 46
Les différents cas 46
3. Cycle de vie et analyse fonctionnelle 47
Présentation 47
Elément d’analyse 47
Exemples 47
4. Dictionnaire des attributs 49
Présentation 49
Exemple 1 49
Exemple 2 50
5. Jeu de tests 51
Présentation 51
Trucs pour bien construire son jeu de tests 51
Edition Novembre 2017
MODELE RELATIONNEL BRUT
PRINCIPALES NOTIONS
Modèle relationnel Clé primaire
Table Clé significative
Tuple Schéma de la BD
Attribut NULL
Clé étrangère Clé étrangère réflexive Clé primaire concaténée
« table-nom » « table-verbe »
Table d’objets Table de types
Table-espèce Table de compléments
Table de composants Table d’historiques Table de liaisons Table complexe
1. Les 3 objectifs majeurs d’une BD et d’un SGBD
L’intégrité des données : altération et incohérence
Garantir l’intégrité des données, c’est éviter l’altération et l’incohérence des données.
L’altération des données
Il y a plusieurs sources d’altération possibles : l’usure, les pannes, les erreurs, les malveillances.
Une BD (et un SGBD) aura comme objectif d’en limiter la possibilité. Ce problème relève de la modélisation et de problèmes de sécurité.
L’incohérence des données
Une donnée est incohérente si elle est contradictoire avec une autre donnée.
Il y a deux grand types d’incohérence :
• La duplication des données avec des valeurs différentes. Exemple : deux adresses différentes pour une même personne.
• Les valeurs aberrantes. Exemples : un âge négatif ou supérieur à 150 ; une donnée faisant référence à une autre donnée qui n’existe pas.
La BD a pour objectif d’être un réservoir d’informations canonique (unique et commun), garantie sans incohérences (donc sans duplication de données).
La performance
Une BD doit fournir des performances acceptables par l’utilisateur.
C’est la problématique de l’optimisation.
La principale solution consiste à indexer correctement les attributs.
La distinction entre données et traitements
Les données existent indépendamment des traitements qu’on leur applique.
La BD permet d’apporter une vision unifiée des données manipulées (dans une entreprise ou n’importe quel système d’informations, scientifique par exemple), indépendamment des traitements qui leur sont appliqués.
Cette vision unifiée permet une meilleure compréhension de la réalité représentée par les données.
Elle permet aussi de rationaliser et donc de faciliter les traitements appliqués aux données.
2. La modélisation
La modélisation est l’activité qui consiste à produire un modèle.
Un modèle est ce qui sert ou doit servir d’objet d’imitation pour faire ou reproduire quelque chose.
On s’intéresse ici à la modélisation des données.
Un modèle des données est une représentation de l’ensemble des données. Cette représentation prend en compte un outil de représentation (un langage) et un niveau de précision (des contraintes méthodologiques).
Il existe plusieurs modèles de représentation des données : hiérarchique, relationnel, entité- association, objet, ensembliste, etc.
Les deux modèles dominants actuellement sont : le modèle relationnel : MR (qui correspond aux SGBD-R) et le modèle entité-association : MEA (qui est indépendant du type de SGBD utilisé). Ces deux modèles correspondent à 2 langages différents.
Les schémas entité-relation et les diagrammes de classes UML peuvent être utilisés comme autres langages à peu près équivalents au MEA. On peut aussi les utiliser pour le MR.
La méthode MERISE, utilisée quasi-exclusivement en France, distingue entre 3 types de modèles selon des critères méthodologiques : le modèle conceptuel des données : MCD, le modèle logique des données : MLD et le modèle physique des données : MPD. L’usage tend à rendre équivalents MCD et MEA, MLD et MR, MPD et SQL.
Le MCD est du niveau de l’analyse fonctionnelle : il est adapté à la maîtrise d’ouvrage (MOA) et à la partie fonctionnelle de la maîtrise d’œuvre (MOE).
Le MLD est du niveau de l’analyse organique et est adapté à la maîtrise d’œuvre (MOE).
La « jungle » des modèles !
Méthode MCD MLD MPD
Langage MEA, schema E-R, UML MR SQL
Type de langage Algo client Algo informaticien Code Niveau Analyse fonctionnelle
(externe).
MOA ou MOE
Analyse organique (interne, technique) MOE
Réalisation
MOE
3. Le modèle relationnel
Présentation
Le modèle relationnel a été inventé par Codd à IBM-San Jose en 1970.
C’est un modèle mathématique rigoureux basé sur un concept simple : celui de relation (ou table, ou tableau).
Ce modèle, c’est celui qui est implanté dans les SGBR-R.
Il permet à la fois de fabriquer la BD et de l’interroger.
Table, tuple, attribut, clé primaire Exemple traité
Un service de ressources humaines dans une entreprise veut gérer le personnel. Dans un premier temps, on veut pouvoir connaître le nom, la fonction, la date d’entrée, le salaire et la commission (part de salaire variable) de chaque employé.
Chaque employé a donc les caractéristiques suivantes :
Nom, fonction, date d’entrée, salaire, commission
Table, tuples et attributs
Pour ranger ces données, on peut faire un tableau à 5 colonnes :4
RELATION 5 attributs :
EMPLOYES Nom Fonction Date d’entrée Salaire Commission
TURNER SALESMAN 8-SEP-81 1500 0
JAMES CLERK 3-DEC-81 950 NULL
4 tuples : WARD SALESMAN 22-FEB-81 1250 500
TURNER ANALYST 3-DEC-81 3000 NULL
Vocabulaire
Relation = tableau = table = classe = ensemble = collection
Tuple = ligne du tableau = élément = enregistrement = individu = objet = donnée Attribut = colonne du tableau = caractéristique = propriété = champ
BD = toutes les lignes de toutes les tables NULL
NULL est la seule information codée qu’on rentre dans une table : elle signifie « non renseignée ». La valeur « 0 », par contre, ne signifie pas du tout « non renseignée », mais bien
« valeur = 0 », comme on dirait « valeur = 500 ».
En règle générale, il faut limiter les valeurs NULL.
A noter que MySQL, pour gagner facilement en performance, préconise d’éviter les valeurs NULL et de mettre ‘0’ à la place.
Clé primaire
On souhaite pouvoir distinguer facilement chaque ligne d’une autre ligne. Or, certains employés ont le même nom.
Pour distinguer chaque ligne, on introduit la notion de clé primaire.
La clé primaire est un attribut qui identifie un tuple et un seul.
Cela veut dire que quand on connait la clé primaire, on sait de quel tuple on parle, et on peut donc accéder sans ambiguïté à toutes les autres informations du tuple. La clé primaire est un attribut qui détermine tous les autres.
Une clé primaire est toujours renseignée.
Exemple de clé primaire : le numéro de sécurité sociale dans un tableau de personne. Quand on connaît le numéro de sécurité sociale, on sait de qui on parle, donc tous les attributs sont déterminés (même si on ne connaît pas leur valeur à un instant donné).
Dans le tableau des employés, la clé primaire pourrait être un numéro de référence choisi par l’entreprise. On le nomme NE (pour Numéro d’Employe).
6 attributs :
EMPLOYE NE Nom Fonction Date d’entrée Salaire Commission 1 TURNER SALESMAN 8-SEP-81 3000 0
2 JAMES CLERK 3-DEC-81 1800 NULL
3 WARD SALESMAN 22-FEB-81 2500 500
4 tuples : 4 TURNER ANALYST 3-DEC-81 5000 NULL
Clé secondaire
Une clé secondaire est un attribut qui pourrait être clé primaire, mais qui ne l’est pas.
Par exemple, dans le tableau des employés, on pourrait avoir le numéro de sécurité social. Cet attribut détermine tous les autres. Si on garde le numéro d’employé comme clé primaire, le numéro de sécurité sociale est alors clé secondaire.
En l’occurrence, on a tout intérêt à ne pas faire du numéro de sécurité sociale la clé primaire car on peut imaginer que l’employé existe sans que cette information soit renseignée.
Une clé secondaire peut ne pas être renseignée.
Clé significative
La clé significative, c’est l’attribut qui sert de clé dans le langage ordinaire. Dans le cas des employés, c’est leur nom. Toutefois, il peut y avoir des homonymes : la clé significative est utile dans le langage ordinaire pour savoir de quoi on parle, mais elle est insuffisante dans le langage mathématique pour garantir l’identification de l’individu. Elle est fonction du contexte. Dans un autre contexte, la clé significative pourrait être le prénom.
Schéma de la BD
Schéma des tables et schéma de la BD
Le schéma d’une table consiste à écrire la table sur une ligne avec les noms de code des attributs:
EMPLOYES (NE, nom, fonction, dateEmb, sal, comm)
L’ensemble des schémas des tables constitue le schéma de la BD.
Formalisme de l’écriture des tables en MR
1. Les clés primaires sont soulignées et placées en premier dans la liste des attributs.
2. Les clés secondaires se notent juste après la clé primaire, entre parenthèses.
3. La clé significative se note juste après la clé primaire.
Table-nom
La table des EMPLOYES représente une réalité physique. On l’appelle « table-nom ».
Le nom donné à une « table-nom » est un nom commun, au pluriel puisqu’une table contient plusieurs tuples. Toutefois, on peut aussi les mettre au singulier si ces tables sont destinées à produire des classes dans un mapping relationnel objet car le nom d’une classe, en tant que type, est par contre au singulier.
La clé primaire d’une « table-nom » est N (pour numéro) suivi des premières lettres du nom de la table (une seule éventuellement). Cette technique n’est d’usage que pédagogique ! On peut aussi les nommer « idNomDeLaTable » ou encore « id », quelle que soit la table.
Définition d’une BD
Une BD c’est un ensemble de tables avec leurs tuples.
Un SGBD gère une ou plusieurs BD.
Relations ensemblistes d’une table
Employes est un ensemble d’employés. Employes = {e1, e2, e3, e4 } On peut le représenter graphiquement :
Employés
Cette représentation permet de montrer les éléments en plus de l’ensemble. Elle ne montre pas les attributs.
Cette représentation trouve son intérêt quand on veut montrer les liens entre les ensembles dans un « schéma sagittal » (sagitta veut dire flèche en latin).
e1
e2
e3
e4
4. Notion de clé étrangère
Présentation Le problème
Au problème précédent de gestion des ressources humaines, on ajoute les spécifications suivantes :
Le service du personnel souhaite aussi connaître le nom du département dans lequel l’employé travaille. L’entreprise est répartie dans plusieurs villes. Les départements sont donc caractérisés par leur nom et par leur ville. Un employé travaille dans un département et un seul. Il peut y avoir plusieurs départements qui ont le même nom.
Solution 1 : la mauvaise !
On aurait pu ajouter directement les attributs du département dans la table des employés.
9 attributs :
EMPLOYE NE Nom Fonction Date d’entrée Salaire Comm. Num.
Dept Nom Ville
1 TURNER SALESMAN 8-SEP-81 3000 0 10 ACCOUNTING NEW YORK 2 JAMES CLERK 3-DEC-81 1800 NULL 30 SALES CHICAGO 3 WARD SALESMAN 22-FEB-81 2500 500 20 RESEARCH DALLAS 4 tuples : 4 TURNER ANALYST 3-DEC-81 5000 NULL 10 ACCOUNTING NEW YORK
Cette solution pose deux problèmes :
1) Elle viole le principe de non duplication : le triplet (10, Accounting, New York) apparaît 2 fois. Elle risque donc de conduire à des incohérences.
2) Elle ne permet pas d’avoir des départements vides.
Exemple d’incohérence
RELATION 7 attributs :
Employés NE Nom Fonction Date d’entrée Salaire Comm. Num.
Dept Nom Ville
1 TURNER SALESMAN 8-SEP-81 3000 0 10 ACCOUNTING DETROIT 2 JAMES CLERK 3-DEC-81 1800 NULL 30 SALES CHICAGO 3 WARD SALESMAN 22-FEB-81 2500 500 20 RESEARCH DALLAS 4 tuples : 4 TURNER ANALYST 3-DEC-81 5000 NULL 10 ACCOUNTING NEW YORK
INCOHERENCE !!!
Si dans le tuple numéro 1, on modifie la ville, remplaçant NEW YORK par DETROIT, on aura une BD incohérente puisque dans le tuple 1, le département 10 est à DETROIT et dans le tuple 4, ce même département est à NEW YORK
Solution 2 : la bonne !
Ø On retrouve la table des employés :
RELATION 7 attributs :
EMPLOYES NE Nom Fonction Date d’entrée Salaire Comm. ND 1 TURNER SALESMAN 8-SEP-81 3000 0 10
2 JAMES CLERK 3-DEC-81 1800 NULL 30 3 WARD SALESMAN 22-FEB-81 2500 500 20
4 tuples : 4 TURNER ANALYST 3-DEC-81 5000 NULL 10
Ø On va ajouter une table : la table des départements :
RELATION 3 attributs :
DEPARTEMENTS ND Nom Ville
10 ACCOUNTING NEW YORK
20 RESEARCH DALLAS
30 SALES CHICAGO
4 tuples : 40 OPERATIONS BOSTON
• ND est le numéro de département : il était déjà dans la table des employés.
• ND est clé primaire dans la table des départements.
• Désormais, le numéro de département ND de la table des employés fait référence au numéro de département de la table des départements.
• ND est ainsi clé étrangère dans la table des employés.
Avantages
1) On a un département vide : le 40
2) Si le département 10 de NEW YORK passe à WHASHINGTON, il suffit de modifier l’unique tuple concerné :
RELATION 3 attributs :
DEPARTEMENTS ND Nom Ville
10 ACCOUNTING WHASHINGTON
20 RESEARCH DALLAS
30 SALES CHICAGO
4 tuples : 40 OPERATIONS BOSTON
Unique modification : on évite ainsi les incohérences.
Vocabulaire Définition
Une clé étrangère est un attribut qui fait référence à une clé primaire.
Schéma de la BD
Le schéma de la BD consiste à écrire chaque table sur une ligne avec les noms de code des attributs :
EMP(NE, nom, fonction, dateEmb, sal, comm., #ND) DEPT (ND, nom, ville)
Formalisme usuel pour la clé étrangère
• Le nom d’une clé étrangère est en général le nom de la clé primaire qu’elle référence.
• Les clés étrangères sont mises en dernier dans la liste des attributs.
Le nom des clés étrangères est précédé d’un « # » sur le papier, mais pas dans la programmation !
Graphe des tables
Le graphe des tables montre les tables et le lien entre les tables : Emp
Dept
On peut aussi présenter le nom de la clé étrangère : Emp ND
Dept
Clé étrangère réflexive Présentation
Au problème précédent de gestion des ressources humaines, on ajoute les spécifications suivantes :
Chaque membre du personnel a un supérieur hiérarchique et un seul lui-même membre du personnel, sauf le président qui n’a pas de supérieur hiérarchique.
La solution :
La table résultat ressemblera à celle-ci :
8 attributs :
EMPLOYES NE Nom Fonction Date d’entrée Salaire Comm. # #ND #NEchef 1 TURNER SALESMAN 8-SEP-81 3000 0 10 5
2 JAMES CLERK 3-DEC-81 1800 NULL 30 1
3 WARD SALESMAN 22-FEB-81 2500 500 20 4
5 tuples : 4 TURNER ANALYST 3-DEC-81 5000 NULL 10 5
5 BOSS PRESIDENT 10-DEC-80 7000 NULL 5 NULL
Définition
Une clé étrangère réflexive est un attribut qui fait référence la clé primaire de sa table.
Schéma de la BD
Le schéma de la BD consiste à écrire chaque table sur une ligne avec les noms de code des attributs :
EMPLOYES (NE, nom, job, datemb, sal, comm., #ND, #NEchef) DEPARTEMENTS (ND, nom, ville)
Formalisme de l’écriture des tables en MR
1. Les clés primaires sont soulignées et placées en premier dans la liste des attributs.
2. Les clés secondaires se notent juste après la clé primaire, entre parenthèses.
3. La clé significative se note juste après la clé primaire.
4. Les clés étrangères sont précédées d’un #.
5. Les clés étrangères sont mises en dernier dans la liste des attributs.
6. Les clés étrangères réflexives sont mises après les clés étrangères non-réflexives.
7. Le nom des clés étrangères réflexives reprend le nom de la clé primaire Remarque sur le nom des clés primaires
Les clés primaires sont souvent appelées : « id », pour toutes les clés.
Les clés étrangères sont parfois appelées : « idNomTable.
Exemple :
EMPLOYES (id, nom, job, datemb, sal, comm., #idDepartement, #idChef) DEPARTEMENTS (id, nom, ville)
Remarque sur le nom des tables
Le nom des tables peut être mis au singulier.
Graphe des tables
On précise au minimum le nom de l’attribut clé étrangère réflexive :
EMPLOYES NEchef
DEPARTEMENTS
Définition d’une BD et d’un SGBD
• Une BD c’est un ensemble de tables avec leurs tuples.
• Un SGBD gère une ou plusieurs BD.
Relations ensemblistes entre 2 tables
Employes est un ensemble d’employés. Employes = {e1, e2, e3, e4, e5 } Departements est un ensemble de départements. Departements = {d1, d2, d3}
On s’intéresse à la relation : « travailler dans » : « les employés travailler dans un départements».
On peut décrire la situation par un « schéma sagittal » (sagitta veut dire flèche en latin)
Employes « travailler dans » Departements
1.1 0.*
1.1 est une « cardinalité ». Elle veut dire que 1 employé travaille dans 1 département et 1 seul (minimum 1, maximum 1).
0.* veut dire que dans un département, il peut y avoir 0 ou plusieurs (et parfois 1 seul) employés.
e1
e2
e3
e4
e5
d1
d2
d3
5. Clé primaire concaténée : une difficulté du modèle relationnel
Cahier des charge
• Une bibliothèque gère les emprunts des livres de ses adhérents.
• Les livres ont un titre et un auteur.
• Les exemplaires physiques des livres ont un numéro différent par exemplaire. Ils correspondent à un livre et ont un éditeur.
• Les adhérents ont un nom, un prénom, une adresse et un téléphone.
• On souhaite archiver tous les emprunts.
• Un livre ne peut pas être rendu le jour même de son emprunt.
• La durée maximum d'emprunt doit être est de 14 jours.
• La bibliothèque souhaite pouvoir connaître à tout moment la situation de chaque abonné (nombre de livres empruntés, retards éventuels). On veut pouvoir connaître la durée de chaque emprunt. On veut pouvoir faire faire des statistiques sur la pratique des clients (nombre de livres empruntés par an, répartition des emprunts par genre, nombre d’emprunts par livre, etc.).
Modèle relationnel de la bibliothèque : les adhérents et les livres Tables des Adhérents et des Livres
De l’analyse du texte précédent, on extrait aisément la table des adhérents et celle des livres :
Version en cours :
ADHERENTS (NA, nom, prenom, adr, tel) LIVRES (NL, titre, auteur, editeur)
Les livres correspondent à chaque exemplaire physiquement présent dans la bibliothèque.
+---+---+---+---+
|NL | titre | auteur | editeur | +---+---+---+---+
| 1 | Alcibiade | Jacqueline de ROMILLY | FOLIO |
| 2 | Narcisse et Goldmund | Hermann HESSE | FOLIO |
| 3 | Bénénice | Jean RACINE | FOLIO |
| 4 | Bénénice | Jean RACINE | HACHETTE |
| 5 | L'éthique | Baruch SPINOZA | GF |
| 6 | Le bruit et la fureur | William FAULKNER | GF |
| 7 | Le bruit et la fureur | William FAULKNER | HACHETTE |
| 8 | Les possédés | Fedor DOSTOIEVSKI | FOLIO |
| 9 | Lettres à un jeune poète | Rainer Maria RILKE | FOLIO | etc.
Comment gérer le fait d’avoir plusieurs exemplaires d’un même livre ? Ø Première solution
Par exemple, on a deux exemplaires de Alcibiade :
+---+---+---+---+
|NL | titre | auteur | editeur | +---+---+---+---+
| 1 | Alcibiade | Jacqueline de ROMILLY | FOLIO |
| 10| Alcibiade | Jacqueline de ROMILLY | FOLIO |
Le défaut est qu’on duplique le couple (titre, auteur) à chaque fois.
Ø Deuxième solution
Pour remédier à cela, on peut créer une table des d’ŒUVRES avec le couple (titre, auteur).
On garde la table des LIVRES qui correspondent aux exemplaires dans la bibliothèque avec leurs éditeurs et qui font référence aux ŒUVRES.
OEUVRES (NO, titre, auteur)
+----+---+---+
|NO | titre | auteur | +---+---+---+
| 1 | Alcibiade | Jacqueline de ROMILLY |
| 2 | Narcisse et Goldmund | Hermann HESSE |
| 3 | Bénénice | Jean RACINE |
| 4 | L'éthique | Baruch SPINOZA |
| 5 | Le bruit et la fureur | William FAULKNER |
| 6 | Les possédés | Fedor DOSTOIEVSKI |
| 7 | Lettres à un jeune poète | Rainer Maria RILKE | etc.
LIVRES (NL, editeur, #NO)
+---+---+----+
|NL | editeur | NO | +---+---+----+
| 1 | FOLIO | 1 |
| 2 | FOLIO | 2 |
| 3 | FOLIO | 3 |
| 4 | HACHETTE | 3 |
| 5 | GF | 4 |
| 6 | GF | 5 |
| 7 | HACHETTE | 5 |
| 8 | FOLIO | 6 |
| 9 | FOLIO | 7 |
| 10| FOLIO | | etc.
Ø Le modèle devient :
Version en cours :
ADHERENTS (NA, nom, prenom, adr, tel) LIVRES (NL, editeur, #NO)
OEUVRES (NO, titre, auteur)
On peut imaginer des informations supplémentaires pour livres et auteurs : Livres : année d’édition, date d’achat, sorti du stock, etc.
Ouvres : date de parution, langue originale, etc. On pourrait aussi avec des thèmes rattachés aux œuvres (policier, science-fiction, jeunesse, etc.).
Modèle relationnel de la bibliothèque : la table EMPRUNTER
Pour enregistrer les emprunts et les retours, on se dote d’une table EMPRUNTER : les adhérents empruntent des livres.
Les attributs de cette table sont les suivants :
EMPRUNTER (#NA, #NL, datemp, duremax, datret) La table contient par exemple :
+----+---+---+---+----+
| NL | datEmp | dureeMax | dateRet | NA | +----+---+---+---+----+
| 24 | 2017-02-24 | 14 | 2017-03-02 | 26 |
| 25 | 2016-12-01 | 21 | 2016-12-19 | 1 |
| 26 | 2016-11-27 | 21 | 2016-11-24 | 9 |
| 28 | 2017-09-28 | 14 | NULL | 16 |
| 31 | 2017-10-07 | 14 | NULL | 20 | +----+---+---+---+----+
Cela veut dire, en considérant qu’on est le 20/10/2017, que :
le livre 24 a été emprunté par l’adhérent 26 le 24/02/2017 et rendu le 02/03/2017. Il avait le droit à une durée d’emprunt de 14 jours.
Le livre 31 est actuellement emprunté par l’adhérent 31 et n’a pas été rendu : la dateRet est à NULL. Il n’est pas en retard. Il lui reste 4 jours.
Le livre 28 est actuellement emprunté par l’adhérent 28 et n’a pas été rendu : la dateRet est à NULL. Il est en retard de 8 jours.
2. Clé primaire concaténée : une difficulté du modèle relationnel
Quelle est la clé primaire de la table EMPRUNTER ? Quelle est la clé primaire de la table EMPRUNTER ?
On pourrait penser créer un attribut : « NEMP » et en faire la clé primaire.
Mais ce n’est pas la bonne solution.
Règle empirique de modélisation relationnelle :
Quand on a plus d’une clé étrangère dans une table, il faut se demander si la concaténation de plusieurs attributs de la table n’est pas clé primaire de la table.
Méthode pour déterminer la clé primaire quand on a plusieurs clés étrangères La méthode de recherche de la clé primaire sera la suivante :
1) Se demander si la concaténation des clés étrangères ne forme pas la clé primaire.
2) Si ç’est le cas, se demander si on ne peut pas retirer quelques clés étrangères de la concaténation.
3) Si ce n’était pas le cas, essayer d’ajouter des attributs non clé étrangère pour trouver la clé primaire.
4) Une fois trouvé, essayer de supprimer des attributs clés étrangères de la nouvelle clé primaire concaténée.
Application
1ère hypothèse : EMPRUNTER(#NA, #NL, datemp, dureeMax, datret)
Est-ce que NA et NL forment bien la clé primaire ? Non : un adhérent peut emprunter plusieurs fois le même livre à des dates différentes.
2ème hypothèse : on ajoute datemp : EMPRUNTER(#NA, #NL, datemp, dureeMax, datret) Le tripmet (NA, NL, datemp) est clé primaire
3ème hypothèse : on supprime NL : EMPRUNTER(#NA, #NL, datemp, dureeMax, datret) Le couple (NA, datemp) n’est pas clé primaire.
4ème hypothèse : on supprime NA : EMPRUNTER(#NA, #NL, datemp, dureeMax, datret) Le couple (NL, datemp) est clé primaire.
Conclusion
La table s’écrit donc ainsi :
EMPRUNTER(#NL, datemp, dureeMax, datret, #NA)
3. Bilan de la modélisation
Schéma de la BD de la bibliothèque
Version finale :
ADHERENTS (NA, nom, prenom, adr, tel) OEUVRES (NO, titre, auteur)
LIVRES (NL, editeur, #NO)
EMPRUNTER(#NL, datemp, dureeMax, datret, #NA)
Formalisme de l’écriture des tables en MR
1. Les clés primaires sont soulignées et placées en premier dans la liste des attributs.
2. Dans une clé primaire concaténée, les attributs clés étrangères sont placés en premier.
3. Les clés secondaires se notent juste après la clé primaire, entre parenthèses.
4. La clé significative se note juste après la clé primaire.
5. Les clés étrangères sont précédées d’un #.
6. Les clés étrangères sont mises en dernier dans la liste des attributs.
7. Les clés étrangères réflexives sont mises après les clés étrangères non-réflexives.
8. Le nom des clés étrangères réflexives reprend le nom de la clé primaire Graphe des tables du schéma de la BD
EMPRUNTER
LIVRES ADHERENTS
OEUVRES
4. Eléments de modélisation
Distinction entre table-nom et table-verbe
On a donc deux grands types de tables : les tables-noms et les tables-verbes
Les tables-noms
En général, les tables-noms représentent une réalité matérielle : les ADHERENTS, les LIVRES.
Les ŒUVRES, qui correspondent à un type, sont aussi une table-nom.
Elles ont une clé primaire simple.
Les tables-verbes
En général, les tables-verbes représentent une relation, un lien entre deux tables noms.
Ici on peut dire que « les adhérents empruntent des livres ».
Elles contiennent le plus souvent au moins 2 clés étrangères.
Formalisme
Le nom des tables-noms est un nom commun, en général au pluriel : ADHERENTS.
Le nom des tables-verbes est un verbe à l’infinitif : EMPRUNTER. Ce verbe désigne la relation que la table verbe établit entre les deux tables-noms : les adhérents empruntent des livres.
Relations ensemblistes entre table-verbe et tables-noms
Soit Adhérents un ensemble d’adhérents. Adhérents = {a1, a2, a3, …}
Soit Livres un ensemble de livres. Livres = {l1, l2, l3, …}
On s’intéresse à la relation : « Emprunter» : « les adhérents empruntent des livres ».
On peut décrire la situation par un « schéma sagittal » (sagitta veut dire flèche en latin)
Adhérent Emprunter Livres
0.* 0.*
0.* est une « cardinalité ». Elle veut dire qu’un adhérent peut avoir emprunté au minimum 0 livres et au maximum plusieurs (*).
a1
a2
a3
a4
a5
g1
g2
g3
g4
Intérêt de la clé primaire concaténée
Pourquoi n’a-t-on pas utilisé un attribut NE (numéro d’emprunt) comme clé primaire ? Pour 3 raisons :
• En déclarant (NL, datemp) comme clé primaire, on garantit l’unicité du couple NL, datemb, ce qui garantit la cohérence des données.
• On évite de créer un attribut inutile : NE ne signifie rien et ne sera jamais utilisé dans l’usage base de données.
• On met au jour le fait qu’un emprunt est défini par le couple (NL, datemb). Cela permet de mieux comprendre les données. En l’occurrence, la table EMPRUNTER est un historique des Livres : l’historique des emprunts qui arrivent aux livres.
Syntaxe SQL
Clé primaire concaténée
CREATE TABLE emprunter (
NL integer not null, datEmp date not null,
…
primary key (NL, datEmp)
foreign key(NL) references livres(NL), );
Clé clé secondaire concaténée Principe
Si la clé primaire de la table EMPRUNTER devait être un identifiant simple, alors le couple (NL, datemp) serait une clé secondaire concaténée.
Formalisme des clés secondaires
EMPRUNTER(NE, (#NL, datemp), datretmax, datret, #NA)
On met la clé secondaire juste après la clé primaire, entre parenthèses pour la repérer.
Syntaxe SQL : UNIQUE (NL, datemp)
CREATE TABLE emprunter ( NE integer primary, NL integer not null, datEmp date not null,
…
unique (NL, datEmp)
foreign key(NL) references livres(NL), );
6. Clé étrangère concaténée
Principe
Une clé étrangère fait référence à une clé primaire.
Une clé étrangère qui fait référence à une clé primaire concaténée sera elle aussi concaténée.
Exemple
Quand les adhérents sont en retard, la bibliothèque envoie des courriers de rappel aux adhérents.
On considère, ce qui n’est pas très réaliste !, que la bibliothèque envoie un courrier par emprunt en retard. Par exemple, un adhérent a emprunter 3 livres (A, B, C), en a rendu 1 (C), en a réemprunté 1 (D). Le temps passe. Les livres A et B sont en retard. Le livre C est rentré. Le livre D est emprunté et pas en retard. La bibliothèque envoie deux courriers : un pour le livre A et un pour le livre B.
Modèle relationnel
Au modèle précédent, on ajoute :
COURRIERS (NC, texte, date, # (NL, datemp) )
Le courrier fait référence à un emprunt (NL, datemp) qui lui-même fera référence à un adhérent.
Formalisme
Les attributs de la clé étrangère concaténée sont mis entre parenthèses et un « # » est mis devant les parenthèses. A noter qu’il n’y a plus de « # » devant « NL ». En effet, la clé étrangère concaténée fait référence à une clé primaire concaténée et c’est ensuite la clé primaire concaténée qui fait référence à des clés primaires simples.
Graphe des tables
COURRIERS
EMPRUNTER
LIVRES ADHERENTS
ŒUVRES
Syntaxe SQL : clé étrangère concaténée
Une clé primaire concaténée peut aussi devenir clé étrangère dans une autre table :
CREATE TABLE test (
NL integer not null,
datEmp date not null,
foreign key(NL, datemp) references emprunter(NL, datemp) ) ;
7. Attributs calculés
Définition
Un attribut calculé est un attribut dont la valeur peut être déterminée (calculée) à partir de l’état de la BD (des valeurs des autres attributs dans la BD).
Par définition, il duplique donc l’information.
Attribut calculé et modèle relationnel brut
Dans un modèle relationnel brut, on évite toute duplication d’information : on évite donc tous les attributs calculés.
Exemple
On reprend la bibliothèque et on ajoute qu’on veut savoir à tout moment le nombre de livres actuellement empruntés par un adhérent.
Requête
La demande précédente peut être traitée par une requête : Select count(*) from emprunter
Where na = notreAdhérent And dateRet is null;
Cette requête permet de répondre à la question sans avoir à créer un nouvel attribut. C’est la meilleure solution dans un premier temps.
Attribut calculé
On peut être tenté d’ajouter l’attribut « nbEmprunts » dans la table des adhérents : ADHERENTS (NA, nom, prenom, adr, tel, nbEmprunts)
OEUVRES (NO, titre, auteur) LIVRES (NL, editeur, #NO)
EMPRUNTER(#NL, datEmp, dureeMax, datRet, #NA)
Conséquences du choix d’un attribut calculé : les risques d’incohérence, gestion de trigger Risque d’incohérence
L’adhérent 32 vient emprunter le livre 10. Mettre à jour la BD :
Insert into emprunter values (10, current_date( ), 14, NULL, 32);
Update adherents
Set nbEmprunts = nbEmprunts +1 Where NA = 32;
En plus de la mise à jour de la table emprunter, il faut mettre à jour la table adhérents. Si one ne fait pas la mise à jour dans la table adhérents, les données seront incohérentes : la requête vue précédemment ne correspondra pas à la valeur de l’attribut nbEmprunts.
Gestion d’un trigger
Pour éviter le risque d’incohérence, on va gérer un trigger : ma mise à jour de l’attribut calculé sera automatique et pas manuel.
Les triggers sont des scripts déclenchés automatiquement à l’occasion d’une instruction du DML (insert, update ou delete).
Dans notre exemple, il faut mettre à jour l’attribut « nbEmprunts » de la table « Adhérents » à l’occasion d’un insert ou d’un update dans la table « Emprunter ».
Un attribut calculé doit toujours être associé à un système de trigger qui gère ses mises à jour automatiquement.
Ø Exemple de code MySQL
drop trigger if exists tai_emprunter;
# tai : trigger after insert delimiter //
create trigger tai_emprunter after insert on emprunter for each row
begin
update adherents
set nbEmprunts = nbEmprunts + 1 where NA = new.NA;
end;
//
delimiter ;
8. Ontologie relationnelle : tous les cas de clé primaire Sur l’ontologie informatique, voir par exemple :
http://www.academia.edu/586956/Essai_de_comparaison_des_ontologies_informatiques_et_ph ilosophiques_entre_etre_et_artefacts
1 : Clé primaire simple : les « tables d’objets » et les « tables de types » Exemples
1 : Les employés et les départements.
2 : Les livres de la bibliothèque.
3 : Les avions et leurs types
Solutions
Employés (NE, nom, fonction, salaire, #ND) Départements (ND, nom, ville)
Livres (NL, éditeur, dateAchat, #NO) Oeuvres (NO, titre, auteur, dateCréation)
Avions (NA, année, couleur, propriétaire, #typeAvion) TypeAvion(typeAvion, nombre places, année, moteur)
Principe de la distinction entre « table d’objets » et « table de types »
En général, une table avec une clé primaire simple correspond à une réalité physique : les employés, les départements, les exemplaires physiques des livres. Ce sont les « table d’objets ».
On peut aussi les considérer comme des tables d’instance (en référence à la notion d’instanciation de la programmation objet).
Une table avec une clé primaire simple peut aussi correspondre à des types de la réalité physique : c’est le cas des « TypeAvion », par exemple, le A320, ou des « œuvres » qui peuvent être considérées comme un type de « livres », le livre comme l’avion étant les exemplaires physiques (tous les « Voyage au bout de la nuit » de « Louis Ferdinand CELINE »). Ce sont les
« tables de types »
2 : Clé primaire simple et étrangère : les « tables-espèce » et les « tables de compléments » Exemple 1
On gère des personnes. Certaines sont étudiantes et suivent des études : année, domaine, spécialisation. D’autres sont salariés et ont une fonction, un salaire et une date d’embauche.
Solution 1
Personnes (NP, nom, prénom, adresse, téléphone) Etudiants (#NP, domaine, spécialisation, année) Salariés (#NP, fonction, salaire, datemb)
Exemple 2
Une galerie d’art vend des tableaux qui ont un titre, une année de création, une technique, un format, un prix et un auteur. Les tableaux sont des pièces uniques. Ils sont vendus une seule fois à un des clients. On enregistre aussi le prix et la date de la vente. Les clients ont un nom et une adresse
Solution 2
Tableaux (NT, titre, année, technique, format, prix, auteur) Ventes (#NT, prix, date, #NC)
Clients (NC, nom, adresse)
Principe
Une table avec une clé primaire simple et clé étrangère en même temps peut être :
Ø Soit une « table-espèce » (les étudiants)
Elle correspond à une spécialisation d’une autre table (les personnes qui correspondent alors au genre de l’espèce des étudiants). La clé primaire de la « table-espèce » est constituée par celle de la table qu’elle spécialise et est donc clé étrangère en même temps. Un étudiant est caractérisé par les données de son tuple dans la « table-espèce » et les données du tuple référencé dans la table correspondant à son genre, les personnes ici.
On dit que chaque tuple de la « table-espèce » « hérite » des attributs du tuple de la « table- genre » auquel il fait référence.
Ø Soit une « table de compléments »
Elle ajoute des informations à sa table d’origine : ici, la vente vient compléter les informations du tableau. La vente est un historique du tableau : la table « Ventes » contient une date. Mais la date ne participe pas à la clé primaire car un tableau n’est vendu qu’une seule fois.
L’intérêt de ne pas fusionner les « tables de compléments » avec leurs table d’origine, c’est de garantir la cohérence des données : en effet dans l’exemple proposé, on peut considérer que tous les attributs de la vente sont obligatoires, ce qui ne serait pas gérable en fusionnant la table des ventes et la table des tableaux (on pourrait avoir le NC renseigné mais pas de prix et pas de date). La table de compléments peut donc être considérée comme une « table des attributs facultatifs (pas obligatoires) liés entre eux ». Dans l’exemple, le prix, la date et le numéro de clients ne sont pas obligatoires pour une œuvre (ils ne seront renseignés qu’à l’occasion de la vente), mais sont liés entre eux : si on en renseigne un, il faut renseigner les autres.
3 : Clé primaire concaténée avec un identifiant relatif : les « tables de composants » Exemple
On gère des projets qui ont un nom, une date de début, une date de fin et un budget. Les projets sont composés d’étapes en nombres variables. Une étape est définie par son numéro d’ordre dans le projet (de 1 à N), par une date de début et une date de fin, un nom d’étape et un budget d’étape.
Solution
Projets (NP, nom, début, fin, budget) Etapes (#NP, NE, nom, début, fin, budget)
Principe
Le numéro d’étape est un identifiant relatif : de 1 à N. Il y a plusieurs étapes qui ont le même numéro d’étape. C’est le couple «NP, NE » qui est unique.
L’étape est un composant du projet : elle disparaît nécessairement avec le projet (elle n’a pas d’existence indépendamment du projet).
La table « Etapes » est une « table de composants ». La suppression d’un tuple dans la « table- composé » correspondante (les projets ici) implique nécessairement la suppression des tuples de la « table de composants ».
A noter que l’identifiant relatif peut être un numéro ou n’importe quelle information.
4 : Clé primaire concaténée avec une date : les « tables d’historiques » Exemple
1 : les emprunts à la bibliothèque.
2 : l’historique des adresses des adhérents de la bibliothèque
Solution
Livres (NL, éditeur, dateAchat, #NO) Oeuvres (NO, titre, auteur, dateCréation) Adhérents (NA, nom)
Emprunter (#NL, datEmp, dureeMax, dateRet, #NA) HistoAdressesAdherents (#NA, date, adresse)
Principe
Dès qu’une clé primaire contient une date, c’est un historique.
Dans le cas de l’adresse, on a sorti l’attribut adresse de la table « Adhérents ».
Remarque : historique et historique unique
L’exemple de l’historique unique concerne des tableaux qui sont vendus une seule fois : Ventes (#NT, prix, date, #NC)
La table « Ventes » est ici une « table de compléments ».
Si les tableaux pouvaient être vendus plusieurs fois (imaginons une location pour une certaine durée), la table d’historique unique deviendrait une table d’historique :
Location (#NT, date, durée, prix, #NC)
5 : Clé primaire concaténée avec uniquement des clés étrangères : les « tables de liaisons » Exemple 1
Un employé participe à plusieurs projets. Plusieurs employés participent à un projet.
Ø Solution
Employés (NE, nom, dateEmbauche)
Projets (NP, intitulé, dateDébut, dateFin, budget) Participer (#NE, #NP)
Principe
La table « Participer » est une « table de liaisons » entre les employés et les projets.
La clé primaire comporte plusieurs attributs dont au moins une clé étrangère.
Il n’y a pas d’attribut « date » dans la clé primaire.
Il n’y a pas de relation de composition entre les attributs de la clé primaire.
Il peut y avoir des attributs en plus de la clé primaire.
Exemple 2
On ajoute à l’exemple 1 le fait que l’employé joue un rôle unique sur le projet.
Ø Solution
Participer (#NE, #NP, rôle)
Exemple 3
On considère maintenant que l’employé peut jouer plusieurs rôles sur le projet et que pour chaque rôle de l’employé sur le projet on définit le nombre de jours d’activité.
Ø Solution
Participer (#NE, #NP, rôle, nbJours)
Principe
Une table de liaisons peut être constituée de plus de 2 attributs.
Les attributs d’une table de liaisons ne sont pas forcément des clés primaires mais ils sont forcément des identifiants.
Dans l’exemple 3, l’attribut « rôle » jour le rôle d’un identifiant : il pourrait être clé primaire de la table des rôles dans laquelle on trouverait par exemple le coût journalier pour un rôle donné.
6 : Table complexe Exemple 1
On gère des projets qui ont un nom, une date de début, une date de fin et un budget. Les projets sont composés d’étapes en nombres variables. Une étape est définie par son numéro d’ordre dans le projet (de 1 à N), par une date de début et une date de fin, un nom d’étape et un budget d’étape.
Le budget des étapes peut varier. On veut garder l’historique.
Solution 1
Projets (NP, nom, début, fin, budget) Etapes (#NP, NE, nom, début, fin)
HistoBudgetEtapes (#(NP, NE), date, budget)
Principe 1
Les clés étrangères peuvent toujours faire référence à n’importe quel type de clé primaire. Elles peuvent donc toujours être concaténées.
Dans l’exemple traité, on un historique : c’est un historique de la table de composition.
La clé étrangère de la table d’historique fait référence à une clé primaire concaténée.
Exemple 2
On envoie des courriers en nombre à des clients. Un courrier est caractérisé par un libellé et une date. Un même courrier peut être envoyé plusieurs fois à la même personne. On veut savoir quel client à reçu quel courrier
Solution 2
Courriers (NCO, libellé, date) Clients (NCL, nom, adresse) Envoyer (#NCL, #NCO, date)
Principe 3
C’est le même principe qu’un historique simple. C’est un historique de table de liaisons.
La clé étrangère de la table d’historique fait référence à une clé primaire concaténée : une table de liaisons. On pourrait écrire :
HistoEnvoyer (#(NCL, NCO), date) Envoyer (#NCL, #NCO)
Dans notre exemple, il est inutile de séparer les deux tables car la table envoyer ne contient pas d’attribut en dehors de la clé.
Exemple abstrait
On peut imaginer une table de liaisons historique qui relie une table de liaisons historique avec une table de composition, ce qui donnerait comme clé primaire :
#(CP, n°), #(CP1, CP2, date), date
7 : Synthèse
Ontologie relationnelle
On a initialement distingué entre 2 types de tables : celles à clé primaire simple (les « tables- nom ») et celles à clés primaires concaténées (les « tables-verbes »).
On distingue maintenant 5 types de clés primaires : CP, #CP, (#CP, date), (#CP, n°), (#CP1,
#CP2).
Ces 5 types de clé primaire correspondent à la description de 7 types de réalité : c’est la sémantique des tables de l’ontologie relationnelle.
A cela s’ajoute la possibilité de former des tables complexes.
TYPOLOGIE Type de clé primaire
TYPOLOGIE Type de table
ONTOLOGIE RELATIONNELLE Sémantique de la table
1 CP « table-nom » 1 : « table d’objets » ; 2 : « table de types » 2 #CP « table-nom » 3 : « table-espèce » ; 4 : « table de compléments » 3 #CP, n° « table-nom » 5 : « table de composants » (identifiant relatif) 4 #CP, date « table-nom » ou
« table-verbe »
6 : « table d’historiques »
5 #CP1, #CP2 ou #CP1, attribut
« table-verbe » 7 : « table de liaisons »
+1 complexe « table-nom » ou
« table-verbe »
+1 : table complexe de 3 à 7
Ø Remarque orthographique
Table-espèce, table-nom, table-verbe : espèce, nom et verbe au singulier car c’est la table qui est une espèce, un nom ou un verbe et non pas les tuples.
Table d’objets, de types, de composants, de compléments, d’historiques, de liaisons : tous au pluriel car chaque tuple est un objet, un type, un composant, etc., donc il y en a plusieurs par table.
Ø Remarque 1
Les tables de liaisons peuvent avoir plus de 2 clés étrangères.
Ø Remarque 2
Dans une table de liaisons, un attribut de la clé primaire peut, tout en étant un identifiant absolu (et non pas relatif), ne pas être clé étrangère. On peut donc avoir des tables de liaisons de la forme : #CP1, attribut.
Ø Remarque 3
Les tables d’historiques peuvent être des « tables-noms » ou des « tables-verbes ». L’historique d’un attribut est une « table-nom » : (#NEmployé, date, salaire). L’historique des emprunts de livres est une « table-verbe » : (#NLivre, dateEmp, dateRetour, #NAdhérent). C’est une « table- verbe » car elle relie les livres et les adhérents.
Ø Remarque 4
Les tables complexes peuvent être des « tables-noms » dans le cas où on fait l’historique d’un attribut d’une « table-espèce » ou d’une « table de composants ». Par exemple, si on voulait conserver l’historique du budget prévisionnel d’une étape d’un projet, on obtiendrait cette table : (#(NProjet, NEtape), date, budget). On a l’historique du budget d’une étape. La clé étrangère fait référence à une étape qui est un composant du projet.
Principe de la découverte de la totalité des clés primaires
A partir d’une clé primaire simple, on peut avoir 3 types de relations :
• Des relations d’héritage (inclusion d’ensemble).
• Des relations de composition
• Des relations de liaison simple
Ces trois types de relations sont celles qu’on retrouvera en UML dans les diagrammes de cas d’utilisation et dans les diagrammes de classes.
A cela s’ajoute dans tous les cas :
• la possibilité d’un historique.
9. Évolutions d’un modèle
Présentation
Un modèle relationnel modélise une situation donnée.
On peut envisager des modifications du modèle en fonction des évolutions prévisibles de la situation.
3 types d’évolution sont courantes :
1. La gestion de l’historique d’un attribut ou d’une table : création d’une table d’historique 2. Passage d’un attribut monovalué à un attribut multivalué : création d’une « table de
liaisons » ou d’une « table de composants »
3. Transformation d’un attribut en type : création d’une « table de types »
Du bon usage des évolutions dans le MR brut et valorisé
En première analyse, dans un MR brut et valorisé, il vaut mieux éviter la prise en compte des évolutions pour ne pas surcharger le modèle.
Ces évolutions pourront apparaître dans un second temps après justification.
Évolution par gestion de l’historique d’un attribut Principe
Soit la table : (CP, ..., attribut)
On peut faire évoluer la table en gérant un historique de l’attribut. On obtient alors : (CP, ...)
(#CP, date, attribut) : cette table est une « table d’historiques »
Exemple 1 : l’historique des salaires des employés Employés (NE, nom, job, salaire)
devient :
Emloyés (NE, nom, job) HistoSalaire(#NE, date, sal)
Exemple 1 : la vente des tableaux Ventes (#NT, prix, date, #NC)
La Vente est un complément du Tableau (NT) faite à un client (NC).
La table de compléments (historique unique) Ventes, devient une table d’historique : Ventes (#NT, date, prix, #NC)
Cela veut dire que la vente peut avoir lieu plusieurs fois (ce qui est étrange !)
Evolution par passage d’un attribut monovalué à un attribut multivalué Principe
Soit la table : (CP, ..., attribut)
On peut faire évoluer la table en considérant que la CP ne détermine plus une seule valeur de l’attribut mais plusieurs :
(CP, ...)
(#CP, attribut) : cette table est soit une « table de liaisons », soit une « table de composants »
Exemple 1 : les employés ont plusieurs jobs en même temps Employés (NE, nom, job, salaire)
devient :
Emloyés (NE, nom, salaire) JobsEmployés(#NE, job )
Evolution par transformation d’un attribut en type Principe
Soit la table : (CP, ..., attribut)
On peut faire évoluer la table en autonomisant l’attribut en en faisant une table : (CP, ...,, #attribut)
(attribut) : cette table est une « table de types ».
L’intérêt de cette transformation est de permettre de créer une liste de « attribut » qui soit indépendante de l’usage qu’on en fait dans une autre table.
A noter qu’il n’est pas nécessaire de créer un numéro comme clé primaire déterminant l’attribut.
Si toutefois on le faisait, l’attribut serait clé secondaire et on obtiendrait : (CP, ...,, #NA)
(NA , (attribut) )
Exemple : les employés et leur job Employés (NE, nom, job, salaire) devient :
Emloyés (NE, nom, salaire, #job) Jobs( job )
L’intérêt de cette transformation est de permettre de créer une liste de « job » qui soit indépendante de l’usage qu’on en fait dans la table des employés. Ainsi certains « job » peuvent être définis dans la table des Jobs sans être utilisés dans la table des employés.
10. Méthode : comment fabriquer un schéma de BD ?
Analyse du problème formulé
On part d’une situation décrite par un texte. Le texte décrit les données du monde réel. Ces données peuvent aussi provenir d’interviews d’acteurs du système.
Dans le texte, on ne s’intéresse pas aux objectifs à atteindre, mais seulement aux informations qui sont manipulées.
Correspondance grammaticale
A chaque mot du texte, on va pouvoir faire correspondre une table ou un attribut, selon un principe grammatical :
Principes de correspondance :
Type grammatical Elément du MR Exemples
Nom « table-nom » ou attribut Les employés
Adjectif Attribut Les emplo
Verbe reliant deux tables Relation entre deux tables Relation entre deux tables
Attention, ces principes de correspondance ne sont pas formels : ils servent de point de départ à l’analyse.
Ontologie sémantique
Sémantiquement, on trouve 7 types de tables : 1. objets
2. types 3. espèces
4. compléments dans le temps 5. composants
6. liaisons 7. historiques
Chaque fois qu’on trouve une table, il faut se demander à quel type de table elle correspond et ensuite quelle est sa clé primaire.
Les « tables-noms » : objets, types, espèces Quelles tables concevoir en premier ?
1. Il faut commencer par identifier des « tables d’objets» dont les tuples représentent une réalité physique concrète : donc les « tables d’objets ».
Par exemple : les employés sont des réalités physiques. On aura une table des employés.
2. A partir d’une table d’objet, on peut réfléchir aux tables de types et aux tables d’espèces qui
Par exemple : si on a défini des avions, on peut avoir une table de types d’avion. Si on a défini une table de personnes, on peut avoir l’espèce des employés et l’espèce des clients.
Questions à se poser pour chaque table envisagée :
1. Quelle est la clé primaire ? S’il n’y a pas de clé primaire, ce n’est pas une table
2. Quels sont les attributs ? S’il n’y a pas d’attributs, ce n’est pas une table. Les attributs doivent correspondre à une description du monde réel. Il ne faut pas en inventer.
3. Puis-je imaginer plusieurs tuples (lignes) concrets dans la table ? S’il n’y a pas de tuples, ce n’est pas une table.
Quelques remarques sur les tables
1. Si une table contient un nombre petit et fixe de tuples, c’est que ce n’est pas une table, mais un ensemble de valeurs constantes.
2. Si deux tables contiennent les mêmes tuples, ou les mêmes attributs, ou la même clé primaire, c’est qu’elles sont identiques.
3. Si une table n’a que 2 attributs, dont la clé primaire, elle peut probablement être fusionnée dans une autre table qui pointe sur elle.
a. A(A, Ax, #B1) et B(B1, B2) devient : A(A, Ax, B2)
Clés étrangères et « tables-verbes » Clés étrangères
Dès qu’on a deux tables, il faut se demander si la clé primaire de l’une ne pourrait pas être clé étrangère dans l’autre et réfléchir à la signification d’une telle relation.
Par exemple : avec Employés et Départements. On ne peut pas avoir de numéro d’employé dans la table des départements. Par contre, on peut avoir un numéro de département dans la table des employés : ce sera le département dans lequel l’employé travaille.
« Tables-verbes »
Dès qu’on a deux tables, il faut se demander si on ne peut pas créer une nouvelle table qui soit une liste qui regroupe les deux clés primaires de ces deux tables et réfléchir à la signification possible d’une telle table. Il faudra aussi se demander si on ne peut pas ajouter des attributs dans cette nouvelle table.
Par exemple : avec les Livres et les Abonnés. On peut concevoir une liste de couples (NL, NA).
La signification correspond à la relation possible entre les deux attributs : un abonné emprunte un livre. C’est une table d’emprunts. On peut y ajouter la date d’emprunt comme attribut.
Autres types de table
Tables-espèce et table de compléments
Quand on a une première table qui fait référence via une clé étrangère à une seconde table traitant grosso modo de la même réalité, il faut se demander si la clé primaire de la première table ne peut pas être remplacée par la clé étrangère vers la seconde table.
Table de composition
Dès qu’une première contient une clé étrangère vers une deuxième table et que la première table est un composant de la seconde, alors il existe probablement un attribut identifiant relatif dans la première table.
Ni trop ni pas assez ! Rasoir d’Occam et formes normales de Codd Pour avoir une bonne modélisation :
• Il faut d’une part éviter de multiplier les tables et les attributs (éviter tous les attributs calculés, éviter de transformer, au moins en première analyse, un attribut en table et surtout éviter de transformer une valeur d’attribut en table). C’est le principe du « rasoir d’Occam », vieux principe de logique de Occam (1287-1349) et qui dit : Entia non sunt multiplicanda praeter necessitatem, c’est-à-dire : il ne faut pas multiplier les entités plus que nécessaire.
• Il faut d’autre part éviter de fusionner des tables qui doivent être séparées. C’est ce que l’analyse des formes normales de Codd nous apprendra.
Le secret de la modélisation : être concret !!!
Pour avoir une bonne modélisation, il faut concrétiser le modèle.
Autrement dit, il faut mettre des tuples dans les tables qu’on crée, pour vérifier la validité des tables.
11. Eléments théoriques du modèle relationnel
Domaine
Un domaine c'est un ensemble de valeurs (que peut prendre un prédicat ou attribut). Il est défini en intension ou en extension. Il est non vide.
Exemples de domaine
• l'alphabet, domaine défini en extension;
• une chaîne de 20 caractères, définie en intension (toutes les combinaisons possibles de lettres entre 1 et 20 caractères).
• les entiers, domaine défini en intension;
• les entiers compris entre 0 et 100, domaine défini en extension;
• l'ensemble de couleurs {bleu, rouge, vert, marron}, domaine défini en extension.
Relation (table)
Une relation n-aire (ou table) est un sous-ensemble du produit cartésien d'une liste de domaines D1, D2, …, Dn.
R = sous ensemble de D1 x D2 x … x Dn
Une relation peut être vue comme un tableau à deux dimensions dont les colonnes correspondent aux domaines (et donc aux attributs) et les lignes correspondent aux éléments individuels.
Attribut
Un attribut est une fonction entre une relation et un domaine auquel on ajoute la valeur NULL, cette valeur voulant dire « non défini ».
Ai : R → Di ∪ {NULL}
Une relation R définie sur n attributs est notée :
R(A1, A2, …, An)
Un attribut c'est une colonne d'une relation caractérisée par un nom. L’ordre des colonnes dans la relation n’a pas d’importance.
Tuple
Un tuple est un n-uplet du produit cartésien d'une liste de domaines.
Le tuple, c’est une ligne de la table. L’ordre des lignes dans la table n’a pas d’importance.
Exemple :
Un tuple de la table des employés, c’est un sext-uplet du produit cartésien entre le domaine des n°, des noms, des fonctions, des dates, des salaires et des commissions.