NAGÎȚ Mădălina Elena [311128]
NAGÎȚ Mădălina Elena
Realizarea și strategia de implementare la nivel local a unei baze de date pentru boli greu de dagnosticat
PROIECT DE DIPLOMĂ
Specializarea:
INGINERIE MEDICALĂ
Brașov
2018
REZUMAT
Lucrarea de licență are titlul „Realizarea și strategia de implementare la nivel local a unei baze de date pentru boli greu de diagnosticat”, [anonimizat] ([anonimizat], unele nediagnosticate) și crearea unei conexiuni puternice între medicii specialiști.
Prima parte a [anonimizat]. Se vor prezenta informații despre Sistemele informatice în domeniul medical (este structurat în general pe baze de date mari care stochează date medicale), un exemplu de generare a [anonimizat]. [anonimizat] o scurtă descriere și obiectivele acestora. Obiective care sunt în strânsă legătura cu obiectivul pe care îl are această temă.
A doua partea a proiectului prezintă ce este o [anonimizat], utilizarea unui sistem de gestionare a bazelor de date care permite utilizatorilor sa creeze și să mențină o [anonimizat]. [anonimizat].
În a [anonimizat]. Această aplicație este tema centrală a lucrării, fiind manifestarea practică a ideii principale: interconectarea medicilor care se confruntă cu boli greu de diagnosticat. [anonimizat], [anonimizat], la finalul acestei părți a lucrării.
[anonimizat] a României în cazul bolilor rare nediagnosticate sau greu de diagnosticat.
Lucrarea este de interes și oferă oportunitatea dezvoltării în continuare a [anonimizat].
ABSTRACT
The bachelor thesis has the title "Developing a database with difficult to identify diseases and defining the local implementation strategy", [anonimizat] ([anonimizat], some undiagnosed) and to create a strong connection between specialist doctors.
[anonimizat]. Information on Medical Information Systems (generally structured on medical data stores) [anonimizat] a medical database that involves medical translation and its concept. [anonimizat]ses with a brief description and objectives. Objective care is closely related to the objective of this theme.
The second part of the project presents what a database is, its features, the use of a database management system that allows users to create and maintain a database, the SQL language that is considered a major success for relational databases in the commercial world and the threats to them. General information about databases that are used and needed in any field, daily.
The third part is the „IN” application and the rare diseases database behind the application. This application is the central theme of the paper, being the practical manifestation of the main idea: the interconnection of doctors who are facing difficult diseases to diagnose. The implementation strategy, from national to local level, is detailed by the steps to be followed so that doctors have access to the database at the end of this part of the paper.
I believe that I have achieved the research objectives originally proposed, related to the elaboration of the paper, contributing to the national need of Romania in case of rare diseases undiagnosed or difficult to diagnose.
The paper is of interest and offers the opportunity to further develop this idea, in line with the dynamics of the evolution of medical databases needed at national level.
CUPRINS
LISTĂ DE FIGURI
Fig 1.1 Ceas normal
Fig 1.2 Ceasul desenat de pacientă
Fig.1.3. Funcțiile bazei de date
Fig 1.4 Traseul bazei de date
Fig. 1.5. National Organisation for Rare Disorters
Fig. 1.6. CrowMed
Fig. 1.7. Orphanet
Fig. 1.8. European Union Committee of Experts on Rare Diseases
Fig. 1.9. Alianța Națională pentru Boli Rare – România
Fig. 1.10. Centrul de Informare pentru Boli Genetice Rare- Asociația PRADER WILLI din România
Fig. 1.11. Conferința Europlan de la Zalău
Fig. 2.1. Conceptul bazelor de date
Fig.2.2. Reprezentarea grafică a utilizării parametrilor de filtrare
Fig.2.3. Reprezentarea grafică a teoriei mulțimilor
Fig.2.4. Reprezentarea grafică a șablonului de proiectare LDA
Fig. 2.5. Medicina modernă
Fig.2.6. Arhitectura unui sistem bazat pe mediator
Fig.2.7. Flux de informații în Medicina Translațională
Fig. 2.8. World Health Organization
Fig. 2.9. Institute for Heath Metrics and Evaluation
Fig. 2.11. Institutul Național de Sănătate Publică
Fig. 2.10. Statistica în România- durata vieții (IHME)
Fig. 2.11. Institutul Național de Sănătate Publică
Fig. 2.12. Centrul Național de Statistică și Informatică în Sănătate Publică
Fig. 2.13. Casa Națională de Asigurări de Sănătate
Fig. 2.14. Baza de date PharmEc CabiNet
Fig. 2.15. Cititor de carduri de sănătate HID Omnikey 3121, v.2
Fig. 2.16. Prima fereastră după introducere card
Fig. 2.17. Fereastra Meniu eCard
Fig. 2.18. Listă consultații pacient
Fig. 2.19. Fereastra „Introducere Rețetă Nouă”
Fig. 3.1. Procesul de proiectare a bazei de date
Fig. 3.2. Partajarea datelor cu mai mulți utilizatori
Fig. 3.3. Ingineria Software-ului
Fig. 3.4. Exemplu- tabele
Fig. 3.5. Funcțiile majore pentru o bază de date
Fig. 3.6. Elemente SQL Server
Fig. 3.7 Scopul securității bazei de date
Fig. 3.8. Principiile securității bazei de date
Fig. 3.9. Elementele de securitate SQL
Fig. 3.10. Arhitectura client- server pe trei niveluri
Fig. 4.1. Schema relațională a tabelelor
Fig. 4.2. Pagină ”Log In”
Fig. 4.3. Meniu ”Solicitare utilizator
Fig. 4.4. ”Pagina principală”
Fig. 4.5. Meniu ”Căutare avansată”
Fig. 4.6. Pagină ”Rezultat căutare avansată sau normală”
Fig. 4.7. Meniu ”Introducere diagnostic”
Fig. 4.8. Meniu ”Administrare”
Fig. 4.9. Meniu ”Aprobare user”
Fig. 4.10. Meniu Aprobare diagnostic”
Fig. 4.11. Meniu ”Feedback/ Contact”
Fig. 4.12. Meniu ”Despre”
Fig. 5.1 Pașii de implementare a aplicației
1. INTRODUCERE
1.1. DE UNDE A PORNIT IDEEA?
Cine suntem?
Noi oamenii, cine suntem? De ce suntem aici? Ce este binele și răul? De ce există boli și suferință? De mică, am avut un sentiment de grijă și drag față de toți oamenii din jurul meu. Am căutat să le înțeleg nevoile și atunci când suferă să le fiu alături. Și am fost alături de oameni bolnavi și încercam să le diminuez suferința. Atât cea fizică cât și cea interioară.
Fiecare avem o lume interioară. O lume a gândurilor, a bucuriilor și a tristeților. O lume în care se manifestă sentimente plăcute dar și suferință. Iar boala, uneori, ne creează nuanțe de gri și negru. Astfel apar gândurile. Uneori gânduri care ne conduc către o stare de bine, alte ori care ne scad moralul. Nu înțelegem de ce, nu înțelegem de unde a venit boala, de ce noi, ce se va întâmpla?
În acest context al perspectivei mele asupra oamenilor, asupra vieții și asupra trăirilor interioare, în urma vizionării unui film, mi-a venit ideea. Ideea de a contribui la un mic și modest bine, pentru cei care se află în suferință și nu știu de unde vine această suferință.
Filmul se numește Brain on Fire (tr.eng. Creier în flăcări), realizat după un caz real. Acest film relatează povestea unei paciente tinere de 24 de ani care s-a confruntat cu una din miile de boli greu de diagnosticat. Și în cazul ei diagnosticele inițiale au fost greșite. Susannah C. avea o viață împlinită cu un loc de muncă stabil. Brusc a început să se simtă diferit, crezând că este de la oboseală nu a acordat atenție . Curând nu mai reușea să lucreze deoarece au apărut halucinațiile și devenise paranoică. Într-o zi a avut o criză asemănătoare celor pe care le au bolnavii de epilepsie, iar tânăra a devenit foarte agresivă cu cei din jur. Familia și-a dus fiica la medici iar aceștia au decis să o interneze într-un centru psihiatric, crezând că are o cădere nervoasă. Însă acest lucru s-a dovedit a fi greșit. Doctorul Souhel Najjar a intervenit în cazul ei și a rugat-o să deseneze un ceas. Pacienta a desenat ceasul din imaginea alăturată:
Fig. 1.1. Ceas normal [1] Fig. 1.2. Ceasul desenat de pacientă [2]
În urma desenului, doctorul și-a dat seama că indică o boală neurologică, deoarece tânăra desenase toate cifrele pe partea dreapta. După puțin timp, ea a fost diagnosticată cu encefalită anti-NMDA, o boală care se dezvoltă atunci când aticorpii produși de sistemul imun al organismului atacă creierul. Această boală afectează mai mult femeile (în proporție de 80%) și este de obicei asociată cu existența unei tumori care ajunge să se formeze din cauzele scrise mai sus. Dacă Susannah nu ar fi fost tratată corespunzător în conformitate cu diagnosticul real, ar fi intrat în comă și ar fi murit. După ce a petrecut o lună în spital, tânăra s-a recuperat complet datorită unui simplu desen și a unui medic bun.
Ideea este crearea unei baze de date, care să fie accesibiă și utilizată de medici, în vederea diagnosticării mai rapide a bolilor rare care sunt greu de identificat. Baza de date va avea două importante funcții:
introducerea unor informații de către medic, detaliate cu simptome, date exacte ale analizelor, analize speciale, rezultate RMN, tomograf etc., a unor boli rare cu care s-a confruntat medicul respectiv;
accesarea informațiilor bazei de date în cazul în care un medic întâmpină dificultăți în diagnosticare.
Fig.1.3. Funcțiile bazei de date
Securitatea datelor și acuratețea acestora
Fig 1.4. Traseul bazei de date
Medicii care introduc simptome ale unor boli rare nu vor introduce pacientul nominal ci fiecare diagnostic va primi o codificare automată. Fiecare nou diagnostic introdus va fi verificat de o comisie de medici numită Comisia de Acceptare (CA) care vor aproba publicarea diagnosticului în baza de date.
Traseul pentru accesarea informațiilor constă în parcurgerea unor întrebări cu raspunsuri exacte la care medicul este obligat să răspundă, apoi vor urma căutări deschise dupa anumite cuvinte cheie. Medicul va obține o listă cu mai multe cazuri (diagnostice) care pot fi consultate și de asemenea datele de contact ale medicului care a introdus boala respectivă în baza de date. Astfel este facilitată comunicarea între medici care nu se cunosc și probabilitatea de a diagnostica corect boala respectivă este mai mare.
1.2. EXPLICAREA ȘI IMPORTANȚA TEMEI
„Bolile sunt rare, dar pacienții cu boli rare sunt mulți.”
În contextul mondial în care trăim, cu poluare, mâncare fast food, stres la cote ridicate, de multe ori s-au tras semnale de alarmă referitoare la noi boli sau manifestarea diferită a bolilor cunoscute deja. Timpul prețios care poate fi folosit pentru tratament sau investigație se pierde prin interpretare greșită sau în părerile diferite de la un medic sau specialist la altul. [3]
1.2.1. BOLILE RARE
Ce este o boală rară?
“Bolile rare” sunt boli care afectează un număr mic de persoane și apar probleme foarte specifice legate de raritatea lor. În Europa, o boală este considerată a fi rară dacă afectează o persoană din 2000. O boală poate fi rară într-o regiune, dar comună în alta. Acesta este cazul talasemiei, o anemie de cauză genetică, rară în Europa de Nord, dar frecventă în regiunea Mediteraneană.
Câte boli rare există?
Până în prezent sunt aproximativ 6.000-7.000 boli rare care au fost descoperite și noi boli sunt descrise în literatura medicală în mod constant. Numărul bolilor rare depinde și de acuratețea definirii bolii. Până acum, în domeniul medical, o boală a fost definită ca alterare a stării de sănătate, care prezintă un model unic de simptome cu un singur tratament.
Care sunt caracteristicile și originile unei boli rare ?
Aproape toate bolile genetice sunt rare, dar nu toate bolile rare sunt genetice. Există boli infecțioase foarte rare, de exemplu, dar și boli autoimune și cancere rare. Până în prezent, cauza multor boli rare este încă necunoscută.
Bolile rare sunt boli serioase, frecvent cronice și progresive. Pentru multe boli rare, semnele pot fi observate la naștere sau în copilărie. Totuși, peste 50% din bolile rare apar la adult, așa cum se întâmplă în boala Huntington, Crohn, Charcot Marie Tooth, scleroza laterală amiotrofică, sarcomul Kaposi sau cancerul tiroidian. [3]
Care sunt consecințele medicale și sociale ale rarității acestor boli ?
Pentru mult timp, doctorii, cercetătorii și politicienii nu au fost avizați despre bolile rare și până de curând nu exista cercetare reală sau politică de sănătate publică privind aspectele legate de acest domeniu. Nu există tratament pentru majoritatea bolilor rare, dar tratamentul și îngrijirea medicală corespunzătoare pot îmbunătăți calitatea vieții celor afectați și să le prelungească durata vieții. Progrese impresionante s-au făcut pentru unele boli, ceea ce ne arată că nu trebuie să se continue eforturile în domeniul cercetării și solidarității sociale.
Toți cei afectați de aceste boli fac față unor dificultăți similare în ce privește căutarea diagnosticului, a informațiilor relevante și direcționarea către specialiști calificați. Cei afectați de boli rare sunt mai vulnerabili psihologic, social, economic și cultural. Aceste dificultăți pot fi depășite prin politici corespunzătoare. Datorită lipsei de suficientă cunoaștere medicală și științifică, mulți pacienți nu sunt diagnosticați. Boala lor rămâne neidentificată. Aceștia sunt oamenii care suferă cel mai mult din cauza dificultăților în ce privește primirea susținerii adecvate.
Ce progres se observă în diagnosticul și tratamentul bolilor rare ?
Sute de boli rare pot fi acum diagnosticate prin testarea unei probe biologice. Cunoașterea evoluției naturale a acestor boli este îmbunătățită de crearea registrelor pentru unele dintre ele. Cercetătorii muncesc din ce în ce mai mult în rețele pentru a împărtăși rezultatele cercetării lor și a avansa mai eficient în domeniul bolilor rare. [3]
1.2.2. CONTEXTUL MONDIAL, EUROPEAN ȘI NAȚIONAL
1.2.2.1. CONTEXTUL MONDIAL
La nivel mondial există o preocupare a bolilor rare și aceasta se manifestă prin diverse organizații, asociații, comitete de medici, portaluri și registre ale bolilor rare. De exemplu:
National Organisation for Rare Disorters- Statele Unite ale Americii
Fig. 1.5. National Organisation for Rare Disorters [4]
National Organisation for Rare Disorters este o organizație care se angajează să identifice, să trateze și să vindece tulburarile rare prin programe de educație, cercetare, sustinere și servicii. [4]
CrowMed
Fig. 1.6. CrowMed [5]
CrowMed este o platformă de îngrijire a sănătății în care sunt aproximativ 20.000 de medici și asistenți care oferă sugestii de diagnostic pacienților, contra-cost. Această platformă își propune să identifice bolile care nu au un diagnostic. [5]
1.2.2.2. CONTEXTUL EUROPEAN
Orphanet
Fig. 1.7. Orphanet [3]
Orphanet este un portal pentru informații privind bolile și medicamentele orfane, pentru toate tipurile de public. Scopul Orphanet-ului este de a ajuta îmbunătățirea diagnosticului, îngrijirii și tratamentului pacienților cu boli rare. [3]
European Union Committee of Experts on Rare Diseases
Fig. 1.8. European Union Committee of Experts on Rare Diseases [6]
Comitetul de experți al Uniunii Europene privind bolile rare a fost însărcinat cu sprijinirea Comisiei Europene în pregătirea și punerea în aplicare a activităților comunitare în domeniulbolilor rare, în cooperare și consultare cu organismele specializate din statele membre, autoritățile europene competente în domeniul cercetării și acțiunilor în domeniul sănătății publice și alte părți interesate relevante care acționează în domeniu. [6]
1.2.2.3. CONTEXTUL NAȚIONAL
Alianța Națională pentru Boli Rare – România
Fig. 1.9. Alianța Națională pentru Boli Rare – România [7]
Alianța Națională pentru Boli Rare – România, au ca obiectiv îmbunătățirea caității vieții persoanelor cu boli rare din România prin crearea și organizarea unor programe de informare privind abordarea bolilor rare. [7]
Centrul de Informare pentru Boli Genetice Rare – Asociația PRADER WILLI din România
Fig. 1.10. Centrul de Informare pentru Boli Genetice Rare – Asociația PRADER WILLI din România [8]
Centrul de Informare pentru Boli Genetice Rare – Asociația PRADER WILLI din România, au o bază de date cu boli cunoscute și boli genetice. Dacă boala nu este cunoscută se începe o investigație și o căutare de informații. Având în vedere că stabilirea unui diagnostic poate dura între 5-30 de ani, baza de date pe care am gândit-o poate interveni, facilitând accesul la informații camasate și structurate într-un singur loc. [8]
Conferința Europlan 2017
În anul 2017 a avut loc la Zalău, Conferința Europlan dedicată elaborarii politicilor naționale pentru bolile rare. Conferințele sau workshopurile naționale EUROPLAN sunt organizate în numeroase țări europene, pentru a promova elaborarea de planuri sau strategii naționale pentru boli rare care să răspundă nevoilor nesatisfăcute ale pacienților care suferă de o boală rară în Europa. [9]
Fig. 1.11. Conferința Europlan de la Zalău [9]
Concluziile redactate în Raportul Final al Conferinței Naționale Europlan în cadrul acțiunii comune UE RD- ACTION, Zalău 16-17 Noimebrie 2017, sunt următoarele:
Ministrul Sănătății, prin mesajul transmis la Conferința Europlan a subliniat că bolile rare rămân o prioritate pentru MS și că încurajează continuarea acreditării centrelor de expertiză și participarea lor la Rețelele Europene de Referință la viitorul call al Comisiei Europene în 2018.
Necesitatea înființării Registrului Național Pilot de Boli Rare prin realizarea unui consorțiu al centrelor de expertiză acreditate, adoptarea unui set minim de date comune care să se comunice în registrul național;
Inițierea unei strategii de colaborare pentru proiecte de cercetare în bolile rare, corelând planurile de cercetare ale centrelor de expertiză acreditate.
Identificarea de proiecte și colaborarea cu Ministerul Muncii pentru instruirea personalului din serviciile sociale la nivel local pe domeniul bolilor rare (ex. management de caz, managementul bolilor rare, pedagog de recuperare, asistentul personal al persoanei cu handicap grav, etc.), crearea de rețele de suport în comunitate pentru asigurarea managementului de caz și coordonarea îngrijirii pacienților; [9]
Participarea activă în grupul de lucru organizat la MMSSF pentru actualizarea criteriilor de încadrare în grad de handicap pentru pacienții cu "dizabilități rare";
Reprezentantul MMSSF a promis reactivarea acestui grup de lucru care a fost inițiat în guvernarea precedentă;
Inițierea de proiecte care încurajează angajarea în muncă a persoanelor afectate de boli rare, clarificarea situației atelierelor protejate și a unităților protejate, contracte cu timp flexibil de muncă, angajare asistată (coaching), adaptarea locurilor de muncă la nevoile persoanei cu boli rare;
Dezvoltarea de servicii respiro pentru pacienți și familii și crearea de case de tip familial pentru persoanele adulte cu boli rare.
În cadrul acestei conferințe s-au discutat anumite aspecte prinvind strategia națională de sănătate 2014-2020 și a planului de acțiuni în această perioadă. Principalele obiective pe care le poate îndeplinii această baza de date cu boli rare, obiective necesare, sunt:
înregistrarea bolilor rare la nivel național și realizarea registrelor de boli rare;
creșterea gradului de implicare a specialiștilor români în inițiativele europene și internaționae de schimb de informații și între specialiști și de cercetare;
Una dintre temele specifice discutate evidențiază necesitatea creerii unei rețele naționale care reiese din nevoia asigurării de servicii integrate și eficiente. Prin intermediul acestor rețele se va asigura îmbunătățirea capacităților de diagnostic (majoritatea bolilor rare fiind încă fără tratament, dificil de diagnosticat, unele nediagnosticate). Lipsa informațiilor despre boală și impactul asupra vieții, lipsa experților și a RESURSELOR, conexiunile care nu exisa între medici, sunt provocari care îngreunează viața pacienților și familiilor. [9]
Așadar, realizarea unei baze de date cu boli greu de identificat/ boli rare este una din SOLUȚIILE problemelor identificate și specificate în cadrul Conferinței Naționale Europlan de la Zalău, venind în întâmpinarea nevoilor naționale de dezvoltare în domeniul bolilor rare.
1.3. SCURT ISTORIC
Ființele umane au început să stocheze informații cu mult timp în urmă. În cele mai vechi timpuri, sisteme elaborate de baze de date au fost elaborate de birouri guvernamentale, biblioteci, spitale și organizații de afaceri, iar unele dintre principiile de bază ale acestor sisteme sunt încă folosite astăzi. [10]
Anii 1960: Baza de date computerizată a început în anii 1960, când utilizarea computerelor a devenit o opțiune mai rentabilă pentru organizațiile private. În acest deceniu, au existat două modele de date populare: un model de rețea numit CODASYL și un model ierarhic numit IMS. Un sistem de baze de date care sa dovedit a fi un succes comercial a fost sistemul SABER folosit de IBM pentru a ajuta compania americană să își gestioneze datele de rezervare.
1970 – 1972: E.F. Codd a publicat o lucrare importantă care propune utilizarea unui model de bază de date relațională, iar ideile sale au schimbat modul în care oamenii se gândeau la bazele de date. În modelul său, schema bazei de date sau organizarea logică este deconectată de la stocarea informațiilor fizice și aceasta a devenit principiul standard pentru sistemele de baze de date.
1970: Au fost create două prototipuri importante de baze de date relaționale între anii 1974 și 1977 și au fost Ingres, dezvoltat la UBC, și System R, creat la IBM San Jose. Ingres a folosit o limbă de interogare cunoscută sub numele de QUEL și a dus la crearea unor sisteme cum ar fi Ingres Corp, MS SQL Server, Sybase, PACE și Britton-Lee. Pe de altă parte, sistemul R a folosit limbajul de interogare SEQUEL și a contribuit la dezvoltarea SQL / DS, DB2, Allbase, Oracle și Non-Stop SQL. De asemenea, în acest deceniu, sistemul relațional de gestionare a bazelor de date, sau RDBMS, a devenit un termen recunoscut. [10]
1976: Un nou model de bază de date numit entitate-relație, sau ER, a fost propus de P. Chen în acest an. Acest model a făcut posibil ca designerii să se concentreze asupra aplicației de date, în locul structurii de tabelă logică.
1980: Limbajul de interogare structurat, sau SQL, a devenit limba standard de interogare.
Sistemele de baze de date relaționale au devenit un succes comercial, deoarece creșterea rapidă a vânzărilor de computere a stimulat piața de baze de date, ceea ce a dus la o scădere majoră a popularității modelelor de baze de date de rețea și ierarhice. DB2 a devenit produsul de bază de date pilot pentru IBM, precum și introducerea de PC-ul IBM a dus la unitățile de multe companii de baze de date noi și dezvoltarea de produse, cum ar fi PARADOX, RBASE 5000, RIM, Dbase III și IV, OS / 2 Database Manager, și Watcom SQL.
Începutul anilor 1990: După ce o industrie a bazei de date sa scuturat, majoritatea companiilor care au supraviețuit au vândut produse complexe de baze de date la prețuri ridicate. În acest timp, au fost lansate noi instrumente client pentru dezvoltarea aplicațiilor, printre acestea fiind programele Oracle Developer, PowerBuilder, VB și altele. Au fost dezvoltate și câteva instrumente pentru productivitatea personală, precum ODBC și Excel / Access. Prototipurile pentru sistemele de gestionare a bazelor de date Object, sau ODBMS, au fost create la începutul anilor 1990. [10]
Mijlocul anilor ‘90: Apariția internetului a dus la creșterea exponențială a industriei de baze de date. Utilizatorii medii de desktop au început să utilizeze sisteme baze de date client-server pentru a accesa sistemele informatice care conțin date moștenite.
Ultimii 90 de ani: Investițiile crescute în afaceri online au determinat o creștere a cererii pentru conectori de baze de date pe Internet, cum ar fi Front Page, Active Server Pages, Java Servelets, Dream Weaver, ColdFusion, Enterprise Java Beans și Oracle Developer 2000. Utilizarea cgi, gcc, MySQL, Apache și alte sisteme au adus soluții open source pe Internet. Odată cu utilizarea sporită a tehnologiei de la punctul de vânzare, procesarea tranzacțiilor online și procesarea analitică online au început să crească.
Anii 2000: Deși industria de Internet a cunoscut un declin la începutul anilor 2000, aplicațiile de baze de date continuă să crească. Au fost dezvoltate noi aplicații interactive pentru PDA-uri, tranzacții la punctul de vânzare și consolidarea vânzătorilor. În prezent, cele trei companii de baze de date din lumea occidentală sunt Microsoft, IBM și Oracle. [10]
2. BAZE DE DATE ÎN MEDICINĂ
Fig. 2.1. Conceptul bazelor de date
2.1. INTRODUCERE
Sistemele informatice în domeniul medical (SIM) se bazează pe baze de date mari care stochează date medicale. În afară de problemele specifice legate de proiectarea structurilor de date, aceste sisteme prezintă o provocare pentru dezvoltatori în ceea ce privește arhitectura de nivel extern al bazei de date, strâns legată de construirea interfeței cu utilizatorul. [11]
Aspectele care sunt abordate pe parcursul dezvoltării unui SIM sunt următoarele:
– Filtrarea – filtrarea datelor după diferite criterii;
– Ordonarea – sortarea datelor pentru a se potrivi nevoilor utilizatorului;
– Procesul de sincronizare – filtrarea subseturilor de date în funcție de o valoare curentă selectată;
– Proprietatea temporală – gestionarea datelor care au o valabilitate limitată în timp;
– Procesul de alocare – asocierea seturilor de date la o înregistrare dată în baza de date;
– Lista deschisă de atribute – gestionarea datelor care au asociate o listă de caracteristici ce evoluează în timp;
– Prelucrarea structurilor de date complexe medicale – arbori și arbori multipli;
– Procesul de raportare – extragerea de informații relevante pentru utilizator.
Abordarea se bazează mai mult pe vizualizări de date, construite pe partea de server și pe partea de aplicație client. Cu toate acestea este necesară completarea acestora cu un număr redus de proceduri stocate pentru a implementa funcționalitatea completă a sistemului. [11]
2.2. EXEMPLU DE GENERARE A UNEI BAZE DE DATE ÎN MEDICINĂ
În continuare se va discuta despre aspecte specifice legate de interfața cu utilizatorul a unei baze de date medicale, utilizând o abordare orientată spre date pentru nivelul extern (Proprietatea Temporală, Procesul de Alocare și Lista Deschisă de Atribute).
Tehnicile de dezvoltare de software care sunt propuse în acest exemplu sunt derivate dintr-un proiect real, care implică utilizarea datelor medicale ale pacienților investigați și tratați în cadrul unei secții de gastroenterologie. Cerințele pentru acest sistem au fost complexe și au avut o evoluție în timp pe parcursul proiectării și dezvoltării software-ului. Prin această abordarea se dorește nu doar rezolvarea unor probleme curente, ci dezvoltarea unei soluții pentru o întreagă categorie de probleme similare. Astfel, folosind concepte teoretice găsite în literatura de specialitate, s-a identificat problemele menționate mai sus și s-a dezvoltat o serie de soluții care implică șabloane de proiectare de baze de date, soluții de arhitectură a aplicațiilor și module tip pentru construirea interfeței utilizator.
Arhitectura sistemului este una de tip client-server. S-a folosit un sistem relațional de gestionare de baze de date (SGBD) pe partea de server. Pentru partea de client s-a folosit un mediu de dezvoltare de software, care oferă facilități de programare orientată spre obiecte, dar care dispune, de asemenea, de propriul motor de baze de date relaționale, permițând astfel utilizarea de vederi de date pe partea de client. [11]
Modelarea Timpului – Proprietatea Temporală
Timpul este o dimensiune omniprezentă care influențează toate procesele din lumea noastră. Aceasta include și evoluția datelor medicale, chiar dacă este vorba de datele clinice sau cele legate de cercetare. Acestea fiind spuse, o cerință de bază a unui SIM va fi întotdeauna capacitatea de a înregistra datele cronologice sau evoluția datelor în timp. S-a implementat un astfel de mecanism într-o bază de date prin utilizarea unei ștampile duble de timp, care include o dată de început și o dată de sfârșit. Acest lucru ne permite modelarea unei intervale de timp, mai degrabă decât doar puncte singulare în timp, cum ar fi cazul atunci când se utilizează o ștampilă simplă de timp. Când sunt necesare momente punctuale de timp, intervalul va fi îngustat până la un punct, prin înregistrarea aceleiași date și ore la ambele capete ale acestuia. Această abordare oferă un model complet de timp, dar necesită o putere de procesare mai mare pentru interogarea bazei de date. Fiecare interogare care accesează date temporale trebuie să fie filtrată folosind un interval de timp dat sau predefinit. Pentru a nu supraîncărca interfața cu utilizatorul cu controale de filtrare specifice, s-a implementat un tabel special în baza de date care conține astfel de intervale de timp pentru fiecare utilizator.
Așa cum s-a ilustrat în Figura 2.2. acești parametri de filtrare pentru intervalele de timp sunt apoi utilizati într-un nivel intermediar de vederi, stocat pe server. Programatorii care implementează diferite părți ale interfeței vor folosi aceste vederi în interogări în locul tabelelor de bază. În acest fel, în multe cazuri, dezvoltatorii nu mai trebuie să țțină cont de faptul că datele interogate au o componentă temporală. Această abordare s-a dovedit a crește eficiența de dezvoltare în mod semnificativ. [11]
Fig. 2.2. Reprezentarea grafică a utilizării parametrilor de filtrare [11]
Modelarea Submulțimilor – Procesul de Alocare
Procese ca atribuirea unui element la un grup sau o categorie sunt adesea regăsite ca o cerință la nivel de interfață utilizator a SIM. În general, utilizatorul va atribui un număr de elemente dintr-un set la un anumit grup sau categorie. La rândul său, grupul sau categoria este reprezentat de obicei de o înregistrare într-un tabel, sau un element într-un al doilea set. Se poate observa la acest proces punctul de vedere al teoriei mulțimilor, adică asocierea unui număr de elemente ale mulțimii A (o submulțime a lui A) cu un singur element al mulțimii B.
Utilizatorul va naviga de obicei prin elementele mulțimii B și fiecăruia îi va aloca o submulțime de elemente ale lui A. În conitnuare mulțimea B se va numi mulțimea elementelor „părinte”. O submulțime a lui A, deja alocată unui părinte dat va constitui lista elementelor „alocate” iar restul mulțimii A va reprezenta elemente care pot fi în mod potențial alocate, sau "elemente candidate". [11]
Fig.2.3. Reprezentarea grafică a teoriei mulțimilor [11]
În cadrul Interfeței Grafice Utilizator (IGU), s-a reprezentat setul părinte folosind un ecran care oferă o funcționalitate completă pentru a crea, interoga, actualiza și respectiv șterge înregistrări. Aceasta conține un set de date are se va numi “vedere Părinte”. Alocarea va avea loc folosind un al doilea ecran sincronizat cu primul. Aici sunt prezentate cele două submulțimi ale lui A, elementele deja alocate și elementele candidate, împreună cu butoanele funcționale pentru alocare/dealocare (Figura 2.3). Cele două submulțimi ale lui A sunt implementate cu ajutorul a două vederi speciale construite în nivelul extern al bazei de date.
Vederea elementelor alocate
Această vedere selectează înregistrările din tabelul A, care sunt deja alocate la înregistrarea curentă din B. Caracteristica cea mai importantă a acestei vederi este faptul că aceasta este filtrată în funcție de înregistrarea curentă a vederii părinte, folosind o cheie din tabelul părinte.
Vederea elementelor candidate
Această vedere trebuie să identifice lista elementelor candidate în conformitate cu înregistrarea curentă din vederea părinte. Va trebui deci să returneze un subset al lui A eliminând elementele deja alocate din întregul set. Implementarea unei astfel de vederi cu ajutorul unei interogări SQL presupune utilizarea unei clauze NOT IN, care poate crea probleme de performanță. În cazul în care tabelul care reprezintă mulțimea A conține un volum mare de date, mai multe opțiuni de filtrare pot fi implementate. Acestea vor fi accesibile prin intermediul IGU folosind controale special concepute. [11]
Lista deschisă de atribute
Una dintre provocările cu care se confruntă proiectantul bazei de date atunci când construiește un SIM care va fi folosit în cercetarea medicală este faptul că nu toate cerințele pot fi formulate în prima fază. Noi cerințe vor fi formulate pe măsură ce sistemul este utilizat și multe dintre acestea vor viza structura bazei de date. În scopul de a preveni reproiectarea constantă a bazei de date ca urmare a acestui proces, s-a folosit un șablon de proiectare care modelează extensional unele dintre atributele unei entități în loc ca acestea să fie modelate intensional.
S-a implementat acest lucru prin intermediul unui tabel special, care stochează atributele ca și înregistrări, nu ca și coloane. Acest tabel poate fi apoi legat cu un alt tabel care reprezintă o entitate prin intermediul unei relații de tip m la n (care poate stoca și valorile atributelor dacă este necesar). S-a numit acest șablon de proiectare “Lista Deschisă de Atribute” (LDA). [11]
Fig. 2.4. Reprezentarea grafică a șablonului de proiectare LDA [11]
O problemă specifică întâlnită la acest șablon de proiectare a fost utilizarea pe scară largă a legăturilor de tip „outer-join” atunci când s-a convertit aceste atribute stocate ca și rânduri în coloane în cadrul diferitelor vederi (Figura 2.4). Aceste legături sunt impuse de o convenție pe care s-a stabilit, prin care fiecare element al unei entități poate avea zero sau mai multe atribute înregistrate în LDA. Acest lucru oferă un mare grad de flexibilitate, dar poate avea un impact negativ asupra performanței. [11]
Această abordare centralizează mentenanța părților sensibile ale bazei de date, îmbunătățind astfel consistența și eficiența în dezvoltare. Însă, pentru baze de date mari, pot apărea unele probleme de performanță ca urmare a prelucrării suplimentare necesare pentru interogarea nivelului de bază al vederilor. [11]
2.3 INTEGRAREA INFORMAȚIILOR ÎN MEDICINA TRANSLAȚIONALĂ
Fig. 2.5. Medicina modernă [12]
Medicina translațională este un proces în care descoperirile științifice sunt transferate din cercetarea de bază în cercetarea clinică și apoi rezultatele studiilor clinice sunt aplicate în practică pentru îmbunătățirea stării de sănătate. [13]
Componentele esențiale ale cercetării din medicina translațională sunt:
accesul la informații;
analiza de date și
integrarea cunoștințelor.
2.3.1. CONCEPTUL MEDICINEI TRANSLAȚIONALE
Medicina translațională reprezintă un domeniu de cercetare multidisciplinar în care se utilizează atât date publice (ghiduri medicale, literatură științifică, baze de date biomedicale), cât și date protejate (date private de la pacienți, date proprietare de la companii farmaceutice și de publicare).
Oamenii de știință și medicii trebuie să fie capabili să integreze datele obținute cu alte date disponibile, să combine informații de la mai multe surse și propriile rezultatele cu cunoștințe anterioare. Bazându-se pe rezultatele astfel obținute pentru fiecare pacient în medicina translațională, medicina personalizată propune îmbunătățirea diagnozei și tratamentului fiecărui pacient în funcție de caracteristice individuale ale acestuia. [13]
Cantitatea enormă de date care rezultă din progresul științelor biomedicale și dezvoltarea societății informaționale, care are drept scop informatizarea celor mai importante aspecte ale vieții, în special a celor de sănătate, conduce la utilizarea ontologiilor în sistemele de sănătate și în cercetările biologice.
Un alt aspect de care trebuie ținut cont este integrarea informației din punctul de vedere al structurii datelor (de exemplu: formatul în care datele au fost stocate, limbajul folosit, etc.).
Medicina personalizată propune îmbunătățirea procesului de diagnoză și tratament, prin folosirea rezultatelor medicinii translaționale și a unor metode de tratament și medicamente specifice nevoilor fiecărui pacient. Astfel, se dorește eliminarea abordării în care un anumit tratament sau medicament se aplică pe scară largă tuturor pacienților, fără a se ține cont de istoricul medical sau de specificul fiecăruia.
Esențială pentru realizarea medicinei personalizate este dezvoltarea sistemelor de informare capabile să furnizeze informații exacte și în timp util cu privire la relațiile potențial complexe între pacienți, medicamente și opțiuni terapeutice adaptate. [13]
2.3.2. SURSE DE DATE, STRUCTURI DE DATE MEDICALE
În legătura cu Sistemul Informatic Medical, Organizația Mondială a Sănătății propune combinarea datelor obținute din fișele electronice ale pacienților cu datele de monitorizare de la dispozitivele medicale, de la sistemele de tratament, cu rezultatele laboratoarelor automatizate, arhivele de imagini medicale, informația financiară și mijloacele moderne de schimb de informații (poșta electronică, Internet, videoconferințe) etc.
2.3.3. STANDARDE DISPONIBILE
Standardizarea în domeniul medical devine tot mai remarcabilă datorită utilizării frecvente a fișei electronice a pacientului. Standardele facilitează comunicarea automată între diverse sisteme, furnizează informații utile în practica medicală. [13]
În Europa, organismul recunoscut în domeniul standardelor pentru informatica medicală este CEN (Comité Européen de Normalisation – Comitetul European de Standardizare). Acesta are competența și responsabilitatea organizării, coordonării și monitorizării activității de dezvoltare a standardelor în domeniul informaticii medicale, precum și a promulgării acestor standarde.
Multe state europene, inclusiv România, s-au orientat către aceste standarde, majoritatea de origine nord americană, reprezentative fiind HL7 pentru mesajele medicale și DICOM (Digital Imaging and Communication in Medicine) pentru imagistica medicală.
2.3.4. INTEGRAREA SURSELOR DE INFORMAȚII
Stabilirea unor depozite de date nu este întotdeauna o soluție potrivită. De exemplu, datele de dimensiuni enorme, fiind obținute din proiectele de cercetare în domeniul genomului uman, nu sunt transferate cu ușurință. [13]
Astfel, în loc de colectarea și stocarea datelor într-un depozit centralizat, o abordare alternativă este lăsarea datelor la sursele de date originale și combinarea lor în mod dinamic prin interogări rezolvate de un mediator.
În procesul de integrare a datelor, un sistem bazat pe mediator realizează traducerea dinamică a interogărilor utilizatorului între schema unei componente mediator și schemele surselor de date. Un astfel de sistem este ilustrat în Figura 2.6, în care wrapper-ul este un set de programe care accesează sursele de date și asigură vizualizarea datelor într-o schemă de date uniformă. [13]
Fig. 2.6. Arhitectura unui sistem bazat pe mediator [13]
Fluxul de informații asociat examinării unui pacient, prin care, pornind de la probele recoltate de la pacient, se realizează teste de genomică. Acestea sunt utilizate împreună cu observațiile clinice și cu arhivele de date integrate, pentru realizarea unei interpretări corecte a analizelor precum este prezentat în Figura 2.7. [13]
Fig. 2.7. Flux de informații în Medicina Translațională [13]
2.4. EXEMPLE DE BAZE DE DATE UTILIZATE LA NIVEL MONDIAL, NAȚIONAL ȘI LOCAL
2.4.1. WORLD HEALTH ORGANIZATION
Fig. 2.8. World Health Organization [14]
Scurtă descriere
WHO a început atunci când Constituția noastră a intrat în vigoare la 7 aprilie 1948 – o zi pe care o sărbătorim în fiecare an ca Ziua Mondială a Sănătății. Acum aunt peste 7000 de persoane din mai mult de 150 de țări care lucrează în 150 oficii, în 6 birouri regionale și la sediul din Geneva.
World Health Organization este autoritatea de coordonare a sănătății internaționale în cadrul sistemului Organizației Națiunilor Unite.
Se face acest lucru prin:
asigurarea leadershipului în chestiuni critice pentru sănătate și angajarea în parteneriate în care sunt necesare acțiuni comune;
modelarea agendei de cercetare și stimularea generării, traducerii și difuzării de cunoștințe valoroase;
stabilirea de norme și standarde și promovarea și monitorizarea implementării acestora;
articularea opțiunilor de politică etice și bazate pe dovezi;
furnizarea de suport tehnic, schimbarea catalizatoarelor și construirea unei capacități instituționale durabile; [14]
monitorizarea situației de sănătate și evaluarea tendințelor în materie de sănătate.
Prioritatea WHO în domeniul sistemelor de sănătate se îndreaptă către o acoperire universală a sănătății. WHO lucrează împreună cu factorii de decizie politică, partenerii globali în domeniul sănătății, societatea civilă, mediul academic și sectorul privat, pentru a sprijini țările să dezvolte, să pună în aplicare și să monitorizeze planurile naționale solide de sănătate. În plus, OMS susține țările să asigure disponibilitatea unor servicii de sănătate centralizate echitabile la un preț accesibil; facilitarea accesului la tehnologii sanitare accesibile, sigure și eficiente; și să consolideze sistemele de informare în domeniul sănătății și elaborarea politicilor bazate pe dovezi. [14]
2.4.2. INSTITUTE FOR HEATH METRICS AND EVALUATION
Fig. 2.9. Institute for Heath Metrics and Evaluation [15]
Scurtă descriere
The Institute for Health Metrics and Evaluation (Institutul de Metrologie și Evaluare a Sănătății- IHME) este un centru independent de cercetare a sănătății populației din cadrul UW Medicine, parte a Universității din Washington, care oferă o evaluare riguroasă și comparabilă a celor mai importante probleme de sănătate din lume și evaluează strategiile utilizate pentru a le aborda.
IHME aspiră să pună la dispoziția lumii informații de înaltă calitate privind sănătatea populației, determinanții acesteia și performanța sistemelor de sănătate. Se caută să se realizeze acest lucru în mod direct, prin catalizarea activității altora și prin formarea cercetătorilor.
Misiunea instituției este de a îmbunătăți sănătatea populațiilor lumii oferind cele mai bune informații privind sănătatea populației. [15]
Această bază de date ne pune la dispoziție statistici și rezultatele diferitelor analize la nivel global. Selectând țara noastră, România, s-a afișat o serie de rezultate cu starea națiunii pe planul sănătății. În imaginea de mai jos observăm numărul populației, PIB-ul pe cap de locuitor, rata fertilității, nivelul educațional (ani), în anul 2016. [15]
Primul grafic reprezintă “Cât timp trăiesc oamenii?”
Rezultatul:
Fig. 2.10. Statistica în România- durata vieții (IHME) [15]
2.4.3. INSTITUTUL NAȚIONAL DE SĂNĂTATE PUBLICĂ
Fig. 2.11. Institutul Național de Sănătate Publică [16]
Scurtă descriere
Institutul are ca scop:
prevenirea, supravegherea și controlul bolilor transmisibile și netransmisibile;
monitorizarea stării de sănătate;
promovarea sănătății și educația pentru sănătate;
evaluarea sănătății ocupaționale;
monitorizarea sănătății în relație cu mediul;
elaborarea reglementărilor în domeniul sănătății publice;
asigurarea managementului sănătății publice;
dezvoltarea serviciilor de sănătate publică specifice. [16]
Pentru îndeplinirea scopurilor prevăzute mai sus, Institutul exercită următoarele atribuții generale:
asigură îndrumarea tehnică și metodologică a rețelei de sănătate publică, în funcție de domeniul de competență;
participă la elaborarea strategiilor și politicilor din domeniul de competență;
supraveghează starea de sănătate a populației, bolile transmisibile și netransmisibile, pentru identificarea problemelor de sănătate comunitară;
asigură existența unui sistem informațional și informatic integrat pentru managementul sănătății publice, ș.a.m.d. [16]
Fig. 2.12. Centrul Național de Statistică și Informatică în Sănătate Publică [16]
2.4.4. CASA NAȚIONALĂ DE ASIGURĂRI DE SĂNĂTATE
Fig. 2.13. Casa Națională de Asigurări de Sănătate [17]
Scurtă descriere
Casa Națională de Asigurări de Sănătate (CNAS) este instituție publică, autonomă, de interes național, cu personalitate juridică, al cărei principal obiect de activitate îl reprezintă asigurarea funcționării unitare și coordonate a sistemului asigurărilor sociale de sănătate din România. [17]
CNAS are misiunea de a realiza un sistem de asigurări sociale de sănătate modern și eficient, pus permanent în slujba interesului public și a asiguratului, care are rolul de a îmbunătăți starea de sănătate a populației.
CNAS funcționează pe baza Statutului propriu și are următoarele obligații:
• să asigure logistica funcționării unitare și coordonate a sistemului asigurărilor sociale de sănătate;
• să urmărească colectarea și folosirea cu eficiență a fondului;
• să folosească mijloace adecvate de mediatizare pentru reprezentarea, informarea și susținerea intereselor asiguraților pe care îi reprezintă;
• să acopere nevoile de servicii de sănătate ale persoanelor, în limita fondurilor disponibile. [17]
2.4.5. CMI DR. TABĂCILĂ POMPILIA ILIANA – MEDICINA MUNCII ȘI MEDICINA DE FAMILIE
În cursul cercetării am ales să merg la cabinetul medicului meu de familie pentru a mă informa despre baza de date pe care aceasta o folosește. Baza de data utilizată este privată și se numește PharmEc CabiNet. Chiar daca este o bază de date privată, ea este conectată cu baza de date a CNAS-ului.
Fig. 2.14. Baza de date PharmEc CabiNet
Cardul național de asigurări de sănătate este un card electronic care se folosește doar pe teritoriul României și oferă informații minime, cum ar fi: numele, prenumele, codul numeric personal al asiguratului, codul unic de identificare în sistem și numărul de identificare al cardului național.
În următoarele poze sunt indentificați pașii urmați de medic din momentul în care cardul este introdus în cititorul de carduri se sănătate până la afișarea infomațiilor din baza de date, pe care le dorește medicul sa le cunoască.
Așadar, introducerea cardului se face cu ajutorul unui dispozitiv de citire a cardurilor de sănătate. În poza atașată se poate observa un model HID Omnikey 3121, v.2.
Fig. 2.15. Cititor de carduri de sănătate
HID Omnikey 3121, v.2
După introducerea cardului imediat se afișează o fereastră cu un singur câmp obligatoriu care cere introducerea PIN-ului asiguratului.
Fig. 2.16. Prima fereastră după introducere card
Următoarea fereastră care apare reprezintă Meniu eCard- ADMIN, arată starea cardului inserat (activ/inactiv), autentificare, citire date eCard, schimbare PIN, resetare PIN, reinițializare cititor și ultimul buton de închidere.
Fig. 2.17. Fereastra Meniu eCard
Se vor afișa consultațiile afectuate în cabinetul respectiv, datele pacientului, diagnostice, data consultației, medicamente, simptome, observații și numele medicului.
Fig. 2.18. Listă consultații pacient
Pentru a efectua o rețetă se va da click dreapta pe numele pacientului iar apoi click stânga „rețetă nouă pentru acest pacient” și va apărea o fereastră cu date despre pacient și câmpuri care trebuie să fie bifate sau nu: numele – prenumele pacientului, data prescrierii, motiv gratuitate, gravitate rețetă, număr registru, diagnostic, denumire medicament, ambalaj, pre, producător, cantitate etc. Selectare butonul de salvare și tipărire, salvare sau renunțare.
Fig. 2.19. Fereastra „Introducere Rețetă Nouă”
3. BAZE DE DATE
3.1. INTRODUCERE ÎN BAZE DE DATE
3.1.1. INTRODUCERE
Bazele de date și sistemele de baze de date au devenit o componentă esențială a vieții de zi cu zi în societatea moderna. În cursul unei zile, majoritatea dintre noi întâlnesc mai multe activități care implică o anumită interacțiune cu o bază de date. De exemplu, dacă mergem la bancă pentru a depune sau retrage fonduri, dacă facem rezervare la un hotel sau la o companie aeriană, dacă accesăm un catalog computerizat de bibliotecă pentru a căuta un element bibliografic sau dacă comandăm un abonament la reviste de la un editor, sunt șanse ca activitățile noastre să implice accesarea unei baze de date. Chiar și achiziționarea de produse de la un supermarket în zilele noastre implică în multe cazuri o actualizarea automată a bazei de date care păstrează inventarul articolelor din supermarket. [18]
Interacțiunile de mai sus sunt exemple a ceea ce putem numi aplicații tradiționale de baze de date, unde majoritatea informațiilor stocate și accesate sunt fie textuale, fie numerice. În ultimii câtiva ani, progresele tehnologice au condus la aplicații noi de sisteme de baze de date. Bazele de date multimedia pot stoca acum imagini, clipuri video și mesaje audio. Sistemele informatice geografice (SIG) pot stoca și analiza hărți, date meteo și imagini prin satelit. Depozitele de date și sistemele de procesare analitică on-line (OLAP) sunt utilizate în multe companii in extragerea și analizarea informațiilor utile din bazele de date foarte largi, pentru luarea deciziilor. Tehnologia bazelor de date active este utilizată în controlul proceselor industriale și de fabricație. Tehnicile de căutare in baze de date sunt aplicate pe World Wide Web pentru a îmbunătăți căutarea informațiilor necesare utilizatorilor care navighează prin Internet.
Pentru a înțelege fundamentele tehnologiei bazelor de date, trebuie să pornim de la principiile de bază ale aplicațiilor tradiționale de baze de date. In continuarea acestui capitol definim ce este o bază de date și vom da definiții ale altor termeni de bază.
Bazele de date și tehnologia bazei de date au un impact major asupra utilizării în creștere a computerelor. Este corect să se spună că bazele de date joacă un rol critic în aproape toate domeniile în care sunt utilizate computerele, inclusiv afaceri, inginerie, medicină, drept, educație și știința bibliotecii. Termenul “baza de date” este utilizat în mod frecvent, încât trebuie să începem prin definirea unei baze de date. Definiția următoare este una generala: [18]
O bază de date este o colecție de date conexe. Prin date, se înțelege fapte cunoscute care pot fi înregistrate și care au semnificație implicită. De exemplu, se ia în considerare numele, numerele de telefon și adresele oamenilor pe care îi cunoștem. Este posibil să fi înregistrat aceste date într-o agendă indexată, sau poate că le avem stocate pe un stick USB, folosind un computer personal și software cum ar fi DBASE IV sau V, Microsoft ACCESS sau EXCEL. Aceasta este o colecție de date conexe cu un înțeles implicit și, prin urmare, este o Bază de date. [18]
Definiția anterioară a bazei de date este destul de generală; de exemplu, se poate lua în considerare colectarea cuvintele care alcătuiesc această pagină de text să fie date înrudite și, prin urmare, să constituie o bază de date. Însă utilizarea în mod obișnuit a termenului de bază de date este de obicei mai restrânsă. O bază de date are următoarele proprietăți implicite:
O bază de date este proiectată, construită și populată cu date pentru un anumit scop. Are destinat un grup de utilizatori și unele aplicații preconcepute în care acești utilizatori sunt interesati.
O bază de date poate fi de orice dimensiune și de o complexitate variată. De exemplu, lista de nume și adrese la care se face referire mai devreme, poate fi alcătuită doar din câteva sute de înregistrări, fiecare având o structură simplă. Pe de altă parte catalogul de cărți al unei biblioteci mari poate conține o jumătate de milion de cărți stocate sub diferite categorii – după numele de familie al autorului primar, după subiect, după titlu de carte – cu fiecare categorie organizată în ordinea alfabetică. O bază de date cu o dimensiune și complexitate chiar mai mare este baza de date a Casei Nationale de Asigurari de Sanatate ce contine toate persoanele asigurate. Această cantitate imensă de informații trebuie să fie organizată și gestionata astfel încât utilizatorii să poată căuta, prelua și actualiza datele după cum este necesar. [18]
O bază de date poate fi generată și întreținută manual sau poate fi computerizată. Catalogul bibliotecii este un exemplu de bază de date care poate fi creată și întreținută manual. O baza de date computerizată poate fi creată și întreținută fie de un grup de programe de aplicație scrise în mod specific pentru acea sarcină sau printr-un sistem de gestionare a bazelor de date.
Un sistem de gestionare a bazelor de date (numit în continuare SGBD) este o colecție de programe care permite utilizatorilor să creeze și să să mențină o bază de date. Prin urmare, SGBD este un sistem software general care facilitează procese de definire, construire și manipulare a bazelor de date pentru diverse aplicații. Definirea unei baza de date implică specificarea tipurilor de date, a structurilor și a constrângerilor pentru stocarea datelor în baza de date. Construirea bazei de date este procesul de stocare a datelor pe un anumit mediu de stocare care este controlat de SGBD. Manipularea unei baze de date include funcții precum interogarea bazei de date pentru a prelua date specifice, actualizarea bazei de date pentru a reflecta schimbările și generând rapoarte din date. [18]
3.1.2. CARACTERISTICILE ABORDĂRII BAZEI DE DATE
Fig. 3.1. Procesul de proiectare a bazei de date
O serie de caracteristici diferențiază abordarea bazei de date de abordarea tradițională din programarea cu fișiere. În procesarea tradițională a fișierelor, fiecare utilizator definește și implementează fișierele necesare pentru o aplicație specifică ca parte a programării aplicației. De exemplu, un utilizator, biroul de secretariat, poate păstra un dosar cu notele studentilor. Programe pentru tipărirea situatiei unui student, transcrierea și introducerea de note noi în fișier sunt implementate. Un al doilea utilizator, biroul de contabilitate, poate urmări taxele studenților și plățile acestora. Deși ambii utilizatori sunt interesați de date despre studenti, fiecare utilizator întreține fișiere și programe separate pentru manipularea acestor fișiere – pentru că fiecare are nevoie de unele date care nu sunt disponibile in fișierele celorlalți utilizatori. Această redundanță în definirea și stocarea datele duc la creșterea spațiului de stocare și la eforturile redundante de a menține datele comune actualizate. [18]
În abordarea bazei de date, se păstrează un singur depozit de date care este definit o dată și apoi este accesat de diferiți utilizatori. Principalele caracteristici ale abordării bazei de date față de procesarea fișierelor vor fi detaliate in continuare:
Natura unui sistem de baze de date
O caracteristică fundamentală a abordării bazei de date este că sistemul de baze de date conține nu numai baza de date însăși, dar și o definiție sau descrierea completă a structurii și constrângerilor bazei de date. Această definiție este stocată în catalogul de sistem, care conține informații precum structura fiecărui fișier, tipul și formatul de stocare al fiecărui element de date și diverse constrângeri asupra datelor. Informatia stocata în catalog se numește meta-date și descrie structura bazei de date primare. [18]
Catalogul este utilizat de software-ul SGBD și de utilizatorii de baze de date care au nevoie de informații despre structura bazei de date. Un pachet de programe SGBD cu scop general nu este scris pentru o bază de date specifică și, prin urmare, trebuie să se refere la catalog pentru a cunoaște structura fișierelor într-o anumita baza de date, cum ar fi tipul și formatul datelor pe care le va accesa. Software-ul SGBD trebuie să funcționeze în mod egal cu orice număr de aplicații ale bazelor de date – de exemplu, o bază de date universitară, o baza de date a unui serviciu bancar sau o bază de date a unei companii – atâta timp cât definiția bazei de date este stocată în catalog. [18]
În procesarea tradițională a fișierelor, definiția datelor este în mod obișnuit o parte a programelor de aplicație în sine. Prin urmare, aceste programe sunt constrânse să lucreze cu o singură bază de date specifică, a cărei structură este declarata în programele de aplicații. De exemplu, un program PASCAL poate avea structuri de înregistrare declarată în aceasta; un program C ++ poate avea declarații "struct" sau "clasă"; și un program COBOL poate avea divizii de date pentru a defini fișierele. În timp ce software-ul de procesare a fișierelor poate accesa doar anumite informații din baza de date, software-ul SGBD poate accesa diverse baze de date prin extragerea definițiilor bazei de date de la cataloage și apoi folosind aceste definiții. [18]
Izolarea între programe și date și abstractizarea datelor
În procesarea tradițională a fișierelor, structura fișierelor de date este încorporată în programele de acces, deci orice modificări aduse structurii unui fișier pot necesita modificarea tuturor programelor care accesează acest fișier. În contrast, Programele de acces la SGBD nu necesită astfel de modificări în majoritatea cazurilor. Structura fișierelor de date este stocată în catalogul SGBD separat de programele de acces. Denumim acesta proprietate “independența datelor de program”.
În bazele de date orientate pe obiecte și obiect-relaționale, utilizatorii pot defini operațiile pe date ca o parte din definițiile bazei de date. O operație (numită și o funcție) este specificată în două părți: interfața (sau semnătura) unei operații include numele operației și tipurile de date ale argumentelor sale (sau parametrii), implementarea (sau metoda) operației este specificată separat și poate fi modificata fără a afecta interfața. Programele de aplicație pentru utilizatori pot opera pe date invocând aceste operațiuni prin numele și argumentele lor, indiferent de modul în care sunt implementate operațiunile. Aceasta se poate numi independență în funcționarea programelor. [18]
Caracteristica care permite independența datelor de program și independența programelor de funcționare este numită abstractizare de date. Un SGBD oferă utilizatorilor o reprezentare conceptuală a datelor pe care le efectuează si nu include multe detalii despre modul în care sunt stocate datele sau modul în care sunt implementate operațiunile. În mod informal, un model de date este un tip de abstractizare a datelor care este folosit pentru a furniza aceasta reprezentare conceptuala. Modelul de date utilizează concepte logice, cum ar fi obiectele, proprietățile lor și propriile lor interrelații, care pot fi mai ușor de înțeles pentru majoritatea utilizatorilor decât conceptele de stocare a computerelor. Prin urmare, modelul de date ascunde detaliile de stocare și implementare care nu prezintă interes pentru majoritatea utilizatorilor bazei de date. [18]
Sprijinul multiplelor viziuni ale datelor
O bază de date are în mod obișnuit mulți utilizatori, dintre care fiecare poate necesita o perspectivă diferită sau o vizualizare diferită a bazei de date. O vizualizare poate fi un subset al bazei de date sau poate conține date virtuale derivate din fișierele bazei de date, dar nu sunt stocate în mod explicit. Este posibil ca unii utilizatori să nu fie nevoiți să știe dacă datele accesate sunt stocate sau derivate. Un SGBD cu mai multi utilizatori trebuie să ofere facilități pentru definirea punctelor de vedere multiple.
Partajarea datelor și procesarea tranzacțiilor cu mai mulți utilizatori
Fig. 3.2. Partajarea datelor cu mai mulți utilizatori [19]
Un SGBD cu mai multi utilizatori, așa cum sugerează și numele său, trebuie să permită accesul mai multor utilizatori la baza de date în același timp. Acest lucru este esențial dacă datele pentru mai multe aplicații sunt integrate și menținute într-o singură aplicație Bază de date. SGBD trebuie să includă software de control al utilizarii comune pentru a se asigura că mai mulți utilizatori pot accesa aceleași date. De exemplu, în cazul în care mai mulți grefieri de rezervă încearcă să aloce un loc pe un zbor de linie aeriană, SGBD trebuie sa asigure ca fiecare scaun poate fi accesat de un singur funcționar la un moment dat pentru alocarea pasagerului. Aceste tipuri de aplicații sunt denumite în general “aplicații de procesare a tranzacțiilor on-line”. Rolul fundamental al software-ului SGBD cu mai multi utilizatori este de a asigura funcționarea tranzacțiilor concurente corect. [18]
Caracteristicile precedente sunt cele mai importante în diferențierea unui SGBD de procesarea tradițională a fișierelor software. [18]
3.1.3. ACTORII DE PE SCENĂ
Pentru o bază de date personală mică, cum ar fi lista adreselor cunostiintelor, o persoană definește, construiește și manipulează baza de date. Cu toate acestea, multe persoane sunt implicate în proiectarea, utilizarea și întreținerea unei baze de date mari cu câteva sute de utilizatori. În această secțiune identificăm persoanele ale căror locuri de muncă implică utilizarea zilnică a unei baze de date extinse; le numim "actorii de pe scenă ". În urmatoarea secțiune, luăm în considerare oameni care pot fi numiți "muncitori din spatele scenei" -aceia care lucreaza pentru a menține mediul sistemului bazei de date, dar care nu sunt interesați în mod activ în baza de date în sine. [18]
Administratorii de baze de date
În orice organizație în care multe persoane utilizează aceleași resurse, este nevoie de un șef administrator pentru a supraveghea și gestiona aceste resurse. Într-un mediu de baze de date, resursa principală este baza de date în sine și resursa secundară este SGBD și software-ul conex.
Administrarea acestor resurse sunt responsabilitatea administratorului bazei de date ( numit în continuare ABD). ABD este responsabil pentru autorizarea accesului la baza de date, coordonarea și monitorizarea utilizării acesteia și achiziționarea de software și resursele hardware, după cum este necesar. ABD este responsabil pentru probleme precum încălcarea securității sau timpul de răspuns scăzut al sistemului. În organizațiile mari, ABD este asistat de un personal care ajută la îndeplinire aceste funcții. [18]
Designeri de baze de date
Designerii de baze de date sunt responsabili pentru identificarea datelor care vor fi stocate în baza de date și pentru alegerea structurilor adecvate pentru a reprezenta și a stoca aceste date. Aceste sarcini sunt în mare parte întreprinse înainte ca baza de date să fie implementată și să fie completată cu date. Este responsabilitatea designeri-lor bazei de date să comunice cu toți utilizatorii potențiali ai bazei de date, pentru a le înțelege cerințele și să vină cu un design care să respecte aceste cerințe.
În multe cazuri, designerii sunt angajați ai ABD și li se pot atribui alte responsabilități după ce este proiectata baza de date finala. De obicei, designerii de baze de date interacționează cu fiecare grup potențial de utilizatori și dezvoltă o viziune a bazei de date care îndeplinește cerințele privind datele și procesarea acestui grup. Aceste puncte de vedere sunt analizate și integrate cu opiniile altor grupuri de utilizatori. Proiectarea finală a bazei de date trebuie să fie capabilă de a sprijini cerințele tuturor grupurilor de utilizatori. [18]
Utilizatorii finali
Utilizatorii finali sunt persoanele ale căror locuri de muncă necesită accesul la baza de date pentru interogarea, actualizarea și generarea de rapoarte. Există mai multe categorii de utilizatori finali: [18]
• Utilizatorii finali ocazionali accesează baza de date, dar pot avea nevoie de informații diferite de fiecare data. Ei folosesc un limbaj complex de interogare a bazei de date pentru a specifica cererile lor și sunt de obicei managerii de nivel mediu sau de nivel înalt.
• Utilizatorii finali frecvenți constituie o parte considerabilă a utilizatorilor finali ai bazei de date. Activitatea lor principala se învârte în jurul interogării și actualizării în mod constant a bazei de date, utilizând interogări și actualizări standard – numite tranzacții conservate – care au fost atent programate și testate. Sarcinile pe care acești utilizatori le îndeplinesc sunt variate:
– Operatorii bancari verifică soldurile conturilor, retrageri și depozite.
– Angajații de rezervare pentru companii aeriene, hoteluri și companii de închiriere auto verifică disponibilitatea pentru o anumită solicitare și fac rezervări.
– Grefierii de la posturile de primire pentru poșta de curierat introduc identificarea pachetelor prin coduri de bare și informații descriptive pentru a actualiza o bază de date centrală a pachetelor primite și în tranzit.
• Utilizatorii finali cu abordare complexă includ ingineri, oameni de știință, analiști de afaceri și alții care vor să se familiarizeze cu facilitățile SGBD astfel încât să le pună la dispozitie aplicații pentru a-și satisface cerințele complexe.
• Utilizatorii independenți păstrează baze de date personale folosind pachete de programe gata făcute care oferă interfețe bazate pe meniuri sau grafice ușor de utilizat. [18]
Analiști de sistem și programatori de aplicații (ingineri de software)
Analiștii sistemului determină cerințele utilizatorilor finali, în special utilizatorii finali frecventi, să dezvolte specificații pentru tranzacțiile comune care îndeplinesc aceste cerințe. Acesti utilizatori solicita programatorilor sa implementează aceste specificații ca programe; apoi testează, depanează, documentează și mențin aceste tranzacți. Astfel de analiști și programatori (numiți în prezent ingineri de software) ar trebui să fie familiarizați cu întreaga gamă de capabilități oferite de SGBD pentru sarcinile lor. [18]
Fig. 3.3. Ingineria Software-ului [20]
3.1.4. LUCRĂTORII DIN SPATELE SCENEI
În plus față de cei care proiectează, utilizează și administrează o bază de date, alte persoane sunt asociate cu proiectarea, dezvoltarea și funcționarea software-ului SGBD și a mediului de sistem. Aceste persoane nu sunt de obicei interesate de baza de date în sine. Ii vom numi "lucrătorii din spatele scenei" și ei includ următoarele categorii: [18]
• Dezvoltatorii de sisteme SGBD și implementatorii sunt persoane care proiectează și implementează Modulele și interfețele SGBD ca pachet software. Un SGBD este un sistem software complex care constă din mai multe componente sau module, inclusiv module pentru implementarea catalogului, limba de interogare, procesoarele de interfață, accesul la date, controlul concurenței, recuperarea și Securitate. SGBD trebuie să interfereze cu alte sisteme software, cum ar fi sistemul de operare și compilatoare pentru diferite limbi de programare.
• Dezvoltatorii de instrumente includ persoane care proiectează și implementează instrumente – pachetele software care facilitează proiectarea și utilizarea sistemului de baze de date și contribuie la îmbunătățirea performanței. Instrumentele sunt pachete opționale care sunt adesea achiziționate separat. Acestea includ pachete pentru baza de date cum ar fi: design, monitorizarea performanțelor, interfețe grafice naturale sau interfețe grafice, prototipuri, simularea și generarea de date de testare. În multe cazuri, se dezvoltă furnizori independenți de software care comercializeaza aceste instrumente.
• Operatorii și personalul de întreținere sunt personalul de administrare a sistemului care este responsabil pentru funcționarea și întreținerea efectivă a mediului hardware și software pentru sistemul de baze de date. [18]
Cu toate că aceste categorii de lucrători de mai sus din scenă au un rol esențial în realizarea bazei de date, sistem disponibil pentru utilizatorii finali, de obicei nu folosesc baza de date pentru propriile scopuri. [18]
3.1.5. AVANTAJELE UTILIZĂRII UNUI SGBD
În această secțiune discutăm câteva dintre avantajele utilizării unui SGBD și a capacităților pe care le oferă un bun SGBD trebuie să le posede. ABD trebuie să utilizeze aceste capacități pentru a realiza o varietate de obiective legate de proiectarea, administrarea și utilizarea unei baze de date cu maimulti utilizatori. [18]
Controlul redundanței
În dezvoltarea software tradițională care utilizează procesarea fișierelor, fiecare grup de utilizatori își păstrează propriile fișiere pentru manipularea aplicațiilor sale de prelucrare a datelor. De exemplu, in abordarea tradițională, exista cate un grup care păstrează fișiere în mod independent pe studenti. Biroul contabilitate păstrează, de asemenea, datele privind înregistrarea și informațiile de facturare aferente, în timp ce biroul de înregistrare ține evidența cursurilor și notelor studenților. O mare parte din date sunt stocate de două ori: cate o dată în fișierele fiecărui grup de utilizatori. Grupurile de utilizatori suplimentare pot duplica în continuare unele sau toate datele în propriile lor fișiere. [18]
Această redundanță în stocarea acelorași date de mai multe ori duce la mai multe probleme. În primul rând, trebuie să se efectueze o singură actualizare logică, cum ar fi introducerea datelor pentru un nou student, de mai multe ori: o singură dată pentru fiecare fișier în care sunt înregistrate datele studenților. Acest lucru duce la dublarea efortului. În al doilea rând, spațiul de stocare este marit atunci când aceleași date sunt stocate în mod repetat, iar această problemă poate fi serioasă pentru bazele de date mari. În al treilea rând, fișierele care reprezintă aceleași date pot deveni incoerente. Acest lucru se poate întâmpla din cauza unei actualizări care se aplică anumitor fișiere, dar nu și altora. Chiar dacă o actualizare – cum ar fi adăugarea unui nou student – este aplicată la toate fișierele corespunzătoare, datele referitoare la student pot fi inconsistente din moment ce actualizările sunt aplicate independent de fiecare grup de utilizatori. De exemplu, un grup de utilizatori poate introduce datele de naștere ale unui student eronat ca IAN-19-1974, în timp ce celelalte grupuri de utilizatori pot introduce corect valoarea lui IAN-29-1974.
În abordarea bazei de date, opiniile diferitelor grupuri de utilizatori sunt integrate în timpul proiectării bazei de date. Pentru consistență, ar trebui să avem un design de bază de date care stochează fiecare element de date logic – cum ar fi un student cu numele sau data nașterii – într-un singur loc în baza de date. [18]
Restricționarea accesului neautorizat
Atunci când mai mulți utilizatori au acces la o bază de date, este probabil ca unii utilizatori să nu fie autorizați să acceseze toate informațiile din baza de date. De exemplu, datele financiare sunt adesea considerate confidențiale, și prin urmare numai persoanele autorizate au acces la astfel de date.
În plus, unii utilizatori pot fi autorizați numai pentru a prelua date, în timp ce altii sunt permise atât pentru recuperare, cât și pentru actualizare. Prin urmare, operațiunea de preluare sau de actualizare trebuie de asemenea să fie controlată. De obicei, utilizatorii sau grupurile de utilizatori au numerele de cont protejate de parole, pe care le pot utiliza pentru a avea acces la baza de date. Un SGBD ar trebui să furnizeze un subsistem de securitate și de autorizare, pe care ABD îl utilizează pentru a crea conturi și pentru a specifica restricțiile contului. SGBD ar trebui apoi să aplice aceste restricții în mod automat. De exemplu, numai personalul ABD ar putea să utilizeze anumite programe privilegiate, cum ar fi software-ul pentru crearea de conturi noi. În mod similar, utilizatorii frecventi pot fi autorizați să acceseze baza de date doar prin intermediul tranzacțiilor comune dezvoltate pentru utilizarea lor. [18]
Asigurarea stocării durabile a obiectelor de program și a structurilor de date
Bazele de date pot fi utilizate pentru stocarea permanentă a obiectelor de program și a structurilor de date. Acesta este unul dintre principalele motive pentru apariția sistemelor de baze de date orientate pe obiecte.
Limbajele de programare, de obicei au structuri complexe de date, cum ar fi tipurile de înregistrări în PASCAL sau definițiile de clasă în C ++. Valorile variabilelor programului sunt eliminate odată ce programul se termină, cu excepția cazului în care programatorul le stochează în mod explicit în fișiere permanente, ceea ce implică adesea conversia acestor complexe structuri într-un format adecvat pentru stocarea fișierelor. Atunci când este necesar să se citească din nou aceste date, programatorul trebuie să convertească de la formatul de fișier la structura variabilei de program. Orientarea pe obiect si sistemele de baze de date sunt compatibile cu limbajele de programare precum C++, JAVA și SGBD software-ul care efectuează automat orice conversie necesara. Prin urmare, un obiect complex în C++ poate fi stocat permanent într-un SGBD orientat spre obiect, cum ar fi ObjectStore sau O2 (numit acum Ardent). Un astfel de obiect se spune că este durabil, deoarece supraviețuiește încetării programului de execuție și poate fi ulterior recuperat direct de un alt program C++.[18]
Depozitarea durabila a obiectelor de program și a structurilor de date este o funcție importantă a sisteme de baze de date. Sistemele tradiționale de baze de date au suferit deseori de o așa-numita nepotrivire a impedanței deoarece structurile de date furnizate de SGBD erau incompatibile cu limbajul de programare. Sistemele de baze de date orientate pe obiecte oferă de obicei structură de date compatibile cu una sau mai multe limbaje de programare orientate pe obiect. [18]
Permiterea interactiunilor și acțiunilor care utilizează regulile
Unele sisteme de baze de date oferă capabilități pentru definirea regulilor de deducere pentru interactiunile informațiilor stocate in baza de date. Astfel de sisteme sunt numite sisteme de baze de date deductive.
De exemplu, pot exista reguli complexe în aplicația baze de date pentru a determina momentul în care un student este activ. Acestea pot fi specificate declarativ ca reguli, care, atunci când sunt compilate și menținute de SGBD poate determina toți studenții aflați în probă. Într-un SGBD tradițional codul ar trebui să fie scris expicit pentru a sprijini astfel de aplicații. Dar dacă se schimbă regulile bazei de date, este în general mai convenabil să se modifice normele de deducere decât să se reconecteze programele procedurale. Funcționalități mai puternice sunt oferite de sistemele de baze de date active care oferă reguli active ce pot iniția automat acțiuni. [18]
Furnizarea de interfețe multiple de utilizator
Deoarece multe tipuri de utilizatori cu niveluri diferite de cunoștințe tehnice folosesc o bază de date, un SGBD ar trebui să ofere o varietate de interfețe pentru utilizatori.
Acestea includ limbaje de interogare pentru utilizatorii ocazionali; interfețe de limbaj de programare pentru programatorii de aplicații; formulare și coduri de comandă pentru utilizatorii frecventi, interfețe bazate pe meniuri și un limbaj comun pentru utilizatorii independenți. Ambele interfețe de stil și interfețe de meniu sunt cunoscute ca interfețe grafice de utilizare. Multe limbaje și medii specializate există pentru specificarea interfețelor grafice. Posibilitățile de furnizare a accesului la World Wide Web a unei baze de date sunt de asemenea, din ce în ce mai frecvențe.
Reprezentarea relațiilor complexe dintre date
O bază de date poate include numeroase soiuri de date care sunt interconectate în multe feluri. Un SGBD trebuie sa aiba capacitatea de a reprezenta o varietate de relații complexe între date, precum și de a le recupera și actualiza datele asociate cu ușurință și eficient. [18]
Impunerea constrângerilor de integritate
Cele mai multe aplicații de baze de date au anumite constrângeri de integritate care trebuie să fie valabile pentru date. Un SGBD ar trebui să ofere capacități pentru definirea și aplicarea acestor constrângeri. Cel mai simplu tip de constrângere implică specificarea unui tip de date pentru fiecare element de date.
Un alt tip de constrângere specifică unicitatea pe elementul de valori de date. Aceste constrângeri sunt derivate din semnificația sau semantica datelor și din baza de date pe care o reprezintă. Este responsabilitatea designer-ilor de baze de date pentru a identifica constrângerile de integritatea în timpul proiectării bazei de date. Niste constrângeri pot fi specificate în SGBD și aplicate automat. Este posibil să fie și alte constrângeri verificate de programele de actualizare sau în momentul introducerii datelor.
Un element de date poate fi introdus eronat și nu îndeplinește constrângerile de integritate specificate. De exemplu, dacă un student primește nota 10, dar o notă de 8 este introdusă în baza de date, SGBD nu poate descoperi automat această eroare, deoarece 8 este o valoare validă pentru tipul de date Note. Asemenea date eronate de intrare pot fi descoperite doar manual (când studentul primește nota și se plânge) și corectată ulterior prin actualizarea bazei de date. Cu toate acestea, o nota de 12 poate fi respinsa automat de către SGBD, deoarece 12 nu este o valoare validă pentru tipul de date Note. [18]
3.1.6. IMPLICAȚIILE UTILIZĂRII BAZELOR DE DATE
Pe lângă problemele discutate în secțiunea anterioară, există și alte implicații ale utilizării bazelor de date care pot aduce beneficii majorității organizațiilor.
Potențial pentru aplicarea standardelor
Utilizarea bazei de date permite ABD să definească și să impună standarde în rândul utilizatorilor de baze de date dintr-o mare organizație. Acest lucru facilitează comunicarea și cooperarea între diferite departamente, proiecte și utilizatori din cadrul organizației. Standardele pot fi definite pentru nume și formate de date elementare, formate de afișare, structuri de rapoarte, terminologie și așa mai departe. ABD poate impune standarde într-un mediu de baze de date centralizat mai ușor decât într-un mediu în care fiecare grup de utilizatori are controlul propriilor fișiere și al software-ului. [18]
Timp redus de dezvoltare a aplicației
O caracteristică primară a utilizarii bazei de date este aceea că dezvoltarea unei noi aplicații – cum ar fi recuperarea anumitor date din baza de date pentru tipărirea unui nou raport – durează foarte puțin timp. Proiectul și implementarea unei noi baze de date de la zero poate dura mai mult timp decât scrierea unei cereri specializate. Cu toate acestea, odată ce o bază de date este în curs de funcționare, în mod substanțial mai puțin timp este în general necesar pentru a crea noi aplicații utilizând facilitățile SGBD. Timpul de dezvoltare folosind un SGBD este estimat a fi de la un sfert din cel pentru un sistem de fișiere tradițional.
Flexibilitate
Poate fi necesară modificarea structurii unei baze de date pe măsură ce cerințele se schimbă. De exemplu, poate apărea un nou grup de utilizatori care are nevoie de informații care nu sunt în prezent în baza de date. Ca răspuns, ar putea fi necesar pentru a adăuga un fișier în baza de date sau pentru a extinde elementele de date într-un fișier existent. SGBD-urile moderne permit anumite tipuri de modificări ale structurii bazei de date fără a afecta datele stocate și programele aplicațiilor existente. [18]
Disponibilitatea informațiilor actualizate
Un SGBD face ca baza de date să fie disponibilă tuturor utilizatorilor. Imediat ce se aplică o actualizare a unui utilizator in baza de date, toți ceilalți utilizatori pot vedea imediat această actualizare. Această disponibilitate de informații actualizate este esențiala pentru multe aplicații de procesare a tranzacțiilor, cum ar fi sisteme de rezervare sau servicii bancare și este posibilă prin subsistemele de control și recuperare a unui SGBD. [18]
3.1.7. CĂND NU SE UTILIZEAZĂ UN SGBD
În ciuda avantajelor utilizării unui SGBD, există câteva situații în care un astfel de sistem poate implica costuri generale inutile. Cheltuielile generale de utilizare a unui SGBD se datorează următoarelor:
• Investiție inițială ridicată în hardware, software și instruire.
• Generalitatea pe care un SGBD o oferă pentru definirea și prelucrarea datelor.
• Securitate pentru furnizarea de funcții de securitate, de control al concurenței, de recuperare și de integritate. [18]
3.2. BAZE DE DATE RELAȚIONALE
3.2.1. GENERALITĂȚI
Modelul relațional al datelor a fost primit cu entuziasm și acceptat aproape fără rezerve atât de specialiștii din domeniul bazelor de date cât și de utilizatori, încă de la apariția primelor articole ale lui Codd E. F., în 1970 prin care erau puse bazele acestui model. Ideea unui model asamblist al datelor a fost lansată în 1968 de către Childs D.F. care a subliniat faptul că orice structură de date poate fi reprezentată prin una sau mai multe tabele de date, în cadrul acestora este necesar să existe și informații de legatură, pentru asigurarea legăturilor între tabele. Codd are meritul de a fi articulat și dezvoltat ideile cu privire la utilizarea teoriei apartenenței la ansambluri sub forma unui model coerent de structurare a datelor numit “modelul relațional” . Despre acest model s-a scris mult, astfel încât în prezent, lucrările consacrate modelului relațional și sistemelor de gestiune a bazelor de date relaționale sunt cu mult mai numeroase decât cele dedicate altor tipuri de modele și sisteme. [21]
S-a constatat că prin utilizarea sistemelor relaționale este posibilă atingerea unor obiective importante ale organizării datelor și anume: asigurarea unei mai mari independențe a programelor de aplicație față de organizarea datelor precum și a unor instrumente eficace de control a coerenței și redundanței datelor.
Utilizatorii cuceriți de simplitatea modelului relațional au manifestat o puternică preferință pentru sistemele relaționale. Trebuie subliniat faptul că folosirea modelului relațional nu necesită cunoștiințe teoretice deosebite. Modelul relațional poate fi prezentat utiizatorilor cu ajutorul unor concepte extrem de simple și intuitive. De exemplu, relația tablou de date. Reprezentarea relației în acest mod este comodă, ușor de înteles și de utilizat, în special în cadrul operațiilor asupra datelor.
Definirea unui SGBD relațional impune realizarea caracteristicilor pe care trebuie să le prezinte un model de date pentru a fi considerat relațional. Există diferite modalități pentru a defini acest concept:
Prezentarea datelor în tabele supuse anumitor operații: selecție, proiecție, reuniune, compunere, intersecție etc.
Un sistem de baze de date ce suportă un limbaj de tip SQL- Structured Query Language
Un sistem de baze de date care respecta principiile modelului relațional introdus de Codd. [21]
Caracteristicile modelului relațional
Un model relațional este caracterizat de trei concepte, acestea sunt:
Structura relațională a datelor. În cadrul bazelor de date relaționale, datele sunt organizate sub formă de tablouri bidimenesionale (tabele de date), numite relații. Asocierile dintre relații se reprezintă explicit prin atribute de legătură. Aceste atribute figurează într-una din relațiile implicate în asociere (de regulă, în cazul legăturilor de tip “unu la mulți”) sau sunt plasate într-o relație distinctă, construită special pentru examinarea legăturilor între relații (în cazul legăturilor de tip “mulți la mulți”). O bază de date relațională (BDR) reprezintă un ansamblu de relații , prin care se reprezintă atât datele cât și legăturile dintre date.
Operatorii modelului relațional. Definesc operațiile care se pot efectua asupra relațiilor, în scopul realizării funcțiilor de prelucrare asupra bazei de date, respectiv consultarea, inserarea, modificarea și ștergerea datelor.
Restricțiile de integritate ale modelului relațional. Permit definirea stărilor coerente ale bazei de date. [21]
3.2.2. LIMBAJE RELAȚIONALE
Un limbaj de manipulare a datelor se compune dintr-o mulțime de comenzi care permit interogarea unei baze de date și dintr-o mulțime de comenzi care permit modificarea acesteia. Modificarea unei baze de date implică inserare, suprimare și reactualizare. În general, un limbaj de manipulare a datelor este încorporabil într-un limbaj de programare clasic numit limbaj gazdă. [21]
Unul dintre cele mai mari merite ale modelului relațional este că prin intermediul multiplelor sale limbaje de interogare permite utilizatorului, să indice rezultatul care interesează, fără a preciza modul în care este obținut acest rezultat.
Se poate clasifica limbajele de manipulare a datelor relaționale în limbaje algebrice (exemplu: SEQUEL/ SQL) și limbaje predictive. Limbajele predictive pot fi orientate pe tupluri (exemplu: QUEL, ALPHA) sau orientate pe domenii. Limbajele orientate pe domenii pot fi non-grafice (exemplu: ILL, FQL) sau grafice. Limbajele grafice pot fi cu variabile (exemplu: QBE) sau fără variabile (exemplu: LAGRIF, CUPID, VGQF).
Se va analiza caracteristicile limbajului algebric SQL.
Limbajul SQL este atat un limbaj interactiv, cât și un limbaj integrat într-un limbaj de programare. SQL este un limbaj standard de descriere a datelor și acces la informațiile din baza de date. SQL nu este un limbaj unic (cu excepția stadardului care este puțin utilizat), există o mulțime de dialecte (aproximativ 100), dintre care amintim: SQL pentru DB2, SQL*PLUS pentru ORACLE, SQL pentru INGRES, SQL pentru dBASEIV etc. au fost concepute și dezvoltate diverse versiuni ale standardului SQL de către ANSI, IBM, Microsoft, Borland etc. [21]
3.2.3. ELEMENTE ALE BAZELOR DE DATE RELAȚIONALE
Tabele
Unitățile de bază într-o bază de date sunt tabelele și relația dintre ele. Strict, o bază de date relațională este o colecție de relații (frecvent numite tabele). Mai jos vom vedea modul în care o relație între două tabele este definita folosind chei primare și chei externe. [22]
Fig. 3.4. Exemplu- tabele [22]
Cheile primare sunt definite cu următoarea sintaxă:
Dacă cheia primară constă doar dintr-o singură coloană, coloana poate fi marcate ca atare, utilizând următoarea sintaxă:
Definiția sintactica a unei chei unice este foarte similara cu cheia primara. [22]
De asemenea, cheile unice pot fi definite ca făcând parte din instrucțiunea SQL CREATE TABLE.
Sau, dacă cheia unică constă doar dintr-o singură coloană, coloana poate fi marcata ca atare folosind următoarea sintaxă:
Cheie externă
În contextul bazelor de date relaționale, o cheie externă este o constrângere referențială între două tabele. Cheia externă identifică o coloană sau un set de coloane într-un singur tabel care se referă la o coloană sau un set de coloane dintr-un alt tabel. Coloanele din tabelul de referința trebuie să fie cheie primară sau o altă cheie definita pentru cel de-al doilea tabel. Valorile dintr-un singur rând al coloanelor din tabelul de referința trebuie să aibă loc într-un singur rând în cel de-al doilea tabel. Astfel, un rând în tabelul de referința nu poate conține valori care nu există în cel de-al doilea tabel. De aici, pot fi făcute referințe pentru a lega informațiile împreună și aceasta este o parte esențială a normalizarii bazei de date. Rânduri multiple din tabelul de referința se pot referi la același rând din cel de-al doilea tabel.
Tabelul la care se face referire si tabelul de referință pot fi același tabel, adică cheia externă se referă înapoi la aceeași tabel. O astfel de cheie externă este cunoscuta sub numele de auto-referința sau cheie externa recursiva. [22]
Un tabel poate avea mai multe chei externe, iar fiecare cheie externa poate avea un alt tabel cu date de referință. Fiecare cheie externă este aplicată în mod independent de sistemul de baze de date. Prin urmare, relațiile între tabele în cascadă pot fi stabilite cu ajutorul unei chei externe.
Relațiile necorespunzătoare cheie externă/cheie primara sau neaplicarea acestor relații sunt adesea sursa multor probleme de modelare a bazelor de date. Cheile externe pot fi definite ca făcând parte din instrucțiunea SQL CREATE TABLE. [22]
În cazul în care cheia externă este o singură coloană, coloana poate fi marcata ca atare folosind următoarea sintaxă: [22]
Vizualizări
În teoria bazelor de date, o vizualizare constă intr-un tabel virtual compus din setul de rezultate al unei interogări. Spre deosebire de tabele obișnuite dintr-o bază de date relațională, o vizualizare nu face parte din schema fizică: este un tabel dinamic, calculat virtual sau adunat de la datele din baza de date. Modificarea datelor dintr-un tabel modifică vizualizările viitoare.
Vizualizarile pot oferi avantaje față de tabele: [22]
• Vizualizările pot reprezenta un subset al datelor dintr-un tabel,
• Vizualizările pot să se conecteze și să simplifice mai multe tabele într-un singur tabel virtual,
• Vizualizările pot acționa ca tabele agregate, în cazul în care motorul de bază de date agregă datele (Sumă, etc medie) și prezintă rezultatele calculate ca parte a datelor,
• Vizualizările pot ascunde complexitatea datelor,
• Vizualizările necesită foarte puțin spațiu pentru stocare; baza de date conține doar definiția unei vizualizari, nu o copie a tuturor datelor pe care le prezintă,
• Vizualizările pot limita gradul de expunere al unui tabel sau a unor tabele la lumea exterioară. [22]
Sintaxă:
Funcții
În bazele de date SQL, o funcție definită de utilizator oferă un mecanism de extindere a funcționalitatii serverului de baze de date prin adăugarea unei funcții care poate fi evaluată în specificatiile SQL. Standardul SQL face distincție între funcțiile scalare și de tabele. O funcție scalara returnează o singură valoare (sau NULL), în timp ce o funcție tabelara returnează un tabel cuprinzând zero sau mai multe rânduri, fiecare rând cu una sau mai multe coloane. Funcțiile definite de utilizator în SQL sunt declarate folosind instrucțiunea CREATE FUNCTION. [22]
Sintaxă:
Proceduri stocate
O procedură stocată este un cod executabil care este asociat cu bază de date. Procedurile stocate colectează și personalizeaza operațiunile comune, colecteaza informații statistice cu privire la modul de utilizare sau cuprind calcule. Acestea sunt frecvent utilizate ca interfață de programare a aplicațiilor (IPA) pentru securitate sau simplitate. Procedurile stocate nu fac parte din modelul de baze de date relaționale, dar toate implementarile comerciale le includ.
Procedurile stocate sunt numite sau folosite cu următoarele sintaxe:
Structura limbajului standard de interogare, oferă IF, WHILE, LOOP, REPEAT, CASE, și altele. Procedurile memorate pot primi variabile, returna rezultate sau modifica variabile și sa le restituie, în funcție de modul în care variabila este declarată. [22]
Declansatoare
Un declanșator al unei baze de date este un cod de procedură care se execută automat ca răspuns la anumite evenimente dintr-un anumit tabel sau dintr-o vizualizare a unei baze de date. Declanșatorul este folosit mai ales pentru păstrarea integritatii informațiilor privind baza de date. De exemplu, atunci când o noua inregistrare (reprezentând un nou angajat) se adaugă la tabelul de angajați, înregistrări noi ar trebui să fie create de asemenea, în tabelele de impozite, concedii și salarii. [22]
Sintaxa este următoarea:
3.3. LIMBAJUL SQL
Limbajul SQL poate fi considerat unul dintre motivele majore pentru succesul bazelor de date relaționale în lumea comercială. Deoarece a devenit un standard pentru bazele de date relaționale, utilizatorii au fost mai puțini preocupați de migrarea aplicațiilor acestora de baze de date, de la alte tipuri de sisteme de baze de date la sistemele relaționale. Motivul este că, chiar dacă utilizatorul a devenit nemulțumit de produsul SGBD relațional special pe care l-au ales să îl folosească, convertindu-se la un alt SGBD relațional nu ar fi de așteptat să fie prea scump și consumator de timp, deoarece ambele sisteme ar urma aceleași standarde lingvistice. În practică, desigur, există multe diferențe între diferite pachete SGBD relaționale comerciale. Cu toate acestea, dacă utilizatorul este atent în a utiliza numai acele caracteristici care fac parte din standard și dacă ambele sisteme relaționale sprijină cu fidelitate standardul, atunci conversia dintre cele două sisteme ar trebui sa fie mult simplificată. Un alt avantaj al detinerii unui astfel de standard este că utilizatorii pot scrie într-un program de aplicații de bază de date care pot accesa datele stocate în două sau mai multe SGBD relaționale fără a fi nevoie să modificați sublimbajul bazei de date (SQL) dacă ambele SGBD-uri relaționale suportă SQL standard.
Acest capitol prezintă principalele caracteristici ale standardului SQL pentru SGBD-urile comerciale relaționale. [18]
Numele SQL este derivat din limbajul structurat de interogări. Inițial, SQL a fost numit SEQUEL si a fost proiectat și implementat la IBM Research pentru o bază de date relațională experimentală numită SYSTEM R. SQL este acum limbajul standard pentru SGBD comerciale relaționale. Un efort comun al ANSI (Institutul Național al Statelor Unite pentru Standarde) și ISO (Organizația Internațională pentru Standarde) a condus la o versiune standard a SQL (ANSI 1986), numit SQL-86 sau SQL1. Un standard revizuit și extins numit SQL2 (de asemenea denumit SQL-92) a fost ulterior dezvoltat.
SQL este un limbaj de baze de date cuprinzător; are instrucțiuni pentru definirea, interogarea și actualizarea datelor. Prin urmare, este vorba de un LDD (Limbaj de definire a datelor) și de un LMD (Limbaj de manipulare a datelor). În plus, dispune de facilități pentru vizualizarea bazei de date, specificatii asupra securitatii și nivelurilor de acces, pentru definirea constrângerilor de integritate și pentru specificarea controalelor tranzacției. De asemenea, are reguli pentru încorporarea instrucțiunilor SQL într-un limbaj de programare cu scop general cum ar fi C sau PASCAL. [18]
Ce poate face SQL?
• SQL poate executa interogări într-o baza de date;
• SQL poate prelua date dintr-o bază de date;
• SQL poate introduce înregistrări într-o bază de date;
• SQL poate actualiza înregistrările într-o bază de date;
• SQL poate șterge înregistrările dintr-o bază de date;
• SQL poate crea noi baze de date;
• SQL poate crea noi tabele într-o bază de date;
• SQL poate crea proceduri stocate într-o bază de date;
• SQL poate crea vizualizări într-o bază de date;
• SQL poate seta permisiuni pe tabele, proceduri și vizualizări.
Chiar dacă SQL este un standard, multe dintre sistemele de baze de date care există astăzi implementează propriile lor versiuni ale limbajului SQL. În acest document vom folosi Microsoft SQL Server un exemplu. [18]
Există o mulțime de sisteme de baze de date diferite sau SGBD – Sisteme de gestionare bazelor de date, precum:
• Microsoft SQL Server
– Enterprise, versiuni pentru dezvoltatori etc.
-Versiunea Express este gratuită.
• Oracle;
• MySQL (Oracle, anterior Sun Microsystems) – MySQL poate fi folosit gratuit (Licență open source), site-uri web care folosesc MySQL: YouTube, Wikipedia, Facebook;
• Microsoft Access ;
• IBM DB2;
• Sybase;
• și multe alte sisteme. [18]
Limbajul de definire a datelor (LDD)
Limbajul de definire a datelor (LDD) gestionează structura tabelelor și indexului. Cele mai de bază elemente de LDD sunt CREATE, ALTER, RENAME și DROP:
• CREATE creează un obiect (de exemplu un tabel) în baza de date.
• DROP șterge un obiect din baza de date, de obicei irevocabil.
• ALTER modifică structura unui obiect existent în diverse moduri – de exemplu, adăugând o coloană la un tabel existent. [23]
Limbajul de manipulare a datelor (LMD)
Limbajul de manipulare a datelor (LMD) este subsetul de SQL folosit pentru a adăuga, actualiza și șterge date. Acronimul CRUD se referă la toate funcțiile majore care trebuie implementate într-o aplicație de baze de date relaționale pentru a o considera completă. Fiecare literă din acronim poate fi conectata la o formula standard SQL:
Fig. 3.5. Funcțiile majore pentru o bază de date [23]
Introducere în SQL Server
Microsoft este furnizor de SQL Server.
Există ediții diferite ale SQL Server, unde SQL Server Express este gratuit pentru descărcare și utilizare. SQL Server utilizează T-SQL (Transact-SQL). T-SQL este extensie de proprietate Microsoft SQL. TSQL este foarte asemănător cu standardul SQL, dar în plus suportă și câteva funcționalități suplimentare, funcții încorporate etc. T-SQL se extinde pe standardul SQL pentru a include programarea procedurală, variabile locale, diverse funcții de sprijin pentru prelucrare șiruri de caractere, de prelucrare date, matematică etc.
SQL Server constă într-un motor de bază de date și un management de studio. Motorul bazei de date nu are o interfață grafică – este doar un serviciu care rulează în fundal. Management Studio este un instrument grafic pentru configurarea și vizualizarea informațiilor din baza de date. Acesta poate fi instalat pe server sau la utilizator (sau ambele). [23]
Fig. 3.6. Elemente SQL Server [23]
3.4. SECURITATEA ȘI PROTECȚIA DATELOR ÎN BAZE DE DATE
3.4.1. GENERALITĂȚI
Obiective
• Înțelegerea și explicarea ideei de securitate a bazei de date în contextul managmentului analizei si securității;
• Înțelegerea, explicarea și aplicarea conceptelor de securitate relevante pentru sistemele bazei de date;
• Înțelegerea, identificarea și găsirea de soluții la problemele de securitate pentru sistemele bazei de date;
• Înțelegerea limbajului de bază al mecanismelor de securitate la care se aplică sistemele bazei de date;
• Analiza cerințelor de control al accesului și realizarea implementărilor folosind SQL;
• Aprecierea limitelor subsistemelor de securitate. [24]
Sfera de aplicare a securității bazei de date
Toate sistemele au diverse elemente și securitatea vizează protejarea elementelor sistemului. Primul pas este sa cunoasteti valoarea acestora. Securitatea se concentreaza pe obiectele bazei de date (tabele, vizualizări, rânduri), accesul la ele și sistemul general care le administrează. Rețineți că nu toate datele sunt sensibile, deci nu toate necesită mare efort de protecție.
Important de cunoscut sunt aspectele care pun în pericol elementele sistemului. Acestea includ lucruri precum eșecul energetic și frauda informatică. Amenințările sunt parțial ipotetice, se schimbă întotdeauna și sunt întotdeauna necunoscute. Activitatea de securitate este îndreptată spre protejarea sistemului împotriva amenințărilor manifestate.
Dacă o amenințare este potențială, trebuie să se manifeste interes asupra ei. Cand devine reală există un IMPACT. Impact pe care se poate lua în considerare și planifica. Dar în cel mai rău caz, va exista o pierdere. Activitatea de securitate este îndreptată în minimizarea pierderilor și recuperarea bazei de date. [24]
Fig. 3.7 Scopul securității bazei de date [24]
Mecanismul de dezvoltare prezentat conține:
Conținutul documentelor (ce sunt, care este valoarea lor);
Identificarea amenințările (ce sunt acestea, cât de probabile sunt acestea, ce impact există dacă acestea apar);
Asocerea amenințările cu fiecare conținut;
Proiectare de mecanisme pentru protejarea fiecărui conținut.
Amenințări asupra bazelor de date
Se va construi construi abilitățile de securitate din două direcții. Una este de apreciere și de conștientizare a amenințărilor, iar cealalta, identificarea din punct de vedere tehnic a remediilor. Amenințările includ:
• Modificări neautorizate: modificarea valorilor datelor din motive de sabotaj, criminalitate sau ignoranța care ar putea fi posibilă prin mecanisme de securitate inadecvate, partajarea parolelor sau ghicirea parolelor, de exemplu.
• Dezvăluirea neautorizată: atunci când nu ar fi trebuit să fie informații dezvăluite. O problemă generală de importanță crucială, care poate fi accidentală sau deliberată.
• Pierderea disponibilității: uneori numită negare a serviciului. Când baza de date nu este disponibilă, suferă o pierdere. Deci, orice amenințare care dă naștere la timp offline, chiar și pentru a verifica dacă s-a întâmplat ceva, trebuie evitată. [24]
Restul acestei secțiuni este o prezentare generală a categoriilor de reglementări specifice de amenințări la adresa sistemelor de baze de date.
• Sensibilitatea comercială: Majoritatea pierderilor financiare prin fraudă apare de la angajați. Controalele de acces oferă atât protecție împotriva actelor criminale și dovada încercărilor (reușite sau altfel) de a efectua acte în detrimentul organizației, fie că este vorba despre fraudă, extragerea datelor sensibile sau pierderea disponibilității. [24]
• Confidențialitatea și protecția datelor personale: la nivel internațional, datele personale sunt, în mod normal, supuse controalelor legislative. Datele personale sunt date despre o persoană identificabilă. Deci, un cod poștal pentru o casă poate identifica în anumite cazuri un individ, dacă locuieste doar o singură persoană la adresa cu codul poștal. Aceste date necesită o manipulare atentă și control. Datele personale trebuie identificate ca atare. Controalele trebuie să existe pe utilizarea acestor date (care pot restricționa interogările ad-hoc). Piste de audit ale tuturor cailor de acces și dezvăluirea informațiilor trebuie păstrate ca dovezi.
• Utilizarea necorespunzătoare a computerului: Există, de asemenea, în general, o legislație privind abuzul informatic. Abuzul include încălcarea controalelor de acces și încercărilor pentru a provoca daune, schimbând starea bazei de date sau introducând viruși să interfereze cu funcționarea corectă. Aceste infracțiuni sunt deseori extrădabile. Deci, un acces neautorizat în Hong Kong, folosind calculatoare din Franța, pentru a accesa bazele de date din Germania care se referă la bazele de date din SUA, ar putea duce la extrădarea în Franța, Germania sau în SUA.
• Cerințe de audit: Acestea sunt constrângeri operaționale construite în jurul nevoii de a sti cine a facut ceva, cine a încercat să facă ceva, unde și când totul s-a întâmplat. Ele implică detectarea evenimentelor (inclusiv CONNECT și GRANT), furnizând dovezi pentru detectarea, asigurarea, precum și apărarea sau urmărirea penală. [24]
Principiile securității bazei de date
Fig. 3.8. Principiile securității bazei de date
Pentru a structura ideile privind securitatea, este nevoie de un model de securitate. Acestea vin în diverse forme care depind de roluri, grad de detaliu și scop. Majoritatea categoriilor sunt zonele de interes (amenințări, impact și pierderi), precum și acțiunile implicate în tratarea acestora. [24]
Riscurile de securitate trebuie văzute în ceea ce privește pierderea conținutului. Acest conținut include:
• Hardware;
• Software;
• Date;
• Calitatea datelor;
• Credibilitatea;
• Disponibilitatea;
• Beneficii pentru afaceri. [24]
3.4.2. MODELE DE SECURITATE
Un model de securitate stabilește criteriile externe pentru examinarea securității în general, și oferă contextul pentru considerațiile bazei de date, inclusiv punerea în aplicare și funcționare. Sistemele SGBD specifice au propriul lor model de securitate care este foarte important în proiectarea și funcționarea sistemelor.
Se va realiza că modelele de securitate explică caracteristicile disponibile în SGBD care trebuie utilizate pentru a dezvolta și a opera sistemele de securitate actuale. Acestea trebuie să contina concepte, politici și să furnizeze servere pentru astfel de funcții. Orice defecțiune din modelul de securitate se va traduce fie în funcționare nesigură, fie în functionare greoaie. [24]
Controlul accesului
Scopul controlului accesului trebuie să fie întotdeauna clar. Controlul accesului este scump în ceea ce privește costurile de analiză, proiectare și funcționare. Se aplică în situații cunoscute, la standarde cunoscute, pentru a atinge scopuri cunoscute. Nu aplicam controale fără toate cunoștințele de mai sus. Controlul trebuie să fie întotdeauna adecvat situatiei. Principalele aspecte sunt prezentate mai jos.
Autentificare și autorizare
Suntem cu toții familiarizați, ca utilizatori, cu cerința de conectare (log in) a majorității sistemelor. Accesul la resursele IT necesită, în general, un proces de logare care să fie recunoscut ca fiind sigur. [24]
Acest subiect are legătură cu accesul la sistemele de gestionare a bazelor de date și este o prezentare generală a procesului din perspectiva ABD. [24]
Printre principalele principii ale sistemelor de baze de date se numără autentificarea și autorizarea.
Controlul accesului în SQL
Această secțiune se referă la implementarea securității în SQL. Elementele de bază sunt date în SQL-92 dar, după cum ne vom da seama, SGBD și hardware-specific contin multe elemente de securitate. Dacă este necesar, specificațiile sunt date în SQL al Oracle.
Primul obiectiv este studierea specificului sistemelor. Specificația privind cerințele de acces care vor fi implementate folosind aceste elemente. Al doilea obiectiv este pentru a ne extinde înțelegerea problemei până la management și funcțiile de audit ale unui sistem de operare. [24]
Fig. 3.9. Elementele de securitate SQL [25]
Siguranță discretă în SQL
Această secțiune introduce instrucțiunile SQL necesare implementării controlului accesului. Ar trebui să avem în vedere cunoașterea suficientă a acestei zone de SQL pentru a traduce o specificație simplă într-un script SQL. De asemenea, trebuie să fim conștienti de limitările implicite în acest script care împiedică parolele în text. [24]
Elementele de bază ale SQL sunt în mod inerent discreționare. Drepturile de acces pentru utilizarea resurselor unei baze de date sunt atribuite și eliminate individual. Prima problemă este cine are controlul asupra subsistemului de securitate. Trebuie să existe un nivel ridicat de drepturi pentru a putea aplica măsuri de securitate.
Din păcate, aceste roluri nu se încadrează în standardul SQL și variază de la SGBD la SGBD. Un rol este definit ca o colecție de drepturi. De exemplu, rolurile furnizate în Oracle includ (printre altele):
• SYSOPER: porniți și opriți SGBD;
• DBA: autoritatea de a crea utilizatori și de a gestiona baza de date și utilizatori existenti;
• SYSDBA: Toată autoritatea DBA plus autoritatea de a crea, a începe, a opri și a recupera. [24]
3.5. CONCEPTE ȘI ARHITECTURA UNEI BAZE DE DATE
3.5.1. MODELE DE DATE, SCHEME ȘI INSTANȚE
O caracteristică fundamentală a abordării bazei de date este aceea că furnizează un anumit nivel de date abstractizate prin ascunderea detaliilor de stocare a datelor care nu sunt necesare majoritatii utilizatorilor de baze de date. Un model de date – o colecție de concepte care pot fi folosite pentru a descrie structura unei baze de date – furnizează mijloacele necesare pentru a realiza această abstractizare. Prin structura unei baze de date înțelegem tipurile de date, relațiile și constrângerile dintre date. [18]
Categorii de modele de date
Au fost propuse numeroase modele de date și se pot clasifica în funcție de tipurile de concepte pe care le folosesc pentru a descrie structura bazei de date. Modelele de date de nivel înalt sau conceptuale furnizează concepte care sunt aproape de modul în care mulți utilizatori percep datele, în timp ce modelele cu nivel scăzut sau fizice oferă concepte de date care descriu detaliile despre modul în care sunt stocate datele în computer. Concepte furnizate de modele de date cu nivelul scăzut sunt în general destinate specialiștilor de calculatoare, nu pentru utilizatorii finali tipici. Între aceste două extreme exista o clasă de modele de reprezentare (sau de implementare) care le oferă concepte care pot fi înțelese de utilizatorii finali, dar care nu sunt prea îndepărtate de modul în care sunt datele organizate în computer. [18]
Modelele de reprezentare sau de implementare sunt modelele utilizate cel mai frecvent în SGBD-urile tradiționale comerciale și includ modelul de date relațional utilizat pe scară largă, precum și așa-numitele modele de date moștenite – modelele de rețea și ierarhice – care au fost utilizate pe scară largă în trecut.
Modelele de date fizice descriu cum sunt stocate datele în computer, reprezentând informații, cum ar fi formate de înregistrare, ordine de înregistrare și căi de acces. O cale de acces este o structură care face mai eficienta căutarea pentru înregistrările particluare din bazele de date. [18]
Scheme, instanțe și starea bazei de date
În orice model de date, este important să se facă o distincție între descrierea bazei de date și baza de date. Descrierea unei baze de date se numește “schema bazei de date”, care este specificată în timpul designului bazei de date și nu este de așteptat să se schimbe frecvent.
O diagrama schemă afișează doar câteva aspecte ale unei scheme, cum ar fi numele tipurilor de înregistrări și elemente de date și unele tipuri de constrângeri. Alte aspecte nu sunt specificate în diagrama schemă. Multe tipuri de constrângeri nu sunt reprezentate în diagrama schemă. Datele reale dintr-o bază de date se pot schimba destul de frecvent; de exemplu, o baza de date a unei faculati se schimbă de fiecare dată când adăugăm un student sau introducem o nota pentru un student. Datele din baza de date la un anumit moment în timp se numesc “starea bazei de date” sau “instantaneu”. Se mai numește și setul de apariții sau cazuri actuale în baza de date. Într-o stare a bazei de date dată, fiecare schemă are propriul set curent de instanțe; de exemplu, construcția STUDENT va conține setul de entități studenți individuali (înregistrări) ca instanțe. . [18]
Multe stări ale baze de date pot fi construite astfel încât să corespundă unei anumite scheme a bazei de date. De fiecare dată când se introduce sau se șterge o înregistrare sau se schimbă valoarea unui element de date într-o înregistrare, se schimbă o stare a bazei de date într-o alta stare. Distincția între schema bazei de date și starea bazei de date este foarte importantă. Când se definește o nouă bază de date, trebuie specificat schema bazei de date doar pentru sistemul SGBD
3.5.2. ARHITECTURA ȘI INDEPENDENȚA DATELOR SGBD
Trei caracteristici importante ale abordării bazelor de date, sunt:
(1) izolarea programelor și datelor (independență program-date și operare program);
(2) suportul vizualiazării utilizatorilor multiplii;
(3) utilizarea unui catalog pentru a stoca descrierea bazei de date (schemă). [18]
Arhitectura cu trei scheme
Scopul arhitecturii cu trei scheme, este de a separa utilizatorul aplicației de baza de date fizică. În această arhitectură, schemele pot fi definite la următoarele trei nivele:
Nivelul intern are o schemă internă, care descrie structura fizică de stocare a bazei de date. Schema internă utilizează un model fizic de date și descrie procesul complet detaliat despre datele de stocare și căile de acces pentru baza de date.
Nivelul conceptual are o schemă conceptuală, care descrie structura întregii baze de date pentru o comunitate de utilizatori. Schema conceptuală ascunde detaliile fizice ale structurii de stocare și se concentrează pe descrierea entităților, tipuri de date, relații, utilizatori operațiuni și constrângeri. Un model de date de nivel înalt sau un model de date de implementare pot fi utilizate la acest nivel.
Nivelul extern sau de vizualizare include o serie de scheme externe sau vizualizări de utilizator. Fiecare schema externă descrie partea din baza de date pe care un anumit grup de utilizatori îl interesează și ascunde restul bazei de date din acel grup de utilizatori. Un model de date de nivel înalt sau un modelul de date de implementare pot fi utilizate la acest nivel. [18]
Arhitectura cu trei scheme este o unealtă convenabilă pentru ca utilizatorul să vizualizeze nivelurile de schemă într-un sistem de baze de date. Majoritatea sistemelor SGBD nu separă complet cele trei niveluri, dar acceptă într-o anumită măsură arhitectura celor trei scheme. Unele SGBD-uri pot include detalii de nivel fizic în schema conceptuala. În cele mai multe SGBD-uri care acceptă vizualizările utilizatorilor, în aceleași model de date sunt specificate scheme externe care descriu informația la nivel conceptual. Unele SGBD-uri permit diferite modele de date utilizate la nivel conceptual și extern. [18]
Fig. 3.10. Arhitectura client- server pe trei niveluri [26]
Independența datelor
Arhitectura cu trei scheme poate fi folosită pentru a explica conceptul de independență a datelor, care poate fi definită ca fiind capacitatea de a schimba schema la un anumit nivel al unui sistem de baze de date fără a trebui să se schimbe schema de la nivelul următor. Se definesc două tipuri de independență a datelor:
Independența logică a datelor este capacitatea de a schimba schema conceptuală fără a schimba schemele externe sau aplicațiile de programe. Putem schimba schema conceptuală pentru a extinde baza de date (prin adăugarea unui tip de înregistrare sau a unui element de date) sau pentru a reduce baza de date (prin eliminarea unui tip de înregistrare sau a unui element de date). În acest caz, schemele externe care se referă numai la datele rămase, nu ar trebui să fie afectate.
Independența datelor fizice este capacitatea de a schimba schema internă fără a fi nevoie de schimbarea schemelor conceptuale (sau externe). Pot fi necesare modificări la schema internă deoarece anumite fișiere fizice trebuiau reorganizate – de exemplu, prin crearea unei structuri de acces suplimentar – pentru a îmbunătăți performanța recuperării sau actualizării. Dacă aceleași date ca înainte rămân în baza de date, nu ar trebui să schimbăm schema conceptuală.
Arhitectura cu trei scheme poate facilita obținerea independenței a adevăratelor date, atât fizice cât și logice. Cu toate acestea, există puține SGBD-uri ce au implementat arhitectura completă cu trei scheme. [18]
4. ELABORARE PROIECT
4.1. STRUCTURA APLICAȚIEI ȘI A BAZEI DE DATE
Aplicația și baza de date s-au realizat cu ajutorul următoarelor limbaje de programare:
• HTML
• CSS3
• JavaScript
• PHP
• My SQL
HyperTextMarkup Language (HTML) este un limbaj de marcare utilizat pentru crearea paginilor web care sunt afișsate intr-un browser.
Cascading Syle Sheets (CSS3) este un standard pentru formatarea elementelor unui document HTML.
Java Script (JS) este un limbaj de programare orientat obiect bazat pe conceptul prototipurilor.
Hypertext Preprocessor (PHP) este un limbaj de programare folosit pentru producerea paginilor și dezvoltarea aplicațiilor web. [27]
Aplicația este structurată astfel:
Pagina Log In are doua opțiuni: prima oferă posibilitatea utilizatorilor de a se conecta la aplicație iar a doua opțiune este de a accesa o cerere pentru un utilizator nou;
Solicitare utiizator: medicul își introduce datele personale în vederea solicitării unui utilizator nou;
Pagina Principală: oferă acces la o căutare rapidă de diagnostic dar și o cale către o căutare avansată. Conține și butoanele către meniurile de Introducere diagnostic, Administrare și Contact/ Feedback;
Introducere diagnostic: în această pagină medicii introduc date despre un diagnostic nou în baza de date;
Căutare avansată: pagina oferă posibilitatea unei căutări după mai multe criterii unei căutări avansate;
Pagină Rezultat căutare: prezintă variante de boli în urma datelor de intrare pentru căutare;
Pagina Administrare: conține următoarele butoane: Aprobare utilizatori noi, Aprobare diagnostice noi, Listă toți utilizatorii, Listă toate diagnosticele;
Aprobare user: prezintă cererile efectuate de către noii utilizatori care necesită aprobare;
Aprobare diagnostic: prezintă cererile efectuate de catre medici în vederea introducerii unui diagnostic nou în baza de date;
Pagina Feedback/ Contact: oferă posibilitatea acordării unui feedback referitor la utilizarea aplicației dar și informații de contact ae administratorului aplicației.
Baza de date are următoarea structură de tabele:
Tabel 4.1. Listă tabele bază de date
Tabel diagnostice- conține diagnosticele introduse în baza de data;
Tabel 4.2. Tabel diagnostice
Tabel meniu- conține informații ce țin de meniul aplicației;
Tabel 4.3. Tabel meniu
Tabel setări- conține informații referitoare la setările aplicației
Tabel 4.4. Tabel setări
Tabel specialități medicale- conține toate specialitățile medicale introduse în baza de date;
Tabel 4.5. Tabel specialități medicale
Tabel utilizatori- conține datele tuturor utilizatorilor care se înregistrează pentru acces în baza de date;
Tabel 4.6. Tabel utilizatori
Schema relațională a tabelelor bazei de date.
Fig. 4.1. Schema relațională a tabelelor
Variabile folosite:
Varchar(225)- caractere variabile, maxim 225
Int(11)- număr întreg de maxim 11 cifre
Auto_increment- incrementare automată
Text- text
4.2. DESCRIEREA ȘI UTILIZAREA MENIURILOR APLICAȚIEI
Pagina Log In
Utilizatorul se conectează la aplicație prin intermediul adresei web, folosind un browser de internet (de exemplu: Google Chrome, Internet Explorer). Dacă utilizatorul are deja un user înregistrat pe platformă, următorul pas este introducerea numelui de utilizator și a parolei, apoi click pe butonul de acces al bazei de date. Dacă medicul nu are un nume de utilizator cu parolă înscris în aplicație va da click pe butonul ”Solicitare utilizator” pentru crearea unui cont.
Fig. 4.2. Pagină Log In
”Solicitare utilizator”
Meniul ”Solicitare utilizator” conține mai multe câmpuri care trebuie completate în vederea obținerii unui cont pentru accesarea bazei de date. Medicul introduce datele din campurile obligatorii ce se pot oberva în figura 4.2. Apoi se va da click pe butonul ”Trimitere spre aprobare” și așteaptă aprobarea solicitării.
Fig. 4.3. Meniu ”Solicitare utilizator”
”Pagina Pricipală”
Dacă medicul are deja un cont pentru accesare bazei de date, din aplicație, după ce va conecta va ajunge pe pagina principală care conține următoarele elemente:
Un câmp pentru căutarea rapida a diagnosticelor- cu ajutorul acestui câmp diagnosticele pot fi căutate după anumite cuvinte cheie (tag-uri) cu virgule între ele. Dacă se dorește o căutare avansată se va da click pe butonul ”Căutare avansată”;
Un alt buton al paginii principale este ”Introducere diagnostic”- în momentul în care se va da click pe acest buton, utilizatorul va fi direcționat către meniul utilizat la introducerea diagnosticelor;
Butonul ”Administrare”- oferă acces celor care au drepturi de administratori asupra aplicației și a bazei de date, la pagina de administrare;
Ultimul buton de pe pagina principală, ”Contact/ Feedback”- oferă posibilitatea de a accesa pagina cu formularul de feedback și datele de contact ale persoanei care administrează aplicația și baza de date.
Fig. 4.4. ”Pagină Principală”
”Căutare avansată”
În meniul de căutare avansată medicul poate căuta un diagnostic, în primul rând după anumite cuvinte cheie și în al doilea rând selectând anumite opțiuni:
Vârstă pacient- medicul poate selecta intervalul în care se regăsește vârsta pacientului după cum urmează:
– mai mică de 30 de ani
– mai mare de 30 de ani și mai mică de 60 de ani
– mai mare de 60 de ani;
Sexul pacientului:
masculin sau feminin;
Variații în analize sânge:
Mici, medii sau mari;
Variații în analize glande
Mici, medii sau mari;
Variații în analize hormonale:
Mici, medii sau mari;
Analize genetice- se va selecta dacă este obligatoriu ca acestea să fie atașate la diagnostic sau dacă acest lucru este facultativ;
Analize sțânge atașate- se va selecta dacă este obligatoriu ca acestea să fie atașate la diagnostic sau dacă acest lucru este facultativ;
Analize glande atașate- se va selecta dacă este obligatoriu ca acestea să fie atașate la diagnostic sau dacă acest lucru este facultativ;
Analize hormonale atașate- se va selecta dacă este obligatoriu ca acestea să fie atașate la diagnostic sau dacă acest lucru este facultativ;
RMN atașat- se va selecta dacă este obligatoriu ca acestea să fie atașate la diagnostic sau dacă acest lucru este facultativ;
CT atașat- se va selecta dacă este obligatoriu ca acestea să fie atașate la diagnostic sau dacă acest lucru este facultativ;
Ecografie atașat- se va selecta dacă este obligatoriu ca acestea să fie atașate la diagnostic sau dacă acest lucru este facultativ;
Generarea rezultatelor căutării se realizează prin click pe butonul ”Căutare avansată”.
Fig. 4.5. Meniu ”Căutare avansată”
Pagină ”Rezultat căutare- normală sau avansată”
Pe această pagină apare o listă cu diagnosticele existente în baza de date sau potrivit opțiunilor introduse în căutare, făcând click pe butonul de lângă denumirea bolii apare o pagină pop-up (pagină cu toate datele despre boală + butoane pentru download atașamente), aceastp pagină pop-up are un buton care ne întoarce la rezultatul căutării, adică lista cu bolile identificate.
Fig. 4.6. Pagină ”Rezultat căutare avansată sau normală”
”Introducere diagnostic”
Medicul va introduce denumirea bolii cunoscută deja, de către el, în câmpul destinat acesteia.
Un al doilea pas pe care îl va face este acela de a selecta specialitatea în care se încadrează boala respectivă, accesând lista cu selecție de ”Specialități medicale”;
Vârstă pacient- medicul poate selecta intervalul în care se regăsește vârsta pacientului după cum urmează:
– mai mică de 30 de ani
– mai mare de 30 de ani și mai mică de 60 de ani
– mai mare de 60 de ani;
Sexul pacientului:
masculin sau feminin;
Boala, care va fi:
sitematică, genetică sau autoimună;
Va urma introducerea unor cuvinte cheie (maxim 10), fiecare cuvânt fiind atribuit unui singur câmp.
Variații în analize sânge:
Mici, medii sau mari;
Variații în analize glande
Mici, medii sau mari;
Variații în analize hormonale:
Mici, medii sau mari;
Există varianta de atașare a analizelor genetice, de sânge, ale glandelor sau hormonale. De asemenea se pot atașa RMN-ul, CT-ul, ecografii și alte documente relevante.
Un ultimp pas efectuat după introducerea unei boli, se va da click pe butonul ”Trimitere spre aprobare”, către administratori. Un criteriu important este bifarea câmpului care condiționează medicul să confirme ca datele personale ale pacientului să nu fie vizibile. Dacă această casuță nu va fi bifată nu se va putea merge mai departe în îndeplinirea scopului, acela de a introduce un diagnostic.
Fig. 4.7. Meniu ”Introducere diagnostic”
”Administrare”
În figura… observăm pagina de aministrare a licației. Administratorii are rolul de a aproba atât utilizatorii noi înscriși, prin butonul ”Aprobare utilizatori noi”, cât și diagnosticele, prin butonul ”Aprobare diagnostice noi”.
Pentru afișarea tuturor utilizatorilor care există în baza de date este se va da click pe butonul ”Listă toți utilizatorii”. Iar pentru afișarea diagnosticelor introduse în baza de date, se va da click pe butonul ”Listă toate diagnosticele”.
Dacă există situația în care un utilizator fără drepturi administrative, va da click pe butonul ”Administrare”, imediat va aparea o fereastră cu mesajul ”Acces interzis!”. De asemenea pot exista administratori cu drepturi limitate: fie doar dreptul de a aproba utilizatori noi, fie doar dreptul de a aproba diagnostice noi.
Fig. 4.8. Meniu ”Administrare”
”Aprobare user”
Meniul conține lista cu cereri de user și datele personale completate de aceștia. Administratorii pot aproba sau respinge un utilizator și de asemenea poate oferi noilor utilizatori drepturi de administrare.
Fig. 4.9. Meniu ”Aprobare user”
”Aprobare diagnostic”
Meniul conține lista cu cereri de diagnostice și datele despre utilizatorul care le-a introdus. Administratorul va da click pe ”Detalii” și o fereastră pop-up va apărea în care se pot vizualiza detalii despre boală, iar acesta va alege dacă va aproba sau va respinge prin butoanele ”Aprobă” sau ”Respinge”.
Fig. 4.10. Meniu ”Aprobare diagnostic”
”Feedback/ Contact”
În această pagină utilizatorii pot acorda un feedback în privința funcționalității paginii și de asemenea pot contacta administratorul aplicației și a bazei de date prin datele de contact.
Fig. 4.11. Meniu ”Feedback/ Contact”
”Despre”
Această pagină oferă informații despre numele bazei de date, scopul și misiunea acesteia.
Fig. 4.12. Meniu ”Despre”
5. DEFINIEREA STRATEGIEI DE IMPLEMENTARE NAȚIONALĂ
5.1. CONTEXTUL PENTRU IMPLEMENTARE
În vederea impementării a aplicației cu baza de date sunt necesare a fi supuse evaluării două aspecte:
Elementele necesare pentru implementare;
Elementele deja existente în sistemul medical (care pot contribui la facilitarea implementării).
Elementele necesare pentru implementare:
Agrearea și acceptarea bazei de date de către Ministerul Sănătății, în contextul strategiei naționale pentru bolile rare;
Realizarea unei echipe de proiect pluridisciplinară, în cadrul Ministerului Sănătății;
Facilitarea accesului medicilor la baza de date ( înmânarea aplicației);
Școlarizarea medicilor în vederea utilizării aplicației;
Startul utilizării bazei de date.
Elementele deja existente în sistemul medical:
Baze de date deja existente și utilizate de către medici (există experiență în utilizarea bazelor de date);
Servere ale Ministerului Sănătății;
Infrastructura IT;
Experiențe anterioare cu implementarea de srategii la nivel național.
Proiectul descris în prezenta lucrare vine în întâmpinarea concluziilor Congresului EUROPLAN din Noiembrie 2017 de la Zalău, respectiv propunerea realizării Registrului Național Pilot de Boli Rare.
5.2. PAȘII CONCREȚI PENTRU IMPLEMENTARE
Pașii concreți propuși pentru implementarea bazei de date la nivel național sunt:
Aprobarea de către Ministrul Sănătății a implementării în cadrul sitemului de sănătate din România
Se va înainta un memoriu în atenția Ministrului Sănătății care va descrie utilitatea bazei de date în contextul național al bolilor rare, modul de funcționare al aplicației, beneficiile pe care aceasta le aduce, planul de activități, pe scurt, necesare în vederea implementării și elementele ce țin de domeniul IT.
Se va propune ca, în vederea implementării, să fie definit un responsabil la nivel de Ministru Secretar de Stat sau Președinte de Comisie de Specialitate din cadrul Ministerului.
Propunerea va sugera ca implementarea la nivel național să se facă prin implicarea Comisiei de Sănătate Publică si Management formată la 29.01.2018 prin Ordinul nr. 118, al Ministrului Sănătății.
Definirea echipei de proiect la nivel de Minister/ Comisii ale Ministerului
Ținân cont de aspectele ce țin de implementare se propune, așa cum am scris anterior, ca urmărirea și supravegherea implementării, să se facă de o singură comisie, dar echipa de proiect să fie multidiscilinară din mai multe comisii. Astfel se va defini un manager de proiect și membrii ai echipei de proiect responsabili de:
Comunicare, implementare IT, școlarizare/ formare și specialist în boli rare.
Realizare structură proiect
Se va realiza un manual de proiect be baza standardelor internaționale de management al proiectului cu obiective clare și măsurabile încadrate într-un interval de timp definit pentru implementare.
Identificare responsabili la nivel județean
La nivel de județ mai ales în cadrul spitalelor județene, se va facilita realizarea unei echipe restrânse responsabilă de implementarea bazei de date. Managementul spitalelor va putea să aleagă persoanele responsabile de implementare, propunerea este ca responsabilitatea să fie transferată către medicii rezidenți și studenți la medicină sau inginerie medicală. Acest proiect poate să facă parte din procesul lor de învățare.
Stabilire modului de abordare și gestiune IT
Un element important al implementării ține de infrastructura IT. Astfel este necessară o comunicare consistentă între specialișii IT de la nivel de minister și specialiștii IT din județe. Se vor lua decizii referitoare la server-ul gazdă și se va evalua dacă este necesară o mărire a capacității de stocare per servere-le Ministerului Sănătății. Referitor la utilizatorul final, medicii din spitale, aceștia vor putea utiliza infrastructuradeja existentă, calculatoarele din spitale sau inclusiv calculatoarele personale.
Pregătire pachet școlarizare și aplicație și transmiterea către responsabilii din fiecare județ
Aplicația va fi transmisă în județe pe un mediu de stocare (DVD, USB stick) și va fi oferită spre instalare medicilor. De asemenea se va realiza un manual de utilizare cu instrucțiuni pentru facilitarea utilizării bazei de date. Responsabilii din județe pot organiza sesiuni de formare cu medicii ce vor utiliza baza de date.
Perioada de implementare (instalare aplicatie, instruire medici la nivel judetean);
Se va acorda o perioadă pentru obținerea accesului în baza de date și testarea individuală a aplicației.
Testare aplicație la nivel national
Se vor realiza teste la nivel național pentru a se asigura o bună utilizare a bazei de date.
Start utilizare aplicație
Ultimul pas este atunci când baza de date devine acesibilă și poate fi utilizată de către medici în vederea stabilirii corecte a unor diagnostice greu de diagnosticat.
Fig. 5.1 Pașii de implementare a aplicației
CONCLUZII
Pentru lucrarea aceasta pot spune că am creat o echipă pluridisciplinară , am discutat cu medicul de familie Dr. Tăbăcilă Pompilia Ileana și am analizat baza de date pe care o folosește.
Următorul pas pe care l-am făcut a fost comunicarea cu un medic neurolog de la Spitalul de Psihiatrie și Neurologie din Brașov care mi-a oferit informații despre anumite boli rare și a confirmat că ideea realizării unei baze de date pentru boli greu de diagnosticat este utilă și de luat în considerare pe viitor.
Construirea bazei de date și a aplicației a fost realizată împreună cu un programator. Am făcut analiza pe ce există în lume în acest domeniu, am cătat informații despre abordarea bolilor rare în România.
În lume există baze de date și portaluri care vin în ajutorul pacienților care se confruntă cu una dintre miile de boli rare. Aceste platforme oferă suport la nivelul informațional și statistic, însă, ținând cont de concluziile de la Conferința Națională Europlan de la Zalău din noiembrie 2017, România are nevoie de platforme de comunicare și interconectare a medicilor din mediul de stat și privat pe subiectul bolilor rare.
Având în vedere faptul că trăim în era comunicării rapide, online, care este în beneficiul utilizatorilor, educația în legătură cu sănătatea oamenilor a devenit mai bine studiată și împărtășită mai multor persoane. Așadar, baza de date cu boli greu de identificat/ diagnosticat, este o nouă sursă medicală care simplifică munca depusă de medici, oferă o altfel de comunicare între aceștia și scurtează timpul de suferință al pacienților. Această bază de date este ușor de utilizat și diseminat. Cu ajutorul internetului, a site-ului specific bazei de date și a unui laptop, este posibilă conectarea la aplicație. Acela este momentul în care utilizatorul face cunoștiință cu baza de date.
Facultatea Design de Produs și Mediu, specializarea Inginerie Medicală, a avut și are un impact pozitiv asupra studenților prin dezvoltarea creativității și generarea unor idei de viitor precum cea explicată în această lucrare. Urmând această facultate am avut parte de beneficii personale și profesionale raportate la specializarea Inginerie Medicală pe care o consider o direcție de perspectivă și de viitor, raportată la nevoile omenirii.
BIBLIOGRAFIE
1. Kreativfun. [Online] [Cited: 02 14, 2018.] http://www.kreativfun.ro.
2. Melrosegreene. The ink cloud. [Online] 07 12, 2017. [Cited: 02 14, 2018.] https://theinkcloud.wordpress.com/2017/07/12/brain-on-fire-susannah-cahalan/.
3. Orphanet Romania. Orphanet. [Online] [Cited: 03 22, 2018.] http://www.orpha.net/national/RO-RO/index/despre-boli-rare/.
4. National Organization for Rare Disorters. [Online] [Cited: 05 15, 2018.] https://rarediseases.org/.
5. CrowMed. [Online] [Cited: 04 15, 2018.] https://www.crowdmed.com/.
6. European Union Committee of Experts on Rare Diseases . [Online] 2014. [Cited: 04 15, 2018.] http://www.eucerd.eu/.
7. Alianța Națională pentru Boli Rare – România . [Online] [Cited: 04 15, 2018.] http://bolirareromania.ro/.
8. Centrul de Informare pentru Boli Genetice Rare – Asociația PRADER WILLI din România . [Online] [Cited: 04 15, 2018.] http://www.apwromania.ro/.
9. adevarul.ro. [Online] [Cited: 04 15, 2018.] http://adevarul.ro/locale/zalau/conferinta-europlan-2017-ministerul-sanatatii-dezvolta-reteaua-genetica-boli-rare-.
10. Quick base. [Online] 2017. [Cited: 05 23, 2018.] https://www.quickbase.com/articles/timeline-of-database-history.
11. Baze de date medicale- construirea unor interfete utilizator eficiente. [book auth.] M. Marusteri, Monica Suciu, Daniela Dobru P. Olah. Targu Mures : s.n., 2012.
12. Integrarea informatiilor in medicina translationala. Adriana Alexandru, Dora Coardos. 1, Bucuresti : Institutul Național de Cercetare – Dezvoltare în Informatică – ICI București- Revista Română de Informatică și Automatică, 2017, Vol. 27.
13. MED-SHOP. [Online] 2015. [Cited: 04 15, 2018.] http://www.med-shop.ro/stiri-medicale/descoperirile-din-medicina.html.
14. World Health Organization . [Online] [Cited: 05 15, 2018.] http://www.who.int/.
15. Institute for Heath Metrics and Evaluation . [Online] [Cited: 05 15, 2018.] http://www.healthdata.org/gbd.
16. Institutul Național de Sănătate Publică . [Online] [Cited: 05 15, 2018.] http://www.insp.gov.ro/.
17. Casa Națională de Asigurări de Sănătate . [Online] [Cited: 05 15, 2018.] http://www.cnas.ro/.
18. [book auth.] Ramez Elmasri and Shamkant B. Navathe. Fundamentals of Database Systems. Vancouver : Buschlen/ Mowatt, 2000.
19. Computer Daily News. Channelnews. [Online] 04 04, 2018. [Cited: 05 15, 2018.] https://www.channelnews.com.au/government-plans-crackdown-on-data-sharing-by-aussie-groups/.
20. FZI. [Online] [Cited: 05 17, 2018.] https://www.fzi.de/en/about-us/organisation/research-divisions/se-software-engineering/.
21. Baze de date relationale- Teorie si Aplicatii. [book auth.] Cyorody Cornelia. Oradea : TREITRA, 2000.
22. Introduction to Database Systems. [book auth.] Hans- Petter Halvorsen. s.l. : University College of Southeast Norway, 2016.
23. Structured Query Language. [book auth.] Hans- Petter Halvorsen. s.l. : University College of Southeast Norway, 2016.
24. [Online] [Cited: 02 15, 2018.] https://www.cs.uct.ac.za/mit_notes/database/pdfs/chp12.pdf.
25. Radik Chumaren and Linda Wu. aws. [Online] Amazon, 02 21, 2018. [Cited: 04 14, 2018.] https://aws.amazon.com/blogs/database/monitor-amazon-aurora-database-activities-using-datasunrise-database-security/.
26. Jeevitha Murugan. DB Info World. [Online] 11 09, 2014. [Cited: 04 23, 2018.] https://dbinfoworld.wordpress.com/2014/11/09/different-types-of-database-architecture/.
27. Ro.wikipedia.org. [Online] [Cited: 05 29, 2018.] https://ro.wikipedia.org.
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: NAGÎȚ Mădălina Elena [311128] (ID: 311128)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.