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

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

БД 12.10.06

Три варианта

Целевой список (target list)

var.attr var_имя свобю переменной WFF

var == var.attr1, Var.attr2, ... , var.attrn – порядок не важен, в SQL не так.

new_name = vaar.attr – аналог RENAME

target_list WHERE WFF – выражение реляционного исчисления, аналог проекции

Та интерпретация которую лектор называет наивной, работает. Это не просчто интерпретация, это семантика.

При такой интерпретации много шагов, каждый шаг – шаг цикла. Это результирующее отношение строится кусочками, за каждый проход добавляется один кортеж. На кажом шаге мы знаем, откуда взялся кортеж -результат. Легко преобразовать язык запросов в язык обновлений. Вместо того, чтобы написать, что я хочу найти ..., можно сказать выкинуть, и эта операция будет однозначно интерпретирована. Над выражениями реляционной алгебры написать DELETE или UPDATE написать гораздо сложнее, Потому что надо пройти назад и понять, откуда взялось это выражение.

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

С одной стороны, эта штука декларативная, ибо пишем процедуру, с другой стороны он позволяет операцию отображения произвести.

Один из пунктов борьбы Дейты с SQL является механизм курсоров. В результате запросов получаются таблицы. Обычные ЯП не имеют средств работы с таблицами. По этому поводу в SQL принято компромиссное решение – вставить средство, которое позволяет итерировать таблицы, что позволяет обходить результат по одному кортежу. Очень многие средства для изменения базы данных завязан на механиз курсоров. Почему – потому что можно сказать системе, кого я имею в виду, когда говорю что-то делать. Пояему это Дейта ругает – в язык, который является реляционным мы втыкаем вещи, которые свсем опперёк. Здесь же, несморя на реляционность, внутри содержится понятие курсора, что позволяет менять таблицу.

Ещё олдин вид исчисления – исчисление доменов

Лектор не помнит, откуда пошло это нозвание, ибо у Кодда было исчисление доменов.

Основное отличие от языка исчисления кортежей в том, что облдасть определения переменной – множество значений ТД, в кортежах – отношение, там кортеж – составное значение, здесь атомарное.

Всё строится аналогично.

Отличия: как привязывается это исчисление к БД. Вводится специальный вид предикатов.

R-n-арное отношение – принимает тру тогда и только тогда, когда входит в какой-либо кортеж текущего значения R.

R{ai1 : vi1 (константа переменная), ai2

vi2, ..., a1m : vim}

Это можно было бы расширисть сравнениями или регэкспами, ибо шаблон, но это и так достаотчно мощное вещь.

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

Запрос:

СЛУЖАЩИЕ

WFF - <2934, 'Иванов', 22400.00, 1>

СЛУЖАЩИЕ (СЛУ_НОМ: 2934, СЛУ_ИМЯ: 'Иванов', СЛУ_ЗАРП: 22400,00, ПРО_НОМ: 1)

Тут можно ставить предикаты, кванторы и т д, над такими формулами строятся выражения, и в них учавствуют имена доменных переменных, и они все разные.

Запрос служащих с неминимальной з/п:

СЛУ_НОМ, СЛУ_ИМЯ WHERE EXISTS СЛУ_ЗАРП1(СЛУЖАЩИЕ(СЛУ_ЗАРП1) AND СЛУЖАЩИЕ(СЛУ_НОМ, СЛУ_ИМЯ, СЛУ_ЗАРП) AND СЛУ_ЗАРП>СЛУ_ЗАРП1)

Мойше Zluf придумал запрос по образцу – Query_by_example – первый язык графического изображения запросов к БД. Этот язык по мощности превосходит и язык рел алгебры, и исчисл кортежеи, ибо он умудрился создать рекурсивные запросы.

Первый графич язык – Query By Forms – фактически был Query by Example, с выброшенной рекурсией. Поячему он так попёр? Потому что никто из нормальных людей не пишет запросы на SQL.

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

Злуф жив, здоров и невредим, выпустил новый язык – Programming By Example – очень утопическая идея. Есть большой репозиторий заготовок, и трудно подобрать то, чот нужно. Есть идея в том, что пишется шаблон программы, по которому система подбирает заготовки, из которых собирается программа. Никаких практических шагов по реализации шагов не видно.

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

//педедыв

Проектирование реляционных БД

Проектирование путём нормализации

Подход заключаетс в том, что БД представляется в виде таблиц, как взбредёт в голову, и потом нормализируются.

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

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

У лектора зазвони телефон.

Если БД содержит порядка 20-30 таблиц, то её надо проектировать, используя обычные ручные средства. Если 100 таблиц, то нужно использовать комбинации, рисовалки, но не их интеллект. Если в БД тысячи таблиц, там деваться уже некогда.

Если не доволишь хороший проект до конца и отдаёшь его другому, то он всё равно умудряется его изгадить.

Лектор видел объявление в хорошей фирме, где обязательным требованием было прослушивание его курса.

Проектирование путём нормализации

1. Элементы теории

2. Нормальные фромы

Элементы теории: книги Мейера, но её лектор не советует читать.

В основе всей теории лежит понятие зависимости.

Зависимости

1. Функциональные

2. Многозначные

3. Проекции/соединения – небинарные соответствия

Есть некоторый набор фактов, который касается зависимостей. На праактике абсолютно идеальные БД получаются с учётом наиболее простых зависимостей – функциональных.

Если в Китае, нет в Китае нельзя говорить, в Северной Корее одному человеку соответствует одна чашка риса в день, то это функциональная зависимость. Если ему её не дать, то он без неё умрёт, И это трагедия для страны – образуется лишний рис.

Все преподаватели курса БД на ВМК пользуются одними и теми же учебниками – это насилие, это неестественное требование.

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

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

Лектор избегает рекурсии, но она пронизывает весь мир и от неё надо отбиваться. Ибо наличие рекурсии очень осложняет понимание.

Есть отношение r – regular, x, y – аттрибуты

Существует функционгальная зависимость x от y z.x -> z.y (у функ зависит от х, ...) Если для каждого значения х в точсности имеется одно значение у.

<COL WIDTH=80> <COL WIDTH=81> <COL WIDTH=134> <COL WIDTH=82> <COL WIDTH=106> <THEAD> </THEAD> <TBODY> </TBODY>

СЛУ_НОМ	СЛУ_ИМЯ	СЛУ_ЗАРП	ПРО_НОМ	ПРОЕКТ_РУК
2934	Иванов	22400	1	Иванов
2935	Петорв	29600	1	Иванов
2936	Сидоров	18060 (было 18000)	1	Иванов
2937	Федоров	21000	1	Иванов
2938	Иванов	22500	1	Иванов
2939	Сидоренко	18000	2	Иваненко
2940	Федоренко	20000	2	Иваненко
2941	Иваненко	22000	2	Иваненко

СЛУ_НОМ -> СЛУ_ИМЯ

СЛУ_НОМ -> СЛУ_ЗАРП

СЛУ_НОМ -> ПРО_НОМ

СЛУ_НОМ -> ПРОЕКТ_РУК

{СЛУ_НОМ, СЛУ_ИМЯ} -> СЛУ_НОМ

{СЛУ_НОМ, СЛУ_ИМЯ} -> СЛУ_ЗАРП

{СЛУ_НОМ, СЛУ_ИМЯ} -> ПРО_НОМ

{СЛУ_НОМ, СЛУ_ИМЯ} -> {СЛУ_ЗАРП, ПРО_НОМ}

...

ПРО_НОМ -> ПРОЕК_РУК

У всех зависимостей разные имена. Если это правильно отражает предм область, то есть и такие зависимости (из того, что имена разные):

(2)

СЛУ_ИМЯ -> СЛУ_ЗАРП

СЛУ_ИМЯ -> ПРОЕКТ_РУК

(3)

СЛУ_ЗАРП -> ПРО_НОМ

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

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