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

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

(Перенаправлено с Базы Данных, 11 лекция)
Перейти к: навигация, поиск

БД 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)

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


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


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




Базы Данных


01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28


Календарь

пт чт пт чт пт чт пт чт пт чт
Сентябрь
01 07 14 15 21 22 28 29
Октябрь
  05 06 12 13 19 20 26 27
Ноябрь
  02 03 09 16 17 23 24 30
Декабрь
  07 08 14 15

Вопросы к экзамену
1999 2000 2001 2002 2003 2004 2005 2006


Дополнительная информация к экзамену


Эта статья является конспектом лекции.

Эта статья ещё не вычитана. Пожалуйста, вычитайте её и исправьте ошибки, если они есть.
Личные инструменты
Разделы