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

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

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

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

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

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

1

Сообщение от titan4ik ...решил создать отдельную тему....

Хорошая тема.
У меня правда оперативной памяти в голове не хватило дочитать до конца, но начало и задумка первых 10-15 строк мне пнравилась.
Ибо 90% начинающих создавать реляционные БД ваааще похоже не понимають, чего от них требуют, а тем более чему их учат преподы.
Обычно это оперирование максимум таблицами Экселя.
Поставлю ка я отзыв за хорошую тему.
Может в важное со временем перенесут.

0

0

pincet, Если это про меня, то - Истину глаголите Член Корреспондент Академии Наук.
Если про - titan4ik, то прям возжаждал его поддержать.
Ибо за душу взяло, т. к. сам что то на подобии хотел давно написать.
Наверное мы с ним родственники, а то и ваще, разлучённые в детстве - Братья-Близнецы.

0

VinniPuh,
я про ТС

0

Я делал так
Во главу угла ставим Объект (то что описываем) и начинаем его разбивать на более мелкие части в логической последовательности. И в итоге получаем основу Объекта. А потом уже на неё начинаем навешивать что надо.
Если взять мою БД, то логика такая

tblGenPlan (Сам объект) -> tblDraw (чертежи на части объекта) -> tblDrawSys (системы в чертежах частей объекта) -> tblDrawSpec (спецификация - сааамая мелкая часть всего)

А все остальное уже добавлено для реализации специфических задач. И никаких ER-моделей я не рисовал, бумага + ручка + голова + документация Из инструментов MS SQL Server + SSMS + Access для морды БД.
Может я и не прав, но мне так было гораздо проще

Миниатюры

 

1

Сообщение от pincet ...я про ТС...

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

0

Сообщение от Andrey-MSK И никаких ER-моделей я не рисовал, бумага + ручка + голова + документация Из инструментов MS SQL Server + SSMS + Access для морды БД. Может я и не прав, но мне так было гораздо проще

Andrey-MSK, чтобы понять как относиться к вашей инфе, Вы специалист по БД или это был первый и единственный опыт?
На самом деле, вот это метод "бумага + ручка + голова" он конечно является универсальным и я его очень уважаю. Например, любой бизнес-план сводится к 3-5 цифрам (то бишь, числам) и должен умещаться на 1/2 А4 и т.д. и т.п. То бишь логика здравого смысла - это сила!
Однако... хотелось бы услышать и других граждан. Давно заметил, что чем проще и конкретнее вопрос, тем туманнее ответы. Такое ачучение, что граждане-гуру не хотят признаваться в методах своей работы. Неужели и тут работает теория заговора?!)
Пацаны, кто-то применяет ER-модель, использует ER-диаграммы?
Если да, то какие для этого инструменты используете?
Если нет, то что тогда - "бумага + ручка + голова"? А если проект объемный, работает много народа, тоже "бумага + ручка + голова"?
P.S. Тут новости как раз прошли по банкоматам, по платежам, по теме транзакций и параллелизма. Интересно кому все эти Дейт и Грабер и прочие яйцеголовые все эти книги писали и зачем?

Хмм... граждане-специалисты, настоятельно прошу высказаться конкретно.

0

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

Сообщение от titan4ik ...вот это метод "бумага + ручка + голова" он конечно является универсальным и я его очень уважаю...

Лично я не являясь специалистом, а просто любителем БД (ибо на работе приспичило облегчить себе и другим работу и побольше полентяйничать ) стал изучать Access в основном из за безделья.
В те времена наверное и интернета то не было, только книги.
Ручкой и бумажкой ни когда не пользовался.
Всегда интерактивно как в конструкторе творил и пробовал как это будет в натуре работать, очень увлекло.
Access для творчества БД на мой взгляд самое наилучшее средство для начинающих, ИБО там не абстрактно делаются связи между табличками, а чётко и конкретно видно что и в куда в схеме данных, что очень помогает на начальном этапе.
Плюс в нем есть помощники в виде -
Мастер таблиц
Мастер форм
Мастер запросов
Мастер отчетов.
Щас ими не пользуюсь, но в самом начале пути очень даже помогло перестроить логику в голове.
Щас думаю совсем по другому, чем 20 лет назад, что очень помогает по жизни.

1

Сообщение от VinniPuh Щас ими не пользуюсь

А щас как?

0

titan4ik, щас есть - наработки и заготовки.
Пользуюсь только ими.

0

А если новая предметная область и для неё нужно сделать БД, то будете пользоваться ER-диаграммами? Или как?
Или послушаете специалистов из этой области, порисуете карандашом по бумаге, а потом сразу схему (таблицы уже) будете делать с помощью инструментов конкретной используемой (любимой) СУБД?

0

titan4ik, если вы мне, то карандашом портить листочек не буду.
Прокручу все в голове и буду ваять с табличками.
Если чего то не так придумал, то изменяю, ибо когда начинаешь вводить данные, то сразу видно, так или не так придумано.
Но тут нужно учесть, что уже есть опыт создания БД и половина делается просто на автомате.

1

Сообщение от titan4ik А если новая предметная область и для неё нужно сделать БД, то будете пользоваться ER-диаграммами? Или как?

лично мне проще ER на бумаге наваять. Помогает осмыслить. и не более
пысы - если интересно - юзаю нотацию Мартина (воронья лапа)

1

Нет, VinniPuh, про карандаш, я не вам)
А так-то понятно. В экономике это называется "менеджмент здравого смысла". В технике - опыт и наработки. Это понятно.
Не понятно только использует ли кто-то вообще ER-модель.
Пока за неё никто не высказался.

Сообщение от VinniPuh Если чего то не так придумал, то изменяю, ибо когда начинаешь вводить данные

Не знаю как в Access, а так пишут, что изменять таблицы чревато - лучше уничтожать и делать новую(???). А это вроде не оч удобно.

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

Сообщение от pincet лично мне проще ER на бумаге наваять. Помогает осмыслить. и не более

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

0

Сообщение от titan4ik ...что изменять таблицы чревато...

На стадии разработки менять и изменять структуру можно и наверное полезно для оптимизации.
Опробование Запросов и Процедур.
Про ввод данных имелось ввиду - тестовые данные, а не уже сама работа с БД.

Добавлено через 2 минуты
titan4ik, Под - ER диаграммой вы имеете ввиду всякие квадратики, ромбики и кружочки с треугольничками, соединенные черточками?

1

Сообщение от VinniPuh На стадии разработки менять и изменять структуру можно и наверное полезно для оптимизации.

То есть, использование ALTER TABLE чревато только потерей данных? Это хорошо, ежели так.

Добавлено через 27 секунд

Сообщение от VinniPuh titan4ik, Под - ER диаграммой вы имеете ввиду всякие квадратики, ромбики и кружочки с треугольничками, соединенные черточками?

Именно!!!
Мартин Грабер Гл 19. Проектирование базы данных.
стр 255 Построение ER-модели.
стр 260 Диаграммное представление ER-модели.

0

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

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

0

Сообщение от VinniPuh Тут наверное таки нужно иметь общий план и схему

Ну, вот, казалось бы, что ER-модель и может быть таким общим базисом. А практически выходит, что это не вполне так.
P.S. Фактически, ER-модель должна быть последней частью (итоговым содержанием) ТЗ. Это если по-хорошему.
Но в ходе работы она конечно должна "совершенствоваться")

0

titan4ik, Щас вот подумал и понял, что я просто зациклился на БД, а так к примеру у себя на работе, при проектировании принципиальных схем по автоматизации оборудования котельных, всегда сначала нарисую принципиальную электрическую схему схему с теми же реле, их контактами и прочими переключателями.
Правда не на листочке это делаю а на компе в экселе рисую, ибо можно изменить не черкая и не стирая.
типа к примеру так.
Если надо распечатать, очень даже удобно.
Возможно есть какие то и более продвинутые программы, но т. к. я старый пердун привык по старинке, мне так привычнее и тем более эксель есть на любом ПК.

Миниатюры

 

Вложения

Сх.КИПиА (ДЕ-1).rar (20.6 Кб, 1 просмотров)

0