Корпоративная база данных является центральным звеном корпоративной информационной системы и позволяет создать единое информационное пространство корпорации. Корпоративные базы данных

Поделитесь работой в социальных сетях

Если эта работа Вам не подошла внизу страницы есть список похожих работ. Так же Вы можете воспользоваться кнопкой поиск

PAGE 15

ТЕМА V. КОРПОРАТИВНЫЕ БАЗЫ ДАННЫХ

ЛЕКЦИЯ 8

V .1. Организация данных в корпоративных системах. Корпоративные базы данных.

V .2. СУБД и структурные решения в корпоративных системах.

V .3. Технологии Internet / Intranet и корпоративные решения по доступу к базам данных.

V .1. ОРГАНИЗАЦИЯ ДАННЫХ В КОРПОРАТИВНЫХ СИСТЕМАХ. КОРПОРАТИВНЫЕ БАЗЫ ДАННЫХ

Корпоративная база данных является центральным звеном корпоративной информационной системы и позволяет создать единое информационное пространство корпорации. Корпоративные базы данных (рис.1.1).

Существуют различные определения баз данных.

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

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

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

Цель создания баз данных как формы хранения данных  построение системы данных, не зависящих от принятых алгоритмов (программного обеспечения), применяемых технических средств, физического расположения данных в ЭВМ. База данных предполагает многоцелевое использование (несколько пользователей, множество форм документов и запросов одного пользователя).

Основные требования к базам данных :

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

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

База знаний (БЗ)  совокупность баз данных и используемых правил, полученных от лиц, принимающих решения. База знаний является элементом экспертных систем.

Следует различать различные способы представления данных .

Физические данные – это данные, хранящиеся в памяти ЭВМ.

Логическое представление данных соответствует пользовательскому представлению физических данных. Различие между физическим и соответствующим логическим представлением данных состоит в том, что последнее отражает некоторые важные взаимосвязи между физическими данными.

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

Рис. 1.1. Структура взаимодействия подразделений с информационными ресурсами корпорации.

Корпоративные базы данных бывают сосредоточенные (централизованные ) и распределенные .

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

Рис.1.2. Схема гетерогенной централизованной базы данных

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

• Большой поток обмена данными;
• Высокий трафик в сети;
• Низкая надежность;
• Низкая общая производительность.

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

• Более высокая степень одновременности обработки вследствие распределения нагрузки;
• Улучшение использования данных на местах при выполнении удаленных (дистанционных) запросов;
• Меньшие затраты;
• Простота управления локальными базами.

Затраты на создание сети, в узлах которой находятся рабочие станции (малые ЭВМ), гораздо ниже, чем затраты на создание аналогичной системы с использованием большой ЭВМ. На Рис.1.3 приведена логическая схема распределенной базы данных.

Рис.1.3. Распределенная база данных корпорации.

Дадим следующее определение распределенной базы данных.

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

Важнейшие требования к характеристикам распределенной базы данных таковы:

• Масштабируемость;
• Совместимость;
• Поддержка различных моделей данных;
• Переносимость;
• Прозрачность расположения;
• Автономность узлов распределенной базы данных (Site Autonomy);
• Обработка распределенных запросов;
• Выполнение распределенных транзакций.
• Поддержка однородной системы безопасности.

Прозрачность расположения позволяет пользователям работать с базами данных, не зная ничего об их расположении. Автономность узлов распределенной базы данных означает, что ведение каждой базы может происходить независимо от других. Распределенный запрос - это такой запрос (SQL-предложение), в ходе выполнения которого происходит доступ к объектам (таблицам или представлениям) разных баз данных. При выполнении распределенных транзакций осуществляется согласованное управление (concurrency control) всеми вовлеченными базами данных. Oracle7 использует технологию двухфазной передачи информации для выполнения распределенных транзакций.

Базы данных, составляющие распределенную базу данных, не обязательно должны быть однородными (т.е. вестись одной СУБД) или обрабатываться в среде одной и той же операционной системы и/или на компьютерах одного и того же типа. Например, одна база данных может быть базой Oracle на компьютере SUN с операционной системой SUN OS(UNIX), вторая база данных может вестись СУБД DB2 на мейнфрейме IBM 3090 с операционной системой MVS, а для ведения третьей базы может использоваться СУБД SQL/DS также на мейнфрейме IBM, но с операционной системой VM. Обязательно только одно условие - все машины с базами данных должны быть доступны по сети, в которую они входят.

Основная задача распределенной базы данных – распределение данных по сети и обеспечения доступа к ней. Существуют следующие способы решения этой задачи:

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

При создании распределенной базы данных на концептуальном уровне приходится решать следующие задачи:

• Необходимо иметь единую концептуальную схему всей сети. Это обеспечит логическую прозрачность данных для пользователя, в результате чего он сможет сформировать запрос ко всей базе, находясь за отдельным терминалом (он как бы работает с централизованной базой данных).
• Необходима схема, определяющая местонахождение данных в сети. Это обеспечит прозрачность размещения данных, благодаря которой пользователь может не указывать, куда переслать запрос, чтобы получить требуемые данные.
• Необходимо решить проблему неоднородности распределенных баз данных. Распределенные базы могут быть однородными и неоднородными в смысле аппаратных и программных средств. Проблема неоднородности сравнительно легко решается, если распределенная база данных является неоднородной в смысле аппаратных средств, но однородной в смысле программных средств (одинаковые СУБД в узлах). Если же в узлах распределенной системы используются разные СУБД, необходимы средства преобразования структур данных и языков. Это должно обеспечить прозрачность преобразования в узлах распределенной базы данных.
• Необходимо решить проблему управления словарями. Для обеспечения всех видов прозрачности в распределенной базе данных нужны программы, управляющие многочисленными словарями и справочниками.
• Необходимо определить методы выполнения запросов в распределенной базе данных. Методы выполнения запросов в распределенной базе данных отличаются от аналогичных методов в централизованных базах, так как отдельные части запросов нужно выполнять на месте расположения соответствующих данных и передавать частичные результаты на другие узлы; при этом должна быть обеспечена координация всех процессов.
• Необходимо решить проблему параллельного выполнения запросов. В распределенной базе нужен сложный механизм управления одновременной обработкой, который, в частности, должен обеспечить синхронизацию при обновлениях информации, что гарантирует непротиворечивость данных.
• Необходима развитая методология распределения и размещения данных, включая расщепление, является одним из основных требований к распределенной базе данных.

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

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

Для реализации машины баз данных были разработаны параллельные и ассоциативные архитектуры, как альтернатива однопроцессорной фоннеймановской структуре, позволяющие работать с большими объемами информации в реальном масштабе времени.

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

Информационные хранилища. Сегодня многие признают, что уже сейчас в большинстве компаний эксплуатируется несколько БД и, для успешной работы с информацией, требуются не просто разнотипные базы данных, а разные поколения СУБД. Согласно статистике, в каждой организации используется в среднем 2,5 различных СУБД. Стала очевидной необходимость "изолировать" бизнес компаний, вернее, людей, занимающихся этим бизнесом, от технологических особенностей баз данных, предоставить пользователям единый взгляд на корпоративную информацию независимо от того, где она физически хранится. Это стимулировало появление технологии информационных хранилищ (Data Warehousing, DW ).

Основная цель DW - создание единого логического представления данных, содержащихся в разнотипных БД, или, другими словами, единой модели корпоративных данных.

Новый виток развития DW стал возможным благодаря совершенствованию информационных технологий в целом, в частности появлению новых типов баз данных на основе параллельной обработки запросов, которые в свою очередь опирались на достижения в области параллельных компьютеров. Были созданы программы-конструкторы запросов с интуитивным графическим интерфейсом, позволившие легко строить сложные запросы к БД. Разнообразное ПО промежуточного слоя (midleware) обеспечило связь между разнотипными базами данных , и, наконец, резко подешевели устройства хранения информации .

В структуре корпорации может присутствовать банк данных.

Банк данных – функционально-организационная компонента в автоматизированных системах управления и информационно-вычислительных системах, осуществляющая централизованное информационное обеспечение коллектива пользователей или совокупности решаемых в системе задач.

Банк данных рассматривают как информационно-справочную систему, основное назначение которой состоит:

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

Таким образом, современный банк данных представляет собой сложный программно-технический комплекс, в состав которого входят технические, системные и сетевые средства, базы данных и СУБД, информационно-поисковые системы различного назначения.

V .2. СУБД И СТРУКТУРНЫЕ РЕШЕНИЯ В КОРПОРАТИВНЫХ СИСТЕМАХ

Системы управления базами данных и знаний

Важной составляющей современных информационных систем являются системы управления базами данных (СУБД).

СУБД – комплекс программных и языковых средств, предназначенных для создания, ведения и использования баз данных.

Система управления базами данных обеспечивает доступ систем обработки данных к базам данных. Как уже отмечалось, важную роль СУБД приобретают при создании корпоративных информационных систем и, особо важную роль, при создании информационных систем использующих распределенные информационные ресурсы, базирующиеся на современных сетевых компьютерных технологиях.

Основная особенность современных СУБД - это то, что современные СУБД поддерживают такие технологии как :

• Технологию клиент/сервер.
• Поддержка языков БД. Это язык определения схемы БД (SDL - Schema Definition Language), язык манипулирования данными (DML - Data Manipulation Language), интегрированные языки SQL (Structured Queue Language ), QDB (Query - By - Example ) и QMF (Query Management Facility ) – развитое периферийное средство спецификации запросов и генерации отчетов для DB 2 и т. д.;
• Непосредственное управление данными во внешней памяти.
• Управление буферами оперативной памяти.
• Управление транзакциями . OLTP – технология (On -Line Transaction Processing), OLAP – технология (On -Line Analysis Processing) для DW.
• Обеспечить защиту и целостность данных. Использование системы разрешается лишь пользователям, имеющим право доступа к данным. При выполнении пользователями операций над данными поддерживается согласованность хранящихся данных (целостность). Это важно в корпоративных многопользовательских информационных системах.
• Журнализация.

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

• Независимость данных.
• Универсальность. СУБД должна обладать мощными средствами поддержки концептуальной модели данных для отображения пользовательских логических представлений.
• Совместимость. СУБД должна сохранять работоспособность при развитии программного и аппаратного обеспечения.
• Неизбыточность данных. В отличие от файловых систем база данных должна представлять собой единую совокупность интегрированных данных.
• Защита данных. СУБД должна обеспечивать защиту от несанкционированного доступа.
• Целостность данных. СУБД должна предотвращать нарушение базы данных пользователями.
• Управление одновременной работой. СУБД должна предохранять базу данных от рассогласований в режиме коллективного доступа. Для обеспечения согласованного состояния базы все запросы пользователей (транзакции) должны выполняться в определенном порядке.
• СУБД должна быть универсальной. Она должна поддерживать разные модели данных на единой логической и физической основе.
• СУБД должна поддерживать как централизованные, так и распределенные базы данных и, таким образом, стать важным звеном вычислительных сетей.

Рассматривая СУБД как класс программных продуктов, ориентированных на поддержание в автоматизированных системах баз данных, можно выделить два наиболее существенных признака, определяющих типы СУБД. Согласно им, СУБД можно рассматривать с двух точек зрения:

• их возможностей по отношению к распределенным (корпоративным) базам;
• их отношения к типу реализуемой в СУБД модели данных.

По отношению к корпоративным (распределенным) базам данных условно можно выделить следующие типы СУБД:

• СУБД «рабочего стола». Эти продукты, в первую очередь ориентированы на работу с персональными данными (данные "рабочего стола"). Они имеют наборы команд для совместного использования общих БД, но небольшого размера (типа малого офиса). Прежде всего, это СУБД типа Ассеss, dВАSЕ, Рагаdох, ЕохРго. Почему Ассеss, dВАSЕ, Рагаdох, ЕохРго имеют неудовлетворительный доступ к корпоративным данным. Дело в том, что не существует простого способа преодолеть барьер между персональными и корпоративными данными. И суть даже не в том, что механизм СУБД персональных данных (или малого офиса) ориентирован на доступ к данным через многие шлюзы, межсетевые продукты и т.д. Проблема состоит в том, что эти механизмы обычно связаны с полной передачей файлов и отсутствием разветвленной поддержки индексов, в результате чего очереди к серверу практически останавливают работу в больших системах.
• Специализированные высокопроизводительные многопользовательские СУБД. Такие СУБД характеризуются наличием многопользовательского ядра системы, языка манипулирования данными и следующими функциями, характерными для развитых многопользовательских СУБД:
• организацией буферного пула;
• наличием системы обработки очередей транзакций;
• наличием механизмов многопользовательской блокировки данных;
• ведением журнала транзакций;
• наличием механизмов разграничения доступа.

Это СУБД типа Oracle, DВ2, SQL/Server, Informix, Sybase, ADABAS, Titanium и другие предоставляют широкий сервис для обработки корпоративных БД.

При работе с базами данных используется механизм транзакций.

Транзакция – это логическая единица работы.

Транзакция - это последовательность операторов манипулирования данными, выполняющаяся как единое целое (все или ничего) и переводящая базу данных из одного целостного состояния в другое целостное состояние .

Транзакция обладает четырьмя важными свойствами, известными как свойства АСИД :

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

Транзакция обычно начинается автоматически с момента присоединения пользователя к СУБД и продолжается до тех пор, пока не произойдет одно из следующих событий:

• Подана команда COMMIT WORK (зафиксировать транзакцию).
• Подана команда ROLLBACK WORK (откатить транзакцию).
• Произошло отсоединение пользователя от СУБД.
• Произошел сбой системы.

Для пользователя она носит, как правило, атомарный характер . На самом деле это сложный механизм взаимодействия пользователь (приложение) – база данных. Программное обеспечение корпоративных систем используют механизм обработки транзакций в реальном времени (On-lineTransaction Processing Systems, OLTP ), в частности программы бухгалтерского учета, программное обеспечение приема и обработки клиентских заявок, финансовые приложения, производят массу информации. Эти системы рассчитаны (и соответствующим образом оптимизированы) на обработку больших объемов данных, выполнение сложных транзакций и интенсивных операций чтения/записи.

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

Доставкой информации конечному пользователю - занимаются системы аналитической обработки данных в реальном времени (On-line Analytical Processing, OLAP) , которые обеспечивают исключительно простой доступ к данным за счет удобных средств генерации запросов и анализа результатов. В OLAP-системах ценность информационного товара увеличивается благодаря применению разнообразных методов анализа и статистической обработки. Кроме того, эти системы оптимизированы с точки зрения скорости извлечения данных, сбора обобщенной информации и ориентированы на рядовых пользователей (имеют интуитивно понятный интерфейс). Если OLTP-система выдает ответы на простые вопросы типа "каков был уровень продаж товара N в регионе M в январе 199х г.?", то OLAP- системы готовы к более сложным запросам пользователей, например: "Дать анализ продаж товара N по всем регионам по плану на второй квартал в сравнении с двумя предыдущими годами".

Архитектура клиент/сервер

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

Сервер		База данных
Компьютер-сервер
Сеть
IBM-совместимый ПК	IBM-совместимый ПК	IBM-совместимый ПК
Клиенты		Приложения

Рис. 2.1. Система архитектуры клиент-сервер

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

Сервер (Server ) – это объект (ЭВМ), предоставляющий услуги другим объектам по их запросам.

Как следует уже из самого термина, главная функция компьютера-сервера заключается в обслуживании потребностей клиента. Термин "Сервер" используется для обозначения двух различных групп функций: файл-сервер и сервер баз данных (далее эти термины означают в зависимости от контекста либо программное обеспечение, реализующее указанные группы функций, либо компьютеры с этим программным обеспечением). Файл-серверы не предназначены для выполнения операций с базами данных, их основная функция - разделение файлов между несколькими пользователями, т.е. обеспечение одновременного доступа многих пользователей к файлам на компьютере - файл-сервере. Примером файл-сервера является операционная система NetWare компании Novell. Сервер баз данных можно установить и привести в действие на компьютере -- файл-сервере. СУБД Oracle в виде NLM (Network Loadable Module) выполняется в среде NetWare на файл-сервере.

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

Одно из важных требований к серверу - это то, что операционная система, в среде которой размещен сервер баз данных, должна быть многозадачной (и, желательно, но не обязательно, многопользовательской). Например, СУБД Oracle, установленная на персональном компьютере с операционной системой MS-DOS (или PC-DOS), не удовлетворяющей требованию многозадачности, не может использоваться как сервер баз данных. И та же СУБД Oracle, установленная на компьютере с многозадачной (хотя и не многопользовательской) операционной системой OS/2, может быть сервером баз данных. Многие разновидности систем UNIX, MVS, VM и некоторые другие операционные системы являются и многозадачными, и многопользовательными.

Распределенные вычисления

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

• Распределенная база данных;
• Распределенная обработка данных.

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

Существует много типов серверов:

• Сервер баз данных;
• Сервер печати;
• Сервер удаленного доступа;
• Факс-сервер;
• Web -сервер и т.д.

В основе базовой технологии Клиент/сервер лежат такие базовые технологии, как:

• Технологии операционных систем, концепция взаимодействия открытых систем, создание объектно-ориентированных сред функционирования программ;
• Телекоммуникационные технологии;
• Сетевые технологии;
• Технологии графического пользовательского интерфейса (GUI );
• И т.д.

Преимущества технологии клиент-сервер:

• Технология клиент/сервер позволяет производить вычисления на неоднородных вычислительных средах. Независимость от платформ: доступ к разнородным сетевым средам, в состав которых входят компьютеры разных типов с различными операционными системами.
• Независимость от источников данных: доступ к информации разнородных баз данных. Примеры таких систем -- DB2, SQL/DS, Oracle, Sybase.
• Баланс загрузки клиента и сервера.
• Выполнение вычислений там, где это происходит наиболее эффективно;
• Предоставляют возможность эффективного масштабирования;
• Межплатформные вычисления . Межплатформные вычисления определяются просто как реализация технологий в неоднородных вычислительных средах. Здесь должны быть обеспечены следующие возможности:
• Приложение должно выполняться на нескольких платформах;
• На всех платформах оно должно иметь один и тот же интерфейс и логику работы;
• Приложение должно интегрироваться с родной операционной средой;
• Оно должно одинаково вести себя на всех платформах;
• Для него должна предусматриваться простая и согласованная поддержка.

 Распределенные вычисления. Распределенные вычисления предусматривают распределение работ между несколькими вычислительными машинами (правда, распределенные вычисления более широкое понятие).

 Разукрупнение. Разукрупнение – перенос приложений для больших ЭВМ на малые компьютерные платформы.

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

 Сокращение общего времени выполнения приложения;

 Уменьшение использования клиентом памяти;

 Сокращение сетевого трафика.

• Возможность работы с мультимедиа: к настоящему времени создано немало программ работы с мультимедиа для ПК. Подобных программ для конфигурации терминал-хост либо нет, либо они очень дороги.
• Возможность привлечения больших вычислительных ресурсов для операций с базами данных: поскольку приложения выполняются на компьютерах-клиентах, на компьютере-сервере для операций с базами данных высвобождаются дополнительные (по сравнению с конфигурацией терминал-хост) ресурсы, такие, как вычислительные ресурсы центрального процессора и оперативная память.
• Более высокая продуктивность работы программистов: производительность труда программистов возрастает благодаря использованию таких средств, как SQL*Forms и CASE: они позволяют разрабатывать приложения быстрее, чем такие языки программирования, как C, PL1 или COBOL.
• Повышение продуктивности работы конечных пользователей: в настоящее время многие конечные пользователи освоили такие системы, как Lotus, Paradox, Word Perfect, Harvard Graphics и т.д.

Интерфейс серверной части определен и фиксирован. Поэтому возможно создание новых клиентских частей существующей системы (пример интероперабельности на системном уровне).

Рис. 2.2. Иллюстрация доступа клиентов к общему ресурсу сервера.

Как внедрить технологию клиент-сервер

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

• компьютер-сервер базы данных;
• компьютеры-клиентов;
• коммуникационная сеть;
• сетевое программное обеспечение;
• прикладное программное обеспечение.

Язык SQL . Язык запросов высокого уровня - SQL (Structured Query Language ) служит для реализации запросов к базам данных, таких как ЯМД, ЯОД и ПЯД и принят в качестве стандарта. Язык SQL первоначально был принят в качестве языка данных программных изделий фирмы IBM и ЯМД реляционной СУБД SYSTEM R фирмы IBM . Важной особенностью языка SQL заключается в том, что один и тот же язык представляется через два различных интерфейса, а именно: через интерактивный интерфейс и через интерфейс прикладного программирования (динамический SQL ). Динамический SQL состоит из множества возможностей встроенного языка SQL , предусмотренных специально для конструирования интерактивных приложений, где под интерактивным приложением понимается программа, которая написана для поддержки обращения к базе данных конечного пользователя, работающего на интерактивном терминале. Язык SQL обеспечивает выполнение функций определения, манипулирования и управления данными баз данных и является прозрачным для пользователя с точки зрения реализуемой СУБД.

Рис. 2.3. Схема выполнения запросов пользователя к распределенным базам данных.

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

Модель данных состоит из трех компонент :

• Структура данных для представления с точки зрения пользователя на базу данных.
• Допустимые операции, выполняемые на структуре данных. Необходимо иметь возможность работать с этой структурой при помощи различных операций ЯОД и ЯМД. Богатая структура ничего не стоит, если нет возможности оперировать ее содержимым.
• Ограничения для контроля целостности. Модель данных должна быть обеспечена средствами, позволяющими сохранять ее целостность и защищать ее. В качестве примера рассмотрим два следующих ограничения:
• Каждое поддерево должно иметь исходный узел. В иерархических базах данных нельзя хранить порожденные узлы без исходного узла.
• В отношении реляционной базы данных не может быть одинаковых кортежей. Для файла это требование требует уникальности всех записей.

Одной из важнейших характеристик работы СУБД является возможность связывать объекты.

Существуют следующие виды связей между объектами:

• Один-к-Одному (1:1) . Один объект одного множества может быть связан с одним объектом другого множества.
• Один-ко-Многим (1:M) . Один объект одного множества может быть связан со многими объектами другого множества.
• Многие-ко-Многим (M:N) . Один объект одного множества может быть связан со многими объектами другого множества, но при этом один объект другого множества может быть связан со многими объектами первого множества.
• Разветвленная . Один объект одного множества может быть связан с объектами многих множеств.
• Рекурсивная . Один объект данного множества может быть связан объектом этого же множества.

Существуют следующие основные модели данных :

• Реляционная модель данных.
• Иерархическая модель данных.
• Неполная сетевая модель данных.
• Модель данных CODASYL.
• Расширенная сетевая модель данных.

V .3. ТЕХНОЛОГИИ INTERNET / INTRANET И КОРПОРАТИВНЫЕ РЕШЕНИЯ ПО ДОСТУПУ К БАЗАМ ДАННЫХ

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

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

Общим решением проблемы мобильности систем, основанных на архитектуре "клиент-сервер" является опора на программные пакеты, реализующие протоколы удаленного вызова процедур (RPC - Remote Procedure Call). При использовании таких средств обращение к сервису в удаленном узле выглядит как обычный вызов процедуры. Средства RPC, в которых, естественно, содержится вся информация о специфике аппаратуры локальной сети и сетевых протоколов, переводит вызов в последовательность сетевых взаимодействий. Тем самым, специфика сетевой среды и протоколов скрыта от прикладного программиста.

При вызове удаленной процедуры программы RPC производят преобразование форматов данных клиента в промежуточные машинно-независимые форматы и затем преобразование в форматы данных сервера. При передаче ответных параметров производятся аналогичные преобразования.

Другие похожие работы, которые могут вас заинтересовать.вшм>
6914.		Понятие базы данных	11.56 KB
	Базой данных является представленная в объективной форме совокупность самостоятельных материалов статей расчетов нормативных актов судебных решений и иных подобных материалов систематизированных таким образом чтобы эти материалы могли быть найдены и обработаны с помощью электронной вычислительной машины Гражданский кодекс РФ ст. База данных организованная в соответствии с определёнными правилами и поддерживаемая в памяти компьютера совокупность данных характеризующая актуальное состояние некоторой...
8064.		Распределенные базы данных	43.66 KB
	Распределенные базы данных Под распределенной базой данных РБД понимается набор логически связанных между собой разделяемых данных которые физически распределены по разных узлам компьютерной сети. Доступ к данным не должен зависеть от наличия или отсутствия реплик данных. Система должна автоматически определять методы выполнения соединения объединения данных сетевой канал способный справиться с объёмом передаваемой информации и узел имеющий достаточную вычислительную мощность для соединения таблиц. СУРБД должна быть способной...
20319.		БАЗЫ ДАННЫХ И ИХ ЗАЩИТА	102.86 KB
	Оперативные сетевые базы данных появились в середине 1960-х. Операции над оперативными базами данных обрабатывались в интерактивном режиме с помощью терминалов. Простые индексно-последовательные организации записей быстро развились к более мощной модели записей, ориентированной на наборы. За руководство работой Data Base Task Group (DBTG), разработавшей стандартный язык описания данных и манипулирования данными, Чарльз Бахман получил Тьюринговскую премию.
5031.		Разработка базы данных Библиотека	11.72 MB
	Технология проектирования баз данных. Определение взаимосвязей между сущностями и создание модели данных. Основные идеи современной информационной технологии базируются на концепции согласно которой данные должны быть организованы в базы данных с целью адекватного отображения изменяющегося реального мира и удовлетворения информационных потребностей пользователей. Эти базы данных создаются и функционируют под управлением специальных программных комплексов называемых системами управления базами данных СУБД.
13815.		ИЕРАРХИЧЕСКАЯ МОДЕЛЬ БАЗЫ ДАННЫХ	81.62 KB
	Основные идеи современной информационной технологии базируются на концепции баз данных согласно которой основой информационной технологии являются данные организованные в базах данных адекватно отражающие состояние той или иной предметной области и обеспечивающие пользователя актуальной информацией в этой предметной области. Необходимо признать тот факт что данные являются...
14095.		Разработка базы данных библиотеки	11.72 MB
	Увеличение объема и структурной сложности хранимых данных, расширение круга пользователей информационных систем привели к широкому распространению наиболее удобных и сравнительно простых для понимания реляционных (табличных) СУБД.
5061.		Создание базы данных поликлиники	2.4 MB
	Развитие средств вычислительной техники и информационных технологий обеспечило возможности для создания и широкого применения автоматизированных информационных систем (АИС) разнообразного назначения. Разрабатываются и внедряются информационные системы управления хозяйственными и техническими объектами
13542.		Базы данных геологической информации	20.73 KB
	В последнее время широкими темпами происходит внедрение компьютерных технологий и, в частности баз данных, в научную сферу. Этот процесс не обходит стороной и геологию, так как именно в естественных науках имеется необходимость для хранения и обработки больших объемов информации.
9100.		Базы данных. Основные понятия	26.28 KB
	База данных – это совокупность сведений о конкретных объектах реального мира в какой-либо предметной области экономика менеджмент химия и т. Целью информационной системы является не просто хранение данных об объектах но и манипулирование этими данными учитывая связи между объектами. Каждый объект характеризуется каким-либо набором данных свойств которые в БД называются атрибутами.
5240.		Создание базы данных «Деканат ВУЗа»	1.57 MB
	База данных (БД) - это совокупность взаимосвязанных, хранящихся вместе на внешних носителях памяти компьютера данных, при наличии такой организации и минимальной избыточности, которая допускает их использование оптимальным образом для одного или нескольких приложений

Зайцев С.Л., к.ф.-м.н.

Повторяющиеся группы

Повторяющимися группами являются атрибуты, для которых единственный экземпляр сущности может иметь более одного значения. Например, персона может иметь более одного навыка. Если, с точки зрения требований бизнеса, нам нужно знать уровень владения навыком для каждого, и каждая персона может иметь только два навыка, мы можем создать сущность, показанную на рис. 1.6. Здесь представлена сущность ПЕРСОНА с двумя атрибутами для хранения навыков и уровня владения навыками для каждого.

Рис. 1.6. В данном примере используются повторяющиеся группы.

Проблема повторяющихся групп заключается в том, что мы не можем точно знать, сколько навыков может иметь персона. В реальной жизни у некоторых людей есть один навык, у некоторых - несколько, а у некоторых - пока ни одного. На рисунке 1.7 представлена модель, приведенная к первой нормальной форме. Обратите внимание на добавленный Идентификатор навыка , который уникально определяет каждыйНАВЫК.

Рис. 1.7. Модель, приведенная к первой нормальной форме.

Один факт в одном месте

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

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

В предыдущем примере НАВЫК зависит отИдентификатора персоны и отИдентификатора навыка. Это значит, что у вас не появитсяНАВЫК до тех пор, пока не появитсяПЕРСОНА, обладающая этим навыком. Это так же усложняет изменение Названия навыка. Необходимо найти каждую запись с Названием навыка и изменить ее для каждой Персоны, владеющей этим навыком.

На рисунке 1.8 представлена модель во второй нормальной форме. Заметьте, что добавлена сущность НАВЫК , и атрибут НАЗВАНИЕ навыка перенесен в эту сущность. Уровень навыка остался, соответственно, на пересеченииПЕРСОНЫ и НАВЫКА.

Рис. 1.8. Во второй нормальной форме повторяющаяся группа вынесена в другую сущность. Это обеспечивает гибкость при добавлении необходимого количества Навыков и изменении Названия навыка или Описания навыка в одном месте.

Каждый атрибут зависит от ключа

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

Рис. 1.9. В третьей нормальной форме Название школы и Географический регион перенесены в сущность, где их значения зависят от ключа.

Отношения многие-ко-многим

Отношения многие-ко-многим отражают реальность окружающего мира. Обратите внимание, что на рисунке 1.9 существует отношение многие-ко-многим междуПЕРСОНОЙ иШКОЛОЙ . Отношение точно отражает тот факт, чтоПЕРСОНА может учиться во многихШКОЛАХ и вШКОЛЕ может учиться многоПЕРСОН. Для достижения четвертой нормальной формы создается ассоциативная сущность, которая устраняет отношение моногие-ко-многим за счет формирования отдельной записи для каждой уникальной комбинации школы и персоны. На рисунке 1.10 представлена модель в четвертой нормальной форме.

Рис. 1.10. В четвертой нормальной форме отношение моногие-ко-многим между ПЕРСОНОЙ и ШКОЛОЙ разрешается за счет введения ассоциативной сущности, в которой отводится отдельная запись для каждой уникальной комбинации ШКОЛЫ и ПЕРСОНЫ.

Формальные определения нормальных форм

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

В заданном отношении R атрибут Y функционально зависит от атрибута X. В символьном виде R.X -> R.Y (читается как "R.X функционально определяет R.Y") - в том и только в том случае если каждое значение X в R ассоциируется строго с одним значением Y в R (в каждый конкретный момент времени). Атрибуты X и Y могут быть составными (Дейт К. Дж. Введение в системы баз данных. 6-е издание. Изд. Вильямс: 1999, 848 с.).

Отношение R соответствует первой нормальной форме (1NF) тогда и только тогда, когда все принадлежащие ему домены содержат только атомарные значения (Дейт, там же).

Отношение R соответствует второй нормальной форме (2NF) тогда и только тогда, когда оно соответствует 1NF, и каждый неключевой атрибут полностью зависит от первичного ключа (Дейт, там же).

Отношение R соответствует третьей нормальной форме (3NF) тогда и только тогда, когда оно соответствует 2NF, и каждый неключевой атрибут не транзитивно зависит от первичного ключа (Дейт, там же).

Отношение R соответствует нормальной форме Бойса-Кодда (BCNF) тогда и только тогда, когда каждый детерминант является кандидатом на использование в качестве ключа.

ПРИМЕЧАНИЕ Ниже приводится краткое объяснение некоторых аббревиатур, используемых в определениях Дейта.

MVD (multi-valued dependency) - многозначная зависимость. Используется только для сущностей с тремя и более атрибутами. При многозначной зависимости значение атрибута зависит только от части первичного ключа.

FD (functional dependency) - функциональная зависимость. При функциональной зависимости значение атрибута зависит от значения другого атрибута, который не является частью первичного ключа.

JD (join dependency) - зависимость по объединению. При зависимости по объединению первичный ключ родительской сущности прослеживается до потомков, по меньшей мере, третьего уровня сохраняя способность использоваться в объединении по исходному ключу.

Отношение соответствует четвертой нормальной форме (4NF) тогда и только тогда, когда в R существует MVD, например A®®B. При этом все атрибуты R функционально зависят от A. Другими словами, в R присутствуют только зависимости (FD или MVD) формы K®X (т.е. функциональная зависимость атрибута X от кандидата на использование в качестве ключа K). Соответственно R отвечает требованиям 4NF, если оно соответствует BCNF и все MVD фактически являются FD (Дейт, там же).

Для пятой нормальной формы отношение R удовлетворяет зависимости по объединению (JD)*(X, Y, …, Z) тогда и только тогда, когда R эквивалентно его проекциям на X, Y,..., Z, где X, Y,..., Z подмножества множества атрибутов R.

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

Бизнес-нормальные формы

В своей книге Клайв Финклештейн (Finklestein Cl. An Introduction to Information Engineering: From Strategic Planning to Information Systems. Reading, Massachusetts: Addison-Wesley, 1989) применил другой подход к нормализации. Он определяет бизнес-нормальные формы в терминах приведения к этим формам. Многие разработчики моделей, считают этот подход интуитивно более ясным и прагматичным.

Первая бизнес-нормальная форма (1BNF) выносит повторяющиеся группы в другую сущность. Эта сущность получает собственное имя и первичные (составные) ключевые атрибуты из исходной сущности и ее повторяющейся группы.

Вторая бизнес-нормальная форма (2BNF) выносит атрибуты, которые частично зависят от первичного ключа в другую сущность. Первичный (составной) ключ этой сущности является первичным ключом сущности, в которой он исходно находился, вместе с дополнительными ключами, от которых атрибут полностью зависит.

Третья бизнес-нормальная форма (3BNF) выносит атрибуты, не зависящие от первичного ключа, в другую сущность, где они полностью зависят от первичного ключа этой сущности.

Четвертая бизнес-нормальная форма (4BNF) выносит атрибуты, которые зависят от значения первичного ключа или являются необязательными, во вторичную сущность, где они полностью зависят от значения первичного ключа или где они должны (обязательно) присутствовать в этой сущности.

Пятая бизнес-нормальная форма (5BNF) проявляется как структурная сущность, если есть рекурсивная или другая зависимость между экземплярами вторичной сущности, или если рекурсивная зависимость существует между экземплярами ее первичной сущности.

Завершенная логическая модель данных

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

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

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

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

ПРИМЕЧАНИЕ Множественность связи описывает максимальное число экземпляров вторичной сущности, которые могут быть связаны с экземпляром исходной сущности. Необходимость существования или возможность отсутствия связи служит для определения минимального числа экземпляров вторичной сущности, которые могут быть связаны с экземпляром исходной сущности.

Физическая модель данных

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

В ERwin физическая модель является графическим представлением реально реализованной базы данных. Физическая база данных будет состоять из таблиц, столбцов и связей. Физическая модель зависит от платформы, выбранной для реализации, и требований к использованию данных. Физическая модель для IMS будет серьезно отличаться от такой же модели для Sybase. Физическая модель для OLAP-отчетов будет выглядеть иначе, чем модель для OLTP (оперативной обработки транзакций).

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

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

Сбор требований к использованию данных

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

Требования к доступу и производительности

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

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

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

Требования к формированию отчетов и стандартных запросов, помогающих администратору базы данных формировать индексы

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

Кроме председателя, секретаря и пользователей в сессии, посвященной требованиям к использованию, должны принимать участие разработчик модели, администратор базы данных и архитектор базы данных. Обсуждению должны подвергаться требования пользователя к историческим данным. Длительность периода времени, в течение которого хранятся данные, оказывает значительное влияние на размер базы данных. Часто более старые данные хранятся в обобщенном виде, а атомарные данные архивируются или удаляются.

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

Компоненты физической модели данных

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

Обратное проектирование

Когда логическая модель недоступна, возникает необходимость воссоздания модели из существующей базы данных. В ERwin этот процесс называется обратным проектированием. Обратное проектирование может производиться несколькими способами. Разработчик модели может исследовать структуры данных в базе данных и воссоздать таблицы в визуальной среде моделирования. Вы можете импортировать язык описания данных (DDL - data definitions language) в инструмент, который поддерживает проведение обратного проектирования (например, Erwin). Развитые средства, такие как ERwin, включают функции, обеспечивающие связь через ODBC с существующей базой данных, для создания модели путем прямого чтения структур данных. Обратное проектирование с использованием ERwin будет подробно обсуждаться в одной из последующих публикаций.

Использование корпоративных функциональных границ

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

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

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

Что такое корпоративная модель данных?

Корпоративная модель данных (EDM - enterprise data model) содержит сущности, атрибуты и отношения, которые представляют информационные потребности корпорации. EDM обычно подразделяется в соответствие с предметными областями, которые представляют группы сущностей, относящихся к поддержке конкретных нужд бизнеса. Некоторые предметные области могут покрывать такие специфические бизнес-функции, как управление контрактами, другие - объединять сущности, описывающие продукты или услуги.

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

EDM также включает специфические сущности, которые определяют область определения значений для ключевых атрибутов. Эти сущности не имеют родителей и определяются как независимые. Независимые сущности часто используются для поддержания целостности связей. Эти сущности идентифицируются несколькими различными именами, такими как кодовые таблицы, таблицы ссылок, таблицы типов или классификационные таблицы. Мы будем использовать термин "корпоративный бизнес-объект". Корпоративный бизнес-объект это сущность, которая содержит набор значений атрибутов, не зависящих ни от какой другой сущности. Корпоративные бизнес-объекты в рамках корпорации следует использовать единообразно.

Построение корпоративной модели данных путем наращивания

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

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

Понятие методологии моделирования

Существует несколько методологий визуального моделирования данных. ERwin поддерживает две:

IDEF1X (Integration Definition for Information Modeling - интегрированное описание информационных моделей).

IE (Information Engineering - информационная инженерия).

IDEF1X - хорошая методология и использование ее нотации широко распространено

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

IDEF1X- высоко структурированная методология моделирования данных, расширяющая методологию IDEF1, принятую в качестве стандарта FIPS (Federal Information Processing Standards - федеральный орган стандартов обработки информации). IDEF1X использует строго структурированный набор типов конструкций моделирования и приводит к модели данных, которая требует понимания физической природы данных до того, как такая информация может стать доступной.

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

Информационный инжиниринг

Клайва Финклештейна часто называют отцом информационного инжиниринга, хотя подобные же концепции излагал вместе с ним и Джеймс Мартин (Martin, James. Managing the Database Environment. Upper Saddle River, New Jersey: Prentice Hall, 1983.). Информационный инжиниринг использует для управления информацией подход, направляемый бизнесом, и применяет другую нотацию для представления бизнес-правил. IE служит расширением и развитием нотации и базовых концепций методологии ER, предложенной Питером Ченом.

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

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

Заключение

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

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

Модель данных состоит из логической и физической моделей, отображающих требования к информации и бизнес-правила. Логическая модель должна быть приведена к третьей нормальной форме. Третья нормальная форма ограничивает, добавляет, обновляет и удаляет аномалии структур данных для поддержки принципа "один факт в одном месте". Собранные требования к информации и бизнес-правила должны быть проанализированы и исследованы. Их необходимо сравнить с корпоративной моделью для гарантии того, что они не конфликтует с существующими моделями объектов, и включают в себя все необходимые объекты.

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

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

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

ПРИМЕЧАНИЕ Множественность связи описывает максимальное число экземпляров вторичной сущности, которые могут быть связаны с экземпляром исходной сущности. Необходимость существования или возможность отсутствия связи служит для определения минимального числа экземпляров вторичной сущности, которые могут быть связаны с экземпляром исходной

Всё чаще IT-специалисты обращают своё внимание на решения по управлению данными, основанные на стандартных отраслевых моделях данных и шаблонах бизнес-решений. Готовые к загрузке комплексные модели физических данных и отчёты бизнес-аналитики для конкретных сфер деятельности позволяют унифицировать информационную составляющую деятельности предприятия и значительно ускорить выполнение бизнес-процессов. Шаблоны решений позволяют поставщикам услуг использовать возможности нестандартной информации, скрытой в существующих системах, сокращая тем самым сроки выполнения проектов, затраты и риски. Например, реальные проекты показывают, что модель данных и шаблоны бизнес-решений могут сократить объём трудозатрат на разработку на 50%.

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

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

Пример модели “ГИС для органов власти и местного самоуправления”.

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

Помочь в облегчении и оптимизации этого процесса, в переводе ИТ-подхода на современный уровень как раз и призваны отраслевые модели данных.

Отраслевые модели данных от компании Esri

Модели данных под платформу Esri ArcGIS представляют собой рабочие шаблоны для применения в ГИС-проектах и создания структур данных для разных прикладных областей. Формирование модели данных включает создание концептуального дизайна, логической и физической структуры, которые затем можно использовать для построения персональной или корпоративной базы геоданных. ArcGIS предоставляет инструменты для создания и управления схемой базы данных, а шаблоны модели данных используются для быстрого запуска ГИС-проекта по разным сферам применения и отраслям. Специалисты Esri вместе с сообществом пользователей потратили значительное количество времени на разработку ряда шаблонов, которые могут обеспечить возможность быстрого начала проектирования базы геоданных предприятия. Эти проекты описаны и задокументированы на веб-сайте support.esri.com/datamodels . Ниже, в порядке их упоминания на этом сайте, представлен смысловой перевод названий отраслевых моделей Esri:

• Адресный реестр
• Сельское хозяйство
• Метеорология
• Базовые пространственные данные
• Биоразнообразие
• Внутреннее пространство зданий
• Учет парниковых газов
• Ведение административных границ
• Вооружённые силы. Разведка
• Энергетика (включая новый протокол ArcGIS MultiSpeak)
• Экологические сооружения
• МЧС. Пожарная охрана
• Лесной кадастр
• Лесное хозяйство
• Геология
• ГИС национального уровня (e-gov)
• Подземные и сточные воды
• Здравоохранение
• Археология и охрана памятных мест
• Национальная безопасность
• Гидрология
• Международная гидрографическая организация (IHO). Формат S-57 для ENC
• Ирригация
• Земельный кадастр
• Муниципальное правительство
• Морская навигация
• Государственный кадастр
• Нефтегазовые структуры
• Трубопроводы
• Растровые хранилища
• Батиметрия, рельеф морского дна
• Телекоммуникации
• Транспорт
• Водопровод, канализация, ЖКХ

Эти модели содержат все необходимые признаки отраслевого стандарта, а именно:

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

Специалисты Esri входят в экспертную группу независимых органов, которые рекомендуют к использованию различные отраслевые модели, например PODS (Pipeline Open Data Standards - открытый стандарт для нефтегазовой отрасли; в настоящее время имеется реализация PODS в качестве базы геоданных Esri PODS Esri Spatial 5.1.1) или база геоданных (БГД) из ArcGIS for Aviation, которая учитывает рекомендации ICAO и FAA, а также стандарт обмена навигационными данными AIXM 5.0. Кроме того, существуют рекомендованные модели, строго соответствующие существующим отраслевым стандартам, например S-57 и ArcGIS for Maritime (морские и прибрежные объекты), а также модели, созданные по результатам выполненных работ Esri Professional Services и являющиеся «де-факто» стандартами в соответствующей области. Например, GIS for the Nation и Local Government ("ГИС для органов государственной власти и местного самоуправления") оказали влияние на стандарты NSDI и INSPIRE, а Hydro и Groundwater (гидрология и грунтовые воды) активно используются в свободно доступном профессиональном пакете ArcHydro и коммерческих продуктах третьих фирм. Нужно отметить, что Esri поддерживает и стандарты "de-facto", например NHDI. Все предлагаемые модели данных документированы и готовы к использованию в IT-процессах предприятия. Сопроводительные материалы к моделям включают:

• UML-диаграммы связей сущностей;
• структуры данных, домены, справочники;
• готовые шаблоны баз геоданных в формате ArcGIS GDB;
• примеры данных и примеры приложений;
• примеры скриптов загрузки данных, примеры утилит анализа;
• справочники по предлагаемой структуре данных.

Компания Esri обобщает свой опыт построения отраслевых моделей в виде книг и локализует публикуемые материалы. Компанией Esri CIS локализованы и изданы следующие книги:

• Геопространственная сервис-ориентированная архитектура (СОА);
• Проектирование баз геоданных для транспорта;
• Корпоративные геоинформационные системы;
• ГИС: новая энергия электрических и газовых предприятий;
• Нефть и газ на цифровой карте;
• Моделирование нашего мира. Руководство Esri по проектированию базы геоданных;
• Думая о ГИС. Планирование ГИС: руководство для менеджеров;
• Географические информационные системы. Основы;
• ГИС для административно-хозяйственного управления;
• Веб-ГИС. Принципы и применение;
• Стратегии проектирования систем, 26-е издание;
• 68 выпусков журнала ArcReview с публикациями компаний и пользователей ГИС-систем;
• ... и множество других тематических заметок и публикаций.

Например, книга "Моделирование нашего мира… " (перевод) - это всестороннее руководство и справочник по моделированию данных в ГИС вообще, и по модели данных базы геоданных в частности. Книга показывает, как вырабатывать правильные решения по моделированию данных, решения, которые участвуют в каждом аспекте проекта ГИС: от проектирования базы данных и сбора данных до пространственного анализа и визуального представления. Подробно описывается, как спроектировать географическую БД, соответствующую проекту, настроить функциональность базы данных без программирования, управлять потоком работ в сложных проектах, моделировать разнообразные сетевые структуры, такие как речные, транспортные или электрические сети, внедрять данные космосъёмки в процесс географического анализа и отображения, а также создавать 3D-модели данных ГИС. Книга "Проектирование баз геоданных для транспорта " содержит методологические подходы, опробованные на большом количестве проектов и полностью соответствующие законодательным требованиям Европы и США, а также международным стандартам. А в книге "ГИС: новая энергия электрических и газовых предприятий " с использованием реальных примеров показаны преимущества, которые корпоративная ГИС может дать компании-поставщику энергии, включая такие аспекты как обслуживание клиентов, эксплуатация сетей и другие бизнес-процессы.

Некоторые из книг, переводных и оригинальных, изданных на русском языке компаниями Esri CIS и DATA+. В них затрагиваются как концептуальные вопросы, связанные с технологией ГИС, так и многие прикладные аспекты моделирования и развертывания ГИС разного масштаба и назначения.

Применение отраслевых моделей рассмотрим на примере модели данных BISDM (Building Interior Space Data Model, информационная модель внутреннего пространства здания) версии 3.0. BISDM является развитием более общей модели BIM (Building Information Model, информационная модель здания) и предназначена к использованию в задачах проектирования, строительства, эксплуатации и вывода из эксплуатации зданий и сооружений. Используется в ПО ГИС, позволяет эффективно обмениваться геоданными с другими платформами и взаимодействовать с ними. Относится к общей группе задач FM (управление инфраструктурой организации). Перечислим основные преимущества модели BISDM, применение которой позволяет:

• организовать обмен информацией в гетерогенной среде по единым правилам;
• получить «физическое» воплощение концепции BIM и рекомендуемых правил управление проектом строительства;
• поддерживать средствами ГИС единое хранилище на всем жизненном цикле здания (от проекта до вывода из эксплуатации);
• координировать работу различных специалистов в проекте;
• визуализировать заложенный календарный план и этапы строительства для всех участников;
• давать предварительную оценку стоимости и сроков возведения (4D- и 5D-данные);
• контролировать ход реализации проекта;
• обеспечить качественную эксплуатацию здания, включая обслуживание и ремонты;
• стать частью системы управления активами, включая функции анализа эффективности использования площадей (сдача в аренду, складские помещения, менеджмент сотрудников);
• проводить расчёт и осуществлять управление задачами энергоэффективности здания;
• моделировать перемещения людских потоков.

BISDM определяет правила работы с пространственными данными на уровне внутренних помещений в здании, в том числе предназначение и виды использования, проложенные коммуникации, установленное оборудование, учёт ремонтов и обслуживание, протоколирование инцидентов, взаимосвязи с другими активами компании. Модель помогает создавать единое хранилище географических и негеографических данных. Был использован опыт ведущих мировых компаний для выделения сущностей и моделирования на уровне БГД (базы геоданных) пространственных и логических взаимосвязей всех физических элементов, формирующих как само здание, так и его внутренние помещения. Следование принципам BISDM позволяет существенно упростить задачи интеграции с другими системами. На первом этапе это, как правило, интеграция с CAD. Затем, при эксплуатации здания, используется обмен данными с ERP и EAM-системами (SAP, TRIRIGA, Maximo и др.).

Визуализация структурных элементов BISDM средствами ArcGIS.

В случае использования BISDM заказчик/владелец объекта получает сквозной обмен информацией от идеи создания объекта до разработки полного проекта, контроль строительства с получением актуальной информации к моменту ввода объекта в эксплуатацию, контроль параметров во время эксплуатации, и даже при реконструкции или выводе объекта из эксплуатации. Следуя парадигме BISDM, ГИС и создаваемая с её помощью БГД становятся общим хранилищем данных для связанных систем. Часто в БГД оказываются данные, созданные и эксплуатируемые сторонними системами. Это нужно учитывать при проектировании архитектуры создаваемой системы.

На определённом этапе накопленная «критическая масса» информации позволяет перейти на новый качественный уровень. К примеру, по завершению этапа проектирования нового здания, в ГИС возможно автоматически визуализировать обзорные 3D-модели, составить перечень устанавливаемого оборудования, подсчитать километраж прокладываемых инженерных сетей, выполнить ряд поверок и даже дать предварительную финансовую оценку стоимости проекта.

Ещё раз отметим, что при совместном использовании BISDM и ArcGIS появляется возможность автоматического построения 3D-моделей по накопленным данным, поскольку БГД содержит полное описание объекта, включая z-координаты, принадлежность к этажу, виды соединений элементов, способы установки оборудования, материал, доступные пути перемещения персонала, функциональное назначение каждого элемента и т.д. и т.п. Нужно учесть, что после выполнения первоначального импорта всех проектных материалов в BISDM БГД возникает потребность дополнительного информационного наполнения для:

• простановки на обозначенных местах 3D-моделей объектов и оборудования;
• сбора сведений о стоимости материалов и порядка их укладки и монтажа;
• контроля проходимости по габаритам устанавливаемого нестандартного оборудования.

За счёт применения ArcGIS упрощается импорт дополнительных 3D-объектов и справочников из внешних источников, т.к. модуль ArcGIS Data Interoperability позволяет создавать процедуры по импорту подобных данных и корректному их размещению внутри модели. Поддерживаются все используемые в данной отрасли форматы, в том числе IFC, AutoCAD Revit, Bentlye Microstation.

Отраслевые модели данных от компании IBM

IBM предоставляет набор инструментов и моделей управления хранением данных для различных областей деятельности:

• IBM Banking and Financial Markets Data Warehouse (финансы)
• IBM Banking Data Warehouse
• IBM Banking Process and Service Models
• IBM Health Plan Data Model (здравоохранение)
• IBM Insurance Information Warehouse (страхование)
• IBM Insurance Process and Service Models
• IBM Retail Data Warehouse (розничная торговля)
• IBM Telecommunications Data Warehouse (телекоммуникации)
• InfoSphere Warehouse Pack:
  - for Customer Insight (для понимания клиентов)
  - for Market and Campaign Insight (для понимания компании и рынка)
  - for Supply Chain Insight (для понимания поставщиков).

Например, модель IBM Banking and Financial Markets Data Warehouse предназначена для решения специфических проблем банковской отрасли с точки зрения данных, а IBM Banking Process and Service Models - с точки зрения процессов и СОА (сервис-ориентированной архитектуры). Для телекоммуникационной отрасли представлены модели IBM Information FrameWork (IFW) и IBM Telecommunications Data Warehouse (TDW) . Они помогают существенно ускорить процесс создания аналитических систем, а также снизить риски, связанные с разработкой приложений бизнес-анализа, управлением корпоративными данными и организацией хранилищ данных с учётом специфики телекоммуникационной отрасли. Возможности IBM TDW охватывают весь спектр рынка телекоммуникационных услуг - от интернет-провайдеров и операторов кабельных сетей, предлагающих услуги проводной и беспроводной телефонии, передачи данных и мультимедийного контента, до транснациональных компаний, предоставляющих услуги телефонной, спутниковой, междугородней и международной связи, а также организации глобальных сетей. На сегодняшний день TDW используется крупными и мелкими поставщиками услуг проводной и беспроводной связи по всему миру.

Инструмент под названием InfoSphere Warehouse Pack for Customer Insight представляет собой структурированное и легко внедряемое бизнес-содержимое для всё большего числа бизнес-проектов и отраслей, среди которых банковское дело, страхование, финансы, программы медицинского страхования, телекоммуникации, розничная торговля и дистрибуция. Для бизнес-пользователей InfoSphere Warehouse Pack for Market and Campaign Insight помогает максимально повысить эффективность мероприятий по анализу рынка и маркетинговых кампаний благодаря пошаговому процессу разработки и учёта специфики бизнеса. С помощью InfoSphere Warehouse Pack for Supply Chain Insight организации имеют возможность получать текущую информацию по операциям цепочек поставок.

Позиция Esri внутри архитектуры решений IBM.

Особого внимания заслуживает подход IBM для электроэнергетических компаний и предприятий ЖКХ. Для того чтобы удовлетворить растущие запросы потребителей, энергоснабжающим предприятиям необходима более гибкая архитектура по сравнению с используемой сегодня, а также стандартная отраслевая объектная модель, что упростит свободный обмен информацией. Это повысит коммуникативные возможности энергетических компаний, обеспечивая взаимодействие в более экономичном режиме, и предоставит новым системам лучшую видимость всех необходимых ресурсов независимо от того, где они располагаются в пределах организации. Базой для такого подхода служит СОА (сервис-ориентированная архитектура), компонентная модель, устанавливающая соответствие между функциями подразделений и сервисами различных приложений, которые можно многократно использовать. «Службы» таких компонентов обмениваются данными посредством интерфейсов без жёсткой привязки, скрывая от пользователя всю сложность стоящих за ними систем. В таком режиме предприятия могут легко добавлять новые приложения независимо от поставщика программного обеспечения, операционной системы, языка программирования или иных внутренних характеристик ПО. На основе СОА реализуется концепция SAFE (Solution Architecture for Energy), она позволяет компании электроэнергетической отрасли получить основанное на стандартах целостное представление своей инфраструктуры.

Esri ArcGIS ® - признанная во всём мире программная платформа для геоинформационных систем (ГИС), обеспечивающая создание и управление цифровыми активами электроэнергетических, газотранспортных, распределительных, а также телекоммуникационных сетей. ArcGIS позволяет провести наиболее полную инвентаризацию компонентов электрической распределительной сети с учётом их пространственного расположения. ArcGIS существенно расширяет архитектуру IBM SAFE, предоставляя инструменты, приложения, рабочие процессы, аналитику и информационно-интеграционные возможности, необходимые для управления интеллектуальным энергопредприятием. ArcGIS в рамках IBM SAFE позволяет получать из различных источников информацию об объектах инфраструктуры, активах, клиентах и сотрудниках с точными данными об их местоположении, а также создавать, хранить и обрабатывать геопривязанную информацию об активах предприятия (опоры, трубопроводы, провода, трансформаторы, кабельная канализация и т.д.). ArcGIS внутри инфраструктуры SAFE позволяет динамически объединить основные бизнес-приложения, комбинируя данные из ГИС, SCADA и систем обслуживания клиентов с внешней информацией, например об интенсивности трафика, погодных условиях или спутниковыми снимками. Энергопредприятия используют такую комбинированную информацию для различных целей, от С.О.Р. (общей картины оперативной обстановки) до инспектирования объектов, технического обслуживания, анализа и планирования сетей.

Информационные компоненты энергоснабжающего предприятия можно смоделировать с помощью нескольких уровней, которые ранжируются от самого низкого - физического - до верхнего, наиболее сложного уровня логики бизнес-процессов. Эти уровни можно интегрировать, чтобы обеспечить соответствие типичным отраслевым требованиям, например, при автоматизированной регистрации измерений и управлении системой диспетчерского контроля и сбора данных (SCADA). Выстраивая архитектуру SAFE, энергоснабжающие компании делают значительные шаги в продвижении общеотраслевой открытой объектной модели под названием «Общая информационная модель для энергетических компаний» (Common Information Model (CIM) for Energy and Utilities). Эта модель обеспечивает необходимую базу для продвижения множества предприятий к сервис-ориентированной архитектуре, поскольку она поощряет использование открытых стандартов для структуризации данных и объектов. За счёт того, что все системы используют одни и те же объекты, путаница и неэластичность, связанные с различными реализациями одинаковых объектов, будут сокращены до минимума. Таким образом, определение объекта «клиент» и прочих важных бизнес-объектов будет унифицировано во всех системах энергоснабжающего предприятия. Теперь с помощью CIM поставщики и потребители услуг могут использовать общую структуру данных, облегчая вывод дорогостоящих компонентов бизнеса на аутсорсинг, так как CIM устанавливает общую базу, на которой можно построить обмен информацией.

Заключение

Комплексные отраслевые модели данных обеспечивают компаниям единое интегрированное представление их бизнес-информации. Многим компаниям бывает непросто осуществить интеграцию своих данных, хотя это является необходимым условием для большинства общекорпоративных проектов. По данным исследования Института Хранилищ данных (The Data Warehousing Institute, TDWI), более 69% опрошенных организаций обнаружили, что интеграция является существенным барьером при внедрении новых приложений. Напротив, осуществление интеграции данных приносит компании ощутимый доход и рост эффективности.

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

Архитектура БД

Схема КМД – это описание структуры модели данных с точки зрения администратора.

Схема ВМД – это описание внутренней или физической модели. Здесь хранится описание физического расположения данных на носителях. Схема хранит прямые указания на размещение данных в памяти (томах, дисках).

Схема КМД описывает структуру данных, записей и полей.

Все СУБД поддерживают три основных вида моделей данных:

1. Иерархическая модель. Она предполагает некоторую корневую запись. От корней идут ветви.

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

2. Сетевая модель. Позволяет правильно отобразить все сложности взаимосвязей.

Модель удобна для представления связей с данными внешней среды, но менее удобна для описания в БД, что приводит к дополнительному труду пользователя по изучению навигации по связям.

3. Реляционная модель. В основе лежит математический термин Relation – отношение, а попросту – таблица. Например, прямоугольная двухмерная.

Реляционная структура данных была разработана в конце 60-х годов рядом исследо­вателей, из которых наиболее значимый вклад внес сотрудник фирмы IBM Эдгар Кодд. При реляционном подходе данные представляются в виде двумерных таблиц – наи­более естественном для человека. В то же время, для обработки данных Кодд предло­жил использовать аппарат теории множеств – объединение, пересечение, разность, де­картово произведение.

Тип данных – это понятие имеет такой же смысл, как и в языках программирования (т.е. тип данных определяет внутреннее представление в памяти компьютера и способ хранения экземпляра данных, а также множество значений, которые может принимать экземпляр данных и множество допустимых операций над данными). Все существующие современные базы данных поддерживают специальные тины данных, предназначенные для хранения данных целого типа, дробного с плавающей точкой, сим­волов и строк, календарных дат. У многих серверов баз данных реализованы и другие типы, например, у сервера Interbase имеется специальный тип данных для хранения круп­ных массивов бинарной информации (BLOB).

Домен – это потенциальное множество значений простого типа данных, он имеет сходство с подтипом данных в некоторых языках программирования. Домен определя­ется двумя элементами – типом данных и логическим выражением, которое применяется к данным. Если результат этого выражения равен значению «истина», то экземпляр дан­ных принадлежит домену.

Отношение – это двумерная таблица особого вида, состоящая из заголовка и тела.

Заголовок – это фиксированное множество атрибутов, каждый из которых опреде­лен на каком-то домене, причем между атрибутами и определяющими доменами суще­ствует взаимно однозначное соответствие.

Каждый из ат­рибутов определен на своем домене. Домен представляет собой тип данных «це­лый», а логическое условие - n>0. Заголовок является неизменным во времени, в от­личие от тела отношения. Тело отношения – это совокупность кортежей , каждый из которых представляет собой пару «атрибут - значение».

Мощностью отношения называется число его кортежей, а степенью отношения – число атрибутов.

Степень отношения является для данного отношения величиной постоянной, тогда как мощность отношения изменяется во времени. Мощность отношения еще называют кардинальным числом.

Приведенные выше понятия являются теоретическими и используются при разработ­ке языковых средств и программных систем реляционных СУБД. В повседневной работе вместо них используются их неформальные эквиваленты:

отношение – таблица;

атрибут- колонка или поле;

кортеж - запись или строка.

Таким образом, степень отношения – это число колонок в таблице, а кардинальное число - количество строк.

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

Ключ должен удовлетворять следующим требованиям:

· должен быть уникальным;

· должен быть минимальным, то есть удаление любого атрибута из ключа ведет к нарушению уникальности.

Как правило, число атрибутов в ключе меньше степени отношения, однако, в крайнем случае, ключ может содержать все атрибуты, так как комбинация всех атрибутов удов­летворяет условию уникальности. Обычно отношение имеет несколько ключей. Из всех ключей отношения (их еще называют «возможными ключами») один выбирается в ка­честве первичного ключа . При выборе первичного ключа предпочтение обычно отдается ключу с наименьшим числом атрибутов. Нецелесообразно также использовать ключи с длинными строковыми значениями.

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

Описанные в данной главе основные понятия не относятся к какой-либо конкретной реализации базы данных, а являются общими для них всех. Таким образом, эти понятия являются основой определенной общей модели, которая называется реляционной мо­делью данных.

Основатель реляционного подхода Дейт установил, что реляционная модель состо­ит из трех частей:

· структурной;

· манипуляционной;

· целостной.

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

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

Под целостной частью понимают некий механизм обеспечения не разрушаемости дан­ных. Целостная часть заключает в себе два основных требования целостности реляци­онных баз данных - целостность сущностей и целостность по ссылкам.

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

В языке манипулирования данными, а также на языке запросов, исполняется математический аппарат, называемый алгеброй отношений, для определены следующие действия:

1. Стандартные операции: – пересечение, – объединение, \ – разность, X – декартово произведение.

2. Специфические: проекция, ограничение, соединение, деление.

a. Объединение.

ШД ШМ ЕИ НР

R 1 (шифр детали, шифр материала, единицы измерения, норма расхода)

R 2 (ШД, ШМ, ЕИ, НР)

Необходимо найти

Предполагается присоединение множеств R 1 и R 2 . В этой операции степень сохраняется, а мощность результирующего множества

b. Пересечение.

Выделение совпадающих строк.

c. Разность.

Исключение из R 1 кортежей, совпадающих с R 2 .

d. Декартово произведение.

Здесь производится конкатенация кортежей.

Каждая строка одного множества конкатенирует с каждой строкой другого.

Даны два множества:

Декартово произведение имеет следующий вид:

В этом случае S-степень равна, а, т.е. получится 12 строк и 5 столбцов.

Корпоративная база данных является центральным звеном корпоративной информационной системы и позволяет создать единое информационное пространство корпорации. Корпоративные базы данных

Поделитесь работой в социальных сетях

Если эта работа Вам не подошла внизу страницы есть список похожих работ. Так же Вы можете воспользоваться кнопкой поиск

ТЕМА V. КОРПОРАТИВНЫЕ БАЗЫ ДАННЫХ

V .1. Организация данных в корпоративных системах. Корпоративные базы данных.

V .2. СУБД и структурные решения в корпоративных системах.

V .3. Технологии Internet / Intranet и корпоративные решения по доступу к базам данных.

V .1. ОРГАНИЗАЦИЯ ДАННЫХ В КОРПОРАТИВНЫХ СИСТЕМАХ. КОРПОРАТИВНЫЕ БАЗЫ ДАННЫХ

Корпоративная база данных является центральным звеном корпоративной информационной системы и позволяет создать единое информационное пространство корпорации. Корпоративные базы данных (рис.1.1).

Существуют различные определения баз данных.

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

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

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

Цель создания баз данных как формы хранения данных  построение системы данных, не зависящих от принятых алгоритмов (программного обеспечения), применяемых технических средств, физического расположения данных в ЭВМ. База данных предполагает многоцелевое использование (несколько пользователей, множество форм документов и запросов одного пользователя).

Основные требования к базам данных:

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

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

База знаний (БЗ)  совокупность баз данных и используемых правил, полученных от лиц, принимающих решения. База знаний является элементом экспертных систем.

Следует различать различные способы представления данных .

Физические данные – это данные, хранящиеся в памяти ЭВМ.

Логическое представление данных соответствует пользовательскому представлению физических данных. Различие между физическим и соответствующим логическим представлением данных состоит в том, что последнее отражает некоторые важные взаимосвязи между физическими данными.

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

Рис. 1.1. Структура взаимодействия подразделений с информационными ресурсами корпорации.

Корпоративные базы данных бывают сосредоточенные (централизованные ) и распределенные.

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

Рис.1.2. Схема гетерогенной централизованной базы данных

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

• Большой поток обмена данными;
• Высокий трафик в сети;
• Низкая надежность;
• Низкая общая производительность.

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

• Более высокая степень одновременности обработки вследствие распределения нагрузки;
• Улучшение использования данных на местах при выполнении удаленных (дистанционных) запросов;
• Меньшие затраты;
• Простота управления локальными базами.

Затраты на создание сети, в узлах которой находятся рабочие станции (малые ЭВМ), гораздо ниже, чем затраты на создание аналогичной системы с использованием большой ЭВМ. На Рис.1.3 приведена логическая схема распределенной базы данных.

Рис.1.3. Распределенная база данных корпорации.

Дадим следующее определение распределенной базы данных.

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

Важнейшие требования к характеристикам распределенной базы данных таковы:

• Масштабируемость;
• Совместимость;
• Поддержка различных моделей данных;
• Переносимость;
• Прозрачность расположения;
• Автономность узлов распределенной базы данных (Site Autonomy);
• Обработка распределенных запросов;
• Выполнение распределенных транзакций.
• Поддержка однородной системы безопасности.

Прозрачность расположения позволяет пользователям работать с базами данных, не зная ничего об их расположении. Автономность узлов распределенной базы данных означает, что ведение каждой базы может происходить независимо от других. Распределенный запрос - это такой запрос (SQL-предложение), в ходе выполнения которого происходит доступ к объектам (таблицам или представлениям) разных баз данных. При выполнении распределенных транзакций осуществляется согласованное управление (concurrency control) всеми вовлеченными базами данных. Oracle7 использует технологию двухфазной передачи информации для выполнения распределенных транзакций.

Базы данных, составляющие распределенную базу данных, не обязательно должны быть однородными (т.е. вестись одной СУБД) или обрабатываться в среде одной и той же операционной системы и/или на компьютерах одного и того же типа. Например, одна база данных может быть базой Oracle на компьютере SUN с операционной системой SUN OS(UNIX), вторая база данных может вестись СУБД DB2 на мейнфрейме IBM 3090 с операционной системой MVS, а для ведения третьей базы может использоваться СУБД SQL/DS также на мейнфрейме IBM, но с операционной системой VM. Обязательно только одно условие - все машины с базами данных должны быть доступны по сети, в которую они входят.

Основная задача распределенной базы данных – распределение данных по сети и обеспечения доступа к ней. Существуют следующие способы решения этой задачи:

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

При создании распределенной базы данных на концептуальном уровне приходится решать следующие задачи:

• Необходимо иметь единую концептуальную схему всей сети. Это обеспечит логическую прозрачность данных для пользователя, в результате чего он сможет сформировать запрос ко всей базе, находясь за отдельным терминалом (он как бы работает с централизованной базой данных).
• Необходима схема, определяющая местонахождение данных в сети. Это обеспечит прозрачность размещения данных, благодаря которой пользователь может не указывать, куда переслать запрос, чтобы получить требуемые данные.
• Необходимо решить проблему неоднородности распределенных баз данных. Распределенные базы могут быть однородными и неоднородными в смысле аппаратных и программных средств. Проблема неоднородности сравнительно легко решается, если распределенная база данных является неоднородной в смысле аппаратных средств, но однородной в смысле программных средств (одинаковые СУБД в узлах). Если же в узлах распределенной системы используются разные СУБД, необходимы средства преобразования структур данных и языков. Это должно обеспечить прозрачность преобразования в узлах распределенной базы данных.
• Необходимо решить проблему управления словарями. Для обеспечения всех видов прозрачности в распределенной базе данных нужны программы, управляющие многочисленными словарями и справочниками.
• Необходимо определить методы выполнения запросов в распределенной базе данных. Методы выполнения запросов в распределенной базе данных отличаются от аналогичных методов в централизованных базах, так как отдельные части запросов нужно выполнять на месте расположения соответствующих данных и передавать частичные результаты на другие узлы; при этом должна быть обеспечена координация всех процессов.
• Необходимо решить проблему параллельного выполнения запросов. В распределенной базе нужен сложный механизм управления одновременной обработкой, который, в частности, должен обеспечить синхронизацию при обновлениях информации, что гарантирует непротиворечивость данных.
• Необходима развитая методология распределения и размещения данных, включая расщепление, является одним из основных требований к распределенной базе данных.

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

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

Для реализации машины баз данных были разработаны параллельные и ассоциативные архитектуры, как альтернатива однопроцессорной фоннеймановской структуре, позволяющие работать с большими объемами информации в реальном масштабе времени.

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

Информационные хранилища. Сегодня многие признают, что уже сейчас в большинстве компаний эксплуатируется несколько БД и, для успешной работы с информацией, требуются не просто разнотипные базы данных, а разные поколения СУБД. Согласно статистике, в каждой организации используется в среднем 2,5 различных СУБД. Стала очевидной необходимость "изолировать" бизнес компаний, вернее, людей, занимающихся этим бизнесом, от технологических особенностей баз данных, предоставить пользователям единый взгляд на корпоративную информацию независимо от того, где она физически хранится. Это стимулировало появление технологии информационных хранилищ (Data Warehousing, DW).

Основная цель DW - создание единого логического представления данных, содержащихся в разнотипных БД, или, другими словами, единой модели корпоративных данных.

Новый виток развития DW стал возможным благодаря совершенствованию информационных технологий в целом, в частности появлению новых типов баз данных на основе параллельной обработки запросов, которые в свою очередь опирались на достижения в области параллельных компьютеров. Были созданы программы-конструкторы запросов с интуитивным графическим интерфейсом, позволившие легко строить сложные запросы к БД. Разнообразное ПО промежуточного слоя (midleware) обеспечило связь между разнотипными базами данных , и, наконец, резко подешевели устройства хранения информации .

В структуре корпорации может присутствовать банк данных.

Банк данных – функционально-организационная компонента в автоматизированных системах управления и информационно-вычислительных системах, осуществляющая централизованное информационное обеспечение коллектива пользователей или совокупности решаемых в системе задач.

Банк данных рассматривают как информационно-справочную систему, основное назначение которой состоит:

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

Таким образом, современный банк данных представляет собой сложный программно-технический комплекс, в состав которого входят технические, системные и сетевые средства, базы данных и СУБД, информационно-поисковые системы различного назначения.

V .2. СУБД И СТРУКТУРНЫЕ РЕШЕНИЯ В КОРПОРАТИВНЫХ СИСТЕМАХ

Системы управления базами данных и знаний

Важной составляющей современных информационных систем являются системы управления базами данных (СУБД).

СУБД – комплекс программных и языковых средств, предназначенных для создания, ведения и использования баз данных.

Система управления базами данных обеспечивает доступ систем обработки данных к базам данных. Как уже отмечалось, важную роль СУБД приобретают при создании корпоративных информационных систем и, особо важную роль, при создании информационных систем использующих распределенные информационные ресурсы, базирующиеся на современных сетевых компьютерных технологиях.

Основная особенность современных СУБД - это то, что современные СУБД поддерживают такие технологии как:

• Технологию клиент/сервер.
• Поддержка языков БД. Это язык определения схемы БД (SDL - Schema Definition Language), язык манипулирования данными (DML - Data Manipulation Language), интегрированные языки SQL (Structured Queue Language), QDB (Query - By - Example) и QMF (Query Management Facility ) – развитое периферийное средство спецификации запросов и генерации отчетов для DB 2 и т. д.;
• Непосредственное управление данными во внешней памяти.
• Управление буферами оперативной памяти.
• Управление транзакциями. OLTP – технология (On -Line Transaction Processing), OLAP – технология (On -Line Analysis Processing) для DW.
• Обеспечить защиту и целостность данных. Использование системы разрешается лишь пользователям, имеющим право доступа к данным. При выполнении пользователями операций над данными поддерживается согласованность хранящихся данных (целостность). Это важно в корпоративных многопользовательских информационных системах.
• Журнализация.

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

• Независимость данных.
• Универсальность. СУБД должна обладать мощными средствами поддержки концептуальной модели данных для отображения пользовательских логических представлений.
• Совместимость. СУБД должна сохранять работоспособность при развитии программного и аппаратного обеспечения.
• Неизбыточность данных. В отличие от файловых систем база данных должна представлять собой единую совокупность интегрированных данных.
• Защита данных. СУБД должна обеспечивать защиту от несанкционированного доступа.
• Целостность данных. СУБД должна предотвращать нарушение базы данных пользователями.
• Управление одновременной работой. СУБД должна предохранять базу данных от рассогласований в режиме коллективного доступа. Для обеспечения согласованного состояния базы все запросы пользователей (транзакции) должны выполняться в определенном порядке.
• СУБД должна быть универсальной. Она должна поддерживать разные модели данных на единой логической и физической основе.
• СУБД должна поддерживать как централизованные, так и распределенные базы данных и, таким образом, стать важным звеном вычислительных сетей.

Рассматривая СУБД как класс программных продуктов, ориентированных на поддержание в автоматизированных системах баз данных, можно выделить два наиболее существенных признака, определяющих типы СУБД. Согласно им, СУБД можно рассматривать с двух точек зрения:

• их возможностей по отношению к распределенным (корпоративным) базам;
• их отношения к типу реализуемой в СУБД модели данных.

По отношению к корпоративным (распределенным) базам данных условно можно выделить следующие типы СУБД:

• СУБД «рабочего стола». Эти продукты, в первую очередь ориентированы на работу с персональными данными (данные "рабочего стола"). Они имеют наборы команд для совместного использования общих БД, но небольшого размера (типа малого офиса). Прежде всего, это СУБД типа Ассеss, dВАSЕ, Рагаdох, ЕохРго. Почему Ассеss, dВАSЕ, Рагаdох, ЕохРго имеют неудовлетворительный доступ к корпоративным данным. Дело в том, что не существует простого способа преодолеть барьер между персональными и корпоративными данными. И суть даже не в том, что механизм СУБД персональных данных (или малого офиса) ориентирован на доступ к данным через многие шлюзы, межсетевые продукты и т.д. Проблема состоит в том, что эти механизмы обычно связаны с полной передачей файлов и отсутствием разветвленной поддержки индексов, в результате чего очереди к серверу практически останавливают работу в больших системах.
• Специализированные высокопроизводительные многопользовательские СУБД. Такие СУБД характеризуются наличием многопользовательского ядра системы, языка манипулирования данными и следующими функциями, характерными для развитых многопользовательских СУБД:
• организацией буферного пула;
• наличием системы обработки очередей транзакций;
• наличием механизмов многопользовательской блокировки данных;
• ведением журнала транзакций;
• наличием механизмов разграничения доступа.

Это СУБД типа Oracle, DВ2, SQL/Server, Informix, Sybase, ADABAS, Titanium и другие предоставляют широкий сервис для обработки корпоративных БД.

При работе с базами данных используется механизм транзакций.

Транзакция – это логическая единица работы.

Транзакция - это последовательность операторов манипулирования данными, выполняющаяся как единое целое (все или ничего) и переводящая базу данных из одного целостного состояния в другое целостное состояние .

Транзакция обладает четырьмя важными свойствами, известными как свойства АСИД:

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

Транзакция обычно начинается автоматически с момента присоединения пользователя к СУБД и продолжается до тех пор, пока не произойдет одно из следующих событий:

• Подана команда COMMIT WORK (зафиксировать транзакцию).
• Подана команда ROLLBACK WORK (откатить транзакцию).
• Произошло отсоединение пользователя от СУБД.
• Произошел сбой системы.

Для пользователя она носит, как правило, атомарный характер . На самом деле это сложный механизм взаимодействия пользователь (приложение) – база данных. Программное обеспечение корпоративных систем используют механизм обработки транзакций в реальном времени (On-lineTransaction Processing Systems, OLTP ), в частности программы бухгалтерского учета, программное обеспечение приема и обработки клиентских заявок, финансовые приложения, производят массу информации. Эти системы рассчитаны (и соответствующим образом оптимизированы) на обработку больших объемов данных, выполнение сложных транзакций и интенсивных операций чтения/записи.

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

Доставкой информации конечному пользователю - занимаются системы аналитической обработки данных в реальном времени (On-line Analytical Processing, OLAP) , которые обеспечивают исключительно простой доступ к данным за счет удобных средств генерации запросов и анализа результатов. В OLAP-системах ценность информационного товара увеличивается благодаря применению разнообразных методов анализа и статистической обработки. Кроме того, эти системы оптимизированы с точки зрения скорости извлечения данных, сбора обобщенной информации и ориентированы на рядовых пользователей (имеют интуитивно понятный интерфейс). Если OLTP-система выдает ответы на простые вопросы типа "каков был уровень продаж товара N в регионе M в январе 199х г.?", то OLAP- системы готовы к более сложным запросам пользователей, например: "Дать анализ продаж товара N по всем регионам по плану на второй квартал в сравнении с двумя предыдущими годами".

Архитектура клиент/сервер

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

		База данных
Компьютер-сервер
Сеть
IBM-совместимый ПК	IBM-совместимый ПК	IBM-совместимый ПК
		Приложения

Рис. 2.1. Система архитектуры клиент-сервер

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

Сервер (Server) – это объект (ЭВМ), предоставляющий услуги другим объектам по их запросам.

Как следует уже из самого термина, главная функция компьютера-сервера заключается в обслуживании потребностей клиента. Термин "Сервер" используется для обозначения двух различных групп функций: файл-сервер и сервер баз данных (далее эти термины означают в зависимости от контекста либо программное обеспечение, реализующее указанные группы функций, либо компьютеры с этим программным обеспечением). Файл-серверы не предназначены для выполнения операций с базами данных, их основная функция - разделение файлов между несколькими пользователями, т.е. обеспечение одновременного доступа многих пользователей к файлам на компьютере - файл-сервере. Примером файл-сервера является операционная система NetWare компании Novell. Сервер баз данных можно установить и привести в действие на компьютере -- файл-сервере. СУБД Oracle в виде NLM (Network Loadable Module) выполняется в среде NetWare на файл-сервере.

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

Одно из важных требований к серверу - это то, что операционная система, в среде которой размещен сервер баз данных, должна быть многозадачной (и, желательно, но не обязательно, многопользовательской). Например, СУБД Oracle, установленная на персональном компьютере с операционной системой MS-DOS (или PC-DOS), не удовлетворяющей требованию многозадачности, не может использоваться как сервер баз данных. И та же СУБД Oracle, установленная на компьютере с многозадачной (хотя и не многопользовательской) операционной системой OS/2, может быть сервером баз данных. Многие разновидности систем UNIX, MVS, VM и некоторые другие операционные системы являются и многозадачными, и многопользовательными.

Распределенные вычисления

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

• Распределенная база данных;
• Распределенная обработка данных.

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

Существует много типов серверов:

• Сервер баз данных;
• Сервер печати;
• Сервер удаленного доступа;
• Факс-сервер;
• Web -сервер и т.д.

В основе базовой технологии Клиент/сервер лежат такие базовые технологии, как:

• Технологии операционных систем, концепция взаимодействия открытых систем, создание объектно-ориентированных сред функционирования программ;
• Телекоммуникационные технологии;
• Сетевые технологии;
• Технологии графического пользовательского интерфейса (GUI);
• И т.д.

Преимущества технологии клиент-сервер:

• Технология клиент/сервер позволяет производить вычисления на неоднородных вычислительных средах. Независимость от платформ: доступ к разнородным сетевым средам, в состав которых входят компьютеры разных типов с различными операционными системами.
• Независимость от источников данных: доступ к информации разнородных баз данных. Примеры таких систем -- DB2, SQL/DS, Oracle, Sybase.
• Баланс загрузки клиента и сервера.
• Выполнение вычислений там, где это происходит наиболее эффективно;
• Предоставляют возможность эффективного масштабирования;
• Межплатформные вычисления . Межплатформные вычисления определяются просто как реализация технологий в неоднородных вычислительных средах. Здесь должны быть обеспечены следующие возможности:
• Приложение должно выполняться на нескольких платформах;
• На всех платформах оно должно иметь один и тот же интерфейс и логику работы;
• Приложение должно интегрироваться с родной операционной средой;
• Оно должно одинаково вести себя на всех платформах;
• Для него должна предусматриваться простая и согласованная поддержка.

 Распределенные вычисления. Распределенные вычисления предусматривают распределение работ между несколькими вычислительными машинами (правда, распределенные вычисления более широкое понятие).

 Разукрупнение. Разукрупнение – перенос приложений для больших ЭВМ на малые компьютерные платформы.

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

 Сокращение общего времени выполнения приложения;

 Уменьшение использования клиентом памяти;

 Сокращение сетевого трафика.

• Возможность работы с мультимедиа: к настоящему времени создано немало программ работы с мультимедиа для ПК. Подобных программ для конфигурации терминал-хост либо нет, либо они очень дороги.
• Возможность привлечения больших вычислительных ресурсов для операций с базами данных: поскольку приложения выполняются на компьютерах-клиентах, на компьютере-сервере для операций с базами данных высвобождаются дополнительные (по сравнению с конфигурацией терминал-хост) ресурсы, такие, как вычислительные ресурсы центрального процессора и оперативная память.
• Более высокая продуктивность работы программистов: производительность труда программистов возрастает благодаря использованию таких средств, как SQL*Forms и CASE: они позволяют разрабатывать приложения быстрее, чем такие языки программирования, как C, PL1 или COBOL.
• Повышение продуктивности работы конечных пользователей: в настоящее время многие конечные пользователи освоили такие системы, как Lotus, Paradox, Word Perfect, Harvard Graphics и т.д.

Интерфейс серверной части определен и фиксирован. Поэтому возможно создание новых клиентских частей существующей системы (пример интероперабельности на системном уровне).

Рис. 2.2. Иллюстрация доступа клиентов к общему ресурсу сервера.

Как внедрить технологию клиент-сервер

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

• компьютер-сервер базы данных;
• компьютеры-клиентов;
• коммуникационная сеть;
• сетевое программное обеспечение;
• прикладное программное обеспечение.

Язык SQL . Язык запросов высокого уровня - SQL (Structured Query Language ) служит для реализации запросов к базам данных, таких как ЯМД, ЯОД и ПЯД и принят в качестве стандарта. Язык SQL первоначально был принят в качестве языка данных программных изделий фирмы IBM и ЯМД реляционной СУБД SYSTEM R фирмы IBM . Важной особенностью языка SQL заключается в том, что один и тот же язык представляется через два различных интерфейса, а именно: через интерактивный интерфейс и через интерфейс прикладного программирования (динамический SQL). Динамический SQL состоит из множества возможностей встроенного языка SQL , предусмотренных специально для конструирования интерактивных приложений, где под интерактивным приложением понимается программа, которая написана для поддержки обращения к базе данных конечного пользователя, работающего на интерактивном терминале. Язык SQL обеспечивает выполнение функций определения, манипулирования и управления данными баз данных и является прозрачным для пользователя с точки зрения реализуемой СУБД.

Рис. 2.3. Схема выполнения запросов пользователя к распределенным базам данных.

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

Модель данных состоит из трех компонент:

• Структура данных для представления с точки зрения пользователя на базу данных.
• Допустимые операции, выполняемые на структуре данных. Необходимо иметь возможность работать с этой структурой при помощи различных операций ЯОД и ЯМД. Богатая структура ничего не стоит, если нет возможности оперировать ее содержимым.
• Ограничения для контроля целостности. Модель данных должна быть обеспечена средствами, позволяющими сохранять ее целостность и защищать ее. В качестве примера рассмотрим два следующих ограничения:
• Каждое поддерево должно иметь исходный узел. В иерархических базах данных нельзя хранить порожденные узлы без исходного узла.
• В отношении реляционной базы данных не может быть одинаковых кортежей. Для файла это требование требует уникальности всех записей.

Одной из важнейших характеристик работы СУБД является возможность связывать объекты.

Существуют следующие виды связей между объектами:

• Один-к-Одному (1:1) . Один объект одного множества может быть связан с одним объектом другого множества.
• Один-ко-Многим (1:M) . Один объект одного множества может быть связан со многими объектами другого множества.
• Многие-ко-Многим (M:N) . Один объект одного множества может быть связан со многими объектами другого множества, но при этом один объект другого множества может быть связан со многими объектами первого множества.
• Разветвленная . Один объект одного множества может быть связан с объектами многих множеств.
• Рекурсивная . Один объект данного множества может быть связан объектом этого же множества.

Существуют следующие основные модели данных:

• Реляционная модель данных.
• Иерархическая модель данных.
• Неполная сетевая модель данных.
• Модель данных CODASYL.
• Расширенная сетевая модель данных.

V .3. ТЕХНОЛОГИИ INTERNET / INTRANET И КОРПОРАТИВНЫЕ РЕШЕНИЯ ПО ДОСТУПУ К БАЗАМ ДАННЫХ

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

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

Общим решением проблемы мобильности систем, основанных на архитектуре "клиент-сервер" является опора на программные пакеты, реализующие протоколы удаленного вызова процедур (RPC - Remote Procedure Call). При использовании таких средств обращение к сервису в удаленном узле выглядит как обычный вызов процедуры. Средства RPC, в которых, естественно, содержится вся информация о специфике аппаратуры локальной сети и сетевых протоколов, переводит вызов в последовательность сетевых взаимодействий. Тем самым, специфика сетевой среды и протоколов скрыта от прикладного программиста.

При вызове удаленной процедуры программы RPC производят преобразование форматов данных клиента в промежуточные машинно-независимые форматы и затем преобразование в форматы данных сервера. При передаче ответных параметров производятся аналогичные преобразования.

Другие похожие работы, которые могут вас заинтересовать.вшм>
6914.		Понятие базы данных	11.56 KB
	Базой данных является представленная в объективной форме совокупность самостоятельных материалов статей расчетов нормативных актов судебных решений и иных подобных материалов систематизированных таким образом чтобы эти материалы могли быть найдены и обработаны с помощью электронной вычислительной машины Гражданский кодекс РФ ст. База данных организованная в соответствии с определёнными правилами и поддерживаемая в памяти компьютера совокупность данных характеризующая актуальное состояние некоторой...
8064.		Распределенные базы данных	43.66 KB
	Распределенные базы данных Под распределенной базой данных РБД понимается набор логически связанных между собой разделяемых данных которые физически распределены по разных узлам компьютерной сети. Доступ к данным не должен зависеть от наличия или отсутствия реплик данных. Система должна автоматически определять методы выполнения соединения объединения данных сетевой канал способный справиться с объёмом передаваемой информации и узел имеющий достаточную вычислительную мощность для соединения таблиц. СУРБД должна быть способной...
20319.		БАЗЫ ДАННЫХ И ИХ ЗАЩИТА	102.86 KB
	Оперативные сетевые базы данных появились в середине 1960-х. Операции над оперативными базами данных обрабатывались в интерактивном режиме с помощью терминалов. Простые индексно-последовательные организации записей быстро развились к более мощной модели записей, ориентированной на наборы. За руководство работой Data Base Task Group (DBTG), разработавшей стандартный язык описания данных и манипулирования данными, Чарльз Бахман получил Тьюринговскую премию.
5031.		Разработка базы данных Библиотека	11.72 MB
	Технология проектирования баз данных. Определение взаимосвязей между сущностями и создание модели данных. Основные идеи современной информационной технологии базируются на концепции согласно которой данные должны быть организованы в базы данных с целью адекватного отображения изменяющегося реального мира и удовлетворения информационных потребностей пользователей. Эти базы данных создаются и функционируют под управлением специальных программных комплексов называемых системами управления базами данных СУБД.
13815.		ИЕРАРХИЧЕСКАЯ МОДЕЛЬ БАЗЫ ДАННЫХ	81.62 KB
	Основные идеи современной информационной технологии базируются на концепции баз данных согласно которой основой информационной технологии являются данные организованные в базах данных адекватно отражающие состояние той или иной предметной области и обеспечивающие пользователя актуальной информацией в этой предметной области. Необходимо признать тот факт что данные являются...
14095.		Разработка базы данных библиотеки	11.72 MB
	Увеличение объема и структурной сложности хранимых данных, расширение круга пользователей информационных систем привели к широкому распространению наиболее удобных и сравнительно простых для понимания реляционных (табличных) СУБД.
5061.		Создание базы данных поликлиники	2.4 MB
	Развитие средств вычислительной техники и информационных технологий обеспечило возможности для создания и широкого применения автоматизированных информационных систем (АИС) разнообразного назначения. Разрабатываются и внедряются информационные системы управления хозяйственными и техническими объектами
13542.		Базы данных геологической информации	20.73 KB
	В последнее время широкими темпами происходит внедрение компьютерных технологий и, в частности баз данных, в научную сферу. Этот процесс не обходит стороной и геологию, так как именно в естественных науках имеется необходимость для хранения и обработки больших объемов информации.
9100.		Базы данных. Основные понятия	26.28 KB
	База данных – это совокупность сведений о конкретных объектах реального мира в какой-либо предметной области экономика менеджмент химия и т. Целью информационной системы является не просто хранение данных об объектах но и манипулирование этими данными учитывая связи между объектами. Каждый объект характеризуется каким-либо набором данных свойств которые в БД называются атрибутами.
5240.		Создание базы данных «Деканат ВУЗа»	1.57 MB
	База данных (БД) - это совокупность взаимосвязанных, хранящихся вместе на внешних носителях памяти компьютера данных, при наличии такой организации и минимальной избыточности, которая допускает их использование оптимальным образом для одного или нескольких приложений

Отраслевые модели данных

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

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

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

Как правило, выделяются модели более высокого уровня (и более общие по содержанию) и более низкого (соответственно, более детальные). Верхний уровень моделирования – это так называемые концептуальные модели данных (conceptual data models), которые дают самую общую картину функционирования предприятия или организации. Концептуальная модель включает основные концепции или предметные области, критичные для функционирования организации; обычно их количество не превышает 12-15. Такая модель описывает классы сущностей, важных для организации (бизнес-объекты), их характеристики (атрибуты) и ассоциации между парами этих классов (т.е. связи). Поскольку в бизнес-моделировании терминология еще окончательно не устоялась, в различных англоязычных источниках концептуальные модели данных могут также носить название subject area model (что можно перевести как модели предметных областей) или subject enterprise data model (предметные корпоративные модели данных).

Следующий иерархический уровень – это логические модели данных (logical data models). Они также могут называться корпоративными моделями данных или бизнес-моделями. Эти модели содержат структуры данных, их атрибуты и бизнес-правила и представляют информацию, используемую предприятием, с точки зрения бизнес-перспективы. В такой модели данные организованы в виде сущностей и связей между ними. Логическая модель представляет данные таким образом, что они легко воспринимаются бизнес-пользователями. В логической модели может быть выделен словарь данных – перечень всех сущностей с их точными определениями, что позволяет различным категориям пользователей иметь общее понимание всех входных и информационных выходных потоков модели. Следующий, более низкий уровень моделирования – это уже физическая реализация логической модели с помощью конкретных программных средств и технических платформ.

Логическая модель содержит детальное корпоративное бизнес-решение, которое обычно принимает форму нормализованной модели. Нормализация – это процесс, который гарантирует, что каждый элемент данных в модели имеет только одно значение и полностью и однозначно зависит от первичного ключа. Элементы данных организуются в группы согласно их уникальной идентификации. Бизнес-правила, управляющие элементами данных, должны быть полностью включены в нормализованную модель с предварительной проверкой их достоверности и корректности. Например, такой элемент данных, как Имя клиента, скорее всего, будет разделен на Имя и Фамилию и сгруппирован с другими соответствующими элементами данных в сущность Клиент с первичным ключом Идентификатор клиента.

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

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

У компании может быть два пути создания корпоративной логической модели данных: строить ее самостоятельно или воспользоваться готовой отраслевой моделью (industry logical data model). В данном случае различия в терминах отражают лишь разные подходы к построению одной и той же логической модели. В том случае, если компания самостоятельно разрабатывает и внедряет собственную логическую модель данных, то такая модель, как правило, носит название просто корпоративной логической модели. Если же организация решает воспользоваться готовым продуктом профессионального поставщика, то тогда можно говорить об отраслевой логической модели данных. Последняя представляет собой готовую логическую модель данных, с высокой степенью точности отражающую функционирование определенной отрасли. Отраслевая логическая модель – это предметно-ориентированный и интегрированный вид всей информации, которая должна находиться в корпоративном Хранилище данных для получения ответов как на стратегические, так и на тактические бизнес-вопросы. Как и любая другая логическая модель данных, отраслевая модель не зависит от прикладных решений. Она также не включает производные данные или другие вычисления для более быстрого извлечения данных. Как правило, большинство логических структур такой модели находят хорошее воплощение в ее эффективной физической реализации. Такие модели разрабатываются многими поставщиками для самых различных областей деятельности: финансовой сферы, производства, туризма, здравоохранения, страхования и т.д.

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

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

Специалист в области бизнес-аналитики (Business Intelligence) Стив Хобермэн (Steve Hoberman) выделяет пять факторов, которые необходимо принимать во внимание при решении вопроса о приобретении отраслевой модель данных. Первый – это время и средства, необходимые для построения модели. Если организации необходимо быстро добиться результатов, то отраслевая модель даст преимущество. Использование отраслевой модели не может немедленно обеспечить картину всей организации, но способно сэкономить значительное количество времени. Вместо собственно моделирования время будет потрачено на связывание существующих структур с отраслевой моделью, а также на обсуждение того, как лучше ее настроить под нужды организации (например, какие определения должны быть изменены, а какие элементы данных – добавлены).

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

Третий фактор – опыт в оценке рисков и моделировании. Создание корпоративной модели данных требует квалифицированных ресурсов как со стороны бизнеса, так и IT-персонала. Как правило, менеджеры хорошо знают либо работу организации в целом, либо деятельность конкретного отдела. Лишь немногие их них обладают как широкими (в масштабах всей компании), так и глубокими (в рамках подразделений) знаниями о своем бизнесе. Большинство менеджеров обычно хорошо знают только одну область. Поэтому, для того чтобы получить общекорпоративную картину, требуются существенные бизнес-ресурсы. Это увеличивает и требования к IT-персоналу. Чем больше бизнес-ресурсов требуется для создания и тестирования модели, тем более опытными должны быть аналитики. Они должны не только знать, как получить информацию от бизнес-персонала, но также уметь находить общую точку зрения в спорных областях и быть способными представлять всю эту информацию в интегрированном виде. Тот, кто занимается созданием модели (во многих случаях это тот же аналитик), должен обладать хорошими навыками моделирования. Создание корпоративных логических моделей требует моделирования «для будущего» и способности конвертировать сложный бизнес в буквальном смысле «в квадраты и линии».

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

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

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

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

Отраслевые модели данных обеспечивают компаниям единое интегрированное представление их бизнес-информации. Многим компаниям бывает непросто осуществить интеграцию своих данных, хотя это является необходимым условием для большинства общекорпоративных проектов. По данным исследования Института Хранилищ данных (The Data Warehousing Institute, TDWI), более 69% опрошенных организаций обнаружили, что интеграция является существенным барьером при внедрении новых приложений. Напротив, осуществление интеграции данных приносит компании ощутимый доход.

Отраслевая модель данных, помимо связей с уже существующими системами, дает большие преимущества при осуществлении общекорпоративных проектов, таких как планирование ресурсов предприятия (Enterprise Resource Planning, ERP), управление основными данными, бизнес-аналитика, повышение качества данных и повышение квалификации сотрудников.

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

Публикации

1. Стив Хобермэн (Steve Hoberman). Использование отраслевой логической модели данных в качестве корпоративной модели (Leveraging the Industry Logical Data Model as Your Enterprise Data Model).
2. Клодиа Имхоф (Claudia Imhoff). Оперативное создание Хранилищ данных и выполнение проектов Business Intelligence с помощью моделирования данных (Fast-Tracking Data Warehousing & Business Intelligence Projects via Intelligent Data Modeling)

Цель лекции

Изучив материал настоящей лекции, вы будете знать:

• что такое корпоративная модель данных ;
• как преобразовать корпоративную модель данных в модель хранилища данных;
• основные элементы корпоративной модели данных ;
• уровни представления корпоративной модели данных ;
• алгоритм преобразования корпоративной модели данных в многомерную модель хранилища данных ;

и научитесь:

• разрабатывать модели хранилища данных на основе корпоративной модели данных организации;
• разрабатывать схему "звезда" с помощью CASE-средств;
• секционировать таблицы многомерной модели с помощью CASE-средств.

Корпоративная модель данных

Введение

Ядром любого ХД является его модель данных. Без модели данных будет очень сложно организовать данные в ХД. Поэтому разработчики ХД должны потратить время и силы на разработку такой модели. Разработка модели ХД ложится на плечи проектировщика ХД.

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

Отправной точкой в проектировании ХД может служить так называемая корпоративная модель данных ( corporate data model или enterprise data model, EDM ), которая создается в процессе проектирования OLTP-систем организации. При проектировании корпоративной модели данных обычно предпринимается попытка создать на основе бизнес-операций такую структуру данных, которая бы собрала и синтезировала в себе все информационные потребности организации.

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

Корпоративная модель данных

Как решить задачу преобразования корпоративной модели данных в модель ХД? Чтобы решить эту задачу, нужно иметь эту модель, т.е. корпоративная модели данных должна быть построена и документирована . И нужно понять, что из этой модели и как должно трансформироваться в модель ХД.

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

Основными элементами корпоративной модели данных являются:

• описание предметных областей организации (определение сфер деятельности);
• взаимоотношения между определенными выше предметными областями;
• информационная модель данных ( ERD -модель или модель "сущность-связь");
• для каждой предметной области описание:
  • ключей сущностей;
  • атрибутов сущностей ;
  • подтипов и супертипов ;
  • связей между сущностями;
  • группировки атрибутов;
  • взаимосвязей между предметными областями;
• функциональная модель или модель бизнес-процессов;
• диаграммы потоков данных;
• диаграммы состояний;
• другие модели.

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

Уровни представления корпоративной модели данных

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

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

Корпоративная модель данных обычно имеет несколько уровней представления. На самом высоком уровне (high level) корпоративной модели данных располагается описание основных предметных областей организации и их взаимосвязей на уровне сущностей. На рис. 16.2 приведен фрагмент корпоративной модели данных верхнего уровня.

Рис. 16.2.

На схеме, приведенной на рисунке, представлено четыре предметных области: "Покупатель" (Customer ), "Счет" (account ), "Заказ" (Order ) и "Товар" (Product ). Как правило, на верхнем уровне представления модели указываются только прямые связи между предметными областями, которые, например, фиксируют следующий факт: покупатель оплачивает счет на заказ товаров. Подробная информация и косвенные взаимосвязи на этом уровне корпоративной модели не приводятся.

На следующем, среднем уровне (mid level) корпоративной модели данных показывается подробная информация об объектах предметных областей, т. е. ключи и атрибуты сущностей , их взаимосвязи, подтипы и супертипы и т.д. Для каждой предметной области модели верхнего уровня существует одна модель среднего уровня. На рис. 16.3 изображен средний уровень представления корпоративной модели для фрагмента предметной области "Заказ".

Из рис. 16.3 видно, что предметная область "Заказ" (Order ) включает в себя несколько сущностей, определенных через их атрибуты, и взаимосвязей между ними. Представленная модель позволяет ответить на такие вопросы, как дата заказа, кто сделал заказ, кто отправил заказ, кто получает заказ и ряд других. Из приведенной схемы видно, что в данной организации выделяют два типа заказов – заказы по рекламной акции (Commersial ) и заказы по розничной торговле (Retail ).

Заметим, что корпоративная модель данных может представлять различные аспекты деятельности организации и с различной степенью детализации и завершенности. Если корпоративная модель представляет все аспекты деятельности организации, она еще называется моделью данных организации ( enterprise data model).

С точки зрения проектирования ХД важным фактором в принятии решения создания модели ХД из корпоративной модели данных является состояние завершенности корпоративной модели данных .

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

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

На самом низком уровне представления корпоративной модели данных показывается информация о физических характеристиках объектов БД, соответствующих логической модели данных среднего уровня представления корпоративной модели данных .

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

Эпилог

При подготовке данной статьи я постаралась ориентироваться прежде всего на архитекторов, аналитиков и разработчиков, которые непосредственно работают с хранилищами данных. Но получилось, что неизбежно «брала тему чуть шире» - и поле зрения попадали другие категории читателей. Какие-то моменты покажутся спорны, какие-то не понятны, какие-то очевидны. Люди разные – с разным опытом, бэкграундом и позицией.
Например, типичные вопросы менеджеров - «когда привлекать архитекторов?», «когда надо заниматься архитектурой?», «архитектура – не будет ли это слишком дорого?» звучат для нас (разработчиков, проектировщиков) довольно странно, потому что для нас архитектура системы появляется с ее рождением – не важно, осознаем мы это, или нет. И даже если формально роли архитектора в проекте нет, нормальный разработчик всегда «включает своего внутреннего архитектора».

По большом счету, не важно – кто именно выполняет роль архитектора – важно, что кто-то ставит подобные вопросы и исследует на них ответы. Если архитектор явно выделен – это лишь означает, что ответственность за систему и ее развитие несет, прежде всего, он.
Почему мне показалась тема «антихрупкости» релевантной относительно данного предмета?

“Уникальность антихрупкости состоит в том, что она позволяет нам работать с неизвестностью, делать что-то в условиях, когда мы не понимаем, что именно делаем, – и добиваться успеха” /Нассим Н.Талеб/

Поэтому, кризис и высокая степень неопределенности – это не оправдание в пользу отсутствия архитектуры, а факторы, усиливающие ее необходимость.

Теги: Добавить метки

5.1. Организация данных в корпоративных информационных системах.

Рассматривая КИС на самом упрощенном уровне можно сказать, что она содержит в себе корпоративную компьютерную (вычислительную) сеть и специализированный пакет прикладных программ (ППП) для решения задач предметной области. В свою очередь как ППП, так и компьютерная сеть предполагают в своей основе использование информационных данных о состоянии и развитии, контролируемых и управляемых ими систем. Исторически сложилось так, что КИС состоит из отдельных разветвленных подсистем отдельных предприятий, взаимосвязанных между собой и зачастую представляющих собой иерархическую систему. Естественно предположить, что подобные подсистемы имеют как собственные источники, так и собственные места хранения сопутствующих данных. Объединяясь в единую систему, возникают вопросы совместного корректного использования данных, территориально находящихся в различных местах их хранения. Следовательно, для успешного управления производственным объединением, оснащенным КИС, ему необходима надежная система сбора, хранения и обработки данных. Иными словами необходима единая информационная инфраструктура, удовлетворяющая стратегическим проектам BI (Business Intelligence) или интегрированная база для хранения и использования данных. Главной целью интеграции данных является получение единой и цельной картины состояния корпоративных бизнес - данных. Сама по себе интеграция представляет собой сложный процесс, в основе которого целесообразно выделить:

Технологии,

Продукты,

Приложения.

Методы – это подходы к интеграции данных.

Технологии – это процессы, реализующие те или иные методы интеграции данных.

Продукты – это коммерческие решения, поддерживающие ту или иную технологию интеграции данных.

Приложения – это готовые технические решения, поставляемые разработчиками в соответствии с пожеланиями клиентов – заказчиков.

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

5.2. Корпоративные базы данных и требования, предъявляемые к ним

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

· Простой и понятный пользователю ввод данных в базу,

· Хранение данных в виде, который не приведет к чрезмерному разрастанию данных,

· Доступность к общей информации сотрудников всех подразделений корпорации при обязательном условии разграничения прав доступа,

· Быстрое нахождение и выборка требуемой информации,

· Сортировку и фильтрацию необходимых данных,

· Группировку одноименных данных,

· Промежуточные и итоговые вычисления над полями,

· Преобразование и наглядность выводимых данных,

· Масштабируемость,

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

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

Создание интегрированной корпоративной базы данных возможно различными методами, основными из которых являются:

· Консолидация,

· Федерализация,

· Распространение.

5.3. Характеристика интеграционных решений корпоративных баз данных

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

Применительно к корпорации при использовании этого метода данные копируются и собираются из первичных баз (БД – Slave) путем интеграции в единое место хранения (БД –Master). Как правило, таким местом хранения выбирается сервер центрального (головного) офиса (рис.5.1).

Рис.5.1. Метод консолидации данных

Данные в БД – Master используются для подготовки отчетности, проведения анализа, выработки и принятия решения, а также как источник данных для других филиалов корпорации.

Наиболее распространенными технологиями поддержки таких решений при консолидации являются технологии:

· Извлечение, преобразование и загрузка - ETL (Extract Transform Load);

· Управление содержанием корпорации - ECM (Enterprise Content Management).

Достоинствами метода консолидации являются:

1. Возможность осуществлять трансформацию (реструктуризацию, согласование, очистку и/или агрегирование) значительных объемов данных в процессе их передачи от первичных систем к конечным местам хранения за счет технологии ETL,

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

Для работы с консолидированной базой данных КИС создаются специальные бизнес-приложения, которые позволяют создавать запросы к данным базы, отчеты и, на их основе, осуществлять анализ данных.

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

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

Такое отставание может составлять от нескольких секунд до нескольких часов или даже дней.

Федерализация. Под федерализацией обычно понимается объединение. Подобный термин часто используется в политике при обустройстве границ государства (например, ФРГ, РФ, США).

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

Рис.2. Метод федерализации данных

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

Поддержку федеративного подхода к интеграции данных обеспечивает технология Enterprise information integration (E I I), что в переводе означает – Интеграция корпоративной информации.

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

Основными достоинствами федеративного подхода являются:

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

· целесообразность применения после приобретения или слияния компаний,

· незаменимость в тех случаях, когда по соображениям безопасности существуют лицензионные ограничения на копирование данных первичных систем,

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

· высокая степень полезности для крупных транснациональных корпораций.

К недостаткам подхода следует отнести:

· Снижение производительности из-за дополнительных затрат на доступ к многочисленным источникам данных,

· федерализация наиболее приемлема для извлечения небольших массивов данных,

· высокие требования к качеству первичных данных.

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

Примерами технологий, поддерживающих реализацию метода распространения данных, являются:

· Интеграция корпоративных приложений EAI – Enterprise Application Integration,

· Тиражирование корпоративных данных EDR – Enterprise Data Replication.

Обобщенная структура реализации метода распространения данных имеет вид рис.5.3.

Рис.5.3. Метод распространения данных

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

Сочетание в методе технологий интеграции (EAI) и тиражирования (EDR) дает множественные преимущества, в виде следующих достоинств:

· Высокая производительность,

· Возможность реструктуризации и очистки данных,

· Уравновешивание нагрузки за счет создания резервных копий и восстановления данных.

Гибридный подход. Реалии экономической деятельности таковы, что не существует двух одинаковых предприятий, тем более двух одинаковых корпораций. Данное обстоятельство накладывает свой отпечаток на процесс создания и наполнения КИС. Это всецело относится и к методам интеграции данных в базах. По этой причине многие КИС используют в своих приложениях интеграции данных так называемый гибридный подход, который одновременно включает несколько методов интеграции.Примерами такого подхода служат технологии, обеспечивающие согласованную картину информации о клиентах:

· Интеграция данных о клиентах в системахCDI – Customer Data Integration,

· Интеграция данных о клиентах в модуляхCRM – Customer Relations Management.

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

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

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

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

Более того, гибридный подход может быть расширен использованием метода распространения данных. Например, клиент, пользующийся услугами Интернет – магазина, во время обслуживания изменяет свои реквизиты. Эти изменения могут быть отправлены в консолидированную часть БД, а оттуда распространены во все первичные системы, содержащие данные о клиентах магазина.

Памятуя о достоинствах и недостатках каждого из методов целесообразно творчески подходить к их применению и совместному использованию.

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

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

5.4. Понятие и структурные решения хранилищ данных

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

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

В основе концепции хранилищ данных положены две основные идеи:

1. Интеграция разъединенных детализированных данных (описывающих конкретные факты, свойства, события и т.д.) в едином хранилище.

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

Хранилище данных организуется в тех случаях, когда необходимо получить:

· Интеграцию текущих и исторических значений данных,

· Объединение данных из разрозненных источников,

· Создание надежной платформы данных для аналитических целей,

· Обеспечение однородности данных в организации,

· Облегчение внедрения корпоративных стандартов данных без изменения существующих операционных систем,

· Обеспечение широкой исторической картины и возможностей для анализа тенденций развития.

Исторически хранилища данных строились по одно- двух и трехуровневой схеме.

Одноуровневые схемы изначально предназначались для наиболее простых архитектур, к которым относятся функциональные СППР, с недостаточно развитой информационной инфраструктурой, когда анализ осуществляется с использованием данных из оперативных систем, по принципу: данные - формы представления.

Достоинствами таких схем являются:

· Быстрая передача данных из оперативных систем в специализированную систему без промежуточных звеньев,

· Минимум затрат за счет использования единой платформы.

Недостатки:

· Узкий круг решаемых вопросов из-за единственного источника данных,

· Низкое качество данных ввиду отсутствия этапа очистки.

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

Достоинства:

· Используемые витрины проектируются для ответов на конкретный ряд вопросов,

· Имеется возможность оптимизировать данные в витринах, что способствует повышению производительности.

Недостатки:

· Сложность обеспечения непротиворечивости данных из-за многократного их повторения в витринах,

· Потенциальная сложность наполнения витрин при большом числе источников данных,

· В виду отсутствия консолидации данных на уровне корпорации нет единой картины бизнеса.

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

На первом уровне расположены разнообразные регистрирующие системы, являющиеся источниками данных. Такими системами могут быть системы планирования ресурсов предприятия (ERP – Enterprise Resource Planning), справочные (оперативные) системы, внешние источники или системы, поставляющие данные от информационных агентств и др.

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

· Склад является источником аналитической информации, используемой для оперативного управления,

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

Третий уровень представляет собой совокупность предметно-ориентированных витрин данных.

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

Рис.5.4. Архитектура хранилища данных

Основными технологическими операциями подобным образом организованных хранилищ данных являются:

· Извлечение данных – это процесс переноса данных из неоднородных источников в оперативный склад,

· Преобразование данных – это модификация данных на основе специальных правил с последующей передачей их в центральное хранилище,

· Очистка данных – это исключение дублирования данных, поступающих от разных источников,

· Обновление данных – это распространение обновления данных на исходные данные базовых таблиц и производные данные, размещенные в хранилище.

Достоинства:

· Наполнение витрин упрощено ввиду использования единого источника очищенных данных,

· Витрины данных синхронизированы с корпоративной бизнес – картиной, что позволяет легко расширить центральное хранилище и добавить витрины данных,

· Гарантированная производительность.

Недостатки:

· Наличие избыточности данных, ведущее к росту требований к технологии хранения данных,

5. 5.Системы управления базами данных и технологии доступа к данным в КИС

Система управления базой данных (СУБД) – это комплекс языковых и программных средств, предназначенных для создания, ведения и совместного использования базы данных одним или многими пользователями.

В настоящее время наиболее широкое распространение получили СУБД, построенные на основе реляционной модели данных, описываемой строгим математическим аппаратом теории отношений.

Особенностью СУБД работающих в КИС является тот факт, что им приходится управлять базами данных, размещенными на носителях, распределенных в пространстве.

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

Основными технологическими решениями при многопользовательской работе с базами данных являются файл/серверные и клиент/серверные технологии. Взяв наиболее приемлемый вариант из этих технологий, клиент/сервер в КИС организуются специализированные системы обработки распределенных баз данных. При этом управление распределенными базами данных осуществляется таким образом, что данные распределяются не на логическом, а на физическом уровне и сама база данных рассматривается как единая "суперсхема". В распределенной базе данных функции администратора распределяются между администратором интегрированной базы данных и администраторами локальных баз данных. Администратор интегрированной базы данных следит за разграничением доступа разных пользователей к базе данных и обеспечивает целостность и сохранность данных, а также защиту данных от одновременной их корректировки несколькими пользователями. Разграничение доступа осуществляется в соответствии с правами, предоставляемыми отдельным пользователям в сетевой операционной системе.

Характерной особенностью созданных с помощью СУБД программ для работы с удаленными и распределенными корпоративными базами данных является использование открытого интерфейса доступа к данным – ODBC (Open Data Base Connectivity). Все функции по передаче данных возлагаются на интерфейс ODBC, который является связующим мостом между СУБД интегрированной базы и СУБД клиентских приложений. При этом СУБД клиента могут взаимодействовать не только со своими локальными базами, но и с данными, расположенными в интегрированной базе. Клиент имеет возможность посылать запросы на СУБД интегрированной базы, получать по ним данные и пересылать собственные обновленные данные.

Отраслевые модели данных

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

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

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

Как правило, выделяются модели более высокого уровня (и более общие по содержанию) и более низкого (соответственно, более детальные). Верхний уровень моделирования – это так называемые концептуальные модели данных (conceptual data models), которые дают самую общую картину функционирования предприятия или организации. Концептуальная модель включает основные концепции или предметные области, критичные для функционирования организации; обычно их количество не превышает 12-15. Такая модель описывает классы сущностей, важных для организации (бизнес-объекты), их характеристики (атрибуты) и ассоциации между парами этих классов (т.е. связи). Поскольку в бизнес-моделировании терминология еще окончательно не устоялась, в различных англоязычных источниках концептуальные модели данных могут также носить название subject area model (что можно перевести как модели предметных областей) или subject enterprise data model (предметные корпоративные модели данных).

Следующий иерархический уровень – это логические модели данных (logical data models). Они также могут называться корпоративными моделями данных или бизнес-моделями. Эти модели содержат структуры данных, их атрибуты и бизнес-правила и представляют информацию, используемую предприятием, с точки зрения бизнес-перспективы. В такой модели данные организованы в виде сущностей и связей между ними. Логическая модель представляет данные таким образом, что они легко воспринимаются бизнес-пользователями. В логической модели может быть выделен словарь данных – перечень всех сущностей с их точными определениями, что позволяет различным категориям пользователей иметь общее понимание всех входных и информационных выходных потоков модели. Следующий, более низкий уровень моделирования – это уже физическая реализация логической модели с помощью конкретных программных средств и технических платформ.

Логическая модель содержит детальное корпоративное бизнес-решение, которое обычно принимает форму нормализованной модели. Нормализация – это процесс, который гарантирует, что каждый элемент данных в модели имеет только одно значение и полностью и однозначно зависит от первичного ключа. Элементы данных организуются в группы согласно их уникальной идентификации. Бизнес-правила, управляющие элементами данных, должны быть полностью включены в нормализованную модель с предварительной проверкой их достоверности и корректности. Например, такой элемент данных, как Имя клиента, скорее всего, будет разделен на Имя и Фамилию и сгруппирован с другими соответствующими элементами данных в сущность Клиент с первичным ключом Идентификатор клиента.

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

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

У компании может быть два пути создания корпоративной логической модели данных: строить ее самостоятельно или воспользоваться готовой отраслевой моделью (industry logical data model). В данном случае различия в терминах отражают лишь разные подходы к построению одной и той же логической модели. В том случае, если компания самостоятельно разрабатывает и внедряет собственную логическую модель данных, то такая модель, как правило, носит название просто корпоративной логической модели. Если же организация решает воспользоваться готовым продуктом профессионального поставщика, то тогда можно говорить об отраслевой логической модели данных. Последняя представляет собой готовую логическую модель данных, с высокой степенью точности отражающую функционирование определенной отрасли. Отраслевая логическая модель – это предметно-ориентированный и интегрированный вид всей информации, которая должна находиться в корпоративном Хранилище данных для получения ответов как на стратегические, так и на тактические бизнес-вопросы. Как и любая другая логическая модель данных, отраслевая модель не зависит от прикладных решений. Она также не включает производные данные или другие вычисления для более быстрого извлечения данных. Как правило, большинство логических структур такой модели находят хорошее воплощение в ее эффективной физической реализации. Такие модели разрабатываются многими поставщиками для самых различных областей деятельности: финансовой сферы, производства, туризма, здравоохранения, страхования и т.д.

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

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

Специалист в области бизнес-аналитики (Business Intelligence) Стив Хобермэн (Steve Hoberman) выделяет пять факторов, которые необходимо принимать во внимание при решении вопроса о приобретении отраслевой модель данных. Первый – это время и средства, необходимые для построения модели. Если организации необходимо быстро добиться результатов, то отраслевая модель даст преимущество. Использование отраслевой модели не может немедленно обеспечить картину всей организации, но способно сэкономить значительное количество времени. Вместо собственно моделирования время будет потрачено на связывание существующих структур с отраслевой моделью, а также на обсуждение того, как лучше ее настроить под нужды организации (например, какие определения должны быть изменены, а какие элементы данных – добавлены).

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

Третий фактор – опыт в оценке рисков и моделировании. Создание корпоративной модели данных требует квалифицированных ресурсов как со стороны бизнеса, так и IT-персонала. Как правило, менеджеры хорошо знают либо работу организации в целом, либо деятельность конкретного отдела. Лишь немногие их них обладают как широкими (в масштабах всей компании), так и глубокими (в рамках подразделений) знаниями о своем бизнесе. Большинство менеджеров обычно хорошо знают только одну область. Поэтому, для того чтобы получить общекорпоративную картину, требуются существенные бизнес-ресурсы. Это увеличивает и требования к IT-персоналу. Чем больше бизнес-ресурсов требуется для создания и тестирования модели, тем более опытными должны быть аналитики. Они должны не только знать, как получить информацию от бизнес-персонала, но также уметь находить общую точку зрения в спорных областях и быть способными представлять всю эту информацию в интегрированном виде. Тот, кто занимается созданием модели (во многих случаях это тот же аналитик), должен обладать хорошими навыками моделирования. Создание корпоративных логических моделей требует моделирования «для будущего» и способности конвертировать сложный бизнес в буквальном смысле «в квадраты и линии».

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

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

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

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

Отраслевые модели данных обеспечивают компаниям единое интегрированное представление их бизнес-информации. Многим компаниям бывает непросто осуществить интеграцию своих данных, хотя это является необходимым условием для большинства общекорпоративных проектов. По данным исследования Института Хранилищ данных (The Data Warehousing Institute, TDWI), более 69% опрошенных организаций обнаружили, что интеграция является существенным барьером при внедрении новых приложений. Напротив, осуществление интеграции данных приносит компании ощутимый доход.

Отраслевая модель данных, помимо связей с уже существующими системами, дает большие преимущества при осуществлении общекорпоративных проектов, таких как планирование ресурсов предприятия (Enterprise Resource Planning, ERP), управление основными данными, бизнес-аналитика, повышение качества данных и повышение квалификации сотрудников.

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

Публикации

1. Стив Хобермэн (Steve Hoberman). Использование отраслевой логической модели данных в качестве корпоративной модели (Leveraging the Industry Logical Data Model as Your Enterprise Data Model).
2. Клодиа Имхоф (Claudia Imhoff). Оперативное создание Хранилищ данных и выполнение проектов Business Intelligence с помощью моделирования данных (Fast-Tracking Data Warehousing & Business Intelligence Projects via Intelligent Data Modeling)

Корпоративная база данных является центральным звеном корпоративной информационной системы и позволяет создать единое информационное пространство корпорации. Корпоративные базы данных

Поделитесь работой в социальных сетях

Если эта работа Вам не подошла внизу страницы есть список похожих работ. Так же Вы можете воспользоваться кнопкой поиск

ТЕМА V. КОРПОРАТИВНЫЕ БАЗЫ ДАННЫХ

V .1. Организация данных в корпоративных системах. Корпоративные базы данных.

V .2. СУБД и структурные решения в корпоративных системах.

V .3. Технологии Internet / Intranet и корпоративные решения по доступу к базам данных.

V .1. ОРГАНИЗАЦИЯ ДАННЫХ В КОРПОРАТИВНЫХ СИСТЕМАХ. КОРПОРАТИВНЫЕ БАЗЫ ДАННЫХ

Корпоративная база данных является центральным звеном корпоративной информационной системы и позволяет создать единое информационное пространство корпорации. Корпоративные базы данных (рис.1.1).

Существуют различные определения баз данных.

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

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

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

Цель создания баз данных как формы хранения данных  построение системы данных, не зависящих от принятых алгоритмов (программного обеспечения), применяемых технических средств, физического расположения данных в ЭВМ. База данных предполагает многоцелевое использование (несколько пользователей, множество форм документов и запросов одного пользователя).

Основные требования к базам данных:

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

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

База знаний (БЗ)  совокупность баз данных и используемых правил, полученных от лиц, принимающих решения. База знаний является элементом экспертных систем.

Следует различать различные способы представления данных .

Физические данные – это данные, хранящиеся в памяти ЭВМ.

Логическое представление данных соответствует пользовательскому представлению физических данных. Различие между физическим и соответствующим логическим представлением данных состоит в том, что последнее отражает некоторые важные взаимосвязи между физическими данными.

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

Рис. 1.1. Структура взаимодействия подразделений с информационными ресурсами корпорации.

Корпоративные базы данных бывают сосредоточенные (централизованные ) и распределенные.

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

Рис.1.2. Схема гетерогенной централизованной базы данных

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

• Большой поток обмена данными;
• Высокий трафик в сети;
• Низкая надежность;
• Низкая общая производительность.

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

• Более высокая степень одновременности обработки вследствие распределения нагрузки;
• Улучшение использования данных на местах при выполнении удаленных (дистанционных) запросов;
• Меньшие затраты;
• Простота управления локальными базами.

Затраты на создание сети, в узлах которой находятся рабочие станции (малые ЭВМ), гораздо ниже, чем затраты на создание аналогичной системы с использованием большой ЭВМ. На Рис.1.3 приведена логическая схема распределенной базы данных.

Рис.1.3. Распределенная база данных корпорации.

Дадим следующее определение распределенной базы данных.

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

Важнейшие требования к характеристикам распределенной базы данных таковы:

• Масштабируемость;
• Совместимость;
• Поддержка различных моделей данных;
• Переносимость;
• Прозрачность расположения;
• Автономность узлов распределенной базы данных (Site Autonomy);
• Обработка распределенных запросов;
• Выполнение распределенных транзакций.
• Поддержка однородной системы безопасности.

Прозрачность расположения позволяет пользователям работать с базами данных, не зная ничего об их расположении. Автономность узлов распределенной базы данных означает, что ведение каждой базы может происходить независимо от других. Распределенный запрос - это такой запрос (SQL-предложение), в ходе выполнения которого происходит доступ к объектам (таблицам или представлениям) разных баз данных. При выполнении распределенных транзакций осуществляется согласованное управление (concurrency control) всеми вовлеченными базами данных. Oracle7 использует технологию двухфазной передачи информации для выполнения распределенных транзакций.

Базы данных, составляющие распределенную базу данных, не обязательно должны быть однородными (т.е. вестись одной СУБД) или обрабатываться в среде одной и той же операционной системы и/или на компьютерах одного и того же типа. Например, одна база данных может быть базой Oracle на компьютере SUN с операционной системой SUN OS(UNIX), вторая база данных может вестись СУБД DB2 на мейнфрейме IBM 3090 с операционной системой MVS, а для ведения третьей базы может использоваться СУБД SQL/DS также на мейнфрейме IBM, но с операционной системой VM. Обязательно только одно условие - все машины с базами данных должны быть доступны по сети, в которую они входят.

Основная задача распределенной базы данных – распределение данных по сети и обеспечения доступа к ней. Существуют следующие способы решения этой задачи:

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

При создании распределенной базы данных на концептуальном уровне приходится решать следующие задачи:

• Необходимо иметь единую концептуальную схему всей сети. Это обеспечит логическую прозрачность данных для пользователя, в результате чего он сможет сформировать запрос ко всей базе, находясь за отдельным терминалом (он как бы работает с централизованной базой данных).
• Необходима схема, определяющая местонахождение данных в сети. Это обеспечит прозрачность размещения данных, благодаря которой пользователь может не указывать, куда переслать запрос, чтобы получить требуемые данные.
• Необходимо решить проблему неоднородности распределенных баз данных. Распределенные базы могут быть однородными и неоднородными в смысле аппаратных и программных средств. Проблема неоднородности сравнительно легко решается, если распределенная база данных является неоднородной в смысле аппаратных средств, но однородной в смысле программных средств (одинаковые СУБД в узлах). Если же в узлах распределенной системы используются разные СУБД, необходимы средства преобразования структур данных и языков. Это должно обеспечить прозрачность преобразования в узлах распределенной базы данных.
• Необходимо решить проблему управления словарями. Для обеспечения всех видов прозрачности в распределенной базе данных нужны программы, управляющие многочисленными словарями и справочниками.
• Необходимо определить методы выполнения запросов в распределенной базе данных. Методы выполнения запросов в распределенной базе данных отличаются от аналогичных методов в централизованных базах, так как отдельные части запросов нужно выполнять на месте расположения соответствующих данных и передавать частичные результаты на другие узлы; при этом должна быть обеспечена координация всех процессов.
• Необходимо решить проблему параллельного выполнения запросов. В распределенной базе нужен сложный механизм управления одновременной обработкой, который, в частности, должен обеспечить синхронизацию при обновлениях информации, что гарантирует непротиворечивость данных.
• Необходима развитая методология распределения и размещения данных, включая расщепление, является одним из основных требований к распределенной базе данных.

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

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

Для реализации машины баз данных были разработаны параллельные и ассоциативные архитектуры, как альтернатива однопроцессорной фоннеймановской структуре, позволяющие работать с большими объемами информации в реальном масштабе времени.

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

Информационные хранилища. Сегодня многие признают, что уже сейчас в большинстве компаний эксплуатируется несколько БД и, для успешной работы с информацией, требуются не просто разнотипные базы данных, а разные поколения СУБД. Согласно статистике, в каждой организации используется в среднем 2,5 различных СУБД. Стала очевидной необходимость "изолировать" бизнес компаний, вернее, людей, занимающихся этим бизнесом, от технологических особенностей баз данных, предоставить пользователям единый взгляд на корпоративную информацию независимо от того, где она физически хранится. Это стимулировало появление технологии информационных хранилищ (Data Warehousing, DW).

Основная цель DW - создание единого логического представления данных, содержащихся в разнотипных БД, или, другими словами, единой модели корпоративных данных.

Новый виток развития DW стал возможным благодаря совершенствованию информационных технологий в целом, в частности появлению новых типов баз данных на основе параллельной обработки запросов, которые в свою очередь опирались на достижения в области параллельных компьютеров. Были созданы программы-конструкторы запросов с интуитивным графическим интерфейсом, позволившие легко строить сложные запросы к БД. Разнообразное ПО промежуточного слоя (midleware) обеспечило связь между разнотипными базами данных , и, наконец, резко подешевели устройства хранения информации .

В структуре корпорации может присутствовать банк данных.

Банк данных – функционально-организационная компонента в автоматизированных системах управления и информационно-вычислительных системах, осуществляющая централизованное информационное обеспечение коллектива пользователей или совокупности решаемых в системе задач.

Банк данных рассматривают как информационно-справочную систему, основное назначение которой состоит:

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

Таким образом, современный банк данных представляет собой сложный программно-технический комплекс, в состав которого входят технические, системные и сетевые средства, базы данных и СУБД, информационно-поисковые системы различного назначения.

V .2. СУБД И СТРУКТУРНЫЕ РЕШЕНИЯ В КОРПОРАТИВНЫХ СИСТЕМАХ

Системы управления базами данных и знаний

Важной составляющей современных информационных систем являются системы управления базами данных (СУБД).

СУБД – комплекс программных и языковых средств, предназначенных для создания, ведения и использования баз данных.

Система управления базами данных обеспечивает доступ систем обработки данных к базам данных. Как уже отмечалось, важную роль СУБД приобретают при создании корпоративных информационных систем и, особо важную роль, при создании информационных систем использующих распределенные информационные ресурсы, базирующиеся на современных сетевых компьютерных технологиях.

Основная особенность современных СУБД - это то, что современные СУБД поддерживают такие технологии как:

• Технологию клиент/сервер.
• Поддержка языков БД. Это язык определения схемы БД (SDL - Schema Definition Language), язык манипулирования данными (DML - Data Manipulation Language), интегрированные языки SQL (Structured Queue Language), QDB (Query - By - Example) и QMF (Query Management Facility ) – развитое периферийное средство спецификации запросов и генерации отчетов для DB 2 и т. д.;
• Непосредственное управление данными во внешней памяти.
• Управление буферами оперативной памяти.
• Управление транзакциями. OLTP – технология (On -Line Transaction Processing), OLAP – технология (On -Line Analysis Processing) для DW.
• Обеспечить защиту и целостность данных. Использование системы разрешается лишь пользователям, имеющим право доступа к данным. При выполнении пользователями операций над данными поддерживается согласованность хранящихся данных (целостность). Это важно в корпоративных многопользовательских информационных системах.
• Журнализация.

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

• Независимость данных.
• Универсальность. СУБД должна обладать мощными средствами поддержки концептуальной модели данных для отображения пользовательских логических представлений.
• Совместимость. СУБД должна сохранять работоспособность при развитии программного и аппаратного обеспечения.
• Неизбыточность данных. В отличие от файловых систем база данных должна представлять собой единую совокупность интегрированных данных.
• Защита данных. СУБД должна обеспечивать защиту от несанкционированного доступа.
• Целостность данных. СУБД должна предотвращать нарушение базы данных пользователями.
• Управление одновременной работой. СУБД должна предохранять базу данных от рассогласований в режиме коллективного доступа. Для обеспечения согласованного состояния базы все запросы пользователей (транзакции) должны выполняться в определенном порядке.
• СУБД должна быть универсальной. Она должна поддерживать разные модели данных на единой логической и физической основе.
• СУБД должна поддерживать как централизованные, так и распределенные базы данных и, таким образом, стать важным звеном вычислительных сетей.

Рассматривая СУБД как класс программных продуктов, ориентированных на поддержание в автоматизированных системах баз данных, можно выделить два наиболее существенных признака, определяющих типы СУБД. Согласно им, СУБД можно рассматривать с двух точек зрения:

• их возможностей по отношению к распределенным (корпоративным) базам;
• их отношения к типу реализуемой в СУБД модели данных.

По отношению к корпоративным (распределенным) базам данных условно можно выделить следующие типы СУБД:

• СУБД «рабочего стола». Эти продукты, в первую очередь ориентированы на работу с персональными данными (данные "рабочего стола"). Они имеют наборы команд для совместного использования общих БД, но небольшого размера (типа малого офиса). Прежде всего, это СУБД типа Ассеss, dВАSЕ, Рагаdох, ЕохРго. Почему Ассеss, dВАSЕ, Рагаdох, ЕохРго имеют неудовлетворительный доступ к корпоративным данным. Дело в том, что не существует простого способа преодолеть барьер между персональными и корпоративными данными. И суть даже не в том, что механизм СУБД персональных данных (или малого офиса) ориентирован на доступ к данным через многие шлюзы, межсетевые продукты и т.д. Проблема состоит в том, что эти механизмы обычно связаны с полной передачей файлов и отсутствием разветвленной поддержки индексов, в результате чего очереди к серверу практически останавливают работу в больших системах.
• Специализированные высокопроизводительные многопользовательские СУБД. Такие СУБД характеризуются наличием многопользовательского ядра системы, языка манипулирования данными и следующими функциями, характерными для развитых многопользовательских СУБД:
• организацией буферного пула;
• наличием системы обработки очередей транзакций;
• наличием механизмов многопользовательской блокировки данных;
• ведением журнала транзакций;
• наличием механизмов разграничения доступа.

Это СУБД типа Oracle, DВ2, SQL/Server, Informix, Sybase, ADABAS, Titanium и другие предоставляют широкий сервис для обработки корпоративных БД.

При работе с базами данных используется механизм транзакций.

Транзакция – это логическая единица работы.

Транзакция - это последовательность операторов манипулирования данными, выполняющаяся как единое целое (все или ничего) и переводящая базу данных из одного целостного состояния в другое целостное состояние .

Транзакция обладает четырьмя важными свойствами, известными как свойства АСИД:

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

Транзакция обычно начинается автоматически с момента присоединения пользователя к СУБД и продолжается до тех пор, пока не произойдет одно из следующих событий:

• Подана команда COMMIT WORK (зафиксировать транзакцию).
• Подана команда ROLLBACK WORK (откатить транзакцию).
• Произошло отсоединение пользователя от СУБД.
• Произошел сбой системы.

Для пользователя она носит, как правило, атомарный характер . На самом деле это сложный механизм взаимодействия пользователь (приложение) – база данных. Программное обеспечение корпоративных систем используют механизм обработки транзакций в реальном времени (On-lineTransaction Processing Systems, OLTP ), в частности программы бухгалтерского учета, программное обеспечение приема и обработки клиентских заявок, финансовые приложения, производят массу информации. Эти системы рассчитаны (и соответствующим образом оптимизированы) на обработку больших объемов данных, выполнение сложных транзакций и интенсивных операций чтения/записи.

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

Доставкой информации конечному пользователю - занимаются системы аналитической обработки данных в реальном времени (On-line Analytical Processing, OLAP) , которые обеспечивают исключительно простой доступ к данным за счет удобных средств генерации запросов и анализа результатов. В OLAP-системах ценность информационного товара увеличивается благодаря применению разнообразных методов анализа и статистической обработки. Кроме того, эти системы оптимизированы с точки зрения скорости извлечения данных, сбора обобщенной информации и ориентированы на рядовых пользователей (имеют интуитивно понятный интерфейс). Если OLTP-система выдает ответы на простые вопросы типа "каков был уровень продаж товара N в регионе M в январе 199х г.?", то OLAP- системы готовы к более сложным запросам пользователей, например: "Дать анализ продаж товара N по всем регионам по плану на второй квартал в сравнении с двумя предыдущими годами".

Архитектура клиент/сервер

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

		База данных
Компьютер-сервер
Сеть
IBM-совместимый ПК	IBM-совместимый ПК	IBM-совместимый ПК
		Приложения

Рис. 2.1. Система архитектуры клиент-сервер

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

Сервер (Server) – это объект (ЭВМ), предоставляющий услуги другим объектам по их запросам.

Как следует уже из самого термина, главная функция компьютера-сервера заключается в обслуживании потребностей клиента. Термин "Сервер" используется для обозначения двух различных групп функций: файл-сервер и сервер баз данных (далее эти термины означают в зависимости от контекста либо программное обеспечение, реализующее указанные группы функций, либо компьютеры с этим программным обеспечением). Файл-серверы не предназначены для выполнения операций с базами данных, их основная функция - разделение файлов между несколькими пользователями, т.е. обеспечение одновременного доступа многих пользователей к файлам на компьютере - файл-сервере. Примером файл-сервера является операционная система NetWare компании Novell. Сервер баз данных можно установить и привести в действие на компьютере -- файл-сервере. СУБД Oracle в виде NLM (Network Loadable Module) выполняется в среде NetWare на файл-сервере.

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

Одно из важных требований к серверу - это то, что операционная система, в среде которой размещен сервер баз данных, должна быть многозадачной (и, желательно, но не обязательно, многопользовательской). Например, СУБД Oracle, установленная на персональном компьютере с операционной системой MS-DOS (или PC-DOS), не удовлетворяющей требованию многозадачности, не может использоваться как сервер баз данных. И та же СУБД Oracle, установленная на компьютере с многозадачной (хотя и не многопользовательской) операционной системой OS/2, может быть сервером баз данных. Многие разновидности систем UNIX, MVS, VM и некоторые другие операционные системы являются и многозадачными, и многопользовательными.

Распределенные вычисления

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

• Распределенная база данных;
• Распределенная обработка данных.

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

Существует много типов серверов:

• Сервер баз данных;
• Сервер печати;
• Сервер удаленного доступа;
• Факс-сервер;
• Web -сервер и т.д.

В основе базовой технологии Клиент/сервер лежат такие базовые технологии, как:

• Технологии операционных систем, концепция взаимодействия открытых систем, создание объектно-ориентированных сред функционирования программ;
• Телекоммуникационные технологии;
• Сетевые технологии;
• Технологии графического пользовательского интерфейса (GUI);
• И т.д.

Преимущества технологии клиент-сервер:

• Технология клиент/сервер позволяет производить вычисления на неоднородных вычислительных средах. Независимость от платформ: доступ к разнородным сетевым средам, в состав которых входят компьютеры разных типов с различными операционными системами.
• Независимость от источников данных: доступ к информации разнородных баз данных. Примеры таких систем -- DB2, SQL/DS, Oracle, Sybase.
• Баланс загрузки клиента и сервера.
• Выполнение вычислений там, где это происходит наиболее эффективно;
• Предоставляют возможность эффективного масштабирования;
• Межплатформные вычисления . Межплатформные вычисления определяются просто как реализация технологий в неоднородных вычислительных средах. Здесь должны быть обеспечены следующие возможности:
• Приложение должно выполняться на нескольких платформах;
• На всех платформах оно должно иметь один и тот же интерфейс и логику работы;
• Приложение должно интегрироваться с родной операционной средой;
• Оно должно одинаково вести себя на всех платформах;
• Для него должна предусматриваться простая и согласованная поддержка.

 Распределенные вычисления. Распределенные вычисления предусматривают распределение работ между несколькими вычислительными машинами (правда, распределенные вычисления более широкое понятие).

 Разукрупнение. Разукрупнение – перенос приложений для больших ЭВМ на малые компьютерные платформы.

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

 Сокращение общего времени выполнения приложения;

 Уменьшение использования клиентом памяти;

 Сокращение сетевого трафика.

• Возможность работы с мультимедиа: к настоящему времени создано немало программ работы с мультимедиа для ПК. Подобных программ для конфигурации терминал-хост либо нет, либо они очень дороги.
• Возможность привлечения больших вычислительных ресурсов для операций с базами данных: поскольку приложения выполняются на компьютерах-клиентах, на компьютере-сервере для операций с базами данных высвобождаются дополнительные (по сравнению с конфигурацией терминал-хост) ресурсы, такие, как вычислительные ресурсы центрального процессора и оперативная память.
• Более высокая продуктивность работы программистов: производительность труда программистов возрастает благодаря использованию таких средств, как SQL*Forms и CASE: они позволяют разрабатывать приложения быстрее, чем такие языки программирования, как C, PL1 или COBOL.
• Повышение продуктивности работы конечных пользователей: в настоящее время многие конечные пользователи освоили такие системы, как Lotus, Paradox, Word Perfect, Harvard Graphics и т.д.

Интерфейс серверной части определен и фиксирован. Поэтому возможно создание новых клиентских частей существующей системы (пример интероперабельности на системном уровне).

Рис. 2.2. Иллюстрация доступа клиентов к общему ресурсу сервера.

Как внедрить технологию клиент-сервер

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

• компьютер-сервер базы данных;
• компьютеры-клиентов;
• коммуникационная сеть;
• сетевое программное обеспечение;
• прикладное программное обеспечение.

Язык SQL . Язык запросов высокого уровня - SQL (Structured Query Language ) служит для реализации запросов к базам данных, таких как ЯМД, ЯОД и ПЯД и принят в качестве стандарта. Язык SQL первоначально был принят в качестве языка данных программных изделий фирмы IBM и ЯМД реляционной СУБД SYSTEM R фирмы IBM . Важной особенностью языка SQL заключается в том, что один и тот же язык представляется через два различных интерфейса, а именно: через интерактивный интерфейс и через интерфейс прикладного программирования (динамический SQL). Динамический SQL состоит из множества возможностей встроенного языка SQL , предусмотренных специально для конструирования интерактивных приложений, где под интерактивным приложением понимается программа, которая написана для поддержки обращения к базе данных конечного пользователя, работающего на интерактивном терминале. Язык SQL обеспечивает выполнение функций определения, манипулирования и управления данными баз данных и является прозрачным для пользователя с точки зрения реализуемой СУБД.

Рис. 2.3. Схема выполнения запросов пользователя к распределенным базам данных.

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

Модель данных состоит из трех компонент:

• Структура данных для представления с точки зрения пользователя на базу данных.
• Допустимые операции, выполняемые на структуре данных. Необходимо иметь возможность работать с этой структурой при помощи различных операций ЯОД и ЯМД. Богатая структура ничего не стоит, если нет возможности оперировать ее содержимым.
• Ограничения для контроля целостности. Модель данных должна быть обеспечена средствами, позволяющими сохранять ее целостность и защищать ее. В качестве примера рассмотрим два следующих ограничения:
• Каждое поддерево должно иметь исходный узел. В иерархических базах данных нельзя хранить порожденные узлы без исходного узла.
• В отношении реляционной базы данных не может быть одинаковых кортежей. Для файла это требование требует уникальности всех записей.

Одной из важнейших характеристик работы СУБД является возможность связывать объекты.

Существуют следующие виды связей между объектами:

• Один-к-Одному (1:1) . Один объект одного множества может быть связан с одним объектом другого множества.
• Один-ко-Многим (1:M) . Один объект одного множества может быть связан со многими объектами другого множества.
• Многие-ко-Многим (M:N) . Один объект одного множества может быть связан со многими объектами другого множества, но при этом один объект другого множества может быть связан со многими объектами первого множества.
• Разветвленная . Один объект одного множества может быть связан с объектами многих множеств.
• Рекурсивная . Один объект данного множества может быть связан объектом этого же множества.

Существуют следующие основные модели данных:

• Реляционная модель данных.
• Иерархическая модель данных.
• Неполная сетевая модель данных.
• Модель данных CODASYL.
• Расширенная сетевая модель данных.

V .3. ТЕХНОЛОГИИ INTERNET / INTRANET И КОРПОРАТИВНЫЕ РЕШЕНИЯ ПО ДОСТУПУ К БАЗАМ ДАННЫХ

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

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

Общим решением проблемы мобильности систем, основанных на архитектуре "клиент-сервер" является опора на программные пакеты, реализующие протоколы удаленного вызова процедур (RPC - Remote Procedure Call). При использовании таких средств обращение к сервису в удаленном узле выглядит как обычный вызов процедуры. Средства RPC, в которых, естественно, содержится вся информация о специфике аппаратуры локальной сети и сетевых протоколов, переводит вызов в последовательность сетевых взаимодействий. Тем самым, специфика сетевой среды и протоколов скрыта от прикладного программиста.

При вызове удаленной процедуры программы RPC производят преобразование форматов данных клиента в промежуточные машинно-независимые форматы и затем преобразование в форматы данных сервера. При передаче ответных параметров производятся аналогичные преобразования.

Другие похожие работы, которые могут вас заинтересовать.вшм>
6914.		Понятие базы данных	11.56 KB
	Базой данных является представленная в объективной форме совокупность самостоятельных материалов статей расчетов нормативных актов судебных решений и иных подобных материалов систематизированных таким образом чтобы эти материалы могли быть найдены и обработаны с помощью электронной вычислительной машины Гражданский кодекс РФ ст. База данных организованная в соответствии с определёнными правилами и поддерживаемая в памяти компьютера совокупность данных характеризующая актуальное состояние некоторой...
8064.		Распределенные базы данных	43.66 KB
	Распределенные базы данных Под распределенной базой данных РБД понимается набор логически связанных между собой разделяемых данных которые физически распределены по разных узлам компьютерной сети. Доступ к данным не должен зависеть от наличия или отсутствия реплик данных. Система должна автоматически определять методы выполнения соединения объединения данных сетевой канал способный справиться с объёмом передаваемой информации и узел имеющий достаточную вычислительную мощность для соединения таблиц. СУРБД должна быть способной...
20319.		БАЗЫ ДАННЫХ И ИХ ЗАЩИТА	102.86 KB
	Оперативные сетевые базы данных появились в середине 1960-х. Операции над оперативными базами данных обрабатывались в интерактивном режиме с помощью терминалов. Простые индексно-последовательные организации записей быстро развились к более мощной модели записей, ориентированной на наборы. За руководство работой Data Base Task Group (DBTG), разработавшей стандартный язык описания данных и манипулирования данными, Чарльз Бахман получил Тьюринговскую премию.
5031.		Разработка базы данных Библиотека	11.72 MB
	Технология проектирования баз данных. Определение взаимосвязей между сущностями и создание модели данных. Основные идеи современной информационной технологии базируются на концепции согласно которой данные должны быть организованы в базы данных с целью адекватного отображения изменяющегося реального мира и удовлетворения информационных потребностей пользователей. Эти базы данных создаются и функционируют под управлением специальных программных комплексов называемых системами управления базами данных СУБД.
13815.		ИЕРАРХИЧЕСКАЯ МОДЕЛЬ БАЗЫ ДАННЫХ	81.62 KB
	Основные идеи современной информационной технологии базируются на концепции баз данных согласно которой основой информационной технологии являются данные организованные в базах данных адекватно отражающие состояние той или иной предметной области и обеспечивающие пользователя актуальной информацией в этой предметной области. Необходимо признать тот факт что данные являются...
14095.		Разработка базы данных библиотеки	11.72 MB
	Увеличение объема и структурной сложности хранимых данных, расширение круга пользователей информационных систем привели к широкому распространению наиболее удобных и сравнительно простых для понимания реляционных (табличных) СУБД.
5061.		Создание базы данных поликлиники	2.4 MB
	Развитие средств вычислительной техники и информационных технологий обеспечило возможности для создания и широкого применения автоматизированных информационных систем (АИС) разнообразного назначения. Разрабатываются и внедряются информационные системы управления хозяйственными и техническими объектами
13542.		Базы данных геологической информации	20.73 KB
	В последнее время широкими темпами происходит внедрение компьютерных технологий и, в частности баз данных, в научную сферу. Этот процесс не обходит стороной и геологию, так как именно в естественных науках имеется необходимость для хранения и обработки больших объемов информации.
9100.		Базы данных. Основные понятия	26.28 KB
	База данных – это совокупность сведений о конкретных объектах реального мира в какой-либо предметной области экономика менеджмент химия и т. Целью информационной системы является не просто хранение данных об объектах но и манипулирование этими данными учитывая связи между объектами. Каждый объект характеризуется каким-либо набором данных свойств которые в БД называются атрибутами.
5240.		Создание базы данных «Деканат ВУЗа»	1.57 MB
	База данных (БД) - это совокупность взаимосвязанных, хранящихся вместе на внешних носителях памяти компьютера данных, при наличии такой организации и минимальной избыточности, которая допускает их использование оптимальным образом для одного или нескольких приложений

Цель лекции

Изучив материал настоящей лекции, вы будете знать:

• что такое корпоративная модель данных ;
• как преобразовать корпоративную модель данных в модель хранилища данных;
• основные элементы корпоративной модели данных ;
• уровни представления корпоративной модели данных ;
• алгоритм преобразования корпоративной модели данных в многомерную модель хранилища данных ;

и научитесь:

• разрабатывать модели хранилища данных на основе корпоративной модели данных организации;
• разрабатывать схему "звезда" с помощью CASE-средств;
• секционировать таблицы многомерной модели с помощью CASE-средств.

Корпоративная модель данных

Введение

Ядром любого ХД является его модель данных. Без модели данных будет очень сложно организовать данные в ХД. Поэтому разработчики ХД должны потратить время и силы на разработку такой модели. Разработка модели ХД ложится на плечи проектировщика ХД.

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

Отправной точкой в проектировании ХД может служить так называемая корпоративная модель данных (corporate data model или enterprise data model, EDM), которая создается в процессе проектирования OLTP-систем организации. При проектировании корпоративной модели данных обычно предпринимается попытка создать на основе бизнес-операций такую структуру данных, которая бы собрала и синтезировала в себе все информационные потребности организации.

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

Корпоративная модель данных

Как решить задачу преобразования корпоративной модели данных в модель ХД? Чтобы решить эту задачу, нужно иметь эту модель, т.е. корпоративная модели данных должна быть построена и документирована . И нужно понять, что из этой модели и как должно трансформироваться в модель ХД.

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

Основными элементами корпоративной модели данных являются:

• описание предметных областей организации (определение сфер деятельности);
• взаимоотношения между определенными выше предметными областями;
• информационная модель данных (ERD -модель или модель "сущность-связь");
• для каждой предметной области описание:
  • ключей сущностей;
  • атрибутов сущностей ;
  • подтипов и супертипов;
  • связей между сущностями;
  • группировки атрибутов;
  • взаимосвязей между предметными областями;
• функциональная модель или модель бизнес-процессов;
• диаграммы потоков данных;
• диаграммы состояний;
• другие модели.

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

Уровни представления корпоративной модели данных

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

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

Корпоративная модель данных обычно имеет несколько уровней представления. На самом высоком уровне (high level) корпоративной модели данных располагается описание основных предметных областей организации и их взаимосвязей на уровне сущностей. На рис. 16.2 приведен фрагмент корпоративной модели данных верхнего уровня.

Рис. 16.2.

На схеме, приведенной на рисунке, представлено четыре предметных области: "Покупатель" (Customer ), "Счет" (account ), "Заказ" (Order ) и "Товар" (Product ). Как правило, на верхнем уровне представления модели указываются только прямые связи между предметными областями, которые, например, фиксируют следующий факт: покупатель оплачивает счет на заказ товаров. Подробная информация и косвенные взаимосвязи на этом уровне корпоративной модели не приводятся.

На следующем, среднем уровне (mid level) корпоративной модели данных показывается подробная информация об объектах предметных областей, т. е. ключи и атрибуты сущностей , их взаимосвязи, подтипы и супертипы и т.д. Для каждой предметной области модели верхнего уровня существует одна модель среднего уровня. На рис. 16.3 изображен средний уровень представления корпоративной модели для фрагмента предметной области "Заказ".

Из рис. 16.3 видно, что предметная область "Заказ" (Order ) включает в себя несколько сущностей, определенных через их атрибуты, и взаимосвязей между ними. Представленная модель позволяет ответить на такие вопросы, как дата заказа, кто сделал заказ, кто отправил заказ, кто получает заказ и ряд других. Из приведенной схемы видно, что в данной организации выделяют два типа заказов – заказы по рекламной акции (Commersial ) и заказы по розничной торговле (Retail ).

Заметим, что корпоративная модель данных может представлять различные аспекты деятельности организации и с различной степенью детализации и завершенности. Если корпоративная модель представляет все аспекты деятельности организации, она еще называется моделью данных организации (enterprise data model).

С точки зрения проектирования ХД важным фактором в принятии решения создания модели ХД из корпоративной модели данных является состояние завершенности корпоративной модели данных .

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

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

На самом низком уровне представления корпоративной модели данных показывается информация о физических характеристиках объектов БД, соответствующих логической модели данных среднего уровня представления корпоративной модели данных .

Обслуживание