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

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

БД 17.11.06

Хотя эт объектная схема, то легко видеть, что свойство ОО-сситем, что у объекта есть уникальный идентиф. естественно.

У лектора есть ощущение, чот если у схеми нет уник идентиф, то с ней что-то не так.

В отделах с номерами >5 должны работать служащие старше 30 лет.

Общее ОЦЛовское свойство – когда пишутся огрнаичения, от их можно писать, либо оттлакиваясь от отделов, лбо от служащих. Есть ощущение, что ограничения мржно формулировать, начиная с любых классов.

Как это на ОЦЛ сформулировать от отдела:

context Отдел inv:

self.отдел.номер <= 5 OR self.служащий -> select(возраст <= 5) -> size()=0

context Служащий inv:

self.возраст<=30 OR self.отдел.номер > 5

У каждого отдела имеется менеджер и отдел не может быть образован раньше компании

context Отдел inv:

self.служащий -> exists(должен=»manager») and

self.компания.годОснования <= self.годОснования

context Компания inv:

forAll self.Отдел(self.годОснования < self.отдел.годОснования and exists(self.отдел.служащий.должность=manager))

В лбюбой компании служащих не больше 1000

context Компания inv:

self.отдел -> collect(служащие)->size() < 1000

Это очень приятный язычок.

Традиционная схема проектированная:

1. есть большое желание определять класс с операциями. Если это очень хочется, надо подуматьб, в какой СУБД это будет реализовываться.

2. Если у нас много связей 1 к 1, то нужно подумать, нужны ли они нам. Нужно подумать, не является ли объект на другом конце связи атрибутом. Есть хорошая парочка доярка и корова. Предположим, что у доярки может быть одна корова. Но корова не есть собственность доярки, у неё есть своя жизнь, свои связи...

3. Очень надо аккуратно относиться к тому, когда мы рисуем агрегатные или композитные связи. Надщо подумать, если такие средства в SQL.

4. Направленные связи. Подумать, нужны ли они.

5. Не злоупотреблять ограничениями целостности и не пренебрегать ими.

Теперь миы приступаем к теме ,которая ране занимала бОльшую часть курса.

Внутренне устройство СУБД

В прошлые годы, лет 10 назад, лектор настолько её отдавал должное, что у неё было три прохода:

1. Введение

2. На примере System R

3. Общее, совр подход

По прошествии лет лекто понял:

1. Можно убиццо, но все не расскажешь.

2. Нужен какой-то каркас, нельзя рассказывать их в отрыве от общих методов построения СУБДЖ. Как ни странно, оказываетсф структура System R, которой 30 лет, остаётся эталоном.

Меньше всего компромиссов в DB2.

Давате рассмотрим 2.. 3.. 4 примера:

1. Oracle. Это система, которая делалась после Стистем Р, и писалась она, как вспоминают, на основе статей по поводу Систем Р. Люди их прочитали, переманили людей и делали эту систему. У оракла была задача сделать быстро работающую систему, которая заняла бы место на рынке. А нишей тогда были миникомпьютеры (ПДП-11). Они быстро склепали ядро системы, и до сих пор они от этого ядра освободиться не смогли. На него настраивали, настраивали, настривали новые модули. Сейчас вообще не видна её архитектура

2. MySQL - система, котроая делалась на коленке, чтобы появились в ОпенСорсе возможности СКЛ, чтобы работали вебсайты. Собрались немсколько горячих финских парней, которые написали, как линукс, систему.

3. PostgreSQL – это ещё более древняя история, чем у оракла. Датируется 74 годом. Когда длелалась Ingris (?), сделана она была некрасиво, но там быле кое-каие яркие пятна. Там динамически можно было определять новые способы доступа. Потом, когда делалли Постгрес, они не выбросили старый код. Потом опять горячие финские парни, которые почему-то больше всего наделали в опенсурсе, сделаи ПостгреСКЛ.

4. MSSQL – история вообще занимательная. Была маленькая зародышевая компания, которая сделала собственную разработку ядра, они стали делать свои собственные версии SQL, и потом откололся кусочек. Внешне это очень мощная система, но безыдейная.

Почему ДБ2 лучше всех. Онва делалась по пообию Систем Р, они перепичсали код, но архитектура та же. Потом они ещё раз его переписали.

При том, что ИБМ не меньший монстр, чем МС, что касается с тз БД, это практически идеальная компания, потому что про них известно почти всё.

После педедыва:

1. Основные цели

2. Как эти цели отразились на организации системы

3. Потом про отдельные компоненты, и как задачи можно было бы решать сегодня

//педедыв

Контекст, в котором рождался Систем Р:

существовало 5-10 лет некая технология БД. Поддерживалось три разновидности способов организации БД:

1. Иерархическая организация, фактически на физическом уровне. И ИБМ была в этом отношении передовой, у неё была ИМС, котораябыла есть, будет, и будет оставаться

2. Сетевые БД. Те же самые физ ссылки, но могли они образовывать орграф, и тут у каждого потомка моглоб ыть бльше одного родителя

3. Инвертированные таблицы. То есть когда основными структурами были именно таблицы, и над этими таблицами можно было строить индекс явно. Это Adobase. И что бы они не говорили, у них всё тоже

Когда у ИБМ появилась идея Эдгара Кодда, что можно было бы абстрагироваться от физ структур и ввести реляц модель, в которой единственным способом предст данных было бы отношение и все операции над отношениями. И возникла идея такой проект выполнить. С точки зрения начальства фактиески это переход от уровня ассембоера на уровень управления данными. Лектора это удивляет, поотму что ИБМ изнутри всегда порождала конкуренты своей собственной технологий.

Сектор иерархичесикх БД очень-очень маленький, но очень дорогой.

Соответственно, был сформирован достаточно мололдо коллектив разработчиков, за последние 30 лет умерло почти 3 человека. Они немногим старше лектора, сейчас, уже, конечно, не работоспособны, но вполне себе функционируют. Например, Джим Грей.

Цели Systrem R

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

2. Многообр способов использ БД, возм прогр прилож, интеракт доступ и генер отчётов

3. Обеспечивание возможностей динамической изменяемой среды

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

Вопрос на экзамене: как удалить таблицу, заполненную данными?

5. Средства восстановления сост БД после сдбоя

6. Обеспечить механизм представления БД (view)

7. Приемлемая производительность

Ненавигационный интерфейс

Одно из основных новшеств – предложение нового языка, имепративного.

Как работают сегодняшние системы: если должна выполница какая-то операция SQL, в любом случае этот текст передаётся на компиляцию (JIT). В IBM- заблаовременная компиляция. Есть приложение, и в это приложение вставлены SQL-операции, и они компилируются во время компиляции приложения. Для этого были специальные прекомпиляторы.

Пункт 2

(картинка, что представляет язык СКЛ)

В 73 году появился первый драф,т который назывался SEQUEL-1, в 74 SEQUEL-2, и первая статья была посвященна именно ему. Это язык, который позволял достичь первой цели. Потом появился SQL (1976).

Direct SQL – язык, который позволяет работьа с таблицами. На нём нельзя писать приложения, поотму что он этого не умеют

Embedded SQL -

SQL это такой impendance mismatch, о котором говорили большевики

В результате компиляции вам БД говорит, а что же это вы такое откомпилировали.