Отцы,

Позвольте мне представить на ваш суд свой планчик по проектированию БД среднего масштаба, которые я сделал для себя, изучая Дэйвида М. Крёнке ( «Теория и практика построения БД». 8-е издание ) и проектируя базу для CRM нашей фирмы, на основе изученного.

Цель плана - не в создании "новой" методологии. Мне просто нужно выяснить у практиков и теоретиков чего здесь не хватает или что лишнее. Понимаю, что невозможно привести к какому-либо алгоритму такую нелинейную задачу как планирование БД, и всеже мне кажется, что необходим хотя бы самый общий план, для того чтобы избежать хотя бы грубых неточностей. Намеренно избегаю слово “ошибок”, потому как и в самом плане наверняка многие найдут просчеты.

Использована модель проектирования «Сущность-Связь» (сверху-вниз), для семантической модели не было достаточно исходных документов.
Для эскизов использовались (пригибаю голову пониже ;-) Power Point, для графического оформления модели данных пользователя и как CASE инструмент – MS Visio2002. Карандашом и бумагой - пробовал, но опыта не хватает с первого раза всё правильно нарисовать. И со второго тоже.

Итак,

Практический план проектирования БД

1. Постановка задачи. Формулировка в письменном виде — цели приложения, основные объекты, операции движения документов между объектами.
2. Интервью с будущими пользователями приложения. Можно по корпоративному мылу, разослать своё описание представления, собрать в кучу ответы и переписать представление.
3. Уточнить требования.
4. Составить первичную модель данных пользователя – User Data Model (UDM), только сущности и их связи: Parent <-- Child.
5. Уточнить UDM:
a. определить на UDM слабые сущности,
b. определить кардинальные числа.
6. В Database Model Diagram (DMD) сущности представить в виде отношений.
7. Добавить атрибуты отношений.
8. Отношения Parent: определить Primary Key
9. Отношения Parent: добавить IsValid (устаревание/удаление данных)
10. Уточнить с пользователями состав атрибутов и домены аттрибутов, определить необходимость хранения NULL значений (неизвестен, неприменим на данный момент, равен нулю).
11. Создать связи между отношениями (далее, исходя из того что DMD составляется в Visio)
a. Протянуть коннекторы Relationship от Child к (-->) Parent
b. Определить установку аттрибутов IsRequired для созданных Foreign Key в Child Table
c. Установить вид зависимости для слабых сущностей: идентификационная или нет. Если нет - нужно ли каскадированное удаление.
d. Установить кардинальность связи.

12. Добавить ограничения на значения доменов атрибутов (проверки, дефолты и т.д.)
13. Протянуть связи между надтипами и подтипами в категориях.
14. Создать отношения пересечений, для связей N:M, протянуть связи. (Нотация – INTS _Сущность1_Cущность2)
15. Создать отношения пересечений для рекурсивных связей,
a. создать связи,
b. один из Foreign Key в пересечении – выставить как Primary Key.
c. Второй FK – необязательный (Nullable), развернуть его связь с Parent наооборот (Verb Prase – is of, Inverse Phrase - has)
16. Проанализировать отношения на нормализацию, в случае необходимости нормализовать.
17. Перепроверить связи и кардинальные числа в DMD сверяясь с UDM.
a. Parent <-- Child, направление связи, кардинальности.
b. Child -->Parent, FK – required если Child к Parent как N:1(1:1) и обязателен в связи.

18. Добавить описание тернарных связей в Report.
19. Добавить индексы.

Проделав все операции, я сделал Validation Logical and Physical модель versus SQL driver - ошибок – 0, что конечно ни о чем не говорит.

С уважением,
Axl.

Здорово отцы!

Очень рад видеть здесь ваши ответы, и как рад видеть что задел что-то в душе (или что там у него) гуру Репликанта. Раз он разразился таким длинным письмом. :-)

2 Репликант. Письмо ваше я сохранил к себе по подушку, буду перечитывать и набираться разуму. Я серьёзно, спасибо за линки и обзор!
Как я писал, я не ставил целью создать описание алгоритма проектирования. И тем не менее, изучив своего Д. Кренке до главы о переносе физмодели проекта на СУБД, я пришел к выводу, что определенные последовательности в проектировании есть! Особенно в части касающейся проектирования логической модели на физическую, так как повторяющиеся операции присутствуют на определенных шагах довольно часто. Возможно вы как опытный разработчик даже не осознаете этого, но для меня алгоритм важен, для того чтобы не запутаться и произвести все необходимые операции для каждой сущности. Конечно это нужно делать с головой, кто спорит?! Мне вообщем хотелось просто узнать, не допустил ли я грубых просчетов, прежде чем начинать генерить и дорабатывать скрипты DDL.

По поводу первых трех шагов, я согласен описание этих шагов довольно размытое, впрочем ТЗ что я получил от сотрудников фирмы, еще более бестолковое. Не буду касаться процесса его создания, это другой топик с участием в главной роли г-на Репликанта, который я еще не дочитал. Скажу только, что ТЗ(да бросьте какое там ТЗ, просто описание объектов и требуемых аттрибутов) я написал сам и уточнил его у манагеров и части пользователей. В силу того что сложных формул не предвидится и процессы в пределах человеческой логики, надеюсь что этого будет достаточно.

Однозначно, придется доделывать после, но тут и самое растолковое ТЗ не поможет, просто потому что я не могу заставить подписаться манагеров под своими словами и доработку нужно будет делать на ходу.

Еще одно наблюдение, по прочтении части материалов этого форума, у меня сложилось впечатление, что вообще к ПРОЕКТИРОВАНИЮ БД, обычно два отношения. Одно - стиль Cat2 (системные требования а дальше полет фантазии) и стиль Репликанта (все подробно и по науке, что конечно не исключает полет мысли :) Истина наверно как всегда посредине...

Спасибо!

2Cat2 - Спасибо за вашу оценку. Все таки мне непонятно ваше отношение к слабым сущностям. Что ВЫ подразумеваете под тем что их не должно быть? В любом проекте почти все объекты - логически зависимые от других объектов, а независимыми являются только те зависимость которых отслеживать нет необходимости. Это вопрос отношений м/у объектами. К примеру если мы рассматриваем кадровую структуру офиса, и в проекте не предусмотрена связь офиса с головным офисом, то он и будет независимой сущностью, от которой будут зависеть остальные более мелкие сущности (отдел, начальник, подчиненный и т.д.) Эти сущности и будут слабыми. Как мне кажется слабые сущности могут отсутствовать в проекте только если в проекте одно громадное денормализованное отношение. Г-н Репликант, или я не таки-не прав?

С уважением,
Axl