Теория и практика построения баз данных (1088289), страница 75
Текст из файла (страница 75)
Если для пользователя нечто имеет смысл в качестве переменной сортировки, то это нечто должно быль в воображении пользователя объектом, вне зависимости от того, смоделнрован этот объект в базе данных или нет. Сортировка по атрибутам, входящим в состав объектных атрибутов Третий возможньш способ сортировки отчетов — сортировка во атрибутам, содсржашимся в объектных атрибутах. 11апример, пользователь может запросить сочст о произведениях, отсортированный по дате рождения художшп<а, Ооъект ЯКТ?5Т является объекп«ым атрибутом объекта ИОкК, а В!кй0а(е (дата рождения) — ато атрибут, содержащийся в объскте АкТ?51.
В этом случае пользователь на самом деле запрашивает отчет о подразумеваемом объекте (называемом, скажем, Т1МЕ (врсмя) или АРТ?5Т?Е РЕК?00 (период в искусстве)), который содержит много объектов АРТ?5Т, каждый пз которых, в свою очередь, включает много объектов УкОКК, представленных в галерее. Понимание того, как меняется тип объекта, может упростить задачу разработки отчста. Если действовать так, как будто базовым объектом является УкОкК, логика отчета будет запутанной. Если в качестве базового объекта принимается УгОкК, то необходимо создать материализации для всех объектов УкОКК, включающие 356 Глава 10. Проектирование приложений баз данных Реализация ограничений 357 атрибуты АРТ151 и В!Ппйа(е.
Если же в основу отчета положить подразумеваемый объект, содержащий объект АРТ15Т, который, в свою очередь, содержит объект !!ТОРК, то можно создать объекты АРТ15Т, отсортированные по атрибуту В!ПпОа(е и объектным атрибутам <4!ОРК, которые можно трактовать как многозначные строки в каждом нз объектов АРП51. Реализация ограничений В соответствии с рпс.
10.1, третьей основной функцией приложения базы данных является реализация ограничений. Во многих случаях СУБД способна реализовать ограничения лучше, чем приложение, поэтому данная функция не является функцией одних только прикладных программ. Наша задача, однако, состоит в том, чтобы описать типы ограничений и способы пх реализапни независимо от того, каким путем они будут реализовываться — через прикладную программу или через СУБД. Первая причина, по которой СУБД часто является более подходяшим кандидатом на реализацию ограничений, чем прикладная программа, заюпочается в том, что СУБД вЂ” это центр, через который обязательно проходят все изменения в данных.
Независимо от того, что является источником изменения (форма, другая программа. импорт большого объема данных), СУБД имеет возможность проверить и в случае необходимости отвергнуть данное изменение. Далее, определенные правила (одним из таких правил является уникальность) могут потребовать проверки всех строк в таблице, а СУБД лучше приспособлена к выполнению таких операций, чем приложение. Кроме того, если правило реализуется СУБД, то его достаточно будет запрограммировать единожды. Если же правило реализуется приложением, то для каждого нового приложения его придется программировать заново.
Это неэкономно и порождает опасность несогласованной реализации правил прикладными программами, Следует, тем не менее, отметить, что не все СУБД обладают возможностями и функциями, необходимыми для реализации ограничений. Вдобавок, порою намного сложнее написать и установить код, реализуюшпй ограничение, с помощью инструментов, предлагаемых СУБД, чем встроить такой код в прикладную программу. Более того, в некоторых архитектурах (в частности, в М!сгозо(Г Тгапэасг!оп Бегтег) обработка оказывается более эффективной, если с сервера данных снимается бремя проверки ограничений.
Пользователю определенной формы, например, лгожет быть запрещено предпринимать некоторые действия или вводи~ь определенные данные. В этом случае с реализацией ограничения лучше справится приложение. Ваша цель должна быль в том, чтобы понять, какие существуют типы ограничений и какими способами онп реализуются. Если можно, реализуйте их с помощью СУБД; в противном случае реализуйте их в приложении.
Сейчас мы рассмотрим четыре типа ограничений: ограничения доменов, ограничен<и уникальности, ограничения ссылочпой целостности и положения делового регламента. Ограничения доменов ! !спомпите из главы 4, что домен — это множество значений, которые может принимать атрибут. Определения доменов содержат семантический компонент (имя лудожника) и физический компонент (Тех< 25, алфавитные символы). В обшем случае невозможно реализовать ограничение на семантический компонент с полнпцью автоматизированного процесса. Мь< еше не находимся на такой стадии развития компьютерной индустрии, чтобы автоматизированные процессы могли ~<пределять, что ЗМ вЂ” это название компании, а не имя художника.
Поэтому сегодня нас главным образом интересует реализация физической части определения домена. Ограничения доменов проистека<от из модели данных, как описывалось в главе 4. Степень конкретизации ограничений доменов может варьироваться в широких пределах. В базе даш<ых галереи Ч!е<к Р!<!Ре атрибут АРТ15Т.!»аше может бь<ть произвольным набором из 25 пли менее текстовых символов. Домен атрибута Сору определен более конкретно. Формат, пспольауемый галереей, имеет впд пп/шп<, где пп — это номер данной копии, а <вш — общее количество суще< твукицих копий. Так, 5/100 обозначает пятую копию из ста существующих. 1!оно, что значение типа 105/100 не имеет смысла. Поэтому следует предусмотреть код, проверякнций корректность данных, чтобь< гарантировать соблюдение формата.
На рис. 10.14 приведен пример ограничения домена в Ассезэ. Ограничение состоит в том, что дата покупки (атрибут Роге!<азе0аге) должна быть меньше или равна системной дате компьютера ца момент ввода инфорл<ации о покупке. Обратите внимание на строку, обозначенную Ча!!Ваг!оп Рц!е (Правило проверки). ! !равило задается выражением»к !1о<ч()». Если пользователь попытается внес~и данные, которые нарушают это правило, появится сооб<цение, содержашее текст, который введен в следующей строке (Ча!!<!а(!оп Техт — Текст сообщения).
! !а рис. 10.15 показано, что произойдет, если пользователь попытается ввести дату 10/15/99, когда системная дата компьютера меньше, чем 10/15/99. Введенные данные Ассеэз отвергает, Еше один тип ограничений — это обязательность значения. Строго говоря, гребованне, чтобы значение было задано, представляет собой скорее ограничениее таблипы, чем ограничение домена. Домен — это множество значений; вопрос о том, обязателыю данное значение или нет, возникает тогда, когда домен появляется в таблице. В модели данных должно быть указано, является ли атрибут обязательным.
В семантической объектной модели, если минимальное кардинальное число атрибута равно 1, то этот атрибут является обязательньш. Единственное, что требуется, чтобы реализовать это ограничение в Ассезз, — установить свойство Редгйгей (Обязательный) данного столбца в значение уел (Да). На рис. 10.16 это сделано для атрибута !»ап<е в определении таблицы АРТ15Т. В других СУБД, как вы увидите позже, используются другие способы. Реализация ограничений 389 *м ьчзр ччн чф "мы икгав ивувгу СцеГсгяер Сцв1еглег негев гьы ьмс г 1Я смв чь Ситг .. Се 1мвь гчь, ф*-1 лг„.ч.*с 388 Глава 10.
Проектирование приложений баз данных Рис. 10.14. Создание сгрвничвния домена в Ассп.. в гьчяв!сгт1 й 1 з ~ч1(ьп,ее гунемг!иаййжйййФ ....:.хгегь)ь~4к~фа:.":.. Рис. 10.15. Результат нвруцгения пр е:ила проверки в е ееьйд чвр . отггегмде!'.";ыяфг:.',„эьччм ~!'...: .:...,.,; ...;...".. !...3Фн: .,;;1еы Рис. 10.! б. Определение атрибуте Мвгпв таблицы АНТ!ВТ в качестве обязательного и уникального Ограничения обязательности важны потому, что они предотврашают появление пустых значений. Егце один способ это сделать — определить начальное значение, которое СУБД будет присваивать столбцу при создании строки. В Ассезз зто делается путем записи значения или выражения в свойство 0е1апй Ча(це (Значение по умолчанию).
См. рис. 10.16 и обсуждение нулевых значений в главе 6. Ограничения уникальности Уникальность — второй тип ограничений. Как уже отмечалось, ограничения этого типа лучше реализуются СУБД, поскольку она способна создавать структуры данных, позволяюшие проводить проверку уникальности весьма быстро. В приложении А описано, как для этой цели можно использовать индексы. На рис. 10.16 показано определение в Ассеэз атрибута Мате таблицы АЙТ15Т в качестве уникального. Обратите внимание, что свойство 1пдехеб (Индексируемый) установлено в значение Уев (Мо 0црйсатеэ) (Да, без повторений). Прн таких установках Ассеее гарантирует, что ни из одного источника в базу данных не будут введены одинаковые имена художников.
Ограничения связей Есть два типа ограничений связей: ограничения ссылочной целостности (ге1егепйа1 йггейг(гу сопзгга(пгз) и ограничения кардинальности связи (ге1аг1опэЬ(р сагг11па)йу 360 Глава 10. Проектирование приложений баз данных Реализация ограничений 361 сопэгга1пгэ). Ограни гениями ссылочной целостности называются ограничения на значения внепшего ключа. Это те ограничения, которые возникают, например, при нормализации, когда одно отношение разбивается на два новых, и которые появляются между сильными и слабыми сущностями. Ограничения кардинальности связи обусловлены значениями минимальной и максимальной кардинальности связи. Рассмотрим оба этих типа ограничений. Ограничения ссылочной целостности Все ограничения ссьшочной целостности являкпся ограничениями на значения внешнего ключа.
Рассмотрим сна гала ограничение ссылочной целостности на рис. 10.3, пи значение атрибута Агт1эПО в таблице в10КК должно существовать среди значений одноименного атрибута в таблице АЯТ15Т. Атрибут Агтв110 является внешним ключом в таблипе нОЯК, и ограничение означает, что его значение должно соответствовать одному ич значешш атрибута Агтн110 в таблице АКТ15Т, как объяснялось ранее. Пока все приложения запрограммированы правильно, пока все транзакции обрабатываются корректно и пока никто из пользователей случайно не удалит художника, не удалив связанные с нпм произведения (а из-за второго ограничения — и связанные с ннм транзакции, а из-за третьего ограничения — и связанных с ним покупателей), — в общем, пока все идет хорошо, никаких нар шений у целостности по внешнему ключу не произойдет.