Wprowadzenie do relacyjnych baz danych

Wykład 1: Wprowadzenie do relacyjnych baz danych

Od problemu organizacyjnego do projektu bazy

Wyobraźmy sobie ośrodek szkoleniowy, który organizuje kilka kursów. Początkowo wystarcza arkusz: nazwisko uczestnika, temat kursu, termin, sala i nazwisko prowadzącego. Z czasem ten sam kurs odbywa się wielokrotnie, uczestnicy zmieniają decyzje, a kilka osób jednocześnie aktualizuje zapisy.

Wtedy pojawiają się pytania:

Która lista uczestników jest aktualna?
Czy rezygnacja z jednego terminu usuwa osobę również z pozostałych zajęć?
Czy dwa wpisy o tej samej osobie oznaczają pomyłkę, czy dwa różne zapisy?
Jak policzyć wolne miejsca, jeśli część zapisów anulowano?

Projektowanie bazy zaczyna się od ustalenia znaczenia danych i zasad ich zmieniania. Wybór programu i pisanie poleceń są kolejnymi krokami. Nawet sprawnie działający system może udzielać błędnych odpowiedzi, jeśli źle opisaliśmy rzeczywistość.

Co mamy zrozumieć po tym wykładzie?

Czym różnią się dane, informacja, baza danych i program zarządzający bazą.
Dlaczego model relacyjny oddziela logiczny opis danych od szczegółów ich przechowywania.
Po co rozróżniamy perspektywę użytkownika, wspólny model bazy i fizyczny zapis.
Co oznaczają tabela, wiersz, kolumna, dziedzina, schemat i stan danych.
Jak identyfikatory i ograniczenia pomagają wykrywać błędne zapisy.

Na pierwszych zajęciach poznajemy pojęcia, ale zadaniem projektowym jest zebranie wymagań. Nie trzeba jeszcze samodzielnie projektować tabel, rysować formalnego diagramu ani pisać zapytań.

Dlaczego same pliki przestały wystarczać?

Przechowywanie danych w oddzielnych plikach

W podejściu plikowym każdy program może utrzymywać własny zestaw danych i własne reguły ich odczytu. Jedna osoba prowadzi listę zgłoszeń, druga listę obecności, a trzecia zestawienie sal. Problemem nie jest sam plik, lecz brak wspólnie egzekwowanego opisu danych i zasad pracy.

W naszym ośrodku nazwisko uczestnika może pojawić się w kilku arkuszach. Jeśli poprawimy je tylko w jednym miejscu, powstaną sprzeczne wersje. Jeśli dwa programy inaczej rozumieją „anulowanie”, jeden może usunąć zapis, a drugi całą osobę.

Problem	Przykład w ośrodku	Czego potrzebujemy?
Powielanie faktów	Dane prowadzącego są przepisywane przy każdym zapisie	Jednego uzgodnionego miejsca przechowywania danego faktu
Sprzeczne aktualizacje	Dwie osoby inaczej zmieniają tę samą listę	Kontroli równoczesnej pracy
Brak wspólnych ograniczeń	Zapis wskazuje nieistniejący termin	Sprawdzania poprawności powiązań
Zależność programu od formatu	Zmiana układu pliku wymaga poprawienia wielu programów	Oddzielenia sposobu użycia danych od ich fizycznego zapisu

Baza danych również może korzystać z plików na dysku. Różnica polega na tym, że wyspecjalizowane oprogramowanie zarządza ich zawartością i udostępnia dane według określonych reguł. Nie chodzi więc o zastąpienie „złych plików” czymś, co nie używa plików.

Pytanie do przemyślenia: czy przeniesienie trzech sprzecznych arkuszy do jednego katalogu sprawi, że ich zawartość stanie się spójna?

Od modeli hierarchicznych do modelu relacyjnego

W latach 60. i 70. XX wieku rozwijały się systemy zarządzania dużymi zbiorami danych. Modele hierarchiczne organizowały dane w struktury przypominające drzewa. Modele sieciowe pozwalały opisywać bardziej rozbudowane powiązania i poruszać się po nich określonymi ścieżkami. Nie należy utożsamiać historycznego modelu sieciowego ze współczesną aplikacją działającą przez internet.

Istotną trudnością była zależność programu od sposobu organizacji i dostępu do danych. Edgar F. Codd w pracy z 1970 roku zaproponował model relacyjny, oparty na relacjach matematycznych. Ważną ideą było umożliwienie pracy na logicznym opisie danych bez znajomości szczegółów ich wewnętrznej reprezentacji. Praca Codda — IBM Research.

Dla użytkownika oznacza to zmianę sposobu myślenia: zamiast wskazywać ścieżkę przejścia po fizycznych strukturach, opisuje on, jakich danych potrzebuje. Sposób ich znalezienia w dużej mierze dobiera system zarządzający bazą.

Model relacyjny nie gwarantuje sam z siebie bezpieczeństwa ani poprawności wszystkich danych. Daje podstawy ich opisu i przetwarzania; projektant musi jeszcze określić właściwe reguły, a system musi je egzekwować.

Dane, informacja, baza danych i oprogramowanie

Dane a informacja

Dane to zapisane wartości, takie jak liczba 4, oznaczenie E2 czy tekst cancelled. Informacja powstaje, gdy odczytujemy te wartości w odpowiednim kontekście.

Przykład:

4 oznacza limit uczestników edycji E2;
na E2 jest jeden potwierdzony zapis;
z połączenia tych danych wynika informacja: na E2 pozostały trzy wolne miejsca.

Sam zapis liczby nie mówi, czy chodzi o liczbę sal, uczestników, czy wolnych miejsc. Dlatego w projekcie musimy ustalić znaczenie każdej informacji. Równie ważne jest znaczenie statusu: anulowany zapis istnieje w ewidencji, lecz nie zajmuje miejsca.

Baza danych — co przechowujemy?

Baza danych, w skrócie BD, to zorganizowany zbiór powiązanych danych dotyczących określonego obszaru rzeczywistości. Angielski termin to database, skrót DB.

W ośrodku bazą są zapisane informacje o uczestnikach, kursach, edycjach i zgłoszeniach wraz z ich organizacją. Baza nie musi znajdować się na jednym fizycznym komputerze: centralny, uzgodniony opis danych nie oznacza obowiązkowo jednego miejsca ich przechowywania.

Nie wystarczy też nazwać zbioru „bazą”, aby automatycznie stał się trwały i bezpieczny. Trwałość, kontrola dostępu i możliwość odtworzenia danych wymagają odpowiednich mechanizmów oraz konfiguracji.

DBMS i SZBD — kto zarządza danymi?

DBMS — Database Management System oznacza system zarządzania bazą danych, po polsku SZBD. To oprogramowanie, które obsługuje tworzenie struktur, odczyt i modyfikowanie danych oraz kontrolę dostępu do nich.

Rozróżnijmy trzy rzeczy:

Element	Co oznacza?	Przykład
Baza danych	Konkretny zbiór danych i jego struktura	Dane naszego ośrodka
DBMS / SZBD	Oprogramowanie zarządzające bazą	PostgreSQL, MySQL, Oracle Database, Microsoft SQL Server, SQLite
Aplikacja	Narzędzie realizujące potrzeby użytkownika	Formularz zapisów i raport dla kierownika

Jeden system zarządzania może obsługiwać różne bazy, a z tych samych danych mogą korzystać różne aplikacje. SQLite jest przykładem silnika działającego wewnątrz aplikacji, a nie obowiązkowo jako osobny serwer. To nadal system zarządzający bazą.

Do zadań DBMS należą między innymi:

obsługa struktury: jakie dane przechowujemy i jakie ograniczenia obowiązują;
odczyt i modyfikacja: znajdowanie, dodawanie, poprawianie i usuwanie danych;
kontrola spójności: odrzucanie operacji naruszających zdefiniowane ograniczenia;
koordynowanie zmian: obsługa transakcji, czyli operacji wykonywanych jako jedna logiczna całość;
organizacja dostępu: dobór sposobu wyszukania danych oraz mechanizmy uprawnień i odtwarzania właściwe danemu systemowi.

Oprogramowanie nie domyśli się jednak, że limit szkolenia powinien wynosić 12. Regułę trzeba najpierw uzgodnić, a dopiero później zapisać i egzekwować.

CRUD — cztery podstawowe operacje

CRUD — Create, Read, Update, Delete to nazwa czterech podstawowych rodzajów operacji na danych.

Litera	Angielska nazwa	Znaczenie	Przykład
C	Create	Utworzenie danych	Dodanie nowej edycji kursu
R	Read	Odczyt danych	Wyświetlenie zapisów na E1
U	Update	Aktualizacja danych	Zmiana statusu zapisu na anulowany
D	Delete	Usunięcie danych	Usunięcie omyłkowo utworzonego rekordu, jeśli pozwalają na to reguły

Rezygnacja uczestnika nie musi oznaczać operacji Delete. W naszym projekcie zachowujemy zapis i zmieniamy jego status, więc jest to Update. Wybór operacji wynika ze znaczenia zdarzenia.

SQL — język, a nie baza

SQL — Structured Query Language, po polsku strukturalny język zapytań, służy między innymi do definiowania struktur, pobierania i zmieniania danych w systemach relacyjnych.

Polecenia SELECT (wybierz dane), INSERT (wstaw dane), UPDATE (zaktualizuj dane) i DELETE (usuń dane) odpowiadają różnym operacjom. To angielskie słowa kluczowe, nie skróty. Litera C w CRUD oznacza tworzenie rekordu; nie należy jej utożsamiać wyłącznie z poleceniem CREATE TABLE, które tworzy strukturę tabeli.

Na razie wystarczy rozumieć intencję: „pokaż potwierdzonych uczestników E1”. Składni zapytań będziemy uczyć się później. SQL jest językiem, PostgreSQL jest systemem zarządzającym, a dane ośrodka stanowią bazę.

Po co nam trzy poziomy opisu danych?

Poznaliśmy problem rozproszonych plików oraz rolę wspólnego systemu zarządzającego. Pozostaje pytanie: czy każdy użytkownik musi znać całą strukturę bazy i sposób zapisu na dysku?

W ośrodku występują różne potrzeby:

prowadzący chce listy potwierdzonych uczestników swojej edycji;
kierownik chce zestawienia wszystkich terminów i wolnych miejsc;
osoba administrująca bazą chce przyspieszyć odczyt dużej liczby zapisów.

To trzy spojrzenia na te same dane. Nie powinniśmy tworzyć trzech niezależnych, ręcznie uzgadnianych kopii tylko dlatego, że odbiorcy potrzebują innych zestawień. Nie chcemy też zmieniać raportu kierownika za każdym razem, gdy administrator zmieni organizację plików.

Właśnie temu rozdzieleniu służy architektura ANSI/SPARC. Łączy się z wcześniejszą częścią wykładu poprzez ideę niezależności danych: użytkownik opisuje potrzebną informację, a szczegóły przechowywania pozostają zadaniem systemu.

Co oznacza ANSI/SPARC?

ANSI — American National Standards Institute: Amerykański Narodowy Instytut Normalizacyjny.
SPARC — Standards Planning and Requirements Committee: komitet planowania standardów i wymagań.

Nazwa odnosi się do prac nad architekturą systemów baz danych. Wykorzystujemy ją jako model odniesienia, który porządkuje trzy poziomy opisu. Nie jest to dodatkowy program do instalacji ani obietnica, że każdy produkt ma trzy osobne moduły dokładnie o tych nazwach. Raport architektury ANSI/X3/SPARC.

Te same dane, trzy różne pytania

Poziom	Nazwa angielska	Pytanie	Przykład w ośrodku
Zewnętrzny	External level	Jakich danych potrzebuje dany użytkownik lub aplikacja?	Lista uczestników E1 dla prowadzącego; raport wolnych miejsc dla kierownika
Pojęciowy, czyli logiczny opis całej bazy	Conceptual level	Jakie fakty przechowujemy i jak są ze sobą powiązane?	Uczestnicy, edycje i zapisy; zapis wskazuje uczestnika i edycję oraz ma status
Wewnętrzny, czyli fizyczny	Internal level	Jak system zapisuje i odnajduje te dane?	Pliki, strony danych i indeksy przyspieszające wyszukiwanie

Poziom zewnętrzny nie oznacza tylko wyglądu okienka. Określa zakres i postać danych dostępnych z danej perspektywy. Może być realizowany przez zapytania, raporty lub widoki bazy. Samo pominięcie kolumny w raporcie nie odbiera uprawnień do jej odczytu inną drogą — kontrolę dostępu trzeba skonfigurować.

Poziom pojęciowy jest wspólnym opisem całej bazy, a nie osobną listą dla każdego odbiorcy. W systemie relacyjnym wyrażamy go za pomocą struktur relacyjnych i ograniczeń. Pytamy tutaj o znaczenie danych, a nie o położenie bajtów na dysku.

Poziom wewnętrzny obejmuje technikę przechowywania. Indeks można na tym etapie wyobrazić sobie jako dodatkową strukturę ułatwiającą znalezienie danych, podobnie jak indeks haseł w książce. Szczegóły indeksowania nie są potrzebne do zrozumienia reguły zapisu na kurs.

flowchart TB
    A["Prowadzący: lista uczestników E1"] --> C["Wspólny opis: uczestnik — zapis — edycja"]
    B["Kierownik: terminy i wolne miejsca"] --> C
    C --> D["Zapis wewnętrzny: pliki i indeksy"]

Strzałki oznaczają powiązanie opisów, nie kopiowanie bazy ani kolejność przesyłania żądania przez sieć.

Niezależność fizyczna i logiczna — co ma pozostać bez zmian?

Fizyczna niezależność danych — physical data independence oznacza możliwość zmiany organizacji przechowywania bez zmiany logicznego opisu danych. Administrator może dodać indeks ułatwiający wyszukiwanie zapisów po edycji. Prowadzący nadal prosi o tę samą listę uczestników, a znaczenie jej kolumn pozostaje takie samo.

Logiczna niezależność danych — logical data independence oznacza możliwość zmiany wspólnego schematu przy zachowaniu potrzebnych opisów zewnętrznych i współpracujących z nimi aplikacji. Przykładowo po rozdzieleniu opisu kursu i jego edycji można utrzymać dotychczasowy raport dzięki odpowiedniemu odwzorowaniu danych.

To cel projektowy, nie automatyczna ochrona przed każdą zmianą. Usunięcie informacji potrzebnej raportowi albo zmiana znaczenia kolumny może wymagać poprawienia aplikacji. Zachowanie zgodnego raportu po przebudowie schematu również wymaga pracy.

Co łączy ten model z resztą wykładu?

Pliki pokazały problem zależności programów od organizacji danych. DBMS dostarcza mechanizmy wspólnego zarządzania. ANSI/SPARC pomaga rozdzielić potrzeby odbiorcy, znaczenie danych i sposób ich zapisu. Za chwilę model relacyjny pokaże, jak opisać wspólną strukturę za pomocą relacji i kluczy.

Nie myl tych trzech poziomów z podziałem aplikacji na interfejs, serwer i bazę. ANSI/SPARC opisuje perspektywy danych, a nie trzy komputery lub procesy.

Sprawdź rozumienie: dodajemy indeks, przygotowujemy nowy raport dla prowadzącego i zmieniamy sposób powiązania zapisów z edycjami. Którego poziomu dotyczy każda z tych zmian?

Jak model relacyjny opisuje dane?

Relacja, tabela i znaczenie wiersza

W matematycznym modelu relacyjnym relacja — relation jest zbiorem krotek o określonej strukturze. Praktycznym sposobem jej przedstawienia jest tabela. Tabele języka SQL nie odwzorowują wszystkich własności relacji idealnie: mogą między innymi zawierać powtórzenia wierszy, jeśli odpowiednie ograniczenia ich nie zabraniają.

Przykładowy fragment danych o zapisach:

enrollment_id	participant_id	edition_id	status
Z1	U1	E1	confirmed
Z2	U2	E1	confirmed
Z3	U3	E2	confirmed
Z4	U2	E2	cancelled

W nazwach kolumn id oznacza identifier, czyli identyfikator. U1 to Ada, U2 to Bartek, U3 to Celina. Każdy wiersz opisuje jeden zapis uczestnika na edycję, a nie całą osobę ani cały kurs.

Dobra tabela ma jasno ustalone znaczenie wiersza. Może opisywać obiekty, zdarzenia lub powiązania — tabela zapisów jest właśnie przykładem powiązania. Nie chodzi o to, żeby wszystkie kolumny miały ten sam typ danych, lecz żeby wspólnie opisywały ten sam rodzaj faktu.

Tabela nie jest uporządkowaną listą. Bez jawnego sortowania nie wolno zakładać kolejności wyników. Służy do tego między innymi ORDER BY — „uporządkuj według”. Nazwa tabeli musi być jednoznaczna w odpowiedniej przestrzeni nazw; różne schematy tej samej bazy mogą zawierać tabele o tej samej krótkiej nazwie.

Krotka, atrybut i dziedzina

Krotka — tuple, w praktyce wiersz lub rekord: pojedynczy zapis zgodny ze strukturą relacji. Wiersz Z4 mówi o zapisie Bartka do E2, obecnie anulowanym.
Atrybut — attribute, w praktyce kolumna: nazwana właściwość, np. status zapisu albo identyfikator edycji.
Dziedzina — domain: zbiór dopuszczalnych wartości atrybutu. Status w naszym projekcie przyjmuje confirmed albo cancelled.

Typ „tekst” dopuszcza znacznie więcej wartości niż te dwa statusy. Typ danych i reguła dziedziny nie zawsze są tym samym. Podobnie liczba całkowita może być ujemna, ale limit uczestników ma być dodatni.

Schemat a aktualny stan danych

Schemat relacji — relation schema opisuje jej strukturę: atrybuty, ich dziedziny oraz ograniczenia. Stan relacji — relation instance to zbiór krotek występujących w danym momencie.

Dopisanie kolejnego uczestnika zmienia stan danych, ale nie musi zmieniać schematu.
Dodanie nowego atrybutu opisującego zapis zmienia schemat.
Zmiana confirmed na cancelled zmienia stan konkretnego zapisu.

Słowo „schemat” bywa też nazwą przestrzeni nazw w konkretnym systemie bazodanowym. Tutaj interesuje nas przede wszystkim schemat jako opis struktury, w odróżnieniu od aktualnej zawartości.

Jak rozpoznać rekord i odrzucić błędny zapis?

Klucz kandydujący i klucz główny

Dwie osoby mogą mieć takie samo imię i nazwisko. Potrzebujemy więc sposobu jednoznacznego wskazania rekordu, który nie zależy od jego miejsca na ekranie.

Klucz kandydujący — candidate key jest minimalnym zestawem atrybutów jednoznacznie identyfikującym krotkę. „Minimalny” znaczy, że usunięcie któregokolwiek atrybutu z tego zestawu pozbawiłoby go tej własności. Klucz może składać się z jednej lub kilku kolumn.

Klucz główny — primary key, PK to wybrany klucz kandydujący. Jego wartości mają być unikalne, a żaden składnik nie może być NULL. NULL nie jest skrótem: w SQL jest znacznikiem braku wartości, nie liczbą zero ani pustym tekstem.

W tabeli uczestników możemy użyć participant_id. Adres e-mail nie staje się dobrym kluczem tylko dlatego, że w kilku przykładowych wierszach jest różny. Najpierw trzeba ustalić, czy jest wymagany i czy rzeczywiście ma być unikalny.

W tabeli zapisów można nadać każdemu rekordowi enrollment_id, lecz nadal potrzebna jest reguła „najwyżej jeden zapis danej osoby do danej edycji”. Dwa różne identyfikatory zapisu same nie zapobiegną powtórzeniu pary uczestnik–edycja.

Klucz obcy — odwołanie do istniejących danych

Klucz obcy — foreign key, FK to atrybut lub zestaw atrybutów, którego wartości odwołują się do dopuszczonego klucza w tabeli wskazywanej. Najczęściej jest to jej klucz główny, ale może to być także odpowiedni klucz unikalny. Odwołanie może prowadzić również do tej samej tabeli.

W naszym przykładzie participant_id w zapisie wskazuje istniejącego uczestnika, a edition_id istniejącą edycję. Próba zapisania osoby U99, której nie ma w ewidencji, powinna zostać odrzucona przez poprawnie zdefiniowane ograniczenie.

Klucz obcy nie przechowuje kopii całej osoby. Przechowuje odwołanie, dzięki któremu możemy powiązać zapis z właściwym uczestnikiem. Nie sprawdza jednak sam, czy na edycji jest wolne miejsce. Przykłady ograniczeń w dokumentacji PostgreSQL.

Integralność — jakie błędy chcemy wykryć?

Integralność danych — data integrity oznacza zgodność danych z ustalonymi ograniczeniami. Rozróżnimy trzy podstawowe grupy:

Rodzaj	Nazwa angielska	Sens	Przykład błędu
Integralność encji	Entity integrity	Rekord ma jednoznaczną tożsamość; klucz główny jest unikalny i bez NULL	Dwie osoby otrzymały to samo `participant_id`
Integralność referencyjna	Referential integrity	Odwołania prowadzą do istniejących danych	Zapis wskazuje uczestnika U99, którego nie ma
Integralność dziedzinowa	Domain integrity	Wartości spełniają ograniczenia dziedziny	Limit wynosi −3 albo status ma niedopuszczalną wartość

Jeśli powiązanie jest opcjonalne, klucz obcy może dopuszczać brak wartości zgodnie z jego definicją. Gdy zapis obowiązkowo musi wskazywać uczestnika, oprócz odwołania wymagamy niepustej wartości. Te zasady należy ustalić jawnie.

Istnieją też reguły biznesowe — business rules, np. nieprzekraczanie limitu potwierdzonych zapisów lub zakaz nakładających się zajęć w tej samej sali. Ich egzekwowanie może wymagać uwzględnienia wielu rekordów i odpowiedniej obsługi równoczesnych operacji. Nie każdą regułę da się wyrazić samym kluczem obcym czy typem kolumny.

Na dzisiejszych zajęciach wystarczy umieć nazwać regułę i pokazać sytuację, która ją narusza. Dobór mechanizmu jej realizacji będzie kolejnym etapem projektu.

Od wykładu do pierwszego zadania projektowego

Przeszliśmy od problemu kilku ewidencji do wspólnego opisu danych:

Potrzeby użytkownika mówią, na jakie pytania ma odpowiadać system.
Dane potrzebują ustalonego znaczenia i reguł.
DBMS zarządza ich zapisem i przetwarzaniem.
ANSI/SPARC rozdziela perspektywę odbiorcy, strukturę logiczną i zapis fizyczny.
Model relacyjny daje pojęcia potrzebne do opisu struktury, a klucze i ograniczenia pomagają pilnować poprawności.

Teraz pracujecie w parach jako projektanci bazy dla ośrodka. Prowadzący odgrywa klienta. Najpierw ustalacie wymagania, nie próbujecie od razu zamieniać każdego słowa na tabelę.

Otwórzcie opis projektu i formularz. Przygotujcie trzy pytania z uzasadnieniem. Po omówieniu odpowiedzi uzupełnicie pojęcia, reguły i analizę przypadku. Formularz zostawcie otwarty w osobnej karcie, a przed zamknięciem pobierzcie kopię notatki.

Słownik skrótów i nazw

Skrót lub zapis	Pełna nazwa angielska	Znaczenie po polsku
BD / DB	Database	Baza danych; BD jest skrótem polskim, DB angielskim
SZBD / DBMS	Database Management System	System zarządzania bazą danych
SQL	Structured Query Language	Strukturalny język zapytań
CRUD	Create, Read, Update, Delete	Tworzenie, odczyt, aktualizacja i usuwanie danych
ANSI	American National Standards Institute	Amerykański Narodowy Instytut Normalizacyjny
SPARC	Standards Planning and Requirements Committee	Komitet planowania standardów i wymagań
PK	Primary Key	Klucz główny
FK	Foreign Key	Klucz obcy
ID / id	Identifier	Identyfikator
NULL	Nie jest skrótem	Znacznik braku wartości w SQL

Nazwy produktów, takie jak PostgreSQL czy SQLite, oznaczają konkretne oprogramowanie. confirmed znaczy „potwierdzony”, a cancelled — „anulowany”; są to wartości statusu w naszym przykładzie.

Pytania do samodzielnego sprawdzenia

To powtórka po lekturze, a nie formularz punktowanego quizu.

Pytania jednokrotnego wyboru

Kto zaproponował model relacyjny w pracy z 1970 roku?
1. Donald Knuth.
2. Edgar F. Codd.
3. Bill Gates.
4. Charles Bachman.
Co opisuje poziom pojęciowy, czyli logiczny, w architekturze ANSI/SPARC?
1. Położenie danych w plikach.
2. Wyłącznie wygląd formularza użytkownika.
3. Wspólną strukturę danych i ich powiązania.
4. Sposób zestawiania połączenia sieciowego.

Pytania opisowe

Wyjaśnij różnicę między daną i informacją na przykładzie wolnych miejsc.
Rozróżnij bazę ośrodka, DBMS i aplikację zapisów.
Rozwiń CRUD i wyjaśnij, dlaczego anulowanie zapisu jest w naszym projekcie aktualizacją.
Po co model ANSI/SPARC wprowadza trzy poziomy? Podaj przykład dla każdego z nich.
Wyjaśnij różnicę między fizyczną i logiczną niezależnością danych. Czy każda zmiana jest przez to niewidoczna dla aplikacji?
W tabeli zapisów wskaż krotkę, atrybut i przykład dziedziny. Czy kolejność wierszy określa ich tożsamość?
Czym różni się schemat relacji od jej aktualnego stanu?
Dlaczego imię i nazwisko nie muszą być kluczem? Co znaczy minimalność klucza kandydującego?
Która zasada zabroni zapisania oceny dla nieistniejącego studenta, jeśli tabela ocen odwołuje się do studentów kluczem obcym?
Podaj regułę ośrodka, której nie sprawdzi samo istnienie klucza obcego.