merise sgbdr / phpmyadmin sql - razafimamonjy.fr

MERISEMERISESGBDR / PHPMYADMIN SGBDR / PHPMYADMIN

SQL SQL

Raymond RAZAFIMAMONJY

raymond@razafimamonjy.fr 1Copyright Raymond RAZAFIMAMONJY

MERISE Il existe plusieurs méthodes pour concevoir un système d'information informatisé, IMS (Information Management System), RACINES, MERISE, ...

La méthode IMS (Information Management System) : a débuté comme une base de

données hiérarchique créée par IBM en 1966 pour le compte de Rockwell et le programme

Apollo. Il fut utilisé pour suivre les factures des matériels pour le programme Saturn V.

IMS est toujours en fonctionnement une quarantaine d'années après son lancement et

raymond@razafimamonjy.fr Copyright Raymond RAZAFIMAMONJY 2

IMS est toujours en fonctionnement une quarantaine d'années après son lancement et

continue à donner lieu à des développements sous le système d'exploitation MVS d'IBM

(OS/390, z/OS).

La méthode RACINES : est une méthode informatique destinée à étudier la stratégie du

système d'information. RACINES est un acronyme de rationalisation des Choix Informatiques.

Elle a pour but de définir des priorités d'informatisation par domaine dans le cadre d'un

fonctionnement global futur, en tenant compte des budgets et des calendriers.

MERISE La Méthode MERISE (Méthode d'Étude et de Réalisation Informatique pour les Systèmes

d'Entreprise) :

o Une représentation Merise permet de valider les choix par rapport aux objectifs,

o de quantifier les solutions retenues,

o de mettre en œuvre des techniques d'optimisation et enfin de guider jusqu'à

l'implémentation.

o Elle est certainement le langage de spécification le plus répandu dans la communauté

francophone de l'informatique des systèmes d'information, et plus particulièrement dans le

domaine des bases de données.

MERISE MERISE est une méthode française née dans les années 70, à la demande du Ministère de

l'Industrie qui souhaitait une méthode de conception des SI. Popularisé à partir des années 80.

MERISE est donc une méthode d'analyse et de conception des SI basée sur le principe de la

séparation des données et des traitements. Elle possède un certain nombre de modèles (ou

schémas) qui sont répartis sur 3 niveaux principaux :

o Le niveau conceptuel,

o Le niveau logique ou organisationnel,

o Le niveau physique.

Dans ce cours, nous ne nous intéresserons qu'à certains schémas permettant la conception

d'une base de données relationnelle puis sa réalisation sur un SGBDR.

MERISE

MERISE : Modèle Conceptuel de Communication

Prérequis : la notion d’Unité Fonctionnelle

Définitions:

Le dessin externe classique, utilisé pour représenter des fonctions, des traitements à

programmer, est celui des unités fonctionnelles.

Une U.F. (ou fonction logique) regroupe un ensemble de tâches réalisées sur un même

poste de travail, suivant un même mode de travail (conversationnel ou temps différé),

avec la même périodicité.

On peut la positionner ainsi :

o Une entreprise se décompose en domaines, c'est à dire de très gros projets : gestion commerciale, gestion d'une bibliothèque, etc.

o Un domaine se décompose en applications (ou activités ou encore processus) : gestion des commandes, gestion des règlements, etc.

gestion des commandes, gestion des règlements, etc.

o Chaque application se décompose en fonctions : saisie de commandes, édition de bons de livraisons, etc.

o Une fonction est composée de tâches ou de modules fonctionnels : saisir les coordonnées d'un client, ...

o Enfin, chaque tâche est composée d'opérations élémentaires : saisie le n° du client, afficher un solde de compte, un nom de client, ...

Formalisme des unités fonctionnelles.

Une U.F. est donc un ensemble de tâches déclenchées de deux façons possibles :

Interactive (ou conversationnelle) : Les U.F. ont pour origine un même type d'évènement(s), comme un coup de téléphone pour une commande peut provoquer la saisie d'une commande

Batch (ou différé) : Les U.F.ont pour origine une ou plusieurs restitution(s) à produire à une

Batch (ou différé) : Les U.F.ont pour origine une ou plusieurs restitution(s) à produire à une même date , par exemple l'édition de fin de mois des fiches de paie des salariés.

Voici maintenant les symboles utilisés pour décrire une U.F. :

Construction et description.

Construction des U.F. :

Une première démarche consiste à partir du M.C.D.

Pour toute entité nous définissons une U.F. conversationnelle de mise à jour ou de consultation. Par mise à jour, nous entendons les opérations habituelles d'ajout, de modification et de suppression d'informations.

suppression d'informations.

Reprenons le M.C.D. traité dans ce cours :

A l'entité CLIENT correspond une U.F. de mise à jour :

Description des U.F. :

Pour chaque unité fonctionnelle (organisationnelle), il faut décrire :

o Le but (l'objectif, l'usage ou le résultat demandé par l'utilisateur).

o La périodicité (quotidien, hebdomadaire, trimestriel, ...).

o Le responsable.

o Le dessin d'U.F. (ci dessus).

o Le descriptif de traitement.

Les fichiers logiques permanents, les tables d'une base de données sont décrits une fois en dehors des descriptifs d'unités fonctionnelles, car ils sont utilisés dans plusieurs U.F.

Voyons maintenant la construction du dessin d'U.F. en lui-même. On représente par des ovales tous les fichiers avec lesquels l'U.F. doit être en relation.

Ces fichiers correspondent aux tables logiques du M.L.D ( Modèle Logique des Données) défini, c'est à dire aux entités et aux associations porteuses.

Ces fichiers sont reliés à l'U.F. selon la façon dont ils sont exploités par l'.U.F. : en lecture, en écriture ou en mise à jour (lecture/écriture).

écriture ou en mise à jour (lecture/écriture).

On représente un écran si, pour le traitement de l'U.F., il y a un besoin d'interactivité avec l'utilisateur. Ex : pour créer un nouveau client, il faut rentrer ses coordonnées.

Il en sera de même pour les états imprimés si, dans la gestion de l'U.F. il y a des documents à imprimer. Ex : établir un listing des clients.

Pour bien illustrer la construction d'U.F. voici celle qui correspond à la gestion des produits :

U.F. de gestion des produits.

But : traitement des produits.Périodicité : tous les jours de 9h à 17h.Responsable : Service commercial.

Descriptif : La saisie s'effectue sur le N°produit. La mise à jour elle, sur le libellé du produit, le prix unitaire, son code TVA et la quantité. Enfin l'édition des catalogues de produits se fait par facture et/ou par magasins.

Formalisme des diagrammes d'U.F.

Le diagramme d'unité fonctionnelle est un dessin d'U.F. dont les différents modules fonctionnels apparaissent distincts dans le dessin, alors que dans le formalisme d'une U.F ils n'apparaissent que dans le descriptif.

Une fonction n'est pas interruptible, c'est à dire qu'elle n'a pas besoin d'attendre d'autres entrées, ou évènements que ceux ayant provoqué le lancement du travail.

d'autres entrées, ou évènements que ceux ayant provoqué le lancement du travail.

Un module, en revanche n'est pas sécable : un découpage plus fin n'aurait aucun sens, au niveau de la compréhension externe (pour un utilisateur).

Un D.U.F. correspond à la description plus fine d'une unité fonctionnelle. Ex : étudions la saisie d'un prêt dans une bibliothèque.

L'emprunteur choisit un livre dans la bibliothèque, et se présente à l'enregistrement du prêt de livre, voici ce qui pourrait se passer :

Le numéro de l'emprunteur est saisi, l'opérateur vérifie à l'écran le nom et l'état de l'emprunteur : le nombre de livres déjà empruntés, les dates de retour des livres

l'emprunteur : le nombre de livres déjà empruntés, les dates de retour des livres empruntés et pas encore rendus, ...

On saisit ensuite le ou les numéro(s) de livres à emprunter.Si tout est en ordre, le prêt est validé et les tables sont mises à jour.

Construction des D.U.F.

La construction d'un D.U.F. se fait, comme pour les autre modèles, par touches successives, c'est à dire qu'on essaie une solution, et donc un découpage en modules fonctionnels, puis une autre, etc. jusqu'à l'obtention d'une solution satisfaisante.

Pour chaque module, on note à côté des objets mémorisés (fichiers, tables d'une base de données, ...), les rubriques nécessaires. Celles-ci ne coïncident pas toujours avec les

de données, ...), les rubriques nécessaires. Celles-ci ne coïncident pas toujours avec les rubriques affichées, car il peut exister des rubriques calculées, des constantes, les dates système, ... qui ne sont pas dans l'objet utilisé.

L'ensemble des D.U.F. permet de vérifier le modèle des données mémorisées, ou de le construire, car les D.U.F. donnent la totalité des informations élémentaires nécessaires aux différentes tâches.

Construction des D.U.F :

Ex : continuons avec l'exemple du prêt de livre.

Nous définissons une exception E1 : il s'agit du cas où un emprunteur n'est pas en ordre (il n'est pas représenté dans le dessin par soucis de clarté, mais il faudrait le traiter ensuite).

L'exception E2 correspond au cas où un livre ne peut pas être sorti de la bibliothèque. Voici le D.U.F. correspondant au scénario du prêt de livre :

Construction des D.U.F : DUF SAISIE D’UN PRET

Construction des D.U.F :

Pour les manipulations d'objets :

oUne flèche vers la gauche représente une lecture.oUne flèche vers la droite représente une écriture (ou une création).oUne double flèche représente la mise à jour d'une rubrique d'une occurence déjà existante.

Ce formalisme peut aussi être utilisé dans une description organique,il faut alors être plus précis sur les accès aux tables, les contrôles, ... Il faut aussi envisager d'autres cas exceptionnels comme les N° livre ou N°emprunteur inexistants.

DEFINITION

Le modèle conceptuel de communication (M.C.C.) a pour but de modéliser les arcs de

communication entre les différents intervenants (ou acteurs) d'un projet ou d'une

application.

Nous avons vu dans le chapitre sur les U.F. que chaque projet était successivement

décomposé en applications, en fonctions, en modules fonctionnels, puis en opérations

élémentaires.

Les U.F. représentaient les modules fonctionnels.

Dans le M.C.C. nous reprenons tous les modules pour modéliser les liens qui les

relient.

FORMALISME DU MCCLe M.C.C. représente les acteurs et les arcs de communication entre ces acteurs. Il faut cependant

définir deux types d'acteurs, selon un référentiel que l'on choisira (dans la plupart des cas, le référentiel

sera l'entreprise, ou le service responsable du projet à traiter) :

Les acteurs qui appartiennent au référentiel (Ex : service vente, service comptable, ...).

Les acteurs qui sont en dehors du référentiel (Ex: client, fournisseur, ...).

Un acteur est modélisé de la façon suivante :

un flux (ou arc) sera modélisé de cette façon :

arc de communication, tout en sachant qu'un flux interne (dans le référentiel) doit avoir une origine. Il

existe 3 types d'origine pour un flux :

Un flux n peut avoir pour origine un flux n-1.

Un flux peut découler d'une décision (notée D).

Un flux peut enfin provenir d'une temporisation (Ex : fin de mois, +60 jours, etc).

FORMALISME DU MCC

Un flux n peut avoir pour origine un flux n-1.

Un flux peut découler d'une décision (notée D).

Un flux peut enfin provenir d'une temporisation (Ex : fin de mois, +60 jours, etc).

Dans un M.C.C. nous faisons abstraction du support de communication pour représenter les flux. Nous n'indiquons pas s'il s'agit d'un document manuscrit, imprimé, d'un fax ou du téléphone ...

CONSTRUCTION DU MCC

Pour comprendre la construction d'un M.C.C. voici un exemple :

Une entreprise commerciale est constituée de trois services principaux :

ventes, comptabilité et magasin.

Pour chaque commande passée, le bon est transmis du service vente au service

comptabilité qui envoie la facture au client (qui lui, renverra le règlement).

Le service ventes enverra un bon de sortie au magasin pour le déstockage. Ce dernier

envoie le bon de livraison et la commande au client.

En ce qui concerne les stocks, c'est le magasin qui décide seul du réapprovisionnement.

On dénombre cinq acteurs : Client, Service ventes, Service comptabilité, Magasin et

Fournisseur.

On dénombre ensuite sept flux :

CONSTRUCTION DU MCC

On dénombre ensuite sept flux :

(1) et (2) Bon de commande : (du client au service ventes et du service ventes au service

comptabilité).

(3) Facture : du servie comptabilité au client.

(4 )Règlement : du client au service comptabilité.

(5 )Bon de sortie : du service ventes au magasin.

(6 )Bon de livraison+commande : du magasin vers le client.

(7 )Bon de commande fournisseur : du magasin vers le fournisseur.

CONSTRUCTION DU MCC

Pour plus de lisibilité et de commodité, seuls les numéros des flux apparaissent sur le graphique.

Rappel : Le référentiel est l’ensemble des acteurs interne de l’entreprise.

EXERCICE

Voici la description du fonctionnement d'une société de services :

Modélisation du système de gestion des affaires d'une société de service.

Le Service Commercial est chargé d'examiner les études de demande client (cahier des charges). Si ceux-ci correspondent à l'activité de la société, le dossier est transmis à la Direction Technique qui élabore un devis estimatif. Celui-ci est complété au Service Commercial, édité et envoyé au client pour accord.

Si le devis commercial est accepté par le client, le Service Commercial adresse une demande d'étude technique au Service Technique. Le Directeur Technique élabore des devis techniques qui correspondent à un découpage en lots du devis technique.

Chaque devis est transmis à un Chef de Projet. Celui-ci procède à un nouveau découpage technique du devis et établit le planning de réalisation en affectant chacun des postes du devis technique à un Analyste Programmeur.

EXERCICE

Les Analystes Programmeurs établissent journalièrement un compte rendu d'activité. Chaque semaine, le Chef de Projet édite un rapport d'avancement et informe la Direction Technique de la situation des travaux en cours.

Lorsqu'un poste du devis technique est réalisé, le chef de Projet transmet les programmes au client qui établit un procès verbal de réception. La recette est signalée au Service Comptable pour facturation.

Chaque mois, une proposition de facture est établie par le Service Comptable et transmise à la Direction Technique pour être validée. Cette proposition correspond à l'ensemble des lignes du devis commercial non facturées.

Les factures sont ensuite éditées et envoyées au client par le Service Comptable.

EXERCICE

Etablir le M.C.C. correspondant à l'organisation de cette société, en mettant en scène les acteurs

suivants, et en prenant la société comme référentiel :

oLe Client.

oLe Service Commercial.

oLa Direction Technique.

oLe Chef de Projet.

oL'Analyste Programmeur.

oLe Service Comptable.

EXERCICE

MERISE : Modèle Conceptuel des Traitements (M.C.T)

Definition

Tout comme le M.C.C. (chapitre précédent) représentait les arcs de communications, le

M.C.T. a pour principal but de modéliser les traitements d'une application. En cela, il

complète le M.C.C. et se construit à partir de ce dernier et du M.C.D. Pour comprendre un

M.C.T. il faut d'abord connaître les notions suivantes :

Processus.

o Processus.

o Evènement.

o Opération.

o Résultat.

FORMALISME

Le M.C.T. est l'ensemble des traitements, chaque traitement correspondant à un processus.

Un processus est composé :

od'évènements,

od'opérations

oet de résultats.

Voici un exemple de processus :

On notera les évènements E1, E2, E3, ...

Les opérations sont notées Op.1, Op.2, ...

et les résultats sont marqués R.

FORMALISME

Les évènements : qu'ils soient externes ou internes, il peut y avoir de 1 à n évènement déclenchant un processus ou une opération.

Tout processus commence par un évènement soit externe, soit interne répondant à une de ces deux caractéristiques :

Temporisation (Ex : fin de mois, à une heure donnée, ...)Décision (comme dans le M.C.C.).

Décision (comme dans le M.C.C.).

Les flèches arrivant aux opérations sont notées :

ET, s'il y a nécessité des tous les résultats à l'entrée de l'opération (Ex : R2 et E2).OU, si l'un des résultats n'est pas nécessaire (Ex : R1 et R5).VIDE, s'il n'y a besoin d'aucune condition (Ex : E1, R3).

On peut très bien avoir plusieurs conditions à l'entrée d'une opération (Ex : Rx et (Ry ou Rz)).

FORMALISME

Les opérations : elles consistent en un ensemble de traitements élémentaires à effectuer sur les évènements arrivant, en lui ajoutant une valeur abstraite ou concrète.La partie supérieure de l'opération est une description de cet ensemble de tâches. La partie inférieure correspond à une règle d'émission des résultats :

T correspond à toujours (Ex : Op.1, 3 et 4).OK signifie que l'opération est validée et renvoie un résultat bien précis (Ex : Op.2).

(OK barre) signifie que l'opération non validée donne un résultat différent (Ex : Op.2).

Dans ce cas aussi, il se peut qu'il y ait des règles d'émission de résultats complexes.

Les résultats : ils sont une valeur ajoutée au(x) flux entrant de l'opération et peuvent être de deux types diférents :Valeur concrète : un nouvel objet est créé. (Ex : R1, R2, R3, R5).Valeur abstraite : mise à jour d'un flux entrant (Ex : R4, R6, R7).

Il est à noter que les résultats peuvent devenir des évènements pour les opération suivantes (Ex : R1, R2, R3, R5).

Démarche de construction du M.C.T.

Les règles de construction de processus étant établies, il reste à dénombrer ces processus

et à définir leur points de départ et d'arrivée.

Basons-nous sur un exemple pour procéder à ce découpage :

Les règles de construction de processus étant établies, il reste à dénombrer ces processus

et à définir leur points de départ et d'arrivée.

Basons-nous sur un exemple pour procéder à ce découpage :

En règle générale, on peut distinguer trois types de points de départ pour la construction

d'un processus :

Tout flux externe entrant.

Toute temporisation (ici il s'agit de l'origine du quatrième flux).

Toute décision, peuvent être considérés comme points de départ.

Si on observe attentivement le M.C.C. ci-dessus, nous dénombrons ainsi quatre processus.

Numérotons les et donnons en une courte description :

Processus P1 : Gestion de la commande (déclenché par le bon de commande).

Processus P2 : Gestion des règlements (déclenché par le règlement).

Processus P3 : Gestion des relances (déclenché par H/fin de semaine).

Processus P4 : Gestion des fournisseurs (déclenché par décision du magasin).

Processus P1 : Gestion de la commande (déclenché par le bon de commande).

Processus P2 : Gestion des règlements (déclenché par le règlement).

Processus P3 : Gestion des relances (déclenché par H/fin de semaine).

Processus P4 : Gestion des fournisseurs (déclenché par décision du magasin).

Gestion des invariants:

Le M.C.T. a pour but de construire tous les processus, or si nous n'analysons que le M.C.C.

on se rend compte que nous n'avons étudié que les processus sur les flux.

Il faut repérer les invariants, sur les quels on ne dispose pas de processus de gestion.

Dans l'exemple que nous avons traité ici, on ne possède pas de processus sur la gestion des

clients.

Il faut donc faire le M.C.T. sur l'invariant CLIENT.

Le M.C.T. sur invariant est constitué de quatre parties :

Création : Il faut notifier le mode de création de l'identifiant (manuel, automatique, semi-

automatique), les éléments obligatoires en cas de création, les éléments facultatifs et les

conditions de création.

Suppression : Il faut préciser ce qui est supprimé, les conditions de suppression, s'il y a une

trace de la suppression ou non.

Consultation : Il faut spécifier les critères d'accès, et ce que l'on peut consulter ou pas.

Modification : Il faut préciser les modes de suppression (individuel, global, mixte), et

prévoir les conséquences des modifications (voire même insérer une date d'effet pour

certaines modifications).

EXERCICE 1

Soit le M.C.C de la « Gestion des approvisionnement » suivants.

Etablissez sa M.C.T

EXERCICE 1

M.C.T de la « Gestion des approvisionnement»

EXERCICE 1

Gestion des approvisionnement

EXERCICE 2

Soit le M.C.C de la « Gestion des cartes bleues» suivants.

Etablissez sa M.C.T

EXERCICE 2

M.C.T Gestion des cartes bleues

EXERCICE 1

M.C.T Gestion des cartes bleues

MERISE : Modèle Conceptuel des Données (M.C.D)

C'est une représentation graphique et structurée des informations mémorisées par un SI.

Le MCD est basé sur deux notions principales :

Les entités et les associations, d'où sa seconde appellation : le schéma Entité/Association.

L'élaboration du MCD passe par les étapes suivantes :

La mise en place de règles de gestion (si celles-ci ne vous sont pas données),

L'élaboration du dictionnaire des données,

La recherche des dépendances fonctionnelles entre ces données,

L'élaboration du MCD (création des entités puis des associations puis ajout des

cardinalités).

Les règles de gestion métiers

Avant de vous lancer dans la création de vos tables (ou même de vos entités et associations pour rester dans un vocabulaire conceptuel), il vous faut recueillir les besoins des futurs utilisateurs de votre application.

Et à partir de ces besoins, vous devez être en mesure d'établir les règles de gestion des données à conserver.

Prenons l'exemple d'un développeur qui doit informatiser le SI d'une bibliothèque.

Prenons l'exemple d'un développeur qui doit informatiser le SI d'une bibliothèque. On lui fixe les règles de gestion suivantes :

Pour chaque livre, on doit connaître le titre, l'année de parution, un résumé et le type (roman, poésie, science fiction, ...).

Un livre peut être rédigé par aucun auteur (dans le cas d'une œuvre anonyme), un auteur ou plusieurs auteurs dont on connaît le nom, le prénom, la date de naissance et le pays d'origine.

Chaque exemplaire d'un livre est identifié par une référence composée de lettres et de chiffres et ne peut être paru que dans une et une seule édition.

Un inscrit est identifié par un numéro et on doit mémoriser son nom, prénom, adresse, téléphone et adresse e-mail.

Un inscrit peut faire zéro, un ou plusieurs emprunts qui concernent chacun un et un seul

Un inscrit peut faire zéro, un ou plusieurs emprunts qui concernent chacun un et un seul exemplaire.

Pour chaque emprunt, on connaît la date et le délai accordé (en nombre de jours).

Ces règles vous sont parfois données mais vous pouvez être amené à les établir vous-même dans deux cas :

Vous êtes à la fois maîtrise d'œuvre (MOE) et maîtrise d'ouvrage (MOA), et vous développez une application pour votre compte et/ou selon vos propres directives.

Ce qui arrive le plus souvent : les futurs utilisateurs de votre projet n'ont pas été en mesure

Ce qui arrive le plus souvent : les futurs utilisateurs de votre projet n'ont pas été en mesure de vous fournir ces règles avec suffisamment de précision ; c'est pourquoi vous devrez les interroger afin d'établir vous même ces règles.

N'oubliez jamais qu'en tant que développeur, vous avez un devoir d'assistance à maîtrise d'ouvrage si cela s'avère nécessaire.

Le dictionnaire des données

Structure d'un système automatisé d'informations:

Une application informatique (logiciel, jeux, ...) est constituée de trois composantes

fonctionnelles principales :

Une fonction d'interface utilisateur/machine qui consiste à définir les informations à saisir,

et celles à transmettre à l'utilisateur.

Une fonction de mémorisation qui a pour but de stocker ces informations (scores,

sauvegardes, documents, ...) sur des supports externes. Cette fonction implique une

structuration des données sous forme de fichiers ou de bases de données.

Une fonction de traitement effectuée à partir des informations saisies et mémorisées.

Les traitements se distinguent en quatre catégories fondamentales :

Les contrôles : ils permettent de valider les données saisies et de s'assurer de leurs conformité (vraisemblance d'une date, prix et quantité commandée supérieurs à zéro, ...)

Les mises à jour : elles permettent l'évolution des informations mémorisées par ajout,

Les mises à jour : elles permettent l'évolution des informations mémorisées par ajout, suppression ou modification (augmentation d'un prix, suppression d'un article dans une commande).La consultation : les critères de selection permis peuvent avoir une influence sur l'organisation et la structuration des données mémorisées, sur la rapidité d'un programme, ...Les calculs : ils doivent respecter certaines règles de gestion, d'algorithme. Ex : Prix TTC = Prix HT +TVA.

Le dictionnaire des donnéesLes Informations:

Toute information manipulée possède cinq caractéristiques, plus ou moins importantes :Le nom : il paraît évident que chaque information doit posséder un nom unique et propre à elle : il ne doit pas y avoir de polysémie, ni de synonymes.

Polysémie :

Deux noms d'informations sont polysémiés, si elles ont le même nom et expriment des valeurs différentes.

valeurs différentes. Ex : la date de facturation a le nom DATE et la date de commande a le nom DATE elle aussi, alors qu'il s'agit de deux dates différentes. On peut les renommer DATE_FACT pour la première et DATE_CDE pour la seconde.

Synonyme :

Les noms synonymes sont des noms qui représentent deux fois la même propriété. Ex : dans un document le nom du client est nommé NOM_CLIENT, dans un autre il est nommé NOM_DU_CLIENT. Tous deux représentent la même propriété : le nom du client .Dans un cas de redondance, il faut donc supprimer l'un des deux champ.

Les Informations :

La nature :

Une information peut être calculée ou non.

Une information non calculée (NC) est un champ de texte, ou un nombre dont on ne sert pas pour des calculs. Ex : le nom d'un client, son adresse, un numéro de téléphone ou le code postal.

Ex : le nom d'un client, son adresse, un numéro de téléphone ou le code postal.

Une donnée calculée (C) peut l'être à partir d'autres données calculées ou non. Ex : montant HT (C) = quantité (NC) * prix HT (NC).

En revanche, une quantité en stock, par exemple, est calculée comme suit : quantité en stock = ancien stock + somme des entrées - somme des sorties. Une telle donnée pourra être calculée et mémorisées (CM).

Les Informations:

Le type : une information peut se caractériser par des types différents :

D pour une date (JJ/MM/AAAA),

A pour une donnée alphanumérique,

N pour un nombre,

B pour une valeur booléenne (vrai ou faux).

La longueur : il convient de donner une longueur à chaque donnée, en nombre de

caractères ou de chiffres.

Les observations : pour chaque propriété, on peut associer un commentaire ou une

remarque, qui pourra aider.

Ex : pour une date on peut indiquer qu'elle est sous la forme JJ/MM/AAAA.

En résumé, toute propriété est caractérisée par :

L'ensemble des propriétés d'un système d'informations compose ainsi un Dictionnaire Global (ou Brut) des Données.

Global (ou Brut) des Données.

Remarque : On pourra trouver le terme de PROPRIETE à la place d'INFORMATION, ou vice-versa, sachant que chacun des deux termes désignent la même chose.

Reprenons l'exemple de notre bibliothèque et du système de gestion des emprunts que nous

sommes chargés d'informatiser.

Après l'étude des règles de gestion, nous pouvons établir le dictionnaire des données suivant

Le dictionnaire des données : Exercice

Construction d'un Dictionnaire Global des Informations.

Le dictionnaire doit être constitué après l'étude physique de l'existant (phase de recueil).

L'analyse des fiches, des documents, des fichiers permet de construire le dictionnaire.

L'étude des travaux, des postes de travail et des tâches déjà informatisées, permet de mettre en évidence les règles de gestion et d'organisation.

mettre en évidence les règles de gestion et d'organisation.

Ex : examinons les deux documents suivants et construisons le dictionnaire des données.

Voici un indice

Ex : examinons les deux documents suivants et construisons le dictionnaire des données.Résultats de la première ébauche

Résultats de la première ébauche

Nous remarquons que les informations non calculées (NC) étant les plus fréquentes,

nous n'inscrirons dans la colonne NATURE, que les informations calculées (C) et calculées

mémorisées (CM), afin de faciliter la rédaction du dictionnaire.

Sur ce dictionnaire, ne figurent pas les date de facturation et la date de l'état des stocks,

cela signifie que dans chaque dictionnaire, nous ne nous occuperons pas de :

odate système.

otouches de fonctions.

onuméros de pages (documents imprimés).

Dans la colonne OBSERVATIONS, nous avons utilisé les termes règle 1, règle 2, ... pour montrer que ces propriétés étaient liées à des règles de gestion. Il est nécessaire de préciser ces règles :

règle 1 : Une information Total HT est égal à la somme des prix unitaires HT des produits soumis au même taux de TVA.

règle 2 : Le montant TVA est égal au Total HT multiplié par le taux de TVA correspondant.

règle 3 : Le montant TTC est égal à la somme des informations Total HT plus les différents montants de TVA.

règle 4 : La quantité en stock est, pour une période donnée, et pour chaque magasin, obtenue à partir de l'ancienne valeur à laquelle on ajoute la somme des entrées et à laquelle on soustrait la somme des sorties.

A cette étape, il est important de vérifier qu'il n'existe pas de polysémies ou de synonymes pour les noms. L'exemple du dessus contient un polysémie N°produit et un synonyme (Libellé produit et Désignation produit).

Résultats de la deuxième ébauche

Le dictionnaire des données n'est jamais figé, il est sans cesse complété et enrichi par de nouvelles données dans le cycle de vie du projet. Toutes les propriétés, mêmes celles calculées, doivent être recensées dans ce dictionnaire en début.

Le dictionnaire des données n'est jamais figé, il est sans cesse complété et enrichi par de nouvelles données dans le cycle de vie du projet. Toutes les propriétés, mêmes celles calculées, doivent être recensées dans ce dictionnaire en début.Cependant afin d’affiner et de finaliser le dictionnaires , il faut respecter la règle suivante :

Les données qui figurent dans le MCD (et donc dans le dictionnaire des données) doivent être, dans la plupart des cas, élémentaires :

Elles ne doivent pas être calculées : les données calculées doivent être obtenues, par le calcul, à partir de données élémentaires qui, elles, sont conservées en base. Cependant, il existe quelques cas où il s'avère pertinent de conserver, pour des raisons d'optimisation, une donnée calculée, le montant d'une commande par exemple.

On ne conservera pas les données calculées intermédiaires sauf en cas d'obligation légale (c'est le cas pour un montant HT par exemple, où les composantes peuvent d'ailleurs avoir un prix variable dans le temps). Cela évite de refaire les calculs plusieurs fois pour un résultat qui restera fixe.

Elles ne doivent pas être composées :

les données composées doivent être obtenues par la concaténation de données

élémentaires conservées en base.

Par exemple une adresse est obtenue à partir d'une rue, d'une ville et d'un code postal :

ce sont ces trois dernières données qui sont conservées et donc qui figureront dans le

MCD (et dans le dictionnaire des données).

Lorsque l'on n‘effectue jamais de calcul sur une donnée numérique, celle-ci doit être de

type AN (c'est le cas par exemple pour un numéro de téléphone).

Construction d'un Dictionnaire Epuré des Informations:

Cette étape consiste à recopier le dictionnaire global des informations en ne conservant

que les données non calculées (NC) et calculées mémorisées (CM).

L'étude des règles de gestion et de calcul permet parfois de découvrir de nouvelles

informations qui n'étaient pas présentes dans les documents fournis.

Ex : ici, il faut ajouter les propriétés Taux de TVA et Sortie de stock, en raison des règles de

gestion énoncées plus haut.

La dernière étape consiste à classer par ordre alphabétique sur le nom, le dictionnaire

épuré.

Et voici, le dictionnaire épuré final.

Cette étape consiste à recopier le dictionnaire global des informations en ne conservant que les données non calculées (NC) et calculées mémorisées (CM).

L'étude des règles de gestion et de calcul permet parfois de découvrir de nouvelles informations qui n'étaient pas présentes dans les documents fournis. Ex : ici, il faut ajouter les propriétés Taux de TVA et Sortie de stock, en raison des règles de gestion énoncées plus haut.

énoncées plus haut.

La dernière étape consiste à classer par ordre alphabétique sur le nom, le dictionnaire épuré.Et voici, le dictionnaire épuré final.

Il est à noter qu'il n'est pas nécessaire d'inclure la colonne DOCUMENT dans le dictionnaire épuré des données.

Les dépendances fonctionnelles

Soit deux propriétés (ou données) P1 et P2. On dit que P1 et P2 sont reliées par une dépendance fonctionnelle (DF) si et seulement si une occurrence (ou valeur) de P1 permet de connaître une et une seule occurrence de P2.

Cette dépendance est représentée comme ceci :P1 → P2On dit que P1 est la source de la DF et que P2 en est le but.Cas d’une dépendances fonctionnelles élémentaire.

Par ailleurs, plusieurs données peuvent être source comme plusieurs données peuvent être but d'une DF. Exemples :P1,P2 → P3P1 → P2,P3P1, P2 → P3,P4,P5Cas d’une dépendances fonctionnelles composées

En reprenant les données du dictionnaire précédent, on peut établir les DF suivantes :

id_em → date_em, delais_em, id_i, ref_eid_i → nom_i, prenom_i, rue_i, ville_i, cp_i, tel_i, tel_port_i, email_i, date_naissance_iref_e → id_lid_l → titre_l, annee_l, resume_l, id_t, id_edid_t → libelle_t

id_t → libelle_tid_ed → nom_edid_a → nom_a, prenom_a, date_naissance_a, nom_p

On peut déduire les conclusions suivantes de ces DF :

À partir d'un numéro d'emprunt, on obtient une date d'emprunt, un délai, l'identifiant de l'inscrit ayant effectué l'emprunt, la référence de l'exemplaire emprunté.

À partir d'une référence d'exemplaire, on obtient l'identifiant du livre

À partir d'une référence d'exemplaire, on obtient l'identifiant du livre correspondant.

À partir d'un numéro de livre, on obtient son titre, son année de parution, un résumé, l'identifiant du type correspondant, son numéro d'édition.

Une DF doit être :

élémentaire : C'est l'intégralité de la source qui doit déterminer le but d'une DF. Par exemple si P1 → P3 alors P1,P2 → P3 n'est pas élémentaire.

Dépendance fonctionnelle Dépendance fonctionnelle élementaireélementaire::

Une dépendance Fonc]onnelle de A → B est élémentaire s'il n’existe pas une donnée C, sous-ensemble de A, décrivant une dépendance de type C → B.

C, sous-ensemble de A, décrivant une dépendance de type C → B.

Exemple:

RéférenceProduit → Désigna]on

NuméroCommande, RéférenceProduit → Quan]té

NuméroCommande, RéférenceProduit → Désigna]on

1. RéférenceProduit→ Désignation2. NuméroCommande, RéférenceProduit→ Quantité (df composée)3. NuméroCommande, RéférenceProduit→ Désignation

La première dépendance fonctionnelle est correcte car ayant deux rubriques elle est élémentaire.

La deuxième dépendance fonctionnelle est correcte aussi car la connaissance d'un numéro de commande et d'une référence produit nous permet de connaitre la

numéro de commande et d'une référence produit nous permet de connaitre la quantité commandé du produit.Elle est aussi élémentaire car c'est la connaissance du couple (NuméroCommande, RéférenceProduit) et pas seulement d'un des éléménts qui permet la connaissance de la quantité.

La troisième dépendance fonctionnelle n'est pas élémentaire car il existe à l'intérieur d'elle RéférenceProduit → Désignation, qui était déjà une dépendance fonctionnelle élémentaire.Pour connaitre la Désignation, NuméroCommande est dans ce cas superflu.

MCD rappel des règles d’edition des données

Les Informations:

Toute information manipulée possède cinq caractéristiques, plus ou moins importantes :Le nom : il paraît évident que chaque information doit posséder un nom unique et propre à elle : il ne doit pas y avoir de polysémie, ni de synonymes.

Polysémie :

Deux noms d'informations sont polysémiés, si elles ont le même nom et expriment des

Deux noms d'informations sont polysémiés, si elles ont le même nom et expriment des valeurs différentes. Ex : la date de facturation a le nom DATE et la date de commande a le nom DATE elle aussi, alors qu'il s'agit de deux dates différentes. On peut les renommer DATE_FACT pour la première et DATE_CDE pour la seconde.

Synonyme :

Les noms synonymes sont des noms qui représentent deux fois la même propriété. Ex : dans un document le nom du client est nommé NOM_CLIENT, dans un autre il est nommé NOM_DU_CLIENT. Tous deux représentent la même propriété : le nom du client .Dans un cas de redondance, il faut donc supprimer l'un des deux champ.

Dépendance fonctionnelle Dépendance fonctionnelle élementaireélementaire directe:directe:

On dit que la dépendance fonc]onnelle A → B est directe .S’il n’existe aucun a^ribut C tel que l’on puisse avoir A → C et C → B.

En d’autres termes, cela signifie que la dépendance fonctionnelle entre A et B ne peut pas être obtenue par transitivité (sans intermédiaire).

Exemple :1. NumClasse → NumElève

2. NumEleve → NomElève

3. NumClasse → NomElève

La troisième dépendance fonctionnelle n’est pas directe car nous pourrions écrire :NumClasse → NumElève → NomElève ( ici, c’est une dépendance fonctionnelle transitive).

Dépendance fonctionnelle composée:Dépendance fonctionnelle composée:

une dépendances fonctionnelle qui comporte plusieurs attributs est dite composée:

Exemple 1 :

sur 100m, Usaine bolt a fait 9.58ssur 200m, Usaine bolt a fait 19.19ssur 400m, Usaine bolt a fait 36.84s

sur 400m, Usaine bolt a fait 36.84s

(N° course , N° coureur) → (temps)

Interprétation:

Connaissant le numéro de la course et le numéro du coureur , nous connaissons de façons certaine le temps chronométré d'un coureur précis sur une course précis.

Dépendance fonctionnelle composée:Dépendance fonctionnelle composée:

une dépendances fonctionnelle qui comporte plusieurs attributs est dite composée:

Exemple 2:

Connaissant le code de l'athlète et le code du sport , nous pouvons connaitre de façons sûre et unique le nombre d'année de pratique.

La seule connaissance du code athlètes ne nous permet pas de connaître le nombre d'années de pratique.

De la même manière la seule connaissance du code du sport ne permet pas la connaissance pleine et entière des années de pratique .

Structurellement il est nécessaire d'avoir les deux informations : -> le code de l'athlète et le code du sport pour pouvoir connaitre les années de

pratique d'un sport précis par athlète précis.

Résumé :

Une dépendance fonctionnelle noté DF doit être :

élémentaire : C'est l'intégralité de la source qui doit déterminer le but d'une DF. Par exemple si P1 → P3 alors P1,P2 → P3 n'est pas élémentaire mais composée .

directe : La DF ne doit pas être obtenue par transitivité. Par exemple, si P1 → P2 et P2 → P3 alors P1 → P3 a été obtenue par transitivité et n'est donc pas directe.

Conclusion :

Les DF qui existent entre les données sont parfois évidentes et ne nécessitent pas toujours une modélisation mais celle-ci peut s'avérer utile car elle permet, entre autres, de distinguer les futures entités du MCD et leur identifiants.

Méthodologie d’élaboration des dépendances fonctionnelles :

L’élaboration des dépendances fonctionnelles est réalisée à l’aide du dictionnaire des

données.

La démarche consiste à rechercher :

- les dépendances fonctionnelles formées par deux rubriques, élémentaires et directes ;

- les dépendances fonctionnelles composées.

Les dépendances fonctionnelles Méthodologie d’élaboration des dépendances fonctionnelles

Exemple

Monique, sa fille Rachel et son gendre Marc gèrent un camping dans les Pyrénées orientales.

Le camping est ouvert du 1er juin au 30 septembre.

Ils disposent de cinquante emplacements sur un terrain d’une superficie totale de quarante hectares.

Ils sont équipés d’un logiciel spécialisé dans la réservation des emplacements qui fonctionne très bien

mais qui ne permet pas de gérer les achats de l’épicerie ou du bar selon leurs règles de gestion.

En effet, les vacanciers ne payent leurs achats qu’à la fin de leur séjour.

Concrètement, les achats sont inscrits manuellement sur une fiche bristol créée pour chaque famille

de vacanciers.

À la fin du séjour, les cumuls sont réalisés et une facture manuelle concernant les achats est établie.

Les propriétaires du camping souhaiteraient disposer d’un logiciel permettant d’automatiser la

création de la facture grâce à la saisie journalière des achats.

Exemple

Voici une représentation de la fiche bristol :

Exemple

Résolution du cas:

À la lecture de l’énoncé, nous devons déterminer et séparer les informations mémorisables des informations décrivant le contexte.

Les prénoms des propriétaires du camping sont ils des informations stockables ou des informations d’ordre général ? Si nous analysons la demande d’informatisation ces données ne font pas partie du système d’information.

d’information.

Il en est de même pour les dates d’ouverture, de fermeture, le nombre d’emplacements ou la superficie du camping.Il paraît évident que nous devons nous intéresser à l’élément de base, c’est-à-dire la fiche bristol.

C’est elle qui contient les informations indispensables à l’élaboration de la facture finale.Nous pouvons y trouver le nom de la famille, son adresse, la liste des articles achetés, leur prix unitaire, la quantité, le total.

Il va être nécessaire de rajouter deux informations non présentes : le numéro du client et le code de l’article.

Exemple

Le dictionnaire des données qui pourrait être élaboré suite à la lecture de l’énoncé :

Exemple

Le dictionnaire des données qui pourrait être élaboré suite à la lecture de l’énoncé :

Le dictionnaire des données recense l’ensemble des informations. Comme nous pouvons le constater certaines informations seront déduites (ou calculées) en fonction d’informations élémentaires.

C’est le cas du TotalLigne qui est le résultat de la multiplication du prix unitaire du produit et de sa quantité et du TotalFacture qui est la somme des TotalLigne.

et de sa quantité et du TotalFacture qui est la somme des TotalLigne.

Ces deux informations sont utiles pour le développeur de l’application qui mettra en oeuvreles procédures de calculs a posteriori.

Dans le cycle de modélisation Merise ces deux informations sont des données déduites et non stockables, elles n’apparaîtront donc pas dans la suite du processus.

Exemple

Détermination des dépendances fonctionnelles ou DF

À la lecture du dictionnaire nous pouvons déduire deux groupes d’informations distinctes. Un groupe caractérise les clients, l’autre les produits.

Dépendances fonctionnelles pour les clients:

Posons nous la question :« Quand je connais le numéro du client, est ce que je connais de façon sûre et unique le nom du client ? ». Si la réponse est « oui » alors voici la transcription de la Dépendances Fonctionnelle « DF » :

Numcli → Nom

Voici maintenant l’ensemble des Dépendances Fonctionnelle élémentaires :

Numcli → PrénomNumcli → AdresseNumcli → Code PostalNumcli → Ville

Dépendances fonctionnelles pour les articles :

CodeArticle → Désigna]onCodeArticle → PrixUnitaire

Les DF auraient pu aussi s’écrire de la façon suivante : Numcli → (Nom, Prénom, Adresse, Code Postal, Ville),CodeArticle → (Désigna]on, PrixUnitaire).

ExempleIntéressons nous à la donnée Qté :

est ce que la connaissance du code de l’article nous permet de connaître de façon sûre et unique une quantité ?

Autrement dit :

Connaissant « 567Nut » nous pouvons connaître de façon sûre et unique la quantité « 4 » ?Nous nous rendons compte que cette donnée Qté fait partie d’une DF composée.

Voici une proposition :

(Numcli, CodeArticle, Date) → Qté

Et maintenant si nous nous posons la question :

« Connaissant le code du client, le code de l’article et la date d’achat puis je connaître de façon sûre et unique la quantité achetée ? ».Il est évident que la réponse est oui !Voilà, nous venons de définir l’ensemble des DF concernant notre cas.

Rappel : Les dépendances fonctionnelles ne concernent que les données non déduites. C’est pour cela que n’apparaissent pas les données concernant le total par ligne et le total global de la facture qui sont des informations déduites par calcul.

Exemple

Graphe des dépendances fonctionnelles

C’ est une étape intéressante car il épure le dictionnaire en ne retenant que les données non déduites et élémentaires et il permet une représentation spatiale de ce que sera le futur modèle conceptuel des données.

Voici le graphe des dépendances fonctionnelles concernant le camping :

Exemple

Matrice des dépendances fonctionnelles

Une autre façon de représenter les dépendances fonctionnelles est de créer une matrice. Cependant, cette représentation ne présente pas le même intérêt que le graphe, qui lui permet une vision plus graphique du futur modèle conceptuel des données.

Elle se présente sous forme d’un tableau ayant pour entrées l’ensemble des données du dictionnaire.

Les entêtes de lignes sont les données sources des dépendances fonctionnelles

Les entêtes de colonnes sont les données buts des dépendances fonctionnelles

Le tableau est parcouru colonne par colonne, et pour chaque colonne ligne par ligne.

À chaque étape la question suivante doit être posée : la donnée source est elle en dépendance fonctionnelle avec la donnée but ?

En cas de réponse positive, nous inscrivons un « 1 » dans la case d’intersection.

Exemple

Matrice des dépendances fonctionnelles

Exemple

Matrice des dépendances fonctionnelles en versions simplifiée :

Exemple

Conclusion :

Il est impératif de bien comprendre et bien maîtriser ces notions de DF, car elles sont les fondations des modèles Merises qui vont suivre.

Donc, il est nécessaire de passer du temps à bien les définir pour éviter les erreurs de conception plus tard.

conception plus tard.

Construction de la MCD

Le M C D introduit la notion d’entités, de relations et de propriétés. Nous allons commencer par voir certains aspects « théoriques » avant de plonger dans la pratique.

Il décrit de façon formelle les donnéesutilisées par le système d’information.

La représentation graphique, simple et accessible, permet à un non-informaticien de participer à son élaboration.

participer à son élaboration.

Les éléments de base constituant un modèle conceptuel des données sont :

1. les propriétés ;

2. les entités ;

3. les relations.

1.Les propriétés ( ou attributs):

Les propriétés sont les informations de base du système d’information.

Un client possède un numéro de client, un nom, un prénom, habite à une adresse précise, etc.

Ces informations élémentaires essentielles sont des propriétés.Les propriétés disposent d’un type.

Les propriétés disposent d’un type.

Elles peuvent être numériques, représenter une date, leur longueur peut être aussi définie. Par exemple : le nom est une propriété de type alphabétique et de longueur 50, c’est à direque la valeur saisie ne comportera aucun chiffre et ne dépassera pas cinquante caractères.

Les types ne sont pas décrits au niveau conceptuel, car ce niveau est trop proche de la définition du système physique. Nous y reviendrons plus tard.

2. Les entités ou objets :

Comme il est aisé de le constater, les clients sont définis par certaines propriétés (numéro, nom, prénom…).

Le fait de les regrouper amène naturellement à créer une entité Clients.

Le symbolisme retenu est le suivant :

2.a L’identifiant :

Une de ces propriétés a un rôle bien précis, c’est l’identifiant nommé aussi la clé.

L’identifiant permet de connaître de façon sûre et unique l’ensemble des propriétés qui participent à l’entité.

Par exemple, le fait de connaître la ville d’un client permet il de connaître son nom ? La réponse est non.

La connaissance du nom du client permet elle de connaître sa ville ?

La connaissance du nom du client permet elle de connaître sa ville ? La réponse est toujours non, car en cas d’homonymie la confusion entre un DURAND Max et un DURAND Raymond est totale. ( pas de Polysémie ).

Il faut donc trouver, ou inventer, une propriété qui lorsque sa valeur est connue permet la connaissance de l’ensemble des valeurs qui s’y rattachent de façon formelle.

Ainsi, lorsque le numéro du client est connu, son nom, son prénom et toutes les valeurs des autres propriétés qui s’y rattachent sont connues de façon sûre et unique.

Au niveau du formalisme, cette propriété se souligne.

Voici le schéma modifié de l’entité Clients.

Si on résume :

Formalisme de l’entité: Dans le dictionnaire des données:

À partir de cette entité, on peut retrouver la règle de gestion suivante :

Un client est identifié par un numéro unique ou clé (id_c) et est caractérisé par un nom, un

prénom , un Code postale, une adresse et une ville .

Une entité peut n'avoir aucune, une ou plusieurs occurrences.

Pour illustrer ce terme d'«occurrence», voici un exemple de table d'occurrences de l'entité

Pour illustrer ce terme d'«occurrence», voici un exemple de table d'occurrences de l'entité Client comprenant 3 occurences ou 3 uplets:

Remarques :

-La table d'occurrence peut être comparée à l'instance d'une relation (implantation relationnelle d'une entité ou association) à un moment donné. Nous reviendrons sur cette notion de relation dans les prochains slides.

-Au niveau conceptuel, on devrait plutôt parler d'entités-types , les entités étant en fait des instances d'entités-types.

les entités étant en fait des instances d'entités-types. Par soucis de simplicité, on gardera les termes d'entités et associations tout au long du cours.

3. Les relations ou associations

Nous avons vu que les entités regroupaient un ensemble d’informations élémentaires. Les entités sont souvent liées entre elles.

Par exemple :

Un client peut commander des articles.

Si nous analysons cette phrase, on distingue deux entités (clients et articles) et un verbe (commander) qui indique un lien entre clients et articles.

Formalisons cette phrase avec Merise.

Voilà la première étape, première car la lecture du schéma doit être améliorée en incorporant une notion importante : les cardinalités.

3.a. Les cardinalités :

Elles expriment le nombre de fois ou l’occurrence d’une entité participe aux occurrences de la relation. Dans notre exemple on peut se poser les questions suivantes :

Combien de fois au minimum un client peut il commander un article ?

Combien de fois au maximum un client peut il commander un article ?

À la première question, nous pouvons répondre qu’un client, pour être client, doit

commander au moins un article.

À la deuxième question, nous pouvons répondre qu’un client peut commander plusieurs

articles.

Voici comment symboliser cet état :

Le n représente la notion de « plusieurs » ; ici nous avons représenté le fait qu’un client peut commander un ou plusieurs articles.

Il faut que nous nous posions les mêmes questions pour l’article :

Combien de fois au minimum un article peut il être commandé par un client ?

Combien de fois au maximum un article peut il être commandé par un client ?

Pour le minimum, nous pouvons l’interpréter de la façon suivante :A-t-on des articles qui ne peuvent jamais être commandés ?

A-t-on des articles qui ne peuvent jamais être commandés ?Si nous répondons oui dans ce cas la cardinalité minimale est 0.

Pour le maximum :

A-t-on des articles qui peuvent être commandés plusieurs fois ?Nous pouvons espérer que oui, dans ce cas la cardinalité maximale sera n.

Voici le schéma finalisé :

La cardinalité minimale (0 ou 1) exprime le nombre de fois minimum qu’une occurrence d’une entité participe aux occurrences d’une relation.

La cardinalité maximale (1 ou n) exprime le nombre de fois maximal qu’une occurrence d’une entité participe aux occurrences de la relation.

d’une entité participe aux occurrences de la relation.

Si le maximum est connu, il faut inscrire sa valeur.

Par exemple, si dans les règles de gestion le client n’a le droit de commander qu’un maximum de 3 articles en tout et pour tout, dans ce cas là les cardinalités s’exprimeront de cette façon : 1,3.

Autre exemple :Modélisons le fait qu’une mère élève des enfants.

Nous avons deux entités Mères et Enfants :

Définitions

Une relation Elever :

Aujourd’hui, dans une configuration familiale de modèle couple hétérosexuel et monogame. (Et stop ! pas de débats inutile…faite le à la pause si vous le souhaitez)

Les cardinalités seront donc les suivantes:

Une mère peut élever un ou plusieurs enfants.Un enfant peut être élevé par une et une seule mère.

Bien sûr, tout est question d’interprétation.Au sein d’une équipe de développement, il peut y avoir des divergences de point de vue.

Pour les cardinalités, il faut être le plus logique possible, se référer aux règles de gestion édictées par le commanditaire de l’application , c’est-à-dire le client , votre patron .Et se rappeler la maxime suivante : "Qui peut le plus peut le moins".

Construction de la MCD3. b. Les relations porteuses :

Définition :

Une relation est dite porteuse lorsqu’elle contient des propriétés.

Imaginons que l’on veuille connaître la quantité d’articles commandés par clients, nous nous rendons compte qu’il faut utiliser une nouvelle propriété Quantité.

Cette nouvelle propriété dépend de clients, d’articles ou des deux ?La bonne réponse est que Quantité dépend des deux entités.

Voici le modèle conceptuel correspondant :

Nous pouvons interpréter ce schéma de la façon suivante :

Le client X a commandé la quantité Y d’articles Z. Si nous désirons connaître la date d’achat, il nous suffit de créer une entité Date à la relation Commander.

Définition :

Une relation est dite porteuse lorsqu’elle contient des propriétés.

Imaginons que l’on veuille connaître la quantité d’articles commandés par clients, nous nous rendons compte qu’il faut utiliser une nouvelle propriété Quantité.

Cette nouvelle propriété dépend de clients, d’articles ou des deux ?La bonne réponse est que Quantité dépend des deux entités.

Nous pouvons interpréter ce schéma de la façon suivante :

Le client X a commandé la quantité Y d’articles Z. Si nous désirons connaître la date d’achat, il nous suffit de créer une entité Date à la relation Commander.

Une relation faisant intervenir deux entités est dite binaire.

Si nous désirons connaître la date d’achat, il nous suffit de créer une entité Date à la relation

Commander.

Une relation faisant intervenir trois entités est dite ternaire ou « Tripattes ».

Construction de la MCD3.c. Les relations réflexives

Une relation réflexive est une relation d’une entité sur elle même.Par exemple: on désire modéliser le fait qu’un employé peut diriger d’autres employés.

À la lecture de ce schéma, nous interprétons donc :qu’un employé peut diriger zéro ou plusieurs personnes et qu’un employé est dirigé par

un et un seul autre employé.

4. Règles d’usages

Toute entité doit comporter un identifiant.

Toutes les propriétés de l’entité dépendent fonctionnellement de l’identifiant.

C’est-à-dire que connaissant la valeur de l’identifiant, nous connaissons de façon sûre et unique la valeur des propriétés associées.

Si nous recherchons le client numéro 2, nous devons récupérer le nom et le prénom du client numéro 2 et pas ceux d’une autre personne.

client numéro 2 et pas ceux d’une autre personne.

Le nom d’une propriété ne doit apparaître qu’une seule fois dans le modèle conceptuel des données. Si nous établissons une entité Clients et une nommée Prospects, nous ne devons pas retrouver la propriété Nom dans les deux entités.Il faut préférer la dénomination suivante Nom_client et Nom_prospect. Pas de polysémie.

Les propriétés résultantes d’un calcul ne doivent pas apparaître dans le modèle conceptuel des données.

Cas pratique

Reprenons le graphe concernant le cas du camping vu précédement et réalisons le modèle conceptuel qui en découle.

Le graphe :

Le MCD pas à pas :

Commençons par déterminer les entités. Par rapport au graphe, nous pouvons remarquer trois sources de dépendances fonctionnelles :

1. CodeArticle2. Date3. NumCli

Chacune de ces sources peut représenter une entité :

a. Articles

a. Articlesb. Datec. Clients

Construction de la MCDLe MCD pas à pas :

Voici la représentation graphique des entités :

Renseignons maintenant les entités avec leurs propriétés respectives :

Traçons les relations

Nous savons qu’une quantité d’articles est achetée par un client à une date donnée.Nous voyons qu’il existe une relation entre les trois entités.La voici modélisée :

Examinons les cardinalités: Sur le graphique ci-dessus nous pouvons interpréter qu’au minimum il ne se vend strictement rien.

En pratique, nous pouvons imaginer qu’il ne se passe pas une journée sans que se produise la vente d’un article à un client. En voici le MCD revu :

Maintenant, nous pouvons lire qu’au minimum un article est acheté dans une certaine

quantité, par au minimum un client à une date donnée.

Voilà qui nous rapproche plus de la réalité.

Construction de la MCD / EXERCICE

Cardinalités de la relation mariage dans les 2 cas suivants :

1. Peut-on jouer des matchs de double ?

Non, la cardinalité 2,2 indique qu'un match n'est joué que pas 2 joueurs exactement et non 4 (cas de jeu en double, 2 fois 2 adversaires).

2. Un joueur peut-il gagner un match sans y avoir participé ?

Dans la vraie vie surement non, mais curieusement le modèle n'indique pas cette contrainte de gestion.

contrainte de gestion.

3. Peut-il y avoir deux matchs sur le même terrain à la même heure ?

La encore rien sur le modèle n'indique cette contrainte

4. Connaissant un joueur, peut-on savoir sur quels terrains il a joué?

Oui, à partir d'un joueur, la relation "participe" indique tous les matchs qu'il a joué et d'après la relation "se joue sur" tous les terrains qu'il a occupé.

1. Un patient peut-il effectuer plusieurs consultations ?

En effet, la cardinalité 1,n indique qu'il peut en prendre plusieurs.

2. Un médecin peut-il recevoir plusieurs patients dans la même consultation ?

Non, les cardinalités 1,1 de part et d'autre de l'entité consultation indique qu'une consultation ne peut avoir qu'un seul et unique patient avec un seul et unique médecin.

3. Peut-on prescrire plusieurs médicaments dans une même consultation ?

Oui, les cardinalité 0,n entre la consultaion et le médicament précisent qu'à une consultation donnée, on peut prescrire aucun, un ou plusieurs médicaments.

4. Deux médecins différents peuvent-ils prescrire le même médicament ?

Bien sur, un patient peut prendre plusieurs consultations (cardinalités 0,n) avec des médecins différents (pas de contrainte entre le patient et le medecin qui traduirait un medecin référent !)

Notion d’entité forte et d’entité faible

Définition

a. Entité forte :

Une entité forte est une entité qui, disposant de son identifiant, peut être considérée de façon isolée.

Définition

b. Entité faible :

Une entité faible est une entité qui ne peut être considérée qu’en association avec une autre entité.Voici un exemple :

Dans ce cas l’entité forte est l’entité Mères et l’entité faible est l’entité Enfants.

Notion de Contrainte d’Intégrité Fonctionnelle

Définition

Une contrainte d’intégrité fonctionnelle (ou CIF) est définie par le fait qu’une des entités de l’association est complètement déterminée par la connaissance d’une ou de plusieurs entités participant à cette même association.

Exemple:

Nous pouvons lire qu’une salle peut contenir zéro ou plusieurs ordinateurs et qu’un ordinateur existe dans une et une seule salle. Dans le cas d’une association binaire comme celle ci, une contrainte d’intégrité fonctionnelle existe à partir du moment ou une cardinalité de type 1,1 existe.

Donc on peut l’écrire aussi de la manière suivante (au lieu de contenir ):

Notion d’identifiant relatif :

Les identifiants relatifs font partie des extensions Merise/2, je vous les présente volontairement dans ce chapitre.

Certaines entités ont une existence totalement dépendante d’autres entités. Dans ce cas nous avons recours à un identifiant relatif.

Notion d’identifiant relatif : exemple :Nous devons gérer les exemplaires des livres commandés dans une bibliothèque :

Nous pouvons considérer qu’une bibliothèque achète plusieurs exemplaires du même livre.

Nous pouvons considérer qu’une bibliothèque achète plusieurs exemplaires du même livre. Doit elle numéroter les exemplaires dans l’ordre séquentiel croisant c’est à direde 1 à 6 000 ou pour chaque ouvrage de 1 au nombre maximal de cet ouvrage présent dans

la bibliothèque ?

Il paraît évident que la solution la plus judicieuse est la seconde proposition. Ainsi, la clé d’identification de l’exemplaire sera la concaténation du Num ISBN (International

Standard Book Number ou Numéro international normalisé du livre) et du Num Exemplaire. L’identification d’un identifiant relatif se traduit par le symbole (R) à côté de la cardinalité.

Notion d’identifiant relatif : Par exemple suite :Nous devons gérer les exemplaires des livres commandés dans une bibliothèque :

Pour reconnaître un identifiant relatif, nous pouvons aussi nous poser la question

Pour reconnaître un identifiant relatif, nous pouvons aussi nous poser la question « si je supprime l’ouvrage X de ma bibliothèque, dois je supprimer tous les exemplaires ? ». La réponse est bien entendu oui.

Nous pouvons donc dire que l’existence même de l’entité Exemplaire dépend de l’existence de l’entité Ouvrage.Voici un autre exemple encore plus évident :Vous êtes le responsable informatique d’un centre de formation possédant un campus sur lequel sont construits 3 bâtiments strictement identiques :Ils possèdent 3 étages et chaque étage héberge 12 salles informatiques dans lesquelles peuvent être installés 10 PC

Par exemple suite :

Nous pouvons en conclure que dans chaque bâtiment, nous pouvons installer 360 ordinateurs et la capacité du campus est de 3*360 ordinateurs soit 1080.

Imaginons le scénario suivant, vous recevez une dotation de 1080 ordinateurs à répartir dans toutes les salles.

En outre, vous devez les numéroter pour les identifier.

En outre, vous devez les numéroter pour les identifier.Quelle solution choisissez vous ?

Une solution serait de les numéroter de 1 à 1080.

Une autre serait de rendre la numérotation relative à la salle.

Par exemple dans la salle 1 du premier étage du bâtiment A la numérotation serait de 11à 110, dans la salle 2 la numérotation irait de 21 à 210.

Par exemple suite :

Maintenant, il serait judicieux de rendre la salle relative à l’étage.

La numérotation deviendrait E111, pour le premier ordinateur de la salle 1 de l’étage 1, ou E31210 pour le dixième ordinateur de la salle 12 de l’étage 3.

Vous venez de comprendre que maintenant nous pourrions rendre les étages relatifs aux

Vous venez de comprendre que maintenant nous pourrions rendre les étages relatifs aux bâtiments et numéroter les ordinateurs de la façon suivante : BAE31210.

Ainsi, nous savons que nous avons affaire à l’ordinateur 10 de la salle 12 de l’étage 3 du bâtiment A.

Si les ordinateurs peuvent être changés de lieu rien qu’en regardant leur identifiant, vous pouvez les réinstaller dans leurs salles respectives.

Voici le modèle conceptuel découlant de cet exemple :

Imaginons que le centre de formation décide de vendre un bâtiment, tout disparaît en cascade !

MERISE : Modèle Logiques des Données (M.L.D)

Le MLD a pour but de nous rapprocher au plus près du Modèle Physique des Données (MPD). Pour cela, nous partons du MCD et nous lui enlevons les relations, mais pas n’importe comment, il faut en effet respecter certaines règles. Voici la procédure à suivre.

Cas (0, n), (1,1) ou (1,n), (0,1)

Voici un modèle conceptuel de départ :

Cas (0, n), (1,1) ou (1,n), (0,1)

Voici un modèle conceptuel de départ :

Nous devons supprimer la relation Elever, cela se réalise de façon tout à fait mécanique. L’entité ayant la cardinalité de type 1,1 ou 0,1 absorbe l’identifiant de l’entité la plus forte (0, n ou 1, n).

L’entité ayant la cardinalité de type 1,1 ou 0,1 absorbe l’identifiant de l’entité la plus forte (0, n ou 1, n).

Cet identifiant est alors appelé la clé étrangère.

Voici le Modèle Logique des Données découlant du Modèle conceptuel précédent :

Nous pouvons l’illustrer par un cas concret.

Béatrice BAPTISTE a trois enfants : Amandine, Cédric, Sylvain.

Patricia AUGUY a deux enfants : Mathilde et Lucie.

Sandrine BAPTISTE a quatre enfants : Ophélie, Olivia, Lucie et Tom.

Voici le contenu du fichier de données Mères.

Maintenant, illustrons le fichier de données Enfants.

Si nous désirons connaître les enfants de Patricia AUGUY,

-> il nous faut concevoir une procédure qui réalise une recherche dans le fichier Mères et qui récupère l’identifiant de la mère recherchée.Ensuite, la procédure parcourt le fichier Enfants et chaque fois qu’elle rencontre l’identifiant de la mère dans la rubrique clé étrangère #Numéro_Mère elle affiche la ligne correspondante.

Comme nous le voyons, le principe général est très simple à comprendre.