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-х годах решений по реляционным СУБД, обеспечивают новые возможности по обработке данных на основе методов навигации и визуализации, впервые представленных в сетевых СУБД.
IX Международная студенческая научная конференция Студенческий научный форум — 2017
Во многих сферах, будь то деловая или личная, все чаще приходится работать с данными из разных источников, каждый из которых связан с определенным видом деятельности. Хранение информации является одной из важнейших функций компьютера. Одним из распространенных средств хранения данных – базы данных [1].
База данных – это упорядоченное хранение какой-либо информации. То есть, информация хранится в упорядоченном или систематизированном виде. Видов систематизации, упорядочивания и хранения информации может быть множество. Каждый из способов хранения информации отвечает каким-либо специфическим требованиям или предназначен для выполнения каких-либо определенных действий [4].
Основой любой базы данных является модель данных. Модель данных – это совокупность структур данных и операций их обработки. С ее помощью могут быть представлены информационные объекты и их взаимосвязи. Выделяют три основных типа моделей данных: иерархическую, сетевую и реляционную.
- Иерархическая модель представляет собой совокупность элементов, расположенных в порядке их подчинения от общего к частному.
То есть, в иерархической БД каждый объект представляется в виде определенной сущности, то есть, у этой сущности могут быть дочерние элементы, родительские элементы, а у тех дочерних могут быть еще дочерние элементы, но есть один объект, с которого все начинается. Получается своеобразное структурное дерево (граф).
- Сетевые базы данных, являются своеобразной модификацией иерархических баз данных. Отличаются от иерархических лишь тем, что у дочернего элемента может быть несколько предков, то есть, элементов стоящих выше него. Ниже на рисунке 1 приведен пример структуры сетевых баз данных.
- Главной особенностью реляционных баз данных является, то, что объекты внутри таких баз данных хранятся в виде набора двумерных таблиц. То есть, таблица состоит из набора столбцов, в котором может указываться: название, тип данных (дата, число, строка, текст и так далее). Еще одной важной особенность реляционных БД является, то, что число столбцов фиксировано, то есть, структурабазы данных известна заранее, а вот число строк или рядов в реляционных базах данных ничем не ограничено, если говорить грубо, то строки в реляционных базах данных и есть объекты, которые хранятся в базе данных [2].
- ИСТОРИЯ ВОЗНИКНОВЕНИЯ СЕТЕВОЙ МОДЕЛИ ДАННЫХ. ОПИСАНИЕ
На разработку этого стандарта большое влияние оказал американский ученый Чарльз Уильям Бахман. Основные принципы сетевой модели данных были разработаны в середине 60-х годов, эталонный вариант сетевой модели данных описан в отчетах рабочей группы по языкам баз данных (COnference on DAta SYstem Languages) CODASYL в 1971г.
Наиболее известной из таких систем была IDMS корпорации Computer Associates International, Inc [7].
Сетевая модель данных — это логическая модель данных, представляющая их сетевыми структурами типов записей и связанные отношениями мощности один-к-одному или один-ко-многим.
Сети – это естественный способ представления отношений между объектами базы данных и связей между этими объектами. Под словом объекты следует понимать таблицы баз данных или сущности.
Сетевые базы данных опираются на математику графов, конкретнее, сетевую модель данных можно представить в виде ориентированного графа. Направленный граф состоит из узлов и ребер. Узлы направленного графа – это ни что иное, как объекты сетевой базы данных, а ребра такого графа показывают связи между объектами сетевой модели данных, причем ребра показывают не только саму связь, но и тип связи (связь один к одному или связь один ко многим).
Рисунок 1 – Пример структуры сетевой базы данных
В отличие от реляционной модели, связи в ней моделируются наборами, которые реализуются с помощью указателей. Сетевые модели данных являются расширенной версией иерархической модели, однако основным отличием является то, что в сетевых моделях данных имеются указатели в обоих направлениях, которые соединяют родственную информацию.Сетевую модель можно представить, как граф узлами, которого является запись, а ребрами — набор. Сегменты данных в сетевых БД могут иметь множественные связи с сегментами старшего уровня. При этом направление и характер связи в сетевых БД не являются столь очевидными, как в случае иерархических БД. Поэтому имена и направление связей должны идентифицироваться при описании БД.
Сетевые базы данных имеют достаточно простую структуру. Структура состоит из четырех компонентов, то есть в сетевой модели используют четыре типа структур данных. Два из которых являются главными и два, если можно так сказать, не главными. Главные типы структур сетевых данных – это запись и набор [6]. Вспомогательные типы структур сетевой модели данных, которые используются для построения главных структур – это элемент данных и агрегат данных, на рисунке 2 представлена вся структура сетевых БД:
Рисунок 2 – Пример структуры сетевых баз данных
Рассмотрим каждую структуру более подробно:
- Элемент данных – это наименьшая информационная именованная единица данных, доступная пользователю, если провести аналогию с файловой системой, то это поле в файловой системе, а если проводить аналогию с реляционной базой данных, то элемент данных – один столбец таблицы реляционной БД. Если говорить точнее, то это подстолбец.
- Агрегат данных – это именованная совокупность данных внутри одной записи. Аналогию с реляционными БД тут не проведешь, поскольку агрегат данных – это столбец над столбцами, который объединяет элементы данных по логике их содержимого, для наглядности выше сказанного, рассмотрим рисунок 3:
Рисунок 3 – Пример агрегата данных сетевой модели данных
На данном рисунке видно, что дата – это агрегат данных структуры сетевой модели, а день, месяц и год – это элемент данных сетевой БД.
- Запись в сетевой модели данных – это конечный уровень обобщения данных, что-то наподобие таблицы в реляционной базе данных. Каждая запись в сетевой базе данных должна обладать или содержать в себе, как минимум один именованный элемент данных, если элементов внутри записи более одного, то каждый элемент данных должен обладать уникальным форматом.