Гайдамакин Н. А. 11 страница

4.3.4. Особенности обработки данных в СУБД с сетевой моделью организации данных

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

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

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

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

Рис. 4.27. Навигация по связанным записям в сетевых СУБД

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

SELECT Лицо.*, Организация.*, Адрес.*

FROM (Лицо INNERJOIN (Адрес INNERJOIN Организация ON Адрес.№№=Организация.Адрес)

ON (((Лицо.Работает = Организация.Наименование)

WHERE (((Лицo.Фaмилия)=»Ивaнoв»));

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

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

Навигационный подход к анализу и просмотру данных, ес­тественный уже для ранних сетевых СУБД, впоследствии (в конце 80-х годов) был реализован в технике гипертекста, и в созданной на его основе новой разновидности документальных информа­ционных систем — гипертекстовых информационно-поисковых систем.

Вместе с тем навигация по связанным данным порождает и ряд своих специфических проблем, таких как «потеря ориента­ции» и трудности с визуализацией цепочек «пройденных» ин­формационных объектов (записей). Схемы баз данных, отра­жающих сложные предметные области, могут насчитывать де­сятки различных информационных объектов и еще большее количество связей между ними. В результате такие базы данных представляют сложное многомерное информационное простран­ство из множества разнотипных наборов записей, пронизанных и опутанных порой несметным количеством связей. «Путеше­ствуя» в таком клубке, легко «сбиться с пути», потерять общую картину состояния данных.* При этом следует иметь в виду, что особенности человеческого мышления таковы, что человек спо­собен удержать в представлении с полным отслеживанием всех связей и нюансов не более 3-4 сложных объектов.**

* То есть оказаться в ситуации, которая образно выражается известной поговор­кой «За деревьями леса не видно».

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

 

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

На рис. 4.28 для примера приведен вариант изображения це­почки связанных записей с корневой записью «Иванов» объекта «Лицо». Такая визуализация позволяет быстро составить общее представление о полученном образовании, трудовой деятельно­сти и проживании данного лица. При этом длина цепочки огра­ничена тремя последовательно связанными записями, но, как вид­но из рисунка, и в этом, в общем-то простом для многих жизненных ситуаций случае, достаточно сложно отобразить общую схе­му связей, не «запутывая» ее восприятие.

 

Рис. 4.28. Пример визуализации цепочки связанных записей

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

Одним из направлений развития современной теории и тех­ники СУБД является линия объектно-ориентированных СУБД, которые на витке наработанных в конце 70-х и в 80-х годах ре­шений по реляционным СУБД, обеспечивают новые возмож­ности по обработке данных на основе методов навигации и ви­зуализации, впервые представленных в сетевых СУБД.

4.4. Вывод данных

Результаты обработки данных должны использоваться в том порядке и в тех формах, которые приняты в предметной области АИС. Решение этой задачи обеспечивается комплексом функций СУБД, определяемым термином «вывод данных».

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

Вывод данных осуществляется:

• через выходные (выводные) формы;

• через «отчеты»;

• через экспорт данных.

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

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

Рис. 4.29. Пример формы для реализации и отображения резуль­татов запроса с параметрами

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

Так же как и в формы, в отчеты могут помещаться элементы управления, среди которых особое значение имеют вычис­ляемые поля, т. е. поля, содержимое которых формируется на основе вычисления определенных статистических функций по помещаемым в отчет данным. Для примера на рис. 4.30 приве­ден отчет для вывода данных по командировкам сотрудников. Поля с надписями «ИТОГО» являются как раз вычисляемыми элементами через функцию «Сумма» поданным в поле «Аванс».

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

Рис. 4.30. Пример отчета

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

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

* Слэш налево.

 

Вопросы и упражнения

1. Кем и в каких целях применяется язык SQL в реляционных СУБД?

2. Какова структура и каковы функции структурных элементов SQL-ииструкций?

3. Что включают и в каких целях используются «включающие» языки?

4. Поясните процесс «открытия» таблиц и форм. Что происходит при этом с данными?

5. В чем преимущества и недостатки представления и отображения данных в табличном виде и в виде экранных форм?

6. В текстовых и табличных редакторах изменения данных (корректировка, добавление, удаление) фиксируются во внешней памяти в момент закрытия файлов (если не было явной предварительной команды «Сохранить»). Каков порядок фиксации изменений данных в таблицах СУБД?

7. В чем сходства и различия фильтрации данных и запросов на вы­борку данных?

8. Постройте запрос по формированию списка студентов 1980 года рождения с реквизитами — ФИО, Уч. Группа, Дата рождения, из таблицы «Студенты» (№№, ФИО, Уч. Группа, Дата рождения, Год поступления). К какому типу относится данный запрос?

9. Постройте запрос по формированию списка сотрудников руково­дящего звена не старше 35 лет, с окладом свыше 1000 р. и с пол­ным набором реквизитов из таблицы «Сотрудники» (Таб.№, ФИО, Должность — Начальник отдела, Зам. начальника отдела, На­чальник сектора, Ведущий инженер. Старший инженер, Инже­нер, Техник, Оклад, Дата Рождения). К какому типу относится данный запрос?

10. Интерпретируйте на естественном языке следующую SQL-инструкцию:

SELEСТСотрудники.Таб. —№,Сотрудиики.Фамилия,Сотруд­ники.Имя

FRОМ Сотрудники

WHERE ((Сотрудники.Должность=«Инженep» Or Сотрудни­ки.—Должность=«Методист») AND (Сотрудники.Оклад> 100р.));

11. Постройте запросы по формированию списка организационных форм, списка профилей деятельности и списка сочетаний орга­низационной формы с профилем деятельности организаций из таб­лицы «Организации»—Код, Код ОКПО, Наименование, Услов­ное наименование, Профиль деятельности (Производственный, Коммерческий, Посреднический, Научно-производственный), Организационная форма (ЗАО, ОАО, и т. д.).

12. Интерпретируйте на естественном языке следующие SQL-инструкции:

SELECT Квартиры.№, Здания.№_Дома, Здания. Улица

FROM Квартиры INNER JOIN Здания ON Квартиры.№№_Здания = Здания. №№

WHERE (((Квартиры.Кол Комнат=1) Or (Квартиры. КолКомнат=4)) AND ((Квартиры.Этаж >=4)

AND (Квартиры-.Этаж<=6)));

SELECT Сотрудники.Таб_№. Сотрудники. ФИО, Подразде­ления. Наименование,

Sum(Нетрудоспособность. ДатаОкончания Нетрудоспособность.Дата Начала) AS ОбщКолНетр

FROM (Сотрудники INNER JOIN Подразделения ON Сотруд­ники.№_Подразделения =

Подразделения.№№)INNERJOIN Нетрудоспособность ON Нетрудоспособность.

№_Сотрудника = Сотрудники. Ta6_№)

WHERE (Нетрудоспособность.ДатаНачала>=#01.01.1999#)

AND(Нетрудоспособность.ДатаНача.1а<=#31.12.1999#)

AND способность.ДатаОкончания<=#31.12.1999#)

GROUP BY Нетрудоспособность. №_Сотрудника;

13. Постройте запрос по формированию списка категорий фильмов видеотеки с группировкой по кинокомпаниям, и вышедших в 90-х годах из таблицы «Фильмы»—№№, Название, Режиссер, Год выхода, Кинокомпания, Категория (Комедия, Психологическая драма. Боевик, Триллер, Детектив, Мистика), Инв.№№ видеокас­сеты.

14. В базе данных с таблицами «Подразделения»—№№, Наимено­вание, Руководитель; «Сотрудники»— Таб№, ФИО, №№ под­разделения, Должность, «Материальные средства» — Инв.№, Наименование, Тип, №№ Подразделения, Таб № мат. ответ­ственного сотрудника. Начальная стоимость, % амортизации, Построите запрос по формированию списка материально ответ­ственных сотрудников со следующим набором реквизитов — Таб. №, ФИО, Наименование подразделения. Должность.

15. В базе данных с таблицами из предыдущего примера построите запрос по формированию перечня всех подразделений с данными по их средствам вычислительной техники при следующем на­боре реквизитов—№№ подразделения. Наименование, Руково­дитель, Инв.№ мат. средства. Наименование мат. средства, Тип мат. средства, ФИОмат. ответственного сотрудника.

16. В базе данных с таблицами «Лицо» —№№. ФИО, Дата рожде­ния, Месторождения, Паспортные данные; «Владение» — Код владения, №№ Лица. №№ имущества. Вид (Единоличное, Совме­стное), Доля, Дата приобретения. Данные документа. Дата окон­чания владения; «Имущество» — №№ имущества, Категория (Недвижимость, Автотранспорт, Акции, Ювелирные изделия. Ху­дожественные произведения. Бытовая техника. Земельный надел), Описание. Стоимость, постройте запрос по формированию спис­ка лиц (ФИО, Дата рождения. Месторождения, Паспортные данные), имеющих в единоличном владении недвижимость на сум­му свыше 10 000 минимальных размеров оплаты труда.

17. В базе данных с таблицами из предыдущего примера постройте запросы по формированию списка лиц (№№, ФИО, Дата рожде­ния, Месторождения, Паспортные данные), имеющих в совме­стном владении земельные наделы, и дополнительными реквизи­тами —Доля и Стоимость доли, а также запрос по формированию сведений о самой высокой стоимости имущества по всем возмож­ным категориям.

18. Постройте запрос по формированию списка всех запасных час­тей, относящихся к ходовой части со всеми реквизитами из таб­лицы «Запчасти» — Код, Код автомобиля. Наименование, Тип (Двигатель, Кузов, Ходовая часть. Электрооборудование, Аксес­суары), Марка, Количество на складе. Цена единицы, Поставки прекращены, с дополнительным реквизитом Общая стоимость.

19. Постройте запрос по формированию набора записей со всеми рек­визитами из таблицы «Преподаватели»—№№, ФИО, Уч. сте­пень, Уч. звание. Пед. стаж. Специализация, для которых име­ются вакансии по прикладной математике в таблице «Вакансии» со следующим набором реквизитов—№№, Вуз, Должность, Треб. пед. стаж. Специализация. К какому типу относится данный зап­рос?

20. Постройте запрос для формирования набора записей со всеми рек­визитами по оборудованию из таблицы «Оборудование»—Зав.№, Производитель, Марка, Сырье, Производительность, которое может применяться на всех предприятиях, использующих в каче­стве сырья очищенное зерно, данные по которым приведены в таблице «Предприятие» — Наименование. Треб. производительность и,. Используемое сырье. К какому типу относится данный зап­рос?

21. Постройте запрос по формированию списка сотрудников с пол­ным набором реквизитов из таблицы «Сотрудники» — Таб_№, ФИО, Должность, Подразделение, Телефон, которые входят по таблице «Штатное расписание» — Наименование должности. Ка­тегория, Оклад, в пятерку наиболее оплачиваемых должностей. К какому типу относится данный запрос?

22. Интерпретируйте на естественном языке следующие SQL-инструкции:

SELECT Автомобили. *

FROM Автомобили

WHERE ((Автомобили.Код)

= Any (SELECT Запчасти.Код_автомобиля

FROM ((Запчасти INNER JOIN Поставки ON Запчасти.

Код = Поставки.Код­_запчасти) INNER JOIN Поставщики ON

Поставки. Код_поставщика = Поставщики.Код)

WHERE (Поставщики.Город=«Саратов») AND (Зап-

части.Тип=«Стеклооборудование»););

SELECT Клиенты. *

FROM Клиенты INNER JOIN Счета ON Клиенты.Код = Счета.КодКлиента

WHERE (Счета.Остаток>= All (SELECT Товары.Стоимость

FROM Товары

WHERE Тoвapы.Kaтeгopия= «Бытовая техника»););

23. Постройте запрос по переименованию производителя автомоби­лей завода «ИжМаш» в «ИжVWMaш» в таблице «Автомобили»

(Код, Производитель, Модель, ГодНачалаПроизводства, ГодПрекр Производства, Фото.

24. Оптимизируйте следующие условия отбора записей по таблицам «Имущество» и «Сотрудники»: когда налог превышает тысячу единиц минимального размера оплаты труда (МРОТ) —

Имущество. Стоимость * СтавкаНалога — 1000*МРОТ > 0 когда десятикратная стоимость с учетом амортизации больше ок­лада сотрудников —

10*(Имущество. Стоимость — Имущество. Стоимость* Имущество. %Износа) — Сотрудники. Оклад > 0

25. Оптимизируйте следующее условие по отбору записей по табли­цам «Сотрудники» и «Премирование»:

сотрудники, премированные на величину более должностного оклада, равного 1000 р. —

(Премирование.Сумма > Сотрудники. Оклад) AND (Со­трудники. Оклад = 1000р.)

26. Согласно одному из проектов закона о декларировании расходов все операции по оплате приобретении или услуг гражданами, сто­имостью свыше 1000 МРОТ, должны осуществляться только без­наличным расчетом через банки, а данные по таким операциям автоматически сообщаться в налоговые органы. В базе данных АИС финансово-кредитной организации имеется и ведется таб­лица «Проводки» (№№, Дата/Время, Сумма, №Счета, Приход/ расход). Предложите на основе технологии «События-Правила-Процедуры» вариант построения схемы обработки данных при принятии и вступлении в силу подобного закона.

5. Распределенные информационные системы

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

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

* В данном контексте более понятен сам термин — «внедрение», предполагаю­щий сопротивление.

 

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

Осознание подобных проблем постепенно стало приводить к мысли о распределенных информационных системах.

5.1. Понятие распределенных информационных систем, принципы их создания и функционирования

 

Впервые задача об исследовании основ и принципов со­здания и функционирования распределенных информационных систем была поставлена известным специалистом в области баз данных К. Дейтом в рамках уже не раз упоминавшегося проек­та System R, что в конце 70-х — начале 80-х годов вылилось в отдельный проект создания первой распределенной системы (проект System R*). Большую роль в исследовании принципов создания и функционирования распределенных баз данных вне­сли также и разработчики системы Ingres.

Собственно в основе распределенных АИС лежат две ос­новные идеи:

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

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

Крис Дейт сформулировал также основные принципы со­здания и функционирования распределенных баз данных. К их числу относятся:

• прозрачность расположения данных для пользовате­ля (иначе говоря, для пользователя распределенная база дан­ных должна представляться и выглядеть точно так же, как и нераспределенная);

• изолированность пользователей друг от друга (пользо­ватель должен «не чувствовать», «не видеть» работу других пользователей в тот момент, когда он изменяет, обновляет, уда­ляет данные);

• синхронизация и согласованность (непротиворечи­вость) состояния данных в любой момент времени.

Из основных вытекает ряд дополнительных принципов:

• локальная автономия (ни одна вычислительная установка для своего успешного функционирования не должна зависеть от любой другой установки);

• отсутствие центральной установки (следствие преды­дущего пункта);

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

• непрерывность функционирования (отсутствие плано­вых отключений системы в целом, например для подключения новой установки или обновления версии СУБД);

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

• независимость от реплицирования (дублирования) дан­ных (когда какая-либо таблица базы данных, или ее часть физически может быть представлена несколькими копиями, рас­положенными на различных установках, причем «прозрачно» для пользователя);

• распределенная обработка запросов (оптимизация зап­росов должна носить распределенный характер — сначала гло­бальная оптимизация, а далее локальная оптимизация на каж­дой из задействованных установок);

• распределенное управление транзакциями (в распреде­ленной системе отдельная транзакция может требовать выпол­нения действий на разных установках, транзакция считается завершенной, если она успешно завершена на всех вовлечен­ных установках);

• независимость от аппаратуры (желательно, чтобы сис­тема могла функционировать на установках, включающих ком­пьютеры разных типов);

• независимость от типа операционной системы (систе­ма должна функционировать вне зависимости от возможного различия ОС на различных вычислительных установках);

• независимость от коммуникационной сети (возможность функционирования в разных коммуникационных средах);

• независимость от СУБД* (на разных установках могут функционировать СУБД различного типа, на практике ограни­чиваемые кругом СУБД, поддерживающих SQL).

* Данное свойство характеризуют также термином «интероперабельность».

 

В обиходе СУБД, на основе которых создаются распреде­ленные информационные системы, также характеризуют тер­мином «Распределенные СУБД», и, соответственно, использу­ют термин «Распределенные базы данных».

Важнейшую роль в технологии создания и функциониро­вания распределенных баз данных играет техника «представ­лений» (Views).

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

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

Схематично идея техники представлений проиллюстриро­вана на рис. 5.1.

Рис. 5.1. Основная идея техники представлений

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