Теория и практика построения баз данных (1088289), страница 77
Текст из файла (страница 77)
Свойства связи в Ассввв 364 Глава 10. Проектирование приложений баз данных каких-либо ограничений. Но изменение ключа родителя разрешено лишь в том случае, если соответствующие значения в дочерних строках также будут изменены. Если у отношения ПРЕПОДАВАТЕЛЬ в связи на рис. 10.18, б изменится ключ, то значение атрибута Руководитель у всех студентов, руководимых данным профессором, нужно тоже изменить, Наконец, в связи с ограничением «О-Н» родительская строка может быть удалена, только если все потомки будут удалены или переназначены, Для связи ПРЕПОДАВАТЕЛЬ-СТУДЕНТ придется, возможно, переназначить все строки. В ограничениях «Н — О» родитель может быть вставлен только в том случае, если в это же время добавляется по меньшей мере один потомок или если соответствующий потомок уже существует.
Для связи «Н-0» между таблицами ЕТУДЕНТ и КЛУБ на рис. 10.18, в новый клуб можно добавить, только если создать соответствующую строку в таблице СТУДЕНТ (либо добавив нового студента, либо изменив значение атрибута Клуб у существующего студента). Кроме того, подходящий студе»т может уже существовать. Аналогичным образом, ключ родителя в связи «Н вЂ” 0» может быть изменен, только если будет создан новый потомок или если подходящая дочерняя строка уже существует. То есть «Секция лыж» может начать называться «Секцией подводного плавания», только если хотя бы один лыжник хочет заняться подводным плаванием плп какой-то студент уже занимается этим видом спорта. Ограничения на удаление родительских строк в связи «Н-0> отсутствуют.
Последний тцп ограничений связи, «Н — Н», показан на рис. 10.18, к В такой связи отсутствуют какие-либо ограничения на любой тпп обновления строк. Строки отношений ПРОЕКТ и СОТРУДНИК могут модифицироваться так, как это необходимо. Ограничения на обновление дочерних строк Правила, предотвращающие появление фрагментов при обновлении дочерних строк, представлены на рис. 10.19, б и аналогичны правилам на рис. 10.19, а. Одно заметное различие состоит в том, что в некоторых случаях дочерние строки могут модифицироваться или удаляться, если у них имеются братья.
Например, в ограничении «О вЂ” О» дочерняя строка может быть удалена, пока у нее существук>т братья (последний ребенок никогда не покидает дом!). Для ограничения «О — 0» иа рис. 10.18, а строка отношения ПЛАТА ЗА ДЕНЬ может быть удалена, пока кроме нее остается хотя бы одна строка. За исключениел> того, что относится к братьям, правила, предотвраща>ощие появление фрагментов при обработке дочерних строк, подобны правилам, сформулированным для предков. Убедитесь, что вы понимаете каждое из высказываний в табл. 10.2. Использование СуБд для реализации ограничений кардинальности Имея в виду сказанное выше, полезно рассмотреть ограничения в табл.
10.1 и 10.2 в контексте средств определения связей в СУБД Ассевв. Предположим, что в базе данных имеется объект ЕМРЕОУЕЕ (сотрудник) с многозначным атрибутом РЬоле йшпЬег (номер телефона). Чтобы показать значение средних столбцов табл. 10.1 и 10.2, примем, что в качестве ключа ЕМРЕОУЕЕ используется не суррогатный клк>ч, а атрибут ЕМРЕОУЕЕ.Наше. На рис. 10.19 показано окно определения связи для этого примера.
Установленный флажок Еп(огсе Ре(егепйа( 1п1ейп1у (Реализовывать ссылочную целостность) указывает на то, что Ассезз не позво.лит создать новую строку в таблице ЕМРЕОУЕЕ РЬопейцп>Ьег, если соответствующее значение атрибута Ел>р1оуеейав>е <>тсутствуег в таблице ЕМРЕОУЕЕ. В этол> состоит суть ссылочной целостиости— как описывалось выше. Второй установленный флажок, Саксауле Орба1е Ре1а1е>1 Е>е1й (Каскадное обновление связанных полей), означает, что если в таблице ЕМРЕОУЕЕ меняется имя сотрудника, то это изменеш>е будет распространено на все связанные с ним строки в таблице ЕМРЕОУЕЕ РЬопейол>Ьег. Это реализует правила в средних столбцах табл, 10.1 и 10.2.
(Опять-таки, в этом не было бы необходимости, если бы использовались суррогатные ключи.) Последний установленный флажок, Еавса>)е Ое1е1е Ре1а1ед Ресогй (Каскадное удаление связанных записей), означает, что когда удаляется строка из таблицы ЕМРЕОУЕЕ, все связанные с ней строки в таблице ЕМРЕОУЕЕ РЬопейцгпЬег также удаляк>тся. Это аналогично описанной ранее ситуации прп удалении экземпляров представлении 366 Глава 10. Проектирование приложений баз данных Безопасность и контроль 367 Эта возможность Ассеьз относится к правилам во втором и третьем столбцах табл.
10.1 и в первом и втором столбцах табл. 10.2. Она не затрагивает правила в первом столбце табл. 10.1 или в третьем столбце табл. 10.2. Эти правила должны быть реализованы в хранимых процедурах или в приложении, Ограничения делового регламента Ограничения делового рвгламвгглга (Ьогйпеаа го!е сопгкга!псз) определяются логикой и требованиями конкретного приложения. Они проистекают пз процедур и политики, существующих в организации, которая будет использовать приложение баз данных. Примерами положений делового регламента могут служить следующие правила. + Сумма комиссионных продавца не может превышать 50% общего объема пула комиссионных.
+ Заказ не будет оформляться, если суммарная стоимость заказываемых товаров меньше чем 3200. + Для избранных покупателей расходы по пересылке не учитываются. + Продавцы не могут оформлять заказы для себя. + Чтобы быть менеджером по продаже, сотрудник должен прежде всего быть продавцом. Поскольку деловой регламент зависит от приложения, в СУБД не предусмотрено никаких общих возможностей для их реализации. Вместо этого в СУБД предоставлена возможность вставки кода перед наиболее важными событиями п после них. На рцс. 10.20 представлен перечень собьгтийг, которые могут перехватываться формами в Ассезз. На этом рисунке разработчик находи~ся в процессе добавления логики обработки события Ве1аге 1пзегс (перед вставкой). Логика может принимать одну из нескольких форм: процедура обработки события на входном языке Ассезз, Ъ'!зпа! Ваз!с или каком-либо другом языке программирования либо макрокоманда Ассезз.
Для процедуры обраболки события пли макрокоманды доступны все данные, содержащиеся в форме и в базе данных. Таким образом, с помощью перехвата событий можно реализовать любое из правил, перечис.ленных в приведенном выше списке. В серверных СУБД, таких как Огас!е и БЯЕ Бегуег, используготся аналогичные спосооы. Логика может бьггь встроена в тригтеры — хранимые процедуры, которые вызываются прп наступлении событий в базе данных. События, доступные для перехвата, подобны тем, что перечислены на рпс. 10.20.
Безопасность и контроль Четвертая основная функция приложения базы данных из перечисленных на рис. 10.1 — обеспечение механизмов безопасности и контроля. Цель состоит в том, чтобы создавать приложения, в которых соответствующие действия моглп бы совершать только пользователи с достаточными полномочиями и в подходящее время.
! СМС:,~::;~6';:;: 1-"::."::::::,"!';:::::'г. ' "''' ' ! ! ге кем Ргосябые! ~ иасггп г~фггяях ~ оятаг ' В' в ' 0с ык':;;;, 'ЩЫ:и ';; ° ° ;.рйг цяЬяд," 1гг ° г оя'кяуцр1,' ° г Скг Кеу Рягм'..... Оя еггог .': „.. Оя Рнег ° ° * » ° ° ° ° ; оя Арр!у 6!гф",г1„. лтг г ! 1 ! ! г ! го и; н' Рис. то.20. События, доступные для перехвата формами Ассеяя Безопасность Больппгнство СУБД обеспечивагот безопасность на уровне имени пользователя и пароля.
Прп получении пользователем учетной записи может быть ограничен его доступ к определенным формам, отчетам, таблицам и даже столбцам таблиц. Все это полезно. и в этом имеется смысл. Однако это не помогает ограничить доступ пользователя к определенным экземплярам данных. Например, в приложении базы данных кадрового отдела каждый сотрудник должен иметь привилегии для просмотра только своей собственной записи. Определенным сотрудникам кадрового отдела должно быть предоставлено право просматривать некоторые данные обо всех сотрудниках, а старший менеджер по кадрам должен иметь возможность просматривать все данные обо всех сотрудниках. Ограничение доступа к определенным формам и отчетам здесь не поможет. Каждому сотруднику необходимо просматривать форму Ешр!оуее; ограничение Безопасность и контроль, 36Я Ч!ЕУУ ЦГООЕ ОАЬЬЕЙУ 1.
Ргосввв СОБТОМЕР Ов!а 2. Ргосввв АЙТ!БТ Оа!в 3. Ргосевв АИТ ууОНК Овгв Ргевв <Е1> !ог НЕ<Р; <ЕБС> !с ЕХ!Т Ч!ЕЧУ Н!ОСЕ ОА<<ЕНУ СОБТОМЕН Ргссевепя Малс 1. Е!па СЦБтОМЕН Ов1в 2. Ааа в НеиСЦБТОМЕН 3. Рг!п1 СЦБТОМЕН ЫМ Ргевв <Е1> Гог НЕЬР; <ЕБС> 1с ЕХ!Т ч!еуг %ООе ОАььеиу Е!па СЦБТОМЕИ Малс 1. Е!ла Ьу СЦБТОМЕИ четв 2. Е!па Ьу СЦБТОМЕИ ЧсглЬег Ргввв <Е1> гсг НЕЬР; <ЕБС> 1с ЕХ!Т Контроль МООЕП яаг«вав «в!в<ма !сгм 366 Глава 10. Проектирование приложений баз данных должно состоять в том, что сотрудник может видеть только те данные в этой ' форме, которые относятся лично к лему (за указанными исключениями).
Иногда вам могут встретиться термины горизоптальиая безопасность (Ъогггопга! зесцпгу) и вертикальная безопасность (чегггса! зесцпсу). Чтобы понять их, представим себе таблицу. Вертикальная безопасност! будет ограничивать доступ к определенным столбцам, по все строки будут видны. Горизонтальная безопасность будет ограничивать доступ к определенным строкам, но при атом видны будут все столбцы.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
