1.1 Concepts de base

SI.1 /Introduction aux SI 2012-2013

1

1.1 Concepts de base

1.1.1 Système

Un système est un ensemble d’éléments matériels ou immatériels en interaction, organisés enfonction d’un objectif. C’est un tout constitué d’éléments unis par des relations. Ces éléments etces relations sont munis de propriétés.

Donc, "décrire un tel système consiste à déterminer ses éléments, ses relations, leurs propriétés etles valeurs que peuvent prendre ainsi que son activité et l’organisation qui en découle"

Exemples :

- le système "Scolarité" est composé des éléments Professeur, Etudiant, Cours etDépartement.

- les propriétés qui peuvent décrire ces éléments sont par exemple : le matricule duprofesseur, son nom, le numéro d’inscription de l’étudiant, le code du cours, son titre,l’adresse du département, etc.

- les relations entre éléments sont : la relation est rattachée entre Professeur etDépartement et la relation suit entre Etudiant et Cours.

- Les propriétés de ces relations sont du type date d’affectation, note, etc.

1.1.2 Système d’Information dans l’Entreprise

L’entreprise est un système complexe dans lequel transitent de très nombreux flux d’informations.Sans un dispositif de maîtrise de ces flux, l’entreprise peut très vite être dépassée et ne plusfonctionner avec une qualité de service satisfaisante. L’enjeu de toute entreprise qu’elle soit denégoce, industrielle ou de services consiste donc à mettre en place un système destiné à collecter,mémoriser, traiter et distribuer l’information (avec un temps de réponse suffisamment bref). Cesystème d’information assurera le lien entre deux autres systèmes de l’entreprise : le systèmeopérant et le système de pilotage.

N°Inscnom

« suit »

noteCours

codetitreEtudiant

matriculenom

« est rattaché »

date affectationDépartement

codeadresseProfesseur


2

figure 1.1 Sous-systèmes de l’organisation

Le système de pilotage décide des actions à conduire sur le système opérant en fonctiondes objectifs et des politiques de l’entreprise,

Le système opérant englobe toutes les fonctions liées à l’activité propre de l’entreprise :facturer les clients, régler les salariés, gérer les stocks, etc.

Une telle décomposition prend bien en compte :

- la différence de besoin en matière d’information des modules opérants et pilotes,

- la nécessité pour le système d’information de ne pas se contenter de transmettre lesinformations mais d’en changer le niveau de synthèse.

Dans certaines organisations, on peut trouver des formes plus intégrées du système d’information.Cette intégration peut se faire soit au niveau du système opérant (GPAO par exemple), soit auniveau du système de pilotage (SIAD par exemple).

1.1.3 Fonction du Système d’Information

La prise en charge des informations de l’organisation se traduit par :

- la collecte d’information ;- la mémorisation de l’information ;- le traitement de l’information ;- la diffusion de l’information ;

1.1.4 Système d’Information & Système Informatisé

Un système d’information est une représentation possible du système dont une partie peut êtreautomatisée ; on parle alors de système informatisé. Ce dernier prend appui sur un systèmeinformatique composé de matériels et de logiciels de base.

Système de Pilotage

Système d’Information

Système Opérant

information-représentationinformation-décision

information-interaction information-représentation

ExtérieurExtérieur


3

1.2 Modèles de Flux d’information

1.2.1 Modèles

Un modèle est une représentation (souvent graphique) de la réalité et est établi pour répondre àun type de questions que l’on se pose sur cette réalité. La notation (symboles) utilisée doit êtrealors suffisamment précise et riche. Les formalismes normalisés permettent en plus unecommunication sans ambiguïté.

En pratique la modélisation d’un système (aspect statique, dynamique et architectural) nécessitel’utilisation d’une combinaison de types de modèles (modèles de flux d’information, modèles dedonnées, modèles de traitements, etc.) pour obtenir une représentation complète du systèmeavec différents niveau d’abstraction (conceptuel, organisationnel et technique pour la méthodeMerise par exemple). Cette partie du cours présente les modes de représentation des fluxd’information dans l’organisation.

1.3 Flux d’Information

C’est l’ensemble des informations échangées entre acteurs et peut être interne, entrant ousortant du système d’information.

1.3.1 Domaines d’activités de l’organisation

Un domaine d’activités de l’organisation ou poste de travail est un sous-ensemble relativementindépendant constitué d’information, de règles et de procédures de gestion.

Pour mieux analyser une organisation, il est nécessaire de la découper en domaines d’activitésindépendants et de mettre en évidence les interactions entre ces domaines (flux internes) ainsique les échanges avec l’extérieur (flux externes).

1.3.2 Graphe de flux d’information

Ce graphe permet une représentation globale du système, des contraintes (événements) qui luisont imposées, et des réponses du système à ces contraintes (figure 1.2).

figure 1.2 diagramme de contexte

demande achat

proposition

commande

facture

règlement

VenteClient


4

Ce type de modèles peut servir également pour décrire les domaines d’activités de l’organisation(postes de travail) recevant et générant des flux externes (figure 1.3).

figure 1.3 graphe de flux d’information

1.3.3 Diagramme de Circulation d’information (tâche-document)

Ce diagramme permet de décrire comment sont réalisées actuellement les procédures et dedéfinir avec précision l’ensemble des objectifs recherchés et qui doivent être pris en considérationlors de la conception de la solution.

1.3.3.1 Recueil : une série d’interviews (ou questionnaires, enquêtes, etc.) des différentsintervenants dans l’organisation ; la direction (dégager une vue globale du système et l’ensembledes objectifs) et les postes de travail (description détaillée du domaine).

1.3.3.2 Formalisme : au fil des interviews, un diagramme tâche-document doit être construit pourpermettre de visualiser l’enchainement des tâches à travers les documents et/ou les informationsqui les déclenchent et ceux qu’elles produisent.

- La notation utilisée : à donner pendant le cours

Exemple :

- voir l’exemple du cours.

double commande

Caissier

demande achat

proposition

commande

facture

règlement

Vente

Client

SI.2 /Codification et Contrôles 2012/2013

5


Les informations traitées par ordinateur doivent être structurées : associer des codes auxinformations du système. Ces codes doivent permettre une désignation claire et unique desinformations.

Exemple. Soit le bon de commande suivant :

Les données qu'on peut extraire de ce document sont :Numéro commande, Date commande, Numéro client, Nom client, Adresse client, Référence produit,Désignation produit et Quantité commandée.

Les désignations de ces données sont trop longues et par conséquent très lourdes à manipuler. Lemieux, serait de les abréger sans perdre leurs significations :

Numéro commande : Num_Cde Date commande : Date_Cde Numéro client : Num_Cl Nom client : Nom_Cl …

De l'autre côté, pour différencier les clients, on doit affecter à leurs codes des valeurs différentes :

Valeur 1 : 3ème client dans la région centre Valeur 2 : 8ème client dans la région est …

Là encore, les données sont longues et, encore, on doit chercher à les abréger. Pour cela, nousallons représenter ces données par un code comme suit :

Région (C, E, O) Numéro du client par région

Valeur 1 : Num_Cl = C003

Bon de commande

Numéro commande : ……Date commande : ……

Numéro client : ……Nom client : ……

Adresse client : ……

QuantitéDésignationRéférence…..…..…..…..…..…..


6

Valeur 2 : Num_Cl = E008 …

La codification porte sur le Nom de l'information à codifier et aussi sur sa Valeur, et :

- ne doit pas être ambiguë (Num_C?),- doit s'adapter aux changements du système (Client numéro 1001 de la région Ouest?),- doit être concise et significative.

2.2 Types de codification

Il existe différents types de codification : séquentielle, par tranches ou articulée.

2.2.1 Codification séquentielle

Les numéros attribués aux informations sont consécutifs (1, 2, 3, …). C'est une codification trèssimple et non ambiguë, mais non significative et insertion impossible (sauf réutilisation).

2.2.2 Codification par tranches

Attribuer une tranche de codes à chaque catégorie d'objets à codifier (0-999 : info, 1000-1999 :math, 2000-2999 : physique, …). La codification est très simple et non ambiguë, mais nonsignificative et insertion impossible si le nombre d'informations à codifier dépasse l'intervalle descodes prévus.

2.2.3 Codification articulée

Attribuer des codes découpés en zones appelées descripteurs. Chaque descripteur a unesignification particulière relative à l'élément codifié.

Exemple. Immatriculation d'un véhicule :

0 0 2 1 5 1 0 5 1 9

Numéro séquentiel Catégorie Année Code wilaya

Significative et non ambiguë, insertion et extension possibles, mais les codes sont trop longs,possibilité de saturation et instabilité.

2.2.4 Codification par niveau

C'est un cas particulier de la codification articulée dans lequel les descripteurs sont des niveaux.

Exemple. Code postal :

1 6 3 2 0

Code wilaya Daïra Commune


7

2.2.5 Codification mnémonique

Associer au nom de l'élément, un nom abrégé qui rappelle l'élément codifié (code postal : C_P).C'est une codification simple et significative. Elle porte, cependant, sur le nom et non pas sur lavaleur.

2.3 Contrôles

L'objectif des opérations de contrôle est de vérifier l'exactitude et la conformité de l'information.

Exemple. Numéro étudiant dont la spécialité n'existe pas.

Les contrôles peuvent être directs; effectués sur l'information sans tenir compte des autresinformations du système, ou indirects; vérifier la conformité de l'information par rapport àl'ensemble des informations du système.

2.3.1 Contrôles directs

Les principaux contrôles directs sont :

- Contrôle de présence ou de non présence (abonné/nouveau);- Contrôle de type;- Contrôle de cadrage (position de l'information dans la zone de saisie).

2.3.2 Contrôles indirects

Parmi les contrôles indirects, on peut citer :

- Contrôle de cohérence interne (Numéro_Etud = Li.4.175 : année pour licence ≤ 3);- Contrôle de cohérence externe (DateNais = 1970 et Âge = 63);- Contrôle de vraisemblance (Date_Cde = 15/13/09 : mois ≤ 12).

SI.3 /Merise 2012/2013

12

3.1 Démarche de développement de systèmes logiciels

Le groupe d'étude (Project group)

Un système d'information qui n'est pas trop complexe et volumineux en termes d'informations,peut facilement être informatisé par une seule personne. Il suffit d'être un peu familiarisé avecune méthode de modélisation, et de savoir manipuler un SGBD pour réaliser une implémentationinformatique, cohérente et fonctionnelle, d'un tel système d'information.

Dès que le système d'information atteint une certaine envergure (par exemple: informatiser lagestion des sinistres d'une compagnie d'assurances), un groupe d'étude est généralement créé.

Ce groupe doit contenir en plus des informaticiens :

Un ou plusieurs représentants des futurs utilisateurs du système informatisé (Par exemple: Unemployé du service qui gère les sinistres) ;

Un ou plusieurs représentants de chaque département impliqué (Par exemple: Un employé duservice des contrats) ;

Un représentant de la direction.

Généralement, un responsable du groupe (Project Manager) est nommé, afin de coordonner lestravaux effectués par le groupe et de suivre le déroulement à partir de l'analyse jusqu'à la mise enplace du système informatisé.

Les étapes

Chaque projet d'informatisation, qu'il soit exécuté par une seule personne, ou géré par un grouped'étude, prévoit plusieurs étapes. En général, les principales étapes sont :

1. Analyse de la situation existante et des besoins;

2. Création d'une série de modèles qui permettent de représenter tous les aspects importants;

3. Implémentation du système logiciel correspondant.

Sources d'information

La première étape de chaque projet est donc l'analyse de l'existant et des besoins. Donc, il fautd'abord identifier les sources d'information, et puis rassembler les informations importantes pourle projet. Les principales sources d'information sont :

L'interview avec les utilisateurs;

Documents provenant du système d'information actuel (Bons de commandes, Factures …).

SI.3 /Merise 2012/2013

13

Pour les projets d'une certaine envergure s'ajoute :

L'interview avec les responsables des services impliqués;

Pour les projets qui se basent sur un système déjà partiellement informatisé s'ajoute:

L'étude de l'application informatique existante.

3.2 Merise

Nous avons vu que la démarche classique d'un projet informatique comprend les étapes suivantes:

1. Analyse de la situation existante et des besoins;

2. Création d'une série de modèles, qui permettent de représenter tous les aspects importants;

3. A partir des modèles, implémentation d'une base de données.

En ce qui concerne la première étape, nous n'allons pas introduire de vraies règles, maissimplement utiliser nos connaissances de gestion d'une entreprise, notre esprit ouvert et mêmenotre fantaisie pour analyser correctement la situation existante et les besoins des utilisateurs. Lerésultat de l'analyse est généralement un ou plusieurs documents, qui contiennent les indicationsprincipales sur le fonctionnement désiré du système informatisé. Le document d'analyse contientsouvent déjà des prototypes de certains documents importants, que le futur système devra êtrecapable de produire.

Une fois que l'analyse est terminée, il s'agit d'élaborer une série de modèles, basés sur ledocument d'analyse. Ces modèles nous permettront plus tard d'implémenter une application quirépondra à tous les besoins fonctionnels du système. La création de ces modèles se fait selon unecertaine méthode.

Nous allons baser notre cours sur la méthode MERISE (Méthode d'Etude et de RéalisationInformatique de Systèmes d'Entreprise), qui a été développée pendant les années 70. C'est uneméthode systémique qui sépare les données des traitements, prévoit une conception parniveaux, et définit pour cela 3 niveaux essentiels :

1. Le niveau conceptuel, qui se base directement sur l'analyse, décrit l'ensemble des données etdes traitements du système d'information, sans tenir compte de l'implémentation informatiquede ces données ni des détails organisationnels et techniques des traitements (quoi?). Ce niveause traduit par deux modèles conceptuels que nous appelons : Modèle conceptuel des données(MCD) et Modèle conceptuel des traitements (MCT).

2. Le niveau logique, qui se base sur le modèle conceptuel, prend en considération la techniqued'organisation de données et les détails organisationnels des traitements (qui, où et quand?).Ce niveau est représenté par les : Modèle logique des données (MLD) et Modèleorganisationnel des traitements (MOT).

SI.3 /Merise 2012/2013

14

3. Le niveau physique, qui se base sur les modèles du niveau précédent, contient finalement tousles détails d'implémentation du système de données et des traitements (comment?). Ce niveauest représenté par les : Modèle physique des données (MPD) et Modèle opérationnel destraitements (MOpT).

Voici donc les étapes nécessaires pour automatiser un système d'information :

La validation

Définir les données d'une application de manière complètement indépendante des traitementsconduit nécessairement à un échec global. En faite, les traitements utilisent, manipulent etproduisent des données. Donc, il serait indispensable de valider le modèle de données par lestraitements avant de passer à l'implémentation. Cette validation vise à rajouter les donnéesnécessaires (qui ne sont pas encore définies dans le MCD) et de supprimer les données inutiles(qui sont définies dans le MCD mais qui ne sont utilisées par aucun traitement).

MCT

MOT

MOpT

Analyse

MCD

MCD validé

MLD

MPD

Validation

SI.4 /Modèle Conceptuel de Données 2012/2013

15

4.1 Définition

En se basant sur un document d'analyse, le modèle conceptuel des données (MCD) fait référence àtous les éléments du système d'information et aux relations entre ces éléments. Le formalismeutilisé dans ce modèle est connu sous le nom de "Schéma Entité-Relation". Ce formalisme se basesur trois concepts principaux, les entités, les relations et les propriétés.

Voici par exemple un MCD qui représente une entreprise avec ses employés.


a. Entité (individu ou objet). Une entité permet de modéliser un ensemble d'objets concrets ouabstraits de même nature. Une entité est caractérisée par son nom et ses propriétés.

Exemple : Employé, entreprise, Etudiant, Cours, etc.

Représentation graphique :

Voici un exemple de l'entité Etudiant :

Entité

Propriété Relation

Num_EtudiantNom_EtudiantDN_EtudiantAdr_Etudiant

Etudiant


16

Chacun des étudiants suivants représente une occurrence de l'entité Etudiant.

b. Propriété. Une propriété est une donnée élémentaire d'une entité. Elle est unique dans unMCD; et ne peut pas être rattachée à plusieurs entités différentes. Une propriété est caractériséepar :

son type (Numérique, Alphabétique, etc.), sa longueur (taille en caractères), et sa nature (élémentaire, calculée ou concaténée).

Exemple : Nom de l'étudiant, Adresse de l'étudiant, etc.

A l'intérieur de chaque occurrence, chaque propriété prend une valeur, qui est dans la plupart descas une valeur numérique, une valeur sous forme de texte ou encore une date.

Exemple : La propriété Nom_Etud de l'entité Etudiant prend par exemple les valeurs "Ahmed","Omar" et "Fatima" dans les 3 occurrences de l'exemple précédent.

A l’intérieur de chaque occurrence, chaque propriété ne prend qu’une seule valeur au maximum.

Exemple : L'étudiant 095 ne peut pas avoir 2 adresses.

c. Identifiant

Afin de pouvoir distinguer les différentes occurrences d'une même entité, l'entité doit être dotéed'un identifiant. Chaque occurrence de l'entité doit avoir une valeur différente pour l’identifiant.Le choix de l'identifiant repose sur 3 possibilités:

1. Une propriété naturelle

Exemple: Le nom d'un pays pour une entité Pays

2. Une propriété artificielle qui est inventée par le développeur du MCD

Exemple: Le numéro d'un étudiant (Num_etud)

3. Une propriété concaténée (composée d'autres propriétés naturelles)

Exemple: Le nom et la localité pour une entité Entreprise (NomEntr_NomVille)

017Ahmed12/03/94Sétif

:Etudiant

095Omar06/02/94El-Eulma

:Etudiant

129Fatima31/05/95Sétif

:Etudiant


17

Dans le formalisme utilisé, l'identifiant d'une entité est une propriété soulignée en tête del'ensemble des propriétés.

d. Relation. Une relation décrit un lien entre deux ou plusieurs entités (collection de la relation).Elle possède un nom, généralement un verbe à l'infinitif. L'existence de la relation estconditionnée par celle des entités qui participent à cette relation.

La relation n'a pas d'identifiant propre, mais elle est implicitement identifiée par la concaténationdes identifiants des entités qui participent à cette relation.

1. Dimension d'une relation : c'est le nombre de pattes de la relation. Le nombre de pattes n'estpas nécessairement identique au nombre d'entités. Il représente plutôt le nombre d'occurrencesd'entités qui doivent participer à une occurrence de la relation.

Nous distinguons des relations :

binaires, qui possèdent 2 pattes; ternaires, qui possèdent 3 pattes; n-aires, qui possèdent n pattes.

Exemple d'une relation binaire:

2. Cardinalités d'une relation

Une relation est liée à chacune de ses entités par une ou plusieurs pattes. Sur la patte, on indiqueles cardinalités qui précisent le nombre de participations de chaque occurrence de l'entité à larelation. Le premier nombre indique la cardinalité minimale, le deuxième la cardinalité maximale.

Patte

Cardinalité minimaleCardinalité maximale


18

Exemple :

Dans cet exemple, entre l'entité Client et la relation Passer, nous avons les cardinalités suivantes:

Cardinalité minimale = 1, ce qui signifie que chaque client passe au moins une commande.

Cardinalité maximale = n, ce qui signifie que chaque client peut passer plusieurs (n) commandes.

Entre l'entité Commande et la relation Passer, nous retrouvons les cardinalités suivantes:

Cardinalité minimale = 1, chaque commande est passée par au moins un client.

Cardinalité maximale =1, chaque commande est passée au maximum par un seul client.

De façon générale, quatre types sont distingués :

0,1 : chaque occurrence participe au plus une seule fois à la relation. 1,1 : chaque occurrence participe une et une seule fois à la relation. 1,n : chaque occurrence participe au moins une fois à la relation. 0,n ; aucune précision n'est donnée quant au nombre de participations.

Comme cas particulier, la modélisation suivante par exemple n'est pas correcte:

Dans ce cas, il faut réunir les propriétés des deux entités dans une seule.


19

3. Propriétés d'une relation

Une relation peut généralement être porteuse de propriétés.

Exemple:

f. Règles de gestion

Les règles de gestion précisent les contraintes qui doivent être respectées par le modèle.

Exemples : pour un magasin,

Une personne habite dans une et une seule maison; Plusieurs personnes peuvent habiter dans la même maison; Une personne peut être propriétaire de plusieurs maisons; Pour une maison, nous avons au moins un propriétaire.

Les règles de gestion expriment les contraintes d'intégrité du modèle (les lois de l'univers réelmodélisé dans le SI).

4.3 Cas particuliers du MCD

a. Plusieurs relations différentes entre deux entités

Il est possible d'avoir plusieurs relations différentes entre deux mêmes entités. Chacune de cesrelations possède évidemment une sémantique différente. Le rôle de l'entité diffère alors d'unerelation à une autre.

Exemple :

Une personne, peut être l'habitant d'une maison et/ou le propriétaire de la maison. Ici, habitant etpropriétaire sont des rôles joués par l'entité Personne.


20

b. Relation réflexive et rôle d'une patte de relation

Exemple :

Une relation réflexive, est une relation, dont les deux pattes sont liées à une même entité. Engénéral, la signification des pattes d'une relation réflexive devrait être clarifiée par l'indicationd'un rôle.

Nous avons donc:

4.4 Dépendances fonctionnelles

4.4.1 Définition

Les propriétés a et b sont reliées par une dépendance fonctionnelle a –df b, si la connaissancede la valeur de a détermine une et une seule valeur de b.

Exemple : Num_Etud –df Nom_Etud.

La dépendance fonctionnelle peut porter sur la concaténation de plusieurs propriétés.

Exemple : NumCommande + RéfProduit –df QtéCommandée.

4.4.2 Dépendance fonctionnelle élémentaire

Il y a dépendance fonctionnelle élémentaire entre les propriétés a et b et on note a b, sia –df b et aucune partie de a ne détermine b.


21

Exemple : Num_Etud+Nom_Etud –df Adr_Etud n'est pas élémentaire puisque la connaissancede Num_Etud suffit pour déterminer Adr_Etud.

Par contre, Num_Etud –df Adr_Etud est élémentaire et on note Num_Etud Adr_Etud.

4.4.3 Dépendance fonctionnelle élémentaire directe

Les propriétés a et b sont reliées par une dépendance fonctionnelle élémentaire directe si ab ets'il n'existe pas une propriété c telle que a –df c et c –df b. autrement dit, on élimine toutetransitivité.

Exemple :

NumProf CodeMatière

CodeMatière NomMatière

NumProf NomMatière.

Les deux premières dépendances fonctionnelles sont directes, mais la troisième ne l'est pas :transitivité NumProf CodeMatière NomMatière.

4.4.4 Clé d'une entité

Toutes les propriétés d'une entité doivent dépendre fonctionnellement de sa clé et ceci n'est plusvrai pour aucune des parties de cette clé.

Exemple 1 :

Num_Etud+Nom_Etud n'est pas une clé puisque Num_Etud détermine Adr_Etud. En revanche,Num_Etud est une clé car :

Num_Etud –df Nom_Etud

Num_Etud –df Adr_Etud

4.4.5 Propriétés des dépendances fonctionnelles

Réflexivité : a –df a

Projection : a –df b+c a –df b et a –df c

Augmentation : a –df b a+c –df b

Additivité : a –df b et a –df c a –df b+c

Transitivité : a –df b et b –df c a –df c

Pseudo-transitivité : a –df b et b+c –df d a+c –df d


22

4.5 Règles relatives au MCD

Tout MCD doit être normalisé, vérifié et décomposé.

4.5.1 Normalisation des entités

Les entités du MCD doivent vérifier les règles suivantes :

a. 1ère forme normale : dans une entité, toutes les propriétés sont élémentaires et il existe au moisune clé caractérisant chaque occurrence (identifiant).

Exemple : (voir exemple du cours)

b. 2ème forme normale : toutes les propriétés d'une entité doivent dépendre de la clé par unedépendance fonctionnelle élémentaire.


c. 3ème forme normale : dans une entité, les propriétés doivent dépendre de la clé par unedépendance fonctionnelle élémentaire directe.


d. forme normale de Boyce-Codd (BCNF) : si l'entité possède un identifiant concaténé, un deséléments composant cet identifiant ne doit pas dépendre d'une autre propriété.


L'objectif de la normalisation est d'éliminer la redondance (répéter la désignation du produitcommandé à chaque commande du même produit) et les anomalies de mise-à-jour (annuleremployé annuler catégorie)

4.5.2 Vérification

Dans toute occurrence d'entité ou de relation, il ne doit y avoir qu'une seule valeur de chaquepropriété. Pour les entités ceci résulte de la première forme normale.


"Les propriétés d'une relation doivent dépendre fonctionnellement des identifiants des entitésconcernées par la relation. La concaténation de ces identifiants forme l'identifiant de la relation."

4.5.3 Normalisation des relations

Chaque propriété d'une relation doit dépendre fonctionnellement de l'ensemble des identifiantsdes entités de la collection de cette relation, mais d'aucun sous-ensemble.



23

4.5.4 Décomposition des relations

La décomposition consiste à remplacer une relation de dimension n (supérieure à 2) en plusieursrelations de dimensions plus petites en utilisant les dépendances fonctionnelles présentes sur larelation.

La décomposition n'est possible que si les deux conditions sont vérifiées :

1. Cardinalité minimale des entités à gauche de la dépendance fonctionnelle doit être 1 dansla relation à décomposer;

2. Si la dépendance fonctionnelle provient d'une autre relation, il faut qu'elle concerne lesmêmes occurrences d'entités que la relation à décomposer.


4.6 Démarche de construction du MCD

1. Etablir la liste des données recensées : cette liste est appelée dictionnaire de données.2. Epurer le dictionnaire de données : ne garder que les données utiles pour le SI. De ce fait,

les synonymes, les polysémies, les données calculées et les données concaténées doiventêtre supprimées. Le formalisme du DD est le suivant :

Code Désignation Type Taille ObservationCode_F Numéro du fournisseur N 3Nom_F Nom du fournisseur A 20Adr_F … .. ..Date_Cde Date de la commande Date ......

… .. ..

3. Etablir le graphe des dépendances fonctionnelles (structure d'accès théorique) : à partirdes règles de gestion.

a. Il ne faut garder que les dépendances fonctionnelles élémentaires directes,b. S'il reste des propriétés isolées, proposer des identifiants qui permettent de les

déterminer.4. Construire le MCD :

a. Les arcs terminaux d'une même origine Entité,b. Les arcs restants qui relient deux ou plusieurs entités traduisent des relations entre

ces entités,c. Tenir compte des règles de gestion qui ne sont pas encore couvertes (celles qui

n'expriment pas de dépendances fonctionnelles),d. Normaliser, vérifier et décomposer le MCD brut


24

5. Quantifier le MCD : description des entités et des relations.a. Description des entités :

Entité Identifiant Propriétés Longueur Nombres occurrences

…. ….

b. Description des relations :

Relation Entités Cardinalités Propriétés Longueur Nombres d'occurrences

…. ….

SI.5 /Modèle Conceptuel des Traitements 2012/2013

25

5.1 Objectifs

Dégager les actions menées par l’entreprise, indépendamment de la façon dont cette dernière achoisi de les organiser. Le MCT exprime ce qu’il faut faire(le Quoi), mais n’indique pas Qui, Quandet Où (Concepts Organisationnels) ni Comment il faut le faire (Concepts Opérationnels).

5.2 Définitions

1. Evénement : traduit un fait nouveau dans le système qui peut être déclencheur (ex. arrivéed’une commande) ou résultat (ex. facture établie) d’une opération du SI. Ce fait est porteurd’information.

2. Opération : ensemble d’actions accomplies en réaction à un événement ou à uneconjonction d’événements déclencheurs et produit en sortie de nouveaux événements.L’enchainement des actions dans une opération conceptuelle est ininterruptible et touteattente d’un événement externe provoque un découpage de l’opération.

3. Synchronisation : c’est la représentation d’une pré-condition au déclenchement d’uneopération ; c’est une association d’événements. L’opération est déclenchée après arrivéesdes événements contributifs selon une proposition logique (OU et ET).

4. Règle d’émission : condition traduisant les règles de gestion, auxquelles est soumisel’émission des résultats d’une opération. Ces règles doivent couvrir l’ensemble dessituations possibles de façon que l’opération émette toujours un résultat.

5. Processus : c’est un enchaînement d’opérations propre à un domaine d’activités. C’est unsous-ensemble d’activités dont les points d’entrée et de sortie sont stables etindépendants des choix organisationnels.

5.3 Formalisme

Le formalisme utilisé est le suivant :

5.4 Exemple (voir exemple du cours)

Event1 Eventn

R1 Rj

Nom Opération

Liste actions

Règle émission 1 Règle émission 2

Synch

SI.6 /Modèle Organisationnel des Traitements 2012/2013

26

6.1 Objectifs

Fournir une représentation schématique de l’organisation du SI en répondant aux questions :

Où? : le poste de travail concerné.

Qui? : nature du traitement manuel ou automatisé (batch ou conversationnel).

Quand ? : le temps et la durée (déroulement).

Merise n’impose aucun choix organisationnel. La méthode offre simplement des outils permettantde décrire l’organisation retenue.

6.2 Définitions

1. Règle d’organisation : ce qui est mis en place en termes de poste de travail, de nature detraitement et de chronologie.

2. Evénement : fait réel dont l’occurrence déclenche une ou plusieurs procéduresfonctionnelles (ex. arrivée déclaration sinistré).

3. Procédure fonctionnelle : ensemble d’actions de même nature accomplies dans un postede travail en réaction à un déclencheur de manière continue et complète.

4. Synchronisation : condition logique traduisant les règles de gestion et d’organisation quedoivent vérifier les événements pour déclencher les procédures. Le déroulement (temps etdurée) fait partie intégrante de la synchronisation (ex. demande inscription et début année)

5. Règle d’émission : condition traduisant les règles de gestion et d’organisation, auxquellesest soumise l’émission des résultats d’une procédure.

6.3 Formalisme

Le formalisme utilisé est le suivant :

6.4 Exemple (voir exemple du cours)

Event1 Eventn

R1 Rj

Nom Procédure

Liste actionsRègle émission 1 Règle émission 2

Synch

Nature Poste detravail

Déroulement Enchaînement des Procédures Fonctionnelles

SI.7 /Validation du MCD 2012/2013

27

7.1 IntroductionChaque traitement possède son modèle externe (vue externe) qui reflète la vision que possèdel’utilisateur des données à travers la procédure (procédure fonctionnelle automatisée). C’est unMCD construit dan l’optique d’un seul traitement sans se préoccuper du MCD réel.

La validation permettra d’ajuster MCD et vues externes (mettre en accord données ettraitements).

7.2 Formalisme

Utilisation du formalisme entités/relations. Cependant, L’identifiant n’est pas obligatoire etutilisation du vocabulaire du dictionnaire de données pour les propriétés externes quicorrespondent à des propriétés conceptuelles.

7.3 Construction des ME

Construire une vue externe pour chaque traitement de consultation ou de mise-à-jourd’une même procédure fonctionnelle automatisée :

o Consultation : à partir des données produites

o Mise-à-jour : à partir des données entrantes

Une PF peut avoir donc plusieurs modèles externes.

Appliquer les règles de normalisation, vérification et décomposition

Les propriétés, entités ou relations externes peuvent ne pas exister dans le MCD

7.4 Validation du MCD

Les principales étapes de validation sont les suivantes :

Valider les ME en consultation ; ajouter les propriétés externes qui ne sont pas encoredéfinies dans le MCD. Toute modification du MCD implique une réévaluation des ME

Valider les ME en m-à-j de la même manière

Toute propriété conceptuelle est manipulée dans une vue externe au minimum

Supprimer du MCD toutes les propriétés conceptuelles qui ne participent à aucune vueexterne

Construire le MCD validé en tenant compte des modifications apportées.

SI.8 /MLD 2012/2013

28

8.1 IntroductionJusqu'à présent nous avons établi des MCD basés sur une analyse d'un domaine bien défini. Lafinalité d'un MCD est de nous faciliter la création d'un système de données pour gérer un teldomaine.

Au niveau organisationnel, il faut intégrer les choix d'organisation (gestion des données) ettranscrire le MCD validé dans un formalisme dépendant du choix organisationnel sans tenircompte des techniques de stockage et d'accès (niveau opérationnel). L'organisation peut êtrerelationnelle (bases de données), navigationnelle (fichiers), Hiérarchiques, etc.

Le modèle logique des données contient donc, toutes les informations du MCD, et les représenteà l'aide d'un formalisme différent qui tient compte de la manière dont les données du systèmesont organisées.

8.2 Contexte relationnel

Raisonner en termes de relations qui existent entre les différentes propriétés (ne pas confondreavec les relations du modèle conceptuel qui expriment des associations entre entités.

Voici un exemple qui montre un MCD avec son MLD relationnel correspondant:

Le MLD correspondant : AUTEUR (No_Auteur, Nom) LIVRE (No_Livre, titre, No_Auteur)

8.3 Règles de passage du MCD au MLD relationnel

Nous allons définir les règles de transformation pour le passage du MCD au MLD relationnel, enrespectant les différents cas qui se posent.

Les entités deviennent des relations au sens relationnel (leurs propriétés deviennent desconstituants de la relation)

Une relation R du MCD du type :

disparaît dans le MLD. L'identifiant de A étant incorporé à la relation B (au sens relationnel)

0,1ou 1,1A

0,nou 1,n

BR

SI.8 /MLD 2012/2013

29

Une relation R du MCD du type :

devient une relation relationnelle dans le MLD. La clé étant obtenue de la concaténation desidentifiants des entités qui participent à la relation conceptuelle. Si R est porteuse de propriétés,celles-ci deviennent des constituants de la relation relationnelle.

Cas particuliers

Un MCD du type :

Se traduit de la manière suivante :A (Id_A, …., Id_B) avec B (Id_B, …) ou A(Id_A, …) avec B (id_B, …,Id_A)

Les Relations réflexives du type :

se traduit comme suit : A (id_A, …., Id_A)

On applique les règles générales avec la seule différence que la relation est 2 fois reliée à lamême entité.

Application. Pour le MCD suivant :

Voici le MLD relationnel correspondant :

CLIENT (No_Client, Nom, Prénom, Adresse, Code_Postal, Localité)FACTURE (No_Facture, Date, No_Client)ARTICLE (No_Article, Libellé, Prix_Unitaire)PORTER (No_Facture+No_Article, Quantité)

0,nou 1,nA

0,nou 1,n

BR

0,1ou 1,1A

0,1ou 1,1

BR

1,n

A1,1

R