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




 

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

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

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

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

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

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

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

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

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

1) произвести выборку из базы конкретного данного по его наименованию;

2) произвести выборку из базы всех данных определенного типа, значения которых удовлетворяют определенным признакам;

3) найти в базе позицию данного и поместить туда его новое значение и т.д.

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

По способу реализации языков СУБД принято подразделять на две группы: 1) с включающим языком и 2) с базовым языком. В системах управления базами данных с включающим языком в качестве последнего выбирают один из общепринятых алгоритмических языков (например, Ассемблер, ПЛ/1, КОБОЛ), на котором пишут прикладную программу. Прикладная программа, написанная на включающем языке, может инициировать команды ЯМД одним из следующих способов:

1) путем вызова специальных соответствующих подпрограмм СУБД;

2) путем использования специальных операторов (команд ЯМД), включенных в состав операторов используемого алгоритмического языка. В этом случае последний называется расширенным включающим языком.

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

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

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

Таким образом, в каждой СУБД прежде всего реализуются (т.е. имеются соответствующие трансляторы либо интерпретаторы) ЯОД и ЯМД, единые для всей БД, которая будет поддерживаться с помощью этой СУБД.

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

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

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

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

Следующим важным средством централизации управления данными является словарь данных (СД).

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

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

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

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

В системах с интегрированным словарем описания данных хранятся в единственном экземпляре в словаре и используются при работе системы. При этом СД может служить также средством контроля при работе системы.

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

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

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

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

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

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

2) координировать все действия по проектированию, реализации и ведению БД; учитывать как перспективные, так и текущие требования пользователей; следить, чтобы БД удовлетворяла актуальным информационным потребностям;

3) решать вопросы, связанные с расширением БД в связи с изменением границ ПО;

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

5) выполнять работу по ведению словаря данных, контролировать избыточность и противоречивость данных, их достоверность;

6) следить за тем, чтобы БнД отвечал заданным требованиям по производительности, т.е. чтобы обработка запросов выполнялась за приемлемое время;

7) при необходимости изменять методы хранения данных, пути доступа к ним и связи между ними, форматы данных; определять степень влияния изменений в данных на всю БД;

8) координировать вопросы технического обеспечения системы аппаратными средствами исходя из требований, предъявляемых БД к оборудованию;

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

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

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

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

 



Поделиться:




Поиск по сайту

©2015-2024 poisk-ru.ru
Все права принадлежать их авторам. Данный сайт не претендует на авторства, а предоставляет бесплатное использование.
Дата создания страницы: 2016-02-16 Нарушение авторских прав и Нарушение персональных данных


Поиск по сайту: