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

 > 

Conception et réalisation d'un logiciel de suivi des patients au sein du centre de santé UHAKI

( Télécharger le fichier original )
par Grâce MURHULA KABI
ISP-Bukavu - Diplôme de graduat en Informatique de gestion 2014
  

précédent sommaire suivant

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

III.4. LE NIVEAU LOGIQUE

III.4.1. Le Modèle Logique de Données Relationnelles (MLDR)

C'est grâce à toutes les opérations précédentes que l'ensemble des tables de la base de données vont pouvoir être structurées de manière simple et rapide. Ce sont les entités, les cardinalités maximales et minimales qui vont jouer le rôle essentiel pendant la réalisation du MLDR. Le modèle logique de données relationnel s'obtient soit à partir du modèle conceptuel de données ou soit à partir du modèle organisationnel de données.

III.4.1.1. Règles de passage du MCD au MLDR

Toutes les entités du MCD deviennent des tables de la base de données. Les propriétés des objets du MCD deviennent des attributs dans le modèle logique de données relationnel, l'identifiant de l'entité devient la clé primaire de la table.

La clé primaire de la table à la cardinalité (X, n) devient une clé étrangère dans la table à la cardinalité (X, 1), X=1 ou 0. Il y a création d'une table supplémentaire ayant comme clé primaire, une clé composée des identifiants de 2 entités lorsque les cardinalités sont (X, n)-(X, n), X=1 ou 0.

Les règles de passage du MCD au MLDR ne sont pas exhaustives. Et ci-dessous nous présentons notre MLDR.

III.4.1.2. Représentation du MLDR

On représente le modèle logique de données relationnel de deux manières, soit en intention ou soit en extension.

a) Représentation en intention

T_RECEPTION (numrec, nomal, datearrive, nomrec)

T_MALADE (numal, nufich, nomal, fonction, sexe, adresse, nompere, nomere, nomconj, tel, reference, nomeglise, #numrec, #numcons, #numlab, #numtr)

T_CONSULTATION (numcons, nomal, nominfir, plaintes, diagnostic, datecons, mois, année)

T_LABORATOIRE (numlab, nomal, natexam, decision, datelab)

T_TRAITEMENT (numtr, nomal, nominf, décision, datetr, mois, année)

T_PRESCRIPTION (codmed, nomed, dose, qté, #numcons)

b) Présentation en extension

III.5. LE NIVEAU PHYSIQUE

III.5.1. Le modèle physique de données (MPD)13(*)

Le modèle physique de données, MPD, est une représentation de l'organisation des données en tenant compte d'un système de gestion de base de données retenu, la plupart du temps un SGBDR.

Le modèle physique de données reprend donc la structure créée à l'étape précédente et introduit une précision quant aux types de données des différentes colonnes. La structure en tables et en colonnes du modèle relationnel est conservée, mais on va y ajouter les types de données de chacune des colonnes. Ces types de données vont varier et pourront être différents d'un SGBD à un autre. Nous représentons notre modèle physique de données de la manière ci-après :

1) Table Agent

2) Table Réceptionner

3) Table Malade

4) Table Infirmier

5) Table Consulter

6) Table Examiner

7) Table Traiter

8) Table Prescription

9) Table Payer

10) Table Sortie

11) Table Facturer

* 13 MUKAMBA V, Cours de méthode d'analyse informatique, Inédit, G2 IG, ISP/Bukavu, 2013-2014

précédent sommaire suivant






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








"Je voudrais vivre pour étudier, non pas étudier pour vivre"   Francis Bacon