Базы Данных, 18 лекция (от 03 ноября)
Материал из ESyr's Wiki pages.
БД 03.11.06
Лектор посмотрел на полупустую аудиторию и сказал, что перед праздником трудно, всё-таки день освобождения от поляков.
Наследование типов:
вещь чрезвычайно важная. Она важна как способ повторнгоо использования. Некоторый способ определния новых типов с помощью сущ типов – не нужно определять заново все свойства, только доопределяем или переопределяем.
Механизмов наследования очень много. Один из полезных обзоров есть в книжках Дейта. К тематике курса лектора есть несколько полезных механизмов наследования, и тот, который существует в рассм варианте диаграм, один из лучших. Лучший – в третьем манифесте. Новое поветрие – составляются программы для магистров, и у лектора есть желание в том курсе все эти вопросы воткнуть. А вообще, лектор может рассказать, что он может рассказать: наследование модели сущность связь, наследование в UML, Наследование, Которое появилось в SQL 1999 (похоже на Джаву), свой механизм наследования есть в моджели ООБД, этот механизм наследования близок к тому, что есть в УМЛ, модель наследования в третьем манифесте у Дейта. Как ни странно, лектор не может расскзать модель третьего манифеста, потому что для этого требуется лекций 10. Некоторые элементы есть в UML, хотя Дейта его не любит, он вообще ничего не любит. Объединяет все механизмы семантика включения. Семантика включения в обычных ЯП – с любым объектом подкласса можно работать как с оюъектом суперкласса. Это понятная вещь, если мы утосчняем, что счеловек не просто человек, а программист, то это не значит, что с ним нельзя работать как с челдовеком. У Дейты: для некоторых программисто в странно: есть ТД яблоко, и нет у него свойства цвет, то по Дейте нельзя породить подтип Зелёное яблоко, то есть нельзя породить объект, у которого етсь свойства, корторых нельзя вывести из свойств супертипа.
Несколько лет назад у лектора были две девочки, которые были первыми, которые занимались наследованием типов в третьем манифесте. И одна из них ругалась, что по Дейте из человека нельзя получить программиста.
Наследование в ER-диаграммах
Суть мевханизма насл в том – любой тип сущности может быть расщеплён на два или более подтьипа, каждый из которых включает атрибуты супертипа (?)
Если мы не уверены, что эта совокупность подтипов включает все летательные аппараты (например, ракетную авиацию).
Понятно, что первое свойство – атрибуты, которые опредлелены на уровне супертипа, являются атрибутами на уровне подтипа (аналогично связи).
Если у типа сущности А имеются подтипы B1 ... Bn,
любой экземпляр подтипа Bi принадледит A.
Если a принадлежит A, то существует Bi, такое что a принадлжеит Bi. У Дейты этого свойства нет. Из этого всё остальное. Требуется, чтобы у подтипа не было собственных значений. Грубо говоря, если бы у нас были люди со специальностями, то если мы определяем программиста, то остальных либо в прочие либо тоже определяем до конца
Не существуют такие Bi, Bj и а, что а принадлжеит Bi и а принадлежит Bj. Это свойство Дейт считает совершенно обязательным
Три замечания
Вот такая вот картинка очень хорошо отражает иерархическую природу подтипизации. Она рчень наглядная. Но. Есть одно но: вспомните пример с двойным футбольным полю, где надо проводить стрелочки из одного угла в другой. Фактически такой способ заставляет локально их располагать на диаграмме. Связи – необязательно. С родной стороны удобная схема, С другой возникают трудности при навигации
Есть одна характеристика, которая очень существенна – сколько супертипов может быт у одного типа. В этой картинке – только один. Есть другой подход, когда может быть сколько угодно. Механизм наследования таконго рода назыв одиночным насл, а когда много смупертипов – множественное наследование. Люди множ насл очень не любят, там есть одна проблема – как быть с атрибутами-методами, которые имеют одинаковый набор параметров. Есть возмодность переименования, введения синонимов, но все они получаются доаольно нескладными. Но есть ситуация, Дейт её показывает, когда если вводишь наследование, ноо получается множественным. Из-за чего – он честно вводит механизм наследлования для скалярных типов, но. Ведь в РБД есть тип отношение – это заголовок отношения, в котором много атрибутов. Если мы, а ещё мы хотим обеспечить наслелдодование типов отношения, и тут хочешь-не хочешь вылезает множественное наследование. Кпоме того, тип атрибут может быть типом отношения. А здесь вот, даже в такой нотации, даже если захотеть, множ нас сделать не сможешь, ибо это нарушает иерархию.
К наследованию может особого не имеет. В ER-диаграмах Для одного супертипа можно сделать несколько вариантов разбиения на плодтипы. Тип человек модет разбиватся на плотника-доярку-программиста, а может на демократа-фашиста. Сро связями будет не очень красиво, потому что вот мы связываем проргаммиста Кузнецова, и беспартийных, которым Кузнецов является, с нелюбимыми партиями, и Кузнецов связывается с партиями, хотя он с ними ни сном, ни духом.
Взаимоисключающие связи
Есть тип сущности самолёт. И этот самолёт может назодиться в одном из двух состояний: исправен-неисправен. Если исправен, то у него должен быть пилот, на самом деле, лектор не уверен, что правильно ли он здесь нарисовал пунктир, потому что сейчас пилотов меньше, чем самолётов; а если неисправен, то должен быть связан с авиаремонтным предприятием. И на самом деле для любого экземпляра типа сущности самолёт есть либо одна свзяь, либо другая связь. Это обозначается вот так вот. На самом деле, лектор хочет сразу сказать, что взаимоискл связи – вещь избыточная, потому что это омжно сделать с помощью наследования.
Объект может менять свой тип сущности. Объекты в БД могут менять свои типы, то же самое и с людьми. Человек может жить-жить-жить и вдруг бах и стать программистом.
Как правило, когда опред концептуальная схема, до введения ТД не доходит. Но это иногда полезно.
Можно специальным образом, проводя связь, специальным образом указать, что делать с детьми при смерти родителей. В УМЛ это делается специального вида стрелочками. Здесь на стороне связи со степенью единица можно написать, что делать с теми экземпларами типа сущности. В этих диаграмах либо каскадное удаление, либо запрещение удаления.
Как рекомендовал Оракл переходить от концептуальной схемы к реляционной, на самом деле эСКуэЛовской.
простой тип сущности - преобразуется в таблицу или переменную отношения
Имя сущности – имя таблицы
Экземпляры типа сущности – строки таблицы (кортежами, если реляц модель)
Атрибут – столбец таблицы или атрибут отношения
Если на концептуальной схеме не вводили типы атрибутов, то здесь их придётся вводить
Необязательные атрибуты – классификация, отсутствует спецификация NO NULL
Компоненты уникального идентификатора – возможный ключ
Прпедлагается след вещь – идём по связи, находим уник идентиф, и его компоненты перетаскиваем в этот тип сущности, где будет опред первич ключ. В том типе сущности в состав идентифи могут входит связи, поэтому мы должны поитй дальше, пойти к третьему типу сущности, вытащить оттуда, и вполне возможно, что мы можем вернуться обратно.
Связь многие к одному (n to 1) – перетаскиваем возможный ключ, который был построен, перетаскиваем его в ту таблицу, которая ссотв сущности на стороне многие.
В SQL огранич по ссылкам сложнее, чем в реляц модели, из за нулей.
После педедыва бует два вопроса, которые лектор любит задавать на экзамене:
//педедыв
Чтобы не забыть – по поводу разннобр видов связей – один к одному, ко многим, многие ко многим – Дейт написал зануднейшую статью, эту статью лектор тоже перевёл.
Нетривиальные вещи – что такое связь, когда добавляют связь один к одному и n к m. Оба вопроса возн на экзамене.
Самый дурацкий ответ – и там и там первичный ключ. Откуда тогда возьмётся связь?
На самом деле: Если оперд 1 к 1, то надо выбрать, что где будет, в одной таблице объявл первич ключ, в другой внешний ключ, но сам он должен быть уникальным идентификатором первой сущности. То есть это комбинация внешнего и возможного ключа. Если на одном конце связь необяз, то на этом конце надо определить возм ключ, который обладает свойствами внешнего по скуэлоским понятиям.
Н к М – всегда очень сильно показывает ответ на экзамене, готовился ли человек к экзамену вообще, читал ли он лекции лектора, ходил ли он на лекции.
Странные ответы: на двух концах внешние ключи. Куда ссылаются? На первичные ключи. А откуда н к м?
Очень хороший пример – когда бригада милиционеров ловит банду бандитов.
Как это делается:
Если у нас два типа сущностей: милиционеры и бандиты, у них есть связь. Предположим, что есть уник ИД милиционера (МИД), уник идентификатор бандита (БИД). Заводится таблица, один столбец МИД, другой – БИД, и в ней выписываются все пары МИДов и БИДов, эта таблица называется таблицей связи, и лектор не слышал других способов. На самом деле, один парень смог придумать на экзамене страшно сложный механизм, неправильность которого лектор доказать не смог.
На самом деле, в СКЛ с любой реализации, если в таблице опред возм ключ, то создаётся индекс, если внеш ключ – то индекс на внеш ключе. В некоторых БД все индексы создавались явно. И если такие вещи не делаются, их надо проделать.
Теперь осталось рассмотреть две более сложные вещи: когда сущность непростая.
Те возможности, которые существуют в ЕР-диаграмах, прекрасно реализуюися без возм СКЛ. Но когда в СКЛ появилась подтипизация, ей воспользоваться нельзя.
Начали делить людей на программистов и доярок, программистов на квалифиуц и не очень, квалиф на паскалевых и джава, джава – на нетбинс и не очень. Утверждается, что не следует делать подтипизацию более чем на три уровня в глубину. Когда лектор это читал, ему казалось это странно. На самом деле, в жизни лектору пришлось столкнуться с двумя примерами, которые показали...
В институте была хорошая коммандлв, которая занималась 3Д. И есть стандарт, который называется STAN (?). В стандарте есть несколько томов, в которых определяется ОО-язык, на котором написаны остальные тома. В мире этим стандартом все пользуются. В том чиссле в этом стандарте есть несколько томов, посыящённые опред 3Д-объектов, очень грамотно. Через аморфный 3Д-объект, через параллелепипеды, циллилндры и проч вводятреальные объекты. И наши ребята решили сделать библиотеку, которая делалал то же самое. Получились классы с глубиной порядка 40. И были два проекта, на гцц и борланд цпп. И когда они вносили какое-то изменение, и нужно было построить заново систему, уомпиляция на гцц занимала 30 миинут, на борланде, из-за того что там был довольно хитрый механизм управления проектами – за минуту. Выяснилось, что если мы хотим реально работать с таким модом, нельзя делать глубину такой большой, потому что столкнетесь с пробьлемами с компиляторами
Был такой Майкл Броуди (?) - один из авторов сборника семантического моделирования – работает в компании GTI, там есть очень большой штат программистов, программируют на С++, у них есть набор производственных классов, программисту разрешается породить только один подкласс, если второй – письменное разрешение у менеджера, если третий – начальство смотрит, где недочёт в базовой библиотеке.
Если нас затягивает глубокое наследование, то что-то мы делаем не так.
Как же это можно просто реализовать в РБД:
Два подхода
Все подтипы в одной таблице. Если ввернуться к картинке, которую лектор стер с птицелётами, то делается таблица ЛЕТ АППАРАТ, в неё ячпомещ строки, соотв всем лет аппаратма, и для того, чтобы понять, к какому подтипу относится запись, вводится спец столбец, где указываетс подтип
Таблица на подтип. Не будет большой таблицы, будут таблицы самолётов, тпицелётов...
Как работать
1. Если мы хотим работать с лет аппаратами вообще, из неё выбираются только столбцы, которые для лет аппаратов, если только с вертолётами – делаем выборку
Если отдельно, то легко, если вместе, то нужно объекдинить таблицы, предварительно сделав проекцию.
Плюсы-минусы:
Если говорить про одну таблицу. Вообще-то говоря, это хорошо соотв семантике сключения. Мы явно включаем всё в одну таблицу. Мы можем работать с экз подтипа как с экз супертипа. Сокращается количество таблиц.
Минусы: если етсь какое-то приложение, которое желает работать с подтипами, в нём явно должны быть прописаны возможности выборки, оно должно знать пор доп столбец. Втоорй минус – много лет всегда говорят, что СССР отсталый, Россия отсталая, но технологически мы всегда использовали методы, которые на одно поколение впереди мировых. Когда в середине 80 (?) мы начали делать свою СУБД, лектору было очевидно, что блокировка должна быть как минимум на уровне строк. И вот, 15 лет спустя лектор узнаёт, что Мелкомягкая наконец-то перешла от блокировки всей таблицы к блокировке блоками. Поэтому, пока мы работаем с вертолётами, мы не можем работать с птицелётами. Ещё недостаток – большое количество столбцов. Если делать грамотно, для хранения неопр знач память почти не тратится.
Много таблиц:
Проще работать с подтипами
Упрощается логика
Нет лишних строк
Недостаток:
Много таблиц
С супертипом надо работать как с вирт таблицей
Проблемы с изменением вирт таблицы
Реализация взаимоискл связей:
//рисуются картинки, икари-кун их должен выложить
Лектору не лезет в голову ничего приличного.
Вполне приличный пример:
Человек и место. Где он будет ночевать. Как правило, человек ночует дома. Но иногда он уезжает в коммандировку, и там ночует в гостиннице. Дом и гостиниццу можно в супертип объекдинить, а пилоты с транс предприятиями объединять в супертип трудно.
Отсалось 5 минут.
УМЛ:
появился в Rational Software. Получилось очень простым образом – были три умных человека, каждый из которых занимался ОО-проектированием. И вот рацоинальный софт смогла заманить их к себе, и заставить их поработать вместе, и УМЛ Unified не потому, что унифицированный, а потому что они три поработали.
Начиная с 2000 года ведёт OMG.
В 2001 году вся работа закрылась, и никто его улучшать не стал.
В прошлом году появился OODPMS, который будет писать новую версию ODMG.
