Kórházi információs rendszer létrehozása
- Az orvos szakirányzata
- név
- Id- orvos
2.2. A kapcsolatok normalizálása
A kapcsolat normalizálása azt jelenti, hogy kapcsolatot alakítunk ki az úgynevezett normál formák egyikével (NF). Azonban az NF megfontolása előtt néhány szót kell mondanunk, miért szükséges a normalizálás.
Az adatbázis stabil állapotban történő fenntartásához számos olyan mechanizmust használnak, amelyek az integritási támogatás általános nevét kapták. Ezeket a mechanizmusokat statikusan (az adatbázis tervezési szakaszában) és dinamikusan (az adatbázisban való munkában) használják. Nézzük
Figyelembe kell venni azokat a korlátokat, amelyeket az adatbázisnak a tartalom létrehozásától függetlenül meg kell felelnie a létrehozás folyamatában. Az adatbázis szerkezetének ezekkel a korlátozásokkal való összehozása az a normalizáció.
Miután meghatározta az egyes entitásokat, meghatározhatja annak attribútumait.
Minden páciensnek az alábbi információk vannak:
Minden beteget egy adott lakóhelyen jegyeznek be: Index
Ha a páciens kórházba kerül, megbeszélést kap, jelezve:
- A recepció nyilvántartási száma
- Id- beteg
- Id- orvos
- A vétel dátuma
- A beteg biztosítási kötvényszáma
Az orvos rendelkezik a paraméterekkel:
- Id-orvos
- Passport sorozat
- Útlevél száma
- szakosodás
- Szakirány kód
- Licencszám
- Születési ideje
- Az orvos neve
- Az orvos neve
- Az orvos védnöksége
Ebben az esetben az orvos szakosodott, amely a következő információkat tartalmazza:
- Az orvos szakirányzata
- név
- Id- orvos
Ebben a szakaszban a kapcsolatszerkezet az első normál forma (1NF), mert attribútum értékek atomok, és az összes nem kulcs attribútum funkcionálisan függ a kulcstól.
Próbáljuk megteremteni a kapcsolatot a második normál formához (2NF).
Ehhez megkülönböztetjük a következő funkcionális függőséget:
Tekintsünk egy olyan kapcsolatot, amely szimulálja az orvoshoz intézett írásmódot. Ennek a kapcsolatnak a struktúráját a következő tulajdonságok határozzák meg:
(A befogadók regisztrációs száma, id-páciens, id-orvos, a felvétel dátuma, a beteg biztosítási kötvényének száma)
A kapcsolat elsődleges kulcsa lehet (a befogadás regisztrációs száma, a beteg biztosítási kötvényének száma), amely egyedileg azonosítja az egyes kapcsolódási sorokat. Másrészt az FIO attribútumai csak az elsődleges kulcsnak - a beteg TIN-jének - függenek, ezért ahhoz, hogy ezt a kapcsolatot a második normális alakhoz hozzák, azt előrejelzésekre kell bontani.
Így a következő két kapcsolatunk van:
(A beteg biztosítási kötvényének száma, utónév, név, utónév)
(A befogadóképesség azonosító száma, Id-patient, Id-doctor, A befogadás dátuma)
Ez a kapcsolatrendszer nem hiányos funkcionális függőségek, ezért a második rendes formában van.
Most próbáljuk meggyőzni a hozzáállást a harmadik normálisra
Tekintsük az orvos és a beteg közötti kapcsolatot:
- (Beteg neve, beteg neve, védőszövetség címzettje, betegbiztosítási kötvény száma, felvételi dátum, id beteg, orvos neve, orvos neve, orvos neve, védjegy neve, szakorvosi kódex, engedély száma)
E kapcsolat elsődleges kulcsa a beteg biztosítási kötvényének száma, de érdemes más funkcionális függőségeket figyelembe venni:
Betegbiztosítási kötvény száma → Beteg neve, Beteg neve, Patron középső neve
Betegbiztosítási kötvény száma → Beteg Id
A beteg biztosítási kötvényének száma → Id-doctor
Doktori engedély száma → Doktori szakirány kód
Doktori engedély száma → Orvos neve, orvos neve, az orvos patronímiája
Ezen függõségek többsége átmeneti csoportokat alkot, ennek elkerülése érdekében meg kell különböztetni az ilyen viszonyokat:
(Betegbiztosítási kötvény száma, Beteg neve, Beteg neve, Védett középnév, befogadás dátuma)
(Id-orvos, orvosi engedély száma, orvosi szakirány, orvos neve, orvos neve, orvos középső neve)
(A felvétel nyilvántartási száma, a beteg biztosítási kötvényének száma, a felvétel időpontja)
Az elsődleges kapcsolattartó gombok kiemelve vannak.
2.3. Az adatmodell fejlesztése "Kórházi tevékenységek"
Az adatmodell az All Fusion ERWIN adatmodellezőn keresztül valósult meg az entitások, kapcsolatok és attribútumok meghatározásával (10.
10. ábra. Adatok adatmodellje "Kórházi tevékenységek"
Fizikai adatok modell ezzel szemben függ a konkrét adatbázis rendszer katalógus valójában jelenik meg. A fizikai modell minden adatbázis objektumról tartalmaz információt. Mivel nincs DB-objektumok szabványa, a fizikai modell a DBMS konkrét végrehajtásától függ. Következésképpen számos különböző fizikai modell ugyanazt a logikai modellt illeti. Ha a logikai modell nem számít, melyik adott típusú adatot attribútummal, a fizikai modell fontos információkat ismerteti a konkrét fizikai objektumok - .. A táblák, oszlopok, indexek, eljárások, stb az adatok elkülönítését modell logikai és fizikai megoldja több fontos feladatokat.
Az alábbi listát a CA ERwin Data Modeler alkalmazásával hajtottuk végre, a kapcsolat ODBC / Generic (1. függelék) segítségével történt. A kódot a főmenüből hozták létre: Tools -> Forward Engineer -> Séma generáció. Ezután válassza ki az Előnézet gombot az ablakban. És megkapjuk az utolsó listát.
2.5. Az információs rendszer architektúrája
Az ügyfél-kiszolgáló az egyik legdinamikusabban fejlődő technológia a többszintű EIS kiépítéséhez.
A kiszolgáló logikai folyamat, amely szolgáltatásokat nyújt a folyamatok megkereséséhez és a munka eredményeinek visszaadásához. Számos szerver típus létezik, amelyek különböznek a szolgáltatáskészletben (általában bizonyos információk vagy számítási erőforrások elérése). Az ügyfél olyan folyamat, amely kérést küld a kiszolgálónak egy szolgáltatásért. A gyakorlatban a szoftverrendszer szétválasztása több, egymással kölcsönhatásban lévő komponenssel történik, amelyek ugyanakkor kliensként vagy kiszolgálóként, kliensként és kiszolgálóként működhetnek. Különösen háromszintű architektúrát fogunk megvizsgálni, ahol van egy harmadik elem, például egy alkalmazáskiszolgáló.
Az ügyfél a szerverrel szigorúan meghatározott algoritmus szerint működik együtt:
· Kommunikáció létrehozása a szerverrel;
· Egy adott típusú szolgáltatás igénylése;
· A keresési eredmények fogadása a kiszolgálóról az alkalmazáskiszolgálón keresztül;
· Kapcsolódás a kiszolgálóról.
Egy megoldás az elosztott struktúrájú vállalatok számára.
A rendszer architektúrája olyan speciális eszközöket tartalmaz, amelyek lehetővé teszik egy egységes, könnyen kezelhető megoldást a területileg elosztott struktúrájú vállalkozások (területi távoli fiókok) számára.
A Távol-Keletről származó felhasználók például St. Petersburgban működő rendszerrel dolgozhatnak. Az ilyen kapcsolat különböző kommunikációs csatornákon keresztül szervezhető, beleértve a műholdakat is.
12. ábra. Adatbázis művelet egy háromszintű modellben
A háromszintű modell egy általános verzió, amelyben minden alkalmazás külön számítógépen fut. Az ilyen rendszer előnyei a rugalmasság, méretezhetőség, magas biztonság, nagy megbízhatóság, terheléskiegyenlítés, sebességnövelés és sokoldalúság.
2.6. Az adatok közzététele az interneten az "kórházi tevékenységek" IP keretében
- Hozzáférés a WEB felületen keresztül
- Az FTP protokoll végrehajtása, ahol az adatbázis közvetlenül működik
- Adatbázis közzététele az FTP protokollon.
Az FTP-t használó kiszolgálóval használható programok: