Вордовские лекции (1121814), страница 11

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

Текст из файла (страница 11)

Первое утверждение лектора: для БД с достаточно большой сложностью (более ста таблиц0 надо использовать какую-нибудь нотацию. И проблем перевести эту нотацию в SQL проблем не составляет, но картинки обязательно должны сохраняться на время проектирования БД.

Положительнеый пример: проектировали книжный магазин, простая БД на 30-40 таблиц, и тогда таки сделали картинки. Продаётся уже в 4 раз.

Ручная документация проекта БД, желательно, чтобы не в один этап, можно там и нормализацию проводить, и можно задокументировать весь процесс.

CASE-системы (computer Aided Software Ingeenering), но это не совсем CASE, больше похоже на САПР.

Когда в Москве пыталось появиться первое представительство Sun microsystems, и тогда на презентацию привезли 19-дюймовый монитор, где они показывали, как можно было использовать CASE для Оракла.

Неистребимый порок диаграмного предсталения – какой бы большой монитор не был, всё равно придётся скроллить.

Появились рисовалк, и народ начал рисовать. Почему нельзя сделать компилятор для графич нотации? И появлись первые CASE-средства, которые умели генерировать SQL. Смотря на то, что SQL почти не менялся за 15 лет, в каждой реализации свои отклонения, и генераторы должны привязываться к платформе, и такое могут позвольить себе немногие, например, ИБМ.

Следующий шаг: как человек рисует картинки, откуда он берёт информацию? На самом деле в области проектирования БД не надо думать, что картинку придумывает проектировщик, её придумывают люди, эксперты в предметной области. И возникает идея: есди проектировщик может выслушать людей, почему программа не может. Подобные проекты делались в Киеве, и закончились с СССР – смесь экспертной системы и CASE-средства, там были шаблоны ответов, эксперты ответы давали, система проверяла всё на непроречивость, и когда необходимые графы внутри таблицы были заполнены, она рисовала картинки, она показывала картинку проектировщику и он говорит, подходит картинка или нет, если нет, то задавались уточняющие вопросы. Они обеспечивали 3НФ уже в конце 80х годов. Лектор не понимает, почему нет ни одной коммерческой системы не сделано, хотя понятно уже 20 лет как, что это можно.

Далее: есть красивое диаграмное представление, сжема БД, и мы умеем отобразить эту схему в SQLовскую схему, но почему мы тогда заставляем работать людей в терминах SQL, а не схем? Почемцу мы не можем отобразить операции над схемой в операции на SQL, Такие опыты производились, и были средства, которые позволяли взаимодействовать с БД. И возникает вопрос – а на фига тогда SQL,Это породило направление, которое SQL было задавлено – прямая реализация семантическим представлением. Одно время лектору казалось, 14 лет назад, когда он впервые готовил этот курс, лектору кахалось, что сработают ООБД. Хотя понятно, что ОО позволяется сохранять больше семантики, чем реляционные БД, там богатые структуры данных, их можно разным образом интерпретировать. Но этого не произошло, и ожидания лектора от ООБД были преувеличены, и он ошибался в том, что они обесп более высокую семантику, и лектор теперь в этом уверен.

Теперь лектор будет рассказывать просто про нотацию, конкретные модели.

ER-диаграмы

(Entity-Relationship) – сущность-связь

Почему в математике нет терминологической проблемы – потому что там все термины долговечны. Компьютерная технология меняется очень быстро, и термины, которые вводятся 50 лет назад, уже не использоуются. И такой суеты, как в последние 6 лет, лектор не видел. Даже если новое – это хорошо забытое старое, маркетологи всё равно придумывают новые термины.

Сущность – понятие также неопределимое, также как и процесс, жизнь.

В UML это называется association.

Peter Chen 1976

Oracle Case Method – был представлен свой диалект диаграм ER, который дектор полюбил по двум причинам. В этой нотации очень простые графич символы и их хватает. Во всех остальных те же самые понятие, но немного другие графич символы. Поэтому лектор будет использовать именно этот диалект.

Определиния Орвкла нравятся лектору своей эмоциональность.

1. Сущность

2. Связь

3. Атрибут

На овощном складе есть куча реальных предметов.

С другой стороны – методы решения дифуров, ничего реального нет. Но мы можем скзать, чт хотим ввести сущность дифур, у неё будут понятнве свойства, и будут связи.

Последнее, что хочет скзаать лектор: сущность во всех видах диаграм изобр в виде прямоуг, в нём должно писаться имя сущности, в этой нотации должно быть оно большими буквами. В этой нотации, когда мы вводим этот прямоуголиничек, мы вводим новый тип.

БД 02.11.06

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

Некоторые потребности модели в отрыве от потребностей РБД. Оракловский синтаксис сильно ориентирован на SQL 80х годов.

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

Основные понятия:

1. Сущность

2. Связь

3. Атрибут

В прошлый раз лектор остановился на понятии сущности. Это реальный или представляемый объект, информация о котором должна сохраняться и быть доступной. На дианграме изображается в виде прямоугольника, имя большими буквами, и ещё могут приводиться примеры.

На само деле, это немножечко отходит от понятия класса в диаграме классов uML, потому что там это требованрие необязательно, и там считается, что если мы определяем класс Корова, то там может быть много объектов, и часть из них может быть одинакова. Здесь все Коровы должны быть разные.

Связь

Связь (так, как это было у Оракла) – графически изобр ассоциация, устанавливаемая между двумя сущностями.

В одном диалекте связь – ассоциация, в лругой ассоциация – подвид связи.

Связь бинарна.

На практике:

Люди ездят на поездах, у поездов машинисты, машинисты работают в жд парке и т. д.

В принципе, все отношения в БД можно сделать бинарными. Связи один с одним в действиетльности являются достаточными, и в частности, Оракл утверждал, что невозможно придумать такой жизненной ситуации, когда нельзя её привести к бинарному случаю.

Пример: есть рыбак, у него есть несколько лодок, каждая находится на своём водохранилище, и рыбак может ловить рыбу на любом водохранилище. Кажется, что связь тренарная, но её можно преобразовать к бинарной и это будет понятнее. В некоторых диалетах связи не только бинарные, но от этого не легче.

Связи устанавливаются не между экземплярами, а между типами сущностей. Это понятие, которое распространяетя на все экземпляры типов сущностей, и можно говорить об экземпляре типов связей.

Есть сущности и связи между ними, и Когда происходит инстанциация, ... .

У каждого типа связиопределяются два конца. Они называются ролями по отношению к соотв типам сущностей. В терминологии Оракловских диаграмм роли называются концами типов связей.

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

Связь представляется в виде ненаправленной линии, и она может проводиться между двумя прямоугольниками или связывать прямогульни сам с обой. В последнем случае связь называается рекурсивной. Это слово не очень хорошее, но не будем привязывааться к терминологии. В месте стыковки конца связи с сущностью указывается, сколько экземпляров типа сущности могут стыковаться с типом связи (?) .

Есть два типа сущности:

пассажир может иметь сколько угодно билетов, и у белета ровно один пассажир

В терминологии Оракла это называется степенью. Слева степень много, Справа 1. Пунктир – необязательность связи.

Лектор недавно перевёл несколько новых статей Дейта, одна из них в частности ругает диаграммы классов (UML), у них понятие, сколько экземпляров объектов может присутствоватьна конце связи называется multiplicity, и Дейта ругает людей, которые заменили (cardinality) мощность на множественность, которая неизвестно что обозначает. Русские программисты придумали слово кратность.

Пассажир может иметь 0 или сколько угодно билетов.

Пример рекурсивной связи

Каждый – сын мужчины, и у мужчины 0 или более детей.

Атрибут

Атрибут – любая деталь, которая служит для уточнения, идентификации, классификации, числовой характеристики или выражения состояния сущности.

Лектора эти определнения забавляют.

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

Пример: книга. Казалось бы, тривиальная вещь. Рассмотрим два случая: книга на складе и книга в библиотеке. Для библ и для склада экземпляр сущности книга является разным. И для склада лучшим идентификатором будет ISBN, а для библиотеки – уникальный идентификатор библиотеки и уникальный идентификатор библиотеки.

Уникальным идентификатором типа сущности может являться атрибут, комбинация атрибутов, связь, комбинация связей, комбинация связей и атрибутов.

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

//педедыв

Пример про паспорт

Зная порялки паспортного стола, делаем связь принадлежит необязательной.

Курс определяется профессором и дисциплиной.

Нормальные формы

1НФ – устраняются атрибуты, которые содержат множественные значения

(пример с аэродромом и авиамот предп)

Проблема в том, что ремонтируют самолёты, а не аэродром, и может оказаться, что самолёт может починять только одно предприятие, и получается что аэродром подчиняется неск предприятиями, хотя это не так.

... //ну задолбался я писать

Лектор всегда мечтал знать, на каком самолёте полетит.

РЕЙС

номер рейса

аэропорт вылета

аэропорт прибытия

ЭЛЕМЕНТ РАСПИСАНИЯ

дата вылета

бортовой номер

ГОРОД

...

Эта схема стала лучше. Когда мы говорили о РБД, мы говорили о аномалиях обновления. Здесь же мы просто вытаскиваем сущности.

Очень важные три вещи:

1. наследование. Подтипы и супертипы. Механизм наследования вообще важен. Важно определять новые типы.

2. Взаимоисключающие связи. Несколько связей, но может существовать только одна

3. Уточняемые степени связи.

Уточняемые степени.

Сейчас мы можем сказать:

1. Существует точно одна связь

2. Существует 0 или одна связь

Пример (аналог) – регэкспы в никсах. * и +. Ноь иногда хочется сказать более точно.

В Китае было нельзя иметь больше 2 детей. Родили третьего – родителей в тюрьму, детей в детдом. Хотелось бы иметь средства, которые позволяют это указывать. Для этого рядом с концом связи пишется необх. Степень связи. Чем блоьше подробностей накручиваем на степень связи, тем сложнее ограничения целостности.

Не исключено, что в след четверг контрольной не будет.

10 лекции не будет, ибо защита диссертации.

Придётся контрольную сдвинуть на одну неделю.

БД 03.11.06

Лектор посмотрел на полупустую аудиторию и сказал, что перед праздником трудно, всё-таки день освобождения от поляков.

Наследование типов:

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

Механизмов наследования очень много. Один из полезных обзоров есть в книжках Дейта. К тематике курса лектора есть несколько полезных механизмов наследования, и тот, который существует в рассм варианте диаграм, один из лучших. Лучший – в третьем манифесте. Новое поветрие – составляются программы для магистров, и у лектора есть желание в том курсе все эти вопросы воткнуть. А вообще, лектор может рассказать, что он может рассказать: наследование модели сущность связь, наследование в UML, Наследование, Которое появилось в SQL 1999 (похоже на Джаву), свой механизм наследования есть в моджели ООБД, этот механизм наследования близок к тому, что есть в УМЛ, модель наследования в третьем манифесте у Дейта. Как ни странно, лектор не может расскзать модель третьего манифеста, потому что для этого требуется лекций 10. Некоторые элементы есть в UML, хотя Дейта его не любит, он вообще ничего не любит. Объединяет все механизмы семантика включения. Семантика включения в обычных ЯП – с любым объектом подкласса можно работать как с оюъектом суперкласса. Это понятная вещь, если мы утосчняем, что счеловек не просто человек, а программист, то это не значит, что с ним нельзя работать как с челдовеком. У Дейты: для некоторых программисто в странно: есть ТД яблоко, и нет у него свойства цвет, то по Дейте нельзя породить подтип Зелёное яблоко, то есть нельзя породить объект, у которого етсь свойства, корторых нельзя вывести из свойств супертипа.

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

Характеристики

Список файлов лекций