Информационные системы и технологии

Краткий конспект лекций по дисциплине «Информационные системы и технологии» Оглавление 1.Унифицированный язык визуального моделирования (UML) 6 2.Введение в основы OLAP 20 3. Клиентские и серверные OLAP-средства. технические аспекты многомерного хранения данных 31 4. Общие сведения о многомерном анализе данных при помощи службы SQL Server 2008 Analysis Services 38 5. Планирование и архитектура SQL Server Analysis Services 47 6. Разработка многомерных баз данных с использованием SSAS 55 Тема 1 Унифицированный язык визуального моделирования (UML) 1.1. Концептуальная модель UML Методологии разработки программного обеспечения.Unified Modelling Language Средства UML-моделирования UML – это средство описания процесса моделирования и разработки программного обеспечения. Предусмотрен ряд утилит, позволяющих довольно легко использовать UML. Ниже приводится далеко не полный список некоторых продуктов, поддерживающих UML: • Rational Rose (Rational Software, Windows 98/NT/2000/XP, Linux Red Hat 6.2, 7.0, Solaris 2.5.1, 2.6, 7, 8, HP-UX 10.20, 11.0, 11.i); • Microsoft Visual Studio .NET Enterprise Architect, Microsoft Visio (Microsoft, платформы: Windows 98/NT/2000/XP/Server 2003); • Describe Enterprise (Embarcadero technologies, платформы: Windows 98/NT/2000/XP); • семейство продуктов Together (Borland, платформы: Windows 98/NT/2000/XP, Linux, Solaris); • Bold for Delphi (Borland, платформы: Windows 8/NT/2000/XP); • MagicDraw (Magic, Inc., платформы: Windows 8/Me/NT/2000/XP, Solaris, OS/2, Linux, HP-UX, AIX, Mac OS); • QuickUML (ExcelSoftware, платплатформы: Windows 98/NT/2000/XP) UML – это язык визуализации. Написание моделей на UML преследует одну простую цель - облегчение процесса передачи информации о системе. За каждым символом UML стоит строго определенная семантика, что позволяет избегать ошибок интерпретации (ответы на вопросы типа «а что имел в виду разработчик Х, когда он описал иерархию классов Y…» и т.п. будут достаточно прозрачны). Элементы языка Основными элементами UML являются: • сущности (Thing), • отношения (Relationship), • диаграммы (Diagram). Сущности являются ключевыми абстракциями языка, отношения связывают сущности вместе, диаграммы группируют коллекции сущностей, которые представляют интерес. Сущности классы (Class) – это набор объектов, разделяющих одни и те же атрибуты, операции, отношения и семантику. Класс реализует один или несколько интерфейсов и изображается виде прямоугольника, включающего имя класса, имена атрибутов, операций, примечание; интерфейсы (Interface) – это набор операций, которые определяют сервис класса или компоненты. Интерфейс графически изображается в виде круга и, как правило, присоединяется к классу или к компоненту, который реализует данный интерфейс; кооперации (Collaboration) – определяют взаимодействие и служат для объединения ролей и других элементов, которые взаимодействуют вместе так, что получающееся в результате поведение объекта оказывается большим, чем просто сумма всех элементов. Изображается в виде эллипса с пунктирной границей; прецеденты (Use case) – описание набора последовательностей действий, которые выполняются системой и имеют значение для конкретного действующего лица (Actor). Прецеденты изображаются в виде эллипса и используются для структурирования поведенческих сущностей в модели; активные классы (Active class) – это классы, чьими экземплярами являются активные объекты, которые владеют процессом или потоком управления и могут инициировать управляющее воздействие. Стереотипами конкретного класса являются процесс (Process) и поток (Thread). Графически такой класс изображается как класс с жирной границей; компоненты (Component) – это физически заменяемые части системы, обеспечивающие реализацию ряда интерфейсов. Компонент – это физическое представление таких логических элементов, как классы, интерфейсы и кооперации. Предметная область компонентов относится к реализации. Изображаются компоненты в виде прямоугольника с ярлыками слева и, как правило, имеют только имя и примечание; узлы (Node) – физические объекты, которые существуют во время исполнения программы и представляют собой коммуникационный ресурс, обладающий, по крайней мере, памятью, а зачастую и процессором. На узлах могут находиться выполняемые объекты и компоненты. Изображаются узлы в виде куба, имеют имя и примечание. Отношения зависимость (Dependency) – это семантическое отношение между двумя сущностями, при котором изменение одной из них (независимой сущности) может отразиться на семантике другой (зависимой). ассоциация (Association) – структурное отношение, описывающее множество связей между объектами классификаторов, где связь (Link) – это соединение между объектами, которое описывает связи между их экземплярами. Ассоциации являются как бы клеем, который связывает систему воедино. Без ассоциаций мы имели бы просто некоторое количество классов, не способных взаимодействовать друг с другом. обобщение (Generalization) – это отношение специализации/обобщения, при котором объекты специализированного элемента (потомка – Child) можно подставить вместо объектов обобщенного элемента (родителя, предка – Parent). В случае обобщения классов прямой предок может именоваться суперклассом, а прямой потомок – подклассом; реализация (Realization) – отношение между спецификацией и ее программной реализацией; указание на то, что поведение наследуется без структуры. 1.2. Основные типы диаграмм UML Диаграмма классов (Class Diagram) Диаграмма классов по праву занимает одно из центральных мест не только в UML, но и в объектно-ориентированном подходе вообще. Данная диаграмма включает в себя большой набор понятий моделирования. Диаграмма классов описывает типы объектов системы и различные статические отношения, которые существуют между ними. Существуют два основных вида статических отношений, это ассоциации и подтипы. На диаграммах классов также изображаются атрибуты классов, операции классов и ограничения, которые накладываются на связи между объектами. Диаграмма прецедентов(Use Case Diagram) Use case (вариант использования) – это функциональное требование. Данный вид диаграмм в основном используется для описания функциональных требований к системе, для описания предметной области с целью лучшего понимания функционирования системы. Основные элементы диаграммы usecase: • собственно usecase (вариант использования), • актеры (представляют собой некоторую роль, которую играет пользователь по отношению к системе), • связи и отношения между актерами и use case. Этот вид диаграмм позволяет создать список операций, которые выполняет система. Часто этот вид диаграмм называют диаграммой функций, потому что на основе набора таких диаграмм создается список требований к системе и определяется множество выполняемых системой функций. Каждая такая диаграмма - это описание сценария поведения, которому следуют действующие лица (Actors). Диаграмма состояния (Statechart Diagram) Диаграммы состояний являются хорошо известным методом описания поведения систем. Они изображают все возможные состояния, в которых может находиться конкретный объект. Они изображают также изменения состояния объекта, которые происходят в результате влияния некоторых событий на этот объект. В большинстве объектно-ориентированных методов диаграммы состояний строятся для единственного класса, чтобы показать динамику поведения единственного объекта. Диаграмма развертывания (Deployment Diagram)  Диаграмма развертывания отражает физические взаимосвязи между программными и аппаратными компонентами разрабатываемой системы. Одним из существенных понятий данного вида диаграмм является понятие узел. Узел представляет собой некоторый тип вычислительного устройства, как правило, самостоятельную часть аппаратуры. Диаграмма последовательности (Sequence Diagram) Это диаграмма, на которой изображено упорядоченное во времени взаимодействие объектов. На ней изображаются участвующие во взаимодействии объекты и последовательность сообщений, которыми они обмениваются. Одно из основных назначений данной диаграммы – отобразить последовательность действий для части или целого варианта использования (use case). Как правило, по вертикали отображена временная ось, а по горизонтали указаны объекты, участвующие в данном процессе. 1.3. Виды диаграмм UML с точки зрения моделирования ИС Диаграммы используются для визуализации системы с разных точек зрения. Ни одна сложная система не может быть понята при одностороннем рассмотрении. UML определяет множество диаграмм, с тем чтобы вы могли сфокусировать внимание на различных аспектах системы, которые рассматриваются обособленно. Представление архитектуры ИС – это проекция организации и структуры системной модели, сфокусированная на одном из ее аспектов. С точки зрения моделирования ИС, диаграммы UML делятся на группы: • Статические (структурные) – описывают статические части системы (структуру) • Поведенческие - описывают динамические части системы (поведение) 1. Структурные диаграммы UML Структурные диаграммы UML преимущественно включают в себя основные группы сущностей, которые вы используете при моделировании системы Диаграмма классов (class diagram) показывает набор классов, интерфейсов и коопераций, а также их связи. Иллюстрирует статическое представление дизайна системы. Элементы диаграммы -классы (1) (включая многочисленные частные случаи классов: интерфейсы, примитивные типы, классы-ассоциации и многие другие), между которыми устанавливаются следующие основные типы отношений: -между классами (2) (с множеством дополнительных подробностей) -обобщение между классами (3) -зависимости (различных типов) между классами (4) и между классами и интерфейсами. Диаграмма компонентов (component diagram) показывает взаимосвязи между модулями (логическими или физическими), из которых состоит моделируемая система. Элементы диаграммы: Сущности: • компоненты (1) • интерфейсы (2), посредством которых указывается взаимосвязь между компонентами. Отношения: • реализации между компонентами и интерфейсами (компонент реализует интерфейс); • зависимости между компонентами и интерфейсами (компонент использует интерфейс) (3). Диаграмма внутренней (составной) структуры (composite structure diagram) используется для более подробного представления структурных классификаторов, прежде всего классов и компонентов. Элементы диаграммы Структурный классификатор изображается в виде прямоугольника (1), в верхней части которого находится имя классификатора (2). Внутри находятся части (parts) (3). Частей может быть несколько. Части могут взаимодействовать друг с другом. Это обозначается с помощью соединителей (connectors) (4) различных видов. Место на внешней границе части, к которому присоединяется соединитель, называется портом (port) (5). Порты располагаются также на внешней границе структурного классификатора (6). Диаграмма объектов (object diagram) показывает набор объектов и их связи. Является экземпляром (частью) диаграммы классов. Вспомогательные диаграммы - используется для описания структур данных, статических снимков экземпляров сущностей. Можно использовать для прототипных ситуаций. Элементы диаграммы: Объекты (1) (экземпляры классов), между которыми указываются конкретные связи (2) Диаграмма размещения (deployment diagram) показывает набор узлов и их связей, как они физически размещены на вычислительных ресурсах. Описывает статическое представление архитектуры. Элементы диаграммы: -артефакт (1), который является реализацией компонента (2) -узел (3) (может быть как классификатор, описывающий тип узла, так и конкретный экземпляр) -отношение ассоциации между узлами (4), показывающее, что узлы физически связаны во время выполнения Для того чтобы показать, что одна сущность является частью другой, применяется либо отношение зависимости «deploy» (5), либо фигура одной сущности помещается внутрь фигуры другой сущности (6) Диаграмма артефактов показывает набор артефактов и их связей с другими артефактами, а также классами, которые они реализуют. Используется для представления физической реализации элементов системы. UML рассматривает диаграммы артефактов как разновидность диаграмм размещения. 2. Поведенческие диаграммы UML Поведенческие диаграммы UML используются для визуализации, специфицирования, конструирования и документирования динамических аспектов системы – в основном потоки сообщений во времени и физическое перемещение компонентов по сети. Способы моделирования: 1. Диаграмма вариантов использования организует поведение системы 2. Диаграмма последовательности сфокусирована на временной последовательности сообщений 3. Диаграмма коммуникации сфокусирована на структурной организации объектов, отправляющих и принимающих сообщения 4. Диаграмма состояний сфокусирована на изменении состояния системы в ответ на события 5. Диаграмма деятельности сфокусирована на потоке управления от деятельности к деятельности Диаграмма вариантов использования (use case diagram) показывает набор вариантов использования и действующих лиц, а также их связи. Наиболее общее представление функционального назначения системы. Отвечает на вопрос - что делает система во внешнем мире? Диаграмма прецендентов - вариантов использования (use case diagram) Элементы диаграммы: Два типа основных сущностей: варианты использования (1) и действующие лица (2), между которыми устанавливаются следующие основные типы отношений: - ассоциация между действующим лицом и вариантом использования (3); - обобщение между действующими лицами (4); - обобщение между вариантами использования (5); - зависимости между вариантами использования (6). Диаграмма взаимодействия (interaction diagram) – это общее название диаграмм последовательности и коммуникации. В их основе одна и та же модель, хотя на практике они включают разные сущности. Еще один вид диаграмм взаимодействия – диаграммы синхронизации (timing diagram). В ООП самым существенным во время выполнения является пересылка сообщений между взаимодействующими объектами. Диаграмма последовательности (sequence diagram) отображает последовательность посылок сообщений. Фактически - запись протокола конкретного сеанса работы системы Основной тип сущностей — экземпляры взаимодействующих классификаторов (1) (в основном классов, компонентов и действующих лиц), и один тип отношений — связи (2), по которым происходит обмен сообщениями (3). Пунктирная линия, выходящая из объекта, называется линией жизни (lifeline) (4). Это не обозначение отношения в модели, а графический комментарий, призванный направить взгляд читателя диаграммы в правильном направлении. Фигуры в виде узких полосок, наложенных на линию жизни - графический комментарий, показывающий отрезки времени, в течении которых объект владеет потоком управления (execution occurrence) (5) или другими словами имеет место активация (activation) объекта. Составные шаги взаимодействия (combined fragment) (6) позволяют на диаграмме последовательности, отражать и алгоритмические аспекты протокола взаимодействия. Диаграмма коммуникации (communication diagram) – это диаграмма взаимодействия, показывающая структурную организацию объектов, отправляющих и принимающих сообщения. Способ, семантически эквивалентный диаграмме последовательности. Фактически, это такое же описание последовательности обмена сообщениями взаимодействующих экземпляров классификаторов, только выраженное другими графическими средствами. Акцент делается не на времени, а на структуре связей между конкретными экземплярами Основной тип сущностей — экземпляры взаимодействующих классификаторов (1) (в основном классов, компонентов и действующих лиц), и один тип отношений — связи (2), по которым происходит обмен сообщениями (3). Диаграмма синхронизации (timing diagram) представляет собой особую форму диаграммы последовательности, на которой особое внимание уделяется -изменению состояний (1) различных экземпляров классификаторов -и их временной синхронизации (2) Обзорная диаграмма взаимодействия (interaction overview diagram) является разновидностью диаграммы деятельности с расширенным синтаксисом: в качестве элементов обзорной диаграммы взаимодействия могут выступать ссылки на взаимодействия (interaction use), определяемые диаграммами последовательности Диаграмма автомата (state machine diagram) или диаграмма состояний— это один из способов детального описания поведения в UML. Отображают упорядоченное по событиям поведение объекта. Представляют собой граф состояний и переходов конечного автомата Абстрактный автомат (в теории алгоритмов) — математическая абстракция, модель , имеющего один вход, один выход и в каждый момент времени находящегося в одном состоянии из множества возможных Элементы диаграммы: Один тип сущностей — состояния (1), и один тип отношений — переходы (2) Для сущностей и отношений определено множество разновидностей, специальных случаев и дополнительных обозначений Диаграмма деятельности (activity diagram) — показывает последовательный поток действий (управления). Визуально напоминает блок-схему алгоритма, однако дополнена обозначениями, согласованными с объектно-ориентированным подходом Элементы диаграммы: Основной тип сущностей — действие (1), и один тип отношений — переходы (2) (передачи управления). Также используются такие конструкции как развилки, слияния, соединения, ветвления (3) Диаграмма пакетов (package diagram) — единственное средство, позволяющее управлять сложностью самой модели. Основные элементы нотации — пакеты (1) и зависимости с различными стереотипами (2), 1.4. Представления архитектуры ИС с точки зрения моделирования UML Ситуация в разработке Визуализация, специфицирование, конструирование и документирование программных систем требуют их представления с различных точек зрения. Разные заинтересованные лица – конечные пользователи, аналитики, разработчики, системные интеграторы, тестировщики, технические писатели и менеджеры проекта – имеют различное представление о проекте, и каждый из них видит информационную систему по-разному в разные моменты жизненного цикла проекта. Системная архитектура является продуктом, который может быть использован для управления всеми этими разнообразными точками зрения и тем самым управляет итеративным и пошаговым процессом разработки информационной системы на протяжении всего ее жизненного цикла. Архитектура – это набор существенных решений относительно: - организации программной системы - выбора структурных элементов, составляющих систему, и их интерфейсов - поведения этих элементов, определенного в их кооперациях - объединения этих структурных и поведенческих элементов в более крупные подсистемы - архитектурного стиля, определяющего организацию системы: статические и динамические элементы и их интерфейсы, кооперацию и композицию Архитектура информационной системы с точки зрения UML Архитектура ИС может быть наилучшим описана с помощью пяти взаимосвязанных представлений. Каждое представление – проекция организации и структуры системы, сосредоточенная на определенном ее аспекте Представление вариантов использования (Use Case View) системы охватывает варианты использования, описывающие поведение системы с точки зрения конечных пользователей, аналитиков и тестировщиков. Представление специфицирует не истинную организацию программной системы, а лишь некие движущие силы, формирующие системную архитектуру. • статические аспекты представления: диаграммы вариантов использования, • динамические аспекты: диаграммы взаимодействий, состояний и деятельности Представление системы с точки зрения проектирования (дизайна, design view) охватывает классы, интерфейсы и кооперации, формирующие словарь проблемы и ее решение. Предназначено для описания словаря предметной области, то есть, в парадигме объектно-ориентированного программирования, классов, а также таких вспомогательных сущностей как, например, интерфейсы или кооперации Поддерживает функциональные требования к системе, то есть сервис, который она должна предоставлять конечным пользователям • Статические аспекты: диаграммы классов и объектов • Динамические аспекты: диаграммы взаимодействий, состояний и деятельности Представление взаимодействия (вид с т.з. процессов, Process View ) системы показывает поток управления, проходящий через разные ее части, включая возможные механизмы параллелизма и синхронизации. Это представление касается производительности, масштабируемости и пропускной способности системы • Структурные аспекты: диаграммы классов и объектов (для классов/объектов, которые передают сообщения) • Поведенческие аспекты ‒ диаграммы взаимодействия, состояний и деятельности Представление реализации (компонентов) (Component view) - описание системы на уровне артефактов (компонентов, файлов и т.д.), используемых для сборки, выпуска, конфигурации программного продукта. Представление относится к управлению конфигурацией версий системы, состоящей из файлов и компонентов, которые могут быть собраны различными способами для формирования работающей системы. • Структурные аспекты: диаграммы компонентов, артефактов • Поведенческие аспекты: диаграммы взаимодействия, состояний и деятельности Представление развертывания (deployment view) отражает топологию связей аппаратных средств и размещения на них компонентов. Это представление в основном связано с поставкой, распределением и установкой частей, составляющих физическую систему. • Структурные аспекты: диаграммы размещения • Поведенческие аспекты: диаграммы взаимодействия, состояний и деятельности Процесс моделирования (независимо от назначения модели) является не линейным последовательным, а итеративным и параллельным, примерно таким, как показано ниже: Представление использования -  что делает система? Указать: • Действующие лица • Границы системы • Функциональные требования • Ответственность компонентов Представление структуры - из чего состоит система? Выделение структурных элементов ‒ составных частей системы ‒ и описания взаимосвязей между ними. Принципиальным является чисто статический характер описания, то есть отсутствие понятия времени в любой форме, в частности, в форме последовательности событий и/или действий. Указать: • Предметная область • Архитектура системы • Структура хранения • Детали реализации Основные: • диаграммы классов (class diagram)  Дополнительно: • диаграммы компонентов (component diagram) • диаграммы размещения deployment diagram • диаграммы внутренней структуры (composite structure diagram) • диаграммами объектов (object diagram) Представление поведения - как работает система ? Определяющим признаком для отнесения элементов модели к представлению поведения является явное использование понятия времени, в частности, в форме описания последовательности событий / действий, то есть в форме алгоритма.  Указать: • Бизнес-процессы • Пользовательский интерфейс • Алгоритмы обработки • Жизненные циклы Основные диаграммы: • диаграмма автомата (state machine diagram) • диаграмма деятельности (activity diagram) • обзорная диаграммой взаимодействия (interaction overview diagram) • диаграмма коммуникации (communication diagram) • диаграмма последовательности (sequence diagram ) • диаграмма синхронизации (timing diagram) Тема 2 Введение в основы OLAP 2.1. Хранилища данных. Понятие и архитектура системы поддержки принятия решений К настоящему времени во многих организациях накоплены значительные объемы данных, на основе которых имеется возможность решения разнообразных аналитических и управленческих задач. Проблемы хранения и обработки аналитической информации становятся все более актуальными и привлекают внимание специалистов и фирм, работающих в области информационных технологий, что привело к формированию полноценного рынка технологий бизнес-анализа. В идеале работа аналитиков и руководителей различных уровней должна быть организована так, чтобы они могли иметь доступ ко всей интересующей их информации и пользоваться удобными и простыми средствами представления и работы с этой информацией. Именно на достижение этих целей и направлены информационные технологии, объединяющиеся под общим названием хранилищ данных и бизнес-анализа. В соответствии с определением Gartner, бизнес-анализ (BI, Business Intelligence) - это категория приложений и технологий для сбора, хранения, анализа и публикации данных, позволяющая корпоративным пользователям принимать лучшие решения. В русскоязычной терминологии подобные системы называются также системами поддержки принятия решений (СППР). Архитектура СППР Сбор и хранение информации, а также решение задач информационно-поискового запроса эффективно реализуются средствами систем управления базами данных (СУБД). В OLTP (Online Transaction Processing)-подсистемах реализуется транзакционная обработка данных. Непосредственно OLTP-системы не подходят для полноценного анализа информации в силу противоречивости требований, предъявляемых к OLTP-системам и СППР. Для предоставления необходимой для принятия решений информации обычно приходится собирать данные из нескольких транзакционных баз данных различной структуры и содержания. Основная проблема при этом состоит в несогласованности и противоречивости этих баз-источников, отсутствии единого логического взгляда на корпоративные данные. Поэтому для объединения в одной системе OLTP и СППР для реализации подсистемы хранения используются концепция хранилищ данных (ХД). В основе концепции ХД лежит идея разделения данных, используемых для оперативной обработки и для решения задач анализа, что позволяет оптимизировать структуры хранения. ХД позволяет интегрировать ранее разъединенные детализированные данные, содержащиеся в исторических архивах, накапливаемых в традиционных OLTP-системах, поступающих из внешних источников, в единую базу данных, осуществляя их предварительное согласование и, возможно, агрегацию. Понятие хранилища данных Технология ХД предназначена для хранения и анализа больших объемов данных с целью дальнейшего обнаружения в них скрытых закономерностей и, наряду с технологией Data Mining, входит в понятие "предсказательная аналитика". Data Mining, в свою очередь, изучает процесс нахождения новых, действительных и потенциально полезных знаний в базах данных. ХД - предметно-ориентированный, интегрированный, редко меняющийся, поддерживающий хронологию набор данных, организованный для целей поддержки принятия решений. Предметная ориентация означает, что ХД интегрируют информацию, отражающую различные точки зрения на предметную область. Интеграция предполагает, что данные, хранящиеся в ХД, приводятся к единому формату. Поддержка хронологии означает, что все данные в ХД соответствуют последовательным интервалам времени. Кроме возможности работать с единым источником информации, руководители и аналитики должны иметь удобные средства визуализации данных, агрегирования, поиска тенденций, прогнозирования. Несмотря на многообразие аналитической деятельности можно выделить типовые технологии анализа данных, каждой из которых соответствует определенный набор инструментальных средств. Вместе с хранилищем данных эти средства обеспечивают полное решение для автоматизации аналитической деятельности и создания корпоративной информационно-аналитической системы. Физические и виртуальные хранилища данных При загрузке данных из OLTP-системы в ХД происходит дублирование данных. Однако в ходе этой загрузки данные фильтруются, поскольку не все из них имеют значение для проведения процедур анализа. В ХД хранится обобщенная информация, которая в OLTP-системе отсутствует. Структура СППР с физическим ХД Избыточность информации можно свести к нулю, используя виртуальное ХД. В такой системе данные из OLTP-системы не копируются в единое хранилище. Они извлекаются, преобразуются и интегрируются непосредственно при выполнении аналитических запросов в режиме реального времени. Фактически такие запросы напрямую передаются к OLTP-системе. Достоинства виртуального ХД: • минимизация объема хранимых данных; • работа с текущими, актуальными данными. Недостатки виртуального ХД: • более высокое, по сравнению с физическим ХД время обработки запросов; • необходимость постоянной доступности всех OLTP-источников; • снижение быстродействия OLTP-систем; • OLTP-системы не ориентированы на хранение данных за длительный период времени, по мере необходимости данные выгружаются в архивные, поэтому не всегда имеется физическая возможность получения полного набора данных в ХД. Проблематика построения хранилищ данных Основная проблематика при создании ХД заключается в следующем: 1. интеграция разнородных данных. Данные в ХД поступают из разнородных OLTP-систем, которые физически могут быть расположены на различных узлах сети. При проектировании и разработке ХД необходимо решать задачу интеграции различных программных платформ хранения; 2. эффективное хранение и обработка больших объемов данных. Построение ХД предполагает накопление данных за значительные периоды времени, что ведет к постоянному росту объемов дисковой памяти, а также росту объема оперативной памяти, требующейся для обработки этих данных. При возрастании объемов данных этот рост нелинеен; 3. организация многоуровневых справочников метаданных. Конечным пользователям СППР необходимы метаданные, описывающие структуру хранящихся в ХД данных, а также инструменты их визуализации; 4. обеспечение информационной безопасности ХД. Сводная информация о деятельности компании, как правило, относится к коммерческой тайне и подлежит защите; кроме того, в ХД могут содержаться персональные данные клиентов и сотрудников, которые также необходимо защищать. Для выполнения этой функции должна быть разработана политика безопасности ХД и связанной с ним инфраструктуры, а также реализованы предусмотренные в политике организационные и программно-технические мероприятия по защите информации. Витрины данных Сокращение затрат на проектирование и разработку ХД может быть достигнуто путем создания витрин данных (ВД). ВД - это упрощенный вариант ХД, содержащий только тематически объединенные данные. Структура СППР с самостоятельными ВД ВД содержит данные, ориентированные на конкретного пользователя, существенно меньше по объему, и для ее реализации требуется меньше затрат. ВД могут строиться как самостоятельно, так и вместе с ХД. ВД внедряются гораздо быстрее и быстрее виден эффект от их использования. Недостатками ВД является многократное хранение одних и тех же данных в различных ВД и отсутствие консолидированности на уровне предметной области. Обычно информация попадает в ВД из ХД, в этом случае ВД называются зависимыми. Возможна также ситуация, когда источником информации для пополнения ВД служат непосредственно OLTP-системы. Такие ВД, получившие название независимых, как правило, рассматриваются как временное решение, позволяющее достаточно быстро и с небольшими затратами решить наиболее важные задачи, оценить преимущества нового подхода, сформулировать некоторые рекомендации для более масштабного проекта разработки общего ХД. Возможно также совмещение ХД и ВД в рамках одной СППР. ХД в этом случае представляет собой единый источник данных для всей предметной области, а ВД являются подмножествами данных из хранилища, организованными для представления информации по тематическим разделам данной области. В том случае, если пользователю, для которого создавалась ВД, содержащихся в ней данных недостаточно, то он может обратиться к ХД. Структура СППР с ХД и ВД Достоинствами такого решения являются простота создания и наполнения ВД, поскольку наполнение происходит из единого стандартизированного источника очищенных данных - из ХД, простота расширения за счет добавления новых ВД, а также снижение нагрузки на основное ХД. Недостатки заключаются в избыточности, так как данные хранятся и в ХД, и в ВД, а также дополнительные затраты на разработку СППР с ХД и ВД. 2.2. Понятие и модель данных OLAP OLAP (Online Analytical Processing) - технология оперативной аналитической обработки данных, использующая методы и средства для сбора, хранения и анализа многомерных данных в целях поддержки процессов принятия решений. Основное назначение OLAP-систем - поддержка аналитической деятельности, произвольных запросов пользователей - аналитиков. Цель OLAP-анализа - проверка возникающих гипотез. Подсистема анализа может быть построена на основе: 1. подсистемы информационно-поискового анализа на базе реляционных СУБД и статических запросов с использованием языка SQL; 2. подсистемы оперативного анализа. Для реализации таких подсистем применяется технология оперативной аналитической обработки данных OLAP, использующая концепцию многомерного представления данных; 3. подсистемы интеллектуального анализа, реализующие методы и алгоритмы Data Mining. Структура OLAP-куба В процессе анализа данных часто возникает необходимость построения зависимостей между различными параметрами, число которых может быть значительным. Под измерением будем понимать последовательность значений одного из анализируемых параметров. Например, для параметра "время" это - последовательность дней, месяцев, кварталов, лет. Возможность анализа зависимостей между различными параметрами предполагает возможность представления данных в виде многомерной модели - гиперкуба или OLAP-куба. Гиперкуб Оси куба представляют собой измерения, по которым откладывают параметры, относящиеся к анализируемой предметной области, например, названия товаров и названия месяцев года. На пересечении осей измерений располагаются данные, количественно характеризующие анализируемые факты - меры, например, объемы продаж, выраженные в единицах продукции. В простейшем случае двумерного куба получается таблица, показывающая значения уровней продаж по товарам и месяцам. Дальнейшее усложнение модели данных возможно по нескольким направлениям: 1. увеличение числа измерений данные о продажах не только по месяцам и товарам, но и по регионам. В этом случае куб становится трехмерным; 2. усложнение содержимого ячейки например, нас может интересовать не только уровень продаж, но и чистая прибыль или остаток на складе. В этом случае в ячейке будет несколько значений; 3. введение иерархии в пределах одного измерения общее понятие "время" связано с иерархией значений: год состоит из кварталов, квартал из месяцев и т.д. Иерархия измерений OLAP-кубов Каждое из измерений OLAP-куба может быть представлено в виде иерархической структуры. Например, измерение "Регион" может иметь следующие уровни иерархии: "страна - федеральный округ - область - город - район". Некоторые измерения могут иметь несколько уровней иерархического представления, например измерение "время" - представление "год - квартал - месяц - день" и представление "год - неделя - день". Точно так же в рамках измерения "География" можно ввести уровни "Страна", "Регион", "Область" и "Город". Операции, выполняемые над гиперкубом Над гиперкубом могут выполняться следующие операции: 1. Срез - формируется подмножество многомерного массива данных, соответствующее единственному значению одного или нескольких элементов измерений, не входящих в это подмножество. 2. Вращение- изменение расположения измерений, представленных в отчете или на отображаемой странице. Например, операция вращения может заключаться в перестановке местами строк и столбцов таблицы. Кроме того, вращением куба данных является перемещение внетабличных измерений на место измерений, представленных на отображаемой странице, и наоборот. Консолидация и детализация - операции, которые определяют переход вверх по направлению от детального представления данных к агрегированному и наоборот, соответственно. Направление детализации (обобщения) может быть задано как по иерархии отдельных измерений, так и согласно прочим отношениям, установленным в рамках измерений или между измерениями. Консолидация Детализация Таблица фактов Таблица фактов - является основной таблицей хранилища данных. Как правило, она содержит сведения об объектах или событиях, совокупность которых будет в дальнейшем анализироваться. Обычно говорят о четырех наиболее часто встречающихся типах фактов. К ним относятся: 1. факты, связанные с транзакциями (Transaction facts). Они основаны на отдельных событиях (типичными примерами которых являются телефонный звонок или снятие денег со счета с помощью банкомата); 2. факты, связанные с "моментальными снимками" (Snapshot facts). Основаны на состоянии объекта (например, банковского счета) в определенные моменты времени, например на конец дня или месяца. Типичными примерами таких фактов являются объем продаж за день или дневная выручка; 3. факты, связанные с элементами документа (Line-item facts). Основаны на том или ином документе (например, счете за товар или услуги) и содержат подробную информацию об элементах этого документа (например, количестве, цене, проценте скидки); 4. факты, связанные с событиями или состоянием объекта (Event or state facts). Представляют возникновение события без подробностей о нем (например, просто факт продажи или факт отсутствия таковой без иных подробностей). Таблица фактов, как правило, содержит уникальный составной ключ, объединяющий первичные ключи таблиц измерений. Чаще всего это целочисленные значения либо значения типа "дата/время" - ведь таблица фактов может содержать сотни тысяч или даже миллионы записей, и хранить в ней повторяющиеся текстовые описания, как правило, невыгодно - лучше поместить их в меньшие по объему таблицы измерений. При этом как ключевые, так и некоторые неключевые поля должны соответствовать будущим измерениям OLAP-куба. Помимо этого таблица фактов содержит одно или несколько числовых полей, на основании которых в дальнейшем будут получены агрегатные данные. Для многомерного анализа пригодны таблицы фактов, содержащие как можно более подробные данные (то есть соответствующие членам нижних уровней иерархии соответствующих измерений). В данном случае предпочтительнее взять за основу факты продажи товаров отдельным заказчикам, а не суммы продаж для разных стран - последние все равно будут вычислены OLAP-средством. В таблице фактов нет никаких сведений о том, как группировать записи при вычислении агрегатных данных. Например, в ней есть идентификаторы продуктов или клиентов, но отсутствует информация о том, к какой категории относится данный продукт или в каком городе находится данный клиент. Эти сведения, в дальнейшем используемые для построения иерархий в измерениях куба, содержатся в таблицах измерений. Пример фрагмента схемы данных хранилища данных AdventureWorks. В приведенной схеме данных таблица FactInternetSales является таблицей фактов и содержит сведения о продажах через Интернет в разрезе товаров, дат, валют, рекламы, клиентов и территории. Таблицы измерений Таблицы измерений содержат неизменяемые либо редко изменяемые данные. В подавляющем большинстве случаев эти данные представляют собой по одной записи для каждого члена нижнего уровня иерархии в измерении. Таблицы измерений также содержат как минимум одно описательное поле (обычно с именем члена измерения) и, как правило, целочисленное ключевое поле (обычно это суррогатный ключ) для однозначной идентификации члена измерения. Если будущее измерение, основанное на данной таблице измерений, содержит иерархию, то таблица измерений также может содержать поля, указывающие на "родителя" данного члена в этой иерархии. Нередко (но не всегда) таблица измерений может содержать и поля, указывающие на "прародителей", и иных "предков" в данной иерархии (это обычно характерно для сбалансированных иерархий), а также дополнительные атрибуты членов измерений, содержавшиеся в исходной оперативной базе данных (например, адреса и телефоны клиентов). Каждая таблица измерений должна находиться в отношении "один ко многим" с таблицей фактов. Отметим, что скорость роста таблиц измерений должна быть незначительной по сравнению со скоростью роста таблицы фактов; например, добавление новой записи в таблицу измерений, характеризующую товары, производится только при появлении нового товара, не продававшегося ранее. 2.3. Архитектура OLAP-систем Полномасштабная OLAP-система должна выполнять сложные и разнообразные функции, включающие сбор данных из различных источников, их согласование, преобразование и загрузку в хранилище, хранение аналитической информации, регламентную отчетность, поддержку произвольных запросов, многомерный анализ и др. В настоящее время существуют фактические стандарты построения OLAP-систем, основанных на концепции ХД. Эти стандарты опираются на современные исследования и общемировую практику создания хранилищ данных и аналитических систем. В общем виде архитектура корпоративной OLAP-системы описывается схемой с тремя выделенными слоями. • извлечение, преобразование и загрузка данных; • хранение данных; • анализ данных. Данные поступают из различных внутренних OLTP-систем, от подчиненных структур, от внешних организаций в соответствии с установленным регламентом, формами и макетами отчетности. Вся эта информация проверяется, согласуется, преобразуется и помещается в хранилище и витрины данных. После этого пользователи с помощью специализированных инструментальных средств получают необходимую им информацию для построения различных табличных и графических представлений, прогнозирования, моделирования и выполнения других аналитических задач. Слой извлечения, преобразования и загрузки данных С организационной точки зрения, данный слой включает подразделения и структуры организации всех уровней, поддерживающие базы данных оперативного доступа. Он представляет собой низовой уровень генерации информации, уровень внутренних и внешних информационных источников, вырабатывающих "сырую" информацию. Эта информация является рабочей для повседневной деятельности различных подразделений, которые ее вырабатывают и используют. С системно-технической точки зрения данный слой представлен ЛВС всех подразделений всех уровней, к которым подключены специализированные технические комплексы, хранящие информацию, чаще всего реализованные в виде реляционных СУБД. Из источников данных информация перемещается на основе некоторого регламента в централизованное хранилище. Как правило, необходимые для хранилища данные не хранятся в окончательном виде ни в одной из OLTP-систем. Эти данные обычно можно получить из исходных баз данных путем специальных преобразований, вычислений и агрегирования. Кроме того, несмотря на различную функциональную направленность, исходные транзакционные системы часто "пересекаются" по данным, т.е. их локальные базы данных содержат однотипную по смыслу информацию. Это, прежде всего, касается нормативно-справочной информации, которая используется в том или ином виде в любой OLTP-системе. При этом существенно, что одинаковые по смыслу данные обычно имеют в разных системах различный формат, вид представления, идентификацию, единицы измерения и т.п. Перед загрузкой в хранилище вся эта информация должна быть согласована, чтобы обеспечить целостность и непротиворечивость аналитических данных. Согласование данных необходимо и при загрузке данных из одного источника. Дело в том, что в хранилище хранятся исторические данные, т.е. данные за достаточно большой промежуток времени. В оперативной системе данные хранятся в целостном виде за ограниченный промежуток, после чего они отправляются в архив. При изменениях в структуре или собственно данных архивы не подвергаются никакой дополнительной обработке, а хранятся в исходном виде. Следовательно, при необходимости иметь данные за достаточно большой период времени необходимо согласовывать архивную информацию с текущей. Таким образом, загрузка данных из источников в хранилище осуществляется специальными процедурами, позволяющими: 1. извлекать данные из различных баз данных, текстовых файлов; 2. выполнять различные типы согласования и очистки данных; 3. преобразовывать данные при перемещении их от источников к хранилищу; 4. загружать согласованные и "очищенные" данные в структуры хранилища. Слой хранения данных Слой хранения данных предназначен непосредственно для хранения значимой, проверенной, согласованной, непротиворечивой и хронологически целостной информации, которую с достаточно высокой степенью уверенности можно считать достоверной. Собственно ХД не ориентировано на решение какой-либо определенной функциональной аналитической задачи. Цель ХД - обеспечить целостность и поддерживать хронологию всевозможных корпоративных данных, и с этой точки зрения оно нейтрально по отношению к приложениям. В связи с этим в большинстве случаев для выполнения определенного комплекса функционально замкнутых аналитических задач рационально создавать витрины данных, в основе которых может быть как многомерная, так и реляционная модель данных. По существу витрина представляет собой относительно небольшое, но что самое важное, функционально-ориентированное ХД, в котором информация хранится специальным образом, оптимизированным с точки зрения решения конкретных аналитических задач некоторого подразделения или группы аналитиков. ХД чаще всего реализуется в виде реляционной БД, работающей под управлением достаточно мощной реляционной СУБД. Такая СУБД должна поддерживать эффективную работу с терабайтными объемами информации, иметь развитые средства ограничения доступа, обеспечивать повышенный уровень надежности и безопасности, соответствовать необходимым требованиям по восстановлению и архивации. Слой анализа данных Для организации доступа аналитиков к данным ХД и ВД используются специализированные рабочие места, поддерживающие необходимые технологии как оперативного, так и долговременного анализа. Результаты работы аналитиков оформляются в виде отчетов, графиков, рекомендаций и сохраняются как на локальном компьютере, так и в общедоступном узле локальной сети. Аналитическая деятельность в рамках корпорации достаточно разнообразна и определяется характером решаемых задач, организационными особенностями компании, уровнем и степенью подготовленности аналитиков. В связи с этим современный подход к инструментальным средствам анализа не ограничивается использованием какой-то одной технологи. В настоящее время принято различать следующие основные виды аналитической деятельности: 1. стандартная отчетность; 2. нерегламентированные запросы; 3. многомерный анализ (OLAP); 4. извлечение знаний (data mining). Каждая из этих технологий имеет свои особенности, определенный набор типовых задач и должна поддерживаться специализированной инструментальной средой. Тема 3 Клиентские и серверные OLAP-средства. технические аспекты многомерного хранения данных 3.1. Клиентские OLAP-средства Клиентские OLAP-средства представляют собой приложения, осуществляющие вычисление агрегатных данных (сумм, средних величин, максимальных или минимальных значений) и их отображение, при этом сами агрегатные данные содержатся в кэше внутри адресного пространства такого OLAP-средства. Если исходные данные содержатся в настольной СУБД, вычисление агрегатных данных производится самим OLAP-средством. Если же источник исходных данных - серверная СУБД, многие из клиентских OLAP-средств посылают на сервер SQL-запросы, содержащие оператор GROUP BY, и в результате получают агрегатные данные, вычисленные на сервере. Как правило, OLAP-функциональность реализована в средствах статистической обработки данных (из продуктов этого класса на российском рынке широко распространены продукты компаний StatSoft и SPSS) и в некоторых электронных таблицах. В частности, средствами многомерного анализа обладает Microsoft Excel. С помощью этого продукта можно создать и сохранить в виде файла небольшой локальный многомерный OLAP-куб и отобразить его двух- или трехмерные сечения. Надстройки к пакету приложений Microsoft Office для извлечения и обработки данных представляют собой ряд функций, обеспечивающих доступ к возможностям извлечения и обработки данных из приложений Microsoft Office, и тем самым позволяющих осуществлять прогностический анализ на локальном компьютере. Благодаря тому, что встроенные в службы платформы Microsoft SQL Server алгоритмы извлечения и обработки данных доступны из среды приложений Microsoft Office, бизнес-пользователи могут легко извлекать ценную информацию из сложных наборов данных всего несколькими щелчками мыши. Надстройки к пакету приложений Office для извлечения и обработки данных дают конечным пользователям возможность выполнять анализ непосредственно в приложениях Microsoft Excel и Microsoft Visio. В состав Microsoft Office 2007 входят три отдельных OLAP-компонента: 1. клиент извлечения и обработки данных для Excel позволяет создавать проекты извлечения и обработки данных на базе служб SSAS и управлять ими из Excel 2007; 2. средства анализа таблиц для приложения Excel позволяют использовать встроенные в службы SSAS функции извлечения и обработки информации для анализа данных, хранящихся в таблицах Excel; 3. шаблоны извлечения и обработки данных для приложения Visio позволяют визуализировать деревья решений, деревья регрессии, кластерные диаграммы и сети зависимостей на диаграммах Visio. Изображена сводная таблица Excel, используемая для доступа клиентов к данным служб аналитики. С помощью приложения Microsoft Office Visio можно аннотировать, дополнять и отображать графические представления результатов извлечения и обработки данных. Платформа SQL Server 2008 в сочетании с приложением Visio 2007 позволяет: 1. визуализировать деревья решений, деревья регрессии, кластерные диаграммы и сети зависимостей; 2. сохранять модели извлечения и обработки данных в виде документов Visio, внедренных в другие документы приложений Office или сохраненных в виде веб-страниц. Клиентские OLAP-средства применяются, как правило, при малом числе измерений (обычно рекомендуется не более шести) и небольшом разнообразии значений этих параметров, - ведь полученные агрегатные данные должны умещаться в адресном пространстве подобного средства, а их количество растет экспоненциально при увеличении числа измерений. Поэтому даже самые примитивные клиентские OLAP-средства, как правило, позволяют произвести предварительный подсчет объема требуемой оперативной памяти для создания в ней многомерного куба. 3.2. Серверные OLAP-средства Преимущества применения серверных OLAP-средств по сравнению с клиентскими OLAP-средствами сходны с преимуществами применения серверных СУБД по сравнению с настольными: в случае применения серверных средств вычисление и хранение агрегатных данных происходят на сервере, а клиентское приложение получает лишь результаты запросов к ним, что позволяет в общем случае снизить сетевой трафик, время выполнения запросов и требования к ресурсам, потребляемым клиентским приложением. Отметим, что средства анализа и обработки данных масштаба предприятия, как правило, базируются именно на серверных OLAP-средствах, например, таких как Oracle Database Server и Microsoft SQL Server. Некоторые клиентские OLAP-средства (в частности, Microsoft Excel) позволяют обращаться к серверным OLAP-хранилищам, выступая в этом случае в роли клиентских приложений, выполняющих подобные запросы. Помимо этого имеется немало продуктов, представляющих собой клиентские приложения к OLAP-средствам различных производителей. Oracle Business Intellegence У компании Oracle существует несколько линеек продуктов класса Business Intelligence. Основная и самая большая называется Oracle Business Intelligence Enterprise Edition PLUS. Oracle Business Intelligence (BI) - это самый обширный комплекс технологий и приложений для обеспечения представления внутренней организации бизнеса, включающий ведущие BI-приложения, технологические BI-платформы и хранилища данных. В основе BI-платформы Oracle лежит аналитический сервер Oracle BI Server EE. Этот сервер хранит: 1. описание различных источников данных. В качестве источников данных могут быть практически любые СУБД, как реляционные (Oracle, Microsoft SQL Server, Microsoft Analysis Services, IBM DB2), так и многомерные (MS AS, Hyperion Essbase или SAP BW), а также ODBC источники, текстовые файлы и т.д. 2. в репозитории хранится бизнес-модель данных, построенная над физическими источниками данных. Бизнес-модель описывает данные в терминах, используемых при проектировании и построении хранилищ данных. Там же описывается, каким образом данные из физических источников соответствуют бизнес-модели. 3. презентационный слой, представляющий собой витрины данных. В презентационном слое описывается, по сути, как, в каких терминах и в каком наборе будут видны данные разным типам пользователей. BI Server фактически представляет собой сервер приложений, который по запросу от пользователя вычисляет, какие данные нужны, в каком физическом источнике они находятся и делает запрос к соответствующему источнику или источникам (один запрос может возвращать данные из нескольких разных источников одновременно), после чего, сервер собирает, при необходимости агрегирует или производит дополнительные вычисления и возвращает результат. С другой стороны, BI Server сам виден в сети как ODBC источник и позволяет делать к себе запросы с помощью любого инструмента или программы, работающей с ODBC. При этом этот сервер остается виртуальным, так как данные на нем не хранятся, а собираются в момент запроса. Аналитический сервер позволяет использовать хранилище как источник данных, одновременно с OLTP системами. Инструментальные средства корпорации Oracle обеспечивают полное интегрированное решение для создания ХД и эффективного использования накопленной в нем информации. Общий перечень продуктов Oracle, необходимых для реализации технологии хранилищ данных и аналитических приложений Business Intelligence Server Сервер бизнес-анализа, интегрирующий данные из множества реляционных, неструктурированных, OLAP и готовых приложений-источников В качестве среды хранения информации в реляционных ХД и ВД используется сервер Oracle Database. Центральным инструментальным средством создания хранилищ и витрин является Oracle Warehouse Builder, построенный на базе современной архитектуры Common Warehouse Metadata. Он предназначен для описания структуры ХД и ВД, проектирования и создания процедур извлечения, согласования и загрузки данных, а также генерации метаданных для средств доступа, например таких, как Discoverer. Проектировать хранилище можно и с помощью стандартного инструмента Oracle Designer, а затем автоматически перенести описание проекта в репозиторий метаданных Oracle Warehouse Builder. Microsoft SQL Server Analysis Services Другой значимой OLAP-технологией является BI-решение от компании Microsoft, построенное на платформе SQL Server и включающее компоненты Analysis Services и Integration Services. Это решение будет подробно рассмотрено во второй главе. 3.3. Технические аспекты многомерного хранения данных OLAP-серверы скрывают от конечного пользователя способ реализации многомерной модели. Они формируют гиперкуб, с которым пользователи посредством OLAP-клиента выполняют необходимые манипуляции, анализируя данные. Однако способ реализации важен, поскольку от него зависят производительность решения и требуемые ресурсы. Существует три основных способа реализации многомерной модели - MOLAP, ROLAP, HOLAP. MOLAP (Multidimensional OLAP) - для реализации многомерной модели используются многомерные БД. При этом данные хранятся в виде упорядоченных многомерных массивов. Такие массивы подразделяются на гиперкубы, в которых все хранимые в БД ячейки имеют одинаковую мерность, и поликубы, в которых каждая ячейка хранится с собственным набором измерений. Физически данные хранятся в "плоских" файлах, при этом куб представляется в виде одной плоской таблицы, в которую построчно вписываются все комбинации элементов всех измерений с соответствующими им значениями мер. Преимущества использования многомерных БД в OLAP-системах: • поиск и выборка данных осуществляется значительно быстрее, чем при многомерном концептуальном взгляде на реляционную БД, так как многомерная БД денормализована и содержит заранее агрегированные показатели, обеспечивая оптимизированный доступ к запрашиваемым ячейкам и не требуя дополнительных преобразований при переходе от множества связанных таблиц к многомерной модели; • многомерные БД легко справляются с задачами включения в информационную модель разнообразных встроенных функций, тогда как объективно существующие ограничения языка SQL делают выполнение этих задач на основе реляционных БД достаточно сложным, а иногда и невозможным. Недостатки MOLAP: • за счет денормализации и предварительно выполненной агрегации объем данных в многомерной БД, как правило, соответствует (по оценке Кодда) в 2,5... 100 раз меньшему объему исходных детализированных данных; • в подавляющем большинстве случаев информационный гиперкуб является сильно разреженным, а поскольку данные хранятся в упорядоченном виде, неопределенные значения удается удалить только за счет выбора оптимального порядка сортировки, позволяющего организовать данные в максимально большие непрерывные группы. Кроме того, оптимальный с точки зрения хранения разреженных данных порядок сортировки, скорее всего, не будет совпадать с порядком, который чаще всего используется в запросах. Поэтому в реальных системах приходится искать компромисс между быстродействием и избыточностью дискового пространства, занятого базой данных; • многомерные БД чувствительны к изменениям в многомерной модели. Например, при добавлении нового измерения приходится изменять структуру всей БД, что влечет за собой большие затраты времени. На основании анализа достоинств и недостатков многомерных БД можно выделить следующие условия, при которых их использование является эффективным: • объем исходных данных для анализа не слишком велик (не более нескольких гигабайт), т. е. уровень агрегации данных достаточно высок; • набор информационных измерений стабилен; • время ответа системы на нерегламентированные запросы является наиболее критичным параметром; • требуется широкое использование сложных встроенных функций для выполнения кроссмерных вычислений над ячейками гиперкуба, в том числе возможность написания пользовательских функций. ROLAP (Relational OLAP) - для реализации многомерной модели используются реляционные БД. В настоящее время распространены две основные схемы реализации многомерного представления данных с помощью реляционных таблиц: схема "звезда" и схема "снежинка". Если каждое измерение содержится в одной таблице, такая схема хранилища данных носит название "звезда" (star schema). Если же хотя бы одно измерение содержится в нескольких связанных таблицах, такая схема хранилища данных носит название "снежинка" (snowflake schema). Дополнительные таблицы измерений в такой схеме, обычно соответствующие верхним уровням иерархии измерения и находящиеся в соотношении "один ко многим" в главной таблице измерений, соответствующей нижнему уровню иерархии, иногда называют консольными таблицами (outrigger table). В сложных задачах с иерархическими измерениями целесообразно использование схемы "снежинка". В этих случаях отдельные таблицы фактов создаются для возможных сочетаний уровней обобщения различных измерений. Это позволяет добиться лучшей производительности, но часто приводит к избыточности данных и к значительным усложнениям в структуре базы данных, в которой оказывается огромное количество таблиц фактов. Увеличение числа таблиц фактов в БД определяется не только множественностью уровней различных измерений, но и тем обстоятельством, что в общем случае факты имеют разные множества измерений. При абстрагировании от отдельных измерений пользователь должен получать проекцию максимально полного гиперкуба, причем не всегда значения показателей в ней должны являться результатом элементарного суммирования. Таким образом, при большом числе независимых измерений необходимо поддерживать множество таблиц фактов, соответствующих каждому возможному сочетанию выбранных в запросе измерений, что также приводит к неэкономному использованию внешней памяти, увеличению времени загрузки данных в БД со схемой "звезда" из внешних источников и сложностям администрирования. Использование реляционных БД в OLAP-системах имеет следующие достоинства: • в большинстве случаев корпоративные ХД реализуются средствами реляционных СУБД, и инструменты ROLAP позволяют производить анализ непосредственно над ними. При этом размер хранилища не является таким критичным параметром, как в случае MOLAP; • в случае переменной размерности задачи, когда изменения в структуру измерений приходится вносить достаточно часто, ROLAP-системы с динамическим представлением размерности являются оптимальным решением, т. к. в них такие модификации не требуют физической реорганизации БД; • реляционные СУБД обеспечивают значительно более высокий уровень защиты данных и хорошие возможности разграничения прав доступа. Главный недостаток ROLAP по сравнению с многомерными СУБД - меньшая производительность. Для обеспечения производительности, сравнимой с MOLAP, реляционные системы требуют тщательной проработки схемы базы данных и настройки индексов. Только при использовании схем типа "звезда" производительность хорошо настроенных реляционных систем может быть приближена к производительности систем на основе многомерных баз данных. HOLAP (Hybrid OLAP) - для реализации многомерной модели используются и многомерные, и реляционные БД. HOLAP-серверы используют гибридную архитектуру, которая объединяет технологии ROLAP и MOLAP. В отличие от MOLAP, которая работает лучше, когда данные более-менее плотные, серверы ROLAP показывают лучшие параметры в тех случаях, когда данные довольно разрежены. Серверы HOLAP применяют подход ROLAP для разреженных областей многомерного пространства и подход MOLAP - для плотных областей. Серверы HOLAP разделяют запрос на несколько подзапросов, направляют их к соответствующим фрагментам данных, комбинируют результаты, а затем предоставляют результат пользователю. Тема 4 Общие сведения о многомерном анализе данных при помощи службы SQL Server 2008 Analysis Services 4.1. Общие сведения о мно-гомерном анализе данных при помощи службы SQL Server 2008 Analysis Services Возможности службы SSAS Microsoft SQL Server Analysis Services (SSAS) является базовой платформой для развития систем бизнес-анализа (Business Intelligence). SSAS 2008 обеспечивают высокую производительность работы приложений и масштабируемость на уровне миллионов записей и тысяч пользователей. Компоненты BI-решения Microsoft BI-решение компании Microsoft основывается на масштабируемой платформе, предназначенной для интеграции данных, построения хранилищ данных, анализа накопленных данных и построения отчетов. Ядром BI-решения Microsoft является платформа SQL Server. Компоненты BI-решения Microsoft Компонент Описание SQL Server Database Engine Масштабируемая, высокопроизводительная СУБД, способная хранить большие объемы данных, образующиеся в результате консолидации данных в единое хранилище для анализа и построения отчетов. SQL Server Integration Services Платформа для выполнения операций извлечения, преобразования и загрузки, которая обеспечивает заполнение ХД и его синхронизацию с данными из различных источников, которые используются бизнес-приложениями организации. SQL Server Analysis Services Обеспечивает возможность построения OLAP-решений, включая возможность расчета ключевых индикаторов производительности ( KPI ). Применяется также для построения data-mining -решений, которые используют специализированные алгоритмы для выявления трендов и зависимостей в бизнес-данных. SQL Server Reporting Services Инструментарий построения отчетов, предназначенный для создания, публикации и распространения детализированных бизнес-отчетов, как для внутренних, так и для внешних целей. UDM SSAS построены на основе Унифицированной Многомерной Модели (Unified Dimensional Model, UDM), появившейся в версии 2005, которая позволяет различным типам клиентских приложений получать доступ к данным как из реляционных, так и из многомерных баз данных без использования отдельных моделей для каждого типа баз данных. Основой UDM является архитектура измерений на основе атрибутов. Архитектура измерений на основе атрибутов дает возможность группировать свойства (атрибуты), определяющие функционирование бизнеса, в одно измерение и отделить эти свойства от правил навигации по измерению - иерархий. UDM предоставляет возможность использовать множество источников данных ( data sources ) для создания многомерной модели. Модель UDM может быть использована для создания единого представления реляционных и многомерных данных, включающих бизнес-объекты, бизнес-аналитику, вычисления и метрики. Модель UDM создает промежуточный логический уровень между физической реляционной базой данных, используемой в качестве источника данных, и фирменными структурами куба и измерений, используемыми для обработки пользовательских запросов. Таким образом, модель UDM можно представить себе как ядро системы OLAP. Одним из ключевых преимуществ модели UDM является возможность сочетать гибкость и функциональное богатство традиционной реляционной модели генерации отчетов с мощными аналитическими средствами и превосходной производительностью классической модели системы OLAP. В эту модель включен широкий спектр функций бизнес-аналитики, позволяющих эффективнее осуществлять реляционный и OLAP-анализ, и дающих организациям возможность расширять свои решения с использованием механизма ключевых показателей эффективности KPI, а также сложных функций прогностического анализа. Масштабируемость и производительность За счет высокой масштабируемости службы SSAS позволяют работать с терабайтными базами данных, и с тысячами пользователей. Чтобы обеспечить работу большого количества пользователей, избежать конфликтов при пользовании ресурсами и снизить затраты, имеется возможность горизонтального масштабирования служб SSAS. Горизонтальное масштабирование заключается в наращивании вычислительных мощностей и емкости хранилищ данных с целью хранения и синхронизации нескольких версий данных, но в то же время службы SSAS позволяют организовать общий доступ для чтения информации из одной базы данных служб с нескольких серверов, устраняя необходимость в избыточных ресурсах. Кубы служб SSAS - это многомерные структуры, обеспечивающие высокоскоростной доступ к большим объемам предварительно объединенных данных, и позволяющие конечным пользователям получать интересующие их бизнес-данные в реальном времени. В службах SSAS хранятся бизнес-данные в формате MOLAP, предоставляющем возможность высокой степени оптимизации и сжатия . Присущая этому формату гибкость дает также возможность частично или полностью хранить данные в реляционной базе данных в режиме реляционного OLAP (ROLAP) или в смешанном режиме, называемом гибридным OLAP (HOLAP). Режим MOLAP обеспечивает значительно более высокую производительность, чем режимы ROLAP и HOLAP. Представление источника данных SSAS предоставляет уровень абстракции над реляционным источником данных - представление источника данных. Представление источника данных позволяет определять таблицы из реляционной базы для использования в многомерной модели. Кроме того, объект представления источника данных позволяет создавать вычисляемые столбцы и представления над реляционными таблицами. Интеграция с Microsoft Office System 2007 BI-платформа Microsoft предоставляет возможности интеграции с продуктами семейства Microsoft Office System 2007, в частности: • Microsoft Office Excel 2007 дает возможность просматривать данные, хранящиеся в OLAP-кубах SSAS путем построения динамических представлений Microsoft PivotTable, что не требует установки дополнительного программного обеспечения; • Microsoft Office Word 2007, как и Microsoft Office Excel 2007, позволяют просматривать отчеты, генерируемые при помощи Reporting Services; • Microsoft Office Visio 2007 позволяет визуализировать деревья решений, деревья зависимостей, кластерные диаграммы и другие модели технологии data mining; • Microsoft Office SharePoint Server позволяет создать единый пользовательский интерфейс для просмотра и управления отчетами, генерируемыми при помощи Reporting Services. Локализация решения посредством использования переводов Часто возникает необходимость разработки многоязыковых решений. Как правило, сами данные едины для всего мира, но метаданные - куб, меры, наименования и уровни измерений, ключевые показатели эффективности (KPI) будут своими для каждого используемого языка. Переводы позволяют задавать различные значения метаданных для разных языков и приспосабливать решения для работы в международном контексте. Финансовую информацию также необходимо локализировать для представления результатов в надлежащей валюте. Предусмотренные в службах SSAS возможности перевода и автоматического конвертирования валют позволяют отображать локализованные данные анализа на родном языке пользователей. 4.2. Инструменты управления службой SSAS SQL Server 2008 представляет следующий набор инструментов для разработки приложений и управления серверами: BI Dev Studio SQL Server Business Intelligence Development Studio (BI Dev Studio) - инструмент, предназначенный для разработки полноценных систем бизнес-анализа на основе Analysis Services, Reporting Services и Integration Services. BI Dev Studio интегрируется в оболочку Visual Studio, что позволяет создавать дополнительные типы проектов для SSAS: При помощи среды BI Dev Studio можно создавать проекты служб SSAS, содержащие определения объектов (кубов, измерений и т.д.) служб SSAS, которые хранятся в XML-файлах, содержащих элементы языка сценариев служб SSAS (ASSL). Эти проекты содержатся в решениях, где также содержатся проекты из других компонентов SQL Server, включая службы SQL Server Integration Services и SQL Server Reporting Services. В среде BI DevStudio можно разрабатывать проекты служб SSAS как часть решения, которое не зависит от какого-либо конкретного экземпляра служб SSAS. Во время разработки объекты могут быть развернуты на экземпляре на тестовом сервере с целью проверки, после чего этот же проект служб SSAS может быть использован для развертывания объектов в экземплярах на одном или нескольких промежуточных или рабочих серверах. Средой BI DevStudio можно также воспользоваться, чтобы напрямую подсоединиться к существующему экземпляру служб SSAS для создания и изменения объектов служб SSAS, без работы с проектом и без хранения определений объекта в XML-файлах. В BI Dev Studio входит средство оповещения Best Practice Design Alerts , автоматически информирующее о возможных недочетах в проекте на ранних стадиях процесса разработки, и сокращающее потери времени, вызванные проектными ошибками, что существенно ускоряет разработку. SSMS SQL Server Management Studio (SSMS) - инструмент, предназначенный для администраторов баз данных, позволяющий управлять многомерными объектами, созданными разработчиками баз данных (рисунок 3.3). SSMS позволяет администрировать Analysis Services, SQL Server, Reporting Services и Integration Services в единой консоли, которая объединяет функциональность управления, редактирования запросов и настройки производительности. При помощи среды SQL Server Management Studio можно управлять объектами служб Analysis Services (выполнять резервное копирование, обработку и т. д.), а также создавать новые объекты непосредственно в существующем экземпляре служб Analysis Services с помощью сценариев XML для аналитики. Среда SQL Server Management Studio представляет проект сценариев сервера анализа данных, в котором можно разрабатывать и сохранять сценарии, написанные на языках многомерных выражений, расширений интеллектуального анализа данных и XML для аналитики ( XMLA ). Обычно проекты сценариев сервера анализа данных используются для выполнения задач по управлению или для повторного создания объектов, например: баз данных или кубов, в экземплярах служб Analysis Services. Хранимые процедуры. Создание динамических запросов при помощи хранимых процедур Хранимая процедура - SQL запрос, который имеет параметры, то есть он выполняется как обычная процедура (мы задаем ее имя и передаем в хранимую процедуру значение параметров.) В зависимости от значения параметров хранимой процедуры мы получаем тот или иной результат запроса. В SQL сервере хранимые процедуры реализуют динамические запросы, выполняемые на стороне сервера. Рассмотрим создание хранимых процедур при помощи команд языка SQL. Чтобы отобразить хранимые процедуры рабочей БД панели "Object Explorer" нужно выделить пункт "Stored Procedures". Чтобы создать новую процедуру при помощи команд языка SQL нужно щелкнуть ЛКМ по кнопке на панели инструментов. В рабочей области окна сервера появится вкладка SQLQuery1.sql, где нужно набрать код новой процедуры, который имеет следующий синтаксис: CREATE PROCEDURE <Имя процедуры> [@<Параметр1> <Тип1>[=<Значение1>], @<Параметр2> <Тип2>[=<Значение2>], …] [WITH ENCRYPTION] AS <Команды SQL> Здесь: • Имя процедуры - имя создаваемой хранимой процедуры. • Параметр1, Параметр2, … - параметры передаваемые в процедуру. • Значение1, Значение2, … - значения параметров по умолчанию. • Тип1, Тип2, … - типы данных параметров. • WITH ENCRYPTION - включает шифрование данных. • Команды SQL - SQL запрос, который выполняется при запуске процедур. Замечание: SQL запрос включает в себя параметры, если параметры сравниваются с какими то полями или выражениями, то они должны иметь точно такой же тип данных как эти поля или выражения. Замечание: После создания процедура помещается в раздел Stored Procedures текущей БД на панели "Object Explorer". Если дважды щелкнуть по процедуре ЛКМ, то она откроется для редактирования на вкладке "SQLQuery". Чтобы посмотреть информацию о хранимой процедуре необходимо выполнить команду: EXEC SP_HELPTEXT <Имя процедуры> Хранимые процедуры могут быть запущены следующей командой EXEC <Имя процедуры> [<Параметр1>, <Параметр2>, …] Здесь: • <Имя процедуры> - имя выполняемой процедуры. • Параметр1, Параметр2, … - значение параметров. Пример: Создание хранимой процедуры, который выводит имя студентов, у которых средний балл больше заданной величины: CREATE PROCEDURE СрБАЛЛ @X Real AS SELECT * FROM Студенты WHERE (Оценка1+ Оценка2+ Оценка3)/3>@X Команда вызова приведенной выше процедуры выглядит следующим образом: EXEC СрБАЛЛ 4 Команда выводит всех студентов, у которых средний балл больше 4. Научимся работать с хранимыми процедурами. Перейдем к созданию хранимых процедур. Для работы с хранимыми процедурами в обозревателе объектов необходимо выделить папку "Programmability/Stored Procedures" базы данных "Students". Создадим процедуру, вычисляющую среднее трех чисел. Для создания новой хранимой процедуры щелкните ПКМ по папке "Stored Procedures" и в появившемся меню выберите пункт "New Stored Procedure". Появиться окно кода новой хранимой процедуры. Хранимая процедура имеет следующую структуру: 1. Область настройки параметров синтаксиса процедуры. Позволяет настраивать некоторые синтаксические правила, используемые при наборе кода процедуры. В нашем случае это: ◦ SET ANSI_NULLS ON - включает использование значений NULL (Пусто) в кодировке ANSI, ◦ SET QUOTED_IDENTIFIER ON - включает возможность использования двойных кавычек для определения идентификаторов; 2. Область определения имени процедуры ( Procedure_Name ) и параметров передаваемых в процедуру ( @Param1, @Param2 ). Определение параметров имеет следующий синтаксис: @<Имя параметра> <Тип данных> = <Значение по умолчанию> Параметры разделяются между собой запятыми; 3. Начало тела процедуры, обозначается служебным словом "BEGIN" ; 4. Тело процедуры, содержит команды языка программирования запросов T-SQL; 5. Конец тела процедуры, обозначается служебным словом "END". Замечание: В коде зеленым цветом выделяются комментарии. Они не обрабатываются сервером и выполняют функцию пояснений к коду. Строки комментариев начинаются с подстроки "--". Далее в коде, мы не будем отображать комментарии, они будут свернуты. Слева от раздела с комментариями будет стоять знак "+", щелкнув по которому можно развернуть комментарий. Наберем код процедуры вычисляющей среднее трех чисел, как это показано на рисунке. Рассмотрим код данной процедуры более подробно: 1. CREATE PROCEDURE [Среднее трех величин] - определяет имя создаваемой процедуры как "Среднее трех величин"; 2. @Value1 Real = 0, @Value2 Real = 0, @Value3 Real = 0 - определяют три параметра процедуры Value1, Value2 и Value3. Данным параметрам можно присвоить дробные числа (Тип данных Real), значения по умолчанию равны 0; 3. SELECT 'Среднее значение'=(@Value1+@Value2+@Value3)/3 - вычисляет среднее и выводит результат с подписью "Среднее значение". Остальные фрагменты кода рассмотрены выше на рисунке. Для создания процедуры, выполним вышеописанный код, нажав кнопку (Выполнить) на панели инструментов. В нижней части окна с кодом появиться сообщение "Command(s) completed successfully.". Закройте окно с кодом, щелкнув мышью по кнопке закрытия расположенной в верхнем правом углу окна с кодом процедуры. Проверим работоспособность созданной хранимой процедуры. Для запуска хранимой процедуры необходимо создать новый пустой запрос, нажав на кнопку (Новый запрос) на панели инструментов. В появившемся окне с пустым запросом наберите команду EXEC [Среднее трех величин] 1, 7, 9 и нажмите кнопку на панели инструментов. В нижней части окна с кодом появится результат выполнения новой хранимой процедуры: Среднее значение 5,66667. Теперь создадим хранимую процедуру для отбора студентов из таблицы студенты по их "ФИО". Для этого создайте новую хранимую процедуру, как это описано выше, и наберите код новой процедуры как на рисунке. Рассмотрим код процедуры "Отображение студентов по ФИО" более подробно: 1. CREATE PROCEDURE [Отображение студентов по ФИО] - определяет имя создаваемой процедуры как "Отображение студентов по ФИО"; 2. @FIO Varchar(50)='' - определяют единственный параметр процедуры FIO. Параметру можно присвоить текстовые строки переменной длины, длинной до 50 символов (Тип данных Varchar(50)), значения по умолчанию равны пустой строке; 3. SELECT * FROM dbo.Студенты WHERE ФИО=@FIO - отобразить все поля (*) из таблицы студенты (dbo.Студенты), где значение поля ФИО равно значению параметра FIO (ФИО=@FIO). Тема 5 Планирование и архитектура SQL Server Analysis Services 5.1. Планирование и архитектура SSAS. Логическая архитектура Службы Microsoft SQL Server Analysis Services используют как серверные, так и клиентские компоненты для предоставления приложениям бизнес-аналитики функций оперативной аналитической обработки (OLAP) и интеллектуального анализа данных. Серверный компонент служб SSAS реализован в виде службы Microsoft Windows. Службы SQL Server Analysis Services поддерживают работу нескольких экземпляров на одном компьютере, при этом каждый экземпляр служб SSAS реализован как отдельный экземпляр службы Windows. Клиенты обмениваются данными со службами SSAS с помощью общедоступного стандарта XML для аналитики ( XMLA ), который представляет собой протокол на базе SOAP для выполнения команд и получения ответов и предоставляется в виде веб-службы. Поэтому каждый экземпляр SSAS является Web-сервисом. Клиентские модели объектов также предоставляются через XML для аналитики, и доступ к ним производится через управляемый поставщик, например http://www.ADOMD.NET, или через собственный поставщик http://www.oledbdirect.com. Также службы SSAS поддерживают ядро локального куба, которое позволяет приложениям на отключенных клиентах просматривать локально хранимые многомерные данные. Экземпляр служб SSAS может содержать несколько баз данных, а в базе данных могут одновременно присутствовать объекты OLAP и объекты интеллектуального анализа данных. Приложения подключаются к указанному экземпляру служб SSAS и к указанной базе данных. На серверном компьютере может эксплуатироваться несколько экземпляров служб SSAS. Экземпляры служб SSAS именуются как "<ИмяСервера>\<ИмяЭкземпляра>". Связи между объектами служб SSAS Основные классы представляют собой минимальный набор объектов, требуемый для формирования куба. Этот минимальный набор объектов включает измерение, группу мер и секцию. Определение статистической обработки является необязательным. Измерение описывает элемент данных, по которому производится анализ. Например, распространенным элементом анализа является время. Измерения создаются на основе атрибутов и иерархий. Атрибут - это полная коллекция элементов одного типа. Например, все дни недели будут атрибутом измерения "Время". Иерархии формируются с использованием упорядоченного набора атрибутов, такого, что каждый атрибут соответствует одному из уровней в иерархии. Кубы создаются на основе измерений и групп мер. Начиная с Analysis Services 2005, поддерживается множество фактов в одном кубе. Меры из таблицы фактов группируются в группу мер. Куб может иметь несколько групп мер. Измерения в коллекции измерений куба принадлежат к коллекции измерений базы данных. Группы мер - это коллекции мер, которые имеют одно и то же представление источника данных и одно и то же подмножество измерений в кубе. Группа мер имеет одну или несколько секций, предназначенных для управления физическими данными. Группа мер может иметь применяемую по умолчанию статистическую схему. Статистическая схема по умолчанию может использоваться во всех секциях в группе мер; кроме того, каждая секция может иметь собственную статистическую схему. Каждый экземпляр служб SSAS рассматривается как отдельный объект сервера. Каждый отдельный экземпляр подключается к объекту Server с помощью отдельного соединения. Каждый объект сервера содержит один или несколько источников данных, представление источника данных и объекты базы данных, а также сборки и роли безопасности. Каждый объект базы данных содержит несколько объектов измерения. Каждый объект измерения содержит один или несколько атрибутов, которые организованы в виде иерархий. Каждый объект базы данных содержит один или несколько объектов куба. Куб задается его мерами и измерениями. Меры и измерения куба выводятся из таблиц и представлений в представлении источника данных, на котором основан куб или который создан из определений мер и измерений. Пример Куб "Импорт" содержит две меры ("Пакеты" и "Последняя дата") и три связанных измерения ("Маршрут", "Источник" и "Время"). По осям куба отложены элементы измерений. Примеры элементов - "Наземный" (элемент измерения "Маршрут"), "Африка" (элемент измерения "Источник") и "1-й квартал" (элемент измерения "Время"). Значение в ячейках куба представляют две меры - "Пакеты" и "Последняя дата". Мера "Пакеты" представляет число импортированных посылок; для статистической обработки фактов используется функция Sum. Мера "Последняя дата" представляет собой дату получения; для статистической обработки используется функция Max. Измерение "Маршрут" представляет пути, которыми импортируемый товар достигает своего назначения. В число элементов этого измерения входят "наземный", "не наземный", "воздушный", "морской", "дорожный" и "железнодорожный". Измерение "Источник" представляет место производства импортируемого товара, например Азию или Африку. Измерение "Время" представляет кварталы и полугодия. Пользователи куба могут определять значения его мер для каждого элемента в каждом измерении независимо от уровня элемента в измерении, поскольку службы SSAS вычисляют значения верхних уровней по мере необходимости. Например, значения меры могут быть вычислены в соответствии с обычной календарной иерархией с использованием иерархии "Календарное время" в измерении "Время". Значения мер в соответствии с иерархией "Календарное время" Меры, атрибуты и иерархии в примере куба выводятся из следующих столбцов таблиц фактов и измерений куба. Соответствие элементов куба таблицам фактов и измерений Мера или атрибут (уровень) Элементы Исходная таблица Исходный столбец Образец значения столбца Мера "Посылки" Неприменимо ImportsFactTable Посылки 12 Мера "Последняя дата" Неприменимо ImportsFactTable Последняя дата 03-май-99 Уровень категории "Маршрут" в измерении "Маршрут" не наземный, наземный RouteDimensionTable Route_Category Не наземный Атрибут "Маршрут" в измерении "Маршрут" воздушный, морской, дорожный, железнодорожный RouteDimensionTable Маршрут Морской Атрибут "Полушарие" в измерении "Источник" Восточное полушарие, западное полушарие SourceDimensionTable Полушарие Восточное полушарие Атрибут "Континент" в измерении "Источник" Африка, Азия, Австралия, Европа, Северная Америка, Южная Америка SourceDimensionTable Континент Европа Атрибут "Полугодие" в измерении "Время" Первое полугодие, второе полугодие TimeDimensionTable Полугодие Второе полугодие Атрибут "Квартал" в измерении "Время" Первый квартал, второй квартал, третий квартал, четвертый квартал TimeDimensionTable Квартал Третий квартал Приведенный пример представляет простой куб, в том смысле, что это куб с единственной группой мер, а все таблицы измерений соединены с таблицей фактов по схеме "звезда". Другая схема - это схема "снежинка", в которой одна или несколько таблиц измерений присоединяются к другой таблице измерения, а не напрямую к таблице фактов. В приведенном здесь примере содержится только одна таблица фактов. Когда в кубе есть несколько таблиц фактов, меры каждой из них организуются в группы мер, причем группа мер связана с соответствующим набором измерений согласно заданным связям измерений. 5.2. Планирование и архитектура SSAS. Физическая архитектура. С точки зрения физической архитектуры службы SSAS состоят из серверного и клиентского компонентов. 1. Серверный компонент служб SSAS реализован в виде службы Microsoft Windows. Службы SSAS поддерживают работу нескольких экземпляров на одном компьютере, при этом каждый экземпляр служб SSAS реализован как отдельный экземпляр службы Windows. 2. Клиенты обмениваются данными со службами SSAS с помощью общедоступного стандарта XML для аналитики ( XMLA ), который представляет собой протокол на базе SOAP для выполнения команд и получения ответов и предоставляется в виде веб-службы. Клиентские модели объектов также предоставляются через XML для аналитики, и доступ к ним производится через управляемый поставщик, например http://www.ADOMD.NET, или через собственный поставщик OLE DB. Команды запросов могут быть выражены на следующих языках: 1. Расширения интеллектуального анализа данных ( MDX ) - стандартный язык запросов, ориентированный на интеллектуальный анализ данных. 2. Язык сценариев служб Analysis Services (ASSL) также может использоваться для управления объектами базы данных служб SSAS. Экземпляр служб SSAS запускается, как изолированная служба, взаимодействие с этой службой происходит через XMLA с использованием протокола HTTP или TCP. Объекты AMO - это прослойка между приложением пользователя и экземпляром служб SSAS. Они предоставляют доступ к административным объектам служб SSAS. Объект AMO - это библиотека класса, которая принимает команды от клиентского приложения и преобразует их в XMLA -сообщения для экземпляра служб SSAS. Объекты AMO представляют объекты экземпляра служб SSAS, как классы для приложения конечного пользователя, с элементами-методами, запускающими команды и элементами-свойствами, хранящими данные объектов служб SSAS. Архитектура компонентов служб SSAS включает все главные элементы, запущенные на экземпляре служб SSAS, и все пользовательские компоненты, взаимодействующие с этим экземпляром. Как показано на рисунке, единственным путем доступа к экземпляру является прослушиватель XML для аналитики или использование протокола HTTP или TCP. 5.3. Архитектура программирования SSAS Прикладная модель определяет формат данных, и в котором они передаются аналитическим приложениям. Основным пользователем прикладной модели данных является клиентское приложение, которое представляет модель пользователю. Прикладная модель создается с помощью Языка Многомерных Выражений (Multidimensional Expressions, MDX), который служит как для представления запросов к многомерной базе данных, так и для описания модели формирования данных внутри нее при помощи MDX -сценариев (MDX Scripts). Объекты AMO Объекты AMO являются полной коллекцией классов управления для служб SSAS, доступных для использования программным способом в управляемой среде, через пространство имен Microsoft.AnalysisServices. Эти классы включены в файл AnalysisServices.dll, который обычно находится в каталоге установки SQL Server, то есть в папке \100\SDK\Assemblies\. Для работы с классами AMO следует указать в проекте Visual Studio ссылку на эту сборку. Объекты AMO позволяют создавать, изменять и удалять такие объекты, как кубы, измерения, структуры интеллектуального анализа, а также базы данных служб SSAS. Приложение, работающее на платформе .NET Framework, может выполнять действия со всеми этими объектами. Кроме этого, существует также возможность обновления и обработки данных, хранящихся в базах данных служб SSAS. Объекты AMO не позволяют выполнять запросы к данным. Для запроса данных предназначены объекты, описанные в разделе http://www.ADOMD.NET. Библиотека классов AMO содержит иерархию классов, где для использования в коде сначала создаются экземпляры одних классов, а затем других. Существуют также дополнительные классы, экземпляры которых могут быть в любой момент созданы в коде, однако сначала, вероятно, потребуется создать экземпляры одного или нескольких классов иерархии. На приведена иерархия классов AMO высокого уровня, содержащая основные классы. Объекты AMO особенно полезны для автоматизации часто выполняемых задач (например, для создания новых секций в группе мер при появлении новых данных в таблице фактов или для повторного обучения модели интеллектуального анализа при появлении новых данных). Обычно эти задачи, которые создают новые объекты, выполняются ежемесячно, еженедельно или ежеквартально, а приложение может легко именовать эти новые объекты на основе новых данных. Администраторы служб SSAS могут использовать объекты AMO, чтобы автоматизировать обработку баз данных служб SSAS. Проектирование и развертывание баз данных служб SSAS следует производить в среде BI Dev Studio. Разработчикам объекты AMO дают возможность создавать интерфейсы администрирования для определенных наборов пользователей. Эти интерфейсы позволяют ограничивать доступ к объектам служб SSAS и разрешать пользователям выполнять только определенные задачи. На основе объектов AMO можно, например, создать приложение для создания резервных копий, которое позволит пользователям видеть все объекты баз данных, выбрать любую из баз данных и создать ее резервную копию на любом устройстве из указанного набора. Разработчики могут также внедрять в приложения логику служб SSAS. Это возможно благодаря созданию кубов, измерений, структур и моделей интеллектуального анализа на основе пользовательского ввода и других факторов. Проектирование, развертывание и обслуживание большинства наиболее часто выполняемых задач лучше всего выполняется при помощи приложений на основе служб Integration Services, написанных на любом языке. А для тех повторяющихся задач, автоматизировать которые при помощи служб Integration Services невозможно, можно использовать объекты AMO. Объекты AMO также полезны при разработке специализированных приложений для бизнес-аналитики на основе служб SSAS. Язык ASSL Клиентские приложения служб SSAS, в том числе SQL Server Management Studio и BI Dev Studio, поддерживают связь со службами SSAS с помощью сообщений SOAP. Язык сценариев служб Analysis Services (язык ASSL), который является разновидностью XML, используемой для этих сообщений, состоит из двух частей: 1. языка описания данных DDL, или язык определения объектов, который определяет и описывает экземпляр служб SSAS, а также базы данных и объекты баз данных, находящихся в этом экземпляре; 2. командного языка, который отправляет команды-действия, например Create, Alter или Process, экземпляру служб SSAS. В службах SSAS язык определения данных (Data Definition Language, DDL) языка ASSL определяет структуру объектов служб SSAS (например, кубов, измерений и моделей интеллектуального анализа данных), а также привязку объектов служб SSAS к источникам данных. DDL также сохраняет определение объектов служб SSAS. Приложения служб SSAS используют DDL для создания, изменения, развертывания и описания объектов SSAS. Разработчик проектирует набор кубов при помощи средств проектирования среды BI DevStudio и сохраняет это определение как часть проекта. Разработчик не ограничен использованием только средств проектирования, он также может открывать непосредственно файлы определений кубов для изменения XML. Администратор БД использует среду SQL Server Management Studio для непосредственного редактирования XML в качестве средства создания и изменения объектов служб SSAS так же, как он использует SQL Server DDL, чтобы создавать и изменять объекты Microsoft SQL Server. Поставщик данных ADOMD.NET Как и в случае с поставщиками данных платформы Microsoft .NET Framework, такими как http://www.ADO.NET,http://www. ADOMD.NET выступает в качестве моста между приложением и источником данных. Однакоhttp://www. ADOMD.NET отличается от остальных поставщиков данных платформы .NET Framework тем, что он работает с аналитическими данными. Чтобы работать с аналитическими данными, компонент http://www.ADOMD.NET обладает функциями, которые значительно отличаются от функций других поставщиков данных платформы .NET Framework. http://www.ADOMD.NET позволяет получать не только данные, но и метаданные, а также изменять структуру источника аналитических данных. Получив метаданные при помощи наборов строк схемы или модели объекта, приложения могут узнать больше о тех данных, которые можно извлечь из источника данных. Получить можно такие сведения, как типы доступных ключевых индикаторов производительности, измерения в кубе и параметры, которые требуются модели интеллектуального анализа данных. Наибольшее значение метаданные имеют для динамических приложений, которым для определения типа, глубины и области действия получаемых данных требуется ввод пользователя. Среди таких приложений Query Analyzer, Microsoft Excel и другие средства запросов. Метаданные менее значимы для статических приложений, выполняющих набор стандартных действий. Получение данных - это фактическое извлечение сведений, хранящихся в источнике данных. Получение данных является основной функцией "статических" приложений, которым известна структура источника данных. Получение данных также является конечным результатом "динамических" приложений. Значение ключевого индикатора производительности в данное время суток, число велосипедов, проданных за последний час по каждому магазину и факторы, влияющие на среднегодовую производительность сотрудников - все это примеры данных, которые можно получить. Получение данных важно для любого выполняющего запросы приложения. Компонент http://www.ADOMD.NET также можно использовать, чтобы фактически изменять структуру хранилища аналитических данных. И хотя обычно это делается с помощью модели объектов AMO, компонент http://www.ADOMD.NET можно использовать для отправки команд на ASSL, чтобы создавать, изменять или удалять объекты на сервере. Тема 6 Разработка многомерных баз данных с использованием SSAS 6.1. Проектирование и реализация многомерных баз данных с использованием SQL Server Analysis Services Решения, проекты и элементы И среда BI Dev Studio, и среда SQL Server Management Studio предоставляют проекты, которые, в свою очередь, организованы в решения. Решение может содержать несколько проектов, а проект обычно содержит несколько элементов. При создании проекта автоматически создается новое решение, а в существующее решение при необходимости можно добавлять проекты. Объекты, которые содержатся в проекте, зависят от его типа. Элементы в каждом контейнере проекта хранятся в виде файлов, расположенных в папках проекта в файловой системе. Типы проектов бизнес-аналитики Типы проектов бизнес-аналитики в среде BI Dev Studio Проект Описание Проект служб Analysis Services Содержит определения объектов для одиночной базы данных служб SSAS. Импорт базы данных служб Analysis Services 2008 Предоставляет мастер, который можно использовать для создания нового проекта служб SSAS путем импортирования определений объектов из существующей базы данных служб SSAS. Проект служб Integration Services Содержит определения объектов для набора пакетов служб Integration Services. Мастер проектов отчетов Предоставляет мастер, который помогает выполнить процесс создания проекта отчета с помощью служб Reporting Services. Проект модели отчета Содержит определения объектов для модели отчета служб Reporting Services. Проект сервера отчетов Содержит определения объектов для одного или нескольких отчетов служб Reporting Services. Среда SSMS также содержит несколько типов проектов, предназначенных для различных типов запросов или сценариев. Типы проектов бизнес-аналитики в SSMS Проект Описание Сценарии служб Analysis Services Содержит сценарии расширений интеллектуального анализа данных, многомерных выражений и XML для аналитики для служб SSAS, а также соединения с экземплярами служб SSAS, в которых эти сценарии могут выполняться. Сценарии SQL Server Compact Содержит сценарии SQL для SQL Server Compact, а также соединения с экземплярами SQL Server Compact, в которых могут выполняться эти сценарии. Сценарии SQL Server Содержит сценарии Transact-SQL и XQuery для экземпляра компонента SQL Server Database Engine, а также соединения с экземплярами компонента SQL Server Database Engine, в которых эти сценарии могут выполняться. Выбор между SSMS и BI Dev Studio Среда SSMS разработана для администрирования и настройки существующих объектов в компонентах SQL Server Database Engine, Analysis Services, Integration Services и Reporting Services. Среда BI Dev Studio предназначена для разработки решений в области бизнес-аналитики, которые включают функции служб Analysis Services, Integration Services и Reporting Services. Основные различия между SSMS и BI Dev Studio заключаются в следующем: • среда SSMS предоставляет интегрированную среду для соединения с экземплярами служб SSAS, SQL Server и Reporting Services, чтобы настраивать объекты, а также проводить администрирование объектов и управлять ими в пределах экземпляра служб SSAS. С использованием этих сценариев можно также использовать среду SSMS для создания или изменения объектов служб SSAS, но среда SSMS не предоставляет графический интерфейс для конструирования и определения объектов; • среда BI Dev Studio предоставляет интегрированную среду разработки для разработки решений бизнес-аналитики. Среду BI Dev Studio можно использовать в проектном режиме, использующем определения на основе XML объектов служб SSAS, Integration Services и Reporting Services, содержащихся в проектах и решениях. Использование среды BI Dev Studio в проектном режиме означает, что изменения объектов служб SSAS в среде BI Dev Studio применяются к определениям объектов на основе XML, но не применяются непосредственно к объекту в экземпляре служб SSAS до тех пор, пока решение не будет развернуто. Среду BI Dev Studio можно также использовать в оперативном режиме, т. е. напрямую подключаться к экземпляру служб SSAS и работать с объектами существующей базы данных. 6.2. Создание пользовательских функций Пользовательские функции очень похожи на хранимые процедуры. Так же в них можно передавать параметры и они выполняют некоторые действия, однако их главным отличием от хранимых процедур является то, что они выводят (возвращают) какой то результат. Более того, они вызываются только при помощи оператора SELECT, аналогично встроенным функциям. Все пользовательские функции делятся на 2 вида: 1. Скалярные функции - функции, которые возвращают число или текст, то есть одно или несколько значений; 2. Табличные функции - функции, которые выводят результат в виде таблицы. Для создания новой пользовательской функции используется команда CREATE FUNCTION имеющая следующий синтаксис: CREATE FUNCTION <Имя функции> ([@<Параметр1> <Тип1>[=<Значение1>], @<Параметр2> <Тип2>[=<Значение2>], . . .]) RETURNS <Тип>/TABLE AS RETURN([<Команды SQL>]) Здесь: • Имя функции - имя создаваемой пользовательской функции. • Параметр1, Параметр2, .. - параметры передаваемые в функцию. • Значение1, Значение2, … - значения параметров по умолчанию. • Тип1, Тип2, . .. - типы данных параметров. После служебного слова RETURNS в скалярных функциях ставится тип данных результата, который возвращает скалярная функция, либо ставится служебное слово TABLE в табличных функциях. После служебного слова RETURN ставится SQL команда самой функции. Замечание: После служебного слова RETURN может быть несколько команд, которые располагаются между словами BEGIN и END. В этом случае служебное слово RETURN не ставится. Замечание: Тип данных параметра должен совпадать с типом данных выражения, в котором он используется. Замечание: Если используются несколько SQL команд и BEGIN и END, то перед END нужно ставить команду RETURN <результат функции>. Пример (скалярная пользовательская функция): Функция для вычисления среднего 3 чисел: CREATE FUNCTION Среднее (@X1 Int,@X2 Int,@X3 Int) RETURNS Real AS BEGIN DECLARE @Res Real SET @Res =(@X1+@X2+@X3)/3 RETURN @Res END Замечание: Команда DECLARE создает переменную Res для хранения дробных чисел (тип данных Real ). Представленная выше пользовательская функция реализована при помощи нескольких команд SQL, но ее можно реализовать при помощи одной функции следующим образом: CREATE FUNCTION Среднее (@X1 Int,@X2 Int,@X3 Int) RETURNS Real AS RETURN (SELECT (@X1+@X2+@X3)/3) Созданная функция, вычисляющая среднее 6, 3 и 3, запускается следующим образом: SELECT Среднее (6, 3, 3) Результат будет 4. Пример (табличная пользовательская функция): Из таблицы Студенты выводятся поля ФИО, дата рождения и столбец возраст, который вычисляется как разница дат в годах, между датой рождения и текущей датой (параметр CurDate ). CREATE FUNCTION Возраст (@CurDate Date) RETURNS TABLE AS RETURN (SELECT ФИО, [Дата рождения], Возраст = DATEDIFF (yy,[Дата рождения], @CurDate) FROM Студенты) Данная функция вызывается следующим образом: SELECT * FROM Возраст ('12/17/2007') В результате отобразятся студенты с их возрастом на 17 декабря 2007 года. 6.3. Создание интерфейса пользователя Интерфейс информационных систем В системах построенных по технологии клиент-сервер существует два вида интерфейса: • Интерфейс, реализуемый при помощи клиентского приложения; • Web -интерфейс. Интерфейс, реализуемый при помощи клиентского приложения - это компьютерная программа, устанавливаемая на клиентские компьютеры, предназначенная для работы с файлами данных через сеть. Основными элементами клиентских приложений являются формы (окно программы) и отчёты. Элементы управления на форме называется объектами. Каждый объект обладает своим набором свойств, событий и методов. • Свойства объекта - это его характеристики (высота, ширина и т.д.); • События объекта - это события операционных систем или события инициируемые пользователем, на которые может реагировать объект (нажатие кнопки); • Методы объекта - действия, которые можно производить с объектом в ходе выполнения программ. В БД все объекты форм делятся на два класса: • Объекты управления - объекты, осуществляющие управление БД (Например: Кнопка или Выпадающий список); • Объекты для отображения информации - элементы, отображающие содержимое таблиц, запросов или фильтров, позволяющие добавлять изменять и удалять информацию, и проводить ее анализ. Все формы в клиентском приложении делятся на три группы: 1. Формы для работы с данными - формы, содержащие как объекты управления, так и объекты просмотра данных. Такие формы предназначены для отображения, изменения, удаления и анализа данных; 2. Кнопочные формы - формы, содержащие только объекты управления, предназначаются для открытия всех других форм. Замечание: Кнопочная форма, которая появляется первой после запуска программы, называется, главной кнопочной формой. 3. Информационные и служебные формы - формы, содержащие только элементы управления, предназначены для отображения служебной информации (справки), несвязанной с таблицами, запросами и фильтрами, либо для выполнения служебных операций не связанных с данными (Например: форма с калькулятором) Замечание: Существует два вида дизайна форм: 1. Ленточные формы - формы, выводящие информацию по одной записи; 2. Табличные формы - формы выводящие информацию в виде таблицы. Замечание: Объекты связи используются только в клиентском интерфейсе. В web-интерфейса функции объекта связи выполняет сервер. Основой web-интерфейса являются страницы (файл с расширенным htm или html). Работа со страницами осуществляется с помощью программы - браузера. Изначально страницы находятся на сервере, пользователь сначала загружает их на свой компьютер с сервера, а затем с помощью страниц пользователь работает с файлом данных. Замечание: В web- интерфейсе отсутствуют отчёты, их роль выполняют сами страницы. Создание интерфейса пользователя Создание интерфейса при помощи окна "Data Sources" Visual Basic 2008 позволяет создавать не сложный интерфейс БД, без помощи панели объектов и окна свойств, лишь используя окно "Data Sources". В окне "Data Sources" после подключения источника данных отображается все таблицы, запросы, фильтры данных и их поля. В Visual Basic 2008 как и в Visual Basic 6.0 можно перетаскивать источники данных, соответственно таблицы, запросы, фильтры прямо из окна "Data Sources" на форму (в Visual Basic 6.0 окно "Data Sources" заменено на окно "Data Environment" ). Главное отличие Visual Basic 2008 является то, что при перетаскивании можно выбирать для каждого поля источника данных объект, который будет отображать его содержимое. Замечание: Таким способом можно создавать только определённые объекты для отображения данных поля, и набор этих объектов зависит от типа данных поля. Создание объектов для отображения данных перетаскиванием состоит из двух шагов: • Для каждого поля таблицы, запроса, или фильтра выбирается объект, который будет отображать его содержимое. Для этого необходимо щелкнуть мышью по полю в окне "Data Sources", рядом с именем поля появится кнопка, со стрелкой, щелкнув мышью по стрелке, отобразится выпадающее меню с объектами, которые могут отображать информацию, содержащуюся в поле. Для полей стандартными объектами являются: TextBox, ComboBox, Label, LinkLabel, ListBox. Для полей типа данных Дата Время (DateTime) возможно использования объекта DataTimePicker. Для полей логических типов данных возможно использование объекта CheckBox. Для отображения таблиц, запросов или фильтров целиком возможно два варианта отображения: ◦ При помощи объекта DataGridView - информация из таблицы, запроса или фильтра отображается в виде таблицы; ◦ DetalledView - отображение всех полей источника данных в TextBox по отдельности Замечание: В выпадающем меню с вариантами выбора объектов имеется пункт "Customize" (Настройки), который позволяет выбрать дополнительные допустимые объекты для отображения информации. • после выбора объектов для отображения необходимо их поместить на форму, перетаскивая мышью с панели "Data Sources" в нужное место на форме. Замечание: При помещении первого объекта на форму на ней автоматически создаются объекты для связей с файлом данных и объекты по навигациям по источникам данных (DataSet, BindingSource, TableAdapter, BindingNavigator). Замечание: По умолчанию панель навигации располагается в верхней части формы. Эту панель можно прикрепить около различных краев формы. Для этого необходимо воспользоваться меню действий объектов. Это меню схоже с окном "Property Pages" из Visual Basic 6.0, но кроме основных свойств объектов оно содержит и действия, которые можно производить с объектами. Чтобы вызвать это меню, необходимо выделить объект. В его правом верхнем углу появится кнопка (квадратик со стрелочкой), при нажатии этой кнопки появляется выпадающее меню с настройками и действия с объектом. Например, чтобы поменять местоположение навигации панели - надо в этом меню выбрать настройку Docking. Замечание: При перетаскивании на форму полей источников данных автоматически создаются подписи к ним ( Label ). Замечание: После перетаскивания с созданным объектом можно работать как и с обычным объектом Visual Basic. Подключение объектов к источнику данных при помощи окна свойств Visual Basic 2008 позволяет подключать источники данных к объектам без использования перетаскивания, то есть вручную, с использованием панели свойств, как в Visual Basic 6.0. Для этого на форму помещается объект, который будет подключаться к источнику данных. Его выделяют, затем на панели свойств разворачивается группа свойств "DataBindings" она содержит два свойства: • Text - определяет таблицу, запрос или фильтр, из которого выводятся данные в объект; • Tag - определяет поле, выбранного в свойстве Text источника данных, которое отображается в объекте. 6.4. Главная кнопочная форма. Создание простых ленточных форм для работы с данными Перейдем теперь к созданию пользовательского интерфейса. Его создание начнем с создания главной кнопочной формы. Запустите "Microsoft Visual Studio 2008" и откройте созданный ранее проект "StudentsDB", щелкнув по его значку в области "Recent Projects" стартовой страницы "Start Page". После появления стандартного окна среды разработки в рабочей области на форму поместите надпись ( Label ) и четыре кнопки ( Button ) как показано на рисунке. Замечание: Для создания надписи на панели объектов необходимо нажать кнопку а затем нарисовать прямоугольник мышью на форме, удерживая ЛКМ. Кнопки создаются таким же образом, только на панели объектов нажмите кнопку После создания объектов перейдем к настройке их свойств. Начнем с настройки свойств формы. Выделите форму, щелкнув ЛКМ в пустом месте формы. На панели свойств задайте свойства формы как представлено ниже: • FormBorderStyle (Стиль границы формы): Fixed3D; • MaximizeBox (Кнопка развертывания формы во весь экран): False; • MinimizeBox (Кнопка свертывания формы на панель задач): False; • Text (Текст надписи в заголовке формы): База данных "Студент". На форме выделите надпись, щелкнув по ней ЛКМ и на панели свойств, задайте свойства надписи следующим образом: • AutoSize (Авторазмер): False; • Font (Шрифт): Microsoft Sans Serif, размер 14; • ForeColor (Цвет текста): Темно синий; • Text (Текст надписи): База данных "Студент"; • TextAlign (Выравнивание текста): MiddleCenter. У кнопок задайте надписи (свойство "Text" ) как показано на рисунке. После настройки свойств вышеперечисленных объектов форма примет вид представленный на рисунке. Теперь перейдем к созданию простых ленточных форм для работы с данными. Для начала создадим ленточную форму, отображающую таблицу "Специальности". Добавим в проект новую пустую форму. Для этого в оконном меню выберите пункт "Project/Add Windows Form". Появится окно "Add New Item - StudentsDB" (Добавить новый компонент). В данном окне в разделе "Categories:" (Категории) выберите "Windows Forms" (Формы Windows), затем в разделе "Templates:" (Шаблоны) выберите "Windows Form" (Форма Windows) и нажмите кнопку "Add" (Добавить). Новая пустая форма появится в рабочей области среды разработки. В верхней части новой формы создайте надпись ( Label ), как это показано на рисунке. Перейдем к настройке свойств формы и надписи. Выделите форму, щелкнув ЛКМ в пустом месте формы. На панели свойств задайте свойства формы следующим образом: • FormBorderStyle (Стиль границы формы): Fixed3D; • MaximizeBox (Кнопка развертывания формы во весь экран): False; • MinimizeBox (Кнопка свертывания формы на панель задач): False; • Text (Текст надписи в заголовке формы): Таблица "Специальности". На форме выделите надпись, щелкнув по ней ЛКМ и на панели свойств, задайте свойства надписи как показано ниже: • AutoSize (Авторазмер): False; • Font (Шрифт): Microsoft Sans Serif, размер 14; • ForeColor (Цвет текста): Темно синий; • Text (Текст надписи): Таблица "Специальности"; • TextAlign (Выравнивание текста): MiddleCenter. После настройки всех вышеперечисленных свойств форма будет выглядеть следующим образом: Теперь поместим на форму поля таблицы "Специальности". Сначала откройте панель "Источники данных" (Data Sources), щелкнув по ее вкладке в правой части окна среды разработки. На панели "Источники данных" отобразите поля таблицы "Специальности", щелкнув по значку "+", расположенному слева от имени таблицы. Панель "Источники данных" примет вид, представленный на рисунке выше. Замечание: Под полями таблицы специальности в виде подтаблицы располагается таблица "Студенты". Подтаблица показывает, что таблица "Студенты" является вторичной по отношению к таблице специальности. Замечание: При выделении, какого либо поля таблицы, оно будет отображаться в виде выпадающего списка, позволяющего выбирать объект, отображающий содержимое выделенного поля. 6.5. Стандартные объекты для отображения данных. Программное управление информационной системой Стандартные объекты для отображения данных Способ создания объектов для отображения данных описанный ранее, позволяет создавать только ограниченный набор объектов. Однако, Visual Basic 2008 позволяет подключать источники данных практически к любому объекту, который может быть создан на форме. Это можно сделать при помощи перетаскивания поля источника данных из окна "Data Sources" на объект на форме. Операция состоит из двух шагов: • При помощи панели объектов (слева) на форме создается какой-то объект. Объекты несвязанные с источником данных называют несвязанными объектами; • Вновь созданный объект связывается с источником данных. Для этого на объект нужно перетащить поле таблицы запроса или фильтра из окна "Data Sources". Замечание: При перетаскивании поля из окна "Data Sources" необходимо учитывать его тип данных. Объект на форме должен поддерживать тип данных подключаемого к нему поля. Замечание: В случае подключения объекта к источнику данных, способом, описанным выше, подпись к объекту не создаётся автоматически и её надо создавать вручную с помощью объекта Label. Наиболее часто в БД используются следующие объекты для отображения информации: 1. Текстовое поле ( TextBox ) 2. Надпись ( Label ) 3. Надпись со ссылкой ( LinkLabel ) 4. Календарь ( DataPicker ) 5. Переключатель ( CheckBox ) 6. Таблица ( DataGridView ) 7. Список ( ListBox ) 8. Выпадающий список ( ComboBox ) 9. Текстовое поле с маской ввода ( MaskedTextBox ) TextBox - отображает текст и числовые поля, это наиболее часто употребляемый объект для отображения данных. Его можно создавать либо перетаскиванием из окна "Data Sources", либо подключить вручную. Создание этого объекта, перетаскиванием возможно почти у полей любых типов данных. Label - полностью аналогичен объекту TextBox, но не позволяет изменить данные. Этот объект используется для отображения заблокированных неизменяемых полей. LinkLabel - специальный объект для отображения ссылок на адреса в Интернете. Его используют для отображения текстовых полей, если в них хранятся адреса Интернета или какой-то компьютерной сети. Это новый объект, ему не было аналога в Visual Basic 6.0. DataPicker - специальный объект, предназначенный для отображения полей типа данных "Дата/Время" в виде календаря. CheckBox - объект используется для отображения логических полей, может быть создан перетаскиванием только для логических полей. DataGridView - объект, отображающий источник данных (таблицу, запрос или фильтр) в виде таблицы. ListBox - список отображающий значения полей и позволяющий выбирать значения полей из списка. Более того, пункты списка можно задавать, используя другой источник данных. ComboBox - объект подобный объекту ListBox, однако информация отображается не в списке, а выпадающем списке. MaskedTextBox - нестандартный объект, предназначенный для отображения и ввода информации по заранее заданному шаблону (маске). Этот объект может быть создан только при помощи панели объектов и его подключение осуществляется либо перетаскиванием на него поля из окна "Data Sources", либо заданием его свойств вручную. По своим свойствам он ничем не отличается от объекта TextBox. Единственное дополнительное свойство у этого объекта это свойство Mask. Для этого нужно щелкнуть по кнопке действий объекта в верхнем правом углу объекта. Затем в списке действий выбрать пункт "Edit Mask". В появившемся окне выбрать шаблон ввода, то есть маску ( Mask ). Замечание: Тип данных отображаемой информации должен совпадать с типом данных маски. Замечание: Объекты ListBox и ComboBox могут использоваться для заполнения полей с кодами, то есть списки заполняются информацией из одной таблицы, а при выборе пункта списка его код подставляется в другую таблицу. Для этого на форму располагают не подключенный ListBox или ComboBox, затем открываем его меню действий. В меню действий в указанной последовательности выполняют следующие шаги: • Установить галочку "Use Data Bound Items", • В выпадающем списке "Data Source" выбрать пункт "Other Data Source" и там выбрать нужную таблицу. • В выпадающем списке "Display Member" и указываем поле, которое отображается в списке. • В выпадающем списке "Value Member" указываем поле, которое подставляем при выборе пункта списка. • В выпадающем списке "Selected Value" указываем поле, куда подставляется выбранное в "Value Member" значение. Программное управление информационной системой В Visual Studio 2008 добавлять, удалять записи и перемещаться по ним можно как используя объект Navigator, так и используя обычные кнопки. Рассмотрим создание кнопок для управления записями. В Visual Studio 2008 отсутствует объект "RecordSet" все операции с записями осуществляются с использованием объекта "BindingSource". В Visual Basic 2008 для добавления новой записи из таблицы "Студенты" используется команда вида СтудентыBindingSource.AddNew. Вместо метода AddNew можно использовать методы: • MoveNext (перейти к следующей); • MoveFirst (Перейти к первой); • Move Previous (Перейти к предыдущей); • Move Last (Перейти к последней); • Delete (Удалить запись). У объекта BindingSource имеется свойство Filter. Оно аналогично Filter у объекта RecordSet в Visual Basic 6.0. Его использование ничем не отличается от исполнения такого же свойства в Visual Basic 6.0. То есть в свойстве Filter задаётся строка, определяющая условие отбора записей в динамических фильтрах, выполняемых на стороне клиента. Данная строка имеет следующий синтаксис: <Поле1><Оператор1><Выражение1> [AND|OR <Поле2><Оператор2><Выражение2>…] Здесь: • <Поле1>, <Поле2>... - поля на которые накладываются условия; • <Оператор1>, <Опрераторы2> - операторы сравнения, участвующие в условиях; • <Выражение1>, <Выражение2> - выражения с которыми сравниваются поля. Под выражениями понимаются, константы, переменные, формулы, функции и свойства объектов Пример: Из таблицы "Студенты" необходимо отобразить студента, у которого значение поля ФИО равно "Петров". СтудентыBindingSource.Filter = "ФИО = 'Петров'" Обычно при формировании запроса при помощи свойства Filter задания условий отбора используют либо списки ListBox, либо выпадающие списки ComboBox. Замечание: Если мы используем ComboBox для создания динамического фильтра, то в меню действий параметры "Value Member" и "Selected Value" настраивать не надо. Пример: Имеется таблица "Студенты", которая отображается на форме в DataGridView. Необходимо на форме поместить ComboBox с фамилиями студентов. При выборе ФИО и нажатием на кнопку отобразить данные только по выбранному студенту. В этом случае в меню действий ComboBox в параметре "Data Source" указываем "Other Data Source/Студенты". Затем в "Display Member" выбираем ФИО. В коде кнопки прописываем следующую команду: СтудентыBindingSource.Filter = "ФИО='" & ComboBox1.Text & "'" После нажатия кнопки в DataGridView отображаются данные по студенту, выбранному в выпадающем списке ComboBox1.