Что вы делаете перед началом диаграммы модели базы данных? Я имею в виду, как вы формируете требования, спецификации и т. Д. Случаи использования - это одно, а что-то еще? Какая-то лучшая практика или эмпирическое правило? Будучи учеником-самоучкой, я хочу посмотреть, как это происходит в руках профессионалов?Перед запуском модели базы данных
Удостоверьтесь, что у вас есть полный список требований от вашего клиента. Сделайте все возможное, чтобы полностью понять эти требования, это действительно поможет в вашем дизайне, если вы это сделаете. Если вы определяете требования, это может быть проще, поскольку у вас уже будет представление о том, что вам нужно делать. Полностью понять вашу цель - самая важная часть.
Если есть очевидная часть вашей базы данных, которая будет самой важной (например, приложение в системе онлайн-приложений), я обычно начинаю оттуда и обрабатываю одну часть за раз.
Лично мне нравится рисовать грубые картинки (что когда-либо имеет смысл для вас, не обязательно должно быть официальной ERD) того, что, по моему мнению, будет выглядеть в базе данных, и пересмотреть ее до более тонких уровней детализации.
Не полагайтесь только на письменные требования. Нет такой вещи, как полный список требований. Поговорите с заинтересованными сторонами, задайте вопросы и используйте результаты этих интервью, чтобы определить, какие атрибуты нужно моделировать, как они используются и идентифицировать бизнес-ключи. Затем для определения правильных типов данных и других аспектов обычно требуется анализ и исследование данных.
Возможно, вы сможете получить хороший первый разрез модели данных спереди, но не беспокойтесь, если не сможете. Моделирование данных обычно должно быть итеративным, гибким процессом, выполняемым в разумных размерах по мере развития проекта (хотя, безусловно, такие случаи, как дизайн хранилища данных, где гибкий подход может быть сложнее применить).
В зависимости от ваших клиентов может быть хорошей идеей иметь две модели данных и две диаграммы. Одна модель и диаграмма предназначены для анализа данных. Другая - для проектирования базы данных.
У меня были хорошие результаты, используя модель и диаграмму ER (Entity-Relationship) для анализа данных и модель и диаграмму RDM (реляционная модель данных) для отражения дизайна базы данных.
Диаграмма ER полезна для того, чтобы сообщать о требованиях, обнаруженных до сих пор клиентами, и убедиться, что они полны и правильны. Диаграммы ER легко понять, даже если у клиента нет фона в теории базы данных. Как отреагировали другие, это итеративный процесс, а не единственный водопад.
Модель и диаграмма RDM полезна для отражения логических решений по созданию базы данных, таких как решение нормализовать данные или сделать что-то еще. Его легко получить модель RDM из ER-модели, хотя вам нужно бросить некоторые проектные решения, которые намеренно опущены на диаграмме ER.
В свою очередь, его легко построить таблицу, создающую скрипт из диаграммы RDM. Вам нужно будет добавить некоторые физические функции, такие как индексы, чтобы получить хорошую производительность без разрыва ваших волос.
Неужели кто-то реально использует прецеденты-диаграммы и все это дерьмо в реальном мире o.0? thats только то, что сказал вам в школе ... – oezi
да, мне говорят в школе, которые определяют диаграммы вариантов использования и используют Prosa или что-то или UML и рисуют модель данных, прежде чем вы даже подумаете о физической реализации базы данных. –