Kann man Tabellen mit referentieller Integrität erstellen?

Keine wirklich brauchbare.

In der SM30-Pflege könnte man im Exit-Zeitpunkt, der beim Löschen prozessiert wird, eine entsprechende Prüfung einbauen.
Hilft aber allenfalls, wenn auch beim Pflegen einer Tabelle immer beide gesperrt werden.
Ansonsten Pflegt User1 einen neuen Eintrag in Tabelle2, bevor er sichert, löscht User2 den passenden Eintrag aus Tabelle1, ...

Und dann muss man noch den EXIT-Zeitpunkt zur Aufnahme eines Tabelleneintrags in einen Transport anpassen, damit im Zielsystem keine Inkonsistenzen entstehen können, ...
(Hindert aber trotzdem niemanden, Einträge R3TR TABU ... manuell in einen Auftrag aufzunehmen.)

Wenn gar keine (per SM30 pflegbaren) Customizing-Tabellen gemeint sind, müsste man die Prüfung in dem Programm vornehmen, das die Einträge löschen will.
Wenn es aber mehrere Große Tabellen mit entsprechenden Fremdschlüssel-Beziehungen gibt, müsste man jede Menge zusätzlicher Sekundär-Indizes anlegen.
Und da wieder eine zeitliche Differenz zwischen "User löscht Eintrag oder User erzeugt neuen Eintrag" und "Änderungen werden verbucht" gegeben ist, müsste man wieder mehrere Objekte sperren, obwohl man nur eins bearbeiten will.
Da kann es dann auch schnell zu Deadlock-Situationen kommen.

Jede Menge Aufwand für ein unsicheres Ergebnis.

Und damit die Prüfung in allen ABAPs zieht, auch wenn in den ABAPs keine entsprechenden Prüfungen vorkommen, müsste man Trigger auf DB-Ebene definieren.
Überhaupt nicht zu empfehlen. (Muss ich das wirklich begründen?)

Deswegen gibt es im SAP-Standard an etlichen Stellen "Löschkennzeichen"-Felder, d.h., ein Eintrag wird als nicht mehr für zukünftige Referenzen verwendbar markiert, bleibt aber erst mal im System.

Der Begriff Referentielle Integrität beschreibt nicht zwangsläufig ein Datenbank Feature.

Das ganze ist ja nur ein Konzept zur Wahrung der Aussagekraft und Logik eines Datenbestandes.

Auf Datenbankebene wurde dieses bei SAP aus einem einfachen grund nicht implementiert:
- Bei der Fülle von Datenbanktabellen, Customizingobjekten etc. wäre die Datenbank viel zu langsam, wenn sie permanent die Integrität ihrer Daten über alle Objekte/Tabellen sicherstelen müsste.
- Das Datenmodell von SAP ist an vielen Stellen nicht auf eine solche feste DB-Logik ausgerichtet (vgl. Objektschlüssel in COEP etc.)

Aus diesem Grund wird die referentielle Integrität bei SAP in der Anwendungslogik selbst sichergestellt und zwar nur in den Komponenten, die zum Zeitpunkt der Transaktion auch wirklich (aufgrund vom Funktionsumfang der Transaktion) betroffen sind.

Aussagen wie: "SAP kennt keine Fremdschlüssel" sind unangebrachte, vorschnelle und unkorrekte Aussagen.
Sap verwendet lediglich nicht die Integritätslogik der darunter liegenden Datenbank, sondern hat diese selbst implementiert.

Und dieses ist eben auch vom Anwendungsentwickler durch zuführen.

Und das Löschkennzeichen dient vielmehr dazu, das OLTP-System nachvollziehbar zu gestalten und zwar zu allen Zeitpunkten. Dieses sind Grundsätze ordnungsgemäßer Datenhaltung bei SAP. Die "Lösung" eines Integritätsproblems stand dabei nicht im Vordergrund.