2.2 Использование сетевой модели
Разбираться со структурой сетевых баз данных на примере будет более понятно и доступно. Представим, что мы хотим создать запись в сетевую базу данных, назовем ее скажем «Сотрудник», в которую обязательно должен входить агрегат данных, который представлен на рисунке 3, его мы назовем «Дата».
Рис. 3 «Агрегат данных сетевой модели данных»
В эту запись нам необходимо будет добавить: табельный номер, ФИО и адрес сотрудника. Такая запись в сетевой модели данных представлена на рисунке 4.
Рис. 4 «Запись сетевой базы данных»
Для большей ясности представим новый агрегат данных, который назовем «Товар». Новый агрегат представлен на рисунке 5.
Рис. 5 «Агрегат типа повторяющаяся группа»
Товары обычно хранятся на складе или их продают, зачастую по нескольку штук. Агрегат типа повторяющаяся группа – это несколько агрегатов типа вектор, объединенных вместе. Допустим, у нас покупают 5 товаров, значит, если наш агрегат «Товар» будет иметь тип повторяющаяся группа, то он будет состоять из 5 агрегатов типа вектор, примерно так.
Представим, что у нас имеется две записи в сетевой базе данных: запись «Сотрудник» и запись «Отдел», структура которой в данном контексте нам не важна.
Перед нами стоит задача: осуществить логическую связь между двумя этими записями, то есть определить какая запись будет управляемой, а какая управляющей. Логично предположить, что запись «Отдел» должна быть управляющей, поскольку сотрудник работает в отделе, а не отдел в сотруднике. И понятно, что связь между этими записями должна быть один ко многим, потому что отдел один, а сотрудников много, назовем эту связь «Работает». Можно прийти к выводу, что набор записей сетевой модели данных определяет: управляющую запись, в нашем случае это «Отдел», подчиненную запись, которую мы назвали «Сотрудник», а также тип связи между этими записями, которую мы обозначили «Работает». «Работает» — это не только имя связи, но еще и метка, которая именует сам набор данных сетевой модели, который представлен на рисунке 6.6
Рис 6. Набор записей сетевой модели данных
В данном случае связь один ко многим говорит нам о том, что с одним экземпляром записи «Отдел» может быть связано ноль, один или несколько экземпляров записи «Сотрудник». Экземпляр записи – это что-то наподобие кортежа (строки таблицы) из реляционной БД.7 Использую понятия сетевой модели данных, приведенные выше, можно нарисовать набор записей по-другому. Можно отобразить логические типы данных для обеих записей, структуру записей сетевой модели данных и указать связь между записями, которую мы обозвали «Работает».
Заключение
Таким образом, пользователи сетевых СУБД ограничены связями, определенными для них разработчиками БД-приложений. Подобно иерархическим, сетевые СУБД предполагают разработку БД приложений опытными программистами и системными аналитиками.
Также к недостаткам сетевой модели данных относится высокая сложность и жесткость схемы БД, построенной на ее основе, а также сложность для понимания и выполнения обработки информации в БД обычным пользователем. Кроме того, в сетевой модели данных ослаблен контроль целостности связей вследствие допустимости установления произвольных связей между записями.
Однако достоинством сетевой модели данных является возможность эффективной реализации по показателям затрат памяти и оперативности. В сравнении с иерархической моделью сетевая модель предоставляет большие возможности в смысле допустимости образования произвольных связей. В рамках сетевых СУБД легко реализуются и иерархические даталогические модели. Сетевые СУБД поддерживают сложные соотношения между типами данных, что делает их пригодными в различных приложениях.