Tabele. Klucze podstawowe i generatory
_NOTICE: Ten dokument jest rozdziałem z książki „The InterBase World”, napisanej przez Aleksieja Kowiazina i Siergieja Wostrikowa.
InterBase to relacyjny system zarządzania bazami danych. Oznacza to, że wszystkie dane w InterBase są przechowywane w postaci tabel. Tabela, z punktu widzenia SQL, jest bardzo podobna do zwykłej tabeli, którą można narysować ręcznie na kartce papieru lub utworzyć w programie takim jak Microsoft Excel. Tabele w InterBase mają kolumny i wiersze, w których umieszczane są dane. Tabela musi mieć nazwę, unikalną w obrębie jednej bazy danych. Tabele są głównym miejscem przechowywania informacji w bazie danych, dlatego należy bardzo ostrożnie podchodzić do ich tworzenia.
Istnieją zasady opisujące, jak tworzyć tabele w relacyjnej bazie danych, które odzwierciedlają dane rzeczywistego świata, a jednocześnie pozwalają zorganizować efektywne przechowywanie informacji w bazie. Proces stosowania tych zasad do projektowania „poprawnej” bazy danych nazywa się normalizacją. Celowo użyliśmy cudzysłowu w słowie „poprawna”, ponieważ „znormalizowana baza danych” i „zoptymalizowana baza danych” nie są synonimami. Nie musisz bezwzględnie przestrzegać zasad normalizacji - zawsze uwzględniaj poprawki wynikające ze specyfiki danego problemu.
Normalizacja tabel w bazie danych jest szczegółowo omówiona w książce [14.], dlatego nie będziemy próbować objąć nieobjętego i wrócimy do naszego tematu - tabel w InterBase. Rozważmy składnię polecenia DDL (DDL - Data Definition Language, więcej szczegółów w słowniczku), które pozwala tworzyć tabele:
CREATE TABLE table [EXTERNAL [FILE] “”] ( [, | …]);
Tutaj table to nazwa tworzonej tabeli, - opis kolumn (czasami będziemy mówić - pól) tworzonej tabeli. Opcja table [EXTERNAL [FILE] “”] oznacza, że zostanie utworzona tak zwana tabela zewnętrzna, która jest przechowywana nie we wspólnym pliku bazy danych, ale w osobnym pliku o nazwie . Jak widać, wszystko jest proste - definiujemy nazwę tabeli i kolumny, które zawiera. Teraz przyjrzymy się szczegółowo, jak definiować kolumny. Składnia tworzenia kolumny jest opisana następującym poleceniem DDL:
= col { datatype | COMPUTED [BY] (< expr>)} | domain}
[DEFAULT { literal | NULL | USER}]
[NOT NULL] [ ]
[COLLATE collation]
To dość obszerna definicja, jednak w definicji kolumny tylko niewielka część podanych poleceń jest obowiązkowa. Każda kolumna w tabeli musi mieć nazwę, unikalną w obrębie tabeli, oraz typ danych określony przez polecenie datatype, lub wyrażenie do obliczania wartości kolumny (dla kolumn obliczanych), lub domenę (patrz poniżej), zdefiniowaną jako domain. Typy danych zostały omówione w rozdziale „Typy danych”; dlatego łatwo zrozumiesz, jak tworzone jest wyrażenie SQL do tworzenia tabeli.
Połączmy się z naszą bazą danych FIRSTBASE.gdb, utworzoną wcześniej w rozdziale „Tworzenie bazy danych”, i spróbujmy pracować z tabelami w praktyce. Jeśli chodzi o tworzenie, usuwanie i aktualizowanie tabel, odpowiednie będzie dowolne narzędzie administracyjne InterBase - spośród wymienionych w aplikacji „Narzędzia dla administratorów i programistów InterBase”, a także standardowe narzędzie isql.exe z zestawu dostarczanego z dowolnym klonem InterBase.
Oto przykład prostej tabeli o nazwie TABLE_EXAMPLE zawierającej 3 pola różnych typów:
CREATE TABLE Table_example ( ID INTEGER, NAME VARCHAR(80), PRICE_1 DOUBLE PRECISION);
Ta tabela ilustruje najczęstszy przypadek w procesie tworzenia bazy danych. Istnieją jednak również inne metody definiowania pól. Na przykład możemy ustawić typ pola za pomocą domen. Domena to typ zdefiniowany przez użytkownika dla wygody stosowania określonych kombinacji parametrów typu. Na przykład można zdefiniować domenę D_ID do określania pól identyfikatorów. Po zdefiniowaniu domeny możemy jej użyć do ustawienia typu pola:
CREATE DOMAIN D_ID AS INTEGER; CREATE TABLE Тable_example ( ID D_ID, NAME VARCHAR(80), PRICE_1 DOUBLE PRECISION);
Pole ID będzie miało typ zdefiniowany przez domenę D_ID. W ten sposób, definiując typ pola w domenie, wymagane sprawdzenia i ograniczenia, możemy stosować tę domenę wielokrotnie do tworzenia pól o tej samej funkcji. Na przykład pieniężnych, bez żmudnego i niosącego ryzyko błędów kopiowania definicji typów zmiennych. Trzeci sposób ustawienia kolumny w tabeli to zdefiniowanie jej jako obliczanej (COMPUTED BY) i podanie warunku, według którego jej wartość będzie obliczana. Na przykład możemy chcieć mieć w naszej tabeli kolumnę obliczającą 10% wartości pola PRICE_1. W takim przypadku należy napisać następujące polecenie:
CREATE TABLE Тable_example ( ID INTEGER, NAME VARCHAR(80), PRICE_1 DOUBLE PRECISION, PRICE_10 COMPUTED BY (PRICE_1.0.1));
Ale nie myśl, że teraz, gdy tylko wstawimy dane do pola PRICE_1, w polu PRICE_10 pojawi się dziesiąta część wartości tego pola. Nie, proces tutaj jest bardziej skomplikowany. W rzeczywistości otrzymamy wymaganą dziesiątą część dopiero po odwołaniu się do pola PRICE_10, na przykład podczas wykonywania zapytania SELECT do tej tabeli. Oznacza to, że żadne dane nie są przechowywane w kolumnie obliczanej, a wykonywane jest pobieranie obliczeń wyrażenia związanego z polem, a wynik jest generowany jako odpowiedź na zapytanie.
Omówiliśmy więc 3 główne sposoby określania pól w tabeli. Teraz przyjrzyjmy się szczegółowo opcjom, które można ustawić podczas tworzenia kolumny. Opcja [DEFAULT {literal | NULL | USER}] - pozwala ustawić domyślną wartość kolumny. Jest to bardzo wygodne do automatycznego wypełniania danych. Istnieją 3 sposoby ustawienia wartości domyślnej. Pierwszy jest oznaczony jako literal i pozwala ustawić wartości domyślne jako stałe tekstowe, liczby lub daty. Na przykład możemy wygenerować następujące wyrażenia do tworzenia kolumny z domyślnym tekstem: NAME VARCHAR(80) DEFAULT ‘Василий Станиславович’
W ten sposób wszystkie pola wstawione do tabeli przyjmą wartości domyślne, tj. jeśli dla pola NAME nie zdefiniowano innej wartości, pojawi się ciąg ‘Wasilij Stanisławowicz’. Drugi sposób ustawienia wartości domyślnej to określenie DEFAULT NULL w definicji kolumny. W nowo utworzonych rekordach wartość tej kolumny będzie NULL, jeśli oczywiście nie ustawiono jawnie innej wartości. Przykład:
PRICE_1 DOUBLE PRECISION DEFAULT NULL
Trzeci sposób ustawienia wartości domyślnej to określenie DEFAULT USER w definicji kolumny. W nowo utworzonych rekordach to pole będzie zawierać nazwę bieżącego użytkownika, tj. użytkownika, który nawiązał połączenie z InterBase i wykonał to wstawienie (więcej szczegółów na temat użytkowników w rozdziale „Bezpieczeństwo w InterBase: użytkownicy, ich funkcje i prawa” (część 4)). Dla niektórych pól istotne jest, aby pole miało niepustą wartość. Na przykład pole, które zgodnie ze specyfikacją problemu nie może być puste. Aby ustawić na poziomie bazy danych ograniczenie, że pole powinno mieć określoną wartość, należy dodać do opisu kolumny następujący fragment:
NAME VARCHAR(80) NOT NULL
W ten sposób powstanie pole, w którym nie można przechowywać wartości NULL. Zazwyczaj ograniczenie NOT NULL jest łączone z opcją DEFAULT, która jednoznacznie przypisuje poprawną wartość temu polu. Ale często samo ograniczenie NOT NULL nie wystarcza. Na przykład w przypadku przechowywania cen w bazie danych jest oczywiste, że nie mogą one przyjmować wartości ujemnych (choć byłoby wspaniale, gdyby dopłacano nam przy zakupie towarów). Aby serwer sprawdzał wartości cen wstawianych do bazy danych pod kątem warunku dodatniości, należy zdefiniować kolumnę w następujący sposób:
PRICE_1 DOUBLE PRECISION CHECK (PRICE_1>0)
Wartości wstawiane do kolumny PRICE_1 będą sprawdzane pod kątem warunku dodatniości. Należy zauważyć, że różne spójne opcje można łączyć, a na przykład możemy ustawić niepustą wartość i sprawdzenie dodatniości:
PRICE_1 DOUBLE PRECISION NOT NULL CHECK (PRICE_1>0)
Podczas tworzenia kolumn niektórych opcji nie można łączyć, na przykład nie można ustawić NULL jako wartości domyślnej i jednocześnie ograniczenia niepustej wartości. Należy zaznaczyć, że sprawdzenia mogą pełnić wiele przydatnych funkcji w zarządzaniu danymi w bazie. Szczegółowo omówimy ich użycie w rozdziale „Ograniczenia bazy danych”.
Omówiliśmy więc sposoby tworzenia tabel i pól z różnymi opcjami. Istnieją jednak przypadki, gdy musimy zmienić już istniejącą tabelę. Oczywiście możemy całkowicie odtworzyć tabelę. Najpierw należy wykonać polecenie usunięcia tabeli, a następnie utworzyć ją ponownie. Na przykład:
DROP TABLE Table_example; CREATE TABLE Table_example(ID NUMERIC(15,2);
Ale taki sposób zmiany tabel ma znaczące wady. Podczas usuwania tabeli za pomocą polecenia DROP wszystkie dane zawarte w tabeli są usuwane, a aby ich nie stracić, konieczne jest skopiowanie ich do tabel tymczasowych. To dość uciążliwe. Dlatego istnieje polecenie ALTER TABLE do łatwej zmiany struktury tabel, które pozwala dodawać nowe pola, usuwać istniejące, a także dodawać / usuwać ograniczenia integralności referencyjnej.
Na przykład chcemy dodać do tabeli jeszcze jedną kolumnę przeznaczoną do przechowywania danych o patronimiku osoby:
ALTER TABLE Table_example ADD Patronimic VARCHAR(80);
Po wykonaniu tego polecenia nasza tabela Table_example będzie miała nową kolumnę o nazwie Patronimic i typie VARCHAR(80). Jeśli chcemy usunąć z tabeli kolumnę o nazwie NAME, powinniśmy wykonać następujące polecenie:
ALTER TABLE Table_example DROP Name;
Pełną składnię polecenia ALTER TABLE można zobaczyć w [1.. Jest to bardzo przydatne polecenie i będziemy go często używać.
A co zrobić, zapytasz, jeśli konieczna jest modyfikacja kolumny? Na przykład zdecydowaliśmy, że do przechowywania nazw lepiej użyć pola HUMAN_NAME niż NAME. W takim przypadku możemy zastosować ALTER TABLE:
ALTER TABLE Table_example ALTER COLUMN NAME TO HUMAN_NAME;
Jeśli zdecydowaliśmy się zmienić typ pola, na przykład zwiększyć liczbę znaków przechowywanych w polu, będziemy musieli zmienić domenę tego pola za pomocą polecenia ALTER DOMAIN (patrz rozdział „Typy danych” powyżej).
Omówiliśmy więc tworzenie i modyfikację tabel w InterBase. Teraz czas zagłębić się nieco w teorię baz danych. InterBase, jak już powiedziano, jest relacyjną bazą danych. Oznacza to, że każdy rekord w tabeli powinien mieć cechę, dzięki której można odróżnić jeden rekord od drugiego. Temu celowi służy specjalny mechanizm unikalnych kluczy.
Klucze podstawowe w tabelach
Oczywiście możemy utworzyć tabelę, która nie zawiera żadnych kluczy. Nie jest nam to zabronione. Ale, jak powiedziano wcześniej, stworzenie efektywnej bazy danych jest niemożliwe bez przestrzegania zasad normalizacji. Obecność kluczy jest najważniejszym elementem normalizacji. Dlatego, chociaż nie stawiamy sobie za cel omówienia teorii i normalizacji baz danych, powinniśmy wprowadzić definicję kluczy i omówić ich funkcję w InterBase. Będziemy iść krok po kroku i zaczniemy od najczęstszego typu kluczy - klucza podstawowego.
Czym więc jest klucz podstawowy? To jedno lub więcej pól w tabeli, jednoznacznie identyfikujących rekordy w tej tabeli. Brzmi to skomplikowanie, ale w rzeczywistości wszystko jest bardzo proste. Wyobraź sobie zwykłą tabelę, na przykład arkusz księgowy. Jaka jest pierwsza kolumna? Zgadza się, numer porządkowy - 1, 2, 3 … Ten numer oznacza unikalny wiersz w tabeli i wystarczy znać ten numer, aby znaleźć wiersz w tabeli. W tym przykładzie będzie to klucz podstawowy. Zdecydowana większość tabel w relacyjnej bazie danych koniecznie ma klucz podstawowy (PK - skrót od Primary key). Powszechną wytyczną przy tworzeniu tabel jest tworzenie klucza podstawowego. Klucz podstawowy można utworzyć podczas tworzenia tabeli lub później. Załóżmy, że w momencie tworzenia tabeli zdecydowaliśmy, że pole ID będzie naszym kluczem podstawowym. Wtedy możemy dodać klucz podstawowy w następujący sposób:
CREATE TABLE Table_example ( ID INTEGER NOT NULL, NAME VARCHAR(80), PRICE_1 DOUBLE PRECISION, CONSTRAINT pkTable PRIMARY KEY (ID));
Co należy zrobić, aby utworzyć klucz główny dla tabeli table_example? Sprawdźmy, co zmieniło się w definicji tabeli. Po pierwsze, kolumna ID otrzymała dodatkową definicję NOT NULL. Jest to ważne, ponieważ klucz główny powinien być unikalny i nie może zawierać wartości niezdefiniowanych. A NULL, jak wiadomo, jest wartością niezdefiniowaną. Zatem wszystkie pola wchodzące w skład klucza głównego powinny mieć ograniczenie NOT NULL. Aby dokończyć tworzenie klucza głównego, na końcu tabeli należy zapisać: CONSTRAINT ()
Pełną składnię ograniczeń znajdziesz w rozdziale „Ograniczenia bazy danych” þ. 1, a dla naszego przykładu klucza głównego będzie to wyglądać następująco:
CONSTRAINT pkTable PRIMARY KEY (ID)
Tutaj pkTable to nazwa klucza głównego, a ID to kolumny, które on zawiera. Taki sposób definiowania kluczy głównych dla tabel jest wygodny przy masowym tworzeniu tabel (na przykład podczas budowania prototypu bazy danych na podstawie skryptów otrzymanych z różnych narzędzi CASE). Ale co zrobić, jeśli musimy dodać / usunąć klucz główny do tabeli, która już istnieje i jest wypełniona danymi? W tym celu należy zastosować kolejne rozszerzenie polecenia - ALTER TABLE. Przykład dodania klucza głównego do naszej tabeli:
ALTER TABLE TABLE_EXAMPLE ADD CONSTRAINT FF PRIMARY KEY (ID);
W ten sposób tabela Table_example będzie miała dokładnie taki sam klucz główny jak w poprzednim przykładzie, gdy został utworzony razem z tabelą. Aby usunąć klucz główny, należy wprowadzić następujące polecenie:
ALTER TABLE Table_example DROP CONSTRAINT pkTable;
W ten sposób klucz o nazwie pkTable zostanie usunięty z bazy danych.
Generatory - najlepsi przyjaciele kluczy głównych
Musimy powiedzieć kilka słów o implementacji klucza głównego. Ponieważ ma on zapewniać unikalność, żadne dwa rekordy w jednej tabeli nie mogą mieć tych samych wartości tego klucza. Oznacza to, że aby spełnić ten warunek, podczas wstawiania nowego rekordu do tabeli InterBase musi sprawdzić wszystkie rekordy w tabeli i ustalić, czy tabela zawiera takie wartości, czy nie. Do szybkiego wyszukiwania InterBase wykorzystuje mechanizm indeksów - specjalnych obiektów InterBase, które pozwalają bardzo szybko znaleźć rekord w tabeli. Dlatego podczas tworzenia i usuwania klucza głównego tworzony jest lub usuwany indeks dla tego pola (lub pól), które wchodzi w skład klucza głównego.
Jak powiedziano wcześniej, klucz główny może zawierać kilka pól. W ten sposób możemy zauważyć unikalność kombinacji wartości tych pól. Na przykład, jeśli zdefiniujemy klucz dla pól ID i NAME, serwer będzie kontrolował, czy w tabeli nie ma identycznych kombinacji tych pól. Oznacza to, że kombinacje pól ID i 1 oraz „Ivanov”, 2 oraz „Ivanov” będą poprawne, ponieważ różnią się wartościami pola ID.
Zatem klucz główny może obejmować kilka pól dowolnych typów. Jednak w praktyce najczęstszym typem klucza jest licznik - pole całkowitoliczbowe, które zawiera rosnące wartości. Dlaczego tak jest? Jest to odzwierciedlenie starego sporu między kluczami naturalnymi a zastępczymi. Koncepcja kluczy naturalnych mówi, że jako klucz powinniśmy starać się używać wartości rzeczywiście istniejących w dziedzinie danych, którą odzwierciedla baza danych. Na przykład, jeśli opracowujemy system rejestracji osób dla urzędu paszportowego, zgodnie z tą koncepcją jako klucz główny należy przyjąć kombinację numeru i serii paszportu. Rzeczywiście, każda osoba musi mieć unikalną kombinację numeru i serii paszportu. Jednak co zrobić z faktem, że osoba może zmienić paszport w ciągu życia (w związku z osiągnięciem określonego wieku, zawarciem małżeństwa itp.)? W takim przypadku będziemy musieli zmienić numer i serię paszportu przypisane do konkretnej osoby, czyli faktycznie zmienić nasz klucz główny. Jest to niepożądane z punktu widzenia tworzenia aplikacji bazodanowych: biorąc pod uwagę rozgałęziony system powiązań między tabelami (następny rozdział jest temu poświęcony), programista będzie musiał włożyć wiele wysiłku, aby kontrolować tę sytuację.
Dlatego w większości przypadków stosuje się klucz zastępczy. Zastępczy - oznacza sztuczny, tj. nieistniejący w dziedzinie danych, którą opisuje nasza baza danych, i sztucznie utworzony - dla wygody tworzenia aplikacji bazodanowych. Jak powiedziano, zwykle kluczem głównym jest licznik. Niektóre systemy zarządzania bazami danych, takie jak Paradox i MS SQL, mają specjalny typ - licznik (auto inkrementacja). Podczas dodawania nowego rekordu do tabeli wartość pola automatycznie zwiększa się o wartość przyrostu - zwykle o jeden. W InterBase nie ma pola typu licznik, jednak takie zachowanie można zrealizować. Do utworzenia pola, które byłoby automatycznie wypełniane podczas dodawania rekordu do tabeli, wykorzystuje się zestaw zasobów: pierwszym z nich jest generator.
Czym jest generator? Mówiąc prosto, generator to nazwany licznik. W obrębie bazy danych możemy utworzyć licznik, nadać mu unikalną nazwę w tej bazie i kontrolować wartości tego licznika. To będzie generator. Oto przykład instrukcji DDL, które to wyjaśnią:
CREATE GENERATOR g1; SET GENERATOR g1 TO 2445;
W pierwszej linii tego przykładu tworzony jest generator o nazwie g1, a w drugiej linii przypisywana jest wartość 2445 temu generatorowi. Teraz pojawia się pytanie, jak użyć otrzymanego generatora. W InterBase istnieje wbudowana funkcja GEN_ID do pobierania i zmiany wartości generatorów. Funkcja ta przyjmuje jako parametry nazwę generatora oraz wartość przyrostu, który ma być zastosowany do danego generatora, i zwraca wartość całkowitą odpowiadającą wartości generatora otrzymanej w wyniku dodania do niej przyrostu. Oto przykład wywołania funkcji GEN_ID w triggerze lub procedurze składowanej:
Current_value = GEN_ID (g1, 1)
Jeśli chcemy otrzymać wartość generatora, możemy użyć następującego zapytania:
SELECT GEN_ID(g1, 1)FROM RDB$ DATABASE
Ponieważ tabela RDB $ Database zawsze zawiera tylko jeden rekord, w wyniku tego zapytania otrzymamy wartość generatora g1.
Tutaj current_value to zmienna (w następnych rozdziałach znajdziesz informacje, jak używać zmiennych w InterBase), g1 - generator, 1 - przyrost. W tym przykładzie wartość generatora g1 trafi do zmiennej current_value po dodaniu przyrostu 1, czyli następna wartość generatora. Zwróć uwagę, że przyrost nie musi wynosić 1! Co więcej, może być nawet ujemny: Current_value = GEN_ID (g1, -23)
W wyniku wykonania tej funkcji bieżąca wartość generatora g1 zostanie zmniejszona o 23. Jak widać, zakres możliwych zastosowań generatorów jest dość szeroki - można ich używać nie tylko do uzyskiwania wartości kluczy głównych, ale także do śledzenia globalnych zmian w bazie danych.
Osoby znające bazy danych mogą zadać pytanie: „co się stanie, jeśli jednocześnie kilku klientów spróbuje wstawić dane do tej samej tabeli i jednocześnie „pociągnie” generatory? Czy otrzymają te same czy różne wartości generatora?”. Jednoznacznie otrzymają RÓŻNE wartości generatora. Niezależnie od tego, jak „jednoczesna” była próba uzyskania wartości generatora, każdy, kto się o nią ubiegał, otrzyma unikalną wartość. Gwarantuje to „konstrukcja” generatorów: działają one na najniższym poziomie serwera i żadne procesy zapisu i wstawiania nie mają na nie wpływu - często mówi się, że generatory działają „poza kontekstem transakcji”. Jeśli chcesz dowiedzieć się więcej o transakcjach, przeczytaj rozdział „Transakcje. Parametry transakcji” (część 1); o tym, jak zbudowane są generatory - „Struktura bazy danych InterBase” (część 4). Cóż, w postaci generatorów mamy niezawodny mechanizm tworzenia unikalnych kluczy głównych. Jednak czy możemy użyć tego mechanizmu? Jak umieścić wartość otrzymaną z generatora w polu klucza głównego?
W tym celu istnieją dwa sposoby - wstawienie klucza głównego w imieniu klienta i w imieniu serwera. Aby opanować pierwszy sposób, należy odwołać się do rozdziału „Użycie głównych komponentów FIBPlus”, a aby zrozumieć drugi - do rozdziału „Triggery” (część 1). Tutaj krótko omówimy główną istotę obu sposobów.
W przypadku tworzenia klucza głównego w imieniu klienta dzieje się następująco. Gdy generowany jest rekord, który ma zostać wstawiony do bazy danych, wykonywane jest wywołanie funkcji GEN_ID (, 1), a otrzymana wartość jest podstawiana do tego rekordu. Następnie następuje wstawienie do tabeli i mamy gwarancję otrzymania unikalnego klucza głównego.
Drugi sposób - tworzenie klucza głównego w imieniu serwera - w zasadzie eliminuje wszelką troskę klienta o to, jaka będzie wartość klucza głównego. W tym przypadku podczas wstawiania rekordu działa trigger - specjalny obiekt bazy danych, który może wykonywać dowolne operacje podczas wstawiania / usuwania / aktualizowania rekordów w tabelach. W tym triggerze wykonywane są następujące operacje: wywołanie funkcji GEN_ID, otrzymanie wymaganej wartości generatora i jej wstawienie do tabeli. Zaletą drugiego sposobu jest to, że podczas tworzenia aplikacji klienckiej nie trzeba w ogóle martwić się o tworzenie klucza głównego - jedyne, co trzeba zrobić, to raz napisać odpowiedni trigger. Wadą jest jednak to, że nie możemy otrzymać wartości wygenerowanego klucza w aplikacji bezpośrednio po wstawieniu! Jeśli użyjemy pierwszego sposobu, możemy otrzymać wartość klucza głównego, chociaż musimy dbać o jego tworzenie przy każdym wstawieniu. Trudno jednoznacznie stwierdzić, który sposób jest lepszy - wszystko zależy od konkretnego problemu. W dalszej części tej książki rozważymy możliwe warianty rozwiązywania kwestii związanych z pracą z kluczem głównym.
Podsumowanie
Tak więc w tym rozdziale omówiliśmy, jak tworzyć i aktualizować tabele w InterBase, a także jak zarządzać kluczami głównymi. W ten sposób rozważyliśmy główne obiekty w InterBase, które można warunkowo nazwać statycznymi, ponieważ przechowują one tylko informacje i nie wykonują ich przetwarzania. Następnie porozmawiamy o sposobach kontroli informacji i przetwarzania informacji w bazie danych.