WOW !! MUCH LOVE ! SO WORLD PEACE !
Fond bitcoin pour l'amélioration du site: 1memzGeKS7CB3ECNkzSn2qHwxU6NZoJ8o
Dogecoin (tips/pourboires): DCLoo9Dd4qECqpMLurdgGnaoqbftj16Nvp

Home | Publier un mémoire | Une page au hasard

Memoire Online >

Informatique et Télécommunications

Conception et réalisation d'une base de données pour le suivi de la transfusion sanguine dans une structure sanitaire: Cas de l'hôpital général de référence de Tshofa

par Patrick MULENDA KIABU
Institut supérieur pédagogique de Tshofa - Graduat 2022

Disponible en mode multipage

Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy

INTRODUCTION

L'organisation de toute entreprise ainsi que la politique de gestion influencent le développement de celle-ci, comme est le cas aujourd'hui avec l'évolution de la technologie.

L'informatique devient nécessaire et suffisante dans le traitement de données et reste véritablement un soubassement d'un suivi sain et efficace dans une entreprise à travers le progiciel bien adapté dans un domaine précis.

D'où, le recours à la gestion automatique reste pour les entreprises un moyen efficace dans la révolution ou dans le traitement rationnel des informations à travers des programmes spécifiques « Application » qui faciliterait la tâche aux gestionnaires dans la prise des décisions en mettant à leurs dispositions des données fiables et cela dans un temps record.

Suite aux nombreux avantages que l'informatique offre dans les entreprises, nous allons essayer de proposer une mise en place d'un logiciel pour le suivi des transfusions sanguines chez un patient en vue d'améliorer le travail combien louable pour notre hôpital. Et éviter les pertes humaines dans les jours avenir.

0.1. PROBLEMATIQUE

La problématique désigne l'ensemble de questions posées par un chercheur dans un domaine de la science en vue d'une recherche des solutions (1(*)).

Elle est également une approche à une perspective théorique que l'on décide d'adopter pour traiter un problème posé par la question au départ (2(*)).

Lors de notre passage à l'hôpital Général de Référence de Tshofa, nous avons constaté les problèmes ci- dessous :

- Le suivi de la transfusion du sang se fait d'une manière manuelle sans aucune confidentialité ;

- L'insécurité des informations par rapport au suivi de la transfusion sanguine ;

- Enregistrement manuel des opérations de la transfusion ;

- Perte des documents liés aux suivis de la transfusion.

A cet effet, quelques questions méritent d'être posées :

ü Que faire pour améliorer le suivi relatif à la transfusion sanguine à l'HGR/TSHOFA ?

ü Que ce qu'il faut faire pour garantir la disponibilité des informations liées aux suivis de la transfusion sanguine ?

ü Que faut - il faire pour accroitre et assurer la rapidité dans le suivi de la transfusion sanguine à l'HGR/TSHOFA ?

0.2. HYPOTHESE

PINTO et GRAWTZ, définissent l'hypothèse comme étant une proposition des réponses aux question que l'on se pose sur l'objet de la recherche formulée en terme tel que l'observation que l'analyste puisse fournir une réponse3(*).

En rapport avec notre problématique, nous proposons la mise en place d'un logiciel pour le suivi de transfusion sanguine (d') :

ü Mettre en place un logiciel capable de gérer les informations relatives aux suivis de la transfusion sanguine ;

ü Nous envisageons à faire une étude minutieuse sur le système existant afin de dénicher les forces et les faiblesses de cette dernière et aussi proposé une solution adaptée.

0.3. CHOIX ET INTERET DU SUJET

0.3.1. CHOIX DU SUJET

Eu égard à tous ce qui précède, nous avons choisi le sujet intitulé « Conception et réalisation d'une base de données pour le suivi de la transfusion sanguine dans une structure sanitaire « cas de l'Hôpital Général de Référence de Tshofa ».

3.2. INTERET DU SUJET

Notre intérêt du sujet est d'appréhendé selon trois points de vue :

- Intérêt professionnel : de doter à l'hôpital général de référence de Tshofa d'un logiciel qui assure le suivi de la transfusion sanguine sans aucune confusion ;

- Intérêt scientifique : nous pensons bien que ce travail servira de documentation de référence pour tout chercheur en informatique de gestion.

- Intérêt académique : Ce dernier nous permet à sanctionner la fin de notre premier cycle en informatique de gestion.

0.4. DELIMITATION DU SUJET

La délimitation du sujet n'est ni une attitude de faiblesse ni une fuite de responsabilité, mais une contrainte de la démarche scientifique. Nous l'avons limité dans le temps et dans l'espace.

0.4.1DELIMITATION DANS L'ESPACE

Notre recherche portera sur l'hôpital général de référence de Tshofa et plus précisément au laboratoire dudit hôpital.

0.4.2. DELIMITATION DANS LE TEMPS

Notre recherche couvre la période allant de 2020 à 2023, ces sont les données de cette période qui vont nous servir à matérialiser notre logiciel de suivi de la transfusion sanguine des patients à l'Hôpital G énéral de Référence de Tshofa.

0.5. METHODES ET TECHINQUES UTILISEES

0.5.1. METHODES UTILISEES

Une méthode est un ensemble d'opérations intellectuelles par lesquelles une discipline cherche à atteindre les vérités qu'elle poursuit, les démontrés et les vérifiés. (4(*))

La Méthode MERISE : Elle est nous a permis de maitriser notre étude détaillée sur les études suivantes :

- L'étude préalable ;

- Étude détaillée qui doit à son tour étendre l'étude préalable avec trois objectifs qui sont :

ü La description de tous les processus composant le fonctionnement du futur système ;

ü La définition exhaustive des informations utilisées et mémorisées ;

ü La spécification des tâches à effectuer, en particulier pour celles à informatiser ;

ü La description des procédures exceptionnelle, phases transitoires et le fonctionnement dégradé.

0.5.2. TECHNIQUES UTILISEES 5(*)

Elle est définie comme étant les procédés limités, mettant enjeu les éléments concrets, adaptés à un but précis et défini.

Tout au long de notre travail, nous avons utilisé les techniques suivantes :

- La technique documentaire

Elle nous a renvoyé à la lecture des ouvrages, des notes de cours et autres documents se rapportant à notre sujet.

- La technique d'interview

C'est une technique qui nous a servi à recueillir les renseignements approfondis sur notre thème de recherche en entrant en contact avec les personnes chargées de la gestion des frais d'hospitalisation des patients.

0.6. SUBDIVISION DU TRAVAIL

Outre l'introduction et conclusion générale, notre oeuvre est subdivisée en quatre chapitres d'où nous avons :

- Les Études préalables ; nous permis de détailler l'hôpital général de Référence, son fonctionnement, la hiérarchisation des services ainsi que sa gestion ;

- Conception d'un système d'information organisé ;

- Conception du Système d'information informatisé ;

- Réalisation de la base des données

CHAPITRE I : ETUDES PREALABLES

Les études préalables constituent la première phase de l'étude informatique et rêvé d'une grande nécessité dans laquelle l'étude serait impossible d'autant plus qu'elle se focalise sur l'existence du cadre de recherche de par son historique, son fonctionnement est débouché sur la critique et la proposition des solutions retenues.

I.1. ANALYSE DE L'EXISTANT

Cette étude est caractérisée par l'étude minutieuse de l'existant et permet de répondre à la question suivante : est- ce nécessaire, est-ce possible d'informatiser ? Comme tout problème ne nécessite pas l'informatisation.

I.1.1. PRÉSENTATION DE L'HOPITAL GENERAL DE REFERENCE

I.1.1.1. MISSION DE HGR/TSHOFA

Elle est une structure sanitaire de la ville de Tshofa qui a pour but :

- Les soins médicaux aux patients de toutes catégories ;

- Garantie de la vie en cas de la maladie ;

- De toutes sortes des maladies locales.

I.1.1.2. HISTORIQUE

L'HGR Tshofa est une structure Étatique situé dans le quartier Lunya, Village de Tshofa, secteur de Tshofa, territoire de Lubao, province de Lomami en République Démocratique du Congo. Fut construit en 1933 par monsieur VANNYL et n'avait aucun médecin résident. Seuls ceux qui étaient à Lubao passaient en transit. C'est vers 1990 que ce dernier a pris réellement le sens d'un Hôpital. Il a connu réhabilitation avec la COGET en 1992 et à travers elle l'appui de l'ONG MDM-Belgique qui prit en charge l'HGR en quatre volets à savoir :

- Le renforcement de capacité du personnel,

- La réhabilitation et la construction des infrastructures sanitaires,

- L'approvisionnement en megs,

- L'équipement et autres appuis financiers.

Depuis lors, il a connu à sa direction onze médecins Directeurs qui se sont suivi de la manière ci-après :

En 1990 : Dr Franc NASIBU ABDOUL,

1992 : Dr KANKOLONGO LUABA,

2001 : Dr Richard NGONGO qui, à la même Période a restauré les AS ainsi que les différentes FOSA avec l'appui du partenaire MDM/B,

2003: Dr Martin KIPAMBA,

2004: DrElie MUAMBA MUTOMBO,

2005: Dr Gerard KANKU TSHIAMWENE,

2008: Dr Gabriel KABINDA KATAMBUE,

2012: Dr Florentin KABEYA KABONGO,

2018: Dr Germain NTAMBWE EBANGA,

2019 jusqu'à ce jour DR MAUNGA MAUNGA JP.

I.1.1.3. SITUATION GEOGRAPHIQUE

L'hôpital général de référence de Tshofa est borné :

- Au nord par l'HGR de Wembonyama à 175 Km

- Au sud par l'HGR Kamana à 115Km

- Au sud-ouest par l'HGR de Mpengie à 85 Km

- A l'est par l'HGR de Lubao à 80Km

CONSULTATION

STAFF MEDICAL

I.1.2.1. ETUDE STRUCTURALE

Figure N°1

ECZ

CODIR

MDH

SECRETARIAT

COMPTABILITE

CAISSE

INTENDENCE

PHARMACIE

LABORATOIRE

MATERNITE

MÉDECINE INTERNE

SOINS INTENSES

PEDIATRIE

BUANDERIE

STATISTIQUE

IMAGERIE MEDICALE

SECURITE

MAINTENANCE

Source : secrétariat de l'Hôpital

Figure n° 2

I.1.1.2. ORGANIGRAMME RESTREINT

Figure N°2

DIRECTION

SECRETARIAT

DIRECTEUR DE NURSING

LABORATOIRE

Source : Nous-mêmes

I.1.2.3. DESCRIPTION DE L'ORGANIGRAMME RESTREINT

Décrire un poste, c'est définir un emploi dans le but de viser exécution correcte des activités en vue d'atteindre les objectifs d'une entreprise, pour le cas sous examen, quelques postes ont été retenus pour être décrits vu qu'ils entrent directement dans l'organigramme restreint, il s'agit notamment de :

a) Directeur Général

Il coordonne toutes les activités quotidiennes de l'hôpital Général de référence, convoque le conseil d'administration (gestion) préside la réunion de comité directeur.

b) Directeur Nursing

- Coordonne les soins infirmiers à l'HGR ;

- Supervise et assure la qualité des soins à l'HGR ;

- Forme le personnel de FOSA ;

- Participe au réunion de l'ECZ ;

c) Secrétariat De Direction

- Recevoir le visiteur de l'HGR ;

- Recevoir et enregistre les correspondances adressées à l'HGR ;

- Rédiger les différentes correspondances, les enregistrés et en assure l'expédition ;

- Encoder la statistique de la HGR ;

- En relation directe avec la direction.

d) Laboratoire

Ce service est chargé de :

- Tester les groupes des patients ;

- Prélèvement du sang ;

- Transfusion du sang aux patients.

e) Salle d'Urgence

- Réception du malade ;

- Diagnostiques des malades

I.1.3. ETUDE DES DOCUMENTS

I.1.3.1. RECENSEMENT DES DOCUMENTS

a) BON DE RECHERCHE

Celle - ci permet de découvrir ou identifier le patient en ordre ou non.

- Description

Le bon de recherche des groupes sanguins des patients possède les rubriques suivantes :

- Identité receveur ;

- Nom ;

- Age ;

- Numéro dossier ;

- Sexe

- Service ;

- Post nom ;

b) BON DE TRANFUSION

Ce document montre à suffisance que le patient doit être transfusé.

- Description

Ce document possède les rubriques suivantes :

- Date ;

- Service ;

- N.U Patient ;

- Les Maladies à tester ;

- Nom du patient ;

- Post nom du patient ;

I.1.4 Etudes de Moyens De Traitements

Evidement que l'étude des moyens de traitement de l'information dans le bureau tout comme dans chaque entreprise a toujours été divisée en deux parties :

- Moyens Humains ;

- Moyens Matériels.

Tableau n° 1

I.1.4.1. Moyens Humains

N°	Poste de travail	Fonction	Qualification	Nombre	Ancienneté
1	Salle Intensif	Infirmier	A1	4	4 ans
2	Labo	Laborantin	A2	3	6 ans
3	Service	Médecin	Docteur	1	2ans

Source : Nous - Mêmes

Tableau n° 2

I.1.4.2. Moyens Matériels

N°	Matériels	Nombre	Capacité Mémoire	Support	Date d'Acquisition	Durée
1	Ordinateur	2	500Go	-	Le19/02/2007	10 ans
3	Imprimante	2	Laser	-	Le01/05/2017	3 ans
5	Tables	2	-	-	Le 24/12/2007	13ans
6	Chaises	2	-	-	Le 24/12/2019	1 ans
7	Banc	1	-	-	Le 24/12/2007	13ans
8	Scanner	1	-	-	Le 01/07/2016
9	Flash disque	1	-	-	Le 01/07/2016	6 ans
10	Disque dur externe	1	-	-	Le 01/07/2016	6 ans
11	Classeur	1	-	-	Le 01/07/2016	6 ans
12	rétroprojecteur	1	-	-	Le 01/07/2016	6 ans

Les Ressources matériels l'hôpital général de référence sont :

Source : Nous - mêmes

I.5. LE DIAGRAMME BRUT DE FLUX

Ici le diagramme brut de flux nous présente les différentes transactions (échanges) effectué entre les le laboratoire et le service d'attache.

Figure N°3

SECRETARIAT

ADMINISTRATEUR GETIONNAIRE

LABORATOIRE

SERVICE

Source : Nous -mêmes

LEGENDE

1. Envoi bon de transfusion au secrétariat ;

2. Transmission du bon à Administrateur Gestionnaire ;

3. Envoi du bon de recherche au Labo ;

4. Envoi du Bon de transfusion au Labo ;

5. Transmission du rapport à l'Administrateur Gestionnaire.

LE DIAGRAMME DE CONTEXTE

La figure ci - dessous illustre les échanges des flux selon le cas sous examen.

Figure N°4

LABORATOIRE

MDH

Source : Nous - mêmes

I.6. SHEMA DE CIRCULATION D'INFORMATION

A ce stade, il s'agit d'établir un schéma de circulation des informations pour chaque processus précis, question de mettre en évidence la totalité de flux reçus, traités et émis par chacun des acteurs dans différent processus.

Les valeurs ajoutées d'un schéma de circulation par rapport aux autres outils montrant le trajet de flux sont : la présentation des documents non circulant, la spécification des moyens et support de transmission ainsi que la présentation de traitement des documents apporté aux informations pour chaque acteur.

Plusieurs symboles sont utilisés pour formaliser un schéma de circulation de l'information en fonction de l'élément à représenter. Ci -dessous, nous donnons quelques symboles plus couramment utilisés.

: Déclenchement de l'opération

: Envoi d'un document à un poste

:. Réception d'un document venant d'un autre poste

: Document circulant en un seul exemplaire

: Document circulant en plusieurs exemplaires

: Archivage

: Classement

: Base des Données

: Ordinateur

Figure n° 3

1.7. ANCIEN CIRCUIT D'INFORMATION

SERVICE MEDICAUX		MEDECIN	LABORATOIRE	DONNEUR (Banque du Sang)
100		200	300	400

101

201

301


101		201	301	401

- 301

Envoi du patient au donneur

- Réception du patient ;

- Test du groupe du donneur au laboratoire ;

- Envoi du donneur au laboratoire

201

301

201

EBR

201

401

301

EBR

302

TGD

302

- Réception du donneur ;

- Transfusion du patient ;

- Enregistrement du patient

302

301

Source Nous-mêmes

1.2. CRITIQUE DE L'EXISTANT

L'Hôpital général de référence de Tshofa possède une structure organisationnelle et fonctionnelle stable et forte avec une très bonne division de travail.

I.2.1. POINTS FORT

L'hôpital général de référence de Tshofa dispose d'un moyen matériel pouvant lui permettre d'atteindre ses objectifs. Nombreux patients sont transfusés sans aucune inquiétude à l'hôpital. Nous avons fait le constat d'une très bonne circulation des informations d'un poste à un autre, ce qui facilite la rapidité du travail.

I.2.2. POINTS FAIBLE

Au regard du volume de travail, l'hôpital général de référence de Tshofa ne dispose pas d'un nombre suffisant du personnel. Nombreux qui sont là, ne sont pas spécialiste dans le domaine médical pour faire correctement le suivi de la transmission des patients sans aucune difficulté.

I.3. PROPOSITION DES SOLUTIONS

Les solutions informatiques sont :

- Informatisation sans réorganisation ;

- Informatisation avec réorganisation ;

- Réorganisation sans informatisation.

I.3.1. Solution Manuelle

La solution manuelle consiste à faire une réorganisation pure et simple du système d'information existant, elle est préférée quand il n'Ya pas l'opportunité d'informatisation.

I.3.2. Solution informatique

La solution informatique repose sur l'intervention de l'ordinateur en vue d'untraitement automatique des informations avec un logiciel approprié.

Cette solution nous apporte des avantages suivants :

- Bonne conservation des informations sur les supports magnétiques réduisant ainsi l'encombrement ;

- Possibilité de faire la mise à jour rapide des données ;

- Facilité de localiser à tout moment une information ;

- Rapidité dans le traitement d'information ;

- Fiabilité assurée des résultats par l'intervention de l'ordinateur dans la réalisation des opérations très complexe.

I.3.3. CHOIX DELA MEILLEURE SOLUTION

Avec notre étude, nous avons choisi la solution d'informatisation sans réorganisation pour afin atteindre le but poursuivis par l'hôpital général de référence de Tshofa.

Tableau n° 4

1.10. NOUVEAU CIRCUIT D'INFORMATION

SERVICE ( MEDECIN)		LABORATOIRE	DONNEUR (Banque du Sang)
200		300	400

101

201


101		201	301

- 301

Envoi du patient au donneur

- Réception du patient ;

- Test du groupe du donneur au laboratoire ;

- Envoi du donneur au laboratoire

301

201

EBR

201

EBR

301

401

302

TGD

302

- Réception du donneur ;

- Transfusion du patient ;

- Enregistrement de l'opération

302

BDD

301

Source : nous-mêmes

CHAPITRE II

CONCEPTION DU SYSTEME D'INFORMATION ORGANISATIONNEL

Le système d'information organisationnel fait la description du système d'information sans prendre en compte des aspects techniques liés à l'information, c'est-à-dire on ne tient pas compte de la machine.^6(*)

Le système d'information organisationnel est en effet constitué de deux étapes suivantes :

- Niveau conceptuel ;

- Niveau organisationnel.

II.1. ETAPE CONCEPTUELLE

Le niveau conceptuel consiste à déterminer les objets du système d'information ainsi que les rapports existants entre eux, en faisant abstraction de l'environnement matériel et logiciel.

Il est formalisé de manière suivante :

- Modélisation conceptuelle de données ;

- Modélisation conceptuelle de traitements.

II.1.1. MODELE CONCEPTUEL DES DONNEES (MCD)

La modélisation conceptuelle de données (MCD), c'est un diagramme entité relation permettant de modéliser le système d'information sans tenir compte des détails liés à la mise en oeuvre physique.

II.1.1.1 PROBLEMATIQUE DU MODELE CONCEPTUEL DES DONNEES

La symbiose des informations utilisées est échangée constituent l'univers du discours du domaine, on fait allusion aux objets concret ou abstrait ou association entre les objets. Ce modèle est un diagramme entité, association permettant de modeliser le système d'information sans tenir compte de détaille lié à la mise en oeuvre physique.

Les Concepts :

ü Objet : est une entité ayant une existance autonome et présentant un certain intérêt dans le domaine de gestion considéré ;

ü Propriété ou attribut: c'est une information élementaire qui permet d'intensifier ou de caractériser un objet ou une relation ;

ü Identifiant : c'est une realisation de l'individu type ou d'une relation type pour une valeur de son identifiant ;

ü Association : C'est un lien entre les objets un lien verbal qui uni deux objets ou plusieurs objets ;

ü Cardinalités

II.1.1.2. DEFINITION DES REGLES DE GESTION

Seules les données utiles au frais d'hospitalisation doivent êtres retenues, ces sont seulles qui permettent d'en réaliser les différents traitements, donc obtenir le resultat souhaité(^7(*)).

Les données d'une application sont détectées à l'examen de documents existants, d'anciens fichiers ou de dessins d'écran et lors des divers entretiens avec les personnels de l'organisation^8(*).

Une donnée est désignée par un nom dans le langage de l'entreprise étudiée. L'analyse informatique recense les données et étudie les valeurs qu'elles peuvent prendre car ses dernières permettent de définir les caractéristiques précises de chacune des données.Les règles de gestion sont des expressions des contraintes administratives dans une entreprise.

Voici présentée ci-dessous la liste des règles de gestion pour notre sujet de recherche :

- Un service médical doit recevoir une ou plusieurs fois les patients;

- Un bon de transfusion appartient à un et un seul patient;

- Un patient peut passer au laboratoire une ou plusieurs fois pour une ou plusieurs maladies;

- Un bon de transfusion appartient à une et une seule catégorie des patients;

- Un donneur peut donner à un ou plusieurs patients de même groupe de sang ;

- Un infirmier peut faire un ou plusieurs testes chez lz patient

II.1.1.3. IDENTIFICATION ET DESCRIPTION DES DONNEES OBJETS

A. Recensement des Entités

C'est une opération qui consiste à énumérer la liste de toutes les entités concernées par notre étude.

Pour notre travail, nous avons recensé les entités ci-après :

- Patient ;

- Donneur ;

- Infirmier ;

- Type Service ;

- Groupe.

B. Description des objets

Le formalisme représentatif d'une entité est un rectangle constitué de deux parties dont la première supérieure où on trouve le nom de l'entité et la seconde inférieure possédant les différentes propriétés qui constituent cette entité.

Voici ci-dessous la description des différentes entités qui concernent notre travail :

1. Patient

L'entité Patient contient toutes les informations nécessaires d'un Patient.

Figure N°6

Source : nous-mêmes

2. Donneur

L'entitédonneurcontient les informations en rapport avec le donneur.

Figure N°7

Source : nous-mêmes

3. Infirmier

L'entité infirmier contient les informations en rapport avec l'infirmier.

Figure N°8

Source : nous-mêmes

4. Groupe

L'entité groupe contient les informations en rapport avec le groupe du malade

Figure N°9

Source : nous-mêmes

5. Service

L'entité Service contient les informations en rapport avec le Service.

figure N°10

Source : nous-mêmes

II.1.1.4. IDENTIFICATION ET DESCRIPTION DES ASSOCIATIONS

Dans le domaine informatique, une relation est un lien logique entre deux ou plusieurs entités. Elle peut ou ne pas être porteuse d'une ou plusieurs propriétés.

a) Recensement des relations

Le recensement des relations consiste à présenter la liste intégrale des relations qui relient les différentes entités qui participent à la gestion de notre application. Il s'agit de :

ü Appartenir ;

ü Tester ;

ü Prelever.

ü Transfuser ;

ü Dependre

b) Description des relations

les rélations consistent à relier deux ou plusieurs entités entre elles pour faciliter l'interaction. Elles peuvent aussi avoir les attributs, et les identifiants si cela est nécessaire. Ainsi, une relation est représentée physiquement ou shematiquement sous la forme ovale traduisant un verbe ou une action.

Tableau N°5

N°	RELATION	Type	Dimension	Table	Propriété
1	Appartenir	Père et Fils	Binaire	Infirmier & Service	Numinfir Code serv
2	Tester	Père et Fils	Binaire	Infirmier Groupe&	Numinfir CodeGroup
3	Prélever	Père et Fils	Binaire	Infirmier &Donneur	Numinfir numdonn
4	Transfuser	Père et Fils	Binaire	Infirmier& patient	Numinfir Numpatie
5	Dépendre	Père et Fils	Binaire	Patient & Donneur	Numpat Numdonne

Source : Nous mêmes

II.1.1.5. CARDINALITES

Elle nous permet de décrire la manière dont on caractérise le lien existant entre une entité et la relation à laquelle elle est liée.

Cette cardinalité prend sa valeur dans l'intervalle qui existe entre la borne maximale (1, n) qui dérive le nombre de fois maximum qu'une entité participe à une relation et celle minimale (0, n) décrivant le nombre de fois minimum qu'une entité participe à une relation.

a) Définition des contraintes des contraintes

- 0, 1 : une occurrence de l'entité existe mais ne participe pas à la relation (0), mais participe au maximum une fois (1) ;

- 1,1 : une occurrence de l'entité participe au minimum et maximum une et une seule fois à la relation ;

- 0, n : une occurrence de l'entité existe mais ne participe pas à la relation (0), mais au maximum plusieurs fois (n) ;

- 1, n : une occurrence d'une entité participe au minimum une fois (1) à la relation et peut participer sans limite (n) ;

Voici les différentes cardinalités possibles pour notre travail :

1. Service - Infirmier = Appartenir

Figure N°11

Appartenir

CIF

(1,n)

(1,1)

Source : nous-mêmes

2. Infirmier - Groupe = Tester

Tester

CIF

Figure N°12

(1,n)

Source : nous-mêmes

3. Infirmier - Donneur = Prélever

Figure N°13

Prélever

CIF

(1,n)

Source : nous-mêmes

4. Infirmier - Patient = Transfuser

Figure N°14

(1,n)

Transfuser

CIF

Source : nous-mêmes

5. Patient - Donneur = Dépendre

Dépendre

CIF

Figure N°16

(1,n)

Source :nous-mêmes

II.1.1.6. MODÉLISATION CONCEPTUELLE DES DONNÉES

Figure N°17

Source : nous-mêmes

II.1.2. MODELE CONCEPTUEL DES TRAITEMENTS

Le Modèle Conceptuel des Traitements (MCT) conduit à la détermination des procédures, et des limites homogènes des préoccupations. A ce niveau, il sera question de répondre à la question « Quoi », c'est-à-dire quel traitement sera effectué sur la base de données, ces traitements sont bien entendus des besoins des utilisateurs.

II.1.2.1. IDENTIFICATION ET DESCRIPTION D'OPERATIONS

Le processus est un ensemble d'opérations définies à partir des orientations de la gestion au sein du domaine de gestion étudiée et qui concourt à la sollicitation des plusieurs événements extérieurs au système d'information.

Un processus est un enchaînement synchronisé d'opérations qui représentent une entité homogène des préoccupations de l'entreprise. Il se rapporte à un domaine d'activité.

II.1.2.2. DÉFINITION DES CONCEPTS DE BASE.

v Evénement (E).

C'est le compte rendu au système d'information du fait que quelque chose s'était produit dans l'univers extérieur ou dans le système d'information lui-même. L'élément qui déclenche une opération ; une nouvelle arrivée de l'information peut être externe ou interne. Externe lorsqu'il provient de l'univers extérieur en provoquant une nouvelle réaction du système d'information ; soit constitué d'un résultat pour l'univers extérieur.

v Processus.

C'est une suite l'opération concourant à une finalité, déclenchée par des événements dans un domaine considéré pour une gestion donnée.

v Règle d'émission

Une règle d'émission définit la condition dans laquelle des évènements résultats seront produits par une opération.

v Synchronisation (S)

Une condition de synchronisation est représentée par une condition booléenne liant les événements déclencheurs grâce aux opérateurs logiques « Et », « Ou » et « Non ».

C'est le choix judicieux à l'aide des connexions logiques des événements qui doivent faire partir de processus réalisé ; la synchronisation est représentée par une figure en forme d'un entonnoir à l'intérieur duquel il y a une formule booléenne ou règle booléenne. La synchronisation intervient au cas où il y a conjonction d'événements.

v Opération (O)

Une opération est une production de flux d'information. Elle est définie « immatériellement », sans contrainte organisationnelle. Elle décrit aussi bien la gestion manuelle que la gestion automatisée.

1) Formalisme.

La représentation conceptuelle suit le formalisme. Pour construire le MCT, dans le cas de notre travail, nous allons exploiter les formalismes connus sous le nom de EOR qui signifie « Evénement, opération, résultat »

2) Recensement des opérations

Ø Arrivé du patient ;

Ø Réception du ; patient

Ø Administration soins intensifs ;

Ø Elaboration du bon de Laboratoire ;

Ø Teste d'Hémoglobine ;

Ø Recherche du donneur ;

Ø Test du groupe ;

Ø Fixation du prix ;

Ø Prélèvement du sang ;

Ø Envoi de la pochette du sang au service ;

Ø Transfusion du patient.

3) Description des opérations

La description est une étape très importante dans le modèle conceptuel de traitement, parce qu'elle permet de récapituler les différentes opérations, les événements qui les déclenchent et les résultats qui en résultent.

Se basant sur le recensement des opérations, la description des opérations sera comme suite :

1. Arrivé du Patient

#172; Evénement

- Reception du Patient ;

- Présence du Reeceptionniste.

#172; Règle d'émission

- OK

- KO

#172; Résultat

- Patient reçu ;

- Patient non reçu.

2. Administration des soins intensifs

#172; Evénement

- Patient reçu

#172; Règle d'émission

- Toujours

#172; Résultat

- Soins intensifs administrés

3. Elaboration du bon de laboratoire

#172; Evénement

- Soins intensifs administrés

#172; Règle d'émission

- Toujours

#172; Résultat

- Bon élaboré ;

4. Test d'hemoglobine

#172; Evénement

- Bon élaboré

#172; Règle d'émission

- Toujours

#172; Résultat

- Homoglobine testé ;

5. Demande de la transfusion

#172; Evénement

- Hemoglobine testé

#172; Règle d'émission

- Toujours

#172; Résultat

- Tranfusion demandé ;

6. Recherche du donneur

#172; Evénement

- Transfusion demandé

#172; Règle d'émission

- Toujours

#172; Résultat

- Donneur trouvé ;

7. Test du groupe

#172; Evénement

- Donneur trouvé

#172; Règle d'émission

- Toujours

- Groupe tester ;

8. Fixation du prix

#172; Evénement

- Groupe tester

#172; Règle d'émission

- Toujours

#172; Résultat

- Prix fixer ;

9. Prelevement du sang

#172; Evénement

- Prix fixer

#172; Règle d'émission

- Toujours

#172; Résultat

- Sang prélevé ;

10. Envoi de la pochette du sang au service

#172; Evénement

- Sang prélevé

#172; Règle d'émission

- Toujours

#172; Résultat

- Pochette du sang envoyé ;

11. Transfusion du patient

#172; Evénement

- Pochette du sang envoyé

#172; Règle d'émission

- Toujours

#172; Résultat

- Transfusion effective;

4) Formalisme du modèle conceptuel des traitements

Figure N° 18

Evénement

Synchronisation

Evt

Syn.

Rst

Opération

Condition d'émission

Résultat

Source : cours de méthode d'analyse informatique

II.1.3. PRESNTATION DU MODELE CONCEPTUEL DE TRAITEMENT

Figure N°19

Présence du Service

Arrivée patient

Administration effective

Patient non reçu

Patient reçu

Réception du patient

Réception du Patient

Administration soins intensifs

Toujours

Elaboration bon du labo

Toujours

Bon élaboré

Teste d'Hémoglobine

Toujours

Hémoglobine testé

Demande de transfusion

Toujours

Transfusion autorisée

Source : nous-mêmes

Groupe identique

Transfusion effective

Transfusion du patient

Toujours

Fixation du prix

Toujours

Test du groupe de sang

Réception du Patient

Prix fixé

Groupe différent

Recherche du Donneur

Toujours

Donneur trouvé

II.2. ETAPE ORGANISATIONNEL

Ce niveau exprime le choix d'organisation de ressources humaines et matériels, au travers de la définition des sites et postes de travail.

Ce niveau comporte deux modèles qui sont :

- .Le modèle organisationnel de données ;

- Le modèle organisationnel de traitement

II.2.1 MODELISATION ORGANISATIONNEL DES DONNEES

Ce modèle précise quelles sont les données retenues pour le système future, leurs répartitions et leurs localisations par site, ou encore leur confidentialité pour chaque intervenants.^9(*)

C'est à ce niveau que s'effectué le passage des données aux informations de leur durée de vie, la localisation des données par site, la définition des niveaux de sécurité.

II.2.1.1. PROBLEMATIQUE DU MODELE ORGANISATIONNEL DES DONNEES

Le modèle organisationnel des données va permettre de prendre en compte les éléments relevant de l'utilisation des ressources de mémorisation.

- Choix des informations à mémoriser informatiquement ;

- La quantification (ou volume) et la durée des informations à mémoriser ;

- La répétition des données informatisées entre unité organisationnelle.

Ces différentes préoccupations nous conduirons à définir deux niveaux de modélisation organisationnelle des données :

- MOD Global, directement dirigé du MCD ;

- Le MOD locaux, spécifique à une unité organisationnelle, les MOD locaux sont dérivé du MOD global en prenant compte de deux choix d'organisation, en particulier de répartition.

Le modèle organisationnel des données apparait donc comme une représentation, exprimée avec le formalisme entité-relation, les informations serons mémorisées informatiquement compte tenu de volume de la répartition et de l'accessibilité, sans encore tenir compte de la condition de la structure, de stockage et de performance liée à la technologie de mémorisation qui sera utilisée.

II.2.1.2. REGLE DE DU M.C.D AU M.O.D

Le passage du MCD au MOD se fait en appliquant les deux règles suivantes:

- Supprimer toutes les entités et toutes les relations avec leurs propriétés qui ne peuvent pas être mémorisés dans le modèle organisationnel de données (MOD) ;

- En cas de nécessité, créer des entités ou des relations nouvelles.

Pour notre application, toutes les entités et toutes les relations seront mémorisés. Ainsi notre modèle conceptuel de données (MCD) est égal au modèle organisationnel de données (MOD) c'est-à-dire (MCD = MOD).

II.2.1.3. Présentation du modèle organisationnel des données

Figure N°20

Source : nous-mêmes

II.2.1.4.MODÈLE ORGANISATIONNEL DE TRAITEMENT

Le MOT est issu du MCT, il reprend sa représentation de base et surtout de l'organisation choisie à la fin des études préalables^10(*).

Sur le plan descriptif de traitement, le MOT intègre les notions de temps et de la durée, de lieu et la nature de traitement pour répondre aux questions :

II.2.1.4.1. PROBLEMATIQUE DE LA MOT

"Qui ?" la réponse à cette question implique trois réponses à savoir : Qui effectue la tâche, si c'est l'homme la tâche est dite manuelle (TM) ; si c'est la machine la tâche est dite automatique (TA) ou tache informatique (TI) et si c'est l'homme et la machine la tâche est dite semi- manuelle, semi- informatique ou tâche est réelle (TR) ;

"Quand ?" la réponse à cette question donne lieu à une colonne appelée déroulement de la tache c'est-à-dire la périodicité, la fréquence de la tâche. Nous avons les taches dites :

- Journalière ;

- Périodique ;

- Hebdomadaire ;

- Mensuelle

- Annuelle

« Où » la réponse à cette question donne lieu à une colonne réponse appelée poste de travail, l'endroit où s'effectue la tâche.

Certains vocabulaires changent en ce sens que les opérations deviennent des procédures fonctionnelles ou organisationnelles.

Pour chaque traitement, il faut préciser le poste de travail associé à la nature de la tâche en terme de degré d'automatisation ainsi que la répartition dans le temps en ajoutant le délai de réponse qui peut être soit Immédiat (I), soit en différé (D) ; et le mode de fonctionnement unitaire (U) ou par lot (L).

II.2.1.4.2. Présentation Du modèle Organisationnel De Traitement

Tableau N°5

Périodicité

Quand ?

Procédure fonctionnelle

Nature de tâche où ?

Poste de travail

Patient reçu

Patient non reçu

Arrivée patient

Présence du Service

Administration effective

Réception du patient

Réception du Patient

Administration soins intensifs

Toujours

Elaboration bon du labo

Toujours

Bon élaboré

Teste d'Hémoglobine

Toujours

Hémoglobine testé

Demande de transfusion

Toujours

Transfusion autorisée

T.M

T.I

T.A

Réception

Service

Laboratoire

Recherche du Donneur

Toujours

Donneur trouvé

Groupe identique

Groupe différent

Prix fixé

Test du groupe de sang

Réception du Patient

Fixation du prix

Toujours

Transfusion du patient

Toujours

Transfusion effective

T.M

T.A

T.I

T.A

Laboratoire

Service

Source : nous-mêmes CHAPITRE III.CONCEPTION DU SYSTEME D'INFORMATION INFORMATISE

Cette étape nous permet de répondre aux questions « avec quoi ? » « Quels outils » En effet, nous tiendrons à répondre à la question « comment doit-on élaborer notre Base de données tout en tenant compte de la technologie informatique au niveau informatisé ? ». Cette question détermine les ressources matérielles et logicielles nécessaires à l'implémentation de notre base de données.

La conception du système d'information informatisé décrira le schéma de la base des données (relationnelle, hiérarchique ou réseau) c'est-à-dire les caractéristiques du mode de gestion des données, la répartition des données sur les différentes unités de stockage, les volumes par unité de stockage et l'optimisation des coûts induits par le mode de gestion^11(*).

Elle est constituée de deux niveaux à savoir :

- Le niveau logique ;

- Le niveau physique.

III.3.1. ETAPE LOGIQUE

Le niveau logique exprime le choix des moyens et des ressources informatiques en faisant abstraction de leurs caractéristiques techniques précises. Il comporte un modèle logique de données et un modèle logique de traitement.

III.3.2. MODELE LOGIQUE DES DONNEES

Le modèle logique de données (MLD) est construit à partir du MCD et MOD global en tenant compte de l'orientation des choix techniques concernant le système de gestion des données. Il permet de décrire la structure des données utilisées sans faire référence à un langage de programmation. Il s'agit donc de préciser le type de données lors de traitement.

III.3.1.1.2. REGLE DE PASSAGE DU M.O.D AU M.L.D BRUT12(*)

Le passage du MOD global au MLD brut doit respecter les règles suivantes :

- Les entités deviennent des tables ;

- Les propriétés des entités deviennent des attributs des tables ;

- Les identifiants des entités deviennent des clés primaires.

Les relations dans le sens conceptuel ou sémantique subissent plusieurs traitements selon le cas notamment :

- La relation du type père et fils disparaît, mais la sémantique sera maintenue. Comme la table fils dépend de la table père, elle va recevoir la clé de son père et cette dernière (clé) sera migrée dans la table fils comme clé étrangère et une sémantique orientée vers la table père.

- Pour la relation du type autre que père et fils ; cette relation devient la table et ses clés seront la concaténation des clés de deux autres tables. Si la relation portait une propriété, celle-ci demeurera dans la table comme attribut.

1. Formalisme du Modèle Logique des Données

Table : conserve le formalisme de l'entité.

Table de lien : pointe les autres tables

Tous les arcs sont orientés.

III.3.1.1.3. PRESENTATION DU MODELE LOGIQUE DES DONNEES BRUT

Figure N°21

Source : nous-mêmes

III.3.1.1.4. NORMALISATION

L'opération de la normalisation consiste à supprimer les redondances qui peuvent encore se trouver dans le MLD brut. Cela veut dire qu'au niveau de l'étape conceptuelle, nous n'avons pas tenu compte des règles de vérification des entités pour que leurs propriétés ne soient pas répétitives. C'est ainsi que nous allons vérifier ces entités de manière que ceux-ci aient des propriétés non répétitives.

Cette opération de la normalisation nous octroie trois formes normales à respecter afin de pouvoir valider notre MLD.

1^ère forme normale

Une table est en première forme normale, si tous ses attributs sont élémentaires, c'est-à-dire non décomposables, non répétitifs, et qu'elle porte une clé primaire ou concaténée.

2^ème forme normale

Une table est en deuxième forme normale, si étant déjà en première forme normale et ses attributs dépendent pleinement de la clé primaire de cette table.

3^ème forme normale

Une table est en troisième forme normale, si étant déjà en deuxième forme normale, les attributs qu'elle porte ont une dépendance fonctionnelle directe avec la clé sans passer transitivement à un autre attribut non clé. Il faut s'assurer aussi qu'il n'y a pas de tables qui soient cachées parmi les autres.

Dès lors que les trois premières formes sont respectées, les tables peuvent être déjà déclarées normalisées, et le MLD sera validé.

III.3.1.1.5. PRESENTATION DU MODELE LOGIQUE DES DONNEES VALIDE

Figure N°22

Source : nous-mêmes

III.3.1.1.6. SCHEMAS LOGIQUES ASSOCIES AU MODELE LOGIQUE DES DONNEES VALIDE

1) Sevice [(#Code_Serv car : (20),libelle servi texte (70)] ;

2) Infirmier[( #numinfi car (20), nominfir texte (10), prenominfir texte (10), sexeinfir texte (2), nationaliteinfir texte (10)]

3) Groupe[(#code groupe car (20), #Num infir car; (20), libelle groupe odegrouptexte (30)]

4) Donneur [(#Code_donneur : Car[20] ; #num infir car : (20), libelle donneur texte (30)] ;

5) Patient[(#numpat car (20), #codetransf Car (20), nompat texte (10),postnompat (10), prenom patien (10),datenaisspat date/heure (10), adressepatien texte (10), sexepatie texte (2), Nationalitépatie (10)] ;

6) Tester [(#Code_group : Car (20), #numinfir car (20),#codedonneur car (20)]

7) Prélever[(#codeprelev car (20), #numinfir car (20), #numdonneur car (20), dateprelev date/heure (6)]

8) Transferer [(#codetransfer car (20), #numinfir car (20), #numdonneur car (20), datetransfu date/heure (6)]

III.3.1.1.7. Calcul de de la volumetrie

a. Volume utile de la base des données

Tableau N°6

N°	OBJETS	Nombre d'occurances	TAILLES	VOLUME
1	Service	1800	90	162000
2	Patient	2500	102	255000
3	Infirmier	2500	52	130000
4	Tester	2500	60	150000
5	Prélever	2500	66	165000
6	Transferer	2500	66	165000
7	Groupe	1800	70	126000
8	Donneur	1800	70	126000
Volume Utile de la base				1279000

Source : Nous - mêmes

b. Tableau N° 7

Volume des indexes de la base des données

N°	TABLE	INDEXE	TAILLE	OCCURRENCE	VOLUME INDEXE
1.	Service	#Codeser	20	1800	36000
2.	Patient	#Numpat #codetransf	40	2500	100000
3.	Infirmier	#Numinfir #Codeserv	40	2500	100000
4.	Tester	#Codegroup #numinfir #codedonne	60	2500	150000
5.	Prélever	#Codeprelev #numinfir #codedonneur	60	2500	150000
6.	Transferer	#Codetransf #numinfir #codedonn	60	2500	150000
7.	Groupe	#Codegroup #numinfir	40	1800	72000
8	Donneur	#Codedonner #Codetransf	40	1800	72000

Source : Nous - mêmes

Volumes des indexes

830000

c. Volume total de la base des données

Volume total= (volume utile + volume des indexes) * ?

? : coefficient de sécurité(2,5)

Volume total= (1279000+ 830000) *2,5 = 3354000 caractères

=3354000/1024 = 1281026,3671875 Mo

= 1281026,3671875 /1024 = 1251,00Ko

=1251,00/1024 = 1,2216796875 Soit 1,22 Go

III.3.1.2.3. MODELE LOGIQUE DE TRAITEMENT

La modélisation organisationnelle des traitements s'est centrée avant tout sur les préoccupations de l'utilisateur en faisant abstraction de toute considération technique. Le modèle logique de traitement (MLT) va porter sur le domaine de l'informaticien et de sa responsabilité. Il servira à construire une solution technique répondant aux spécifications du modèle organisationnel des traitements.

Cette solution technique sera basée sur la description des unités logiques des traitements.

1. Définition des concepts de base^13(*)

Une procédure logique est un enchaînement logique de plusieurs unités logiques de traitements.

Tandis qu'une unité logique de traitement est un ensemble d'actions organisées d'une tâche exécutable d'une manière automatique. Cette unité logique de traitement est associée avec les sous schémas logiques de données, qui ne sont rien d'autres qu'un sous-ensemble de tables et d'attributs définis sur le modèle logique de données que nous venons de valider afin de pouvoir présenter la logique fonctionnelle qui représente l'organisation générale de l'ensemble des traitements à effectuer.

III.3.1.2.2. Regle de Passage M.O.T au M.L.T

Le passage du MOT au MLT concerne la réflexion et/ou l'imagination du développeur de l'application, selon sa maîtrise et/ou sa pensée dans laquelle il appliquera sur la conception de ses interfaces graphiques.

Cependant, nous allons éliminer à partir du MOT les tâches qui ne seront pas informatisées et les tâches restantes détermineront l'unité logique de traitement où les événements fonctionnels disparaissent et cèdent la place aux actions des utilisateurs notamment : clique, saisie, etc. Les tâches deviennent des unités logiques de traitement ; les procédures fonctionnelles deviennent procédure logique ; l'ensemble des procédures logiques constitue le MLT et les postes de travail deviennent des sites.

Figure N° 21

III.3.1.2.3. Présentation du Modèle Logique de Traitement

Début de la procédure

Figure n°23

ULT 000

LOGO

ULT 001

CONNEXION

Connexion

Annuler

Fin de la procédure

ULT 002

MENU PRINCIPAL

Saisie

Edition

Fermer

Mis à jour

ULT 003

ULT003

- Service

- Infirmier

- Groupe

- Donneur

- Patient

- Tester

- Transfuser

- Prélever

ULT 004

ULT004

- Liste des Patients transfusés

- Listes des donneurs

- Listes de nombres de pochettes par patients

- - MAJ table Patient

- MAJ table Groupe

- MAJ table Donneur

- MAJ table Transfuse

- MAJ table Tester

- MAJ table Prélever

- MAJ table Tester

- - ULT004 005

BDD

SUIV

ANN

SUIV

ANN

SUIV

ANN

Source : Nous-mêmes

III.3.2. ETAPE PHYSIQUE

III.3.2.1. PRISE EN COMPTE DES RESSOURCES

III.3.2.1.1. RESSOURCES MATERIELS

La description des matériels s'effectue en tenant compte de deux grandes parties de l'ordinateur (le Hardware et le Software).

@ Présentation de Hardware

- Marque Ordinateur : DELL ;

- Type de processeur : Intel i5, 4 Ghz ;

- Ram : 2 Go ;

- Disque Dur : 500 Go ;

- Lecteur DVD;

- Souris : PS/2 Compatible ;

- Clavier : AZERTY ;

- Ecran : Plat en couleur ;

- Imprimante : HP Deskjet 1510

- Onduleur : UPS, 2 KVA, Autonomie 2 heures.

III.3.2.1.2. RESOURCES LOGICIELS

Le système d'exploitation : Microsoft Windows 10,

Logiciel d'application : Microsoft Office 2016 (Word, Excel, Access, PowerPoint ...), Anti-virus (Kaspersky)

III.3.2.2. MODÉLISATION PHYSIQUE DES DONNÉES

III.3.2.1.1. PROBLEMATIQUE DU MODELE PHYSIQUE DES DONNEES

Le modèle physique de données (MPD) est le dérivé du modèle logique de données. En d'autres termes, le modèle physique de données n'est rien d'autre qu'un résultat du modèle logique de données sauvegardé sur un support magnétique^14(*).

III.3.2.3.2 REGLE DE PASSAGE DU M.L.T AU M.P.T

Le passage du modèle logique de données (MLD) au modèle physique de données (MPD) sera effectué grâce au système de gestion de base de données (SGBD) que nous avons choisi (Access).

III.3.3. PRESENTATION DU MODELE PHYSIQUE DES DONNEES

La présentation du MPD est un tableau qui reprend le nom de la table, les propriétés, la nature de chaque propriété, la taille et la description.

1) Table Service

Image N°1

Source : nous-mêmes

2) Table Infirmier

Image N°2

Source : Nous - mêmes

3) Image N°3

Table Tester

Source : Nous - mêmes

Image N° 4

4) Table Groupe

Source : Nous - mêmes

Image N° 5

5) Table Donneur

Source : Nous - mêmes

6) Table Prélever

Image N°6

Source : Nous - mêmes

7) Table Transfuser

Image N°7

Source : Nous - mêmes

8) Table Patient

Image N°8

Source : Nous - mêmes

III.3.2.3.3. PRESENTATION DU MODÉLE PHYSIQUE DES TRAITEMENTS

1) Passage du Modèle Logique de Traitement au Modèle Physique de Traitement

Le modèle physique de traitement (MPT) n'est rien d'autre qu'une représentation graphique de la structure qui parle sur la transfusion sanguine des patient.

2) Présentation du Modèle Physique des Traitements

Figure n°24

CREATION DES TABLES

Groupe

Tester NE

Infirmier

Service

Prélever

Donneur

Transfuser

Patient

CREATION DES REQUETTES

CREATION DES FORMULAIRES

CREATION DES ETATS

LISTES DE NOMBRES DE POCHETTES PAR PATIENTS

LISTES DES DONNEURS

LISTE DES PATIENTS TRANSFUSES

Source : Nous-mêmes

CHAPITRE IV : REALISATION DE LA BASE DE DONNEES

Ce chapitre consiste à implémenter la base de données qui assure le suivi de la transfusion sanguine à l'hôpital général de Référence de Kabinda en sigle HGR/TSHOFA. A ce niveau, nous allons présenter quelques procédures et images qui représentent notre logiciel.

IV. 1 IMPLEMENTATION DE LA BASE DES DONNEES

VI.1.1. NOTION SUR LE SYSTEME DE GESTION DES BASE DES DONNEES

La procédure de la création d'une base des données vide en Access est la suivante dès qu'Access est actif.

ü Cliquer sur l'icône « BDD » ;

ü Nommer la BDD ;

ü Choisir l'emplacement ou l'endroit à loger le BDD ;

ü Cliquer sur le bouton créer.

Après toutes opérations de la création ; voici comment notre base de données vide doit se présenter :

Image N°9

Source nous-mêmes

Image N°10

Source nous-mêmes

IV.2 : STRUCTURATION DE LA BASE DES DONNEES

IV.2.1 : CREATION DES TABLES

Table est le premier objet de la base des données et celle qui nous permet de stocker les données. La procédure de la création d'une table est la suivante :

ü Cliquer sur l'onglet « créer » de la barre de menu ;

ü Cliquer sur l'outil « création table » ;

ü Une fenêtre s'ouvre et permettant de définir les champs, en précisant le nom du champ et le type des données qu'il contient ainsi que leur taille ;

ü Cliquer sur « enregistrer » pour sauvegarder ;

ü Dans la fenêtre enregistrer sous, donnez le nom à la table et cliquez sur ok

Image N°11

Source nous-mêmes

IV.2.2. CREATION DES RELATIONS ENTRE LES TABLES

Pour la création des relations la procédure à suivre est la suivante :

@ A partir de la fenêtre Access, cliquer sur l'onglet « Outils de base des données » du menu ;

@ Clique sur l'onglet « relation » ;

@ Une fenêtre s'ouvre, nous permettra d'ajouter les tables ;

@ La fenêtre » modifié la relation » s'ouvre pour nous donner la possibilité de cacher les cases suivantes ;

@ Appliquer l'intégrité référentielle ;

@ Mettre à jour en cascade les champs correspondants ;

@ Effacer en cascade les enregistrements correspondants ; cliquer sur le bouton « type de jointure » pour faire le choix de jointure ;

@ Cliquer sur le Bouton « créer » pour réaliser la jointure.

Ainsi, la « relation » se présente.

Image N°12

Source nous-mêmes

IV.2.3 CREATION DES REQUETES

Pour créer une requête il faut :

@ Cliquer sur l'onglet « créer » de la barre de menu ;

@ Cliquez sue l'outil « création table » ;

@ Dans la fenêtre « afficher table » s'affiche ;

@ Sélectionner la table sur laquelle doit porter la requête puis cliquez successivement sur le bouton « Ajouter » et « fermer » ;

@ Double cliquez sur le champ à reprendre ou sait cliquer sur l'attribut net maintenir le bouton gauche de la souris enfoncé, en suite glisser jusque dans la grille puis relâcher ;

@ Cliquez sur « enregistrer » pour sauvegarder la table ;

@ Dans la fenêtre enregistrer sous, donnée le nom à la table et cliquer sur OK.

Image N°13

Source nous-mêmes

IV.2.4. CREATION DES FORMULAIRES

La procédure de la création d'un formulaire est la suivante :

@ Cliquez sur l'onglet « créer » de la barre de menu ;

@ Cliquez sur l'outil « création formulaire » ;

@ Cliquez sur l'outil « feuille de propriétés » ;

@ Dans la liste de choix de la propriété « source » ;

Sélectionner le champ et le déposer sur le formulaire en faisant« glisser -déposer ».

@ Cliquer sur « enregistrer » pour la sauvegarder de la table ;

@ Dans la fenêtre enregistrer sous, donnez le nom à la tab le et cliquer sur OK.

Image N°14

Source : Nous - mêmes

IV.2.5. CREATION DES ETATS

La procédure de la création d'un Etat est la suivante :

@ Ouvrir d'abord la base de données ;

@ Cliquer sur l'onglet créer » ;

@ Dans le groupe Etatcliquer sur la Commande « Assistant Etat» ;

@ Dans la boite de dialogue assistant Etats, dérouler la zone « Table/requetés » et cliquer sur la table ou la requête concernée par l'Etat« source » ;

Image N°15

Source : nous-mêmes

CREATION DU MENU PRINCIPAL

Procédure pour créer le formulaire Menu Principal

- Ouvrir d'abord la base de données ;

- Dans le groupe « Formulaires », cliquer sur la commande « Création de formulaire » sous l'onglet « Créer » ;

- Enregistrer ce formulaire de la même manière que tous les autres formulaires ;

- Dans le groupe "Contrôles", sous l'onglet contextuel "Création", cliquer sur la commande "Contrôle onglet" puis déposer cette commande sur la grille du formulaire à l'aide d'un simple clic;

- Cliquer sur l'onglet "Page 1", cliquer ensuite sur la commande "Feuille des propriétés" du groupe "Outils" sous l'onglet contextuel "Création";

- Dans cette feuille des propriétés, cliquer sur l'onglet "Format" puis sur l'option "Légende". Taper immédiatement l'expression qui sera considérée comme le nom de l'onglet (Ex : Affichage des formulaires) et fermer la feuille des propriétés ;

- Cliquer sur l'onglet "Page 2", cliquer ensuite sur la commande "Feuille des propriétés" du groupe "Outils" sous l'onglet contextuel "Création";

- Dans cette feuille des propriétés, cliquer sur l'onglet "Format" puis sur l'option "Légende". Taper immédiatement l'expression qui sera considérée comme le nom de l'onglet (Ex : Aperçu des états) et fermer la feuille des propriétés ;

- Insérer une étiquette au - dessus du contrôle onglet et y taper l'expression "Menu Principal" et faire la mise en forme de cette expression ;

- Cliquer sur le 1^er onglet et y ajouter une image si cela est possible. Pour ce faire, cliquer sur la commande "Image" du groupe "Contrôle" sous l'onglet contextuel "Création" ;

- Cliquer à l'intérieur du contrôle onglet pour déposer la commande "Image". Dans la boîte de dialogue qui apparait, rechercher l'image préférée, après l'avoir retrouvé, cliquer sur son nom puis sur le bouton "Ouvrir" de cette boîte de dialogue ;

- Cliquer sur cette image, afficher la feuille des propriétés, cliquer sur l'onglet "Format", cliquer sur "Mode d'affichage" dans cette feuille des propriétés et choisir comme mode d'affichage "Échelle" et fermer la feuille des propriétés ;

- Cliquer sur le 2^ème onglet et y ajouter une image si cela est possible. Pour ce faire, cliquer sur la commande "Image" du groupe "Contrôle" sous l'onglet contextuel "Création";

- Cliquer à l'intérieur du contrôle onglet pour déposer la commande "Image". Dans la boîte de dialogue qui apparait, rechercher l'image préférée, la retrouver et cliquer sur son nom puis cliquer sur le bouton "Ouvrir" de cette boîte de dialogue;

- Cliquer sur cette image, afficher la feuille des propriétés, cliquer sur son onglet "Format", cliquer sur "Mode d'affichage" dans cette feuille des propriétés et choisir comme mode d'affichage "Échelle";

- Cliquer sur chaque onglet et y déposer autant de boutons selon le nombre de formulaires ou d'états à afficher dans le menu principal en choisissant comme Catégorie "Opérations sur formulaire" et comme action "Ouvrir un formulaire" dans le cas des formulaires ou bien "Opérations sur état" et comme action "Aperçu d'un état" dans le cas des états ;

- Cliquer sur le bouton « Suivant » de cette boite de dialogue et cliquer ensuite sur le nom du formulaire ou de l'état qui doit être affiché sur le menu principal et cliquer de nouveau sur le bouton « Suivant » de cette boite de dialogue ;

- Cliquer dans la 1^ère zone de texte, remplacer la mention qui s'y trouve par le nom que le bouton du menu principal pourra porter (Ex : Enregistrement des mouvements, Enregistrement des fournisseurs, Enregistrement des commandes, ...) puis cliquer sur le bouton « Suivant » de cette boite de dialogue ;

- Cliquer enfin sur le bouton « Terminer »

- Placer une étiquette au - dessus du contrôle onglet puis saisir le titre de ce formulaire (Ex : MENU PRINCIPAL) et mettre en forme cette étiquette en forme.

Image N°16

Source nous-mêmes

CREATION DE PAGE D'ACCUEIL

Procédure pour créer le formulaire Page d'accueil

- Ouvrir d'abord la base de données ;

- Dans le groupe « Formulaires », cliquer sur la commande « Création de formulaire » sous l'onglet « Créer » ;

- Enregistrer ce formulaire de la même manière que tous les autres formulaires ;

- Placer autant d'étiquettes sur la grille de ce formulaire selon le nombre de lignes prévues pour les commentaires sur la base de données et celui qui l'a réalisée.

- Placer deux boutons de commande sur cette grille : le premier permet de quitter Microsoft Access en utilisant la catégorie « Opérations sur Application » et comme action « Quitter Access » ; le deuxième bouton permettra l'accès au menu principal.

La figure ci - dessous illustre la création du formulaire Page d'accueil :

Image N°17

Source nous-mêmes

IV.2.5. PROTECTION D'UNE BASE DE DONNEES

Pour sécuriser une base de données, il faut la protéger à l'aide d'un mot de passe de la manière suivante :

- Lancer Access 2007 ;

- A partir de la page « prise en main de Microsoft office Access faire la combinaison des touches CTRL + O ou bien cliquer sur l'outil « Ouvrir » de la barre d'outils Access rapide ;

- Dans la boite de dialogue qui apparait, rechercher et sélectionné la base de données concernée, dérouler la commande « ouvrir » et cliquez sur « ouvrir en exclusif » cette base de données s'ouvre en mode exclusif ;

- Sous l'onglet « Outils de base de données cliquez sur la commande définir le mot de passe de la base de données » ;

- Dans la boite de dialogue qui apparait taper le mot de passe préféré dans la première Zone ; retaper ce même mot de passe dans la deuxième Zone pour confirmation et cliquez enfin sur le bouton « Ok »

Image N°18

Source nous-mêmes

CONCLUSION

Étant à terme de notre travail qui a porté sur « Conception et réalisation d'une base de données pour le suivi de la transfusion sanguine dans une structure sanitaire cas de l'HGR/TSHOFA ». Nous avons fait ce travail dans le but de connaitre le nombre des patients transfusés durant une période donnée en dotant à l'hôpital Général de référence de Tshofad'une Base de données capable d'assurer un travail efficace et fiable.

Partant de nos recherches, nous avons fait recours aux méthodes : descriptive, historique, analytique etméthode merise ainsi qu'aux technique documentaire et d'interview.

En dehors de l'introduction et de la conclusion, ce travail a quatre chapitres :

ü Le premier chapitre concerne les analyses préalables dans lequel nous avons analysé, critiqué le système existant et proposé la solution informatique.

ü Le deuxième chapitre consacré à la conception d'un système d'information organisationnel où nous avons analysé toutes les informations avec la méthode « MERISE de deuxième génération » en utilisant les étapes ci-après :

- L'étape conceptuelle de données et l'étape conceptuelle de traitement ;

- L'étape organisationnelle des données et l'étape organisationnelle de traitement.

ü Le troisième chapitre concerne la conception d'un système d'information informatisé, dans lequel nous avons développé les étapes ci-après :

- L'étape logique de données et l'étape logique de traitement ;

- L'étape physique de données et l'étape physique de traitement.

Et enfin, le quatrième chapitre basé sur la programmation, dans lequel nous avons réalisé notre base des données relative à la transfusion sanguine en se servant d'Access 2010.

Ce travail est loin d'être parfait, ainsi vos remarques et suggestions seront les bienvenues pour son amélioration.