Создание логической модели

Введение

«Нужно бежать со всех ног, чтобы только оставаться на месте, а чтобы куда-то попасть, надо бежать как минимум вдвое быстрее!» (с) Алиса в стране чудес

Недавно, «от нечего делать», я задался вопросом (длинные майские выходные в режиме карантина к этому особенно располагают), насколько теоретические выкладки будут соответствовать практике? Собственно, так и родилась идея этой статьи. Разработчик, который не первый день работает с NoSQL, возможно и не почерпнет из нее что-то новое (и поэтому может сразу промотать полстатьи). Но для аналитиков, которые еще не работали плотно с NoSQL, полагаю, она будет полезна для получения базовых представлений об особенностях проектирования моделей данных для HBase.


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

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

Содержание отчета

  1. Тема, цель работы.
  2. ERD-диаграмма БД Служба занятости с атрибутами и ключами.
  3. Выводы по работе

Структурные элементы базы данных

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

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

имя, например. Фамилия, Имя, Отчество, Дата рождения;

тип, например, символьный, числовой, календарный;

длина, например, 15 байт, причем будет определяться максимально возможным ко­личеством символов;

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

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

Файл (таблица) — совокупность экземпляров записей одной структуры.

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

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

Концептуальная модель предметной области

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

     На рис. 7 приведен фрагмент концептуальной модели предметной области «Предприятие».

Рисунок 7 — Концептуальная модель ИС «Предприятие»     

     Из наиболее известных методик исследования предметных областей и построения концептуальных моделей можно назвать системный анализ. Также существует целый ряд методик, учитывающих принципы системного анализа, — методика структурного анализа SADT и основанная на нем IDEF0, диаграммы потоков данных Гейна-Сарсона, методика объектно-ориентированного анализа UML, и др. Концептуальная модель предметной области описывает скорее процессы, происходящие в предметной области и данные, используемые этими процессами. От того, насколько правильно смоделирована предметная область, зависит успех дальнейшей разработки приложений.

     Модель данных — инструментарий для отображения предметной области, определяется:

     — допустимой организацией данных;

     — ограничениями целостности (семантикой);

     — множеством операций, допустимых над объектами модели данных.

Мультимодельные СУБД «без основной модели»

На рынке также представлены СУБД, позиционирующие себя как изначально мультимодельные, не имеющие никакой унаследованной основной модели. К их числу относятся ArangoDB, OrientDB (c 2018 года компания-разработчик принадлежит SAP) и CosmosDB (сервис в составе облачной платформы Microsoft Azure).

На самом деле «основные» модели в ArangoDB и OrientDB есть. Это в том и в другом случае собственные модели данных, являющиеся обобщениями документной. Обобщения заключаются в основном в облегчении возможности производить запросы графового и реляционного характера.

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

Про ArangoDB и OrientDB на Хабре уже была замечательная статья: JOIN в NoSQL базах данных.

ArangoDB

ArangoDB заявляет поддержку графовой модели данных.

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

OrientDB

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

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

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

Azure CosmosDB

В меньшей степени сказанное выше об ArangoDB и OrientDB относится к Azure CosmosDB. CosmosDB предоставляет следующие API доступа к данным: SQL, MongoDB, Gremlin и Cassandra.

SQL API и MongoDB API используются для доступа к данным в документной модели. Gremlin API и Cassandra API — для доступа к данным соответственно в графовой и колоночной. Данные во всех моделях сохраняются в формате внутренней модели CosmosDB: ARS («atom-record-sequence»), которая также близка к документной.

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

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

Логическая модель данных

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

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

     Можно выделить три основные виде логических моделей:

     — иерархическую модель;


     — сетевую модель;     

     — реляционную модель.

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

Рисунок 8 — Пример логической модели данных

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

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

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

Эпилог

Проведенные грубые эксперименты не следует воспринимать как абсолютную истину. Есть множество факторов, которые не были учтены и вносили искажения в результаты (особенно хорошо эти флуктуации видны на графиках при небольшом размере сети). Например, скорость работы thrift, который используется happybase, объем и способ реализации логики, которая у меня была написана на Python (не берусь утверждать, что код был написан оптимально и эффективно использовал возможности всех компонент), возможно особенности кэширования HBase, фоновая активность Windows 10 на моем ноутбуке и т.п. В целом можно считать, что все теоретические выкладки экспериментально показали свою состоятельность. Ну или как минимум опровергнуть их таким вот «наскоком в лоб» не получилось.

В заключении — рекомендации всем, кто только начинает проектировать модели данных в HBase: абстрагируйтесь от предыдущего опыта работы с реляционными базами и помните «заповеди»:

  • Проектируя, идем от задачи и шаблонов манипуляции с данными, а не от модели предметной области
  • Эффективный доступ (без full table scan) – только по ключу
  • Денормализация
  • Разные строки могу содержать разные колонки
  • Динамический состав колонок

Пример

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

Таблица 6.1. Атрибуты сущности «Студент»

Атрибут Описание
Номер Уникальный номер для идентификации пользователя
Ф.И.О. Фамилия, имя и отчество пользователя
Пароль Пароль для доступа в систему
Возраст Возраст студента
Пол Пол студента
Характеристика Memo-поле с общей характеристикой пользователя
E-mail Адреса электронной почты
Телефон Номера телефонов студента (домашний, рабочий)
Опыт работы Специальности и опыт работы студента по каждой из них
Специальность Специальность, получаемая студентом при окончании учебного заведения
Специализация Направление специальности, по которому обучается студент
Иностранный язык Список иностранных языков и уровень владения ими
Тестирование Список тестов и отметки о их прохождении
Экспертная оценка Список предметов с экспертными оценками по каждому из них
Оценки по экзаменам Список сданных предметов с оценками

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

Таблица 6.2. Атрибуты сущности «Опыт работы»

Атрибут

Описание

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

Таблица 6.3. Атрибуты сущности «Иностранный язык»

Атрибут Описание
Язык Название иностранного языка, которым владеет студент
Уровень владения Численная оценка уровня владения иностранным языком

Таблица 6.4. Атрибуты сущности «Тестирование»

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

Таблица 6.5. Атрибуты сущности «Экспертная оценка»

Атрибут Описание
Дисциплина Наименование дисциплины, по которой оценивался студент
Ф.И.О. преподавателя Ф.И.О. преподавателя, который оценивал студента
Оценка Экспертная оценку преподавателя
Атрибут Описание
Предмет Название предмета, экзамен по которому сдавался
Оценка Полученная оценка

Составим ERD-диаграмму, определяя типы атрибутов и проставляя связи между сущностями (рис. 6.4). Все сущности будут зависимыми от сущности «Студент». Связи будут типа «один-ко-многим».

Рис. 6.4. ERD-диаграмма БД студентов

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

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

Таблица 6.7. Типы атрибутов

Атрибут Тип

Номер

Number

Ф.И.О.

String


Пароль

String

Возраст

Number

Атрибут

Тип

Пол

String

Характеристика

String

String

Специальность

String

Специализация

String

Опыт

Number

Место работы

String

Язык

String

Уровень владения

Number

Название

String

Описание

String

Оценка

Number


Дисциплина

String

Ф.И.О. преподавателя

String

Предмет

String

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

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

Рис. 6.5. ERD-диаграмма БД студентов с ключевыми атрибутами

Логические взаимосвязи

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

Некоторые примеры взаимосвязей:

  • команда включает много игроков,
  • самолет перевозит много пассажиров,
  • продавец продает много продуктов.

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

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

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

ERD-диаграммы

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

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

Рис. 6.1. Пример ERD-диаграммы,

Polyglot persistence

Сказанное выше приводит к тому, что порою в рамках даже одной системы приходится для хранения данных и решения различных задач по их обработке использовать несколько различных СУБД, каждая из которых поддерживает свою модель данных. С легкой руки М. Фаулера, автора ряда известных книг и одного из соавторов Agile Manifesto, такая ситуация получила название многовариантного хранения («polyglot persistence»).

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

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

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

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

С точки зрения директора зоопарка все выглядит так:

  • Кратное увеличение стоимости лицензий и техподдержки от производителя СУБД.
  • Раздутие штата и увеличение сроков.
  • Прямые финансовые потери или штрафные санкции из-за несогласованности данных.

Имеет место значительный рост совокупной стоимости владения системой (TCO). Есть ли из ситуации «многовариантного хранения» какой-то выход?

Пост-реляционные модели баз данных

Продукты, предлагающие более общую модель данных, чем реляционная модель, иногда классифицируются как пост-реляционные. Альтернативные термины включают «гибридную базу данных», «RDBMS с расширенными объектами» и другие. Модель данных в таких продуктах включает в себя отношения, но не ограничивается информационным принципом Кодда, который требует, чтобы вся информация в базе данных была явно указана с точки зрения значений в отношениях и никоим образом.

Некоторые из этих расширений к реляционной модели объединяют понятия из технологий, которые предшествуют реляционной модели. Например, они позволяют представить ориентированный граф с деревьями на узлах. Немецкая компания sones реализует эту концепцию в своем GraphDB.

Некоторые пост-реляционные продукты расширяют реляционные системы с нереляционными функциями.

Графовая модель

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

Многозначная модель

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

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

Объектно-ориентированная модель

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

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

Альтернативой переходу между объектами и реляционными базами данных является использование библиотеки объектно-реляционного сопоставления (ORM).

Плоская модель

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

Предметная область

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

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

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

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

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


С этим читают