С.Д. Кузнецов - Основы баз данных (1121716), страница 42
Текст из файла (страница 42)
отдел. номер к 5. Поскольку отдег — это имя роли соединения, значением подвыражения яе11.отдел является коллекция (множество). Но кратность роли отде;. равна единице, т. е. каждому объекту служащего соответствует в точности олин объект отдела. Поэтому в ОС1. допускается сокращенная запись операции яе1г.отдел. номер, значением которой является номер отдела текущего служащего. Пример 10.3 Определить ограничение, в соответствии с которым у каждого отдела должен быть менеджер, и любой отдел должен быть основан не раньше соответствующей компании: сопеехе Отдел 1пу: яе11.служащий ехуяся (должность = "щапапег") апб яе1г.компания,годОснования й ве К.годОснования Здесь должность — атрибут класса служащий, а атрибуты с именем годОснования имеются и у класса Отдел, и у класса Компания. В условном выражении этого инварианта подвыражение яе 1.служащюэ ехуяся (должность = "щагадег" ) эквивалентно выражению яе'1.служащий яе1есг (должность = "щапачег" ) я1яе () > 1.
Если бы в ограничении мы потребовали, чтобы у каждого отдела был только один менеджер,тоследовалобы написать... яузе () = 1,иэтобылобынеэквивалентно варианту с ехуяея. Обратите внимание, что в этом случае снова законным является подвыражение яе1'. компания. годОснования, поскольку кратность роли компания в ассоциации классов Отдел и Компания равна единице. Пример 10.4 Условие четвертого инварианта ограничивает максимально возможное количество служащих компании числом 1000: сопсехс Ко>я-ания 1гг: яе11.отдел со' есг, (служащле) яузе ( ) < 1000 Здесь полезно обратить внимание на использование операции со11есг.
Проследим за вычислением условного выражения. В нашем случае в классе компания всего один объект, и он сразу становится текущим. В результате выполнения операции яе11. отдел будет получено множество объектов, соответствующих всем отделам компании.
При выполнении операции со1' есг (служащие) для каждого объекта-отдела по соединению с объектами класса служлдик будет образовано множество объектов-служащих данного отдела, а в результате будет образовано мно- 200 Лекция 10 Диаграммы классов языка ОМь жество объектов, соответствующих всем служащим всех отделов компа- нии, т. е. всем служащим компании. Плюсы и минусы использования языка ОСЕ при проектировании реляционных баз данных Плюсы и минусы использования языка ОС! при проектировании реляционных БД очевидны. Язык позволяет формально и однозначно (без двусмысленностей, свойственных естественным языкам) определять ограничения целостности БД в терминах ее концептуальной схемы.
Скорее всего, наличие подобной проектной документации будет полезным для сопровождения БД, даже если придется преобразовывать инварианты ОСЕ в ограничения целостности БОЕ вручную. К отрицательным сторонам использования ОСЕ относится, прежде всего, сложность языка и неочевидность некоторых его конструкций. Кроме того, строгость синтаксиса и линейная форма языка в некотором роде противоречат наглядности и интуитивной ясности диаграммной части 0М) .
Да, в инвариантах ОСЕ используются те же понятия и имена, что и в соответствующей диаграмме классов, но используются совсем в другой манере. И последнее. Трудно доказать или опровергнуть как предположение, что на языке ОС 1 можно выразить любое ограничение целостности, которое можно определить средствами БОЕ, так и утверждение, что на языке ОСЕ нельзя выразить такой инвариант, для которого окажется невозможным сформулировать эквивалентное ограничение целостности на языке КОЕ. Лично мне неизвестны работы, в которых бы сравнивалась выразительная мощность этих языков в связи с ограничениями целостности реляционных БД.
Получение схемы реляционной базы данных из диаграммы классов 0М~ Если не обращать внимания на различия в терминологии*, то здесь выполняются практически те же шаги, что и в случае преобразования в схему реляционной БД Ей-диаграммы. Поэтому ограничимся только некоторыми рекомендациями, специфичными для диаграмм классов. ' Очевидным аналогом класса является тип сущности, а аналогом связи-ассоцяации — связь в смысле ЕК-модели. Кстати, различия и беспорядок в терминологии действительно удручают. В ек-модели связь (ге)агюлзй!р) — это ассоцяация )азтосгаг!ол) между двумя типами сущности. В Г)М 1. ассоциация (азззс!айол) — это один нз видов связи (ге1айолзагр). Да еще зачем-то в ЦМЕ введен специачьный термин 11л)г для обозначения экземпляра ассоциации. И снова хотелось бы использовать в качестве русского эквивалента термин связь, но он уже безнадежно занят, и приходится переводить Лла как соединение.
Это, конечно, не противоречит смыслу, но тоже очень плохо, поскольку в области реляционных БД термин соединение и без этого имеет два разных смысла — операции соединения и соединения с сервером баз ланных. Мне очень жаль переволчиков книг посвященных Г)МЦ го) Основы бвз данных Курс Рекомендация 1. Прежде чем определять в классах операции, подумайте, что вы будете делать с этими определениями в среде целевой РСУБД.
Если в этой среде поддерживаются хранимые процедуры, то, возможно, некоторые операции могут быть реализованы именно с помошью такого механизма. Но если в среде РСУБД поддерживается механизм определяемых пользователями функций, возможно, он окажется более подходяшим. Рекомендация 2. Помните, что сравнительно эффективно в РСУБД реализуются только ассоциации видов «один ко многим» и «многие ко многим».
Если в созданной диаграмме классов имеются ассоциации «один к одному», следует задуматься о целесообразности такого проектного решения. Реализация в среде РСУБД ассоциаций с точно заданными кратностями ролей возможна, но требует определения дополнительных триггеров, выполнение которых понизит эффективность.
Рекомендация 3. Для технологии реляционных БД агрегатные и в особенности композитные ассоциации неестественны. Подумайте о том, что вы хотите получить в реляционной БД, объявив некоторую ассоциацию агрегатной. Скорее всего, ничего. Рекомендация 4. В спецификации ПМЕ говорится о том, что, определяя однонаправленные связи, вы можете способствовать эффективности доступа к некоторым объектам. Для технологии реляционных баз данных поддержка тако~о объявления вызовет дополнительные накладные расходы и тем самым снизит эффективность. Рекомендация 5.
Не злоупотребляйте возможностями ОС1.. Диаграммы классов 0МŠ— это мощный инструмент для создания концептуальных схем баз данных, но, как известно, все хорошо в меру. Заключение Нельзя сказать, что проектирование баз данных на основе семантических моделей в любом случае ускоряет и/или упрошает процесс проектирования.
Все зависит от сложности предметной области, квалификации проектировщика и качества вспомогательных программных средств. Но так или иначе этап диаграммного моделирования обеспечивает следуюшие преимущества: «на раннем этапе проектирования до привязки к конкретной РСУБД проектировшик может обнаружить и исправить логические недочеты проекта, руководствуясь наглядным графическим представлением концептуальной схемы; ° окончательный вид концептуальной схемы, полученной непосредственно перед переходом к формированию реляционной схемы, а может быть, и промежуточной версии концептуальной схемы, должен стать гог Лекция 10 Диаграммы классов языка 0М1 частью документации целевой реляционной БД; наличие этой документации очень полезно для сопровождения и, в особенности, для изменения схемы БД в связи с изменившимися требованиями; ° при использовании САЯЕ-средств концептуальное моделирование БД МОжЕт СтатЬ ггаетЬЮ ВСЕГО ПРОЦЕССа ПРОЕКтИРОВаНИЯ ЦЕЛЕВОЙ ИифОРМационной системы, что должно способствовать правильной структуризации процесса, эффективности и повышению качества проекта в целом*.
Мы также хотели показать, что в контексте проектирования реляционных БД структурные методы проектирования, основанные на использовании ЕК-диаграмм, и объектно-ориентированные методы, основанные на использовании языка 13МЕ, различаются, главным образом, лишь терминологией. Егс-модель концептуально проще 13МЕ, в ней меньше понятий, терминов, вариантов применения.
И это понятно, поскольку разные варианты ЕК-моделей разрабатывались именно для поддержки проектирования реляционных БД, и Ей.-модели почти не содержат возможностей, выходяших за пределы реальных потребностей проектировшика реляционной БД. Язык ПМЕ принадлежит обьектному миру. Этот мир гораздо сложнее (если угодно, непонятнее, запутаннее) реляционного мира. Поскольку ПМЕ может использоваться для унифицированного объектно-ориентированного моделирования всего чего угодно, в этом языке содержится масса различных понятий, терминов и вариантов использования, избыточных с точки зрения проектирования реляционных БД. Если вычленить из обшего механизма диаграмм классов то, что действительно требуется для проектирования реляционных БД, то мы получим в точности ЕК-диаграммы с другой нотацией и терминологией.
Поэтому выбор конкретной концептуальной модели — это вопрос вкуса и сложившихся обстоятельств. Понятно, что если в организации уже имеется сложившаяся инфраструктура проектирования приложений, то разумно продолжать ею пользоваться до тех пор, пока это не станет тормозом. При построении же новой инфраструктуры стратегические соображения высшего руководства компании имеют больший вес, чем предпочтения технических специалистов, хотя эти предпочтения тоже обязательно должны учитываться.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
