Введение в системы БД (542480), страница 130
Текст из файла (страница 130)
РК1МАКХ ЕЕУ ( ЕМРУ, ОЕР МАМЕ ) Свойства Каждое показанное на ЕК-диаграмме свойство отображается в отдельный атрибут в соответствующей переменной-отношении, за исключением случая многозначного свойства, для которого потребуется создать новую переменную-отношение, что прямо следует из принципов нормализации. Домены лля множеств значений создаются простым и очевидным способом (хотя, конечно, сам выбор множеств допустимых значений может оказаться не совсем простой задачей), поэтому подробности здесь опушены.
Супертипы и подтипы сущности Поскольку на рис. 13.1 не содержится никаких супертипов или подтипов, далее речь пойдет о примере, представленном на рис.!3.2. Рассмотрим типы сущностей ЕМРЬОУЕЕ и РКООКАИМЕК. Предположим для простоты, что программисты обладают навыками работы только с одним языком программирования (т.е. свойство АДАМО является однозначным)4.
° Супертип ЕМРЬОУЕЕ отображается в базовую переменную-отношение, например ЕМР, обычным образом (т.е. так, как уже обсуждалось выше). 4 Здесь, в частности, следует отметить, что мы не собираемся отображать типы сущностей ЕИРЬОУЕЕ и РЯОБИЛМЕЯ на какие-то "супертабличные" или "подтабличные" конструк. ции. В этом заключается концептуальная трудность иеи, по крайней мере, ловушка: из того, что на ЕЕ-диагральме тип сущности Уявляется подтипом типа сущности Х не следует, что реляционный аналог сущности Уявляется "подчиненным" реляционного аналога сущности Х и это действительно так.
Более подробно данная тема рассматриваетсл в ПЗ. 121. 520 Часть 111. Проектирование базы данных ° Подтип РВ06ВАММЕВ отображается в другую базовую переменную-отношение, например РОМЕ, с таким же первичным ключом, что и у переменной-отношения ее супертипа, но с другим набором атрибутов, соответствующим свойствам, которые применяются для описания только работников-программистов (например, ЬАМ6 в нашем примере).
ЧАВ РОМЕ БАБЕ ВЕБАТ10М ( ЯМР() ..., АДАМО, РВ1МАВЧ КЯ1 ( ЕМР() ) Более того, первичный ключ переменной-отношения Р6МВ также является внешним ключом, который ссылается на переменную-отношение ЕМР. Следовательно, приведенное выше определение необходимо соответствующим образом расширить (в частности, обратите внимание на определение правил удаления и обновления). ЧАВ РОЕВ БАБЕ ВЕЬАТ10М ( ЯМН ..., БАЕ6, ...
) РВ1МАВ1 КЕ1 ( ЕМР() ) ) РОВЕ16М КЕЧ ( ЕМР() ) ВЕРЕВЕМСЕБ ЕМР ОМ ОЕЬЕЧЕ САБСАОЕ ОИ ОРОАТЕ САБСАОЕ ) ° Нам также потребуется лредсглавлелие, например с именем ЕМР Р6МВ, являющееся соединением переменных-отношений супертипа и подтипа. ЧАВ ЕМР РОМЕ Ч1ЕИ ЕМР 301М РОМЕ ) Обратите внимание, что это соединение имеет тип связи "(нуль или один) к одному", направлено от потенциального ключа к соответствующему внешнему ключу и этот внешний ключ сам по себе является потенциальным ключом. В результате представление будет содержать сведения только о работниках- программистах. Такая структура позволяет выполнять следующие действия. ° С помощью базовой переменной-отношения ЕМР можно получить доступ (например, для извлечения данных) к тем свойствам, которые являются общими для всех работников.
° С помощью базовой переменной-отношения Р6МВ можно получить доступ к особым свойствам, принадлежащим только программистам. ° С помощью представления ЕМР РОМЕ можно получить доступ ко всему набору свойств программистов. ° В базовую переменную-отношение ЕМР можно вставлять сведения о работниках, которые не являются программистами. ° Сведения о работниках-программистах можно вставлять в базу данных с помощью представления ЕМР РОМЕ. Глава 13. Семантическое моделирование 521 ° Сведения о любых работниках (программистах и не программистах) можно удалить из базы данных, удалив их из базовой переменной-отношения ЕМР, а сведения о работниках-программистах можно удалить нз базы данных, удалив их из представления ЕМР РОМЕ.
° Свойства, общие лля всех работников, можно обновлять в базовой переменной- отношении ЕМР, а свойства только работников-программистов можно обновлять и с помощью представления ЕМР РОМВ, ° Свойства, характерные только для программистов, можно обновлять в базовой переменной-отношении РОМЕ. ° Статус сотрудника-не программиста можно изменить на статус программиста за счет вставки сведений об этом сотруднике в базовую переменную-отношение РОМЕ или же в представление ЕМР РОМЕ. ° Статус программиста можно изменить на статус сотрудника-не программиста за счет удаления сведений об этом программисте из базовой переменной-отношения РОМЕ.
Читателю предлагается самостоятельно разобраться в других типах сущностей, показанных на рис. 13.2 (АРРЕТСйТТОМ РЕООЫЛМЕЕ и 8'з ЯТЕМ РЕООЕвММЕЕ). 13.6. Краткий анализ ЕК-модели В этом разделе кратко рассматриваются некоторые определенные аспекты ЕК-модели. Большая часть излагаемого здесь материала взята из другой работы автора (! 3.81, в которой эта тема обсуждается подробнее. Дополнительные сведения и комментарии можно найти в аннотациях, помещенных в список рекомендуемой литературы к данной главе. ЕК-модель как основа реляционной модели Рассмотрим подход с использованием ЕК-модели с несколько иной точки зрения.
Надо полагать, вполне очевидно, что идеи, послужившие основанием для разработки этого подхода, во многом очень близки тем идеям, которые послужили Колду неформатьной основой при создании им исходной формгьзьной реляционной модели.
Как уже объяснялось в разделе 13.2, общий подход к разработке "расширенных" моделей включает четыре больших этапа; назначение каждого из них можно кратко сформулировать следующим образом. !. Идентифицировать полезные семантические концепции. 2. Определить формальные объекты. 3. Определить формальные правила полдержки целостности данных ("метаограничения*').
4. Определить формальные операторы. Обратите внимание, что эти этапы вполне применимы и для разработки базовой реляционной модели (а также для любой другой формальной модели данных), а не только для "расширенных" моделей, подобных ЕК-модели. Иначе говоря, для того чтобы создать формальную базовую реляционную модель, Кодл прежде всего должен был выявить некоторые неформальные "полезные семантические концепции".
Эти концепции в основе своей были близки идеям ЕК-моделнрованя или чему-то очень 522 Часть 1П. Проектирование базы данных схожему с ними. Действительно, работы Ковда подтверждают это, поскольку в его первой статье 1самой ранней версии работы 15.11), посвяшенной реляционной модели, имеются следующие строки. "Множество сущностей заданного типа сущности можно рассматривать как отношение, и такое отношение мы будки называть отношением типа сушности... Оставигиеся отношения... между типами сущностей...
называются межсушностными отношениями... Важнейшии свойствам каждого межсущнастного отношения является пга, чта 1'оно содержит па крайней мере два внешних ключа, которые~ обращаются к различныи пгипаи сущностей либо к общему типу суигнаспги, выполняющему различные роли. " Здесь Кодд явно предлагает использовать отношения для моделирования и "сущностей", и "связей".
Но самое главное заключается в том, что отношения являются формальны ми абьектами, а реляционная модель — формальной системой. Ценность научного вклада Ковда состоит в том, что он нашел удачную формальную модель для определенных аспектов реального мира. В противоположность этому ЕК-модель не является 1или, по крайней мере, не в первую очередь является) формальной моделью. Фактически она состоит из набора преимушественно неформальных концепций, соответствуюших только первому из четырех приведенных выше этапов.
1Более того, ее формальные аспекты на самом деле не очень значительно отличаются от соответствуюших аспектов основной реляционной модели; обсуждение этого вопроса будет продолжено нигке.) Для проектирования базы данных, конечно, полезно иметь в своем распоряжении, помимо всего прочего, набор концепций, определенных на этапе 1. Однако несомненным остается тот факт, что проектирование базы данных не может быть завершено без применения формальных объектов и правил, представленных на этапах 2 и 3, а множество других задач и вовсе не может быть решено без использования формальных операторов, определяемых на этапе 4. Следует отметить, что перечисленные выше замечания не предполагают доказательства бесполезности ЕК-модели; скорее всего, наоборот.
Однако одной этой модели недостаточно. Более того, несколько странным кажется тот факт, что первые описания неформальной ЕК-модели были опубликованы спустя несколько лет после опубликования описания формальной реляционной модели, изначально основанной 1как мы видели) на некоторых идеях ЕК-модели. Является лн ЕК-модель моделью данных Из вышеизложенного не совсем ясно, является ли ЕК-модель на самом деле моделью данных, по крайней мере в предложенном в этой книге смысле 1т.е, формальной системой, включаюшей структурные аспекты, аспекты поддержания целостности и манипулирования данными).
Конечно, термин "ЕК-моделирование" обычно используется для обозначения процесса выбора только структуры базы данных, хотя выше, в разделах 13.3-13.5з, рассматривались и некоторые аспекты целостности (они, в основ- З Основная слабость здесь занлючавтел в толг, что ЕВ-модель эа исключением некоторых специальных (нв, надо полагать, очень важных) случаев совершенно непригодна для работы с ограничениями целостности нлн бизнес-правилами. Праципгирувгг типичное высказывание на 523 Глава 13. Семантическое моделирование ном, относились к первичным и внешним ключам). Однако при более внимательном чтении работы [13.5) можно предположить, что ЕК-модель действительно является моделью данных, но такой, которая представляет собой лишь тонкий слой на вершине базовой реляционной модели (и, конечно, не может заменить реляционную модель, как хотелось бы некоторым авторам).
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
