Здравствуйте!
проектирую складскую БД. В базе есть таблицы Empl, Users, Groups, Users_Groups с полями:

Empl - сотрудники
ID_Empl
ID_Contrag- связь с таблицей контрагенты
ID_Depart- связь с таблицей департаменты
ID_Posts- Должности
ID_Contract
FirstName
LastName
Phones
Resident
Salary
IncomeTax- Ндс
HomeAddr
PostStart

Users - пользователи БД
ID_User
ID_Group
name
Login
Passw
Comment

Groups - группы пользователей БД
ID_Group
Name

Users_Groups - для связи многие-ко-многим
ID
ID_User
ID_Group

Думаю перенести поля таблицы Empl(сотрудники) в Users.
Есть по какими-нибудь причинами необходимость в отдельных таблицах для сотрудников и пользователей БД?

покритикуйте, посоветуйте, плз

SERG1257А в словаре БД разве нет инфы про пользователей, ролей, групп и т.д.
Зачем изобретать велосипед?
Вы говорите о security2.fdb?

или о системных таблицах самой БД?

SERG1257Delphi159 или о системных таблицах самой БД? Да. Кроме русского наименования (фио у пользователя) не вижу ничего нового. Зачем?
Не понял о чём вы говорите! Чтобы использовать системные таблицы?
Delphi159 Думаю перенести поля таблицы Empl(сотрудники) в Users.
Есть по какими-нибудь причинами необходимость в отдельных таблицах для сотрудников и пользователей БД?
Я говорю о том, чтобы убрать таблицу empl и её поля перенести в Users. Зачем в БД таблица сотрудников, если там заходят только сотрудники, которые можно найти в Users? Залогиняются сотрудники, которые для БД являются пользователями.

mad_nazgul
Плохое решение.
Т.к. могут быть пользователи не сотрудники, например, "гость".

А так обычно решается добавлением новой абстракции.
Приблизительно так
1) Person - конкретный человек, все его данные (ФИО, пол, год рождения, паспорт)
2) Employee - Сотрудник, имеет ссылку на Person и должность (свзяь Employee_Должность, т.к. сотрудник может совмещать должности)
3) User - пользователь, может имеет ссылку на Person (связь ч/з User_Person) и роли (связт ч/з User_Groups)

Опять же объединять Person и Employee так же плохо, т.к. могут быть конкретные лица которые не являются сотрудниками, но могут иметь доступ к данным.

Где-то так.
Мне понравился это решение, но хочу уточнить 2 момента:
1) Как я вас понял, в таблице Person включаем только тех людей, кто не сотрудник ?
например,
1."гость"-осматривает мою программу,собирается купить
2. "будущий оператор программы"-пока не принимали на работу и изучает программу
3. Аудит?

Тогда в таблице Person зачем для них сделать запись(ФИО, пол, год рождения, паспорт)- это же будет бесполезная, никому ненужная информация? Или ничего не добавить в Person и для их всех в Users создать один запись- guest(гость) и давать им доступ к БД по роли guest?

2) Если я правильно рассуждаю в первом вопросе, тогда таблица Person теряет значение- не так ли?

dma_caviar Users - сотрудники/пользователи
Отдельные таблицы persons и users или признаки "Пользователь", "Сотрудник" как LSV предлагает?

dma_caviarDelphi159,

Таблица одна. Если у сотрудника есть ссылка на логин, значит это сотрудник-пользователь, если нет значит просто сотрудник.
А вам зачем кстати отличать сотрудников от пользователей?
Не зачем. Сейчас у меня отдельные таблицы для сотрудников и для пользователей БД и просто думаю на счет их объединения в одну. Но таблицы users, usergroups, roles- это одна группа таблиц, ответственные за безопасность БД и права доступа, а в этой цепи запихнуть persons вместо таблицы Users, пока не могу решать, взвешиваю всё за и против.

Кот МатроскинDelphi159Не зачем. Сейчас у меня отдельные таблицы для сотрудников и для пользователей БД и просто думаю на счет их объединения в одну. Но таблицы users, usergroups, roles- это одна группа таблиц, ответственные за безопасность БД и права доступа, а в этой цепи запихнуть persons вместо таблицы Users, пока не могу решать, взвешиваю всё за и против.

А где Вы видите хоть одно "за" объединения?
LSV 17292394 17291265 .
Хотя я тоже уже больше сомневаюсь. Ищу оптимальное решение и не хочу быть белой вороной среды черных.

dma_caviarDelphi159,

Если у сотрудника есть ссылка на логин, значит это сотрудник-пользователь, если нет значит просто сотрудник.

если нет ссылки на логин- это не значит что просто сотрудник, это значит что или просто сотрудник или "гость"(аудит, пока не назначен на должность и т.д.). По этому признаку нельзя их различать. А как вы их различаете? Как узнать что гость а не "просто сотрудник"?

dma_caviarА что означает Гость, какие-то особенности в доступе? Не роль ли это?)
Конечно роль, я не об этом. Сначала как их дифференцируйте? По той причине что не нашли в memberships логина мы не можем говорит что он "просто сотрудник",а не гость. Как узнать что он гость?

Я так представляю:
1.подсоединяюсь к БД,
2.запросом в DBLookupCombobox выбираю сотрудника и в таблице memberships ищу его роли
3.если у него роли несколько выбираю нужный роль
4. отсоединяюсь от бд и подсоединяюсь с этой ролью

А если гость, тогда включить на форме checkbox и прямо с ролью guest подключиться к бд, минуя вышесказанные этапы 1-4?
Вы как поступаете в случае guest?

dma_caviarЕсли чел гость, то назначаю ему роль Гость.
Или Вы имеете ввиду если он сам себя регистрирует? Можно тогда по умолчанию эту роль назначать. Или если вообще без ролей значит не будет иметь доступ туда куда не надо - т.е. это и есть "гость".

говорите "Если чел гость, то назначаю ему роль Гость." - Кааааааааааак узнаете что он гость по вашей схеме, который предложили? Вы сами как делаете?

dma_caviarDelphi159в таблице memberships ищу его роли
Если вы про ту схему которую я предложил, то memberships это не роли юзера. Это доступ (ID, логин, пароль, соль, всякие флаги, типа неудачные попытки и т.п.). А роли юзера и всякие заморочки доступа связаны именно с этим ID.
Неправильно высказался, в memberships- login и пароль найду, а роли- в таблице roles или в системной таблице(пока не решил создать или нет таблицу roles).

ViPRosАнатоЛой,

прально
"сотрудника" воще может не быть как такового
Что значит не быть? Допустим некий сотрудник имеет логин "asdr14" или "User147". Они кому-нибудь говорят кто выписал накладной? Никому и ничего. А если если между этими таблицами(users,persons) будет связь, уже можно узнать кто залогинился и выписал накладной или сделал приход- Вася Пупкин или Иван Иванич. Со всеми таблицами связи будут идти от users, а не от сотрудник.

АнатоЛойСегодня у вас пользователь Сотрудник Вася Пупкин (пользуется UI вашей системы), а завтра - используемая на предпрятии ERP (пользуется API вашей системы).
Вы имеете ввиду создать пользователи не в БД, а в security2.fdb?

АнатоЛойDelphi159, я отвечал на вопрос в стартовой теме: нужно ли разделять "Пользователя" и "Сотрудника".

Ответ: да, нужно.
"Пользователь" = некто (персона)/нечто (система), пользующееся интерфейсами (UI, API) нашей системы .
"Сотрудник" - некто (персона), имеющий отношения с нашей организацией .

Тот факт, что одна и та же персона :
- может выступать или не выступать в роли сотрудника компании
- может выступать или не выступать в роли пользователя системы,
не самый лучший способ совместить "Пользователей" и "Сотрудников" в одной таблице.

"Пользователи" - подмножество объединения "Персон" и "Систем".
"Сотрудники" - подмножество "Персон".

Пересечение "Пользователей" и "Сотрудников" в общем случае меньше и чем "Пользователи", и чем "Сотрудники".

Атрибуты "Пользователей" не пересекаются с атрибутами "Сотрудников".

У "Пользователя" есть НЕОБЯЗАТЕЛЬНАЯ ссылка на "Сотрудника" или на "Персону".
У "Сотрудника" есть НЕОБЯЗАТЕЛЬНАЯ ссылка на "Пользователя".

Мдааа, самый исчерпывающий ответ! Вопросов почти не остался, кроме:

1) Уже не сомневаюсь в необходимости отдельной таблицы Emplyees, но не могу понять в чём необходимость таблицы Persons? . В таблице Persons включаем тех людей, кто не сотрудник, например:
а."гость"-осматривает мою программу,собирается в будущем её купить
б. "будущий оператор программы"-пока не принимали на работу и изучает программу
в. Аудит...
Зачем для них сделать запись в persons (ФИО, паспорт...)- это же будет лишняя, никому ненужная информация? Они все временные гости в системе, имея привилегию только на select, мы можем всем им давать доступ к БД с одной ролью Guests. Зачем несотрудников конкретизировать?

2) Как гостям давать права на доступ к БД? Имею в виду каким может быть алгоритм:
а. Ели не ввёл логин и пароль- тогда он гость и пусть заидёт с ролью Guests.
б. иметь на форме чекбокс "гости". Если включен, disable 2 edits:login, passwoed и заходить как гость.
в. создать заранее один user "гость". Но где его запихнуть? только для этого создать вышесказанную таблицу persons?
у кого как реализован?

посмотрите что получилось, покритикуйте кто чем может....
зелёные таблицы- связывающие(многие ко многим).

Mr.FontaineDelphi159, ну разве что для связки полей id_roles-id_users использовать отдельную табличку, а в таблице roles оставить id_roles и name. Также предусмотреть, возможность привязки роли к группе пользователей.

да ещё в таблице users_groups поле id_users_groups лишнее, ибо везде всё равно будет привязки или к группе или к пользователю.

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

Mr.Fontaineнормально
Вы только об отношении таблиц users, empl(выходя из заголовка топика) или о диаграмме в целом? Я прощу всех покритиковать целую диаграмму, связи контрагента с другими таблицами, поля таблиц(что не хватает, лишние, не в том таблице и т.д.).

Кот Матроскин
... мигрировавших полей.

В смысле?

Кот МатроскинDelphi159,

Ну в смысле - у Вас у таблиц юридических лиц и контрагентов отношение 1:1, верно?
И в одной и в другой есть поле "юридический адрес". В чем смысл? У этих полей одно и то же значение? Тогда это ФЗ.

Согласен, кроме этого manager и identcode тоже должны быть только у юриков. Спасибо!

Кот МатроскинDelphi159,

Да в том-то и дело, что по Вашей диаграмме все поля этой таблицы повторяют соответствующие поля контрагента - и упомянутые Вами, и Name, и ChiefAccount
Согласен, доработаю эту часть,это легко исправить.Просто потом добавил таблицу legalentities и и там и там остались. Спасибо!
Больше критических замечании у кого-нибудь есть?