Как лучше сделать такую БД ...

У меня есть база предприятий. У каждого предприятия куча подразделений. У каждого подразделения куча должностей. У каждой должности куча обязанностей. На каждую обязанность наложено куча ответственностей. Получается чем дальше, тем больше данных. Как правильно сформировать БД???
Ведь под каждое предприятие надо делать свою БД или хотя бы что-то типа каталога где хранить.
Как быть???
Понятно что надо завести отдельно таблицу предприятий, подразделений, должностей и т.д. Но если в таблице хранить несколько предприятий(порядка 200), то запросы будут обрабатываться чёрт знает сколько времени.
Я новичок в этом деле. Может быть не очень понятно объяснил. Задавайте вопросы.
Жду помощи.. Большое Спасибо всем кто примет участие и даст совет.

0

Ничего особенного. Под каждый тип объекта - отдельную таблицу. Для отношений объектов - тоже по таблице. На каждый справочник по таблице. Джойниш их друг с другом - получаешь результирующий рекордсет.
Так что - обычная ситуация(если работать в идеологии ErWin:-).

0

Для sergwsk . Что значит для отношений тоже по таблице???

0

Есть слово такое нормализация. Менее страшно, чем ErWin звучит.

to forrest:
Есть две связанные таблицы A и B.
В UML этот факт отображается как A <-> B в любом случае. В базе же, если у тебя соотношение 1 ко многим то требуется три сущности:
A(PKa,...), B(PKb,...) и AB (FKa, FKb). Так это отображается в ErWin'е и кстати на диаграмме в Enterprise Manager.
Возвращаясь к нормализации - обычно базы проектируют в третьей нормальной форме. Но (и об этом часто умалчивают в книгах) в жизненных ситуациях (очень часто как раз из-за отчётов) от 3-й формы приходится отступать ко второй.

Ес-но на логическом уровне проектирования БД. Например есть: объект книга и объект автор. Нужно куда то поместить 'процент гонорара автора в стоимости конкретной книги при написании её в соавторстве с другим автором'. Так вот- этот процент есть свойство отношения и будет храниться в специальной таблице отношений, типа 'книга-автор'.
P.S.Кстати, можно обобщить для всех объектов в БД.

0

Короче, не забивай себе голову . Лепишь концептуальную модель БД. И , при правильном проектировании, она уже в 4НФ. А уж каким инструментом пользоваться (ервин-сие инструмент для проектирования) - это дело частное.
Ну а если серьёзно, то задачка у тебя не простая. Литературу почитай по проектированию БД - в двух словах, что и как тут не описать.

0

Разработка базы действительно очень трудоемкий процесс, здесь тебе все выложить не сможет никто. Читай литературу и задавай конкретные вопросы. А что касается твоей задачи, то на самом деле она не самая сложная, оргштатная структура хорошо укладывается в ER-модель... И еще, 200 записей в таблице это мелочь, при правильной организации сруктуры и построении запросов речь нужно вести о сотнях тысяч записей...так что это не должно тебя пугать...

Спасибо всем кто ответил!
Хочу ещё кое-что добавить!
Проблема в том, что даже если следовать модели ER-Win то всё равно проблема решённой не остаётся.
Для каждого предприятия (организации) процент правильного исполнения той или иной ответственности разный. Даже это не процент, а своеобразный внутренний коэффициент(цифра, м.б. и 3-х значная, ну это и не важно). Т.е. для каждого предприятия для каждого подразделения, для каждой должности под каждую ответственность надо хранить этот самый коэффициент (это всё я утрирую).
Например у менеджера по доставке продукции есть несколько доставок(ответственностей). По каждой доставке вводятся следующие критерии:
1) время доставки (в какое время удобное или неудобное для клиента была доставлена продукция)
2) продолжительность доставки (время в пути)
3) Стоимость доставки (грубо говоря он должен постараться взять как можно больше денег с клиента)
4) Затраты на доставку(расходы).
И т.д. и т.п.
Это всё надо хранить и разделять.
Если строить сначала справочники, а потом таблицы отношений, то это можно будет запутаться.
Речь идёт о нескольких таблицах(м.б. 200-300), где
порядка (для начала) 20000 записей. И это будет разрастаться со временем поступления заказа то от одного или другого предприятия.
При том у менеджеров одни ответсвенности - это доставки, а у администрации или неквалифицированной рабочей силы они совсем другие, и для каждого предприятия разные. Естественно время от времени они повторяются. Поэтому и возникла идея о подведении всего этого хозяйства под одну гребёнку.
Справочники содержат около 5000 записей в среднем. Их штук 50.
Жду ответа. Спасибо!!!

0

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

0

lan > не совсем согласен с тобой, разработка бд на предприятии процесс достаточно критичный (особенно если заказчик ставит в какие-то жесткие рамки). Не везде менталитет предприятий дорос до того уровня в IT-технологиях, где можно применять классические правила. Поэтому оптимизировать структуру данных и думать о том как ты будешь строить запросы порой необходимо априорно, хотя согласен что для этого необходим определенный опыт в разработке. Это называется частным решением или подходом. Вобщем, пытаясь строить модель на уровне сущностей, атрибутов и связей необходимо сразу представлять себе как это будет выглядеть на уровне физическом.

forrest > С другой стороны lan описывает правильный (классический подход) и по сути он прав. А что касается твоей системы, прежде всего, чтобы дать тебе какие-то рекомендации необходимо знать цель разработки, может это сбор статистики и анализ, может это автоматизация бизнес-процесса, может еще что...т.к. к решению одной и той же задачи может быть много подходов.

2mouser: Теперь я не соглашусь. Не имея сформированной концептуальной модели, крайне трудно, если вообще возможно, грамотно спроектировать БД. И на производстве, всем заказчикам глубоко параллелепипедно как ты это делаешь. Важен результат. И без 'правильно подхода' база будет кривая - это факт. И дальнейшее её функционирование, в основном будет зависеть от терпения юзеров и быстроты программеров.

0

lan > никто и не отказывается от концептуальной модели, просто разрабатывая ее нужно сразу смотреть вперед...
А что касается юзеров-ненасытных, так они всегда чем-то недовольны, предпочитаю модель 'заказчик <-> тз <-> разработчик' нежели 'юзер <-> (разработка)сопровождение <-> разработчик' последняя это сущий ад...

> никто и не отказывается от концептуальной >модели, просто разрабатывая ее нужно сразу
>смотреть вперед...
Интересно, а как смотреть вперёд не разработав концептуальную модель?

>'юзер <-> (разработка)сопровождение <-> разработчик'
Такого не бывает, т.е. попытки можно делать в этом направлении, но без результа.

0

lan > как оказывается на практике бывает и то и другое и довольно часто...

Помоему мы несколько отклоняемся от исходной темы...

Вся эта бодяга необходима для оптимизации бизнес процесса. Точнее для формированияя отчётов, которые показывают насколько эффективнее работает тот или иной человечек на одной и той же должности но на разных предприятиях. Затем проводится сравнительный анализ??
В чём бизнес-процесс? В том что потом можно давать рекомендации как лучше вести себя, например, менеджеру в той или иной ситуации.
От какой-то фирмы приходит запрос типа:
'Прошу провести анализ работы агента по продажам специализация №... отрасль №...(берётся из справочника)'.
Что делает фирма: Проводит сравнительный анализ с другими предприятиями с похожей специализацией в той же отрасли. Конечно перед этим запрашивает у клиента кое-какие данные(не буду их приводить нет надобности).
Весь расчёт, всякие там замеры, оптимизацию проводят отдел аналитиков. Моя задача заключается в том, чтобы ускорить процесс составления ответа фирме-клиенту(составление отчётов).
В принципе на этапе проектирования мне пока всё ясно. А Вопросы возникнут потом при работе с самим SQL Server 2000.
Кто-нибудь с ним работал?
Может дадите какие-нибудь рекомендации по поводу его использования? Посоветуете литературу или ссылки пришлёте?
По поводу всякой конкретики:
Как лучше хранить результаты замеров для каждой должности. Наверное в отдельном каталоге ?
Не засорять же базу ими. Ведь для каждого предприятия для каждой должности эта статистика разная. В отчёте всё равно придётся показывать что расчитывали, исходя из чего. Т.е. эти данные придётся откуда-то вытаскивать?
Потом для градации по подразделениям для каждого предприятия тоже придётся создавать таблицу, аможет и не одну (пока над этим не сосредотачивался).
Вот такие пока вопросы.
Буду рад выслушать ответы.
Спасибо всем!

0

все правильно, разработай модель, в этой модели выдели объекты
такие как - предрпиятие, подразделение, должность, и тд
для каждого объекта определи методы и свойства.
и что самое интересное, после этого, хранить все данные можно и в одной таблице.
причем все необходимые отчеты, тоже должны быть представленны в виде объектов!