Temat: Diagram E/R w UML?
Jarek Żeliński:
ja też.. odpadam...
Jako ten, który nie ma do czynienia na codzień z bazami, które obsługuja miliony transakcji na sekundę, podczytuję tylko sobie dyskusję i nie poczuwam się upoważnionym do wypowiadania się, ale kiedy po raz n-ty pojawia się pomieszanie z poplątaniem, więc też .. odpadam ... i pozwolę sobie na komentarz.
nie gadam o spójności bazy relacyjnej bo ich nie mam za bardzo kiedy używać, muszę logikę obsłużyć w aplikacji...
???????????????????? !!!!!!! ???????????? a to poniżej to jak jest realizowane?
dobrze zaprojektowany system (oprogarmowanie) cechuje się, tym, ze zmiana domenowa (nowa stawka VAT, zmiana sposobu kontroli i naliczania wynagrodzenia i masa innych, sa implementowane we jednym miejscu.
Przecież aby z tego skorzystać, to wszędzie tam gdzie jakaś dana jest potrzebna należy się do tego miejsca odwołać. Aby odczytać właściwą wartość należy system tak zdefiniować aby było coś, co wskaże tę konkretną pożądaną wartość, czyli jest to nic innego jak zaprojektowanie logicznej relacji, która będzie podstawą użytkowania takiej bazy. Już ta logiczna relacja czyni tę bazę relacyjną!
Implementacja bazy danych może oczywiście obejmować nie wszystkie constrainty, ale pewne musi, np: unikatowość pola klucza, aby wskazywać jednoznacznie to co ma być wskazane. Można darować sobie inkeksowanie tegoż, wskazywanie pól powiązanych z nim w innych tabelach i zależności czy to jeden-jeden albo jeden-do wielu, ale brak tegoż przełoży się na wydajność (jej brak), a nie kwalifikację, że to już baza nierelacyjna!
Nie zmieniajmy definicji, bo nikt nie będzie wiedział o czym mowa!
Relacyjna baza danych - baza danych złożona z dwóch lub więcej tabel powiązanych ze sobą za pomocą relacji.
Czy w definicji jest coś co mówi, że klucze obce czynią bazę relacyjną? Nie! Relacyjność bo to domena logiki, która łączy tabele powiązane ze sobą w bazie. :-(
Podobnie jest z plikiem płaskim - jeżeli przechowuje dane, tzn. pełni funkcję bazy danych! :-(
To, że to jest to
zwykły plik tekstowy czy binarny przechowujący typy rekordowe zdefiniowane na własne potrzeby przez programistę, nie ma nic do tego czy jest to baza danych czy nie jest, bo
jest to baza danych tyle, że niestandardowa. Tu standardy wyznaczają ORACLE, MICROSOFT, .., i inni. Jak ktoś chce obsługiwać plik przechowywujący dane po swojemu, niech to robi. A jak jeszcze przekona klienta, że jest to równie dobre lub lepsze od standardów SQL, PL/SQL, to nawet na tym zarobi!
jako że projektuję nowe systemy a nie konserwuje starych mało mam z takimi bazami do czynienia... i twierdzenie, że gdybym użył relacyjnej bazy to... to nie ma sensu bo relacyjna baza usztywnia cały system a tego nie chcemy...
100% NIE! Wcześniej wypowiadając się z pozycji analityka stojącego na straży potrzeby spełniania wymagań klienta, itd. itp., w 100% z Pańskimi wypowiedziami się zgadzałem, ale teraz jako projektant, który jest osobą narzucającą już szczegółowe implementacyjne wymagania pisze Pan bzdury. :-( Przedstawione podejście to jedna z możliwości implementacji. Rozumiem, że z Pańskiego doświadczenia wyszło Panu, że tak jest najlepiej. Nie polemizuję.
Być może pozostawienie dotychczasowej struktury tabel archiwalnych i zdefiniowanie nowej struktury na nowe dane oraz implementacja logiki posługiwania się całością w aplikacji, gdzieś się sprawdziło. Można przekonywać że tak jest najlepiej i najnowocześniej, zgodnie z najnowszymi trendami w budowaniu aplikacji IT, jak ktoś ma takie przekonanie. Ale są też inne podejścia.
Można przecież to co było pozostawić bez zmian i do danych archiwalnych sięgać za pomocą starych aplikacji. Można też przecież zdefiniować całą bazę na nowo, nowocześnie i dopisać aplikację migracji, która nie tylko przepisze dane archiwalne ale także właściwie je przekonwertuje, tak aby można było z danych archiwalnych korzystać z wykorzystaniem nowej logiki biznesowej. Można .. . Można i jest to pochodną posiadanych pieniędzy, czasu, potrzeb, mozliwości intelektualnych, .. . ;-)
Co do nieszczęsnych więzów integralności i obiektowości. Wg. mnie nie jest tak, że ma się to wszystko nijak do relacyjności. To, że diagram E/R i UML to inne bajki to już było wielokrotnie. Ale w sprawie obiektowości, jak dla mnie, też mamy do czynienia z nieporozumieniem podobnym do tego tytułowego, bo nie paradygmat obiektowy jest tu najważniejszy. :-(
Jeżeli wyjść od użytkownika, to on np: przyjmuje i realizuje zamówienia klienta, przyjmuje i wydaje towar z magazynu, ewidencjonuje zakup, sprzedaż, .. i robi wieeeele innych rzeczy. Czy to są obiekty? Nie, to są zdarzenia.
Biznes reaguje więc na zdarzenia i jak dla mnie aplikacja biznesowa powinna najpierw być opisana w kategorii zdarzeń. Te zdarzenia oczywiście muszą "jakoś" być obsługiwane, do czegoś przypisane, tym bardziej, że towarzyszy im potrzeba zapamiętania jakieś ilości danych. Tym czymś jest obiekt.
Tym samym kolejny poziom logicznego opisu aplikacji, to poziom obiektów. Obiekty nie są oczywiście opisywane "od sasa do lasa" w kontekście zdarzeń, ale nie są to też opisy identyczne, bo i zdrzenia odwołują się do różnych obiektów, a i obiekty odwołują się do różnych zdarzeń.
Mając powyższe można przystąpić do realizacji, co przełoży się na jakąś logikę, i w aplikacji, i bazie. Szczegóły implementacyjne będą oczywiście różniły się w istotnych detalach od modelu obsługi zdarzeń, czy relacji wiążących obiekty, więc i nic dziwnego, że diagramy będą różne.
Jak zbudowana jest warstwa fizyczna zależy więc tak od wybranych narzędzi (konkretna baza, język programowania), jak i od logiki biznesowej. Wszak zdarzenia to nie tylko zdarzenia proste, ale także (przede wszystkim?), te w szczególności rozciągnięte w czasie.
Przekładając to na język praktyki wychodzi, że rejestrując w bazie nie zawsze dysponuje się wszystkimi danymi. Aby zapewnić spójność stosuje się więc podział tabel (ta obśmiana przez niektórych normalizacja), definiuje indeksy/klucze własne, a dla pól gdzie nie ma wszystkich danych w momencie ich wprowadzania, rezygnuje się często z kluczy obcych, przerzucając sprawdzenie tego powiązania na aplikację, bo jego założenie mogłoby nie pozwolić przejść użytkownikowi do następnego kroku. Ale brak tegoż klucza obcego nie upoważnia do olania wszystkich constraintów przysłowiowym "ciepłym moczem".
Ot perfekcyjna baza danych zapewne uczyniłyby aplikację nieżyciową z punktu widzenia użytkownika, więc zapewne także niezdolną do zaliczenia testu funkcjonalności u użytkownika ;-(, ale nie widzę u kolegów broniących potrzeby projektowania baz danych zgodnie z wykorzystaniem jak największej ilości wbudowanych w nie mechanizmów, negowania że odstępstwa od reguł są dopuszczalne. :-)
To tak z punktu widzenia rozumu, który się przypadkowo w przyrodzie przydażył. ;-)
пропозиції роботи
