Le TP cherche à simuler le fonctionnement de ce groupe hospitalier en utilisant le principe des Bases de données réparties.

Transcription

1 Base de données Avancée (BDA) 2012/2013, Enseignant : M. Nakechbnadi, mail : nakech@free.fr Thème : Implémentation d une BD Répartie : Liens, vue matérialisé, snapshot, intégrité révérencielle et déclencheur A/ Présentation I. Base de données distribuées hôpitaux Le groupe Hospitalier d une grande ville de Normandie est le plus grand Etablissement de Santé non universitaire de France. Il possède près de 2000 lits pour satisfaire plus de hospitalisations et consultations par an. Le groupe est segmenté en huit sites répartis dans la région havraise afin de répondre à la demande des patients potentiels. Le TP cherche à simuler le fonctionnement de ce groupe hospitalier en utilisant le principe des Bases de données réparties. Fonctionnement général du groupement : Chaque hôpital gère ses propres services et son propre personnel. L'hôpital central, quant à lui, gère la liste des hôpitaux et la liste des patients des différents hôpitaux du groupement. Dans cette simulation, on a choisi de n'utiliser que deux sites : site 1 : l hôpital central, site 2 : un hôpital. D'autres sites représentant les autres hôpitaux pourront être ajoutés si l on le souhaite. II. Modèle conceptuel et règles de gestion Pour simuler la gestion de ce groupement d'hôpitaux, nous disposons donc de deux sites : le premier représentant l'hôpital central qui gère les données relatives à son personnel et la liste des patients de tous les autres sites affiliés. Le second site représente un hôpital qui, lui, administre que les données relatives à son personnel. La liste des hôpitaux est également centralisée à l'hôpital central avec la liste des patients pour pouvoir être accessible à tout moment et à partir de n'importe quel site du groupe. Cette centralisation est nécessaire car les établissements hospitaliers ne peuvent se permettent d'avoir des données erronées (non mises à jour) sous prétexte que ces données ne sont pas centralisées. En effet, un patient peut être transféré très rapidement d'un site à un autre à la suite d'une complication dans une opération, par exemple. Le personnel soignant de l'hôpital recevant le patient doit être mis au courant de toutes les informations nécessaires sur l'opération qui vient d'être effectuée dans l'autre hôpital. Donc, toutes les données relatives au patient sont centralisées pour ces raisons. Par contre, en ce qui concerne les données touchant le personnel soignant, administratif et technique, elles doivent être distribuées sur les différents sites. Effectivement, ces données n'ont pas de caractère critique, il n'y a pas de vie en jeu. De plus, la distribution, site à site, permet une plus grande rapidité de traitement et une meilleure gestion. Règles de gestion : Un hôpital ne peut être créé, mis à jour ou supprimé que par l'hôpital central. En effet, la liste des hôpitaux est centralisée. L'hôpital garde ainsi la "main" sur ce qui ce fait dans les autres hôpitaux. Chaque hôpital peut modifier ses tables de personnel, ils en ont de ce fait l'entière responsabilité. Les autres hôpitaux, y compris l'hôpital central, ne peuvent que lire les tables. Ils n'ont, en aucun cas, l'autorisation de les modifier. En revanche, les données centralisées relatives aux patients peuvent être modifiées par tous les sites pour les raisons décrites ci-dessus Principe : Chaque hôpital gère son propre personnel et ses propres services. L'hôpital central, quant à lui, gère la liste des patients des différents hôpitaux du groupement et la liste des hôpitaux. En effet, les patients ne sont pas obligés d'aller toujours dans le même hôpital car, généralement, les différents sites d un groupe hospitalier n exercent que certaines spécialités (la maternité, la chirurgie, les urgences, ). Il faut donc un organisme qui s'occupe de gérer la liste de tous les patients des hôpitaux. Ainsi, le patient, peut aller dans n'importe quel hôpital du groupement et sera toujours "connu" par un même numéro de dossier. 1

2 III. Modèle relationnel distribué Site 1 : hopital central Site 2 hopital IV. Accès physique aux bases de données Figure 1 : Modèle concepuel de la BDD hôpitaux La base de données du site 1 est implémenté sur le SGBD oraadm, tendis que la base de données du site 2 est implémenté sur le SGBD oraedu. B/ Travail à faire Exercice 1. Sur le site 1, créer et peupler les tables de la base de données "Hôpital Central" (voir annexe 1 ) Exercice 2. Sur le site 2, créer et peupler les tables de la base de données " Hôpital " (voir annexe 2) Exercice 3. Création des liens 3.1/ Créer un lien de la base de données du site 2 vers la base de données du site 1 : Create database link central connect to alain identified by elcaro using 'oraadm'; Ce lien crée une référence sur la base distante située sur le site 1. Il utilise différents paramètres de connexion : un nom d'utilisateur ("alain") et un mot de passe ("elcaro"). La création du lien peut se faire grâce à l'alias de base de 2

3 données "oraadm" Ce lien a pour fonction principale d'avoir un accès aux tables de la base distante du site 1. "alain" est un utilisateur oracle de la base du site 1, sa création peut se faire par la commande suivante : create user alain identified by elcaro; Les droits de connexion et de création de tables peuvent être donnés à alain par la commande suivante : grant connect, resource to alain; 3.2/ Utiliser le lien précédent pour insérer une ligne dans la table personne à partir du site / Créer un lien de la base de données du site 1 vers la base de données du site 2 : Create database link hopit connect to 'oraedu'; identified by mot_passe using Ce lien crée une référence sur la base distante située sur le site 2. Il utilise plusieurs paramètres de connexion : un nom d'utilisateur (" ") et un mot de passe ("mot_passe"). " " est un utilisateur oracle de la base du site 2 et qui a les droits d utiliser les tables de ce site. 3.4/ Utiliser le lien précédent pour insérer une ligne dans la table personnel à partir du site 1. Exercice 4. Création de synonymes. Ces synonymes ont pour intérêt de rendre l'utilisation des tables distantes complètement transparente comme si toute la base était centralisée. Ils permettent aussi une simplification d'écriture lors de l'utilisation d'une table distante. En effet, on est plus obligés d'utiliser l'écriture "nomtable@lien". La transparence est assurée en remplaçant les noms globaux d'objets par des noms logiques. 4.1/ Créer les synonymes permettant aux utilisateurs du site 2 d avoir un accès simplifié aux objets du site 1. Indications : create synonym Personne for Personne@central; create synonym Hopital for Hopital@central; create synonym Integre for Integre@central; create synonym Patient for Patient@central; create synonym Externe for Externe@central, create synonym Hospitalise for Hospitalise@central; 4.2/ Idem, créer les synonymes permettant aux utilisateurs du site 1 d avoir un accès simplifié aux objets du site 2. Indications : create synonym personnel for personnel@hopit; create synonym medecin create synonym infermiere create synonym rattache create synonym affectation create synonym sevice Tester les synonymes précédent avec au moins deux requêtes significatives avec jointure sur chaque site. Exemples : (sur le site 2) select * from personne; select nom, date_entrée from personne pe, patient pa where pe.numsecu = pa. numsecu; Exercice 5. Création des déclencheurs pour préserver l'intégrité des données inter-site 6.1 Réaliser un déclencheur supprimepersonne qui permet de vérifier avant de supprimer un enregistrement dans la table Personne, que le numéro numsecu (clef primaire de la table Personne) de 3

4 l'enregistrement concerné n'est référencé par aucune table distante (dans aucune table Personnel des bases représentant un hôpital). create or replace trigger supprimepersonne before delete on Personne for each row declare excep exception; numsecudistant number; begin numsecudistant:=0; -- compte le nombre de NumSecu dans la table distante select count(numsecu)into numsecudistant from where numsecu=:old.numsecu; if(numsecudistant!= 0) then raise excep; end if; exception when excep then raise_application_error(-20009,'suppression impossible! NumSecu référencé dans une table distante'); end 6.2 Réaliser un déclencheur supprimehopital : Ce déclencheur permet de vérifier, avant de supprimer un enregistrement dans la table Hopital, que le numéro numhopital (clef primaire de la table Hopital) de l'enregistrement concerné n'est référencé par la table distante Service. Ce déclencheur est très utile car il permet d'assurer la cohérence des données entre les différentes tables de l'application et de préserver l'intégrité des données. Instructions SQL : create or replace trigger supprimehopital before delete on Hopital for each row declare excep exception; numhopitaldistant number; begin numhopitaldistant:=0; -- compte le nombre de NumHopital dans la table distante select count(numhopital) into numhopitaldistant from service@hopit where numhopital=:old.numhopital; if(numhopitaldistant!= 0) then raise excep; end if; exception when excep then raise_application_error(-20009,'suppression impossible! NumHopital référencé dans une table distante'); end ; / 6.3 Réaliser un déclencheur TService : Ce déclencheur permet de vérifier, avant de supprimer un enregistrement dans la table Service, que le numéro numservice (clef primaire de la table Service) de l'enregistrement concerné n'est pas référencé par la table distante Integre. Aussi, ce trigger a pour objectif de vérifier, avant l'insertion ou la modification d'un enregistrement dans la table Service, que le numéro NumHopital existe bien dans la table distante Hopital. Pour réaliser cela, le trigger compte le nombre de tuples dans la table distante Hopital qui référencient le NumHopital concerné par l'insertion ou la modification d'un enregistrement dans la table locale Service. Si ce nombre est différent de 1, alors une exception est générée car l'utilisateur essaye d'insérer ou de modifier un tuple ayant une valeur de NumHopital inconnue. Ce déclencheur est d'une grande utilité car il permet d'assurer la cohérence des données entre les différentes tables de l'application et de préserver l'intégrité des données de l'application. Instructions SQL : create or replace trigger TService 4

5 before delete or update or insert on Service for each row declare excep exception; numservicedistant number; nbtuples number; begin numservicedistant:=0; nbtuples:=0; if deleting then -- compte le nombre de NumService dans la table distante select count(numservice) into numservicedistant from where numservice=:old.numservice; if(numservicedistant!= 0) then raise excep; end if; end if; if inserting or updating then -- compte le nombre de tuples distants correspondants select count(*) into nbtuples from where numhopital=:new.numhopital; if(nbtuples!= 1) then raise excep; end if; end if; exception when excep then raise_application_error(-20009,'violation de contrainte!'); end ; / 6.4 Réaliser un déclencheur inserepersonnel Ce trigger permet de vérifier, avant l'insertion ou la modification d'un enregistrement dans la table Personnel, que le numéro NumSecu existe bien dans la table distante Personne. Pour ce faire, le trigger compte le nombre de tuples dans la table distante Personne qui référencient le NumSecu concerné par l'insertion ou la modification d'un enregistrement dans la table locale Personnel. Si ce nombre n'est pas égal à 1, alors une exception est lancée car l'utilisateur tente d'insérer ou de modifier un tuple ayant une valeur de NumSecu inconnue. Le rôle de ce trigger est très important car il permet, comme tous les triggers précédents, d'assurer la cohérence des données entre les différentes tables de l'application. Instructions SQL : create or replace trigger inserepersonnel before insert or update on Personnel for each row declare excep exception; nbtuples number; begin nbtuples:=0; select count(*) into nbtuples from Personne@central where numsecu=:new.numsecu; if(nbtuples!= 1) then raise excep; end if; exception when excep then raise_application_error(-20009,'impossible, violation de contrainte'); end ; / 6.5 Réaliser un déclencheur insereintegre Ce déclencheur permet de vérifier, avant l'insertion ou la modification d'un tuple dans la table Integre, que le numéro NumService est bien présent dans la table distante Service. Pour ce faire, le trigger compte le nombre de tuples dans la table distante Service qui référencient le NumService concerné par l'insertion ou la modification d'un enregistrement dans la table locale Integre. Si ce nombre n'est pas égal à 1, alors une exception est lancée car l'utilisateur tente d'insérer ou de modifier un tuple ayant une valeur de NumService inconnue. Le rôle de ce déclencheur est très important car il permet, comme les triggers précédents, de préserver l'intégrité des données de l'application. create or replace trigger insereintegre before insert or update on Integre for each row... Exercice 6. Tester les déclencheurs 5

6 7.1/ Sur le site 2, représentant un hôpital. essaye d'insérer un membre du personnel qui n'est pas référencé dans la table Personne de la base distante de l'hôpital central.(sur le site 1) insert into Personnel values (4006, ' ', 1400, null, to_date('07/01/01', 'DD/MM/YY')); 7.2/ Interpreter le message d erreur. ERROR at line 1: ORA-20009: Impossible, violation de contrainte... Une erreur a bien été générée par le déclencheur InserePersonnel. 7.3/ Remplacer la requete précedent par une requête d'insertion bien écrite (avec un NumSecu correct) : insert into Personnel values (4006, ' ', 1400, null,, to_date('07/02/07', 'DD/MM/YY')); 7.4/ Sur le site 1, représentant un hôpital central. esaye de supprimer un hôpital qui est référencé dans la table Service de la base distante de l'hôpital du site 2. delete from Hopital where numhopital=1; Commenter? 7.5/ Remplacer la requête précédente par une requête de suppression correcte (l'hôpital numéro 2 ne contient plus de services) delete from Hopital where numhopital=2; 7.6/ Sur le site 2, représentant un hôpital. essaye d'insérer un nouveau service qui n'est pas référencé dans la table Hôpital de la base distante de l'hôpital central. 7.7/ Insérer maintenant un nouveau service valable. Exercice 7. Vues globales on suppose maintenant que l hôpital central possède un petit service hospitalier que a la même structure que le service du site / Sur le site 1, créer les tables nécessaires pour cette gestion supplémentaire et les peupler. 8.1/ Créer une vue vueemployes permettant d accéder aux employés de deux sites Cette vue fait l union de la nouvelle table personnel du site 1 et la table personnel du site 2. Elle permet d'afficher la totalité des informations concernant un membre du personnel d'un hôpital alors que les informations ne sont pas sur le même site. Utiliser la commande union 8.2/ Tester la vue précédente : select * from vueemployes Exercice 8. Requêtes multi sites 9.1/ Réaliser une requête permettant d affiche nom prénom des infirmières avec le nom de service et l hôpital d attachement. 9.1/ Réaliser une requête permettant d'afficher les noms, prénoms et numéros de Sécu des patients hospitalisés dans le service chirurgie de tous les hôpitaux. 9.2/ Réaliser une requête permettant d'afficher les noms, prénoms des médecins attachés au service chirurgie. 6

7 *9.3/ Compter le nombre de patients par service entre début 1998 et fin 2001 Exercice 9. Réplication des données avec les vues matérialisées 10.1/ Sur le site 1, effacer le synonyme personnel puis créer une vue matérialisée permettant d avoir une copie en local de la table distante personnel Indications : Drop sysnonym personnel ; create materialized view personnel refresh complete start with sysdate next sysdate + 1 as select * from personnel@hopit; 10.2/ Tester la replication précédente Indication Sur le site 1: select * from personnel ; Sur le site 2: select * from personnel ; Insert into personnel values(4010, ' ', 1200,null,to_date('20/02/07', Sur le site 1: select * from personnel ; Votre commentaire? 10.3/ Modifier le vue précédente pour que le rafraîchissement se fasse chaque minute Indications : DROP MATERIALIZED VIEW personnel; Puis remplaçant dans la vue personnel 1 par 1/(24*60) 10.4/ Refaire maintenant un teste similaire à 10.2 (attendre une minute puis select * from personnel ;) 10.5/ Sur le site 1 tester la vue vueemployes réaliser par la question 7.1 Remarquer qu avant personnel est un synonyme correspondant à un accès à distance de la table personnel du site 2. Maintenant personnel est table correspondant à une réplication (ou un copie dure) de la table personnel sur le site / Sur le site 1 réaliser une réplication de la table distante medecin et de la table infermiere. 10.7/ Sur site 2 réaliser réplication de la table personne. Quel est la fréquence de rafraîchissement? Chaque heure ou chaque jour ou une fois par semaine, justifier votre choix. Exercice 10. Réplication des données avec les SNAPSHOT Remplacer la vue matérialisée de la question 10.1 par un snapshot (appelé aussi cliché ou image). DROP MATERIALIZED VIEW personnel; create snapshot personnel refresh complete start with sysdate next sysdate + 1 as select * from personnel@hopit; Tester. 7

8 Annexe1 : Création des tables de "HopitalCentral" Script disponible sur Table Personne create table Personne ( numsecu char(15) primary key, -- numéro de sécurité sociale nom varchar2(20) not null, prenom varchar2(20) not null, adresse varchar2(100) not null, telephone number(10) ); - Table Patient create table Patient (numdossier number(10) primary key, -- numéro de dossier numsecu char(15) references Personne(numSecu), -- numéro de sécurité sociale nummutuelle number(10), -- numéro de mutuelle datecreation date not null -- date de création du dossier pour ce patient ); - Table Externe create table Externe (numadmission number(10) primary key, -- numéro d'admission numdossier number(10) references Patient(numDossier), dateadmission date not null -- date où le patient a été soigné en externe ); - Table Hospitalise create table Hospitalise (numhospitalisation number(10) primary key, numdossier number(10) references Patient(numDossier), dateentree date not null, -- date d'entrée du patient datesortie date -- date de sortie ); -- Table Hopital create table Hopital (numhopital number primary key, -- numéro de l'hôpital nomhopital varchar2(30), -- nom de l'hôpital adresse varchar2(100) -- adresse de l'hôpital); - Table Integre create table Integre (numhospitalisation number(10) references Hospitalise(numHospitalisation), numservice number(2), -- numéro de service distant type_conditionnement varchar2(3), -- type de conditionnement du patient prix number, -- coût de l'hospitalisation dateintegration date, -- date d'intégration du service primary key(numhospitalisation, numservice) ); Insert into Personne values( ' ', 'Brennetot','Alain','13 rue des nenuphars LANQUETOT', ) ; Insert into Personne values( ' ','Lefevre','Alexandre','184 rue liberation GAINNEVILLE', ) ; Insert into Personne values( ' ','Dupont','Ghislaine', '38 Cours de la republique 76600,LE HAVRE', ) ; Insert into Personne values( ' ','Durant','Therese','66 rue Coty LE HAVRE', ) ; Insert into Personne values( ' ','Martin','Paul','32 rue Lesueur LE HAVRE', ) ; Insert into Personne values( ' ','Mabuse','Raymond','15 rue du Bel Air HARFLEUR', ) ; Insert into Personne values( ' ','Deschamps','Marcel','Place de la mairie BOLBEC', ) ; Insert into Personne values( ' ','Marchand','Bernard', '147 rue Ernest Renan LE HAVRE', ) ; Insert into Personne values( ' ','Enstein','Frank','19 rue Bougainville LE HAVRE', ) ; Insert into Personne values( ' ','Bouchard','Renee','56 rue Delavigne LE HAVRE', ) ; Insert into patient values( , ' ', , to_date('30/09/98', Insert into patient values( , ' ', , to_date('15/10/99', Insert into patient values( , ' ', , to_date('04/02/01', Insert into externe values( , , to_date('07/01/99', Insert into hospitalise values( , , to_date('30/09/98', 'DD/MM/YY'), to_date('06/10/98', Insert into hospitalise values( , , to_date('17/12/98', 'DD/MM/YY'), to_date('15/01/99', Insert into hospitalise values( , , to_date('15/10/99', 'DD/MM/YY'), to_date('23/10/99', Insert into hospitalise values( , , to_date('04/02/01', 'DD/MM/YY'), to_date('12/02/01', Insert into hopital values(1, 'Hopital Flaubert', '55 rue Gustave Flaubert LE HAVRE') ; Insert into hopital values(2, 'Hopital Pierre Janet', '47 rue Tourneville LE HAVRE') ; Insert into hopital values(3, 'Hopital Monod', '29 Pierre Mendes France MONTIVILLIERS') ; Insert into integre values( , 10, 'AMB', 120, to_date('30/09/98', Insert into integre values( , 11, 'AMB', 75, to_date('01/10/98', Insert into integre values( , 10, 'AMB', 100, to_date('17/12/98', Insert into integre values( , 11, 'AMB', 115, to_date('04/02/01', 8

9 Annexe 2 : Création des tables de la base de données Hôpital du site 2: Script disponible sur drop table Affectation; drop table Rattache; drop table Service; drop table Administratif; drop table Infirmiere; drop table Medecin; drop table Personnel; create table Personnel (nummatricule number(4) primary key, -- numéro de matricule de l'employé numsecu char(15), salaire number not null, grade varchar2(10), dateembauche date not null ); create table Medecin (numagrement number(3) primary key, -- identifiant représentant son numéro d'agrément nummatricule number(4) references Personnel(numMatricule), -- numéro de matricule specialite varchar2(20) not null -- spécialité exercée par le médecin ); create table Infirmiere ( numinfirmiere number(3) primary key, nummatricule number(4) references Personnel(numMatricule), -- numéro de matricule typecontrat varchar2(20) not null ); create table Administratif ( numadministratif number(3) primary key, nummatricule number(4) references Personnel(numMatricule), poste varchar2(20) not null, -- poste occupé qualification varchar2(20) not null, typecontrat varchar2(20) not null ); create table Service ( numservice number(2) primary key, nomservice varchar2(20) not null, tel number(10), -- numéro de téléphone nblits number, -- nombre de lits dans le service numhopital number -- numéro de l'hôpital distant ); create table Rattache ( numagrement number(3) references Medecin(numAgrement), -- numéro d'agrément numservice number(2) references Service(numService), -- numéro de service primary key(numagrement, numservice) ); create table Affectation ( numinfirmiere number(3) references Infirmiere(numInfirmiere), numservice number(2) references Service(numService), primary key(numinfirmiere, numservice) ); Insert into personnel values(4000, ' ', 1200,null,to_date('01/01/01', Insert into personnel values(4001, ' ', 1200,null,to_date('02/01/01', Insert into personnel values(4002, ' ', 1200,null,to_date('03/01/01', Insert into personnel values(4003, ' ', 1200,null,to_date('04/01/01', Insert into personnel values(4004, ' ', 1700,null,to_date('05/01/01', Insert into personnel values(4005, ' ', 1700,null,to_date('06/01/01', Insert into medecin values(300, 4004, 'neuro-chirurgie') ; Insert into medecin values(301, 4005, 'chirurgie esthetique') ; Insert into infirmiere values( 310, 4003, 'CDI') ; Insert into infirmiere values( 311, 4002, 'CDD') ; Insert into service values(10,'chirurgie', ,50,1); Insert into service values(11,'reanimation', ,35,1); Insert into service values(12,'pediatrie', ,40,1); Insert into rattache values(300, 10) ; Insert into rattache values(301, 11) ; Insert into affectation values(310, 10); Insert into affectation values(311, 11); 9