- Codul de specializare al medicului
- nume
- medicul ID-
2.2.Normalizarea relațiilor
Normalizarea unei relații înseamnă procesul de a aduce o relație la una dintre așa-numitele forme normale (NF). Cu toate acestea, înainte de a analiza NF, ar trebui să spunem câteva cuvinte, de ce este necesară normalizarea.
Pentru a menține o bază de date într-o stare stabilă, se utilizează un număr de mecanisme care au primit un nume general pentru suportul de integritate. Aceste mecanisme sunt utilizate atât static (la etapa de proiectare a bazei de date) cât și dinamic (în procesul de lucru cu baza de date). Să ne
atenție la acele constrângeri pe care baza de date trebuie să le satisfacă în procesul de creare, indiferent de conținutul său. Aducerea structurii bazei de date în conformitate cu aceste restricții este ceea ce este normalizarea.
După ce ați definit fiecare entitate, puteți defini un set de atribute ale acesteia.
Fiecare pacient are următorul set de informații:
Fiecare pacient este înregistrat la un anumit loc de domiciliu: Index
Dacă pacientul vine la spital, i se dă o întâlnire, indicând:
- Numărul de înregistrare al recepției
- pacient ID-
- medicul ID-
- Data primirii
- Numărul poliței de asigurare a pacientului
Medicul are parametrii:
- Id-medic
- Seria de pașapoarte
- Numărul pașaportului
- specializare
- Cod de specializare
- Numărul licenței
- Data nașterii
- Numele medicului
- Numele medicului
- Patronajul medicului
În acest caz, medicul are o specializare, care are următorul set de informații:
- Codul de specializare al medicului
- nume
- medicul ID-
În această etapă, structura relației este în prima formă normală (1NF), deoarece atributele atomice și toate atributele non-cheie sunt funcțional dependente de cheie.
Să încercăm să aducem relația la a doua formă normală (2NF).
Pentru a face acest lucru, distingem următoarele dependențe funcționale:
Luați în considerare o relație care simulează procesul de scriere la un medic. Structura acestei relații este determinată de următorul set de atribute:
(Numărul de înregistrare a recepției, Id-pacient, Id-doctor, data de admitere, Nr. Poliței de asigurare a pacientului)
Cheia primară a relației poate fi (numărul de înregistrare al primirii, numărul politicii de asigurare a pacientului), care identifică în mod unic fiecare linie de relație. Pe de altă parte, atributele FIO depind numai de partea cheii primare - TIN a pacientului, prin urmare, pentru a aduce această relație la a doua formă normală, ar trebui împărțită în proiecții.
Astfel, avem următoarele două relații:
(Nr de poliță de asigurare a pacientului, nume, nume, patronimic)
(Numărul de înregistrare a recepției, Id-pacient, Id-doctor, Data primirii)
Acest set de relații nu are dependențe funcționale incomplete și, prin urmare, se află în a doua formă normală.
Acum, să încercăm să aducem atitudinea la cea de-a treia normală
Luați în considerare relația dintre medic și pacient:
- (Numele pacientului, numele pacientului, patronimul patronului, numărul de poliță de asigurare a pacientului, data admiterii, pacientul, medicul id, numele medicului, numele medicului, numele patronului, codul de specialitate, numărul licenței)
Cheia primară a acestei relații este numărul de polițe de asigurare al pacientului, dar merită luate în considerare și alte dependențe funcționale:
Numărul de poliță de asigurare a pacientului → Numele pacientului, numele pacientului, numele intermediar al Patronului
Numărul de poliță de asigurare a pacientului → ID pacient
Nr. De poliță de asigurare a pacientului → Id-doctor
Numărul licenței de medic → Codul de specializare al doctorului
Numărul licenței doctorului → Numele medicului, numele medicului, Patronimicul medicului
Cele mai multe dintre aceste dependențe formează grupuri transitive, pentru a evita acest lucru, trebuie să distingem astfel de seturi de relații:
(Numărul poliței de asigurare a pacientului, numele pacientului, numele pacientului, numele intermediar al Patronului, data admiterii)
(Id-doctor, număr de licență, cod de medic specialist, numele medicului, numele medicului, numele intermediar al medicului)
(Numărul de înregistrare al admiterii, numărul politicii de asigurare a pacientului, data admiterii)
Principalele chei de relație sunt evidențiate.
2.3. Elaborarea unui model de date de date "Activități de spital"
Modelul de date a fost implementat prin ERWIN Data Modeler prin definirea entităților, a relațiilor și a atributelor (Figura 10).
Figura 10. Modelul de date al datelor "Activități spitalicești"
Modelul de date fizic, dimpotrivă, depinde de SGBD special, fiind de fapt un afișaj al catalogului de sistem. Modelul fizic conține informații despre toate obiectele bazei de date. Deoarece nu există standarde pentru obiectele DB, modelul fizic depinde de implementarea specifică a DBMS. În consecință, mai multe modele fizice diferite pot corespunde aceluiași model logic. În cazul în care modelul logic nu contează ce tip specific de date are un atribut, modelul fizic este important să se descrie informațiile privind anumite obiecte fizice - .. Tabelele, coloane, indici, proceduri, etc. Separarea modelului de date la logică și fizică rezolvă mai multe sarcini importante.
Listarea de mai jos este implementată utilizând CA ERwin Data Modeler, conexiunea a fost realizată prin intermediul ODBC / Generic (Anexa # 1). Codul a fost generat prin meniul principal: Tools -> Inward Engineer -> Generarea schemei. Apoi, selectați butonul Preview din fereastră. Și avem lista finală.
2.5 Arhitectura sistemului informatic
Client-server este una dintre cele mai dinamice tehnologii de dezvoltare pentru construirea EIS multi-nivel.
Un server este un proces logic care oferă servicii la solicitarea proceselor și returnează rezultatele muncii. Există mai multe tipuri de servere care diferă în setul de servicii furnizate (de obicei accesând o anumită informație sau o resursă de calcul). Un client este un proces care trimite o solicitare serverului pentru un serviciu. În practică, există o separare a sistemului software de mai multe componente care interacționează, care la rândul său pot acționa ca un client sau un server sau un client și un server în același timp. În particular, vom lua în considerare o arhitectură pe trei niveluri, în care există un al treilea element, cum ar fi un server de aplicații.
Clientul interacționează cu serverul conform unui algoritm strict definit:
· Stabilirea comunicării cu serverul;
· Solicitarea unui tip specific de servicii;
· Primirea rezultatelor interogării de la server prin serverul de aplicații;
· Deconectarea de la server.
O soluție pentru companii cu structură distribuită.
Arhitectura sistemului include instrumente speciale care permit crearea unei singure soluții ușor de gestionat pentru întreprinderile cu structură distribuită teritorial (ramificații teritorială la distanță).
Utilizatorii, de exemplu, din Orientul Îndepărtat, pot lucra cu un sistem situat în St. Petersburg. O astfel de conexiune poate fi organizată prin diferite canale de comunicare, inclusiv prin satelit.
Figura 12. Funcționarea bazei de date într-un model pe trei niveluri
Modelul pe trei niveluri este o versiune generică, în care fiecare aplicație este implementată pe un computer separat. Avantajele unui astfel de sistem sunt flexibilitatea, scalabilitatea, siguranța ridicată, fiabilitatea ridicată, echilibrarea încărcării, creșterea vitezei și versatilitatea.
2.6.Publicarea datelor pe Internet în cadrul activităților de spital "IP"
- Acces prin interfața WEB
- Implementarea protocolului FTP, unde veți lucra direct cu baza de date
- Publicați baza de date pe protocolul FTP.
Programele recomandate pentru utilizarea cu server folosind FTP sunt: