два внешних ключа к одному и тому же числовому типу данных и ссылаются на две таблицы

Question

Возможно создание двух внешних ключей для одного и того же типа числовых данных в таблице и ссылки на две таблицы, и у меня есть эти примеры вниз

создать таблицу администратор и ключ

/* table admin*/ 
create table admin (id_admin number(10) not null, 
        email_admin varchar(30) not null, 
        password_admin varchar(10) not null); 
/* primary key */ 
alter table admin add constraint admin_pk primary key (id_admin); 

создать пользователь основной таблицы и первичного ключ

/* table user*/ 
create table user (id_user number(10) not null, 
        email_user varchar(30) not null, 
        password_user varchar(10) not null); 
/* primary key */ 
alter table user add constraint user_pk primary key (id_user); 

создать таблицу логин и первичный ключ и внешний ключ

/* table login*/ 
create table login(id_login number(10) not null, 
        id_admin_user_login number(10) not null, 
        email_login varchar(20) not null, 
        password_login varchar(10) not null); 
/* primary key */ 
alter table login add constraint login_pk primary key (id_login); 

/* foreign key reference to admin*/ 
alter table login add constraint login_fk_admin foreign key (id_admin_user_login) 
reference admin(id_admin); 

/* foreign key reference to user*/ 
alter table login add constraint login_fk_user foreign key (id_admin_user_login) 
reference user(id_user); 

возможно?

Answer 1

Ваша модель данных Безразлично» похоже, имеет большой смысл. У вас есть три разных объекта: admin, user и login. Все три из них, похоже, хранят одну и ту же информацию - адрес электронной почты, имя пользователя и пароль (который, я надеюсь, для базовой безопасности - это хеш-пароль). Если между таблицами существуют какие-либо отношения, это нарушает базовую нормализацию, потому что вы будете хранить одну и ту же информацию в нескольких местах.

Не зная требований бизнеса для сущностей, которые вы на самом деле пытаетесь моделировать, трудно точно знать, что вы хотите.

Мое первое предположение состоит в том, что у вас есть два типа пользователей, администраторов и постоянных пользователей, каждый из которых может войти в ваше приложение. Предполагая, что атрибуты пользователей довольно согласованы независимо от их роли (как администраторы, так и обычные пользователи имеют адреса электронной почты, пароли и т. Д.), Самый простой способ моделирования, который будет с одной таблицей 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) 
); 

Если вы хотите больше гибкости, следующим шагом было бы сказать, что логины не действительно есть тип. Вместо этого у них есть одна или несколько роли, которая имеет некоторый набор разрешений. Вы могли бы иметь 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) 
); 

Answer 2

Имея FK до 2 таблиц в этом случае побеждает цель - человек должен быть пользователем и администратором одновременно. Администратор или пользователь фактически являются роли, так что вы можете иметь, например, (упрощенно, например, только для иллюстрации подхода. Вы можете найти более путем поиска модели партийно-ролевые отношения),

PARTY (party_id (PK), name, ... .); 
PARTY_LOGIN(party_login_id(PK), party_id (FK to PARTY), ...); 
PARTY_ROLE(party_id (PK,FK), role_id(PK,FK)) ;