Normalization
Logiczne projektu bazy danych, takich jak tabele i relacje między nimi, jest podstawowym zoptymalizowane relacyjnej bazy danych.Projektowania dobrej logicznej bazy danych można określić podstawę dla optymalnego bazy danych i wydajność aplikacji.Projektowanie słabej logicznej bazy danych mogą zmniejszyć wydajność całego systemu.
Normalizowanie Projekt logiczny bazy danych polega na użyciu metody formalne rozdzielić dane do wielu, tabele powiązane.Kilka tabel wąskie z mniejszą liczbą kolumn jest cechą znormalizowana bazy danych.Kilka szerokości tabel z większej liczby kolumn jest charakterystyczne dla danej bazy danych innych niż znormalizowane.
Rozsądne normalizacji często zwiększa wydajność.Po udostępnieniu przydatnych indeksów SQL Server optymalizator kwerendy jest skuteczne na wybranie szybki i wydajny sprzężenia między tabelami.
Korzyści wynikające z normalizacji między innymi następujące:
Szybsze tworzenie sortowania i indeks.
Większa liczba indeksów klastrowanych.Aby uzyskać więcej informacji zobaczWskazówki dotyczące projektu indeks klastrowany.
Indeksy węższy i bardziej zwarty.
Mniejsza liczba indeksów tabela.To zwiększa wydajność INSERT UPDATE, i DELETE instrukcji.
Mniejsza liczba wartości null i mniej możliwości niespójności.Powoduje to zwiększenie zwartość bazy danych.
Jak normalizacji wzrasta, liczba i złożoność sprzężenia wymagany do pobrania danych również wzrasta.Za dużo relacyjnej złączeniach złożonych za dużo tabel mogą zmniejszyć wydajność.Rozsądne normalizacji często zawiera kilka kwerendy wykonywane regularnie, używające obejmujące więcej niż cztery tabele sprzężeń.
Czasami Projekt logiczny bazy danych jest już ustalona, a całkowita zmianom nie jest realistyczne.Jednak nawet wówczas może istnieć możliwość selektywnie znormalizować dużą tabela na kilka mniejszych tabele.Jeśli baza danych jest dostępna za pośrednictwem procedur przechowywanych, to zmiany schematu może nastąpić bez wpływu na aplikacje.W przeciwnym razie może się zdarzyć, że można było utworzyć widok, która ukrywa zmiany schematu z aplikacji.
Osiągnięcie Well-Designed bazy danych
Teoretycznie projektowania relacyjnych baz danych, reguł normalizacji zidentyfikować niektóre atrybuty, które muszą być obecne lub nieobecny w zaprojektowanej bazie danych.Szczegółowe omówienie reguł normalizacji przekracza zakres tego tematu.Istnieje jednak kilka reguł, które mogą pomóc w osiągnięciu projektowania bazy danych dźwiękowych:
Tabela powinna mieć identyfikator.
Podstawowe zasady teorii projektowania bazy danych jest, że każda tabela powinna mieć identyfikator unikatowy wiersz, kolumna lub zestaw kolumn, używany do odróżnienia dowolnego pojedynczego rekordu każdego rekordu w tabeli.Każda tabela powinna mieć kolumna z IDENTYFIKATOREM i dwa rekordy nie mogą udostępniać tę samą wartość IDENTYFIKATORA.kolumna lub kolumna, służąc jako identyfikator unikatowy wiersz tabela jest klucz podstawowy tabela.W AdventureWorks bazy danych, każda tabela zawiera kolumny klucz podstawowy kolumna tożsamości.Na przykład VendorID jest klucz podstawowy dla Purchasing.Vendor tabela.
tabela powinny być przechowywane tylko dane dla pojedynczego typu encji.
Próbujesz zapisać zbyt wiele informacji w tabela mogą utrudniać skuteczny i niezawodny zarządzania danymi w tabela.W AdventureWorks przykładowej bazy danych, zamówienie sprzedaży i informacji o klientach są przechowywane w osobnych tabelach.Chociaż może mieć kolumny, które zawierają informacje dla zamówienia sprzedaży i odbiorców w jednej tabela, tego projektu, prowadzi do różnych problemów.Informacje o klientach, nazwę i adres, musi być dodany i nadmiarowo przechowywane dla każdego zamówienia sprzedaży.To używa dodatkowej pamięci masowej miejsca w bazie danych.Jeśli zmiany adresu odbiorcy, zmiany muszą być wykonane dla każdego zamówienia sprzedaży.Ponadto, jeśli zamówienie sprzedaży ostatni dla klienta jest usuwany z Sales.SalesOrderHeader tabela, informacje dla tego nabywcy zostaną utracone.
Tabela, należy unikać pustych kolumn.
Tabele mogą mieć kolumn zdefiniowanych zezwalająca na wartości null.Wartość null wskazuje brak wartości.Chociaż może być przydatne zezwalająca na wartości null w przypadkach odłączone, należy ich używać oszczędnie.Dzieje się tak, ponieważ wymagają specjalnego traktowania zwiększającą się złożonością operacje na danych.Jeśli tabela o kilka pustych kolumn z kilku wierszy mają wartości null w kolumnach, należy rozważyć umieszczenie tych kolumn w innej tabeli połączone z tabela podstawowa.Przechowując dane w dwóch osobnych tabelach, tabela podstawowa może być prosty w projekcie i nadal obsługiwać okazjonalnych potrzebę przechowywania tych informacji.
Tabela nie powinno być powtarzające się wartości lub kolumn.
W tabela dla danego element w bazie danych nie powinna zawierać listę wartości dla określonej nowych informacji.Na przykład produkt w AdventureWorks bazy danych może być zakupione od wielu dostawców.Jeśli kolumna w Production.Product tabela dla nazwy dostawcy, spowoduje to utworzenie problem.Jedno rozwiązanie jest przechowywane kolumna Nazwa wszystkich dostawców.Jednak to utrudnia wyświetlanie listy poszczególnych dostawców.Innym rozwiązaniem jest zmiana strukturę tabela, aby dodać kolejną kolumna do nazwy drugiego dostawcy.Jednak to zapewnia dwóch dostawców.Ponadto innej kolumna muszą zostać dodane, jeśli książka zawiera trzy dostawców.
Jeśli okaże się, że do przechowywania listy wartości w jednej kolumnie lub jeśli masz wiele kolumn dla pojedynczego fragmentu danych, takich jak TelephoneNumber1, and TelephoneNumber2, należy wziąć pod uwagę wprowadzanie zduplikowanych danych w innej tabela, zawierającą łącze do tabela podstawowej.The AdventureWorks database has a Production.Product tabela for product information, a Purchasing.Vendor tabela for vendor information, and a third tabela, Purchasing.ProductVendor.W tej trzeciej tabela są przechowywane tylko wartości identyfikatorów produktów i identyfikatorów dostawców produktów.Taki projekt umożliwia dowolną liczbę dostawców dla produktu bez modyfikowania definicji tabel i bez konieczności przydzielania nieużywane miejsce dla produktów z jednym dostawcą.