Автор: Claudia Imhoff
Дата публикации оригинала: 2007-12-20
Источник: сайт B-Eye-Network

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

Очень трудно точно определить, какой период времени необходим для создания модели данных, но хотя теоретических пределов и не существует, есть определённые практические реалии.

В конце концов, разве компании не отличаются друг от друга? И не имеют ли некоторые компании гораздо больший уровень сложности, чем другие? Если это так, то зачем такие ограничения, как период времени, который необходим для создания модели данных?


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

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

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

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

Иметь в модели только детальные данные
Вторым способом является добавление в модель только детальных данных. Если разработчик принимается за моделирование производных данных, тогда процесс моделирования никогда не закончится, так как существует очень много производных данных, бизнес-правил и формул для производных данных, а также, в силу того, что эти формулы постоянно изменяются. Пока вы определите одну формулу, изменятся две другие.

Проектировать итеративно
Третьим способом является итеративное построение модели данных. Вы не определяете всё. Вы определяете и строите модель только для одного подмножества полной модели. Ключи для других частей еще не построенной модели внимательно определяются, но не более того. Атрибуты, структура, отношения вида «является типом» не проектируются для оставшихся частей модели, в противном случае модель данных будет строиться вечно.

Избегать каскадного мышления
Но, возможно, самым важным способом является избегание каскадного мышления. При каскадном мышлении (которое пришло к нам из SDLC – жизненного цикла разработки системы) считается, что все действия по построению необходимо завершить, прежде чем будет завершен текущий этап разработки. Это был один из основных принципов разработки оперативных систем. Но, при создании хранилища данных по многим причинам невозможно реализовать эту позицию. В среде разработки хранилищ данных некоторые из ваших систем будут на одном уровне моделирования или разработки, другие – на другом, и поэтому разные части проекта будут на разных уровнях моделирования и разработки. Это единственно разумный путь, который может применяться в среде разработки.

Проектировать для более общего толкования
В конце концов, данные должны быть абстрактными. Не должно быть отдельных компонентов модели данных для мужчин и отдельных – для женщин. Должен быть один компонент модели данных для человека, а в этом компоненте должен быть элемент данных, который определяет пол.

Продолжая вышесказанное, модель данных должна строиться для более общего толкования данных. Затем должны добавляться квалификаторы для того, чтобы позволить аналитикам выделять различные экземпляры данных. Например, если строится модель КЛИЕНТ, она должна толковаться в широком значении как КЛИЕНТ. Затем разработчик включает сюда информацию о различных типах КЛИЕНТА, такую как пол, возраст, адрес, когда была совершена первая покупка, когда была совершена последняя покупка и так далее.

Есть несколько хороших способов, чтобы проект разработки не стал вечным:

  • Определите размер проекта и не допускайте расползания проекта.
  • Концентрируйтесь на ключах и детальных данных. Избегайте производных данных.
  • Сознательно работайте на основе итерационной разработки. Не пытайтесь съесть слона целиком. Перед тем как проглотить его, разрежьте слона на маленькие кусочки.
  • Признайте, что в надлежащим образом созданной среде хранилища данных, в конкретный момент времени присутствуют части проекта в различном состоянии.
  • Признайте, что необходима абстракция данных, и что модель данных должна создаваться для более общего толкования данных, а также то, что в модель данных должны добавляться квалификаторы для того, чтобы аналитик мог выбрать необходимый для анализа тип данных.


Для удобства отслеживания новых публикаций рекомендуем подписаться на рассылку или на канал RSS.

Читайте также: