94675249-merise-module-1

Méthode de modélisation Merise

Module N°1 Concevoir une base de données

(MCC, MCD, MLD)

PSBDMF!Programme de formation Supinfo

Laboratoire ORACLE Auteur : Aurélie Vuaroqueaux Date : 07/11/2002 - v 1.1 Nombre de pages : 1 http://www.labo-oracle.com Ecole Supérieure d'Informatique 23 rue Château Landon 75010 PARIS http://www.supinfo.com

CONCEVOIR UNE BASE DE DONNEES (MCC, MCD, MLD) - v 1.1

Laboratoire Oracle SUPINFO www.labo-oracle.com

04/09/2002

Page 0

TABLE DES MATIERES

1 PRESENTATION GENERALE DE MERISE_________________________________________ 0 1.1 Les principes généraux___________________________________________________ 0 1.2 Présentation des différents niveaux et des modèles associés ___________________ 0

1.2.1 Le niveau conceptuel _______________________________________________ 0 1.2.2 Le niveau organisationnel ____________________________________________ 0 1.2.3 Le niveau logique __________________________________________________ 0 1.2.4 Le niveau physique _________________________________________________ 0

1.3 Présentation des étapes de développement d’un SI ___________________________ 0 2 LE MODELE CONCEPTUEL DES COMMUNICATIONS_______________________________ 0

2.1 Les concepts ___________________________________________________________ 0 2.2 Le graphisme ___________________________________________________________ 0 2.3 Les communications possibles entre les acteurs conceptuels __________________ 0 2.4 Les étapes de construction du MCC ________________________________________ 0 2.5 Synoptique _____________________________________________________________ 0 2.6 Exemple : Gestion des livres dans une bibliothèque ___________________________ 0

3 LE MODELE CONCEPTUEL DES DONNEES_______________________________________ 0 3.1 Le MCD et ses concepts de base ___________________________________________ 0

3.1.1 Le concept d’entité (ou objet) _________________________________________ 0 3.1.2 Le concept de propriétés_____________________________________________ 0 3.1.3 Le concept d'association_____________________________________________ 0 3.1.4 Le concept de cardinalités ___________________________________________ 0

3.2 Les règles de normalisation et de vérification ________________________________ 0 3.2.1 Règle N°1 et N°2 concernant les entités et leurs propriétés __________________ 0 3.2.2 Règle N°3 concernant les relations_____________________________________ 0 3.2.3 Règle N°4 et N°5 concernant l’ensemble du MCD _________________________ 0

3.3 Exemple : Le championnat d'athlétisme _____________________________________ 0 4 LE MODELE LOGIQUE DES DONNEES ___________________________________________ 0

4.1 Le MLD et ses concepts de base ___________________________________________ 0 4.2 Passage du MCD au MLD _________________________________________________ 0 4.3 Passage du MLD au DPD (Description Physique des Données) __________________ 0



04/09/2002

Page 0

Préambule

Avant de réaliser un projet informatique, il faut pratiquer une analyse informatique. Cette analyse consiste à comprendre et modéliser le système d’information sur lequel on travaille.

Un système d’information regroupe toutes les informations d’un domaine précis. Par exemple, toutes les informations concernant la gestion des employés : les coordonnées de l’employé, son grade, son département, ses activités…

L'efficacité et la validé de l’analyse reposent sur la qualité de la communication entre les utilisateurs (maîtrise d’ouvrage, MOA) et les informaticiens (maîtrise d’œuvre, MOE). Pour obtenir une bonne communication, les informaticiens utilisent une méthode d’analyse.

Une méthode d'analyse est constituée de trois éléments indispensables :

- La démarche : il s'agit du processus opératoire qui permet d'effectuer le travail de modélisation, de description et de réalisation du système d'information.

- Les modèles : il s'agit des concepts normalisés qui permettent de construire et d'aménager le

système d'information. Ils sont présentés sous forme de schéma afin de permettre une représentation simple de la réalité et de faciliter le raisonnement.

- Les outils : il s'agit d'abord de la technique employée pour analyser et concevoir un système

d'information, puis du support papier ou logiciel employé pour conserver une trace du travail. Il existe des Ateliers de Génie Logiciel (AGL) qui permettent de concevoir des modèles, de créer des documentations, de faire des simulations, des évaluations...

La méthode d'analyse MERISE est une méthode de conception et de développement de

systèmes d'information. Elle a été créée en 1977 par la volonté des autorités publiques, désireuses de doter les administrations et les entreprises publiques d'une méthodologie rigoureuse tout en intégrant les aspects nouveaux d'informatique répartie et de bases de données.



04/09/2002

Page 0

1 PRESENTATION GENERALE DE MERISE

1.1 Les principes généraux La méthode Merise est une méthode de conception des systèmes d’information (SI), mais aussi une démarche méthodologique de développement de SI. La méthode est une approche globale du SI menée parallèlement et simultanément sur les données et les traitements. Elle permet une description du SI sur différents niveaux :

- niveau conceptuel, - niveau organisationnel, - niveau logique, - niveau physique ou opérationnel.

Ces quatre niveaux constituent le cycle d’abstraction du SI. La description des données du SI suit un formalisme de représentation précis, simple et rigoureux. Ce formalisme a été normalisé au plan international par l’ISO sous le nom de « ENTITE RELATION ». La représentation visuelle contribue à l’établissement d’un dialogue constructif entre tous les partenaires qui collaborent pour concevoir ensemble le SI. Le second point de Merise est le découpage du processus de développement en quatre étapes :

- Etude préalable - Etude détaillée - Réalisation - Mise en œuvre

Ce découpage a été repris et normalisé par l’AFNOR (norme Z67 – 101 : recommandations pour la conduite des projets informatiques). Il correspond au cycle de vie d’un SI. L’ensemble des résultats produis à chaque étape constitue le cycle de décision. Merise permet d’établir une description détaillée de la structure de travail à mettre en place pour mener à bien le développement du SI. Cette structure est « théoriquement » composée d’un COMITE DIRECTEUR, d’un GROUPE PROJET et d’un COMITE UTILISATEUR.

1.2 Présentation des différents niveaux et des modèles associés

Ils existent différents niveaux d’abstraction allant de l’abstrait au concret. Ces niveaux d’abstraction sont répartis en deux sous-ensembles :

- Niveau conceptuel et niveau organisationnel : description du SI sans prendre en compte les aspects techniques liés à l’informatisation.

- Niveau logique et niveau physique : description du SI en prenant compte de la technologie informatique de la solution retenue pour l’informatisation.



04/09/2002

Page 0

Abstraction

Niveau conceptuel MCD MCT MCC

Prise en compte de l’organisation

Niveau organisationnel

MOD MOT MOC

Prise en compte des choix logiques

Niveau logique MLD MLT MLC

Prise en compte des choix techniques

Niveau physique

MPD MPT MPC

1.2.1 Le niveau conceptuel Le niveau conceptuel est constitué des trois modèles suivant :

- Le Modèle Conceptuel des Données (MCD) : Diagramme entité-relation permettant de modéliser le SI sans prendre en compte des détails liés à sa mise en œuvre physique.

- Le Modèle Conceptuel des Traitements (MCT) : Diagramme représentant l’activité ou un sous-ensemble de l’activité d’une entreprise indépendamment des choix d’organisation et des moyens d’exécution.

- Le Modèle Conceptuel des Communications (MCC) : Diagramme représentant les informations transmises et récupérées par le domaine de gestion.

Ce niveau d’abstraction répond à la question « quoi ? ». Il s’agit de rechercher toutes les données qui circulent et qui sont traitées dans le système d’information et de les modéliser sans tenir compte des aspects organisationnels, logiques et physiques. Exemple :

Un client, identifié par son numéro de client, son nom, son prénom et son adresse, passe une commande identifiée par son numéro de commande et sa date. Cette commande est constituée de produits identifiés par un numéro de produit, un libellé et un prix. Cette commande est ensuite facturée au client par l’intermédiaire d’une facture (n° facture, date de facture, montant de la facture) Comment les données circulent elles ?

o le client passe une commande o la commande est facturée au client

Quelles sont les données ? o Le client : n° client, nom, prénom, adresse o La commande : n° commande, date de la commande o La facture : n° facture, date de la facture, montant de la facture

Comment sont elles liées entre elles ? o Une commande n’appartient qu’à un seul client o Un client peut passer plusieurs commandes o Une commande est constituée de produits o Une facture ne se rapporte qu’à une seule commande



04/09/2002

Page 0

1.2.2 Le niveau organisationnel Le niveau organisationnel permet de prendre en compte les choix d’organisation, à savoir :

- la répartition des traitements entre l’homme et la machine, - le mode de fonctionnement (temps réel ou temps différé), - l’affectation des données et des traitements par type de site organisationnel et par type de

poste

Ce niveau d’abstraction répond à la question « qui fait quoi et où ? ». Exemple :

L’acheminement du courrier par la Poste Un client dépose une lettre dans une boîte aux lettres. Le facteur passe à une heure déterminée pour ramasser le contenu de la boîte. Il dépose les lettres ramassées au centre postal dont il dépend. A une heure déterminée, une entreprise de transport achemine les lettres à distribuer au centre de tri postal. A leur arrivée, les lettres sont triées par une machine suivant leur format. Les lettres ne possédant pas un format standard sont séparées des autres et envoyer au service de tri manuel. Les enveloppes non timbrées, suspectes, possédant une adresse erronée ou illisible ne sont pas acheminées aussi rapidement que les autres enveloppes. Elles sont réparties suivant leur anomalie dans différents services d’enquête qui ne seront pas détaillés. Les enveloppes ne possédant aucune anomalie sont triées suivant leur destination et acheminées, selon les besoins, par camion, train ou avion... Qui fait quoi ?

o Un service de transport s’occupe de l’acheminent du courrier entre les centres postaux et les centres de tris

o Les facteurs relèvent et distribue le courrier o Les centres de tris s’occupent du tri du courrier et possèdent un service d’enquête

pour les enveloppes non valides. o Le centre postal stocke le courrier relevé par les facteurs et le courrier à distribuer.

Le niveau organisationnel est constitué des trois modèles suivants :

- Le Modèle Organisationnel des Données (MOD) : Diagramme représentant l’ensemble des données par type de site organisationnel (formalisme identique au MCD)

- Le Modèle Organisationnel des Traitements (MOT) : Diagramme représentant l’ensemble des traitements en prenant compte de l’organisation de l’entreprise.

- Le Modèle Organisationnel des Communications (MOC) : Diagramme représentant les communications entre les acteurs organisationnels qui composent le domaine et les acteurs externes.

1.2.3 Le niveau logique Ce niveau d’abstraction répond à la question « Comment ? ». Le niveau logique est constitué des trois modèles suivants :

- Le Modèle Logique des Données (MLD) ou Modèle Relationnel des Données (MRD) : diagramme issue du MCD et permettant de prendre en compte la structuration technique propre au stockage informatisé.

- La Description Logique des Traitements : Diagramme représentant la conception technique (structuration en unités de traitements de type temps réel ou de type temps différé).

- Le Modèle Logique des Communications : Diagramme de répartition du dialogue entre l’homme et la machine. Il est déployé pour spécifier en détail une composante logicielle interactive d’un projet.

Depuis quelques années, la technologie des systèmes de gestion des bases de données s’est stabilisée. Dans les années 80, c’est le modèle de structuration de données CODASYL qui a été très utilisé. Mais depuis la fin des années 80, c’est le modèle RELATIONNEL qui s’est largement imposé.



04/09/2002

Page 0

Aujourd’hui, nous sommes en présence d’un standard pour la description logique : le Modèle Relationnel des Données. Aucune normalisation n’a été établie et adoptée par les informaticiens car la technologie évolue trop rapidement et les solutions techniques possibles sont trop diverses.

1.2.4 Le niveau physique La description physique est étroitement liée aux choix techniques informatiques concernant le système de gestion des données. Ce niveau d’abstraction répond aussi à la question « Comment ? ». Aucun formalisme universel n’est disponible aujourd’hui pour le niveau physique, c’est pourquoi les représentations sont appelées des descriptions et non des modèles. Le niveau physique est constitué des trois modèles suivants :

- La Description Physique des Données : Diagramme table-référence qui permet de modéliser le SI en tenant compte des détails de mise en œuvre physique. Le DPD peut corespondre :

o à un script de création des tables en fonction du SGBD utilisé. o au stockage des données dans des fichiers suivant le type des fichiers, leur

organisation. - La Description Opérationnelle (ou Modèle Physique) des Traitements : Diagramme permettant

de détailler au niveau opérationnel chaque tâche logicielle par des actions logicielles élémentaires.

- La Description Physique des Communications : Diagramme représentant les communications entre acteurs et machines permettant de spécifier en détail les tâches logicielles.



04/09/2002

Page 0

1.3 Présentation des étapes de développement d’un SI

ETAPES PHASE DE L’ETAPE MODELES OBJECTIFS SCHEMA DIRECTEUR

Choix d’une stratégie. Constitution d’équipes. Ebauche de solutions globales.

ETUDE D’OPPORTUNITE

Evaluation projective des résultats escomptés. Décision de suivre la stratégie du schéma directeur.

Description de l’existant MOC, MCC Description du système actuel en se basant sur des documents et des interviews.

Analyse de l’existant MOT, MCT, MOD, MCD

Modélisation conceptuelle des traitements et des données de l’existant.

Spécifications des besoins Tableaux analytiques

Critique de l’existant et définition des orientations du nouveau système.

Modélisation conceptuelle et scénarios organisationnels du nouveau système

MCT, MCD, MCC, MOT(s), MOC(s)

Modélisation conceptuelle et organisationnelle à partir des nouvelles règles de gestion et d’organisation.

ETUDE PREALABLE sur le Domaine

Production du dossier d’étude

Maquettage des documents nouveaux, Modèles externes, Modèle global des données

MOD, Validation du MCD global

Concevoir les nouveaux documents ou restaurer les documents existants. Construire les MODs correspondant et valider le MCD global du projet.

Modèle logique MLC, MLT, MLD Elaboration des solutions logiques. Identification des tâches logicielles. Choix du type de MLD en fonction du SGBD envisagé.

Optimisation du MLD MLD optimisé Optimisation du MLD pour réduire les encombrements ou limiter les temps d’accès.

ETUDE DETAILLEE sur le projet

Production du dossier de spécifications détaillées

Modélisation physique et optimisation des données

MPD Définition des modes d’organisations des données. Création des fichiers…

Maquettage des écrans IHM (Interface Homme/ Machine)

Conception des écrans et spécification des actions des rubriques de l’IHM sur la base de données.

ETUDE TECHNIQUE sur le projet

Spécification détaillée des traitements et des communications

Fiche de description des PF (Procédures fonctionnelles, MPC, MPT

Elaboration du MPC. Détermination des actions logiques : actions environnementales, contraintes dynamiques, algorithmes et règles associées aux tâches logiques.

Jeux d’essais Programmation

REALISATION de l’application Tests

Recette de l’application MISE EN ŒUVRE de l’application Assistance aux utilisateurs



04/09/2002

Page 0

Remarque : Les aspects logique et physique (tels que les systèmes informatiques, les moyens de stockage, le réseau, les logiciels, le degrés de portabilité et de sécurité…) ne sont pas pris en compte dans l’étude de l’existant. Mais ils peuvent être rajoutés au tableau.

2 LE MODELE CONCEPTUEL DES COMMUNICATIONS

2.1 Les concepts Le MCC représente les informations transmises et récupérées par le domaine de gestion (ou domaine d’étude). Les concepts manipulés dans les communications et utilisés dans ce cours sont les suivants :

- Domaine d’étude : le domaine englobe les activités ou les services concernés par une étude. Il ne peut y avoir q’un seul domaine d’étude.

- Activité du domaine d’étude

Exemple : Le domaine d’étude GESTION DES VENTES peut être divisé en quatre activités : gestion des commandes, gestion des clients, gestion des stocks, contentieux.

- Acteur Externe (ou Partenaire) : un acteur externe est extérieur au domaine d’étude mais

communique avec celui-ci. Il peut s’agir d’une activité, d’un service, d’une personne, d’un profil (secrétaire, ingénieur, directeur…), d’un matériel ou d’un lieu géographique.

Exemple : Le domaine d’étude GESTION DES VENTES gère les clients, les commandes, le stock et le service contentieux. Donc le domaine est en interaction avec des clients (ventes) et des fournisseurs (commandes). Donc les clients et les fournisseurs seront modélisés comme deux acteurs externes.

- Domaine connexe : il s’agit d’une activité ou d’un service du domaine d’étude en étroite liaison et dont la gestion ne doit pas être prise en compte.

Exemple : En admettant que le domaine d’étude GESTION DES VENTES ne doive pas prendre en compte la gestion du service contentieux, le service contentieux qui n’est pas un partenaire et qui ne doit pas se trouver dans le domaine, est modélisé comme étant un domaine connexe.

- Communication (ou Flux) : échanges entre les différentes parties prenantes du système et

entre le système et son environnement.

Exemple : L’activité « gestion des commandes » s’occupe de passer des commandes à ses fournisseurs. L’activité « gestion des clients » s’occupe de la réaliser des ventes aux clients. L’activité « gestion des clients » envoie un avis de non paiement au service contentieux. Le service contentieux envoie des rappels de non paiement au client. …



04/09/2002

Page 0

2.2 Le graphisme Ensemble des symboles graphiques des différents concepts manipulés dans les communications et utilisés dans ce cours :

2.3 Les communications possibles entre les acteurs conceptuels

Le système est représenté par un domaine d’activités en interaction avec l’environnement des acteurs externes. Tableau récapitulatif des communications possibles et impossibles entre les différents acteurs conceptuels :

EMETTEUR RECEPTEUR Domaine Domaine Domaine Acteur Externe Domaine Domaine connexe

Activité Activité Activité Acteur Externe Activité Domaine connexe

Domaine connexe X Domaine connexe Domaine connexe X Acteur Externe

Acteur Externe X Acteur Externe

2.4 Les étapes de construction du MCC La représentation du MCC se divise en plusieurs étapes. Chaque étape nécessite une relecture du texte définissant le système d'information :

- Rechercher le domaine d'étude - Rechercher le(s) partenaire(s) - Rechercher le(s) domaine(s) connexe(s) éventuel(s) - Etablir les flux d'informations circulants entre le domaine et les intervenants (extérieurs) - Déterminer les activités du domaine - Etablir les flux d'informations circulants entre les activités du domaine

Acteur Externe Activité Flux

Domaine Domaine Connexe



04/09/2002

Page 0

2.5 Synoptique

Domaine

Partenaire

flux 1

flux 2

flux 3

flux 4

Domaineconnexe

Activité 1

Activité 2

flux 5

flux 6

flux 7

flux 8

flux 9flux 10

Il peut y avoir plusieurs domaines connexes et plusieurs partenaires. Il faut éviter la communication entre les partenaires et entre les domaines connexes. Attention, le domaine d’étude ne gère pas l’activité d’un domaine connexe ni d’un partenaire.

2.6 Exemple : Gestion des livres dans une bibliothèque Description du SI :

Les abonnées à la bibliothèque peuvent faire des demandes d'achats de livres nouveaux, ces

demandes sont remises à un bibliothécaire qui les classifie. En fin de semaine le responsable de la bibliothèque examine ces demandes, décide les achats et fait les commandes aux éditeurs. Ceux-ci envoient séparément les livres et les factures.

Lors de la livraison d'une commande, un bibliothécaire contrôle la concordance avec la commande. Pour chaque exemplaire, une fiche est établie, elle accompagnera le livre lors de son rangement dans les rayons.

Le responsable de la bibliothèque, lorsqu'il reçoit les factures, contrôle la conformité de la livraison et de la facture et envoie au service comptable un ordre de paiement. Dans un premier temps, il faut déterminer le domaine d'étude :

La question essentielle à se poser est " Que décrit le sujet ? " Dans notre exemple, le sujet décrit la façon dont une bibliothèque gère les achats de ses livres. Le domaine d'étude pourrait être "La bibliothèque" ou "Gestion des achats de livres".

Dans un deuxième temps, il faut rechercher les partenaires éventuels :

La question à se poser est " Qui intervient dans la gestion des achats de livres ? " En relisant attentivement le texte, on relèvera cinq partenaires éventuels : l'abonné, le bibliothécaire, les éditeurs, le responsable de la bibliothèque, le service comptable. Les partenaires sont des acteurs externes à la bibliothèque. C'est pourquoi il faut distinguer, parmi cette liste, ceux qui font parti de la bibliothèque ou d'un service indépendant, c'est-à-dire le bibliothécaire, le responsable de la bibliothèque et le service comptable.

Dans un troisième temps, il faut rechercher les domaines connexes éventuels :



04/09/2002

Page 0

La question à se poser dans ce cas est "Y a t-il des services indépendants qui interviennent dans la gestion des achats de livres ?" On relèvera, en tant que domaine connexe, le service comptable qui s'occupe des ordres de paiement.

Dans un quatrième temps, il faut établir les flux informationnels circulants entre le domaine et les partenaires :

La question à se poser est " Quels sont les contacts entre le domaine et ses partenaires ?" Voici les éléments du texte permettant de déterminer les flux informationnels :

- "Les abonnées à la bibliothèque peuvent faire des demandes d'achats de livres nouveaux", - "le responsable [...] décide les achats et fait les commandes aux éditeurs", - "Ceux-ci [les éditeurs] envoient séparément les livres et les factures", - "le responsable [...] envoie au service comptable un ordre de paiement".

Dans un cinquième temps, il faut découper le domaine d’étude en activité :

La question à se poser est "Quelles sont les différentes activités dans le domaine d’étude ?" Voici les activités que l'on peut relever :

- Gestion des demandes d'achats - Gestion des achats - Gestion des livraisons - Gestion des factures

A partir des étapes précédentes, on établit le modèle suivant :

1 -Paiement

La bibliothèque

Les abonnés

Demande d'achats

Réponse

2 - Ordre de paiement

3 - Accord servicecompta

Les éditeurs

Commandes

Envoi des livres

4 - Paiement

Gestion des demandes

Gestion des achats

Gestion des factures

Gestion des livraisons Envoi des factures

Le paiement des éditeurs n'est pas mentionné dans le texte. Plusieurs solutions se présentent : - On ne gère pas le paiement : dans ce cas, les flux 1, 2 et 3 n'apparaissent pas sur le modèle

ci-dessus. - Le service comptabilité envoie le paiement aux éditeurs : ce flux correspond au flux 4 barré

sur le modèle. En effet, il n'est pas nécessaire et même très déconseillé de faire apparaître les messages circulants entre les partenaires, entre les domaines connexes ou entre les partenaires et les domaines connexes.

- Le service comptabilité envoie son accord de paiement au responsable de la bibliothèque qui envoie, à son tour, le paiement aux éditeurs : ces flux correspondent aux flux 1, 2 et 3 sur le modèle.

Quelque soit la solution choisie, elle doit figurer avec le MCC comme hypothèse de gestion.



04/09/2002

Page 0

3 LE MODELE CONCEPTUEL DES DONNEES

3.1 Le MCD et ses concepts de base Il s’agit d’un diagramme entité-association (ou individu-relation) permettant de modéliser le système d’information sans prendre en compte les aspects physiques et organisationnels. Il comporte plusieurs concepts :

- Entité (ou objet) : personne, lieu, chose ou concept dont certaines caractéristiques présentent un intérêt pour le domaine d’étude et sur lesquels de l’information souhaitent être conservée. Une entité est pourvue d’une existence propre et conforme aux choix de gestion de l’entreprise.

- Propriété (ou attribut) : donnée élémentaire que l’on perçoit sur une entité ou sur une relations entre entités.

- Relation (ou Association) : association perçue dans le réel entre deux ou plusieurs entités. (Contrairement à une entité, une relation n’est pas pourvue d’existence propre.)

- Cardinalités : La cardinalité d’une entité par rapport à une relation s’exprime par deux nombres appelés cardinalité minimale et cardinalité maximale définies ci-après.

3.1.1 Le concept d’entité (ou objet) Une entité permet de modéliser un ensemble d'objets de même nature, concrets ou abstraits, perçus d'intérêts dans le discours. L'entité exprime un type, une classe, un ensemble dont les éléments sont appelés occurrence d'entité. C'est la définition des activités de gestion qui va permettre de déterminer les entités à créer. Exemples d'entités : Etudiant, Matière d'enseignement et Coefficient. Exemples d'occurrences de l'entité Matière d'enseignement : mathématique, informatique ou anglais. Quelques règles régissent la modélisation en termes d'entité : - Règle de pertinence : la définition d'une entité est un choix du concepteur en fonction de l'intérêt

qu'il présente. Plusieurs modélisations sont possibles à partir de mêmes objets. Il faut choisir celui qui est le mieux adapté aux besoins.

- Règles d'identification : on doit pouvoir faire référence distinctement à chaque occurrence d'une entité. Pour cela l'entité doit être dotée d'un identifiant (voir définition dans la paragraphe " Le concept de propriétés " ci-après).

- Règle de distinguabilité : les occurrences d'une entité doivent être distinguables. Cette distinguabilité induit la compréhension de l'entité et se traduit par le choix de l'identifiant.

- Règle de vérification : l'entité est décrite par une liste d'attributs. Chaque attribut de l'entité doit suivre la règle suivante : « A toute occurrence de l'entité, il ne peut y avoir, dans la mémoire du système d'information, au plus qu'une valeur de l'attribut ».

- Règle d'homogénéité : Les attributs d'une entité doivent avoir un sens pour toutes les occurrences de celle-ci. (il faut éviter d'englober plusieurs populations dont certaines ont des caractères propres exprimés dans la liste des attributs).

3.1.2 Le concept de propriétés

Une propriété ou un attribut est la modélisation d'une information élémentaire présente dans le discours. L'attribut est l'élément descriptif de l'entité ou de l'association. Il est unique dans un modèle conceptuel et ne peut être rattaché qu'à un seul concept (entité ou association).



04/09/2002

Page 0

Remarque : il faut distinguer information et attribut. L'attribut est une manière de modéliser une information, mais toutes les informations ne seront pas systématiquement traduites par un attribut. Exemple d'attributs de l’entité Etudiant : Identifiant Etudiant, Nom Etudiant, Prénom Etudiant Un identifiant d'entité est constitué d'un ou plusieurs attributs de cette entité, de sorte qu'à chaque valeur de l'identifiant correspond une occurrence unique de l'entité. L'identifiant est représenté souligné pour qu'il puisse être distingué des attributs de l'entité. Exemple : L'entité Etudiant a pour identifiant Identifiant étudiant, il s'agit d'un numéro unique à chaque étudiant.

3.1.3 Le concept d'association

On appelle association l'ensemble qui constituent le lien d'association et l'objet association lui-

même. Il s'agit d'une relation nommée entre entités qui exprime l'existence d'un rapport entre elles. On appelle dimension le nombre d'entités composant l'association et collection la liste de ces

entités. Dans la représentation ci-dessous, l'association a une dimension égale à 2 et sa collection est

composée de l'entité 1 et de l'entité 2.

Symbolisation d'une association :

Nom de l'entité 1

Identifiant 1Attribut 1Attribut 2

...

Nom de l'entité 2

Identifiant 2Attribut 1Attribut 2

...

Nom association

Attribut 1...

Exemple : L'association Posséder entre les entités Matière d'enseignement et Coefficient : une matière d'enseignement possède un coefficient.

MATIERE

Identifiant matièreLibellé matière

...

COEFFICIENT

Identifiant coefficientCoefficient

...

Posséder

Une entité peut être associée à elle-même, on parle alors d'association réflexive. Symbolisation d'une association réflexive :

Pattes de l’association



04/09/2002

Page 0

Nom de l'entité

IdentifiantAttribut 1Attribut 2

...

Nom association

Attribut 1...

Exemple 1 : Un individu possède une mère et un père qui représentent chacun un individu unique.

INDIVIDU

Identifiant individuNom individu

Prénom individu...

MEREPERE

Quelques règles régissent la modélisation en terme d'association : - Le choix de l'association : l'association n'existe qu'à travers les entités qui la composent. Il est

souhaitable d'utiliser un verbe statique à l'infinitif. La forme passive ou active permet d'orienter l'association. La numérotation des associations est déconseillée.

- L'identifiant d'une association : une association n'a pas d'identifiant propre. L'occurrence d'une

association est déterminée par les occurrences des entités de sa collection. Une occurrence d'une association ne peut exister que reliée à une occurrence de chacune des entités de sa collection.

- Les attributs d'une association : L'association ne peut être dotée d'attributs. Il s'agit d'informations

qui ne peuvent prendre de sens qu'avec la présence de la collection de cette association. - Les règles de vérification et de normalisation : A toute occurrence d'une association, il ne peut y

avoir, dans la mémoire du système d'information, qu'une seule valeur pour chacun des attributs rattachés à cette association.

3.1.4 Le concept de cardinalités

Le terme « cardinalité » traduit la participation des occurrences d'une entité aux occurrences d'une association.

Une cardinalité appartient à une patte (branche) de l'association. Chaque patte possède deux cardinalités : une cardinalité minimum (m) et une cardinalité maximum (M).

Signification des valeurs possibles des cardinalités : - m = 0 : certaines occurrences de l'entité ne participent pas à l'association (participation

optionnelle), - m = 1 : toute occurrence de l'entité participe au moins une fois aux occurrences de

l'association (participation obligatoire), - M = 1 : quand une occurrence type de l'entité participe à une association, elle n'y participe

au plus qu'une fois (unicité de participation), - M = n : quand une occurrence type de l'entité participe à une association, elle peut y

participer plusieurs fois (multiplicité de participation). Exemple 1 : le cas d'une association simple avec les cardinalités



04/09/2002

Page 0

MATIERE

Identifiant matière

Libellé matière

COEFFICIENT

Identifiant coefficientCoefficient

Posséder0,n0,1

Un même coefficient peut être attribué à plusieurs matières différentes, d'où les cardinalités "0,n". Mais une matière donnée ne peut posséder qu'un seul coefficient, d'où les cardinalités "0,1".

Exemple 2 : le cas de l'association réflexive avec les cardinalités

INDIVIDU

Identifiant individuNom individu

Prénom individu...

MEREPERE

0,n

0,1 0,1

0,n

Un individu peut être père ou mère de plusieurs individus, d'où les cardinalités "0,n". Un individu n'a qu'un seul père et qu'une seule mère, d'où les cardinalités "0,1".

Exemple 3 : Un répertoire peut appartenir à un autre répertoire et peut contenir d’autres répertoires et des fichiers.

REPERTOIRE

Identifiant répertoire

Nom répertoire

contientappartient

0,n

0,1

0,n

FICHIER

Identifiant ficheirNom fichier

...

1,1



04/09/2002

Page 0

3.2 Les règles de normalisation et de vérification

3.2.1 Règle N°1 et N°2 concernant les entités et leurs propriétés

Règle n°1 : Il doit exister un identifiant pour chaque entité. Règle n°2 : Toutes les propriétés autres que l’identifiant doivent être en dépendance fonctionnelle complète et directe de l’identifiant. Notion 1 : La dépendance fonctionnelle

Une propriété B est dite en dépendance fonctionnelle d’une propriété A, si pour toute valeur de A, il existe une et une seule valeur B ; autrement dit : A B. D’où la règle pratique suivante (sous-règle n° 2) : Pour chaque occurrence d’une entité, chaque propriété doit être en dépendance fonctionnelle de l’identifiant et doit ainsi prendre une et une seule valeur. Autrement dit, il ne peut pas de valeurs répétitives, ni d’absence de valeur pour une même propriété. Exemple :

EMPLOYEn° employénomprénomprénom enfant La propriété "prénom-enfant" peut domiciliation prendre plusieurs valeurs selon leprime de qualification nombre d'enfants

Il faut en conséquence créer une autre entité, d’où le nouveau MCD :

EMPLOYE ENFANTn° employé 0,n 1,1 n° employé -n° ordrenom appartenir nom-enfantprénom prénom-enfantdomiciliation date de naissanceprime de qualification

Notion 2 : La dépendance complète Les propriétés doivent dépendre de tout l’identifiant et non pas d’une partie de cet identifiant. Exemple : Dans l’exemple ci-dessus, l’entité ENFANT possède une propriété nom. Cette propriété ne dépend pas complètement de l’identifiant, mais d’une partie de l’identifiant : en effet, le nom dépend du n° employé et non du n° ordre.



04/09/2002

Page 0

EMPLOYE ENFANTn° employé 0,n 1,1 n° employé -n° ordrenom appartenir prénom-enfantprénom date de naissancedomiciliationprime de qualification

Notion 3 : la dépendance directe Chaque propriété doit dépendre directement de l’identifiant et non par l’intermédiaire d’une ou plusieurs autres propriétés. Exemple : Admettons que la prime de qualification de l’employé dépende en fait de la qualification de l’employé. Par conséquent, la propriété prime qualification de l’entité EMPLOYE ne dépend directement de l’identifiant n° employé, mais dépend d’abord de la propriété qualification. Il faut créer une entité QUALIFICATION qui aura comme propriétés qualification et prime de qualification et comme identifiant n° qualification.

EMPLOYE ENFANTn° employé 0,n 1,1 n° employé -n° ordrenom appartenir prénom-enfantprénom date de naissancedomiciliation1,1

posséder

0,nQUALIFICATION

n° qualificationlibellé qualicationprime de qualification

3.2.2 Règle N°3 concernant les relations

Règle n° 3 : Toutes les propriétés d’une relation doivent dépendre complètement de l’identifiant de la relation ; chaque propriété doit dépendre de tout l’identifiant et non d’une partie de cet identifiant. Ainsi pour chaque occurrence d’une relation, chaque propriétés doit être en dépendance fonctionnelle de l’identifiant de la relation et doit donc prendre une et une seule valeur.

3.2.3 Règle N°4 et N°5 concernant l’ensemble du MCD

Règle n°4 : Une propriété ne peut apparaître qu’une seule fois dans un même MCD, c’est ainsi qu’elle ne peut qualifier qu’une seule entité ou une relation. Règle n°5 : Les propriétés qui sont le résultat d’un calcul ne doivent pas, en principe, figurer dans un MCD sauf si elles sont indispensables à la compréhension de celui-ci.



04/09/2002

Page 0

3.3 Exemple : Le championnat d'athlétisme

On souhaite mémoriser une partie des données d’un championnat international d’athlétisme comprenant des courses et des concours de lancer et de saut. Le domaine concerné est décrit si-dessous :

Le championnat est divisé en compétitions (100 m homme, 800 m femme, disque homme…) décrites par un numéro, un nom et le sexe des compétiteurs. Une compétition peut comprendre plusieurs épreuves de niveaux différents (finale, demi-finale… éliminatoires). Chaque épreuve est décrite par un code, un niveau, une date et une heure de début.

les athlètes (n° d’athlète, nom, prénom, date de naissance, n° licence) appartiennent à différents pays (code-nation, nation, titre, hymne nationale). Ils sont engagés dans différentes compétition et participent à des épreuves dont les résultats sont mémorisés. Interprétation du texte - « Le championnat est divisé en compétitions […] décrites par un numéro, un nom et le sexe des

compétiteurs » ⇒ création d’une entité COMPETITION avec les attributs numéro compétition, nom compétition, sexe.

- « Une compétition peut comprendre plusieurs épreuves » ⇒ création d’une entité EPREUVE associée à l’entité COMPETITION.

- « plusieurs épreuves de niveaux différents » ⇒ création d’une entité NIVEAU associée à l’entité EPREUVE.

- « Chaque épreuve est décrite par un code, un niveau, une date et une heure de début » ⇒ création des attributs code, niveau, date, heure de début dans l’entité EPREUVE.

- « Les athlètes [...] appartiennent à différents pays […] » ⇒ Création d’une entité ATHLETE avec les attributs se trouvant dans la première paire de crochet, et associée à une nouvelle entité PAYS ayant pour attributs le contenu de la seconde paire de crochet.

- « Ils [les athlètes] sont engagés dans différentes compétitions » ⇒ création d’une association entre l’entité ATHLETE et l’entité COMPETITION.

- « Ils [les athlètes] […] participent à des épreuves dont les résultats sont mémorisés » ⇒ création d’une association entre l’entité ATHLETE et l’entité EPREUVE.

Proposition d’un modèle :

COMPETITION EPREUVEN° compétition composer CodeLibellé NiveauSexe Date

Heure

engager participerrésultat

ATHLETE PAYSN° Athlète Code nationNom appartenir NationPrénom TitreDate naisssance Hymnen° licence

1,11,n

1,n

1,n1,n

1,n

1,1 0,n



04/09/2002

Page 0



04/09/2002

Page 0

4 LE MODELE LOGIQUE DES DONNEES

4.1 Le MLD et ses concepts de base Le Modèle Logique des Données est un diagramme qui permet de décrire la structure de données utilisée sans faire référence à un langage de programmation. Les concepts manipulés dans le MLD sont les suivants :

- Relation (appelée plus couramment Table) - Tuple : Elément d’un produit cartésien appelé plus couramment ligne d’une table.

- Attribut : colonne d’une relation caractérisée par un nom.

Exemple : marque et couleur sont les attributs de la relation VOITURE. Cette relation s’écrit VOITURE (marque, couleur).

- Clé d’une relation : un ou plusieurs attributs dont les valeurs permettent de définir de manière

unique les tuples de la relation.

Exemple : La relation VOITURE (marque, couleur) n’identifie pas de manière unique les tuples. En effet il peut y avoir plusieurs Peugeot rouge. C’est pourquoi il faut lui rajouter une clé n° voiture. Cela donnerait alors la relation : VOITURE (n° voiture, couleur, marque) avec les tuples suivants :

o tuple 1 1 RENAULT BLANCHE o tuple 2 2 PEUGEOT ROUGE o tuple 3 3 RENAULT BLEU o tuple 4 4 PEUGEOT ROUGE

4.2 Passage du MCD au MLD Tableau de conversion :

MCD MLDentité tablepropriété de l'entité colonne ou attribut de la tableidentifiant de l'entité clés primaire de la tablerelation plusieurs (0,n ou 1,n) à plusieurs (0,n ou1,n) tablerelation binaire 1 (0,1 ou1,1) à plusieurs (0,n ou1,n) exportation clé étrangère et attributs portés Exemple :

MLD Le championnat d’athlétisme (cf. 3.3 Exemple : Le championnat d’athlétisme)



04/09/2002

Page 0

COMPETITION EPREUVEid_competition codelib niveausexe date

heureid_competition

ENGAGER PARTICIPERid_competition codeid_athlete id_athlete

résultat

ATHLETEid_athlete PAYSnom code_nationprenom nationdate_naissance titrenum_licence hymnecode_nation

L’association participer entre les entités ATHLETE et EPREUVE est une relation « plusieurs à plusieurs » qui est, par conséquent, devenu la table PARTICIPER dans le MLD. Cette table possède une clé constituée des clés des tables ATHLETE et EPREUVE, soit id_ahtlete et code. Elle possède une colonne résultat qui correspondait à l’attribut porté de l’association participer dans le MCD. L’association engager entre les entités COMPETITION et ATHLETE est une relation « plusieurs à plusieurs » qui est devenu la table ENGAGER dans le MLD. Cette table est possède une clé constituée des clés des tables ATHLETE et EPREUVE, soit id_ahtlete et code. L’association composer entre les entités COMPETITION et EPREUVE est une relation « binaire à plusieurs ». Au moment du passage du MCD au MLD, l’association provoque l’exportation de la clé id_competition dans la table EPREUVE. L’association appartenir entre les entités PAYS et ATHLETE est une relation « binaire à plusieurs ». Au moment du passage du MCD au MLD, l’association provoque l’exportation de la clé code_nation dans la table ATHLETE.

4.3 Passage du MLD au DPD (Description Physique des Données)

Aujourd’hui il n’existe pas d’approche normalisée de description et de représentation du niveau physique des données. La description physique des données est étroitement liée aux choix techniques informatiques concernant le système de gestion des données. Le Diagramme Physique des Données sera assimilé au script de création des tables du MLD. Exemple :

DPD Le championnat d’athlétisme CREATE TABLE competition ( id_competition NUMBER(6) NOT NULL, libelle VARCHAR2(20), sexe CHAR(1) NOT NULL, CONSTRAINT competition_pk PRIMARY KEY

(id_competition));



04/09/2002

Page 0

CREATE TABLE epreuve ( code NUMBER(6) NOT NULL, niveau NUMBER(2) NOT NULL, date_epreuve DATE, heure DATE, id_competition NUMBER(6) NOT NULL, CONSTRAINT epreuve_pk PRIMARY KEY (code), CONSTRAINT epreuve_id_competition_fk FOREIGN KEY(id_competition) REFERENCES competition(id_competition)); CREATE TABLE pays ( code_nation NUMBER(6) NOT NULL, nation VARCHAR2(20), titre VARCHAR2(20), hymne VARCHAR2(20), CONSTRAINT pays_pk PRIMARY KEY(code_nation)); CREATE TABLE athlete ( id_athlete NUMBER(6) NOT NULL, nom VARCHAR2(15), prenom VARCHAR2(15), date_naissance DATE, num_licence NUMBER(12), code_nation NUMBER(6) NOT NULL, CONSTRAINT athlete_pk PRIMARY KEY (id_athlete), CONSTRAINT athlete_code_nation_fk FOREIGN KEY(code_nation) REFERENCES pays(code_nation)) ; CREATE TABLE participer ( code NUMBER(6), id_athlete NUMBER(6), CONSTRAINT participer_pk PRIMARY KEY (code, id_athlete), CONSTRAINT participer_id_athlete_fk FOREIGN KEY(id_athlete) REFERENCES athlete(id_athlete), CONSTRAINT participer_code_fk FOREIGN KEY (code) REFERENCES epreuve(code)); CREATE TABLE engager ( id_competition NUMBER(6), id_athlete NUMBER(6), CONSTRAINT engager_pk PRIMARY KEY (id_competition, id_athlete), CONSTRAINT engager_id_athlete_fk FOREIGN KEY(id_athlete) REFERENCES athlete(id_athlete), CONSTRAINT engager_id_competition_fk FOREIGN KEY (id_competition) REFERENCES competition(id_competition));

94675249-merise-module-1

Documents