zwei Fremdschlüssel auf den gleichen numerischen Datentyp und verweisen auf zwei Tabellen

Ihr Datenmodell scheint nicht sehr sinnvoll zu sein. Sie haben drei verschiedene Entitäten admin , user , und login . Alle drei scheinen die gleichen Informationen zu speichern – eine E-Mail-Adresse, einen Benutzernamen und ein Passwort (von dem ich hoffe, dass es für die grundlegende Sicherheit wirklich ein Passwort-Hash ist). Wenn Beziehungen zwischen den Tabellen bestehen, verstößt dies gegen die grundlegende Normalisierung, da Sie dieselben Informationen an mehreren Stellen speichern würden.

Wenn Sie die Geschäftsanforderungen für die Entitäten, die Sie tatsächlich zu modellieren versuchen, nicht kennen, ist es schwierig, genau zu wissen, was Sie wollen.

Meine erste Vermutung ist, dass Sie zwei Arten von Benutzern haben, Administratoren und normale Benutzer, die sich jeweils bei Ihrer Anwendung anmelden können. Unter der Annahme, dass die Attribute von Benutzern unabhängig von ihrer Rolle ziemlich konsistent sind (sowohl Administratoren als auch normale Benutzer haben E-Mail-Adressen, Passwörter usw.), wäre die einfachste Art, dies zu modellieren, mit einer einzigen login Tabelle mit einem login_type die Ihnen sagt, ob ein bestimmter Benutzer ein Administrator oder ein normaler Benutzer ist

create table login (
  login_id      integer primary key,
  email         varchar2(255),
  password_hash raw(32),
  login_type    varchar2(1) check( login_type IN ('A', 'U') )
);

Sie können dies etwas flexibler gestalten, indem Sie eine Nachschlagetabelle für die Login-Typen erstellen, die Ihr login enthält Tabellenreferenzen

create table login_type_lkup (
  login_type_code varchar2(1) primary key,
  login_type_desc varchar2(255)
);

create table login (
  login_id        integer primary key,
  email           varchar2(255),
  password_hash   raw(32),
  login_type_code varchar2(1) references login_type_lkup( login_type_code )
);

Wenn Sie mehr Flexibilität wünschen, wäre der nächste Schritt zu sagen, dass Logins nicht wirklich einen Typ haben. Stattdessen haben sie eine oder mehrere Rollen mit bestimmten Berechtigungen. Möglicherweise haben Sie einen admin Rolle und ein regular user zunächst eine Rolle, möchten aber später einen read only user hinzufügen Rolle, ein superuser Rolle usw. In diesem Fall hätten Sie so etwas wie

create table login (
  login_id        integer primary key,
  email           varchar2(255),
  password_hash   raw(32)
);

create table role (
  role_id integer primary key,
  role_desc varchar2(255)
);

create table permission (
  permission_id integer primary key,
  permission_desc varchar2(255)
);

create table login_role (
  login_id integer references login(login_id), 
  role_id  integer references role(role_id),
  primary key pk_login_role( login_id, role_id )
);

create table role_permission (
  role_id       integer references role(role_id),
  permission_id integer references permission(permission_id),
  primary key pk_role_permission( role_id, permission_id )
);