Волк В.К. Базы данных. Практикум по проектированию, программированию и администрированию баз данных, включающий примеры и практические задания для самостоятельного выполнения
 Скачать 3.17 Mb.
|
|
2.4.1. Компоненты реляционной модели данных Логическая модель данных считается заданной, если определены три ее базовые составляющие: структурная, целостностная и манипуляционная. Структурная составляющая модели определяет множество допустимых структур данных логического уровня, обеспечивающих представление сущно- стей и связей ER-модели. Структуры данных должны поддерживаться на язы- ковом уровне, на них должны «работать» методы манипуляционной составля- ющей модели. Целостностная составляющая включает множество ограничений целост- ности данных, поддерживаемых серверами БД и обеспечивающих возможность автоматического контроля непротиворечивости и согласованности объектов БД при их модификации соответствующими запросами. Манипуляционная составляющая модели — это набор допустимых опе- раций, выполняемых над допустимыми структурами данных и обеспечивающих реализацию пользовательских запросов к базе данных. 2.4.2. Допустимые структуры данных Единственной структурой данных, допустимой в реляционной (R-) модели и используемой для представления сущностей, атрибутов и связей ER-модели, является отношение (relationship). По аналогии с языками программирования отношение можно рассматривать как структурированный тип данных, использу- емый для представления неупорядоченного множества кортежей, каждый из которых состоит из множества атрибутов соответствующих скалярных типов. Используют также и альтернативные наименования реляционных струк- тур: отношения называют таблицами или множествами записей, кортежи — строками или записями, а атрибуты кортежей — столбцами таблиц или поля- ми записей. Описание переменной типа отношение называется схемой отношения (со- ответственно — заголовком таблицы или описанием типа записи). Схема отношения описывает внутреннюю структуру всех входящих в не- го кортежей и включает список имен атрибутов этого отношения с указанием для каждого атрибута типа данных, домена допустимых значений и других ограничений целостности. Концепции типов данных и доменов допустимых значений атрибутов от- ношений будут рассмотрены ниже при обсуждении ограничений целостности реляционной модели данных. При обращении к атрибутам допускается исполь- зовать их двухуровневые имена (по аналогии с именами элементов структури- рованных типов данных в языках программирования), когда в качестве префик- са имени атрибута используется имя его отношения, например атрибут atr кор- тежей отношений R1 и R2 может быть обозначен соответственно как R1.atr и R2.atr. 2 / 19 22 Значение переменной типа отношение, называемое телом отношения, — это множество кортежей, структура которых соответствует схеме отношения. Каждый кортеж отношения представляет некоторый экземпляр соответствую- щей сущности, а значения атрибутов кортежа представляют свойства этого эк- земпляра. Язык SQL содержит операторы Create Table и Alter Table, используемые для определения и модификации схем отношений. Для модификации тела от- ношения используются SQL-операторы Insert, Delete и Update, определяющие состав кортежей тела отношения и значения их атрибутов. В определенном смысле эти операторы можно считать операторами присваивания значений пе- ременным типа отношение. Отношение характеризуется арностью и мощностью: арность — это ко- личество атрибутов в каждом из кортежей (соответственно столбцов в таблице или полей в записи), а мощность — это количество кортежей в теле отношения (строк в таблице или записей во множестве). 2.4.3. Ограничения целостности данных Обеспечение целостности базы данных в процессе ее эксплуатации — одна из важнейших функций СУБД, при этом под целостностью понимается сохранение согласованного и непротиворечивого состояния информации, хра- нимой в базе данных. Реляционная модель данных накладывает ограничения целостности двух видов: ограничения структурной целостности отдельных отношений базы данных и ограничения ссылочной целостности, обеспечивающие согласован- ность связей между ними. Структурная целостность отношений включает: • базовые ограничения целостности реляционной модели данных: − атомарность атрибутов; − уникальность кортежей отношения; • ограничения типов данных атрибутов отношений; • ограничения доменов допустимых значений атрибутов; • проверяемые ограничения, накладываемые на значения атрибутов. Атомарность атрибутов означает, что ни один из атрибутов отношения не может иметь никакой внутренней структуры, видимой пользователям и под- держиваемой СУБД 3 . В реализации требование атомарности атрибутов предпи- сывает использовать для атрибутов отношений исключительно скалярные типы данных, что позволяет считать отношение плоской таблицей. Требование уникальности кортежей запрещает наличие в теле отноше- ния кортежей-дубликатов. Такой «запрет» вытекает из определения отношения как множества кортежей — в классической теории множеств все элементы множества должны быть различными. 3 Для сравнения — записи сетевой модели CODASYL (рис. 1.5) могут иметь агрегированные поля, что, несомненно, является достоинством этой модели данных. 3 / 19 23 В реализации соблюдение этого ограничения требует наличия в схеме от- ношения первичного ключа — такого минимального подмножества атрибутов, составное значение которых не должно повторяться в разных кортежах и может использоваться в качестве уникального идентификатора кортежа. СУБД, полу- чив информацию о статусе «первичного ключа» некоторого атрибута отноше- ния, не допустит повторения его значений в различных кортежах, что, соб- ственно, и будет гарантировать отсутствие кортежей-дубликатов в теле отно- шения. Если в схеме отношения объективно присутствуют несколько таких уни- кальных идентификаторов (элементарных или составных), первичным ключом объявляется самый экономичный из них, а все остальные получают статус «возможного первичного ключа», сохраняя при этом свойство уникальности. Требование «экономичности» первичных ключей вытекает из способа ре- ализации связей (раздел 4.1) между отношениями реляционной базы данных, согласно которому схема одного из связываемых отношений дополняется атри- бутом — так называемым внешним ключом, в качестве которого используется копия первичного ключа другого отношения. Имеются и другие основания тре- бовать экономичности первичных ключей — одно из них связано с использова- нием индексных структур данных, в которых ключи многократно дублируются на различных уровнях индексных «деревьев». Если ни один из возможных первичных ключей не удовлетворяет требо- ванию экономичности, разработчик может дополнить схему отношения «искус- ственным» атрибутом «короткого» типа данных, присвоить этому атрибуту свойство уникальности и объявить его первичным ключом. Как правило, СУБД поддерживают «автоинкрементные» целочисленные типы данных, специально предназначенные для искусственных первичных ключей отношений, и автома- тически присваивают таким ключам очередные (или случайные) уникальные значения при вставке кортежей. Включение в схемы отношений искусственных первичных ключей, не ас- социированных ни с одним из свойств сущностей предметной области, и исполь- зование автоинкрементных типов данных для таких атрибутов считается хоро- шим стилем, так как избавляет разработчика базы данных от необходимости присваивать значения первичным ключам и контролировать их уникальность. Ограничение типов данных атрибутов отношения уже затрагивалось ранее при обсуждении их атомарности. Реляционные СУБД поддерживают множество скалярных типов данных — строковых, числовых, темпоральных и многих других. Ограничение типа данных трактуется здесь точно так же, как и в языках программирования — тип данных атрибута определяет низкоуров- невый формат его хранения, ограничивает множество потенциально возможных значений атрибута и набор допустимых операций по его обработке, а также блокирует возможность сравнения значений атрибутов разных типов. Ограничение домена позволяет более тонко разграничить значения атри- бутов одного типа: атрибуты отношений будут считаться сравнимыми, только если они принадлежат одному домену. При этом домен может рассматриваться как некоторый подтип базового типа данных. Например, пусть в схеме отноше- 4 / 19 24 ния Товарный_Склад определены атрибуты числового типа цена, количество и срок_хранения, принадлежащие соответственно к доменам Цены_товаров, Складской_запас и Сроки_реализации. Принадлежность этих атрибутов числовому типу данных формально поз- волит выполнять над ними различные математические операции: например, можно определить суммарную стоимость складского запаса определенного то- вара умножением его цены на количество или увеличить нормативный срок ре- ализации товара на 30 дней сложением атрибута срок_хранения с константой 30. Если не учитывать ограничения домена, формально возможными окажутся и любые логические операции сравнения значений этих «однотипных» атрибу- тов, в том числе и операции, не имеющие смысла. Ограничения домена позво- лят СУБД блокировать выполнение таких операций, например попытка сравне- ния значений атрибутов количество и срок_хранения будет заблокирована, так как эти атрибуты принадлежат разным доменам. Так называемые проверяемые ограничения (check constraints) представля- ют собой логические выражения, связываемые с некоторым атрибутом отноше- ния. СУБД будет автоматически контролировать истинность значения такого выражения при каждой модификации значения этого атрибута. Ссылочная целостность — это целостность схемы базы данных, пред- ставленной множеством схем отношений, кортежи которых могут быть связа- ны ссылками на значения их атрибутов — так называемых внешних ключей (раздел 4.1). Для обеспечения ссылочной целостностибазы данных СУБД должна контролировать соответствие типов данных и доменов, заданных для первич- ных и внешних ключей в схемах связываемых отношений, а также контролиро- вать соответствие значений этих ключей при выполнении любых операций мо- дификации связанных кортежей отношений. Концепции структурной и целостностной составляющих реляционной модели данных иллюстрируются листингом 1.3, на котором приведена SQL-реализация фрагмента схемы реляционной БД, описывающего контингент студентов. Операторами CREATE TABLE создаются схемы трех отношений (таблиц), представляющих три сущности предметной области: «Факультеты», «Студен- ческие группы» и «Студенты». В каждой из схем отношений определены первичные ключи (ограничение PRIMARY KEY) автоинкрементного (IDENTITY) типа. Ограничение UNIQUE задано для атрибутов, являющихся возможными ключами отношений. СУБД будет блокировать появление дубликатов значений этих атрибутов при вставке или модификации значений кортежей отношений. Ограничение NOT NULL не допускает неопределенных значений атри- бутов — если для атрибута не задано значение по умолчанию (DEFAULT), то СУБД выполнит откат операции вставки или модификации кортежей. Для атрибутов Groups.Year (год обучения студенческой группы) и Students.Rating (персональный рейтинг студента) заданы проверяемые ограничения 5 / 19 25 (CHECK CONSTRAINT), блокирующие возможность ошибочного ввода значений, выходящих за пределы заданных диапазонов. В схему отношения Students включен атрибут Group числового типа, для которого задано ограничение внешнего ключа FOREIGN KEY, обеспечивающее ссылочную целостность базы данных. Атрибут Students.Group ссылается (REFERENCES) на первичный ключ ID_Group родительского отношения Groups и совместим с ним по типу данных. Параметры этого ссылочного ограничения задают поведение СУБД при модификации кортежей родительского отношения. CREATE TABLE Departmets( ID_Dep INT IDENTITY PRIMARY KEY, DepShortName CHAR(4) NOT NULL UNIQUE, DepName VARCHAR(128) NOT NULL UNIQUE, DepAdress VARCHAR(128) NOT NULL DEFAULT «NoAdress»); CREATE TABLE Groups( ID_Group IDENTITY PRIMARY KEY, GroupName CHAR(8) NOT NULL UNIQUE, Year BYTE NOT NULL DEFAULT 1 CONSTRAINT LearningYears CHECK(BETWEEN 1 AND 6), Department INT FOREIGN KEY REFERENCES Departmets(ID_Dep) ON DELETE NO ACTION ON UPDATE CASCADE), Monitor INT NOT NULL FOREIGN KEY REFERENCES Students(ID_Stud) ON DELETE SET NULL ON UPDATE CASCADE); CREATE TABLE Students( ID_Stud IDENTITY PRIMARY KEY, StudName VARCHAR(32) NOT NULL DEFAULT «InvisibleStudient», StudAdress VARCHAR(128) NOT NULL DEFAULT «HomelessStudient»); Rating BYTE NOT NULL DEFAULT 0 CONSTRAINT PersonalRatings CHECK(BETWEEN 0 AND 100), Scholarship INT NOT NULL DEFAULT 0, Bonus INT NOT NULL DEFAULT 0, Group INT NOT NULL FOREIGN KEY REFERENCES Groups(ID_Group) ON DELETE NO ACTION ON UPDATE CASCADE); ALTER TABLE Students ADD CONSTRAINT MonitorBonus CHECK ( IF Students.ID_Stud IN (SELECT Groups.Monitor FROM Groups) Then Students.Bonus = 0.01 * Students.Scholarship * Students.Rating); Листинг 1.3 Примеры использования ограничений целостности 6 / 19 26 При изменении (ON UPDATE) значений первичного ключа ID_Group в каком-либо кортеже родительского отношения Groups соответственно обновляются (CASCADE) и значения внешнего ключа Group в кортежах дочернего (ссылающегося) отношения, связанных с измененным кортежем родительского отношения. Параметр NO ACTION этого ограничения означает, что при попытке удаления (ON DELETE) кортежа родительского отношения, в котором значение первичного ключа совпадает со значением внешнего ключа в дочернем отношении, СУБД выполнит откат операции удаления (семантически это блокирует удаление студенческой группы, пока в ней числятся студенты). Внешний ключ Monitor отношения Groups ссылается на первичный ключ ID_Studродительского отношения Students — эта ссылка определяет студентов, являющихся старостами соответствующих групп. При удалении (ON DELETE) из отношения Students кортежа, представляющего студента — старосту одной из групп, внешний ключ Monitor в соответствующем кортеже отношения Groups получит неопределенное значение (SET NULL), что соответствует реальной ситуации: при отчислении старосты студенческая группа на некоторое время может остаться без руководителя. Внешний ключ Department ссылается на первичный ключ ID_Dep отношения Departmets, что семантически отражает принадлежность студенческих групп факультетам университета и невозможность удаления факультета, пока на нем обучается хотя бы одна группа студентов. Оператором ALTER TABLE вносится изменение в схему отношения Students — добавляется проверяемое ограничение MonitorBonus на значение атрибута Bonus: при выполнении операций модификации кортежей отношения Students СУБД будет автоматически проверять значение этого атрибута на соответствие заданному ограничению (1% от размера стипендии Scholarship за каждый балл персонального рейтинга Rating каждому студенту, являющемуся старостой какой-либо группы). 2.4.4. Методы обработки данных Манипуляционная составляющая реляционной модели данных включает множество методов обработки отношений (единственных допустимых этой моделью структур данных), выполнение которых должно позволить реляцион- ной СУБД «вычислять» результаты реализации SQL-запросов к базе данных. В реляционной модели определены два базовых «механизма» реализации таких методов — это реляционная алгебра, основанная на теории множеств, и реляционное исчисление, основанное на математической логике. Реляционная алгебра оперирует понятием «алгебраическое выражение», а реляционное ис- числение — понятием «формула». Любой запрос к базе данных может быть записан либо алгебраически с помощью соответствующего реляционного вы- ражения, либо представлен формулой реляционного исчисления — оба этих представления эквивалентны в том смысле, что формула всегда может быть преобразована в соответствующее ей выражение, а выражение — в соответ- ствующую ему формулу. 7 / 19 27 И реляционно-алгебраическое выражение, и формула реляционного ис- числения «замкнуты» относительно понятия отношение — их операндами мо- гут быть только отношения, отношениями являются и результаты их вычисле- ния, что позволяет использовать выражения и формулы в качестве операндов других выражений или формул без ограничений глубины вложенности. В результате становится возможным описание очень сложного запроса к базе данных одним выражением реляционной алгебры или одной формулой реляци- онного исчисления, что позволяет говорить о большой выразительной мощно- сти двух этих базовых средств манипуляционного компонента реляционной модели данных, составляющих основу языка запросов. Реляционная алгебра представляет собой процедурный аспект языка SQL и позволяет задать последовательность выполнения логических операций, необ- ходимых для выполнения запроса, а реляционное исчисление дает инструмент для описания условий истинности результата исполнения запроса или ограниче- ния целостности, то есть поддерживает декларативный аспект этого языка. Язык запросов считается реляционно-полным, если одним его оператором можно описать любой запрос, представленный одним выражением реляцион- ной алгебры или одной формулой реляционного исчисления. Учитывая прикладной характер настоящего издания, ограничимся крат- ким обзором элементов реляционной алгебры Э. Кодда и реляционного исчис- ления кортежей в объеме, достаточном для понимания технологии нормализа- ции реляционной базы данных и освоения базовых конструкций языка SQL. Более фундаментально эти вопросы рассмотрены в [7]. 2.4.4.1. Реляционная алгебра Реляционная алгебра базируется на традиционных теоретико-множе- ственных операциях (пересечение, объединение, вычитание и декартово умножение) и дополнена четырьмя операциями (ограничение, проекция, деле- ние и соединение), специфичными для обработки реляционных данных. Все эти операции обрабатывают отношения, которые (по определению) являются множествами кортежей. Кроме этих операций, в реляционную алгебру включают операцию пере- именования атрибутов (AS), позволяющую корректно формировать схему (за- головок) результирующего отношения, и операцию присваивания (:=), позволя- ющую сохранять в базе данных результаты вычисления алгебраических выра- жений. Объединение R := R1 ∪ R2 — результирующее отношение R включает все кортежи, входящие хотя бы в одно из отношений-операндов R1 или R2. Пересечение R := R1 ∩ R2 — результирующее отношение R включает все кортежи, входящие в оба отношения-операнда R1 и R2. Вычитание R := R1 – R2 — результирующее отношение R включает все кортежи, входящие в отношение-операнд R1, такие, что ни один из них не вхо- дит в отношение-операнд R2. Расширенное декартово произведение R := R1R2 — кортежи результи- рующего отношения R производятся путем попарного соединения (конкатена- 8 / 19 28 ции, или сцепления) всех кортежей отношений-операндов R1 и R2. Арность ре- зультирующего отношения будет равной сумме арностей всех перемножаемых отношений-операндов, а мощность — произведению их мощностей. Операндами первых трех операций могут быть только совместимые от- ношения, то есть такие отношения, схемы которых (арность кортежей, имена и типы соответствующих атрибутов) одинаковы. Это ограничение объясняется тем, что результатом операций является отношение, а в отношении все кортежи должны иметь одинаковые схемы. Отношения-операнды, схемы которых отли- чаются только именами атрибутов, становятся полностью совместимыми после применения к ним операций переименования. Операция расширенного декартова произведения отношений применима к отношениям, схемы которых не имеют совпадающих атрибутов, и трактуется иначе, чем базовая теоретико-множественная операция декартова произведе- ния, результатом которой является множество пар элементов перемножаемых отношений. Реляционная модель не использует понятия «пара кортежей», и по этой причине реляционную операцию называют расширенным декартовым произведением. Эта операция не имеет какого-либо содержательного смысла и введена в состав манипуляционной составляющей модели по той причине, что через нее определяются действительно полезные специальные операции соеди- нения отношений. Ограничение R := R1 WHERE условие — результирующее отношение R включает подмножество кортежей отношения-операнда R1, удовлетворяющих заданному условию (любому корректному логическому выражению). Проекция R := R1 PROJECT список атрибутов — схема результирующего отношения R включает только те атрибуты исходного отношения R, которые включены в список атрибутов; если ни один из атрибутов этого списка не об- ладает свойством уникальности, в результирующем отношении потенциально возможны кортежи-дубликаты, которые (при их наличии) удаляются из резуль- тирующего отношения. Деление R := R1 DIVIDE BY R2 — бинарное отношение-операнд R1 делится на унарное отношение-операнд R2; результирующее унарное отношение R включает значения первого атрибута кортежей отношения R1 такие, что мно- жество значений второго атрибута кортежей этого отношения (при фиксиро- ванном значении первого атрибута) включает множество значений единствен- ного атрибута кортежей отношения R2. Соединение R:=R1 JOIN R2 ON условие — кортежи результирующего от- ношения R образуются путем соединения (конкатенации, или сцепления) кор- тежей отношений-операндов R1 и R2, удовлетворяющих заданному условию (любому корректному логическому выражению). Выполнение операции соеди- нения отношений можно рассматривать как операцию их расширенного декар- това произведения с последующей фильтрацией множества кортежей получен- ного промежуточного отношения по заданному условию. В манипуляционной составляющей реляционной модели определено не- сколько разновидностей операции соединения: 9 / 19 29 – внутреннее соединение (inner join) — соединяются только те кортежи отношений-операндов, для которых выполняется заданное условие; – левое (left join) и правое (right join) соединение — результирующее от- ношение будет безусловно содержать все кортежи левого (или соответственно правого) отношения-операнда, в том числе и те, для которых нет «пары» в дру- гом отношении-операнде, при этом «недостающие» атрибуты в таких кортежах результирующего отношения получат неопределенные NULL-значения; – внешнее соединение(foreign или outer join) — одновременно и левое, и правое соединение; – экви-соединение (equal join) — такое соединение, условие которого со- держит оператор сравнения «равно»; – естественное соединение (natural join) — экви-соединение двух отно- шений, имеющих одинаковые атрибуты (как правило, это первичный и внеш- ний ключи соединяемых отношений), равенство которых и является условием соединения кортежей (при этом совпадающий атрибут в схеме результирующе- го отношения не дублируется). В таблице 1.1 приведены примеры, иллюстрирующие применение опера- ций реляционной алгебры для реализации запросов к базе данных, моделирую- щей контингент студентов университета (листинг 1.3). Таблица 1.1 Примеры выражений реляционной алгебры № Выражение Результирующее отношение Семантика 1 1 st _Year_Groups:=Groups WHERE Group.Year = 1 Множество кортежей отноше- ния Groups, для которых атри- бут Year принимает значение, равное константе 1 Список групп сту- дентов первого года обучения 2 2 nd _Year_Good_Students:= (Groups INNER JOIN Students ON Groups.ID_Group = Students.Group) WHERE Groups.Year = 2 AND Student.Rating > 50% Множество кортежей отноше- ния, полученного в результате соединения отношений Students и Groups, для кото- рых атрибут Rating принимает значение, превышающее 50 Список студентов 2-го курса, имею- щих высокий рей- тинг (полная ин- формация о студен- тах и их группах) 3 2 nd _Year_Bad_Students := ((Groups INNER JOIN Students ON Groups.ID_Group = Students.Group) WHERE Groups.Year = 2 AND Students.Rating < 30%) PROJECT Groups.GroupName, Students.StudentName Бинарное отношение — про- екция отношения, полученно- го в результате соединения отношений Students и Groups, для которых атрибут Rating принимает значение, меньшее 50, на атрибуты GroupName и StudentName Список студентов 2-го курса, имею- щих низкий рей- тинг (только имя группы и имя сту- дента) 4 All_Group_Scolarships:= ((Groups INNER JOIN Students ON Groups.ID_Group = Students.Group) PROJECT Groups.GroupName, Stu- dents.Scolarship) DIVIDE BY (Students PROJECT Students.Scolarship) Результат операции деления — унарное отношение All_Group_Scolarships: список наименований тех групп, студенты которых получают стипендии всех возможных размеров 10 / 19 30 2.4.4.2. Реляционное исчисление кортежей Реляционное исчисление кортежей базируется на концепции правильно построенной формулы (WFF — Well Formed Formula), при построении которой используются кортежные переменные, предикаты и кванторы, и понятии це- левого списка (Target List), используемом для формирования схемы результи- рующего отношения, описанного такой формулой. Кортежные переменные Областью определения кортежной переменной является тело некоторого отношения базы данных, а ее допустимым значением может быть любой кор- теж этого отношения. Для именования и определения переменной будем ис- пользовать конструкцию RANGE переменная IS отношение, при этом перемен- ная наследует схему кортежа своего отношения и допускает обращение к лю- бому своему атрибуту по расширенному имени переменной: перемен- ная.имя_атрибута. WFF-формулы WFF-формулы используются для описания условий, накладываемых на значения кортежных переменных, и представляют собой логические выраже- ния, принимающие значения true или false. Логические выражения WFF-формул включают предикаты сравнения скалярных значений атрибутов переменных или констант, кванторы существо- вания EXISTS и всеобщности FORALL, а также операторы отрицания NOT, конъ- юнкции AND, дизъюнкции OR и импликации IF ... THEN с учетом их приоритетов и с возможностью расстановки скобок. WFF-формула вида EXISTS var (WFF-form) принимает значение true, если в области определения переменной var найдется хотя бы один кортеж, для кото- рого формула WFF-form принимает значение true. WFF-формула вида FORALL var (WFF-form) принимает значение true, если для всех кортежей переменной var формула WFF-form принимает значение true. Пусть на отношениях Groups и Students (листинг 1.3) заданы кортежные переменные: RANGE Group IS Groups иRANGE Student IS Students. Таблица 1.2 иллюстрирует области истинности и семантику результатов вычисления WFF-формул, заданных на этих кортежных переменных. Целевые списки Целевой список (Target List) — это список атрибутов кортежной пере- менной, образующих схему результирующего отношения, представленного WFF-формулой. Выражением реляционного исчисления кортежей называется конструкция вида target_list WHERE WFF-формула. Значением такого выраже- ния является отношение, схема которого определяется целевым списком target_list, а тело — областью истинности WFF-формулы. Следующие два выражения реляционного исчисления кортежей предпи- сывают сформировать тернарные отношения на базе WFF-формул, приведен- ной в примерах № 5 и 7 таблицы 1.2: 11 / 19 31 Groups.Group_Name, Groups.Year, Students.Stud_Name WHERE Groups.Monitor = Students.ID_Stud Groups.Group_Name, Groups.Year, Groups.Department WHERE FORALL Groups (Groups.ID_Group = Students.Group AND Students.Rating>50) Таблица 1.2 Примеры WFF-формул исчисления кортежей № WFF-формула Область истинности формулы Семантика 1 Group.Year = 1 Множество кортежей отноше- ния Groups, для которых атри- бут Year принимает значение, равное константе 1 Полная информация обо всех студенческих груп- пах первого года обучения 2 Group.Year > 1 AND Group.Year < 3 Множество кортежей отноше- ния Groups, для которых атри- бут Year принимает значение в заданном диапазоне Полная информация о группах 2-го курса 3 Student.Rating > 50% Множество кортежей отноше- ния Students, для которых ат- рибут Rating принимает значе- ние, превышающее 50 Полная информация о студентах, чей персональ- ный рейтинг больше 50% 4 Student.Scholarship = 0 Множество кортежей отноше- ния Students, для которых ат- рибут Scholarship принимает нулевое значение Полная информация о студентах, не получающих стипендию 5 Group.Monitor = Stu- dent.ID_Stud Множество пар кортежей от- ношений Groups и Students, для которых совпадают значе- ния указанных атрибутов Полная информация о студентах, являющихся старостами групп, и о группах, в которых эти студенты являются старо- стами 6 EXISTS Groups (Groups.ID_Group = Stu- dents.Group AND Stu- dents.Scholarships = 0) Множество кортежей отноше- ния Groups, связанных хотя бы с одним кортежем отношения Students, в котором атрибут Scholarship принимает нулевое значение Полная информация о группах, в которых имеет- ся хотя бы один студент, не получающий стипен- дию 7 FORALL Groups (Groups.ID_Group = Stu- dents.Group AND Stu- dents.Rating>50) Множество кортежей отноше- ния Groups, для которых во всех связанных с ними корте- жах отношения Students атри- бут Rating принимает значе- ние, большее 50 Полная информация о группах, все студенты ко- торых имеют персональ- ный рейтинг, превышаю- щий 50% Завершая обзор манипуляционной составляющей реляционной модели данных, отметим, что выражения реляционного исчисления, в отличие от вы- ражений реляционной алгебры, не определяют процедуры получения результи- рующего отношения, предоставляя СУБД самостоятельно принять соответ- ствующие процедурные решения. 12 / 19 32 Контрольные вопросы и задания 1. Перечислите структуры данных, допустимые в R-модели. 2. Каковы базовые ограничения целостности R-модели? 3. Поясните использование ограничений UNIQUE и PRIMARY KEY, накла- дываемых на значения атрибутов отношений. 4. Как может измениться арность и мощность отношения после примене- ния к нему операции проекции? 5. Определите зависимости арности и мощности результата перемноже- ния отношений от соответствующих параметров отношений-операндов. 6. Используя листинг 1.1 и данные таблиц 1.1 и 1.2, подготовьте соб- ственные примеры выражений реляционной алгебры и WFF-формул реляцион- ного исчисления кортежей. 2.5. Объектные модели данных Современный (постреляционный) этап развития АИС связан с использо- ванием объектно-ориентированных технологий разработки программных си- стем и созданием СУБД нового поколения, унаследовавших все лучшее от до- реляционных и реляционных систем. Постреляционные СУБД поддерживают объектные и объектно-реляционные модели данных и обеспечивают разработ- чикам возможность использовать объектно-ориентированные языки програм- мирования (такие, например, как C++, Java, Perl и Python), что дает таким си- стемам технологические преимущества по сравнению с реляционными СУБД. Рассмотрение объектно-ориентированных моделей данных выходит за рамки этого издания, поэтому приведем лишь два примера постреляционных СУБД, дающих представление о специфических особенностях таких систем. PostgreSQL[5] создавалась как классическая реляционная СУБД в рамках проекта POSTGRES, начало реализации проекта — 1986 г. В 1996 г. система была существенно переработана и получила свое современное название. В частности, была обеспечена совместимость со стандартом SQL92, расширен набор встроенных типов данных, а также оптимизирована система управления транзакциями (вместо блокировки таблиц было применено многоверсионное управление параллельным доступом), что позволило существенно повысить производительность системы. Были внесены изменения в модель данных (и соответствующие дополне- ния в диалект используемого системой языка PSQL), что, собственно, и позво- ляет считать PostgreSQL объектно-реляционной системой: например, появилась возможность определения отношения множественного наследования дочерни- ми таблицами атрибутов родительских таблиц. Постреляционная СУБД Cachè [20], первый выпуск которой состоялся в конце 1997 г., поддерживает транзакционную многомерную модель данных (TMDM), которая позволяет оптимально хранить данные в виде многомерных разреженных массивов, и представлять их так, как это требуется приложению. Cachè использует три альтернативных способа доступа к данным: прямой, объ- ектный и реляционный. 13 / 19 33 Прямой доступ к данным на уровне физической модели обеспечивает максимальную производительность и полный контроль со стороны программи- ста (подобно тому, как это было сделано в спецификации CODASYL) и позво- ляет создавать сверхбыстрые алгоритмы обработки данных. Объектный доступ к данным позволяет естественным образом использо- вать объектно-ориентированный подход как при моделировании предметной области, так и на этапе реализации. TMDM поддерживает объектную логиче- скую модель в полном соответствии с рекомендациями ODMG (множественное наследование, инкапсуляция и полиморфизм). Реляционный доступ с использованием встроенного Cachè-SQL позволяет Cachè успешно конкурировать с реляционными системами. Как только в систе- ме определяется класс объектов, сервер многомерных данных автоматически генерирует их реляционное описание, дающее возможность обращения к ним с использованием SQL. Аналогично при импорте в систему описания реляцион- ной БД этот сервер автоматически генерирует объектное описание данных, от- крывая тем самым доступ к ним как к объектам. При этом исключается дубли- рование данных, а все операции по редактированию проводятся только над од- ним экземпляром данных. Cachè позволяет разработчику комбинировать способы доступа к данным: например, для описания бизнес-логики приложения или создания пользова- тельского интерфейса АИС более эффективным может оказаться объектный доступ, реляционный доступ может использоваться для обеспечения совмести- мости и интеграции с инструментальными системами, использующими реляци- онные БД, а прямой доступ — для реализации операций, в которых применение серверных SQL-процедур не может обеспечить требуемую производительность. 14 / 19 34 15 / 19 35 ЧАСТЬ 2. ПРОЕКТИРОВАНИЕ БАЗ ДАННЫХ 16 / 19 36 Как уже отмечалось, база данных — лишь один из многих компонентов АИС и в этом смысле не является «самостоятельным» программным объектом, из чего следует, что проект БД всегда интегрирован в проект разрабатываемой АИС. Проектирование базы данных — многоэтапный процесс, реализация ко- торого связана с решением двух основных проблем, объединяемых понятиями логического и физического проектирования. В процессе логического проектирования разработчик решает задачу отоб- ражения реальных объектов и процессов предметной области в абстрактные объекты логической модели данных. Такое отображение должно быть семанти- чески адекватным моделируемой предметной области и при этом должно быть эффективным, технологичным и иметь соответствующую языковую поддержку средствами СУБД. Результаты физического проектирования базы данных должны обеспе- чить эффективное хранение данных на внешних запоминающих устройствах и высокую производительность реализации пользовательских запросов. На этом этапе решаются задачи отображения абстрактных объектов логической модели данных на объекты физической модели, поддерживаемые СУБД на файловом уровне, а также задачи формирования дополнительных структур данных (ин- дексов, статистик и пр.), обеспечивающих эффективную трансляцию языкового описания пользовательских запросов к базе данных и высокопроизводительный доступ к запрашиваемой информации. Стадии и результаты проекта базы данных приведены на рисунке 2.1. Основной задачейстадии технического задания является согласование требований к проектируемой АИС, в том числе и требований к обрабатываемой системой информации. На этой стадии проводится детальный анализ бизнес-процессов предмет- ной области АИС, по результатам которого выполняется ее функциональная де- композиция: классифицируются конечные пользователи, определяются их ро- левые функции в проектируемой системе, формируется структура информаци- онных сервисов, предоставляемых системой каждой категории пользователей, прорабатываются сценарии их взаимодействия. Результаты функциональной декомпозиции проектируемой АИС доку- ментируются и передаются для дальнейшей детализации разработчикам следу- ющей стадии проекта. Одним из способов документирования и графического представления функциональной структуры АИС на ранних стадиях проекта яв- ляется UML-диаграмма вариантов использования (называемая также UseCase- диаграммой и диаграммой прецедентов), дополненная описанием соответству- ющих сценариев. Модель АИС, сформированная на стадии технического задания, отражает пользовательские представления о работе проектируемой системы и называется внешней моделью (точнее — множеством внешних моделей, ассоциируемых с различными категориями пользователей). Внешняя модель является основой для объектной декомпозиции (структу- ризации) предметной области АИС, выполняемой на следующей стадии — ста- 17 / 19 37 дии эскизного проекта. В результате объектной декомпозиции формируется концептуальная модель, представляющая объекты предметной области, инфор- мация о которых существенна, то есть должна быть предъявлена пользователям АИС в результате выполнения запросов к базе данных. Концептуальная ER-модель (п. 1.3) описывается в системе терминов сущность, атрибут и связь. Рис. 2.1 Стадии проекта базы данных Если две начальные стадии проекта базы данных можно считать «доком- пьютерными» и не зависящими от программно-аппаратного обеспечения про- ектируемой АИС, то следующая стадия (стадия технического проекта) являет- ся первой из стадий программной реализации базы данных. На этой стадии концептуальная модель преобразуется в логическую модель данных и получает программную реализацию на некотором высокоуровневом языке, поддерживае- мом СУБД. Разумеется, к этому моменту разработчиками АИС уже должны быть приняты решения об общей архитектуре АИС, типе логической модели данных и выборе соответствующей СУБД. На завершающей стадии проекта (стадии рабочего проекта) СУБД транс- лирует логическую модель в низкоуровневую физическую модель данных и со- храняет параметры этой модели в системном каталоге БД. Настройка и оптими- зация параметров физической модели производятся администратором базы данных по результатам мониторинга работы пользователей АИС в процессе ее эксплуатации. Структура физической модели данных и средства ее оптимизации рас- смотрены в четвертой части данного учебника. 18 / 19 |