Модели данных: от иерархической до документной

В прошлом уроке СУБД была строгим секретарём, который ведёт тетрадь. Но тетради бывают разными: в одной всё разложено по папкам, в другой страницы связаны стрелками, в третьей аккуратные таблицы. Этот урок о том, какими способами СУБД раскладывают данные, откуда эти способы взялись и почему сегодня ты чаще всего встретишь таблицы и документы.

Одни данные, четыре картинки

Возьмём маленькую библиотеку. В ней есть авторы и книги, и у одной книги может быть несколько авторов. Например, «Понедельник начинается в субботу» написали двое: Аркадий и Борис Стругацкие. А у Бориса Стругацкого есть и книги, написанные без брата.

Связь, где у книги много авторов, а у автора много книг, называют «многие ко многим». Запомни её: именно на ней модели данных спотыкаются по-разному.

Модель данных это ответ на три вопроса: из каких кирпичиков состоят данные, как выражаются связи между ними и как к ним обращаться. Давай нарисуем нашу библиотеку четырьмя способами, в том порядке, в каком они появлялись в истории.

Иерархическая модель: дерево папок

Самый понятный способ разложить что угодно это дерево, как папки на компьютере. Есть корень, у него дети, у детей свои дети. У каждого ребёнка ровно один родитель.

Аркадий Стругацкий
├── Понедельник начинается в субботу
└── Дьявол среди людей
Борис Стругацкий
├── Понедельник начинается в субботу   ← копия
└── Поиск предназначения

Это иерархическая модель. На ней в конце 1960-х работала IBM IMS, одна из первых коммерческих СУБД, которую делали в том числе для учёта деталей программы «Аполлон».

Пока каждая книга принадлежит одному автору, всё прекрасно. Но у «Понедельника» два автора, а у ребёнка в дереве может быть только один родитель. Приходится хранить книгу дважды. Это ровно та беда из прошлого урока: исправил год издания в одной копии, а вторая осталась со старым.

Есть и вторая проблема. Дерево удобно читать сверху вниз: «все книги автора». А вопрос «кто авторы этой книги?» заставляет обойти всё дерево целиком.

Сетевая модель: стрелки между карточками

Следующая идея: раз дерево слишком строгое, разрешим записи иметь несколько родителей. Каждая книга хранится один раз, а связи это указатели, стрелки от записи к записи.

[Аркадий] ──┬──▶ [Дьявол среди людей]
            └──▶ [Понедельник начинается в субботу]
[Борис] ────┬──▶ [Понедельник начинается в субботу]  ← та же запись
            └──▶ [Поиск предназначения]

Это сетевая модель, её стандартизировал комитет CODASYL около 1970 года. Дублирование ушло. Но появилась новая плата: чтобы что-то найти, программа идёт по стрелкам сама. «Встань на Бориса, переходи по его стрелкам к книгам, на каждой книге проверь год». Это называют навигационным доступом.

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