Tabela główna

Tabela główna to podstawowa tabela w schemacie, do której odwołują się pozostałe struktury relacyjne.

Rola tabeli głównej w relacyjnej bazie danych

Tabela główna to tabela, która przechowuje podstawowy zbiór rekordów danego obszaru danych i stanowi punkt odniesienia dla innych tabel. W praktyce może zawierać informacje o klientach, produktach, urządzeniach, pracownikach albo zgłoszeniach serwisowych. Jej rekordy mają własną tożsamość, zwykle wyrażoną przez klucz główny. Klucz ten jednoznacznie identyfikuje wiersz i pozwala odwoływać się do niego z innych struktur bazy.

Określenie „tabela główna” nie jest nazwą jednego polecenia ani uniwersalnym obiektem występującym identycznie w każdym silniku baz danych. Jest opisem roli tabeli w modelu relacyjnym. W jednej bazie takich tabel może być kilka, ponieważ każda dziedzina informacji może mieć własny centralny zbiór rekordów. Tabela klientów może być główna dla tabel adresów i historii kontaktów, a tabela urządzeń może pełnić taką funkcję wobec tabel napraw, części oraz pomiarów diagnostycznych.

Ważną cechą tabeli głównej jest względna niezależność jej rekordów. Zależne tabele przechowują zwykle klucze obce wskazujące rekord nadrzędny. Dzięki temu relacja między danymi jest zapisana w sposób jednoznaczny, a informacje nie muszą być wielokrotnie kopiowane w wielu miejscach. Ogranicza to ryzyko rozbieżności, na przykład sytuacji, w której nazwa tego samego urządzenia zostałaby zmieniona w jednym rekordzie, ale pozostała nieaktualna w kilku innych tabelach.

Klucz główny, klucze obce i spójność danych

Najczęściej tabela główna posiada klucz główny zdefiniowany na jednej kolumnie, takiej jak identyfikator klienta, albo na kilku kolumnach tworzących klucz złożony. Wartość klucza głównego musi być unikalna i nie może być pusta. W SQL odpowiadają temu ograniczenia PRIMARY KEY, które wymuszają jednoznaczność identyfikatorów i wykluczają wartość NULL w kolumnach klucza. Sam sposób generowania identyfikatorów zależy od silnika bazy danych i może wykorzystywać między innymi sekwencje, kolumny tożsamości lub wartości nadawane przez aplikację.

Tabela zależna odwołuje się do tabeli głównej za pomocą klucza obcego. Ograniczenie FOREIGN KEY może uniemożliwić zapisanie rekordu wskazującego nieistniejący wiersz nadrzędny. Jeżeli tabela urzadzenia zawiera kolumnę klient_id, to jej wartość powinna odpowiadać istniejącemu identyfikatorowi w tabeli klienci. Takie powiązanie chroni integralność referencyjną. Reakcja na usunięcie lub zmianę rekordu nadrzędnego jest określana przez regułę relacji, na przykład RESTRICT, CASCADE albo SET NULL, o ile dany silnik i definicja schematu dopuszczają takie zachowanie.

Projektując tabelę główną, trzeba dobrać typy danych zgodne z rzeczywistym znaczeniem kolumn. Identyfikator liczbowy nie powinien być przechowywany jako tekst bez uzasadnienia, a daty i godziny powinny korzystać z typów przeznaczonych do przechowywania wartości czasowych. Ograniczenia NOT NULL, UNIQUE i CHECK pozwalają odrzucać część niepoprawnych danych już na poziomie bazy. Reguły aplikacji są potrzebne, ale nie powinny być jedyną ochroną, ponieważ do bazy mogą zapisywać dane także inne programy, importy lub zadania administracyjne.

Projektowanie i zapytania wykorzystujące tabelę główną

Tabela główna powinna opisywać jeden jasno określony typ obiektu. Umieszczanie w jednym wierszu danych kilku niezależnych elementów, takich jak klient, urządzenie i wszystkie wykonane naprawy, prowadzi do powtarzania wartości oraz problemów z aktualizacją. W modelu relacyjnym informacje o obiekcie nadrzędnym przechowuje się raz, a elementy powtarzalne umieszcza w tabeli podrzędnej. Tabela napraw może wtedy zawierać identyfikator urządzenia, datę przyjęcia, opis usterki i status realizacji, bez kopiowania całego opisu właściciela przy każdej naprawie.

Do pobierania danych z tabeli głównej i powiązanych tabel służy JOIN. Złączenie INNER JOIN zwraca tylko rekordy mające odpowiadające wpisy po obu stronach, natomiast LEFT JOIN może zwrócić wszystkie rekordy tabeli głównej, także te, dla których nie istnieje jeszcze rekord zależny. Przykładowo LEFT JOIN pozwala wyświetlić wszystkie urządzenia, w tym urządzenia bez historii napraw. Warunek złączenia powinien wykorzystywać właściwe kolumny klucza głównego i obcego, a nie przypadkowe pola opisowe, takie jak nazwa lub numer telefonu.

Indeksy na kluczu głównym są zwykle tworzone automatycznie przez definicję tego klucza, natomiast kolumny kluczy obcych i często używane filtry mogą wymagać osobnej oceny indeksowania. Indeks może przyspieszyć wyszukiwanie oraz złączenia, ale zwiększa koszt zapisów, ponieważ musi być aktualizowany po zmianie danych. Przy dużych tabelach znaczenie ma także selektywność warunków, kolejność kolumn w indeksie złożonym oraz plan wykonania konkretnego zapytania. Nie należy dodawać indeksów wyłącznie na podstawie nazwy kolumny; ich przydatność trzeba oceniać względem rzeczywistych zapytań i statystyk silnika.

Diagnostyka problemów z tabelą główną

Problemy dotyczące tabeli głównej mogą objawiać się błędami naruszenia klucza głównego, odrzucaniem kluczy obcych, nieoczekiwanymi duplikatami albo wolnym działaniem zapytań. Naruszenie klucza głównego oznacza próbę zapisania identyfikatora już istniejącego lub wartości niedopuszczalnej dla tego klucza. Błąd klucza obcego wskazuje najczęściej na próbę użycia identyfikatora, którego nie ma w tabeli nadrzędnej, albo na operację usunięcia rekordu, do którego nadal odwołują się dane zależne.

Diagnostyka powinna rozpocząć się od sprawdzenia definicji tabeli, ograniczeń, typów kolumn i rzeczywistego schematu używanego przez aplikację. Warto porównać zapytania wykonywane przez program z relacjami zapisanymi w bazie, ponieważ błąd może wynikać z pomylenia identyfikatora technicznego z numerem widocznym dla użytkownika. Przy powolnych odczytach należy przeanalizować plan wykonania i sprawdzić, czy warunki JOIN korzystają z indeksowanych kolumn. Przy problemach z zapisami trzeba dodatkowo uwzględnić transakcje, kolejność operacji oraz blokady.

Podczas naprawy laptopa lub komputera problemy z bazą mogą wynikać zarówno z błędu programu, jak i z uszkodzenia nośnika, systemu plików, usługi bazy danych albo konfiguracji połączenia. Rozsądna diagnostyka obejmuje weryfikację kopii zapasowej, odczyt komunikatów silnika, kontrolę dostępności plików bazy oraz sprawdzenie, czy dane są spójne po awarii. Nie należy usuwać ograniczeń kluczy ani ręcznie kasować rekordów tylko po to, aby ukryć błąd zapisu. Takie działanie może przerwać relacje między tabelą główną a tabelami zależnymi i utrudnić późniejsze odtworzenie poprawnego stanu.