Лекция (1) (1121827), страница 3

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

Текст из файла (страница 3)

В алгебре Кодда имеется деcять операций: объединение (UNION), пересечение (INTERSECT), вычитание (MINUS), взятие расширенного декартова произведения (TIMES), переименование атрибутов (RENAME), проекция (PROJECT), ограничение (WHERE), соединение ( -JOIN), деление (DIVIDE BY) и присваивание. Если не вдаваться в некоторые тонкости, которые мы рассмотрим в лекции 4, то почти все операции предложенного выше набора обладают очевидной и простой интерпретацией.

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

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

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

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

• Операция переименования (RENAME) производит отношение, тело которого совпадает с телом операнда, но имена атрибутов изменены; эта операция позволяет выполнять первые три операции над отношениями с «почти» совпадающими заголовками (совпадающими во всем, кроме имен атрибутов) и выполнять операцию TIMES над отношениями, пересечение заголовков которых не является пустым.

• Результатом ограничения (WHERE) отношения по некоторому условию является отношение, включающее кортежи отношения-операнда, удовлетворяющее этому условию.

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

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

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

• Операция присваивания (:=) позволяет сохранить результат вычисления реляционного выражения в существующем отношении БД.

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

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

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

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

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

На рис. 1.7 для хранения информации о служащих и отделах использовалось два файла, в одном из которых хранились данные, индивидуальные для каждого служащего, а во втором – данные об отделах. Для возможности получения полной информации о служащих и отделах, в которых они работают, в файле СЛУЖАЩИЕ содержалось поле СЛУ_ОТД_НОМЕР, содержащее для каждого служащего его уникальный номер отдела. В то же время, в файле ОТДЕЛЫ имелось поле ОТД_НОМЕР, являющееся уникальным ключом этого файла. На самом деле, введя файлы СЛУЖАЩИЕ и ОТДЕЛЫ, а также обеспечив связь между ними с помощью полей СЛУ_ОТД_НОМЕР и ОТД_НОМЕР, мы смогли обеспечить табличное представление иерархии ОТДЕЛ-СЛУЖАЩИЕ. Если говорить в терминах реляционной модели данных, то в отношении ОТДЕЛЫ поле ОТД_НОМЕР является первичным ключом, а в отношении СЛУЖАЩИЕ поле СЛУ_ОТД_НОМЕР является внешним ключом, ссылающимся на отношение ОТДЕЛЫ.

Более точно, внешним ключом отношения R₁, ссылающимся на отношение R₂, называется подмножество заголовка H_R1, которое совпадает с первичным ключом отношения R₂ (с точностью до имен атрибутов). Тогда ограничение ссылочной целостности реляционной модели данных можно сформулировать следующим образом: в любом теле отношения R₁, которое может появиться в базе данных, для «не пустого» ⁴⁾ значения внешнего ключа, ссылающегося на отношение R₂, в любом кортеже этого тела должен найтись кортеж в теле отношения R₂, которое содержится в базе данных, с совпадающим значением первичного ключа. Легко заметить, что это почти то же самое ограничение, о котором говорилось в подразделе 2.3.2. Иерархическая модель данных: никакой потомок не может существовать без своего родителя, но немного уточненное – ссылки на родителя должны быть корректными.

2 Обозначение s S означает, что элемент s принадлежит множеству S.

3 Обозначение s S означает, что элемент s не принадлежит множеству S.

4 Понятие «пустого», или неопределенного значения мы уточним в лекции 3.

2.5. Современные модели данных

Я считаю, что история современных моделей данных началась с 1989 г., когда группа известных специалистов в области языков программирования баз данных опубликовала статью под названием «Манифест систем объектно-ориентированных баз данных» [2.6]. К этому времени уже существовало несколько реализаций объектно-ориентированных СУБД (ООСУБД), но каждая из них опиралась на некоторое расширение объектной модели какого-либо объектно-ориентированного языка программирования (Smalltalk, Object Lisp, C++), отсутствовали какие-либо общие подходы.

В [2.6] не предлагалась единая объектно-ориентированная модель данных, но выделялся набор требований к ООСУБД. Базовыми требованиями являлось преодоление несоответствия между типами данных, используемыми в языках программирования, и типами данных, поддерживаемыми в набравших к тому времени силу реляционных (вернее, SQL-ориентированных) СУБД, а также придание СУБД возможностей хранить в БД данные произвольно сложной структуры. Эти требования сопровождались утверждениями об ограниченности реляционной модели данных и языка SQL и потребности использовать более развитые модели данных.

Под влиянием [2.6] в 1991 г. возник консорциум ODMG (Object Database Management Group), задачей которого была разработка стандарта объектно-ориентированной модели данных. В течение более чем десятилетнего существования ODMG опубликовала три базовых версии стандарта, последняя из которых называется ODMG 3.0 [4.4]. На этот документ мы и будем опираться в дальнейшем изложении.

В ответ на публикацию [2.6] группа исследователей, близких к индустрии баз данных, в 1990 г. опубликовала документ «Манифест систем баз данных третьего поколения» [2.7], который во многом направлен на защиту инвестиций крупных компаний-производителей программного обеспечения SQL-ориентированных СУБД. Соглашаясь с авторами [2.6] относительно потребности обеспечения развитой системы типов данных в СУБД, авторы [2.7] утверждали, что можно добиться аналогичных результатов, не производя революцию в области технологии баз данных, а эволюционно развивая технологию SQL-ориентированных СУБД.

За публикацией [2.7] последовало появление объектно-реляционных продуктов ведущих компаний-поставщиков SQL-ориентированных СУБД (Informix Universal Server, Oracle8, IBM DB2 Universal Database). В 1999 г. был принят стандарт языка SQL (SQL:1999), в котором был зафиксирован ряд новых черт языка, придающих ему черты полноценной модели данных. В последнем ко времени написания этой книги стандарте SQL:2003 эта модель уточнена и расширена. В Части 4 мы достаточно подробно обсудим стандарт SQL, а в этом разделе остановимся лишь на некоторых особенностях модели данных SQL, отличающих ее от реляционной модели данных.

Итак, в начале 1990-х гг. были провозглашены два манифеста, каждый из которых претендовал на роль программы будущего развития технологии баз данных. В первом манифесте реляционная модель данных отвергалась полностью, а во втором заменялась еще незрелой к тому времени моделью данных SQL, которая уже тогда была далека от реляционной модели. На защиту реляционной модели данных в ее первозданном виде встали Кристофер Дейт и Хью Дарвен, опубликовавшие в 1995 г. статью, под названием «Третий манифест» [2.8].

«Третий манифест» являлся одновременно наиболее консервативным и наиболее радикальным. Консервативность Третьего манифеста заключается в том, что его авторы всеми силами утверждают необходимость и достаточность использования в системах базах данных следующего поколения классической реляционной модели данных. Радикальность состоит в том, что (a) авторы полностью отрицают подходы, предлагаемые в первых двух манифестах, расценивая их как необоснованные, плохо проработанные, избыточные и даже вредные (за исключением одной общей идеи о потребности обеспечения развитой системы типов); (b) фактически, авторы полностью отбрасывают технологию, созданную индустрией баз данных за последние 25 лет, и предлагают вернуться к истокам реляционной модели данных, т.е. начальным статьям Э. Кодда [2.1].

Позже Дейт и Дарвен написали книгу, первое издание которой вышло в 1998 г. под названием «Foundation for Object/Relational Databases: The Third Manifesto» [4.5], второе – в 2000 г. под названием «Foundation for Future Database Systems: The Third Manifesto» [4.6] (издан перевод второго издания на русский язык [1.5]) и третье – под названием «Databases, Types and the Relational Model: The Third Manifesto» в 2006 г. [4.7]. В этих книгах очень подробно излагается подход авторов к построению СУБД на основе, как они утверждают, истинных идей Эдгара Кодда, изложенных им в своих первых статьях про реляционную модель данных. Некоторые более поздние идеи Кодда относительно той же реляционной модели авторами отвергаются. В любом случае, Кодд и Дарвен предлагают некоторый современный вариант реляционной модели данных (далее для определенности мы будем называть ее истинной реляционной моделью), который, безусловно, заслуживает внимания и изучения. В данной книге мы ограничимся только кратким очерком основных черт этой модели.

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

Список файлов лекций