LS-Sb90335

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

Отношения имеют следующие свойства:

−любой тип записи (кортежа) содержит только простые (по структуре) элементы данных;

−обращение к отношению происходит по его имени;

−имя отношения уникально;

−в отношении не должно быть одинаковых кортежей;

−порядок кортежей в отношении несущественен;

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

−если между двумя реляционными отношениями существует зависимость, то одно отношение является исходным, а второе считается

подчиненным.

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

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

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

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

Внешний ключ реализует ограничение целостности, проверяя:

11

−что при добавлении записи в подчиненную таблицу СУБД, в родительской таблице существует запись с таким же значением первичного ключа;

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

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

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

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

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

ративного языка SQL (Structured Query Language).

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

−порядок столбцов (полей) в отношении должен быть фиксирован;

−отношения должны быть конечны.

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

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

12

цедуры обработки и обновления данных, а также минимизировать их дублирование. Для этого отношения должны отвечать требованиям нормализации.

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

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

Таблица, находящаяся во второй нормальной форме, должна отвечать следующим условиям:

−содержать данные об одном типе объектов;

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

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

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

Таблица находится в третьей нормальной форме:

−если все ее неключевые поля зависят только от первичного ключа;

−все ее неключевые поля не зависят друг от друга.

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

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

13

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

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

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

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

2.2. Базы данных, основанные на концепции NoSQL

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

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

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

14

использовать и в менее традиционных прикладных системах: САПР, системах искусственного интеллекта и т. д.

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

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

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

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

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

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

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

15

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

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

−специализация БД для конкретной области применения (позволяет обеспечить более высокую скорость обработки данных);

−разделение БД на системы хранения, системы обработки потоков данных в режиме реального времени и гибридные системы;

−целевая направленность на обработку распределенных данных (многие базы NoSQL используют разные серверные продукты, осуществ-

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

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

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

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

Согласно таблице можно выделить следующие категории NoSQL-баз данных.

Первая категория – базы данных «ключ– значение». Это очень простые по своей идее хранилища. Фактически это очень большие хэш-таблицы1, где каждому ключу присвоено соответствующее значение. Такие базы могут очень быстро оперировать колоссальными объемами информации, но имеют серьезные ограничения в языке запросов. В качестве примеров Value-баз данных «ключ-значение» можно привести Dynomite, Voldemort, Tokyo, Redis,

BigTable.

Следующая категория – документоориентированные базы данных. Такие базы немного напоминают базы «ключ-значение», но в данном случае база данных «знает», что из себя представляют значения. Обычно значением является некоторый документ или объект, структуре которого можно делать запросы. Примерами таких баз являются CouchDB и MongoDB.

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

1 Хеш-табли́ца – это структура данных, которая позволяет хранить пары ключ– значение и выполнять три операции: добавление новой пары, поиск и удаление пары по ключу.

17

могут обладать некоторым количеством атрибутов. В качестве примеров можно привести базы данных Neo4j, AllegroGraph, Sones graphDB.

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

2.3. Объектно-ориентированные базы данных

Термин «объект» в программной индустрии впервые был введен в языке Simula (1967 г.) и означал какой-либо аспект моделируемой реальности. Сейчас под объектом понимается «нечто, имеющее четко определенные границы» (определение известного американского специалиста Г. Буча). Объекты, обладающие одинаковыми свойствами, составляют классы (например, курица, пингвин и чайка – объекты класса «птицы»). Обычно класс описывается как новый тип данных, а объекты (экземпляры класса) – определенные на его основе переменные.

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

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

−инкапсуляция – свойство объекта скрывать внутреннюю структуру;

−наследование – возможность создавать из классов объектов новые классы объектов, которые наследуют структуру и методы своих предков, добавляя к ним черты, отражающие их собственную индивидуальность;

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

18

Для поддержания целостности объектно-ориентированный подход предлагает использовать следующие средства:

−автоматическое поддержание отношений наследования;

−возможность объявить некоторые поля данных и методы объекта как «скрытые», не видимые для других объектов; такие поля и методы используются только методами самого объекта;

−создание процедур контроля целостности внутри объекта.

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

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

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

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

19

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

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

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

Существующие коммерческие ООСУБД (Versant, Objectivity/DB, ObjectStore, GemStone) отличаются очень большой технической разнородностью. Ни одна из компаний, производящих ООСУБД, так и не смогла набрать критическую массу, достаточную, чтобы стать лидером, диктующим моду в данной области (как это произошло с IBM и Oracle в области SQLориентированных СУБД). Крупные компьютерные компании не решились закупить, развивать и продвигать на рынке какой-нибудь продукт ООСУБД.

3. ТЕХНОЛОГИИ РАСПРЕДЕЛЕННОЙ ОБРАБОТКИ ДАННЫХ

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

20