Введение

Базы данных являются основой практически всех современных информационных систем, и без них невозможно представить работу уже ни одной организации. Развитие СУБД началось еще в 60-е годы, когда разрабатывался проект полета корабля Apollo на Луну.

В середине 60-х годов корпорация IBM совместно с фирмой NAA (North American Aviation) разработали первую СУБД - иерархическую систему IMS (Information Management System).

Другим заметным достижением середины 60-х годов было появление системы IDS (Integrated Data Store) фирмы General Electric. Развитие этой системы привело к созданию нового типа систем управления базами данных – сетевых СУБД, что оказало существенное влияние на информационные системы того поколения. Сетевая СУБД создавалась для представления более сложных взаимосвязей между данными, чем те, которые можно было моделировать с помощью иерархических структур, и послужили основой для разработки первых стандартов БД.

В этом курсе мы рассмотрим базовые понятия управления данными, историю развития СУБД. Обзорно узнаем какие бывают модели данных. Основное внимание будет уделено реляционной модели данных, как наиболее распространенной и языку SQL, как наиболее стандартизированному.

Кроме этого, в учебном пособии уделяется внимание базовым методам проектирования БД и рассматриваются практические примеры разработки приложений.

Содержатся практические задания для закрепления материала.

Понятия предметной области

Система управления базами данных (СУБД) – системное программное обеспечения, для создания и использования баз данных (БД), добавления, изменения и удаления данных в них, выполнения запросов к этим данным и их обработки.

Основные функции СУБД:

  1. Хранение данных.
  2. Управление данными.
  3. Резервное копирование и восстановление данных.
  4. Поддержка языков запросов (язык определения данных, язык манипулирования данными).
  5. Обеспечение и контроль многопользовательского доступа к данным.
  6. Обеспечение целостности.

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

Длительное время термин «модель данных» использовался без формального определения. Одним из первых специалистов, который достаточно формально определил это понятие, был Э. Кодд. В статье «Модели данных в управлении базами данных» он определил модель данных как комбинацию трёх компонентов [REF]:

  1. Коллекции типов объектов данных, образующих базовые строительные блоки для любой базы данных, соответствующей модели.
  2. Коллекции общих правил целостности, ограничивающих набор экземпляров тех типов объектов, которые законным образом могут появиться в любой такой базе данных.
  3. Коллекции операций, применимых к таким экземплярам объектов для выборки и других целей.

Классификации СУБД по моделям данных:

  1. Иерархические.
  2. Сетевые.
  3. Реляционные.
  4. Ключ-значение.
  5. Документоориентированные.

Иерархические

В иерархической модели, данные организованы в виде древовидной структуры, подразумевая одного родителя для каждой записи. Поле сортировки сохраняет одноуровневые записи в определенном порядке. Иерархические структуры широко использовались в ранних системах управления базами данных мейнфреймов, таких как IBM IMS. Эта структура допускает одно взаимное отношение между двумя типами данных и очень эффективна для описания многих взаимосвязей в реальном мире: рецепты, оглавление, любую вложенную и отсортированную информацию. Файловая система может служить хорошим примером иерархической организации данных.

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

Схематически иерархическая модель данных показана на рисунке.

Основными операциями над данными в иерархических СУБД являются:

  1. Поиск указанного объекта. Например, сотрудника с указанным номером.
  2. Переход от одного объекта к другому – к дочерней или родительской.
  3. Вставка записи в указанную позицию.
  4. Обновление текущей записи.
  5. Удаление текущей записи.

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

Плюсами иерархических СУБД является быстродействие в случае иерархически упорядоченных данных и эффективное использование памяти.

В тоже время модель данных является сложной для понимания пользователей.

Сетевые

Сетевая модель расширяет иерархическую структуру, позволяя отношения «многие ко многим». Модель определялась спецификацией CODASYL.

Сетевая модель организует данные с использованием двух фундаментальных понятий, называемых записями и наборами. Записи содержат поля (которые могут быть организованы иерархически, как в языке программирования COBOL). Наборы (не путать с математическими наборами) определяют отношения «один ко многим» между записями: один владелец, многие члены. Запись может быть владельцем в любом количестве наборов и членом в любом количестве наборов.

Набор состоит из круговых связанных списков, где один тип записи, владелец набора или родительский элемент, появляется один раз в каждом круге, а второй тип записи, подчиненный или дочерний, может появляться несколько раз в каждом круге. Таким образом, между любыми двумя типами записей может быть установлена иерархия, например, тип A является владельцем B. В то же время может быть определен другой набор, где B является владельцем A. Таким образом, все множества содержат общий ориентированный граф (Право собственности определяет направление) или сетевую конструкцию. Доступ к записям является либо последовательным (обычно в каждом типе записи), либо навигацией в круговых связанных списках.

Сетевая модель способна представлять избыточность данных более эффективно, чем в иерархической модели, и может быть более одного пути от узла-предка до потомка. Операции сетевой модели являются навигационными по стилю: программа поддерживает текущую позицию и перемещается из одной записи в другую, следуя отношениям, в которых участвует запись. Записи также можно найти, указав значения ключа. Хотя это не является существенной особенностью модели, сетевые базы данных обычно реализуют установленные отношения с помощью указателей, которые непосредственно адресуют местоположение записи на диске. Это дает отличную производительность поиска за счет таких операций, как загрузка базы данных и реорганизация.

Популярными СУБД, которые его использовали, были IDMS Cincom Systems и Total ID Cullinet. IDMS получила значительную клиентскую базу; В 1980-х годах приняла реляционную модель и SQL в дополнение к своим оригинальным инструментам и языкам.

Схематически сетевая модель данных показана на рисунке.

Основными операциями над данными в сетевой модели являются:

  1. Поиск записи.
  2. Переход с связному элементу.
  3. Создание новой записи.
  4. Удаление текущей записи.
  5. Обновление текущей записи.
  6. Добавление связи элементов.
  7. Удаление связи элементов.

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

К недостаткам можно отнести сложность схемы БД и операций обработки данных. Кроме того из-за допустимости произвольных связей, сложно контролировать их целостность.

Несмотря на то, что сетевые модели появились в 80-х годах прошлого века, а потом были практически полностью вытеснены реляционными, в последние годы активно развиваюся графовые СУБД, в основе которых тоже лежит сетевая модель в виде графа.

Основными элементами графовой модели являются узлы и связи.

В графовых СУБД, как правило, разделяют подсистему хранения и механизм обработки.

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

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

Примерами графовых СУБД выступают: Neo4j, ArangoDB, Memgraph, OrientDB.

Реляционные

Реляционная модель данных предложена сотрудником фирмы IBM Эд­гаром Коддом и основывается на понятии отношение (relation).

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

Таблица имеет строки (записи) и столбцы (колонки). Каждая строка таб­лицы имеет одинаковую структуру и состоит из полей. Строкам таблицы соответствуют кортежи, а столбцам — атрибуты отношения.

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

Достоинство реляционной модели данных заключается в простоте, понят­ности и удобстве физической реализации на ЭВМ. Именно простота и по­нятность для пользователя явились основной причиной их широкого исполь­зования. Проблемы же эффективности обработки данных этого типа оказались технически вполне разрешимыми.

Основными недостатками реляционной модели являются следующие: отсутствие стандартных средств идентификации отдельных записей и слож­ность описания иерархических и сетевых связей.

Примерами реляционных СУБД являются: DB2 (IBM), Access (Microsoft), Firebird, RedDatabase (RED SOFT), MySQL и Oracle (Oracle), PostgreSQL.

Ключ-значение

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

Такая БД хранит и обрабатывает разных по типу и содержанию данные. В одном хранилище под разными ключами могут находиться файлы, строки, текст, числа, JSON-объекты и другие типы данных. Эта модель обеспечивает высокую скорость доступа к данным за счет адресного хранения и легко масштабируется. Можно создать правила шардирования по определенным ключам – например, сессии пользователей разных сайтов хранятся в различных сегментах БД.

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

Примеры СУБД “ключ-значение”: Amazon, DynamoDB, Redis, Riak, LevelDB, различные хранилища кэша – например, Memcached и пр.

Документоориентированные

В отличие от баз типа «Ключ-значение» данные здесь хранятся в структурированных форматах – XML, JSON, BSON. Однако, сохраняется адресный доступ к данным по ключу. При этом содержимое документа может иметь различный набор свойств.

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

Такие СУБД хорошо подходят для быстрой разработки систем и сервисов, работающих с данными, структурированными по разному, легко масштабируются и меняют структуру при необходимости.

Примеры: MongoDB, RethinkDB, CouchDB, DocumentDB.

Распределенные СУБД

СУБД можно классифицировать по степени распределённости:

  1. Локальные СУБД (все части локальной СУБД размещаются на одном компьютере);
  2. Распределённые СУБД (части СУБД могут размещаться на двух и более компьютерах).

Локальные СУБД

Локальная база данных – это база данных, которая полностью располагается на одном компьютере. Это может быть компьютер пользователя или сервер. Соединение с файлом базы данных происходит через спец драйвер или напрямую. Если эта вычислительная система является компонентом компьютерной сети, то возможен доступ к такой базе с других компьютеров, подключенных к сети.

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

Распределённые СУБД

Распределенная база данных может размещаться на нескольких компьютерах (серверах, узлах).

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

Из этого определения следует, что так называемая распределенная база данных в действительности представляет собой виртуальную базу данных, компоненты которой физически хранятся в нескольких различных реальных базах данных на нескольких различных узлах (в сущности, являясь логическим объединением этих реальных баз данных).

Доступ к СУБД

По способу доступа различают следующий виды СУБД:

  1. Файл-серверные.
  2. Клиент-серверные.
  3. Встраиваемые.

Файл-серверные

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

Преимуществом этой архитектуры является низкая нагрузка на процессор файлового сервера.

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

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

Примеры: Microsoft Access, Paradox, dBase, FoxPro, Visual FoxPro.

Клиент-серверные

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

Недостаток клиент-серверных СУБД состоит в повышенных требованиях к серверу.

Достоинства: потенциально более низкая загрузка локальной сети; удобство централизованного управления; удобство обеспечения таких важных характеристик, как высокая надёжность, высокая доступность и высокая безопасность.

Примеры: Oracle, Firebird, RedDatabase, IBM DB2, MS SQL Server,PostgreSQL, MySQL.

Встраиваемые

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

Достоинствами является отсутствие накладных расходов на сетевое взаимодействие, простота распространения прикладных программ.

Примеры: Firebird, RedDatabase, SQLite.

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

  1. Что такое СУБД?
  2. Какие основные функции СУБД?
  3. Чем определяется модель данных?
  4. Особенности иерархической модели данных?
  5. Основные операции в иерархических БД?
  6. Особенности сетевой модели данных?
  7. Основные операции в сетевых БД?
  8. Особенности графовых СУБД?
  9. В каком виде хранятся данные в реляционных СУБД?
  10. Преимущества баз данных “Ключ-значение”?
  11. Чем отличаются документоориентированные БД от БД “Ключ-значение”?
  12. Различия локальных и распределенных СУБД?
  13. Недостатки файл-серверных СУБД?
  14. Преимущества клиент-серверных СУБД?
  15. Особенности встраиваемых СУБД?