Projekt DB: Pierwsza normalna forma i powtarzające się grupy

Question

Aby zachować 1 normalną formę, jedną z rzeczy, których należy unikać, jest powtarzanie grup. Jak w zamiast:

CustID Name Address  Phone1  Phone2  Phone3 

    102 Jerry 234 East.. 555-2342 555-9854  555-2986 

Należy utworzyć drugą tabelę numer telefonu i następnie łączyć można dostać:

CustID Name  Address  Phone 

102 Jerry 234 East.. 555-2342 
102 Jerry 234 East.. 555-9854 
102 Jerry 234 East.. 555-2986 

Czasami jest to trochę bardziej niejednoznaczne i trudno powiedzieć, kiedy grupa nagłówków kolumn się kwalifikuje. Na przykład, powiedzmy, że masz obecnie dwa testy, które uruchamiasz na każdym sprzęcie. A twój pierwszy projekt DB daje podejście najbardziej pozioma:

projekt 1

SN  Test1_Max Test1_Min Test1_Mean Test2_Max Test2_Min Test2_Mean 
2093  23   2   15   54   -24   45 

Oczywiście, jest to powtarzająca się grupa, która mogłaby znacznie łatwiej być reprezentowane (na sprzężenie pomiędzy „części” oraz "Testy"):

konstrukcyjne 2

SN  Test  Max Min Mean  
2093 1  23  2  15  
2093 2  54  -24  45  

jednak może pójść jeszcze bardziej w pionie:

Projekt 3

SN  Test Statistic Value 
2093 1  Max   23 
2093 1  Min   2 
2093 1  Mean   15  
2093 2  Max   54 
2093 2  Min   -24 
2093 2  Mean   45 

jest projektowanie 3 konieczne? Jak zdecydujesz, jak zrobić to w pionie? Jakie są plusy i minusy między projektami 2 i 3? Wygląda na to, że oba można łatwo wybrać lub połączyć z SQL, z korzyścią dla projektu 3, ponieważ można łatwo dodać nową statystykę bez faktycznego modyfikowania struktury tabeli.

Ale zanim ktokolwiek pójdzie i powie, że im bardziej pionowy, tym lepiej, są chwile, w których jest bardziej niejednoznaczny. Jak:

Projekt 4

SN  AverageCurrent (mA) BatteryCapacity (mA) 
2093   200     540 

Może zamiast być:

Projekt 5

SN  mA_Measuremnt  Value 
2093 AverageCurrent  200 
2093 BatteryCapacity  540 

Chociaż oba atrybuty są z tej samej domeny (MA), które reprezentują bardzo różne rzeczy w odniesieniu do komponentu. W takim przypadku, czy Design 4 jest lepszy, ponieważ nie jest to ściśle powtarzająca się grupa? Domyślam się, że szukam pewnych kryteriów, aby wiedzieć, kiedy podzielić je na więcej stołów, a tym samym uczynić go bardziej pionowym.

Podsumowując to absurdalnie długie pytanie, , czy należy tylko usuwać i normalizować powtarzające się grupy, jeśli są one dokładnie tą samą domeną: i mają dokładnie to samo znaczenie?. Jeśli tak jest, to tylko przykład telefonu i prawdopodobnie dwa testy w projekcie 1 spełniają te kryteria. Chociaż wygląda na to, że projekt 3 i 5 może przynieść korzyści projektowe, nawet jeśli statystyki w Projekcie 3 mają ściśle inne znaczenie, a cechy AverageCurrent i BatteryCapacity mają zdecydowanie inne znaczenie w Projekcie 5.

Answer 1

Design 2 i Design 4 to najlepsze sposoby na to, aby wyniki nie zawsze były obecne (np. NULL w Desigin 1). Jeśli zawsze są brane, to pierwszy projekt jest w porządku.

Wierzę, że powtarzanie grup w SQL byłoby w rzeczywistości, jeśli masz kolumnę z dodatkowymi wartościami, np. Numer telefonu zawiera "123-444-4444,123-333-3334" itd.

W każdym razie, późniejsze projekty są nieoptymalne - kontynuujesz je do ostatecznego poziomu i masz "Jeden prawdziwy stół wyszukiwania" http://www.dbazine.com/ofinterest/oi-articles/celko22 lub podmiot Atrybut Wartość http://tonyandrews.blogspot.com/2004/10/otlt-and-eav-two-big-design-mistakes.html

http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:10678084117056

Tak czy inaczej, to prawie zawsze złe. Chociaż mogą one mieć wspólny typ danych/domenę, to co oznacza różni się - w związku z tym powinny pozostać indywidualnymi atrybutami (maxtemp, menemp, itp.).

Answer 2

Kiedy jesteś pewien, że "test" będzie (kiedykolwiek) miał tylko Max, Min i Średni -> używaj wzoru 2. Jednakże, jeśli jest możliwe, że pojawią się nowe "statystyki" w przyszłości , to lepiej do wykorzystania projektu 3.

odpowiedzią na:

powinien usunąć tylko i normalizacji grupy powtarzalne jeśli są exacly takie same domeny i mają dokładnie takie samo znaczenie?

Chociaż w wielu książkach wygląda na to, że te normalne formy są ściśle określone, nie są. Powinieneś zobaczyć dla swojej aplikacji, jakie jest najlepsze rozwiązanie ... Normalizacja za dużo nie zawsze jest najlepszym rozwiązaniem, szczególnie gdy widzisz, że zawsze łączysz wszystkie dane razem.

Answer 3

Myślę o (i nauczyłem się) 1NF jako "wszystkie wiersze powinny być tej samej długości, a nie "bez powtarzania się grup". Przy takim widoku można nieco łatwiej podjąć decyzję:

Czy w projekcie 1 oba testy są ZAWSZE obecne? Jeśli tak, to nie jest to naprawdę powtarzająca się grupa. Czy wszystkie średnie są zawsze obecne w projekcie 2? Czy w danym wierszu może być więcej (lub mniej)?

W projekcie 4, czy obie te wartości są zawsze obecne? Jeśli tak, to jest w porządku. Jeśli nie, należy użyć wzoru 5.

Answer 4

Proponuję przenieść powtarzające się grupy tylko do oddzielnych tabel, jeśli mają one zmienną długość. Jeśli kiedykolwiek będziesz mieć tylko Telefon1, Telefon2 i Telefon3, nie ma potrzeby ich rozdzielania. W drugim przypadku, jeśli liczba powtórzeń jest różna, lepszym rozwiązaniem jest oddzielna tabela.

A twoja koncepcja dokładnie tej samej domeny i znaczenia nie jest zbyt intuicyjna, ponieważ zależy od poziomu abstrakcji. Phone1 nie jest dokładnie taki sam jak Phone2, ale oba są numerami telefonów. Można również utworzyć tabelę AddressDetails i przenieść tam numery telefonów. Ale także nazwa, ulica i miasto - wszystkie są danymi adresowymi. Musisz znaleźć sposób między ogólnymi parami wartości klucza i tylko dedykowanymi kolumnami.

Answer 5

Projekt 1 jest rzeczywiście w 1NF, jeśli masz PK na CustID. Może być w 3NF, jeśli żadne dane nie są zależne od niczego poza PK, np. Phone1 nie jest powtarzany dla innego CustID.

Nie można wybrać modelu bez spraw biznesowych, które próbujesz rozwiązać.Zatem Projekt 1 może być doskonale prawidłowym modelem logicznym.

Answer 6

Oto zasada powtarzania grup - co jest zależne funkcjonalnie?

Jeśli wartość statystyczna jest zależna funkcjonalnie od SN, Test i nazwa statystyczna, to masz trzy kluczowe elementy i jeden element wartości. (SN, Test, Statistic -> Value)

W tym konkretnym przypadku - dane zagregowane (średnia, suma, min, maks.) - masz niejednoznaczność, ponieważ nie masz do czynienia z obiektami atomowymi, masz do czynienia z agregatami. Ściśle mówiąc, nie należy przechowywać agregatów, należy je obliczyć. (Tak, wiem, że jest to niepraktyczne, ale taka jest teoria relacyjna.)

W innych przypadkach zwykle wiadomo, co to jest klucz i jaka jest wartość powtarzających się grup. Jednak w tym przypadku znajdujesz się w mrocznej sytuacji, ponieważ przechowujesz dane możliwe do pozyskania.

Dla swoich przykładach, wykonaj projekt hurtowni danych, aby znaleźć bardziej pragmatyczne Test:

Mógłbyś Slice and Dice przez innego klucza?

Wyobraź sobie fakt statystyczny jako punkt otoczony trzema wymiarami: (SN, test, statystyka). Czy to jest ważne? (W przypadku danych zbiorczych często jest mętny.)

Zamiast tego spójrzmy na dane szczegółowe, które powinniśmy zachować: SN, Test, Wynik. Istnieją wyraźnie dwa wymiary (SN, Test) i jedna miara (punktacja) na przecięciu tych dwóch wymiarów. Możemy czerpać dowolną liczbę statystyk z tych szczegółowych danych przy użyciu dowolnego wymiaru (SN lub Test).

Na przykład z baterii, prawdopodobnie chcemy utworzyć go jako bazę danych EAV zamiast bardziej typowej relacyjnej bazy danych. Twoje pomiary (AvergaeCurrent i BatteryCapacity) dają dobre powody do korzystania z projektu bazy danych Entity-Attribute-Value.

Należy pamiętać, że WSZYSTKIE projekty relacyjne są napięciami między dłuższymi relacjami a trójkątami EAV. Zawsze musisz balansować "to jest klucz", a "to jest kolumna", ponieważ zawsze możesz oznaczyć wszystko jako klucz atrybutu i użyć projektu EAV.

Answer 7

Projekt powinien zostać określony na podstawie scenariuszy użycia i rodzaju oczekiwanych zapytań. Czy zamierzasz dużo czytać, pisać lub dużo aktualizacji? Czy chcesz uzyskać wszystkie dane testowe dla kandydata lub chcesz uzyskać tylko najlepszy test lub coś podobnego? Jakie zapytanie najczęściej będzie wyświetlane?

Projekt 1

SN  Test1_Max Test1_Min Test1_Mean Test2_Max Test2_Min Test2_Mean 
2093  23   2   15   54   -24   45 

Jest to najlepszy pod względem wydajności. Nie wymaga żadnych JOINów. Jeśli liczba pól jest deterministyczna i nie jest arbitralna (przykład każda osoba ma najwyżej dwa wyniki testu), to jest to lepsze, aczkolwiek bardziej sztywne, jeśli zdecydujesz się powiązać więcej niż dwie wyniki testu z osobą. Ponieważ SN jest tutaj unique dla każdego wiersza, aparat bazy danych może wrócić, gdy tylko znajdzie dopasowanie, co jest kolejnym powodem, dla którego wydajność jest lepsza.

projekt 2

SN  Test  Max Min Mean  
2093 1  23  2  15  
2093 2  54  -24  45  

Jest to użyteczne SN 2093 może mieć testy N w profilu.Podobnie, jeśli liczba testów wynosi 10 m, to również ten projekt jest lepszy niż 30 kolumn. Każde zapytanie i porównanie będzie dość ciężkie. Jest to również użyteczne, jeśli aplikacja wymaga zapytań, gdzie chce uzyskać najlepszy test dla ucznia 2093 lub jeśli chce wykonać pewne analizy i raportować wyniki testu. Jest to bardziej elastyczne, choć nieco wolniejsze od poprzedniego. Wolę to, ponieważ mam przeczucie, że prawdopodobnie będziesz zainteresowany statystyką testów, a uczniowie mogą mieć więcej niż dwa testy.

Projekt 3

SN  Test Statistic Value 
2093 1  Max   23 
2093 1  Min   2 
2093 1  Mean   15  
2093 2  Max   54 
2093 2  Min   -24 
2093 2  Mean   45 

Jest to przydatne, jeśli zapytań byli zainteresowani wartości bardziej niż cokolwiek innego. Na przykład, jeśli interesuje Cię, ile wartości było większe niż 80, byłaby szybka. W twoim scenariuszu to nie ma sensu. Kończysz wykonywanie zbyt wielu JOINów własnych. Czytanie będzie wolne! Jednak zapisy będą prawdopodobnie szybsze, ponieważ możesz szybko ZAKTUALIZOWAĆ maksymalny wynik dla SN 2093 i Test 2 (zakładając, że kolumna Statystyka jest wyliczeniem zamiast łańcucha, ponieważ porównania łańcuchów mogą być kosztowne).

Projekt 4

SN  AverageCurrent (mA) BatteryCapacity (mA) 
2093   200     540 

Projekt zastosować 5

SN  mA_Measuremnt  Value 
2093 AverageCurrent  200 
2093 BatteryCapacity  540 

same argumenty. To naprawdę zależy od tego, czy zamierzasz optymalizować czytanie czy pisać? Na przykład dla aplikacji internetowych, jeśli możesz sobie z tym poradzić, wolę Design 1. Na przykład, zazwyczaj będę wiedział, że użytkownik będzie miał tylko najwyżej 3 numery telefonów, więc zrobię je każde z pól w kolumnie użytkownika i unikaj JOINów. Odczyty są szybkie, nawet jeśli zapisy wymagają ustawienia niektórych pól na zero.