Сетевая модель данных — это способ организации базы данных, в котором записи связаны отношениями «многие-ко-многим»: у одной записи может быть несколько родительских и несколько дочерних. Это отличает ее от иерархической модели, где у записи только один родитель.
Содержание
Сразу разведем частую путаницу. Сетевая модель БД — это не про компьютерные сети и передачу данных. «Сеть» здесь — метафора структуры: записи и связи между ними образуют граф. Речь об организации данных, а не о протоколах и каналах связи.
Ниже разберем, как устроена модель (записи, наборы, связи), в чем ее плюсы и минусы, чем она отличается от иерархической и реляционной, и на каких системах она реально работала — CODASYL, IDS, IDMS.
Как устроена: записи, наборы, связи
В основе модели два понятия.
Запись (record) — единица данных об объекте: студент, курс, деталь, поставщик. Записи одного вида образуют тип записи (аналог сущности).
Набор (set) — именованная связь «один-ко-многим» между записью-владельцем (owner) и записями-членами (member). Именно наборы соединяют записи в структуру.
Связь «многие-ко-многим» в чистом виде набор не выражает — набор всегда «один владелец -> много членов». Поэтому M:N собирают из двух наборов через промежуточную запись-связку. Это ключевой прием модели.
Возьмем сквозной пример: студенты и курсы. Один студент ходит на много курсов, один курс слушает много студентов — это связь «многие-ко-многим». Ее раскладывают через запись-связку «Запись на курс»:
Студент "Иванов" Курс "Базы данных"
| набор "записи студента" | набор "записи курса"
+----> [Запись на курс] <--------+
+----> [Запись на курс] <-- Курс "Алгоритмы"
Здесь запись «Запись на курс» — член сразу двух наборов: набора со владельцем-студентом и набора со владельцем-курсом. Пройдя по первому набору, мы получим все курсы студента; пройдя по второму — всех студентов курса.
Обращение к данным — навигационное. Программа явно перемещается по связям: взять владельца, перейти к первому члену набора, к следующему, подняться к владельцу другого набора. Такой обход задает сам разработчик, а не декларативный запрос вроде SQL.
Особенности: плюсы и минусы
Сетевая модель сильна там, где связей много и они сложные, но расплачивается за это жесткостью и трудоемкостью.
| Плюсы | Минусы |
|---|---|
| Прямое выражение связей «многие-ко-многим» через наборы | Навигационный доступ: обход связей пишет программист вручную |
| Быстрый обход по заранее проложенным связям (указателям) | Жесткая схема: изменить структуру связей в работающей базе трудно |
| Контроль целостности через членство записи в наборе | Нет единого декларативного языка запросов уровня SQL |
| Экономия на дублировании: связка вместо повторения данных | Код приложения тесно привязан к физической структуре хранения |
Важная оговорка: «быстро» здесь означает быстрый проход по уже существующей связи. Если нужен запрос, под который связь не проложена, модель проигрывает реляционной — произвольную выборку по условию она делает плохо.
Сетевая, иерархическая и реляционная модели: сравнение
Три классические модели удобно сравнить по тому, как они выражают связи и как к данным обращаются.
| Признак | Иерархическая | Сетевая | Реляционная |
|---|---|---|---|
| Структура | Дерево | Граф (записи и наборы) | Таблицы (отношения) |
| Родители у записи | Один | Несколько | Задается через ключи, не фиксирована |
| Связь «многие-ко-многим» | Напрямую нельзя, только через дублирование | Через запись-связку и два набора | Через отдельную таблицу и внешние ключи |
| Доступ к данным | Навигационный, по дереву | Навигационный, по связям | Декларативный (SQL), по значениям |
| Пример СУБД | IBM IMS | IDS, IDMS (CODASYL) | Oracle, PostgreSQL, MySQL |
| Когда уместна | Строго древовидные данные | Много жестких связей M:N, критична скорость обхода | Большинство прикладных задач сегодня |
Коротко: иерархическая модель — частный случай (дерево, один родитель), сетевая снимает ограничение на одного родителя, а реляционная меняет сам принцип — от ручной навигации по связям к запросам по значениям в таблицах.
Отдельно про графовые СУБД (например Neo4j). Они возвращают интуицию «узлы и связи», но это не та же самая сетевая модель CODASYL: у них декларативный язык запросов и гибкая схема, а не жесткие наборы и ручная навигация. Родство здесь идейное, а не техническое.
Примеры: CODASYL, IDS, IDMS
IDS (Integrated Data Store). Первую систему на основе сетевой модели создал Чарльз Бахман в General Electric в начале 1960-х. За вклад в технологии баз данных Бахман получил премию Тьюринга в 1973 году.
CODASYL / DBTG. CODASYL — это Conference on Data Systems Languages, та же организация, что стандартизировала язык COBOL. Ее рабочая группа по базам данных (Data Base Task Group, DBTG) в 1971 году выпустила отчет, который зафиксировал сетевую модель как стандарт: понятия записи, набора, схемы и языка манипулирования данными.
IDMS (Integrated Database Management System). Промышленная реализация сетевой модели CODASYL. Появилась в начале 1970-х, работала на мейнфреймах IBM и, что важно, поддерживается до сих пор — сейчас под маркой Broadcom (ранее Computer Associates, CA IDMS). Это редкий случай, когда сетевая СУБД пережила эпоху и осталась в эксплуатации в крупных legacy-системах.
Почему модель уступила место реляционной. После статьи Эдгара Кодда о реляционной модели (1970) и появления SQL промышленный стандарт сместился к таблицам и декларативным запросам: их проще сопровождать и не нужно вручную прокладывать пути доступа. Сетевые СУБД остались в узкой нише — там, где системы работают десятилетиями и переписывать их дороже, чем поддерживать.
Выводы
- Сетевая модель данных организует базу как граф записей и наборов, где у записи может быть несколько родителей и несколько потомков.
- «Сетевая» относится к структуре связей внутри базы, а не к компьютерным сетям и передаче данных — это разные темы.
- Связь «многие-ко-многим» модель выражает через запись-связку и два набора; в этом ее главное отличие от иерархической модели с единственным родителем.
- Доступ навигационный: пути обхода задает программист, единого декларативного языка уровня SQL в модели нет.
- Реляционная модель вытеснила сетевую за счет простоты сопровождения и запросов по значениям; сетевые СУБД остались в legacy-нише (IDMS на мейнфреймах).
Где применяется / связь с практикой
На практике сетевую модель сегодня чаще встречают не как выбор для нового проекта, а как наследие: legacy-системы на IDMS, миграции с мейнфреймов, задачи, где нужно понять и перенести структуру связей в реляционную или графовую базу. Понимание модели помогает читать такие системы и грамотно их переносить.
Освойте тему на практике
Если вы разбираетесь в моделях данных предметно — от иерархической и сетевой до реляционной и проектирования схем, — системно это дают на курсе subd. Посмотреть формат и темы вживую можно на бесплатных вебинарах — без оплаты и с разбором практических задач.
Смежные темы: Иерархическая база данных: модель, структура и примеры, Все о сетях в компьютерах и передаче данных.
FAQ
Сетевая модель БД и графовая база данных — это одно и то же?
Нет. Идея «узлы и связи» общая, но графовые СУБД (Neo4j и подобные) используют декларативные запросы и гибкую схему, а классическая сетевая модель CODASYL опирается на жесткие наборы и ручную навигацию по связям.
Сетевые базы данных еще используют или это только история?
В новых проектах почти нет, но эксплуатируемые системы остались: IDMS до сих пор работает на мейнфреймах в крупных организациях, поэтому модель встречается при сопровождении и миграции legacy.
Чем набор (set) отличается от таблицы связей в реляционной БД?
Набор — это заранее проложенная связь с указателями от владельца к членам, обход задает программа. Таблица связей в реляционной базе соединяет строки по значениям ключей, а выборку описывает декларативный SQL-запрос.
