Тема 7. Проектирование бд
7.1. Особенности проектирования хранилищ данных
При проектировании БД следует учитывать, что все БД можно разбить на два класса:
БД для оперативной обработки информации в реальном времени;
хранилища данных (data warehouse), в которых накапливается ретроспективная информация.
БД первого типа отличаются высокой степенью нормализации данных, что в значительной степени уменьшает избыточность представления информации и облегчает поддержку согласованности. Как правило, промышленная БД такого типа содержит сотни и тысячи таблиц малого объема с небольшим количеством атрибутов и имеет сложную структуру.
Рис. 7.1. Пример хранилища данных, построенного по схеме «звезда»
Хранилища данных обычно имеют простую денормализованную структуру, обеспечивающую высокую скорость выполнения сложных запросов. Типовой схемой хранилища данных является так называемая «звезда» (star schema), при которой вся хранимая фактографическая информация записывается в одну большую таблицу фактов (fact table). Каждая строка таблицы фактов соответствует точке в многомерном пространстве, определяемом измерениями хранилища данных. Измерение классифицирует некоторый факт и, как правило, имеет иерархическую структуру.
Для каждого измерения в таблице фактов заводится столбец, в котором в кодированном виде записываются значения измерения для каждой строки. С целью расшифровки закодированных значений для каждого измерения создается отдельная таблица (dimension table). Таблицы связываются на основании закодированных значений измерений так, что таблица фактов становится центром «звезды», а таблицы измерений — ее лучами (рис. 7.1). В общем случае, хранилище данных имеет несколько таблиц фактов и, следовательно, состоит из нескольких «звезд».
7.2. Особенности проектирования клиент-серверных ис
Современные ИС базируется на принципах распределенной обработки данных. Архитектура таких систем позволяет реализовать многопользовательский режим работы и является распределенной. Различные виды архитектур современных ИС часто объединяют под термином «клиент-серверная архитектура».
Под сервером обычно понимают процесс, который обслуживает информационную потребность клиента. Клиентом является приложение, посылающее запрос на обслуживание сервером. Задачей клиента являются инициирование связи с сервером, определение вида запроса на обслуживание, получение от сервера результата обслуживания, подтверждение окончания обслуживания. При этом клиенты и серверы, как правило, располагаются на разных узлах локальной или глобальной вычислительной сети.
В общем случае схема клиент-серверной архитектуры включает три уровня представления:
уровень представления данных пользователем (клиентом);
уровень обработки данных приложением;
уровень взаимодействия с БД.
По этой схеме клиент в одном случае вводит данные, которые после контроля и преобразования некоторым приложением попадают в БД, а в другом случае клиент запрашивает обработку данных приложением, которое обращается за необходимыми данными к БД. Получив необходимые данные, сервер их обрабатывает, а результаты или помещает в БД, или выдает клиенту в удобном для него виде, например в виде текстового документа, электронной таблицы, графика, или делает то и другое вместе.
Клиент-серверная архитектура в вычислительной сети может быть реализована по-разному. Выбор конкретной схемы определяется различными вариантами территориального распределения удаленных подразделений предприятия, требованиями эксплуатационной надежности, быстродействием, простотой обслуживания. Рассмотрим различные схемы клиент-серверной архитектуры:
Файл-серверная архитектура представляет наиболее простой случай распределенной обработки данных, согласно которой на сервере располагаются только файлы данных, а на клиентской части находятся приложения пользователей вместе с СУБД.
Двухуровневая клиент-серверная архитектура основана на использовании только сервера БД, когда клиентская часть содержит уровень представления данных, а на сервере находится БД вместе с СУБД и прикладными программами.
Обращение к БД осуществляется на языке SQL (Structured Query Language), который фактически стал стандартом для реляционных БД. Отсюда сервер БД часто называют SQL-сервером, который поддерживается всеми реляционными СУБД: Oracle, Informix, MS SQL, InterBase, SyBase и др. Клиентское приложение может быть реализовано на языке настольных СУБД MS Access, FoxPro, Paradox и др. При этом взаимодействие клиентского приложения с SQL-сервером осуществляется через ODBC-драйвер, который обеспечивает возможность пересылки и преобразования данных из глобальной БД в структуру БД клиентского приложения. Применение этой технологии позволило разработчикам не заботиться о специфике работы с той или иной СУБД и делать свои системы переносимыми между БД.
Трехуровневая клиент-серверная архитектура позволяет помещать прикладные программы на отдельные серверы приложений, с которыми через API-интерфейс (Application Program Interface) устанавливается связь клиентских рабочих станций. Работа клиентской части приложения сводится к вызову необходимых функций сервера приложения, которые называются «сервисами». Прикладные программы, в свою очередь, обращаются к серверу БД с помощью SQL запросов. Такая организация позволяет повысить производительность и эффективность ИС за счет:
многократности повторного использования общих функций обработки данных в множестве клиентских приложений при существенной экономии системных ресурсов;
параллельности в работе сервера приложений и сервера БД, причем сервер приложений может быть менее мощным по сравнению с сервером БД;
оптимизации доступа к БД через сервер приложений из клиентских мест путем диспетчеризации выполнения запросов в вычислительной сети;
повышения скорости и надежности обработки данных в результате дублирования ПО на нескольких серверах приложений, которые могут заменять друг друга в сети в случае перегрузки или выхода из строя одного из них;
переноса функций администрирования системы по проверке полномочий доступа пользователей с сервера БД на сервер приложений.
Многоуровневая клиент-серверная архитектура создается для территориально-распределенных предприятий. Для нее в общем случае характерны отношения «многие ко многим» между клиентскими рабочими станциями и серверами приложений, между серверами приложений и серверами БД. Такая организация позволяет более рационально организовать информационные потоки между структурными подразделениями в процессе выполнения общих деловых процессов. Так, каждый сервер приложений, как правило, обслуживает потребности какой-либо одной функциональной подсистемы и сосредоточивается в головном для подсистемы структурном подразделении, например, сервер приложения по управлению сбытом - в отделе сбыта, сервер приложения по управлению снабжением -в отделе закупок и т.д. Естественно, что локальная сеть каждого из подразделений обеспечивает более быструю реакцию на запросы основного контингента пользователей из соответствующего подразделения. Интегрированная БД находится на отдельном сервере, на котором обеспечиваются централизованное ведение и администрирование общих данных для всех приложений.
Выделение нескольких серверов БД особенно актуально для предприятий с филиальной структурой, когда в центральном офисе используется общая БД, содержащая общую нормативно-справочную, планово-бюджетную информацию и консолидированную отчетность, а в территориально-удаленных филиалах поддерживается оперативная информация о деловых процессах. При обработке данных в филиалах для контроля используется плановая и нормативно-справочная информация из центральной БД, а в центральном офисе получение консолидированной отчетности сопряжено с обработкой оперативной информации филиалов.