Potrzebuje do tego bazy danych z encjami
Pewna przychodnia dentystyczna potr/ebuje bazy danych, ktôra usprawnilaby jej prace. W bazie tej maja
maleze sie nastepujace pola: pesel pacjenta, nazwisko i imie dentysty, nazwa zeba, nazwa zabiegu, adres dentysty, telefon pacjenta, data wizyty, cena zabiegu, ezy pacjent zaslabl podezas wizyty?, plce pacjenta; adres pacjenta, czy wizyta refundowana? data zatrudnienia dentysty, czy pacjent posiada dany zab? Data urodzenia dentysty, cry wizyta sie odbyla?
Zbuduj schemat bazy danych z okresleniem kluezy glównych i obcych.
Wsród wymagan stawianych w fazie projektowej sq nastepujace:
Wszystkie zabiegi w ramach jednej wizyty kazdego pacjenta wykonuje jeden dentysta.
Podezas ronych wizyt kazdego pacienta moze obslugwac inny dentysta.
W ramach wizyty zabiegi mogg bye wykonywane na wiecej niz jednym zebie.
W ramach wizyty wszystkie zabiegi sa refundowane.
Ogólnie to mamy to za Ciebie zrobić czy o co chodzi? Kilka chwil w Google i nie musiał/a-byś pytać na forum.
Tu taka podstawa podstaw:
http://www.informatyka.orawskie.pl/?pl_projektowanie-bazy-danych,113
https://developeronthego.pl/sql-schemat-bazy-danych/
Przykładowe narzędzie:
https://www.microsoft.com/pl-pl/sql-server/sql-server-downloads
Filmiki na YT:
Powodzenia!
Te Twoje "encje" to tak naprawdę tabele połączone kluczami (relacje). Jak chcesz to sam ogarnąć to w zasadzie mój przedmówca podał fajne linki. Jak chcesz gotowca to proponuję wrzucić do działu ogłoszenia drobne i z pewnością znajdzie się ktoś kto Ci to za $$$ ogarnie :)
@wolfik: ...sam ogarnąć..
Widać, że kolega z młodego/średniego pokolenia i nie uczył się wierszyka: my ałfabet uże znajem i wsie bukwy po pariadkie biez oszybki nazywajem :)
Imię autorki wątku to Oleksandra.
P.S. ja się uczyłem, czytam powoli jak dziecko w 1-szej klasie, ale pisać po rosyjsku już nie umiem.
Ciekawe czy GPT by to ogarnął i wypluł scheme 
Pomysł na programowanie aplikacji zaczynając od schematu bazy danych to pomysł dość.... nieprzemyślany.
Nie wpadnij w pułapkę myślenia że encje domenowe da się obrazować tabelami w SQL. Nie da się.
Riddle napisał(a):
Pomysł na programowanie aplikacji zaczynając od schematu bazy danych to pomysł dość.... nieprzemyślany.
Nie wpadnij w pułapkę myślenia że encje domenowe da się obrazować tabelami w SQL. Nie da się.
Toż modelowanie związków encji, z których wychodzi nam schemat/model danych systemu, to chyba najbardziej klasyczne i ograne podejście do projektowania aplikacji jakie może być. Skoro absolutne fundamenty inżynierii oprogramowania to dla Ciebie nieprzemyślany ruch, to cóż... Jest to tak wielka bzdura, że można tylko po prostu napisać, ze to nieprawda.
I oczywiście, ze encje da się obrazować tabelami. Oczywiście ludzie w obiektowej pułapce myślenia :) będą pierdzielić, że to anemiczny model dziedziny i antywzorzec i za niestosowanie dziedziczenia idzie się za do piekła, ale... niekoniecznie warto się tym przejmować.
kabotyn napisał(a):
Toż modelowanie związków encji, z których wychodzi nam schemat/model danych systemu, to chyba najbardziej klasyczne i ograne podejście do projektowania aplikacji jakie może być. Skoro absolutne fundamenty inżynierii oprogramowania to dla Ciebie nieprzemyślany ruch, to cóż... Jest to tak wielka bzdura, że można tylko po prostu napisać, ze to nieprawda.
I oczywiście, ze encje da się obrazować tabelami. Oczywiście ludzie w obiektowej pułapce myślenia :) będą pierdzielić, że to anemiczny model dziedziny i antywzorzec i za niestosowanie dziedziczenia idzie się za do piekła, ale... niekoniecznie warto się tym przejmować.
Pomysł ze warto zaczynać tworzenie aplikacji od jakiegoś "modelu danych" czy też "schematu danych" również jest bardzo słaby.
kabotyn napisał(a):
to chyba najbardziej klasyczne i ograne podejście do projektowania aplikacji jakie może być
Na pewno nie najbardziej klasyczne, powiedziałbym że raczej amatorskie.
Jeśli chcesz zacząć dobrze projektowanie tej aplikacji, to powinieneś się zastanowić co ta aplikacja ma robić (a nie to w jakiej postaci dane mają wejść).
Jeśli chcesz się dowiedzieć jak na prawdę warto zacząć projekt, to obejrzyj filmik od Dave'a Farly'ego, pt "How to start a new softwar project".
Już pomijam to, ze z tego filmiku totalnie nic nie wynika i spytam czy ogarniasz, że patenty takie jak ten, który likowałeś pojawiają się i znikają w ilościach hurtowych co roku, a to co nazwałeś podejściem "amatorskim" to od dziesięcioleci absolutne abecadło projektowania oprogramowania, które wciąż najlepsi wykładowcy na najlepszych uczelniach świata wkładają do głowy studentom?
Bo biorąc pod uwagę tylko to, Twoje twierdzenie o amatorskości jest i bezpodstawne i... cokolwiek aroganckie.
kabotyn napisał(a):
Już pomijam to, ze z tego filmiku totalnie nic nie wynika i spytam czy ogarniasz, że patenty takie jak ten, który likowałeś pojawiają się i znikają w ilościach hurtowych co roku, a to co nazwałeś podejściem "amatorskim" to od dziesięcioleci absolutne abecadło projektowania oprogramowania, które wciąż najlepsi wykładowcy na najlepszych uczelniach świata wkładają do głowy studentom?
Ten "model danych", czy "schemat" danych to jest niepotrzebne skupianie się na formie danych wejściowych, czyli inaczej mówiąc szczegółach implementacyjnych.
Powinieneś zacząć tworzenie aplikacji od tego co aplikacja ma robić. Nie od tego w jakiej firmie mają być dane w niej.
@kabotyn: nic w tym aroganckiego nie widzę. Trend w tworzeniu software już dawno odszedł od data first do behavior first. Polecam poczytać o sesjach Event Stormingowych i DDD. Wymaga to trochę zmiany spojrzenia na software, ale jest to otwierająca oczy lektura 
Ale ostatecznie i tak kończy się na danych, więc nie można ignorować sposobu w jaki są zapisane. Bo prędzej czy później zderzymy się z zadaniem wydobycia jakiejś informacji z tych danych. I wtedy decyzje podjęte na początku projektu mogą się srodze zemścić, jeśli nie zwrócono wystarczającej uwagi na to co i jak zapisujemy.
robertos7778 napisał(a):
Ale ostatecznie i tak kończy się na danych, więc nie można ignorować sposobu w jaki są zapisane.
Tak, ale to się robi w środku lub na końcu projektu.
robertos7778 napisał(a):
I wtedy decyzje podjęte na początku projektu mogą się srodze zemścić, jeśli nie zwrócono wystarczającej uwagi na to co i jak zapisujemy.
Jeśli zacznie się projekt odpowiednio to nie.
Tzn. jeśli zacznie się od zachowania, to decyzje podjęte na starcie właśnie nie powinny "się zemścić". Dla przykładu, wybranie formy danych na początku najpewniej się zemści, kiedy będziesz chciał dodac zachowanie. Dokładnie o tym jest ten filmik który podlinkowałem.
rjakubowski napisał(a):
@kabotyn: nic w tym aroganckiego nie widzę. Trend w tworzeniu software już dawno odszedł od data first do behavior first. Polecam poczytać o sesjach Event Stormingowych i DDD.
Problem w tym, że w ciągu ostatnich 30 latach takich "odejść" było co najmniej kilka lub kilkanaście i za każdym razem odchodzono w jakieś nowe, modne metody by nigdy nie wracać, ani nie patrzeć wstecz. I jakoś tak dziwacznie po większości tych mód słuch zaginął, ale model danych, czasem przebrany dla niepoznaki w nowe szaty (choćby i DDD, o którym wspominasz) wraca jak bumerang.
kabotyn napisał(a):
rjakubowski napisał(a):
@kabotyn: nic w tym aroganckiego nie widzę. Trend w tworzeniu software już dawno odszedł od data first do behavior first. Polecam poczytać o sesjach Event Stormingowych i DDD.
Problem w tym, że w ciągu ostatnich 30 latach takich "odejść" było co najmniej kilka lub kilkanaście i za każdym razem odchodzono w jakieś nowe, modne metody by nigdy nie wracać, ani nie patrzeć wstecz.
O czym Ty mówisz? ;|
Rozchodzi się o to, żeby schować szczegóły implementacyjne (model danych), a uwidocznić zachowanie (czyli to co aplikacja ma robić). Ten sposób po pierwsze jest stosowany od bardzo dawna (conajmniej 1970), a po drugie to nie do końca wiem o jakich "innych" schematach mówisz.
kabotyn napisał(a):
I jakoś tak dziwacznie po większości tych mód słuch zaginął, ale model danych, czasem przebrany dla niepoznaki w nowe szaty (choćby i DDD, o którym wspominasz) wraca jak bumerang.
Masz jakiś przykład, tego o czym mówisz? Bo posługujesz się na tyle niejasnymi terminami, że ciężko z Tobą argumentować, a jednocześnie przez to Twoje wiadomości są trochę jałowe w treść.
Natomiast to że projekt zaczynając od danych wraca jak bumerang, to akurat nie jest argument "za". To jest coś, na co po prostu początkujący programiści wpadają - dlatego powiedziałem w poście wcześniej że to jest amatorskie pojęcie.
@kabotyn: myślę że siła i możliwości podejścia event driven bija na głowę oparcie się na danych. Rozumiem też Twoje podejście trochę, też tak myślałem kiedyś i też myślałem że dane i ich zapis to klucz, ale dziś wiem jak bardzo się myliłem 
Poza tym to naplanujesz wiele jak te struktury mają wyglądać jak raz na dwa tygodnie biznes będzie miał kolejny "genialny" pomysł i się okaże że pół bazy trzeba zaorać 
Spoko, tak samo mówiono o obiektach 20 lat temu. Zresztą, całe to event driven to mutacja tego podejścia. I są spore szanse, że podzieli jego los, a myślenie o nowym systemie będzie się wciąż zaczynać od identyfikacji encji - co jest to tyle logiczne, że atrybut zawsze będzie czymś bardziej elementarnym/obiektywnym/przewidywalnym i względnie niezmienianym niż metoda, niezależnie od tego czy w zależności od mody nazwiemy ją funkcją, zdarzeniem, procedurą lub instrukcją.
Tak więc, niespecjalnie tę "siłę" widzę. Jak by ona miała zresztą wyglądać, choćby dla takiego banalnego przykładu jak ten, który otworzył tę dyskusje?
kabotyn napisał(a):
Spoko, tak samo mówiono o obiektach 20 lat temu. Zresztą, całe to event driven to mutacja tego podejścia. I są spore szanse, że podzieli jego los, a myślenie o nowym systemie będzie się wciąż zaczynać od identyfikacji encji - co jest to tyle logiczne, że atrybut zawsze będzie czymś bardziej elementarnym/obiektywnym/przewidywalnym i względnie niezmienianym niż metoda, niezależnie od tego czy w zależności od mody nazwiemy ją funkcją, zdarzeniem, procedurą lub instrukcją.
Pomysł że utożsamiasz dane i zachowanie programu z atrybutami i metodami obiektu to jest dla mnie znak, że to jednak Ty czegoś nie czaisz. Bo ani jak ani @rjakubowski nic nie mówiliśmy o obiektach. Zgadzam się że myślenie o programie w kontekście obiektów jest słabe, tak samo jak myślenie o nim w kontekście modelu danych. Oba te podejscia są słabe.
To o czym ja mówiłem nie ma nic wspólnego z obiektami. Ja powiedziałem, że program należy zacząć od tego co program ma robić: liczyć podatki? integrować się z jakimś systemem? robić prezentacje? rysować wykres? chodzi o zachowanie z punktu widzenia użytkownika.
kabotyn napisał(a):
Tak więc, niespecjalnie tę "siłę" widzę. Jak by ona miała zresztą wyglądać, choćby dla takiego banalnego przykładu jak ten, który otworzył tę dyskusje?
No biorąc pod uwagę zadanie z pytania, to jasno widać że jest na to za mało informacji.
Autor pisze:
kabotyn napisał(a):
Pewna przychodnia dentystyczna potrzebuje bazy danych, ktôra usprawnilaby jej prace. W bazie tej maja
maleze sie nastepujace pola: pesel pacjenta, nazwisko i imie dentysty, nazwa zeba, nazwa zabiegu, adres dentysty, telefon pacjenta, data wizyty, cena zabiegu, ezy pacjent zaslabl podezas wizyty?, plce pacjenta; adres pacjenta, czy wizyta refundowana? data zatrudnienia dentysty, czy pacjent posiada dany zab? Data urodzenia dentysty, cry wizyta sie odbyla?
Jedyna informacja o tym co aplikacja ma robić kryje się w "przychodnia dentystyczna potrzebuje bazy danych, ktôra usprawnilaby jej prace". Czyli jedyne co ta aplikacja ma robić to "usprawniać pracę" :D Jasno widać że to nie jest sprecyzowane wymaganie, i nikt nie wie co ona ma robić. Dlatego zaczęcie od modelowania danych to zły pomysł - zbudujesz sobie tabelki i encje, super - i co dalej? Skoro nie wiesz co ona ma robić. Skupisz się na nieistotnych szczegółach, a nie zwrócisz uwagi na na prawdę istotny fakt.
Należałoby wrócić do klienta (albo tego kto Ci zadał to zadanie), i zapytać go: co to dokładnie znaczy "usprawnić jej prace"? Wyszukiwać ludzi? Powiadamiać ich? wysyłać im maile? Przeprowadzać na nich jakieś operacje? A jeśli tak - to jakie? Bez tego wymagania zaczynanie projektu nie ma sensu.
Tak że rozbijasz sobie to co ma system robić, dajmy na to ktoś umawia wizytę i leci event na który możesz sobie zareagować gdzie chcesz.
Głupi przykład: pacjent umawia wizytę, leci to w system, zapisujesz ja ze statusem Requested i wysyłasz event VisitRequested. Ten sobie event ma handler który wysyła notyfikację lekarzowi z informacjami o której ta wizyta, gdzie i reszta ważnych informacji oraz linkiem do potwierdzenia. Lekarz potwierdza i leci event VisitAccepted, a ten z kolei ma handler, który wysyła pacjentowi SMS, że potwierdzone i ustawia jej stan na Accepted.
Dodatkowo, ktoś mógłby taka wizytę, np. odwołać albo przełożyć (czy to pacjent czy lekarz).
A już najpiękniej jakby wizyta była sobie agregatem w takiej domenie i trzymała sobie całą logikę w sobie bez zależności na cokolwiek.
Życzę Ci powodzenia, w utrzymaniu jakichkolwiek dobrych zasad, jak np. SRP, upierając się przy podejściu serwisowym i data first.