Назад
согласованной со всеми категориями пользователей. Словарь
используется для документирования разработки СБД и справочного
обслуживания разработчиков и пользователей. Часть словаря
системный каталог, содержащий формальные описания структуры БД,
правил целостности и т.п., обеспечивает поддержку
функционирования СУБД и прикладных программ. Таким образом,
словарь является необходимым компонентом СБД, обеспечивающим
ее разработку и эксплуатацию [3].
СУБД комплекс программных и языковых средств,
предназначенный для создания баз данных и управления данными.
Штатные средства СУБД обеспечивают следующие функции:
ядро организацию ввода, обработки и хранения данных;
трансляторы/интерпретаторы компиляцию и/или
интерпретацию прикладных программ, написанных на входных языках
СУБД;
утилиты различные вспомогательные функции: настройку
системы, ее тестирование, восстановление БД в случае разрушения,
сбор статистики о функционировании СБД и т.д.
Прикладные программы П) создаются программистами,
обслуживающими конечных пользователей СБД. Они обрабатывают
запросы к БД и поддерживают интерфейс КП, обеспечивая
предоставление информации в привычной и понятной конечным
пользователям форме.
Языковые средства СУБД предназначены для обеспечения
интерфейсов всех категорий пользователей.
Языки определения данных предоставляют средства описания
элементов и структур данных, экранных форм и других параметров
приложений.
Языки манипулирования данными обеспечивают навигацию в
БД или формулирование запросов к данным.
Языки программирования предназначены для написания
прикладных программ, обрабатывающих данные в интересах конечных
пользователей.
Используя эти средства, прикладные программисты,
13
обслуживающие СБД, могут создавать специализированные языки,
ориентированные на конечных пользователей. Как правило, это
наборы экранных форм, содержащих поля ввода/вывода данных и
органы управления. Такие формы отображают данные в виде,
привычном для пользователя, и обеспечивают ему возможность
управления данными с использованием привычной терминологии.
Операционная система рассматривается как часть СБД,
поскольку, как правило, СУБД работает под управлением
универсальной ОС, используя ее штатные средства управления
файлами.
Технические средства СБД это чаще всего универсальные
ЭВМ с необходимым набором периферийных средств. Тенденция
нашего времени – реализация СБД на сетях персональных ЭВМ.
К организационно-методическим средствам относятся
различные инструкции, методические и регламентирующие
документы, предназначенные для пользователей различных категорий,
такие как проектная документация, руководство пользователя и т.п.
Администратор БД это группа специалистов,
обеспечивающих создание, функционирование и развитие системы
базы данных. Она создается на начальном этапе жизненного цикла
системы и выступает как ее идеолог и разработчик. Функционирование
системы невозможно без АБД.
1.2.3 Функции и состав АБД. В зависимости от сложности и
объема СБД, ее специфики, особенностей используемой СУБД и
некоторых других факторов, количественный состав и структура
группы АБД могут быть различными. Однако в любом случае АБД
выполняет следующие функции [3]:
анализ предметной области;
проектирование структуры БД;
обеспечение целостности данных;
первоначальная загрузка и ведение БД;
защита данных;
обеспечение восстановления БД;
анализ обращений пользователей к БД;
14
анализ эффективности функционирования СБД и развитие
системы;
работа с пользователями;
подготовка и поддержание системных программных средств;
организационно-методическая работа.
В зависимости от специфики конкретной СБД объем этих
функций может быть различным, но так или иначе все они должны
выполняться АБД.
Этот перечень функций определяет состав АБД. В группу
должны входить следующие специалисты:
системные аналитики;
проектировщики структур БД;
проектировщики технологических процессов обработки
данных;
системные программисты;
прикладные программисты;
операторы;
специалисты по техническому обслуживанию.
Количественный состав АБД определяется спецификой
организации, в которой используется система. Перечисленные
функции могут в той или иной степени выполнять один-два человека
(ситуация, характерная для СБД небольших предприятий), а иной раз
АБД это крупное структурное подразделение, в состав которого
входит несколько групп специалистов.
Функции АБД определяют его связи с внешним (по отношению
к АБД) миром. Здесь можно выделить три канала.
Связь с администрацией предприятия, использующего СБД.
Ни создание, ни эксплуатация СБД невозможны без поддержки
администрации предприятия-пользователя. Проблемы, требующие
разрешения на уровне компетенции руководителя предприятия и его
заместителей, возникают с самого начала разработки СБД и не
исчезают никогда. Поэтому в организациях, серьезно относящихся к
развитию средств автоматизации обработки данных, руководитель
АБД обычно является одним из заместителей главного руководителя и
принимает участие во всех решениях, связанных с изменениями
15
информационных потоков.
Связь с конечными пользователями также возникает на
первых этапах (выяснение потребностей, принятых правил работы с
документами, привычных форм и т.д.). Эта связь поддерживается
постоянно в соответствии с вышеперечисленными функциями АБД.
Связь с внешними специалистами родственных профилей
также имеет место всегда. Это поставщики оборудования, СУБД,
пакетов прикладных программ, администраторы других СБД и т.д.
1.3 Архитектурные концепции
1.3.1 Принцип интегрированного хранения. Деловая
информация возникает в различных подразделениях предприятия и на
различных рабочих местах. Однако для управления бизнесом она
нужна в совокупности. Информация ресурс предприятия. Она не
может быть собственностью какого-то лица или подразделения,
получившего ее. Каждому служащему предприятия должны быть
доступны все необходимые для выполнения служебных обязанностей
сведения тогда и там, когда и где они ему понадобятся. Это один из
основных принципов эффективного управления делами.
Реализация этого принципа «бумажными» средствами приводит
к избыточности хранимых данных вследствие многократного
дублирования данных в архивах подразделений. Избыточность
открывает возможность появления противоречивой информации.
«Копии» одних и тех же сведений могут оказаться различными, так
как человеку свойственно ошибаться.
Для того чтобы устранить избыточность, связанную с ней
возможную противоречивость информации и обеспечить управление
информацией как общим (корпоративным) ресурсом предприятия,
нужно фиксировать каждый факт однократно. Эта мысль приводит к
принципу интегрированного хранения информации.
На предприятии должен поддерживаться только
общий архив, в который поступают все сведения по мере их
появления. Любой сотрудник получает нужную ему информацию
только из этого архива.
16
Реализовать эту идею средствами «бумажного» архива
невозможно. Решившееся на это предприятие немедленно погибнет,
т.к. нужные сведения нельзя будет получить в нужное время.
Главная задача систем баз данных поддержание
интегрированных хранилищ информации. Избыточность в них есть, но
ее ровно столько, сколько нужно, и, самое главное, она
контролируема, т.е. обеспечена идентичность всех копий данных.
1.3.2 Независимость прикладных программ и данных
1
.
Конечные пользователи СБД получают доступ к хранимым данным
через посредство прикладных программ (ПП), работающих с общим
полем данных во внешней памяти (см. рис. 1.3). Этого требует
принцип интег-
Ï Ï 1
Ï Ï 3
Ï Ï 2
Î áù èå
äàí í û å
Ï Ï n
Рис. 1.3 ПП вокруг данных
рированного хранения. При этом ПП могут использовать только общие
для всех форматы хранимых файлов, определенные проектировщиком
БД. Игнорирование этого требования недопустимо.
В самом деле, предположим, что прикладные программы
создают файлы собственных форматов. Тогда возможны показанные
на рис. 1.4 варианты соответствия ПП и данных.
Вариант 1 Вариант 2
1
Далее в настоящей главе термин ‘данные’ используется в смысле второго
определения. Имеются в виду символы, а не их значения.
17
Ï Ï 1
Ï Ï 2
Ï Ï 3
Ä1
Ä2
Ä3
Ï Ï 1
Ï Ï 3
Ï Ï 2
Ä1
Ä2
Ä3
Каждая ПП использует только
собственные файлы со всеми
нужными данными.
ПП создает собственные файлы,
если нет подходящих файлов
других ПП.
Рис. 1.4 Данные вокруг ПП
В первом варианте неизбежна неконтролируемая избыточность.
Данным нельзя доверять и ими невозможно управлять как общим
ресурсом предприятия.
Во втором варианте избыточности нет, но возникает ряд
проблем проектирования и развития системы. Главная из них состоит в
том, что если прикладной программист изменит структуры файлов
своей ПП, скажем, с целью повышения эффективности программы, то
придется переписать все ПП, использующие эти файлы. Прикладные
программы оказываются взаимно зависимыми в этом смысле.
Вариант «ПП вокруг данных» (рис. 1.3) лишен этих
недостатков. Здесь нет ни неконтролируемой избыточности, ни
взаимной зависимости ПП. Однако, если ПП получают доступ к
данным непосредственно от ОС, то возникает проблема зависимости
ПП от данных. Подробное обсуждение этой проблемы можно найти в
[1]. Здесь излагается только ее суть. Начнем с определения терминов.
Данные, хранящиеся во внешней памяти, будем называть
хранимыми. Наименьшая (логическая) единица хранимых данных
называется хранимым полем. Обычно во внешней памяти размещается
много экземпляров хранимых полей, т.е. значений поля. Поле имеет
имя и тип. Хранимые поля объединяются в хранимые записи.
Хранимая записьэто набор связанных хранимых полей. Например
номер детали наименование вес – тип хранимой записи
18
‘P12’ ‘шайба’ 0,1 – экземпляр записи
Хранимую запись следует понимать как тип, представленный
во внешней памяти многими экземплярами. Набор всех экземпляров
хранимых записей одного типа называется хранимым файлом.
Вариант «ПП вокруг данных» предполагает, что все нужные
типы хранимых записей и все их связи определены проектировщиком
БД в виде схемы хранения данных. Прикладной программе известна
часть схемы, содержащая необходимые ее пользователю данные. Тело
программы содержит ссылки на доступные ей хранимые записи и
поля. Если схема хранения изменится, то придется переписать все ПП,
ориентированные на измененную часть схемы.
Необходимость внесения изменений в схему хранения
возникает отнюдь не в исключительных случаях.
В связи с изменениями требований пользователей могут быть
добавлены/удалены хранимые поля или типы записей.
В связи с изменением программноехнической платформы
системы может измениться, например, способ упорядочения записей
или способ доступа к записям и т.п.
Для повышения эффективности обработки запросов к данным
может потребоваться изменение структуры хранимых записей.
Например, два существующих типа хранимых записей используются в
запросах, как правило, вместе. Разумно объединить их в один. Это
приведет к уменьшению числа обращений к внешней памяти. Или
наоборот, часть длинной записи редко используется и может быть
размещена на более медленном устройстве. Разумно расщепить запись
на две.
Для удовлетворения новым стандартам или требованиям
защиты, или с целью экономии внешней памяти и т.д. может
понадобиться: изменить представление числовых данных форму,
основание системы счисления, масштаб, тип, точность и т.д.; изменить
кодировку символов (ASCIIEBCDIC); ввести кодирование данных.
Требование независимости ПП и данных состоит в
том, что все эти изменения не должны быть видны прикладным
программам.
19
1.3.3 Трехуровневая архитектура СБД. Решение проблемы
независимости ПП и данных обеспечивается использованием
трехуровневой архитектуры системы (рис. 1.5).
Эта архитектурная концепция предлагает использовать три
уровня представления данных:
внешний уровень представления данных для различных
конечных пользователей.
внутренний уровень представление данных в памяти ЭВМ,
но без конкретных технических деталей (схема хранения).
концептуальный уровень обобщенное логическое
представление данных, не содержащее никаких ссылок на реализацию.
Êî í öåï òóàëüí û é óðî âåí ü
Ì Ä)
Î áî áù åí í î å
ï ðåäñòàâëåí èå
ï î ëüçî âàòåëåé
ÓÐÎ ÂÍ È ÑÓÁÄ
Ï Ï 1 Ï Ï 2 Ï Ï n
Ï ðèêëàäí û å ï ðî ãðàì ì û
ÂÌ Ä1 ÂÌ Ä2 ÂÌ Än
Âí åø í èé óðî âåí ü
(èí äèâèäóàëüí û å
ï ðåäñòàâëåí èÿ
ï î ëüçî âàòåëåé)
Âí óòðåí í èé óðî âåí ü
(Âí Ì Ä)
Ï ðåäñòàâëåí èå
â ï àì ÿòè
ÓÐÎ ÂÅÍ Ü Î Ñ
Ôèçè÷åñêèé
óðî âåí ü
(ÔÁÄ)
20
Рис. 1.5 Трехуровневая архитектура БД (общий вид)
Пример. Пусть в нашей ПО имеется объект СЛУЖАЩИЙ,
характеризующийся свойствами
табельный номер номер отдела зарплата
. . . ,
и есть два конечных пользователя БД КП1 и КП2. Для КП1
представляют интерес только табельный номер и номер отдела, для
КП2 – табельный номер и зарплата. Объект имеет три уровня
представления или описания.
На внешнем уровне показаны два представления объекта
СЛУЖАЩИЙ для различных конечных пользователей. Каждому из
них обслуживающая его ПП предоставляет ту информацию о
СЛУЖАЩем, в которой он заинтересован, скрывая другие
характеристики.
Внешний уровень 1 (COBOL) Внешний уровень 2 (PL/1)
01 EMP# DCL 1 EMP
02 ЕМPNO PIC X (6) 2 EMP CHAR (6)
02 DEPNO PIC X (4) 3 SAL FIXED BIN (31);
Первые строчки этих текстов объявляют имена объекта. Вторые
и третьи строчки указывают имена и типы характеристик объекта. Для
КП1 это табельный номер и номер отдела, а для КП2
табельный номер и зарплата. Отметим, что в разных
представлениях имена объекта и его характеристик могут быть
различными.
С точки зрения обобщенного пользователя БД содержит
следующую информацию о служащих.
Концептуальный уровень
СЛУЖАЩИЙ
Номер служащего CHAR (6)
Номер отдела CHAR (4)
Зарплата NUMERIC (5)
Из приведенного описания совершенно не видно, как эта
информация организована в памяти ЭВМ. Пользователю не нужно это
знать. На внутреннем уровне объект СЛУЖАЩИЙ представлен типом
внутренней записи STORED_EMP.
Внутренний уровень
21
STORED_EMP LENGTH= 20
PREFIX TYPE = BYTE (6), OFFSET= 0
EMP# TYPE = BYTE (6), OFFSET= 6, INDEX = EmPX
DEPT# TYPE = BYTE (4), OFFSET=12,
PAY TYPE =FULLWORD, OFFSET=16
Указана длина записи 20 байт. Запись состоит из четырех
хранимых полей PREFIX, EMP#, DEPT# и PAY. Поле PREFIX
содержит необходимую служебную информацию. Три поля данных
соответствуют свойствам СЛУЖАЩего. Поле EMP# связано с
индексом ЕМРХ, обеспечивающим быстрый поиск по значениям
ЕМР#. Этот индекс определен на внутреннем уровне, но не виден уже
на концептуальном.
Рассмотрим детали трехуровневой архитектуры,
представленные на рис. 1.6.
22