Ключевые слова
Тесты
Заключение
Получение схемы реляционной базы данных из диаграммы классов UML
Если не обращать внимания на различия в терминологии*, то пригодны практически те же шаги, что и в случае преобразования в схему реляционной БД ER-диаграммы. Поэтому ограничимся только некоторыми рекомендациями, специфичными для диаграмм классов.
Рекомендация 1.Прежде, чем определять в классах операции, подумайте, что вы будете делать с этими определениями в среде целевой РСУБД. Если в этой среде поддерживаются хранимые процедуры, то, возможно, некоторые операции могут быть реализованы именно с помощью такого механизма. Но если в среде РСУБД поддерживается механизм определяемых пользователями функций, то, возможно, он окажется более подходящим.
Рекомендация 2. Помните, что сравнительно эффективно в РСУБД реализуются только ассоциации видов “один-ко-многим” и “многие-ко-многим”. Если в созданной диаграмме классов имеются ассоциации “один-к-одному”, то следует задуматься о целесообразности такого проектного решения. Реализация в среде РСУБД ассоциаций с точно заданными кратностями ролей возможна, но требует определения дополнительных триггеров, выполнение которых понизит эффективность.
Рекомендация 3.Для технологии реляционных БД агрегатные и в особенности композитные ассоциации являются неестественными. Подумайте о том, что вы хотите получить в реляционной БД, объявив некоторую ассоциацию агрегатной. Скорее всего, ничего.
Рекомендация 4.В спецификации UML говорится, что, определяя однонаправленные связи, вы можете способствовать эффективности доступа к некоторым объектам. Для технологии реляционных баз данных поддержка такого объявления вызовет дополнительные накладные расходы и тем самым снизит эффективность.
Рекомендация 5.Не злоупотребляйте возможностями OCL.
Диаграммы классов UML – это хороший и мощный инструмент для создания концептуальных схем баз данных, но, как известно, все хорошо в меру.
Нельзя сказать, что проектирование баз данных на основе семантических моделей в любом случае убыстряет и/или упрощает процесс проектирования. Все зависит от сложности предметной области, квалификации проектировщика и качества вспомогательных программных средств. Но в любом случае этап диаграммного моделирования обеспечивает следующие преимущества:
· на раннем этапе проектирования до привязки к конкретной РСУБД проектировщик может обнаружить и исправить логические огрехи проекта, руководствуясь наглядным графическим представлением концептуальной схемы;
· окончательный вид концептуальной схемы, полученной непосредственно перед переходом к формированию реляционной схемы, а может быть, и промежуточные версии концептуальной схемы должны стать часть документации целевой реляционной БД; наличие этой документации очень полезно для сопровождения и, в особенности, для изменения схемы БД в связи с изменившимися требованиями;
· при использовании CASE-средств концептуальное моделирование БД может стать частью всего процесса проектирования целевой информационной системы, что может способствовать правильной структуризации процесса, эффективности и повышению качества проекта в целом*.
Мы также хотели показать, что в контексте проектирования реляционных БД структурные методы проектирования, основанные на использовании ER-диаграмм, и объектно-ориентированные методы, основанные на использовании языка UML, различаются, главным образом, лишь терминологией. ER-модель концептуально проще UML, в ней меньше понятий, терминов, вариантов использования. И это понятно, поскольку разные варианты ER-моделей разрабатывались именно для поддержки проектирования реляционных БД, и ER-модели почти не содержат возможностей, выходящих за пределы реальных потребностей проектировщика реляционной БД.
Язык UML принадлежит объектному миру. Этот мир гораздо сложнее (если угодно, непонятнее, запутанее) реляционного мира. Поскольку UML может использоваться для унифицированного объектно-ориентированного моделирования всего, что угодно, в этом языке содержится масса различных понятий, терминов и вариантов использования, совершенно избыточных с точки зрения проектирования реляционных БД. Если вычленить из общего механизма диаграмм классов то, что действительно требуется для проектирования реляционных БД, то мы получим в точности ER-диаграммы с другой нотацией и терминологией.
Поэтому выбор конкретной концептуальной модели – это вопрос вкуса и сложившихся обстоятельств. Понятно, что если в организации уже имеется сложившаяся инфраструктура проектирования приложений, но разумно продолжать пользоваться именно ей до тех пор, пока это не станет тормозом. При построении же новой инфраструктуры стратегические соображения высшего руководства компании имеют больший вес, чем предпочтения технических специалистов, хотя эти предпочтения, с нашей точки зрения, обязательно должны учитываться.
1 (1) Какая из приведенных ниже диаграмм классов со связями обобщения демонстрирует множественное наследование класса МоторныеЛодки от базового класса ПлавательныеСредства через некоторые промежуточные классы?
(а) -
 |
(б) +
 | |||
 |
(в) -
 |
1 (2) Какая из приведенных ниже диаграмм классов со связями обобщения демонстрирует множественное наследование класса ЗлыеРазбойники от базового класса Люди через некоторые промежуточные классы?
(а) -
 | |||
 |
(б) -
| |||
 |
(в) +
 | |||
 |
1 (3) Какая из приведенных ниже диаграмм классов со связями обобщения демонстрирует множественное наследование класса МолодыеСтроителиКоммунизма от базового класса Люди через некоторые промежуточные классы?
(а) -
| |||
 |
(б) +
| |||||
 | |||||
 | |||||
(в) -
 |
 | |||
 |
2 (1) Какая из приведенных ниже диаграмм классов правильно моделирует следующую ситуацию: имеется ряд гостиниц, в каждой из которых от 10 до 1000 комнат; зная гостиницу, можно получить данные обо всех ее комнатах, но не наоборот.
(а)
|
| |
 |
(б) -
 |
(в) -
2 (2) Какая из приведенных ниже диаграмм классов правильно моделирует следующую ситуацию: имеется несколько военных кораблей, на каждом из которых служит не менее 50 человек; среди моряков каждого корабля имеется пять мичманов и один капитан.
|
|
| |
 | |||
 |
|
|
| |
 |
|
| |
| |
| |||
 |
2 (3) Какая из приведенных ниже диаграмм классов правильно моделирует следующую ситуацию: имеется несколько библиотек, в каждой из которых имеется от 2000 до 20000 книг. У библиотеки может быть до 100 зарегистрированных читателей, каждый из которых может взять из библиотеки от 2 до 5 книг. Один из читателей библиотеки является ее заведующим.
(а) +
 |
(б) -
 |
(в)
 |
3 (1) Пусть имеется следующая диаграмма классов:
| |
|
| ||||||
| ||||||||
 | ||||||
|
|
Имеется несколько военных кораблей, на каждом из которых служат матросы, пять мичманов и капитан. При наличии представленной диаграммы требуется сформулировать на языке ограничение: каждый мичман является мичманом на том корабле, на котором он служит моряком. Какие из приведенных формулировок правильны?
(а) -
context МОРЯК inv:
self.корабль.мичман ® SELECT (корабль.номер ¹ self.номер)
® size () = 0
(б) +
context КОРАБЛЬ inv:
self.мичман ® SELECT (корабльМичманов.номер ¹ корабль.номер)
® size () = 0
(в) +
context МОРЯК inv:
self.корабльМичманов.номер = self.корабль.номер
3 (2) Пусть имеется следующая диаграмма классов:
 |
Имеется несколько библиотек, у которых есть зарегистрированные читатели. При наличии представленной диаграммы требуется сформулировать на языке ограничение: у каждого читателя на руках книги только из той библиотеки, в которой он зарегистрирован. Какие из приведенных формулировок правильны?
(а) -
context ЧИТАТЕЛЬ inv:
self.читает ® SELECT (self.зарегистрирован.номер ¹ вБиблиотеке.номер)
® size () = 0
(б) +
context БИБЛИОТЕКА inv:
self.читают ® COLLECT (читает)
® SELECT (self.номер ¹ вБиблиотеке.номер) ® size () = 0
(в) +
context КНИГА inv:
self.наРуках ® COLLECT (зарегистрирован)
® SELECT (номер ¹ вБиблиотеке.номер) ® size () = 0
3 (3) Пусть имеется следующая диаграмма классов:
 |
Эта диаграмма почти совпадает с диаграммой классов с рис. 10.14, но на ней появился новый класс ПРОЕКТ: каждый служащий теперь может участвовать в проектах (до трех проектов), и в каждом проекте участвует, по крайней мере, один служащий. При наличии представленной диаграммы требуется сформулировать на языке ограничение: ни в одном проекте не должны работать служащие из отделов, образованных после начала проекта. Какие из приведенных формулировок правильны?
(а) +
context ПРОЕКТ inv:
self.служащий ® COLLECT (отдел)
® SELECT (годОснования > self.годОснования) ® size () = 0
(б) +
context СЛУЖАЩИЙ inv:
self.проект ® SELECT (годОснования < self.отдел.годОснования)
® size () = 0
(в) +
context ОТДЕЛ inv:
self.служащий ® COLLECT (проект)
® SELECT (годОснования < self.годОснования) ® size () = 0
4 (1) Для диаграммы классов, приведенной в упр. 3(1), требуется сформулировать ограничение: среди моряков любого корабля имеется не меньше пяти матросов. Какие из приведенных формулировок правильны?
(а) -
context КОРАБЛЬ inv:
self.экипаж ® size () ³ 10
(б) +
context КОРАБЛЬ inv:
(self.экипаж symmetricDifference (self.капитан UNION self.мичман))
® size () ³ 5
(в) +
context МОРЯК inv:
(self.корабль.экипаж symmetricDifference (self.корабль.капитан UNION self.корабль.мичман)) ® size () ³ 5
4 (2) Для диаграммы классов, приведенной в упр. 3(2), требуется сформулировать ограничение: у любого читателя на руках может находиться не более одной книги категории “редкая”. Какие из приведенных формулировок правильны?
(а) +
context ЧИТАТЕЛЬ inv:
self.читает ® SELECT (категория = ‘редкая’) ® size () £ 1
(б) -
context БИБЛИОТЕКА inv:
((self.книги ® SELECT (категория = ‘редкая’) ® size ()) -
(self.читают ® COLLECT (читает)
® SELECT (категория = ‘редкая’) ® size ())) £
self.читают ® size ()
(в) -
context КНИГА inv:
(self ® SELECT (категория = ‘редкая’) ® size ()) ³
(self.наРуках ® COLLECT (читает) ® size ())
4 (3) Для диаграммы классов, приведенной в упр. 3(3), требуется сформулировать ограничение: ни один из участников какого-либо проекта не должен работать в отделе, число работников в котором превышает число участников данного проекта. Какие из приведенных формулировок правильны?
(а) +
context ПРОЕКТ inv:
(self.служащий ® COLLECT (отдел) ® COLLECT (служащий) ® size ()) £
(self.служащий ® size ())
(б) +
context СЛУЖАЩИЙ inv:
(self.ПРОЕКТ ® COLLECT (служащие) ® size ()) ³
(self.отдел ® COLLECT (служащие) ® size ())
(в) +
context ОТДЕЛ inv:
(self.служащий ® COLLECT (проект)
® COLLECT (служащий) ® size ()) ³
(self.служащий ® size ())
Лекция 11. Язык баз данных SQL: общее введение, типы данных и средства определения доменов
Оставшаяся часть этого курса посвящается языку реляционных баз данных SQL. В курсе о реляционных базах данных невозможно обойтись без материала, который относится к этому языку. Это связано совсем не с тем, что язык представляет собой особое достижение в области реляционных БД. Напротив, многие черты SQL, начиная с появления самых первых его вариантов, противоречили принципам реляционной модели данных, заложенным Эдгаром Коддом. С другой стороны, спецификация языка SQL, по своей сути, является завершенной спецификацией модели данных, которая сегодня служит в роли суррогата реляционной модели.
Если мы попытались обойтись в этом курсе без обсуждения языка SQL, курс был бы полностью оторван от жизни. Сегодня SQL является lingua franca в мире баз данных. Интерфейсы, основанные на SQL, поддерживаются почти во всех практически используемых СУБД, далеко не все из которых первоначально разрабатывались как реляционные системы. И похоже, что эта ситуация не изменится радикальным образом при жизни нынешнего поколения. Кроме того, язык сам по себе достаточно интересен. В нем нашел отражение многолетний практический опыт многих людей, и он впитал в себя многие положительные (и отрицательные) черты других языков и подходов (не только языков баз данных и не только реляционного подхода).
В данной лекции после небольшой исторической справки и краткого введения в структуру языка SQL обсуждаются типы данных, допустимые в языке SQL и в SQL-ориентированных базах данных, а также языковые средства определения, изменения определения и отмены определения доменов.
Язык баз данных SQL, СУБД System R, SEQUEL, SQL/DS, DB2, Oracle, Informix, Sybase, Microsoft SQL Server, стандарт SQL/86, стандарт SQL/89, SQL2, стандарт SQL/92, SQL/CLI, ODBC, JDBC, SQL/PSM, SQL3, стандарт SQL:1999, SQL/Bindings, SQL/Transaction, SQL/Temporal, SQL/MED, SQL/OLB, SQL/OLAP, стандарт SQL:2003, SQL/Schemata, SQL/JRT, SQL/XML, прямой SQL, встроенный SQL, динамический SQL, базовый, промежуточный и полный уровни языка SQL, система типов языка SQL, точные числовые типы, приближенные числовые типы, типы символьных строк, типы битовых строк, типы даты и времени, типы временных интервалов, булевский тип, типы коллекций, анонимные строчные типы, типы, определяемые пользователем, ссылочные типы, истинно целые типы, точные типы, допускающие наличие дробной части, литералы типов, типы времени и временной метки с временной зоной, трехзначная логика, типы массивов, конструктор типа массива, типы мультимножеств, конструктор типа мультимножества, конструктор анонимного строчного типа, структурные определяемые пользователем типы, индивидуальные определяемые пользователем типы, типизированная таблица, ссылочные значениями, определение домена, оператор CREATE DOMAIN, значение домена по умолчанию, ограничение домена, изменение определения домена, оператор ALTER DOMAIN, отмена определения домена, оператор DROP DOMAIN, неявные преобразования типов, правила приводимости типов, явные преобразования типов или доменов, оператор CAST.