Ю. А. Григорьев, Г. И. Ревунков - Банки данных

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

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

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

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

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

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

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

20

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

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

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

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

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

21

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

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

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

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

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

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

22

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

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

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

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

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

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

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

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

ит.д.

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

23

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

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

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

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

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

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

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

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

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

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

24

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

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

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

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

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

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

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

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

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

25

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

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

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

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

ипротиворечивости данных, хранимых как в библиотеках СУБД, так и в словаре.

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

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

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

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

26

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

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

Функции АБД следующие:

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

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

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

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

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

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

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

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

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

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

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

27

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

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

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

1.4.Архитектура банка данных

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

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

Модель <г^ Хранимая БД.

В описании отображения кроме указания соответствий между полями записей модели и полями хранимых записей указываются все необходимые сведения о хранимых данных: в каком коде они представлены, как упорядо-

28

1.4. Архитектура байка данных

Прикладная

программа,,

Рис. 1.2. Двухуровневая архитектура БнД

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

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

Модель <-> ВнМД <-> ФБД.

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

Пользователи составляют свои прикладные программы, используя только термины МД. СУБД, получив запрос из ПП (например, на чтение

29