1626434760-4c9f92f9ed5188f8fc024fed893742bb (844133), страница 14
Текст из файла (страница 14)
Целевые списки и выраженияПравильно построенные формулы обеспечивает только средстваформулирования условий выборки кортежей из отношений БД.Для определения набора имен атрибутов результирующегоотношения служат целевые списки (target lists).Целевой список строится из целевых элементов следующего вида:x.attr, где x – имя свободной переменной из ППФ, а attr – имяатрибута отношения, на котором определена x;x, что эквивалентно наличию подсписка x.attr1 ... x.attrn, гдеattr1 ...
attrn включает все имена атрибутов определяющегоотношения;new_name = x.attr, где new_name – новое имя соответствующегоатрибута результирующего отношения.Последний элемент требуется, когда в ППФ используется несколькосвободных переменных с одинаковой областью определения.29Реляционное исчислениеВыражение реляционного исчисления имеет видtarget_list WHERE ППФ.Значением такого выражения является отношение, тело которогоопределяется ППФ, а набор атрибутов и их имена – целевымсписком target_list.Пример: пусть мы имеем БД со схемойСОТРУДНИКИ (Сотр_Ном, Сотр_Имя, Сотр_Зарп, Отд_Ном)ОТДЕЛЫ (Отд_Ном, Отд_Кол, Отд_Нач).Требуется выдать имена и номера сотрудников, являющихсяначальниками отделов с количеством сотрудников больше 50.30Реляционное исчислениеВ терминах реляционной алгебры потребовалось бы выполнитьследующую последовательность операций:1)выполнить соединение отношений СОТРУДНИКИ и ОТДЕЛЫпо условию Сотр_Ном = Отд_Нач;2) ограничить полученное отношение по условию Отд_Кол >50;3) спроецировать результат операции на атрибуты Сотр_Ном иСотр_Имя.В терминах реляционного исчисления этот же запрос выглядитследующим образом:SELECT СОТР.Сотр_Ном, СОТР.Сотр_Имя WHEREEXISTS ОТД (ОТД.Отд_Нач = СОТР.Сотр_НомAND ОТД.Отд_Кол > 50),где RANGE СОТР IS СОТРУДНИКИ, а RANGE ОТД IS ОТДЕЛЫ.31Реляционное исчисление3.
Особенности исчисления доменовВисчислении доменов областью определения переменнойявляются не отношения, а домены. Например, переменныеИМЯ и НОМ_СОТР могут быть определены на доменахсоответственно атрибутов Сотр_Имя и Сотр_Ном.Основным формальным отличием исчисления доменов отисчисления кортежей является наличие в ППФ дополнительныхпредикатов, позволяющих выражать условия членства. Востальном формулы и выражения исчисления доменов похожина формулы и выражения исчисления кортежей.32Реляционное исчислениеЕсли R – это n-арное отношение с атрибутами a1 , a2 ,...
an , тоусловие членства имеет видR ( a1 : v1 , a2 : v2 , ... am : vm ) (m <= n),где vi - константа или доменная переменная.Условие членства истинно, если в отношении R существуеткортеж, содержащий указанные значения атрибутов.Исчисление доменов проиллюстрируем на примере следующегозапроса: Выдать номера и имена сотрудников,получающих зарплату больше минимальной.33Реляционное исчислениеДля простоты будем считать, что мы определили доменныепеременные, имена которых совпадают с именами атрибутовотношения СОТРУДНИКИ; если требуется несколькодоменных переменных, определенных на одном и том жедомене, мы будем добавлять в конце их имени цифры.
Тогдазапрос будет иметь вид:SELECT Сотр_Ном, Сотр_Имя WHEREEXISTS Сотр_Зарп1 ( СОТРУДНИКИ (Сотр_Зарп1)AND СОТРУДНИКИ (Сотр_Ном, Сотр_Имя, Сотр_Зарп)AND Сотр_Зарп > Сотр_Зарп1).Заметим, что на исчислении доменов базировался известный языкQuery-by-Example.34Проектирование реляционных баз данныхПри проектировании базы данных решаются две основныепроблемы:1) каким образом отобразить объекты предметнойобласти (далее – ПО) в абстрактные объекты моделиданных, чтобы это отображение не противоречилосемантике ПО и было наиболее эффективным;2) как обеспечить эффективность хранения базыданных и выполнения запросов к ней, т.е.
какрасположить данные во внешней памяти, какиедополнительные структуры (например индексныефайлы) создать и т.п.Первая задача известна как проблема логическогопроектирования БД, а вторая задача – как проблемафизического проектирования БД.1Проектирование реляционных баз данныхМы будем рассматривать только проблему логическогопроектирования БД и будем считать, что проектирование БДзаключается в принятии следующих решений:1) из каких отношений должна состоять БД,2) какие атрибуты должны быть у этих отношений.Проектирование баз данных будет выполнятся с использованиемнормализации.2Проектирование реляционных баз данных1. Основные понятияТак как РБД включает только нормализованные отношения,первый шаг перехода к РБД есть представление данных в виденормализованных отношений.Полученное таким образом отношение уже находится в первойнормальной форме (далее – НФ). Будем ее обозначать как НФ-1.Дальнейший процесс нормализации состоит в том, что некоторыеотношения, заданные в НФ-1, "расщепляются" на более простые.Причем сначала получается вторая нормальная форма (далее –НФ-2), а затем и третья нормальная форма (далее – НФ-3),обладающая лучшими свойствами, чем НФ-2.3Проектирование реляционных баз данныхЗачем нужна нормализация?1.
Нормализация нужна потому, что ни первая, ни втораянормальные формы не обеспечивают сохранности отношенийпри изменениях БД.2. Нормализация позволяет минимизировать избыточностьданных и число выполняемых над ними операций.Основные свойства нормальных форм:1) каждая следующая НФ в некотором смысле лучшепредыдущей,2) при переходе к следующей НФ свойства предыдущей НФсохраняются.Понятие НФ основывается на фундаментальном для РБД понятиифункциональной зависимости. Дадим несколько определений.4Проектирование реляционных баз данныхОпределение 1.
Функциональная зависимость.В отношении R атрибут B функционально зависит от атрибута A(A и B могут быть составными), если каждому значению атрибута Aсоответствует в точности одно значение атрибута B, т.е. имеетместо отображение R.A → R.B.(Если известно значение атрибута A, можно получить значениеатрибута B.)Определение 2. Полная функциональная зависимость.Атрибут (набор атрибутов) B полностью зависит от другого набораатрибутов A отношения R, если B функционально зависит отвсего множества A, но не зависит ни от какого подмножества A.5Проектирование реляционных баз данныхОпределение 3.
Транзитивная функциональная зависимость.Функциональная зависимость R.A → R.C называется транзитивной,если в отношении R существует такой атрибут B, что имеютместо зависимости R.A → R.B и R.B → R.C.ABCОпределение 4. Неключевой атрибут.Неключевым (неосновным) называется атрибут, не входящий всостав первичного ключа.6Проектирование реляционных баз данныхПример 1.СЛУЖАЩИЙ (Номер Сл, Имя_Сл, Зарплата,Номер_Проекта, Дата_Окончания).Функциональные зависимости отношения СЛУЖАЩИЙ :Номер СлИмя_СлЗарплатаНомер_ПроектаДата_Окончания7Проектирование реляционных баз данныхПример 2.Рассмотрим отношение ДЕЯТЕЛЬНОСТЬ_ПРОГРАММИСТА,первичный ключ которого состоит из двух атрибутов.ДЕЯТЕЛЬНОСТЬ_ПРОГРАММИСТА(Номер Программиста, Номер Программы,Имя_Программиста, Имя_Программы,Количество_Рабочих_Часов).8Проектирование реляционных баз данныхФункциональные зависимости отношенияДЕЯТЕЛЬНОСТЬ_ПРОГРАММИСТА заданы в предположении,что среди программистов нет однофамильцев и что двепрограммы не могут иметь одинаковых имен.Номер ПрограммистаНомер ПрограммыИмя_ПрограммистаИмя_ПрограммыКоличество_Рабочих_Часов9Проектирование реляционных баз данныхКомментарий к примерам.1.
В примере 1 все неключевые атрибуты полностью зависят отключевых (элементов возможного ключа).2. В примере 2 неключевой атрибут Количество_Рабочих_Часовполностью зависит от нескольких пар атрибутов (от первичногоключа и других пар).3. В примере 1 атрибут Дата_Окончания транзитивно зависит отатрибута Номер_Сл.10Проектирование реляционных баз данных2. Вторая нормальная формаОпределение 5. Вторая нормальная форма.Отношение R находится во второй нормальной форме, если ононаходится в первой нормальной форме и каждый неключевойатрибут полностью зависит от первичного ключа.Если в отношении R ключ содержит один атрибут, то этоотношение уже задано в НФ-2.
(См. отношение СЛУЖАЩИЙ впримере 1.) Нарушение условий НФ-2 приводит к ряду неудобств.Пример 3.Рассмотрим отношениеСОТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ (Сотр Номер, Про Номер,Сотр_Зарп, Отд_Номер, Сотр_Задан)11Проектирование реляционных баз данныхФункциональные зависимости отношенияСОТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫСотр НомерПро НомерСотр_ЗарпОтд_НомерСотр_Задан12Проектирование реляционных баз данныхВ отношении СОТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ неключевыеатрибуты Сотр_Зарп и Отд_Номер функционально зависят отчасти ключа, а именно от атрибута Сотр_Номер.В результате при выполнении операций возникают следующиесложности:1)нельзя вставить кортеж, описывающий сотрудника, еще невключенного ни в один проект, так как первичный ключ неможет содержать неопределенное значение;2) при удалении кортежа из отношения мы не только уничтожаемсвязь сотрудника с проектом, но и теряем информацию о егоотделе и зарплате;3) при переводе сотрудника в другой отдел потребуетсямодифицировать все кортежи, описывающие этого сотрудника.13Проектирование реляционных баз данныхЭти аномалии устраняются путем нормализации.
Можно,например, произвести следующую декомпозицию отношенияСОТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ на два отношения:СОТРУДНИКИ-ОТДЕЛЫ (Сотр Номер, Сотр_Зарп, Отд_Номер)СОТРУДНИКИ-ПРОЕКТЫ (Сотр Номер, Про Номер, Сотр_Задан)Функциональные зависимости этих отношений:СОТРУДНИКИ-ОТДЕЛЫСОТРУДНИКИ-ПРОЕКТЫСотр НомерСотр НомерСотр_ЗарпПро НомерОтд_НомерСотр_Задан14Проектирование реляционных баз данных3. Третья нормальная формаОпределение 6.
Третья нормальная форма.Отношение R находится в третьей нормальной форме, если ононаходится во второй нормальной форме и каждый неключевойатрибут нетранзитивно зависит от первичного ключа.Если отношение содержит транзитивные зависимости, ихнеобходимо устранить. Так, в примере 1 в отношенииСЛУЖАЩИЙ (Номер Сл, Имя_Сл, Зарплата,Номер_Проекта, Дата_Окончания)атрибут Дата_Окончания зависит от атрибута Номер_Проекта,который в свою очередь зависит от атрибута Номер_Сл.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
