Introduction Le but de ce projet est de réaliser une base de données

Introduction
Le but de ce projet est de réaliser une base de données permettant de gérer les
remboursements de clients dans une pharmacie.
Concrètement, il y a des clients, des médecins, des produits. Un client peut être inscrit
dans un centre de gestion des remboursements, cotiser à une mutuelle et être inscrit à une
sécurité social.
Un docteur soigne des clients, fait des ordonnances et les donnes aux clients.
Une ordonnance donne lieu à des factures qui sont envoyés au centre de gestion des
remboursements.
Ce dernier calcule la somme remboursée par la sécurité sociale et la mutuelle et en déduit la
somme à payer par le patient.
Il faut donc créer une base de données dynamique capable de gérer ces données, les
actualiser et les modifier. Il faut donc procéder par étapes pour réaliser un projet tel que celui
la.
En premier lieu, nous allons parler de la conception de la base de données. Il y a
plusieurs stades avant de créer les tables de la base de données sous oracle et nous allons les
détailler. Il faut d’abord réaliser un modèle conceptuel de données, puis le transposer en
modèle logique de données relationnelles et enfin établir le modèle physique des données.
A la suite de ça, nous aborderons tout ce qui touche aux requêtes SQL. A quoi servent-
elles ? Comment introduire des données dans la base ? Comment modifier des données ?
Ensuite nous expliquerons l’utilisation du langage PL/SQL, langage qui permet de
dynamiser la base. Nous montrerons son utilité et l’utilisation que nous en avons fait dans
notre base de données.
Nous avons rencontré je pense comme beaucoup de personnes des problèmes durant la
réalisation de cette base de données. C’est pourquoi notre base a des limites. Nous essaierons
dans cette partie de déterminer les causes des limites de notre projet.
Enfin, un petit mode d’emploi ne serait pas de trop pour expliquer comment s’utilisent
toutes les procédures et les astuces à connaître pour le bon fonctionnement de la base.
A. La conception
1. Le modèle conceptuel de données
Le modèle conceptuel des données est un premier travail de réflexion sur la base. Il
faut en effet utiliser les données que l’on nous a données pour créer un modèle de données.
Dans notre cas, nous avons un sujet qui définit les possibilités de notre base.
Nous allons dans un premier temps établir des phrases clés qui vont nous servir à créer le
modèle.
Un produit peut être remboursable ou non.
Le type de remboursement est déterminé par la sécurité sociale.
Le prix d’un produit varie selon les périodes.
Le pourcentage de remboursement dépend de la classe pharmaceutique.
Une ordonnance est une liste de médicaments.
Une facture est aussi une liste de médicaments.
Un médecin délivre les ordonnances.

Un client reçoit les ordonnances de la part du médecin.
Une ordonnance permet d’établir des factures.
Une facture est envoyée au centre de gestion des remboursements.
Le centre de gestion des remboursements détermine les sommes remboursées par la sécurité
sociale et la mutuelle et la somme à payer par le patient.
Un client peut être inscrit à un centre de gestion et peut aussi cotiser à une mutuelle.
Ces phrases clés vont nous permettre d’établir les entités présentes dans la base de données.
Les entités sont :
- Fabricant
- Produit
- Secu
- Ordonnance
- Facture
- CentreGestion
- Medecin
- Client
- Mutuelle
Une fois les entités trouvées, il faut lister tous les champs des entités.
Un produit est caractérisé par son nom, sa classe pharmaceutique, le nom de son fabricant, la
date d’expiration, le pourcentage de remboursement, son numéro de lot et son prix.
Un fabricant est caractérisé par son nom, son taux qui permet de définir les promotions et les
augmentations et le prix de départ d’un produit.
Une ordonnance est caractérisée par sa date de consultation.
Un médecin est caractérisé par son nom, son adresse et sa spécialité.
Un client est caractérisé par son nom, son adresse et son numéro de téléphone.
Une facture est caractérisée par la somme à payer par le patient et la date d’achat.
La sécu n’a pas de caractérisation précise.
La mutuelle est caractérisée par son nom, et les cotisations des clients.
Enfin le centre de gestion est caractérisé par son nom et son emplacement.
Il faut maintenant établir les différentes relations entre les entités.
On sait qu’une ordonnance est une liste de médicaments avec prescriptions.
Une facture est une liste de produit avec la quantité.
Une ordonnance permet d’établir une ou plusieurs factures.
Un fabricant fournit les produits.
Sécurité sociale détermine le type de remboursement des produits.
La facture est envoyée au centre de gestion des remboursements.
Les médecins établissent les ordonnances et les donnes au client.
Les clients sont inscrits à un centre de gestion des remboursements.
Ils peuvent aussi cotiser pour la mutuelle.
Le centre de gestions des remboursements détermine la somme remboursée par la mutuelle et
la somme remboursée par la sécurité sociale.

Il faut ensuite identifier les cardinalités et le résultat est le modèle conceptuel de données (voir
annexe 1).
2. Le modèle logique de données relationnelles
Une fois le modèle conceptuel de données établit il faut le transposer en modèle
logique de données relationnelles. Dans notre cas les clés primaires sont soulignées alors que
les clés étrangères sont précédées de #.
Nous avons :
- Produit( id_produit, nom, classe, pourcentage, date_expiration, numerot_lot, prix)
- Fabricant( id_fabricant, nom, taux, #id_produit)
- Ordonnance( id_ordonnance, date)
- Facture(id_facture,somme, date_achat)
- PO( id_produit, id_ordonnance, prescriptions)
- PF(id_ produit, id_facture, quantité)
- FO(id_facture, id_ordonnance)
- Secu( id_secu, #id_produit, type_remboursement, #id_centre)
- CentreGestion( id_centre, nom, lieu, numerocentre)
- Mutuelle( id_mutuelle, #id_client, cotisation, #id_centre, nom)
- CF( id_centre, id_facture, somme_secu, somme_mutuelle)
- Client( id_client, nom, adresse, numero_tel)
- Medecin( id_medecin, nom, adresse, specialite)
- MCO( id_medecin, id_client, id_ordonnance)
- CC( id_centre, id_client, numero_identification)
3. Le modèle physique de données
Il faut maintenant établir le modèle physique de données.
Il y a différentes règles qui permettent de construire le modèle physique de données
relationnelles.
Relation binaire aux cardinalités (X,1) - (X,n), X=0 ou X=1.
La clé primaire de la table à la cardinalité (X,n) devient une clé étrangère dans la table à la
cardinalité (X,1).
Relation binaire aux cardinalités (X,n) - (X,n), X=0 ou X=1.
Il y a création d'une table supplémentaire ayant comme clé primaire une clé composée des
identifiants des 2 entités.
On dit que la clé primaire de la nouvelle table est la concaténation des clés primaires des deux
autres tables.
Si la relation est porteuse de donnée, celles ci deviennent des attributs pour la nouvelle table.
Relation binaire aux cardinalités (0,1) - (1,1).

La clé primaire de la table à la cardinalité (0,1) devient une clé étrangère dans la table à la
cardinalité (1,1).
Ces différentes règles nous permettent de construire le modèle visible dans l’annexe 2.
B. Création de tables et requêtes
Une fois le modèle bien conçu et construit, nous pouvons alors créer la base de donnée
avec oracle. Les entités vont devenir des tables. Nous comptons 15 tables à créer pour notre
base de données.
Prenons un exemple de table et décrivons le brièvement :
create table Fabricant(
id_fabricant number primary key not null,
id_produit number,
nom varchar2(20),
taux number,/*fait varier le prix selon les periodes*/
prix_depart number,
constraint cleprod foreign key (id_produit) references
Produit(id_produit)
);
Nous avons créé une table avec 5 attributs, 4 attributs qui sont des nombres et un
attribut qui est une chaîne de caractères qui pourra contenir entre 1 et 20 caractères.
Nous avons une clé primaire et une clé étrangère.
id_fabricant est la clé primaire, elle est unique (elle ne peut pas avoir deux valeurs
différentes), primary key est suivi de son nom et de son type pour indiquer que c’est une clé
primaire. L’option not null signifie qu’elle ne peut pas être nulle. A chaque fois que l’on
ajoutera des informations dans cette table, il faudra absolument mettre une valeur à cette clé
primaire. Nous avons choisi de ne mettre que les clés primaires en not null, de cette manière
toutes les clés primaires et étrangères ne seront pas nulles et les liens entre les tables peuvent
toujours se faire.
id_produit est une clé étrangère, à la fin de la table on précise que c’est une clé
étrangère et il faut aussi préciser la clé avec laquelle elle a un lien (table et attribut) à l’aide de
references.
Il faut répéter cette manipulation pour toutes les tables à créer.
Une fois les tables créées, on peut stocker des informations, choisir des informations à
consulter, et ceux à l’aide des requêtes SQL.
Pour insérer des données dans une table, on utilise insert into.
Par exemple :
insert into Fabricant( id_fabricant, id_produit, nom, taux, prix_depart)
values(1,2,’fabricant’,50,10) ;
Le fabricant ‘fabricant’ possède le produit numéro 2, son taux est de 50 et son prix de
départ est 10.

Les données sont modifiables et on peut les changer à l’aide de update.
Exemple :
Update Fabricant set prix_depart=25 where id_fabricant=1;
Cette commande va modifier le prix du produit que l’on avait inséré précédemment
dans la base.
On peut maintenant sélectionner des données dans les tables à l’aide des requêtes.
Exemple :
Select * from fabricant ;
Cette requête va afficher toutes les informations de la table.
Select id_produit from Fabricant where prix_depart=25;
Cette requête va afficher le numéro de tous les produis qui ont un prix de départ égal à
25.
C. Le langage PL/SQL
Nous avons dans ce projet utiliser le langage PL/SQL qui nous a permis de dynamiser
la base, de mettre à jour les informations automatiquement. Un attribut d’une table peut se
mettre à jour automatiquement quand un événement se passe. Sa valeur peut se calculer avec
les valeurs d’autres attributs dans d’autres tables que l’on peut récupérer grâce à ce langage.
1. Séquences et triggers
Les séquences permettent de générer des entiers uniques qui appartiennent à une suite
arithmétique. Nous avons utiliser des séquences pour auto incrémenter certaines de nos clés
primaires qui sont des entiers. Mais pour que des clés primaires soient incrémentées
automatiquement, il ne suffit pas de créer des séquences, ces séquences devront être
accompagnées de triggers (déclencheurs) qui au moment de l’insertion d’une valeur dans une
table remplira automatiquement la clé primaire de la valeur entière supérieure.
Nous avons d’abord créé quelques séquences qui s’incrémentent de 1 et qui démarre
de 1.
CREATE SEQUENCE seq_ord START WITH 1 INCREMENT BY 1;
CREATE SEQUENCE seq_client START WITH 1 INCREMENT BY 1;
CREATE SEQUENCE seq_medecin START WITH 1 INCREMENT BY 1;
CREATE SEQUENCE seq_facture START WITH 1 INCREMENT BY 1;
CREATE SEQUENCE seq_produit START WITH 1 INCREMENT BY 1;
CREATE SEQUENCE seq_mutuelle START WITH 1 INCREMENT BY 1;
CREATE SEQUENCE seq_secu START WITH 1 INCREMENT BY 1;
Les noms de ces séquences montrent pour quelles tables elles vont server.
Il y a une séquence pour la clé primaire de l’ordonnance, une pour celle de la table
client, de même pour les tables medecin, facture, produit, mutuelle et secu.
Pour connaître la valeur actuelle d’une séquence il faut faire la commande :
Select seq_client.currval from dual;