Arrow Table de matières
3971741

TROISIEME CHAPITRE ANALYSE ET MODELISATION DU SYSTEME D’INFORMATION INFORMATISEE

III.0 Introduction

L’automatisation de toute conception comme aussi celle du suivi des assujettis correspondant à cette conception.

Le système d’information est l’ensemble de flux (information) circulant dans une organisation. L’analyse de notre système d’information sera faite de par la méthode MERISE (MERISE comme une Méthode de recherche en Informatique par sous Ensemble) [KAS2008].

III.1 Analyse du système d’information

Pour notre système d’information, le but de l’analyse est d’étudier l’opportunité et la praticabilité d’information. Il nous revient maintenant de situer les points essentiels de notre sujet. De part ce dernier, il est question d’un suivi de contrôle des assujettis dans leur payement au sein des la direction générale des recettes administratives, judiciaires, domaniales et de participation dans la province du Sud-Kivu.

Une personne morale redevable appelée « assujetti »  qui était ordonnancée par les agents de ces deux divisions d’ordonnancements soit DIVAJUP ou  DIVIDOM après les processus d’identification de l’assujetti, qui est suivi d’élaboration d’une note de perception qui, ensuite sera amenée à une institution bancaire. Cette dernière élabore un bordereau de versement qui sera enregistré par le service informatique comme une preuve d’acquittement de sa taxe dû et sortira avec un reçu comme une preuve justificative du contrôle  du paiement.

Cependant après ce processus général, d’autres cas particuliers sont à signaler comme le contrôle fait par les agents du recouvrement  pour chaque ordonnancement  établit par l’assujetti et est suivi par le paiement de pénalité en cas de non validité. Une autre forme de pénalité est à signaler soit un paiement avec retard, soit un non-paiement.

Tel est notre système information en général.

III.2 la modélisation des données

La définition attribuée au non concept « modèle » sont nombreuse mais nous retiendrons celle proposée par Weinberg : «  un modèle c’est l’expression de quelque chose que nous cherchons à appréhender, représenter enlangage que nous pensons comprendre » [DIO 2003]

III.2.1 le modèle conceptuel de traitement

Le modèle conceptuel de traitement a pour objectif de représenter formellement les activités exercées par le domaine, activités dont la connaissance est base du système informatique. Elle est tournée vers la prise en compte des échanges du domaine avec son environnement. Le MCT préciser les frontières du domaine en décrivant les activités qui lui sont associées et échangez avec son environnement

Réception de la déclaration du service d’assiette

Présentation de l’identité par l’assujetti

                           

Etude du dossier de l’asssujetti

Affectation de l’assujetti à une catégorie

Elaboration de note de perception

 Oui

Non

Payement à la Banque

Enregistrement du Bordereaux

Affichage des Assujettis Ordonnance

Refus du dossier et pas d’ordonnancement ni de recouvrement

Affichage de Reçu

FigureIII.1 : Modèle conceptuel de traitement

III.2.2 Dictionnaire de données

Nom de l’objet

Attribut

Type

Taille

Description

T_ASSUJETTI

NumAss

Entier

10

Numérode l’assujetti

NomAss

Texte

25

Nom de l’assujetti

PostNomAss

Texte

25

Post nom de l’assujetti

VilleAss

Texte

15

Ville de l’’assujetti

CommuneAss

Texte

15

Commune de l’assujetti

TelephoneAss

Entier

10

Téléphone de l’assujetti

EmailAss

Texte

15

Email de l’assujetti

T_TAXE_AFFECTATION

NumTaxe

Entier

10

Numéro de la taxe

MatriculeAffect

Entier

10

Matricule de l’affectation

CodeBanque

Texte

15

Code de la banque

CodeActiv

Texte

15

Code de l’activité

DateAffect

Date

10

Date de l’affectation

ServiceGenerateur

Texte

25

Service générateur

serviceTaxateur

Texte

25

Service taxateur

T_ACTIVITE

NumTypeActiv

Entier

10

Numéro du type d’activité

GenreActiv

Texte

25

Genre de l’activité

Taxe

Monétaire

15

Taxe sur l’activité

Annee

Date

10

Année exerce l’activité

T_CATEGORIE

NumCateg

Entier

10

Numéro de la catégorie

Designation

Texte

30

Désignation de la catégorie

T_BANQUE

NumBanque

Entier

10

Numéro de la banque

NomBanque

Texte

25

Nom de la banque

NumBord

Entier

10

Numéro du bordereau

NumReleve

Texte

15

Numérode larelève

T_PAIEMENT

NumPaie

Entier

10

Numéro du paiement

MontantPaie

Monétaire

15

Montant payer

DatePaie

date

10

Date du paiement

NomCpble

Texte

25

Nom du comptable

PostNomCpble

Texte

25

Post nom du comptable

TelephoneCpble

Entier

15

Téléphone du comptable

III.2.3 Modèle conceptuel de données

Ce modèle sert à décrire les objets manipulable par les utilisateurs dans le système étudie. MCD aboutit à une présentation appelée schéma conceptuel de données. Le modèle entité association ou entité relation.

Une  Entité est un objet d’un monde réel ayant une existence propre, des occurrences multiple et des propriétés

III.2.3.1 Les entités

Départ notre système d’information, nous aurons six entités qui, sont :

  1. Entité d’assujetti:Elle renferme l’identité de l’assujetti et toutes les données des assujettis ordonnancés au court d’une période. Généralement, une entité est créée dans le système d’information si elle possède au moins des occurrences. Chaque élément d’une entité est appelé une occurrence.
  2. L’entité payement: elle renferme toutes les coordonnés se trouvant sur un bordereau identifier par le numéro du banque.
  3. L’entité taxe affectation: renferme toutes les informations sur un assujetti pour son enregistrement : Ses activités, ses catégories. Chaque affectation est identifié par le numéro matricule.
  4. L’entité banque: elle enregistre tous les banques abonnée par la DGRAD/Sud-Kivu et ses références.
  5. L’entité activité: elle referme toutes les données sur la taxation des assujettis. Le montant qu’’ils doivent payer pour tel ou tel autre activité.
  6. L’entité catégorie:elle reprend tous les catégories des assujettis dans la base de données de la DGRAD.

Dans le souci  d’identifier de façon unique les différentes entités, nous allons ajouter à chacune de ces entités une propriété supplémentaire qui  nous servira d’identifiant de l’entité. L’identifiant peut être une référence interne, un code ou plus généralement un nombre entier. C’est une propriété qui est soulignée.

FigureIII.2 : Modèle conceptuel de données

III.2.4 Modèle logique de données

Après avoir établi le MCD, il revient alors de passer à MLD.

Cependant, ce passage se fait selon quelques règles qui s’avèrent indispensables. Ces règles  sont les suivants :

Les différentes entités deviennent des tables.Les différentes propriétés deviennent les différents attributs et les différents identifiant deviennent des clés primaires.

Les différentes relations entre les entités deviennent de tables ayant pour attribut les différents identifiants de différentes entités dont elles unissent, et cela dans le cas où il n’y a pas de contrainte d’intégrité fonctionnelle (CIF) entre ces deux entités. Et il y a CIF entre deux entités quand il existe une relation père-fils entre ces entités. Celle relations se traduit par les cardinalités suivantes : (0,1) et (0, n) ; (1,1) et (1,n) ; (1,1) et (0,n) ; quand il y a CIF l’entité père est celle ayant les cardinalité (0,n) ou (1,n), l’entité fils a ces cardinalité (0,1) ou (1,1).

Dans cette situation, la relation ne devient pas une table mais au contraire l’identifiant de l’entité père devient un attribut de la table fils ou il joue le rôle d’une clé secondai

FigureIII.3 : Modèle logique de données

III.2.5 Le modèle logique de données relationnelles

Les objectifs de cette modélisation sont la définition de l’organisation logique des données à partir du modèle conceptuel et l’optimisation de cette description, compte tenu des traitements à appliquer à l’information.

Modèle relationnel : c’est l’ensemble de schémas relationnels de la forme Relation (clé1, ...clé n, att1, ... att m).

Règles de passage du MCD au MLD relationnel

1 Chaque entité avec au moins une propriété non identifiant donne lieu à un
schéma relationnel, les identifiants deviennent les clés.

Une association binaire de type 1, n disparaît au profil d’une clé étrangère dans la table  côté 0,1 ou 1,1 qui ne référence la clé primaire de l’autre table. Cette clé peut recevoir la valeur si la cardinalité est 1,1.

 3 Une association binaire de type n, n devient une table supplémentaire dont la clé primaire est composée de deux clés étrangères. Les identifiants des entités liées deviennent des clés et les propriétés de l’association deviennent des attributs simples

 4 Une association binaire de type 1,1 est traduite comme une association de type 1,n sauf que la clé se voit imposer une contrainte d’unicité en plus d’une éventuelle contrainte de non vacuité.

5Une association non binaire est traduite par une table supplémentaire dont la clé primaire est composée d’autant de clés étrangères que d’entités en association. Les attributs de l’association deviennent des colonnes de cette nouvelle table.

Voici le modèle logique relationnel(MLDR) que nous obtenons à partir du MCD :

Table Assujetis (#Num_Ass, NomAss, PostNomAss,VilleAss, CommuneAss, TelephoneAss, EmailAss)

Table Taxe_Affectation (#NumTaxe, MatriculeAffect, CodeBanque, CodeActiv, DateAffect, Servicegenerateur, ServiceTaxateur)     

Table Activite (#NumTypeActiv, GenreActiv, Taxe, Année)

Table categorie (#NumCateg, Designation)

Table Banque (#NumBanque, NomBanque, NumBord, NumReleve)

Table verser (#Num_Ass, #NumBanque)

Table Paiement (#NumPaie, MontantPaie, DatePaie, NomCpble, PostNomCpble)

III.2.6Le modèle physique de données

Le MLDR nous mène droit au MPD, une fois le système d’information analysé et modélisé en MCD, et après être passé par MLDR, nous arrivons au MPD. Il s’agit maintenant de créer la base correspondante à l’étude entamée c’est-à-dire à ce stade seulement que la Base de données choisie intervient c’est ainsi que la mise en place de notre conception nous allons devoir utiliser le MS ACCESS avec comme langage de programmation VISUAL STUDIO que nous allons devoir associé à la base de données.

III.3 Conclusion partielle

Ce chapitre  nous permet d’explicité les modèles que nous allons utiliser dans notre travail. Les modèle qui nous ont permis de faire notre conception et voir le langage de programmation que nous allons associer à notre base de données.

Partager ce travail sur :