Diskuze: DB - Hospital Managment System
V předchozím kvízu, Online test znalostí SQL a databází, jsme si ověřili nabyté zkušenosti z kurzu.

Člen

Zobrazeno 41 zpráv z 41.
//= Settings::TRACKING_CODE_B ?> //= Settings::TRACKING_CODE ?>
V předchozím kvízu, Online test znalostí SQL a databází, jsme si ověřili nabyté zkušenosti z kurzu.
Do tabulky "pacient" bych přidal ID(identity 1,1) jako PK, nikde nevidím
vazební tabulky na vazbu M:N (pacient-lékař), nikde nevidím vazbu mezi
tabulkami lékař a typ_lékaře...
Tabulka "umístění" nemá žádné FK, které tvoří vazbu na pacienta ani na
pokoj
Tabulka "cena" mi přijde naprosto zbytečná a jak tak na to koukám, celkově mi v těch tabulkách chybí nějaké FK, které by znázorňovaly vazby mezi tabulkami...
Děkuji za reakci. Jedná se o Entitní diagram, nikoli relační diagram, to
jsem zapomněl zmínit. Relační diagram sestavím na základě toho, tam
dodám ty FK a propojení mezi tabulkami.
Umístění mám definované jakožto kompozitní primární klíč - tj datem a
rodným číslem pacienta (což je jeho primární klíč), v relačním
diagramu potom umístění bude mít FK pokoj_id.
Cenu tam mám, aby se dalo spočítat, jak moc nemocnice vydělala na daném pacientovi. Co jsem informován, tak dostávají za to prachy, podle toho, co provedou za úkony(vyšetření) a za léky.
Cena se může spočítat (když je to potřeba) z jiných tabulek. Mít na to extra tabulku mi přijde zbytečné. Nicméně tam chybí ty vazební tabulky, např. mezi lékařem a pacientem
A jakou vazební tabulku máš na mysli? Jakože pacient_lékař, kde bude pk1, fk1 pacient_rč(id) a pk2,fk2 lékař_id?
Tabulku, kde bude ID, ID_pacient, ID_lekar
protože jeden pacient může mít více lékařů a zároveň jeden lékař
bude asi mít víc pacientů...
A hlavně bych do tabulky "Pacient" přidal to ID, protože RČ není zrovna
nejlepší "identifikátor" jako primární klíč...
Ne v každé zemi si "hrají" na rodná čísla, někdy se může vyskytnout i
duplicita (nemělo by to být, ale stává se)...
Další, co mě při pohledu na diagram napadlo, že bych asi nedával do tabulky lékařů tu položku plat, protože plat se může změnit a jestli se na tu položku bude vázat nějaký výpočet, tak při změně platu nebudou výsledky souhlasit, nehledě k tomu, že nebudeš mít historii vývoje výpočtů...
A jak by jsi změnil tu cenu, aby zároven mohla být zařazena do ceníku, který je platný nějaké časové období? A pokud máme na mysli to samé s těmi vazebními tabulkami, tak by měli být i mezi účtem - lék/léčba?
Díky
Mě příjde divné ta vazba mezi léčbou a cenou. Léčba přece nemá
tabulkové hodnoty, aspoň tak si to myslím.
Potom by v ceníku rozhodně měla být cena.
Dále asi nemá smysl v kontextu léčby uvažovat o sumě.
Plat lékaře bych dal mimo, jak už bylo řečeno. Podobně jako ceník - od,
do, kolik.
Pacienta bych neidentifikoval ID, to například cizinci vůbec nemají. Klidně
tam dej ID.
Také si myslím, že na jenom pokoji může být více pacientů, teď to
povoluje pouze jednoho.
Oddělení bych identifikoval pomocí ID, ne jeho názvem.
To je vše co mě tak napadá, parcialitu už se mi kontrolovat nechtělo.
To Michal Štěpánek: tohle není relační návrh, dekompozice N:M vazby a cizí klíče se nepíší.
Trošku jsem nerozuměl této větě:
Pacienta bych neidentifikoval ID, to například cizinci vůbec nemají. Klidně tam dej ID.
Nemělo to být: "Pacienta bych neidentifikoval RČ..."?
Já tu tvou tabulku "Cena" chápu jako extra tabulku, kde chceš mít
nějaké součty za nějaké výkony, či platby. To mi přijde zbytečné,
protože podle mě budeš chtít potom nějaké součty s konkrétními
parametry (datum, pacient, lékař, výkon...) a to z této tabulky stejně
nevyčteš... Spíš bych udělal nějakou tabulku "výkonů" nebo "prodejů"
(dalo by se to asi i sloučit), kde by bylo třeba "kdo", "kdy", "co" a "za
kolik" a z této tabulky pak jednoduše vytáhneš potřebné údaje... Položka
"cena" samozřejmě patří do ceníku a měla by být vázána na nějaký
výkon, nebo nějaké zboží(léky) a v ideálním případě by měla mít
nějakou platnost, abys mohl sledovat i jakýsi vývoj cen a mít historii.
Při programování by ses měl na aplikaci vždycky podívat jakoby "od konce".
Zjistit, jaká data či údaje by ta appka měla umět vyplivnout a podle toho
zjistíš, jaké údaje tam musíš "nacpat"...
Díky , parcialitu opravím,
id přidám k oddělení a k pacientovi. Co se týká té léčby... Dozvěděl
jsem se, že nemocnice (V ČR) je placena podle toho, jakou léčbu/výkony se
provádějí a také jaké léky nasazují. Podle toho dostávají peníze od
pojištovny. Proto mám léčbu spojenou s cenou, protože je to podobný jako s
těmi léky si myslím... Co myslíš tím, že by v ceníku měla být cena?
Ceník v té tabulce je tvořen cenami platnými dle dat v ceníku.
Bohužel úplně stále nechápu, jak to myslíš v modelu výše mám účet, kde mám
KOMU, KDO, KDY a cenu potom mám přiřazenou k léčbám a lékům. Čili
myslíš, jako tuhle celou konstrukci zničit (účet) a udělat KDO, KDY, ZA
KOLIK ? a jak do toho dostanu tu cenu za nějaký produkt?
Díky
V tom tvém diagramu vidím "účet" a tam je jen ID, datum.
Tento typ diagramu jsem si nikdy nedělal, protože pro mě je
"nicneříkající". Dělal jsem si jen diagram, kde byly jednotlivé tabulky a
konkrétní vazby mezi nimi...
v modelu výše mám účet, kde mám KOMU, KDO, KDY a cenu potom mám přiřazenou k léčbám a lékům.
Pokud nebudeš mít v té tabulce "výkonů" i konkrétní částku, pak nemusíš mít správné výpočty. Když se ti ceníková cena změní, bude se to přepočítávat (pokud to neošetříš složitými konstrukcemi hledání konkrétní ceny) k aktuální ceně a ne k ceně platné v době výkonu.
A myslíš že to je nicneříkající? Návrhy se učím, tak rád přijmu nové rady, jak to udělat lépe.
Ale abych řekl k myšlence toho účtu:
Třeba v nemocnici - vyskočí okénko, kde lékař bude muset vypsat - Pacienta
(což bude patient_id FK), Lékaře, co to podepsal (lékař_id FK), datum bude
vytvořen automaticky při vytvoření a id bude nějaké originální pro tu
"transakci" řekněme. Poté se do toho účtu nahážou všechny léky/léčby,
co jsou předepsané - čili tam potom budou nějaké asociační entity mezi
účtem a lékem/léčbou, kde bude třeba účet id - 123 lék_id - 1 a v
druhé asociační mezi účtem a výkonem bude - účet_id 123 a léčba_id 3 -
čili potom ve finále máme účet o nějakém datumu, lékaři, pacientovi,
které mu jsou přiřazeno x léků, x výkonů a cenu mají ty jednotlivé
výkony přiřazené třeba tou pojištovnou...
PS: Mohl bych tě ještě poprosit, jak by jsi tu entitu "účet" předělal,
aby přímo v tom byla ta cena...?
Čili navrhuješ přidat k entitě Lék/Léčba atribut cena? a jak potom zajistím tu ceníkovou cenu? Jakože Léčba/Lék budou rovnou vázané na ceník?
Někomu ten diagram může přijít jako užitečný, ovšem já bych z něj
nevyčetl v podstatě nic. Pro mě je důležité, abych v tom diagramu viděl
jednotlivé vazby mezi tabulkami a jednotlivé položky tabulek včetně PK a
FK.
V tabulce "účet" bych já chtěl mít třeba toto:
možná mě napadne i něco dalšího, co by se tam mohlo hodit, ale tohle mi přijde jako takový základ pro výpočet nějakého výdělku a pro reporty...
Dobře, hodím sem ještě relační diagram.
Mám tam vše, kromě množství a té ceny.
Čili bylo by možná dobré, rozbít m : n vazbu mezi lékem a účtem a
dát tam entitu množství? jakožto asociační entitu?
A co s tou cenou? jak jí dostanu do toho účtu?
V první řadě bych ale zrušil to RČ u pacienta jako identifikátor a dal bych tam ID (identity 1,1), protože u prvního cizince budeš v pytli.
a ještě jedna, měl jsem tam ještě blbě ty klíče propojené
účet_lék a účet_léčba bych zrušil, podle mě jsou k ničemu, protože
každý řádek v "účtu" bude reprezentovat záznam jen na jeden lék, či na
jeden lék. výkon...
A pořád jsem nějak nepochopil smysl těch tvých tabulek "cena" a
"ceník".
No, já měl za to, že mezi nimi bude m : n vazba - že účet může mít několik léků a léky mohou být ve více účtech. Nebo to tak není? A nebo místo toho lék_účet by možná šla dát ta entita Množství? nebo přímo do toho účtu?
A jak v tom potom vypočtu tu sumu v tom účtu?
No cena je přiřazena léčbě a lékům podle platného ceníku (OD-DO), aby se potom dalo historicky hledat? Nebo je to špatný přístup? Že se ceny budou měnit podle toho ceníku...
Jinými slovy, jak pak zajistím, že když řekněme, že na pacientovi budou provedeny DVA výkony a budou me třeba naordinovány 3 léčby (RTG, obvaz, odběr krve), jak to všechno narvu do jednoho účtu, když tam bude jen místo pro jeden?
Jedna položka v účtu = jedna položka léků nebo výkonu.
Celkovou sumu pak jednoduše sečteš podle zadaných kritérií
Pak jedině, že bys měl další tabulku, kde by byly "položky účtu" a v
tabulce "účet" by byl jen ID, datum, lékař, pacient a celková suma, možná
případně nějaká poznámka.
A tabulka "položky_účtu" by měla jako FK ID_účtu.
Takto myslíš? A jak ted tam dostanu to množství? a jak spočtu tu sumu v účtu?
V podstatě jo, jen nevím, co všechno máš za položky v tom "položky_účtu. Rozhodně bych tam dal nějaký čas pro výkon, množství konkrétního léku, atd...
Ok děkuji. Čili do toho položky_učtu ještě vložím to množství a čas... a jak ještě spočtu tu cenu z takto uspořádaných tabulek, abych měl v tom suma v účte tu celkovou sumu? Třeba za 5 léků a třeba za léčbu RTG, odběr krve. Jak to tam dostanu ted?
A ještě... v tom Položky_účtu nemůžu mít jako ID účet_ID, protože mi to pak vyhodí duplicate-primary key. Co tam za primární klíč?
Sumu jednoduše spočítáš z těch položek při ukončování/ukládání
toho účtu...
Při ukládání jednotlivých položek zjistíš jednotkovou cenu v ceníku,
vynásobíš to počtem kusů/hodin a uložíš cenu za položku (to by měl
být další sloupec v tabulce "položky_účtu"). Při ukládání účtu je
pak jen sečteš...
V "položky_účtu" bude PK normální ID, účet_ID bude FK
a lze to nějak nastavit tu sumu, abych to viděl automaticky v těch tabulkách? že to tam sql propočítá automaticky? např v mysql? Nebo to až pak zjistím (tu sumu) na základě sql dotazu?
A k tomu položky_účtu - neměly by být FK i Lék, Léčba, Účet? A nešlo by udělat ID ze všech těhle 3? Jakože by byly všichni PK, FK - účet_ID,lék_id, léčba_id ? nebo je lepší tam dát takhle to id prostě?
Díky moc
SELECT p.rč, Sum(le.cena_cena) cena_za_léčbu, (Sum(l.cena_cena*pu.množství_léku)) cena_za_léky FROM Pacient p
JOIN účet u
ON p.rč = u.pacient_rč
JOIN položky_účtu pu
ON u.id = pu.účet_id
JOIN Lék l
ON pu.lék_id = l.id
JOIN Léčba le
ON pu.léčba_id = le.id
where p.rč = '9511151321'
GROUP BY p.rč;
Tímhle způsobem dostanu celkovou sumu za léky a léčbu (ps: v mysql mám pacienta identifikovaného přes rč)
Sumu za jednotlivé výkony (nebo prodej) budeš mít v každém řádku v
tabulce "položky_účtu". Celkovou sumu pak budeš mít v tabulce "účet".
Identifikace podle RČ je ten nejméně vhodný způsob, psal jsem ti to už
několikrát (a nejen já).Cizince identifikuješ jak, když RČ nemají?
P.S. to "GROUP BY" tam je proč?
pacient: pacient_id, dalsi data - zadne rodne cislo jako id!!!
pokoj: pokoj_id, dalsi data (cislo dveri..., oddeleni_id)
vazebni pokoj_pacient (tve umisteni): pokoj_id, pacient_id, dalsi data (od-do,
kdo zaznam vytvoril,... kdo zaznam ukoncil --- treba pri premisteni pacienta,
chtel bys dohledat, kdo naridil zmen pokoje)
To mas ok.
A stejnym zpusobem treba ale postupovat pro to ostatni. Logicke celky k
sobe.
lek: lek_id, dalsi data (nazev, cena, popis) - to by mel byt katalog leku
Pacient dostane recept. Kdo, kdy vystavil pro koho. Ten propojis pres tabulku s
lek_id / recept_id.
Nechapu, na co tam mas tabulky jako cenik, cena. Preci, cena je soucasti
katalogu leku. Celkova cena za recept je soucasti receptu. Pripadne, na pokladne
by to byl vydejni doklad, opet propojeny na katalog leku.
Jakoze lekar vystavi recept - propojeno na seznam leku.
V lekarne vystavi uctenku, propojene na seznam leku s cenou.
Idealne, kdyby oba seznamy byly stejne. Nebo, kdyz by mely stejna id nebo aspon
stejne nazvy polozek. Coz ale presne prakticky nebyva, lekar a lekarna jsou jina
firma, vlastni seznamy Takhle
tezko rici, jak to navrhovat.
Take muzou byt na zbozi ruzne akce. Ruzne kategorie pacientu s ruznymi slevami.
Jo, uvazuj tak, aby tabulkove udaje mohli editovat v excelu. Leky s cenou,
Lekare, Pacienty, Oddeleni, Pokoje. Pokud mas cenu u leku mimo tabulku leku, tak
se to bude hrozne spatne editovat. Jako, e-shopove.
Pokud ma cenik vice cen pro ruzne skupiny, tak bych tam dal u leku vice sloupcu.
Opet, kdyz to budes chtit editovat v excelu, tak tak to mas pohromade. Nebo
udelej spesl tabulku se skupinami, kde das treba 5% slevu pro zamestnance na
kategorii leky.
Mozna by ses mohl na to vykaslat a rovnou si nainstalovat nektery z free
e-shop Ten resi tu obchodni
cast. A tobe by zbylo resit jen tu cast s recepty. A slo by vyuzit tabulky leku
z toho eshopu.
zpravy> kolik jaký pacient vydělal nemocnici a jaká mu byla nasazena
léčba, kdo ji nasadil a kolik stála. + samozřejmě ta dolní větev.
zpravy> https://ibb.co/mwKEt8
Hele, tak, jestli je to, jak popisujes, pak mas trochu jine tabulky.
Cili by mela byt tabulka
id_lecba - moznost 1 - lek 1
id_lecba - moznost 1 - lek 2
id_lecba - moznost 2 - lek 3
Jakoze treba pacienta muzes poslat na chemo, ale taky ne. Nebo mu staci nasadit
jenom leky.
Samotna lecba muze neco stat, leky take muzou neco stat. Ted je jeste otazka,
kolik lecby leku pacient dostane.
A ono je to tezko rici, zda to ma fungovat presne takhle. Protoze o lecbe
rozhoduje lekar, neni to tabulkova hodnota. Lekar vidi, ze mu neco nezabira, tak
tu lecbu zrusi, nasadi jinou.
Takze bys mozna mel vest zvlast tabulku, co nasadil lekar a kolik z te lecby
pacient dostal. Takze mozna udelat individualne neco jako vydejni doklad z
pokladny. Pacienta propojis s chemo, skenem, s nejakym lekem, poctem. Tady zas
treba vedet, jakym zpusobem dana lecba fungue, do jakych tabulek sloupcu, co
vyplnit. Treba u elmg. rezonance nemocnici nezajima, jak dlouho bezel pocitac,
ale jak dlouho bezel skener, protoze ten zere mnohonasobne vice energie. Cili to
bude nejaka tabulka cas + zarizeni. Kdezto u leku te zajima treba pocet kusu +
lek nebo pocet mililitru + lek.
Hele, a delas to jako komercne nebo je to skolni uloha? Protoze, mozna ti to zbytecne zeslozituji temi uvahami.
Mozna, ze tabulka ucet by mela byt jen vysledek sql dotazu.
Mozna bych resil tabulku ucet jako vazebni, takto
pacient_id | lecba_id | lek_id | kusu | ml | datum-cas-od | datum-cas-do | mozna i id_lekar
'pepa' | 'elmg rezonance' | - | - | - | 15.2.2018 6:30 | ...15:30
- | 'penicilin' | 3 | - | 15.2.2018 6:30 | ...15:30 - treba 2 dny dostaval lek, pak uz ne (nektere leky se cas vstrebavaji, takze nektere nelze nasadit hned po jinych, ale musi se pockat)
- | 'adrenalin' | - | 30 | 15.2.2018 6:30 | ...15:30 - tady by se uvedl zacatek mozna i konec operace
Zobrazeno 41 zpráv z 41.