Modélisation de bases de données
-
Modèle Relationnel -
Modèle Sagittal-MEA-UML -
2 : Modélisation avancée :
ontologie relationnelle
Modélisation de bases de données
Le modèle relationnel
Ontologie relationnelle : typologie des clés primaires
Ontologie relationnelle
Tous les types de clés primaires
•
On a vu dans les bases de la modélisation deux types de clés primaires :
➡
La clé primaire simple caractérisant les entités ayant une réalité matérielle : les employés, les lions, les gazelles, etc.
➡
Les clés primaires concaténées constituées de clés étrangères comme #idLion, #idBuffle. Ces clés caractérisent une association entre deux entités.
•
Les exercices ont fait apparaître d’autres formes de clé primaires.
•
Le but de cette présentation est de présenter tous les types de clés primaires ainsi que leur signification « ontologique » (ce qu’elles
représentent comme réalité). C’est ce que recouvre la notion d’ « ontologie relationnelle »
•
La présentation montre le formalisme correspondant, qu’il soit relationnel
(MR) mais aussi « sagittal » (MEA et UML).
Table d’objets
MR : * EMPLOYE (NE, nom, fonction, salaire, #ND)
• DEPARTEMENT (ND, nom, ville)
• 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, les lions, les buffles. 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 P.O.O).
MEA :
UML :
Ontologie relationnelle Clé primaire simple
1 - les « tables d’objets » et les « tables de types »
Table de types
MR : * AVION (NA, année, couleur, propriétaire, #typeAvion)
• TypeAvion(typeAvion, nombre places, année, moteur)
Une table avec une clé primaire simple peut aussi correspondre à une
table de types de réalités physiques. C’est le cas des « TypeAvion », parexemple, le A320. Dans ce cas, un avion est une « instance » d’un type d’avion particulier.
MEA :
UML :
Ontologie relationnelle Clé primaire simple
1 - les « tables d’objets » et les « tables de types »
Table de liaison -> Exemple 1 : des employés sur des projets MR : * Employé (NE, nom, dateEmbauche)
• Projet (NP, intitulé, dateDébut, dateFin, budget)
• Participer (#NE, #NP) MEA :
UML :
Principes
• La clé primaire d’une table de liaison comporte plusieurs attributs dont au moins une clé étrangère, le plus souvent 2 clés étrangères.
• Il peut y avoir des attributs en plus de la clé primaire.
• 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.
Ontologie relationnelle
Clé primaire concaténée avec plusieurs des clés étrangères
5 : les « tables de liaisons »
Table de liaison -> Exemple 2 : l’employé joue un rôle unique sur le projet.
MR :
• Participer (#NE, #NP, rôle)
• Le couple NE-NP définit la participation.
• Le rôle est un attribut pour ce couple.
MEA :
UML :
Ontologie relationnelle
Clé primaire concaténée avec plusieurs clés étrangères
5 : les « tables de liaisons »
Table de liaison -> exemple 3 : l’employé joue plusieurs rôles sur le projet et pour chaque rôle joué on définit le nombre de jours d’activité.
MR :
• Participer (#NE, #NP, rôle, durée)
• Désormais, c’est le triplet NR-NP-rôle qui définit la participation.
• Le rôle n’est pas une clé étrangère, mais c’est un attribut énuméré qu’on pourrait transformer en clé étrangère en créant la table correspondante (cf. évolution et valorisation de la modélisation).
• La durée est un attribut pour ce triplet.
MEA :
• Le MEA ne permet pas de montrer que le rôle participe à la clé primaire.
UML : comme l’exemple 2 avec la durée en plus
Ontologie relationnelle
Clé primaire concaténée avec plusieurs clés étrangères
5 : les « tables de liaisons »
Table de liaison -> exemple 4 : un rôle est associé à une description du rôle MR :
• Participer (#NE, #NP, #rôle, durée)
• Désormais, c’est toujours triplet NR-NP-rôle qui définit la participation.
• Le rôle est une clé étrangère, forcément puisqu’on a l’attribut « descriptifRole » qui est associé au rôle.
• La durée est un attribut pour le triplet.
MEA :
Ontologie relationnelle
Clé primaire concaténée avec plusieurs clés étrangères
5 : les « tables de liaisons »
Table de liaison -> exemple 4 : un rôle est associé à une description du rôle UML :
UML, version sans l’attribut durée :
Ontologie relationnelle
Clé primaire concaténée avec plusieurs clés étrangères
5 : les « tables de liaisons »
Table de composant -> exemple : des projets et leurs étapes MR :
• On gère des projets. Chaque projets est constitué d’étapes qui sont numérotées.
• Projets (NP, nom, début, fin, budget)
• Etapes (#NP, NE, nom, début, fin, budget) Principes : identifiant relatif
• Le numéro d’étape (NE) est un identifiant relatif. Le numéro d’étape est relatif à son projet : il y a plusieurs étapes numéro 1 : 1 par projet ! C’est le couple «NP, NE » qui est unique.
• L’étape est un composant du projet : il 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.
MR graphique :
Ontologie relationnelle
Clé primaire concaténée avec un identifiant relatif
3 : les « tables de composants »
Table de composants : MEA :
• On a une association 1 à plusieurs. Le (1.1) est parenthèsé.
• (1.1) veut dire que la clé primaire de l’entité côté N rentre en clé étrangère ET primaire dans la table issue de l’entité 1.
• Il n’y a pas de numéro absolu d’étape mais un identifiant relatif, relatif à son numéro de rojet.
• L’étape est un composant du projet.
UML :
• Le losange noir signifie la relation de composition. Les cardinalités par défaut sont 1.1 du côté du losange noir, et * (1,n ou 0,n) de l’autre côté.
Ontologie relationnelle
Clé primaire concaténée avec un identifiant relatif
3 : les « tables de composants »
Table d’historique -> exemple 1 : Historique issu une association plusieurs à plusieurs MR :
• Dans une bibliothèque, les adhérents empruntent des livres :
• ADHERENT (NA, nom, prenom, adresse, CP, ville, email, tel)
• LIVRE (NL, titre, auteur, éditeur)
• Un livre est emprunté par un adhérent à une certaine date. Une durée maximum d’emprunt est prévu.
Quand l’adhérent rendra son livre, on enregistrera la date de retour.
• EMPRUNTER (#NL, #NA, dateEmprunt, dateRetour, dureeMaxDEmprunt)
• Quelle est la clé primaire de EMPRUNTER ?
• Règle de modélisation : 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 trouver la clé primaire :
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.
• Résultat :
• EMPRUNTER (#NL, dateEmprunt, dateRetour, dureeMaxDEmprunt, #NA)
Ontologie relationnelle
Clé primaire concaténée avec une date
4 : les « tables d’historiques »
Bilan de la bibliothèque : MR :
• ADHERENT (NA, nom, adresse, CP, ville, email)
• LIVRE (NL, titre, auteur, éditeur)
• EMPRUNTER (#NL, dateEmprunt, dateRetour, dureeMaxDEmprunt, #NA)
• La table EMPRUNTER est un historique de #NL, donc un historique des livres. Elle enregistre les événements qui arrivent aux livres : les emprunts et les retours.
• On peut aussi parler de table de liaison historique puisque deux tables sont reliées par EMPRUNTER
MEA :
• Le MEA et l’UML ne permettent pas de montrer que la date d’emprunt participe à la clé primaire et que NL n’en fait plus partie.
UML :
Ontologie relationnelle
Clé primaire concaténée avec une date
4 : les « tables d’historiques »
Table d’historique -> exemple 2 : Historique d’un attribut quelconque MR textuel :
• On veut conserver les adresses successives des adhérents. Au départ on avait la table :
• Adhérents (NA, nom, adresse, CP, ville, email)
• Pour conserver l’historique, on crée une nouvelle table
• Adhérents (NA, nom, email)
• HistoAdresse (#NA, date, adresse, CP, ville) Principes :
• 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 ».
MEA :
Ontologie relationnelle
Clé primaire concaténée avec une date
4 : les « tables d’historiques »
MEA :
• On a une association 1 à plusieurs. Le (1.1) est parenthèsé.
• L’historique est une entité dont la clé primaire est une date.
• (1.1) veut dire que la clé primaire de l’entité côté N rentre en clé étrangère ET primaire dans la table issue de l’entité 1.
• L’historique est un composant de l’adhérent. On peut aussi le voir comme une liaison avec une date.
UML :
• Le losange noir signifie la relation de composition. Les cardinalités par défaut sont 1.1 du côté du losange noir, et * (1,n ou 0,n) de l’autre côté.
Ontologie relationnelle
Clé primaire concaténée avec une date
4 : les « tables d’historiques »
Table de compléments : un historique unique
Exemple : Un tableau, qui est une oeuvre unique, est acheté par un client. L’achat se fait à un certain prix (qui peut être différent de celui prévu pour le tableau) et à une certaine date.
MR textuel :
• Tableaux (NT, titre, année, technique, format, prix, auteur)
• Acheter (#NT, prix, date, #NC)
• Clients (NC, nom, adresse, CP, ville)
• La table de complément ajoute des informations à sa table d’origine : ici, la vente vient
compléter les informations du tableau. La vente est un historique unique 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.
• 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.
MR graphique:
Ontologie relationnelle
Clé primaire simple et étrangère
2 : les « tables-espèce » et les « tables de compléments »
MEA :
• La cardinalité est « 0.1 ». De ce fait, l’association peut porter des attributs. Du fait qu’elle porte des attributs, elle se transforme en table quand on passe au MR.
UML :
Ontologie relationnelle
Clé primaire simple et étrangère
2 : les « tables-espèce » et les « tables de compléments »
Table-espèce - notion d’héritage - Etudiants - Salariés
• Principe
• Quand deux tables ont des attributs en commun, alors il faut mettre ces attributs dans une troisième table dont hériteront les 2 premières. Les 2 premières tables sont des espèces de la troisième. Leur relation à la troisième table est de type « est un ».
• Il est concevable dans ce cas qu’un individu appartienne au deux tables de départ.
• Exemple de 2 tables avec des attributs en commun :
• Etudiants (NE, nom, prénom, adresse, téléphone, domaine, spécialisation, année)
• Salariés (NS, nom, prénom, adresse, téléphone, fonction, salaire, datemb)
• Un étudiant peut aussi être un salarié. Les attributs communs sont : nom, prénom, adresse, téléphone
• MR textuel solution :
• Personnes (NP, nom, prénom, adresse, téléphone)
• Etudiants (#NPetudiant, domaine, spécialisation, année)
• Salariés (#NPsalarié, fonction, salaire, datemb)
• Les clé primaires des tables-espèce sont formées d’une simple clé étrangères.
Ontologie relationnelle
Clé primaire simple et étrangère
2 : les « tables-espèce » et les « tables de compléments »
Modèle mathématique
• Ensemble des Personnes, P = {p1, p2, es1, es2, e1, e2, s1, s2}
• Ensemble des Etudiants, E = {es1, es2, e1, e2 }
• Ensemble des Salariés, S = {es1, es2, s1, s2 }
• E inter S = {es1, es2}
• E et S sont inclus dans P.
Tuples dans les tables :
TABLE PERSONNE Table SALARIE Table ETUDIANT
Le personne 5, s1, est salarié.Son salaire est 3000.
Le personne 7, es1, est salarié et étudiant. Salaire=1000. Domaine=info.
La personne 3, e1, est étudiant. Son domaine est l’informatique.
La personne 1, p1 n’est ni étudiant, ni salarié.
Ontologie relationnelle
Clé primaire simple et étrangère
2 : les « tables-espèce » et les « tables de compléments »
NP Nom
1 p1
2 p2
3 e1
4 e2
5 s1
6 s2
7 es1
8 es2
#NPsalarié salaire
5 3000
6 2000
7 1000
8 800
#NPétudiant domaine
3 informatique
4 compta
7 informatique
8 compta
MR graphique : MEA : UML :
• Dans le MEA et dans l’UML, les espèces n’ont pas de clés primaires (ETUDIANT et SALARIE). C’est la clé primaire de la table dont elles héritent (la table « genre », PErSONNE) qui porte la clé primaire.
• Toutefois, il est possible que les espèces aient leur propre clé primaire. Dans ce cas, ils y aura deux clés primaires candidates dans le MR. Il faudra en choisir une et faire de l’autre un attribut unique et obligatoire.
• En UML, on trouve la flèche classique d’héritage :
• Il ne faut pas la confondre avec la flèche référence d’une clé étrangère vers une clé primaire:
Ontologie relationnelle
Clé primaire simple et étrangère
2 : les « tables-espèce » et les « tables de compléments »
Table complexe
• Dans la typologie des clés primaires, chaque clé étrangère fait référence à une table avec une clé primaire simple.
• Exemple : la table de liaison PARTICIPER relie les EMPLOYES et les PROJETS.
• PARTCIPER (#NE, #NP)
• EMPLOYE (NE, ..)
• PROJET (NP, ..)
• Les tables complexes sont celles pour lesquelles au moins une clé étrangère de la clé primaire fait référence à une table avec une clé primaire complexe.
• Exemple : a table de liaison historique PROJETER relie la SALLE qui est un composant du CINEMA et une date.
• PROJETER (#(N, NS), date, heure, version, #NF)
• SALLE (#NC, NS, nbPlaces, typeEcran, typeSon)
• CINEMA (NC, nom, adresse, CP, ville, tél)
• FILM (NF, titre, année, langueOriginal
Ontologie relationnelle
clés étrangères concaténées
6 - les « tables complexes »
Table complexe
• Dans la typologie des clés primaires, chaque clé étrangère fait référence à une table avec une clé primaire simple. Les tables complexes sont celles pour lesquelles au moins une clé
étrangère de la clé primaire fait référence à une table avec une clé primaire complexe.
• Exemple : a table de liaison historique PROJETER relie la SALLE qui est un composant du CINEMA et une date. La clé primaire est complexe :
MR : * PROJETER (#(NC, NS), date, heure, version, #NF)
• SALLE (#NC, NS, nbPlaces, typeEcran, typeSon)
• CINEMA (NC, nom, adresse, CP, ville, tél)
• FILM (NF, titre, année, langueOriginal) MEA : le MEA n’a rien de particulier :
Ontologie relationnelle
clés étrangères concaténées
6 - les « tables complexes »
Exemple 2 : Historique d’un composant
Les projets ont des étapes numérotées et on fait l’historique des budgets des étapes.
MR : * PROJET (NP, nom, début, fin, budget)
•
ETAPE (#NP, NE, nom, début, fin, budget)
•
HistoBudgetEtape (#(NP, NE), date, budget)
La table HistoBudgetEtapes fait l’historique du budget des ETAPES. C’est un composant des étapes qui sont elles-mêmes des composants des
PROJETS.
MEA :
Ontologie relationnelle
clés étrangères concaténées
6 - les « tables complexes »
Exemple 3 : association d’association
Les centres proposent des animations (activités sportives ou culturelles) : MR : * CENTRE (NC, nom, …) MEA :
• ANIMATION (NA, intitulé, coût, …)
• PROPOSITION (#NA, #NC)
Les personnes pratiquent des animations proposées par les centres : La relation est entre les personnes et les propositions.
MR : * PERSONNE (NP, nom, …) MEA :
• PRATIQUER ( #(NA, NC), #NP ) MEA : dans le MEA, on a trouve une
association d’association. Pour montrer
qu’une association joue le rôle d’une entité, on à mis un petit rectangle d’entité sur
l’ovale de l’association (expression non standard).
Ontologie relationnelle
clés étrangères concaténées
6 - les « tables complexes »
Modélisation de bases de données
Le modèle relationnel
Ontologie relationnelle : typologie des clés primaires
Synthèse
•
Les clés primaires sont soulignées et placées en premier dans la liste des attributs.
•
En première analyse et pour se faciliter la tâche, le nom d’une clé primaire simple est constitué de : « N »+1ère
lettre de la table (NA), ou « id »+1ère lettre de la table (idA)
•
Dans une clé primaire concaténée, les attributs clés étrangères sont placés en premier.
•
Les clés étrangères sont précédées d’un #.
•
Les clés étrangères sont mises en dernier dans la liste des attributs.
Ontologie relationnelle
Formalisme
• Les « tables-noms » proviennent d’entité. Elles peuvent être :
• des objets (les adhérents, les livres)
• des types (les typeAvion, les oeuvres, etc.)
• des composants (l’étape du projet)
• des espèces (les étudiants et les salariés)
• Les « tables-verbes » proviennent d’association. Elles peuvent être
• des tables de liaison (PARTICIPER)
• des historiques (EMPRUNTER). Ils viennent parfois d’une liaison avec une date.
• Elles ont en général au moins deux clés étrangères
• Graphe des table : table pointant sur 2 autres tables :
• Ca peut être une table de liaison : EMPRUNTER
• Ca peut aussi être une table-nom avec 2 clés étrangères : un EMPLOYE travaille dans 1 département et a une fonction définie dans une liste de fonction.
Ontologie relationnelle
table-nom et table-verbe
Ontologie relationnelle
Synthèse
Modélisation de bases de données
Les 6 règles de passage d’un modèle sagittal (le MEA)
au MR
Il existe des règles qui permettent de passer d’un MEA (ou d’une version UML) au MR.
Attention : ces règles ne sont pas clairement standardisées !
On va rappeler d’abord les 3 premières règles qu’on a mis en oeuvre jusqu’à présent qui
correspondent aux 3 éléments qu’on a distingués dans le MEA en prenant en compte en plus les composants et les historiques d’attributs.
• Règle 1 : les entités
• Règle 2 : les associations 1 à plusieurs avec prise en compte des composants
• Règle 3 : les associations plusieurs à plusieurs
On va ensuite présenter d’autre règles prenant en charge d’autres éléments qu’on a distingués dans le MEA :
• Règle 4 : les associations 0.1 à plusieurs
• Règle 5 : l’héritage et les tables espèces
• Règle 6 : les clés complexes
Modèle Relationnel normalisé
Les 6 règles de passage du MEA au MR
Règle 1 - Entité : Chaque entité devient une table. Chaque attribut de l'entité devient un attribut de cette table.
Règle 2 – Association « 1 à plusieurs » : La clé primaire de l’entité supérieure (côté plusieurs) devient attribut clé étrangère dans la table issue de l’entité inférieure (coté 1).
Dans le cas d'une association « 1 à plusieurs » réflexive, ce nouvel attribut doit être renommé (exemple : #NE devient # NEchef).
Dans le cas d’un identifiant relatif (association (1.1) parenthèsée), la clé primaire de l’entité supérieure (côté plusieurs) devient attribut clé étrangère et primaire dans la table issue de l’entité inférieure (coté 1).
Règle 3 – Association « plusieurs à plusieurs » : Une association « plusieurs à plusieurs » devient une table. Les clés primaires des entités associées deviennent clés étrangères dans cette table. Les attributs de l’association deviennent attributs de la table. La détermination de la clé primaire de cette table n’est pas automatique.
En général, la clé primaire de cette table est constituée de la concaténation des clés primaires des entités associées. Toutefois, il faut se demander si cette concaténation forme bien la clé primaire. Si ce n’est pas le cas, on peut essayer d’ajouter des attributs non-clés pour trouver la clé primaire. Ensuite, il faut se demander si on ne peut pas supprimer certains attributs clés étrangères pour réduire la clé primaire au minimum d’attributs.
Modèle Relationnel normalisé
3 premières règles de passage du MEA au MR
Règle 4 – Association « 0.1 à plusieurs » :
-
Si elles portent des attributs, on applique la règle 3 concernant les associations plusieurs à plusieurs. L’association donne une table.
-
Si elles ne portent pas d’attributs, on applique la règle 2 concernant les associations 1 à plusieurs. Dans ce cas la clé étrangère produite n’est pas obligatoire puisque le minimum est à 0 (pas NOT NULL).
Règle 5 – L’héritage : Dans le cas d’un héritage, chaque entité participante (espèce et genre) devient une table. La clé primaire de la table issue de l’entité genre devient clé étrangère dans les tables issues des entités espèces. Si une entité espèce n’a pas de clé primaire, la clé étrangère issue de l’entité genre devient la clé primaire de la table issue de l’entité espèce.
Règle 6 – Clé complexe : Les clés complexe sont produite en appliquant les 5 règles précédentes avec une différence : les associations peuvent relier des
entités ou des associations qui donnent une table dans le modèle relationnel. Dans ce cas les règles 5 premières règles s’appliquent en considérant la clé primaire de la table issue de l’association reliée comme si elle provenait d’une entité.
Modèle Relationnel normalisé
règles 4, 5 et 6 de passage du MEA au MR
Modélisation de bases de données
Le modèle relationnel
Les évolutions
4 types d’évolution sont courantes :
•
Transformation d’un attribut énuméré en type :
=> création d’une « table de types »
•
Passage d’un attribut monovalué à un attribut multivalué. Par exemple, un employé n’a pas une fonction mais plusieurs :
=> création d’une « table de liaisons »
•
La gestion de l’historique d’un attribut
=> création d’une « table d’historique »
•
Gestion particulière des héritages
=> gestion particulière de la table de genre
Le bon usage :
•
En première analyse, dans un MR normalisé, il vaut mieux éviter la prise en compte des évolutions pour ne pas surcharger le modèle.
Modèle Relationnel normalisé
Evolutions du modèle
1er cas : Création d’un type : les employés et leur job
• EMPLOYE (NE, nom, job, salaire) devient :
• EMPLOYE (NE, nom, salaire, #job) ou bien EMPLOYE (NE, nom, salaire, #NJ)
• JOB ( job ) JOB ( NJ, job ) 2ème cas : Attribut Multivalué : les employés ont plusieurs jobs en même temps
• EMPLOYE (NE, nom, job, salaire) devient :
• EMPLOYE (NE, nom, salaire)
• JobEmployé( #NE, job ) // table de liaison
3ème cas : HISTORIQUE des salaires des employés
• EMPLOYE (NE, nom, job, salaire) devient :
• EMPLOYE ( NE, nom, job)
• HistoSalaire(#NE, date, sal) // table d’historique
Modèle Relationnel normalisé
Evolutions du modèle
4ème cas : héritage avec espèces disjointes recouvrant le genre
Il n’y a aucun étudiant salarié et aucune personne qui ne soit ni étudiant, ni salarié
• PERSONNE (NP, nom, prénom, adresse, téléphone)
• ETUDIANT (#NPetudiant, domaine, spécialisation, année)
• SALARIE (#NPsalarié, fonction, salaire, datemb)
devient :
• ETUDIANT (NE, nom, prénom, adresse, téléphone, domaine, spécialisation, année)
• SALARIE (NS, nom, prénom, adresse, téléphone, fonction, salaire, datemb)
5ème cas : héritage avec espèces disjointes ne recouvrant pas le genre
Il n’y a aucun étudiant salarié et des personnes qui ne sont ni étudiant, ni salarié
• PERSONNE (NP, nom, prénom, adresse, téléphone)
• ETUDIANT (#NPetudiant, domaine, spécialisation, année)
• SALARIE (#NPsalarié, fonction, salaire, datemb)
devient :
• PERSONNE (NP, nom, prénom, adresse, téléphone)
• ETUDIANT (NE, nom, prénom, adresse, téléphone, domaine, spécialisation, année)
• SALARIE (NS, nom, prénom, adresse, téléphone, fonction, salaire, datemb)
Modèle Relationnel normalisé
Evolutions du modèle
Modélisation de bases de données
Le modèle relationnel
Comment modéliser ?
1) Définir les ensembles contenant les réalités les plus concrètes
• Par exemple, les employés, les départements, les lions, les buffles, etc.
• Vérifier que les attributs sont reliés au nom de la table par une formule du type « a un » et pas plusieurs ! (un employé à une date d’embauche).
• Définir la clé primaire.
• Trouver une clé significative.
• Eviter les attributs calculés.
2) Chercher les relations (les associations) entre ces ensembles : modéliser sans clés étrangères, avec un modèle sagittal comme le MEA.
• Par exemple, les employés travaillent dans les départements, les lions mangent les buffles, etc.
3) Chercher les cardinalités des relations
• Par exemple, les employés travaillent dans 1 département et 1 seul, dans un département travaillent 0 ou plusieurs employés.
• Les lions mangent 0 ou plusieurs les buffles.
• Les buffles sont mangés par 0 ou plusieurs lions.
4) Chercher des attributs sur les association plusieurs à plusieurs
5) Identifiant relatif
• Vérifier s’il n’y a pas un identifiant relatif pour toutes les associations un à plusieurs.
Modèle Relationnel normalisé
Comment modéliser ?
Modèle Relationnel normalisé Comment modéliser ?
6) Héritage
• Si deux entités ont des attributs en commun, faites de ces attributs une nouvelle table dont hériteront les deux tables de départ.
7) Ni trop, ni pas assez : le rasoir d’Occam
• Ni trop : éviter de multiplier les tables : éviter de transformer une valeur d’attribut en table.
• Ni trop : éviter les tables qui n’ont pas d’attributs sauf si elles sont du côté 1 d’une association 1 à plusieurs.
• Ni pas assez : éviter de fusionner des tables qui doivent être séparées, pour éviter la duplication d’information. La théorie des formes normales de Codd analyse cette question.
8) Du MEA (modèle sagittal sans clés étrangères) au MR (modèle avec clés étrangères)
• Appliquer les règles de passage du MEA au MR.
• Chercher les clés primaires des tables issues d’association plusieurs à plusieurs
9) A partir du MR
• Faire le graphe des tables : il permet d’appréhender le modèle synthétiquement et de faire une première analyse fonctionnelle.
• Définir le type de chaque table (ontologie relationnelle).
• Imaginer des tuples dans les tables : il faut être concret, c’est le secret !
Imaginer des tuples dans les tables : jeu de test
• Il faut imaginer des données concrètes à mettre dans les tables.
Partir des tables correspondant à des entités (les tables les plus concrètes).
• Mettre au moins 3 tuples.
• On peut numéroter les clés primaires simples de 1 à N.
• Il faut 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 peut ne pas être référencée par une clé étrangère, le jeu de tests doit le montrer (un département peut être vide).
Modèle Relationnel normalisé
Comment modéliser ? Jeu de test
Remplir ensuite les tables correspondant à des associations (les tables de laison)
•
Mettre au moins 6 tuples
•
Pour une valeur d’une clé étrangère (le lion 1), lister plusieurs valeurs pour la 2ème clé étrangère (les buffles mangés).
Principes généraux pour les attributs
•
Pour tous les attributs, il faut faire attention à mettre des doublons et des valeurs NULL dès que 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.
L’important pour le test, c’est la cohérence.
•
