Расширенная реляционная модель в rad эрсис


Содержание

Расширенная реляционная модель в rad эрсис

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

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

При проектировании системы содержащей несколько бизнес объектов проектировщик получает набор одноранговых таблиц со множеством связей которые можно легко представить в виде ER-диаграммы. Бизнес объекты как бы «размываются» на фоне таблиц поскольку таблицы не имеют иерархии. Ведь бизнес объекты иерархичны по своей сути. Например, строки товаров в счете-фактуре не могут существовать и не имеют смысла без самого счета. При обращении к бизнес объекту проектировщик определяет в операторах SQL операции «JOIN» для выборки информации из нескольких таблиц.

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

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

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

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

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

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

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

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

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

Не первая нормальная форма NF2

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

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

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

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

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

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

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

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

Рис. 2a. Представление данных в 1-й нормальной форме (1NF)

Рис. 2б. Дальнейшая нормализация (2NF)

Рис. 2в. Структура хранения данных в uniVerse NFNF ( NF2 )

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

О таблицах, содержащих многозначные поля, говорят, что они находятся в непервой нормальной форме, или NF2 (Non First Normal Form). Как было замечено ранее, при условии, что используемые поля подчиняются определенным правилам, позволяющим обращаться с ними, как с таблицами, встроенными в другие таблицы, форма NF2 не нарушает принципы реляционной алгебры. Более того, такая информация полностью доступна, так как расширенные операторы, которые работают с таблицами NF2, позволяют извлекать встроенные таблицы и рассматривать данные как информацию, поступившую из таблиц 1NF. И все же во многих случаях форма 1NF будет скорее исключением, а не правилом. В большинстве случаев гораздо более эффективно осуществлять доступ к многозначным полям одновременно с остальными данными, зная, что их всегда можно извлечь и рассматривать как отдельную таблицу в тех случаях, когда это может понадобиться.

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

Многозначные поля и ассоциации не могут вкладываться друг в друга. Расширение синтаксиса SQL позволяет осуществлять доступ к множественным полям как расширение реляционной модели, но, конечно, можно применять также стандартные и другой язык запросов uniVerse — RetrieVe. В целом многозначность полей является очень полезным свойством при создании коммерческих приложений, где информация нередко представлена в виде списков предметов.

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

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

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

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

Использование вложенных таблиц полностью отражает основную задачу реляционной модели — обеспечение пользователя простой логической структурой данных. Фактически, вложенные таблицы еще более упрощают логическое предcтавление данных и являются естественным расширением реляционной модели. Расширение реляционной базы данных предлагаемое фирмой Ardent позволяет использовать вложенные таблицы как атрибуты со множественными значениями и связанные группы таких атрибутов. Для создания таблицы показанной на рис 2в в может быть использовано следующее SQL предложение:

В данном случае атрибуты со множественными значениями определяются словом MULTIVALUED, а связанные группы — словом ASSOC. Конечно, если необходимо представление данных в первой нормальной форме, Ardent предоставляет механизм для динамической нормализации данных (в процессе запросов). Для данной цели в SQL синтаксис расширен ключевым словом UNNEST.

Вложенные реляционные отношения

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

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

Хостинг в Европе для новичков (от 25 руб/мес) и VIP-хостинг для профессионалов (от 1000 руб/мес)

Скидка 25% на все тарифы хостинга по промокоду STDCITF

Преобразование ER- модели в реляционную модель данных

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

1. Каждая простая сущность превращается в отношение (таблицу). Простая сущность – это сущность, не являющаяся подтипом и не имеющая подтипов. Имя сущности становится именем отношения.

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

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

4. Атрибуты, имеющие типы связи M:1 (и 1:1) становятся внешними ключами.

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

6. Если в концептуальной схеме присутствовали подтипы, то возможны два способа:

а) все подтипы размещаются в одной таблице;


б) для каждого подтипа строится отдельная таблица.

Полученные таблицы должны удовлетворять требованиям:

· каждая таблица состоит из однотипных строк и имеет уникальное имя;

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

· таблицы имеют фиксированное число столбцов и их значений;

· в каждой таблице на пересечении строки и столбца должно находиться только одно значение или ничего;

· в столбцах таблицы размещаются однородные значения данных.

Важным этапом проектирования реляционной БД является обеспечение реляционной целостности данных.

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

Существуют ограничения по условию целостности данных:

· ограничение по сущностям – каждая строка должна отличаться от остальных ее строк значением хотя бы одного столбца;

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

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

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

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

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

Дата добавления: 2015-04-03 ; просмотров: 3092 ; ЗАКАЗАТЬ НАПИСАНИЕ РАБОТЫ

Расширенная реляционная модель данных и объектно-реляционные СУБД

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

Для систем с расширенной реляционной моделью данных используются самые разные термины. Сначала применялся термин расширенная реляционная СУБД (Extended Relational DBMS — ERDBMS). Однако в последние годы используется более информативный термин объектно-реляционная СУБД, или ОРСУБД (Object-Relational DBMS — ORDBMS), в котором содержится указание на использование понятия объект. Чаще всего используется термин Объектно-реляционная СУБД или ОРСУБД. Три ведущих фирмы в области разработки ОРСУБД, а именно Oracle, Informix, IBM, расширили свои системы до уровня ОРСУБД, хотя их функциональные возможности немного отличаются. Концепция ОРСУБД, как комбинации ООСУБД и РСУБД, очень притягательна за счет применения знаний и опыта, которые были накоплены за время работы с РСУБД. Разработка стандартов в этой сфере построена на расширении стандарта языка SQL.

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

Другое очевидное преимущество заключается в том, что расширенный реляционный подход позволяет воспользоваться обширным объемом накопленных знаний и опыта, связанных с разработкой реляционных приложений. Э’ГО очень важное досто инство, поскольку многие организации не хотели бы тратить средства на достаточно дорогой переход к системе нового типа. При правильном проектировании с учетом новых функциональных возможностей подобный подход позволяет организациям воспользоваться преимуществами новых расширений эволюционным путем без утраты преимуществ, получаемых от использования компонентов и функций уже существующей базы данных. Таким образом, переход к ОРСУБД можно организовать в интегрирующем, эволюционном стиле посредством выполнения некоторых пробных и экспериментальных проектов. Будущий стандарт SQL3 проектируется с учетом совместимости снизу вверх с текущим стандартом SQL, а потому любые ОРСУБД, совместимые с SQL3, должны удовлетворять этому условию.

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

Сравнение ООСУБД и ОРСУБД

Таблица 1 – Сравнение моделей данных в ОРСУБД и ООСУБД

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

Таблица 2 – Сравнение методов доступа к данным в ОРСУБД и ООСУБД

Функция ОРСУБД ООСУБД
Создание перманентных данных и доступ к ним Поддерживается, но не прозрачно Поддерживается, но степень прозрачности варьируется для разных продуктов
Произвольные запросы Строгая поддержка Поддерживается на основе стандарта ODMG 2.0
Навигация Поддерживается на основе типа REF Строгая поддержка
Ограничения целостности Строгая поддержка Не предусмотрены
Сервер объектов/сервер страниц Сервер объектов Оба
Эволюция схемы Ограниченная поддержка Поддерживается, но степень поддержки варьируется для разных продуктов

Таблица 3 – Сравнение способов совместного использования данных

Дата добавления: 2020-07-29 ; просмотров: 584 | Нарушение авторских прав

Преобразование ER- модели в реляционную. правила преобразования ER- модели в реляционную. 1. Каждой сущности ставится в соответствие отношение реляционной. — презентация

Презентация была опубликована 6 лет назад пользователемОксана Федькина

Похожие презентации

Презентация на тему: » Преобразование ER- модели в реляционную. правила преобразования ER- модели в реляционную. 1. Каждой сущности ставится в соответствие отношение реляционной.» — Транскрипт:

1 Преобразование ER- модели в реляционную

2 правила преобразования ER- модели в реляционную. 1. Каждой сущности ставится в соответствие отношение реляционной модели данных. 2. Каждый атрибут сущности становится атрибутом соответствующего отношения.

3 Преобразование ключей 3. Первичный ключ сущности становится PRIMARY KEY соответствующего отношения. Атрибуты, входящие в первичный ключ отношения, автоматически получают свойство обязательности (NOT NULL). 4. В каждое отношение, соответствующее подчиненной сущности, добавляется набор атрибутов основной сущности, являющейся первичным ключом основной сущности. В отношении, соответствующем подчиненной сущности, этот набор атрибутов становится внешним ключом (FOREING KEY).

4 Связи 5. Для моделирования необязательного типа связи на физическом уровне у атрибутов, соответствующих внешнему ключу, устанавливается свойство допустимости неопределенных значений (признак NULL). При обязательном типе связи атрибуты получают свойство отсутствия неопределенных значений (признак NOT NULL).

5 Категоризация типов Для отражения Категоризации сущностей при переходе к реляционной модели возможны несколько вариантов представления. Возможно создать только одно отношение для всех подтипов одного супертипа

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

7 дискриминаторы Дополнительно при описании отношения между типом и подтипами необходимо указать тип дискриминатора Дискриминатор может быть взаимоисключающим или нет

8 Пример – наследование идентификатора суперсущности

9 Наследование всех атрибутов суперсущности

10 Разрешение связей типа «многие-ко-многим». Это делается введением специального дополнительного связующего отношения, которое связано с каждым исходным связью «один-ко-многим», атрибутами этого отношения являются первичные ключи связываемых отношений. например» в схеме «Библиотека» присутствует связь такого типа между сущностью «Книги» и «Системный каталог». Для разрешения этой неспецифической связи при переходе к реляционной модели, должно быть введено специальное дополнительное отношение, которое имеет всего два атрибута; ISBN (шифр книги) и KOD (код области знаний). При этом каждый из атрибутов нового отношения является внешним ключом (FORKING KEY), а вместе они образуют первичный ключ (PRIMARY KEY) повой связующей сущности.

12 Алгоритм приведения семантической модели к 5-й нормальной форме Шаг 1. Проанализировать схему на присутствие сущностей, которые скрыто моделируют несколько разных взаимосвязанных классов объектов реального мира (именно это соответствует ненормализованным отношениям). Если такое выявлено, то разделить каждую из этих сущностей на несколько новых сущностей и установить между ними соответствующие связи. Полученная схема будет находиться в первой нормальной форме.

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

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

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

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


17 Проанализировать сущности на наличие в них зависимостей проекции-соединения. При обнаружении таковых расщепить сущность на требуемое число взаимосвязанных сущностей и установить между ними требуемые связи. Полученная таким образом схема будет находиться в пятой нормальной форме

Национальная библиотека им. Н. Э. Баумана
Bauman National Library

Персональные инструменты

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

Реляционная модель — совокупность данных, состоящая из набора двумерных таблиц. В теории множеств таблице соответствует термин отношение (relation), физическим представлением которого является таблица, отсюда и название модели – реляционная. Соответственно теория построения баз данных, которая является приложением к задачам обработки данных таких разделов математики, как теория множеств и логика первого порядка. В сравнении с иерархической и сетевой моделью данных, реляционная модель отличается более высоким уровнем абстракции данных. Реляционная модель является удобной и наиболее привычной формой представления данных, так в настоящее время эта модель является фактическим стандартом, на который ориентируются практически все современные коммерческие СУБД. На реляционной модели данных строятся реляционные базы данных [1] .

Впервые принципы реляционной модели были сформулированы в 1969—1970 годах Э. Ф. Коддом (E. F. Codd). Идеи Кодда были впервые публично изложены в статье «A Relational Model of Data for Large Shared Data Banks». Современную трактовку идей реляционной модели данных можно найти в книге К. Дж. Дейта. «C. J. Date. An Introduction to Database Systems»

Содержание

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

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

Структурная часть

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

Манипуляционная часть

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

Целостная часть

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

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

Структура реляционной модели данных

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

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

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

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

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

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

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

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

Реляционная модель данных: теоретические основы

Реляционная модель данных: кем, когда и для чего создана

Реляционная модель данных — созданная Эдгаром Коддом логическая модель данных, описывающая:

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

Эдгар Франк «Тед» Кодд — (23 августа 1923 —18 апреля 2003) — британский учёный, работы которого заложили основы теории реляционных баз данных. Работая в компании IBM, он создал реляционную модель данных. В 1970 издал работу «A Relational Model of Data for Large Shared Data Banks», которая считается первой работой по реляционной модели данных.

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

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

Цели создания реляционной модели данных:

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

Структура данных в реляционной модели данных

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

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

    Отношение — это плоская (двумерная) таблица, состоящая из столбцов и строк:

    ID Фамилия Имя Должность г.р.
    1 Петров Игорь Директор 1968
    2 Иванов Олег Юрист 1973
    3 Ким Елена Бухгалтер 1980
    4 Сенин Илья Менеджер 1981
    5 Васин Сергей Менеджер 1978

    Атрибут — это поименованный столбец отношения.


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

    Кортеж — это строка отношения.

    Степень определяется количеством атрибутов, которое оно содержит

    Кардинальность — это количество кортежей, которое содержит отношение.

    Первичный ключ — это уникальный идентификатор для таблицы.

    Соответствие между формальными терминами реляционной модели данных и неформальными:

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

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

    Отношение R на множестве доменов D 1 , D 2 , …, D n — это подмножество декартова произведения этих доменов:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Ключи отношения в реляционной модели данных

    Ключи отношения могут быть следующми:

    • суперключ;
    • потенциальный ключ;
    • первичный ключ;
    • внешний ключ;
    • суррогатный ключ.

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

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

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

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

    Первичный ключ (primary key, PK) — это один из потенциальных ключей отношения, выбранный в качестве основного ключа. Допустимо объявление одного и только одного первичного ключа. Атрибуты первичного ключа не могут принимать значения Null.

    Внешний ключ (foreign key, FK) — это ключ, объявленный в базовом отношении, который при этом ссылается на первичный того же самого или какого-то другого базового отношения.

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

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

    Решение. Можно объявить первичным ключём таблицы «Наличие» составной ключ, состоящий из идентификатора аптеки и идентификатора препарата. Тогда в таблице невозможно повторение в разных записях сочетания аптеки и прапарата. Первичный ключ может быть не только простым, но и составным.

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

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

    • определитель 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 — изменение таблицы базы данных.

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

    9.4.2.Методология rad — Rap > На начальном этапе существования компьютерных информационных систем их разработка велась на традиционных языках программирования. Однако по мере возрастания сложности разрабатываемых систем и увеличения запросов пользо­вателей (чему в значительной степени способствовал прогресс в области вычис­лительной техники, а также появление удобного графического интерфейса пользо­вателя в системном программном обеспечении) потребовались новые средства, обеспечивающие значительное сокращение сроков разработки. Это послужило предпосылкой к созданию целого направления в области программного обеспече­ния — инструментальных средств для быстрой разработки приложений. Развитие этого направления привело к появлению на рынке программного обеспечения средств автоматизации практически всех этапов жизненного цикла информаци­онных систем.

    Основные особенности методологии RAD

    Методология разработки информационных систем, основанная на использовании средств быстрой разработки приложений, получила в последнее время широкое распространение и приобрела название методологии быстрой разработки прило­жений — RAD (Rapid Application Development). Данная методология охватывает все этапы жизненного цикла современных информационных систем.

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

    Под методологией быстрой разработки приложений обычно понимается процесс разработки информационных систем, основанный на трех основных элементах:

    небольшой команде программистов (обычно от 2 до 10 человек);

    тщательно проработанный производственный график работ, рассчитанный на сравнительно короткий срок разработки (от 2 до 6 мес.);

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

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

    Основные принципы методологии RAD можно свести к следующему:

    используется итерационная (спиральная) модель разработки;

    полное завершение работ на каждом из этапов жизненного цикла не обяза­тельно;

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

    необходимо применение CASE-средств и средств быстрой разработки приложений;

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

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

    тестирование и развитие проекта осуществляются одновременно с разработкой;

    разработка ведется немногочисленной и хорошо управляемой командой про­фессионалов;

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

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

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

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

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

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

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

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

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

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

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

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

    Среди универсальных систем визуального программирования сейчас наиболее распространены такие, как Borland Delphi и Visual Basic. Универсальными мы их называем потому, что они не ориентированы на разработку только приложений баз данных — с их помощью могут быть разработаны приложения почти любого типа, в том числе и информационные приложения. Причем программы, разраба­тываемые с помощью универсальных систем, могут взаимодействовать практически с любыми системами управления базами данных. Это обеспечивается как исполь­зованием драйверов ODBC или OLE DB, так и применением специализирован­ных средств (компонентов).

    Специализированные средства разработки ориентированы только на создание приложений баз данных. Причем, как правило, они привязаны к вполне определен­ным системам управления базами данных. В качестве примера таких систем мож­но привести Power Builder фирмы Sybase (естественно, предназначенный для работы с СУБД Sybase Anywhere Server) и Visual FoxPro фирмы Microsoft.

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

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

    Логика приложения, построенного с помощью RAD, является событийно-ориен­тированной. Это означает следующее: каждый объект, входящий в состав прило­жения, может генерировать события и реагировать на события, генерируемые дру­гими объектами. Примерами событий могут быть: открытие и закрытие окон, нажатие кнопки, нажатие клавиши клавиатуры, движение мыши, изменение дан­ных в базе данных и т. п.

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

    Обработчики событий, связанных с управлением базой данных (DELETE, INSERT, UPDATE), могут реализовываться в виде триггеров на клиентском или серверном узле. Такие обработчики позволяют обеспечить ссылочную целостность базы дан­ных при операциях удаления, вставки и обновления, а также автоматическую ге­нерацию первичных ключей.


    При использовании методологии быстрой разработки приложений жизненный цикл информационной системы состоит из четырех фаз:

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

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

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

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

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

    Поскольку ПРМД допускает хранение в таблицах ненормализованных данных, возникает проблема обеспечения целостности и непротиворечивости данных. Эта проблема решается включением в СУБД механизмов, подобных хранимым процедурам в клиент-серверных системах.

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

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

    Недостатком ПРМД является сложность решения проблемы обеспечения целостности и непротиворечивости хранимых данных.

    Многомерная модель

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

    Толчком к использованию многомерной модели данных (ММД) послужила опубликованная в 1993 г. программная статья одного из основоположников реляционного подхода Э. Кодда. В ней сформулированы 12 основных требований к системам класса OLAP (OnLine Analytical Processing – оперативная аналитическая обработка), важнейшие из которых связаны с возможностями концептуального представления и обработки многомерных данных. Многомерные системы позволяют оперативно обрабатывать информацию для проведения анализа и принятия решения.

    В развитии концепций OLAP можно выделить следующие два направления:

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

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

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

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

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

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

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

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

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

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

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

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

    Измерение (Dimension) – это множество однотипных данных, образующих одну из граней гиперкуба. Примерами наиболее часто используемых временны́х измерений являются Дни, Месяцы, Кварталы и Годы. В качестве географических измерений широко употребляются Города, Районы, Регионы и Страны. В многомерной модели данных измерения играют роль индексов, служащих для идентификации конкретных значений в ячейках гиперкуба

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

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

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

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

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

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

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

    Операции агрегации (Drill Up) и детализации (Drill Down) означают соответственно переход к более общему и к более детальному представлению информации пользователю из гиперкуба.

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

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

    Реляционная база данных. Проектирование реляционных баз данных

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

    Таблица как важная часть реляционной БД

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

    Таблицы в таких БД обладают следующими свойствами: — столбцы размещаются в определённом порядке, формируемом при создании таблицы. Таблица может не иметь ни одной строки, однако хотя бы один столбец должен быть обязательно; — в таблице не может быть 2-х одинаковых строк. Если вспомнить математику, то такие таблицы называют отношениями (relation). Именно поэтому данные БД и считаются реляционными; — каждый столбец в пределах таблицы имеет уникальное имя, а все значения в одном столбце должны быть одного типа (дата, текст, число и т. п.); — на пересечении строки и столбца может быть только атомарное значение (значение, не состоящее из группы значений). Таблицы, которые удовлетворяют этим условиям, считаются нормализованными.

    Приведём пример

    Допустим, вы хотите создать базу данных для интернет-форума. На форуме есть зарегистрированные пользователи, создающие темы и оставляющие сообщения в данных темах. Вся эта информация и должна размещаться в базе данных.

    В теории всё можно расположить в одной таблице, а именно:

    Однако такое расположение противоречит атомарности, причём в столбцах «Созданные сообщения» и «Созданные темы» возможно неограниченное число значений. Целесообразнее всего разбить таблицу на три:

    Теперь таблица «Пользователи» соответствует правилам. Но вот таблицы «Сообщения» и «Темы» — нет, т. к. не должно быть 2-х одинаковых строк. В нашем же случае один и тот же пользователь может написать 2 одинаковых сообщения:

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


    Ключи в БД

    Первичный ключ (РК, primary key) — столбец, значения которого различны во всех строках. РК бывают логические (естественные) и суррогатные (искусственные).

    Например, для таблицы «Пользователи» первичным ключом может быть столбец e-mail, т. к. не бывает 2-х пользователей с одним и тем же e-mail.

    На практике для хранения и обработки данных рекомендуют применять суррогатные ключи (их использование позволит абстрагировать РК от реальных данных). Это важно, если пользователь, вдруг, сменит e-mail, а ведь первичные ключи нельзя менять.

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

    Вносим первичные ключи в наши таблицы:

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

    Теперь становится ясно, что сообщение >

    Ещё момент: допустим, добавляется новый пользователь по имени Вася.

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

    Итак, наша база данных фактически готова. Схематично она выглядит так:

    В этой небольшой базе данных лишь 3 таблицы. А что делать, если их 10 либо 200? Ясно, что всё не так просто. Именно поэтому любое проектирование реляционных баз данных начинается с разработки концептуальной модели данных.

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

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

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

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

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

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

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

    Атрибуты таблицы

    Каждый объект интернет-магазина имеет свои атрибуты:

    В результате мы создали концептуальную модель будущей базы данных. Точнее говоря, речь идёт лишь о части БД, т. к. мы не учли склады, сотрудников и т. п. Собственно, при обширной предметной области данные лучше разбить на несколько локальных областей. Как правило, объём должен быть в пределах 5-7 объектов. И лишь после создания локальных моделей выполняется их объединение в общую сложную схему. В нашем случае ограничимся созданной моделью. Однако теперь давайте преобразуем её в реляционную модель данных.

    Проектирование реляционной базы данных. Преобразование модели в реляционную

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

    Из набора таблиц состоят наши объекты, а из полей таблиц — атрибуты объектов:

    Итак, мы определились с таблицами, полями, РК и FK. Следует отметить, что в таблицах «Журнал покупок» и «Журнал поставок» РК составные, т. к. состоят из 2-х полей.

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

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

    Нормализация бывает: — 1-й нормальной формы (1НФ); — 2НФ; — 3НФ; — НФБК (нормальной формы Бойса-Кодда); — 4НФ; — 5НФ.

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

    Если говорить о реляционных базах данных, то минимум — это 1НФ. Однако в процессе проектирования специалисты по СУБД стремятся нормализовать базу хотя бы до уровня 3НФ, исключив тем самым избыточность данных и аномалии. Это важно, если мы стремимся получить качественный результат проектирования. Однако подробное описание нормализации данных выходит за рамки нашей статьи, поэтому давайте просто посмотрим, как будет выглядеть наша база на уровне 3НФ:

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

    Подводим итоги проектирования

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

    Вообще, взгляды на проектирование среди разработчиков могут различаться. Некоторые игнорируют теорию, руководствуясь лишь опытом и здравым смыслом. Другие во время проектирования отводят главную роль интуиции, считая проектирование искусством, которым владеют далеко не все. Как бы там ни было, знания никогда не бывают лишними.

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

    В заключение, добавим, что умение проектировать базы вам никогда не помешает. А научиться всему этому вы сможете на нашем курсе «Реляционные СУБД». Ждём вас!

    Альтернативные модели данных и подходы

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

    Модель «Сущность-атрибут-значение» (EAV)

    В англоязычной терминологии модель САЗ (Сущность-Атрибут­-Значение) носит название EAV (Entity-Atribute-Value). В русскоязычном сообществе разработчиков приложений баз данных подход обсуждался в 1990-х годах как «вертикальное хранение атрибутов», в противовес реляционной модели, где атрибуты располагаются горизонтально.

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

    • столбец «Сущность». Содержит уникальный идентификатор сущности. Также может представлять собой пару (идентификатор, временная метка) для отражения хронологии событий и фактов;
    • столбец «Атрибут». Название свойства сущности, как правило — ссылка (короткий идентификатор) на таблицу атрибутов в метаданных;
    • столбец «Значение». Непосредственно значение атрибута.

    Использование реляционной терминологии «таблица» и «столбец» для описания модели САЗ вызвана, во-первых, стереотипом наиболее понятным для большинства разработчиков, во-вторых, тем фактом, что вертикальное хранение в большинстве известных автору случаев было реализовано средствами реляционной СУБД.

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

    Рис. 1. Представление САЗ в виде таблицы

    Рис. 2. Матрица САЗ является разреженной

    Немного углубясь в историю, можно обнаружить гораздо более древний и широко известный в классическом программировании подход ассоциативных массивов, состоящих из пар «ключ-значение». Этот путь прямиком приводит нас в 1960-е годы к языку Лисп. Базы данных, использующие такой поход, применялись ещё до эпохи массового распространения реляционных СУБД. Только и разница, что теперь вместо простого ключа используется составной. Записывали раньше в массив пару («Товар№795/Наименование», «Мука пшеничная в/с»), теперь же ключом ассоциативного списка становится пара атрибутов, а в программе оперируем уже тройками.


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

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

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

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

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

    Расширенная модель САЗ носит название EAV/CR (EAV with classes and relationships), то есть САЗ с классами (типами) и связями. В дальнейшем будем называть её РСАЗ.

    РСАЗ явным образом поддерживает для каждой сущности понятие класса (типа). Это означает, что запросы теперь можно ограничивать только сущностями заданного типа, чтобы избежать приведённой выше неоднозначности выборки по значениям атрибутов.

    Связи между сущностями также поддерживаются в явном виде, кроме того структура, задающая связи, подлежит унификации.

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

    Рис. 3. Пример реализации расширенной модели САЗ

    Запросы, относящиеся к категории CRUD [1] , также не представляют особенных трудностей, за исключением необходимости транспонировать результат в табличную форму. В рамках реализующего САЗ реляционного подхода такие макрозапросы состоят из большого числа мелких подзапросов в соответствии с числом выводимых колонок-атрибутов.

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

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

    Следующий запрос выводит все номера доставленных заказов, в которых имеется товар «Мука пшеничная в/с», и его вес превышает 100 кг.

    Несмотря на относительную простоту первоначального запроса, при реализации РСАЗ в рамках реляционной БД необходимо определить целых 12 соединений!

    Снова приведём для сравнения запрос к таблицам реляционной СУБД.

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

    Теперь наш запрос примет более удобочитаемый вид.

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

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

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

    • строковый или бинарный тип с конвертацией в другие типы данных. Недостатком является более низкое быстродействие по сравнению с хранением в формате встроенных типов СУБД;
    • несколько колонок разного типа, например «Значение-строка», «Значение-целое», «Значение-дата» и т. д. Конвертация данных не требуется, но манипуляции с чтением-записью значений в зависимости от типа атрибута усложняют запросы, необходимо наращивать язык с помощью тех же видов или хранимых процедур. Другой недостаток — разрежённость хранения, ведь если определить 5 колонок для значений разного типа, то только одно значение в каждой строке будет использовано. Некоторые СУБД, например, SQL Server 2008 и выше предлагают оптимизированное хранение для таких разреженных колонок (подробнее см. sparse columns);
    • отдельные таблицы, содержащие значения только заданного типа, связанные с основной eav по короткому уникальному идентификатору. Недостаток — необходимость дополнительных соединений, в том числе внешних (LEFT JOIN вместо INNER JOIN);
    • смешанные подходы, например, создание отдельных таблиц только для хранения длинных текстовых и бинарных значений атрибутов.

    Модель САЗ: плюсы и минусы

    Преимуществами модели САЗ являются:

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

    К недостаткам следует отнести:

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

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

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

    Неполно структурированные модели данных

    К неполно структурированным моделям данных (НСМД, в англоязычной терминологии semi-structured data models) относятся те способы их организации, в которых схема и данные не разделены. Обратите внимание, схема не «зашита» в данные, подобно встроенной DTD в XML- файле, а отсутствует в явном виде, при этом данные остаются структурированными.

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

    Тем не менее, если вы встречаете упоминание о полу- или слабо структурированных данных, то, скорее всего, речь пойдёт о НСМД.

    В рамках статьи будет использован термин «неполно структурированные данные» (НСД).

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

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

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

    Поскольку в НСМД данные остаются структурированными, они могут быть проанализированы и интерпретированы непосредственно в ходе обработки. Таковым, например, является XML, не имеющий ограничений XML-схемы или DTD. Любой разборщик XML позволяет работать с таким нестрогим документом посредством навигации по иерархии тегов и спискам атрибутов.

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

    Другим широко распространенным подходом НСМД является JSON (JavaScript Object Notation). По сравнению с XML «без схем», JSON представляет собой менее удобный для восприятия человеком формат. Однако, он более прост для обработки анализаторами и может быть более экономичным по объёму за счёт отсутствия замыкающих тегов.

    Как и XML, JSON также может иметь схему данных, содержащую информацию о типах элементов и порядке их следования в документе. Ниже — пример сохранения данных в JSON-документе.

    Подходы НСМД тесно связаны с обширной темой самодокументированных данных и понятием «семантический веб» (semantic web). Согласно этой концепции, информация передаётся между системами в НСМД, при этом структура считается самодостаточной для распознавания и интерпретации смысловых и контекстных связей в документе без предварительного согласования схем данных для обмена.

    Документ-ориентированная модель и NoSQL

    Документ-ориентированная модель (ДОМ, не путайте с DOM — Document Object Model, объектной моделью документа, используемой при разборе XML) носит такое название, потому что основным её элементом является документ. В отсутствии строгого определения, это понятие соответствует иерархическим XML, JSON-документам и подобным структурам.

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

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


    Эта возможность позволяет относительно просто расширять структуру хранимой в БД информации. Для аналогичных расширений в реляционной модели приходится создавать таблицы расширений, связанные отношением «один-к-одному» с главной таблицей. Такое расширение в случае иерархии таблиц является выделением подтипов (sub-typing). В случае множественного подчинения речь идёт об агрегации.

    Рис. 4. Расширение структур в документ-ориентированной и реляционной моделях

    СУБД, реализующие документ-ориентированную модель, получили название NoSQL, явно обозначающий их отличие от реляционных подходов. В дальнейшем термин NoSQL «лёгким движением руки» превратился в аббревиатуру, которая расшифровывалась уже как Not Only SQL (не только SQL), став обозначением для семейства нереляционных СУБД, созданных преимущественно в последнее десятилетие и в большинстве своём под свободными лицензиями с открытым исходным кодом: Cassandra, CouchDB, MongoDB и многие другие.

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

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

    Слабым звеном NoSQL является, как это следует из названия, отсутствие стандартизованного декларативного языка запросов, коим является SQL. Иллюстрация ниже показывает, как переписать SQL-запрос на последовательность команд входного языка MongoDB.

    Рис. 5. Сравнение текстов запросов MySQL и MongoDB

    Пояснения к трансформации:

    1. Функции агрегации в MongoDB программируются вручную с использованием механизма map-reduce. Колонки измерений вынесены в map.
    2. Непосредственная реализация функций агрегации над величинами (мерами).
    3. Агрегации, зависящие от числа обработанных записей, должны ждать завершения основной функции.
    4. Внутри можно использовать обычную процедурную логику, например, условные переходы.
    5. Выражения фильтров записываются в близком к ORM стиле.
    6. Фильтры уровня агрегации должны быть применены к результату map-reduce.
    7. Восходящая сортировка кодируется единицей «1», нисходящая — «1».

    Данная иллюстрация хорошо показывает, чем декларативный язык 4 поколения SQL, отличается от императивного, основанного на языке 3 поколения типа Ява-скрипт.

    Для меня же интерпретация данной картинки представила интерес совсем по другой причине: по замыслу авторов подобное переписывание запроса представляет собой более привычный и простой (!) для программиста код.

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

    Ещё одну типичную ситуацию выпукло изобразили редакторы веб-сайта http://www.commitstrip.com. С их любезного разрешения ниже публикуется переведённая мной на русский язык история.

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

    Рис. 6. Некомпетентность в SQL — не причина миграции на NoSQL.

    Некомпетентность в SQL и реляционных СУБД не может служить серьёзным доводом в выборе NoSQL СУБД.

    Многомерные модели данных

    Центральным понятием модели является многомерный куб или гиперкуб. С привычным всем стереометрическим кубом сходство можно найти лишь при числе измерений, равном трём. Искать наглядные аналоги гиперкуба в геометрии трудно, а трёх измерений хватает разве что для самых простых аналитических выборок. Положим, например, что при оценке сбыта нужны всего 3 измерения: покупатель, период, товар. Значением узла куба по этим измерениям может быть сумма продаж или количество товара, если он отгружается в сравнимых единицах.

    Рис. 7. Данные в ячейках гиперкуба трёхмерной модели

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

    • индексы измерений поименованы: вместо целых чисел 1, 2. N используется их заданное соответствие. Например, 1 — «Мука в/с», 2 — «Дрожжи», 3 — «Сахар» и т. д. — это обычная кодификация;
    • для доступа к значениям гиперкуба не обязательно специфицировать все индексы измерений.

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

    что эквивалентно в нашем примере

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

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

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

    Значение термина OLAP гораздо шире гиперкубов, поскольку сюда включены все методы интерактивной аналитической обработки данных: хранилища данных (data warehouse), так называемые витрины данных (data mart), добыча данных (data mining) и т. п. Часть перечисленных понятий может быть одновременно объектом пакетной обработки.

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

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

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

    Рис. 8. Реляционная схема хранения трёхмерного гиперкуба

    Подобная реализация также имеет название ROLAP (Relational OLAP) и поддерживается большинством систем аналитической обработки.

    В общем случае, число необходимых таблиц Mtab для хранения N- мерного гиперкуба определяется как сумма всех возможных сочетаний из N по k, где k меняется от 0 до N.

    В нашем примере при количестве измерений N=3 таблиц должно было быть 2 3 =8, но для простоты исключена таблица с единственной строкой, не содержащая колонок-измерений. Соответствующую величину можно высчитать по наименее детализированной таблице (с одной колонкой- измерением).

    Так как в общем случае для N измерений требуется 2 N таблиц, их число растёт экспоненциально, поэтому на практике возможности ROLAP ограничиваются их небольшим (N 10..15, если таблица ответов содержит даже десятки миллионов строк [2] , а план выполнения запроса представляет собой скопление вложенных циклов со внутренними хеш-слияниями промежуточных выборок.

    Рис. 10. План выполнения запроса в СУБД PostgreSQL при N = 15

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

    Зная, что начиная с некоторого порога N время выполнения первого запроса будет расти линейно, можно переписать его в другом виде, без соединений, но с необходимостью всякий раз производить полное сканирование длинной таблицы ответов. Сканирование и промежуточное агрегирование на основе хеш-функций также негативно влияет на производительность, но время выполнения становится предсказуемым, хотя в случае N > 20..30 может вновь стать неприемлемым.

    Соответствующий план будет примерно следующим, независимо от N.

    Рис. 11. План выполнения запроса в СУБД PostgreSQL

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

    Как можно увидеть, даже в случае очень простых запросов проявляются трудности их реализации. Стоит несколько усложнить условия выборки, например «все пользователи, ответившие на вопросы NNN заданным образом, но по группе вопросов MMM совпадение не превышает 50%», как технические проблемы начинают расти в геометрической прогрессии.

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

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

    [1] CRUD — от англ. Create-Retreive-Update-Delete, типы множественных запросов на создание, считывание, модификацию или удаление единичного экземпляра сущности.

    [2] Разумеется, приведённые значения N приблизительны, точные оценки зависят от многих факторов, прежде всего от производительности аппаратуры и конкретной СУБД. Для их получения необходимо производить нагрузочные тесты.

    Илон Маск рекомендует:  Расширение php 4 0
    Понравилась статья? Поделиться с друзьями:
    Кодинг, CSS и SQL