Cette étude de cas porte sur la conception d'une base de données pour un hôpital en utilisant la

méthode Merise. Voici une résolution détaillée, étape par étape.

1. Identification des Entités et de leurs Attributs

Une entité représente un objet ou un concept du monde réel. Ses attributs sont les propriétés
qui le décrivent.

Entité Attributs

Service CodeService (id), NomService

Médecin MatriculeMed (id), Nom, Prénom, Spécialité

Patient NumPatient (id), Nom, Prénom, DateNaissance, Adresse

Admission NumAdmission (id), DateEntrée, DateSortie

Lit NumLit (id), État (occupé/libre)

Soin NumSoin (id), DateSoin, HeureSoin, TypeSoin

Facture NumFacture (id), DateFacturation, MontantTotal

Export to Sheets

2. Associations et Cardinalités

Les cardinalités définissent le nombre de fois qu'une entité peut participer à une relation.

• Appartenir (Service - Médecin) :

o Un service regroupe plusieurs médecins (1,N).

o Un médecin est affecté à un seul service (1,1).

• Concerner (Patient - Admission) :

o Un patient peut avoir plusieurs admissions (0,N).

o Une admission concerne un seul patient (1,1).

• Attribuer (Admission - Lit) :

o Une admission peut se voir attribuer au plus un lit (0,1).

• Effectuer (Médecin - Soin) :

o Un médecin peut effectuer plusieurs soins (0,N).

o Un soin est effectué par un seul médecin (1,1).

• Lier (Admission - Soin) :

o Une admission peut comporter plusieurs soins (0,N).

o Un soin est rattaché à une seule admission (1,1).

• Établir (Admission - Facture) :

o Une admission donne lieu à une seule facture (1,1).

o Une facture correspond à une seule admission (1,1).

3. Modèle Conceptuel des Données (MCD)

Le MCD est la représentation graphique des entités et des relations.

• [Service] --(1,N)----<Appartenir>----(1,1)-- [Médecin]

• [Médecin] --(0,N)----<Effectuer>----(1,1)-- [Soin]

• [Patient] --(0,N)----<Concerner>----(1,1)-- [Admission]

• [Admission] --(0,N)----<Lier>----(1,1)-- [Soin]

• [Admission] --(0,1)----<Occuper>----(0,N)-- [Lit]

• [Admission] --(1,1)----<Établir>----(1,1)-- [Facture]

4. Modèle Logique des Données (MLD)

Pour passer du MCD au MLD, on applique les règles de transformation : la "clé primaire" du côté
(1,N) devient une "clé étrangère" du côté (1,1).

• Service (<u>CodeService</u>, NomService)

• Médecin (<u>MatriculeMed</u>, Nom, Prénom, Spécialité, #CodeService)

• Patient (<u>NumPatient</u>, Nom, Prénom, DateNaissance)

• Soin (<u>NumSoin</u>, DateSoin, HeureSoin, TypeSoin, #MatriculeMed,

• Lit (<u>NumLit</u>, État)

• Facture (<u>NumFacture</u>, DateFacturation, MontantTotal, #NumAdmission)

5. Schéma Relationnel (SQL simplifié)

Voici la structure finale des tables. Les clés primaires sont en gras et les clés étrangères sont
précédées d'un astérisque.

1. Service (CodeService, NomService)

2. Médecin (MatriculeMed, Nom, Prénom, Spécialité, CodeService)

3. Patient (NumPatient, Nom, Prénom, DateNaissance)

4. Lit (NumLit, État)

5. Admission (NumAdmission, DateEntrée, DateSortie, NumPatient, NumLit)

6. Soin (NumSoin, DateSoin, HeureSoin, TypeSoin, MatriculeMed, NumAdmission)

7. Facture (NumFacture, DateFacturation, MontantTotal, NumAdmission)

Note sur la Facture : Puisqu'une admission a une seule facture et vice-versa (1,1 - 1,1), on aurait
pu fusionner les deux tables, mais garder la facture séparée est plus propre pour la gestion
comptable.

Souhaitez-vous que je génère le code SQL CREATE TABLE correspondant à ce schéma pour créer
la base de données ?

C'est une excellente idée. Passer du schéma logique au code SQL permet de concrétiser la
structure. Voici le script SQL complet pour créer les tables de votre base de données
hospitalière.

Notez que j'ai ajouté des types de données standards (INT, VARCHAR, DATE) et respecté l'ordre
de création pour éviter les erreurs de clés étrangères (on crée d'abord les tables "parentes"
comme Service et Patient avant les tables "enfant" comme Médecin ou Admission).
Script SQL de création

SQL

-- 1. Table Service

CREATE TABLE Service (

CodeService INT PRIMARY KEY,

NomService VARCHAR(100) NOT NULL

);

-- 2. Table Medecin (liée à Service)

CREATE TABLE Medecin (

MatriculeMed INT PRIMARY KEY,

Nom VARCHAR(50) NOT NULL,

Prenom VARCHAR(50),

Specialite VARCHAR(100),

CodeService INT,

FOREIGN KEY (CodeService) REFERENCES Service(CodeService)

);

-- 3. Table Patient

CREATE TABLE Patient (

NumPatient INT PRIMARY KEY,

Nom VARCHAR(50) NOT NULL,

Prenom VARCHAR(50),

DateNaissance DATE,

Adresse VARCHAR(255)

);
-- 4. Table Lit

CREATE TABLE Lit (

NumLit INT PRIMARY KEY,

Etat VARCHAR(20) DEFAULT 'Libre'

);

-- 5. Table Admission (liée à Patient et Lit)

CREATE TABLE Admission (

NumAdmission INT PRIMARY KEY,

DateEntree DATE NOT NULL,

DateSortie DATE,

NumPatient INT NOT NULL,

NumLit INT,

FOREIGN KEY (NumPatient) REFERENCES Patient(NumPatient),

FOREIGN KEY (NumLit) REFERENCES Lit(NumLit)

);

-- 6. Table Soin (liée à Medecin et Admission)

CREATE TABLE Soin (

NumSoin INT PRIMARY KEY,

DateSoin DATE NOT NULL,

HeureSoin TIME,

TypeSoin VARCHAR(100), -- Consultation, examen, intervention...

MatriculeMed INT NOT NULL,

NumAdmission INT NOT NULL,

FOREIGN KEY (NumAdmission) REFERENCES Admission(NumAdmission)

);

-- 7. Table Facture (liée à Admission)

CREATE TABLE Facture (

NumFacture INT PRIMARY KEY,

DateFacturation DATE NOT NULL,

MontantTotal DECIMAL(10, 2), -- 10 chiffres au total, 2 après la virgule

NumAdmission INT UNIQUE NOT NULL, -- UNIQUE car 1 facture = 1 admission

FOREIGN KEY (NumAdmission) REFERENCES Admission(NumAdmission)

);

Explications techniques :

• FOREIGN KEY : Ces contraintes assurent l'intégrité référentielle. Par exemple, vous ne
pouvez pas enregistrer un soin pour un médecin qui n'existe pas dans la table Medecin.

• UNIQUE : Pour la table Facture, le NumAdmission est marqué comme UNIQUE pour
respecter la règle de gestion "Une facture correspond à une seule admission".

• DECIMAL(10, 2) : C'est le format idéal pour les montants financiers afin d'éviter les
erreurs d'arrondi des nombres flottants.

• Ordre de suppression : Si vous devez supprimer ces tables, vous devrez le faire dans
l'ordre inverse de leur création pour ne pas briser les liens de parenté.