Tabela jest fundamentem relacyjnej bazy danych i SQL. W modelu ER nazywana jest encją. A w modelu relacyjnym relacją. Po co różne nazwy? Czy oznaczają różne funkcje? 

Skąd biorą się niejasności?

Niejasności w nazewnictwie i funkcji tabeli wynikają z drogi, którą przebyła. 

Tabela została wynaleziona ok 50 lat temu przez Edgara Franka Codd’a jako relacja. Piękne i schludne odwzorowanie matematycznej teorii zbiorów. W jego pracach była przedstawiana jako zbiór krotek tej samej dziedziny. Cokolwiek to znaczy. Wyglądało to tak:

Czyste i jednoznaczne określenie matematyczne nie wytrzymało próby czasu. Szczególnie w zderzeniu z drapieżnymi kapitalistami, którzy wprowadzali relacyjne bazy danych pod strzechy datacenter. Dzięki ludziom pokroju Larry’ego Ellison’a coraz mniejsze i mniej zasobne firmy mogły pozwolić sobie na mały komputer z systemem UNIX z instancją relacyjnej bazy danych.

Dosłownie każdy mógł się do instancji podłączyć ze swojego taniego komputera osobistego. UNIX zapewniał wszystkim bezkolizyjny i jednoczesny dostęp do procesów instancji bazy danych. Zupełnie jak, znany z dużych korporacji, mainframe IBM tylko za ułamek kosztów. 

Jak zwiększyć sprzedaż relacyjnych baz danych?

Aby zainteresować ludzi relacyjnymi bazami danych nie można było wymagać od nich uczenia się matematycznej teorii zbiorów. Trzeba było przetłumaczyć jej zawiłości na coś co ogarniali. W końcu nie wszyscy z nich to matematycy czy umysły ścisłe. Część z nich to pracownicy biurowi zajmujący się marketingiem czy sprzedażą. Nie muszą znać matematycznych podstaw aby korzystać z danych.

Trzeba było matematyczną teorię przekuć w łatwy w obsłudze produkt. W końcu nikt nie musi wiedzieć dlaczego samolot lata. Ważne aby płacił za bilety, prawda?

Tutaj pojawia się język SQL. Bardzo prosty i przyjazny. Nawiązujący do języka naturalnego, którym użytkownicy komunikują się na co dzień. Szturmem zdobywa salony producentów relacyjnych baz danych.

Nic dziwnego. Na srebrnej tacy podaje im rozwiązanie. Tłumaczy zawiłości matematyczne na język, który są w stanie przyswoić wszyscy. I to używając znanych słów. Nie ma dziwnych relacji, krotek czy dziedzin. Są znane wszystkim tabele, kolumny i typy danych.

To jest świat znany z arkuszy kalkulacyjnych, które zdobyły serca użytkowników komputerów osobistych. Nawet ci starsi ludzie, pamiętający jeszcze papierowe tabelki czy formularze, są w stanie ogarnąć temat. Szczególnie gdy zilustrowany. Wygląda tak:

Przepoczwarzenie relacji

Matematycznie wysublimowana relacja musi wyjść z hermetycznego laboratorium naukowca. Zrzucić swoją skórę zbioru krotek tej samej dziedziny. Przebrać się za powszechnie akceptowalną celebrytkę kultury masowej. 

Staje przed milionami użytkowników jako zwykła tabela. Posiadająca kolumny o określonych nazwach i typie oraz zbiór wierszy o podobnych cechach. 

Z jednorodnego matematycznego tworu przemienia się w twór użytkowy o dwoistej naturze. Dla każdego. Każdy może jej używać do jakichkolwiek celów zechce. 

Podobną drogę odbywają dane. Zamienią się z matematycznych krotek w znane z arkuszy kalkulacyjnych wiersze. Lub w znane z papierowych formularzy zapisy. Z angielskiego rekordy. Na dodatek nie posortowane. Kolejny ukłon w stronę producentów motorów relacyjnych baz danych. 

Tabela jako kontener na dane

Pierwszą z funkcji tabeli jest grupowanie danych. Jest to funkcja najbardziej rzucająca się w oczy i pierwotnie istniejąca w modelu relacyjnym. Język SQL wyraźnie podkreśla tę rolę tabeli używając odpowiednich słów z języka angielskiego. Jeśli zdarzyło Ci się używać relacyjnej bazy danych z pewnością znasz komendy jak te:

INSERT INTO tabela …
SELECT … FROM tabela
SELECT count(*) FROM tabela

Jako twór grupujący dane dostarcza funkcjonalności pozwalających na operowanie danymi. Umożliwia ich wstawianie, modyfikację, usuwanie i wybieranie z bazy danych. Jednocześnie realizuje postulat Codd’a – ukrywa przed użytkownikiem konkretne miejsce zapisu danych. Motor bazy danych bierze na siebie ciężar zarządzania przestrzenią dyskową. 

Tabela jako zbiór cech danych

Użytkownicy relacyjnych baz danych chcą aby dane, które znajdą się w bazie danych spełniały określone kryteria. 

Kryteria te określane są w modelu relacyjnym i ER jako atrybuty. Każdy z atrybutów składa się z 2 elementów. Pierwszy z nich to nazwa atrybutu. Drugi to dziedzina. 

W języku SQL bardziej znane jako nazwa kolumny i typ. 

Tabela grupuje wiele takich par. Nazwa kolumny musi być unikalna w ramach tabeli. 

Motor bazy danych zdejmuje odpowiedzialność za przestrzeganie tych reguł z barków użytkowników. Pilnuje aby dane znalazły się w odpowiednich kolumnach i miały odpowiedni typ. Na przykład aby dane znakowe nie trafiły do kolumny liczbowej. Lub kolumna znakowa mająca pomieścić 123 znaki nie przyjęła 124.

Nazwy tabel – liczba pojedyncza czy mnoga?

Jeśli traktujesz tabelę jako kontener na dane to spodziewasz się, że danych będzie wiele. Wtedy logicznym jest nazywanie tabeli rzeczownikiem w liczbie mnogiej. Na przykład DZIECI.

Z drugiej strony gdy spojrzysz na tabelę jako na zbiór cech, jakie muszą mieć dane aby zapisać je w bazie danych, to liczba pojedyncza ma więcej sensu. Na przykład DZIECKO.

Tutaj moje wideo w którym ilustruję zagadnienie:

Jeśli używasz liczby pojedynczej to odwołania brzmią bardziej naturalnie:

SELECT
  dziecko.wiek
  ,dziecko.wzrost
FROM
  dziecko
WHERE
  dziecko.imię='Ania';

Taka notacja przypomina notację znaną z obiektowych języków programowania. Kontynuując analogię tabela byłaby klasą, a każdy z rekordów obiektem tej klasy.

Jak tabela łączy obie funkcje?

Tabela, znana z relacyjnej bazy danych, składa się z dwóch części. Wybierając dane z tabeli, przy pomocy klienta interaktywnego, widzisz to za każdym razem. Najpierw widzisz nagłówek tabeli później dane. 

Nagłówek informuje Cię o nazwach kolumn. Następnie w odpowiednich kolumnach pojawiają się przypisane im dane. Czyli, znane z modelu relacyjnego, wartości atrybutów. 

Zupełnie jak w excelu czy na papierze. Nagłówek tabeli określa kontekst danych. Z nagłówka wiesz czy łańcuchy znaków w danej kolumnie to rozmiary czy cyfry. Pod nim znajdują się dane tabeli połączone w wiersze (rekordy). 

Może wyglądać to tak:

Pierwsza kolumna dodana jest przez klienta – SQL Developer.

Tutaj znajdziesz mój artykuł o podstawach wstawiania danych do tabeli w relacyjnej bazie danych: Podstawy INSERT w SQL.

Prowadzę szkolenia i kursy z podstaw SQL. Sprawdź ofertę moich kursów SQL.