ConceptBase besitzt zur Überprüfung interner und benutzerdefinierter Konsistenzbedingungen einen Integritätstester. Während wir uns mit den Problemen, die die Konsistenzbedingungen zusätzlich zu den unter ``Regeln`` im letzten Kapitel erwähnten verursacht, erst in Kapitel 4.3.1 beschäftigen wollen, bleibt hier zu bemerken, daß dies ein Transaktionskonzept auf zwei Arten beeinflußt.
Erstens reicht es zur Aufrechterhaltung der Konsistenz nicht mehr, wie bei konventionellen Systemen, einfach für eine serialisierbare Ausführung korrekter Transaktionen zu sorgen: Bei jeder Änderung oder beim Commit einer Transaktion muß geprüft werden, ob die Konsistenzbedingungen verletzt sind.
Tests bei jeder Änderung wären sehr zeitaufwendig, verletzten die Idee, daß ein konsistenter Zustand erst zum Ende einer Transaktion hergestellt werden muß, ließen aber eine gezielte Verweigerung inkonsistenter Änderungen zu und realisierten damit eine pessimistische Einstellung.
Wird die Konsistenz erst zum Commit--Zeitpunkt sichergestellt, so dürfen Änderungen natürlich auch erst nach dem Commit global sichtbar werden. Außerdem kann nur noch der Abschluß der ganzen Transaktion verweigert werden (optimistisch): Entweder durch einen Abort oder mit einer Bitte nach Abhilfe an den Benutzer. Aborts kommen, wie im letzten Unterabschnitt gezeigt, nicht in Frage.
Zweitens enthalten die Integritätsbedingungen semantische Informationen, die sich ein Transaktionskonzept zunutze machen kann. Dies kann soweit gehen, daß auf Serialisierbarkeit als Garant der Konsistenz verzichtet wird und diese nur noch durch umfangreiche Konsistenzbedingungen und den Integritätstester sichergestellt wird.