Перейти к содержанию

Обзорная лекция#

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

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

  • разнообразные численные методы решения задач;
  • специализированные алгоритмические языки (например, Fortran).

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

  • поддержка надежного сохранения информации;
  • выполнение специфических преобразований информации для заданного приложения (программы);
  • удобный и легкоусвояемый интерфейс пользователя;
  • выполнение специфических (иногда несложных) вычислений для заданного приложения.

Развитие этого направления привело к тому, что в конце 60-х, в начале 70-х годов появилось специализированное программное обеспечение, которое получило название Система управления базами данных (DataBase Management System – DBMS).

Какое назначение систем управления базами данных (СУБД)? Что такое база данных?#

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

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

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

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

Модель данных, на которой основана база данных, определяет ее структуру и способы доступа к данным. Например, реляционные базы данных организованы в виде таблиц, где данные хранятся в строках и столбцах, обеспечивая легкий доступ и обработку. Однако есть и другие модели, такие как объектно-ориентированные базы данных или NoSQL-системы, каждая из которых имеет свои особенности и применения.

СУБД позволяют:

  • систематизировать данные в базе данных;
  • организовывать данные для их сохранения на компьютерах.

История развития баз данных#

https://ratcatcher.ru/media/expr/lec/lec1/SQL-History.png

  • 1955: Появление программного оборудования для обработки записей. Программное обеспечение этого времени поддерживало модель обработки записей на основе файлов. Для хранения данных использовались перфокарты.

  • 1956: Компания IBM представила дисководы жестких магнитных дисков для хранения данных, что стало новым способом хранения информации.

  • 1959: В сообществе баз данных "COBOL" была проработана концепция схем баз данных и концепция независимости данных.

  • 1961-1963: Integrated Data Store (IDS), первая система управления базами данных, начало сетевой и навигационной моделей данных, разработанная Чарльзом Бахманом.

  • 1964: На симпозиумах, организованных компанией SDC, введен термин "база данных".

  • 1970: Эдгар Ф. Кодд опубликовал работу по реляционной модели данных, что считается первой работой по этой модели.

  • 1971: CODASYL Data Model, стандарт сетевой модели данных, был разработан организацией CODASYL.

  • 1973: System R компании IBM стала первой системой управления реляционными базами данных. Чарльз Бахман получил Тьюринговскую премию за руководство работой Data Base Task Group (DBTG), разработавшей стандартный язык описания данных и манипулирования данными.

  • 1976: Питер Чен предложил модель "Сущность-связь" (ERD, ERM) - графическую модель данных.

  • 1979: Первая СУБД, поддерживающая язык SQL - Oracle V2 для машин VAX от компании Relational Software Inc.

  • 1981: Эдгар Ф. Кодд получил премию Тьюринга за свой вклад в теорию и практику.

  • 1986: ANSI принял первый стандарт языка SQL.

  • 1997: Стандарт объектных баз данных ODMG 2.0 был представлен.

  • 2002: Журнал Forbes поместил реляционную модель данных в список важнейших инноваций последних 85 лет.

Классификация БД#

Классификация моделей данных включает различные подходы к организации и хранению информации.

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

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

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

Базы данных с иерархической моделью одни из самых старых, и стали первыми системами управления базами данных для мейнфреймов. Разрабатывались в 1950-х и 1960-х, например, Information Management System (IMS) фирмы IBM.

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

  1. Поле данных (атрибут) - минимальная неделимая, уникально адресуемая единица хранения данных

  2. Сегмент данных (запись/record/экземпляр данных) - совокупность полей данных, имеющая уникальную идентификацию (сущность в модели ER).

  3. Экземпляр сегмента — конкретные значения полей

  4. Дерево — совокупность сегментов, связанных с помощью связи родитель-потомок

https://ratcatcher.ru/media/expr/lec/lec1/schema1.png

Проблемы:

  • Требуется много памяти для хранения (производительность)
  • Сложно контролировать целостность данных
  • Дублирование данных
  • Скорость операций записи
  • Огромные трудности при реорганизации структуры (иерархии)
  • Невозможна связь Many-to-many

Сетевая модель#

Можно ссылаться много раз на один и тот же объект
Разделяем хранение связей от хранения данных
Агрегаты — так называют сегменты

https://ratcatcher.ru/media/expr/lec/lec1/загруженное.jpg

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

  1. Сегменты

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

  1. Записи

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

  1. Сети

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

  1. Владение

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

  1. Связи

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

Плюсы:

  • Обеспечивает атрибутивную целостность

Проблемы:

  • Храним сущности и связи отдельно
  • Появилась проблема ссылочной целостности

Графовые модели данных#

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

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

Amazon Neptune — публично-облачная графовая СУБД в составе Amazon Web Services. Поддерживает графовые модели RDF и LPG и, соответственно, языки запросов SPARQL и Gremlin.
Выпущена в тестовом режиме 29 ноября 2017 года, в коммерческую эксплуатацию введена 30 мая 2018 года.

https://ratcatcher.ru/media/expr/lec/lec1/schema5.png

Графовые базы уже нашли применение в:

  • Социальных сетях
  • Системах рекомендаций (с этим товаром часто покупают…)
  • Обработка пользовательских данных, корреляция данных из разных источников (информационный след в сети)

Если в вашем приложении планируется много сущностей и связей многие-ко-многим, то это один из признаков, что предпочтительней выбрать графовую СУБД (утверждение Martin Kleppmann’а в книге “Designing Data Intensive Applications”).

А если у вас уже есть приложение с множеством связей, и обход этих связей занимает много времени и ресурсов — стоит присмотреться в сторону графов, т.к. обход связей в них практически ничего не стоит.

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

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

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

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

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

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

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

https://ratcatcher.ru/media/expr/lec/lec1/schema2.png

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

Преимущества объектно-ориентированных моделей данных:
- Удобство в представлении: Они позволяют описывать данные в виде объектов, что естественно для представления реальных объектов и их взаимодействий.
- Повторное использование: Классы и объекты могут быть повторно использованы в различных частях программы или даже в разных проектах, что упрощает разработку.
- Модульность: Объекты и классы могут быть организованы в модули, что способствует более четкой и удобной структуре программы.
- Инкапсуляция: Данные объекта скрыты от прямого доступа извне и могут быть изменены только с помощью методов объекта, обеспечивая защиту данных и контроль над доступом.
- Наследование: Возможность создания новых классов на основе существующих с добавлением или изменением функциональности позволяет повторно использовать код и уменьшает дублирование.

Недостатки объектно-ориентированных моделей данных:
- Сложность: Некоторые концепции ООП (объектно-ориентированного программирования) могут быть сложными для понимания, особенно для начинающих разработчиков.
- Производительность: Объектно-ориентированные модели могут потреблять больше ресурсов (памяти и процессорного времени) из-за дополнительных слоев абстракции.
- Иерархии классов: Плохо спроектированные иерархии классов могут привести к сложностям и избыточности, усложняя поддержку и модификацию кода.
- Инкапсуляция может быть нарушена: Некоторые языки программирования позволяют обойти ограничения инкапсуляции, что может привести к проблемам с безопасностью данных.
- Накладные расходы на управление объектами: Управление жизненным циклом объектов может привести к дополнительным затратам ресурсов.

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

Документ-ориентированная модель специально предназначенная для хранения иерархических структур данных – документов. Документ – набор атрибутов (ключ и соответствующее ему значение. Документ может быть вложен в документ
- Представление данных – JSON или XML формат.
- Документ-ориентированные базы данных применяются в системах управления содержимым, издательском деле, документальном поиске и т.п.

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

Примеры СУБД: CouchDB, Couchbase, MarkLogic, MongoDB, eXist, Berkeley DB

https://ratcatcher.ru/media/expr/lec/lec1/table3.png

Реляционные модели данных#

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

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

https://ratcatcher.ru/media/expr/lec/lec1/table1.png

Примеры: MySQL, Oracle DB.

Таблица сравнения основных моделей#

Таблица сравнения объектно-ориентированной модели данных

Аспект Объектно-ориентированная модель данных Реляционная модель данных Иерархическая модель данных
Определение Модель данных, основанная на концепции объектов, их свойств и взаимодействий Модель данных, основанная на таблицах, связанных ключами Модель данных, основанная на иерархической структуре данных
Принципы Инкапсуляция, наследование, полиморфизм Нормализация, целостность данных, операции JOIN Структура дерева, родительские и дочерние элементы
Основные понятия Классы, объекты, свойства, методы Таблицы, столбцы, строки, ключи Узлы, родительские и дочерние элементы, связи
Преимущества Гибкость, повторное использование кода, модульность Простота использования, эффективность запросов Поддержка иерархической структуры данных, быстрый доступ к связанным элементам
Примеры использования Разработка приложений, моделирование реального мира Управление данными, хранение информации Системы управления базами данных, файловые системы

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

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

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

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

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

https://ratcatcher.ru/media/expr/lec/lec1/Безымянны211й.png

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

Отношением называется вся структура в целом. Каждая строка, содержащая данные,
является кортежем. Строго говоря, каждая строка является n-кортежем. Число кортежей в
отношении определяет мощность отношения. В примере мощность отношения равна 11.

Каждый столбец отношения называется атрибутом . Число атрибутов в отношении определяет
размерность этого отношения, в примере она равняется трем.
Каждое отношение можно разделить на две части — заголовок и тело.

Телоотношения состоит из кортежей, в то время как заголовок не имеет более мелких
компонентов структуры. Название каждого из атрибутов состоит из двух терминов,
разделенных двоеточием (например, UnitPrice:Currency). Первая часть названия —
непосредственно имя атрибута, вторая — имя домена. Домен атрибута — это вид данных,
которые представляет данный атрибут (в приведенном примере — валюта).

Понятие домен не эквивалентно понятию ≪тип данных≫.
Тело отношения состоит из неупорядоченного набора кортежей (число кортежей
может быть любым, от 0 и более).

Во-первых, отношение не упорядочено. Понятие ≪номер строки≫ не применимо к отношению. Для отношений не существует никакого внутреннего
порядка.

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

Такая таблица обладает рядом свойств:

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

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

  • Заголовок Hr (или схема) отношения r — конечное множество упорядоченных пар вида , где A называется именем атрибута, а T обозначает имя некоторого базового типа или ранее определенного домена, то есть множества допустимых значений. По определению требуется, чтобы все имена атрибутов в заголовке отношения были различны.
  • Кортеж tr, соответствующий заголовку Hr — множество упорядоченных триплетов вида , по одному такому триплету для каждого атрибута в Hr. Третий элемент – v – триплета должен являться допустимым значением типа данных или домена T. Замечание: так как имена атрибутов уникальны, то указание домена в кортеже излишне.
  • Тело Br отношения — неупорядоченное множество различных кортежей tr.
  • Значением Vr отношения r называется пара множеств Hr и Br.
    Полезно также понятие первичного ключа — это такой набор атрибутов, который однозначно определяет кортеж и минимален среди всех своих подмножеств (то есть нельзя убрать ни один из атрибутов). При добавлении новых записей первичный ключ обязан оставаться первичным ключом (например, неверным будет использование в качестве первичного ключа набора Имя + Отчество + Фамилия сотрудника, даже если на момент создания таблицы полных тёзок среди заносимых в неё людей не было).

Домен#

Домен определяет ≪вид≫данных, которые представляет данный атрибут. Если дать
более четкое определение, то домен — это набор всех допустимых значений, которые может
содержать данный атрибут.

Понятие ≪домен≫ часто путают с понятием ≪тип данных≫. Необходимо четко
различать эти два понятия. Тип данных — это физическая концепция, а домен — логическая.
Например, ≪целое число≫— это тип данных, а ≪возраст≫— это домен.

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

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

Самые популярные СУБД#

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

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

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

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

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

https://ratcatcher.ru/media/expr/lec/lec1/rating.jpg

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

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