Normalizacja
Projekt logiczny bazy danych: tabele i relacje między nimi, jest core zoptymalizowane relacyjnej bazy danych.Projekt dobrej logicznej bazy danych można stanowiącą podstawę dla optymalnego bazy danych i wydajność aplikacji.Projekt słabej struktury logicznej bazy danych mogą zmniejszyć wydajność całego systemu.
Normalizowanie Projekt logiczny bazy danych polega na użyciu metody formalne rozdzielić dane do wielu powiązanych tabel.Kilka tabel wąski z mniejszą liczbą kolumn jest cechą znormalizowana bazy danych.Kilka szerokości tabel z większej liczby kolumn jest cechą-znormalizowane bazy danych.
Rozsądne normalizacji często zwiększa wydajność.Po udostępnieniu przydatnych indeksów SQL Server optymalizator kwerendy jest skuteczne na wybranie szybkie, skuteczne sprzężenia między tabelami.
Niektóre z korzyści normalizacji obejmują:
Szybsze tworzenie sortowania i indeksu.
Większa liczba indeksów klastrowanych.Aby uzyskać więcej informacji, zobacz Wytyczne projektowania indeks klastrowany.
Indeksy węższy i bardziej zwarty.
Mniejsza liczba indeksów w tabela.Zwiększa wydajność INSERT, UPDATE i usunąć sprawozdania.
Mniej wartości null i mniej możliwości niespójność.Zwiększa zwartość bazy danych.
Jak normalizacja zwiększa, liczbę i złożoność sprzężeń wymagane do pobierania danych zwiększa także.Zbyt wiele złożonych relacyjnej sprzężenia między tabelami zbyt wiele mogą zmniejszyć wydajność.Rozsądne normalizacji często obejmuje kilka kwerendy wykonywane regularnie, używające obejmujących więcej niż cztery tabele sprzężeń.
Czasami Projekt logiczny bazy danych została już ustalona i całkowita tok nie jest realistyczne.Jednak nawet wówczas może być możliwe selektywne znormalizować dużej tabela na kilka mniejszych tabele.Jeśli baza danych jest dostępna za pośrednictwem procedury przechowywane, może wystąpić tej zmiany schematu, bez wpływu na aplikacje.Jeśli nie może być możliwe utworzenie widoku, który ukrywa zmiany schematu z aplikacji.
Osiągnięcia dobrze zaprojektowanej bazie danych.
Teoretycznie projekt relacyjnej bazy danych reguł normalizacji zidentyfikować niektóre atrybuty, które muszą być obecne lub nieobecny w dobrze zaprojektowanej bazie danych.Szczegółowe omówienie reguł normalizacji przekracza zakres tego tematu.Istnieją jednak kilka reguł, które mogą pomóc w osiągnięciu projektowania bazy danych dźwiękowych:
Tabela powinna mieć identyfikator.
Podstawowe reguły teorii projektowania bazy danych jest każda tabela powinna identyfikator unikatowy wiersz, kolumna lub zestaw kolumn do rozróżniania dowolnego pojedynczego rekordu z każdego rekordu w tabeli.Każda tabela powinna mieć kolumna z Identyfikatorem, a dwa rekordy nie mogą współużytkować te same wartości Identyfikatora.kolumna lub kolumn, służąc jako identyfikator unikatowy wiersz tabela są klucz podstawowy tabela.W AdventureWorks2008R2 bazy danych każda tabela zawiera kolumna tożsamooci jako klucz podstawowy kolumna.Na przykład VendorID jest klucz podstawowy dla Purchasing.Vendor tabela.
Tylko dane dla pojedynczego typu powinny być przechowywane w tabela obiekt.
Próbujesz zapisać zbyt wiele informacji w tabela mogą utrudniać wydajnej i niezawodnej zarządzania danymi w tabela.W AdventureWorks2008R2 Przykładowa baza danych, zamówienie sprzedaży i informacji o klientach są przechowywane w osobnych tabelach.Chociaż może mieć kolumny zawierające informacje dla zamówienia sprzedaży i odbiorców w jednej tabela, projekt ten prowadzi kilka problemów.Informacje o klientach, nazwę i adres, musi dodać i przechowywane nadmiarowo dla każdego zamówienia sprzedaży.Używa dodatkowe miejsca w bazie danych.Jeśli zmiany adresu odbiorcy, zmiany należy dla każdego zamówienia sprzedaży.Ponadto jeśli zamówienie ostatniej sprzedaży dla nabywcy jest usuwany z Sales.SalesOrderHeader tabela — informacje dla tego klienta jest tracone.
tabela należy unikać pustych kolumn.
Tabele mogą mieć kolumn zdefiniowanych zezwalająca na wartości null.Wartość null wskazuje, że nie ma wartości.Chociaż może być przydatne Zezwalaj na wartości null w przypadkach odizolowane, należy ich używać oszczędnie.Jest tak, ponieważ wymagają one specjalnej obsługi, zwiększającą się złożonością operacje na danych.Jeśli masz tabelę z kilku pustych kolumn i kilka 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żna proste w projekcie i nadal obsługiwać okazjonalnych potrzebę przechowywania tej informacji.
Tabela nie powinny mieć powtarzających się wartości lub kolumn.
W tabela element w bazie danych nie powinna zawierać listę wartości określone informacje.Na przykład produkt w AdventureWorks2008R2 bazy danych może być zakupione od wielu dostawców.Jeśli kolumna w Production.Product tabela nazwę dostawcy tworzy problem.Jeden roztwór jest przechowywane kolumna Nazwa wszystkich dostawców.Jednak to utrudnia Pokaż listę poszczególnych dostawców.Innym rozwiązaniem jest zmienić strukturę tabela, aby dodać kolejną kolumna nazwy drugiego dostawcy.Jednak temu tylko dwóch dostawców.Ponadto musi zostać dodany innej kolumna, jeśli książka ma trzech dostawców.
Jeśli okaże się, że przechowywanie listy wartości w jednym kolumna, lub jeśli istnieje wiele kolumnas dla pojedynczego fragmentu danych, takich jak TelephoneNumber1, i TelephoneNumber2, należy rozważyć wprowadzanie zduplikowanych danych w innej tabeli zawierającej łącze do tabela podstawowa. AdventureWorks2008R2 Baza danych zawiera Production.Product tabela informacje o produkcie, Purchasing.Vendor tabela dostawcy informacji i trzecią tabela, Purchasing.ProductVendor.To trzecia tabela przechowuje tylko wartości identyfikatorów produktów i identyfikatorów dostawców produktów.Ten projekt umożliwia dowolną liczbę dostawców produktu bez modyfikowania definicji tabel i bez konieczności przydzielania niewykorzystane miejsca dla produktów z jednego dostawcy.
Zobacz także