Базы Данных, 16 лекция (от 27 октября)

Материал из eSyr's wiki.

БД 06.10.27

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

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

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

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

Пример:

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

<COL WIDTH=80> <COL WIDTH=82> <COL WIDTH=95> <THEAD> </THEAD> <TBODY> </TBODY>

СЛУ_НОМ	ПРО_НОМ	СЛУ_ЗАДАН
2934	1	A
2934	1	B
2934	2	A
2941	1	A

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

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

<COL WIDTH=128*> <COL WIDTH=128*> <THEAD> </THEAD> <TBODY> </TBODY>

СЛУ_НОМ	ПРО_НОМ
2934	1
2934	2
2941	1

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

<COL WIDTH=128*> <COL WIDTH=128*> <THEAD> </THEAD> <TBODY> </TBODY>

ПРО_НОМ	СЛУ_ЗАДАН
1	A
1	B
2	A

r3: СЛУ_ЗАДАН

<COL WIDTH=128*> <COL WIDTH=128*> <THEAD> </THEAD> <TBODY> </TBODY>

СЛУ_НОМ	СЛУ_ЗАДАН
2934	A
2934	B
2941	A

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

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

NAT JOIN

<COL WIDTH=85*> <COL WIDTH=85*> <COL WIDTH=85*> <THEAD> </THEAD> <TBODY> </TBODY>

2934	1	A
2934	1	B
2934	2	A
2941	1	A
2941	1	B

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

<COL WIDTH=85*> <COL WIDTH=85*> <COL WIDTH=85*> <THEAD> </THEAD> <TBODY> </TBODY>

2934	1	A
2934	1	B
2934	2	A
2941	1	A

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

Для 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 таблиц, но они отказались. Через два года комманда сменилась, и они не смогли разобраться.

Первое утверждение лектора: для БД с достаточно большой сложностью (более ста таблиц0 надо использовать какую-нибудь нотацию. И проблем перевести эту нотацию в SQL проблем не составляет, но картинки обязательно должны сохраняться на время проектирования БД.

Положительнеый пример: проектировали книжный магазин, простая БД на 30-40 таблиц, и тогда таки сделали картинки. Продаётся уже в 4 раз.

Ручная документация проекта БД, желательно, чтобы не в один этап, можно там и нормализацию проводить, и можно задокументировать весь процесс.

CASE-системы (computer Aided Software Ingeenering), но это не совсем CASE, больше похоже на САПР.

Когда в Москве пыталось появиться первое представительство Sun microsystems, и тогда на презентацию привезли 19-дюймовый монитор, где они показывали, как можно было использовать CASE для Оракла.

Неистребимый порок диаграмного предсталения – какой бы большой монитор не был, всё равно придётся скроллить.

Появились рисовалк, и народ начал рисовать. Почему нельзя сделать компилятор для графич нотации? И появлись первые CASE-средства, которые умели генерировать SQL. Смотря на то, что SQL почти не менялся за 15 лет, в каждой реализации свои отклонения, и генераторы должны привязываться к платформе, и такое могут позвольить себе немногие, например, ИБМ.

Следующий шаг: как человек рисует картинки, откуда он берёт информацию? На самом деле в области проектирования БД не надо думать, что картинку придумывает проектировщик, её придумывают люди, эксперты в предметной области. И возникает идея: есди проектировщик может выслушать людей, почему программа не может. Подобные проекты делались в Киеве, и закончились с СССР – смесь экспертной системы и CASE-средства, там были шаблоны ответов, эксперты ответы давали, система проверяла всё на непроречивость, и когда необходимые графы внутри таблицы были заполнены, она рисовала картинки, она показывала картинку проектировщику и он говорит, подходит картинка или нет, если нет, то задавались уточняющие вопросы. Они обеспечивали 3НФ уже в конце 80х годов. Лектор не понимает, почему нет ни одной коммерческой системы не сделано, хотя понятно уже 20 лет как, что это можно.

Далее: есть красивое диаграмное представление, сжема БД, и мы умеем отобразить эту схему в SQLовскую схему, но почему мы тогда заставляем работать людей в терминах SQL, а не схем? Почемцу мы не можем отобразить операции над схемой в операции на SQL, Такие опыты производились, и были средства, которые позволяли взаимодействовать с БД. И возникает вопрос – а на фига тогда SQL,Это породило направление, которое SQL было задавлено – прямая реализация семантическим представлением. Одно время лектору казалось, 14 лет назад, когда он впервые готовил этот курс, лектору кахалось, что сработают ООБД. Хотя понятно, что ОО позволяется сохранять больше семантики, чем реляционные БД, там богатые структуры данных, их можно разным образом интерпретировать. Но этого не произошло, и ожидания лектора от ООБД были преувеличены, и он ошибался в том, что они обесп более высокую семантику, и лектор теперь в этом уверен.

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

ER-диаграмы

(Entity-Relationship) – сущность-связь

Почему в математике нет терминологической проблемы – потому что там все термины долговечны. Компьютерная технология меняется очень быстро, и термины, которые вводятся 50 лет назад, уже не использоуются. И такой суеты, как в последние 6 лет, лектор не видел. Даже если новое – это хорошо забытое старое, маркетологи всё равно придумывают новые термины.

Сущность – понятие также неопределимое, также как и процесс, жизнь.

В UML это называется association.

Peter Chen 1976

Oracle Case Method – был представлен свой диалект диаграм ER, который дектор полюбил по двум причинам. В этой нотации очень простые графич символы и их хватает. Во всех остальных те же самые понятие, но немного другие графич символы. Поэтому лектор будет использовать именно этот диалект.

Определиния Орвкла нравятся лектору своей эмоциональность.

1. Сущность

2. Связь

3. Атрибут

На овощном складе есть куча реальных предметов.

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

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

<COL WIDTH=88> <THEAD> </THEAD>

АЭРОПОРТ например, Хитроу