Сетевая модель данных¶

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

¶История возникновения и развития

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

В 1969 году Комитет по языкам баз данных (Conference on Data Systems Languages, CODASYL) опубликовал первый отчет, описывающий сетевую модель данных. Этот документ, известный как «Отчет CODASYL DBTG» (Data Base Task Group), стал основой для стандартизации. В 1971 году появился пересмотренный вариант, в котором были детализированы структура данных, навигационные операции и язык манипулирования данными (DML). Отчет CODASYL определил два основных компонента: схему (описание всей базы данных) и подсхему (описание её части для конкретного приложения).

Первые коммерческие реализации сетевой модели появились в начале 1970-х годов. Среди наиболее известных СУБД того времени — IDMS (Integrated Database Management System) компании Cullinet (изначально разработанная в компании Goodyear Aerospace) и DBMS-10 для операционной системы DEC PDP-10, а также IMAGE компании Hewlett-Packard. В СССР также велись разработки: например, сетевая СУБД «СЕТЬ» для ЕС ЭВМ и «Банк» для СМ ЭВМ. Сетевая модель доминировала в коммерческих системах в 1970-х — начале 1980-х годов, до широкого распространения реляционной модели данных (предложенной Эдгаром Коддом в 1970 году). Однако даже после появления реляционных СУБД, некоторые сетевые системы продолжали использоваться в legacy-системах банков, телекоммуникаций и промышленности вплоть до начала XXI века.

¶Основные понятия и терминология

Сетевая модель данных оперирует рядом специфических понятий, закреплённых стандартом CODASYL:

• Запись (Record) — совокупность полей (атрибутов), описывающих объект. Каждая запись имеет уникальный идентификатор (обычно адрес в памяти или ключ).
• Набор (Set) — поименованная связь между записями двух типов, задающая отношение «один ко многим». Набор состоит из одной записи-владельца (owner) и одного или нескольких записей-членов (member). В отличие от иерархической модели, запись может быть владельцем нескольких разных наборов и одновременно входить как член в несколько разных наборов.
• Тип записи (Record type) — шаблон, определяющий структуру (набор полей) для группы записей. Например, тип «Студент» может содержать поля: ФИО, номер зачётной книжки, год рождения.
• Тип набора (Set type) — определение связи между двумя типами записей. Например, тип набора «Группа-Студент», где владельцем является запись типа «Группа», а членами — записи типа «Студент».
• Экземпляр записи (Record occurrence) — конкретный объект (например, студент Иванов).
• Экземпляр набора (Set occurrence) — конкретная реализация связи (например, группа «ИУ5-22Б» как владелец и список студентов этой группы как члены).

Ключевая особенность сетевой модели — возможность создания нескольких типов наборов для одних и тех же типов записей, а также циклических связей. Это позволяет реализовывать отношения «многие ко многим» путем введения промежуточной записи («ассоциативного типа»), которая входит как член в два разных набора. Например, для связи «Студент-Предмет» (многие ко многим) создается третья запись «Оценка», которая является членом наборов «Студент-Оценка» и «Предмет-Оценка».

¶Структура и навигация

Данные в сетевой модели физически хранятся в виде связанных списков. Каждая запись содержит указатели на другие записи — либо прямые ссылки на память, либо логические ключи. Структура базы данных описывается в схеме, которая определяет все типы записей, типы наборов и правила целостности (например, режим включения членов в набор: автоматический или ручной; режим удаления: обязательное или необязательное).

Доступ к данным осуществляется не через декларативные запросы (как в SQL), а путём навигации — последовательного перемещения по связям между записями. Программист выполняет шаги:

1. Найти первую запись заданного типа (например, первую группу).
2. Перейти к первому члену набора (первому студенту).
3. Прочитать значение поля.
4. Перейти к следующему члену набора (следующему студенту).
5. Повторять, пока не будет пройден весь список.

Для этого используются специальные команды DML, такие как FIND, GET, NEXT, PRIOR, OWNER и другие. Такой подход называют навигационным. Он даёт программисту полный контроль над порядком обработки, но требует написания сложного и объёмного кода, особенно для запросов с несколькими условиями. Язык манипулирования данными обычно встраивался в языки общего назначения, такие как COBOL, FORTRAN или PL/I.

¶Преимущества и недостатки

¶Преимущества

• Гибкость моделирования — возможность описывать произвольные, в том числе циклические связи, что позволяет точно отражать реальные бизнес-правила (например, «сотрудник работает в одном отделе, но может участвовать в нескольких проектах»).
• Производительность — при хорошо спроектированной структуре данные кэшируются в память, а доступ по указателям (ссылкам) часто быстрее, чем реляционные операции соединения (JOIN), особенно на медленных дисковых накопителях 1970—1980-х годов.
• Целостность на уровне модели — связи контролируются системой, что снижает риск получения несогласованных данных (например, нельзя создать запись-член без владельца, если это запрещено схемой).

¶Недостатки

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

¶Сравнение с другими моделями данных

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

¶Пример реализации

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

Типы записей:

• Группа (поля: НомерГруппы, Факультет)
• Студент (поля: ФИО, ДатаРождения)
• Экзамен (поля: Предмет, Дата)
• Оценка (поля: Балл)

Типы наборов:

• Группа-Студент (владелец — Группа, член — Студент): каждый студент принадлежит одной группе; одна группа содержит много студентов.
• Студент-Оценка (владелец — Студент, член — Оценка): у одного студента много оценок.
• Экзамен-Оценка (владелец — Экзамен, член — Оценка): на одном экзамене много полученных оценок.

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

¶Влияние и наследие

Несмотря на практически полное вытеснение реляционными СУБД в новых разработках, сетевая модель оставила значительное наследие. Концепция навигационного доступа повлияла на современные системы управления данными, такие как графовые базы данных (Neo4j, Amazon Neptune) и некоторые реализации объектно-ориентированных БД. Идея использования явных указателей для представления связей также нашла отражение в NoSQL-системах (HBase, Apache Cassandra). Кроме того, многие современные СУБД, работающие с проблемно-ориентированными данными (например, временными рядами или телеметрией), могут использовать сетевые принципы для оптимизации скорости чтения.

Стандарт CODASYL стал одним из первых в истории попыток создания универсального языка определения данных (DDL) и манипулирования данными (DML), что послужило прототипом для более поздних стандартов SQL и ODMG (Object Data Management Group). В академическом образовании сетевая модель изучается как важный исторический этап эволюции баз данных, демонстрирующий как сильные стороны навигационного подхода, так и его фундаментальные ограничения.

¶Источники

1. Отчет CODASYL Data Base Task Group (DBTG), 1971.
2. Ч. Дж. Дейт. Введение в системы баз данных. 8-е издание. — М.: Вильямс, 2006.
3. Т. Коннолли, К. Бегг. Базы данных. Проектирование, реализация и сопровождение. — М.: Вильямс, 2003.
4. Д. Кренке. Теория и практика построения баз данных. — СПб.: Питер, 2002.
5. Г. Г. Трапезникова. Базы данных. Курс лекций. — М.: МФТИ, 2008.
6. C. J. Date. An Introduction to Database Systems. 8th ed. — Addison-Wesley, 2003.