Дизайн базы данных, таблица пользователей для оборудования и служащих

Question

Хорошо, этот вопрос настолько специфичен, что я даже не знаю, как искать, если ранее был дан ответ. У меня есть база данных с несколькими таблицами и отношениями, но последние пару дней у меня возникла проблема с дизайном. Я работаю с Microsoft Access, но идея состоит в том, чтобы перейти на наш Linux-сервер с использованием MySQL, так или иначе, вопрос не связан с СУБД, а является проблемой дизайна.

У меня есть таблица для оборудования (или любое устройство с IP-адресом, скажем, ноутбук, сервер, коммутаторы и т. Д.) И другая таблица для сотрудников (мой дизайн немного сложнее, но я упрощен проблема для объяснения целей). У меня есть другая таблица для хранения имен пользователей, паролей, ролей и областей имени пользователя (локальная, доменная, Wordpress, электронная почта и т. Д.).

Итак, позвольте мне показать упрощенную версию моей проблемы в SQL (нерелевантные поля были намеренно опущены):

CREATE TABLE employees (
    IdEmployee INT NOT NULL, 
    EmployeeName VARCHAR(50), 
    EmployeeDepartment INT, 
    PRIMARY KEY (IdEmployee) 
); 

CREATE TABLE devices (
    IdDevice INT NOT NULL, 
    DeviceType INT, 
    Brand INT, 
    Model VARCHAR(30), 
    PRIMARY KEY (IdDevice) 
) 

CREATE TABLE usernames (
    IdUsername INT NOT NULL, 
    Username VARCHAR(20), 
    Password VARCHAR(20), 
    UserRole INT, 
    UserScope INT, 
    PRIMARY KEY (IdUsername) 
) 

Username и Password полей являются для хранения учетных данных для всех наших маршрутизаторов, коммутаторов и несколько пользователей root для наших серверов и баз данных. Моя проблема с дизайном: у сотрудников есть учетные данные для входа в домен нашей компании, также у устройств есть учетные данные. Но у устройств и сотрудников нет общих полей, поэтому они должны быть в отдельных таблицах. Как связать usernames таблицу employees и devices, учитывая, что:

• Один сотрудник может иметь более одного пользователя (с различными ролями и областей).
• Некоторые сотрудники имеют одинаковое имя пользователя для разных областей (сервер, Wordpress и т. Д.).
• Одно устройство может иметь или не иметь более одного имени пользователя (с разными ролями).
• Учетные данные как для сотрудников, так и для устройств имеют одинаковые характеристики (поля), поэтому мне бы не хотелось иметь две разные таблицы для одной и той же вещи. Но если я не смогу найти решение, я думаю, я пойду с этим.

Это не домашнее задание в школе, это мой третий день, пытаясь понять, как реализовать решение для базы данных. Если мне придется изменить почти весь дизайн в базе данных, я это сделаю. Сама база данных более сложна, и она охватывает полный инвентарь активов и список всех пользователей и статических IP-адресов в наших сетях, поэтому это является частью приведения порядка во все беспорядки.

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

Заранее спасибо.

Answer 1

Вариант 1:

Создание двух аналогичных таблиц, EmployeeUsernames и DeviceUsernames:

CREATE TABLE EmployeeUsernames (
    IdUsername INT NOT NULL, 
    IdEmployee INT, 
    PRIMARY KEY (IdUsername), 
    FOREIGN KEY (IdEmployee) REFERENCES employees (IdEmployee), 
    FOREIGN KEY (IdUsername) REFERENCES usernames (IdUsername) 
); 

CREATE TABLE DeviceUsernames (
    IdUsername INT NOT NULL, 
    IdDevice INT, 
    PRIMARY KEY (IdUsername), 
    FOREIGN KEY (IdDevice) REFERENCES devices (IdDevice), 
    FOREIGN KEY (IdUsername) REFERENCES usernames (IdUsername) 
); 

Это позволяет в тех случаях, где нет имени пользователя и для случаев, когда у вас есть несколько имен пользователей. Если вы захотите, вы можете добавить контрольное ограничение или триггер для принудительного применения каких-либо определенных правил вокруг количества имен пользователей в разных ситуациях.

Вариант 2:

Вы можете поместить два столбца в имена пользователей - IdEmployee и IdDevice. Разрешить им быть нулевыми, а затем использовать контрольное ограничение или триггер, чтобы убедиться, что один столбец или другой заполняется, когда данные вставлены, и что вставленное значение является допустимым (т.е. убедитесь, что сотрудник или устройство существует).

Вариант 3:

Добавьте две колонки в имена пользователей - UsernameOwner и UsernameOwnerType. Поместите значение IdEmployee или IdUsername в первый столбец и используйте второе, чтобы указать, к какой таблице привязана определенная строка. Как указано выше, используйте контрольное ограничение или триггер, чтобы обеспечить сохранение данных.

---

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