Вордовские лекции (1121814), страница 10

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

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

БД 24.10.06

4НФ

Многозначные зависимости ближе всего к функционалам.

Наличие многознач завис в БД обнаружил Рональд Фейджин. Многозначные зависимости обнаруживаются достаточно трудно.

5НФ настолько далека от интуитивного понимая, что лектор не знает примеров, где её хорошо использовать. Во многом она искусственна. Хотя мы увидим, что те ограничение, коотрые порождаются, довольно естественны.

Многознач завис:

Есть отношение СЛУЖ_ПРО_ЗАДАН {СЛУ_НОМ., ПРО_НОМ, СЛУ_ЗАДАН}

Служащий может учавствовать в различных проектах, но выполнять только одно задание. Например, если вы усеете мыть посуду или подметать, то будете востребованы в любом проекте.

Что ещё делать менеджеру проекта, кроме как посуду мыть.

Как выглядит ограничение:

Для каждого кортежа ПРО_ЗАДАН должно выполняться ограничпение: IF (<сн, пн₁, сз₁>) принадлежит B_спз and <сн, пн₂, сз₂> принадлежит B_спз then (<сн, пн₁, сз₂>) принадлежит B_спз and <сн, пн₂, сз₁> принадлежит B_спз

Наличие такого рода зависимостей приводит к аномалиям изменений.

Если вдруг менеджер, Котолько только моет посуду, Вдруг научидлся программировать на Джаве, То придётся добавить количество кортежей по количеству проектов.

Понятно, что эти проблемы решаются декомпозицией отношения.

СЛУЖ_ПРО_НОМ:

Заметим, что было унарное отношение с единственным возмоджным ключом, а стало бинарное с нетривиальной ФЗ. Но это честная бинарная зависимость.

СЛУЖ_ЗАДАН

То, что это декомпозиция правильная, ни из чего не следует.

Почему так, объяснил Фэйджин. Он заметил, что дано отношения с тремя атрибутами, причём мнодество значений третьего зависит от первого и не зависит от второго – ситуация многозначной зависимости. Множество значений второго атрибут зависит от первого, и множество третькего зависит от первого, а друг от друга они никак.

(Служ_ПРО_НОМ WHERE (СЛУ_НОМ=СН and СЛУ_ЗАДАН=СЗ)) PROJECT {ПРО_НОМ}

Определение, которое нравится лектору

MVD (Multi-Valued Dependency)

r{A, B, C} MVD B от A (A->-> B) т и тт когда множество значений B, соотв. Паре знач. A и C, зависит от А и не зависит от С.

Записывают A->->B|C

Лема Фейджина. B отн r{A, B, C} выполн MVD->->B <=> выполн MVD A->->C

Многие годы лектор не доказывал ни теорему лектора, Ни лемму, Но теперь понял, Что надо доказывать, что это просто. Будь бы лектор Фейджином, он бы назвал эту лемму теоремой.

Лектор любит задавать вопрос на экзамене: как будет звучать лемма, если есть ФЗ В от А.

Достаточность:

пусть выполняется MVD A->-> B

B_r, знач A в некотором кортеже B_r

{b} – множество значений отрибута B, соотв a

Пусть для a A->->C не выполняется, Тогда существует с атрибута с и такое b принадлежит {B}, что <a, b, c> не принадлжеит B_r

Необходимость аналогично

Теорема Фейджина

Пусть имеется перем. Отн. r{A, B, C}

r декомпозируется без потерь на r{A, B} и r{A, C} т и тт, когда выполн MVD A->->B|C

Достаточность:

B_r – тело r, a – значение А, {b} – множество значений B, соотв а; {c} – множество С, соотв а

r PROJECT {A, B} -> {a, b}, где b_i принадлежит {b} и если /**/

Необходимость:

Пусть декомпозиция является декомпозицией без потерь для всякого значения B_r

IF (<a, b₁, c₁> принадлежит B_r AND <a, b₂, c₂> принадлежит B_r>) THEN <a, b₂, c₁> принадлежит B_r AND <a, b₁, c₂> принадлежит B_r) Пусть <a, b₂, c₁> не принадлежит B_r OR <a, b₁, c₂> не принадлежит B_r но в r PROJECT {A, B} входит <a,b1> и <a, b2>

r PROJECT {A, C} входят <a, c₁> и <a, c₂>

Контрольная будет через неделю, 9 ноября. Очень хороший день, после октябрьской революции.

Будет запрос

Будет что-то из теоретических вещей

Нельзя пользоваться только соседями.

4НФ

r находится в 4НФ т и тт, когда находится в БКНФ и все MVD являются FD с детерминантами – возможными ключами

Гречушкин выпендривается, задавая умный вопрос. Благодаря этому лектор не сможе рассказать сегодня про 5НФ.

Отнош называется N-композируемым, если его можно разбить на N независимых проекций.

Тривиальная MVD:

r{A, B} MVD A->-> B триивальна, если либо А содержит или равно B? Либо A UNION B = H_r

БД 06.10.27

Гораздо сложнее вопрос с пользовательскими ТД.

Это есть в SQL, но этого никто не делает. На это решаются обычно только сами разработчики конкретной СУБД, иногда эти ТД определяют вне зависимости от БД. Тем больше тех возможностей появляется в СУБД, тем сложнее проектирование. Неизвестно, что по этому поводу думал Кодд, но всё, что неявно можно вывести из его статей, это что БД должны быть как можно проще в использовании.

Лектор возвращается к проекции соединений и 5НФ.

N-декомпозиция соотношения – отношение, которое может быть декомопзировано без потерь на N проекций. До этого мы всё время занимались этим при N=2. В действ бывают такие отношения, которые не явл 2-декомп. Декомп для них имеют смысл, но при N>2.

Пример:

r: СЛУЖ_ПРО_ЗАДАН

Попробуем это отношение декомпозировать.

r1: СЛУЖ_ПРО_НОМ

r2: ПРО_НОМ_ЗАДАН

r3: СЛУ_ЗАДАН

С точки зрения предыдущих рассуждений эта декомпозиция бессмысленна.

Теперь начнём соединять. Сначала соединим вот это отношение с этим.

NAT JOIN

Появился лишний кортеж. Но если теперь мы соединим это соотношение с этим:

Теперь в результате соед с третьим соотношением мы получили исходное. Соединение любой пары не будет соед без потерь, а соединение всех трёх является соединением без потерь.

Для 3-декомп без потерь нужно удовлетворять следующему ограничению:

IF (<СН, ПН> принадлежит B_r1 AND <ПН, СЗ> принадлежит B_r2 AND <СН, СЗ> принадлежит B_r3 ) THEN <СН, ПН, ЗН> принадлежит B_r

n-декомпозируемые отношения

n=2

IF (<СН1, ПН1, СЗ1> принадлежит B_r AND <СН2, ПН1, СЗ1> принадлежит B_r AND <СН1, ПН2, СЗ1> принадлежит B_r ) THEN <СН1, ПН1, ЗН> принадлежит B_r

Если есть отношение r, есть атрибуты A, B, ..., Z коотрые имеют ... *(A, B, ..., Z)

Отношение можно декомп без потерь на n отношений, когда его можно декомпозировать на n отншений.

Основная цель модификации БД – чтобы не надо было выполнять триггеры.

Условие: если Сидоров в проекте 1 моет посуду и Петров в проекте 1 подметает полы, и Сидоров в проекте 2 моет посуду, то Сидоров должен также мыть полы, потому что они ходят парочкой.

Если мы добавляем <2941, 1, A>, то мы должны добавить <2934, 1, A>. Аналогично с удалением.

Весь смысл проекции соединения в том, чтобы довести нормализацию до конца.

Все боятся 5НФ, и лектор тоже в первые разы рассказывал её сложно, пока не понял, что там всё просто.

PJD – Projection join independency.

PJD, Опред. Возм. Ключем

r ЗОВ*(A, B, ..., Z)

Вопрос на экзамене:

Есть r(A1,...An), А1 – возможный ключ. Есть ли здесь зависимость проекций соединений? Если да, то какая?

Ответ: есть, ({A1, A2}, {A1, A3}, {A1, An}) – доказывается по теореме Хитта, так как всё без потерь. Оно сколько угодно декомпозируемое, и его декомпозировтаь не надо, так как оно и так хорошее.

Тривиальная PJD

Зависимость проекций называется тривиальное, если зотя бы один атрибут совпадает с заголовком отношения. Такая зависимость существует всегда, и она бессмысленнва.

5НФ. Если любая нетривиальная зависимость соединения подразумевается возможными ключами.

Он находится в 5НФ, когда декомпозиция становится бессмысленной. Ибо уже после неё аномалий нет.

На саом деле есть дырочка межту 4 и 5НФ. Лектор думает, что при желании можно найти дополнительные условия, которые более сложные, чем многознач завис, но более прочты чем ..., но никто этим не занимался.

БКНФ – только для очень умных проектировщиков, дальше уже выпендрёж.

Проектирование БД на основе семантических моделей

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

В отделах есть ID начальника, В служащих - ID отдела.

На самом деле, Всё-таки РБД по своей природе плоские. Если мы начинаем работать с проектированием БД в терминах проецур нормализации, то и в голову не придёт ... . В дейсьтвиетельности проектировщику БД это не хорош, не удобно, ему удобно считать, что есть большой квадрат – предприятие, есть малые квадроаты – подразделения, отделы, служащие, связи с клиентами... Такая картинка могла быть более удобной. Из-за этого в 80 годы были придуманы модели данных, которые следовали определению Кодда, но рассчитаны на то, что представление объектов внешнего мира в них было бы больше приболижено к жизни.

Лектор собиратеся сказать только два пример семант зависимостей – диаграмы. Были абсолютно линейные модели и языки. Но это было 20 лет назад, а лектор читает не курс по истории БД. И после педедыва лектор расскажет общий взгляд на то, как семант модели данных можно использоваиьт при проектировании и потом. Это не история, это представление лектора о том, что он видел в жизни. Некоторые вещи исользуюися и их разумно исопльзовать, некоторые не используются, но лектор не знвает, почему.

В советское время, вернее в то врем, конгда советская власть казалась вечной бесконечной, были суровые ГОСТы, и при приёмке программ кроме текстов программ должны были быть блоксхемы программ. Но они ни разу не рисовались до того, как программа не начинала работать, и это была самая идиотская работа, ибо никто не сверял блоксему с программой, главное, чтобы там были квадратики, стрелочки... Сейчас, даже с появлением UML то же самое.

При проектировании БД тоже нужно иметь нотацию. Для маленьких БД достаточно смотреть на определение на SQL, для больших (от 100) уже нет, и граница очень расплывчата. Пример: был хороший проект, в 93-94 годах, тогда продавался Oracle 7.3, проект был замечательный, космонавтов, тогда в постСССР, было довольно много ЦУПов, десяток-полтора, некоторые военныЕ, некоторые универсальные, но у всех похожая функциональность, делают они примерно одно и то же, а ПО у всех уникальное, что печально. Замечательный был центр Капустин Яр, народ туда шёл работать под угрозой смертной казни, и у этих ребят была нормальная идея сделать мобильный ЦУП. Они хотели делат это на нормльной тенолгии,чтобы всё работало на БД, и лектор помогал эту БД проектировать. Лектор слёзно умолял их задокументировать БД, там было 100-150 таблиц, но они отказались. Через два года комманда сменилась, и они не смогли разобраться.

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

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