плиз помогите с ДБ дизайном

[Sabina]

Есть кусочек базы (см. диаграмму на картинке)

Проблема с managerID. По идее хорошо бы его привязать к userID, но получаются сплошные противоречия.

1) Если посадить в Department table, то нельзя делать FK на CMSUser.userID, потому что как тогда заполнять. Department не заполнишь без юзеров, а юзеров без department-а.

2) Если посадить аттрибутом в CMSUser, то получается референс таблицы саму на себя и опять сложности с заполнением таблицы: типа начать с менеджера но в первом же рекорде ссылка на самого себя....

Получается никак этого manager ID в foreign key не засунешь...
Ну не делать же отдельную таблицу с парами Отдел-Менеджер, которая будет заполняться после отдела и юзеров?

Как это все дело нормализовать пограмотнее?

Сабина

[Dmitry67]

Картинка не читается
Но если структура запутанная то зачем городить FK ?
Многие сложные аспекты логики проверяются триггерами или обеспечиваются 'по построению' через stored proc

[Sabina]

Картинка не читается

Я на html поменяла.

[Sabina]

Картинка не читается
Но если структура запутанная то зачем городить FK ?
Многие сложные аспекты логики проверяются триггерами или обеспечиваются 'по построению' через stored proc

Дима, у меня есть подозрение, что я это все потому что я дальше first normal form сама никогда не "ходила"...
Пусть думаю спецы глянут.

Сабина

[zVlad]

Есть кусочек базы (см. диаграмму на картинке)

Проблема с managerID. По идее хорошо бы его привязать к userID, но получаются сплошные противоречия.

1) Если посадить в Department table, то нельзя делать FK на CMSUser.userID, потому что как тогда заполнять. Department не заполнишь без юзеров, а юзеров без department-а.

.....

А может уточну позже, но навскидку объяснение такое: внешний ключ может иметь значение NULL (по крайней мере в DB2). Таким образом сначала заводится департмент с NULL в столбце менеджера, затем имрлои (менеджер) и строка департмента обновляется с этим (или другим) имплои.

[JustMax]

1 ) Я бы IMHO обьеденил USER и LoginInfo. (Third Normal Form ?)
Зачем городить сущности ? Ну ето дело вкуса.
2) Согласен с zVlad, добавлю только что, начиная с 8 Оракла
есть возможность создавать deffered constraints, t.e проверка на ссылочную целостность осуществляется только при commit.
T.e. вставляете запись в департамент без managerID -> всавляете
менеджера -> изменяете managerID -> commit. Все FK not null

[Sabina]

1 ) Я бы IMHO обьеденил USER и LoginInfo. (Third Normal Form ?)
Зачем городить сущности ? Ну ето дело вкуса.

Моим мотивом было то, что LoginInfo table будет востребована гораздо чаще чем CMSUser.

Сабина