同じ数値データ型への2つの外部キーと、それを2つのテーブルへの参照

あなたのデータモデルはあまり意味がないようです。 3つの異なるエンティティadminがあります 、user 、およびlogin 。 3つすべてが同じ情報（電子メールアドレス、ユーザー名、パスワード）を格納しているように見えます（基本的なセキュリティが実際にはパスワードハッシュであることを願っています）。テーブル間に関係がある場合、同じ情報を複数の場所に保存するため、基本的な正規化に違反します。

実際にモデル化しようとしているエンティティのビジネス要件がわからないため、必要なものを正確に知ることは困難です。

私の最初の推測では、管理者と通常のユーザーの2種類のユーザーがいて、それぞれがアプリケーションにログインできます。ユーザーの属性が役割に関係なくかなり一貫していると仮定すると（管理者と通常のユーザーの両方が電子メールアドレス、パスワードなどを持っています）、単一のloginでモデル化する最も簡単な方法です。 login_typeのテーブル 特定のユーザーが管理者であるか通常のユーザーであるかを示します

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') )
);

loginのログインタイプのルックアップテーブルを作成することで、これをもう少し柔軟にすることができます。 テーブル参照

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 )
);

より柔軟性が必要な場合、次のステップは、ログインには実際にはタイプがないことを言うことです。代わりに、いくつかの権限のセットを持つ1つ以上の役割があります。あなたはadminを持っているかもしれません 役割とregular user 最初は役割ですが、後でread only userを追加したい 役割、superuser 役割など。その場合、あなたは次のようなものを持っているでしょう

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 )
);