Modèle Relationnel Brut objectifs d une BD distinction données / traitements

Transcription

1 Modélisation

2 Modèle Relationnel Brut objectifs d une BD distinction données / traitements Modèle des données indépendant des traitements La BD offre un modèle synthétique des données indépendant des traitements qui leur sont appliqués. Ce modèle permet une meilleure compréhension du système d informations représenté, que ce soit celui d une entreprise ou d un système scientifique. L information correspondant à une donnée doit être directement intelligible : elle ne correspond pas à un calcul ou à un codage (pas de code spéciaux dans la BD). Traitements rationalisés qu on applique aux données Une fois les données définies, les traitements se ramènent essentiellement à ajouter, retirer, modifier et consulter les données. A cela, s ajouteront ensuite les algorithmes de transformations (calculs) plus ou moins compliqués.

3 Modèle Relationnel Brut objectifs d une BD intégrité des données La BD a pour objectif d être un réservoir d informations unique et partagé dont l intégrité est garantie. 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é. 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 grands 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.

4 Modèle Relationnel Brut objectifs d une BD Performance et optimisation Une BD doit fournir des performances acceptables par l utilisateur. C est la problématique de l optimisation.

5 Modèle Relationnel Brut 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. 2 modèles dominants le modèle relationnel : MR (qui correspond aux SGBD-R) le modèle entité-association : MEA (qui est indépendant du type de SGBD utilisé). 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. Les modèles de la méthodes MERISE (méthode quasi exclusivement française) MCD : modèle conceptuel des données MLD : le modèle logique des données MPD et le modèle physique des données L usage tend à rendre équivalents MCD et MEA, MLD et MR, MPD et SQL.

6 Modèle Relationnel Brut La jungle des modèles! Il faut distinguer entre langage et méthode MERISE est une méthode. Ses modèles définissent des contraintes méthodologiques. Par exemple, le MCD est un modèle des données qui ne prend pas en compte les contraintes techniques, organisationnelles ou économiques. MEA, MR, UML sont des langages. Ils n imposent aucunes contraintes méthodologiques.

7 Modèle Relationnel Brut Le modèle Relationnel Inventé Codd à IBM-San Jose en Modèle mathématique rigoureux et simple Le modèle des SGBD-R : le modèle dominant des SGBD.

8 Modèle Relationnel Brut Le modèle Relationnel 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

9 Modèle Relationnel Brut Clé primaire Clé primaire La clé primaire est un attribut qui permet de distinguer une ligne d une autre. Clé secondaire Il n y a qu une clé primaire dans une table. Une clé secondaire est un attribut qui pourrait être clé primaire alors qu il y en a déjà une. 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. C est une notion subjective et pas mathématique!

10 Modèle Relationnel Brut Clé étrangère #ND fait le lien entre les employés et les départements

11 Une clé étrangère est un attribut qui fait référence à une clé primaire. Schéma de la BD EMP (NE, nom, job, datemb, sal, comm., #ND) DEPARTEMENTS (ND, nom, ville) Formalisme usuel pour la clé étrangère Modèle Relationnel Brut 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 : ou avec l attribut commun :

12 Pourquoi 2 tables?

13 Modèle Relationnel Brut Clé étrangère réflexive 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 EMP (NE, nom, job, datemb, sal, comm., #ND, *NEchef) DEPARTEMENTS (ND, nom, ville) Graphe des tables :

14 Modèle Relationnel Brut Clé primaire concaténée : une difficulté Exemple : la bibliothèque ADHERENT (NA, nom, prenom, , tel) LIVRES (NL, titre, auteur, éditeur) Les adhérents empruntent des livres 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) Question : quelle est la clé primaire de la table EMPRUNTER???

15 Modèle Relationnel Brut Clé primaire concaténée : une difficulté 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.

16 Modèle Relationnel Brut Clé primaire concaténée : une difficulté Solution : le schéma de la BD ADHERENT (NA, nom, prenom, , tel) LIVRES (NL, titre, auteur, éditeur) EMPRUNTER (#NL, dateemprunt, dateretour, dureemaxdemprunt, #NA,) Formalisme Les clés primaires sont soulignées et placées en premier dans la liste des attributs. Le nom d une clé primaire simple est constitué de : «N»+1ère lettre de la table (NA). 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.

17 Modèle Relationnel Brut Table-nom et table-verbe «table-nom»» et «table-verbe» : distinction pédagogique Les «tables-noms» En général, les «tables-noms» représentent une réalité matérielle : les adhérents, les livres. Les oeuvres 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». Elles ont une clé primaire concaténée Elles ont au moins deux clés étrangères Graphe des tables :

18 Modèle Relationnel Brut Clé étrangère concaténée Au modèle précédent, on ajoute : COURRIERS (NC, texte, date, # (NL, datemp) ) Le courriers fait référence à un emprunt (NL, datemp) qui lui-même fera référence à un adhérent. Shéma complet EMPRUNTER (#NL, dateemprunt, dateretour, dureemaxdemprunt, #NA,) ADHERENT (NA, nom, prenom, , tel) LIVRES (NL, titre, auteur, éditeur) COURRIERS (NC, texte, date, # (NL, datemp) ) Graphe des tables :

19 Modèle Relationnel Brut Attribut calculé DEFINITION REGLE 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). Il duplique donc l information. Dans un modèle relationnel brut, on évite toute duplication d information : on évite donc tous les attributs calculés. EXEMPLE Dans le SI de la bibliothèque, on veut savoir à tout moment le nombre de livres actuellement empruntés par un adhérent. On peut être tenté d ajouter l attribut «nbemprunts» dans la table des adhérents : ADHERENTS (NA, nom, prenom, adr, tel, nbemprunts) Conséquence : risque d incohérence si les mises à jour ne sont pas gérés Un calcul peut permettre de trouver l information : Select count(*) from emprunter Where na = notreadhérent And dateret is null; Garder un attribut calculé et éviter les incohérences Solution contre les incohérences : ajout de trigger dans la BD

20 Ontologie relationnelle Clé primaire simple : 1 - les «tables d objets» et les «tables de types» Table d objets Employés (NE, nom, fonction, salaire, #ND) Départements (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. 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). Table de types Avions (NA, année, couleur, propriétaire, #typeavion) TypeAvion(typeAvion, nombre places, année, moteur) 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.

21 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 Personnes (NP, nom, prénom, adresse, téléphone) Etudiants (#NP, domaine, spécialisation, année) Salariés (#NP, fonction, salaire, datemb) Une table-espère correspond à une spécialisation d une autre table (les étudiants sont des spécialisations des personnes). 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.

22 Ontologie relationnelle Clé primaire simple et étrangère : 2 - les «tables-espèce» et les «tables de compléments» Table de compléments Tableaux (NT, titre, année, technique, format, prix, auteur) Ventes (#NT, prix, date, #NC) Clients (NC, nom, adresse) 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 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.

23 Ontologie relationnelle Clé primaire concaténée avec un identifiant relatif : 3 - les «tables de composants» Exemple : des projets et leurs étapes Projets (NP, nom, début, fin, budget) Etapes (#NP, NE, nom, début, fin, budget) Principes Le numéro d étape (NE) 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.

24 Ontologie relationnelle Clé primaire concaténée avec une date : 4 - les «tables d historiques» Exemple : Historique des adresse des Adhérents Adhérents (NA, nom) HistoAdressesAdherents (#NA, date, adresse) 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».

25 Ontologie relationnelle Clé primaire concaténée avec plusieurs des clés étrangères : 5 - les «tables de liaisons» Exemple 1 : des employés sur des projets Employés (NE, nom, dateembauche) Projets (NP, intitulé, datedébut, datefin, budget) Participer (#NE, #NP) Principes 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.

26 Ontologie relationnelle Clé primaire concaténée avec plusieurs clés étrangères : 5 - les «tables de liaisons» Exemple 2 : employé joue un rôle unique sur le projet. Participer (#NE, #NP, rôle) Le couple NE-NP définit la participation. Le rôle est un attribut pour ce couple. 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é. Participer (#NE, #NP, rôle, durée) Désormais, c est le triplet NR-NP-rôle qui définit la participation. La durée est un attribut pour ce triplet.

27 Ontologie relationnelle clés étrangères concaténées : 6 - les «tables complexes» Exemple : les étapes d un projet et l historique du budget des étapes Projets (NP, nom, début, fin, budget) Etapes (#NP, NE, nom, début, fin, budget) HistoBudgetEtapes (#(NP, NE), date, budget) Principes 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.

28 Ontologie relationnelle Synthèse

29 Modèle Relationnel Brut Evolutions du modèle 3 types d évolution sont courantes : La gestion de l historique d un attribut : création d une table d historique Passage d un attribut monovalué à un attribut multivalué : création d une «table de liaisons» ou d une «table de composants» Transformation d un attribut en type : création d une «table de types» 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.

30 Modèle Relationnel Brut Evolutions du modèle 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 2 : 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 ) Exemple 3 : les employés et leur job Employés (NE, nom, job, salaire) devient : Emloyés (NE, nom, salaire, #job) ou bien Emloyés (NE, nom, salaire, #NJ) Jobs( job ) Jobs( NJ, job )

31 Modèle Relationnel Brut Comment modéliser? Correspondance grammaticale Quelles tables concevoir en premier? 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». Trouver la clé primaire, une clé significative, des attributs Imaginer des tuples : il faut être concret, c est le secret!

32 Chercher des liens Modèle Relationnel Brut Comment modéliser? Chercher des liens entres les tables d objets : une clé étrangère ou une table-verbe Pour chaque table d objets, se demander si elle peut intervenir dans une table de composant, d espèce, d historique, de complément ou de liaison. Ni trop, ni pas assez : le rasoir d Occam éviter de multiplier les tables et les attributs (éviter les attributs calculés, éviter de transformer un attribut en table, éviter de transformer une valeur d attribut en table). éviter de fusionner des tables qui doivent être séparées. C est ce que l analyse des formes normales de Codd nous apprendra.

33 Modèle Relationnel Valorisé les contraintes d intégrité 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. 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.

34 Modèle Relationnel Valorisé les contraintes d intégrité 5 : Clé primaire - SQL : PRIMARY KEY Un attribut clé primaire est tel que sa 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). 6 : Obligatoire - SQL : Not NULL 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. 7 : Unicité - SQL : UNIQUE 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.

35 Modèle Relationnel Valorisé les contraintes d intégrité 8 : Valeur par défaut - SQL : DEFAULT, auto_increment, La valeur par défaut est une valeur donnée par défaut si aucune valeur n est saisie. 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). 9 : Calculé - SQL : trigger, vue 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. 10 : Non saisissable - SQL : trigger, gestion des droits, vue 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é. 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

36 Modèle Relationnel Valorisé les contraintes d intégrité référentielles 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

37 Modèle Relationnel Valorisé Contraintes d intégrité référentielles 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. 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. 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.

38 Modèle Relationnel Valorisé Contraintes d intégrité référentielles 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. 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.

39 Modèle Relationnel Valorisé Contraintes d intégrité référentielles pour les tuples 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. 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.

40 Modèle Relationnel Valorisé Cycle de vie des tuples - création et modification Création (insert into) et contrainte obligatoire Obligatoires : NOT NULL. Il est obligatoirement renseigné à la création. Pas obligatoire. La situation par défaut d un attribut est d être obligatoire (elle correspond à une «forme normale 1» stricte). Modification (update) 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. Remarque : 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.

41 Modèle Relationnel Valorisé Cycle de vie des tuples - Suppression et archivage 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é. Il est détruit dans la BD courante mais conservé dans une archive. Les données archivées ne sont pas modiables.

42 Modèle Relationnel Valorisé Cycle de vie des tuples 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éments d analyse essentiels NULL possible (pas obligatoire) : O Normalement modifiable : M

43 Modèle Relationnel Valorisé Cycle de vie des tuples et analyse fonctionnelle Exemple de modèle valorisé M M O-M M M EMPLOYES(NE, nom, datemb, job, sal, comm., #ND, *NEchef) DEPARTEMENTS (ND, nom, ville) Job, sal, comm, ND, NEchef sont normalement modifiable Comm n est pas obligatoire Usages du système Saisie d un employé (tout obligatoire sauf comm) Modification d un employé (les attributs M) Modification exceptionnelle d un employé (NE, nom, datemb) Saisie d un département (tout obligatoire) Modification exceptionnelle d un département (ND, nom, ville)

44 Modèle Relationnel Valorisé Le dictionnaire des attributs 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.

45 Modèle Relationnel Valorisé Jeu de tests Le jeu de tests est un ensemble de tuples qui permet de tester la base de données. Trucs pour bien construire son jeu de tests Au minimum 3 tuples par tables-nom et 6 tuples par tables-verbe. 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). Il faut faire attention aux attributs date et mettre des dates significatives et cohérentes 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.