L'analyse des données - Introduction cours Merise : les étapes d'analyse dans Merise

L'analyse des données - Introduction cours Merise : les étapes d'analyse dans Merise



L'analyse des données - Introduction cours Merise : les étapes d'analyse dans Merise
1- Introduction

2- L'analyse des données
2.1 Le recueil d'information
2.2 L'étude des liens sémantiques
2.3 La modélisation conceptuelle
2.4 La traduction logique
2.5 L'implantation physique

3- Merise
3.1 Historique rapide
3.2 Merise et les données
1 Introduction

Nous avons vu dans le cours précédent l'importance des données de l'entreprise pour définir le Système d'information, et plus particulièrement le domaine à informatiser. Pour analyser correctement ces données, il convient d'une part de pratiquer avec méthode et d'autre part d'analyser correctement l'ensemble des données ainsi que leurs interactions.

2 L'analyse des données

Le but de l’analyse des données est d’obtenir un schéma de l’organisation des données stable et invariant permettant de construire une solution physique, c'est à dire la base de données.

Pour parvenir à ce résultat, on procède par étapes :



Chaque étape conduit à la création de documents qui permet de formaliser les spécifications, et de communiquer avec les acteurs du système à informatiser.

2.1 Le recueil d'information

Cette étape est la plus importante, mais également la plus lourde. Elle se fait en collectant l'ensemble des données à partir :

• De documents écrits
• De l'analyse d''un produit existant dans certains cas
• De discussions avec les acteurs (décideurs, utilisateurs…)
• De spécifications écrites
• De l'analyse des flux du domaine
• …

Le but de ce recueil d'information est de formaliser l'ensemble des données dans un dictionnaire des données.
2.2 L'étude des liens sémantiques

Une fois les données répertoriées, il s’agit de rechercher quels sont les liens qui les unissent. Cette étude s’appuie sur le concept de dépendance fonctionnelle.

Ces dépendances sont ensuite formalisées dans un document présentant soit une matrice, soit un graphe des dépendances .

2.3 La modélisation conceptuelle

Une fois les dépendances établies, on peut établir le schéma global des données du domaine d'étude. Ce modèle doit être vérifié et validé avec soin dans la mesure ou c'est la base de la construction des autres phase. Cette phase dans notre cas fera appel à un des modèles de la méthode MERISE, à savoir le MCD Modèle Conceptuel des Données également appelé dans la littérature MEA (Modèle Entité Association).

Le document fourni à l'issue de cette étape sera un schéma (le MCD) validé par la vérification d'un certain nombre de règles, avec si possible l'aide d'outils de modélisation (Power AMC, Win Design ….)

2.4 La traduction logique

Cette phase de l’étude consiste en une traduction quasi automatique du modèle conceptuel. En appliquant des règles de transformation formalisées, on obtient un nouveau modèle, appelé modèle logique des données qui pourra être traduit et implanté dans une base de données.

En faisant appel à des outils de génie logiciel, cette phase peut être automatisée. Néanmoins, ce modèle pourra dans certains cas être modifié, optimisé en fonction de contraintes organisationnelles ou d'adaptation au logiciel de base de donnée choisi.

Ce modèle logique, également appelé modèle relationnel est écrit dans un langage intermédiaire ou sous forme graphique et présente la structure des données (les tables) ainsi que les relations entre ces données.

2.5 L'implantation physique

Cette étape est la dernière, et consiste à implanter la structure précédente directement au niveau du logiciel de base de donnée. Il faut donc adapter le modèle logique exprimé de façon généraliste aux contraintes du logiciel de base de donnée utilisé.

Cette étape également peut être automatisée à l'aide d'outils qui permettent la traduction du modèle logique en modèle physique.

3 Merise

Merise est une méthode d'analyse, mais n'est pas la seule. Néanmoins, c'est encore une de celle les plus utilisée dans le cadre de l'analyse des données. Elle prend en compte l'ensemble du développement d'un projet informatique en impliquant les différents acteurs et en fournissant pour chacune des phases d'analyse des outils permettant de formaliser ces différentes étapes. Dans le cadre de ce cours, seul le modèle conceptuel (MCD) sera vu. Les autres outils seront présentés ultérieurement.

3.1 Historique rapide

Merise est née en 1978 - 1979 à la suite d’une consultation lancée par le Ministère de l’industrie. Cette naissance est liée :
• A l’inadéquation des méthodes de l’époque aux traitements conversationnels faisant suite à la révolution technologique des années 70.
• Aux nombreux travaux sur les bases de données
• A un rapport ANSI/SPARC de 1975 préconisant pour la construction des bases de données, une approche en 3 niveaux :
o Conceptuel
o Externe
o Interne
• Aux formalismes de description des données issus de différents travaux :
o Le modèle « Entity-Relationship » de Chen
o Le modèle relationnel de Codd

La dernière version Merise/2 date de 90, rajoute certains formalismes et en complète certains existants dont le Modèle Conceptuel des Données
3.2 Merise et les données

Plus qu’une méthode, MERISE est avant tout un état d’esprit et une démarche pratique. La méthode Merise s'appuie sur des modèles de représentation des données (et des traitements), chacun décrivant le SI pour un niveau d’abstraction donné :



D'autres méthodes d'analyse existe dont une de plus en plus utilisée en programmation objet: UML, que vous verrez pour certains l'année prochaine.

Conception de base de données : méthodologie

• Conceptuel : Schéma entité-association(EA)
• Logique : Modèle relationnel
• Physique : SQL








Modèle relationnel



• Dans ce modèle, le concept principal est la relation (~ table)
• Les entités, les associations et les attributs multivalués sont traduits par une relation
• Modèle : Relation(Clé(s),Attribut, Attribut optionnel,...)
• Traduction:
Employee(SSN,Name)

(1) Traduction des attributs multivalués




Livre(ISBN,...)
LivreAuteur(ISBN,Auteur)
LivreAuteur.ISBN référenceLivre.ISBN
• Question : pourquoi(ISBN,Auteur)etpas(ISBN,Auteur)?
(2) Traduction des attributs composés



Client(ClientNo,Nom, AdresseRue,AdresseVille,AdressePays)
(3) Traduction des associations 'un à un' ou 'un à plusieurs'



Department(DNo,Name)
Employee(SSN,Name, DNo)
Employee.DNo référenceDepartment.DNo
• Association 'un à un' : si un des côtés est optionnel, la référence se place du côté obligatoire.
• Association 'un à plusieurs' : la référence se place du côté 'un' de l'association.



Employee(SSN,Name)
Project(PNo,Name)
EmpProj(SSN,PNo)
EmpProj.SSN référenceEmployee.SSN
EmpProj.PNo référenceProject.PNo
• Attention,(SSN,PNo) # (SSN,PNo)
(4) Traduction des généralisations : solution1



Employee(SSN, FName, MInit, LName, BirthDate, Address)
Secretary(SSN, TypingSpeed)
Secretary.SSN référence Employee.SSN
Technician(SSN, TechGrade)
Technician.SSN référence Employee.SSN
Engineer(SSN, EngType)
Engineer.SSN référence Employee.SSN
• + contraintes d'intégrité
• Attention aux références dessous-sous-entités
(4) Traduction des généralisations : solution2



Secretary(SSN, FName, MInit, LName, BirthDate, Address, TypingSpeed)
Technician(SSN, FName, MInit, LName, BirthDate, Address,,TechGrade)
Engineer(SSN, FName, MInit, LName, BirthDate, Address, EngType)
• + contraintesd'intégrité
(4) Traduction des généralisations : solution3



Employee(SSN, FName, MInit, LName, BirthDate, Address, TypingSpeed,
TechGrade, EngType)
• + contraintesd'intégrité

Que peut-on dire des traductions des généralisations :
• Totale,non-exclusive?
• Partielle,exclusive?
• Partielle,non-exclusive?
Exercice1 : Gestion des emprunts dans une Bibliothèque




• La date d'emprunt doit être inférieure à la date de retour.
• La date d'emprunt doit être postérieure à la date d'achat.
• Un livre ne peut être loué qu'une fois à un moment précis : il ne peut y avoir de recouvrement dans les dates pour la location d'un même livre.

Exercice 2 : Plats


• La quantité doit être strictement supérieure à zéro.

Exercice 3 : Université



Exercice 4 : Analyse financière



• La quantité d'actions dans un indice doit être strictement supérieure à zéro.
• Cours minimum <= cours d'ouverture, cours de fermeture, <= cours maximum.
• Les actions d'un indice appartiennent au même marché que l'indice.

Exercice 5 : Organisation d'un colloque



• L'heure de présentation d'un article doit être comprise dans les heures de la session.
• L'orateur d'un article doit être un auteur de cet article.
• Un expert ne peut pas avoir le même employeur que celui d'un auteur d'un article qu'il évalue.
• Un président de session ni un orateur ne peuvent être au même moment à deux sessions.
• Deux articles ne peuvent pas être présentés à la même session à la même heure.


-----------------------------------------------------------------------------------------------------
Correction
-----------------------------------------------------------------------------------------------------

Bases de données
Traduction du modèle entité-association vers le modèle relationnel

Corrections
Exercice 1 : Bibliothèque

Client(SSN, Nom, Prénom, AdRue, AdNuméro, AdCodePostal, AdVille)

Emprunt(Numéro, SSN, ISBN, DateEmprunt, DateRetour)
SSN reference Client.SSN
ISBN reference LIvre.ISBN

Livre(ISBN, Titre, DateAchat)

LivreAuteur(ISBN, Auteur)
ISBN référence Livre.ISBN
• Emprunt.DateEmprunt < Emprunt.DateRetour
• Pour l'emprunt d'un livre, Emprunt.DateEmprunt >= Livre.DateAchat
• Pour tous les emprunts d'un même livre, il ne peut y avoir de recouvrement dans les dates.

Exercice 2 : Plats

Plat(Nom, Origine)

Ingredient(Nom, Unité)

Contient(NomPlat, NomIngredient, Quantité)
NomPlat reference Plat.Nom
NomIngredient reference Ingredient.Nom
• Contient.Quantité >= 1

Exercice 3 : Université

Professeur(Matricule, Titre, Nom, Prenom, AdRue, AdNuméro, AdCodePostal, AdVille)

Cours(Mnémonique, Professeur, Intitulé, Résumé)
Professeur reference Professeur.Matricule

Filière(Code, Nom, Professeur)
Professeur reference Professeur.Matricule

Etudiant(Matricule, Nom, Prenom, AdRue, AdNuméro, AdCodePostal, AdVille, Filière)
Filière reference Filière.Code

EtudiantCours(Matricule, Mnémonique)
Matricule reference Etudiant.Matricule
Mnémonique reference Cours.Mnémonique
• Professeur est unique dans la relation Filière (un professeur peut diriger au maximum une filière)
• Pour tout Etudiant.Matricule, il existe au moins un EtudiantCours.Matricule (un étudiant suit au moins un cours)
• Pour tout Filière.Code, il existe au moins un Etudiant.Filière (une filière possède au moins un étudiant)


Exercice 4 : Analyse financière

Première solution

Actualité(Lien, Titre, Source, Date, Description)

ProduitFinancier(Code, Nom, MNom, MVille, MPays, Type)
ProduitFinancier.(MNom, MVille, MPays) référence Marche.(Nom, Ville, Pays)

ActualitéProduit(Lien,Code)
Lien reference Actualite.Lien
Code reference ProduitFinancier.Code

Marché(Nom, Ville, Pays, Devise)

Cours(Code, Date, Volume, CoursO, CoursF, CoursMin, CoursMax)
Code reference ProduitFinancier.Code (où ProduitFinancier.Type == "Action")

Compose(CodeIndice, CodeAction, Quantité)
CodeIndice reference ProduitFinancier.Code (où ProduitFinancier.Type == "Indice")
CodeAction reference ProduitFinancier.Code (où ProduitFinancier.Type == "Action")

• Pour tout Actualité.Lien, il existe au moins un ActualitéProduit.Lien (une actualité concerne au moins un produit)
• Pour tout Marché.(Nom, Ville, Pays), il existe au moins un ProduitFinancier.(MNom, MVille, MPays) (un marché contient au moins un produit)
• ProduitFinancier.Type est soit "Indice" soit "Action"
• Pour un cours, CoursMin <= (CoursO, CoursF) <= CoursMax
• Pour tout ProduitFinancier.Code où Type = "Action", il existe au moins un Cours.Code (une action a au moins un cours)
• Un CodeIndice apparaissant dans Compose y apparaît au moins deux fois.
• Compose.Quantité >= 1
• Pour tout tuple dans la relation Compose, CodeIndice et CodeAction référencent des produits d'un même marché.

Deuxième solution

Actualité(Lien, Titre, Source, Date, Description)

ActualitéProduit(Lien,Code)
Lien reference Actualite.Lien
Code reference ProduitFinancier.Code

Marché(Nom, Ville, Pays, Devise)

ProduitFinancier(Code, Nom, MNom, MVille, MPays)
ProduitFinancier.(MNom, MVille, MPays) référence Marche.(Nom, Ville, Pays)

Action(Code)
Code reference ProduitFinancier.Code

Indice(Code)
Code reference ProduitFinancier.Code

Cours(Code, Date, Volume, CoursO, CoursF, CoursMin, CoursMax)
Code reference Action.Code

Compose(CodeIndice, CodeAction, Quantité)
CodeIndice reference Indice.Code
CodeAction reference Action.Code

• Pour tout Actualité.Lien, il existe au moins un ActualitéProduit.Lien (une actualité concerne au moins un produit)
• Pour tout Marché.(Nom, Ville, Pays), il existe au moins un ProduitFinancier.(MNom, MVille, MPays) (un marché contient au moins un produit)
• Pour un cours, CoursMin <= (CoursO, CoursF) <= CoursMax
• Pour tout Action.Code, il existe au moins un Cours.Code (une action a au moins un cours)
• Action.Code est différent de tous les Indice.Code
• Un CodeIndice apparaissant dans Compose y apparaît au moins deux fois.
• Compose.Quantité >= 1
• Pour tout tuple dans la relation Compose, CodeIndice et CodeAction référencent des produits d'un même marché.
• Pour tout ProduitFinancier.Code, il existe soit un Action.Code soit un Indice.Code

Exercice 5 : Organisation d'un colloque

Personne(SSN, nom, adresse, employeur)

Expert(SSN, titre, email, tel, fax)
Expert.SSN référence Personne.SSN

Auteur(SSN, titre)
Auteur.SSN référence Personne.SSN

AuteurPrincipal(SSN, email, tel, fax)
AuteurPrincipal.SSN référence Auteur.SSN

Orateur(SSN, CV)
Orateur.SSN référence Auteur.SSN

Article(titre, nbPages, AuteurPrincipal)
AuteurPrincipal référence AuteurPrincipal.SSN

ArticleMot(titre, mot)
titre reference Article.titre

ArticleAccepté(titre, heure, orateur, thème, dateJour, dateMois, dateAnnée, dateHeureDebut, dateHeureFin)

titre reference Article.titre
orateur référence Orateur.SSN
thème, dateJour, dateMois, dateAnnée, dateHeureDebut, dateHeureFin référence Session.thème, dateJour, dateMois, dateAnnée, dateHeureDebut, dateHeureFin

Contribue(titre, auteur)
titre référence Article.titre
auteur référence Auteur.SSN

Evaluation(expert, titre, note)
expert référence Expert.SSN
titre référence Article.titre

Session(thème, dateJour, dateMois, dateAnnée, dateHeureDebut, dateHeureFin, président)
président référence Personne.SSN

• Pour tout AuteurPrincipal.SSN, il existe au moins un Article.AuteurPrincipal
• Pour tout Orateur.SSN, il existe au moins un ArticleAccepté.orateur
• Pour tout Session.thème, dateJour, dateMois, dateAnnée, dateHeureDebut, dateHeureFin, il existe au moins un ArticleAccepté.thème, dateJour, dateMois, dateAnnée, dateHeureDebut, dateHeureFin
• Pour tout Auteur.SSN, il existe au moins un Contribue.auteur
• Un titre apparaît au plus trois fois dans la relation Evaluation
• Pour tout Expert.SSN, il existe au moins un Evaluation.expert
• Pour la Session d'un ArticleAccepté, ArticleAccepté.heure est compris entre Session.DateHeureDébut et Session.DateHeureFin
• Pour un même Article.titre, ArticleAccepté.orateur doit être parmi Contribue.auteur
• Pour un Article.titre, Evaluation.expert ne peut avoir le même employeur (personne.employeur) que Contribue.auteur.
• Deux ArticleAccepté de la même sesion ne peuvent être présentés à la même heure
• Pour un Session.président, il ne peut y avoir deux sessions au même moment
• Pour un ArticleAccepté.orateur, il ne peut y avoir deux sessions au même moment
Le dictionnaire des données Cours Merise Elaboration d'un Dictionnaire des données DD
1- Introduction

2- Les techniques et les outils
2.1 La localisation des informations
2.2 Les techniques de recueil
2.2.1 Les documents
2.2.2 Les entrevues
2.2.3 Les questionnaires

3- Classification des données

4- Typologie des données
4.1 Notion de domaine
4.2 Types de données

5- Le dictionnaire des données
5.1 Formalisme
5.2 Exploitation

1- Introduction

Le dictionnaire des données est en fait le résultat de la phase de collecte des données. C'est comme vu précédemment la première phase à l'informatisation d'un SI (ou d'un domaine d'un SI). Cette phase est également appelée recueil d'information.

Cette phase de recueil est effectuée en plusieurs étapes :




2- Les techniques et les outils

2.1 La localisation des informations

Le premier problème à résoudre est de trouver l’information. On recherchera dans :

• Les documents
• Les règlements
• Les normes, les procédures,
• Les bases de données, les fichiers
• …

Certaines informations sont difficiles à mettre en évidence car elles ne sont pas formalisées. Il faudra alors rechercher dans des domaines similaires le besoin d'information.

2.2 Les techniques de recueil

Pour recenser les informations, on utilise essentiellement :

• L’étude de documents
• Les entrevues
• Parfois les questionnaires

2.2.1 Les documents

L’essentiel des données peut être retrouvé sur les documents en circulation.

On s’efforcera :

• De rassembler un maximum de documents (fiches, impressions, états, journaux …),
• De s’assurer que les documents sont encore valides,
• D’utiliser des documents remplis et de repérer les informations réellement utilisées afin d'avoir une vue claire de ce qui est utile et parfois même non formalisé mais nécessaire au fonctionnement
• D’attacher une attention particulière aux documents non formalisés (ils traduisent souvent l’existence d’une évolution non prise en compte par les procédures ou d’une inadéquation de la procédure en cours),
• De décoder les codes et abréviations utilisés.

2.2.2 Les entrevues

Les entrevues sont des éléments importants qui de plus privilégient le contact et l'écoute. Ils devront faire l'objet de prise de note et de synthèse afin d'en augmenter leur efficacité.

• Avec la direction

Le but est d'obtenir des informations générales : organisation des services, objectifs stratégiques, procédures et règles de gestion globales…En finalité, cette entrevue permettra de cadrer exactement le domaine à informatiser afin d'éviter des débordements sur d'autres domaines non prévus au départ.

• Avec les utilisateurs

Cette partie avec les utilisateurs est primordiale dans la mesure où ce sont les acteurs importants qui utilise les outils au quotidien, et qui peuvent apporter des éléments importants sur les données manipulées ainsi que sur les interactions entre elle. De plus, le fait d'impliquer les utilisateurs dés le début du projet permet de faciliter la phase ultérieure de mise en place. Cette ou ces entrevues ont donc pour objectif :

o Obtenir une description précise et détaillée des procédures
o Mettre en évidence des dysfonctionnements
o Obtenir des propositions, des critiques, des suggestions
o Rechercher des procédés non officiels

2.2.3 Les questionnaires

C’est un outil assez délicat à utiliser pour le recensement des données. Il faut donc une bonne connaissance du domaine étudié, proposer des réponses exhaustives, limiter les questions ouvertes (réticence à la rédaction). Les questionnaires peuvent être utilisés pour préciser un problème donné, une chronologie d’événements, obtenir un avis sur une procédure, des suggestions… Cet outil est assez peu utilisé.

3- Classification des données

On peut distinguer :

• Les données élémentaires : l’information se confond avec la valeur prise par la donnée. Par exemple, un nom, une date… Ces données doivent être recensées de manière exhaustive.
• Les données calculées ou déduites : elles sont obtenues par l’application d’un traitement mathématique ou logique. Ces données sont associées à des règles de calcul (règles de gestion). Il faut penser à bien identifier et conserver la règle de gestion qui permet d’arriver au résultat. Cette règle permettra ensuite par traitement d'obtenir le résultat désiré.
• Les données composées : certaines données sont regroupées en une même entité sémantique (par exemple une adresse). Ces informations doivent être décomposées en données élémentaires. Toutefois, s’il est montré qu’une donnée composée n’est jamais décomposée dans la chaîne de traitement de l’information, on peut envisager de la conserver telle quelle.

4- Typologie des données

4.1 Notion de domaine

Certaines données ont des valeurs prises dans le même ensemble. Par exemple, langue parlée, langue lue et langue maternelle prennent leur valeur dans un ensemble « Langues ».

On appelle domaine l’ensemble des valeurs prises par une donnée, indépendamment du contexte de son utilisation.

L’identification d’un domaine est une opération importante lors du recueil des données. Il s’agit de déterminer précisément l’ensemble des valeurs possibles s’il s’agit d’un domaine exhaustif ou les règles de représentation (codification, types, bornes…) dans les autres cas.

Exemples :

o domaine exhaustif : permis de conduire (A, A1, B, C, D, C1, E, F)
o domaine borné : notes (min 0, max 20)
o domaine typé : noms (30 caractères alphabétiques)

4.2 Types de données

Les types de données ont un sens plus restrictif que le domaine. Alors que le domaine s’applique à la valeur d’une donnée, le type est une contrainte physique liée à la manière dont sera stockée la donnée dans le système d’information.

Les principaux types à retenir sont :

o Alphanumérique (AN) (on cherchera à déterminer la taille maximale)
o Numérique (on peut préciser entier, réel, monétaire…)
o Date (Date/Heure, Date, Heure )
o Logique ou booléen (L ou B)

5- Le dictionnaire des données

Pendant la phase de conception, les données recueillies et spécifiées sont inscrites dans un dictionnaire. Ce dictionnaire est un outil important car il constitue la référence de toutes les études effectuées ensuite.

5.1 Formalisme

Les données sont présentées dans un tableau.



5.2 Exploitation

L’ensemble des données recueillies constitue le dictionnaire des données brut. Toutes les données ne seront pas utilisées de la même manière. Pour la phase de modélisation des données, il convient d’épurer ce dictionnaire brut :

• des synonymes (données ayant le même sens) car ils constituent des redondances ambiguës,
• des polysèmes (mots ayant plusieurs sens) car ils peuvent provoquer des malentendus.

Les données calculées doivent être examinées avec soin.

La règle est la suivante :

Si une donnée calculée peut être obtenue par l’application d’un traitement à partir de données élémentaires valides, on peut la supprimer du dictionnaire.

Par exemple :

Examinons le cas de la donnée calculée MntCde du dictionnaire. Sa valeur est obtenue par l’application du calcul : MntCde = PrixCde * QteCde

Les données élémentaires (PrixCde et QteCde) qui participent à son calcul sont présentes. On peut donc éliminer cette donnée pour la phase de modélisation conceptuelle.

Par contre, si la formule de calcul avait été la suivante : MntCde = PrixProduit * QteCde

dans laquelle le PrixProduit est le prix catalogue du produit. Si MntCde disparaît du dictionnaire, on serait dans l’incapacité de reconstituer ce montant car la donnée PrixProduit peut évoluer dans le temps (changement de tarif du Produit). Il est donc impératif dans ce cas, soit de garder MntCde, soit de rajouter dans le dictionnaire la ou les données permettant d'obtenir ce résultat.