application informatique

Transcription

APPLICATION INFORMATIQUE
DU MCD A LA BASE DE DONNEES
DECEMBRE 2008
Module « Application Informatique » pour LaSalle Beauvais.
2008-2009
1 SOMMAIRE
1
SOMMAIRE .................................................................................................................... 3
2
INTRODUCTION ............................................................................................................ 4
3
EXEMPLE : CREATION D'UNE DVD THEQUE ............................................................ 5
3.1
3.2
LE THEME ................................................................................................................................5
LE RESULTAT A OBTENIR : .........................................................................................................5
3.2.1
3.2.2
4
LE FORMALISME ENTITE/ASSOCIATION ................................................................... 7
4.1
LES PROPRIETES ......................................................................................................................7
4.1.1
4.1.2
4.2
4.3
5
Définition .........................................................................................................................................11
Formalisme .....................................................................................................................................11
Dimension d'une association ..........................................................................................................11
LES CARDINALITES .................................................................................................................. 12
4.4.1
4.4.2
4.5
Définition ........................................................................................................................................... 8
Occurrences d'une entité .................................................................................................................. 8
Identifiant .......................................................................................................................................... 8
Formalisme ....................................................................................................................................... 9
Dépendance fonctionnelle ..............................................................................................................10
LES ASSOCIATIONS ................................................................................................................. 10
4.3.1
4.3.2
4.3.3
4.4
Définition ........................................................................................................................................... 7
Occurrences d'une propriété............................................................................................................. 7
LES ENTITES ............................................................................................................................8
4.2.1
4.2.2
4.2.3
4.2.4
4.2.5
Définition .........................................................................................................................................12
Les combinaisons possibles ...........................................................................................................13
ASSOCIATION HIERARCHIQUE .................................................................................................. 13
CREATION D'UN MODELE CONCEPTUEL DE DONNEES ....................................... 14
5.1
LES REGLES DE CONSTRUCTION .............................................................................................. 14
5.1.1
5.1.2
5.1.3
5.2
5.3
6
Les propriétés .................................................................................................................................17
Les entités .......................................................................................................................................17
Les associations .............................................................................................................................17
SIMPLIFIER LE MCD ................................................................................................................ 17
5.3.1
5.3.2
5.4
Le dictionnaire de données .............................................................................................................14
Mise en place des entités et des associations ...............................................................................15
Les cardinalités ...............................................................................................................................16
LES REGLES DE VERIFICATION ................................................................................................. 17
5.2.1
5.2.2
5.2.3
Redondance de l'information ..........................................................................................................17
Les contraintes d'intégrité fonctionnelles ........................................................................................18
LES CONTRAINTES D'INTEGRITES SUR LES DONNEES ................................................................. 19
PASSAGE AU SCHEMA RELATIONNEL ................................................................... 21
6.1
6.2
LES ENTITES .......................................................................................................................... 21
LES ASSOCIATIONS BINAIRES ................................................................................................... 21
6.2.1
6.2.2
6.3
6.4
Cardinalité x, 1 – x, n ......................................................................................................................21
Cardinalité x, n – x, n ......................................................................................................................22
LES AUTRES ASSOCIATIONS .................................................................................................... 22
CAS PARTICULIERS ................................................................................................................. 23
6.4.1
6.4.2
7
Le Modèle Conceptuel de données .................................................................................................. 6
Le schéma relationnel et les types de données. .............................................................................. 6
Les entités avec une seule propriété ..............................................................................................23
Utilisation d'identifiants relatifs ........................................................................................................23
LES TYPES DE DONNEES ......................................................................................... 25
Tiresias-EFC – V. Tellier
Page 3 / 25
2008-2009
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
M.C.D.
CONCEPTION
Schéma
Logique
DEVELOPPEMENT
Schéma relationnel
Schéma
Physique
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.
Page 4 / 25
2008-2009
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.
Page 5 / 25
3.2.1
2008-2009
Le Modèle Conceptuel de données
Une fois l'analyse faite, nous obtenons le MCD suivant :
Emprunteur
Emprunter
ID_Emprunteur
1, n
Nom_Emprunteur
Prénom_Emprunteur
Téléphone_Emprunteur
Adresse_Emprunteur
Date Emprunt
1, n
Date Retour
Date_Emprunt
0, n
Film
1, 1
Avoir
0, n
ID_Film
1, n
Titre
Durée
Résumé
Année de réalisation
0, n
Individu
1, n
Genre
ID_Genre
Nom_Genre
3.2.2
Réaliser
Tourner
0, n
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)
2c
15 c
FILM (ID_Film, Titre, Durée, Résumé, Année_de_réalisation, ref_genre)
Compteur
30 c Entier
Mémo
Entier
2c
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.
Page 6 / 25
2008-2009
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
Adresse_Emprunteur
1, n (4)
(1)
Emprunter (3)
(4) 1, n
Date Emprunt (2)
Date_Emprunt (1)
Date Retour (1)
1, n (4)
Film (2)
ID_Film
Titre
Durée
Résumé
(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
4.1.1
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.
4.1.2
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
Dubois
Martin
Planque
Etc.
date de réalisation → Propriétés
1987
2003
Occurrences
1970
Etc.
Page 7 / 25
2008-2009
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
4.2.1
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
4.2.2
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
Adresse_Emprunteur → Propriétés
Dubois
Martin
Latoile
Jean
Philippe
Benard
03.22.36.36.25
03.20.06.60.60
03.20.36.64.89
Amiens
Lille
Lille
Occurrences
Chacune des occurrences d'une entité doit pouvoir être retrouvée – identifiée – parmi toutes
les autres. Pour cela, nous allons utiliser un identifiant.
4.2.3
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
05.20.69.56.12 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.
Page 8 / 25
2008-2009
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 05.20.69.56.12 Bordeaux puisque son identifiant est Martin Alain alors que la première
occurrence est identifiée par Martin Philippe.
4.2.4
Formalisme
Sur notre modèle conceptuel, la représentation d'une entité sera la suivante :
Entité
Identifiant
Propriété 1
Propriété 2
…
Propriété n
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
Adresse_Emprunteur
Puis nous avons choisi de prendre la composition Nom_Emprunteur –
Prénom_Emprunteur.
Emprunteur
Nom_Emprunteur
Prénom_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
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.
Page 9 / 25
2008-2009
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 4.1.2 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
Acteur
ID_Emprunteur
Nom_Emprunteur
Prénom_Emprunteur
Téléphone
Adresse
ID_Acteur
Nom_Acteur
Prénom_Acteur
Date_Naissance
Ce formalisme est correct : il respecte bien l'unicité des propriétés.
4.2.5
Dépendance fonctionnelle
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 04.
3. Etc.
Page 10 / 25
2008-2009
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"
2.
3. 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.
4.3.1
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) ;
- 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.
4.3.2
Formalisme
Une assocation est formalisée ainsi :
Entité 2
Entité 1
ID1
Propriété 1
Propriété 2
Propriété 3
Faire action
Propriété 6
ID2
Propriété 4
Propriété 5
Utilisation d'un verbe à l'infinitif
ou conjugué
4.3.3
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 :
Supérieur
Employé
Id
Nom
Ville
Etre le supérieur hiérarchique
Depuis
Subordonné
Ces informations seront utiles lorsque nous
parlerons des cardinalités.
Page 11 / 25
-
2008-2009
Dimension 3 : Association ternaire
C'est une association entre trois entités.
Exemple : location d'une voiture par un client à un commercial
Client
Voiture
Louer
Id_Client
Nom_client
Ville_client
Immatriculation
Date d’achat
km
Commercial
Id_Commercial
Nom_Commercial
Ville_Commercial
Occurrences de cette association :
1Le client n°7 loue au commercial n°4 la voiture 125 ALA 51
2Le client n°15 loue au commercial n°5 la voiture 3695 VF 51
3Le 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.
4.4 Les cardinalités
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.
4.4.1
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
n1, 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
Page 12 / 25
4.4.2
2008-2009
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
0, n : Une occurrence de l’entité peut participer plusieurs fois à une association ou pas du tout
0 : Un employé peut ne pas avoir de subordonnés.
n : Un employé peut être le supérieur de plusieurs autres
employés.
Exemple : l'organigramme
Supérieur 0, n
Employé
Est le supérieur hiérarchique
Depuis
Id
Nom
Ville
Subordonné 0, 1
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
1, n : Une occurrence de l’entité participe au moins une fois à une association
1 : Un client signe au moins un contrat.
n : Un client peut signer plusieurs contrats.
Exemple : Signature d'un contrat
Contrat
Client
Id
Nom
Ville
1, 1
Signer
1, n
N°
Début
Fin
Un contrat est signé par un et un seul client.
4.5 Association hiérarchique
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.
Contrat
Client
Id
Nom
Ville
1, n
Signer
Date de signature
1, 1
N°
Début
Fin
Page 13 / 25
2008-2009
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.
5.1.1
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 : Email = 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
Page 14 / 25
2008-2009
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.
5.1.2
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
Adresse_Emprunteur
Film
Emprunter
Date d'emprunt
Date retour
ID_Film
Titre
Durée
Résumé
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,
Page 15 / 25
2008-2009
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
Film
ID_Emprunteur
Nom_Emprunteur
Prénom_Emprunteur
Adresse_Emprunteur
ID_Film
Titre
Durée
Résumé
Emprunter
Date retour
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.)
5.1.3
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
Adresse_Emprunteur
Film
1, n
Emprunter
Date retour
0, n
ID_Film
Titre
Durée
Résumé
1, n
- Une date n'est utile que si il y a un emprunt
- Plusieurs emprunts peuvent se faire le même jour
Date d'emprunt
Date d'emprunt
Page 16 / 25
2008-2009
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.
5.2.1
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 ;
5.2.2
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) ;
5.2.3
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.
5.3.1
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
Voiture
0,n
Louer
0, n
Immatriculation
Date d’achat
km
Page 17 / 25
2008-2009
Une fois le MCD terminé, j'obtiens le résultat suivant :
Client
Voiture
0,n
Id
Nom
Ville
Louer
0, n
0, n
Immatriculation
Date d’achat
km
Contrat
Signer
1,1
0, n
1,1
N°
Début
Fin
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
Voiture
Contrat
Id
Nom
Ville
Signer
0, n
1,1
1,1
Concerner
0, n
N°
Début
Fin
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 :
Produit
Marché
1, n
Nom
Adresse
Coter
0, n
Id Variété
Nom Variété
Prix
1, n
Variété
1, n
1, 1
Appartenir
1, n
Id Produit
Nom Produit
0, n
Date
Date
1, n
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.
5.3.2
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.
Page 18 / 25
2008-2009
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
0, n
0, n
Louer
Id_Client
Nom_client
Ville_client
Voiture
Immatriculation
Date d’achat
Km
1, n
Commercial
N°Commercial
Nom_Commercial
Prénom_Commercial
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
0, n
0, n
Louer
Id_Client
Nom_client
Ville_client
Voiture
Immatriculation
Date d’achat
Km
1, 1
Commercial
N°Commercial
Nom_Commercial
Prénom_Commercial
1, n
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
0, n
0, n
Donner
Recevoir
1, 1
1, n
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.
Page 19 / 25
2008-2009
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
0, n
Aborder
QCM
1, n
Temps imparti
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
Page 20 / 25
2008-2009
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 1.
6.2.1
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 0, n est introduit en clef étrangère dans
la table provenant de l'entité de cardinalité 1, 1.
Exemple :
Client
IdClient
Nom
Ville
Contrat
Signer
x, n
x,1
N°
Début
Fin
Date Signature
CLIENT (IdClient, Nom, Ville)
CONTRAT (N°, Début, Fin, Date de signature, IdClient)
Page 21 / 25
2008-2009
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.
6.2.2
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
Individu
ID_Film
Titre
Durée
Résumé
x, n
Réaliser
x, n
ID_Individu
Nom_Individu
Prénom_Individu
Date_Naissance
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)
6.3 Les autres associations
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
Salle
1, n
Donner cours
Jour
Heure
Classe
1, n
1, n
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)
Page 22 / 25
2008-2009
6.4 Cas particuliers
6.4.1
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
Adresse_Emprunteur
1, n
Emprunter
1, n
Date Emprunt
Date_Emprunt
Date Retour
1, n
Film
ID_Film
Titre
Durée
Résumé
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)
6.4.2
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
1, n
Appartenir
Echantillon
1, 1
N° Echantillon
Nbre d’oignons
Si nous nous arrêtons là, le schéma relationnel serait celui-ci :
Page 23 / 25
2008-2009
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 2549.
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 875-1 ; 875-2 et 875-3.
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
1, n
Appartenir
N° Lot
Date d’arrivée
(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.
Page 24 / 25
2008-2009
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
06000
6000 ← Le code stocké est sur 4 chiffres
Lille
59000
59000
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
64000 caractères au maximum
Numérique
Octet
1 octet
0 à 255
Entier
2 octets
-32768 à 32767
Entier long
4 octets
-2 milliards à +2 milliards environ
Réel simple
4 octets
-3,4 1038 à 3,4 1038 environ (7 déc. au max)
Réel double
8 octets
-1,7 10308 à 1,7 10308 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.
Page 25 / 25

application informatique

Transcription

Documents pareils

Mini Projet : Gestion d`une bibliothèque - e

DP AFI ESCA 2

4 pages A4 prets.indd - Crédit Municipal d`Avignon

Commune de - Givenchy-en

OFFRE SARHA BPMC ver..

Prêt spécial apprentis - Banque Populaire Rives de Paris

Conditions de tarification - Crédit Immobilier de France

Prêt Etudiant - Banque Populaire Rives de Paris

CONVENTION DE PRÊT DE MATÉRIEL

Solution emprunteur