Покритикуйте пожалуйста структуру БД.
Схема во вложенном файле =)

Kirill Razuvaev
>> Покритикуйте пожалуйста структуру БД.

Было бы неплохо формализуемую предментную область описать...



Это краткое описание ? =)

Система планирования и учёта. направленная на строительство. Что то вроде MS Project только очень маленькая )))

TBL_BRIGADE - Таблица бригад рабочих
TBL_BRIGADE_WORKERS_TREE - Дерево привязки рабочих к бригадам
TBL_COUSTS - таблица затрат
TBL_GRAPH - Основная таблица. Хранятся задачи и их сроки.
TBL_GRAPH_BRIGADE_TREE - Таблица привязки бригад к задачам
TBL_GRAPH_MASH_TREE - Таблица привязки техники к задачам
TBL_GRAPH_RESOURCES_TREE - Таблица привязки материалов к задачам
TBL_GROUP_COUSTS - Таблица групп затрат
TBL_OBJECT_LIST - Список строительных объектов
TBL_RESOURCES_EI - Единицы измерения (м,м2,м3,кг,тн...)
TBL_RESOURCES_TYPE - Типы материалов
TBL_WORKERS - Таблица рабочий
TBL_USERS - Таблица пользователей системы
TBL_USERS_DEPARTMENTS - Список отделов для пользователей
TBL_USERS_POSTS - Должности пользователей
TBL_USERS_ROLE - Пользовательские роли
TBL_USERS_ROLE_ATRIB - Атрибуты для роли
TBL_WORKERS_POSTS - Должности рабочих

Неужели нет никаких косяков ? =)
Тогда спрошу )))
Как организовать хранение и вывод суммарных задач ? как в MS Project ?

Kirill Razuvaev
>> Неужели нет никаких косяков ? =)
Вообще-то, я имел ввиду словесное описание задачи. Тем более, что не все
видели MS Project.

Есть список объектов. По каждому объекту есть список работ. По каждому виду работы есть сроки(начало и конец), объём работы, зарплата рабочих (привязка бригад и планируется ещё несколько таблиц для привязки норм зарплат), материалы(таблица материалов) и строительная техника (тоже привязка таблицы) и ещё сегодня добавил поле длительность(кол-во дней).
Всё это выглядит как на прикреплённой картинке

авторСмысл отдельного ПК ID_TREE в TBL_BRIGADE_WORKERS_TREE?
Я просто не успел удалить табличку ID_TREE =)

автор3. Получается двоякая связь бригады с объектом TBL_BRIGADE -
TBL_OBJECTS_LIST и
TBL_BRIGADE - TBL_GRAPH_BRIGADE_TREE - TBL_GRAPH - TBL_OBJECTS_LIST.
Рискуете получить неоднозначность.
Я не могу удалить связь TBL_BRIGADE - TBL_GRAPH_BRIGADE_TREE - TBL_GRAPH - TBL_OBJECTS_LIST
Но и TBL_BRIGADE - TBL_OBJECTS_LIST тоже вроде не удалить.
Т.К. первый пользователь при создании бригады будет привязывать её к объекту потом следующий пользователь получит список выделенных ему бругад и только после этого будет раскидывать их по работам!
Даже не знаю что и делать =(
автор4. TBL_GRAPH_MASH-TREE - "Таблица привязки техники к задачам" - по
определению не может иметь только один внешний ключ.
Да действительно что то я поспешил =)
Надо полностью переделывать эту связь и добавлять таблички.
Что бы ещё учесть что бы не получилось так что один кран одновременно работал на двух объектах )))
автор5. Не ясен смысл связи TBL_GRAPH - "Основная таблица. Хранятся задачи и их
сроки." и TBL_RESOURCES_EI - "Единицы измерения".
Ну надеюсь после скриншота станет понятно =)
автор6. Обычно не делают без особой нужды отдельные таблицы для аналогичных
сущностей - "Должности рабочих" и "Должности пользователей", удобнее один
справочник, в котором можно флагами разделить рабочих от служащих.

А очень плохо использовать это в двух табличках ?
Просто хотел ограничить доступ пользователей к редактированию таблиц TBL_USERS, TBL_USERS_POSTS, TBL_USERS_DEPARTMENTS, TBL_USERS_ROLE, TBL_USERS_ROLE_ATRIB
авторЕсть такие страшные слова - "отчеты", "выборки", "запросы"... Без них и MSP
не обходится.
Да я это понимаю... =)
Просто думаю как хранить суммарные задачи в базе.
Суммарные задачи это задачи в скриншоте которые выделенные жирным!
Их атрибуты(зарплата,материалы, сроки и прочее) вычисляются из подзадач.
Грубо говоря это как дерево. Где листья это обычные задачи а узлы разветвления это и есть суммарные задачи. Ну а ствол и есть главная суммарная задача состоящая из других суммарных задач =)
авторP.S. Если мы так проектируем учет - то страшно подумать, как строим... :-)))
Я только начинаю =))) Поэтому и попросил указать на ошибки =)
Строим вроде нормально =)

Kirill Razuvaev
А вот этого - пока не ощущается.
Скажу честно, не вижу никакого смысла в Вашем случае хранить агрегаты. Их
хранят отдельно только тогда, когда эти итоги очень часто используются в
качестве исходных данных при объемных расчетов.

P.S. Короче, переделывайте и нормальную схему с бизнес-описанием
выкладывайте, если хотите совет получить. Не забыв, ессно, про все
вышеуказанное.


У каждой задачи есть объём работы. Этот объём измеряется в единицах измерения. Что бы не создавать лишнюю таблицу использую справочник единиц измерения материалов.

Переделывать всё полностью или только части по которым замечания ?

А можно ещё ссылочку на нормальное бизнес описание ? В интернете ничего не нашёл =(

Исправленная схема =)
Над описанием ещё работаю =)

Serguei
С ключами проблема большая у вас. Читайте что такое primary key и для чего они нужны.


Хм странно. Очень внимательно читал тему ключей.
Вроде сделал всё правильно. Не стал использовать естественный ключ а использую суррогатный ключ.
Вроде как у естественного есть недостатки.
Что именно неправильно ?

Составил схему бизнес-процессов =) ну а точнее что то приближённое =)

Ну и наконец схема БД. Там только таблицы которые относятся к процессам которые я описал.

dymkaOleg Kondratskiy,

Свои пять копеек по поводу не структуры, а именования:
1. Непоследовательны наименования ключей, то ID_<ENTITY>, то <ENTITY>_ID. Нужно что-то одно. Лично мне нравится <ENTITY>_ID: RESOURCE_ID, DEMAND_ID итп
2. Я бы убрал нафиг TBL_. Таблицы можно и без префиксов создавать.
3. Если есть семантически отличия между ключами ID_TREE в различных таблицах (т.е. это принципиально различные сущности), то и назвал бы их по-разному. Например, в таблице TBL_GRAPH_BRIGADE_TREE - GBT_ID (GB_TREE_ID итп), а в таблице TBL_BRIGADE_WORKER_TREE - BWT_ID (BW_TREE_ID итп). Потом легче будет просматривать свои запросы.
4. Наименования некоторых таблиц в единственном числе, некоторых во множественном. Опять таки лучше выбрать что-то одно.
5. Наименования полей, являющихся внешними ключами, сделал бы идентичными с именем поля первичного ключа таблицы, например: TBL_USERS: USER_POST_ID и в таблице TBL_USERS_POSTS поле ключа - USER_POST_ID. Не надо будет ломать голову и лазить каждый раз к диаграмме, чтобы вспомнить как то или иное поле называется:
select ... from users as u join user_posts as up on up.user_post_id = u.user_post_id

Ну это так - мелкие придирки. Зачастую спорные - и без всего это будет работать :)

А чтобы понять структуру нужно хорошенько въезжать в процесс. Времени мало.

1. У меня ID_<ENTITY> для primary key а <ENTITY>_ID для FK =) Как то успел уже к этому привыкнуть =)
3. Хорошие сокращения ))) Как я сразу до них не додумался ? =(
5. Вроде как относится к 1 ответу )))
спс

Kirill Razuvaev
>> Составил схему бизнес-процессов =) ну а точнее что то приближённое =)

Вообще-то, я говорил про словесное описание...

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


P.S. А прикладывать рисунки, аналогчиные "Материалы.jpg" по качеству вообще
считаю издевательством.



Сори но файлы свыше 100kb не прикрепить =(
Обработал как смог =(

Описание части учёта материалов .
Есть справочник материалов (tbl_resources) который содержит: название материала, группу материалов, единицу измерения и стоимость.
Сущность материалы - единица измерения материалов . Каждый материал должен иметь единицу измерения, которая берётся из справочника единицы измерения(tbl_resources_ei).
Аналогично устроена сущность тип материала берётся из таблицы типы материалов(tbl_resources type).
Планируется что в справочнике материалов будут храниться и обновляться практически все существующие материалы. Этот список хочу выкачивать с диска прилагаемого к журналу "Сметные цены в строительстве". Цены обновляются каждый месяц и в связи с этим необходимо и обновлять таблицу.
Есть склад(tbl_sklad) в этой таблице будут храниться материалы имеющие в наличии и их количество на базе. Сущность склад-ресурсы : На складе могут храниться материалы только из справочника. Пользователь при закупке материалов будет выбирать материал из списка и вводить кол-во которое он купил. Хочу сделать ещё одну таблицу для хранения затрат на эти ресурсы. тоесть сделать ещё одну сущность склад - затраты, один ко многим. при вводе данных по закупке пользователей будет ещё вводить сумму за купленный материал.
Таблица заявки(tbl_demand). В этой таблице будут храниться заявки с объектов на материалы. Каждая заявке имеет свой номер(number(integer)) и может содержать один или несколько материалов.// Может имеет смысл номер заявки хранить не в integer а в varchar и стоставлять номер примерно так: код объекта_дата_кол-во материалов в заявке. пример 3_17/07/2009_8 и сделать поле UNIQUE. ?
Есть таблица перемещений(tbl_moving) которая служит для хранения данных перемещений материалов.
Сущность передвижение - заявка служит для привязке премещений к заявкам. тоесть перемещать материал со склада можно только по заявке.
Сущность заявка-материалы служит для определения какой материал перемещается.
Я уже понял что сущность передвижение - объект лишняя, т.к. для определения объекта на который отправляется материал можно определить по сущности заявка- объект.

Ну как то так.
Посмотреть бы как нормальное описание выглядет .