Главная » Microsoft SQL Server, Базы данных » Правило полезности

0

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

Удобство модели

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

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

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

Рис. 1.2. Обобщенная схема, при которой в реляционную СУБД внедрены элементы объектно-ориентированной СУБД

Архитектура предприятия

Термин архитектура программного обеспечения имеет разное значение в зависимости от того, кто и в каком контексте его использует.

Когда компания Microsoft использует термин архитектура, она обычно подразумевает свою среду .NET Framework или проектирование систем, требующих привлечения нескольких продуктов Microsoft для решения задачи.

Термин архитектура продукта относится к компоновке различных компонентов в структуре программы.

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

Термин архитектура данных относится к организации и конфигурации хранилищ данных.

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

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

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

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

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

Вопрос управления несет в себе потенциальные проблемы. Если архитектор, который заложил принципы и стандарты, становится главой проекта, возникает конфликт интересов (законодатель, исполнитель, эксперт и судья). Он также ставит архитекторов программы в затруднительное положение, что может вызвать конфликт между организацией, разрабатывающей программный продукт, и заказчиком. Решение здесь одно: изменить механизм организации работы. Архитектор должен непосредственно передавать предлагаемые принципы разработчику программы. Если тот понимает выгоду, приносимую организации, и принимает предложенные принципы (возможно, за некоторыми исключениями) как собственные, то организация и разработчик их реализуют в реальном проекте.

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

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

Источник: Нильсен, Пол. Microsoft SQL Server 2005. Библия пользователя. : Пер. с англ. — М. : ООО “И.Д. Вильямс”, 2008. — 1232 с. : ил. — Парал. тит. англ.

По теме:

  • Комментарии