Znaczenie diagramów ER

Jestem studentem i rozwijam kilka projektów w ramach mojej uczelni.

Opracowując bazę danych dla jednego z projektów, natrafiliśmy na sytuację, w której zastanawialiśmy się, czy ERD jest konieczna, czy nie. W tej chwili nie każdy z nas zgadza się najpierw na opracowanie ERD, a następnie na podstawie bazy danych.

Większość osób woli werbalne tworzenie bazy danych w locie zgodnie z systemem bezpośrednio wymaganym na papierze.

Teraz ściśle przestrzegam zasad bazy danych. Myślę, że bazę danych należy opracowywać wyłącznie na podstawie ERD. Chcę tylko wiedzieć, co następuje:

• Czy przemysł przestrzega tych zasad?
• Czy po prostu marnuję czas na opracowanie ERD?
• Jakie są korzyści z opracowania ERD?

Proste i proste, pomyśl o opracowaniu bazy danych bez ERD jako o budowie domu bez planu budowy. Może to być wykonalne, ponieważ uważasz, że wystarczy położyć cegłę jeden na drugim, aby coś zbudować, jednak w chwili, gdy ktoś bierze odpowiedzialność za projekt, istnieje ryzyko katastrofy.

Z mojego doświadczenia nie skorzystasz dużo na ERD, chyba że użyjesz ich w połączeniu z narzędziami CASE (ERWin, MySQL Workbench itp.), Które dodatkowo umożliwią wykonanie naprawdę pomocnych operacji, takich jak inżynieria do przodu i do tyłu. Nawet bez tych funkcji posiadanie scentralizowanego schematu kompletnej bazy danych jest przydatne, ponieważ czasami ograniczenia zaimplementowane w samej bazie danych nie wystarczą, aby opowiedzieć pełną historię o relacjach między poszczególnymi jednostkami bazy danych.

Oto przykład dotyczący MySQL, który, jak być może wiesz, implementuje kilka wewnętrznych silników pamięci, w szczególności MyISAM i InnoDB. Istnieją między nimi znaczne różnice, z których jedna jest najważniejsza, ponieważ MyISAM nie obsługuje ograniczeń. Pomimo tego MyISAM jest intensywnie wykorzystywany w aplikacjach internetowych, co oznacza, że ​​logika relacyjna musi zostać zaimplementowana albo przez logikę biznesową (kod aplikacji), albo w inny sposób. Problem polega na tym, że podczas przekazywania inżynierii ERD za pomocą tabel (encji) MyISAM MySQL po cichu zignoruje ograniczenia określone przez ERD i powstanie baza danych, która nie identyfikuje jasno natury relacji między eniami. Innymi słowy, po opracowaniu układu bazy danych twórcy kodu nie mogą zaimplementować prawidłowej logiki biznesowej bez ERD.

ERD są naprawdę fajne, aby mieć jasny obraz struktury bazy danych. Oprócz tego, że jest ważnym artefaktem dokumentu dla twojego projektu, ułatwia także implementację zapytań, zwłaszcza połączeń między tabelami. Wyobraź sobie, jak miło jest mieć konfigurację z dwoma monitorami, po lewej stronie masz ERD, a po prawej edytor zapytań. Możesz wyraźnie zobaczyć relacje między tabelami i na tej podstawie pisać zapytania. Jeśli projekt bazy danych jest dość prosty, a twój projekt go nie wymaga, być może bez niego można żyć.

ERD pozwoli Ci zaoszczędzić znacznie więcej czasu, niż myślisz. Jeśli robisz wszystko w locie, utkniesz, gdy chcesz wygenerować tabele połączeń.

Jeśli kilka lat później natkniesz się na bazę danych bez ERD, musisz poświęcić dużo czasu, aby zobaczyć, co dzieje się w twoim projekcie.

Mam firmę i projektujemy ERD, nigdy nie myśl o bazie danych bez ERD. (W rzeczywistości jest to mój osobisty eksperyment)

ERD były kiedyś głównym nurtem. IMO są teraz mniej więcej opcjonalne.

Obecnie niektóre bardzo udane zespoły wcale nie przejmują się ERD, ale zapewniają doskonałe systemy: solidne, wydajne i łatwe w utrzymaniu na dłuższą metę. Jest to szczególnie prawdziwe w rozwoju Agile, kiedy zaczynamy od małego, z minimalistycznym zestawem narzędzi.

ERD są oczywiście dobrym sposobem komunikacji, ale w żadnym wypadku nie jedynym, ani najlepszym w każdych okolicznościach. Niektóre zespoły preferują inne sposoby dokumentacji i komunikacji.

W tej branży nie ma ogólnych reguł.

Ważne jest zaprojektowanie przed napisaniem kodu produkcyjnego. Ważne jest również, aby prototypować; ludzie z baz danych opracowują prototypy pisząc SQL. (Pamiętasz, co Fred Brooks powiedział o prototypach?)

Języki graficzne, których ER jest tylko jednym, nie okazały się bardzo dobre w przechwytywaniu całej semantyki bazy danych w sposób łatwy i łatwy do zrozumienia.

Nie okazały się również bardzo skutecznymi narzędziami komunikacji, z wyjątkiem między programistami. Ale przy projektowaniu baz danych kluczowa komunikacja nie jest między programistami; między programistami a ekspertami od domen (między programistami a przedsiębiorcami).

Modelowanie ról obiektowych (ORM) ma język graficzny, ale opiera się na „faktach” (prostych zdaniach). Ludzie biznesu mogą dość łatwo zweryfikować fakty. Ludzie biznesu nie mogą łatwo zweryfikować diagramu ER lub diagramu ORM.