Вордовские лекции, страница 13

Platform-Independed Model

| MS SQL

V Server 2005

Platform Specific Model

Перекход делается с помощью прфайлов, и идёт к тому, чтобы делалось автоматически.

Теперь алектор сосредотачивается на диаграмах классов.

Диаграммы классов – показывают некоторый набор классов или других сущностей и некоторых связей между этими классами.

Object Constrint Language (OCL) - jxtym rhfcbdsq? Vfktymrbq zpsxjr

У UML семантика очень слабая. Есть люди, которые считают, что коль скоро мы предлагаем людям формальный язык, то, значит, у него должна быть формальная семантика, также документированная, как и синтаксисъ

Пока лектор не расскажет OCL, контрольной не будет. Ибо лектор учень любит давать на неё задачки.

Диаграмма классов

Классы – именованные описания объектов

Какой-то ушлый преподаватель недооценил лектора. - лектор таки нашёл мел, который был спрятан за задвинутой доской.

1. атрибуты

2. операции

3. связь

4. семантика

Формально у класса может не быть атрибутов.

Свойство, выраж атрибутом, является свойством сущности, которая присуща всем объектам класса.

Атрибут – абстракция состояния объекта.

Операции класса – именованная услуга, которужю можно запросить у любого объекта класса.

Сигнатура операции – имя операции, тип значения, список типов параметров

Самая большая неприятность языка UML – то, что там терминологияч не такая. Например, понятие связи в UML – понятие более общее, чем в ER-диаграммах.

Связи:

1. зависимость

2. обобщения

3. ассоциации – то же, чот и связь в ER-диаграммах

Лектор будет расматривать типы связей в порялке возрастания.

Зависимость – то, что одна сущность бкз другой не имеет смысла.

Обобщения (связь «is a»)

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

Лектор – первый человек по в СССР, который написал статью по С++. (1985)

Страустрап.

Обобщение – стрелочка новорит, что у аэроплана один базовый класс, и аэроплан является его подклассом.

Показательный пример.

При том, что Дейта и Дарелл (?) терпеть не может UML, как и полагается нормалдьным людям, тем не менее, у них основные свойства наследования такие же, как в UML.

Есть класс яблоки, и мы там ввели все возможные атрбуты яблок. Лектор знает людей, которые едят принципиально зелёные ябдлоки... этот пример лектору не нравится

Всегда можно прийти к картинке с общим корнем.

Новый курс – модельные основы технологий БД и их приложения.

И у студент, и у преполда есть комната. Препод – комната, где покурить, студент – комната в общаге. У препода-студента и то, и другое. Какие решения – запретить образование класса, пока есть одноимённые атрибуты. Это упражнение не годится, потомцу что класс – вещь динамичная. Втрое – наследовать свойства только от одного изх суперклассов. Ещё одна возможность – переименовать автоматом. На самом деле, тоже не очень сдорово, потому что на уровне ЧеловекИзУнивера не должны быть атрибуты, которые такие. Кроме того, имена получапются очень длинные.

Вывод – ребята, множественное наследование – вещь красивая. Но. Лектор не знает, как её реализовать в SQL.

Связи – ассоциации

У каждой 2 конца, хотя в UML допускаются н-арные ассоциации. В OCL они не допускаются.

Графически на диаграмах сущность-связь это линия, которая соед класс с самим собой или другим классом.

Ассоциации:

1. Имя

2. Роль

3. Кратность

4. Агрегация

Кратность – multiplicity

Число объектов, которые могут находиться на конце связи

Имя.

Допускается именование ассоциации одним именем, именами ролей, и вообще без имени.

БД 16.11.06

Лектор решил контрольную не проводить. Бугага. Но цели он достиг – народу стало побольше

Связи-ассоциации

Языек ОЦЛ

Связи-ассоциации

Есть уровень вовлечения в связь.

1. Простые ассоциации: Объекты не зависимы, то есть могут существовать сами по себе. То есть обязательного наличия партнёров явно не требуется.

2. Агрегатные связи

3. Композитные ассоциации

Пример: есть класс Аудитория. У неё есть атрибуты число квадратнеых метров, граф положение, и так далее. В ней есть парты. Здесь есть некоторая ассоциация – в аудитории есть от 0 до любого числа парт. Но она может обладать таким свойством – если аудитория на ремонт закрывается, то парты из неё выносятся. Это есть агрегатная композиция. Она показывает, что парты являются составной части аудитории. Если для парты связь обязательна, но если аудитория закрывается на ремонт, то это должно подействовать на все парты в аудитории. Это действие не запросов, а обновление БД. Если это состояние такое, которое не допускает наличия парт, то с ними надо что-то сделать.

Другой пример:

Унверситет. Есть факультеты. Если уничтожается универ, то уничтожаются факультеты. В терминах РБД это каскадное удаление. Вопрос: мы можем воткнуть факультеты внутрь универсиетта, то есть денормализовали. Декан принадлежность факультета, он конечно сотрудник университета, но он в первую очередь

//Убивать студентов при закрытии факультета...

Если мы хотим запретить по книгам искать библиотеки, то в современных БД можно определить представление.

Диаграмы классов в общем-то и всё.

Разницы между диаграммами классов и ER-диаграммами нет.

Object Constraint Language

7 ноября был в Москве Билл Гейтс, и, как выяснилось, он – умный мужик.

Вопрос – имеют ли OCL и SQL одинаковую мощность.

Он дал четверокурснику задачу – придумать ограничение в OCL, которое нельзя написать в SQL, или наоборот, Он ничего не придумал.

Лектору что-то подсказывает, что по этому поводу можно сделать 3-4-5 статей.

Свойства OCL, заимствованные из UML (метаметамодель)

1. Класс, атрибут, операции

2. Объект – экземпляр класса (instance)

До и во время экзамена лектор сказал придерживаться его точки зрения относительно instance, но не потому что она абсолютно правильльная, а потому, чтл она по крайней мере понятна.

1. Ассоциации – бинарная

2. Тип данных (Boolean, Integer, Real, String – размытые понятия)

3. Значение – экземпляр типа данных

Пятёрка, она одна пятёрка, и в африке пятёрка, она только пятёрка, и нельзя её сделать шестёркой, и она пятёрка и она всегда будет пятёркой.

1. Идентификатор объекта. Два объекта назывваются идентичными, когда у них одинаковые идентификаторы. На самом деле, что в UML, что в ODMG очень сильно затуманивается операция сравнения. Есть операция мелкого сравнения (когда объект равен, если это он же), и есть операция глубокого сравнения (когда равны внутренности).

2. Объект м. б. ассоциирован с другими объектами

3. Значения, сравнение значений

Структурные ТД

1. Множество (set)

2. Мультимножество (bag)

3. Последовательность (sequence)

Лектора глубоко потрясает операция UNION над двумя списками.

context <class_name> inv;

<ocl_выражение – логическое>

1. Операции над значениями скалярных типов – скалярные выражения

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

1. Операции над объектами

2. Операции над мнвами, мультимнвами, последовательностями

1. Логические, ариф, строковые (конкатенаця, сравнение, взятие подстроки, ...)

2. Операции над атрибутами.

Получение значения атрибута

переход по экземпляру ассоциации

вызов операции объекта

<объект>.<имя атрибута>

<объект>.<имя операции>()

<объект>.<имя роли, противополож>

1. Коллекции

<коллекция> -> <имя_операции> (<список_параметров> - логвыр)

select

collect – выраж, генерир значения или объекты

незапноБ осталось чуть-чуть времени

OCL – язык не простой, а очень простой.

Вопрос, который любит задавать лектор: чем отличается OCL от языка исчисления кортежей. Разница одна. Здесь (в ОЦЛ) есть фактически одна переменная. Что мы не можем сделать с помощью этого языка – мы не можем сделать соединение, можем сделать только полусоединение.

Рисунок.

Ограничение:

Возраст служащего от 18 до 100 лет

context Служащие self.возраст>18 and self.возраст<100

Подумать, какие можно придумать ограничения

БД 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 человека. Они немногим старше лектора, сейчас, уже, конечно, не работоспособны, но вполне себе функционируют. Например, Джим Грей.