Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: Nuada 09. 05. 2015, 15:02:25
-
Dobrý den,
dělám na entitně relačním diagramu pacienta. Ocenil bych pár rad a tipů, zrovna si nejsem jistý u entity DOKTOR. Jestli bude spojená s entitami PODANÉ_LÉKY a PROVEDENÝ_ZÁKROK.
https://drive.google.com/file/d/0BzE_t0crYrojYkk1S3B4QjFPeGM/view?usp=sharing (https://drive.google.com/file/d/0BzE_t0crYrojYkk1S3B4QjFPeGM/view?usp=sharing)
-
Řekl bych, že velmi záleží k jaké účelu budou data sloužit a jaká se za tím skrývá business logika
Příklad #1: pokud jde pouze o výkaznictví pojišťovně, pak nemusí (možná) být nutné rozlišovat mezi lékem a zákrokem. Je to prostě "úkon k proplacení" a je na pojišťovně, ať si to roztřídí, jestli to potřeba (leda, že pojišťovna a její business logika říká jinak)
Příklad #2: Business logika možná bude říkat, že ke konkrétnímu zákroku patří konkrétní medikace, např. To je třeba si zjistit...
-
Spíše je to myšleno jako Příklad #1: výkaznictví.
Doktora tam chci zakomponovat, abych se potom mohl databáze dotázat: Jaký doktor koho ošetřil a co provedl za zákrok případně jaké podal léky. Ale to bude asi jasné podle atributů v entitě OŠETŘENÍ. Když v určitý [datum/konkrétní čas] byl ošetřen [PACIENT] tímto [DOKTOR] rovnou poznám jak doktor postupoval. Tak je asi blbost spojovat [DOKTOR] s [PODANÉ_LÉKY] a [PROVEDENÝ_ZÁKROK].
-
Řekl bych, že velmi záleží k jaké účelu budou data sloužit a jaká se za tím skrývá business logika
Příklad #1: pokud jde pouze o výkaznictví pojišťovně, pak nemusí (možná) být nutné rozlišovat mezi lékem a zákrokem. Je to prostě "úkon k proplacení" a je na pojišťovně, ať si to roztřídí, jestli to potřeba (leda, že pojišťovna a její business logika říká jinak)
Příklad #2: Business logika možná bude říkat, že ke konkrétnímu zákroku patří konkrétní medikace, např. To je třeba si zjistit...
Podle mne je vžycky dobré nakreslit si na začátku (konceptuální) datový model pořádně, se vším, co se podařilo zjistit o entitách a relacích mezi nimi. (nikdy snad není takový nedostatek času, aby se pořádná analýza přeskočila (a většinou se to nikdy nevyplatí a musí se to stejně udělat zpětně))
Na nějaké "ohýbání", optimalizace a podobné "imprúvmenty" je ještě čas ...
-
Podle mne je vžycky dobré nakreslit si na začátku (konceptuální) datový model pořádně, se vším, co se podařilo zjistit o entitách a relacích mezi nimi. (nikdy snad není takový nedostatek času, aby se pořádná analýza přeskočila (a většinou se to nikdy nevyplatí a musí se to stejně udělat zpětně))
No, to jsem měl na mysli, když jsem svou odpověď psal, upozorňoval jsem navrch na to, že je potřeba uvažovat nad tím, zda nejsou nějaké skryté souvislosti (příklad #2) nebo naopak vykonstruované souvislosti, které v realitě neexistují, nebo jsou nezajímavé (příklad #1)...
-
Já to tedy ještě podrobněji analyzuji a doplním i atributy entit.
-
Tady mám nový návrh
https://drive.google.com/file/d/0BzE_t0crYrojb05xVE8yZTFQbFE/view?usp=sharing (https://drive.google.com/file/d/0BzE_t0crYrojb05xVE8yZTFQbFE/view?usp=sharing)
https://drive.google.com/file/d/0BzE_t0crYrojVHlPUGxTbmk4MnM/view?usp=sharing (https://drive.google.com/file/d/0BzE_t0crYrojVHlPUGxTbmk4MnM/view?usp=sharing)
-
Pripada mi zbytecne mit separatne objednani, schuzka, zakrok, to je totez.
pacient ma mnoho zakroku. Kazdy zakrok ma mnoho leku. Kazdy zakrok ma jednoho lekare a jednu pojistovnu.
-
Kazdy zakrok ma jednoho lekare a jednu pojistovnu.
nikoliv zakrok muze mit vice lekaru, napr. operace - anesteziolog, operater, a spol.
-
Nějak takto ?
https://drive.google.com/file/d/0BzE_t0crYrojOGVTZ1RMTGNCRjA/view?usp=sharing (https://drive.google.com/file/d/0BzE_t0crYrojOGVTZ1RMTGNCRjA/view?usp=sharing)
Když jsem se na cvičení ve škole ptal, učitel mi schůzku a zákrok nechal. Já to myslel že buď jdu na prohlídku bez zákroku (pokud se i to nepočítá jako zákrok), anebo si přímo objednám zákrok na určitou schůzku.
-
pojistovnu bych nechal jako soucast zakroku.
pacient muze mit stare zakroky s jinou pojistovnou a pak zmenit pojistovnu.
takze u kazdeho zakroku bude tehdejsi nebo aktualni kod pojistovny.
-
Velmi záleží, co chcete pak s modelem dělat.
Než začnete modelovat, měl byste se zamyslet, jak vidí situaci pacient, pojišťovna, poskytovatel a mezinárodní standardy.
A výsledný model bude buď takový, aby se tam všichni našli, nebo to bude jen ořez pro konkrétní účel.
Příklady různých pohledů na věc:
- Klinická data (dokumentace zdravotního stavu a léčby - např. výsledky testů) vs administrativní data (vyúčtování péče ZP - provedení testu).
- Péče hrazená pojišťovnou / řešená mimo veřejné zdravotní pojištění.
- Léky předepsané / skutečně vyzvednuté - zahrnuje i volně prodejné / skutečně užité(!)
- Dokumentace zdravotních služeb srozumitelná pacientovi / co hradí ZP (chyba je, že to není totéž)
Jinak k prvnímu dotazu - lékař co vím rozhoduje o podání léků, ale většinou je nepodává.
No, určitě písněte, na co má model sloužit.
-
Omlouvám se ale krapet jsem poupravil téma. Do toho s pojišťovnou jsem se zamotal.
Tento diagram je na kliniky ve městě: Dejme tomu, že mám dvě kliniky. Každý pacient bude mít v záznamu kde,kdy a kým byl ošetřen. Doktor kdy a koho ošetřil, plus navíc jeho specializace.
Adresa je tam proto, že mám dvě kliniky a pacienti mají taky adresu. Možná bych tam mohl přidat i typ_schůzky jestli to bude ordinace nebo doma u pacienta.
https://drive.google.com/file/d/0BzE_t0crYrojaEd2M1RTcnRtZFE/view?usp=sharing (https://drive.google.com/file/d/0BzE_t0crYrojaEd2M1RTcnRtZFE/view?usp=sharing)
-
IMHO: jestli chcete, aby vám k tomu někdo poradil, opravdu byste měl uvést účel, pro který model tvoříte. Čím lépe popíšete, co vše má model zahrnout a co se s modelem pak bude dělat (vznikne IS, s jakým use-case?), tím relevantnější budou rady, které dostanete.
-
Je to školní úkol na ERD, RD. Ta aplikační část tam není. Všechno je předvyplněné. Po skompletování bych měl být schopen se např příkazem Select, dotázat na všechny pacienty kliniky A nebo jací tam jsou doktoři.
-
ok, pak samozřejmě nemá cenu nad tím meditovat a předpokládám, že chcete řešit jen aspekty, které jsou v posledním diagramu.
Jaká je věcná interpretace vazby pacient - klinika?
Schůzku (nikoliv pacienta) potřebujete nějak navázat na konkrétní ordinaci (řekněme kliniku = recepce?), aby pacient věděl, kam má v pátek přijít.
Pokud necháte jen relaci schůzky na doktora, musíte udělat relaci doktor - klinika a zakázat záskok doktorů mezi klinikami.
Ke schůzce můžete přidat pár datových polí, aby doktor a sestra věděli, proč k nim pacient přijde.
A na pacienta i kliniku je dobré mít kontakty.
-
Takže nějak takto ?
https://drive.google.com/file/d/0BzE_t0crYrojUEhXWVdCM3I5UWs/view?usp=sharing (https://drive.google.com/file/d/0BzE_t0crYrojUEhXWVdCM3I5UWs/view?usp=sharing)
-
Ano, věcně to teď myslím dává smysl.
Nejsem úplně doma v ERD notaci, ale zkontroloval bych muří nohy u vazeb
- mezi pacientem a schůzkou (pokud se nemá jednat o skupinovou terapii, mediaci, transplantaci od živého dárce apod., bude to 1:N)
- vypadá to, že klinika má jednu adresu, ale pacient více - to může být záměr, ale pak by bylo dobré rozlišit typ adresy (trvalý pobyt / korespondenční).
-
jeden pacient ma N schuzek, nikoliv jedna schuzka N pacientu.
-
jeden pacient ma N schuzek, nikoliv jedna schuzka N pacientu.
Skupinová terapie?
-
Teď mám tedy toto:
https://drive.google.com/file/d/0BzE_t0crYrojUWFydFI3TGRSbUk/view?usp=sharing (https://drive.google.com/file/d/0BzE_t0crYrojUWFydFI3TGRSbUk/view?usp=sharing)
Tou adresou si nejsem moc jistý, jak jí tam správně zakomponovat. Jinak nějaké nápady na další entity ?
-
Lze na tomto fóru editovat předchozí příspěvek ?
Do diagramu jsem přidal ještě medikaci a referenční tabulky mezi adresu a kliniku s pacientem.
https://drive.google.com/file/d/0BzE_t0crYrojcDdpaVhHaURfaHc/view?usp=sharing (https://drive.google.com/file/d/0BzE_t0crYrojcDdpaVhHaURfaHc/view?usp=sharing)
-
Lze na tomto fóru editovat předchozí příspěvek ?
Do diagramu jsem přidal ještě medikaci a referenční tabulky mezi adresu a kliniku s pacientem.
https://drive.google.com/file/d/0BzE_t0crYrojcDdpaVhHaURfaHc/view?usp=sharing (https://drive.google.com/file/d/0BzE_t0crYrojcDdpaVhHaURfaHc/view?usp=sharing)
jj, leky/medikace jsou ok.
ty referencni tabulky N:M nepatri do uml, to je technikalie napriklad pro sql.
v uml mas mit vazby trid, ne jestli pak v programu bude mit pacient v sobe ukazatel na objekt adresa atd.
-
Já tu adresu asi předělám pro obě entity na atributy ulice město. Taky jsem se zamýšlel nad vazbou Doktora a Specializace. Nebude to N ku N ? Nebo spíše N ku 1. Protože většinou má doktor jen jednu specializaci, tak jsem to myslel původně jen jsem to špatně zakreslil.
-
...
ty referencni tabulky N:M nepatri do uml, to je technikalie napriklad pro sql.
v uml mas mit vazby trid, ne jestli pak v programu bude mit pacient v sobe ukazatel na objekt adresa atd.
Tak na začátku stojí toto:
Dobrý den,
dělám na entitně relačním diagramu pacienta. Ocenil bych pár rad a tipů, zrovna si nejsem jistý u entity DOKTOR. Jestli bude spojená s entitami PODANÉ_LÉKY a PROVEDENÝ_ZÁKROK.
https://drive.google.com/file/d/0BzE_t0crYrojYkk1S3B4QjFPeGM/view?usp=sharing (https://drive.google.com/file/d/0BzE_t0crYrojYkk1S3B4QjFPeGM/view?usp=sharing)
Z čehož bych hádal, že má nakreslit entity a relace mezi nimi (asi pro DB), nikoli že má nakreslit uml diagram tak, aby se z toho už dal generovat nějaký kód (= např. je mi teď šumák, že se někde bude generovat nějaký pointer/list pointrů/...).
PS: vztah m:n se (většinou) převádí na asociativní entitu ...
PPS: to nám ta analýza pěkně jde, blahopřeji!
-
Takže ERD je hotovo. Teď jen jestli je správně i RD, pro implementaci do sql management studia.
https://drive.google.com/file/d/0BzE_t0crYrojZmw4RWg0OTZVZ28/view?usp=sharing (https://drive.google.com/file/d/0BzE_t0crYrojZmw4RWg0OTZVZ28/view?usp=sharing)
https://drive.google.com/file/d/0BzE_t0crYrojam9RYzQ1aE9nZ1k/view?usp=sharing (https://drive.google.com/file/d/0BzE_t0crYrojam9RYzQ1aE9nZ1k/view?usp=sharing)