Шпоры 2

Определения.

БД-совокупн-ть спец. образом организ-ых данных, которые:

1подлежат длит-ому хранению на ВЗУ ЭВМ.

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

3исп-ся в одном или неск-их прилож-ях, относящ-ся к одной прикл-ой обл-ти.

1-ый пункт-имеется в виду память, которая не стирается. Жизненный цикл данных существенно > чем жизн. цикл проги обеспечения, которая с ним работает. 2-ой-это специф. св-во БД которое отличает их от др.типов инф-ых систем. Инф.Поиск. Сист: ситуация обратная, те кол-во классов объектов м.б. огромным, а кол-во экземпляров объектов- еденичным.

Категории БД.

В БД различ-ся логич. и физич. уровни описания.

Терминология физич. ур-ня: Поле-наименш. еденица инфы, которая идентифицир-ся СУБД на физич. ур-е. Осн.хар-ка поля-размеры (кол-во битов, байтов). Физич. запись-упорядоч-ая послед-ть фиксир. кол-ва полей. Две физич. записи считаются однотипными, если они состоят из одинаковой послед-ти полей. Файл-совокупн-ть однотипн. физ. записей. Для организации доступа к БД исп-ся индексные файлы различного типа: послед-ого доступа, связанные списки, файлы полного/упорядоч-ого индекса, инвертированные файлы… Блок-ед-ца обмена данными м/у ОП и ВЗУ.

Терминолог. лог. ур-ня: Эл-т данных (атрибут)-наименш. ед-ца инфы, идентифицир. СУБД с опред-ым типом и наименованием(на физич. ур-е - поле). Логич. запись-совокупн. фиксир. кол-ва различных эл-ов данных (физич. запись). Две логич. записи счит-ся однотипн-ми, если они состоят из одинак-го набора эл-ов данных. Отношения-совокупн. однотипн. логич. записей (класс объектов БД). Схема БД-совокупн. отношений с установл-ми связями и ограничениями целостности. Рассм. БД, содерж-ую три класса объектов:сотрудники, оборуд-е, раб. место (рис1) Традиционно индексные файлы исп-ся для реализац. связей на сх-ме и ограничений целост-ти. Из примера видно, что лог. ур-ень-это описание, а физ. ур-ень-это описание и представление.

Требования к БД.

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

2)Защита от програм-ых и аппаратных сбоев. Защита дан-ых должна обеспечивать СУБД и ничего больше. Виды сбоев:1логич.сбой а)если польз-ль пытается ввести свед-ия об объекте, однако эти свед-ия уже есть в БД, то СУБД по знач-ю ключ-ых полей должна идентиф-ть эти свед-я в базе и отвергнуть операц. дополн-я. б)если польз. пытается удалить свед-я о к/л объекте на который есть ссылки из др. объектов, то СУБД должна отвергнуть опер-ю. Этот вид ошибки наз-ся ссылочный целостн-тью дан-ых, либо ошибка 2-го рода. 2физ.сбой. Если по к/л причинам ОС прекратила свою работу, тогда пректр-ла работу СУБД и она могла не завершить к/л операции по преобраз-ю структуры БД, след-о часть дан. будет потеряна. Способы борьбы: 1)резервное кодиров-е 2)локальность модиф-щих воздействий. Структура осн. файлов БД д.б. такой, чтобы записи не зависели др. то др. Если записи в основном файле БД связ-ы в цепочку, то затирание одного указателя приведет к потере всех последних. 3)Ведение сист-ого журнала. Перед тем как вып-ть к/л действия в БД, СУБД помещает необх-ый объем в инфы в буф-ый файл на диске, этой инфы достаточно, чтобы завершить опер-ии преобраз-я после повторного запуска СУБД. 3)Независимость данных. Прикладной прогой будем наз-ть прогу пользов-ля, реализ-ую к/л ф-ию, и взаимод-ую с БД при своей работе. Пр: расчет з/п. Програмн-е обеспечение наз-ся мобильным, если его исходн. код не зависит от ОС и аппаратуры. Если прикл. прога явл-ся мобильн, не зависит от места и способа располож-я данных в БД такая прога удовлет-ет принципу независ-ти данных. Для обесп-я возможности реализ-ии принципа незав-ти дан-х рабочей группой CODACYL была разраб-на и рекоменд-на к исп-ю трехуровневая модель опис-я и представл-я дан-х в БД. 1)уровень: Физич.описание и представл-е дан-х. Кроме собственно дан-х на ур-е содержатся сведения о структуре осн. файлов БД, опис-ие свободн. отведе-ого пространства, обл-ти переполнения, опис-е структуры индексных файлов, те ур-нь содержит инфу необход-ю для преобраз-я значения поискового ключа в адреса физич. записей. 2)глоб-ое опис-е дан-х (концептуальная модель дан-х) Содеж. опис-е схемы БД- перечень отношений с указанием первичных ключей, связи м/у отнош-ми, огранич-я целостности. Не содерж-ся свед-ий о месте и способе исп-я дан-х. 3) внешние схемы. Кажд. отдельн-я сх-а содержит опис-е дан-х в том виде, в котором они должны быть представлены в конкретн. приложении, кроме того внешн. сх. дополняются паролем доступа. Наиболее подвержены изменениям при эксплуатации БД 1-ый и 3-ий ур-ни. Пр: изменен. индексации, разнесение дан. на различн. сервера. От всех физ. измен-ий не должна пострадать ни одна прикладн. прога. Изменения происход. во внеш. среде должны касаться одного прилож-я и не касаться др. Второй ур-нь несет ответственность за стабилиз-ию работы системы.

4)Защита от несанкционир. доступа. 1-ый ур-нь защиты обеспечив-ся паролем доступа во внешн. сх-ы. Если пользов-ль имеет возможн-ть, минуя СУБД обратиться напрямую к файлам БД, то примен-ся 2-ой ур-нь защиты, обеспечив-мый ОС защиты своей файл-й структуры. В случае необх-и дополнит. защиты исп-ся 3-ий ур-нь: шифрование.

Системы упр-я БД.

СУБД-прога, роботающ-я под упр-ем ОС и вып-ая след-ие ф-ии:

1)обмен управл-ми воздействиями с прикладн-ми прогами и ОС в процессе передачи дан-х из БД в прикл-е проги и обратно.

2)преобраз-е дан-х в сист-ых буферах в соотв-ии с описанием внешн-х сх-м.

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

Схема функц-ия СУБД.

Порядок вып-я операций при чтении дан-х из БД:<=> -потоки дан-х <-> - управл-ие воздейств-я. (рис1)

Шаг1)Прикладн. прога формирует запрос соответст-его типа при необход-ти дополняет ее паролем и указ-ет имя внешн. сх. и передает все это в БД. 2)СУБД по имени выбирает описание венешн. сх. при необх-ти проверяет пароль.

3)СУБД анализирует глобальн. лог-ое опис-е, определяет набор отнош-ий, которые будут участвовать в реализ-ии запроса. На этом этапе СУБД может формально выполнять оптимиз-ю запроса.

4)СУБД анализ-ет физ-ое опис-е дан-х и опред-ет набор основн. файлов БД и набор индексн-х файлов, которые будут участвовать в реализ-ии запросов. На этом ур-е вып-ся физич. оптимиз-я запросов.

5)СУБД формирует послед-ть команд GET PUT и передает их ОС.

6)ОС вып-ет переданные команды, перекачивает дан-е из БД в сисит-е буфера (находятся в операт. памяти)

7)СУБД в соотв-ии с опис-ем внешн. схем преобразует дан-е (в сист буферах) при необх. формирует новые команды чтения/записи и возвращ-ся на шаг5)

8)СУБД перекачивает дан-е из сист-х буферов в рабочую область прикладной прогии передает ей управл-е. Замечание: Посл-ть действий при записи дан-х в БД аналогичная, только поток дан-х идет в обратную сторону.

Языковые ср-ва для работы с БД.

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

1)Язык опис-я дан-х предназначен для формир-ия внешних схем схемы БД, для формир-я физ. опис-я.

2)Язык манипулир-ия дан-ми предназначен дя вып-я операций чтение (поиск), доплнение, удаление, модифик-ия.

Способы реализ-ии ЯОД и ЯМД. 1)В кач-ве расширения традиц-го языка прогр-ия а)ЯОД и ЯМД релиз-ся библиотечными процед-ми: CALL-интерфейс, ЯМД VISTA б)Расшир-е традиц. языка прогр-я синтаксически правильными констукциями ЯОД и ЯМД: ADABAS для IBM-370 в)Независ-е компоненты на спец. языке вставляются в проги на традиц. языке. При этом треб-ся претрансляция которая переводит вставки в синтаксически правильн-е конструкции языка ЯОД:VISTA. 2)ЯОД и ЯМД явл-ся неотемлемой частью СУБД, в этом случае ЯОД и ЯМД расширяются операторами традиц-го прогр-ия: dBase, FoxPro 3)ЯМД и ЯОД независ-ы не от языка прогр-ия не от СУБД в этом случ. требуется стандарт на ЯОД и ЯМД: стандарт SQL

Глобальн-е лог-е опис-е.

Недостатками декомпозиц-го подхода явл-ся: 1)невозможность решить проблему синонимов, анонимов и антонимов

2)неоднозначно определение понятий объект и связь. 3)невозможность решения проблемы общих данных, дан-х пересечения и изолир-ых дан-х. При построении БД мы будем пользов-ся декомпоз-ей, доведенной до атомарных компонентов дан-х с послед-им синтезом. Модель сущность-связь будет явл-ся результатом синтеза, а не декомпоз-ии.

Элементы данных и связи.

Элем-ом дан-х наз-ся поименованная атомарная (неделимая) данная с опред. типом (таб. номер сотрудника) (ФИО сотрудника) тип эл-ов дан-х опред-ся при отображ-ии эл-ов на физ. ур-нь. Пр. случаев неправильного пред-я понятия эл-т дан-х: 1)(цех) в этом случае отсутствует однозначная семантическая интерпретация эл-ов дан-х, не ясно какие знач-я должен принимать этот эл-т данных. Наименование Эл-та дан-х должно полностью определять его семантику. 2)(средняя зарплата в отделе) в БД вместо этого эл-та нужно хранить элемент-ые выплаты каждому сотруднику, а средн, max, min должны вычисл-ть прикл-ые проги. 3)(возраст пациента)->(дата рожд) в прикладн. обл-ти не возникает события которое было бы побудит-ой причиной для изменения значения этого эл-та дан-х. 3)(стаж работы)->(дата потупл-я на раб)+(стаж до поступл на раб) Элемент дан-х не явл-ся изменяемым тк студенты переводятся по приказу (номер курся обуч. студента) В БД допускается исп-ие составных эл-ов дан-х, если колич-во вход-их в них эл-ов фиксировано и знач-ия их взаимозависимы, такой эл-т дан-х наз-ся агрегатом Пр:дата. Связи устанавлив-ся м/у эл-ми дан-х и отражают колич-ое соотнесение значений связ-ых эл-ов дан-х. Никакого содержания связей не должно быть. Связь изображается в виде дуги м/у двумя эл-ми дан-х и явл-ся направленной (рис1)

Типы связей.

1)1:1 один к одному. одному знач-ю первого эл-та дан-х соотв-ет не более одного знач-я второго эл-та дан-х (рис1) обычно такие эл-ты явл-ся эквивалентными ключами. 2)М:1 многие к одному множ-ву значений первого эл-та дан-х соотв-ет не более одного знач-ия второго эл-та дан-х (рис2) М={0,1,2,…} 3)1:М один ко многим одному знач-ю первого эл-та сосотв-ет множ-во знач-ей второго эл-та данных (рис3) 4)М:М многие ко многим множ-ву знач-ий первого эл. дан. соотв-ет множ-во знач-ий второго эл-та дан-х (рис4) Замечания: Связи на сх-е первого и второго типа изображ-ся на дуге в виде одиночной стрелки, а связи на сх. третьего и четвертого в виде сдвоенной. Если связи м/у эл-ми дан-х устанавлив-ся в обе стороны, то соотв-щие стрелки изображ-тся на одной дуге (рис5) при установлении связи была введена семантика этих связей (смысловая нагрузка). При появл-ии семантики на связи вводим дополнит. эл-т дан-х с этой семантикой (рис6). Связи на схеме м/у двумя эл-ми дан-х явл-ся избыточными, если от одного эл-та дан-х к др-му имеются неск-ко простых путей (по одиночным стрелкам) (рис7) Правило преобраз-я: Удаляются все короткие пути,остается самый длинный путь. Совокупность эл-ов дан-х с установл-ми связями (избыт. удалены) называется овал-диаграммой. Правило склейки записи:Если от эл-та дан-х А к эл-у дан-х В установлена связь первого или второго типа, то эл-т дан-х В присоединяется к эл-у дан-х А, образуя при этом лог-ую запись ключем которой явл-ся эл-т дан-х А (рис8)

Классификация моделей наборов дан-х. В БД различают 3 осн-ых класса моделей данных: 1)сетевые 2)иерархические 3)реляционные. По правилу склейки из овал-диаграммы почти всегда будет получена сетевая модель, реже-иерархич-ая, редко-реляцион-я. Существуют алгоритмы, которые позволяют преобрз-ть сетевую модель к иерархич-му виду; иерархич. к реляц. и сетевую к реляц-му.

Иерархическике (древовидные) модели дан-х. Деревом наз-ся множ-во узлов, среди которых есть один узел, назыв-ый корнем, остальные узлы находятся в попарнонепересекающ-ся множ-ах, каждое из которых явл-ся деревом. (рис1) 1-корень, 4, 5, 6, 7, 8-листья, (1-2-5), (1-3-8)-max пути, (1-4)-min путь, 2, 3, 4-семейство порожденное эл-ом один, 7, 8, 9-семейство порожд-е эл-ом три, 7 и 9-левый и правый сосед эл.восемь, 7-узел не имеет левого соседа, 9-узел не имеет правого соседа. Замечание: В иерарх. системе БД стрелки на связях сх. м.б. опущены, поскольку подразумевается связь 1:М от предка к потомку. Дерево наз-ся сбалансир-ым, если каждый узел, кроме листа имеет одинаковое число потомков и разница м/у maх и min путем не ревышает 1.(рис2)-сбалансир-е (рис3)-несбалансир-е. Дерево наз-ся бинарным, если каждый его узел имеет не более двух потомков (рис4) Замечание: Очень малое колич-во областей м.б. представлено бинарной сбалансир. моделью дан-х Пр: родословная собаки. Осн. назначение бинар. сбаланс деревьев в БД–организ-я методов доступа к данным на физ. ур-е.

Зависимость дан. от структуры.(рис1)

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

Сетевые модели дан-х.

Если в сх. БД хотябы один узел имеет более одного предка (есть связь М:М), либо из одного узла вых-ят две одиночн-е стрелки, то модель дан-х наз-ся сетевой. (рис1) Связи, установл-ые на сх-е, говорят о том, что один поставщик поставл-ет множ-во изделий, однако кажд-е изд-е поставл-ся только одним поставщиком. Кажд-й потреб-ль приобретает множ-во изделий и также кажд. изделие приобрет-ся только одним потреб-ем. Сх. БД наз-ся простой сетевой моделью, если на ней отсутствует связь типа M:M. В противном случае- сложной сетевой моделью. На физ. ур-е связь типа М:М потребует множественные перекрестные ссылки, поэтому необходимо избавится от этой связи. Правила преобраз-я: Допустим м/у двумя лог-ми записями на схеме установлена связь М:М, тогда формируем новую лог. запись, содерж-ую ключевые поля исходн. двух записей, связь М:М удаляем из сх и м/у двумя старыми лог-ми записями и вновь введенной устнавливаем две связи типа 1:М (рис2)

Общие данные.

Элемент дан-х на сх-е наз-ся общим данным, если к нему приходит сразу неск-ко одиноч-ых стрелок. По правилам склейки они м.б. присоеденены сразу к неск-им лог-им записям. Правило преобраз-я: Формир-ся новая лог-ая запись, содержащая ключевые поля записей, откуда приходят одиночные стрелки, и общ-е данные присоед-ся к введенной лог. записи. Семантика общ. данного при таком преобраз-ии изменяется, она детализ-ся. Поэтому к вновь введ-ой лог-ой записи будут приходить связи со сдвоенными стрелками. От вновь введенной лог. записи к существующей записи (откуда приходили одиночные стредки) устанавливается связь типа М:1 (рис1) Для удаления связи типа М:М и для решения проблемы общего данного было исп-но одно и то же преобраз-е. Теперь колич-во изделий конкретного вида на складе поставлено конкретным поставщиком.

Данные пересечения.

Эл-т данных на схеме наз-ся данным пересечения, если по правилу склейки его нельзя присоеденить ни к одной лог-ой записи (приходят только сдвоенные стрелки), однако его значение однозначно определ-ся значениями ключевых полей, откуда приходят сдвоенные стрелки. Правила преобраз-я: Создается новый тип записи, содерж-ий ключевые поля записей, откуда данные пересечения присоед-ся к этому типу записи (рис1)

Изолированные данные.

Элемент данных на схеме наз-ся изолир-ым, если он по правилу склейки не м.б. присоед-ен ни к какой лог. записи и ключевые поля записей, откуда приходят сдвоен-е стрелки, однозначно не идентифицирует его знач-е. Рекомендация: Обычно изолир-е данные явл-ся характеристикой объекта, для которого отсутствует однозначная идентифик-ия в схеме БД. Необходимо ввести искусственный ключ для этого класса объектов, и после восстановл-ия этих связей повторить преобраз-я схем. Для примера к имеющ-ся сх-е данных данные «наименование потребителя» И после установл-я связей и преобраз-я появится два класса объектов: «потребители», «потребление».

Преобраз-е сетевых моделей к иерархич. виду. Правила преобраз-я: Если к/л лог. запись на схеме имеет более одного порядка, то создается столько дублей этой записи, сколько у нее порядков. Однако все дубли, кроме исходн. записей будут содержать только ключевые поля (рис1) получена сх (рис2) Впервые такое преобраз-е было реализ-о для СУБД ISM IBM класс моделей, которые поддерживет СУБД, двухур-вые иерархич. модели. Для структур-х моделей данных логич. запись осущ-ся за счет операторов навигации. И если лог. запись имеет более двух подобных, то оператор «плучить предка» становится неоднозначным. XML-расшир-ый язык разметки документов, в своей основе имеет иерархич. структуру.

Реляционные модели данных.

Табличное представление данных назыв-ся реляционным, если выполнены след. усл-я:

1) в таблице не м.б. двух картежей с одинаковым содержанием

2) все знач-я в столбце любой таблицы явл-ся однородными те отображают одну и ту же хар-ку картежа.

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

4) кажд. таблица в сх-е описания данных должна иметь уникальное имя

5) кажд. элемент таблицы д.б. элементом дан-х либо агрегатом данных

6) связи на сх устанавлив-ся только за счет одноименных данных в таблице. Реляционные от англ. отношения. Область опред-ия атрибута элемента данных наз-ся доменом (Dom(Aj)). Таблица, состоящая из двух столбцов-бинарная, из 3-тернарная, из n-n-арная. Таблица, удовлетвор-ая перечисленным требованиям, находится в 1НФ.

Преобраз-е структурир-х моделей данных к реляц. виду. Правила преобраз-я: Если м/у двумя лог. записями установл. связь 1:М, то ключ-е поле 1-го типа записи дополняется во 2-ой тип записи и становится неключевым. Если м/у двумя типами записи установл. связь М:М,то формируем новый тип записи, содерж-ий только ключ. поля исходн. записей; связь М:М удаляется из записи, от старых типов записи к новому устанав-ся связь 1:М (рис1) Замечания: При дополн-ии новых сведений в структурир-ую модель мы из иерархич. модели получим сетевую. Прикладные проги, работающие с этой сх, перепис-ся, поскольку операторы навигации будут работать неверно. При модификац. реляц. сх, дополнилась нов таблица и старые прикладн. проги будут работать с новой сх. Вывод: реляц. модели наиболее полно реализуют принцип назавис-ти данных.

Базисный набор операций.

Операндами являются реляционные табл. Ri арности ki(столбцы) и кол. строк ni.

1.Объединение R=R₁ U R2 рез-т содерж. картежи из R1 и те картежи из R2, которых нет в R1. общ. огранич-е k₁=k₂. Треб-ся совпад. схем(одинак заголовки)

R₁=A|B|C R₂=A|B|C R1UR2=A|B|C

a₁|b₁|c₁ a₂|b₁|c₁ a₁|b₁|c₁

a₂|b₁|c₁ a₃|b₂|c₂ a₂|b₁|c₁

a₃|b₂|c₂ a₃|b₂|c₂

a₂|b₂|c₁

SQL-UNION

2.Вычитание R= R₁ \ R₂ в рез-т попад. те картежи из R₁, которых нет в R₂. Огранич. совпадение схем.

R=R₁\R₂=A|B|C

a₁|b₁|c₁

a₂|b₁|c₁

SQL-DELETE

3.Декартово произведение R= R₁ × R₂

Каждый картеж из R₁ состав-ся с каждым картежем из R₂ и рез-т составления запис-ся в табл. Одноимен. атриб. в результирующей. табл. имеют расшир. имена

R₁=A|B|C R₂=B|C|D

a₁|b₁|c₁ b₁|c₁|d₁

a₂|b₁|c₁ b₂|c₁|d₂

a₃|b₂|c₂

k=k₁+k₂

n=n₁*n₂

SQL-SELECT * FROM R₁,R₂

4.Селекция R=σ_F(R₁)

F-логическое выражение, заданное над атриб. из R₁ Атомарное условие <имя атриб>θ<значение>, где θ Є{=,≠,>,<,≥,≤} атомарные условия связ-ся ф-ми {^,v,¬} В результир. табл. R попад. те картежи из R₁, которые при подставлении в форм-лу F дают знач. «истина»

σ_A≠a2^C=c1(R₁)=A|B|C

a₁|b₁|c₁

Вырезка из таблицы по строкам

SQL-SELECT*FROM R₁ WHERE F

5.Проекция R=π_x(R₁), где х-мн-во атриб., явл. подмнож. атр. из R₁.

В рез-т запис-ся картежи, сост-ые из знач. атриб. х исходных картежей из R₁. В рез-те не д/б дублир. картежей

π_B,C(R₁)=B|C

b₁|c₁

b₂|c₂

Вырезка из таблиц по столбцам.

SQL-SELECT DISTINCT * FROM R₁

Дополнительные операции РА

1. пересечение R₁∩R₂=R₁\(R₁\R₂)

2 соединение

R₁►◄R₂ =σ_{R1.A θ R2.B}(R₁×R₂)

R1.A θ R2.B

Каждый картеж из R₁ сост-ся с каждым картежем из R₂. Получ. картеж подстав. в форм-лу, и если значение «истина», то получ. картеж запис-ся в рез-т.

3.Эквисоединение-частн. случай соедин-ия, когда θ-оператор «=»

4.Естеств-ое соедин-ие R=R₁►◄R₂= π_R1UR2(σ _{Λ (i=1..N) R1.Ai=R2.Ai} (R₁×R₂))

Каждый картеж из R₁ сопост-ся с каждым картежем из R₂. Если знач. всех одноим. атр. в картеже совпад., то формир-ся новый картеж, в котором знач. одноим. атрибутов в единств. экз.

R=A|B|C|D

a₁|b₁|c₁|d₁

a₂|b₁|c₁|d₁

R1►◄R2=

π_R1UR2 σ _{Λ (i=1..N) R1.Ai=R2.Ai} (R1×R2)

Свойства операций реляц. алгебры.

1)коммутативность R1×R2=R2×R1, R1►◄R2=R2►◄R1

2)ассоциативность (R1×R2)×R3=R1×(R2× R3), (R1►◄R2)►◄R3=R1►◄(R2►◄ R3)

3)св-во операций проекций π_X(R1×R2)= π_X1(R1)×π_X2(R2), x1=X∩R1-множ. атриб. входящих в R1. x2=X∩R2, π_X(R1►◄R2)= π_X(π_X1(R1)►◄π_X2(R2)), x1=(x∩R1)U(R1∩ R2), x2=(x∩R2)U(R1∩R2)

4)cв-во селекции σ_F(R1×R2)=σ_F1(R1)× σ_F2(R2), σ_F(R1►◄R2)=σ_F1(R1)►◄ σ_F2(R2) формула F1 определена на атрибутах из R1: F=F1ΛF2. Замечание: Св-во операц. РА исп-ся для формальн. оптимизации запроса по след. правилам:

1)операц. проекции должна выполняться раньше чем декартово произвед. и естеств. соединен.

2)опер. селекции вып-ся раньше чем декарт. произвед. и естеств. соед.

3)операц. селекц. и проекции должны выполнятся совместно

Функциональные зависимости.

Дано: сх отношений R, опред. на множ-ве атрибутов U={A1,…,An}, r- реализация сх R. Картеж tЄr ,тогда t[x]=π_X(t) берем произвольн. картеж t и из него выбираем значения соотв-ее атрибутам х.

Определение: Множ-во атрибутов х функцион-но опред-ет множ-во атрибутов y ,где x,yCU, елси для любой реализации r схемы R выполнено:

Пусть t1 и t2 Єr и t1[x]=t2[x], тогда t1[y]=t2[y]. X->Y X,YCU r t1,t2Єr и t1[x]= t2[x]=>t1[y]=t2[y]

Замечание: Функцион-ые завис-ти- основной вид ограничений целостности в БД, которые не м.б. определены никакими алгоритмич. способомами.

Свойства функц. завис-ей.

Дано: схема отношения R определ. на множ-ве U={A1,…,An} и F- множ-во функцион-ых зависимостей.

1)правило лог. следствия (транзитивность) Если X определяет Y (X->Y) и Y->Z ,то Х функционально определяет Z. Доказ-во: предположим,

что выполнены два условия X->Y, Y->Z, а X->Z не выполнено

r t1,t2 t1[x]=t2[x], t1[z]≠t2[z]

1 ситуация t1[y]=t2[y] => Y не->Z

2 ситуация t1[y]≠t2[y] => X не->Y получм,

что завис. выполнена.

2)рефлексия Если Y подмнож. Х, то завис. X->Y всегда выполнена.

3)пополнение Пусть X->Y и ZCU, тогда XZ->YZ, где XZ=XUZ.

Определение: Множ-во всех функц-ых зависимостей, выводимых из исходного множ-ва F посредствам свойств, называется замыканием множ-ва функциональн. завис-ей и обозначается F⁺

Множ-во атрибутов х явл-ся первичным ключем для отношения R, определен. на множ. атрибутов U={A1…An}, если X-> A1..AnЄF⁺

Не существует множ. Y не явл-ся истиннм подмнож-ом Х такого что завис-ть Y->A1..AnЄF⁺ принадлежит замыканию всех функциональных завис-ей.

Рекомендации при анализе получ-ой схемы БД:

1)Строим обобщенный ключ для всего множ-ва атрибутов U={A₁…A_N} Обозначим его Х- набор атрибутов, из которых выводятся остальные атрибуты. По построению внутри множ-ва атрибутов Х не д.б. никаких функц-ых завис-ей. Проблемы:1 Получ-ый набор атрибутов Х не явл-ся интерпретир-ым (не возможн. присвоить наименов-ие таблице, состоящей из атрибутов Х. Решение: Во множ-е Х имеются потерянные функц-ые завис-ти. Неверное опред-ие семантики атрибутов, входящих во множ-во Х. Внутри множ-ва Х имеется многозначная завис-ть 2 Ключ оказ-ся нетехнолог-ым Решение:заменить схему документооборота на предприятии.

2) Проверяем схему БД и если в к/л отношении мн-ва атрибутов Х содерж-ся целиком, то схема БД построена. В противном случ. схему БД дополняем нов. отнош-ми. Если атрибуты из Х содержат многозначную зав-ть: W->>V(Z) пример: (рис1) Признак наличия многозначн. зав-ти как только дополнена запись с таким заголовком в таблице, сразу необходимо заполнять еще неск-ко записей: A1A3->>A2(A4), A1A3->>A4(A2) Выполним декомпозицию обобщенного ключа Х (на два отношения) W V, W Z

Физическая организация БД.

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

1) Скорость поиска данных

2)Скорость обновления данных

3)Объем базы данных

4)Обслуживание ограничений целостности на данные.

5)Обеспеч-ие многопольз-го доступа к данным

Схема временных затрат при организации запросов: (рис1)

Вторая нормальная форма.

Дано отношение R, определ-ое на мн-ве атрибутов U={А₁,…,А_n} и F- исходное мн-во функцион-ых завис-ей. Атрибут В функционально полностью зависит от мн-ва атр. Х, если х->BЄF⁺ и ни для какого y истинного подмнож-ва Х (y C X) не выполнено y-> BЄF⁺. Отношение R находится в 2НФ, если оно находится в1НФ и любой атрибут, не являющийся эл-ом ключа, функцион-но полностью зависит от любого первичного ключа в R.

Способы формирования F.

1)Послед-но формируем сочетания без повторений из n-элементов по k, где k=1,2,3..n. Для атрибутов, соответств-их текущ. сочетанию, определяем мн-во атрибутов, которые функц-но полностью определяются этим сочетанием. Преребор прекращается, если сформиров-ые функц-ые завис-ти содержат все атр. из мн-ва U.

2)Последовательно просматриваем атр. Из мн-ва U и для текущего выпис. мн-ва атр-ов, которыми он функц-но полностью определяется.

Правило формирования 2НФ.

1.В мн-ве F объединяем функц-ые завис-ти с совпадающими лев. частями

x->Ai

x->Aj =>x->AiAj

Объединяем завис-ти с совпадающими обл-ми опред-ия.

2.Формируем декомпозицию исходн. cхемы R: Разбиваем мн-во атр. U на подмнож. y₁,…,y_K т.о., что в y₁ входят атр-ы 1-ой функц. зав-ти, в y_K атр. из k-ой функц. завис-ти. Мн-ва y_K объявляются подсхемами Ri (yi=> Ri). А1(№ издел) А2 (№ поставщика) А3 (наименов. поставщ) А4 (цена изделия)

Отношение R, сформированное на этом мн-ве атр. удовл. 1НФ.

А₁ ->Ø A₁A₂->A₄

A₂ ->A₃ A₁A₃

A₃ ->Ø A₁A₄

A₄ ->Ø

Покрывают все множ. атрибутов. Следуя по правилу формир-ия 2НФ получим

F={ A₂ ->A₃ ; A₁A₂ ->A₄} (рис1) Сформир-ое отнош-ие обладает однозначной семантической интерпретацией. Преимущества 2НФ перед 1НФ:

1)если поставщик временно ничего не поставляет, то сведения о нем будут удалены в 1НФ, а в 2НФ удалять их нет необх.

2)если изменилось название поставщика, то в 1НФ необходимо просмотреть всю табл., чтобы заменить соответ. наименов., в 2НФ наименов. в единств. экземпляре

3)объем БД в 2НФ обычно<, чем в 1НФ.

Классиф-ия методов доступа.

Методы доступа ориентированы оптимальн-е вып-е запросов пользователей, поэтому классифицируем запросы и эту классиф-ию применим к методам доступа

1)Получить все или почти все записи БД. При ответе на запрос требуется от Х% до 100% записей БД. Этому классу соотв-ет последовательный метод доступа, склейки и индексно-послед-го методов доступа

2)Получить уникальную запись. Этому классу соотв-ют запросы, которые по значению первичного ключа находят уник. запись. Различают методы доступа: индексно-послед-ый метод доступа, различают варианты методов полного индекса, в том числе В-дерево и безындексные методы доступа: прямой метод доступа, фиксирование.

3)Получить некоторые записи. Необходимо получить от 0% до Х% записей БД. К этому классу относятся методы: мультисписки, и инвертируемые файлы. Эти методы формируются в виде комбинаций индексных и безындексных методов доступа. Знач-е Х явл-ся границей, которую определяет встроенный в СУБД оптимизатор доступа к данным. Если кол-во записей по запросу меньше Х, то оптимизатор использ-ет индексные файлы для доступа к данным. Если больше Х, то индексные файлы отключаются и запрос реал-ся последовательным просмотром всей БД. Чем качественней оптимизатор, реализ-ый в СУБД, тем больше Х. (в ORACLE 25%)

3НФ.

Отношение R определено на множ-ве атрибутов U={A₁…A_N} и F-исходн. множ-во функциональн-х зависимостей. Отношение R наход-ся в 3НФ, если оно нах-ся во 2НФ и невыполнено след. усл-е: Пусть х первичн. ключ отнош-ия R, Y-некот-е подмнож-во U- Y€U и атрибут Ai не принадлеж. объедин-ю XUY

1) X -> Y Є F⁺(х функционально определяет y и принадлеж. замыканию)

2) Y -> Ai Є F⁺

3) Y -> X не Є F⁺

Выполнение этих 3-х усл-ий явл-ся транзитивной завис-ю.

Правило формир-ия 3НФ: Если на множ-е атрибутов U найдены множ-ва X,Y и Ai, удовлетвор-ие услов-ю 1-3, то выполняя декомпозицию исходной сх R на две подсхемы R₁ содержит атрибуты все, кроме Ai, и R₂ содержит атрибуты Y, Ai (рис1) A₁ -> A₂A₃A₄A₅A₆ отсюда следует, что совокуп- ть атрибутовA₁-A₆ в качестве заголовка R гарантирует, что оно нах-ся во 2НФ. A₄ -> A₅A₆, A₄ не -> A₁ (рис2) Приемущества 3НФ перед 2НФ:

1) Если над проектом временно никто не трудится, то сведения о проекте будут удалены во 2НФ, а в 3НФ сведения хранятся отдельно от сотрудников (удалены не будут)

2) Если изменилась дата окончания проекта, то в 2НФ необходимо просмотреть всю БД, в 3НФ эта дата в единственном экземпляре

3)Объем БД в 3НФ обычно меньше, чем во 2НФ.

Индексно-послед-ый метод доступа. Файловая структура.

Основной файл БД состоит из блоков фиксированной длины. Под блоком понимается еденица объема инфы, перемещаемое в опер. память за одно обращение к устройству ввода/вывода. (рис1) Записи в осн. файле могут иметь переменную длину, но в каждом блоке помещается целое число записей (запись не может превышать длину блока). Записи упорядочены по возрастанию ключа во всем пространстве индексного файла (именно это свойство позволяет исп-ть послед-ый доступ к данным). Для организации быстрого поиска данных исп-ся индексный файл первого уровня, имеющий аналогичную блочную структуру. Записи в блоках индексного файла содержат знач-е ключа последней записи блока и указатель на начало блока. В блоках индексного файла одна запись соответствует целому блоку основного файла. У этого метода самый короткий индексный файл. Обеспеч. высокую скорость доступа к данным, занимает мало места на диске. Это единств. метод доступа, который наиб. удачно совмещ. 2) и 1). При больших объемах индексного файла первого уровня формир-ся индексный файл второго ур-ня с аналогичной структурой, но индексируется в нем индекс первого уровня. Реализация метода для пакета магнитных дисков: (рис1) Совокупность дорожек друг под другом- цилиндр. Дорожки- кластеры. Пакет магнитн. дисков- винчестер. CYL Дисковое устр-во снабжается совокупностью читающих головок (самое медленное устройство в компе). IBM был предложен метод доступа ISAM (индексно-послед-ый). В этом методе блоки индексного файла расположены на нулевом диске пакета, причем один блок-одна дорожка. Блоки основного файла располож. на всех других дисках пакета, причем блоки индексируемые первым ур-ем индекса расположены в одном цилиндре, соответств-ем блокам индекса т.е. механич. перемещение головок сводится к min. Операции поиска удаления и модификации по упорядоченному массиву данных осуществляется за счет поиска соответств-го блока и перемещение его в ОП, затем необход. действия вып-ся в ОП и бок возвращ-ся на место. Проблемы возникают при интенсивном дополнении новых данных. Нов. запись мы должны поместить в опред. блок, причем в соответ-вии с возрастанием ключей. Для реш. исп-ся 2 метода:

1)Метод отведенного свободного пространства. при первоначальной загрузке основн. файла в блоках резервир-ся свободн. пространство (заполнение не более 70%)

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