Методические материалы

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

        Двухуровневый «клиент-сервер»

        Архитектура Клиент-сервер (англ. Client-server) — вычислительная или сетевая архитектура, в которой задания или сетевая нагрузка распределены между поставщиками услуг (сервисов), называемыми серверами, и заказчиками услуг, называемыми клиентами. Нередко клиенты и серверы взаимодействуют через компьютерную сеть и могут быть как различными физическими устройствами, так и программным обеспечением. Существует два вида представление данной архитектуры двухуровневая и трёхуровневая.

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

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

        Распределенная обработка данных типа «двухуровневый клиент-сервер» (рис. 1) предполагает, что на сервере находится БД под управлением СУБД в архитектуре «клиент-сервер». Все рабочие станции (клиенты) посылают запросы на данные к серверу, который осуществляет извлечение и предварительную обработку данных. Единицей обмена по сети является запрос и релевантная запросу выборка данных из БД. Существенно уменьшается трафик сети, снимаются ограничения на доступность данных БД различным приложениям. «Клиентская» часть приложений становится несколько облегченной, но в больших ИС со сложной логикой обработки данных возникает проблема «толстого» клиента. Рабочая станция должна иметь достаточно высокие технические параметры для выполнения сложных приложений. Недостатком архитектуры является наличие очень высоких требований к техническому комплексу сервера БД, который становится центральным звеном всей ИС и определяет ее надежность.

Рис. 1. ИС с архитектурой «двухуровневый клиент-сервер»

Базовые архитектуры распределенной обработки

        Расположение компонентов на стороне клиента или сервера определяет следующие основные модели их взаимодействия в рамках двухуровневой архитектуры:

- сервер терминалов ― распределенное представление данных;

- файл-сервер ― доступ к удаленной базе данных и файловым ресурсам;

- сервер БД ― удаленное представление данных;

- сервер приложений ― удаленное приложение.

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

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

Рис. 2. ИС с архитектурой «Файловый сервер»

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

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

        Преимущества такого подхода очевидны:

- возможно централизованное администрирование прикладных функций;

- снижение стоимости владения системой (TOC, total cost of ownership) за счет аренды сервера, а не его покупки;

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

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

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

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

Многоуровневый «клиент-сервер»

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

        В отличие от двухуровневой архитектуры, данная архитектура  (рис. 3.) обеспечивает эффективное использование приложений общего пользования многими клиентами. Клиенты преобразуются в «тонких» клиентов, при этом снижаются требования к оборудованию рабочих станций. Если серверов приложений и БД в сети несколько, архитектура ИС становится многоуровневой клиент-серверной архитектурой. Наличие самостоятельных уровней в информационно-технологической архитектуре ИС дает возможность варьировать аппаратными и программными средствами: выбирать операционные системы, СУБД, интерфейсы конечных пользователей, типы серверов и рабочих станций.

Рис. 3. ИС с архитектурой «трехуровневый клиент-сервер»

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

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

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

Контрольные вопросы:

1. Дайте определение понятию архитектура клиент-сервер.
2. Дайте подробную классификацию клиент-серверных архитектур в виде схемы.
3. Чем двухуровневая архитектура отличается от трехуровневой (по своему строению)?
4. Какие преимущества и недостатки имеет двухуровневая архитектура?
5. Какие преимущества и недостатки имеет трехуровневая архитектура?
6. Что представляют собой сервер терминалов, файл-сервер, сервер БД, сервер приложений?
7. Опишите модель активного сервера.
8. Как Вы думаете, почему в настоящее время наблюдается возврат к модели сервер терминалов?
9. Когда целесообразно использование многоуровневого клиент-сервера?
10. Дайте определения понятиям толстый клиент, тонкий клиент, для каких архитектур используются эти понятия?
11. Составьте сравнительную таблицу «Архитектуры распределенной обработки».

Архитектура сервера баз данных

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

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

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

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

Рис. 1. Взаимодействие пользовательских и клиентских процессов в модели

"один-к-одному"

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

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

        Проблемы, возникающие в модели "один-к-одному", решаются в архитектуре "систем с выделенным сервером", который способен обрабатывать запросы от многих клиентов. Сервер единственный обладает монополией на управление данными и взаимодействует одновременно со многими клиентами (рис. 2). Логически каждый клиент связан с сервером отдельной нитью ("thread"), или потоком, по которому пересылаются запросы. Такая архитектура получила название многопотоковой односерверной ("multi-threaded"). Она позволяет значительно уменьшить нагрузку на операционную систему, возникающую при работе большого числа пользователей ("trashing").

Рис. 2. Многопотоковая односерверная архитектура

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

        Однако такое решение имеет свои недостатки. Так как сервер может выполняться только на одном процессоре, возникает естественное ограничение на применение СУБД для мультипроцессорных платформ. Если компьютер имеет, например, четыре процессора, то СУБД с одним сервером используют только один из них, не загружая оставшиеся три. В некоторых системах эта проблема решается вводом промежуточного диспетчера. Подобная архитектура называется архитектурой виртуального сервера ("virtual server") (рис. 3).

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

        Однако и эта архитектура не лишена недостатков, потому что здесь в систему добавляется новый слой, который размещается между клиентом и сервером, что увеличивает трату ресурсов на поддержку баланса загрузки актуальных серверов ("load balancing") и ограничивает возможности управления взаимодействием "клиент—сервер". Во-первых, становится невозможным направить запрос от конкретного клиента конкретному серверу, во-вторых, серверы становятся равноправными — нет возможности устанавливать приоритеты для обслуживания запросов.

Рис. 3. Архитектура с виртуальным сервером

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

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

Рис. 4. Многопотоковая мультисерверная архитектура

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

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

Рис. 5. Многонитевая мультисерверная архитектура

Типы параллелизма

        Рассматривают несколько путей распараллеливания запросов.

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

Рис. 6. Выполнение запроса при горизонтальном параллелизме

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

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

        Действительно, если мы рассмотрим, например, последовательность операций реляционной алгебры:

R5=R1 [ A,C]

R6=R2 [A,B,D]

R7 = R5[A > 128]

R8 = R5[A]R6,

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

И третий вид параллелизма является гибридом двух ранее рассмотренных (см. рис. 7).

Рис. 7. Выполнение запроса при гибридном параллелизме

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

Контрольные вопросы:

1. Перечислите и зарисуйте архитектуры сервера БД.
2. В чем заключаются преимущества и недостатки каждой архитектуры?
3. В чем заключается распараллеливание запроса?
4. Опишите типы параллелизма.
5. В каком из перечисленных типов скорость выполнения запроса выше?
6. Дополните определения:

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

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

Трехзвенная архитектура модели «клиент-сервер»

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

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

Компьютер в сети, предназначенный для работы отдельного пользователя

Компьютер или программа, предназначенные для обработки запросов от программ-клиентов

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

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

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

•наличие полной спецификации всех требований;

•наличие приемлемой методологии (системы методов) разработки;

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

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

база данных;

программное обеспечение базы данных;

прикладное программное обеспечение;

аппаратное обеспечение (в том числе устройства хранения);

персонал, разрабатывающий и использующий эту систему.

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

Обзор жизненного цикла приложения баз данных.

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

Рис. 1. Этапы жизненного цикла базы данных

Планирование разработки базы данных.

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

•требуемого объема работы;

•необходимых ресурсов;

•общей стоимости проекта.

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

•определение бизнес-планов и целей организации с последующим выделением ее потребностей в информационных технологиях;

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

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

Определение требований к системе

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

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

Сбор и анализ требований пользователей

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

- посредством опроса и анкетирования отдельных сотрудников предприятия, особенно ведущих специалистов в наиболее важных областях ее деятельности;

- с помощью наблюдений за деятельностью предприятия;

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

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

Проектирование базы данных

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

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

• создание модели данных, способной поддерживать выполнение любых требуемых транзакций обработки данных;

• разработка предварительного варианта проекта, структура которого позволяет удовлетворить все основные требования, предъявляемые к производительности системы — например, ко времени реакции системы.

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

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

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

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

Администрирование баз данных

Выбор целевой СУБД

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

Разработка приложений

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

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

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

Создание прототипов

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

Реализация

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

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

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

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

Конвертирование и загрузка данных

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

Тестирование

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

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

нисходящее тестирование;

восходящее тестирование;

тестирование потоков;

интенсивное тестирование.

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

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

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

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

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

Эксплуатация и сопровождение 

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

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

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

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

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

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

Тема: Концептуальные модели и схемы данных

1. Классификация моделей данных

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

рис.1. Классификация моделей данных

2. ER-модель данных

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

        Модель сущность-связь (ER-модель) (англ. entity-relationship model, ERM) — модель данных, позволяющая описывать концептуальные схемы предметной области. ER-модель используется при высокоуровневом (концептуальном) проектировании баз данных. С её помощью можно выделить ключевые сущности и обозначить связи, которые могут устанавливаться между этими сущностями. Во время проектирования баз данных происходит преобразование ER-модели в конкретную схему базы данных на основе выбранной модели данных (реляционной, объектной, сетевой или др.).

        ER-модель представляет собой формальную конструкцию, которая сама по себе не предписывает никаких графических средств её визуализации. В качестве стандартной графической нотации, с помощью которой можно визуализировать ER-модель, была предложена диаграмма сущность-связь (ER-диаграмма) (англ. entity-relationship diagram, ERD). Понятия ER-модель и ER-диаграмма часто ошибочно не различают, хотя для визуализации ER-моделей предложены и другие графические нотации (см. Ниже).

        Модель «сущность-связь» была предложена в 1976 году Питером Пин-Шен Ченом (англ. Peter Pin-Shen Chen), американским профессором компьютерных наук в университете штата Луизиана.

3. Нотации (графические диаграммы)

3.1. Нотация Питера Чена

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

рис. 2. Простая ER-модель с использованием нотации Питера Чена

3.2. Пример построения диаграммы в нотации Питера Чена

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

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

        Но как поставщик поставляет товары? Он делает поставку, которая подтверждается документом. Аналогично и покупатель делает покупку, которая также может подтверждаться документом. Таким образом, поставка и покупка могут рассматриваться, как самостоятельные объекты:

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

        Но связи "многие ко многим" недопустимы в реляционной модели, поэтому каждую такую связь надо заменить на две связи "один ко многим". Делается это добавлением промежуточного объекта:

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

        Каждый объект магазина имеет свои атрибуты:

        Вот собственно мы и создали концептуальную модель базы данных магазин, вернее ее части, ведь в магазине еще есть сотрудники, склады, доставка товаров и т. д. Если предметная область обширная, то ее полезно разбить на несколько локальных предметных областей (наша концептуальная модель отражает именно локальную предметную область). Объем локальной области выбирается таким образом, чтобы в нее входило не более 6-7 объектов. После создания моделей каждой выделенной предметной области производится объединение локальных концептуальных моделей в одну общую, как правило, довольно сложную схему. Теперь концептуальную модель можно преобразовать в реляционную модель данных, т.е. в уже известные нам таблицы, поля, ключи и т.д.

3.3. Нотация Баркера

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

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

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

рис. 3. Пример оформления диаграммы по нотации Баркера

        Читается связь отдельно для каждого конца, показывая, как сущность КЛИЕНТ связывается с сущностью КРЕДИТНАЯ КАРТА, и наоборот. При этом необходимо учитывать степень обязательности выбранного конца связи, для этой цели используются слова "должен (быть)" или "может (быть)". Так, диаграмма, приведенная на рис. 5.6, читается следующим образом: Каждый КЛИЕНТ может ВЛАДЕТЬ одной или более КРЕДИТНОЙ КАРТОЙ или Каждая КРЕДИТНАЯ КАРТА должна ПРИНАДЛЕЖАТЬ ровно одному КЛИЕНТУ.

Задание:

1. Разработать ER-диаграмму для базы данных «Библиотека», содержащую не менее пяти сущностей в нотации Питера Чена. (Для разработки диаграммы использовать MS Word).
2. Разработать ER-диаграмму для базы данных «Колледж», содержащую не менее пяти сущностей в нотации Баркера. (Для разработки диаграммы использовать MS Word).