Введение в БД: история и модели данных

1. Данные и информация

В истории вычислительной техники выделяют два больших направления. Сначала машины строили для счёта: сложные математические задачи, численные методы, специализированные языки вроде Fortran. Но со временем на первый план вышло другое направление — надёжное хранение информации, её преобразование и удобный доступ. Именно оно к концу 1960-х годов породило особый класс программного обеспечения — системы управления базами данных (DataBase Management System, DBMS).

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

Своё определение информации даёт и закон: согласно Федеральному закону «Об информации, информационных технологиях и о защите информации» от 27.07.2006 № 149-ФЗ информация — это сведения (сообщения, данные) независимо от формы их представления.

Чтобы информация стала данными, её нужно провести через четыре этапа:

1. Сбор — информация, которую предстоит преобразовать, собирается воедино.
2. Формализация — информация структурируется: текст разбивается на заголовки и абзацы, определяются форматы (дата, число, строка).
3. Кодирование — формализованная информация переводится в машинный формат: текст — в байты кодировки UTF-8, изображение — в JPEG.
4. Хранение — закодированные данные сохраняются на носителе: жёстком диске, в базе данных, в облаке.

2. СУБД, база данных и модель данных

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

База данных — набор информации, структурированный и хранящийся по определённым правилам: сведения о клиентах, продукции, финансах, связанные между собой и организованные для оптимального доступа.

СУБД не только хранит данные, но и управляет ими: создаёт, изменяет, удаляет записи и выполняет запросы. Для этого служат специализированные языки — прежде всего SQL (Structured Query Language).

Модель данных — формальная теория представления и обработки данных в СУБД. В классической теории она включает не меньше трёх аспектов:

• структура данных — как данные организованы: типы, логические структуры, связи между ними; именно структура определяет, как данные хранятся и как их можно извлечь;
• средства манипуляции — операции добавления, удаления, изменения и выборки; для них служат языки вроде SQL;
• методы поддержания целостности — правила и механизмы, гарантирующие достоверность и непротиворечивость данных: уникальность ключей, целостность ссылок между таблицами.

3. Краткая история баз данных

• 1955Программная обработка записей на основе файлов; носитель — перфокарты.
• 1956IBM представляет дисководы жёстких магнитных дисков.
• 1959Сообщество COBOL прорабатывает концепции схем БД и независимости данных.
• 1961–1963Integrated Data Store (IDS) Чарльза Бахмана — первая СУБД, начало сетевой и навигационной моделей.
• 1964На симпозиумах SDC введён термин «база данных».
• 1970Эдгар Ф. Кодд публикует первую работу по реляционной модели данных.
• 1971CODASYL Data Model — стандарт сетевой модели.
• 1973System R (IBM) — первая реляционная СУБД; Бахман получает премию Тьюринга.
• 1976Питер Чен предлагает графическую модель «сущность-связь» (ER).
• 1979Oracle V2 — первая коммерческая СУБД с поддержкой SQL.
• 1981Премия Тьюринга Эдгару Кодду за реляционную теорию.
• 1986ANSI принимает первый стандарт языка SQL.
• 1997Представлен стандарт объектных баз данных ODMG 2.0.
• 2002Forbes включает реляционную модель в список важнейших инноваций последних 85 лет.

4. Модели данных

4.1. Иерархическая модель

Иерархическая модель представляет базу данных в виде древовидной структуры из объектов разных уровней. Каждый объект-потомок имеет ровно одного предка, предок может иметь много потомков; объекты с общим предком называют близнецами (в программировании — братьями). Это старейшие СУБД, созданные в 1950–60-х для мейнфреймов — например, Information Management System (IMS) фирмы IBM.

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

1. Поле данных (атрибут) — минимальная неделимая, уникально адресуемая единица хранения данных.
2. Сегмент данных (запись, record, экземпляр данных) — совокупность полей данных, имеющая уникальную идентификацию (сущность в модели ER).
3. Экземпляр сегмента — конкретные значения полей.
4. Дерево — совокупность сегментов, связанных с помощью связи «родитель — потомок».

В иерархической базе данных пользователю доступны несколько ключевых операций, которые позволяют управлять структурами данных, поддерживать актуальность информации и извлекать нужные данные:

• Добавление в базу новой записи. Новые записи добавляются в определённые места структуры, обычно как дочерние элементы существующих записей. При добавлении важно соблюдать иерархические правила, чтобы сохранить правильные связи между родительскими и дочерними узлами.
• Изменение значений атрибутов (кроме ключевых) отдельной записи. Обновлять можно только некритичные атрибуты: изменение ключевых атрибутов, определяющих уникальность записи, может нарушить целостность структуры.
• Удаление записи со всеми дочерними записями. Удаление записи автоматически удаляет все зависимые от неё дочерние записи — в иерархии каждая запись зависит от родительской.
• Извлечение записи. Выбор конкретной записи для просмотра или дальнейшей обработки — основа поиска, анализа и подготовки отчётов.

Сценарии использования операторов

Манипулирование данными в иерархической БД осуществляется набором навигационных операторов:

• Найти указанное дерево в базе данных — идентифицировать и получить доступ к конкретной иерархии связанных записей.
• Перейти от одного дерева к другому — в базе может существовать несколько деревьев, организованных по разным принципам.
• Найти экземпляр записи, удовлетворяющий условию поиска — например, все записи с определённым значением поля.
• Перейти от одной записи к другой внутри дерева — от родительской к дочерней и обратно; основа навигации по сложным иерархиям.
• Перейти от одной записи к другой в порядке обхода иерархии — последовательный обход всех записей дерева сверху вниз или снизу вверх.
• Вставить новый экземпляр записи в указанную позицию — добавить дочернюю запись к существующему родителю или запись в определённую ветвь дерева.
• Обновить текущий экземпляр записи — изменить данные существующей записи без создания новой.
• Удалить текущий экземпляр записи — с учётом того, что удаление может затронуть все дочерние записи.
• Найти и удержать для дальнейшего изменения единственный экземпляр записи, удовлетворяющий условию поиска.
• Найти и удержать следующий экземпляр записи с теми же условиями поиска — удобно для обработки нескольких записей с одинаковыми характеристиками.
• Найти и удержать следующий экземпляр для того же родителя — последовательная обработка записей одного родительского узла.

Иерархические структуры в современности

В реальной жизни мы часто сталкиваемся со сложными связями «многие-ко-многим»: один студент посещает несколько курсов, и каждый курс посещается множеством студентов. В иерархической модели такие связи отразить сложно — она предполагает строгое подчинение, где каждый элемент имеет одного родителя. В результате для связей M:N требуется дублирование данных, что приводит к избыточности, усложняет управление и увеличивает риск ошибок. Именно поэтому иерархическая модель считается неудобной и устаревшей для многих задач.

Сегодня иерархические БД редко используются для новых проектов: их вытеснили более гибкие реляционные модели. Тем не менее старые иерархические системы продолжают эксплуатироваться — когда они содержат огромные объёмы критически важной информации, миграция которой затруднена или невозможна. Специалисты работают с существующими системами, параллельно разрабатывая инструменты постепенного переноса данных в реляционные базы.

При этом в узкоспециализированных задачах модель не потеряла актуальности — там, где связи строго однонаправленные, «один-ко-многим», иерархия проста и эффективна. Самый знакомый пример — файловая система с вложенными папками. Другой — реестр операционной системы Windows: иерархическая база всех настроек и параметров системы. Просмотреть и даже отредактировать её можно встроенной программой regedit (меню «Пуск» → «Выполнить» → regedit): откроется окно с иерархическим деревом, в котором видно, как организована информация о состоянии системы.

4.2. Сетевая модель

Сетевая модель снимает главное ограничение иерархии: на один объект можно ссылаться много раз, а хранение связей отделено от хранения данных. Сегменты здесь называют агрегатами.

Сетевая модель данных состоит из нескольких основных компонентов:

1. Сегменты — основные элементы структуры. Каждый сегмент представляет собой набор связанных записей, которые могут быть связаны с другими сегментами; у каждого сегмента есть уникальный идентификатор для обращения к нему и работы с содержимым.
2. Записи — наборы полей с данными. Каждая запись имеет уникальный идентификатор; записи могут быть связаны с другими записями, что даёт гибкость в организации данных.
3. Сети — связи между сегментами и записями. Они определяют отношения между данными и позволяют обращаться к связанным данным; бывают однонаправленными и двунаправленными, что задаёт направление доступа.
4. Владение — отношение между сегментами и записями: сегмент-владелец имеет доступ к содержимому записи и может изменять его. Владение тоже бывает однонаправленным или двунаправленным.
5. Связи — отношения между сегментами и записями, позволяющие связывать данные между собой; однозначные или многозначные — от этого зависит, сколько записей может быть связано с одним сегментом.

Пример: сетевая модель для финансового отдела

Рассмотрим, как организованы отношения между типами записей в процессе продаж: SALES-MAN (продавец), CUSTOMER (заказчик), PRODUCT (продукт), INVOICE (счёт), PAYMENT (платёж) и INVOICE-LINE (строка счёта).

• INVOICE-LINE (строка счёта) принадлежит одновременно двум типам записей — PRODUCT и INVOICE: каждая строка счёта содержит информацию о конкретном продукте и привязана к определённому счёту.
• INVOICE (счёт) связан с двумя владельцами — SALES-MAN и CUSTOMER: каждый счёт относится и к конкретному продавцу, и к конкретному заказчику, что позволяет отслеживать ответственность за продажу и её адресата.

Плюс модели — она обеспечивает атрибутивную целостность. Проблемы: сущности и связи хранятся отдельно, из-за чего появляется задача поддержания ссылочной целостности.

4.3. Графовые модели

Графовая база данных — развитие сетевой модели в виде графа и его обобщений. Графовые СУБД применяются для социальных сетей, биоинформатики и семантической паутины; на задачах с естественной графовой структурой они могут существенно превосходить реляционные по производительности и наглядности.

Мартин Клеппман в книге «Designing Data-Intensive Applications» формулирует практический признак: если в приложении планируется много сущностей и связей «многие-ко-многим» — это довод в пользу графовой СУБД. А если существующее приложение тратит основное время на обход связей — тем более: обход связей в графе «практически ничего не стоит». Пример промышленной системы — Amazon Neptune, облачная графовая СУБД с поддержкой моделей RDF и LPG и языков запросов SPARQL и Gremlin.

Графовые базы уже нашли применение в социальных сетях, системах рекомендаций («с этим товаром часто покупают…») и обработке пользовательских данных — корреляции сведений из разных источников, «информационного следа» в сети.

Семантические базы данных

Одно из применений графовых БД — семантические базы данных: специально организованные хранилища, где информация не только описывает факты, но и содержит смысловые связи между ними. В отличие от традиционных баз, которые ограничиваются хранением и извлечением данных, семантические исследуют глубинные связи и значения, лежащие в основе этих данных.

Основные строительные блоки семантических баз:

• RDF (Resource Description Framework) — формальный язык описания ресурсов и их отношений;
• SPARQL — язык запросов к RDF-данным;
• Linked Data — концепция объединения данных разных источников через общие семантические структуры.

Ключевая идея RDF — представление данных тройками «субъект — предикат — объект»:

Рассмотрим элементы тройки подробнее.

• Субъект (Subject) — основной объект описания, о котором мы сообщаем информацию: от реальных объектов (конкретные люди, места) до абстрактных концепций и даже других троек. Субъект идентифицируется с помощью URI, уникально определяющего ресурс.
• Предикат (Predicate) — отношение или свойство, связывающее субъект с объектом: «имеет возраст», «является автором», «расположен в». Предикаты также идентифицируются URI.
• Объект (Object) — значение или ресурс, связанный с субъектом через предикат: конкретное значение (строка, число) либо другой ресурс со своим URI. В тройке «Анна имеет возраст 25» объект — «25».

Примеры публичных RDF-проектов:

• DBpedia — извлечение структурированной информации из данных Wikipedia;
• GeoNames — база географических объектов;
• DBLP — база публикаций по информатике;
• PubMed — база публикаций по медицине;
• UniProt — база данных белков;
• OpenCyc — объёмная онтологическая база данных;
• LOD — технология связанных открытых данных.

Словари для описания данных: Dublin Core (DC) — атрибуты библиотечных метаданных; Friend-of-a-Friend (FOAF) — описание людей, их отношений и деятельности; Semantically-Interlinked Online Communities (SIOC) — онлайн-сообщества; Description of a Project (DOAP) — описание проектов; Simple Knowledge Organization System (SKOS) — стандартизованные таксономии; Creative Commons (CC) — описание лицензий.

4.4. Объектно-ориентированные модели

Объектные, или объектно-ориентированные, модели основаны на представлении данных в виде объектов, объединяющих в себе как сами данные, так и методы их обработки. Это позволяет естественно описывать реальные объекты и связи между ними, а также обрабатывать их с помощью методов и операций, применяемых к объектам.

Подобно иерархической модели, объектные модели представляют связи между объектами, однако вместо чёткой иерархии внимание уделяется объектам и их взаимосвязям: объекты могут содержать другие объекты в качестве своих частей, и каждый объект имеет свои уникальные свойства и методы. Важный аспект — возможность создавать и использовать классы объектов, что облегчает повторное использование кода и структурирует данные в единые блоки.

Компоненты объектно-ориентированной модели:

• Объекты — конкретные экземпляры классов с данными и функциональностью, определённой в классе.
• Классы объектов — шаблоны, описывающие структуру, свойства и методы объектов определённого типа.
• Свойства объектов — характеристики, описывающие объекты: имя, возраст, размер и т. д.
• Методы объектов — функции и действия, определяющие поведение объекта и операции с его данными.
• Связи между объектами — отношения и взаимодействия, устанавливаемые на уровне классов и объектов.
• Наследование — возможность одного класса наследовать свойства и методы другого.

Стандарт ODMG

ODMG (Object Data Management Group) — консорциум поставщиков объектно-ориентированных БД и других заинтересованных организаций, созданный в 1991 году для разработки стандарта на хранение объектов в базах данных. Опубликованная вторая версия стандарта — ODMG 2.0 — разработана на основе трёх существующих стандартов: управления базами данных (SQL), объектов (стандарты OMG — Object Management Group) и объектно-ориентированных языков программирования (C++, Smalltalk, Java).

ODMG добавляет в ОО-языки возможности взаимодействия с базами данных: определяются средства долговременного хранения объектов, расширяется семантика языка, вносятся операторы управления данными. Стандарт состоит из нескольких частей:

1. Объектная модель — унифицированная основа стандарта, расширяющая модель OMG связями и транзакциями. Ключевые концепции: атрибуты и связи объектов, методы (поведение), множественное наследование, идентификаторы объектов (ключи), совокупности объектов (списки, наборы, массивы), блокировка объектов и изоляция доступа, операции над базой данных.
2. Язык описания объектов ODL (Object Definition Language) — средство определения схемы базы данных, по аналогии с DDL реляционных СУБД. ODL — расширение IDL (Interface Definition Language) модели OMG: он описывает объектные типы, атрибуты, связи и методы, создавая слой абстрактных описаний, независимый и от языка программирования, и от СУБД. Детали реализации методов ODL не рассматривает, поэтому схему можно переносить между ODMG-совместимыми СУБД и транслировать в другие DDL.
3. Язык объектных запросов OQL (Object Query Language) — SQL-подобный декларативный язык извлечения объектов, включая высокоуровневые примитивы для наборов объектов и объектных структур. Синтаксис SELECT из SQL-92 — подмножество OQL: SELECT-запросы к реляционным таблицам сохраняют работоспособность с наборами объектов ODMG. OQL-запросы можно вызывать из ОО-языка и наоборот; язык обеспечивает целостность объектов через вызов их методов.
4. Связывание с ОО-языками — стандарт определяет OML (Object Manipulation Language), расширяющий C++, Smalltalk и Java средствами манипулирования и хранения объектов, включая OQL, навигацию и транзакции. У каждого языка свой OML, поэтому разработчик остаётся в одной языковой среде.

При объектном подходе выделяют следующие ограничения реляционной технологии:

1. Неестественное представление сложных данных. Реляционная модель моделирует всё плоскими отношениями (таблицами); поскольку все отношения принадлежат одному уровню, многие значимые связи либо теряются, либо поддерживаются в конкретной прикладной программе.
2. Трудно смоделировать свойства данных. Для естественного моделирования сложных структур пользователю нужны собственные типы данных, а не только предоставляемые СУБД.
3. Нельзя определить операции над данными типа. Реляционная модель не позволяет связать с типом данных набор операций — их приходится задавать в приложении.
4. Нет послойного просмотра. Данные нельзя рассматривать на разных уровнях абстракции, отвлекаясь от ненужных деталей.
5. Усложнённый доступ к базе данных. Интерфейс между языком программирования и языком БД сложен: у каждого языка свой набор типов и своя модель вычислений, поэтому при обращении из C++ данные подвергаются структурной трансформации при передаче в базу и из неё.

Примеры применения

• Федеральная авиационная администрация США (FAA) применяет систему на основе объектной БД для моделирования пассажиро- и грузопотоков: процедуры хранятся вместе с данными, поэтому моделирование сложных взаимосвязей проще, чем в реляционной базе.
• Французский национальный центр космических исследований (CNES) использует ООБД в авиакосмической промышленности — мультимедийная база данных помогает моделировать интегрированные системы при проектировании космических аппаратов.
• Électricité de France управляет объектной базой нагрузкой на линии электропередачи: база умеет нарисовать карту линий в зоне ответственности предприятия и помогает определить, какое оборудование необходимо для прокладки новой линии.

4.5. Документо-ориентированные модели

Документоориентированные БД — тип баз данных, предназначенный для хранения и запроса данных в виде документов, подобных JSON. Документо-ориентированная модель специально создана для хранения иерархических структур данных — документов. Документ — это набор атрибутов (пар «ключ — значение»); документ может быть вложен в документ. Представление данных — формат JSON или XML. Такие базы применяются в системах управления содержимым, издательском деле, документальном поиске и подобных задачах.

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

Примеры СУБД: MongoDB, CouchDB, Couchbase, MarkLogic, eXist, Berkeley DB. Применения: eBay использует MongoDB для данных о пользователях и транзакциях; BBC — CouchDB для мультимедийного контента; The New York Times — Firebase Firestore; Capital One — Amazon DocumentDB для финансовых данных.

4.6. Реляционная модель

Одна из самых широко используемых моделей данных. Данные организованы в виде таблиц, где строки представляют собой отдельные записи, а столбцы — атрибуты (характеристики) этих записей. Реляционная модель данных (РМД) — логическая модель данных, прикладная теория построения баз данных, которая является приложением к задачам обработки данных таких разделов математики, как теория множеств и логика первого порядка.

Реляционная модель включает следующие компоненты:

1. Структурный аспект — данные в базе представляют собой набор отношений.
2. Аспект целостности — отношения отвечают определённым условиям целостности; РМД поддерживает декларативные ограничения уровня домена (типа данных), уровня отношения и уровня базы данных.
3. Аспект обработки (манипулирования) — РМД поддерживает операторы манипулирования отношениями: реляционную алгебру и реляционное исчисление.

Примеры: PostgreSQL, MySQL, Oracle Database. Подробно реляционная модель разобрана в лекции 2.

4.7. Сравнение моделей

Каждая модель имеет свои преимущества и недостатки; выбор зависит от требований проекта и характера данных — это и тренирует симулятор ниже.

5. Тренажёр: подбери модель данных

Восемь коротких описаний реальных задач. Для каждой выберите модель данных, которая подходит лучше всего. После ответа тренажёр объясняет, почему правильная модель именно такая — формулировки объяснений опираются на признаки из разделов выше.

6. Главные концепции реляционных баз данных

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

Отношение (relation) — фундаментальное понятие модели, давшее ей имя. Таблица — лишь графическая интерпретация отношения: столбцы соответствуют вхождениям доменов, строки — кортежам.

Число кортежей называют кардинальным числом (мощностью) отношения, число атрибутов — его размерностью. Отношение состоит из заголовка (схемы) и тела; название атрибута может включать имя домена через двоеточие (например, UnitPrice:Currency).

Три важных следствия определения. Во-первых, отношение не упорядочено — понятие «номер строки» к нему неприменимо: для отношений не существует никакого внутреннего порядка. Во-вторых, отношение может иметь нулевое число кортежей — пустое отношение остаётся отношением. В-третьих, отношение — это множество: его элементы по определению уникально идентифицируемы, поэтому каждая строка таблицы-отношения должна быть уникально идентифицируемой, а записи не должны повторяться.

Таблица, представляющая отношение, обладает рядом свойств:

• в таблице нет двух одинаковых строк;
• таблица имеет столбцы, соответствующие атрибутам отношения;
• каждый атрибут в отношении имеет уникальное имя;
• порядок строк в таблице произвольный;
• под атрибутом понимается вхождение домена в отношение; строки отношения называются кортежами.

Формально: заголовок H_r — конечное множество пар ⟨A, T⟩ (имя атрибута и имя типа или домена); кортеж t_r — множество триплетов ⟨A, T, v⟩, где v — допустимое значение типа T; тело B_r — неупорядоченное множество различных кортежей; значение V_r отношения — пара множеств H_r и B_r. Первичный ключ — минимальный набор атрибутов, однозначно определяющий кортеж; при добавлении новых записей он обязан оставаться ключом (поэтому «Фамилия + Имя + Отчество» — плохой ключ, даже если тёзок пока нет).

6.1. Домен

Домен определяет «вид» данных, которые представляет данный атрибут. Более чёткое определение: домен — это набор всех допустимых значений, которые может содержать данный атрибут. Понятие домена намного шире понятия «тип данных», поскольку определение домена включает более детальное описание допустимых значений. Домен — это тип данных плюс логические правила, определённые для данной сущности; при этом логические правила — механизм реализации целостности данных, а не элемент их описания.

7. Пространственные базы данных

Курс называется «Управление данными», но читается он картографам и геоинформатикам — поэтому из всего многообразия баз данных нас особенно интересует один класс: базы, умеющие хранить не только числа и строки, но и местоположение.

7.1. Из чего состоит пространственный объект

ГОСТ Р 52438-2005 «Географические информационные системы. Термины и определения» выделяет в пространственном объекте три составляющие:

• Координатные данные — позиционная характеристика объекта, описывающая его местоположение в установленной системе координат в виде последовательности наборов координат точек. Это «геометрия»: где объект находится и какую форму имеет.
• Идентификатор — уникальная характеристика объекта, присваиваемая пользователем или назначаемая информационной системой. Именно идентификатор фиксирует связь координатных и атрибутивных данных: по нему система знает, что геометрия № 38 и строка № 38 в таблице — один и тот же объект.
• Атрибутивные данные — набор имён и значений атрибутов объекта: название, тип покрытия, население, дата обследования…

7.2. Какие виды объектов бывают

Пространственные данные существуют в двух принципиально разных представлениях. Векторное описывает объекты геометрическими примитивами: точка, линия из узлов, полигон. Растровое покрывает территорию регулярной сеткой ячеек, и значение хранится в каждой ячейке.

С вектором связь «объект → строка таблицы атрибутов» очевидна. А где атрибуты у растра? В структурах вроде ESRI GRID к растру прилагается таблица значений атрибутов (Value Attribute Table, VAT): каждой ячейке присвоен код (Value), а таблица хранит для каждого кода число ячеек (Count) и содержательные атрибуты — например, тип почвы.

7.3. Геопространственные СУБД: два пути

Исторически сложились два подхода к хранению пространственных данных.

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

Расширения реляционных СУБД. Пример — Oracle Spatial: к обычной реляционной СУБД добавляется новый пространственный тип данных, SQL расширяется операторами для манипуляций с ним, а оптимизатор запросов учится ускорять пространственные операции — например, пространственные соединения.

8. Популярные СУБД

Российский рынок СУБД постепенно развивается, и на нём появляются многообещающие продукты. Несмотря на популярность мировых лидеров — Oracle, MySQL и Microsoft SQL Server, — в России активно используют и разрабатывают собственные СУБД, учитывающие особенности и потребности российского бизнеса.

Oracle Database — одна из наиболее узнаваемых и широко используемых СУБД в мире. Её популярность обусловлена не только высокой надёжностью, но и способностью обеспечивать поддержку корпоративных приложений на высоком уровне. Богатый спектр функций позволяет использовать Oracle Database для разнообразных задач: от аналитики до обработки транзакций с высокой производительностью.

MySQL — открытая реляционная СУБД, популярная в веб-разработке и среди малых предприятий. Бесплатность и лёгкость использования делают её предпочтительным выбором для многих разработчиков, особенно начинающих, и для проектов с ограниченными ресурсами.

Microsoft SQL Server — ещё один крупный игрок, предоставляющий разнообразные функции для разработки приложений под Windows и интеграции с другими продуктами Microsoft. Удобство использования и встроенность в экосистему Microsoft делают его популярным для приложений, созданных под Windows.

MongoDB — нереляционная (NoSQL) база данных, которая отличается тем, что хранит данные в формате JSON, обеспечивая гибкость в обработке неструктурированных данных. Масштабируемость и высокая скорость обработки делают MongoDB популярным выбором для приложений с большими объёмами данных.

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

Ещё одна интересная российская разработка — Arenadata DB (ADB): реляционная СУБД, построенная на основе Greenplum и включённая в реестр российского программного обеспечения. Greenplum — мощная распределённая СУБД, ориентированная на анализ больших объёмов данных; Arenadata DB предоставляет широкие возможности для хранения, обработки и анализа данных в корпоративных окружениях.

Контрольные вопросы

• Чем данные отличаются от информации? Какие этапы превращают одно в другое?
  Данные — формализованное представление информации, пригодное для передачи и обработки (ГОСТ 33707-2016). Путь от информации к данным: сбор → формализация (структура и форматы) → кодирование (машинный формат: UTF-8, JPEG) → хранение (диск, БД, облако).
• Назовите три обязательных аспекта модели данных.
  Структура данных (как данные организованы), средства манипуляции (операции добавления, изменения, удаления, выборки — например, SQL) и методы поддержания целостности (уникальность ключей, ссылочная целостность). Без любого из трёх это не модель данных, а формат хранения.
• Почему иерархическая модель не подходит для связи «многие-ко-многим»? Где она уместна до сих пор?
  В иерархии у потомка ровно один предок, поэтому связь M:N требует дублирования данных — отсюда избыточность и риск рассогласования. Уместна там, где связи строго «один-ко-многим»: файловая система, реестр Windows.
• Из чего состоит RDF-тройка? Приведите пример.
  Субъект (описываемый ресурс, идентифицируется URI), предикат (отношение или свойство) и объект (значение или другой ресурс). Пример: «Анна — имеет возраст — 25». На тройках строятся семантические БД; язык запросов — SPARQL.
• По каким признакам стоит выбрать графовую СУБД (по Клеппману)?
  Много сущностей и связей «многие-ко-многим» в планируемом приложении; либо существующее приложение тратит основное время и ресурсы на обход связей — в графовой СУБД обход связей практически ничего не стоит.
• Что такое отношение, кортеж, атрибут и мощность отношения?
  Отношение — вся структура (заголовок + тело); кортеж — элемент тела, «строка»; атрибут — именованное вхождение домена в заголовок, «столбец»; мощность (кардинальность) — число кортежей; размерность — число атрибутов.
• Чем домен отличается от типа данных?
  Тип данных — физическая концепция (целое число, строка), домен — логическая: тип плюс правила допустимости значений («возраст» — целые числа из осмысленного диапазона). Понятие домена шире типа.
• Из каких трёх составляющих состоит пространственный объект по ГОСТ Р 52438-2005?
  Координатные данные (позиционная характеристика — местоположение в системе координат), идентификатор (уникальная характеристика, связывающая координатную и атрибутивную части) и атрибутивные данные (набор имён и значений атрибутов объекта).
• Назовите два подхода к построению геопространственных СУБД. Какой используется в курсе?
  Специализированные геоинформационные СУБД (ArcInfo: подсистема Arc — пространственные данные, Info — описательные) и расширения реляционных СУБД (Oracle Spatial, PostGIS: новый пространственный тип данных плюс SQL-операторы для него). В курсе — второй подход: PostgreSQL + PostGIS.
• Почему «Фамилия + Имя + Отчество» — плохой первичный ключ, даже если тёзок в таблице нет?
  Первичный ключ обязан оставаться уникальным при добавлении новых записей. Отсутствие полных тёзок сейчас не гарантирует их отсутствия в будущем — ключ должен опираться на атрибуты, уникальность которых гарантируется правилами предметной области, а не текущим содержимым таблицы.

Источники

1. ГОСТ 33707-2016 (ISO/IEC 2382:2015). Информационные технологии. Словарь. — М. : Стандартинформ, 2016.
2. ГОСТ Р ИСО/МЭК 10746-2-2000. Информационная технология. Взаимосвязь открытых систем. Управление данными и открытая распределённая обработка. — М. : Изд-во стандартов, 2000.
3. ГОСТ 34.320-96. Информационные технологии. Система стандартов по базам данных. Концепции и терминология для концептуальной схемы и информационной базы. — М. : Изд-во стандартов, 1997.
4. ГОСТ Р 52438-2005. Географические информационные системы. Термины и определения. — М. : Стандартинформ, 2006.
5. Дейт, К. Дж. Введение в системы баз данных / К. Дж. Дейт. — 8-е изд. — М. : Вильямс, 2005. — 1328 с.
6. Codd, E. F. A Relational Model of Data for Large Shared Data Banks // Communications of the ACM. — 1970. — Vol. 13, № 6. — P. 377–387.
7. Клеппман, М. Высоконагруженные приложения. Программирование, масштабирование, поддержка / М. Клеппман. — СПб. : Питер, 2018. — 640 с.
8. DB-Engines Ranking : [сайт]. — URL: https://db-engines.com/en/ranking (дата обращения: 18.08.2026).