Проектирование базы данных: несколько категорий пользователей входят в одну систему - PullRequest
Новая
       38

Проектирование базы данных: несколько категорий пользователей входят в одну систему

1 голос
/ 04 января 2012

В нашей новой системе у нас есть три типа людей

  1. Владелец бизнеса
  2. Помощник владельца бизнеса
  3. Персонал (квалифицированный работник)

У меня есть следующая сущность

  1. [ Бизнес ] - включить сведения о владельце бизнеса
  2. [ Помощник ] - подробности о помощнике
  3. [ Персонал ] - подробности о персонале

Бизнес-правила

  1. Для данного бизнеса будет только один владелец бизнеса, это означает, что для владельца бизнеса может быть только один логин. Он как супер пользователь для своего бизнеса.
  2. Владелец бизнеса также может быть сотрудником.
  3. Один бизнес может содержать более одного сотрудника, и каждый сотрудник имеет различные виды прав / разрешений, которые могут настраиваться владельцем бизнеса.
  4. Владелец бизнеса может настроить только одного помощника для каждой компании, а права / разрешения могут быть настроены.

Каким будет правильный путь для проектирования классов, а также проектирования баз данных?

Любая помощь / предложение приветствуется !!!

Обновление 1 : Основываясь на обратной связи, я пришел к следующей модели данных. Я использую EF 4.1 с первым подходом кода, и каждый объект данных будет отображаться непосредственно с одним классом. Data model

Пожалуйста, предложите свой отзыв!

Ответы [ 3 ]

1 голос
/ 04 января 2012

Если я правильно понимаю, у вас есть какой-то интерфейс, верно?эти 3 типа людей не имеют прямого доступа к базе данных (вход на сервер базы данных).Я думаю, что вам нужно, чтобы пользователи и связанные с ними роли хранились в вашей таблице пользователей и основывались на зарегистрированной роли пользователя, которой ваше веб-приложение / настольное приложение должно ограничивать операции.Когда владелец бизнеса должен назначить роль, он собирается выбрать сотрудников и роли из таблицы ролей и сопоставить их.

Вот как я представляю, UserTable с идентификатором, пропуском, адресом и т. Д., RolesTable с RoleID, RoleDescription, RoleName и т. Д., UserTable - таблица сопоставления RoleTable

При входе в систему ваш внешний интерфейснеобходимо проверить данные для входа и получить связанные роли из таблицы сопоставления userTable - RoleTable.

1 голос
/ 04 января 2012

Я обнаружил некоторые проблемы с дизайном вашего класса.Неправильно хранить информацию о BusinessOwner в бизнес-классе.Я предлагаю следующий дизайн вашей системы - 

Abstract Class BusinessPeople

Class BusinessOwner extends BusinessPeople

Class Assistant extends BusinessPeople

Class Staff extends BusinessPeople

И в вашем бизнес-классе вы можете хранить детали вашего бизнеса.Вы можете создать свою базу данных, используя вышеуказанный дизайн класса.Создайте имя таблицы Staff, в которой первичным ключом должен быть staff_id.Затем создайте таблицы для BusinessOwner, Assistant ... других заинтересованных сторон, каждая из которых имеет атрибут staff_id, который является первичным ключом таблицы Staff, и работает как внешний ключ в этих таблицах (BusinessOwner, Assistant и т. Д.).

1 голос
/ 04 января 2012

Ваш вопрос довольно расплывчатый, но для сценария с несколькими пользователями, я думаю, что здесь был дан превосходный ответ: Преимущества и недостатки минуса для единой таблицы (варианты дизайна базы данных) и в каком случае она использовалась?

Я бы также порекомендовал вам взглянуть на нормализацию базы данных, см .: http://en.wikipedia.org/wiki/Database_normalization

К сожалению, я не могу рекомендовать гораздо больше без дополнительной информации.

...