Тема_7 (1122352), страница 6
Текст из файла (страница 6)
Кузнецов. Базы данных.71 Проектирование РБДСемантическая модель Entity-Relationship(54)Получение реляционной схемы из ER-диаграммы (7) Супертипы и подтипы(2)При использовании второго метода для каждогоподтипа первого уровня (непосредственногоподтипа максимального супертипа) создаетсяотдельная таблицаДля более глубоких уровней наследованияприменяется первый методСупертип воссоздается с помощью объединенияпроекций таблиц, соответствующих подтипам, назаголовок таблицы супертипа (т.е. из всех таблицподтипов выбираются общие столбцы – столбцысупертипа)29.10.2009С.Д.
Кузнецов. Базы данных.72 Проектирование РБДСемантическая модель Entity-Relationship(55)Получение реляционной схемы из ER-диаграммы (8) Супертипы и подтипы(3)У каждого способа есть свои достоинства инедостаткиК достоинствам первого способа (общая таблицадля супертипа и всех его подтипов) можноотнести следующее:соответствие логике супертипов и подтипов: посколькулюбой экземпляр любого подтипа являетсяэкземпляром супертипа, логично хранить вместе всестроки, соответствующие экземплярам супертипа;обеспечение простого доступа к экземплярамсупертипа и не слишком сложный доступ к экземплярамподтипов;возможность обойтись небольшим числом таблиц29.10.2009С.Д.
Кузнецов. Базы данных.73 Проектирование РБДСемантическая модель Entity-Relationship(56)Получение реляционной схемы из ER-диаграммы (9) Супертипы и подтипыНедостатки первого метода:(4) приложения, работающие с одной таблицей супертипа,должны содержать дополнительный программный коддля работы с разными наборами столбцов (взависимости от значения столбца «кода типа») иразными ограничениями целостности (в зависимости отособенностей связей, определенных для подтипа);общая для всех подтипов таблица потенциально можетстать узким местом при многопользовательскомдоступе по причине возможности блокировки таблицыцеликом;потенциально в общей таблице будет содержатьсямного неопределенных значений, что может привести кнепроизводительному расходу внешней памяти29.10.2009С.Д.
Кузнецов. Базы данных.74 Проектирование РБДСемантическая модель Entity-Relationship(57)Получение реляционной схемы из ER-диаграммы (10) Супертипы и подтипы(5)Достоинства второго метода состоят в следующем: действуют более понятные правила работы с подтипами(каждому подтипу соответствует одноименная таблица); упрощается логика приложений; каждая программа работаеттолько с нужной таблицейНедостатки второго метода: в общем случае требуется слишком много отдельныхтаблиц; работа с экземплярами супертипа на основе представления,объединяющего таблицы супертипов, может оказатьсянедостаточно эффективной; поскольку множество экземпляров супертипа являетсяобъединением множеств экземпляров подтипов, не всеРСУБД могут обеспечить выполнение операциймодификации экземпляров супертипа29.10.2009С.Д.
Кузнецов. Базы данных.75 Проектирование РБДСемантическая модель Entity-Relationship(58)Получениереляционной схемыиз ER-диаграммы(11) Взаимноисключающиесвязи (1)Как отмечалосьранее,ER-диаграммус взаимноисключающими связями можно преобразовать к диаграмме сподтипами исходного типа сущностиОднако можно построить схему SQL-ориентированной базыданных и без такого преобразования.Существуют два способа формирования схемы реляционнойБД при наличии взаимно исключающих связей (имеются ввиду связи «один ко многим», причем конец связи «многие»находится на стороне сущности, для которой связи являютсявзаимно исключающими): определение таблицы с одним столбцом для представлениявсех взаимно исключающих связей, т.е. общее хранениевнешних ключей; определение таблицы, в которой каждой взаимноисключающей связи соответствует отдельный столбец, т.е.раздельное хранение внешних ключей29.10.2009С.Д.
Кузнецов. Базы данных.76 Проектирование РБДСемантическая модель Entity-Relationship(59)Получениереляционнойсхемыиз ER-диаграммыВзаимноисключающиеПонятно,что еслиимеютсявзаимно(12)исключающиесвязи связиупомянутой категории, то в таблице, соответствующей сущности,для которой связи являются взаимно исключающими, необходимохранить внешние ключиЕсли внешние ключи всех потенциально связанных таблиц имеютобщий формат, то можно применить первый способ, т. е. создатьдва столбца, содержащие идентификатор связи и уникальныйидентификатор соответствующей сущности (второй столбец можетбыть составным)(2)Столбец идентификатора связи используется для различения связей,покрываемых дугой исключения.Если результирующие внешние ключи не относятся к одномудомену, то приходится прибегать к использованию второгоспособа, т.
е. создавать для каждой связи, покрываемой дугойисключения, явные столбцы внешних ключей;каждый из этих столбцов может содержать неопределенные значения29.10.2009С.Д. Кузнецов. Базы данных.77 Проектирование РБДСемантическая модель Entity-Relationship(60)Получениереляционной схемыиз ER-диаграммыВзаимноисключающиеПреимуществопервогоподхода(13)состоитв том, что всвязи (3)таблице, соответствующей сущности с взаимноисключающими связями, появляется всего двадополнительных столбцаОчевидным недостатком является усложнение выполненияоперации соединения: чтобы воспользоваться длясоединения одной из альтернативных связей, нужно сначалапроизвести ограничение таблицы в соответствии с нужнымзначением столбца, содержащего идентификаторы связей.При использовании второго подхода соединения являютсяявными (и естественными)Недостаток состоит в том, что требуется иметь столькостолбцов, сколько имеется альтернативных связейКроме того, в каждом из таких столбцов будет содержатьсямного неопределенных значений, хранение которых можетпривести к излишнему расходу внешней памяти29.10.2009С.Д.
Кузнецов. Базы данных.78 Проектирование РБДСемантическая модель Entity-Relationship(61)Получениереляционнойсхемы из ER-диаграммы(14) Взаимноисключающиесвязи (4)На этоммы заканчиваемкраткую экскурсиюв семантическоемоделирование с использованием ER-диаграммОсновной целью этого раздела было ознакомление ссемантическими моделями данных на примере упрощенноговарианта ER-моделиПредставленный вариант ER-модели, с одной стороны, являетсядостаточно развитым, чтобы можно было почувствовать общуюспецифику семантических моделей данных, а с другой стороны, неперегружен деталями и излишними понятиями, затрудняющимиобщее понимание подходаС практической точки зрения наибольшую пользу могут принестирассмотренные приемы перехода от ER-диаграмм к схемереляционной базы данныхОсобенно могут пригодиться рекомендации по представлению вреляционной схеме связей «многие ко многим», подтипов исупертипов сущности и взаимно исключающих связей29.10.2009С.Д.
Кузнецов. Базы данных.79 Проектирование РБДДиаграммы классов языка UML (1)Теперь мы обсудим основные понятия диаграмм классовязыка UML и возможности применения этой диаграммноймодели для проектирования реляционных баз данныхКроме того, будет кратко рассмотрен язык объектныхограничений OCL и приведены примеры формулировок наязыке OCL ограничений целостности в терминахконцептуальной схемы базы данныхЯзыку объектно-ориентированного моделирования UML(Unified Modeling Language) посвящено великое множествокниг, многие из которых переведены на русский язык (анекоторые и написаны российскими авторами)Язык UML разработан и развивается консорциумом OMG(Object Management Group) и имеет много общего собъектными моделями, на которых основана технологияраспределенных объектных систем CORBA, и объектноймоделью ODMG (Object Data Management Group)29.10.2009С.Д. Кузнецов. Базы данных.80 Проектирование РБДДиаграммы классов языка UML (2)UML позволяет моделировать разные виды систем: чистопрограммные, чисто аппаратные, программно-аппаратные,смешанные, явно включающие деятельность людей и т.
д.Но, помимо прочего, язык UML активно применяется дляпроектирования реляционных БДДля этого используется небольшая часть языка (диаграммыклассов), да и то не в полном объемеС точки зрения проектирования реляционных БД модельныевозможности не слишком отличаются от возможностей ERдиаграммНо все же мы кратко опишем диаграммы классов UML,поскольку их использование при проектированииреляционных БД позволяет оставаться в общем контекстеUML и применять другие виды диаграмм для проектированияприложений баз данных29.10.2009С.Д. Кузнецов. Базы данных.81 Проектирование РБДДиаграммы классов языка UML (3)Основные понятия диаграмм классов UML (1)Диаграммой классов в терминологии UML называетсядиаграмма, на которой показан набор классов (и некоторыхдругих сущностей, не имеющих явного отношения кпроектированию БД), а также связей между этими классамиКроме того, диаграмма классов может включатькомментарии и ограниченияЗдесь следует сделать два замечания Во-первых, в этом разделе термин сущность используетсянастолько же неформально, как в предыдущем разделеиспользовался термин объект UML претендует на обеспечение более точного иформального понятия объекта (UML обычно называютязыком объектно-ориентированного моделирования) В спецификации языка UML даже присутствует определениепонятия объекта средствами самого UML29.10.2009С.Д.
Кузнецов. Базы данных.82 Проектирование РБДДиаграммы классов языка UML (4)Основные понятия диаграмм классов UML (2)Во-вторых, в UML, как и в модели ER-диаграмм, для родовогообозначения связей используется термин relationshipОднако, несмотря на эти попытки, понятие объекта в UML остаетсятаким же нечетким, как и понятие сущности в ER-моделиПо-прежнему приходится опираться в основном на интуицию и здравыйсмыслВо многих переводах книг про UML на русский язык вместо терминасвязь применяется термин отношениеКак и в предыдущем разделе, мы используем термин связьДля диаграмм классов UML могут задаваться ограничения наестественном языке или же на языке объектных ограничений OCL(Object Constraints Language)Язык OCL является частью общей спецификации UML, но, вотличие от других частей языка, имеет не графическую, а линейнуюнотациюБолее подробно язык OCL обсуждается в конце лекции29.10.2009С.Д.