Лекции и практики (1). Курс лекций и материалы для практических занятий
 Скачать 1.01 Mb.
|
Реляционная модель данных (РМД)Понятие отношения Реляционная модель данных была предложена в 1970 г. математиком Эд- гаром Коддом (Codd E.F.). РМД является наиболее широко распространенной моделью данных и единственной из трёх основных моделей данных, для кото- рой разработан теоретический базис с использованием теории множеств. Базовой структурой РМД является отношение, основанное на декартовом произведении доменов. Домен – это множество значений, которое может при- нимать элемент данных (например, множество целых чисел, множество дат, множество комбинаций символов длиной N и т.п.). Домен может задаваться пе- речислением элементов, указанием диапазона значений, функцией и т.д. Пусть D1, D2 ,…, Dk – произвольные конечные и не обязательно различ- ные множества (домены). Декартово произведение этих множеств определяет- ся следующим образом: D1D2...Dk = {(d1, d2,..., dk) | di Di, i=1,…,k}. Таким образом, декартово произведение позволяет получить все возмож- ные комбинации значений элементов исходных множеств. Пример. Для доменов D1 = (1, 2), D2 = (A, B, C) декартово произведение D = D1D2 будет таким: D = {(1,A), (1,B), (1,C), (2,A), (2,B), (2,C)}. Подмножество декартова произведения доменов называется отношением. Отношение содержит данные о сущностях определённого типа. Поясним это на примере. Если построить произведение трёх доменов Должно-сти ('директор', 'бухгалтер', 'водитель', 'продавец'), Оклады (x | 20000x80000), Надбавки (1.1, 1.2, 1.3), то мы получим 4*60001*3=720012 комбинаций. Но ре- ально отношение «Штатное расписание» содержит по одной строке на каждую должность, т.е. является именно подмножеством декартова произведения доме- нов. Элементы отношения называют кортежами(или записями). Каждый кортеж отношения соответствует одному экземпляру сущности определённого типа. Элементы кортежа принято называть атрибутами(или полями). Свойства отношений Отношение обладает двумя основными свойствами: В отношении не должно быть одинаковых кортежей, т.к. это множество. Порядок кортежей в отношении несущественен. Таким образом, в отношении не бывает первого, второго или последнего кортежа: при выводе данных отношения кортежи выводятся в произвольном порядке, если не задано упорядочение по значениям полей. Отношение удобно представлять как таблицу, где строка является корте- жем, а столбец соответствует домену (рис. 2.7, отношение СТУДЕНТЫ). Коли- чество строк в таблице (кортежей в отношении) называется мощностью отно- шения, количество столбцов (атрибутов) – арностью.
Рис. 2.7. Пример табличной формы представления отношения Отношение имеет имя, которое отличает его от имён всех других отно- шений. Атрибутам реляционного отношения назначаются имена, уникальные в рамках отношения. Обращение к отношению происходит по его имени, а обра- щение к атрибуту – по имени отношения и имени атрибута. Каждый атрибут определён на некотором домене, несколько атрибутов отношения могут быть определены на одном и том же домене (например, номе- ра рабочего и домашнего телефонов). Домен задаётся типом данных, размером и ограничениями целостности: например, пол – это символьное поле длиной 1, которое может принимать значения из множества ('м', 'ж'). В реляционных ба- зах данных поддерживаются такие типы данных как символьный, числовой, да- та и некоторые другие (конкретный перечень типов зависит от СУБД). Атрибут может быть обязательным и необязательным. Значение обяза- тельного атрибута должно быть определено в момент внесения данных в БД. Если атрибут необязательный, то для таких случаев предусмотрено специаль- ное значение – NULL, которое можно интерпретировать как "неизвестное зна- чение". Значение NULL не привязано к определённому типу данных, т.е. может назначаться данным любых типов. Перечень атрибутов отношения с их типами данных и размерами опреде- ляют схему отношения. Отношения, построенные по одинаковой схеме, назы- вают односхемными; по различным схемам – разносхемными. Ключ отношения – это атрибут (группа атрибутов), значения которого классифицируют или идентифицируют кортеж. Например, значение атрибута Группаотношения СТУДЕНТЫпозволяет выделить среди всех студентов ин- ститута студентов конкретной группы. Если ключ состоит из нескольких атри- бутов, он называется составным. Если значения ключа уникальны в рамках столбца отношения, то такой ключ называется потенциальным. Потенциальных ключей может быть несколько (или не быть ни одного), но для отношения вы- деляется один основной ключ – первичный. Первичный ключ идентифициру- ет экземпляр сущности, его значение должно быть уникальным (unique) и обя- зательным (not null). (На рис. 2.7 первичный ключ выделен полужирным шриф- том). Неуникальные ключи ещё называют вторичными. РМД не поддерживает групповые отношения (по версии CODASYL). Для связей между отношениями используются внешние ключи. Внешний ключ (for-eign key) – это атрибут подчинённого (дочернего) отношения, который является копией первичного (primary key) или уникального (unique) ключа родительско- го отношения. (Пример – отношение ОЦЕНКИ, связанное с отношением СТУДЕНТЫвнешним ключом Номерзачётнойкнижки, рис. 2.8).
Рис. 2.8. Связь отношений "Оценки" и "Студенты" по внешнему ключу Если связь необязательная, то значение внешнего ключа может быть не- определённым (null). Внешний ключ – это ограничение целостности, в соответствии с которым множество значений внешнего ключа является подмножеством значений первичного или уникального ключа родительской таблицы. Фактически внешние ключи логически связывают экземпляры сущностей разных типов (родительской и подчинённой сущностей). Ограничение целостности по внешнему ключу проверяется в двух случаях: при добавлении записи в подчинённую таблицу СУБД проверяет, что в ро- дительской таблице есть запись с таким же значением первичного ключа; при удалении записи из родительской таблицы СУБД проверяет, что в под- чинённой таблице нет записей с таким же значением внешнего ключа. Примечание: внешний ключ может ссылаться на первичный ключ этой же таблицы. Это позволяет описывать унарную связь – иерархию однотипных сущностей. Например, если в таблицу СОТРУДНИКИдобавить поле Руководительи описать его как внеш- ний ключ на эту же таблицу, то в этом поле будет храниться идентификатор руково- дителя данного сотрудника (рис. 2.9). Атрибут Руководительявляется необязатель- ным.
Рис. 2.9. Внешний ключ "Руководитель", ссылающийся на первичный ключ этой же таблицы Все операции над данными в РМД выполняются над отношением и тре- буют задания имени отношения. Если операция применяется к части отноше- ния, то может потребоваться идентификация кортежа или группы кортежей и задание имён атрибутов. В РМД используются следующие операции: запомнить: внесение информации в БД (требует формирования значений уникального ключа и обязательных атрибутов кортежа); извлечь: чтение данных; обновить: модификация данных – изменение значений атрибутов кортежей; удалить: физическое или логическое удаление данных (кортежей). Структуризация данных в РМД существенно отличается от структуриза- ции данных по версии CODASYL (см. табл. 2.1). Таблица 2.1. Сравнение структуризации данных в РМД и по версии CODASYL
Примечание: в реляционной модели данных набор (групповое отношение) моделируется с помощью внешнего ключа, описывающего связь между двумя таблицами. 2.3.4. Достоинства и недостатки РМД Широкое распространение реляционной модели объясняется в первую очередь простотой представления и формирования базы данных, универсально- стью и удобством обработки данных, которая осуществляется с помощью де- кларативного языка запросов SQL (Structured Query Language, [2]). Моделирование предметной области в рамках реляционной модели со- здаёт некоторые сложности, т.к. в этой модели нет специальных средств для отображения различных типов связей и агрегатов. Отсутствие агрегатов приво- дит к тому, что при проектировании реляционной БД приходится проводить нормализацию отношений. После нормализации данные об одной сущности предметной области распределяются по нескольким таблицам, что усложняет работу с БД. (Подробнее об этом рассказано в разделе 9.9.7). Отсутствие специальных механизмов навигации (как в иерархической или сетевой моделях), с одной стороны, ведёт к упрощению модели, а с другой к многократному увеличению времени на извлечение данных, т.к. во многих случаях требуется просмотреть всё отношение для поиска нужных данных. В РМД нет понятий "режим включения" и "класс членства". Но с помо- щью внешних ключей и дополнительных возможностей СУБД их можно эму- лировать. Итак, реляционная модель данных – это модель данных, основанная на представлении данных в виде набора отношений, каждое из которых является подмножеством декартова произведения определённых множеств. Манипули- рование данными в РМД осуществляется с помощью операций реляционной алгебры (РА) или реляционного исчисления [1]. Реляционная алгебра основана на теории множеств, а реляционное исчисление базируется на математической логике (вернее, на исчислении предикатов первого порядка). Изучение реляци- онного исчисления выходит за рамки данного пособия, а операции реляцион- ной алгебры будут рассмотрены в следующей главе. Объектно-реляционная модель данных Объектно-реляционная модель данных (ОРМД) реализована с помощью реляционных таблиц, но включает объекты, аналогичные объектам в объектно- ориентированном программировании [3]. В ОРМД используются такие объект- но-ориентированные компоненты, как пользовательские типы данных, инкап- суляция, полиморфизм, наследование, переопределение методов и т.п. К сожалению, до настоящего времени разработчики не пришли к единому мнению о том, что должна обеспечивать ОРМД. В 1999 г. был принят стандарт SQL-99, а в 2003 г. вышел второй релиз этого стандарта, получивший название SQL-3, который определяет основные характеристики ОРМД. Но до сих пор объектно-реляционные модели, поддерживаемые различными производителями СУБД, существенно отличаются друг от друга. О перспективах этого направле- ния свидетельствует тот факт, что ведущие фирмы–производители СУБД, в числе которых Oracle, Informix, INGRES и др., расширили возможности своих продуктов до объектно-реляционной СУБД (ОРСУБД). В большинстве реализаций ОРМД объектами признаются агрегат и таб- лица (отношение), которая может входить в состав другой таблицы. Методы обработки данных представлены в виде хранимых процедур и триггеров, кото- рые являются процедурными объектами базы данных и связаны с таблицами. На концептуальном уровне все данные объектно-реляционной БД представле- ны в виде отношений, и ОРСУБД поддерживают язык SQL. Объектно-ориентированная модель данных Ещё один подход к построению БД – использование объектно- ориентированной модели данных (ООМД) [4]. Моделирование данных в ООМД базируется на понятии объекта. ООМД обычно применяется в сложных пред- метных областях, для моделирования которых не хватает функциональности реляционной модели (например, для систем автоматизации проектирования (САПР), издательских систем и т.п.). При создании объектно-ориентированных СУБД (ООСУБД) используют- ся разные методы, а именно: встраивание в объектно-ориентированный язык средств, предназначенных для работы с БД; расширение существующего языка работы с базами данных объектно- ориентированными функциями; создание объектно-ориентированных библиотек функций для работы с БД; создание нового языка и новой объектно-ориентированной модели данных. К достоинствам ООМД можно отнести широкие возможности моделиро- вания предметной области, выразительный язык запросов и высокую произво- дительность. Каждый объект в ООМД имеет уникальный идентификатор (OID object identifier). Обращение по OID происходит существенно быстрее, чем поиск в реляционной таблице. Среди недостатков ООМД следует отметить отсутствие общепринятой модели, недостаток опыта создания и эксплуатации ООБД, сложность исполь- зования и недостаточность средств защиты данных. В 2000 г. рабочая группа ODMG (Object Database Management Group), об- разованная фирмами-производителями ООСУБД, выпустила очередной стан- дарт (ODMG 3.0) для ООСУБД, в котором описана объектная модель, язык определения запросов, язык объектных запросов и связующие языки С++, Smalltalk и Java. Стандарты ODMG не являются официальными. Подход ODMG к стандартизации заключается в том, что после принятия очередной версии стандарта организациями-членами ODMG публикуется книга, в которой содер- жится текст стандарта. Теперь рассмотрим, как в реляционной модели данных реализован язык запросов к базам данных. ! Задания для практических занятий Тема: составление реляционных отношений Составить реляционные отношения для различных ПрО ("Отдел кадров": список должностей, список сотрудников, список под- разделений; "Магазин": список товаров, список поставщиков, список поставок; "Проектная организация": список отделов, список сотрудников, список проектов). Определить первичные ключи для созданных отношений. Определить внешние ключи для созданных отношений. "Границымоегоязыкаозначаютграницымоегомира". Людвиг Витгенштейн, англо-австрийский философ, логик | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||