Дж. Рамбо, М. Блаха - UML 2.0 - Объектно-ориентированное моделирование и разработка (1158633), страница 100
Текст из файла (страница 100)
В каждую таблицу каждого класса добавляется произвольный численный атрибут (идентификатор объекта), который делается основным ключом этой таблицы. Основной ключ каждой таблицы ассоциации состоит из идентификаторов участвующих в ней классов. Идентификатор объекта представляет собой единственный атрибут, занимающий небольшой объем памяти и однородный в размере. Большинство РСУБД работают с идентификаторами особенно эффективно.
Однако использование идентификаторов объектов затрудняет чтение базы данных в процессе отладки и обслуживания. Идентификаторы затрудняют и слияние баз данных, потому что их значения в разных базах могут совпадать, а в таком случае требуется переназначение идентификаторов.
Эти числа не должны быть видны пользователям. ° Индивидуальность значения. Каждый объект идентифицируется некоторой комбинацией реальных атрибутов. Основной ключ таблицы ассоциации в этом случае также состоит из основных ключей участвующих в ассоциации классов. 19.3.5.
Основные правила реализации РСУБД В табл. 19.1 перечислены основные правила реализации структуры модели в РСУБД. Этим правилам следуют большинство систем для генерации баз дан- ных из моделей 11М1.. Таблица 19.1. Основные правила реализации РСУБД Концепция Конструкция 11МЕ Рекомендуемые правила реализации Отобразить каждый класс н таблицу, а каждый атрибут — в столбец этой таблицы Класс Такая индивидуальность обладает своими преимуществами и недостатками. Основные ключи имеют собственный смысл, что облегчает отладку базы данных.
Однако их может быть сложно изменить. Изменение может распространиться на другие таблицы. Для некоторых классов трудно найти естественные идентификаторы, связанные с реальным миром. Мы рекомендуем использовать индивидуальность объектов для приложений РСУБД. Однородность и простота перевешивают возможные дополнительные затраты на отладку. Более того, индивидуальность объектов согласуется с принципами объектной ориентированности: объекты обладают собственной индивидуальностью, никак не связанной с их свойствами. Объектно-ориентированные языки реализуют индивидуальность при помощи указателей или таблиц поиска указателей, а идентификатор — аналогичная по смыслу конструкция для баз данных. 19.4.
Реализация структуры — дополнительные вопросы 421 Концепция Конструкция ЫМЬ Рекомендуемые правила реализации Использовать отдельную таблицу Использовать встроенный внешний ключ Многие-ко-многим Один-ко-многим Один-к-однол1у Ассоциация (названия полюсов становятся названиялщ 1ч-ариан Использовать отдельную таблицу впепщих ключей) Ассоциация-класс Квалифицированная То же, что и для неквалифицированной То же, что и для ассоциации Агрегация Композиция Агрегация Обобщение Создание отдельных таблиц лля суперкласса н каждого из подклассов Одиночное наследование Раздельное множественное наследование То же, что и при раздельном множественном наследовании, по с таблицей самого обобщения, связывающей записи суперкласса и подкласса Перекрывающееся лш ожествен нос наследование 19.4. Реализация структуры — дополнительные вопросы В предыдущем разделе мы рассказывали о том, каким образом следует определять таблицы базы данных для каждой из конструкций модели классов 1)МЬ.
В этом разделе мы рассмотрим дополнительные аспекты, связанные с повышением производительности н обеспечением качества данных. В ходе реализации модели вам предстоит выполнить следующие действия. ° Реализовать внешние ключи (раздел 19.4.1). ° Реализовать проверочные ограничения (раздел 19.4.2). ° Реализовать индексы (раздел 19А.З). ° Рассмотреть возможные представления (раздел 19.4А).
19.4.1. Внешние ключи Внешние ключи возникают в процессе реализации ассоциаций и обобщений. После определения внешнего ключа РСУБД гарантирует отсутствие повисших ссылок: РСУБД откажется выполнить обновление, результатом которого может стать повисшая ссылка. Поскольку приложение может быть уверено в корректности внешних ключей, оно может не выполнять дополнительную проверку их правильности. 422 Глава 19 ° Базы данных Многие РСУБД могут обеспечивать распространение эффектов улалений и обновлений, влияющих на внешние ключи. Если вы используете индивидуальность объектов (в соответствии с нашими рекомендациями), необходимости распространения обновлений нет, потому что идентификаторы никогда не изменяются.
Однако полезно бывает определить реакцию системы на удаление, о чем мы расскажем ниже. Для каждой таблицы подкласса при реализации обобщений необходимо указать параметр оп х(е1еге саясах1е (каскадное удаление). В листинге 19.7 привелены определения внешних ключей, которые необходимо лобавить к листингу 19.6. Вспомните, что обобщение структурирует описание объекта: каждый уровень обобщения дает часть этого описания. Приложение должно объединить записи суперкласса и подкласса, чтобы получить объект в целом. Удаление суперкласса приводит к каскалному удалению соответствующей записи подкласса, и это удаление распространяется вниз по всем уровням обобщений. Листинг 19.7.
Внешние ключи дпя обобщения — реализация каскадного удаления льтяв тлвьк слепи ч леее е лоо соитвлхит гк еькаееех говвзяи кях еьк аеее то вягявьисяя леееааь ои ояьятя сляслоя; льтяв тлвья яаеьлча ле а лоо соиятвлзит ьк ааеаееа1 говяхои кях аае аееь хо вягявяисяя лес ае ои ояьвтк сляслоя Хорошо было бы иметь возможность распространять удаление записи подкласса вверх к таблице суперкласса, олнако БО1. не поддерживает подобную операцию. Вам придется написать программный код, который будет обеспечивать распространение удаления вверх по иерархии наследования. Внешние ключи необходимо опрелелять и для воплощения ассоциаций, как показано в листинге 19.8.
Действие при удалении зависит от смысла модели. Например, если мы хотим, чтобы удаление записи клиента приводило к удалению соответствующей записи адреса — нужно указывать параметр оп ае!ете саясах(е (первый оператор в листинге 19.8). Если же мы хотим запретить удаление клиента, у которого есть счета (чтобы избежать случайной потери важных данных), нужно указать параметр оп Не(ете по асйоп (никаких действий при попытке улаления). В этом случае, чтобы удалить клиента, пользователь системы должен будет сначала удалить все счета этого клиента. Синтаксис Огас!е позволяет просто не указывать действие при операции ае/еье (второй оператор в листинге 19.8).
Листинг 19.8. Внешние ключи для ассоциации льтяв тлвья лоохеаа лоо соиятвлхит гк аоогеа*1 говяхои кях еааьеиех зэ вягевеисвя сиааепеа ои эеьете сляслэя; льтяв тлвья лееаааа лоо соиятвлхит гк аеееааез 19А. Реализация структуры — дополнительные вопросы 423 говк(ан ккт спассееп (о вкгквквскз спассеес; 19.4.2. Проверка ограничений БЯ1. позволяет устанавливать общие ограничения, которые определяют допустимые значения перечислимых типов. Это особенно полезно при реализации названия набора обобщений. В листинге 19.9 мы добавляем такое ограничение к листингу 19.6. Листинг 19.9.
Обязательное задание названия набора обобщений вьткв тввьк всссппс воо совзтвв(нт аппп асссппс( снкок (асссппс суре (н ('Сьескапэ всссппс','яаеьпча всссппс'Ы 19.4.3. Индексы В большинстве РСУБД создание индексов является побочным эффектом ограничения ил(оие на основной и возможный ключи. Индекс — это структура данных, отображающая значения из одного столбца в строки таблицы базы данных.
Вам следует создать индекс для каждого внешнего ключа, на который не действуют ограничения какого-либо основного или потенциального ключа. Например, наличие основного ключа Ассг Саг((Аигл ьрис. 19А) заставляет РСУБД построить индекс, что обеспечивает быстрый доступ к ассоил( 1Р и к комбинации ассоипг 1Р+ саЫ аий 1Р. Дополнительный индекс для сатИ аий !Р (листинг 19.10) обеспечит столь же быстрый доступ к этому столбцу в отдельности. Наличие индексов критически важно для обеспечения быстродействия базы данных. Индексирование внешних ключей обеспечивает быстрое комбинирование таблиц. Отсутствие индексов замедляет работу РСУБД на несколько порядков.
Индексы внешних ключей должны быть неотъемлемой частью базы данных, потому что их несложно включить, и нет никаких причин, чтобы этого не делать. Администратор базы данных может определить дополнительные индексы для ускорения частых запросов, а также использовать специальные механизмы настройки, предусмотренные в той или иной СУБД. Листинг 19.10. Определение индекса свквте (яоех ьпоех асссса1 он вссс сасс(весь (сапе апсь (ош 19.4.4. Представления Вы можете определить представление для каждого подкласса, чтобы консолидировать унаследованные данные и упростить доступ к объекту. Представление— это таблица, динамически вычисляемая РСУБД. В листинге 19.11 приведен пример создания представления для подкласса СйесйняАссоипк Вы можете свободно считывать любые данные из представления, однако запись данных через представление РСУБД поддерживают лишь частично.
Ограничения зависят от конкретного продукта. 424 Глава 19 ° Базы данных Листинг 19.11. Создание представления спехте дгви член сьескгпд ассоилс хз зеьест слх ассс 1о, ьазапсе, сгесьс 1гвгс, ргаьесс днггс гнои хссоллс х, сл х д хссд с сх кивав к.ассдилс го - сх.слх ассе го; 19.4.5. Дополнительные правила реализации моделей 1.1М~ в РСУБД Таблица 19.2. Дополнительные правила реализации Концепция Правило реализации Определить контрольное ограничение для каждого атрибута с перечислимым типом Класс Вводить внешние ключи. Указать действие при удалении в зависимости от смысла модели: оп ое1еге сазсаое нли оп ое1еге по асцоп Ассоциация, агрепщия, композиция Опрелелить контрольное ограничение лля каждого атрибута с перечислимым типом Определить индексы для всех встроенных внешних ключей, на которые не распространяются ограничения, наложенные на основныс и возможные ключи Обобгцение Вводить внешние ключи.
Указать действие при удалении в зависимости от смысла модели: оп г1е1еге сазсапе нли оп г1е!еге по асйоп Определить проверочное ограничение для каждого набора обобщений Рассмотреть возможность создания представления для консолидации унаследованных данных н для упрощения чтения объектов 19.5. Реализация структуры из примера с банкоматом На рис. 19.10 показаны все таблицы для модели на рис.