Databasebeperkingen in Firebird en InterBase
NOTICE: Dit document is een hoofdstuk uit het boek “The InterBase World”, geschreven door Alexey Kovyazin en Serg Vostrikov.
Dit hoofdstuk is gewijd aan de beperkingen (constraints) van InterBase- en Firebird-databases. Databasebeperkingen zijn regels die de onderlinge relaties tussen tabellen definiëren en die gegevens in een database kunnen controleren en wijzigen. Deze regels worden gerealiseerd als speciale databaseobjecten. Het belangrijkste voordeel van het gebruik van beperkingen is de mogelijkheid om gegevenscontrole en een deel van de bedrijfslogica van de applicatie op databaseniveau te implementeren, d.w.z. om deze te centraliseren en te vereenvoudigen, waardoor de ontwikkeling van databaseapplicaties eenvoudiger en betrouwbaarder wordt.
Beginnende ontwikkelaars verwaarlozen vaak het gebruik van databasebeperkingen, omdat ze denken dat deze het creatieve werk belemmeren. In werkelijkheid is een dergelijke mening echter gebaseerd op onvoldoende kennis van de theorie en praktijk van databaseontwerp.
Tegelijkertijd durven de meest ervaren ontwerpers het gebruik van bepaalde soorten beperkingen te weigeren, waardoor hun applicaties winnen aan snelheid. De ervaring van expertontwerpers stelt hen in staat om het werk van de server zeer goed te begrijpen en het gedrag ervan in complexe gevallen nauwkeurig te voorspellen. Daarom kunnen beginnende InterBase-programmeurs beter geen beroep doen op soortgelijke acties van ervaren collega’s.
In dit boek behandelen we geen databaseontwerp; voor meer informatie over dit onderwerp verwijzen we naar de literatuurlijst aan het einde van het boek. Hier bespreken we alleen alle soorten beperkingen in een InterBase-database en bekijken we voorbeelden van hun toepassing.
Soorten beperkingen in een database
Er zijn de volgende soorten beperkingen in een InterBase-database:
- PRIMARY KEY;
- UNIQUE KEY;
- FOREIGN KEY
- kan automatische triggers inschakelen - ON UPDATE en ON DELETE;
- CHECK
In de voorgaande hoofdstukken hebben we enkele van deze beperkingen genoemd, omdat dit noodzakelijk was voor een logische presentatie van de stof, maar nu zullen we hun syntaxis, toepassing en implementatie in meer detail bekijken. Databasebeperkingen zijn van twee soorten: gebaseerd op één veld en gebaseerd op meerdere velden van de tabel. De syntaxis van beide soorten beperkingen wordt hieronder gegeven.
= [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}]
}
De syntaxis van beperkingen op basis van meerdere velden is als volgt:
= [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 ( )}
Het verschil in syntaxis tussen beperkingen op basis van één veld en op basis van meerdere velden is duidelijk: in het laatste geval kunnen we meerdere velden specificeren die in de beperking zijn opgenomen. In het geval van een beperking op basis van één veld hebben alle beschreven opties alleen betrekking op het huidige veld. Deze twee soorten beperkingen hebben uiteraard een verschillende toepassingswijze: beperkingen op basis van één veld worden eenvoudig toegevoegd aan de definitie van het vereiste veld, en beperkingen op basis van meerdere velden worden na een komma in de algemene definitie van de tabel gespecificeerd. Gedetailleerde voorbeelden worden gegeven in de volgende delen van dit hoofdstuk.
Voorbeeld van een typische beperking
In feite zijn beperkingen op basis van één veld een speciaal geval van beperkingen op basis van meerdere velden.
Hieronder wordt een voorbeeld gegeven van het creëren van een primaire sleutelbeperking met behulp van deze twee verschillende benaderingen. Laten we een tabel maken die slechts één veld bevat en er een primaire sleutelbeperking aan toevoegen.
Hier is het voorbeeld van de primaire sleutel met behulp van de syntaxis van een beperking op basis van één veld:
CREATE TABLE test1( ID_PK INTEGER CONSTRAINT pktest NOT NULL PRIMARY KEY); In dit voorbeeld wordt een primaire sleutel met de naam pktest gemaakt voor het veld ID_PK. Als resultaat hebben we een vrij compacte beschrijving in één regel. We kunnen de syntaxis van beperkingen op basis van meerdere velden voor hetzelfde doel gebruiken: CREATE TABLE test2( ID_PK INTEGER NOT NULL, CONSTRAINT pktst PRIMARY KEY (ID_PK));
Beperkingen creëren
Laten we het creëren van beperkingen in meer detail bekijken. Het eerste in de beschrijving van de algemene syntaxis van beperkingen is de optie [CONSTRAINT constraint]. Zoals u kunt zien, staat deze optie tussen vierkante haken, d.w.z. deze is optioneel.
Met deze optie kunt u de naam van de gemaakte beperking instellen, zowel bij toepassing van de syntaxis van beperkingen op basis van één veld als bij beperkingen op basis van meerdere velden. Als u geen naam voor de beperking heeft opgegeven, genereert InterBase deze automatisch. Het is echter beter om de naam van de gemaakte beperking in te stellen om de leesbaarheid van het databaseschema te verbeteren en het beheer van beperkingen later te vereenvoudigen.
Nadat u de naam van de beperking heeft ingesteld, moet het type ervan worden gedefinieerd. Laten we de verschillende soorten beperkingen bekijken in de volgorde waarin ze worden aangegeven in de beschrijving van de algemene syntaxis van beperkingen.
Primaire en unieke sleutels
Primaire sleutels zijn een van de belangrijkste soorten databasebeperkingen. Ze worden toegepast voor eenduidige identificatie van records in de tabel. Laten we aannemen dat we een lijst van personen in een database opslaan. Het is heel goed mogelijk dat er twee (of meer) personen zijn met dezelfde achternaam, voornaam en patroniem. Hoe kunnen we de ene persoon van de andere onderscheiden (het gaat hier uiteraard om het onderscheiden van de ene persoon van de andere op basis van de informatie die in een database is opgeslagen)?
In dit geval wordt “persoon” vertegenwoordigd door één record in de tabel, dus kunnen we een algemenere vraag stellen: hoe kunnen we het ene record in (willekeurige) de tabel onderscheiden van een ander record in dezelfde tabel. Hiervoor worden beperkingen - primaire sleutels - gebruikt. De primaire sleutel vertegenwoordigt één of enkele velden in de tabel, waarvan de combinatie uniek is voor elk record. Er zijn geen herhalende waarden van een primaire sleutel voor één tabel.
Unieke sleutels vervullen dezelfde functie - ze dienen ook voor eenduidige identificatie van records in de tabel. Het verschil tussen primaire en unieke sleutels is dat er slechts één primaire sleutel in de tabel kan zijn, en wat betreft unieke sleutels - meerdere. Het wordt opgemerkt dat zowel een primaire als een unieke sleutel kan worden gebruikt als referentiebasis voor externe sleutels (zie verder).
De formele beschrijving van de begrippen primaire en unieke sleutels, evenals andere belangrijke definities, vindt u in de bijlage “Verklarende woordenlijst” aan het einde van het boek. De syntaxis van het creëren van een primaire en een unieke sleutel op basis van een uniek veld is als volgt:
< pkukconstraint > = [CONSTRAINT constraint] {PRIMARY KEY | UNIQUE}
Voorbeelden van primaire en unieke sleutels:
CREATE TABLE pkuk( pk NUMERIC(15,0) NOT NULL PRIMARY KEY, /*een primaire sleutel*/
uk1 VARCHAR(50) NOT NULL UNIQUE,/*een unieke sleutel */
uk2 INTEGER NOT NULL UNIQUE /\* nog een unieke sleutel */);
Syntaxis van het creëren van primaire en unieke sleutels op basis van meerdere velden:
= [CONSTRAINT constraint] {PRIMARY KEY | UNIQUE} ( col [, col …])
Deze syntaxis maakt het mogelijk om sleutels te creëren op basis van een combinatie van velden. Hier zijn de voorbeelden van het creëren van primaire en unieke sleutels uit meerdere velden:
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), /*primaire sleutel pkt op basis van twee velden*/ CONSTRAINT ukt1 UNIQUE (kol, Stoim)); /*unieke sleutel ukt1 op basis van twee velden*/
Let op dat alle velden die zijn opgenomen in primaire en unieke sleutels, moeten worden gedeclareerd als NOT NULL, omdat deze sleutels geen ongedefinieerde waarde kunnen hebben. Naast het creëren van de beperking van primaire en unieke sleutels bij het maken van de tabel, is er de mogelijkheid om beperkingen toe te voegen aan een tabel die al bestaat. In dit geval wordt de DDL-instructie ALTER TABLE gebruikt. De syntaxis van het toevoegen van beperkingen van primaire of unieke sleutel aan een bestaande tabel is vergelijkbaar met hierboven beschreven:
ALTER TABLE tablename ADD [CONSTRAINT constraint] {PRIMARY KEY | UNIQUE} ( col [, col …])
Laten we het voorbeeld bekijken van het creëren van een primaire en unieke sleutel met behulp van ALTER TABLE:
CREATE TABLE pkalter( ID1 INTEGER NOT NULL, ID2 INTEGER NOT NULL, UID VARCHAR(24));
Vervolgens voegen we sleutels toe. Eerst de primaire:
ALTER TABLE pkalter ADD CONSTRAINT pkal1 PRIMARY KEY (id1, id2);
Dan de unieke: ALTER TABLE pkalter ADD CONSTRAINT ukal UNIQUE (uid);
Het moet worden opgemerkt dat alleen de eigenaar van deze tabel of de systeembeheerder SYSDBA (voor meer details over de eigenaren en de SYSDBA-gebruiker, zie het hoofdstuk “Beveiliging in InterBase: gebruikers, hun functies en rechten” - deel 4) het toevoegen (evenals het verwijderen) van primaire en unieke sleutels aan de tabel kan uitvoeren.
Externe sleutels
De volgende beperking die vaak wordt gebruikt in InterBase-databases is een externe sleutelbeperking (foreign key). Dit is een zeer krachtig hulpmiddel voor het waarborgen van referentiële integriteit in een database, waarmee niet alleen de aanwezigheid van correcte referenties in een database kan worden gecontroleerd, maar deze referenties ook automatisch kunnen worden beheerd!
Het doel van het creëren van een externe sleutel is het volgende: als twee tabellen dienen voor het opslaan van onderling gerelateerde informatie, is het noodzakelijk om te garanderen dat deze relatie altijd correct zal zijn. Bijvoorbeeld, het document “vrachtbrief” met een algemene kop (datum, nummer van de vrachtbrief, enz.) en een set van gedetailleerde records (beschrijving van goederen, hoeveelheid, enz.).
Voor het opslaan van een dergelijk document worden twee tabellen in een database gemaakt - één voor het opslaan van de koppen van vrachtbrieven, en de tweede - voor het opslaan van de inhoud van de vrachtbrief - records over goederen en hun hoeveelheid. Dergelijke tabellen worden hoofd- en ondergeschikte tabellen of mastertabel en detailtabel genoemd.
Volgens het gezond verstand kan de inhoud van de vrachtbrief niet bestaan zonder de aanwezigheid van de kop ervan. Met andere woorden, we kunnen geen record over de goederen invoegen als we de kop van de vrachtbrief niet hebben aangemaakt, en we kunnen geen record van de kop verwijderen als er records over de goederen zijn. Voor de realisatie van dergelijk gedrag worden de tabel van de kop en de tabel van details verbonden met behulp van een externe sleutelbeperking.
Laten we de betekenis van het instellen van externe sleutelbeperkingen bekijken aan de hand van het voorbeeld van tabellen die informatie over vrachtbrieven bevatten. Hiervoor zullen we twee tabellen maken voor het opslaan van de vrachtbrief - de TITLE-tabel voor het opslaan van de kop en de INVENTORY-tabel voor het opslaan van de informatie over goederen die in de vrachtbrief zijn opgenomen.
CREATE TABLE TITLE( ID_TITLE INTEGER NOT NULL Primary Key, DateNakl DATE, NumNakl INTEGER, NoteNakl VARCHAR(255));
Let op dat we in de tabel van de kop direct een primaire sleutel hebben gedefinieerd op basis van het veld ID_TITLE. De overige velden van de TITLE-tabel bevatten triviale informatie over de kop van de vrachtbrief - datum, nummer, opmerking.
Nu definiëren we de tabel voor het opslaan van informatie over goederen die in de vrachtbrief zijn opgenomen:
CREATE TABLE INVENTORY( ID_INVENTORY INTEGER NOT NULL PRIMARY KEY, FK_TITLE INTEGER NOT NULL, ProductName VARCHAR (255), Kolvo DOUBLE PRECISION, Positio INTEGER);
Laten we kijken welke velden zijn opgenomen in de INVENTORY-tabel. Ten eerste is het ID_INVENTORY - een primaire sleutel van deze tabel. Dan volgt het integer veld FK_TITLE dat dient als de referentie naar de identifier van ID_TITLE in de tabel van vrachtbriefkoppen. Dan volgen de velden ProductName, Kolvo en Positio die de beschrijving van de goederen, de hoeveelheid en een positie in de vrachtbrief beschrijven. Het veld FK_TITLE is het belangrijkste voor ons voorbeeld. Als we de informatie over goederen van een bepaalde vrachtbrief willen uitvoeren, moeten we de volgende query gebruiken, waarin de parameter mas_ID_TITLE de kopidentifier definieert:
SELECT * FROM INVENTORY I1 WHERE I1.FK_TITLE=?mas_ID_TITLE
In feite, in de beschreven situatie, weerhoudt niets ervan om de INVENTORY-tabel te vullen met records die verwijzen naar niet-bestaande records in de TITLE-tabel. Bovendien weerhoudt niets ervan om de kop van een reeds bestaande vrachtbrief te verwijderen, waardoor records over de goederen “eigenloos” kunnen worden. De server zal niet verbieden om al deze invoegingen en verwijderingen uit te voeren. De controle over de gegevensintegriteit in een database wordt dus volledig bij de clientapplicatie gelegd. U weet echter dat meerdere applicaties, mogelijk ontwikkeld door verschillende programmeurs, met één database kunnen werken, wat kan leiden tot verschillende gegevensinterpretaties en fouten. Daarom is het essentieel om de expliciete beperking in te stellen dat alleen die records over de goederen die de correcte referentie naar de kop van de vrachtbrief hebben, in de INVENTORY-tabel kunnen worden geplaatst. Dit is in feite een externe sleutelbeperking die het mogelijk maakt om alleen die waarden in de velden die in de beperking zijn opgenomen, in te voegen die zich in de andere tabel bevinden.
Een dergelijke beperking kan worden gecreëerd met behulp van een foreign key. Voor het gegeven voorbeeld moeten we foreign key-beperkingen instellen voor het veld FK_TITLE en dit koppelen aan de primaire sleutel ID_TITLE in TITLE. We kunnen een foreign key toevoegen aan een bestaande tabel met de volgende opdracht:
ALTER TABLE INVENTORY ADD CONSTRAINT fktitle1 FOREIGN KEY(FK_TITLE) REFERENCES TITLE(ID_TITLE)
Vaak verschijnt bij het toevoegen van een foreign key de foutmelding - object is in use. Het probleem is dat we voor het creëren van een foreign key de database in een burst-modus moeten openen - zodat er op dat moment geen andere gebruikers zijn. Ook mogen we niet verwijzen naar de gewijzigde tabel - dit kan object is in use veroorzaken.
Hier is INVENTORY de naam van de tabel waarvoor de foreign key-beperking is ingesteld; fktitle1 is de naam van de foreign key; FK_TITLE - de velden die de foreign key vormen; TITLE is de naam van de tabel die de waarden levert (de referentiebasis) voor de foreign key; ID_TITLE - velden van de primaire of unieke sleutel in de TITLE-tabel, die dienen als referentiebasis voor de foreign key. Een volledige syntaxis van de foreign key-beperking (met de mogelijkheid om beperkingen op basis van meerdere velden te creëren) wordt hieronder gegeven:
= [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}]
Zoals u kunt zien, bevatten de definities een groot aantal opties. Laten we om te beginnen een basisdefinitie van een foreign key bekijken, die het meest wordt gebruikt in echte databases, en daarna analyseren we de mogelijke opties.
Een declaratieve vorm van een foreign key-beperking wordt meestal gebruikt wanneer een set velden (col [, col …]), die de beperking zal vormen, wordt gespecificeerd; evenals de other_table die een lijst met mogelijke waarden voor de foreign key bevat in velden [(other_col [, other_col …]).
Hier is het voorbeeld van zo’n definitie bij het creëren van de tabel:
CREATE TABLE Inventory2( … FK_TABLE INTEGER NOT NULL CONSTRAINT fkinv REFERENCES TITLE(ID_TITLE) …);
Let op dat in deze definitie de trefwoorden FOREIGN KEY worden weggelaten, en dat het enige veld FK_TITLE impliciet wordt gebruikt als foreign key. Een meer volledige vorm van het creëren van de foreign key gelijktijdig met de tabel wordt gegeven in het volgende voorbeeld:
CREATE TABLE Inventory2( … FK_TABLE INTEGER NOT NULL, CONSTRAINT fkinv FOREIGN KEY (FK_TABLE) REFERENCES TITLE(ID_TITLE) …);
NULL gebruiken in velden van een foreign key
In velden op basis waarvan een foreign key wordt gecreëerd, is het toegestaan NULL-velden toe te passen. Deze mogelijkheid is toegevoegd om wederzijdse verwijzingen mogelijk te maken. Bijvoorbeeld, als er twee tabellen zijn die naar elkaar verwijzen met foreign keys. Als we de lege verwijzing (d.w.z. voor NULL) in deze foreign keys niet toestaan, is het onmogelijk om een record toe te voegen aan gekoppelde tabellen: om een record aan de eerste tabel toe te voegen, is een record in de tweede tabel vereist, en vice versa.
Het gebruik van NULL als lege verwijzing maakt het mogelijk om wederzijdse verwijzingen van twee kruisverwijzende tabellen te creëren, en ook om hiërarchische structuren op te slaan in relationele tabellen - waarbij root-knooppunten verwijzen naar “lege” records (d.w.z. gewoon NULL bevatten).
Uitgebreide mogelijkheden van referentiële integriteitsondersteuning met behulp van foreign key
Meestal is de declaratieve variant van een foreign key-beperking voldoende; de server zorgt er alleen voor dat het onmogelijk is om onjuiste waarden in de tabel met de foreign key in te voegen, of - bij een poging daartoe - verschijnt er een foutmelding. Maar InterBase staat toe om een reeks automatische bewerkingen uit te voeren bij het wijzigen / verwijderen van een foreign key. Hiervoor wordt de volgende set foreign key-opties gebruikt:
[ON DELETE {NO ACTION|CASCADE|SET DEFAULT|SET NULL}] [ON UPDATE {NO ACTION|CASCADE|SET DEFAULT|SET NULL}]
Deze opties maken het mogelijk om verschillende bewerkingen te definiëren bij het bijwerken of verwijderen van foreign key-waarden.
We kunnen bijvoorbeeld instellen dat bij het verwijderen van een primaire sleutel in de master-tabel, alle records met dezelfde foreign key in de ondergeschikte tabel moeten worden verwijderd. In dit geval moeten we een foreign key op de volgende manier definiëren:
ALTER TABLE INVENTORY ADD CONSTRAINT fkautodel FOREIGN KEY (FK_TITLE) REFERENCES TITLE(ID_TITLE) ON DELETE CASCADE
Voor de implementatie van deze bewerkingen is er eigenlijk een systeemtrigger die bepaalde bewerkingen uitvoert. In tabel 1.2 staat een beschrijving van de bewerkingen van verschillende opties (let op dat de opties NO ACTION|CASCADE|SET DEFAULT|SET NULL niet in één zin ON XXX kunnen worden gebruikt).
Tabel 1.2
| Gebeurtenis | Bewerking | |||
| NO ACTION | CASCADE | SET DEFAULT | SET NULL | |
| ON DELETE | Bij het verwijderen van een foreign key niets doen - wordt standaard gebruikt | Bij het verwijderen alle gerelateerde records uit de ondergeschikte tabel verwijderen | Bij het wijzigen een foreign key-veld instellen op een standaardwaarde |
Bij het wijzigen een foreign key-veld instellen op NULL |
| ON UPDATE | Bij het wijzigen niets doen - wordt standaard gebruikt | Bij het wijzigen van een record alle gerelateerde records in de ondergeschikte tabel wijzigen | Bij het verwijderen een foreign key-veld instellen op een standaardwaarde |
Bij het verwijderen een foreign key-veld instellen op NULL |
Als we niets specificeren of NO ACTION specificeren, moeten we zelf zorg dragen voor het wijzigen van een foreign key (in geval van het wijzigen van een primaire sleutel), en bij het verwijderen van de primaire sleutel moeten we vooraf de records uit de ondergeschikte tabel verwijderen. Wees zeer voorzichtig bij het gebruik van de CASCADE-optie: onzorgvuldig gebruik kan leiden tot het verwijderen van een groot aantal gerelateerde records.
CHECK-beperking
Een van de meest nuttige beperkingen in een database is de check-beperking. De functie ervan is heel eenvoudig - de waarde die in de tabel wordt ingevoegd controleren op een bepaalde voorwaarde en, afhankelijk van de uitvoering van deze voorwaarde, de gegevens invoegen of niet. De syntaxis is vrij eenvoudig:
= [CONSTRAINT constraint] CHECK ( )}
Hier is constraint de naam van de beperking; is een zoekvoorwaarde, waarin de ingevoegde / bijgewerkte waarde als parameter kan worden gebruikt. Als aan de zoekvoorwaarde wordt voldaan, is het toegestaan om deze waarde in te voegen / bij te werken; als dat niet het geval is - verschijnt er een foutmelding. Het eenvoudigste voorbeeld van een check:
create table checktst( ID integer CHECK(ID>0));
Deze check bepaalt of de ingevoegde / bijgewerkte waarde van het ID-veld groter is dan nul, en afhankelijk van het resultaat wordt een nieuwe waarde toegestaan of wordt er een foutmelding gegeven (zie het hoofdstuk “Uitgebreide mogelijkheden van de taal van InterBase opgeslagen procedures” (deel 1)).
Er zijn ook meer gecompliceerde varianten van checks. Een volledige syntaxis van de zoekvoorwaarde is de volgende:
= {
{ | ()}
| [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 }
Dus CHECK biedt een grote set opties voor het controleren van ingevoegde / bijgewerkte waarden. U moet rekening houden met de volgende beperkingen bij het gebruik van CHECK:
- De gegevens voor CHECK worden alleen uit een huidig record gehaald. U mag de gegevens voor de expressie in CHECK niet uit andere records van dezelfde tabel halen - deze kunnen door andere gebruikers worden gewijzigd
- Een veld mag slechts één CHECK-beperking hebben
- Als voor velddefinitie een domein met een CHECK-domeinbeperking wordt gebruikt, kan dit niet op het niveau van een concreet veld in de tabel worden hergedefinieerd. Er moet worden opgemerkt dat CHECK wordt geïmplementeerd door systeemtriggers, daarom moeten we voorzichtig zijn bij het gebruik van zeer lange voorwaarden, die de processen van het invoegen en bijwerken van records sterk kunnen vertragen.
Beperkingen verwijderen
Heel vaak verwijderen we verschillende beperkingen om de meest uiteenlopende redenen. Om een beperking te verwijderen, moeten we de ALTER TABLE-instructie van de volgende vorm gebruiken: ALTER TABLE tablename DROP CONSTRAINT constraintname
constraintname is de naam van de beperking die moet worden verwijderd. Als bij het creëren van de beperking een bepaalde naam is opgegeven, moeten we die gebruiken, maar zo niet, dan moeten we een InterBase-beheertool openen, alle beperkingen zoeken die ermee verband houden en uitzoeken welke systeemnaam InterBase voor de vereiste beperking heeft gegenereerd.
Er moet worden opgemerkt dat alleen de eigenaar van de tabel of de SYSDBA-systeembeheerder de beperkingen kan verwijderen.