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

Модели и БД

Последнее обновление: 31.10.2015

Все сущности в приложении принято выделять в отдельные модели. В зависимости от поставленной задачи и сложности приложения
можно выделить различное количество моделей. Так, в тестовом приложении из второй главы использовались две модели — класс для
книги и класс для покупки книги.

Модели представляют собой простые классы и располагаются в проекте в каталоге Models. Модели описывают логику данных.
Например, модель представляющая книгу и ее покупку:

public class Book
{
    // ID книги
    public int Id { get; set; }
    // название книги
    public string Name { get; set; }
    // автор книги
    public string Author { get; set; }
    // цена
    public int Price { get; set; }
}
public class Purchase
{
    // ID покупки
    public int PurchaseId { get; set; }
    // имя и фамилия покупателя
    public string Person { get; set; }
    // адрес покупателя
    public string Address { get; set; }
    // ID книги
    public int BookId { get; set; }
    // дата покупки
    public DateTime Date { get; set; }
}

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

Данные моделей хранятся в базе данных. Чтобы взаимодействовать с базой данных, очень удобно пользоваться фреймворком Entity Framework.
Entity Framework поддерживает подход «Code first», который предполагает сохранение или извлечение информации из БД на SQL Server без создания схемы
базы данных или использования дизайнера в Visual Studo. Наоборот, мы создаем обычные классы, а Entity Framework уже сам определяет, как и где
сохранять объекты этих классов.

Выпуск ASP.NET MVC 4 уже включает Entity Framework 5.0, однако в проектах по типу Empty вам придется подключать фреймворк через пакетный менеджер NuGet.

Чтобы подключиться к базе данных через Entity Framework, нам нужен контекст данных. Контекст данных представляет собой класс, производный от
класса DbContext. Контекст данных содержит одно или несколько свойств типа DbSet<T>, где T представляет тип объекта, хранящегося в базе
данных. Допустим, создадим контекст данных для работы с вышеприведенными моделями Book и Purchase:

using System;
using System.Collections.Generic;
using System.Web;
using System.Data.Entity;

namespace BookStore.Models
{
    public class BookContext : DbContext
    {
        public DbSet<Book> Books { get; set; }
        public DbSet<Purchase> Purchases { get; set; }
    }
}

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

НазадВперед

Требования к проектированию БД

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

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

Возможны и другие требования, причём нередко они противоречат друг другу

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

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

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

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

Целостность данных в реляционной модели данных

Понятия реляционной целостности:

  • определитель NULL;
  • целостность сущностей;
  • ссылочная целостность;
  • корпоративные ограничения целостности.

Определитель NULL. Значение Null обозначает тот факт, что значение не определено.
Null не принадлежит никакому типу данных и может присутствовать среди значений любого атрибута,
определенного на любом типе данных. Двуместная «арифметическая» операция с Null даёт Null. Операция
сравнения с Null даёт UNKNOWN.

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

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

Ссылочная целостность: удаление кортежа. Существует три подхода удаления кортежа
из отношения, на которое ведет ссылка.

  1. Ограничение удаления–Delete: Restrict.
  2. Каскадное удаление–Delete: Cascade.
  3. Установка значения NULL, перевод значения внешнего ключа в неопределённое состояние – Delete:
    Set NULL.

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

Каскадное удаление. При удалении кортежа из отношения, на которое ведет ссылка,
из ссылающегося отношения автоматически удаляются все ссылающиеся кортежи.

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

Пример 3. Есть база данных портала новостей. В ней есть таблица
«Рубрики» (политика, экономика, спорт и т.д), есть таблица «Автора» (фамилии и имена авторов). Есть
таблица «Тексты», в которой в каждой записи о тексте новости есть поля «Рубрика» (с идентификаторами
рубрик из соответствующей таблицы) и «Автор» (с идентификаторами рубрик из соответствующей таблицы).
Какими способами можно добиться, чтобы при удалении рубрики и автора была соблюдена ссылочная целостоность
данных?

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

Как это делается на уровне языка запросов SQL — в материале
SQL ALTER TABLE — изменение таблицы базы данных.

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

Поделиться с друзьями

Реляционные базы данных и язык SQL

Виды моделей данных

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

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

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

  • иерархическая;
  • сетевая;
  • реляционная.

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

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

Основные понятия иерархической структуры

Это – узел, уровень и связь.

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

Иерархическое дерево имеет только одну вершину (корень дерева), не подчиненную никакой другой вершине и находящуюся на самом верхнем (первом) уровне. Зависимые (подчиненные) узлы находятся на втором, третьем и т.д. уровнях. К каждой записи базы данных существует только один (иерархический) путь от корневой записи. Например, как видно из рисунке, для записи С4 путь проходит через записи ВЗ к А.

Пример иерархической структуры:

Сетевая модель данных

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

На рисунке изображена сетевая структура базы данных в виде графа.

Пример сетевой структуры:

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

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

Понятие реляционный (англ. relation – отношение) связано с разработками известного американского специалиста в области систем баз данных Е.Кодда.

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

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

Отношение – это плоская таблица, содержащая N столбцов, среди которых нет одинаковых. N – это степень отношения, или арность отношения. Столбец отношения соответствует атрибуту сущности. Кортеж – строка отношения (соответствует записи в таблице).

Пример реляционной модели

№ личного дела Фамилия Имя Отчество Дата рождения Группа
16493 Сергеев Петр Михайлович 01.01.90 112
16593 Петрова Анна Владимировна 15.03.89 111
16693 Антохин Андрей Борисович 14.04.90 112

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

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

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

Как нарисовать ER-диаграмму-советы

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

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

WebOnTo.ru

Гибридная система Cassandra

Одна из наиболее широко используемых БД NoSQL — Cassandra, разработанная Facebook. Целью Cassandra было создание СУБД, которая не имеет единой точки отказа и обеспечивает максимальную доступность. Cassandra — это, главным образом, БД хранилища столбцов. В некоторых исследованиях она упоминалась как гибридная система, основанная на Google BigTable, которой является БД хранилища столбцов и Amazon DynamoDB, присущая типу «ключ-значение». Ключи в Cassandra указывают на набор семейств столбцов с опорой на распределенную файловую систему Google BigTable и функции доступности Dynamo (распределенная хеш-таблица).

Основные характеристики Cassandra включают в себя:

  1. Отсутствие единой точки отказа. Для этого она должна работать на кластере узлов, а не на одной машине. Это не означает, что данные на каждом кластере одинаковы. Когда происходит сбой в одном из узлов, данные на нем будут недоступны. Однако другие узлы и данные по-прежнему будут доступны.
  2. Распределенное хеширование — это схема, которая обеспечивает функциональность хэш-таблицы таким образом, что добавление или удаление одного слота не приводит к значительному изменению отображения ключей на слоты. Это позволяет распределять нагрузку на серверы или узлы в соответствии с их емкостью и минимизировать время простоя.
  3. Относительно простой в использовании клиентский интерфейс. Она использует Apache Thrift для своего клиентского интерфейса, который предоставляет RPC-клиент на нескольких языках, но большинство разработчиков предпочитают альтернативы с открытым исходным кодом, созданные на основе Apple Thrift, например, Hector.
  4. Репликация данных. По сути, он отражает данные для других узлов в кластере. Репликация может быть случайной или определенной для максимальной защиты данных, например, путем размещения в узле другого центра обработки данных.
  5. Политика разделения решает, где и на каком узле разместить ключ. Это может быть случайным или упорядоченным процессом. При использовании обоих типов политик разделения Cassandra может найти баланс между нагрузкой и оптимизацией производительности запросов.
  6. Согласованность. Репликация усложняет согласованность. Это связано с тем, что все узлы должны быть обновлены в любой момент времени с самыми последними значениями или во время запуска операции чтения.
  7. Чтение/запись действий. Клиент отправляет запрос одному узлу. Узел, согласно политики репликации, сохраняет данные в кластере. Каждый узел сначала изменяет данные в журнале фиксации и обновляет структуру таблицы, причем оба изменения выполняются синхронно. Запрос на чтение отправляется одному единственному узлу, который содержит данные в соответствии с политикой разделения/размещения.

Понятие БД и классификация БД

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

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

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

В зависимости от изменчивости базы данных ее тип относят по классификации БД к статическому или динамическому.

Функции статических БД:

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

Функции динамических БД:

  1. Они обладают понятием самоуправления.
  2. Могут быть связаны с динамическими сетями.
  3. Эта структурная ассоциация позволяет хранить и обновлять информацию базы данных.
  4. Использует HTML в качестве языка связи между сетью и динамической БД.
  5. Наиболее используемые языки для создания динамических сетей, связанных с BBDD: Perl, CGI, PHP, JSP и ASP.

Основными СУБД, которые работают с динамическими веб-страницами, являются PostgresQL, MySQL, Oracle и Microsoft SQL.

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

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

Функциональные возможности библиографических БД:

  1. Связаны со старыми записями, которые содержат информацию о местонахождении книги или документа.
  2. Не содержат полный текст, только ссылку.
  3. Благодаря таким форматам, как PDF, позволяет получать доступ к оригинальным статьям, на которые есть ссылки.
  4. С развитием технологий включаются ссылки из других СМИ.

Особенности специализированных БД:

  1. Содержат точную информацию и ориентированы на конкретную тему.
  2. Используются в академической и научной среде.
  3. Для некоторых случаев не рассматриваются как правильные BBDD: например, телефонный справочник, список контактов компании или международной компании.

Области применения

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

Области применения СУБД:

  1. Банковское дело — для информации о клиентах, счетов и займов, а также банковских операций.
  2. Авиакомпании — для бронирования и информации о расписании. Авиакомпании были одними из первых, кто использовал базы данных в географически распределенном порядке: терминалы, расположенные по всему миру, обращались к центральной системе баз данных через телефонные линии и другие сети передачи данных.
  3. Университеты — для информации о студентах, регистрации курсов и оценок.
  4. Операции с кредитными картами — для покупок по кредитным картам и формирования ежемесячных выписок.
  5. Телекоммуникации — для ведения записей о совершенных вызовах, составления ежемесячных счетов, поддержания баланса на телефонных карточках с предоплатой и хранения информации о сетях связи.
  6. Финансы — для хранения информации о запасах, продажах и покупках финансовых инструментов, таких, как акции и облигации.
  7. Продажи — информация о клиенте, продукте и покупке.
  8. Производство — для управления цепочкой поставок и для отслеживания производства товаров на фабриках, запасов товаров на складах, в магазинах и заказов на товары.
  9. Человеческие ресурсы — для получения информации о сотрудниках, заработной плате, налогах на заработную плату и льготах, а также для получения зарплат.

Как хранится информация в БД

В основе всей структуры хранения лежат три понятия:

  • База данных;
  • Таблица;
  • Запись.

База данных

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

Таблица

По отношению к базе данных таблица является вложенным объеком. То есть одна БД может содержать в себе множество таблиц.
Аналогией из реального мира может быть шкаф (база данных) внутри которого лежит множество коробок (таблиц).
Таблицы нужны для хранения данных одного типа, например, списка городов, пользователей сайта, или библиотечного каталога.
Таблицу можно представить как обычный лист в Excel-таблице, то есть совокупность строк и столбцов.
Наверняка каждый хоть раз имел дело с электронными таблицами (MS Excel).
Заполняя такую таблицу, пользователь определяет столбцы, у каждого из которых есть заголовок. В строках хранится информация.
В БД точно также: создавая новую таблицу, необходимо описать, из каких столбцов она состоит, и дать им имена.

Запись

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

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

  1. Создадим для сайта новую БД и дадим ей название «weather_diary».
  2. Создадим в БД новую таблицу с именем «weather_log» и определим там следующие столбцы:
    • Город (тип: текст);
    • День (тип: дата);
    • Температура (тип: число);
    • Облачность (тип: число; от 0 (нет облачности) до 4 (полная облачность));
    • Были ли осадки (тип: истина или ложь);
    • Комментарий (тип: текст).
  3. При сохранении формы будем добавлять в таблицу weather_log новую запись, и заполнять в ней все поля информацией из полей формы.

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

Реляционная база данных

Английское слово „relation“ можно перевести как связь, отношение.
А определение «реляционные базы данных» означает, что таблицы в этой БД могут вступать в отношения и находиться в связи между собой.
Что это за связи?
Например, одна таблица может ссылаться на другую таблицу. Это часто требуется, чтобы сократить объём и избежать дублирования информации.
В сценарии с дневником погоды пользователь вводит название своего города. Это название сохраняется вместе с погодными данными.
Но можно поступить иначе:

  1. Создать новую таблицу с именем „cities“.
  2. Все города в России известны, поэтому их все можно добавить в одну таблицу.
  3. Переделать форму, изменив поле ввода города с текстового на поле типа «select», чтобы пользователь не вписывал город, а выбирал его из списка.
  4. При сохранении погодной записи, в поле для города поставить ссылку на соответствующую запись из таблицы городов.

Так мы решим сразу две задачи:

  • Сократим объём хранимой информации, так как погодные записи больше не будут содержать название города;
  • Избежим дублирования: все пользователи будут выбирать один из заранее определённых городов, что исключит опечатки.

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

Отношения и их реализация в реляционной модели данных

Отношение на множестве доменов
— это подмножество декартова произведения этих доменов:

Пример 1. Определены домены: —
множество фамилий преподавателей, —
множество аудиторий, —
множество учебных групп, —
множество учебных дисциплин. Записать отношения: 1) закрепление преподавателей за учебными курсами;
2) расписание занятий в группах.

Решение.

1) закрепление преподавателей за учебными курсами:

.

Это отношение определяет множество преподавателей, ведущих множество учебных дисциплин.

2) расписание занятий в группах:

.

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

Свойства отношений:

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

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

Виды отношений:

  • именованное отношение;
  • базовое отношение;
  • производное отношение;
  • выражаемое отношение;
  • представление (view);
  • снимки (snapshot);
  • результат запроса;
  • промежуточный результат.

Именованное отношение — это переменная отношения, определённая в СУБД (системе управления
базами данных) посредством оператора CREATE (CREATE TABLE, CREATE BASE RELATION, CREATE
VIEW, CREATE SNAPSHOT).

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

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

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

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

Снимки (snapshot) — это то же, что и представление, но с физическим сохранением
и с периодическим обновлением.

Результат запроса — это неименованное производное отношение. СУБД не обеспечивает
постоянного существования результатов запросов. Для сохранения результата запроса его можно присвоить
какому-либо именованному отношению.

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

Концептуальная модель базы данных

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

Делая поставку, поставщик подтверждает её документами. Аналогично и с покупателем. Таким образом, и поставку, и покупку можно рассматривать в качестве самостоятельных объектов.

Итого 5 объектов и 4 связи. Из них:
— 2 связи типа «один ко многим» (один поставщик может делать несколько поставок; один покупатель может делать несколько покупок);
— 2 связи типа «многие ко многим» (каждая поставка может включать несколько товаров, причём одинаковый товар может быть в нескольких поставках; аналогичная ситуация по линии «Покупка — Товар»).

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

Видим, что в структуре появились ещё 2 объекта — «Журнал поставок» и «Журнал покупок» со связями типа «один ко многим» (каждый журнал может включать несколько поставок/покупок, но каждая поставка/покупка включает лишь один журнал).

Мультимодельность

Термин «многовариантное хранение» вошел в обиход в 2011 году. Осознание проблем подхода и поиск решения заняли несколько лет, и к 2015 году устами аналитиков Gartner ответ был сформулирован:

  • Из «Market Guide for NoSQL DBMSs — 2015»:
  • Из «Magic Quadrant for ODBMS — 2016»:

Похоже, что в этот раз аналитики Gartner с прогнозом не ошиблись. Если зайти на страницу с основным рейтингом СУБД на DB-Engines, можно увидеть, что большая часть его лидеров позиционирует себя именно как мультимодельные СУБД. То же можно увидеть и на странице с любым частным рейтингом.

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

СУБД Изначальная модель Дополнительные модели
Oracle Реляционная Графовая, документная
MS SQL Реляционная Графовая, документная
PostgreSQL Реляционная Графовая*, документная
MarkLogic Документная Графовая, реляционная
MongoDB Документная Ключ-значение, графовая*
DataStax Wide-column Документная, графовая
Redis Ключ-значение Документная, графовая*
ArangoDB Графовая, документная
OrientDB Графовая, документная
Azure CosmosDB Графовая, документная, реляционная

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

Концептуальная модель базы данных: принятые графические обозначения

Диаграмма сущность/отношения (объект/связь) называют ER-диаграммой или EDR (entity-relationship diagram). Сама модель сущность-связь была предложена профессором Peter Pin-Shen Chen (Питер Чен) в 1976 году. Правила написания и условные обозначения  ER-диаграммы называют нотацией. Распространены две основные нотации ER-диаграмм:

  • Нотация Питера Чена;
  • Нотация  Gordon Everest (Гордона Эверста). Под назаванием Crow’s Foot  или Fork (вилка).

Обозначения ER-диаграммы по Питеру Чену

Чен предложил и это приняли следующие условные обозначения для ER-диаграмм:

  • Сущность или объект обозначать прямоугольником;
  • Отношения обозначать ромбом;
  • Атрибуты объектов, обозначаются овалом;
  • Если сущность связана с отношением, то их связь обозначается прямой линией со стрелкой. Необязательная связь обозначается пунктирной линией. Мощная связь обозначается двойной линией.

Каждый атрибут может быть связан с одним объектом (сущностью).

Нотация  Gordon Everest

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

Атрибуты не выделяются в отдельную фигуру, а вписываются в прямоугольник объекта именем существительным с уточняющим словом.

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

концептуальная модель базы данных ERD Fork

Основные понятия используемые в сетевой модели данных

Элемент данных – минимальная информационная единица доступная пользователю.

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

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

Тип записей – это совокупность логически связанных экземпляров записей. Тип записей представляет некоторый класс реального мира.

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

Особенности сетевой модели данных

  • Связи в сетевой модели данных осуществляются наборами, которые реализуются с помощью указателей. Сетевая модель данных являются особым витком в развитии иерархической модели данных, их основным отличием является то, что в сетевых моделях данных имеются указатели в обоих направлениях, которые соединяют родственную информацию.
  • Сетевая модель данных предпологает наличие в ней произвольного количества записей и наборов в том числе их различных типов.
  • Связь между двумя записями может выражаться произвольным количеством наборов.
  • В любом наборе может быть только один владелец.
  • Тип записи может быть владельцем в одних типах наборов и членом в других типах наборов, а также не входить ни в какой тип наборов.
  • Допускается добавление новой записи в качестве экземпляра владельца, если экземпляр-член отсутствует.
  • При удалении записи-владельца удаляются соответствующие указатели на экземпляры-члены, но сами записи-члены не уничтожаются (сингулярный набор).
Оцените статью
Рейтинг автора
5
Материал подготовил
Илья Коршунов
Наш эксперт
Написано статей
134
Добавить комментарий