Проектирование баз данных. Алгоритм действий и инструменты

в продолжение обсуждения в теме решил создать отдельную тему.

Мартин Грабер в Гл 19 "Проектирование баз данных" описывает два основных алгоритма создания баз данных, а именно:
1. На базе подхода ER-модели создаются ER-диаграммы, затем они преобразуются программистом в таблицы реляционной базы данных и проверяются на соответствие требованиям нормализации (то есть, фактически, не накосячил ли программист, ведь если все делать правильно, то из ER-диаграммы путем достаточно формальных процедур можно получить достаточно нормализованные таблицы).
2. Создается некая супертаблица (набор супертаблиц), то есть набор всех возможных атрибутов (столбцов) в одной куче, и затем путем её декомпозиции создаётся удобоваримый и в меру нормализованный набор таблиц - схема БД.

При это отмечается, что подход на базе ER-модели является предпочтительным и к тому же - более человечным, интуитивно более понятным (он менее формален, чем подход два).

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

P.S.
Есть конечно некий предварительный этап (очень важный и затратный по силам и времени), вплоть до разработки ТЗ, который может разниться в зависимости от рода задачи, а именно:
- Изучение предметной области
- Выявление и определение сущностей, атрибутов (столбцов), связей
и т.д.
Но это отдельная история.
Если говорить ещё и о проблеме разработки ТЗ, о проблеме общения с заказчиками и со специалистами предметной области - то это отдельная задача.
Кстати, проблемы этой задачи в чем-то общие и при разработке БД для заказчика и при разработке сайта. Особенно, если заказчик не является крупной структурой и у него нет специалистов-программистов, погруженных в предметную область и могущих компетентно разработать ТЗ.
То есть, есть проблема преодоления пропасти: программист не знает предметной области, а заказчик не понимает как поставить задачу программисту. Считаю, что для преодоления такой пропасти могло бы существовать специальное ПО. Но это постскриптум.

1

До кучи перенесу диалог с Usaga из соседней темы:

Сообщение от titan4ik Usaga, то есть, практически ER-диаграммы не используются? Шош тогда Мартин Грабер сбивает народ с толку?

Сообщение от Usaga titan4ik, используются в разного рода ТЗ. Для реализации самой схемы базы диаграммы не нужны.

Сообщение от titan4ik То есть, в ТЗ используется, то бишь - для понимания предметной области и осознания задачи используется, как интерфейс общения с "заказчиками" годится. Но ведь ничего больше от ER-модели и не требуется. Как её ещё можно использовать?! Далее программист на основе неё создаёт саму схему (таблицы БД) тем или иным образом. Вывод - для реализации схемы БД она нужна (может быть использована в вышеуказанном смысле).

VinniPuh,
Добавлено через 30 минут

Сообщение от VinniPuh при проектировании принципиальных схем по автоматизации оборудования котельных, всегда сначала нарисую принципиальную электрическую схему схему с теми же реле, их контактами и прочими переключателями.

Не понял. А как же иначе? То бишь как же без принципиальных эл схем разрабатывать эл схемы?!))) Или Вы имеете ввиду, что сначала на этой элементной базе (старой, но при этом визуально интуитивно понятная схема получается), а потом на новой, то бишь полупроводниковой?
То есть, как промежуточный этап осознания и визуализации логики работы схемы?

Сообщение от VinniPuh Правда не на листочке это делаю а на компе в экселе рисую, ибо можно изменить не черкая и не стирая.

Эксель в этом смысле тот же листик и карандаш, только в чем-то удобнее, а в чем-то нет)

Сообщение от VinniPuh Возможно есть какие то и более продвинутые программы, но

Вот именно... НО... Эта продвинутость может быть не вполне в нужную сторону. Излишнее усложнее интерфейса, идиотская логика, "заморочки" с приобретением и т.п.
Плюс-минус - привычка и деловые обыкновения)

0

Сообщение от titan4ik 1. Как быть, если разработка большая и много разработчиков

Сообщение от VinniPuh Тут наверное таки нужно иметь общий план и схему, что бы все работали над проектом в одном ключе, а не вразброс, но это скорее всего должен делать кто то один, типа управляя и направляя процесс созидания.

это как правило делает архитектор

0

Сообщение от pincet это как правило делает архитектор

А он ER-модель использует?) Об этом же речь.

0

рекомендую найти книгу
Ричард Баркер. Моделирование взаимосвязей между сущностями

Добавлено через 2 минуты

Сообщение от titan4ik А он ER-модель использует?) Об этом же речь.

как без моделирования? если говорим про РСУБД - да, если NoSql - то я хз, как там все дело обстоит

Добавлено через 1 минуту

Сообщение от pincet Ричард Баркер. Моделирование взаимосвязей между сущностями

Case*Method - Entity Relationship Modelling by Richard Barker

1

Сообщение от VinniPuh Хорошая тема.

VinniPuh, видать, близнецов оказалось всего два)
И спасибо откликнувшимся pincet и Andrey-MSK.
Хотелось бы конечно услышать ещё и дальних родственников.

0