MERISE
Merise est né vers 1978 à 1979 par le ministère de l’industrie français afin de mettre au point une méthode de conception et de réalisation de système d’information.
Merise est une méthode de conception et de développement de systèmes d’information, elle vise à recenser la totalité des informations dont l’entreprise a besoin pour assurer toute ou partie de ses activités fondamentales, que ces informations soient utilisés manuellement ou qu’elles le soient de manière automatique,quels qu’en soient les lieux de production ou de consommation ou encore les acteurs impliqués.
Ainsi, même des informations dont la production ne fera l’objet d’aucune informatisation, devront être décrites.
Cette description se veut instantanée (Elle concerne les informations du moment.) mais aussi prospective, dans la mesure ou même des informations qui ne deviendront pertinentes que 3 à 5 ans plus tard, seront recherchées et
recensées.
APPROCHE
SYSTEMIQUE
MERISE
ET
L’APPROCHE SYSTEMIQUE
C’est elle qui facilitera la mise en évidence des deux tâches de la méthode MERISE :Etude de l’existant et Etude du futur. Telle qu’elle est une de ces composants.
MERISE se caractérise par une double démarche, par niveaux et par étapes, qui se base sur des visions parcellaires (sectoriels, partiels, relatifs) et personnalisées des acteurs ou visions externes, pour aboutir à une vision synthétique et globale au travers de modèles dits conceptuels.
Ces points forts en matière de conception des systèmes d’information (C.S.I): • un découpage de processus de conception en étapes: approche par étapes
• une description par niveaux: approche par niveaux d’abstraction.
L’OBJECTIF DE LA DEMARCHE PAR NIVEAUX :
La formalisation du futur système sous ses différents aspects (contributions à la stratégie d’entreprise, mise en oeuvre des règles de gestion , aspects organisationnels et techniques).
L’OBJECTIF DE LA DEMARCHE PAR ETAPES :
L’ hiérarchisation des décisions qui doivent être prises au cours de la conception, du développement, de la mise en oeuvre; de la généralisation de l’emploi de tout ou partie d’un nouveau système d’information mais aussi lors de l’évolution du système qui sera mis en place.
N.B :
L’efficacité de ces deux approches est due en grande partie au fait qu’elles tirent parti des principes de la systémique !.
Pour facilité la mise en évidence de telle discipline: A.S. MERISE Stade 1:
Entrée Sortie Matières Produits Premières manufacturés de ses pour Fournisseurs des Clients
Le Système Entreprise
On définit l’entreprise comme une boite noire assurant une fonction de transformation de ressources ou flux physique d’entrée en ressources ou flux physique de sortie. Stade 2:
Fonction de Fonction de
elt1Pilotage Production
elt3 elt2
elt4
Le Système L’Entreprise
Service ou Direction
(Comptabilité)
On définit l’entreprise comme une boite blanche, c’est-à-dire que le contenu de la boite est peu à peu défini.
Schéma récapitulatif de l’approche systémique d’une entreprise ou de tout autre organisme:
SYSTEME DE PILOTAGE
Coordination, Objectifs
E (membres de la direction, ) N
V E Décisions informations
I X traitées
R T
O E
N R SYSTEME D’INFORMATION information
N I informations - collecte
E E - mémorisation des données
M U - traitement informations vers l’extérieur E R externes - transmission
N T
informations collectées
SYSTEME OPERANT
Production, action
(ensemble du personnel exécutant)
Flux entrant Flux sortant
• Le pilote assigne les objectifs (opérations à réaliser) et contrôle le système,
• Le système d’informations enregistre les opérations à réaliser et le résultat des opérations,
• L’opérant effectue les opérations: reçoit et émet les flux (échanges du système avec l’environnement)
3 NIVEAUX : stabilité
conceptuel quoi?
organisationnel / logique qui? où?
operationnel / physique comment?
croissante
Chacun des niveaux fait objet d’approches conjointes et parallèles par les données et par les traitements, approches qui se traduisent par des modèles spécifiques :
niveaux modéles stable+ donnés traitements
conceptuel MCD MCT
logique ou
MLD MOT
organisationnel physique ou
opertionnel MPD MOPT
+evolutif
NIVEAU CONCEPTUEL
Il consiste à penser au système d’information sans envisager aucun concept lié à l’organisation. L’objectif est de répondre à la question Quoi ? de comprendre la nature du problème. Ce niveau décrit à travers un ensemble de règles de gestion, traduit les objectifs et les contraintes qui pèsent sur l’entreprise.
Exemple de règles de gestion :
• Un professeur ne peut donner qu’un seul type de cours.
• Toute commande doit être visée par écrit.
A ce niveau, on trouve le MCD (Modèle Conceptuel de Données) et aussi le MCT (Modèle Conceptuel de Traitements).
NIVEAU ORGANISATIONNEL :
Ce niveau consiste à intégrer à l’analyse les critères liés à l’organisation (notions de lieux, de temps, d’acteurs et de postes de travail).
A ce niveau organisationnel sont fait tous les choix d’organisation afin de déterminer Qui fera quoi ? Où ? Quand ?
Exemple de règles d’organisation :
• La tournée de livraison doit être commencé à 9h. (Quand)
• Toute commande doit être visée par le directeur financier. (Qui)
A ce niveau, on trouve le MLD (Modèle Logique de Données) et MOT (Modèle Organisationnel de Traitements).
NIVEAU OPERATIONNEL :
Il consiste à apporter des solutions techniques aux problèmes, à poser la question Comment ? .
Du point de vue données, on effectue des choix sur les méthodes de stockages et d’accès (fichiers). Pour les traitements automatiques, on étudie le découpage en programmation. D’une manière générale, on envisage les contraintes d’utilisation des ressources physiques.
A ce niveau, on trouve le MPD (Modèle Physique des Données) et MOpT (Modèle Opérationnel des Traitements).
| Nivea u | Traitement | Données | Choix | Préoccupation | Spécification |
| Modèle conceptuel de traitement MCT | Modèle conceptuel de données MCD | Quoi ? Quoi faire ? Avec quelles données ? | - données - Informations - Traitement -Règles de gestion | ||
| Modèle organisationnel de traitement MOT | Modèle logique de données MLD | Qui ? Quand ? Où ? | Homme/Machin e Temps Emplacement | ||
| Modèle opérationnel de traitement MOPT | Modèle physique de données MPD | Comment ? | Programme Fichiers |
DEMARCHE DE MODELISATION DES DONNEES
DEMARCHE DE MODELISATION DES TRAITEMENTS
Démarche par étapes:
6 étapes :
: Schéma directeur
L’objectif est de faire le pont entre la stratégie de l’entreprise et ses besoins en termes de systèmes d’information. Décomposition de l’organisation en domaines.
: Etude préalable
A la suite du schéma directeur, l’étude préalable aura pour but de reprendre domaine par domaine et d’étudier de manière plus approfondie les projets à mettre en oeuvre et leur interfaçage.
: Etude détaillée
Reprend chaque projet. Et elle représente la Description fonctionnelle de la solution à réaliser.
: Etude technique
Prise en compte de tout l’environnement technique informatique.
: Réalisation
Permet d’obtenir le logiciel testé sur un jeu d’essai : Codage des programmes, tests et mise au point, intégration de l’ensemble des transactions et des chaines batch.
: Mise en oeuvre
Exécuter toutes les actions (formation, installation des matériels, initialisation des données, réception, ) qui permettront d’aboutir au lancement du système auprès des utilisateurs.
: Maintenance
La maintenance des applications va permettre de faire vivre les applications et de les mettre à niveau jusqu’à leur mort : Mise à niveau éventuelle des applications. Prolonger la durée de vie.
Plus une étape est générale, moins elle est détaillée REALISER PAR EL HARRAK et réciproquement.
Donc, les étapes de la méthode peuvent être chronologiquement réparties dans l’ordre suivant :
1. Etude de l’existant,
2. Modèle conceptuel de données MCD et modèle conceptuel de traitements MCT sachant que les deux modèles doivent être traiter en parallèle et par deux équipes différentes si celui-ci est possible.
3. Modèle organisationnel de traitements MOT,
4. Validation,
5. Modèle logique de données MLD,
6. Modèle physique de données MPD,
7. Modèle opérationnel de traitements MOpT.
La méthode MERISE permet de déterminer trois cycles concourant à l’étude de tout système d’information qui permettent de situer les étapes .
Cycle de vie : décrit la vie du système d’information. il traduit le cheminement chronologique du système d’information depuis sa création (naissance) et son développement jusqu’à son obsolescence et sa remise en cause (mort).
Lorsque S.I. actuel est complètement dépassé, on fait appel à un
nouveau cycle de vie
Conception Maintenance
Fournir un description Permet de prolonger fonctionnelle et technique la vie du S.I. et son
détaillée du système. adaptation aux besoins nouveaux de
l’entreprise.
Elaboration des programmes afin de mettre en oeuvre les solutions techniques précédemment retenues.
Le cycle de vie et ses étapes
CYCLE D’ABSTRACTION :
Offre les concepts pour pouvoir décrire les différents éléments du monde réel
qui seront représentés dans le système d’information. C’est dans ce cycle que l’on trouve les 3 niveaux d’abstraction (conceptuel, logique et physique).
| NIVEAU | PREOCCUPATION | DONNEES | TRAITEMENT |
| 1 | Quoi ? Que veut-on faire? | Conceptuel | Conceptuel |
| 2 | Qui ? Quand ? Où ? Comment ? | Logique | Organisationnel |
| 3 | Avec quels moyens ? | Physique | Opérationnel |
CYCLE DE DECISION :
Concerne les différentes décisions et choix qui sont effectués tout au long du cycle de vie. La plupart de ces décisions marquent la fin d’une étape et le début d’une autre.
L’étude d’un projet en MERISE s’appuie en tout premier lieu sur la démarche de modélisation suivante:
: Couverture du champ par l’étude détaillé.
ANALYSE DE L’EXISTANT
(AMC*Designor comme exemple)
MCD = Le modèle conceptuel des données permet de représenter les données du réel perçu, indépendamment des choix techniques, afin de faciliter la réflexion lors du travail de conception.
MLD = Le modèle logique des données est une traduction du MCD qui intègre la contrainte technique, à savoir la nature de l’outil logiciel sur lequel sera installée la future structure de données.
AMC*Désignor assure le passage automatique du MCD à un MLD « Relationnel », propre aux systèmes de gestion de base de données relationnels (SGBD/R).
MPD = AMC*Désignor fournit un MLD graphique, Ce MLD est de plus complété des spécifications propres à l’implantations des tables, index, et peut donc être modifié et/ou complété. Il porte alors le terme de M.P.D ou modèle physique des données.
Le modèle relationnel est défini par le mathématicien CODD, basé sur la théorie des ensembles. L’idée étant de disposer les données sous forme de tableaux à deux dimensions appelés tables ou relations.
TABLE: Une table correspond à une entité ou à une association du M.C.D, elle est constitué de lignes et de colonnes.
LIGNE: Une ligne correspond à la notion d’occurrence d’entité ou d’association.
COLONNE: La notion de colonne correspond à celle de propriété.
CLE PRIMAIRE: La notion de clé primaire correspond à celle d’identifiant.
CLE ETRANGERE: Une colonne d’une table Ti est dite clé étrangère si elle correspond à une clé primaire d’un table Tj. Répéter la clé permet la traduction de certains associations tout en évitant la répétition des propriétés de l’entité pointée.
SCHEMA RELATIONNEL : Le schéma relationnel est un ensemble de tables ou relation sémantiquement liées. Concrètement, il consiste en l’écriture de la liste des tables et de leurs colonnes associées.
Exemple de schéma relationnel :
SALARIE ( Numsal , Nomsal , Rue , Divnum ) DIVISION ( Divnum , Divnom , . )
Remarque :
* Les identifiants ou clés primaire sont soulignés et les clés étrangères sont indiquée en italique.
* Un schéma relationnel est une représentation du M.L.D.
Après une phase de pré-analyse, on dresse le dictionnaire des données correspondant aux informations relevées sur les documents de gestion ou lors de l’analyse des postes de travail au moyen d’interviews.
Ce dictionnaire, établi «à la main », peut se présenter sous la forme du document suivant :
| DICTIONNAIRE DES DONNEES : DOMAINE : GESPER…………………… | Date : …………… | ||||||
| DONNEES | DOCUMENTS | ||||||
| Données (= signifié) | Mnémonique ou symbole (= signifiant) | Explications | Type | Longueur | Nature (SI, ST, M) | A | B |
| Matricule | SALMAT | Matricule de salarié | N | 5 | SI | ||
| Nom | SALNOM | Nom du salarié | A | 20 | SI | ||
| … | …. | …. | … | … | |||
Lexique:
| AN : Alpha Numérique | SI : Signalétique |
| N : Numérique | ST : Situation |
| A: Alphabétique | M : Mouvement |
DICTIONNAIRE DES DONNEES
Définition des éléments constitutifs :
A fin d’éviter un certain nombre d’anomalie sur les données retenues, des considérations relatives à la structure et à la nature des propriétés sont à prendre en compte.
Propriétés élémentaires :
Une propriété élémentaire correspond à une donnée qui ne résulte pas d’une concaténation de propriété. Exemple : l’adresse est composée de la rue, la ville, code postal est une donnée non élémentaire.
Le dictionnaire contient toutes les propriétés élémentaires.
Les synonymes et les polysémies :
Une propriété est appelée signifié ou signification. Tandis que le symbole, qui représente une propriété, a pour nom signifiant ou variable.
Les synonymes sont des signifiés qui ont le même signifiant. Exemple :
Numéro Chambre et Numéro Client sont deux signifiés différents qui ont le même signifiant à savoir NUMC.
Les polysémies sont des variables qui représentent le même signifié.
Exemple : code client est une propriété représentée par deux signifiants à savoir CODECLI et
CODCLI.
Les polysémies et les synonymes doivent être évitées lors de la construction du dictionnaire de données.
Données de situation
Les données de situation sont des données qui varient avec le temps ou selon une période.
Exemples : crédit d’un client, température, note d’élève etc.
Il en est ainsi du crédit d'un compte client au sein d'une institution financière.
C'est également le cas de la température constamment variable avec le temps.
Donnéesdemouvements
Les données de mouvements sont des éléments qui résultent des circonstances spécifiques, elles n’existent que parce qu’un événement a eu lieu. Exemple : la quantité d’un produit commandé suppose qu'une commande concernant ce produit a été effectuée. C'est également le cas du nombre de passagers dans un avion lors d'un vol.
Donnéessignalétiquesou (statiques ou stables)
Demeurent généralement inchangées.
Elles ne peuvent être modifiées quelles que soient les circonstances. C'est le cas des date et lieu de naissance. On considérera comme données signalétiques toutes les propriétés qui ne sont ni mouvement, ni de situation.
MCD est un modèle schématique permettant une description statique du système d’information à l’aide des concepts d’entité et d’association.
MCD est une représentation simplifiée d’une réalité, autrement dit un MCD n’est pas directement utilisé par la machine mais c’est un mode de représentation intermédiaire entre la réalité observée (l’existant) et la machine avec son logiciel. Une fois le modèle établi est validé par rapport à la réalité observée, il existe des règles permettant de le transformer en fichier ou base des données.
DEFINITION ET FORMALISME
ENTITE
Une entité est la représentation dans le système d’information d’un objet matériel (concret) ou immatériel (abstrait) ayant une existence propre et conforme aux choix de gestion de l’entreprise.
Une personne ou un salarié sont des exemples d’objets matériels, c’est à dire représentant des réalités concrètes et objectives.
Une infraction, une location ou une division sont des exemples d’objets immatériels.
Les objets d’un même type sont décrits par ce qu’on appelle propriété.
Symbole utilisé :
| NOM DE L’ENTITE |
IDENTIFIANTD’UNEENTITE
L’identifiant d’une entité est constitué d’une ou plusieurs propriétés particulières de l’entité telles qu’à chaque valeur de l’identifiant corresponde une et une seule occurrence de l’entité. La ou les propriétés identifiantes, lorsqu’elles figurent sur le MCD, sont soulignées.
Exemple : la propriété SALNUM est identifiante de l’entité SALARIE, c’est à dire que la connaissance de cette propriété permet d’identifier sans ambiguïté chaque salarié de l’entreprise.
Remarque : toute entité doit porter un identifiant, qui peut être composé d’une ou plusieurs propriétés.
OCCURRENCED’UNEENTITE:
L’occurrence d’une entité est un élément individualisée appartenant à cette entité .
Exemple : les informations relatives au salarié MARTIN constituent une occurrence de l’entité SALARIE .
Remarque : cette notion n’est pas directement représentée au niveau du MCD, mais sera utilisée au travers du concept de cardinalité.
RELATION (ou association)
Une relation est la représentation d’un lien en entité. Elle peut être porteuse de propriétés.
Le nombre d’entités intervenant dans la relation caractérise la dimension de l’association.
• Association réflexive d’une entité sur elle même..
• Association binaire entre deux entités.
• Association ternaire entre trois entités.
• Association n-aires entre n entités.
Symboleutilisé:
| ENTITE 2 |
EXEMPLES :
1. L’association ENCADRE est une association réflexive qui traduit le fait qu’un SALARIE donné est susceptible d’encadrer d’autres salariés.
|
2. L’association TRAVAILLE de dimension binaire permet de traduire le fait qu’un SALARIE travaille dans une DIVISION.
|
3. L’association ACCOMPLIR de dimension binaire permet de traduire le fait qu’un SALARIE accomplie une ou plusieurs tâches.
|
4. L’association ENSEIGNE de dimension ternaire permet de traduire le fait
• qu’un FORMATEUR enseigne plusieurs MATIERES.
• qu’une MATIERE est enseignée par plusieurs FORMATEURS.
• qu’un FORMATEUR enseigne à plusieurs STAGIAIRES.
• qu’une MATIERE est enseignée à plusieurs STAGIAIRES.
Remarque : il est conseillé d’utiliser comme nom de l’association un verbe afin de mieux souligner la relation intervenant entre les différentes entités.
IDENTIFIANTD’UNEASSOCIATION
L’identifiant d’une association est toujours obtenu par concaténation des identifiants des entités participant à l’association.
Exemple : l’identifiant de l’association ACCOMPLIR est constitué de la concaténation des propriétés SALNUM et TACNUM.
Remarque : l’identifiant d’une association ne doit pas figurer sur le MCD.
OCCURENCE D’UNE ASSOCIATION :
L’occurrence d’une association est association individualisée constituée d’une et d’une seule occurence des entités participant à la relation .
Exemple : le salarié MARTIN travaillant dans la division PERSONNEL constitue une occurrence de l’association TRAVAILLE .
Remarque : cette notion n’est pas directement représentée au niveau du sera utilisée au travers du concept de cardinalité.
PROPRIETE
Une propriété (ou attribut) est une donnée élémentaire que l’on peut attacher à une entité ou à une association. De plus elle peut faire référence à un domaine dont elle héritera des caractéristiques (type, longueur, liste de valeurs).
Le nom de chaque propriété peut être inscrit à l’intérieur de chaque entité ou association lorsque celle-ci est porteuse d’attributs.
Exemple :
• L’entité SALARIE est porteuse des propriétés : SALNUM, SALNOM, SALPRE, SALADR…
• L’association ACCOMPLIR est porteuse des propriétés : ACCDEB,
ACCFIN
LIENETCARDINALITE
Un lien représente une liaison entre une entité et une association. Il est caractérisé par sa cardinalité. Cette cardinalité est constitué d’une borne minimale et d’une borne maximale.
Cardinalité minimale : c’est le nombre minimum de fois qu’une occurrence d’une entité participe aux occurrences de l’association. La cardinalité minimale est généralement égale à 0 ou 1.
Cardinalité maximale : c’est le nombre maximum de fois qu’une occurrence d’une entité participe aux occurrences de l’association. la cardinalité maximale peut varier de 1 à n.
|
On peut dire que les cardinalités indiquées entre l’entité SALARIE et l’association TRAVAILLE traduisent le fait
- que tout salarié travaille dans au moins une division. - que tout salarié travaille dans auplus une division.
De même, les cardinalités indiquées entre l’entité DIVISION et l’association
TRAVAILLE traduisent le fait
- qu’une division fait travailler aumoins un salarié. - qu’une division fait travailler auplus n salariés.
LIEN IDENTIFIANT
Nous avons vu la nécessité pour une entité de porter un identifiant. Dans certains cas, cet identifiant ne suffit pas.
Si deux entités sont liées par une relation de composition, on peut vouloir définir l’identifiant de l’entité «composante » relativement à celui de l’entité «composée ». Dans ce cas, le lien qui est issu de l’entité composante est appelé lien identifiant. Il porte nécessairement la cardinalité 1,1. Sur le graphique, cette cardinalité apparaît entre parenthèses, de manière à différencier le lien identifiant d’un lien 1,1 normal.
Symbole utilisé :
Si on examine la partie suivante du MCD
|
On constate que l’identifiant de l’entité TACHE (num_tâche) est relatif à l’identifiant de l’entité PROJET (num_projet).
En effet, comme il est possible que deux tâches portent le même numéro si elles appartiennent à deux projets différents, on identifiera complètement une tâche par son numéro et le numéro de projet auquel elle appartient.
Remarque : on constate que les cardinalités permettent de traduire une réalité et que par conséquent leur choix est primordial ; de plus, comme nous le verrons par la suite, elles ont une influence non négligeable sur le modèle logique de données.
Les cardinalités autorisées se résument aux combinaisons suivantes :
• 0,1 : aucun ou un seul
• 1,1 : un et un seul
• (1,1) : un et un seul, lien identifiant
• 0,n : aucun ou plusieurs
• 1,n : au moins un ou plusieurs.
REGLES DE NORMALISATION D’UN MCD
L’élaboration d’un MCD s’effectue en plusieurs étapes, et fait souvent l’objet de modification au fur et à mesure de l’analyste du projet informatique.
Toutefois, une des étapes essentielles consiste à vérifier le MCD en appliquant un certain nombre de règles dites de normalisation.
Nous avons donc, dans un premier temps, passer en revue les règles principales de normalisation, puis les appliquer sur un exemple simple.
REGLE 1 : toute entité doit posséder un identifiant.
REGLE 2 : toutes les propriétés d’une entité ou d’une association doivent être élémentaires, c’est-à-dire non décomposables au sens pratique du terme.
REGLE3 : pour chaque occurrence d’entité ou d’association, chaque propriété ne peut prendre qu’une seule valeur. Autrement dit, on ne peut avoir de valeurs répétitives pour une même propriété.
REGLE4 : toutes les propriétés autres que l’identifiant doivent dépendre pleinement de l’identifiant et non d’une partie de celui-ci.
REGLE5 : chaque propriété doit dépendre directement de l’identifiant et non par l’intermédiaire d’une ou plusieurs autres propriétés.
APPLICATION
Soit l’univers du discours (UDD) suivant :
« Les salariés d’une entreprise, subdivisée en divisions, travaillent dans une et une seule division et participent à un ou deux projets au maximum. Un salarié est caractérisé par son nom et son adresse. Chaque division comporte un numéro et une désignation. »
Cet UDD est traduit par le MCD suivant :
| SALARIE |
| NOMSAL ADRESSE PROJET-1 PROJET-2 DIVNUM DIVNOM |
Il va de soi que l’on commet quelques entorses aux règles de normalisation, et on peut même préciser que ce MCD n’est pas en accord avec les 3 premières règles car :
- aucune propriété n’est identifiante (règle 1)
- la propriété ADRESSE n’est pas élémentaire (règle 2)
- il y a répétition des noms de projets (règle 3)
Solution possible :
- si l’on admet que pour une division donnée il n’y a pas deux salariés ayant même nom, on pourra retenir comme identifiant le couple de propriétés « DIVNUM, NOMSAL ».
- la propriété ADRESSE se décompose par exemple en deux propriétés élémentaires RUE et VILLE (la propriété RUE regroupe les notions de numéro et de nom de rue que l’on considère comme un tout).
- Le groupe répétitif sera traduit à l’aide d’une entité PROJET et de l’association PARTICIPE.
On obtient alors le MCD suivant :
|
Ce MCD, qui est maintenant en première forme normale, n’est toutefois pas en accord avec la règle 4.
En effet, si le couple de propriétés DIVNUM, NOMSAL identifie sans ambiguïté chaque salarié, la propriété DIVNOM (nom de la division) ne dépend que d’une partie de l’identifiant, la propriété DIVNUM.
Solution possible :
Il suffit dans ce cas d’ajouter à l’entité SALARIE une nouvelle propriété nommée NUMSAL et correspondant à un numéro de salarié qui identifie sans ambiguïté chaque salarié de l’entreprise.
|
Remarque : la cardinalité maximale n de la branche gauche de l’association permet d’exprimer qu’un salarié peut participer à 2 ou plus de 2 projets.
Ce MCD, qui est maintenant en accord avec la règle 4, n’est toutefois pas en accord avec la règle 5.
On constate effectivement que la propriété DIVNOM ne dépend pas directement de l’identifiant, mais dépend plutôt de la propriété DIVNUM.
La dépendance avec l’identifiant n’est pas directe mais plutôt transitive, par l’intermédiaire de la propriété DIVNUM.
Solution possible :
Pour pallier cet inconvénient, il suffit de mettre en place une entité DIVISION et une association TRAVAILLE qui traduit le fait qu’un salarié travaille dans une division.
On obtient alors le MCD suivant qui est maintenant normalisé avec la règle 5 :
| PROJET |
| NOMPROJ |
1,n
On a 6 règles de transformation standard permettant le passage d’un MCD au MLD correspondant.
Ces règles dépendent principalement des cardinalités.
Régle1 : Les entités deviennent des tables.
Les propriétés des entités deviennent les colonnes des tables.
Les identifiants des entités deviennent clés primaires des tables.
Régle2 : Lorsque l’association a un lien X,1 , il y a migration des clés. Soit l’association ASSOC présentant les cardinalités suivantes:
Elle n’est pas traduit par une table au niveau de MLD généré, mais est explicitée en plaçant dans la table A la clé primaire de la table B qui devient alors clé étrangère
On obtient alors le schéma relationnel (=M L D) suivant : schéma relationnel A ( IDA , prop 1 A, prop 2A , IDB ) = :
M L D B (I D B ,prop B )
le schéma relationnel peut être représenté graphiquement par :
M P D :
* Si l’association ASSOC est porteuse de popriété, elle donne lieu à la mise en place d’une table supplémentaire dont la clé primaire est obtenue par concaténation des identifiants des entités participantes à l’association.
On obtient alors le schéma relationnel suivant:
schéma relationnel
= : A(IDA, prop1A, prop2A )
M.L.D B(IDB, propB)
Assoc (IDA, IDB, ., propriété)
Représenté graphiquement par :
| A |
| IDA prop1A prop2B |
MPD :
* Si l’on utilise le concept de lien identifiant comme le MCD ci-dessous:
L’identifiant de l’entité A est alors constitué de la concaténation des identifiants des entités participant à l’association conformément au schéma relationnel ci-dessous:( MLD)
A (IDB, IDA, prop1A, prop2A) B(IDB, propB)
Règle 3 :
Soit l’association ASSOC présentant les Cardinalités suivantes :
A B
prop 1AIDA ..,n ..,n porp BIDB ASSOC prop 2A
Elle devient une table ASSOC au niveau du M.L.D généré, sa clé primaire étant obtenue par concaténation des identifiants des entités participant à l’association. Si l’association est porteuse de propriétés , Celles-ci deviennent des colonnes de la table ASSOC . SCHEMA RELATIONNEL (=MLD ) :
A(IDA , Prop 1A , Prop 2A)
B(IDB , Prop B )
ASSOC (IDA , IDB , , Propriétés )
REPRESENTEE GRAPHIQUEMENT PAR :
A A B
IDA IDAIDB
prop 1A IDB porp B prop 2A propriétés
La notion d’association du MCD est donc traduite en fonction des Cardinalités associées de deux manières :
Soit par l’utilisation du concept de clé étrangère ( règle 2 )
Soit par mise en place d’une nouvelle table (règle 2 & 3 ) Ce qui exige le bon choix des cardinalités !!
REGLE 4 :
Soit l’association ASSOC présentant les cardinalités suivantes
Elle peut :
* Soit permettre la réunion des entités en une seule entité, et l’on obtient alors le schéma relationnel suivant :
AB ( IDA, prop1A, prop2A, IDB, propB)
* Soit conserver les deux entités reliées, en provoquant dans chacune d’entre elles la migration respective de leurs identifiants. On obtient alors le schéma relationnel suivant :
A ( IDA, prop1A, prop2A, IDB ) B ( IDB, propB, IDA )
REGLE 5 :
Les entités qui ne sont pas porteuses d’autres données que leur identifiant
peuvent disparaître du modèle logique des données.
REGLE 6 :
Cette règle concerne essentiellement la prise en compte des entités génériques
et des entités spécifiques.
Soit le MCD suivant :
Le logiciel AMC * designor offre 3 possibilités concernant la génération du MPD :
1)
MLD MPD
Pere (ident pere , prop pere)
Fille1 (ident pere , prop f1)
Fille2 (ident pere , prop f2)
Generer une table pour chaque entité ce qui se traduit par la migration de l’identifiant de l’entité générique ou pére dans chaque entité fille.
2)
MLD MPD
| Pere |
| ident pere prop pere prop f1 prop f2 |
Pere (ident pere , prop pere , prop f1 , prop f2)
Générer une table pour chaque l’entité pére uniquement , ce qui se traduit par la remontée des propriétés de chaque entité fille au niveau de l’entité pére.
3)
MLD MPD
| Fille1 | Fille2 | |
| ident pere prop pere prop f1 | ident père prop père prop f2 |
Fille 1(ident pere , prop pere , prop f1 )
Fille 2(ident pere , prop pere ,prop f2)
Génerer une table pour entité fille uniquement, ce qui se traduit par la migration de tout les propriétés de l’entité pére vers les entité filles.
