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.

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