Ograniczenia baz danych w Firebird i InterBase
_NOTICE: Ten dokument jest rozdziałem z książki „The InterBase World”, która została napisana przez Aleksieja Kowiazina i Siergieja Wostrikowa.
Ten rozdział poświęcony jest ograniczeniom (constraints) w bazach danych InterBase i Firebird. Ograniczenia bazy danych to reguły, które definiują relacje między tabelami oraz mogą sprawdzać i modyfikować dane w bazie. Reguły te są realizowane jako specjalne obiekty bazy danych. Główna zaleta korzystania z ograniczeń polega na możliwości implementacji kontroli danych oraz części logiki biznesowej aplikacji na poziomie bazy danych, czyli jej centralizacji i uproszczeniu, co czyni tworzenie aplikacji bazodanowych łatwiejszym i bardziej niezawodnym.
Początkujący programiści często zaniedbują korzystanie z ograniczeń bazy danych, uważając, że utrudniają one pracę twórczą. Jednak w rzeczywistości taka opinia wynika z niewystarczającej znajomości teorii i praktyki projektowania baz danych.
Jednocześnie najbardziej doświadczeni projektanci decydują się na rezygnację z niektórych typów ograniczeń, dzięki czemu ich aplikacje zyskują na szybkości. Doświadczenie ekspertów pozwala im bardzo dobrze rozumieć działanie serwera i precyzyjnie przewidywać jego zachowanie w skomplikowanych przypadkach, dlatego początkującym programistom InterBase lepiej nie naśladować takich działań doświadczonych kolegów.
W ramach tej książki nie rozważamy projektowania baz danych, dlatego po więcej informacji na ten temat zobacz listę literatury na końcu książki. Tutaj przejrzymy jedynie wszystkie typy ograniczeń w bazie danych InterBase i rozważymy przykłady ich zastosowania.
Typy ograniczeń w bazie danych
W bazie danych InterBase istnieją następujące typy ograniczeń:
- PRIMARY KEY;
- UNIQUE KEY;
- FOREIGN KEY
- mogą włączać automatyczne triggery - ON UPDATE i ON DELETE;
- CHECK
W poprzednich rozdziałach wspomnieliśmy o niektórych z tych ograniczeń, ponieważ było to konieczne dla logicznej prezentacji materiału, ale teraz rozważymy ich składnię, zastosowanie i implementację bardziej szczegółowo. Ograniczenia bazy danych są dwojakiego rodzaju - oparte na jednym polu oraz oparte na kilku polach tabeli. Składnia obu typów ograniczeń jest podana poniżej.
= [CONSTRAINT constraint]
[ …]
= {UNIQUE | PRIMARY KEY
| CHECK ( )
| REFERENCES other_table [( other_col [, other_col …])]
[ON DELETE {NO ACTION|CASCADE|SET DEFAULT|SET NULL}]
[ON UPDATE {NO ACTION|CASCADE|SET DEFAULT|SET NULL}]
}
Składnia ograniczeń opartych na kilku polach jest następująca:
= [CONSTRAINT constraint]
[< tconstraint> …]
= {{PRIMARY KEY | UNIQUE} ( col [, col …])
| FOREIGN KEY ( col [, col …]) REFERENCES other_table[( other_col [, other_col …])]
[ON DELETE {NO ACTION|CASCADE|SET DEFAULT|SET NULL}]
[ON UPDATE {NO ACTION|CASCADE|SET DEFAULT|SET NULL}]
| CHECK ( )}
Różnica w składni między ograniczeniami opartymi na jednym i na kilku polach jest oczywista - w tym drugim przypadku możemy określić kilka pól objętych ograniczeniem. W przypadku ograniczenia opartego na jednym polu wszystkie opisane opcje dotyczą tylko bieżącego pola. Oczywiście te dwa typy ograniczeń mają różny sposób ich zastosowania: ograniczenia oparte na jednym polu są po prostu dodawane do definicji wymaganego pola, a ograniczenia oparte na kilku polach są określane po przecinku w ogólnej definicji tabeli. Szczegółowe przykłady podano w dalszych częściach tego rozdziału.
Przykład typowego ograniczenia
W rzeczywistości ograniczenia oparte na jednym polu są szczególnym przypadkiem ograniczeń opartych na kilku polach.
Przykład utworzenia ograniczenia klucza głównego przy użyciu tych dwóch różnych podejść podano poniżej. Utwórzmy tabelę zawierającą tylko jedno pole i ustawmy na nim ograniczenie klucza głównego.
Oto przykład klucza głównego przy użyciu składni ograniczenia opartego na jednym polu:
CREATE TABLE test1( ID_PK INTEGER CONSTRAINT pktest NOT NULL PRIMARY KEY); W tym przykładzie klucz główny o nazwie pktest jest tworzony dla pola ID_PK. W rezultacie otrzymujemy dość zwarty opis w jednej linii. Możemy użyć składni ograniczeń opartych na kilku polach do tego samego celu: CREATE TABLE test2( ID_PK INTEGER NOT NULL, CONSTRAINT pktst PRIMARY KEY (ID_PK));
Tworzenie ograniczeń
Rozważmy tworzenie ograniczeń bardziej szczegółowo. Pierwszą w opisie wspólnej składni ograniczeń jest opcja [CONSTRAINT constraint]. Jak widać, opcja ta jest umieszczona w nawiasach kwadratowych, tj. jest opcjonalna.
Używając tej opcji, możesz ustawić nazwę tworzonego ograniczenia zarówno w przypadku stosowania składni ograniczeń opartych na jednym polu, jak i w przypadku ograniczeń opartych na kilku polach. Jeśli nie określiłeś nazwy ograniczenia, InterBase wygeneruje ją automatycznie. Niemniej jednak lepiej jest ustawić nazwę tworzonego ograniczenia, aby poprawić czytelność schematu bazy danych i uprościć późniejsze zarządzanie ograniczeniami.
Po ustawieniu nazwy ograniczenia należy zdefiniować jego typ. Rozważmy różne typy ograniczeń w kolejności, w jakiej są wskazane w opisie wspólnej składni ograniczeń.
Klucze główne i unikalne
Klucze główne są jednym z głównych typów ograniczeń bazy danych. Służą do jednoznacznej identyfikacji rekordów w tabeli. Załóżmy, że przechowujemy listę osób w bazie danych. Jest całkiem możliwe, że będą dwie (lub więcej) osoby o tym samym nazwisku, imieniu i patronimiku. Jak możemy odróżnić jedną osobę od drugiej (oczywiście chodzi o odróżnienie jednej osoby od drugiej według informacji przechowywanych w bazie danych)?
W tym przypadku „osoba” jest reprezentowana przez jeden rekord w tabeli, dlatego możemy zadać bardziej ogólne pytanie - jak możemy odróżnić jeden rekord w (dowolnej) tabeli od innego rekordu w tej samej tabeli. W tym celu stosuje się ograniczenia - klucze główne. Klucz główny reprezentuje jedno lub kilka pól w tabeli, których kombinacja jest unikalna dla każdego rekordu. W tabeli nie ma powtarzających się wartości klucza głównego.
Klucze unikalne pełnią tę samą funkcję - również służą do jednoznacznej identyfikacji rekordów w tabeli. Różnica między kluczami głównymi a unikalnymi polega na tym, że w tabeli może być tylko jeden klucz główny, a kluczy unikalnych może być kilka. Należy zauważyć, że zarówno klucz główny, jak i unikalny mogą być używane jako podstawa odniesienia dla kluczy obcych (patrz dalej).
Formalny opis pojęć kluczy głównych i unikalnych, a także innych ważnych definicji można znaleźć w dodatku „Słownik” na końcu książki. Składnia tworzenia klucza głównego i unikalnego opartego na pojedynczym polu jest następująca:
< pkukconstraint > = [CONSTRAINT constraint] {PRIMARY KEY | UNIQUE}
Przykłady kluczy głównych i unikalnych:
CREATE TABLE pkuk( pk NUMERIC(15,0) NOT NULL PRIMARY KEY, /*klucz główny*/
uk1 VARCHAR(50) NOT NULL UNIQUE,/*klucz unikalny */
uk2 INTEGER NOT NULL UNIQUE /\* jeszcze jeden klucz unikalny */);
Składnia tworzenia kluczy głównych i unikalnych opartych na kilku polach:
= [CONSTRAINT constraint] {PRIMARY KEY | UNIQUE} ( col [, col …])
Taka składnia pozwala na tworzenie kluczy na podstawie kombinacji pól. Oto przykłady tworzenia kluczy głównych i unikalnych z kilku pól:
CREATE TABLE pkuk2( Number1 INTEGER NOT NULL, Name1 VARCHAR(50) NOT NULL, Kol INTEGER NOT NULL, Stoim NUMERIC(15,4) NOT NULL, CONSTRAINT pkt PRIMARY KEY (Number1, Name1), /*klucz główny pkt oparty na dwóch polach*/ CONSTRAINT ukt1 UNIQUE (kol, Stoim)); /*klucz unikalny ukt1 oparty na dwóch polach*/
Zwróć uwagę, że wszystkie pola wchodzące w skład kluczy głównych i unikalnych powinny być zadeklarowane jako NOT NULL, ponieważ klucze te nie mogą mieć niezdefiniowanej wartości. Oprócz tworzenia ograniczeń kluczy głównych i unikalnych podczas tworzenia tabeli istnieje możliwość dodania ograniczeń do już istniejącej tabeli. W tym przypadku używane jest polecenie DDL: ALTER TABLE. Składnia dodawania ograniczeń klucza głównego lub unikalnego do istniejącej tabeli jest podobna do opisanej powyżej:
ALTER TABLE tablename ADD [CONSTRAINT constraint] {PRIMARY KEY | UNIQUE} ( col [, col …])
Rozważmy przykład tworzenia klucza głównego i unikalnego przy użyciu ALTER TABLE:
CREATE TABLE pkalter( ID1 INTEGER NOT NULL, ID2 INTEGER NOT NULL, UID VARCHAR(24));
Następnie dodajemy klucze. Najpierw klucz główny:
ALTER TABLE pkalter ADD CONSTRAINT pkal1 PRIMARY KEY (id1, id2);
Następnie unikalny: ALTER TABLE pkalter ADD CONSTRAINT ukal UNIQUE (uid);
Należy zaznaczyć, że tylko właściciel tej tabeli lub administrator systemowy SYSDBA (więcej szczegółów na temat właścicieli i użytkownika SYSDBA, patrz rozdział „Bezpieczeństwo w InterBase: użytkownicy, ich funkcje i prawa” - część 4) może wykonać dodawanie (jak również usuwanie) kluczy głównych i unikalnych do tabeli.
Klucze obce
Kolejnym ograniczeniem często używanym w bazach danych InterBase jest ograniczenie klucza obcego. Jest to bardzo potężne narzędzie do zapewniania integralności referencyjnej w bazie danych, które pozwala nie tylko nadzorować obecność poprawnych odniesień w bazie, ale także automatycznie kontrolować te odniesienia!
Istota tworzenia klucza obcego jest następująca: jeśli dwie tabele służą do przechowywania powiązanych informacji, konieczne jest zagwarantowanie, że to powiązanie będzie zawsze poprawne. Na przykład dokument „list przewozowy” zawierający nagłówek ogólny (data, numer listu przewozowego itp.) oraz zestaw rekordów szczegółowych (opis towarów, ilość itp.).
Do przechowywania takiego dokumentu w bazie danych tworzone są dwie tabele - jedna do przechowywania nagłówków listów przewozowych, a druga - do przechowywania zawartości listu przewozowego - rekordów o towarach i ich ilości. Takie tabele nazywane są główną i podrzędną lub tabelą-master i tabelą szczegółów.
Zgodnie ze zdrowym rozsądkiem zawartość listu przewozowego nie może istnieć bez obecności jego nagłówka. Innymi słowy, nie możemy wstawić rekordu o towarze, jeśli nie utworzyliśmy nagłówka listu przewozowego, i nie możemy usunąć rekordu nagłówka, jeśli istnieją rekordy o towarach. Dla realizacji takiego zachowania tabela nagłówków i tabela szczegółów są łączone za pomocą ograniczenia klucza obcego.
Rozważmy sens ustawiania ograniczeń kluczy obcych na przykładzie tabel zawierających informacje o listach przewozowych. W tym celu utworzymy dwie tabele do przechowywania listu przewozowego - tabelę TITLE do przechowywania nagłówka oraz tabelę INVENTORY do przechowywania informacji o towarach wchodzących w skład listu przewozowego.
CREATE TABLE TITLE( ID_TITLE INTEGER NOT NULL Primary Key, DateNakl DATE, NumNakl INTEGER, NoteNakl VARCHAR(255));
Zwróć uwagę, że od razu zdefiniowaliśmy klucz główny w tabeli nagłówków oparty na polu ID_TITLE. Pozostałe pola tabeli TITLE zawierają trywialne informacje o nagłówku listu przewozowego - datę, numer, komentarz.
Teraz zdefiniujmy tabelę do przechowywania informacji o towarach wchodzących w skład listu przewozowego:
CREATE TABLE INVENTORY( ID_INVENTORY INTEGER NOT NULL PRIMARY KEY, FK_TITLE INTEGER NOT NULL, ProductName VARCHAR (255), Kolvo DOUBLE PRECISION, Positio INTEGER);
Zobaczmy, jakie pola są zawarte w tabeli INVENTORY. Po pierwsze, jest to ID_INVENTORY - klucz główny tej tabeli. Następnie idzie pole całkowitoliczbowe FK_TITLE służące jako odniesienie do identyfikatora ID_TITLE nagłówka w tabeli nagłówków listów przewozowych. Następnie następują pola ProductName, Kolvo i Positio opisujące opis towaru, jego ilość i pozycję w liście przewozowym. Pole FK_TITLE jest najważniejsze dla naszego przykładu. Jeśli chcemy wypisać informacje o towarach danego listu przewozowego, powinniśmy użyć następującego zapytania, w którym parametr mas_ID_TITLE definiuje identyfikator nagłówka:
SELECT * FROM INVENTORY I1 WHERE I1.FK_TITLE=?mas_ID_TITLE
W zasadzie w opisanej sytuacji nic nie przeszkadza w wypełnieniu tabeli INVENTORY rekordami odnoszącymi się do nieistniejących rekordów w tabeli TITLE. Ponadto nic nie przeszkadza w usunięciu nagłówka już istniejącego listu przewozowego, przez co rekordy o towarach mogą stać się „bezpańskie”. Serwer nie zabroni wykonywania wszystkich tych wstawień i usunięć. Zatem kontrola integralności danych w bazie jest całkowicie przeniesiona na aplikację kliencką. Jednak wiesz, że z jedną bazą danych może pracować kilka aplikacji, opracowanych być może przez różnych programistów, co może prowadzić do różnej interpretacji danych i błędów. W związku z tym niezbędne jest ustawienie jawnego ograniczenia, że do tabeli INVENTORY mogą być wprowadzane tylko takie rekordy o towarach, które mają poprawne odniesienie do nagłówka listu przewozowego. To w istocie jest ograniczenie klucza obcego, które pozwala wstawiać do pól objętych ograniczeniami tylko te wartości, które znajdują się w innej tabeli.
Takie ograniczenie można utworzyć za pomocą klucza obcego. Dla podanego przykładu musimy ustawić ograniczenia klucza obcego dla pola FK_TITLE i powiązać je z kluczem głównym ID_TITLE w tabeli TITLE. Możemy dodać klucz obcy do już istniejącej tabeli za pomocą następującego polecenia:
ALTER TABLE INVENTORY ADD CONSTRAINT fktitle1 FOREIGN KEY(FK_TITLE) REFERENCES TITLE(ID_TITLE)
Często podczas dodawania klucza obcego pojawia się błąd - obiekt jest w użyciu. Chodzi o to, że aby utworzyć klucz obcy, musimy otworzyć bazę danych w trybie pojedynczym - tak, aby w tym samym czasie nie było innych użytkowników. Nie powinniśmy również odwoływać się do modyfikowanej tabeli - może to spowodować błąd “obiekt jest w użyciu”.
Tutaj INVENTORY to nazwa tabeli, dla której ustawiane jest ograniczenie klucza obcego; fktitle1 to nazwa klucza obcego; FK_TITLE - pola tworzące klucz obcy; TITLE to nazwa tabeli dostarczającej wartości (podstawy referencyjnej) dla klucza obcego; ID_TITLE - pola klucza głównego lub unikalnego w tabeli TITLE, które służą jako podstawa referencyjna dla klucza obcego. Pełna składnia ograniczenia klucza obcego (z możliwością tworzenia ograniczeń opartych na kilku polach) jest podana poniżej:
= [CONSTRAINT constraint] FOREIGN KEY ( col [, col …]) REFERENCES other_table [( other_col [, other_col …])] [ON DELETE {NO ACTION|CASCADE|SET DEFAULT|SET NULL}] [ON UPDATE {NO ACTION|CASCADE|SET DEFAULT|SET NULL}]
Jak widać, definicje zawierają duży zestaw opcji. Na początek rozważmy podstawową definicję klucza obcego, która jest najczęściej używana w rzeczywistych bazach danych, a następnie przeanalizujemy możliwe opcje.
Deklaratywna forma ograniczenia klucza obcego jest najczęściej używana, gdy określony jest zestaw pól (col [, col …]), które będą tworzyć ograniczenie, oraz other_table zawierająca listę możliwych wartości dla klucza obcego w polach [(other_col [, other_col …])].
Oto przykład takiej definicji podczas tworzenia tabeli:
CREATE TABLE Inventory2( … FK_TABLE INTEGER NOT NULL CONSTRAINT fkinv REFERENCES TITLE(ID_TITLE) …);
Zwróć uwagę, że w tej definicji pominięto słowa kluczowe FOREIGN KEY, a jedyne pole FK_TITLE jest domyślnie używane jako klucz obcy. Bardziej pełna forma tworzenia klucza obcego jednocześnie z tabelą jest podana w następującym przykładzie:
CREATE TABLE Inventory2( … FK_TABLE INTEGER NOT NULL, CONSTRAINT fkinv FOREIGN KEY (FK_TABLE) REFERENCES TITLE(ID_TITLE) …);
Używanie NULL w polach klucza obcego
W polach, na podstawie których tworzony jest klucz obcy, dozwolone jest stosowanie pól NULL. Ta możliwość została dodana, aby umożliwić wzajemne odwołania. Na przykład, jeśli istnieją dwie tabele odwołujące się do siebie za pomocą kluczy obcych. Jeśli nie zezwolimy na puste odwołanie (tj. NULL) w tych kluczach obcych, niemożliwe będzie dodanie jakiegokolwiek rekordu do połączonych tabel: aby dodać rekord do pierwszej tabeli, wymagany jest rekord w drugiej tabeli i odwrotnie.
Użycie NULL jako pustego odwołania pozwala tworzyć wzajemne odwołania dwóch tabel krzyżowo odwołujących się, a także przechowywać struktury hierarchiczne w tabelach relacyjnych - wtedy węzły główne odwołują się do “pustych” rekordów (tj. po prostu zawierają NULL).
Rozszerzone możliwości wsparcia integralności referencyjnej za pomocą klucza obcego
Zazwyczaj deklaratywny wariant ograniczenia klucza obcego jest wystarczający - serwer tylko pilnuje, aby niemożliwe było wstawienie nieprawidłowych wartości do tabeli z kluczem obcym, a przy próbie takiego działania pojawia się błąd. Ale InterBase pozwala wykonać zestaw automatycznych operacji podczas modyfikowania / usuwania klucza obcego. W tym celu używany jest następujący zestaw opcji klucza obcego:
[ON DELETE {NO ACTION|CASCADE|SET DEFAULT|SET NULL}] [ON UPDATE {NO ACTION|CASCADE|SET DEFAULT|SET NULL}]
Te opcje pozwalają zdefiniować różne operacje podczas aktualizacji lub usuwania wartości klucza obcego.
Na przykład możemy ustawić, że podczas usuwania klucza głównego w tabeli-mistrzu wszystkie rekordy z tym samym kluczem obcym w tabeli podrzędnej powinny zostać usunięte. W tym przypadku musimy zdefiniować klucz obcy w następujący sposób:
ALTER TABLE INVENTORY ADD CONSTRAINT fkautodel FOREIGN KEY (FK_TITLE) REFERENCES TITLE(ID_TITLE) ON DELETE CASCADE
W rzeczywistości do implementacji tych operacji istnieje wyzwalacz systemowy, który wykonuje określone operacje. W tabeli 1.2 znajduje się opis operacji różnych opcji (zwróć uwagę, że opcje NO ACTION|CASCADE|SET DEFAULT|SET NULL nie mogą być używane w jednym zdaniu ON XXX).
Tabela 1.2
| Zdarzenie | Operacja | |||
| NO ACTION | CASCADE | SET DEFAULT | SET NULL | |
| ON DELETE | Podczas usuwania klucza obcego nie rób nic - używane domyślnie | Podczas usuwania usuń wszystkie powiązane rekordy z tabeli podrzędnej | Podczas modyfikowania ustaw pole klucza obcego na wartość domyślną |
Podczas modyfikowania ustaw pole klucza obcego na NULL |
| ON UPDATE | Podczas modyfikowania nie rób nic - używane domyślnie | Podczas modyfikowania rekordu zmodyfikuj wszystkie powiązane rekordy w tabeli podrzędnej | Podczas usuwania ustaw pole klucza obcego na wartość domyślną |
Podczas usuwania ustaw pole klucza obcego na NULL |
Jeśli nie określimy nic lub określimy NO ACTION, musimy samodzielnie zadbać o zmianę klucza obcego (w przypadku zmiany klucza głównego), a podczas usuwania klucza głównego musimy wcześniej usunąć rekordy z tabeli podrzędnej. Bądź bardzo ostrożny podczas używania opcji CASCADE: jej nieostrożne użycie może prowadzić do usunięcia dużej liczby powiązanych rekordów.
Ograniczenie CHECK
Jednym z najbardziej przydatnych ograniczeń w bazie danych jest ograniczenie check. Jego funkcja jest bardzo prosta - sprawdzenie wartości wstawianej do tabeli pod kątem dowolnego warunku i zgodnie z wykonaniem tego warunku wstawienie danych lub ich odrzucenie. Jego składnia jest dość prosta:
= [CONSTRAINT constraint] CHECK ( )}
Tutaj constraint to nazwa ograniczenia; to warunek wyszukiwania, w którym wstawiana / aktualizowana wartość może być parametrem. Jeśli warunek wyszukiwania jest spełniony, dozwolone jest wstawienie / aktualizacja tej wartości, jeśli nie - pojawia się błąd. Najprostszy przykład check:
create table checktst( ID integer CHECK(ID>0));
To sprawdzenie określa, czy wstawiana / aktualizowana wartość pola ID jest większa od zera, i w zależności od wyniku pozwala wstawić / zaktualizować nową wartość lub poinformować o błędzie (patrz rozdział “Rozszerzone możliwości języka procedur składowanych InterBase” (część 1)).
Istnieją również bardziej skomplikowane warianty sprawdzeń. Pełna składnia warunku wyszukiwania jest następująca:
= {
{ | ()}
| [NOT] BETWEEN AND
| [NOT] LIKE [ESCAPE ]
| [NOT] IN ( [ , …] | )
| IS [NOT] NULL
| {[NOT] {= | < | >} | >= | <=}
{ALL | SOME | ANY} ()
| EXISTS ( )
| SINGULAR ( )
| [NOT] CONTAINING
| [NOT] STARTING [WITH]
| ()
| NOT
| OR
| AND }
Zatem CHECK daje duży zestaw opcji do sprawdzania wstawianych / aktualizowanych wartości. Należy pamiętać o następujących ograniczeniach podczas używania CHECK:
- Dane dla CHECK są pobierane tylko z bieżącego rekordu. Nie należy pobierać danych do wyrażenia w CHECK z innych rekordów tej samej tabeli - mogą one zostać zmienione przez innych użytkowników
- Pole może mieć tylko jedno ograniczenie CHECK
- Jeśli do definicji pola używana jest domena mająca ograniczenie CHECK domeny, nie można go przedefiniować na poziomie konkretnego pola w tabeli. Należy powiedzieć, że CHECK są implementowane przez wyzwalacze systemowe, dlatego musimy być ostrożni przy używaniu bardzo długich warunków, które mogą znacznie spowolnić procesy wstawiania i aktualizowania rekordów.
Usuwanie ograniczeń
Bardzo często usuwamy różne ograniczenia z różnych powodów. Aby usunąć ograniczenie, należy użyć instrukcji ALTER TABLE w następującej formie: ALTER TABLE tablename DROP CONSTRAINT constraintname
constraintname to nazwa ograniczenia, które ma zostać usunięte. Jeśli podczas tworzenia ograniczenia podano określoną nazwę, należy jej użyć, ale jeśli nie, musimy otworzyć dowolne narzędzie administracyjne InterBase, przeszukać wszystkie ograniczenia z nim związane i dowiedzieć się, jaką nazwę systemową InterBase wygenerował dla wymaganego ograniczenia.
Należy zauważyć, że tylko właściciel tabeli lub administrator systemowy SYSDBA może usuwać ograniczenia.