• Aucun résultat trouvé

Modélisation-03 : MR-MEA-avancé : ontologie relationnelle

N/A
N/A
Protected

Academic year: 2022

Partager "Modélisation-03 : MR-MEA-avancé : ontologie relationnelle"

Copied!
51
0
0

Texte intégral

(1)

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

(2)

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

(3)

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

(4)

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.

(5)

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

(6)

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.

(7)

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.

(8)

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

(9)

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

(10)

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.

(11)

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

(12)

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 :

(13)

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)

(14)

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

(15)

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.

(16)

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.

(17)

Ø 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.

(18)

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)

(19)

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

(20)

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

(21)

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), );

(22)

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) ) ;

(23)

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)

(24)

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 ;

(25)

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 »

(26)

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.

(27)

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.

(28)

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)

(29)

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

(30)

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

(31)

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

(32)

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.

(33)

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

(34)

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.

(35)

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

(36)

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

(37)

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.

(38)

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.

Références

Documents relatifs

3) Le GROUP BY consiste d'abord en un ORDER BY : les tuples restants sont triés selon les valeurs croissantes de la liste des attributs du group by ; ca génère des sous-ensembles. 4)

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

Mettre Mettre à Mettre Mettre à à à jour jour jour en jour en en en cascade cascade cascade les cascade les les les champs champs champs champs correspondants

Faire attention à l'ordre, on ne supprime pas une table qui a sa clé primaire utilisée dans une contrainte d'une autre table (clé étrangère dans une autre table). Lors de

Elle affiche deux champs de saisie de texte, pour le numéro du court et l'heure de début de la réservation, et une liste permettant de choisir son partenaire; la liste affiche

numIndividu, idSport, annee: clé primaire composée de la table Pratique numIndividu clé étrangère qui référence numIndividu de la table Individu idSport clé étrangère

RESPONSABLE DE LA TABLE Responsable de la table. Responsable de

TABLE LUMINEUSE Table lumineuse.