Какая первая модель или база данных? - PullRequest
6 голосов
/ 22 апреля 2011

Мой вопрос о том, что должно быть первым в разработке программного обеспечения: модель базы данных или модель предметной области?Или это понятие параллели?Спасибо.

Ответы [ 6 ]

8 голосов
/ 22 апреля 2011

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

Я бы не согласился с обоими. Первое, что вы должны сделать, это хорошо понять вашу проблему. Модель и схема будут исходить из этого.

Вы не можете избавиться от объектно-реляционного несоответствия, независимо от того, что вы делаете. Объекты основаны на экземплярах; SQL основан на множестве. У вас все еще будет проблема.

1 голос
/ 22 апреля 2011

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

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

Примечание: сбивает с толку ORM (моделирование ролей объектов, не связанное с ORM (реляционное сопоставление объектов).

1 голос
/ 22 апреля 2011

Ответ будет в значительной степени зависеть от типа приложения, которое вы разрабатываете, и языков / фреймворков, которые вы используете. Если вы будете писать много бизнес-логики в базе данных (например, Stored Procs, Views, триггеры), то имеет смысл сначала спроектировать базу данных. Если вы собираетесь использовать некоторые фреймворки, которые отображают модель предметной области в базу данных (и, возможно, генерируют схему, например, в спящем режиме), то вам сначала нужно написать классы предметной области.

1 голос
/ 22 апреля 2011

Разработка хорошей базы данных и объектных моделей и использование слоя объектно-реляционного сопоставления (ORM) для устранения несоответствия импеданса (это то, для чего они предназначены).

0 голосов
/ 22 апреля 2011

Пираты!Ниндзя!Курица!Яйцо!

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

В большинстве случаев проблемой является бизнес-сфера.Я рекомендую «управляемый доменом» дизайн Эванса по этой теме, но я бы посоветовал вам сначала захватить бизнес-домен, используя варианты использования или истории пользователей;превращение этих программ в программное обеспечение является ключевой задачей, и если вы и ваши коллеги лучше думаете в отношениях между сущностями, сделайте это;если вам больше нравятся иерархии классов и диаграммы ответственности, это тоже круто.

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

0 голосов
/ 22 апреля 2011

Эта кровная месть старше, чем пираты против ниндзя.:)

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

...