APPLICATION INFORMATIQUE DU MCD A LA BASE DE DONNEES

Transcription

1 APPLICATION INFORMATIQUE DU MCD A LA BASE DE DONNEES DECEMBRE 2008

2

3 1 SOMMAIRE 1 SOMMAIRE INTRODUCTION EXEMPLE : CREATION D'UNE DVD THEQUE LE THEME LE RESULTAT A OBTENIR : Le Modèle Conceptuel de données Le schéma relationnel et les types de données LE FORMALISME ENTITE/ASSOCIATION LES PROPRIETES Définition Occurrences d'une propriété LES ENTITES Définition Occurrences d'une entité Identifiant Formalisme Dépendance fonctionnelle LES ASSOCIATIONS Définition Formalisme Dimension d'une association LES CARDINALITES Définition Les combinaisons possibles ASSOCIATION HIERARCHIQUE CREATION D'UN MODELE CONCEPTUEL DE DONNEES LES REGLES DE CONSTRUCTION Le dictionnaire de données Mise en place des entités et des associations Les cardinalités LES REGLES DE VERIFICATION Les propriétés Les entités Les associations SIMPLIFIER LE MCD Redondance de l'information Les contraintes d'intégrité fonctionnelles LES CONTRAINTES D'INTEGRITES SUR LES DONNEES PASSAGE AU SCHEMA RELATIONNEL LES ENTITES LES ASSOCIATIONS BINAIRES Cardinalité x, 1 x, n Cardinalité x, n x, n LES AUTRES ASSOCIATIONS CAS PARTICULIERS Les entités avec une seule propriété Utilisation d'identifiants relatifs LES TYPES DE DONNEES Tiresias-EFC V. Tellier Page 3 / 25

4 2 INTRODUCTION Le premier cours du module "Application Informatique" vous aura permis (Si vous avez suivi!) de comprendre pourquoi ce module existe dans votre cursus et son objectif final. Ce document fait suite à ce premier cours. Il vous présente le formalisme Entité Association utilisé pour écrire le Modèle Conceptuel de Données (MCD), les règles à connaître pour mettre en place un MCD conforme, les règles qui permettent de passer du MCD au schéma relationnel et enfin les types de données que nous associerons aux données pour pouvoir traiter celles-ci correctement. Ce document n'est certainement pas suffisant pour pouvoir prétendre faire des bases de données correctes. Avant d'en arriver à ce stade, il vous faudra faire les différents exercices vus en TD et participer activement au projet que vous aurez choisi. Afin de vous aider, garder bien en mémoire le schéma suivant : Réalité ANALYSE Schéma Conceptuel CONCEPTION Schéma Logique DEVELOPPEMENT Schéma Physique M.C.D. Schéma relationnel Base De Données Figure 1 Le Modèle Conceptuel de Données va vous permettre de formaliser les données nécessaires à votre projet et les liens qui existent entre elles. Tant que ce schéma ne correspond pas à la réalité constatée associée aux demandes du client, vous ne devez surtout pas passer à l'étape suivante. Cette étape est la plus importante de votre projet. Une fois faite, vous ne pouvez plus ajouter de données sans modifier le MCD, donc le schéma relationnel donc la base de données. Le schéma relationnel est la description de toutes les tables nécessaire à votre projet. C'est à ce niveau qu'il faudra préciser les types de données que vous souhaitez associer aux données lors de la création de la base de données. C'est une fois le schéma relationnel réalisé, les types de données choisis et les traitements décrits (Nous verrons cela ultérieurement) que vous pouvez utiliser votre ordinateur. Avant, il est inutile de l'allumer! Comme tout projet informatique, tout commence sur le papier. Tiresias-EFC V. Tellier Page 4 / 25

5 3 EXEMPLE : CREATION D'UNE DVD THEQUE Pour illustrer les notions que nous aborderons dans ce document, nous nous baserons sur un exemple simple et concret qu'il vous sera possible d'adapter : la création d'une DVD thèque. 3.1 Le thème Voici les objectifs de notre application et les données qui nous intéressent : Pour les films 1- Nous souhaitons créer une application qui nous permettra de lister l'ensemble des films présents dans notre DVD thèque ; 2- Pour aider les futurs emprunteurs, nous pourrons classer nos films par genre, par réalisateurs ou encore par acteurs ; 3- Nous indiquerons le titre du film, l'année de sa réalisation et un résumé ; 4- Pour chaque acteur ou actrice, ne nous intéressent que son nom, son prénom et sa date de naissance ; 5- Idem pour les réalisateurs ; 6- Il ne faut pas oublier qu'une personne qui commence comme acteur peut devenir réalisateur et vice-versa ; 7- Pour un même film, il sera possible d'indiquer plusieurs réalisateurs et plusieurs acteurs ; Pour les emprunts 8- Nous pourrons garder une trace de tous les emprunts ; 9- Nous pourrons lister tous les films sortis avec les coordonnées de l'emprunteur et la date d'emprunt ; 10- Lorsqu'une personne empruntera un film, nous conserverons la date à laquelle elle est venue le chercher et celle à laquelle elle est venue le rendre ; 11- Pour chaque emprunteur, nous souhaitons avoir son nom, son prénom, son adresse et son numéro de téléphone Remarques : - Ajouter/modifier/supprimer un film, un emprunt, un emprunteur, etc. sont des actions évidentes que nous n'indiquons pas ici. - Certaines informations ne seront utiles que lors de la recherche des traitements. 3.2 Le résultat à obtenir : Si nous reprenons la Figure 1 de la page 4, la description du thème qui vient d'être faite correspond à la réalité. Vous trouverez ci-après, le schéma conceptuel puis le schéma relationnel qui découle de cette analyse. Tiresias-EFC V. Tellier Page 5 / 25

6 3.2.1 Le Modèle Conceptuel de données Une fois l'analyse faite, nous obtenons le MCD suivant : Emprunteur ID_Emprunteur Nom_Emprunteur Prénom_Emprunteur Téléphone_Emprunteur Adresse_Emprunteur Emprunter Date Retour Film Date Emprunt Date_Emprunt Avoir Genre ID_Genre Nom_Genre 1, 1 ID_Film Titre Durée Résumé Année de réalisation Tourner Réaliser Individu ID_Individu Nom_Individu Prénom_Individu Date_Naissance Le schéma relationnel et les types de données. Le MCD ne représente pas les tables qui apparaîtront dans notre base de données. Pour obtenir celles-ci, il faut passer au schéma relationnel. Nous en profitons pour indiquer le type de données que nous avons choisi d'associer à chaque champ. EMPRUNTEUR (ID_Emprunteur, Nom_Emprunteur, Prénom_Emprunteur, Téléphone_Emprunteur, Adresse_Emprunteur) Compteur 30 c 30 c 10 c 150 c GENRE (ID_Genre, Nom_Genre) 2 c 15 c FILM (ID_Film, Titre, Durée, Résumé, Année_de_réalisation, ref_genre) Compteur 30 c Entier Mémo Entier 2 c EMPRUNT (Ref_emprunteur, ref_film, Date_emprunt, date_retour) Entier long Entier long Date Date INDIVIDU (ID_Individu, Nom_Individu, Prénom_Individu, Date_Naissance) Compteur 50 c 30 c Date TOURNAGE (ref_film, ref_individu) Entier long Entier long REALISATION (ref_film, ref_individu) Entier long Entier long Une fois ce schéma relationnel mis en place, nous pourrons aller sur l'ordinateur pour créer notre base de données. Tiresias-EFC V. Tellier Page 6 / 25

7 4 LE FORMALISME ENTITE/ASSOCIATION Pour mettre en place notre MCD, nous allons utiliser une notation qui puisse être comprise par toute personne ayant déjà travaillé sur les bases de données. Cette notation est : le formalisme Entité Association. Ce formalisme repose sur 4 concepts de bases : Les propriétés (1) Les entités (2) Les associations (3) Les cardinalités (4) Emprunteur (2) ID_Emprunteur Nom_Emprunteur Prénom_Emprunteur Téléphone_Emprunteur Adresse_Emprunteur (1) (4) Emprunter (3) Date Retour (1) (4) Film (2) (4) Date Emprunt (2) Date_Emprunt (1) ID_Film Titre Durée Résumé Année de réalisation (1) A ces quatre concepts, il faut ajouter quelques définitions telles que occurrence, identifiant, dépendance fonctionnelle ou encore dimension d'une association. 4.1 Les propriétés Définition Une propriété modélise une information élémentaire manipulée au sein du système d'information étudié. Exemples : Dans notre système, parmi les propriétés, nous trouvons : le nom de l'emprunteur, son prénom, son adresse, son numéro de téléphone, le titre du film, sa durée, son résumé, etc Occurrences d'une propriété Définition : les occurrences d'une propriété sont des éléments individualisés de celle-ci. Exemples : Nom de l'emprunteur date de réalisation Propriétés Dubois 1987 Martin 2003 Planque 1970 Occurrences Etc. Etc. Tiresias-EFC V. Tellier Page 7 / 25

8 Remarque : Une propriété est unique dans le système étudié. Cela veut dire que si deux propriétés ont le même nom, soit elles représentent la même information et l'une d'elle est inutile soit il faut en renommer une (Cf. Les entités.). 4.2 Les entités Définition Une entité modélise le regroupement d'objets de même nature manipulés au sein du système d'information étudié. Exemples : L'entité Emprunteur regroupera l'ensemble des personnes qui peuvent emprunter, l'entité Film regroupera l'ensemble des films qui peuvent être empruntés, etc. Une entité peut être concrète un lieu, une machine, etc. ou abstraite un compte (comptabilité), une matière (enseignement), etc.. Une entité est caractérisée par des propriétés. Exemple : L'entité Emprunteur est caractérisée par les propriétés Nom_Emprunteur, Prénom_Emprunteur, Téléphone_Emprunteur, Adresse_Emprunteur Occurrences d'une entité Définition : les occurrences d'une entité sont des éléments individualisés de celle-ci. Exemple : L'entité Emprunteur Nom_Emprunteur Prénom_Emprunteur Téléphone_Emprunteur Adresse_Emprunteur Propriétés Dubois Jean Amiens Martin Philippe Lille Occurrences Latoile Benard Lille Chacune des occurrences d'une entité doit pouvoir être retrouvée identifiée parmi toutes les autres. Pour cela, nous allons utiliser un identifiant Identifiant Un identifiant est une propriété ou une composition de propriétés permettant d'identifier de manière unique une occurrence parmi les occurrences d'une même entité. Exemple : Si nous reprenons l'exemple précédent nous pourrions choisir d'identifier les occurrences de l'entité Emprunteur pour la propriété Nom_Emprunteur. Pour que cela fonctionne, il faut être sûr que toutes les occurrences de la propriété Nom_emprunteur soient uniques. En effet, si nous souhaitons ajouter l'occurrence Martin Alain Bordeaux à l'entité Emprunteur l'occurrence Martin n'identifierait plus une mais deux occurrences de l'entité Emprunteur. Dans cet exemple, seule une des deux occurrences peut-être présente dans notre système. Tiresias-EFC V. Tellier Page 8 / 25

9 Comme il n'est pas rare de connaître plusieurs personnes ayant le même nom, il serait préférable d'identifier l'entité par le nom et le prénom de l'emprunteur. Nous avons alors un identifiant composé de deux propriétés et nous pouvons, sans problème, ajouter l'occurrence Martin Alain Bordeaux puisque son identifiant est Martin Alain alors que la première occurrence est identifiée par Martin Philippe Formalisme Sur notre modèle conceptuel, la représentation d'une entité sera la suivante : Identifiant Propriété 1 Propriété 2 Propriété n Entité Nom de l'entité (Le nom est toujours au singulier) Liste des propriétés caractérisant l'entité Les propriétés utilisées pour l'identifiant sont mises en premières et soulignées. Exemple 1 : L'entité Emprunteur Dans notre premier choix, seule la propriété Nom_Emprunteur était l'identifiant. Emprunteur Nom_Emprunteur Prénom_Emprunteur Téléphone_Emprunteur Adresse_Emprunteur Puis nous avons choisi de prendre la composition Nom_Emprunteur Prénom_Emprunteur. Emprunteur Nom_Emprunteur Prénom_Emprunteur Téléphone_Emprunteur Adresse_Emprunteur Si vous avez lu correctement ce document, vous aurez remarqué que nous avons choisi la solution suivante : Emprunteur ID_Emprunteur Nom_Emprunteur Prénom_Emprunteur Téléphone_Emprunteur Adresse_Emprunteur Cette solution a été préférée à la précédente afin de pouvoir accepter le cas où deux personnes ont les même noms et prénoms. ID_Emprunteur sera un nombre unique pour chaque occurrence. Tiresias-EFC V. Tellier Page 9 / 25

10 Exemple 2 : Unicité des propriétés Dans l'exemple de la DVD thèque, l'une des premières entités évidentes est l'entité Emprunteur. Emprunteur ID Nom Prénom Téléphone Adresse En continuant notre analyse, nous pourrions mettre en place une entité Acteur. Acteur ID Nom Prénom Date_Naissance Prises séparément, ces deux entités sont correctes. Mais si nous voulons qu'elles soient valables dans notre MCD, nous devons les modifier. En effet, nous avons vu au chapitre qu'une propriété était unique. Elle ne peut donc se trouver dans deux entités différentes. Or, dans nos deux entités, nous retrouvons les propriétés ID, Nom et Prénom. Il est donc nécessaire de redéfinir ces 6 propriétés : Emprunteur ID_Emprunteur Nom_Emprunteur Prénom_Emprunteur Téléphone Adresse Acteur ID_Acteur Nom_Acteur Prénom_Acteur Date_Naissance Dépendance fonctionnelle Ce formalisme est correct : il respecte bien l'unicité des propriétés. La dépendance fonctionnelle est une notion importante qui pourra vous servir lors de la création d'un MCD. Définition : Une (ou plusieurs) propriété A est en dépendance fonctionnelle avec une (ou plusieurs) propriété B si, pour une occurrence de la propriété B il n'existe qu'une et une seule occurrence de la propriété A. B A Toutes les propriétés d'une entité sont en dépendance fonctionnelle avec l'identifiant de cette entité (Rappel : un identifiant peut être un groupe de propriétés). 4.3 Les associations Pour que notre application remplisse correctement sa fonction, elle devra nous permettre de stocker des informations telles que : 1. Le film "yy" est réalisé par le réalisateur "w" et est avec les acteurs "x", "y" et "z" 2. L'emprunteur "x" emprunte un film "yy" le 01 janvier 2004 et le rend le 15 janvier Etc. Tiresias-EFC V. Tellier Page 10 / 25

11 Ces informations représentent des liens qui existent entre des entités. Nous les représenterons par des associations. 1. Le film "yy" est réalisé par le réalisateur "w" et est avec les acteurs "x", "y" et "z" L'emprunteur "x" emprunte un film "yy" le 01 janvier 2004 et le rend le 15 janvier 04. Nous verrons, ultérieurement, que cette association concerne aussi la date d'emprunt Définition Une association modélise l ensemble des associations perçues entre une ou plusieurs entités au sein du système d'information étudié. Remarques : - Une association peut être porteuse de propriétés (Exemple : date retour) ; Formalisme - Un élément individualisé d une association est une occurrence ; - Les occurrences d'une association sont identifiées par les identifiants des occurrences des entités en association ; - Les propriétés de l'association sont en dépendance fonctionnelle avec les identifiants des entités qui participent à cette association. Une assocation est formalisée ainsi : Entité 1 ID1 Propriété 1 Propriété 2 Propriété 3 Faire action Propriété 6 Entité 2 ID2 Propriété 4 Propriété 5 Utilisation d'un verbe à l'infinitif ou conjugué Dimension d'une association La dimension d'une association représente le nombre d'entités participant à l'association. - Dimension 2 : Association binaire (normale) C'est une association entre deux entités (Cf. l'exemple ci-dessus). - Dimension 1 : Association binaire réflexive C'est une association qui représente un lien existant entre une même entité. Exemple : Employé Id Nom Ville Supérieur Subordonné Etre le supérieur hiérarchique Depuis Ces informations seront utiles lorsque nous parlerons des cardinalités. Tiresias-EFC V. Tellier Page 11 / 25

12 - Dimension 3 : Association ternaire C'est une association entre trois entités. Exemple : location d'une voiture par un client à un commercial Client Id_Client Nom_client Ville_client Louer Voiture Immatriculation Date d achat km Commercial Id_Commercial Nom_Commercial Ville_Commercial 4.4 Les cardinalités Occurrences de cette association : 1- Le client n 7 loue au commercial n 4 la voiture 125 ALA Le client n 15 loue au commercial n 5 la voiture 3695 VF Le client n 7 loue au commercial n 4 la voiture 5647 XM 51 Chaque occurrence est identifiée par le numéro du client, le numéro du commercial et le numéro de la voiture. - Dimension n : Association n-aire Les associations de dimension supérieure à 3 n'ont pas de noms spécifiques car elles sont rares. En effet, nous verrons qu'il est souvent possible de réduire une association de dimension n à plusieurs associations de dimensions inférieures ou égales à 3. Les cardinalités, quatrième concept du formalisme Entité Association, permettent de préciser le lien qui existe entre les occurrences d'une entité et les occurrences de l'association à laquelle elles participent Définition Une cardinalité est un couple de nombres qui indique le nombre minimum et le nombre maximum de participations d une occurrence d une entité aux occurrences d une association. Objet n2 Association Ces deux nombres peuvent prendre, chacun, deux valeurs : Cardinalité minimale (n1) : 0 : Au moins une occurrence de l entité ne participe pas aux occurrences de l association 1 : Chaque occurrence de l entité participe au moins une fois aux occurrences de l association Cardinalité maximale (n2) : 1 : Une occurrence de l entité participe au plus à une occurrence de l association n : Une occurrence de l entité peut participer à plusieurs occurrences de l association Tiresias-EFC V. Tellier Page 12 / 25

13 4.4.2 Les combinaisons possibles Suite à ce que nous venons de voir, nous pouvons distinguer quatre combinaisons possibles pour écrire une cardinalité. Voyons ce qu'elles signifient : 0, 1 : Une occurrence de l entité participe au plus une et une seule fois à l association : Une occurrence de l entité peut participer plusieurs fois à une association ou pas du tout Exemple : l'organigramme Employé Id Nom Ville Supérieur Est le supérieur hiérarchique Depuis Subordonné 0, 1 0 : Un employé peut ne pas avoir de subordonnés. n : Un employé peut être le supérieur de plusieurs autres employés. 0 : Un employé peut ne pas avoir de supérieur (Ex : le PDG). 1 : Un employé ne peut avoir qu'un supérieur. Nous voyons ici l'intérêt d'ajouter des informations sur les branches d'une association binaire réflexive. 1, 1 : Une occurrence de l entité participe toujours une et une seule fois à l association : Une occurrence de l entité participe au moins une fois à une association Exemple : Signature d'un contrat 1 : Un client signe au moins un contrat. n : Un client peut signer plusieurs contrats. Client Id Nom Ville Signer 1, 1 Contrat N Début Fin 4.5 Association hiérarchique Un contrat est signé par un et un seul client. L'exemple ci-dessus (Signature d'un contrat) est un cas particulier d'association. La présence d'une cardinalité 1, 1 fait de cette association une association hiérarchique. Une association hiérarchique est une association binaire dont l'une des cardinalités est 0, 1 (A.H faible) ou 1, 1. (A.H forte) Ce type d'association fait qu'il existe une dépendance fonctionnelle entre les deux identifiants des entités en association. Si nous reprenons l'exemple cité, un contrat est signé par un et un seul client. Donc si nous connaissons l'identifiant du contrat, nous connaissons l'identifiant de l'unique client qui l'a signé. N Id. Cette dépendance fonctionnelle implique que l'association ne peut contenir de propriétés. Celles-ci devront se trouver dans l'entité dont la cardinalité est 1, 1. Client Id Nom Ville Signer 1, 1 Date de signature Contrat N Début Fin Tiresias-EFC V. Tellier Page 13 / 25

14 5 CREATION D'UN MODELE CONCEPTUEL DE DONNEES La mise en place d'un MCD se fait en trois phases : sa construction, la vérification de sa conformité avec le formalisme utilisé puis sa simplification. Parfois, le MCD ne suffit pas : Il faut lui ajouter des contraintes d'intégrité sur les données. C'est ce que nous verrons dans le dernier chapitre de cette partie. 5.1 Les règles de construction Pour créer un MCD, nous commencerons par établir un dictionnaire de données qui recensera toutes les données nécessaires à notre application. Ce dictionnaire nous servira à mettre en place les entités et leurs associations. Pour les cardinalités, nous utiliserons les règles de gestions rencontrées lors de l'analyse Le dictionnaire de données Avant de créer un MCD, il faut s'assurer de connaître toutes les données nécessaires à notre application. Pour cela, nous les recensons dans un dictionnaire. Nous obtenons un dictionnaire brut. Dans ce dictionnaire, nous allons expliciter les polysèmes et supprimer les synonymes et les propriétés calculées. Nous obtenons alors un dictionnaire épuré. 1- Les synonymes Lors d'interviews pour la mise en place d'une application de gestion de commandes, des gens vous parleront de n Client et d'autres de code client. Ces deux données représentent la même chose. Cela sera à vous de choisir entre les deux définitions. Autre exemple : = Courrier électronique = courriel 2- Les polysèmes Lors de ces interviews, les vendeurs vous disent que la date d'achat du bon de commande signé par le client est importante car elle influe sur la validité de la garantie. Puis vous apprenez par le service achat que la date d'achat est importante car le paiement à lieu 90 jours après cette date. Parlent-ils de la même date d'achat? Non! Il y a la date d'achat au fournisseur et la date d'achat du client. Autre exemple : Le portable : Téléphone mobile ordinateur portable 3- Les propriétés calculées Dans un bon de commande, vous avez pour chaque produit, son coût à l'unité HT, la quantité achetée et le coût total HT du produit. A la fin de la commande vous avez un pourcentage de remise et le coût total HT et le coût total TTC. Certaines de ses propriétés s'obtiennent à l'aide de formule mathématique impliquant d'autres propriétés. Ex : coût total HT du produit = quantité achetée x coût à l'unité HT Tiresias-EFC V. Tellier Page 14 / 25

15 Nous ne garderons pas Coût total HT du produit puisque nous pouvons le retrouver à l'aide des deux autres propriétés. Remarque : pour faciliter le fonctionnement d'une application, il est parfois souhaitable de conserver certaines propriétés calculées. Il faudra alors mettre en place des contrôles qui permettront d'assurer la cohérence de l'information stockée Mise en place des entités et des associations A votre niveau, l'analyse du projet et la réalisation du dictionnaire vous permettront de déterminer intuitivement la plupart des entités et des associations. Cependant, en cas de doute ou de difficultés, vous étudierez les dépendances fonctionnelles : - Un identifiant détermine une ou plusieurs propriétés : les propriétés vont dans l'entité identifiée par cet identifiant ; - Plusieurs identifiants déterminent 1 ou plusieurs propriétés : création d'une association ; - Un identifiant déterminent un autre identifiant : Création d'une association hiérarchique. Lors de la mise en place des entités et des associations, une des difficultés repose sur la notion de temps : Une date, une heure, une journée ou encore une année sera-t-elle une propriété ou une entité? Prenons l'exemple de l'emprunt d'un film par un emprunteur. Cet emprunt aura lieu à une date donnée et sera rendu à une autre date donnée. La première solution serait la suivante : Emprunteur ID_Emprunteur Nom_Emprunteur Prénom_Emprunteur Téléphone_Emprunteur Adresse_Emprunteur Emprunter Date d'emprunt Date retour Film ID_Film Titre Durée Résumé Année de réalisation L'année de réalisation caractérise effectivement le film. Donc il n'y a pas d'autre choix que de mettre cette propriété dans l'entité film. Regardons maintenant ce qu'il se passe au niveau de l'association. Pour cela prenons l'occurrence suivante : (a) L'emprunteur n 12 emprunte du 12/01/2004 au 1/02/2004 le film n 45 L'identifiant de cette occurrence est l'emprunteur n 12, le film n 45. Si ce même emprunteur emprunte le même film deux mois plus tard cela donne l'occurrence suivante : (b) L'emprunteur n 12 emprunte du 10/04/2004 au 15/05/2004 le film n 45 L'identifiant de cette occurrence est l'emprunteur n 12, le film n 45. Les occurrences (a) et (b) ont le même identifiant. Nous devons donc supprimer (En réalité, modifier) (a) pour conserver (b). Si dans une utilisation personnelle cela ne dérange pas, dans une entreprise de location de films (Ou autre) cela change les fonctionnalités de l'application. En effet, dans ce cas d'utilisation, Tiresias-EFC V. Tellier Page 15 / 25

16 l'application ne conserve pas toutes les locations (l'historique) qui ont été effectuées (Dans notre exemple, nous perdons (a) pour avoir (b)) C'est pourquoi, l'exemple ci-dessous est bien plus intéressant. Emprunteur ID_Emprunteur Nom_Emprunteur Prénom_Emprunteur Téléphone_Emprunteur Adresse_Emprunteur Emprunter Date retour Film ID_Film Titre Durée Résumé Année de réalisation Date d'emprunt Date d'emprunt Les deux occurrences précédentes deviennent : (a) L'emprunteur n 12 emprunte du 12/01/2004 au 1/02/2004 le film n 45 L'identifiant de cette occurrence est l'emprunteur n 12, le film n 45, 12/01/2004. (b) L'emprunteur n 12 emprunte du 10/04/2004 au 15/05/2004 le film n 45 L'identifiant de cette occurrence est l'emprunteur n 12, le film n 45, 10/04/2004. (a) et (b) ont ici deux identifiants différents. Nous les retrouverons donc dans notre système sans conflit d'identifiant. Nous pourrons conserver l'historique des emprunts. Remarque : Il est inutile (et faux!) de mettre la date de retour en entité puisque pour un film donné, un emprunteur donné et une date d'emprunt donnée, il n'existe qu'une seule date de retour possible (Vous n'allez pas rendre plusieurs fois à votre voisin le stylo que vous lui avez emprunté hier.) Les cardinalités Les cardinalités de votre MCD sont déterminées par les règles de gestion mise en évidence lors de l'analyse du système. - J'entre un emprunteur à son premier emprunt - Un emprunteur peut emprunter plusieurs fois - Tous les films sont répertoriés Emprunteur ID_Emprunteur Nom_Emprunteur Prénom_Emprunteur Téléphone_Emprunteur Adresse_Emprunteur - Une date n'est utile que si il y a un emprunt - Plusieurs emprunts peuvent se faire le même jour Emprunter Date retour Date d'emprunt Date d'emprunt Film ID_Film Titre Durée Résumé Année de réalisation Tiresias-EFC V. Tellier Page 16 / 25

17 5.2 Les règles de vérification Une fois notre MCD établit, nous vérifierons qu'il ne contient aucune erreur et qu'il est donc valide Les propriétés 1. Une propriété n'est affectée qu'à une seule entité ; 2. Il ne doit pas y avoir de propriétés calculées ; Les entités 1. Chaque entité doit avoir un identifiant ; 2. Pour une occurrence d'entité, chaque propriété ne doit contenir qu'une seule occurrence ; 3. L'occurrence d'une propriété doit dépendre directement de celle de l'identifiant de l'occurrence (Dépendance fonctionnelle) ; Les associations 1. Pour une occurrence d'association, chaque propriété ne doit contenir qu'une seule occurrence ; 2. Toutes les entités sont nécessaires pour définir les propriétés de l'association. Par exemple, dans une association ternaire, lors de la création d'une occurrence d'association, une occurrence de l'identifiant de chaque entité est nécessaire. Une fois que ces quelques règles ont été vérifiées, nous pouvons essayer de simplifier le MCD. 5.3 Simplifier le MCD Simplifier le MCD consiste à rechercher et supprimer les informations redondantes et réduire les dimensions des associations Redondance de l'information Lors de la création d'un MCD, il arrive que nous mettions en place différentes associations qui amènent des informations identiques. Il faut donc vérifier qu'une de ces associations n'est pas inutile car elle apporterait une information déjà donnée via une autre association. Exemple 1 : location de voiture Je commence mon MCD : Client Id Nom Ville 0,n Louer Voiture Immatriculation Date d achat km Tiresias-EFC V. Tellier Page 17 / 25

18 Une fois le MCD terminé, j'obtiens le résultat suivant : Client Id Nom Ville 0,n Louer Contrat Voiture Immatriculation Date d achat km Signer 1,1 N Début Fin 1,1 Concerner Si nous supprimons l'association Louer, nous ne perdons aucune information puisque nous avons l'information à l'aide des associations signer et concerner. A l'inverse, si nous gardons louer pour supprimer les deux autres associations, nous perdons les informations contenues dans le contrat. Le MCD final est donc le suivant : Client Id Nom Ville Contrat Signer 1,1 1,1 Concerner N Début Fin Voiture Immatriculation Date d achat km Exemple 2 : Cotation de produits sur les marchés Chaque jour, les marchés proposent des produits à la vente. S'il y a des acheteurs, les variétés des produits concernés sont cotées. Après réflexion, nous obtenons le MCD suivant : Marché Nom Adresse Prix Coter Date Date Variété Id Variété Nom Variété 1, 1 Appartenir Produit Id Produit Nom Produit Proposer En observant ce MCD, nous pouvons nous dire : Si une variété de produit est côté c'est que le produit est proposé par le marché et donc que l'association Proposer est redondante. Cependant, si aucune variété d'un produit n'est coté sur un marché, doit-on en conclure que ce produit n'est pas proposé par ce marché? Absolument pas. Un produit peut être proposé sans avoir de variété coté. Donc l'association Proposer n'est pas redondante Les contraintes d'intégrité fonctionnelles Une Contrainte d'intégrité fonctionnelle (CIF) sur des entités d une relation exprime le fait que l une des entités est totalement déterminée par la connaissance d une ou plusieurs autres entités. Tiresias-EFC V. Tellier Page 18 / 25

19 Les contraintes d'intégrités fonctionnelles apparaissent dans les règles de gestion. Logiquement, elles sont prises en compte dès le début de la mise en place du MCD. Il est tout de même préférable d'étudier toutes les associations de dimension supérieure à deux. Exemple : Un client vient louer une voiture à un commercial. Client Id_Client Nom_client Ville_client Louer Commercial N Commercial Nom_Commercial Prénom_Commercial Voiture Immatriculation Date d achat Km Après relecture de nos notes, nous nous apercevons qu'un commercial est responsable de ses propres voitures. Nous avons donc une CIF entre l'entité voiture et l'entité commercial : Si je connais la voiture, je connais le commercial. Nous obtenons alors le schéma suivant : Client Id_Client Nom_client Ville_client Louer Commercial N Commercial Nom_Commercial Prénom_Commercial Voiture Immatriculation Date d achat Km 1, 1 Etre responsable 5.4 Les contraintes d'intégrités sur les données Parfois la lecture d'un MCD peut amener des incohérences entre des entités. Exemple 1 : formation interne à une entreprise Employé ID_E Nom Prénom Donner 1, 1 Recevoir Formation ID_F Titre Date Durée A la lecture de cet exemple, un employé peut recevoir et donner une même formation. Ce qui est incohérent. L'intégrité des données n'est plus respectée. Pour conserver cette intégrité, il est nécessaire d'ajouter au MCD des contraintes d'intégrités sur les données. Cela consiste à ajouter des commentaires sur les occurrences d'entités, d'associations ou de propriétés. Dans ce premier exemple, la contrainte à ajouter est : Un employé qui donne une formation ne peut pas la recevoir. Tiresias-EFC V. Tellier Page 19 / 25

20 Exemple 2 : Mise en place d'un QCM Dans la future application, une personne sera chargée de créer les QCM avec le nom du QCM la durée et la date. Ensuite, les enseignants qui le souhaitent pourront venir ajouter leur matière et le temps imparti à celle-ci lors du QCM. Nous obtenons alors le MCD suivant : Matière ID_M Nom_matière Responsable Aborder Temps imparti QCM ID Nom_QCM Durée Date Prenons l'exemple du QCM n 2 qui doit durer 2H (a) Le professeur de mathématique s'inscrit à ce QCM pour une durée de 0H45 (b) Le professeur de français s'inscrit pour une durée de 1H (c) Le professeur de géographie s'inscrit pour une durée de 0h30 A la lecture du MCD, les créations de l'occurrence QCM et des trois occurrences de l'association Aborder sont correctes. Or si nous additionnons les trois temps impartis nous arrivons à une durée de 2h15 alors que le QCM est prévu pour 2H. L'intégrité des données n'est donc pas respectée. Il faut ajouter la contrainte d'intégrité suivante : Pour une occurrence de QCM donnée : temps impartis durée Tiresias-EFC V. Tellier Page 20 / 25

21 6 PASSAGE AU SCHEMA RELATIONNEL Comme nous l'avons déjà dit au chapitre 3.2.2, le MCD n'est pas la représentation des tables d'une future base de données. Il ne fait que représenter, de manière formalisée, les données de notre (futur) application informatique. Pour arriver à notre base de données, nous allons utiliser des règles de passage qui permettent, en partant du MCD, d'obtenir le schéma relationnel. 6.1 Les entités Chaque entité devient une table ; Chaque propriété de l'entité devient un attribut de la table correspondante ; L'identifiant de l'entité devient la clé primaire de la table correspondante. Exemple : Client Identifiant Nom client Ville client CLIENT (Identifiant, Nom Client, Ville Client) 6.2 Les associations binaires Les associations binaires sont la seule difficulté du passage au schéma relationnel (Si difficultés il y a!). En présence d'une association binaire, il faut commencer par regarder les cardinalités car ce sont elles qui détermineront les règles à utiliser. Deux cas sont possibles : x, 1 x, n ou x, n x, n où x représente indifféremment 0 ou Cardinalité x, 1 x, n Nous sommes en présence d'une association hiérarchique. L'identifiant de l'entité dont les cardinalités sont est introduit en clef étrangère dans la table provenant de l'entité de cardinalité 1, 1. Exemple : Client IdClient Nom Ville Signer x, n x,1 Contrat N Début Fin Date Signature CLIENT (IdClient, Nom, Ville) CONTRAT (N, Début, Fin, Date de signature, IdClient) Tiresias-EFC V. Tellier Page 21 / 25

22 Le schéma relationnel correspond bien au MCD puisque dans les deux cas, un client peut signer plusieurs contrats mais un contrat ne peut être signé que par un seul client (Un seul identifiant client dans la clef étrangère de la table CONTRAT). Remarque : Si x est égal à 0 le champ IdClient de la table CONTRAT sera null pour les occurrences de contrats qui n'ont pas été signés Cardinalité x, n x, n Création d'un table ; Les identifiants de chaque entité forment la clé primaire de cette nouvelle table. Exemple : Film ID_Film Titre Durée Résumé Année de réalisation x, n Réaliser x, n Individu ID_Individu Nom_Individu Prénom_Individu Date_Naissance 6.3 Les autres associations FILM (ID_Film, Titre, Durée, Résumé, Année de réalisation) INDIVIDU (ID_Individu, Nom_Individu, Prénom_Individu, Date_Naissance) REALISATION (ID_Film, ID_Individu) Pour toutes les autres associations, le passage du MCD au schéma relationnel est le même que précédemment : Création d'un table ; Les identifiants de chaque entité forment la clé primaire de cette nouvelle table. Exemple : Assocation ternaire Professeur ID professeur Nom professeur Prénom professeur Classe Jour Heure Donner cours Salle Numéro Salle Etage Aile Capacité Nom classe Nbre d'élèves PROFESSEUR (ID prof, Nom prof, Prénom prof) CLASSE (ID Classe, Nbre d élèves) SALLE (Numéro Salle, Etage, Aile, Capacité) COURS (ID prof, ID Classe, Numéro Salle, jour, heure) Tiresias-EFC V. Tellier Page 22 / 25

23 6.4 Cas particuliers Les entités avec une seule propriété Il n'est pas rare de voir des entités ne comportant qu'un identifiant. Dans notre exemple, il s'agit de l'entité date d'emprunt. Dans ce cas, si la table provenant de cette entité ne contient qu'un champ et que l entité en question est en association avec au moins une autre entité, les règles suivantes sont à suivre : la table n'apparaît pas ; Lors d une association amenant une table, son identifiant composera la clé primaire de cette table ; Lors d une association binaire n amenant pas de table, son identifiant devient une clé étrangère. ATTENTION : si le champ de la table est de type Texte, il sera peut-être préférable de garder cette table afin d éviter les erreurs de saisies. Exemple : Emprunteur ID_Emprunteur Nom_Emprunteur Prénom_Emprunteur Téléphone_Emprunteur Adresse_Emprunteur Emprunter Date Retour Date Emprunt Date_Emprunt Film ID_Film Titre Durée Résumé Année de réalisation EMPRUNTEUR (ID_Emprunteur, Nom_Emprunteur, Prénom_Emprunteur, Téléphone_Emprunteur, Adresse_Emprunteur) FILM (ID_Film, Titre, Durée, Résumé, Année de réalisation) EMPRUNT (ID_Emprunteur, ID_Film, Date_Emprunt, Date Retour) Utilisation d'identifiants relatifs Lorsque vous mettrez en place des MCD, vous remarquerez peut-être (Et même sûrement!) des liens particuliers entre deux entités en association hiérarchique : des occurrences d'une même entité sont contenues dans une occurrence d'une autre entité. Pour mettre en évidence cette particularité, nous utiliserons des identifiants relatifs. Prenons l'exemple d'une étude sur des oignons qui arrivent par lots. Pour réaliser cette étude, il est décidé de diviser ces lots en échantillons. Si nous créons une partie du MCD, cela donnerait : Lot N Lot Date d arrivée Appartenir 1, 1 Echantillon N Echantillon Nbre d oignons Si nous nous arrêtons là, le schéma relationnel serait celui-ci : Tiresias-EFC V. Tellier Page 23 / 25

24 LOT (N Lot, date d arrivée) Echantillon (N Echantillon, Nbre d oignons, N lot) En faisant cela, nous rendons indépendant le numéro d'échantillon par rapport au n de lot. Exemple : - Le lot 1 contient les échantillons 1, 2, 3 et 4 ; - Le lot 2 contient les échantillons 5, 6, 9 et 11 ; - - Le lot 875 contient les échantillons 2544 ; 2546 et Or Il serait plus intéressant de pouvoir identifier les échantillons par rapport au lot auquel ils appartiennent : - Le lot 1 contient les échantillons 1-1, 1-2, 1-3 et 1-4 ; - Le lot 2 contient les échantillons 2-1, 2-2, 2-3 et 2-4 ; - - Le lot 875 contient les échantillons ; et Pour cela nous allons utiliser les identifiants relatifs. Sur le MCD, cette utilisation est indiquée par l'ajout de parenthèses sur de la cardinalité 1, 1. Lot N Lot Date d arrivée Appartenir (1, 1) Echantillon N Echantillon Nbre d oignons Le schéma relationnel devient alors : LOT (N Lot, date d arrivée) ECHANTILLON (N Echantillon, N lot, Nbre d oignons) Le N Lot n'est plus seulement une clef étrangère de la table ECHANTILLON, il compose la clef primaire de cette table avec le champ N Echant illon. L'identification de l'échantillon est donc relative au lot auquel il appartient. Tiresias-EFC V. Tellier Page 24 / 25

25 7 LES TYPES DE DONNEES Pour pouvoir manipuler correctement les données au sein de votre base de données, vous devez leur attribuer le bon type. Nous pouvons distinguer : Numérique Alphanumérique Date Binaire Vous trouverez ci-dessous un tableau qui reprend les types qu'il est possible de donner sous Access. Le choix d'un mauvais type pourrait vous empêcher de faire des calculs ou de forcer le format d'une donnée. Par exemple, le code postal d'une ville est composé de 5 chiffres. Vous seriez donc tentés de mettre un type numérique. Or, aucun calcul ne sera fait avec ce code et vous rencontrerez un problème avec les codes postaux des départements du 01 au 09 car le premier chiffre disparaîtra : Ville Code postal valeur stockée Nice Le code stocké est sur 4 chiffres Lille Le bon choix serait en fait un type texte de 5 caractères. Nous verrons que, sous Access, nous pouvons, en plus, obliger la personne à donner 5 chiffres. Type Taille Texte 255 caractères au maximum Mémo caractères au maximum Numérique Octet 1 octet 0 à 255 Entier 2 octets à Entier long 4 octets -2 milliards à +2 milliards environ Réel simple 4 octets -3, à 3, environ (7 déc. au max) Réel double 8 octets -1, à 1, environ (15 déc. au max) Monétaire 8 octets Muni d'un format monétaire à 2 déc. fixes. NuméroAuto 4 octets Correspond à un entier long. Date/Heure 8 octets Formats prédéfinis Oui/Non 1 bit Oui/Non, Vrai/Faux, Activé/Désactivé ou -1/0. Liaison OLE Jusqu'à 1Go Objet lié, comme la photo d'une personne. Tiresias-EFC V. Tellier Page 25 / 25