Schemat bazy do analizy

Cześć,

Zaprojektowałem bazę dla przychodni do obsługi pacjentów z nadciśnieniem tętniczym oraz cukrzycą. Przeglądam tabele i wygląda dobrze ale mam póki co jedną wątpliwość:

Czy powiązanie lekarz do badanieCis/badanieCuk jest konieczne? W miarę rozumiem model relacyjny i zakładam że skoro to badania mam już przypisanego pacjenta to poprzez tabelę z danymi pacjenta (w której przypisany jest jego lekarz) mogę będąc lekarzem wyciągnąć tylko rekordy jego pacjentów?

Czy coś jeszcze możnaby zmienic? Jest to podstawa mojego projektu na studia więc wolałbym później do tego nie wracać

Pozdrawiam :)

Zdefiniuj co to znaczy "przypisany". Lekarz w badaniu to osoba, która jest odpowiedzialna za pacjenta (wtedy będzie to redundancja) czy osoba, która wykonała to badanie / jest odpowiedzialna za wyniki tego badania? W tym drugim przypadku faktycznie to pole będzie uzasadnione. Bo badanie może chyba wykonać również inny lekarz, a ponad to, lekarz odpowiedzialny za pacjenta może się zmienić, co nie zmieni wtedy faktu, że wcześniejsze badania mógł wykonać ten wcześniejszy lekarz.

Jasne, już tłumaczę.

Generalnie pacjenci będą sami wykonywać badanie (pomiar ciśnienia i cukru można robić w warunkach domowych). Chodzi o to że lekarz ma przypisanych pewną ilość pacjentów (stąd lekID w rekordzie każdego pacjnta w tabeli pacjent) i przegląda sobie wyniki ich badań. Chcę więc żeby lekarz po zalogowaniu do swojego panelu widział tylko te badania które są wykonane przez przypisanych mu pacjentów. Dlatego też wydaje mi się że ta relacja o której wspominałem w pierwszym poście nie jest konieczna, a mógłbym wyciągnąć to poprzez relację tabeli lekarz-pacjent... nie wiem czy dobrze rozumuję?

Tak poza tym inne relacje wydają mi się sensowne.

1. Dziwne nazewnictwo kolumn z tymi prefiksami, moim zdaniem to zaciemnia, ale jak wolisz. Nazwy tabel pisałbym zaś wielką literą.
2. Co to za kolumny badCukLek i badCukPosilek i czemu są one obowiązkowe?
3. PESEL zawsze ma 11 znaków, więc nie ma sensu trzymać tego w varchar, wystarczy char.
4. Imiona i nazwiska mogą zawierać znaki diakrytyczne, więc lepiej je trzymać w nvarchar.
5. Tabelę wizyt rozbudowałbym o jakieś uwagi/wnioski/diagnozę - bo w końcu jakiś efekt wizyty powinien być. Ponadto, jeśli wizyta kończy się receptą, to fajnie byłoby, gdyby można było powiązać receptę z wizytą w bazie.
6. Na jednej recepcie można przepisać wiele lekarstw, a u Ciebie tylko jedno.
7. Co to za kolumny recIleRazy i recPoIle oraz speTabletki. Coś tu jest nie tak.

Dziękuję za uwagi :) Trochę się do nich odniosę:

1. Tak juz się przywyczaiłem, więc raczej zostawię.
2. Są obowiązkowe na zasadzie TAK/NIE. Po prostu ilość cukru we krwi jest związana z tym czy badanie jest po posiłku czy przed a już na pewno mają na to wpływ leki. Czasem podaje się wynik przed i godzinę po zastrzyku.
3. Słusznie.
4. Dzięki! Byłem pewien że varchar to przechowa.
5. W moim projekcie skupiam się na czym innym. Wizyta jest po to żeby wzbogacić wygląd strony głownej panelu. W projekcie mam zaznaczone że może być to część pełnego SSI (Szpitalnego Systemu Informacyjnego)
6. j.w
7. recIleRazy i recPoIle odpowiada ile razy dziennie trzeba brać lek i po ile tabletek. speTabletki mówi ile jest tabletek w opakowaniu. Wymyśliłem że dzięki temu lekarz wie ile tabletek pozostało pacjetowi i dzięki temu wie (można po prostu policzyć funkcjami sql) kiedy trzeba wypisać nową (jakieś powiadomienie w panelu)

Generalnie traktuję mój schemat bazy jako pewną część pełnego systemu bazodanowego szpitala. W moim projekcie skupiam się na pewnej dziedzinie leczenia i chciałbym pokazać że coś takiego może istnieć i funkcjonować poprawnie, dlatego tak naprawdę najważniejszymi parametrami będą wyniki badań.

2. Obowiązkowe na zasadzie TAK/NIE, to dla mnie oznacza konieczność użycia zmiennej logicznej, a nie tekstowej. Co mają u Ciebie zawierać te kolumny? Jeśli mają one oznaczać jakiś "rodzaj pomiaru", to weź pod uwagę, że cukier mierzy się na czczo, przed posiłkiem, 2h po posiłku, przed, po i w trakcie wysiłku fizycznego, przed podaniem bazowej dawki insuliny, przed snem oraz w przypadku złego samopoczucia.
3. W takim razie, Twój system nie będzie prawidłowo modelował rzeczywistości. Nie wiem, czy to ma sens.
4. W takim razie jak zapiszesz w swoim systemie informacje o tym, że jakiegoś leku trzeba wziąć dwie tabletki do śniadania, jedną do obiadu i trzy do kolacji?
   (Tak na marginesie - Twój system ma dotyczyć cukrzycy, którą leczy się nie tylko tabletkami, ale i zastrzykami insuliny, dla których nazwa "tabletka" nie pasuje. ;))

W ogóle co do nazw - jestem absolutnym przeciwnikiem niestosowania języka angielskiego w programowaniu. Już dość się wycierpiałem przy bardzo podobnym nazewnictwie - nie dość, że nie po angielsku (po katalońsku, żeby jeszcze było trudniej) to przesadne stosowanie skrótów w nazwach. Jest jakiś powód, dla którego nie możesz rozwinąć CisSku na CisnienieSkurczowe, a najlepiej SystolicPressure? Czasy, w których nazwy nie mogły przekraczać określonej (niewielkiej) ilości znaków minęły i to bardzo dawno temu.

Tak, przyznam ze tą tabelę do leczenia cukrzycy zrobiłem trochę 'na szybko'.

TAK/NIE chciałbym żeby działało na takiej zasadzie że użytkownik albo wybierze z listy rozwijanej lub zaznaczy radio buttonem. W takim razie jaki typ danych muszę tutaj zastosować?

Przed posiłkiem, po posiłku, przed i po podaniu insuliny, myślę że mogę to umieścić pod sobą i zrobić na takiej samej zasadzie jak to czy badanie było robione przed czy po zażyciu leku.

Co do nazw to sam preferuję pisanie po angielsku, studiowałem w tym języku i przychodzi mi to naturalnie, ale jest to projekt na studia więc... sam nie wiem. Dużo znaków zapytania. Możliwe że po prostu zastosuje pełne polskie nazwy tak jak napisałeś. Myślę że to będzie najlepszy wybór.

Popracuję trochę nad badaniem cukru i zaprezentuję zmiany! :)

TAK/NIE chciałbym żeby działało na takiej zasadzie że użytkownik albo wybierze z listy rozwijanej lub zaznaczy radio buttonem. W takim razie jaki typ danych muszę tutaj zastosować?

To już jest kwestia konkretnego mapowania tego typu na kontrolki, których będziesz używał, ale zdecydowanie powinien być tutaj typ boolean.

Co do nazewnictwa - jeżeli przychodzi ci to naturalnie to tym większy jest to jeszcze powód, żeby robić to właśnie w ten sposób. Projekty na studia to jest czas, w którym wyrabiasz sobie przyzwyczajenia i bez sensu byłoby robienie teraz czegoś, co wkrótce i tak będziesz musiał robić inaczej.