| Текущая версия |
Ваш текст |
| Строка 1: |
Строка 1: |
| - | <P STYLE="margin-bottom: 0cm">БД 03.11.06</P>
| + | == From Ebaums Inc to MurkLoar. == |
| - | <P STYLE="margin-bottom: 0cm"><BR>
| + | We at EbaumsWorld consider you as disgrace of human race. |
| - | </P>
| + | Your faggotry level exceeded any imaginable levels, and therefore we have to inform you that your pitiful resourse should be annihilated. |
| - | <P STYLE="margin-bottom: 0cm">Лектор посмотрел на полупустую
| + | Dig yourself a grave - you will need it. |
| - | аудиторию и сказал, что перед праздником трудно, всё-таки день
| + | |
| - | освобождения от поляков.</P>
| + | |
| - | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
| - | </P>
| + | |
| - | <P STYLE="margin-bottom: 0cm">Наследование типов:
| + | |
| - | </P>
| + | |
| - | <P STYLE="margin-bottom: 0cm">вещь чрезвычайно важная. Она важна как
| + | |
| - | способ повторнгоо использования. Некоторый способ определния новых
| + | |
| - | типов с помощью сущ типов – не нужно определять заново все
| + | |
| - | свойства, только доопределяем или переопределяем.
| + | |
| - | </P>
| + | |
| - | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
| - | </P>
| + | |
| - | <P STYLE="margin-bottom: 0cm">Механизмов наследования очень много.
| + | |
| - | Один из полезных обзоров есть в книжках Дейта. К тематике курса
| + | |
| - | лектора есть несколько полезных механизмов наследования, и тот,
| + | |
| - | который существует в рассм варианте диаграм, один из лучших. Лучший –
| + | |
| - | в третьем манифесте. Новое поветрие – составляются программы
| + | |
| - | для магистров, и у лектора есть желание в том курсе все эти вопросы
| + | |
| - | воткнуть. А вообще, лектор может рассказать, что он может рассказать:
| + | |
| - | наследование модели сущность связь, наследование в UML, Наследование,
| + | |
| - | Которое появилось в SQL 1999 (похоже на Джаву), свой механизм
| + | |
| - | наследования есть в моджели ООБД, этот механизм наследования близок к
| + | |
| - | тому, что есть в УМЛ, модель наследования в третьем манифесте у
| + | |
| - | Дейта. Как ни странно, лектор не может расскзать модель третьего
| + | |
| - | манифеста, потому что для этого требуется лекций 10. Некоторые
| + | |
| - | элементы есть в UML, хотя Дейта его не любит, он вообще ничего не
| + | |
| - | любит. Объединяет все механизмы семантика включения. Семантика
| + | |
| - | включения в обычных ЯП – с любым объектом подкласса можно
| + | |
| - | работать как с оюъектом суперкласса. Это понятная вещь, если мы
| + | |
| - | утосчняем, что счеловек не просто человек, а программист, то это не
| + | |
| - | значит, что с ним нельзя работать как с челдовеком. У Дейты: для
| + | |
| - | некоторых программисто в странно: есть ТД яблоко, и нет у него
| + | |
| - | свойства цвет, то по Дейте нельзя породить подтип Зелёное яблоко, то
| + | |
| - | есть нельзя породить объект, у которого етсь свойства, корторых
| + | |
| - | нельзя вывести из свойств супертипа.
| + | |
| - | </P>
| + | |
| - | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
| - | </P>
| + | |
| - | <P STYLE="margin-bottom: 0cm">Несколько лет назад у лектора были две
| + | |
| - | девочки, которые были первыми, которые занимались наследованием
| + | |
| - | типов в третьем манифесте. И одна из них ругалась, что по Дейте из
| + | |
| - | человека нельзя получить программиста.
| + | |
| - | </P>
| + | |
| - | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
| - | </P>
| + | |
| - | <P STYLE="margin-bottom: 0cm"><B>Наследование в ER-диаграммах</B></P>
| + | |
| - | <P STYLE="margin-bottom: 0cm">Суть мевханизма насл в том –
| + | |
| - | любой тип сущности может быть расщеплён на два или более подтьипа,
| + | |
| - | каждый из которых включает атрибуты супертипа (?)</P>
| + | |
| - | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
| - | </P>
| + | |
| - | <P STYLE="margin-bottom: 0cm">Если мы не уверены, что эта
| + | |
| - | совокупность подтипов включает все летательные аппараты (например,
| + | |
| - | ракетную авиацию).</P>
| + | |
| - | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
| - | </P>
| + | |
| - | <P STYLE="margin-bottom: 0cm">Понятно, что первое свойство –
| + | |
| - | атрибуты, которые опредлелены на уровне супертипа, являются
| + | |
| - | атрибутами на уровне подтипа (аналогично связи).</P>
| + | |
| - | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
| - | </P>
| + | |
| - | <P STYLE="margin-bottom: 0cm">Если у типа сущности А имеются подтипы
| + | |
| - | B1 ... Bn,
| + | |
| - | </P>
| + | |
| - | <OL>
| + | |
| - | <LI><P STYLE="margin-bottom: 0cm">любой экземпляр подтипа Bi
| + | |
| - | принадледит A.</P>
| + | |
| - | <LI><P STYLE="margin-bottom: 0cm">Если a принадлежит A, то
| + | |
| - | существует Bi, такое что a принадлжеит Bi. У Дейты этого свойства
| + | |
| - | нет. Из этого всё остальное. Требуется, чтобы у подтипа не было
| + | |
| - | собственных значений. Грубо говоря, если бы у нас были люди со
| + | |
| - | специальностями, то если мы определяем программиста, то остальных
| + | |
| - | либо в прочие либо тоже определяем до конца</P>
| + | |
| - | <LI><P STYLE="margin-bottom: 0cm">Не существуют такие Bi, Bj и а,
| + | |
| - | что а принадлжеит Bi и а принадлежит Bj. Это свойство Дейт считает
| + | |
| - | совершенно обязательным</P>
| + | |
| - | </OL>
| + | |
| - | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
| - | </P>
| + | |
| - | <P STYLE="margin-bottom: 0cm">Три замечания</P>
| + | |
| - | <OL>
| + | |
| - | <LI><P STYLE="margin-bottom: 0cm">Вот такая вот картинка очень
| + | |
| - | хорошо отражает иерархическую природу подтипизации. Она рчень
| + | |
| - | наглядная. Но. Есть одно но: вспомните пример с двойным футбольным
| + | |
| - | полю, где надо проводить стрелочки из одного угла в другой.
| + | |
| - | Фактически такой способ заставляет локально их располагать на
| + | |
| - | диаграмме. Связи – необязательно. С родной стороны удобная
| + | |
| - | схема, С другой возникают трудности при навигации</P>
| + | |
| - | <LI><P STYLE="margin-bottom: 0cm">Есть одна характеристика, которая
| + | |
| - | очень существенна – сколько супертипов может быт у одного
| + | |
| - | типа. В этой картинке – только один. Есть другой подход, когда
| + | |
| - | может быть сколько угодно. Механизм наследования таконго рода назыв
| + | |
| - | одиночным насл, а когда много смупертипов – множественное
| + | |
| - | наследование. Люди множ насл очень не любят, там есть одна проблема
| + | |
| - | – как быть с атрибутами-методами, которые имеют одинаковый
| + | |
| - | набор параметров. Есть возмодность переименования, введения
| + | |
| - | синонимов, но все они получаются доаольно нескладными. Но есть
| + | |
| - | ситуация, Дейт её показывает, когда если вводишь наследование, ноо
| + | |
| - | получается множественным. Из-за чего – он честно вводит
| + | |
| - | механизм наследлования для скалярных типов, но. Ведь в РБД есть тип
| + | |
| - | отношение – это заголовок отношения, в котором много
| + | |
| - | атрибутов. Если мы, а ещё мы хотим обеспечить наслелдодование типов
| + | |
| - | отношения, и тут хочешь-не хочешь вылезает множественное
| + | |
| - | наследование. Кпоме того, тип атрибут может быть типом отношения. А
| + | |
| - | здесь вот, даже в такой нотации, даже если захотеть, множ нас
| + | |
| - | сделать не сможешь, ибо это нарушает иерархию.
| + | |
| - | </P>
| + | |
| - | <LI><P STYLE="margin-bottom: 0cm">К наследованию может особого не
| + | |
| - | имеет. В ER-диаграмах Для одного супертипа можно сделать несколько
| + | |
| - | вариантов разбиения на плодтипы. Тип человек модет разбиватся на
| + | |
| - | плотника-доярку-программиста, а может на демократа-фашиста. Сро
| + | |
| - | связями будет не очень красиво, потому что вот мы связываем
| + | |
| - | проргаммиста Кузнецова, и беспартийных, которым Кузнецов является, с
| + | |
| - | нелюбимыми партиями, и Кузнецов связывается с партиями, хотя он с
| + | |
| - | ними ни сном, ни духом.</P>
| + | |
| - | </OL>
| + | |
| - | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
| - | </P>
| + | |
| - | <P STYLE="margin-bottom: 0cm">Взаимоисключающие связи</P>
| + | |
| - | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
| - | </P>
| + | |
| - | <P STYLE="margin-bottom: 0cm">Есть тип сущности самолёт. И этот
| + | |
| - | самолёт может назодиться в одном из двух состояний:
| + | |
| - | исправен-неисправен. Если исправен, то у него должен быть пилот, на
| + | |
| - | самом деле, лектор не уверен, что правильно ли он здесь нарисовал
| + | |
| - | пунктир, потому что сейчас пилотов меньше, чем самолётов; а если
| + | |
| - | неисправен, то должен быть связан с авиаремонтным предприятием. И на
| + | |
| - | самом деле для любого экземпляра типа сущности самолёт есть либо одна
| + | |
| - | свзяь, либо другая связь. Это обозначается вот так вот. На самом
| + | |
| - | деле, лектор хочет сразу сказать, что взаимоискл связи – вещь
| + | |
| - | избыточная, потому что это омжно сделать с помощью наследования.</P>
| + | |
| - | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
| - | </P>
| + | |
| - | <P STYLE="margin-bottom: 0cm">Объект может менять свой тип сущности.
| + | |
| - | Объекты в БД могут менять свои типы, то же самое и с людьми. Человек
| + | |
| - | может жить-жить-жить и вдруг бах и стать программистом.</P>
| + | |
| - | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
| - | </P>
| + | |
| - | <P STYLE="margin-bottom: 0cm">Как правило, когда опред концептуальная
| + | |
| - | схема, до введения ТД не доходит. Но это иногда полезно.</P>
| + | |
| - | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
| - | </P>
| + | |
| - | <P STYLE="margin-bottom: 0cm">Можно специальным образом, проводя
| + | |
| - | связь, специальным образом указать, что делать с детьми при смерти
| + | |
| - | родителей. В УМЛ это делается специального вида стрелочками. Здесь на
| + | |
| - | стороне связи со степенью единица можно написать, что делать с теми
| + | |
| - | экземпларами типа сущности. В этих диаграмах либо каскадное удаление,
| + | |
| - | либо запрещение удаления.</P>
| + | |
| - | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
| - | </P>
| + | |
| - | <P STYLE="margin-bottom: 0cm">Как рекомендовал Оракл переходить от
| + | |
| - | концептуальной схемы к реляционной, на самом деле эСКуэЛовской.
| + | |
| - | </P>
| + | |
| - | <OL>
| + | |
| - | <LI><P STYLE="margin-bottom: 0cm">простой тип сущности -
| + | |
| - | преобразуется в таблицу или переменную отношения</P>
| + | |
| - | <P STYLE="margin-bottom: 0cm">Имя сущности – имя таблицы</P>
| + | |
| - | <P STYLE="margin-bottom: 0cm">Экземпляры типа сущности –
| + | |
| - | строки таблицы (кортежами, если реляц модель)</P>
| + | |
| - | <LI><P STYLE="margin-bottom: 0cm">Атрибут – столбец таблицы
| + | |
| - | или атрибут отношения</P>
| + | |
| - | <P STYLE="margin-bottom: 0cm">Если на концептуальной схеме не
| + | |
| - | вводили типы атрибутов, то здесь их придётся вводить</P>
| + | |
| - | <P STYLE="margin-bottom: 0cm">Необязательные атрибуты –
| + | |
| - | классификация, отсутствует спецификация NO NULL</P>
| + | |
| - | <LI><P STYLE="margin-bottom: 0cm">Компоненты уникального
| + | |
| - | идентификатора – возможный ключ</P>
| + | |
| - | <P STYLE="margin-bottom: 0cm">Прпедлагается след вещь – идём
| + | |
| - | по связи, находим уник идентиф, и его компоненты перетаскиваем в
| + | |
| - | этот тип сущности, где будет опред первич ключ. В том типе сущности
| + | |
| - | в состав идентифи могут входит связи, поэтому мы должны поитй
| + | |
| - | дальше, пойти к третьему типу сущности, вытащить оттуда, и вполне
| + | |
| - | возможно, что мы можем вернуться обратно.</P>
| + | |
| - | <LI><P STYLE="margin-bottom: 0cm">Связь многие к одному (n to 1) –
| + | |
| - | перетаскиваем возможный ключ, который был построен, перетаскиваем
| + | |
| - | его в ту таблицу, которая ссотв сущности на стороне многие.</P>
| + | |
| - | </OL>
| + | |
| - | <P STYLE="margin-bottom: 0cm">В SQL огранич по ссылкам сложнее, чем в
| + | |
| - | реляц модели, из за нулей.</P>
| + | |
| - | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
| - | </P>
| + | |
| - | <P STYLE="margin-bottom: 0cm">После педедыва бует два вопроса,
| + | |
| - | которые лектор любит задавать на экзамене:</P>
| + | |
| - | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
| - | </P>
| + | |
| - | <P STYLE="margin-bottom: 0cm">//педедыв</P>
| + | |
| - | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
| - | </P>
| + | |
| - | <P STYLE="margin-bottom: 0cm">Чтобы не забыть – по поводу
| + | |
| - | разннобр видов связей – один к одному, ко многим, многие ко
| + | |
| - | многим – Дейт написал зануднейшую статью, эту статью лектор
| + | |
| - | тоже перевёл.</P>
| + | |
| - | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
| - | </P>
| + | |
| - | <P STYLE="margin-bottom: 0cm">Нетривиальные вещи – что такое
| + | |
| - | связь, когда добавляют связь один к одному и n к m. Оба вопроса возн
| + | |
| - | на экзамене.</P>
| + | |
| - | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
| - | </P>
| + | |
| - | <P STYLE="margin-bottom: 0cm">Самый дурацкий ответ – и там и
| + | |
| - | там первичный ключ. Откуда тогда возьмётся связь?</P>
| + | |
| - | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
| - | </P>
| + | |
| - | <P STYLE="margin-bottom: 0cm">На самом деле: Если оперд 1 к 1, то
| + | |
| - | надо выбрать, что где будет, в одной таблице объявл первич ключ, в
| + | |
| - | другой внешний ключ, но сам он должен быть уникальным идентификатором
| + | |
| - | первой сущности. То есть это комбинация внешнего и возможного ключа.
| + | |
| - | Если на одном конце связь необяз, то на этом конце надо определить
| + | |
| - | возм ключ, который обладает свойствами внешнего по скуэлоским
| + | |
| - | понятиям.</P>
| + | |
| - | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
| - | </P>
| + | |
| - | <P STYLE="margin-bottom: 0cm">Н к М – всегда очень сильно
| + | |
| - | показывает ответ на экзамене, готовился ли человек к экзамену вообще,
| + | |
| - | читал ли он лекции лектора, ходил ли он на лекции.</P>
| + | |
| - | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
| - | </P>
| + | |
| - | <P STYLE="margin-bottom: 0cm">Странные ответы: на двух концах внешние
| + | |
| - | ключи. Куда ссылаются? На первичные ключи. А откуда н к м?</P>
| + | |
| - | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
| - | </P>
| + | |
| - | <P STYLE="margin-bottom: 0cm">Очень хороший пример – когда
| + | |
| - | бригада милиционеров ловит банду бандитов.
| + | |
| - | </P>
| + | |
| - | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
| - | </P>
| + | |
| - | <P STYLE="margin-bottom: 0cm">Как это делается:</P>
| + | |
| - | <P STYLE="margin-bottom: 0cm">Если у нас два типа сущностей:
| + | |
| - | милиционеры и бандиты, у них есть связь. Предположим, что есть уник
| + | |
| - | ИД милиционера (МИД), уник идентификатор бандита (БИД). Заводится
| + | |
| - | таблица, один столбец МИД, другой – БИД, и в ней выписываются
| + | |
| - | все пары МИДов и БИДов, эта таблица называется таблицей связи, и
| + | |
| - | лектор не слышал других способов. На самом деле, один парень смог
| + | |
| - | придумать на экзамене страшно сложный механизм, неправильность
| + | |
| - | которого лектор доказать не смог.</P>
| + | |
| - | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
| - | </P>
| + | |
| - | <P STYLE="margin-bottom: 0cm">На самом деле, в СКЛ с любой
| + | |
| - | реализации, если в таблице опред возм ключ, то создаётся индекс, если
| + | |
| - | внеш ключ – то индекс на внеш ключе. В некоторых БД все индексы
| + | |
| - | создавались явно. И если такие вещи не делаются, их надо проделать.</P>
| + | |
| - | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
| - | </P>
| + | |
| - | <P STYLE="margin-bottom: 0cm">Теперь осталось рассмотреть две более
| + | |
| - | сложные вещи: когда сущность непростая.</P>
| + | |
| - | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
| - | </P>
| + | |
| - | <P STYLE="margin-bottom: 0cm">Те возможности, которые существуют в
| + | |
| - | ЕР-диаграмах, прекрасно реализуюися без возм СКЛ. Но когда в СКЛ
| + | |
| - | появилась подтипизация, ей воспользоваться нельзя.
| + | |
| - | </P>
| + | |
| - | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
| - | </P>
| + | |
| - | <P STYLE="margin-bottom: 0cm">Начали делить людей на программистов и
| + | |
| - | доярок, программистов на квалифиуц и не очень, квалиф на паскалевых и
| + | |
| - | джава, джава – на нетбинс и не очень. Утверждается, что не
| + | |
| - | следует делать подтипизацию более чем на три уровня в глубину. Когда
| + | |
| - | лектор это читал, ему казалось это странно. На самом деле, в жизни
| + | |
| - | лектору пришлось столкнуться с двумя примерами, которые показали...</P>
| + | |
| - | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
| - | </P>
| + | |
| - | <OL>
| + | |
| - | <LI><P STYLE="margin-bottom: 0cm">В институте была хорошая
| + | |
| - | коммандлв, которая занималась 3Д. И есть стандарт, который
| + | |
| - | называется STAN (?). В стандарте есть несколько томов, в которых
| + | |
| - | определяется ОО-язык, на котором написаны остальные тома. В мире
| + | |
| - | этим стандартом все пользуются. В том чиссле в этом стандарте есть
| + | |
| - | несколько томов, посыящённые опред 3Д-объектов, очень грамотно.
| + | |
| - | Через аморфный 3Д-объект, через параллелепипеды, циллилндры и проч
| + | |
| - | вводятреальные объекты. И наши ребята решили сделать библиотеку,
| + | |
| - | которая делалал то же самое. Получились классы с глубиной порядка
| + | |
| - | 40. И были два проекта, на гцц и борланд цпп. И когда они вносили
| + | |
| - | какое-то изменение, и нужно было построить заново систему,
| + | |
| - | уомпиляция на гцц занимала 30 миинут, на борланде, из-за того что
| + | |
| - | там был довольно хитрый механизм управления проектами – за
| + | |
| - | минуту. Выяснилось, что если мы хотим реально работать с таким
| + | |
| - | модом, нельзя делать глубину такой большой, потому что столкнетесь с
| + | |
| - | пробьлемами с компиляторами</P>
| + | |
| - | <LI><P STYLE="margin-bottom: 0cm">Был такой Майкл Броуди (?) - один
| + | |
| - | из авторов сборника семантического моделирования – работает в
| + | |
| - | компании GTI, там есть очень большой штат программистов,
| + | |
| - | программируют на С++, у них есть набор производственных классов,
| + | |
| - | программисту разрешается породить только один подкласс, если второй
| + | |
| - | – письменное разрешение у менеджера, если третий –
| + | |
| - | начальство смотрит, где недочёт в базовой библиотеке.</P>
| + | |
| - | </OL>
| + | |
| - | <P STYLE="margin-bottom: 0cm">Если нас затягивает глубокое
| + | |
| - | наследование, то что-то мы делаем не так.</P>
| + | |
| - | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
| - | </P>
| + | |
| - | <P STYLE="margin-bottom: 0cm">Как же это можно просто реализовать в
| + | |
| - | РБД:</P>
| + | |
| - | <P STYLE="margin-bottom: 0cm">Два подхода</P>
| + | |
| - | <OL>
| + | |
| - | <LI><P STYLE="margin-bottom: 0cm">Все подтипы в одной таблице. Если
| + | |
| - | ввернуться к картинке, которую лектор стер с птицелётами, то
| + | |
| - | делается таблица ЛЕТ АППАРАТ, в неё ячпомещ строки, соотв всем лет
| + | |
| - | аппаратма, и для того, чтобы понять, к какому подтипу относится
| + | |
| - | запись, вводится спец столбец, где указываетс подтип</P>
| + | |
| - | <LI><P STYLE="margin-bottom: 0cm">Таблица на подтип. Не будет
| + | |
| - | большой таблицы, будут таблицы самолётов, тпицелётов...</P>
| + | |
| - | </OL>
| + | |
| - | <P STYLE="margin-bottom: 0cm">Как работать</P>
| + | |
| - | <P STYLE="margin-bottom: 0cm">1. Если мы хотим работать с лет
| + | |
| - | аппаратами вообще, из неё выбираются только столбцы, которые для лет
| + | |
| - | аппаратов, если только с вертолётами – делаем выборку</P>
| + | |
| - | <OL START=2>
| + | |
| - | <LI><P STYLE="margin-bottom: 0cm">Если отдельно, то легко, если
| + | |
| - | вместе, то нужно объекдинить таблицы, предварительно сделав
| + | |
| - | проекцию.</P>
| + | |
| - | </OL>
| + | |
| - | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
| - | </P>
| + | |
| - | <P STYLE="margin-bottom: 0cm">Плюсы-минусы:</P>
| + | |
| - | <P STYLE="margin-bottom: 0cm">Если говорить про одну таблицу.
| + | |
| - | Вообще-то говоря, это хорошо соотв семантике сключения. Мы явно
| + | |
| - | включаем всё в одну таблицу. Мы можем работать с экз подтипа как с
| + | |
| - | экз супертипа. Сокращается количество таблиц.</P>
| + | |
| - | <P STYLE="margin-bottom: 0cm">Минусы: если етсь какое-то приложение,
| + | |
| - | которое желает работать с подтипами, в нём явно должны быть прописаны
| + | |
| - | возможности выборки, оно должно знать пор доп столбец. Втоорй минус –
| + | |
| - | много лет всегда говорят, что СССР отсталый, Россия отсталая, но
| + | |
| - | технологически мы всегда использовали методы, которые на одно
| + | |
| - | поколение впереди мировых. Когда в середине 80 (?) мы начали делать
| + | |
| - | свою СУБД, лектору было очевидно, что блокировка должна быть как
| + | |
| - | минимум на уровне строк. И вот, 15 лет спустя лектор узнаёт, что
| + | |
| - | Мелкомягкая наконец-то перешла от блокировки всей таблицы к
| + | |
| - | блокировке блоками. Поэтому, пока мы работаем с вертолётами, мы не
| + | |
| - | можем работать с птицелётами. Ещё недостаток – большое
| + | |
| - | количество столбцов. Если делать грамотно, для хранения неопр знач
| + | |
| - | память почти не тратится.</P>
| + | |
| - | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
| - | </P>
| + | |
| - | <P STYLE="margin-bottom: 0cm">Много таблиц:</P>
| + | |
| - | <P STYLE="margin-bottom: 0cm">Проще работать с подтипами</P>
| + | |
| - | <P STYLE="margin-bottom: 0cm">Упрощается логика</P>
| + | |
| - | <P STYLE="margin-bottom: 0cm">Нет лишних строк</P>
| + | |
| - | <P STYLE="margin-bottom: 0cm">Недостаток:</P>
| + | |
| - | <P STYLE="margin-bottom: 0cm">Много таблиц</P>
| + | |
| - | <P STYLE="margin-bottom: 0cm">С супертипом надо работать как с вирт
| + | |
| - | таблицей</P>
| + | |
| - | <P STYLE="margin-bottom: 0cm">Проблемы с изменением вирт таблицы</P>
| + | |
| - | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
| - | </P>
| + | |
| - | <P STYLE="margin-bottom: 0cm">Реализация взаимоискл связей:</P>
| + | |
| - | <P STYLE="margin-bottom: 0cm">//рисуются картинки, икари-кун их
| + | |
| - | должен выложить</P>
| + | |
| - | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
| - | </P>
| + | |
| - | <P STYLE="margin-bottom: 0cm">Лектору не лезет в голову ничего
| + | |
| - | приличного.</P>
| + | |
| - | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
| - | </P>
| + | |
| - | <P STYLE="margin-bottom: 0cm">Вполне приличный пример:</P>
| + | |
| - | <P STYLE="margin-bottom: 0cm">Человек и место. Где он будет ночевать.
| + | |
| - | Как правило, человек ночует дома. Но иногда он уезжает в
| + | |
| - | коммандировку, и там ночует в гостиннице. Дом и гостиниццу можно в
| + | |
| - | супертип объекдинить, а пилоты с транс предприятиями объединять в
| + | |
| - | супертип трудно.</P>
| + | |
| - | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
| - | </P>
| + | |
| - | <P STYLE="margin-bottom: 0cm">Отсалось 5 минут.</P>
| + | |
| - | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
| - | </P>
| + | |
| - | <P STYLE="margin-bottom: 0cm">УМЛ:</P>
| + | |
| - | <P STYLE="margin-bottom: 0cm">появился в Rational Software.
| + | |
| - | Получилось очень простым образом – были три умных человека,
| + | |
| - | каждый из которых занимался ОО-проектированием. И вот рацоинальный
| + | |
| - | софт смогла заманить их к себе, и заставить их поработать вместе, и
| + | |
| - | УМЛ Unified не потому, что унифицированный, а потому что они три
| + | |
| - | поработали.
| + | |
| - | </P>
| + | |
| - | <P STYLE="margin-bottom: 0cm">Начиная с 2000 года ведёт OMG.</P>
| + | |
| - | <P STYLE="margin-bottom: 0cm">В 2001 году вся работа закрылась, и
| + | |
| - | никто его улучшать не стал.</P>
| + | |
| - | <P STYLE="margin-bottom: 0cm">В прошлом году появился OODPMS, который
| + | |
| - | будет писать новую версию ODMG.</P>
| + | |
| - | {{Базы Данных}}
| + | |
| - | {{Lection-stub}}
| + | |
