Cours avancé sur la méthode Merise : les structures

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)

DEMARCHE PAR NIVEAUX                                       +

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).

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).

LES 3 NIVEAUX DU CYCLE D’ABSTRACTION

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.

PHASES D’ETUDE

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é.

Courbe du soleil

Conception Du Future Système

LES DONNEES EN MERISE

(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.

MODELE  RELATIONNEL

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 :

Lexique:

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é :

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é:                                              

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 :

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 :

                                                                                                                                                                                              1,n

Passage du MCD au MPD

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 :

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)

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

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.