dimanche 10 avril 2011

Cours Système D'analyse Merise

1.  INTRODUCTION.

1.1.  Définition de l’analyse.

L’informatique est la science du traitement rationnel de l’information, notamment par machine automatique.

Les ordinateurs sont capables de traiter les informations très rapidement et en grande quantité.  Toutefois, cette capacité de traitement, la vitesse à laquelle ils se feront et la fiabilité des résultats obtenus, ne peuvent être optimisés que si l’on passe au préalable par une préparation minutieuse des divers travaux à effectuer.  Cette préparation se traduit bien en amont de l’élaboration des programmes par l’étude des informations que nécessitent ces traitements.

L’objet de l’analyse informatique est donc de mettre en évidence les informations nécessaires aux divers traitements permettant d’obtenir les résultats recherchés.  On estime que cette analyse comporte  5 étapes :

  • analyse préalable
  • analyse conceptuelle ( ou analyse fonctionnelle )
  • analyse organique
  • programmation
  • tests et mise au point

1.2.  MERISE   ?

MERISE est né en 1978 et s’est fortement implanté dans les entreprises.  MERISE est caractérisé par :

Une approche systémique.

MERISE définit une vision de l’entreprise en terme de systèmes.  On peut considérer qu’une entreprise est constituée de 3 systèmes :

  • Le système de pilotage qui dirige l’entreprise et fixe les objectifs.
  • Le système opérationnel qui assure la production.
  • Le système d’information qui assure le lien entre les autres.  Nous traiterons surtout celui-ci.


La séparation des données et des traitements.


Dans MERISE, les informations à traiter ( données ) et les traitements de ces données font l’objet de démarches d’étude séparées qui peuvent même être menées en parallèle par des équipes distinctes.

La conception par niveaux.

MERISE distingue 3 niveaux de description du système d’information :
  • Le niveau conceptuel : son rôle consiste à définir précisément les qualités de l’entreprise.  Il décrit l’ensemble des données stables ou variantes du système d’information et l’ensemble des règles de gestion à y appliquer sans tenir compte d’un quelconque matériel d’informatique devant supporter ces informations.
  • Le niveau organisationnel ou logique : son rôle consiste à définir l’organisation qu’il est souhaitable de mettre en place pour atteindre les objectifs souhaités.  On y précisera les postes de travail, la chronologie des opérations et l’emploi des bases de données.
  • Le niveau physique ou opérationnel  : il définit les organisations physiques des données et la description des traitements effectués par chaque unité de traitement.

Comme dans chaque niveau doit être respectée la séparation des données du traitement, cela peut se résumer :



En théorie, on peut procéder à une estimation du temps passé par étape :

Analyse de l’existant          :      30 %
MCD + MCT + MOT      :     40 % ( en parallèle )
MLD                                :    15 %
MPD et MopT                  :    15 %.

2.  DEMARCHE D’INFORMATISATION.

L’automatisation des tâches d’une entreprise ne doit pas se faire d’une manière désordonnée mais découle d’une succession de phases.

2.1.  Détection d’un besoin d’automatisation.


La détection d’un besoin d’automatisation provient généralement :
  • d’un plan d’entreprise quand il existe
  • de la demande émanant d’un service
  • de l’observation de dysfonctionnements

Parfois, l’automatisation est existante mais ne rend pas tous les services attendus.

2.2.  Etude d’opportunité.

L’étude d’opportunité ou de faisabilité va permettre d’étudier le projet d’automatisation et de décider de sa faisabilité technique, humaine ou financière.  Cette étude peut être décomposée en étapes qui sont :
  • Constitution d’un groupe d’étude : il doit être composé d’informaticiens mais aussi des organisateurs et des futurs utilisateurs.  Un des responsables suivra le déroulement de l’automatisation jusqu’à sa mise en place.
  • Etablissement d’un planning prévisionnel : il est établi par le groupe d’étude et portera sur les trois étapes suivantes.
  • Analyse de l’existant : il s’agit d’identifier les flux d’informations et les stations traversées par ces flux en relevant les documents, les supports, les traitements et les avatars subis.  Comment ?
+      Il faut procéder à l’interview de toutes les personnes concernées de près ou de loin par les informations.  On pose les questions traditionnelles : qui, quoi, où, quand, comment, pourquoi, combien.  On n’hésite pas à poser plusieurs fois les mêmes questions aux mêmes personnes car elles peuvent se contredire.

+     L’étude de tous les documents ( factures, formulaires, notes, informations verbales ) doit recouper les renseignements obtenus lors des interviews.

+    Tous ces renseignements seront résumés dans des schémas :  Voici tout d’abord le

diagramme des flux :




 Schéma de circulation des documents




T1 : Création du bon ce commande (BC)
T2 : Enregistrement commande et visa du bon de commande
T3 :  Préparation et envoi commande et création de l’avis d’expédition (AE)
T4 :  Envoi du bon de commande pour établir la facture
T5 :  Création de la facture (F) et de sa copie (CF)
  • Critique de l’existant : fournit un état de la situation actuelle et tente de faire apparaître ( objectivement ) les défauts et les qualités de ce qui existe déjà. Cette critique peut déboucher sur la remise en cause des structures, des postes, des hommes, des documents…
  • Ebauche de solutions : il s’agit d’établir une ou plusieurs propositions de solution globale, permettant de pallier aux carences repérées lors de la critique de l’existant.  Il faut faire apparaître les axes fondamentaux des solutions proposées et les moyens à mettre en œuvre pour arriver à atteindre les objectifs fixés tout en respectant les contraintes détectées.

2.3.  Le cahier des charges.


Le cahier des charges est un document mentionnant les délais, les coûts, les devoirs et les obligations de chacune des parties au contrat.  Ce document engage donc le concepteur et le promoteur de l’automatisation.

2.4.  Etude du système d’information.

Il s’agit de la partie conceptuelle de l’analyse.  Nous allons développer tout particulièrement cette partie dans la suite du cours.  Cette étude prendra en considération tous les éléments du système :

        +    les entrées et les sorties d’informations
        +    les traitements automatisables et les traitements manuels
        +    les données
        +    la structure des données

2.5.  Etude du système informatique.

Il s’agit de la partie organique de l’analyse.  Elle va définir l’architecture des éléments du système informatique à mettre en œuvre ( fichiers, bases de données, , entrées, sorties, traitements, …) en respectant les spécifications mises en évidence par l’étude du système d’informations et spécifiées par le cahier des charges.

2.6.  Programmation et essais.


  • conception des programmes (algorithmes, arbres programmatiques, …)
  • écritures des programmes à l’aide d’un langage approprié
  • mise au point des programmes à l’aide des jeux d’essais

2.7.  Mise en place de l’application.


  • en mettant directement l’application à disposition du client
  • en remplacement des anciennes procédures
  • en parallèle avec les anciennes procédures

3.  L’INFORMATION.

3.1.  Définition.

L’information est un élément qui permet de compléter notre connaissance sur un objet, un événement, un concept,…

Cette information peut se présenter sous diverses formes :
  • la forme écrite
  • la forme symbolique ( des signes particuliers,…)
  • la forme orale

Le système d’information d’une entreprise peut alors être considéré comme étant constitué d’un ensemble de flux d’informations qui transitent entre diverses stations.




Les stations sont les endroits où l’information est traitée.  Parfois, on peut subdiviser cette station en
sous-stations.

Le flux peut se traduire par des documents écrits ou par des informations orales échangés entre 2 stations.

Pour une automatisation réussie, l’information devra être cernée et classifiée de manière très précise et devra également pouvoir être représentable dans le système informatique.  On distinguera ainsi :
  • la classification de l’information
  • le mode de représentation de l’information

3.2.  Classification de l’information.

Les catégories d’informations.
  • les informations élémentaires : on ne peut pas inventer sa valeur.  Pour pouvoir s’en servir, on doit connaître sa valeur ( exemple : le nom d’un employé )
  • les informations paramètres : un paramètre est une rubrique dont la valeur est constante et prévisible.  On peut estimer que sa valeur est connue et la même pour tout et pour tous ( exemple : un taux de TVA connu et identique pour tous les articles )
  • les informations résultantes : elles sont obtenues par un traitement arithmétique ou logique
  • les informations de commande : il s’agit ici des traitements ( calcul, comparaisons ) à effectuer

Autres classifications des données.
  • interne ou externe
  • quantitative ou qualitative
  • permanente ou temporaire

3.3.  Le mode de représentation des données.


 Il s’agit ici de déterminer de quel type les données seront utilisées par le programme
  • alphabétique pur
  • alphanumérique
  • numérique
  • date
  • logique Booléen

Bien souvent, on détermine par la même occasion la taille de l’information.

3.4.  Le dictionnaire des données.


Le recensement des informations est le préalable absolu à toute démarche d’automatisation.  Il existe 2 méthodes :
  • la méthode ascendante : très pratique pour une nouvelle informatisation ; elle consiste à étudier toutes les sorties à obtenir et à remonter vers les données nécessaires à l’obtention des résultats figurant sur ces sorties.
  • La méthode descendante : à utiliser sur un système existant ; elle consiste à recenser toutes les informations du système rencontrées sur les divers documents en service et à y ajouter les nouvelles données nécessaires aux nouveaux traitements.

Le recensement des informations et de leurs catégories permet de constituer le Dictionnaire des Données ou parfois Lexique des Données.  Il s’agit d’un tableau recensant l’ensemble des informations rencontrées lors de l’analyse préalable ou permettant de répondre aux objectifs du système d’information et mentionnant parfois la classification de l’information, son mode de représentation ainsi que sa longueur.

Afin d’identifier les données ( les rubriques du dictionnaire ), il conviendra d’affecter un nom à chacune.  Il faudra éliminer les synonymes et les polysémes ( un mot qui désigne plusieurs choses différentes : comme une clé qui désigne un outil et qui sert à ouvrir une porte ).

On obtiendra ainsi un dictionnaire des données apuré des polysémes et des synonymes pour que tout le monde parle le même langage. On y inscrira également les contraintes d’intégrité ( par exemple les limites minimales et maximales d’une donnée ).  On ne conservera que les rubriques élémentaires ( on supprimera les rubriques composées comme ADRESSE qui est composée de NUMERO, RUE, CODEPOSTAL, LOCALITE ).  On obtiendra ainsi un Dictionnaires des données élémentaires. On y conserve également certains paramètres, des rubriques calculées de type situation ou historique.

Voici un exemple :




Les données ainsi recueillies vont alors permettre de réaliser un certain nombre de traitements :
  • saisie de l’information  ( clavier ,…)
  • enregistrement sur un support ( disquette, CD DVD, bande, …)
  • classement momentané ( fichier, base de données, …)
  • classement définitif ( archivage )
  • consultation ( écran,…)
  • modification du contenu ( valorisation )
  • diffusion ( impression, …)
  • transmission à distance …
-----------------------------------------------------------------------------------------------

4.  Les Dépendances Fonctionnelles.

Il arrive parfois que des données aient un rapport entre elles.  Il va falloir regrouper ces données.


Il arrive aussi que la connaissance d'une donnée nous fournisse automatiquement la valeur d'une autre donnée
(exemple : votre numéro de registre national nous fournit automatiquement vos noms et prénoms, date de naissance, …).  On dira que ces dernières données sont en dépendance fonctionnelle.
   
4.1.  Définition.

Une donnée 2 est en dépendance fonctionnelle d'une donnée 1 quand la connaissance d'une valeur de la donnée 1 permet de déterminer la connaissance d'au maximum une et une seule valeur de la donnée 2.  La donnée 1 est appelée la source et la donnée 2 est appelée le but. 

Question.

La question fondamentale à se poser est : "Connaissant une valeur de la source, peut-on connaître une valeur unique du but ?".
Quand la réponse est affirmative, on a l'habitude de représenter cette dépendance comme suit :

SOURCE =========> BUT

 Dépendance fonctionnelle à partie gauche ( source ) composée.

Il peut arriver que ce soit la combinaison de plusieurs attributs ( en source ) qui permettent de connaître une valeur unique du but.  Exemple : un numéro de facture + un code produit nous donne la quantité facturée.

(numéro de facture, code produit)     =========>   quantité facturée

On parlera de dépendance fonctionnelle à partie gauche composée ( DFPGC).

Dépendance non fonctionnelle.

Deux rubriques sont en dépendance non fonctionnelle si la connaissance d'une valeur de la première
  • ne permet de connaître aucune des valeurs de la seconde ( pas de rapport entre les deux )
  • détermine la connaissance de plusieurs valeurs de la seconde

exemples :
  • la connaissance d'un numéro de facture permet de connaître plusieurs références d'articles
  • la connaissance d'une date de naissance ne permet pas de connaître une adresse

Dépendance fonctionnelle élémentaire.

Une dépendance fonctionnelle donnée 1 =========>  donnée 2 est élémentaire s'il n'existe pas une donnée 3, sous-ensemble de donnée1, qui assure elle-même une dépendance fonctionnelle donnée 3 =========>  donnée 2.

Exemples :

Référence article =========================>    nom article
(Numéro facture, référence article ) ============>    quantité facturée
(Numéro facture, référence article ) ============>    nom article

La première est élémentaire car la référence article permet directement de connaître son nom.

La deuxième est élémentaire car le numéro de facture seul ou la référence article seule ne permet pas de connaître la quantité facturée.

La troisième n'est pas élémentaire car on peut se passer du numéro de facture pour trouver le nom de l'article ( la partie référence article du source suffit pour retrouver le nom d'article ). 

Dépendance fonctionnelle directe.

Une dépendance fonctionnelle  donnée 1  =========> donnée 2  est directe s'il n'existe pas une donnée 3 ( ou une collection de rubriques ) qui engendrerait une dépendance fonctionnelle transitive de telle sorte que l'on pourrait écrire :

Donnée 1 =========>    donnée 3  =========>  donnée 2

Exemple :

Numéro facture  =========> numéro représentant

Numéro représentant =========>  nom représentant

Numéro facture  =========>  nom représentant

On ne dessinera pas cette dernière car sa représentation est superflue.

Dépendance fonctionnelle élémentaire et directe.  ( DFED).

Les dépendances fonctionnelles que nous allons nous efforcer de trouver dans le système d'information sont celles qui sont à la fois élémentaires et directes.  Cette notion de DFED que nous noterons dorénavant DF ( en oubliant tout ce qui précédait ) est sans doute la partie la plus importante du cours car elle est le fruit de la réflexion de l'analyste alors que pour les étapes suivantes, on pourra utiliser un certain nombre de règles de passage.  Il convient donc de bien maîtriser ces notions avant d'aborder la suite de la démarche.

4.2.  Démarche de recherche des DF.

A partir du dictionnaire des données élémentaires, il faudra
  • rechercher les DF à deux rubriques élémentaires et directes
  • rechercher les DF à partie gauche composée.

Recherche des DF à deux rubriques.

On commence par rechercher les DF à deux rubriques en commençant par les plus évidentes du genre
Numéro de client =========>   nom de client

Si on a une DF du type   Numéro client  =========>  adresse, il faudra la décomposer en
Numéro de client =========>  rue
Numéro de client =========> code postal
Numéro de client =========>  localité
…..
Parfois, pour gagner du temps et de la place, on conserve la première version.

Parfois, la DF est symétrique.  Numéro état civil  ====================>  numéro de sécurité sociale.
Dans ce cas, on supprime une des deux pour garder la plus fréquemment utilisée.

Recherche des DF à partie gauche composée.

Voici la marche à suivre pour les trouver ( en respectant l'ordre suivant ) :

  • considérer l'ensemble des rubriques sources de DF simples ( S )
  • considérer l'ensemble des rubriques non encore concernées par au mois une DF simple ( ni source ni but d'au moins une DF simple )  ( N )
  • chercher une DF à partie gauche composée dont la source est composée de plusieurs rubriques de l'ensemble S ou de l'ensemble N, le but étant une rubrique de l'ensemble N.
  • quand toutes les rubriques de l'ensemble N sont concernées par au moins une DF ( aussi bien dans le but que dans la source ) ou bien quand on ne peut vraiment pas trouver de DF intégrant toutes les rubriques de N : rechercher des DFPGC dont le but serait une rubrique de S et la source des rubriques de S ou de N.  Il ne doit  beaucoup de rubriques non concernées par des DF.

Précautions relatives aux DFPGC.

Quand on traite des DFPGC, il faut toujours se poser les deux questions suivantes , si on a une DFPGC du type A, B, C  =========> D

*       n'y aurait-il pas des DF du style    D =========> A ou  D  =========> B ?
         exemple : ( date commande, n° client ) =========>  n° commande.  On préférera pourtant
         n° commande   =========> n° client et  n° commande  =========> date commande

*    n'y aurait-il pas, entre A, B, C et D une ou des DFPGC de moins de rubriques que celle citée ,
      du type D,A =========> B ?  Dans ce cas, il faut la privilégier.

Exemple :  ( jour, heure, classe, salle ) =========>  professeur où jour donne lundi , mardi, …; heure nous donne 1ère heure, 2ème heure, … ; salle nous donne son n° et classe 1ère info, …

On préférera : ((jour, heure, prof) =========> classe , etc

4.3.  Les modes de représentation des DF.

  Il existe deux méthodes pour représenter les dépendances fonctionnelles ; vous déterminerez celle qui vous convient le mieux en pensant à la manière qui est la plus parlante pour vous.

Le graphe des DF.

Il s'agit de représenter les DF par des flèches.


Dans le cas des DFPGC, on utilise un nœud représenté par un cercle :


Exemple : dans l'analyse des DF de la société OBOULO, nous avons trouvé les dépendances suivantes :




Voici le graphe des DF :


La matrice des DF.

Nous allons représenter les DF sous forme d'un tableau à deux dimensions.  On y met autant de lignes  et de colonnes que de données ( on peut se contenter des données utiles).  On procède ensuite colonne par colonne en se posant la question suivante : "Connaissant la valeur de cette rubrique, peut-on connaître une valeur unique d'une autre rubrique ligne ?".  Si la réponse est oui, on place un 1 dans la case correspondante.


Les colonnes ne contenant pas de 1 sont des alors, soit des éléments de parties gauche de DF, soit des buts.
Nous recherchons ensuite les rubriques à partie gauche composée en ajoutant autant de lignes et de colonnes que nécessaires.


Les colonnes qui contiennent des 1 sont donc des sources de DF,  les autres sont des buts.  Voici la matrice simplifiée :


-----------------------------------------------------------------------------------------------

5.  LE MODELE CONCEPTUEL DES DONNEES.

5.1.  Notions théoriques.

Nous allons étudier le Modèle Conceptuel des Données ( MCD ) d'après le modèle ENTITE ASSOCIATION.

Le vocabulaire.




Propriété : donnée élémentaire perçue sur le système d'information.  Les propriétés peuvent concerner les entités comme les associations.

Entité : objet du système d'information, pourvu d'une existence propre, conforme au choix de gestion de l'entreprise et porteur de propriétés. 

Exemple : dans une application classique de facturation, on trouve les entités suivantes : CLIENT, FACTURE, PRODUIT, COMMANDE, … . 

Occurrence d'une entité :
nombre de fois où cette entité est valorisée.
On peut traduire par une vue en épaisseur :



Le nom du client est une des propriétés de l'entité CLIENT.  Une propriété doit être valorisée de manière unique pour une occurrence.  Il est possible qu'une propriété ne soit pas valorisée.

Parmi les propriétés de l'entité, il en est une très importante  : celle qui permet d'identifier de manière unique l'occurrence de l'entité : on l'appelle l'identifiant.

Identifiant :  propriété particulière, telle qu'à chaque valeur de la propriété corresponde une et une seule occurrence de l'entité. ( ici, le numéro de client )

Association : relation entre deux ou plusieurs entités.   Elle est dépourvue d'existence propre, mais elle peut être porteuse de propriétés.

Une association peut aussi avoir plusieurs occurrences.  On peut aussi y placer un identifiant.

Cardinalité : représente le nombre d'occurrences, minimal et maximal, d'une entité par rapport à une association.

  • chaque client passe au moins une commande et au plus n commandes
  • chaque commande est passée par un et un seul client

On considère habituellement la relation entre l'entité de départ et l'association.  Ainsi, on pourrait dire :
  • chaque client a fait l'action de passer commande au moins une fois et au plus n fois
  • chacune des commandes n'a été passée qu'une et une seule fois

Contrainte d'intégrité fonctionnelle : Quand on détermine, entre une association et une entité, une cardinalité présentant les valeurs 0,1 ou 1,1, on l'appellera Contrainte d'intégrité fonctionnelle ( CIF ).

On les représente de la façon suivante :



Connaissant une commande bien précise, on connaît un client bien précis.




Connaissant une occurrence de l'entité matière et une occurrence de l'entité classe, ont connaît automatiquement une seule valeur de l'occurrence professeur.

5.2.  Règles de passage des DF au MCD.

Repartons du graphe d’OBOULO



Pour passer du graphe des DF au MCD, on va respecter certaines règles :
  • déterminer les rubriques "sources"
  • déterminer les entités
  • déterminer les associations binaires avec cardinalité (0,1 ou 1,1 ) ou CIF
  • déterminer les autres associations
  • déterminer les CIF multiples
  • répartir les rubriques dans les entités ou associations
  • procéder aux aménagements éventuels du MCD

Quelles sont les rubriques "sources" ?

Source de DF simple ( à deux rubriques )
  • N° employé
  • N° ordinateur
  • N° fournisseur
  • Grade
  • Nom logiciel
  • Code installateur

Membre d'une source de DFPGC (non répertorié avant )

·    CA réalisé

But de plusieurs DF sans être source de DF

·    Nom service

Rubrique isolée

·    Diplôme

Chaque rubrique va générer une entité dont elle sera l'identifiant :


Détermination des entités.

Chaque rubrique de l'ensemble S des sources va générer une entité dont elle sera l'identifiant.  On aura donc ainsi, dans notre exemple, neuf entités sur le MCD.






Détermination des associations binaires à cardinalité 0,1 ou 1,1 ( CIF BINAIRES ).

Sur le MCD correspondant à notre exemple, on va donc ajouter quatre associations de ce type, correspondant aux quatre DF suivantes :







Détermination des autres associations.

Une DFPGC détermine une association quand elle a pour but une rubrique ( ou plus ) non recensée comme une source.  Elle va alors générer une association entre les entités qui correspondent aux rubriques constituant la partie gauche en question.  Les cardinalités seront généralement égales à 0,n ou 1,n.

Dans notre exemple, on aura




Détermination des CIF multiples.

Chaque DFPGC dont le but fait partie de l'ensemble des sources va générer une CIF multiple qui part des entités de la partie gauche de la DFPGC vers le but.  Ici, on utilisera des flèches ( comme dans toutes les CIF ).

Dans ce schéma, nous en avons une :





Ventilation des rubriques dans les entités et les associations.

Il nous faut encore placer les rubriques qui sont uniquement des buts des DF.  Il faut les placer dans les entités ou les associations dont l'identifiant est la partie gauche de la DF qui a pour but cette rubrique.

Ainsi, dans l'entité EMPLOYE, on placera le nom de l'employé et son prénom. 
On placera de même la rubrique temps d'utilisation dans l'association UTILISE.
Pour des raisons analogues, on placera les rubriques n° exemplaire et date d'installation dans l'association INSTALLE_SUR.

Il arrive qu'on ne place pas les autres rubriques dans le schéma ( faute de place ).  On tiendra alors une liste détaillée des entités et des associations dans un tableau annexe.

Aménagements au MCD.

Il arrive fréquemment que des modifications soient apportées au MCD.

Entité non but de DF nécessitant la création d'une association.

 Il arrive parfois que certaines entités ( ou rubriques simples ) ne soient but d'aucune DF.  Cependant, la lecture du sujet montre bien que cette donnée est indispensable au système d'informations.




Prenons un autre exemple typique : entre les entités AUTEUR et LIVRE, si nous désirons connaître quel est l'auteur de tel livre, nous créerons l'association ECRIRE  ( cette association n'est pas déductible du graphe des DF ).  On dira que cette association est creuse car elle ne contient pas de propriété et les cardinalités sont toujours 0,n ou 1,n.



Voici une règle qui concerne les associations creuses ajoutées sur le MCD :

Il ne sert à rien d'ajouter une association creuse qui accompagnerait une CIF multiple  ( qui relie les entités formant la partie gauche de cette CIF multiple ).  En effet, elle n'apporterait aucune information complémentaire par rapport à la CIF multiple.

Par contre, une association reliant une partie seulement des entités peut apporter un complément d'informations.

Association ou CIF réflexive.

Parfois, une entité peut pointer sur elle-même.  Voici 2 exemples :



On a une cardinalité binaire : l'association est donc une CIF.



Celui-ci n'est pas une CIF.

Transformation de certaines associations en entités.


On a parfois intérêt à transformer certaines associations en entités.  L'entité doit bien entendu disposer d'un identifiant propre.  Voici un exemple :




Deviendrait




5.3.  Résumé des règles de validation.

  • Chaque entité possède un identifiant.
  • Chaque propriété d'une occurrence d'entité ne possède, au plus, qu'une valeur.
  • Toutes les propriétés doivent être élémentaires.
  • Toutes les propriétés autres que l'identifiant doivent dépendre pleinement et directement de l'identifiant
  • A chaque occurrence d'une association correspond une et une seule occurrence de chaque entité  participant à l'association
  • Pour une occurrence d'une association, il ne doit exister au plus, qu'une valeur pour chaque propriété de cette association.
  • Chaque propriété d'une association doit dépendre pleinement et directement de tout l'identifiant et non pas d'une partie de cet identifiant. 
----------------------------------------------------------------------------------------------

0 commentaires:

Enregistrer un commentaire

Share

Twitter Delicious Facebook Digg Stumbleupon Favorites

 

IP