6. Распределенная база данных. Определение, основные термины, типы моделей, достоинства и недостатки

Основные модели использования баз данных.

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

Двухзвенные модели:

• Файл‑серверная (удаленного доступа к данным, модель RDA – Remote Data Access) – база данных находится на другом компьютере, который называется файл‑сервером, и приложение обращается за информацией к файлу‑серверу. Достоинство: наличие большого числа СУБД и программных средств, работающих в этом режиме. Недостаток: перегрузка каналов связи, так как фактически вся база копируется по каналам на клиентскую машину.

• Клиент‑серверная (модель сервера БД, DBS – DataBase Server) – отличается от предыдущей модели тем, что запросы в виде хранимых процедур хранятся и выполняются на сервере (СУБД Oracle, Ingress, Sybase). Достоинства: централизованное управление разработкой и выполнением приложения, уменьшение объемов пересылаемой информации по сети. Недостаток: ограниченные возможности хранимых процедур, которые обычно разрабатываются на SQL.

• Трехзвенная распределенная модель (компонентная или AS‑модель сервера приложений – Application Server) – к серверам баз добавляются серверы приложений, на которых выполняются приложения клиентов. Клиент формирует исходную информацию для расчета, посылает запрос на выполнение расчета на сервер приложения, где он и выполняется. При необходимости сервер приложения формирует запрос к серверу таблицы, который выполняет запрос, и результат посылает на сервер приложения. После выполнения расчета на сервере приложений результат посылается клиенту. Это позволяет разгрузить сервер таблицы за счет сервера приложения. Эта модель предполагает работу с очередями. Возможность хранения очередей в долговременной памяти позволяет сохранить эти очереди и возобновить с точки, где произошел сбой. Достоинства: гибкость и универсальность. Недостаток: более высокие затраты.

• Клиент‑Интернет (“тонкий клиент”). Доступ к базе данных реализуется из броузера Интернет. Это снижает требования к клиентской машине, при этом не требуется разработка специальных программ и протоколов обмена. Доступ к базе данных может быть как на стороне клиента, так и на стороне сервера. Внешние программы (CGI‑сценарии, CGI‑скриптами, ASP‑страницы) взаимодействуют с сервером БД на языке SQL или на командном языке работы с базой (Visual Basic [5], Delphi, C++ Builder, Visual C++ [6]) через драйверы ODBC или языки программирования, обеспечивающие унифицированный доступ к базам данных с различными СУБД. Внешние программы пишутся на языках C++, Delphi, Perl.

7. Принципы и этапы проектирования и создания баз данных

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

1. Удовлетворение информационных потребностей различных пользователей за приемлемое время и в удобной форме.

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

3. Достоверность данных, исключение дублирования.

4. Защита от несанкционированного доступа.

5. Восстановление данных и надежность функционирования.

Этапы и шаги проектирования и создания баз данных:

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

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

1.2. Определение типов связей. Определение типов связей между сущностями; документирование и составление ER‑диаграмм.

1.3. Определение атрибутов и их связей. Связывание атрибутов с сущностями; выявление простых, составных, множественных, производных атрибутов и их документирование.

1.4. Определение доменов атрибутов.

1.5. Определение первичных и вторичных ключей.

1.6. Определение суперклассов и подклассов для типов сущностей.

1.7. Создание ER‑диаграмм для отдельных пользователей.

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

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

2.1. Выбор целевой СУБД. Формулирование требований и ограничений к CУБД. Изучение и сравнительный анализ СУБД. Оценка кандидатов и выбор СУБД.

2.2. Преобразование локальной концептуальной модели в логическую. Удаление из концептуальной модели связей типа М:М, сложных, рекурсивных и избыточных связей, множественных атрибутов, связей с атрибутами. Перепроверка связей типа 1:1.

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

2.4. Нормализация отношений. Проверка и, при необходимости, проведение процедуры нормализации отношений, по крайней мере, в нормальную форму Бойса‑Кодда (НФБК) (п. 1.5.2).

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

2.6. Создание ER‑диаграмм для отдельных пользователей.

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

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

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

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

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

3.3. Проверка возможностей модификации модели в будущем. Оценка приспособленности модели к возможным изменениям в будущем.

3.4. Создание ER‑диаграммы глобальной логической модели.

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

4. Создание глобальной логической модели в среде целевой СУБД.

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

4.2. Реализация бизнес‑правил. Правила защиты, контроля, обновления и обработки данных.

5. Проектирование физического представления данных. Определение способов хранения таблиц, строк индексов и других элементов базы данных на магнитных дисках.

5.1. Анализ транзакций. Определение характеристик транзакций (частота выполнения, время доступа к данным и др.).

5.2. Настройка физической среды. Распределение файлов по различным дисководам и таблиц по файлам. Определение первичных и максимально возможных размеров файлов и их приращений. Формирование факторов заполнения страниц данных и индексов. Определение кластерных индексов.

5.3. Определение дополнительных индексов. Введение таких индексов может увеличить производительность системы.

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

6. Разработка механизма защиты.

6.1. Разработка представлений (видов) для пользователей.

6.2 Определение прав доступа. Определение прав (полномочий, ролей) для каждого пользователя и его объектов (таблиц, запросов, представлений, колонок и строк и др.).

7. Загрузка информации в базу данных.

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

7.2. Загрузка реальной информации в базу данных.

7.3. Сдача системы в эксплуатацию.

8. Настройка функционирования системы и ее модификация.

8.1. Настройка функционирования системы. Сбор и обработка статистической информации об эффективности функционирования системы и ее настройка с целью повышения производительности работы системы.

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