Цель раздела - определение роли СУБД в информационной системе организации как ее неотъемлемого компонента, краткое рассмотрение различных технологий построения СУБД, сравнение их архитектур и ознакомление с жизненным циклом баз данных.
База данных (БД) – это совместно используемый набор логически связанных данных и их описаний, предназначенный для удовлетворения информационных потребностей организации [4].
Система управления базами данных (СУБД) – это совокупность языковых и программных средств, предназначенных для создания, ведения и совместного использования БД многими пользователями.
СУБД является неотъемлемой частью информационной системы организации [1-3].
Информационная система – ресурсы, которые позволяют выполнять сбор, корректировку и распространение информации внутри организации [4].
В состав типичной компьютеризированой информационной системы входят:
Дадим характеристику методам хранения и управления данными, которые используются информационными системами организаций [4].
Ручные картотеки позволяют успешно справляться с поставленными задачами обработки информации, если количество хранимых объектов невелико. Они вполне годятся для хранения и извлечения большого количества данных, но совершенно не подходят для тех случаев, когда необходимо установить перекрестные связи или выполнить обработку сведений. Если нам понадобится какая-то информация, то потребуется просмотреть картотеку от начала и до конца, чтобы найти искомые сведения. Для обеспечения нахождения нужной информации предусматривается использование в такой системе некоторого алгоритма индексирования, позволяющего ускорить поиск нужных сведений. Например, можно использовать специальные разделители или отдельные папки для различных логически связанных типов объектов.
Файловые системы – это набор программ, с помощью которых пользователь выполняет некоторые операции, например, создает отчеты. Каждая программа определяет свои собственные данные и управляет ими [2, 4, 5].
Файловые системы были первой попыткой компьютеризировать известные всем ручные картотеки. Они были разработаны в ответ на потребность в получении более эффективных способов доступа к данным. Однако, вместо создания централизованного хранилища всех данных организации, был использован децентрализованный подход, когда сотрудники каждого отдела при помощи специалистов по обработке данных работали со своими собственными данными и хранили их в своем отделе.
Этого вполне достаточно для того, чтобы понять имеющиеся недостатки.
Разделение и изоляция данных приводит к существенным затруднениям, когда необходимо организовать обработку информации, котрая находится в двух и более файлах.
Дублирование данных приводит к неэкономному расходованию ресурсов, поскольку на ввод избыточных данных требуется затрачивать дополнительное время и деньги. Оно может привести к нарушению их целостности. Например, в двух разных отделах организации можно получить на один и тот же вопрос противоречивые ответы. Во многих случаях дублирование данных можно избежать совместным использованием файлов.
Зависимость от данных становится причиной больших затрат при изменении физической структуры файлов, которая отражена в программном обеспечении, работающем с ними. Например, после некоторого времени промышленной эксплуатации прикладной программы выяснилось, что по вновь принятому законодательству номер банковского счета будет увеличен с 10 до 16 знаков. Чтобы выйти из этой ситуации, необходимо написать программу, которая отработает всего один раз. Она должна открыть исходный файл, создать временный файл с новой структурой, считать информацию из исходного файла, преобразовать данные в новый формат и записать их во временный файл, удалить исходный файл, присвоить временному файлу имя исходного.
Несовместимость форматов файлов затрудняет обработку информации еще в большем объеме, чем разделение и изоляция данных. Например, она может быть следствием необходимости совместного использования данных двумя локальными задачами. Для этого понадобиться создавать программное обеспечение, которое конвертирует данные в один общий формат. После чего возможна их совместная обработка.
Быстрое увеличение количества прикладных программ для извлечения информации, необходимой пользователям в файловых системах во многом зависит от программиста, потому что все требуемые запросы и отчеты должны быть созданы именно им. В результате события развивались по одному из двух сценариев. В организациях, где программисты отсутствуют в штатном расписании, типы создаваемых запросов и отчетов имели фиксированную форму, и не было никаких инструментов создания незапланированных или произвольных запросов. В других организациях, где программисты работали, наблюдалось быстрое увеличение количества файлов и прикладных программ. В конечном счете, наступал момент, когда они перестают удовлетворять потребности пользователей в получении необходимой им информации.
Перечисленные ограничения файловых систем являются следствием двух факторов.
Для повышения эффективности работы стали использовать новый подход: БД и СУБД.
Чтобы глубже вникнуть в суть этого понятия, рассмотрим его определение более внимательно. БД – это единое, большое хранилище данных, которое однократно определяется, а затем используется одновременно многими пользователями из разных подразделений. Вместо разрозненных файлов, здесь все данные собраны вместе с минимальной долей избыточности. БД уже не принадлежит какому-то единственному отделу, а является общим корпоративным ресурсом. Причем она хранит не только рабочие данные, но и их описания. Поэтому её еще называют набором интегрированных записей с самоописанием. В совокупности описание данных называется системным каталогом (system catalog), или словарем данных (data-dictionary), а сами элементы описания принято называть метаданными (meta-data), т.е. "данными о данных". Именно наличие самоописания данных обеспечивает независимость между прикладными программами и данными (program-data independents).
На сегодня использование СУБД имеет такие преимущества:
и недостатки:
Сервер это программно-аппаратный комплекс, который обрабатывает запрос.
Он, по существу, ждет, пока клиент сделает запрос, а затем обрабатывает его. Сервер должен обладать способностью обрабатывать одновременно несколько запросов от нескольких клиентов, а также уметь распределять эти запросы по приоритетам. Чаще всего серверная программа работает постоянно, обеспечивая не прекращающийся доступ к ее услугам.
Клиенты представляют собой приложения, обеспечивающие графический или иной интерфейс с пользователем.
Прикладные программы клиентов предоставляют пользователю интерфейс для управления данными на сервере. Именно с помощью прикладной программы пользователь получает доступ к функциональным возможностям сервера. Примером запрашиваемых действий может быть получение, добавление, корректировка и удаление информации или печать отчета. В этом случае клиент просто посылает запрос и предоставляет необходимые для его выполнения данные. Сервер несет ответственность за обработку запроса. Это означает, что клиент может самостоятельно выполнять любые логических действий самостоятельно. Вполне возможно, что клиент реализует большую часть (если не все) бизнес-правила.
Бизнес-правила - это процедуры управления, которые определяют, как клиент должен получать доступ и манипулировать данными на сервере.
Эти правила реализуются программным текстом клиента, сервера или ими обоими. На стороне сервера бизнес-правила реализуются в виде хранимых процедур, триггеров и других объектов, присущих серверной БД. Важно понимать, что бизнес-правила определяют поведение всей системы. При их отсутствии у вас есть просто данные на одном компьютере и приложение с интерфейсом пользователя на другом, однако нет метода их соединения.
Если большая часть правил реализована на сервере, то его называют "толстым сервером". Если правила реализуются в основном на стороне клиента, он называется "толстым клиентом". Если правила реализованы на среднем уровне, то сервер также называют "толстым". Таким образом, объем и тип операций, котрые необходимы для управления данными, определяют место реализации бизнес-правил.
Со временем БД на персональных компьютерах совершенствовались по направлению от настольных или локальных прикладных программ, когда реально с БД могло работать одна прикладная программа, до систем коллективного доступа к данным [2 – 7].
Необходимость коллективной работы с одними и теми же данными повлекла за собой перенос БД на файловый сервер. Прикладная программа, работающая с БД, располагалось также на сервере. Способ, заключавшийся в хранении прикладной программы, которая обращается к БД, на компьютере пользователя (клиента) не получил широкого распространения. Были выпущены новые версии локальных СУБД, которые позволяли создавать прикладные программы, одновременно работающие с одной БД на файловом сервере. Основной стала проблемой, которая связана с явной или неявной обработкой транзакций, и обеспечением смысловой и ссылочной целостности БД при одновременном изменении данных несколькими клиентами, которая неизбежно возникает при коллективном доступе.
В ходе эксплуатации локальных систем были выявлены следующие недостатки файл-серверного подхода:
Приведенные недостатки решаются при переводе приложений с архитектуры "файл-сервер" [2, 4, 5] на архитектуру "клиент-сервер", которая является следующим этапом в развитии СУБД [2 - 7]. Характерная особенность архитектуры "клиент-сервер" – перенос вычислительной нагрузки на сервер БД (SQL-сервер) и максимальная разгрузка приложения клиента от вычислительной работы, а также существенное повышение безопасности данных – как от злонамеренных, так и просто ошибочных изменений. БД в этом случае помещается на сервере, как и в архитектуре "файл-сервер", однако прямого доступа к БД из приложений не происходит. Функции прямого обращения к БД осуществляет специальная управляющая программа - SQL-сервер, которая является неотъемлемой частью СУБД.
Взаимодействие сервера БД и прикладной программы-клиента происходит следующим образом: клиент формирует SQL-запрос и отсылает его серверу. Сервер, приняв запрос, выполняет его, и результат возвращает клиенту. В прикладной программе клиента в основном осуществляется интерпретация полученных от сервера данных, реализуется часть бизнес-правил и интерфейса пользователя для манипулирования данными.
Многие из уже существующих систем "клиент-сервер" создавались на базе прикладных программ, которые работали с локальными БД, используемых совместно и размещенных в сетях персональных компьютеров на файловых серверах. Перенос на SQL-серверы СУБД файл-серверной архитектуры осуществлялся с целью повышения эффективности их работы, защищенности и надежности БД.
Модель архитектуры "клиент-сервер" предполагает наличие нескольких уровней. Двухуровневая модель, возможно, наиболее общая, поскольку она следует схеме построения локальных БД (рис. 1.1). В этой модели данные постоянно находятся на сервере, а программное обеспечение доступа к данным — на компьютере пользователя. Бизнес-правила при этом могут располагаться на любом из компьютеров (или даже на обоих одновременно).
Рис. 1.1. Двухуровневая модель "клиент-сервер"
В трехуровневой модели "клиент-сервер" (рис. 1.2) в программном обеспечении клиента реализован лишь пользовательский интерфейс доступа к данным, которые находятся на сервере. Прикладная программа клиента выполняет запросы для получения доступа или изменения данных через сервер прикладных программ или сервер Remote Data Broker (Удаленный брокер-сервер данных) - RDB. Обычно бизнес-правила располагаются именно на сервере RDB. Если клиент, сервер и бизнес-правила распределены по отдельным компьютерам, разработчик может оптимизировать доступ к данным и поддерживать их целостность при обращении к ним из любых прикладных программ во всей системе.
Рис. 1.2. Трехуровневая модель "клиент-сервер"
Архитектура "клиент-сервер" имеет ряд преимуществ:
Жизненный цикл БД неразрывно связан с жизненным циклом информационной системы [1, 3, 4, 6, 8]. Он состоит из таких этапов (рис. 1.3) [4]:
Рис. 1.3. Жизненный цикл БД
Для малых БД с небольшим количеством пользователей жизненный цикл может оказаться не очень сложным. При проектировании больших приложения БД, с десятками и даже тысячами пользователей, сотнями запросов и прикладных программ, он может стать чрезвычайно сложным.
Следует признать, что приведенные этапы не являются строго последовательными, а включают некоторое количество повторов предыдущих шагов в виде циклов обратной связи. Например, при проектировании БД могут возникнуть проблемы, для разрешения которых потребуется вернуться к этапу сбора и анализа требований. Циклы обратной связи могут возникать почти между всеми этапами. Мы рассмотрели наиболее очевидные из них.
СУБД архитектуры " клиент-сервер" - неотъемлемый компонент современной информационной системы организации. Жизненный цикл БД неотделим от жизненного цикла информационной системы. Его этапы и сложность обратных связей зависит от направленности и масштаба деятельности организации.
© Куваев Я.Г., 2005—2023.
Все права защищены.
Вся информация, размещенная на данном веб-сайте, предназначена только для персонального использования и не подлежит дальнейшему воспроизведению и/или распространению в какой-либо форме, иначе как с письменного разрешения Автора.