Базы Данных, 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 таблиц, то нужно использовать комбинации, рисовалки, но не их интеллект. Если в БД тысячи таблиц, там деваться уже некогда.
Если не доволишь хороший проект до конца и отдаёшь его другому, то он всё равно умудряется его изгадить.
Лектор видел объявление в хорошей фирме, где обязательным требованием было прослушивание его курса.
Проектирование путём нормализации
Элементы теории
Нормальные фромы
Элементы теории: книги Мейера, но её лектор не советует читать.
В основе всей теории лежит понятие зависимости.
Зависимости
Функциональные
Многозначные
Проекции/соединения – небинарные соответствия
Есть некоторый набор фактов, который касается зависимостей. На праактике абсолютно идеальные БД получаются с учётом наиболее простых зависимостей – функциональных.
Если в Китае, нет в Китае нельзя говорить, в Северной Корее одному человеку соответствует одна чашка риса в день, то это функциональная зависимость. Если ему её не дать, то он без неё умрёт, И это трагедия для страны – образуется лишний рис.
Все преподаватели курса БД на ВМК пользуются одними и теми же учебниками – это насилие, это неестественное требование.
Если учитываем зависимости проекции/соединения, то получим идеальную БД, но это определить нельзя, это от Бога, но он на такие мелочи внимания не обращает и очень трудно добиться от него такой справки.
Функциональные зависимости
Лектор избегает рекурсии, но она пронизывает весь мир и от неё надо отбиваться. Ибо наличие рекурсии очень осложняет понимание.
Есть отношение r – regular, x, y – аттрибуты
Существует функционгальная зависимость x от y z.x -> z.y (у функ зависит от х, ...) Если для каждого значения х в точсности имеется одно значение у.
|
СЛУ_НОМ |
СЛУ_ИМЯ |
СЛУ_ЗАРП |
ПРО_НОМ |
ПРОЕКТ_РУК |
|---|---|---|---|---|
|
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)
СЛУ_ЗАРП -> ПРО_НОМ
Если руководитель псевдофоб и боится однофамильцев, то он, конечно, может побожиться, что у него не будет сотрудников с одинаковыми фамилиями, но это противоречит законодательству.
Начальник является характеристикой проекта, а не служащего, пожтому они и размножились в диких количествах.
