Projekt bazy danych nazw preferujesz i dlaczego?

Którą notację, metodologię i narzędzia do projektowania baz danych, modelowania, tworzenia diagramów preferujesz i dlaczego?
Która notacja, standardy, metodologia są najczęściej używane i objęte przez różnych dostawców?
Które są standardowe, a które nie ?
czyli których należy się trzymać, a których unikać

I osobiste pytanie do wykonania:
Dlaczego wolisz IDEF1X?
Czy nie wygodniej jest trzymać się narzędzi, notacji wbudowanych w używane narzędzia klienckie RDBMS?

Update:
Właśnie przeczytałem jakie są Twoje najbardziej przydatne standardy baz danych?.
Jestem dość zaskoczony-tuzin odpowiedzi tam i absolutnie żadnych nazwisk lub odniesień, tylko długie opisy.
Czy wszyscy programiści baz danych używają niestandardowej terminologii i konwencji?

Zaktualizowałem tytuł, włączając "nazwę" i wyłączając "metodologię".
To o co prosiłem to nazwiska (ewentualnie referencje) nie opisy.
Notacje dla ex., UML, IDEF1X. Barker, Informatyka

Cóż, jestem głównie dev SQL Server i, jak wspomniał @dportas, widzę pewną notację w diagramach w SSMS i msdn docs, książki, artykuły.

Author: Community, 2010-11-09

3 answers

Extended 11 Dec 10

W odpowiedzi na komentarze

Dobre Pytanie.

Co oznacza pytanie ?

Zanim odpowiemy na pytanie "notacja" , które jest małym widocznym problemem na powierzchni, musimy zrozumieć kwestie, które na niej leżą, które prowadzą do kwestii powierzchniowych. W przeciwnym razie znaczenie pytania sprowadza się do osobistych preferencji; co zapewnia jakiś produkt lub inny, czy jest bezpłatny, itd.

Standardy

Zakładam, że czytelnik nie ma żadnego argumentu, że mosty budowane dla społeczeństwa z publicznej kieszeni (w przeciwieństwie do mostów hobbystycznych budowanych na prywatnej ziemi do użytku osobistego) muszą mieć standardy, aby zapewnić, że nie przewrócą się; że mogą przenosić deklarowany ruch i że ludzie nie zginą podczas ich używania. Zamierzone normy są najpierw przedstawiane przez wysoko cenionych i uznanych ekspertów inżynieryjnych, a także intensywnie praktykowane i testowane przez swoich rówieśników, ostatecznie osiągając status normy i są deklarowane jako takie przez rządowe organy normalizacyjne. Następnie władze po prostu określają standardy, których muszą przestrzegać wszyscy dostawcy, aby dostarczać mosty rządowi.

To strata czasu, aby zaangażować się w dyskusję z niezgodnymi firmami inżynierskimi, ponieważ co lub dlaczego ich oferta poniżej standardu jest warta oceny. Lub przyjrzeć się diagramom, które zawierają konkretne informacje (wymagane według standardu). Albo rozmawiać z firmami prezentującymi się jako Budowniczowie mostów, ale nie mają inżynierów budownictwa na liście płac.

Normy są znormalizowane

Innym ważnym aspektem norm jest to, że nie ma powtórzeń. Standard budowy mostu musi odnosić się tylko do standardu elektrycznego dla wszystkich przewodów na moście, nie powtarza treści. Normy są znormalizowane.. Dzięki temu każdy Standard może się rozwijać i zmieniać (np. w stosownych przypadkach, ze względu na dostępność nowych materiałów budowlanych), bez wpływu na inne normy lub ich zgodność.

Podobnie normy nie konkurują ze sobą. Jeśli ktoś przestrzega standardu budowy mostów, nie ma niebezpieczeństwa, że złamał standard komunikacji.

Normy odnoszą się do wyższych zasad

Standardy są więc wyższymi zasadami, które każdy dostawca, który rzeczywiście dostarcza jakość i wydajność, będzie chętnie przestrzegać. A inne będą wahać się od niechętnej zgodności aż do ignorancji, że istnieje obowiązująca norma.

Standardy to Nie A notacja

Po Trzecie, norma nie jest tylko zbiorem symboli i notacji, które muszą być zgodne z diagramem. Niewykwalifikowani i niedoświadczeni Budowniczowie mostów mogą powiedzieć, że tak, ze względu na ich niski poziom zrozumienia całego zestawu wiedzy wymaganej do budowy bezbłędnych mostów, ale nie. Standardem jest zawsze metodologia lub zestaw wyraźnych kroków, które są przewidziane dla procesu, który jeśli przestrzegane, produkować decyzje, które muszą być wykonane na każdym etapie, w postępie, tak, że każda decyzja może być oparta na poprzednich decyzji, które zostały potwierdzone, i które mogą być opierane. Prosty diagram przechodzi przez określone normy zgodne etapy lub fazy, z złożoności i notacje są stopniowo dodawane, tak że końcowy diagram jest zgodny.

Standardy są kompletne

Czwarta kwestia ma związek z zapewnieniem, że informacje przekazywane na diagramie są kompletne i jednoznaczne. Norma zapewnia kompletność wymaganych informacji. Stosowanie metodologii oznacza, że niejasności zostały formalnie zidentyfikowane i rozwiązane. Diagramy podrzędne nie zawierają tego wymogu istotnych informacji standardowych, są niekompletne i zawierają niejednoznaczności.

Normy są łatwe

Oprócz pewności osiągnięcia pewnego poziomu jakości, łatwiej i szybciej jest przejść przez standardową metodologię. Absurdem jest, aby przedsiębiorstwa, które nie złożyły skargi, ponownie dopasowywały swoje diagramy, dostarczając im jedynie standardową notację. Brak zalecanego procesu jest widoczny dla każdej znormalizowanej osoby, a schemat będzie skonfliktowany(składniki s brak integracji).

Odpowiedzialni, świadomi klienci (govt wydziały, producenci samolotów ... firmy, które spodziewają się być wokół w następnej dekadzie) mają uzasadnione oczekiwania, że oprogramowanie to kupuje od dostawców będzie pewnej jakości; Łatwe do zwiększenia i rozszerzenia; dobrze działać; będzie łatwo zintegrować z innym oprogramowaniem; itp.

Brak standardów w IT

Problem z przemysłem IT polega na tym, że w przeciwieństwie do przemysłu samochodowego czy budowy mostów, ponieważ eksplodował w ciągu ostatnich 30 lat, mamy zostały zalane przez dostawców, którzy:
    W 2007 roku, po raz pierwszy w Polsce, w Polsce i za granicą, w 2009 roku, w Polsce i za granicą.]}
  • nie kwalifikują się do niego (nie mają pojęcia, co jest dobre, a co złe)
  • Nie doświadczeni w tym (są doświadczeni w tym, co wiedzą)
  • nieświadomi standardów
  • Praca w izolacji od swoich wykwalifikowanych rówieśników]} Praca w komforcie i łatwości, izolacji, "produktów" jednego dostawcy [64]}
  • mają fałszywe zaufanie oparte o sukcesie w izolacji
  • niewykwalifikowani i nieświadomi tego
To było przedmiotem wielu badań i Publikacje, to nie jest tylko moja profesjonalna opinia, kredyt idzie do naukowców, którzy wykonali ciężką pracę, aby przesiać i dokładnie określić, jakie są konkretne problemy.

Więc jeśli chodzi o całą populację dostawców IT, firm IT, a także pracowników IT w firmach spoza IT, świadomość jakości, standardów wymagane do zapewnienia jakości, a ich znaczenie, jest znacznie niższa niż 30 lat temu. Jest to mentalność "buduj i zapomnij"; jeśli nie zadziała, wyrzuć ją i zbuduj kolejną. Ale dla wielkiego końca miasta, odpowiedzialny świadomi klienci, to nie do przyjęcia.

Standards are Not Single-Vendor

Z definicji, standardy są dostarczane przez wielu dostawców, na poziomie międzynarodowym.

Jednym z ogromnych problemów w branży jest, pomimo posiadania dobrych dostawcy, którzy dostarczają dobre narzędzia do rzeczywistego modelowania (wykresy, które są zgodne ze standardami), mamy również dostawców, którzy dostarczają pełną gamę absurdalnych obrazów i niezgodnych diagramów. Pozwala to ludziom na tworzenie dobrze wyglądających, ale całkowicie bezsensownych diagramów. Chodzi o to, że te okropne narzędzia dają ludziom pewność, że zbudowali dobry most, dobrą bazę danych. Najpierw tworzą zestaw arkuszy kalkulacyjnych, które ładują do kontenera zwanego "baza danych" i oprogramowanie pomaga im myśleć, że mają teraz "bazę danych"; następnie używają narzędzia i inżynierują wstecznie "bazę danych", aby stworzyć"model danych". Daje im to fałszywe zaufanie; nie są świadomi, że mają zabawny obraz wiadra z rybami i czują się obrażeni, jeśli ktoś na to wskazuje. Trzymaj się narzędzi, które są zgodne ze standardami według deklaracji i certyfikacji, i wyrzuć te, które nie są.

Narzędzia niestandardowe dla jednego dostawcy mogą dać jeden komfort i łatwość i fałszywe poczucie pewności siebie, w izolacji. Ale nie mogą być używane, jeśli ktoś chce osiągnąć diagramy, które przekazują wszystkie wymagane informacje; zaufanie, które uzyskuje się przez akceptację wykwalifikowanych rówieśników; jakość, która pochodzi z zalecanego zestawu kroków; pewność, że nie trzeba zachować na przeróbki modelu.

Konwencje nie są standardami

I zanim ktoś zwróci uwagę, że straszne narzędzia są "de facto standardami", nie są, są powszechne konwencje, bez odniesienia do norm, i nie powinniśmy mylić tych dwóch, używając słowa "standard" w odniesieniu do nich. Sposób, w jaki wychodzi się z łóżka i robi kawę, jest konwencją, być może bardzo powszechną, ale nie jest "standardem". Twój wspólny sprzedawca, w ich interesie komercyjnym, mógł skomercjalizować cię w przekonaniu, że istnieje tylko jeden "standardowy" ekspres do kawy i jeden "standardowy" ekspres do kawy, ale nie ma to żadnego związku ze standardami, do których ekspres do kawy producent musi spełniać lub Standard ziaren kawy importowanych do kraju.

Jest błędny cytat, z którego MS jest niesławny, porównując postęp przemysłu samochodowego do "postępu" MicroShaft, na który przemysł samochodowy zareagował publicznie, z uzasadnionym oburzeniem, i wytarł uśmiech z twarzy billy ' ego Boba. Sun Microsystems również odpowiedział, ale wątpię, że jest znany w kręgach MS. Zauważ, że wiarygodność MS zyskuje dzięki samej objętości: liczba stron internetowych dostarczanie i wymiana ciągle zmieniających się "informacji" wśród wielbicieli państw członkowskich. Są one odizolowane od prawdziwych kwalifikacji i standardów i fałszywie wierzą, że konwencje jednego dostawcy i częściowa wydajność, przy użyciu ładnych obrazów, w rzeczywistości składają się na "oprogramowanie".

Standardy nie są drogie

To nie znaczy, że musisz kupować drogie narzędzia. W przypadku małych projektów całkiem dopuszczalne jest rysowanie diagramów za pomocą prostych narzędzi do rysowania, ponieważ zgodność z normami jest w czaszce, w zalecanej metodologii, a nie w narzędziu, a zatem wykwalifikowana osoba znająca standardy może tworzyć rysunki zgodne ze standardami (dla małych projektów) za pomocą dowolnego niemal narzędzia. I zauważ, że te straszne narzędzia, które źle się przedstawiają, nie dostarczają standardowej notacji; zdecydowana większość "modeli danych" i "diagramów relacji encji" jest rażąco poniżej standardu.

Standardy re relacyjne Bazy danych

Normy lub dokładne definicje lub szczegółowe wytyczne, dla następujących istnieją od ponad 30 lat. W kolejności progresywnej, każda zawierająca poprzednią:

  1. Normalizacja (dla dowolnej bazy danych)
    (norma nie jest wymagana, jest to zasada inżynierska; wspólna dla wielu dyscyplin; prosty proces dla wykwalifikowanych; a jej brak jest łatwy do zidentyfikowania.)

  2. Relacyjne Bazy Danych
    Model Relacyjny: E F Codd & C J Date

  3. Słynne dwanaście zasad relacyjnej zgodności [121]} E F Codd

  4. Relacyjne modelowanie danych
    IDEF1X; 1980 ' s; NIST Standard FIPS 184 z 1993

[2]}jest wielu dostawców, którzy stosują te metody, zgodnie z zaleceniami, a tym samym zgodne z normami, przez okres do 30 lat.
  • Uwaga, Istnieje tylko jeden relacyjny Standard modelowania danych, nie ma konflikt.

  • Zauważ, że notacja jest tylko tym, co widzisz na powierzchni, wynik, jednak wskazuje, że inne notacje mają brak informacji w nich, a Podstawowa metodologia nie została zastosowana.

  • Zauważ dobrze, że normalizacja poprzedzała Model relacyjny i została przyjęta jako podana; dlatego RM nie ma konkretnych odniesień do normalizacji jako zasady, a jedynie identyfikuje normalne formy, pod względem wymogu dla relacyjnych baz danych.

Jeśli jesteś rzeczywiście zakwalifikowany jako Modelarz relacyjnych baz danych, będziesz dokładnie zaznajomiony z pierwszymi trzema; jeśli jesteś zgodnym ze standardami modelarzem relacyjnych baz danych, będziesz dokładnie zaznajomiony z czwartym. Ponownie, nie można racjonalnie oczekiwać, aby spełnić Standard tylko poprzez uczenie się IDEF1X, trzeba się nauczyć i przećwiczyć metodologię, ale nauka notacji może być rozsądne wprowadzenie.

[zgodność ze standardem jest wymagana [przez niektórych]

Istnieją świadomi, odpowiedzialni klienci, którzy domagają się przestrzegania tych standardów.

I jest reszta pola, zarówno nieświadomi klienci, jak i nieświadomi dostawcy, i wszystko pomiędzy.

Jaką Notację ?

Dla większości praktyków znających standardy, nie ma potrzeby dyskutowania "której notacji użyć", biorąc pod uwagę, że istnieje tylko jeden Standard. Dlaczego miałbym rysować diagram (używając drogiego narzędzia w dużym projekcie lub prostego narzędzia do rysowania, aby odpowiedzieć na pytanie na StackOverflow), używając innej notacji, gdy używam jednego standardu od ponad 20 lat, a {36]} nie ma innego standardu {37]} ? Dlaczego miałbym przekazać mniej niż standardowe informacje, skoro mogę przekazać standardowe informacje równie łatwo ? Dlaczego miałbym unikać stosowania standardu, skoro wiem, że stosowanie standardu zapewnia formalne zaufanie, że model danych jest poprawny i będzie odporny na kontrolę (w przeciwieństwie do wyobrażonej pewności, która jest przebita przez najbardziej pobieżne pytania) ?

Jeśli i kiedy jakaś wykwalifikowana, uznana organizacja wymyśli nową metodologię (i uwierz mi, cały czas to robią), przyjrzymy się temu. Jeśli i kiedy metodologia osiągnie uznanie i uznanie rówieśników akademickich, potraktujemy ją poważnie, wypróbujemy ją, staniemy się z nią biegli. Jeśli i kiedy jest deklarowana jako norma przez międzynarodowe organy normalizacyjne (w przeciwieństwie do pojedynczego dostawcy), dostarczymy go. Do tego czasu zapewniamy pełną zgodność ze standardami, które istnieją .

Future Notations & Conventions

Kilkaset ofert dla jednego dostawcy w ciągu ostatnich 20 lat nie było warte czasu poświęconego na dochodzenie. Dlatego też konwencje dla jednego dostawcy, czy to oznaczone jako "standardy", czy nie, nie są warte czasu poświęconego na dochodzenie. W rzeczywistości, ponieważ Standard istnieje, a przed pojawieniem się jednego sprzedawcy, każda oferta jednego sprzedawcy byłaby dorozumianą deklaracją, że nie może być zgodny ze standardem, i oferują anty-standard jako substytucję.

Odpowiedzi na komentarze

  1. Najprostszym sposobem na obalenie zarzutu amatora, że jakieś bzdury są "standardem", jest poproszenie o jego dane publikacji ISO/ANSI/IEC/NIST/etc. Jak na (4) powyżej IDEF1X jest opublikowanym standardem, łatwo patrzeć w górę.

  2. MS słynie z publikowania anty-standardów i nazywania ich "standardami". Poprawnym terminem jest "konwencja". Bill Gates jest amatorem, wykorzystującym brak edukacji wspólnej dla programistów. Bogata Amatorka, ale Amatorka. Wiki może w tym tygodniu nazwać jakąś notację MS standardem, ale już Ostrzegałem cię, że wiki to szambo. Pamiętaj, że oferta jednego dostawcy z definicji nie jest standardem.

  3. IDEF1X to także standard modelowania procesów biznesowych

    Niezupełnie. Na IDEF1X link przeniesie Cię do organizacji, która jest najbardziej odpowiedzialna za nagłośnienie i edukowanie ludzi na ten temat. Jeśli zaznaczysz karty na tej stronie, znajdziesz kilka standardów. Jedna z wielkich potęg (piękności?) standardów jest to, że są one zintegrowane:
    • IDEF oznacza I ntegrated Def inition
      • 0 jest dla funkcji Modelowanie
      • 1 jest do modelowania informacji
        • X służy do modelowania relacyjnych baz danych
    • Są to wszystkie standardy publikowane przez NIST.]} .
      Stwierdzam, że w moim IDEF1X dokument również.
      .

11 gru 10

  1. jaki jest twój stosunek do projektowania baz danych za pomocą notacji UML (diagram)? Uzasadnieniem jest to, że jest szeroko (i wszechobecne) są znane i minimalizują ilość notacji, które trzeba znać dla danego celu

    Najpierw chciałbym zapytać, pokazać mi UML "relacyjny Model danych", który ma w pobliżu ekspozycję szczegółów i subtelności modelu IDEF1X, a następnie mamy coś do omówienia. Do tego czasu są to bezczynne spekulacje, rozmowy ludzi nie relacyjnych, o tym, czego nie wiedzą, z RAM tego, co wiedzą.

    Ale nie uniknę pytania.

    Po Drugie, tam jest to duży problem, z przerażającymi konsekwencjami, kiedy ludzie mają stały sposób myślenia na temat obszaru wiedzy( dobra rzecz), ale wtedy podchodzą do każdego innego obszaru, którego nie znają, z tym samym nastawieniem, nie chcąc uczyć się specjalistycznych umiejętności. Ci biedni ludzie nie czytali o Młot Masłowa. Typy OO są największymi przestępcami. Jeśli odpowiedziałem na to pytanie raz, odpowiedziałem na nie dziesięć razy, a Jestem tu dopiero od trzech tygodni. Pytają, jakby byli pierwsza osoba, która znalazła ten problem, "jak utrzymać moje klasy obiektowe w bazie danych", a oni traktują bazę danych (zapomnij o relacyjnych) jak kosz na śmieci.

    Scott Ambler i Martin Fowler mają wiele do powiedzenia, kiedy spotykają swojego Stwórcę. Kompletni idioci, poza dochodami. Najpierw piszą książki o tym, jak modelować obiekty w niewłaściwy sposób. Następnie odwracają się (czekają na to) i piszą książki o tym, jak rozwiązać problem, który stworzyli. / Align = "left" / I to nie tylko moim zdaniem, wielu innych prawdziwych liderów branży (w przeciwieństwie do publikowanych idiotów) robi podobne komentarze, są dobrze napisane na stronach "Laugh or Cry". Wyobraź sobie "refaktoryzację" bazy danych. Zrobiłby to tylko ktoś, kto nigdy nie czytał nic o bazach danych. Cały podręcznik, Jak to zrobić. Napisane przez głupców, którzy nigdy nie widzieli prawdziwej bazy danych.

    Każdy poważny, doświadczony modelarz wie, że jeśli poprawnie zaprojektujesz (modelujesz) bazę danych, nigdy nie potrzebuje refaktoryzacja .

    Jedynymi "bazami danych", które wymagają refaktoryzacji, są te tworzone przez ludzi, którzy traktują db jak śmieci, po przeczytaniu "książek" i mają wyraźne kroki, jak je ciągle niszczyć. Poczekaj, w przyszłym roku będą mieli "multifactoring".

    Jaki to ma sens ? Nigdy nie traktowali bazy danych z szacunkiem, nigdy się o niej nie dowiedzieli, jak podejść do transferu danych, jak ją modelować. Po prostu "wymodelowali" to młotkiem. Do kogoś takiego jak ja, kto rozwiązuje te problemy w taki sposób, że nigdy nie powracają, "jak modelować moje wielopoziomowe klasy obiektów" mówi mi natychmiast, że są one tak nieświadome, że "utrzymują" swoje modele obiektów w db, a nawet nie przeczytali wystarczająco dużo, aby zrozumieć, że dokładne pytanie brzmi "jak modelować moje podtypy".

    To są problemy na powierzchni. Wady są fundamentalne i głębsze, i wpływają na wszystko, co robią ponownie bazy danych. Nie wierz mi, poczekaj tylko trochę czasu po "aplikacji" wchodzi do produkcji i trafia na słynną ścianę. Uderzają w nią tak często, że mają nawet nazwę oo: Object Relational Impedance Mismatch. Bardzo naukowo brzmiąca nazwa zwykłej głupoty. Nie przyszło im do głowy, że gdyby zaprojektowali relacyjną bazę danych jako relacyjną bazę danych, a aplikację OO jako aplikację OO, z ładnie zdefiniowaną granicą, warstwą transportową między nimi, nigdy nie byłoby "obiektowej impedancji relacyjnej".

    Aplikacja (dowolny język) a db jest jak dobre małżeństwo. Każdy z nich jest zupełnie inny, mają swoje potrzeby i potrzebują siebie nawzajem. Kiedy pracują razem, jest to małżeństwo zawarte w niebie. Jak napisał wielki prorok Khalil Gibran o małżeństwie:

    napełnić nawzajem filiżankę, ale nie pić z jednej filiżanki ...
    Na filarach świątyni stoją od siebie,
    A dąb i cyprys nie rosną w cieniu siebie

    Kiedy jeden partner traktuje drugiego jak niewolnika, a jak nie trzeba ich uznawać i rozumieć, rozwód i przemoc domowa znajdują się w niewielkiej odległości. Refaktoryzacja to tylko zestaw kroków, jak dokonać właściwego wyboru dla swojej następnej panny młodej, jak wyszkolić ją do wykonywania obowiązków. Naprawia objaw na ten miesiąc, ale nie zbliża się do problemu przyczynowego.
    • Nie można "utrzymywać" klas obiektów w bazie danych. Jest rok 2010, piszemy ACID transactions od 30 lat, a nie obiektów wytrwałości. Jeśli napiszesz obiekty trwałości, będziesz miał jedną aplikację Użytkownika, bez współbieżności, masowo nieefektywną, pełną zepsutych transakcji i problemów z integralnością danych.

    • Nie można "projektować" baz danych tak, jakby były "klasami obiektowymi", ponieważ nie są obiektami ani klasami. Przestań marnować czas i dowiedz się, jak projektować dane w lokalizacji dla wielu użytkowników z pewną integralnością. Albo dać pracę komuś, kto wie jak.

    • Korzystanie z OO notacja lub notacja UML traktuje bazę danych jako zbiór obiektów, tylko wzmacnia młot i upewnia się, że jest to najnowsza hartowana stal z importowanym uchwytem wiązu.

    • Możesz mieć doskonale dobre małżeństwo z panną młodą. Wystarczy trochę uznania i szacunku.
      • Oznacza to, nauczyć się terminologii i notacji. Nawet jeśli dałeś pracę komuś wykwalifikowanemu, kiedy dadzą ci gotowy schemat, musisz zrozum to. to jest granicą. Nie możesz iść "EeeeK! Nigdy wcześniej tego nie widziałem".

      • Nie możesz mieć niektórych funkcji bazy danych, ale ignoruj inne podstawowe wymagania. Z pewnością nie mówię, że to wszystko albo nic, to też jest niedojrzałe. Ale musicie mieć podstawowe zrozumienie osoby, którą poślubiacie; im lepsze zrozumienie, tym lepsze małżeństwo.

      • Nie można otworzyć pole bazy danych, bez adresowania wielu użytkowników online; współbieżność( a tym samym waluta danych); transakcje; integralność danych i referencji; itp. Ci idioci (Fowler i Ambler, nie czytelnicy) wymyślają na nowo koło i jeszcze nie doszli do etapu drewnianej szprychy; nie uznali, że gruba okrągła rzecz, która jest przykręcona do siebie, to sama impedancja. Ich "obiekty trwałości" cierpią na wszystkie problemy (takie jak utracone aktualizacje, unikanie niskiej współbieżności), które wyeliminowaliśmy 30 lat temu

    • Dane, które są poprawnie modelowane nie zmieniają się (łatwo je rozszerzyć, ale to, co istnieje, nie zmienia się). Aplikacje przychodzą i odchodzą jak statki. Klasy obiektów przychodzą i odchodzą wraz z deweloperem. Dlatego, jeśli w hierarchii miał być porządek (zamiast równego stosunku), to obiekt powinien być modelowany Po danych.

      • Należy również pamiętać, że dobrze napisane aplikacje (do standardu) są odporne na takie zmiany; aplikacje, które przyjmują podejście "database is a slave", są kruche i pękają przy najmniejszej zmianie; Są to aplikacje rażąco podrzędne. Ale ludzie OO tego nie widzą, widzą "niedopasowanie impedancji".

      • Jeśli (a) aplikacja i baza danych mają rozsądną niezależność oraz (b) granice są jasne, każda strona może zostać zmieniona i rozszerzona bez wpływu na drugą stronę.

      • Alternatywnie, jeśli aplikacja jest naprawdę jedynym głównym wydarzeniem, to aby to zrobić pomyślne (unikaj "refaktoryzacji" co roku lub więcej; napisz to poprawnie, raz, aby trwało), zapomnij o bazach danych, Zachowaj swoje obiekty na dysku C:\ i zachowaj je.

    Dlatego dwadzieścia lat temu niektórzy z nas mówili, publikując artykuły, że Ambler i Fowler mają to na odwrót. Nic dziwnego, że ciągle wpadają w rzeczy i refaktoryzują się. Warto zauważyć, że sekret zwinności polega na tym, że jest ona w pełni znormalizowana. Że jest to zmiana o 180 stopni dla amblera, jego opublikowanych prac, więc nie jest zaskoczeniem, że jest to coś, czego nie może zwiastować i deklarować otwarcie.
I żeby się upewnić, że nie zgubi się w praniu. Zapis jest na powierzchni, ale mówi, co jest w środku. IDEF1X opowiada o relacyjnym nastawieniu osoby, która modelowała bazę danych. Notacja UML dla "relacyjnej bazy danych" mówi o nastawieniu osoby, która uwzględniła stertę danych i która spodziewa się refakturuj to wiele, wiele razy. Wybieraj ostrożnie. Mam coś więcej niż młotek w skrzynce z narzędziami.
  • kiedy modeluję dane, używam IDEF1X
  • kiedy modelować funkcje, używam IDEF0 lub SSADM (w zależności od dojrzałości użytkowników)
  • kiedy modeluję obiekty, używam UML
Jeżdżę konno, strzelam do jeleni, walczę z pożarami i gonię kobiety. Każde działanie ma inny zestaw zasad i reguł, których muszę przestrzegać, aby osiągnąć rozsądny sukces. Imagine jakie byłoby życie, gdybym je pomieszał. Albo gdybym tylko mógł strzelać.
 17
Author: PerformanceDBA,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2010-12-24 01:14:11

Dla modeli ER wolę IEM lub Barker style tylko dlatego, że uważam, że więcej osób rozumie notację kurze łapki. Jeśli chcesz, aby model został zrozumiany przez szerszą publiczność niż ty sam, sensowne jest użycie uznanej standardowej notacji.

Jeśli chodzi o Narzędzia dostawców baz danych, to zależy. Nigdy nie uważałem za niezbędne użycie konkretnego narzędzia, z wyjątkiem przypadków, w których klient już go używał. Oracle i Sybase mają przyzwoite narzędzia do diagramów. Microsoft Visio obsługuje standardowe notacje, chociaż jako narzędzie do projektowania baz danych nie jest tak potężne, jak wiele innych.

Jedynym naprawdę złym przykładem, jaki przychodzi mi do głowy, jest tak zwane narzędzie do projektowania wbudowane w zestaw narzędzi Microsoft SQL Server. To tylko żart. Całkowicie bezużyteczny do jakichkolwiek poważnych celów i nie znam nikogo, kto używa go z wyjątkiem publikacji Microsoftu.

 5
Author: sqlvogel,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2010-11-09 09:55:19

Preferuję podejście trzystopniowe: koncepcyjne modelowanie danych, logiczne modelowanie danych i fizyczne modelowanie danych. Korzystanie z fantazyjnych narzędzi zależy od zakresu projektu.

Pierwszym etapem jest analiza, znana również jako definicja wymagań. Rezultatem pierwszego etapu jest koncepcyjny model danych i powiązane diagramy. Pierwszym etapem jest model danych agnostyczny.

Używam modelowania ER i diagramów ER. Atrybuty są odkrywane, a ich domeny są ustalane, jeśli możliwe. Atrybuty są powiązane z podmiotami przedmiotowymi i relacjami między podmiotami. Relacje są identyfikowane, ale nie są realizowane za pomocą kluczy obcych. Później, w projektowaniu logicznym, relacje zostaną faktycznie zaimplementowane.

Klucze naturalne są identyfikowane i oceniane pod kątem tego, czy można im ufać.

Notacja obejmuje atrybuty, domeny, byty i relacje.

Drugi etap to projektowanie logiczne. Wynikiem drugiego etapu jest logiczny model danych, wyrażony w terminologii SQL. Używam terminologii SQL, takiej jak kolumny, wiersze, tabele i domeny, chociaż są to atrybuty, krotki, relacje i domeny.
Model logiczny jest specyficzny dla relacyjnego modelu danych, ale jest agnostyczny dla DBMS.

W przeciwieństwie do niektórych praktyków, używam kluczy naturalnych jako PKs, gdy można im ufać. Inaczej wymyślę surogatki.

Główna różnica polega na tym, że klucze obce są teraz na zdjęciu. Każdy podmiot otrzymuje stolik. Niektóre relacje są modelowane przez dodawanie kluczy obcych do tabel encji, podczas gdy inne relacje otrzymują własne tabele. Przykładem tego drugiego są relacje wiele do wielu.

Kwestie takie jak skład tabeli i normalizacja są rozpatrywane na tym etapie. W przeciwieństwie do niektórych praktykujących, nie traktuję normalizacji jako jakiejś religii. Podejmuję decyzje projektowe mając na uwadze konsekwencje. Jednak odstępstwa od normalizacji muszą mieć specyficzny uzasadnienie.

Gdybym miał zaprojektować nie relacyjną bazę danych, drugi etap wyglądałby zupełnie inaczej.

Trzecim etapem jest projektowanie fizyczne. Skutkuje to fizycznym modelem danych. Fizyczny model danych zaczyna się od logicznego modelu danych i dodaje funkcje takie jak indeksy, przestrzenie tabel, procedury przechowywane i to, co masz. Projekt fizyczny jest specyficzny dla systemu DBMS i uwzględnia wolumen, ruch, cele wydajności i dostępne zasoby.

Fizyczny model danych jest schematem budowy baz danych.

 3
Author: Walter Mitty,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2016-04-16 15:22:54