Гость
Войти | Профиль | Очистить
Целевая тема:
Создать новую тему:
Автор:
Действия ...
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / структура таблиц для иерархии подразделений, пользователей, данных / 5 сообщений из 5, страница 1 из 1
03.03.2010, 11:30
    #36499191
Serge N
Serge N
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
структура таблиц для иерархии подразделений, пользователей, данных
Добрый день!

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

Структура подразделений - древоводная - филиал -> участок -> отдел
Подразделения могут прекращать существование, дробиться, менять подчинение. Могут появляться новые.

Пользователь может переходить из одного подразделения в другое.

Сейчас есть таблица подразделений
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
create table div 
(div_id number, -- первичный ключ
 parent_id number, -- вышестоящее подразделение
 name varchar2( 100 ),
 date_begin date, -- когда создано
 date_end date -- когда упразнено/закрыто
);
если подразделение меняет подчиненность, то у старой записи выставляется date_end и создается новая запись с той же date_begin и новым подчинением

Таблица пользователей:
Код: plaintext
1.
2.
3.
4.
5.
create table worker 
(
  worker_id number,
  name varchar2( 100 ),
  div_id number -- ссылка на подразделение,  в котором работает пользователь и данные которого он должен видеть
)

Есть несколько систем, пользующихся этими 2 справочниками
В каждой системе есть таблицы данных data:
Код: plaintext
1.
2.
3.
4.
5.
create table data
(
  datafield1 ... datafieldN,
  div_id -- подразделение, к которому относятся эти данные
)
При входе в систему пользователь видит только те данные, где div_id = worker.div_id

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

При переводе отдела в div появляется новая запись. Все пользователи и данные привязаны к старой записи. Если перепривязать к новой записи только пользователя, он перестанет видеть записи старого подразделения. Если поменять div_id на новый и в данных, то на предыдущие периоды нельзя будет увидеть состояние данных - данные будут такими, как будто они заносились в новое подразделение.

Как сделать так, чтобы можно было видеть данные во всей хронологии? Чтобы пользователь видел за предыдущий период данные старого подразделения, а за новый - только нового.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
03.03.2010, 22:13
    #36501119
guest_20040621
guest_20040621
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
структура таблиц для иерархии подразделений, пользователей, данных
Интересная задача, Serge N.

Imho два подхода: костыли к старой структуре или новая реализация. В какой степени готовы к редизайну?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
04.03.2010, 02:36
    #36501272
ChA
ChA
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
структура таблиц для иерархии подразделений, пользователей, данных
Serge NКак сделать так, чтобы можно было видеть данные во всей хронологии? Чтобы пользователь видел за предыдущий период данные старого подразделения, а за новый - только нового.Явная связь "многие-ко-многим", работник может относится к нескольким подразделением, в общем случае - даже одновременно, и наоборот, в подразделении может быть сколь угодно работников. Стандартный вариант - добавить ещё одну таблицу, связи работников с подразделениями, worker_div(worker_id, div_id) . Доступность данных при таком подходе вычисляется очевидным способом. Поле div_id в таблице worker , разумеется, становится абсолютно излишним. Но это, скорее, паллиатив, чем решение.
Если подходить тщательнее, то действительно стоило бы пересмотреть постановку. Есть ощущение непродуманности и некоторых явных искусственных ограничений в схеме данных. Например, "принадлежность" определённых данных только одному подразделению, т.е., ограничение аналогичное "жесткой" привязке работника к одному подразделению, которое Вы теперь вынуждены обходить.
В общем случае, распределение доступа пользователя к данным несколько сложнее описанного Вами варианта. И если есть такая возможность, то его стоило бы переосмыслить в сторону большей унификации и гибкости. Начните, например, отсюда , и далее по ссылкам и ключевым словам.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
04.03.2010, 10:23
    #36501567
_мод
_мод
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
структура таблиц для иерархии подразделений, пользователей, данных
Serge NПроблема при изменении структуры подразделений:
При переводе отдела в div появляется новая запись. Все пользователи и данные привязаны к старой записи.
Здесь ошибка. Пользователи д.б. привязаны не к записи, а к своему подразделению. Перемещение подразделения не влияет на его состав.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
04.03.2010, 10:34
    #36501601
guest_20040621
guest_20040621
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
структура таблиц для иерархии подразделений, пользователей, данных
> Здесь ошибка.

Здесь достаточно логических ошибок.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / структура таблиц для иерархии подразделений, пользователей, данных / 5 сообщений из 5, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение  
Полит. конфиден.  
созд. / загр.: 497ms
Закрыть
start [/forum/topic.php?fid=32&mobile=1&tid=1542822]:
 0ms
get settings:
 9ms
get forum list:
 20ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 166ms
get topic data:
 12ms
get forum data:
 3ms
get page messages:
 48ms
get tp. blocked users:
 2ms
others: 231ms
total:  497ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]