Modélisation Cours 01 – Modèle Relationnel brut et valorisé...

Modélisation – Cours 01 - MR brut et valorisé - page 1/58 - Bertrand LIAUDET

Modélisation Cours 01 – Modèle Relationnel brut et valorisé

Contraintes d’intégrité

Bertrand LIAUDET

SOMMAIRE

SOMMAIRE 1

MODELE RELATIONNEL BRUT 41. Les 3 objectifs majeurs d’une BD et d’un SGBD 4

L’intégrité des données : altération et incohérence 4La performance 4La distinction entre données et traitements 4

2. La modélisation 53. Le modèle relationnel 6

Présentation 6Table, tuple, attribut, clé primaire 6Schéma de la BD 8Définition d’une BD 8

4. Notion de clé étrangère 9Présentation 9Vocabulaire 11Graphe des tables 11Clé étrangère réflexive 12Graphe des tables 14Définition d’une BD et d’un SGBD 14

5. Clé primaire concaténée : une difficulté du modèle relationnel 15Cahier des charge 15Modèle relationnel de la bibliothèque : les adhérents et les livres 15Modèle relationnel de la bibliothèque : la table EMPRUNTER 17

2. Clé primaire concaténée : une difficulté du modèle relationnel 18Quelle est la clé primaire de la table EMPRUNTER ? 18Méthode pour déterminer la clé primaire quand on a plusieurs clés étrangères 18

3. Bilan de la modélisation 19Schéma de la BD de la bibliothèque 19Formalisme de l’écriture des tables en MR 19Graphe des tables du schéma de la BD 19

4. Eléments de modélisation 20Distinction entre table-nom et table-verbe 20


Relations ensemblistes entre table-verbe et tables-noms 20Intérêt de la clé primaire concaténée 21Syntaxe SQL 21Clé clé secondaire concaténée 21

6. Clé étrangère concaténée 22Principe 22Exemple 22Modèle relationnel 22

7. Attributs calculés 23Définition 23Attribut calculé et modèle relationnel brut 23Exemple 23Consé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 251 : Clé primaire simple : les « tables d’objets » et les « tables de types » 252 : Clé primaire simple et étrangère : les « tables-espèce » et les « tables de compléments » 263 : Clé primaire concaténée avec un identifiant relatif : les « tables de composants » 274 : Clé primaire concaténée avec une date : les « tables d’historiques » 285 : Clé primaire concaténée avec uniquement des clés étrangères : les « tables de liaisons » 296 : Table complexe 307 : Synthèse 31

9. Évolutions d’un modèle 33Présentation 33Évolution par gestion de l’historique d’un attribut 33Evolution par passage d’un attribut monovalué à un attribut multivalué 34Evolution par transformation d’un attribut en type 34

10. Méthode : comment fabriquer un schéma de BD ? 35Analyse du problème formulé 35Les « tables-noms » : objets, types, espèces 35Clés étrangères et « tables-verbes » 36Autres types de table 36Ni trop ni pas assez ! Rasoir d’Occam et formes normales de Codd 37Le secret de la modélisation : être concret !!! 37

11. Eléments théoriques du modèle relationnel 38Domaine 38Relation (table) 38Attribut 38Tuple 38Clé 39Dépendance fonctionnelle 40


Expression ultra-schématique d’un schéma 40

MODELE RELATIONNEL VALORISE – CONTRAINTES D’INTEGRITE 411. Contraintes d’intégrité des données 41

Présentation 41Les 11 contraintes de base sur un attribut 41Les contraintes d’intégrité référentielle 44Contrainte d’intégrité référentielle pour les tables 44Contrainte d’intégrité référentielle pour les tuples 44

2. Cycle de vie des tuples 46Présentation 46Les différents cas 46

3. Cycle de vie et analyse fonctionnelle 47Présentation 47Elément d’analyse 47Exemples 47

4. Dictionnaire des attributs 49Présentation 49Exemple 1 49Exemple 2 50

5. Jeu de tests 51Présentation 51Trucs pour bien construire son jeu de tests 51

TD : EXERCICES DE MODELISATION RELATIONNELLE 521 Association et donateurs 52

Travail à partir d’un jeu de données 52Modélisation à réaliser sans jeu de données 53

2 La cinémathèque 533 La maison de disques 554 Les chantiers d’été 555 Les employés et leurs carrières 566. Gestion de projet 567. ASSURAUTO 57 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). RELATION 6 attributs : EMPLOYES 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.


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 ajoute les attributs Nom du département et Ville du département dans la table des employés.

RELATION 7 attributs :

EMPLOYES 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 ne permet pas d’avoir des départements vides. 2) Elle risque de conduire à des incohérences dans la base si on modifie la ville d’un

département. En effet, il faudra modifier tous les tuples concernés pour éviter l’incohérence. Sinon, on se retrouve, comme dans l’exemple, avec un département 10 dans 2 villes différentes.


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 :


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 :


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


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_philosophiques_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 Nom « table-nom » ou attribut

Adjectif Attribut Verbe reliant deux tables clé étrangère ou « table-verbe »

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 pourraient lui être associées.


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.


Clé

Définition La clé d’une table est un sous-ensemble d'attributs qui détermine tous les autres attributs. Ce sous-ensemble est tel que tous les attributs sont nécessaires pour former la clé. Soit R une relation n-aire : R(A1, A2, …, An) Soit l’ensemble d’attributs {Ai..Ak} avec {i, .., k} ∈ [1 :n] Soit f la fonction entre R et Di x … x Dk. f : R → Di x… x Dk L’ensemble d’attributs {Ai..Ak} est une clé de R si et seulement si :

∀x, y ∈ R, x != y ⇒ f(x) != f(y)

Obligation de la clé Toute relation possède au moins une clé. Donc, il n’y a jamais de doublons dans une relation.

Clé irréductible Déf. (clé irréductible) : une clé C sur R est dite irréductible si et seulement si pour tout autre ensemble d’attributs D ⊂ C, D n’est pas une clé.

Clé minimale Déf. (clé minimale) : une clé C sur R est dite minimale s’il n’existe aucune autre clé sur R impliquant un moins grand nombre d'attributs.

Clé candidate Déf. (clé candidate) : toute clé de taille minimale est une clé candidate.

Clé primaire Déf. (clé primaire) : la clé unique choisie par le concepteur de la base parmi les clés candidates est clé primaire.

Clé étrangère Déf. (clé étrangère) : une clé étrangère est un attribut qui fait référence à un attribut clé primaire.


Dépendance fonctionnelle Un attribut Y (ou premier groupe d’attributs) dépend fonctionnellement d’un attribut X (ou second groupe d’attributs), si étant donné une valeur de X, il lui correspond une valeur unique de Y (et ceci quel que soit l’instant considéré). On dit que X détermine fonctionnellement Y et on note :

X - > Y Concrètement, les clés d’une relation déterminent fonctionnellement tous les autres attributs de la relation.

Expression ultra-schématique d’un schéma

Principes L’expression ultra-schématique distingue uniquement les attributs clés primaires, les attributs clés étrangères et les attributs non clés. Cette représentation permet de se focaliser sur la question des liens entre les tables. Son intérêt se justifiera dans des modèles complexes.

La BD des employés De façon ultra-schématique, les tables EMP et DEPT peuvent s’écrire ainsi : E (E, Ex, #D) D (D, Dx) E, c’est le nom de la table Emp (initial de Emp). E : c’est la clé primaire de la table E Ex : ce sont les attributs de la table E #D : c’est une clé étrangère qui ramène sur la clé primaire D D, c’est le nom de la table Dept (initial de Dept) D : c’est la clé primaire de la table D Dx : ce sont les attributs de la table D

La BD de la bibliothèque A (A, Ax) O (O, Ox) L (L, Lx, #NO) E (#L, datemp, Ex, #A)


MODELE RELATIONNEL VALORISE –

CONTRAINTES D’INTEGRITE

1. Contraintes d’intégrité des données

Présentation Dès que le nombre de données est important, il y a des risques d’incohérence, c’est-à-dire de contradiction : • Duplication des données avec des valeurs différentes. Exemple : deux adresses différentes

pour une même personne. • 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 plus. La BD a pour objectif d’être un réservoir d’informations unique et commun : « canonique », garantie sans incohérence (donc sans duplication de données). Les contraintes d’intégrité sont des caractéristiques d’un système d’information (d’une base de données) qui permettent de garantir l’intégrité des données.

Les 11 contraintes de base sur un attribut Il y a 11 types de contraintes qu’on peut préciser.

1 : Nom de code On a donné un nom à l’attribut. Il va falloir leur donner un nom de code qui sera utilisé dans la programmation. Dans une même table, deux attributs ne peuvent pas avoir le même nom. Par contre, deux attributs de deux tables différents peuvent avoir le même nom.

2 : Type Entier, réel, booléen, date, caractère, chaîne de caractère, texte, image, etc.

3 : Énuméré (valeurs possibles en extension) C’est une espèce de type. Il précise la liste des valeurs possibles pour un attribut. La liste de valeur peut être fixe, ou bien modifiable, ou encore calculée à partir de ce qu’on trouve dans la base de donnée.

Ø SQL : check, trigger

4 : Limites et contraintes de valeurs (valeurs possibles en intension) Cette contrainte sur le type qui précise la liste des valeurs possibles pour un attribut en intension. Par exemple, des bornes inférieures et supérieures. Ces bornes peuvent être fixes, ou bien fonction de la valeur d’autres attributs (attribut 1 < attribut2 ; ou bien attribut 1 < moy (attribut2) ; etc.) On peut aussi préciser une valeur par défaut conditionnelle. Par exemple : si attribut 1=NULL, alors attribut 2=NULL.

Ø SQL : check, trigger


5 : Clé primaire Un attribut clé primaire est tel que la valeur est toujours renseignée (elle est obligatoire) et qu’elle est différente pour tous les éléments de la table (elle est unique).

Ø SQL : PRIMARY KEY

6 : Obligatoire Un attribut obligatoire possède nécessairement une valeur. On dit aussi « not NULL ». Il faut distinguer entre la valeur « 0 » : c’est une possibilité de valeur entière ou réelle parmi les autres, et la valeur NULL. La valeur NULL signifie que la valeur n’est pas renseignée. Par défaut un attribut n’est pas obligatoire.

Ø SQL : Not NULL

7 : Unicité Un attribut unique est telle que sa valeur est différente pour tous les éléments de la table (elle est unique). Cette unicité ne concerne pas la valeur NULL : un attribut peut être unique mais non obligatoire. Les clés primaires et secondaires sont uniques et obligatoires. Par défaut, un attribut n’est pas unique.

Ø SQL : UNIQUE

8 : Valeur par défaut La valeur par défaut est une valeur donnée par défaut si aucune valeur n’est donnée. Toutefois, on peut saisir une autre valeur et aussi la valeur NULL. La valeur par défaut peut être une constante ou être une valeur calculée. Si c’est une valeur calculée, diffère de l’attribut calculé car elle n’est calculée qu’à la création du tuple et ne sera plus mise à jour automatiquement ensuite. Par exemple, un attribut « date de création » peut recevoir automatiquement la date du jour au moment de la création. Un attribut clé primaire peut recevoir automatiquement une valeur grâce à un auto-incrément. Les attributs avec valeur par défaut peuvent être saisissable ou pas (un auto-incrément ou une date de création sont plutôt non saisissables).

Ø SQL : DEFAULT, auto_increment, date de création, date de modification, trigger

9 : Calculé Un attribut calculé est un attribut dont la valeur est calculée à partir d’informations qui sont dans la base de données. C’est donc un attribut qui duplique l’information. En général, les attributs calculés sont non-saisissables, mais ce n’est pas obligatoire.

Ø SQL : trigger, vue

10 : Non saisissable Un attribut non saisissable est un attribut qui ne peut pas être saisi. Donc soit il a une valeur par défaut, soit il est calculé.

Ø SQL : trigger, gestion des droits, vue


11 : Non Modifiable, Modifiable, Fixe Une valeur d’attribut peut toujours être modifiée dans la base de données. Mais du point de vue du SI, un attribut peut être naturellement modifiable (mon salaire), plutôt fixe (mon nom), plutôt non modifiable (la date de saisie ou l’identifiant). Le terme « plutôt » montre que c’est relatif et pas absolu.


Les contraintes d’intégrité référentielle

Notion de clé étrangère Un attribut clé étrangère est un attribut qui fait référence à un attribut clé primaire. Les clés étrangères donnent lieu à des contraintes particulières : les contraintes d’intégrité référentielle. La contrainte d’intégrité référentielle consiste à vérifier que la clé primaire référencée existe, que ce soit au niveau de la table ou au niveau des tuples.

Syntaxe SQL

Ø FOREIGN KEY

Contrainte d’intégrité référentielle pour les tables

Contrainte sur la création des tables On ne peut pas créer une table qui contient un attribut clé étrangère si la clé primaire référencée n’a pas déjà été créée. Donc on doit d’abord créer les tables qui n’ont pas de clés étrangères. Ensuite on crée les tables avec des clés étrangères. Par exemple : on ne peut pas créer la table des employés qui fait référence à la table des départements si la table des départements n’a pas déjà été créée. On peut aussi créer toutes les tables, dans n’importe quel ordre, sans préciser quelles sont les clés étrangères (CREATE TABLE). Après la création, on modifie les tables en ajoutant les clés étrangères (ALTER TABLE).

Contrainte sur la suppression des tables On ne peut pas supprimer une table dont la clé primaire est clé étrangère dans une autre table. Il faut commencer par détruire les tables qui ne sont référencées par aucunes autres tables. Par exemple : il faut commencer par détruire les tables des employés, ensuite on peut détruire la table des départements. On peut aussi supprimer toutes les clés étrangères dans n’importe quel ordre (ALTER TABLE), et ensuite supprimer les tables dans n’importe quel ordre (DROP TABLE).

Contrainte sur la modification des tables On ne peut pas modifier le nom d’un attribut dans une table s’il est référencé par un autre attribut.

Contrainte d’intégrité référentielle pour les tuples

Contrainte sur la création des tuples On ne peut pas créer un tuple qui contient un attribut clé étrangère si la clé primaire référencée n’a pas déjà été créée. Par exemple : on ne peut pas créer un employé dans le département 10 si le département 10 n’existe pas.

Contrainte sur la suppression des tuples


On ne peut pas détruire un tuple s’il est référencé par un autre tuple. Par exemple : on ne peut pas détruire le département 10 si des employés travaillent dans le département 10.

Ø Paramétrage des contraintes d’intégrité référentielle en suppression On vient de voir la situation par défaut. Il y a deux autres possibilités : • ON DELETE CASCADE : si on veut détruire un tuple référencé par un ou plusieurs autres

tuples, alors on détruit aussi ce ou ces autres tuples. Cette caractéristique s’applique à l’attribut clé étrangère.

• ON DELETE SET NULL : si on veut détruire un tuple référencé par un ou plusieurs autres tuples, alors on passe la référence au tuple détruit de ce ou ces autres tuples à NULL. Cette caractéristique s’applique à l’attribut clé étrangère.

Par exemple : si on veut détruire le département 10, alors on détruit tous les employés qui travaillent dans le département 10, ou alors on passe le ND des employés du département 10 à NULL.

Contrainte sur la modification des tuples On ne peut pas modifier la valeur d’un attribut d’un tuple si cette valeur est référencée par un autre tuple. Par exemple : on ne peut pas modifier la valeur 10 du département 10 (en la passant à 11 par exemple) si des employés travaillent dans le département 10.

Ø Paramétrage des contraintes d’intégrité référentielle en modification On vient de voir la situation par défaut. Il y a deux autres possibilités : • ON UPDATE CASCADE : si on veut modifier un tuple référencé par un ou plusieurs autres

tuples, alors on modifie la référence au tuple modifié de ce ou ces autres tuples. Cette caractéristique s’applique à l’attribut clé étrangère.

• ON UPDATE SET NULL : si on veut modifier un tuple référencé par un ou plusieurs autres tuples, alors on passe la référence au tuple détruit de ce ou ces autres tuples à NULL. Cette caractéristique s’applique à l’attribut clé étrangère.

On peut concevoir une 3ème possibilité : • ON UPDATE « DELETE CASCADE » : si on veut modifier un tuple référencé par un ou

plusieurs autres tuples, alors on alors on détruit ce ou ces autres tuples.. Cette caractéristique s’applique à l’attribut clé étrangère.

Par exemple : si on veut modifier la valeur 10 le département 10 et la faire passer à 11, alors on modifie aussi le numéro de département de tous les employés qui travaillent dans le département 10 en les faisant passer à 11.


2. Cycle de vie des tuples

Présentation Dans une base de données, les tuples ont un cycle de vie déterminé. Ils peuvent être créés, modifiés, supprimés. Quand ils sont créés ou modifiés, tous les attributs ne sont pas nécessairement concernés.

Les différents cas

Création (insert into) et contrainte obligatoire Un attribut peut être : • Obligatoire NOT NULL ou pas

La situation par défaut d’un attribut est d’être obligatoire (elle correspond à une « forme normale 1 » stricte).

Modification (update) Un attribut peut être : • Normalement non modifiable : la date d’embauche d’un employé. Sa valeur est définitive. • Normalement modifiable : le salaire d’un employé. • Plutôt fixe : le nom d’un employé. La situation par défaut d’un attribut est d’être non modifiable. Il peut être obligatoire et non modifiable et aussi non-obligatoire et non-modifiable : dans ce cas, cela veut dire qu’il peut commencer par valoir NULL (être non renseigné), mais que quand on le renseignera, ce sera définitif. Si tous les attributs d’un tuple sont non modifiables, alors c’est le tuple lui-même qui est non-modifiable. Les modifications sont des historiques qui se traduisent par un ajout de tuple.

Suppression (delete) Le tuple peut être entièrement supprimé. C’est finalement assez rare. On a plutôt tendance à tout conserver pour garder des historiques qui permettent ensuite de faire de l’analyse de données et du « data mining ».

Archivage Le tuple peut être archivé. Cela signifie qu’il est détruit dans la BD courante mais conservé dans une archive. Les données archivées ne sont pas modiables.


3. Cycle de vie et analyse fonctionnelle

Présentation L’analyse fonctionnelle, c’est l’analyse des usages du système qui va utiliser la BD. Le cycle de vie des tuples est lié à l’analyse fonctionnelle. En réfléchissant au cycle de vie des tuples, on met au jour l’usage du SI.

Elément d’analyse Il faut essentiellement mettre au jour les caractéristiques suivantes : NULL possible (pas obligatoire) : ∅ Normalement modifiable : M

Exemples

Les employés et les départements

Ø Présentation EMPLOYES(NE, nom, job, datemb, sal, comm., #ND, *NEchef) DEPARTEMENTS (ND, nom, ville) Valoriser le modèle consiste pour chaque attribut à réfléchir aux caractères obligatoire, unique et modifiable ainsi qu’aux valeurs par défaut. • Tout les attributs sont obligatoires (c’est la situation par défaut) sauf « comm ». • Job, Sal, Comm, #ND, *NEchef, sont normalement modifiables. • Nom d’employé, nom de département, et ville sont exceptionnellement modifiable. • NE, datemb sont non mofiables. • Aucun attribut n’est unique en dehors des clés primaires. • Il n’y a pas de valeurs par défaut.

Ø Modèle valorisé EMPLOYES(NE, nom, job, datemb, sal, comm., #ND, *NEchef) M M ∅M M M DEPARTEMENTS (ND, nom, ville)

Ø Usages du système 1. Saisie d’un employé 2. Modification d’un employé 3. Modification exceptionnelle d’un employé 4. Saisie d’un département 5. Modification exceptionnelle d’un département


La bibliothèque

Ø Modèle valorisé ADHERENTS (NA, nom, prenom, adr, tel) M ∅M OEUVRES (NO, titre, auteur) LIVRES (NL, editeur, #NO) EMPRUNTER(#NL, datemp, dureeMax, datret, #NA) today ∅

Ø Usages du système 1. Saisie d’un adhérent 2. Modification de l’adresse et du tél d’un adhérent 3. Saisie d’une aoeuvre 4. Saisie d’un livre 5. Saisie d’un emprunt (avec datemp = date du jour par défaut) 6. Modification d’un emprunt = saisie d’un retour


4. Dictionnaire des attributs

Présentation Le dictionnaire des attributs regroupe tous les attributs dans un tableau. On sépare les groupes d’attributs par table. On met la clé primaire en premier et la ou les clés étrangères en dernier. Le tableau précise en plus les contraintes de valeurs pour tous les attributs.

Exemple 1

N° Désignation Code Type Obligé Uniq. Val déf Saisi Modif Enum Limites Calculé # 1 Numéro d'adhérent NA E Oui Oui Auto++ Non Non 2 Nom de l'adhérent Nom A 20 Oui 3 Adresse de l'adhérent Adr A 40

4 Numéro de livre NL E Oui Oui Auto++ Non Non 5 Editeur Editeur A 20 6 Numéro d’œuvre NO E Oui 7

7 Numéro d’œuvre NO E Oui Oui Auto++ Non Non 8 Titre du livre Titre A 20 Oui 9 Auteur du livre Auteur A 20

7 Numéro de livre NL E Oui Non 4 8 Date d'emprunt Datemp D Oui today Non Non 9 Date de retour Datret D today Non Non 10 Numéro d'adhérent NA E Oui Non 1

Valeurs par défaut Auto-incrément pur NA, NL, NO Date du jour pour datemp et datret

Saisissable Les clés primaires auto-incrémentées seront non saisissables. Datemp et Datret sont non saisissables

Modifiable Les clés primaires sont non modifiables. Dateret et le NA des Emprunts sont non modifiables aussi : quand on fait un emprunt, NL, datemp et NA sont renseignés et ne sont pas modifiables. Quand on ramène le livre, datret est renseigné et n’est pas modifiable. Finalement, tous les attributs de la table des emprunts sont non modifiables.


Exemple 2

N° Désignation Code Type Obligé Uniq. Val déf Saisi Modif Enum Limites Calculé #

1 N° de l'employé NE E Oui Oui Auto++ Non Non 2 Nom de l'employé Ename A 10 Oui 3 Fonction de l'employé Job A 9 Oui 4 Date d'embauche Hiredate D Oui Non 5 Salaire Sal R Oui > 0 6 Commission Comm. R >= 0 7 Chef NEChef E 1 8 N° de départemt Deptno E Oui 9

9 N° de départemt ND E Oui Oui Auto++ Non Non 10 Nom du département Dname A 14 11 Localité du départemt Loc A 13

Valeurs par défaut Auto-incrément pur NE, ND

Saisissable Les clés primaires auto-incrémentées seront non saisissables.

Modifiable Les clés primaires sont non modifiables. La date d’embauche est non modifiable.

Enuméré Fonction : 'SALESMAN', 'MANAGER', 'PRESIDENT'.

Calculé Pas d’attribut calculé.


5. Jeu de tests

Présentation Le jeu de tests est un ensemble de tuples qui permet de tester la base de données. Il doit être construit judicieusement. En effet, il ne faut pas oublier qu’une requête peut sembler donner de bons résultats sur un jeu de tests et mais pas sur un autre. Le jeu de tests doit être choisi judicieusement pour permettre de bien tester les requêtes.

Trucs pour bien construire son jeu de tests

Nombre de tuples Pour bien construire son jeu de tests, il faut mettre au minimum 3 tuples par tables-nom et 6 tuples par tables-verbe. On est amené à grossir le nombre de tuples en appliquant les règles suivantes.

Les clés primaires simples On peut numéroter les clés primaires de 1 à N.

Les clés étrangères Pour bien construire son jeu de tests, il faut surtout faire attention aux clés étrangères. • Les clés étrangères doivent correctement faire référence aux clés primaires. • Si une clé étrangère peut avoir des doublons, le jeu de test doit le montrer. • Si une clé étrangère peut valoir NULL, le jeu de test doit le montrer. • Si une clé primaire doit forcément être référencée par une clé étrangère, le jeu de tests doit le

montrer. • Si une clé primaire peut ne pas être référencée par une clé étrangère, le jeu de tests doit le

montrer.

Les dates Pour bien construire son jeu de tests, il faut faire attention aux attributs date.

Les autres attributs. Pour bien construire son jeu de tests, il faut faire attention à mettre des doublons dès que cela semble judicieux, et mettre des valeurs NULL dès que c’est possible. On n’est pas obligé de mettre des « vrais valeurs » : on peut mettre des codes : n1, n2, n3 pour des noms, ad1, ad2, ad3 pour des adresses, etc.


TD : EXERCICES DE MODELISATION RELATIONNELLE

1 Association et donateurs Une association reçoit des dons de donateurs privés. Pour chaque don, l’association enregistre la date du don, son montant ainsi que le nom et l’adresse du donateur, le téléphone et l’adresse mail si possible. Les dons ont un numéro identifiant qui les distingue les uns des autres. Vers le mois de février, l’association envoie des reçus fiscaux aux donateurs de l’année. Les reçus fiscaux concernent les dons de l’année précédente. Ils précisent le nom et l’adresse du donateur, l’année fiscale (qui correspond à l’année du don), le montant et la date du don. Si un même donateur fait plusieurs dons dans l’année, il reçoit un unique reçu fiscal qui précise le montant et la date de chaque don ainsi que le nombre de dons et la somme des dons. On enregistre pour chaque don la date d’envoi du reçu fiscal. A noter que certains donateurs demandent leur reçu avant la date d’envoi officiel. Dans ce cas, on leur envoi leur reçu et on enregistre la date de reçu. L’association envoie des courriers par mail ou par voie postale aux donateurs pour leur demander d’envoyer un don. Un courrier est caractérisé par un code d’identification, un libellé (un titre) et une date d’envoi. Il contient un formulaire pour renvoyer les dons. Le formulaire demande les informations de la personne et le montant du don. Il précise le code d’identification du courrier. Le courrier contient aussi une brochure publicitaire. L’association garde la trace de tous les courriers envoyés pour pouvoir faire des statistiques. L’envoi des reçus fiscaux est traité comme un envoi de courrier : avec le reçu fiscal, on envoie un formulaire pour renvoyer un don. Les courriers envoyés reviennent parfois avec la mention NPAI : N’habite pas à l’adresse indiquée. L’information est enregistrée pour éviter de réécrire à cette adresse. Toutefois, on conserve la dernière adresse connue du donateur. Les mails envoyés reviennent parfois en « Undelivered mail ». Dans ce cas, l’adresse mail de la personne est supprimée. Quand l’association reçoit un don avec un formulaire, elle peut savoir de quel courrier provient le don. Cette information est enregistrée avec le don. Ainsi, pour chaque courrier, on connaît le montant total des dons qui s’y rapporte.

Travail à partir d’un jeu de données

Présentation Dans un fichier excel, on trouve plusieurs onglets Onglet « Chèques et formulaires » : contient les informations des chèques reçus et les informations des formulaires qui accompagnaient les chèques, quand il y en avait un. Contient aussi un « id » de personne, pour chaque chèque reçu. Cette table excel est l’équivalent d’une pile de chèques accompagnés ou pas de formulaires. Onglet « Contact » : contient une liste de personnes ont été sollicitées pour envoyer des dons mais qui n’en n’ont pas répondu. Ces personnes ont un « id ».


Onglet « Courrier » : contient les informations des 3 courriers envoyés par l’association. Les formulaire sont des coupons papier au format A4/3 à remplir par le donateur. Le ou les documents associés au courrier c’est la brochure publicitaire qu’on envoie. Onglets « listes » : contiennent la liste des personnes à qui l’association a envoyé chacun des 3 courriers. Qaund c’est un courrier par mail, on a l’adresse mail. Quand c’est un courrier postal, on a l’adresse postale. Onglet « Retour de mail » : contient les adresses mail revenu comme « undeliverd mail » Onglet « NPAI » : contient les informations des personnes dont l’adresse postale n’est plus valable

Objectif de l’exercice Vous devez remplir des tableaux excel de type « lignes-colonnes » permettant de ranger l’information manipulées en évitant les duplications.

Etapes du travail Consolidez d’abord un tableau de personnes. Ensuite, faites un tableau de dons. Et finalisez avec toutes les autres informations !

Passage à une BD MySQL Vous pouvez importer les données des tables excel dans une BD MySQL en passant par un format CSV et en faisant une importation (avec phpMyAdmin de WAMP ou MAMP par exemple). Afficher les donateurs avec leur nombre de dons et le montant total des dons qu’ils ont effectués. Vous pouvez ensuite mettre à jour le type des champs et toutes les contraintes d’intégrité Vous pouvez enfin exporter le code de création de la BD (dump de la BD).

Modélisation à réaliser sans jeu de données 1. Faire le schéma de la BD correspondant au MR Brut 2. Faire le graphe des tables correspondant. 3. Pour chaque table, préciser le type de la clé primaire et la sémantique de la table (ontologie

relationnelle). 4. Mettre des tuples dans vos tables. 5. Valoriser le modèle (obligatoire, unique, modifiable, valeur par défaut) 6. Quels attributs calculés peut-on envisager ?

2 La cinémathèque Une cinémathèque veut mettre en place un système d’information concernant des films et leurs diffusions. Pour chaque film on connaît son titre, sa date de création, ses acteurs avec leur nom, leur prénom et leur nationalité, les réalisateurs avec les mêmes informations, la langue du film. On connaît aussi les salles dans lesquelles il a été projeté, avec l’heure et le jour de la projection, la version projetée (version originale ou version française). On connaît le nombre de places des salles, le type d’écran et le type de son, ainsi que le cinéma correspondant, avec son nom, son


adresse, son téléphone et le nombre de salles du cinéma. On veut pouvoir faire un classement du plus grand nombre d’entrées par film. 1. Faire le schéma de la BD correspondant au MR Brut 2. Faire le graphe des tables correspondant. 3. Pour chaque table, préciser le type de la clé primaire et la sémantique de la table (ontologie



3 La maison de disques Une maison de disques gère des disques. Un disque contient des chansons. On connaît le nombre des chansons du disque. On connaît aussi sa durée. Les chansons ont un numéro sur le disque. Les chansons ont un titre et une durée. Pour chaque chanson, on connait la liste des musiciens qui y participent ainsi que le nom du ou des chanteurs, le nom du ou des auteurs et le nom du ou des compositeurs. Pour chaque personne, on connait son nom et sa nationalité. 1. Faire le schéma de la BD correspondant au MR Brut 2. Faire le graphe des tables correspondant. 3. Pour chaque table, préciser le type de la clé primaire et la sémantique de la table (ontologie


4 Les chantiers d’été Une association organise des chantiers d’été. Il y en a de 3 sortes : chantiers de réhabilitation, chantiers de construction ou chantiers archéologiques. Pour les chantiers de construction et de réhabilitation, on connaît le type de bâtiment. Pour les chantiers de réhabilitation, on connaît la date de création de l’ancien bâtiment et des informations sur l’ancien bâtiment. Pour les chantiers archéologiques, on connaît la période archéologique et la surface du chantier (qui peut être très grande). Les chantiers ont une date de début et une date de fin (qui peut être plusieurs années après la date de fin). Des équipes viennent sur le chantier. Une équipe est constituée pour une durée limitée (environ un mois pendant l’été). Elle est affectée à un chantier et un seul. Les équipes sont constituées de participants. Les participants aux chantiers sont des personnes. Leur participation à l’équipe peut être inférieure à la durée de vie de l’équipe elle-même. Les personnes ont un nom, un prénom, une adresse, un email et un téléphone. L’association peut recevoir des dons de personnes. Les dons ont un montant et une date de don. Ils sont fait par une personne. Ils donnent lieu à un reçu fiscal envoyé à une certaine date. L’association envoie des courriers aux personnes. Les courriers ont un titre, une date et un libellé. L’association gère aussi des membres. Les membres payent des cotisations annuelles. Les cotisations ne donnent pas lieu à un reçu fiscal. On distingue donc deux types de dons : ceux avec reçu et les cotisations. Les membres de l’association peuvent participer au conseil d’administration (CA). Le CA est renouvelé en général tous les ans. Les participants au CA ont une fonction particulière. Cette fonction peut changer en cours de CA. On conserve les dates de début et de fin de chaque fonction occupée. Chaque CA a un certain nombre de participants. 1. Faire le schéma de la BD correspondant au MR Brut 2. Faire le graphe des tables correspondant. 3. Pour chaque table, préciser le type de la clé primaire et la sémantique de la table (ontologie

relationnelle). 4. Mettre des tuples dans vos tables.


5. Valoriser le modèle (obligatoire, unique, modifiable, valeur par défaut) 6. Quels attributs calculés peut-on envisager ?

5 Les employés et leurs carrières On souhaite gérer le personnel d'une société. Chaque membre du personnel a un nom, une fonction, un salaire, une commission (part de salaire variable), un salaire totale (salaire + commission), une date d'entrée dans la société. Chaque membre du personnel travaille dans un département caractérisé par son nom (commercial, production, personnel, comptable et recherche) et la ville dans laquelle il se trouve. 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. A cette situation, qui donne lieu au schéma de la BD abordé en cours, on ajoute les éléments suivants : Le service des Ressources Humaines veut gérer la carrière des employés. Pour chaque employé, on considère chaque modification de salaire, chaque changement de poste, chaque changement de supérieur hiérarchique et chaque changement de département comme une étape dans sa carrière. L’historique des commissions n’est, par contre, pas gardé. 1. Faire le schéma de la BD correspondant au MR Brut 2. Faire le graphe des tables correspondant. 3. Pour chaque table, préciser le type de la clé primaire et la sémantique de la table (ontologie


6. Gestion de projet On modélise l’organisation des projets en tâches dans une entreprise. Un projet est caractérisé par un nom, une date début, une date de fin et un identifiant unique. Un projet est constitué de plusieurs tâches numérotées de 1 à N. Chaque tâche a un intitulé, une date de début et une date de fin. Elle est précédée par 0 ou plusieurs tâches. Elle est suivie par 0 ou plusieurs tâches. Deux tâches d’un même projet peuvent démarrer à la même date. Deux tâches d’un même projet peuvent se terminer à la même date. Une tâche démarre au plus tôt le lendemain de la fin de la tâche qu’elle suit. Une tâche ne peut pas commencer avant le début du projet, ni finir après la fin du projet. Dans l’entreprise, les membres du personnel ont un nom, une fonction et un identifiant. A chaque projet, on affecte des membres du personnel avec une fonction spécifique pour chaque projet. Ensuite, on affecte les membres du projet à des tâches du projet. Chaque tâche peut requérir des ressources spécifiques. L’allocation d’une ressource par une tâche se fait à partir d’un certain jour et pour une certaine durée. Une ressource peut être allouée plusieurs fois par une même tâche à des périodes différentes. Une ressource a un intitulé et coût journalier.


1. Faire le schéma de la BD correspondant au MR Brut 2. Faire le graphe des tables correspondant. 3. Pour chaque table, préciser le type de la clé primaire et la sémantique de la table (ontologie


7. ASSURAUTO On souhaite construire un MR destiné à la gestion de sinistres pour la compagnie d’assurance-automobile. ASSURAUTO à partir de la lettre de demande d’expertise envoyée par un de ses agents d’assurance. Voici la lettre :

A Paris, le 10 juin 2009 De la part de M. Pierre Durand, Agent d’assurance ASSURAUTO 10, rue Saint-Antoine, 75001 Paris tél : 01 42 42 24 24

A M. Henri Dupond Expert en assurance

Monsieur, Je vous saisis par le présent courrier pour vous demander de suivre le dossier du sinistre SIS20020934 constitué à ce jour suite à l’accident survenu le 02 juin 2005 au croisement de la rue de Rivoli et de la rue du Renard à Paris 1er arrondissement, à 11 heures du soir, par temps de pluie, d’où l’état glissant de la chaussée à ce moment-là. M. André Danlemur est un des protagonistes de l’accident. Il a souscrit chez nous, depuis le 17 décembre 2002, un contrat enregistré sous le n° CTR2002120 et de type tout risque sur le véhicule impliqué dans le sinistre et immatriculé 123 ABC 75. Ce véhicule est une Renault Espace de 100 chevaux. M. Oliveau habite à Paris, 25 rue de Rivoli, dans le 1er arrondissement. Il est joignable au 01 42 23 12 20 chez lui, ou au 06 12 12 12 12 sur son portable, ou au 01 23 43 23 34 à son travail. Vous voudrez bien prendre contact avec lui pour convenir d’un rendez-vous en vue de l’expertise que vous voudrez bien effectuer au garage « Saroul », 45, rue Rousseau, 75002 Paris, dans un délai de 15 jours. Dans l’attente de votre rapport d’expertise, nous vous prions de croire, Monsieur l’expert, à nos sentiments distingués.

M. Durant, Agent d’assurance

On ajoute les spécifications suivantes : un accident est expertisé une ou plusieurs fois. En cas de ré-expertise, on change forcément d’expert. Un accident est suivi par l’agent responsable du contrat. Pour un accident, on enregistre aussi, si nécessaire, la liste de tous les véhicules impliqués un accident concerne donc des véhicules assurés ou pas par ASSURAUTO. Le contrat d’assurance est passé par un client et un seul et concerne une voiture et une seule.


1. Faire le schéma de la BD correspondant au MR Brut 2. Faire le graphe des tables correspondant. 3. Pour chaque table, préciser le type de la clé primaire et la sémantique de la table (ontologie


Modélisation Cours 01 – Modèle Relationnel brut et valorisé...

Documents

Transcript of Modélisation Cours 01 – Modèle Relationnel brut et valorisé...