Kiedy Denormalizować projekt bazy danych

1) to jest archiwum. Wszystko, co w nim jest, nigdy nie powinno być aktualizowane. Poszedłbym za sugestią starszego faceta i niech ta tabela faktur będzie niezależna. Może użyć Bloba dla samej faktury, która zawiera język znaczników?

2) usługi raportowania, tabela magazynowa, która jest aktualizowana, coś, co tworzysz skryptem kiedykolwiek... wszystko byłoby w porządku. Jest to rzeczywiście idealne do normalizacji, ale nie zawsze jest to szybkie. Mam dobrą bazę danych opieki zdrowotnej I zarządzanie, które jest w pełni znormalizowane... a następnie ma szereg de-znormalizowanych tabel z zwijanymi równaniami i powszechnie ciągniętymi polami. Prawie wszystko działa z tego od-znormalizowanego zestawu - po prostu szybciej jest dołączać do nich za pomocą wyzwalacza, gdy pliki są ładowane, niż ciągnąć z różnych tabel za każdym razem, gdy chcę spojrzeć na raport rekordu 100,000.

Podnosisz ważne punkty, jednak nie jesteś do końca jasny co do normalizacji i co to znaczy, np. w

1) twierdzenie, że przechowywanie faktur w stanie, w jakim były, denormalizuje dane, jest całkowicie błędne. Weźmy na przykład cenę - jeśli masz wymóg biznesowy, który stwierdza, że musisz zachować historię cen, a następnie utrzymywanie tylko bieżącej Ceny jest złe i łamie wymagania. I nie ma to nic wspólnego z normalizacją, po prostu nie jest zaprojektowany cóż. Denormalizacja polega na wprowadzeniu możliwości dwuznaczności do modelu (i innych artefaktów) - i w tym przypadku po prostu nie modelujesz poprawnie swojej przestrzeni problemowej.
Nie ma nic złego w modelowaniu bazy danych w celu obsługi danych temporalnych(lub wersjonowania i / lub oddzielania obszarów bazy danych na archive / temporal i zestaw roboczy).

Patrzenie na normalizację bez patrzenia na semantykę (w kategoriach wymagań) nie jest możliwe.

Również, jeśli twój starszy programista nie widzi różnicy, więc chyba nie dostał stażu w rozwoju RDBMS;)

Buforowanie wyników pośrednich jest dozwolone nawet w znormalizowanych bazach danych, a nawet przez największych ewangelistów normalizacji - można to zrobić w warstwie aplikacji (jako jakiś cache) lub można to zrobić w poziom bazy danych lub możesz mieć hurtownię danych do takich celów. Wszystkie te wybory są słuszne i nie mają nic wspólnego z normalizacją modelu logicznego.

Również, jeśli chodzi o Twojego księgowego-powinieneś być w stanie przekonać go, że to, co twierdzi, jest , a nie dobrym testem i opracować zestaw testów (może razem z nim), które zautomatyzują testowanie systemu bez interwencji użytkowników i dadzą ci większą pewność, że Twój system jest wolny od błędów.

Na drugiej ręka wiem o systemach, które wymagają od użytkowników wprowadzania zduplikowanych informacji, takich jak wprowadzenie liczby linii na fakturze przed lub po wprowadzeniu faktycznych linii, aby upewnić się, że wpis jest kompletny. Dane te są "zduplikowane" i nie musisz ich przechowywać, jeśli masz procedurę, która poprawi dane wejściowe. Jeśli ta procedura nadejdzie później, dozwolone jest przechowywanie "denormalizowanych" danych-ponownie, semantyka uzasadnia to i można spojrzeć na model jako znormalizowany. (korzystne jest zawijanie twoja głowa wokół tej koncepcji)

EDIT: Termin "denormalized" w (2) nie jest poprawny, jeśli przyjrzymy się formalnej definicji form normalnych i jeśli weźmiemy pod uwagę projekt denormalizowany, jeśli łamie on którąkolwiek z form normalnych (dla niektórych jest to oczywiste i nie ma innego sposobu na to).

Mimo to, może warto przyzwyczaić się do idei, że wiele osób i niepotrzebnych bezużytecznych tekstów będzie używać terminu normalizacja dla każdego wysiłku, który stara się zmniejszyć redundancję w baza danych (jako przykład, znajdziesz artykuły naukowe, przez które nie mówię, że muszą mieć rację, tylko jako ostrzeżenie, że jest powszechne, że pochodne atrybuty nazywają formą denormalizacji, patrz tutaj ).

Jeśli chcesz odnieść się do bardziej spójnych i uznanych autorytetów (znowu, nie uznawanych przez wszystkich), może słowa C. J. Date mogą wyraźnie odróżnić:

Duża część teorii projektowania ma związek z zmniejszenie nadmiarowości; normalizacja zmniejsza redundancję w relvarach, ortogonalność zmniejsza ją w poprzek relvars.

Q z baza danych w głębi: teoria relacyjna dla praktyków

I na następnej stronie

Tak jak brak normalizacji wszystkich sposób zakłada redundancję i może prowadzić do pewne anomalie, więc też może nieprzestrzeganie ortogonalności.

Więc właściwym terminem dla redundancji w relvarach jest ortogonalność (w zasadzie wszystkie normalne formy mówią jeśli chodzi o pojedynczy relvar, więc jeśli przyjrzymy się normalizacji, nigdy nie sugerowałoby to żadnych ulepszeń z powodu zależności między dwoma różnymi relvarami).

W każdym razie, jednym z innych ważnych pojęć, jeśli weźmiemy pod uwagę projektowanie baz danych, jest również różnica między logicznymi i fizycznymi modelami baz danych. Wiele rzeczy, które są przydatne na poziomie fizycznym, takich jak tabele z podlicznikami lub indeksami, nie ma miejsca w modelu logicznym - gdzie próbujesz nawiązać i zbadać relacje pomiędzy koncepcjami, które próbujesz modelować. I dlatego można powiedzieć, że są dopuszczalne i nie psują projektu.

Linie czasami mogą być nieco rozmyte na tym, co jest modelem logicznym, a co modelem fizycznym. Szczególnie dobrym przykładem jest tabela z podlicznikami. Aby uznać to za część fizycznej implementacji i zignorować na poziomie logicznym, musisz:

• upewnij się, że użytkownicy (i aplikacje) nie mogą aktualizować tabeli subtotal bezpośrednio w sposób, który nie jest zgodnie z ich predykatem (innymi słowy mają błąd w procedurze subtotalling)
• upewnij się, że użytkownicy (i aplikacje) nie mogą zaktualizować tabeli, od której są one zależne bez aktualizacji subtotal (innymi słowy, że niektóre aplikacje nie usunie wiersza z tabeli szczegółów bez aktualizacji całości)

Jeśli złamiesz którąkolwiek z powyższych zasad, otrzymasz niespójną bazę danych, która dostarczy niespójnych faktów. (W takim przypadku, jeśli chcesz formalnie zaprojektować procedurę naprawienia lub zbadania spowodowanych problemów, nie uznałbyś jej za dodatkową tabelę, istniałaby ona na poziomie logicznym; gdzie nie powinna być).

Oczywiście, można powiedzieć, ale jeśli system, który budujesz, jest dla firmy audytorskiej, to możesz nie mieć zależność funkcjonalna - może to być audyt kogoś, kto korzysta z obliczeń ręcznych lub ma wadliwe oprogramowanie lub musi mieć zdolność do rejestrowania niekompletnych danych i obliczenia mogą być błędne pierwotnie i jako firma audytorska musisz zarejestrować fakt, jak to się stało.

Tak więc semantyka (predykaty), które są określone przez wymagania, będzie miała wpływ, jeśli którakolwiek z form normalnych zostanie złamana-wpływając na zależności funkcyjne (innymi słowy prawidłowo ustalając funkcjonalne zależności jest dość ważną częścią modelowania, gdy dążysz do znormalizowanej bazy danych).

Zgadzam się z Twoim maturzystą co do (1). Wiersz tabeli transakcji musi przechwytywać cały stan w momencie transakcji. Kropka. To, co sugerujesz, nie rejestruje prawdziwych danych, więc jest niedopuszczalne. Zgadzam się również z (2). Cokolwiek biznes chce poprzez crosschecking, musisz wdrożyć. Księgowość opiera się na sprawdzaniu krzyżowym, podwójnym wpisie, zwijaniu ksiąg itp. Musisz to zrobić. To tak fundamentalne, że nie należy nawet patrzeć na to jak na denormalizację, tak jak realizacja wymagań biznesowych.

1) nie wymaga denormalizacji. Musisz tylko określić, jaki poziom szczegółowości każdej zmiany potrzebujesz i utrzymać to za pomocą odpowiedniego klucza.

2) nie ma nic wspólnego z denormalizacją. Przechowywanie danych podsumowujących nie powoduje denormalizacji bazy danych. Przechowywanie wyników uzyskanych z atrybutów innych niż kluczowe w tej samej tabeli byłoby przykładem denormalizacji, ale nie wydaje się, że o tym tutaj mówisz.

Twój starszy programista daje bardzo ważne punkty. Nauczyłem się tego na własnej skórze, serwisując systemy, które nie de-normalizują danych historycznych.

W pewnym sensie nie jest to dodawanie żadnych kosztów do bazy danych. Tworzysz tabele faktur na podstawie istniejących danych w bazie danych. Faktura jest migawką w czasie. Normalizacja informacji potrzebnych do wystawienia faktury może znacznie ułatwić raportowanie. Kiedy wymagane jest sporządzenie nowego raportu i oczekuje się, że zrobisz to szybko, docenisz de-normalizację.

Pod względem posiadania sumy w bazie danych. To uratowało mi tyłek wcześniej, gdy dokonałem zmiany w aplikacji, która spowodowała, że liczby nie sumują się w ten sam sposób (nie tak trudne, jak może się wydawać). W aplikacji na żywo sumy dały mi określone miejsce do powrotu w celu skorygowania rozbieżności. Pisałem już o tym, możecie przeczytać tutaj: http://jlrand.com/?p=95

Dla #1

Faktura powinna być obliczona na podstawie sprzedaży i płatności. Jeśli nie masz szczegółowych danych dotyczących sprzedaży, w tym ceny/produktu/rabatu/wysyłki/itp.

Dla #2

Zapisanie systemu księgowego do db od podstaw to duży projekt. Upewnij się, że księgowi dają ci zasady biznesowe, dzięki czemu możesz mierzyć dokładność systemów. Ostatnia rzecz, jakiej chcesz, to krok CFO do spotkania DBA i ogłoszenie DB jest nadmierne obciążenie klient, co gorsza jesteś niedoszacowany i wypędzasz firmę z biznesu.

Jeśli masz SQL Server daj Adventure Works db wygląd. Jeśli nienawidzisz MS to spójrz na Adventure Works i nie rób tego w ten sposób.

Normalizacja bazy danych usuwa duplikaty i sprawia, że zapytania sql do aktualizacji danych są bardziej wydajne (i daje kilka innych ulepszeń).

Ale jeśli większość zapytań jest używana do wyboru danych i zapytania select łączą się z kilkoma tabelami w tym czasie, można rozważyć denormalizację tych tabel. Zwiększy to ilość miejsca na dysku potrzebnego na dane, czas wykonywania zapytań SQL update, ale poprawi zapytania select.

Wydaje się, że jeśli rozważasz raczej czy nie powinieneś utworzyć hurtownię danych. Nigdy nie należy denormalizować bazy danych do celów sprawozdawczości historycznej. Utworzenie archiwum i przechowywanie informacji w hurtowni danych spowoduje zarówno denormalizację większości informacji, jak i utrzymanie historii danych.