Po co baza, skoro jest arkusz?
🎯 Po co Ci to?
„Zrobię to w arkuszu" — słyszy się o wypożyczalni, sklepie, ewidencji uczniów. Przez chwilę działa. Potem zaczynają się kłopoty: to samo nazwisko zapisane trzy razy różnie, telefon klienta poprawiony w jednym miejscu a nie w pięciu innych, wiersz skasowany „przy okazji" zabiera dane, których nie chciałeś stracić. To nie pech ani niechlujstwo — to strukturalna wada trzymania powiązanych danych w jednej płaskiej tabeli. Zrozumienie, gdzie i dlaczego arkusz pęka, to najlepsze możliwe wprowadzenie do baz danych — bo baza jest dokładnie odpowiedzią na te pęknięcia.
✅ Czego się nauczysz
Po tej jednostce potrafisz:
- nazwać podstawowe pojęcia: rekord, pole, tabela;
- wskazać trzy typy problemów jednej wielkiej tabeli: powtórzenia, sprzeczności, anomalie;
- wyjaśnić, czemu te problemy są strukturalne, a nie kwestią staranności.
🔁 Przypomnij sobie
Z 11.6: dane surowe jako rekordy (wiersz = zdarzenie, kolumny = cechy) — baza pcha tę dyscyplinę do końca; z 11.1: wartość zdublowana zamiast jednego źródła to grzech.
📘 Wyjaśnienie
📐 DEFINICJA — tabela, rekord, pole: tabela przechowuje dane jednego rodzaju; rekord (wiersz) to jeden obiekt (jeden uczeń, jedna książka); pole (kolumna) to jedna cecha (nazwisko, tytuł). Baza danych to zbiór powiązanych tabel.
Po ludzku: tabela to kartoteka, rekord to jedna karta, pole to rubryka na karcie. Czym NIE jest: baza to nie „większy arkusz". Różnica jest jakościowa: baza pilnuje relacji i spójności, arkusz tylko przechowuje i liczy.
Zobaczmy pęknięcia na przykładzie. Wypożyczalnia prowadzi w jednej wielkiej tabeli: kto, co, kiedy wypożyczył — z danymi klienta i książki w każdym wierszu:
klient telefon tytuł autor data
Kowalska 501-234-567 Lalka Prus 2026-01-10
Kowalska 501-234-567 Ferdydurke Gombrowicz 2026-02-03
Kowalska 501-234-576 Zbrodnia i kara Dostojewski 2026-02-20
Nowak 600-111-222 Lalka Prus B. 2026-03-01
Widzisz trzy katastrofy?
- Powtórzenia (redundancja). Telefon Kowalskiej powtórzony przy każdym wypożyczeniu; autor „Lalki" — przy każdym egzemplarzu. Te same fakty zapisane wielokrotnie: marnotrawstwo i zarzewie kolejnych bied.
- Sprzeczności (anomalie). Trzeci wiersz: telefon Kowalskiej to 501-234-576 — literówka. Który jest prawdziwy? Baza z powtórzeniami zaprasza do sprzeczności: poprawisz w jednym miejscu, zapomnisz w drugim. „Prus" i „Prus B." — ta sama osoba? Dwoje autorów? Nie wiadomo.
- Anomalie operacji. Skasujesz wiersz, bo klient oddał książkę — i tracisz jedyny zapis jego telefonu. Chcesz dodać nową książkę, której nikt jeszcze nie wypożyczył — a nie masz gdzie (tabela jest o wypożyczeniach, nie o książkach). Dane różnego rodzaju upchnięte w jedną tabelę blokują się nawzajem.
💭 Pomyśl: Klientka zmienia numer telefonu. Ile komórek trzeba poprawić w tabeli wyżej — i co się stanie, jeśli przy 500 wypożyczeniach przeoczysz jedną?
Sprawdź odpowiedź
Tyle, ile ma wypożyczeń — telefon jest powtórzony w każdym wierszu. Przy 500 wypożyczeniach to 500 poprawek, i wystarczy przeoczyć jedną, by baza zawierała dwa różne telefony tej samej osoby — sprzeczność, której nikt nie zauważy, dopóki ktoś nie zadzwoni pod stary numer. To jest sedno problemu: fakt „telefon Kowalskiej = X" powinien być zapisany raz (zasada z 11.1!), a jest zapisany 500 razy. Baza relacyjna (12.2) rozwiąże to, dając każdemu faktowi jedno miejsce — i wtedy zmiana telefonu to JEDNA poprawka.
🐞 Znajdź błąd
Ktoś „naprawia" powtórzenia, wypełniając telefon tylko w pierwszym wierszu klienta, a w kolejnych zostawiając pusto (żeby nie dublować). Czemu to gorsze niż powtórzenia?
Sprawdź odpowiedź
Teraz dane zależą od kolejności i kompletu wierszy: posortujesz tabelę (11.4!) — i telefon „odczepi się" od klienta, bo był tylko przy pierwszym z jego wierszy. Skasujesz pierwszy wiersz — telefon przepada dla wszystkich pozostałych. „Oszczędzanie" na powtórzeniach przez puste pola tworzy ukryte zależności między wierszami, których żadna operacja nie respektuje. To ślepa uliczka — właściwym rozwiązaniem nie jest sprytniejsze upychanie w jednej tabeli, lecz rozbicie na tabele (12.2). Czasem problemu nie da się załatać; trzeba zmienić strukturę.
🌍 Powiązania
Problem jednej wielkiej tabeli to nie ciekawostka — to codzienność każdej organizacji, która „zaczęła w arkuszu". Sklepy, przychodnie, kluby sportowe, szkolne kółka — wszystkie dochodzą do tej samej ściany, gdy danych i powiązań przybywa. Umiejętność rozpoznania „to już woła o bazę" jest cenna zawodowo: oszczędza miesięcy grzebania w rozjechanych arkuszach. A samo pojęcie redundancji (zapisania tego samego wielokrotnie) i walki z nią wraca w całej informatyce — od kompresji (2.6: usuwanie powtórzeń!) po projektowanie systemów.
🛠️ Teraz Ty
Weź realną „bazę w arkuszu" (lista wypożyczeń, ewidencja sprzętu szkolnego, zapisy na wycieczki z danymi kontaktowymi) — własną albo wymyśloną, 10–15 wierszy. Zaznacz w niej wszystkie powtórzone fakty (te same dane w wielu wierszach). Wskaż jedno miejsce sprzeczności (albo pokaż, jak łatwo ją wprowadzić). Wypisz jedną operację (dodaj/usuń/zmień), która robi kłopot. To rozpoznanie jest połową drogi do dobrego projektu bazy.
📐 Definicje tej lekcji
- Tabela / rekord / pole — kartoteka jednego rodzaju danych / jedna karta (wiersz) / jedna rubryka (kolumna).
- Redundancja — te same fakty zapisane wielokrotnie; źródło marnotrawstwa i sprzeczności.
- Anomalie — kłopoty przy dodawaniu/usuwaniu/zmianie danych w jednej wielkiej tabeli.
📌 Najważniejsze w pigułce
- Jedna wielka tabela dla powiązanych danych pęka: powtórzenia → sprzeczności → anomalie operacji.
- To wada strukturalna, nie kwestia staranności — im więcej danych, tym pewniejsza.
- Każdy fakt powinien być zapisany raz; „sprytne" łatanie w jednej tabeli tylko pogłębia problem.
🎒 Zadania
- W tabeli wypożyczeń ze wstępu wskaż wszystkie powtórzone fakty i policz, ile razy zapisano fakt „autorem «Lalki» jest Prus".
Wskazówka i odpowiedź
Powtórzone: telefon każdego klienta (przy każdym jego wypożyczeniu), autor każdej książki (przy każdym egzemplarzu). „Autor «Lalki» = Prus" zapisano 2 razy (wiersze 1 i 4) — i już przy dwóch wystąpieniach pojawiła się rozbieżność „Prus"/„Prus B."! Redundancja i sprzeczność idą w parze: gdzie fakt powtórzony, tam prędzej czy później rozjazd.
- Zaprojektuj (opisowo) prostą sytuację, w której usunięcie jednego wiersza kasuje dane, których nie chciałeś stracić (anomalia usuwania). Wyjaśnij mechanizm.
Wskazówka i odpowiedź
Np. tabela „uczeń — kółko — opiekun": jeśli Zosia to jedyna uczestniczka kółka szachowego i się wypisuje (kasujesz wiersz), znika też informacja, że opiekunem szachów jest pan Nowak i że takie kółko w ogóle istnieje. Mechanizm: fakty różnego rodzaju (uczestnictwo, istnienie kółka, opiekun) upchnięte w jeden wiersz — usunięcie jednego niszczy wszystkie. Lekarstwo (12.2): osobna tabela kółek, osobna uczestnictw — usunięcie uczestnictwa nie tyka istnienia kółka.
- Kolega mówi: „przecież wystarczy być starannym i nie robić literówek". Odpowiedz mu, czemu staranność nie rozwiązuje problemu redundancji — użyj argumentu ze skali.
Wskazówka i odpowiedź
Staranność skaluje się źle: przy 10 wierszach dopilnujesz, przy 100 000 wypożyczeń i wielu osobach wpisujących dane — nigdy. Jeden fakt w 500 kopiach to 500 okazji do rozjazdu, a wystarczy jedna. Poza tym staranność nie usuwa marnotrawstwa (miejsce) ani anomalii operacji (usuwanie/dodawanie) — te są niezależne od literówek. Właściwe rozwiązanie usuwa możliwość błędu strukturalnie (fakt zapisany raz = nie ma czego rozjechać), zamiast liczyć na ludzką bezbłędność. To głęboka zasada inżynierii: projektuj tak, by błąd był niemożliwy, nie tylko niepożądany.
🔍 Sprawdź, czy umiesz
- Nazwać rekord, pole, tabelę na konkretnym przykładzie.
- Wskazać powtórzenia, sprzeczności i anomalie w płaskiej tabeli.
- Uzasadnić, czemu to wada strukturalna, nie kwestia staranności.