Теория и практика построения баз данных (1088289), страница 78
Текст из файла (страница 78)
Приложения, которые ограничивают доступ к определенным формам, отчетам, таблицам и столбцам, обеспечивают вертикальну!о безопасность, Приложения, которые ограничивают доступ к определенного рода данным в формах, отчетах, таблицах или столбцах, обеспечива!от горизонтальную безопасность. Имена пользователя и пароли можно непосредственно использовать для обеспечения вертикальной безопасности.
Горизонтальная безопасность требует от разработчиков написания программного кода. Например, чтобы обеспечить горизонтальную безопасность в приложении базы данных кадрового отдела, приложение будет получать пмя пользователя от системы безопасности СУБД и ограничивать доступ пользователя к базе только течи строками, которые содержат данное ичя либо связаны со строками, содержащими данное имя, через соединения.
Один из способов это сделать — указывать нмя пользователя как аргумент предложения УгНЕРЕ в ЗЯ1 -операторах, Поскольку каждая ситуация требует индиа!!дуэльного подхода, большего мы сказать не можем. Просто имейте в виду, что когда говорится, что СУБД поддерживает безопасность, это чаще всего означает только поддержку вертикальной безопасности с помощью имен пользователей и паролей. Большинство приложений управляют действиями пол! зователя посредствоч меню.
На рис. 10,21, а показана система меню для приложения «дографического> периода, а па рис. 10.21, б показана та же самая система меню, но в приложении с графическим интерфейсом пользователя. Мещо на рис. 10.21 являются статическими. Более эффективное управление можно обеспечить путем динамического изменения содержимого меню, когда меняется контекст пользователя. Меню такого типа вы можете видеть в Ассезз, ко!да панель инструментов меняется в зависимости от того, с чем вы работаете — с генератором таблиц, форм пли отчетов. Разработчики приложения базы данных могут использовать подобную стратсппо для изменения содержимого меню в зависимости от формы или отчета, который просматривает пользователь, и даже в зависимости от действия, которое пользователь предпринимает в ходе заполнения формы.
Используя Ассезз, разработчик может менять содержимое меню, перехватывая события, подобные тем, что перечислены па рис. 10.20, и динамически модифицировать его структуру. 18ь я«Я га«й дуяь«1>хг' я«в«ь 'ж" !о> н«Ь й~ 1! ! ) ~ Щ~Я!!!Ц!ЗЯБ ' г г< ьг сияьи< Е««! — — — ваз«ди«сбеххи х ЩатаД1!Я!!!!тг«Ч!ЗЩ 8!<с<ил«<ця 'Т Рис. 10.21.
Иерархия меню для галереи Ч!вхг Имев: в — без использования графического интерфейса; б — с использованием графического интерфейса Особый вид управления необходим для транзакций. В главе 11 вы узнаете о способах управления многопользовательской обработкой, которые предотвращюот нежелательные побочные эффекты от действий одного пользователя на действия другого пользователя.
Ключевым элементом управления многопользовательской обработкой является указание границ, в которых действия должны выполняться как единое целое. Такие границы иногда называ!отса ражкагаи трап!акции (!глазаст!оп Ъоцпс!апез). Например, последовательность 3121.-операторов 370 Глава 1О. Проектирование приложений баз данных Резюме, 371 для создания представления, которая приведена в начале этой главы, должна выполняться как единое целое, как одна транзакция. Мы не будем предвосхищать изложение, которое последует в главе 11, однако скажем, что указание рамок транзакции является задачей приложения. Как правило, приложение делает это, выполняя перед началом единицы обработки оператор ВЕ61М ТВА>ч5АСТ10>>, а по окончании — оператор ЕЙО ТЙАЙ5АСТ10М. Установка рамок транзакции не вызывает затруднешш, если пользовательские представле>тя хорошо спроектированы.
Приложение выполняет оператор ВЕ6111 ТВА115АСТ10>>' в начале представления и Ейй ТкА)т5АСТ101т' в конце представления. Оставшуюся часть этой дискуссии мы отложим до главы 12, Логика приложения Последняя указанная на рис. 10.1 функцня приложения базы данных — реализация лосики приложения (арр!1сат)оп 1ой!с), Эта тема подробно обсуждается в курсе системной разработки, поэтому мы не уделим ей здесь много внимания.
Потребность в реализации логики приложения вытекает из системных требований. В системе ввода заказов логика приложения определяет то, как берегся товар со склада, что делать при недостаточном количестве товара па складе, как организовывать отложенный заказ и т. п. В приложении базы данных, которое базируется на формах (например, приложение галереи У)е» КЫйе), выполнение кода, реализующего эту логику, приурочивается к событиям наподобие перечисленных на рис. 10.20. В других приложениях баз данных, где формы материализуются самим приложением, а не СУБД (распространенная ситуация на больших ЭВМ), приложение обрабатывает данные способом, аналогичным тому, который применяется при обработке файлов.
Логика встраивается в приложение в тех его местах, где происходит обмен данными с СУБД. Некоторые прикладные программы получают данные от других программ; в этом случае логика обработки также встраивается в приложение. Таким образом, способ, которым логика обработки реализуется в приложениях баз данных, зависит как от логики, так и от самой среды. В каждом виде приложений этот способ свой, будь то приложения для настольных компьютеров, клиент-серверных систем, больших ЭВМ или приложения, использующие интернет-технологии.
Вы познакомились с тем, как перехватываются собьппя в приложениях для настольных кол>пьютсров. Прочие способы будут рассмотрены нами в послелующнх главах. Резюме Приложение базы данных имеет пять основных фун>сци>п (1) создание, чтение, обновление и удаление представлений; (2) материализация, или форматирование представлений; (3) реализация ограничений; (4) обеспечение механизмов безопасности и управления; (5) реализация логики приложения. Представление — это структурированный список элементов данных из сушногтсй или семантических обьектов.
Экземпляр представления — это представление, заполненное данными. Поскольку представления структурированы, отдельно взятый элемент данных может фи>урировать в представлении неоднократно. Для чтения представления запускается один или несколько БО(.-операторов, полу >ающих данные. Если представление включает два или более пути следования но связям в схеме, потребуется более одного 5Я(.-оператора. Набор записей— зто отношение, заключенное в оболочку ООП. Создание представления требует добавления одной или более строк в таблицы н, возможно, создания или изменения значений внешних ключей с целью уста>и>аления связей. Есть три возможных типа обновления: изменение сушествующпх ;шнных, изменение связей и создание новых строк для многозначных атрибутов.
Улаление представления требует удаления одной нлп более строк и настройки внешних ключей. Трудность прн удалении заключается в том, чтобы знать, сколько н чего удалять. Слабые сущности должны удаляться, если удаляется сугцность, и > которой они зависят. Многозначные атрибуты, входящие в состав семантиче< кого объекта, должны также удаляться. В некоторых СУБД можно назначать связям режим каскадного удаления, нри котором СУБД будет автоматически удалять соответствуюшие зависимые строки. Форма — это экранный объект, предназначенный для ввода и редактирова>шя данных. Принципы проектирования форм таковы; структура формы должна отражать структуру представления, семантика данных должна быть графически очевидной и структура формы должна побуждать к правильным действиям.
Для ш>вышения удобства работы с формой можно использовать раскрывающиеся списки, переключатели и флажки. Отчеты также должны проектироваться так, побы их структура отражала структуру материализуемого ими представления. Сортировка данных в отчете зачастую подразумевает сушествование других объектов. В большинстве генерагоров отчетов оказывается трудным сконструировать отчет, который следовал бы более чем по одному многозначному пути в схеме.
В отчетах часто встречаютгя вычисленные атрибуты; обычно хранение этих атрибутов в базе данных не оправданно. Ограничения могут реализовываться либо СУБД, либо прикладной программой. В большинстве случаев лучше по возлшжностн поручать их реализацию СУБД, поскольку СУБД является центром, через который обязательно проходят все изменения данных. В некоторых случаях, однако, СУБД не имеет средств лля реализации ограничений, и такие ограничения должны реализовываться нрпложснием. Ограничения домена реализуют физическую часть определения домена.
Еще один тип ограничений — это обязательные значения. Определение значения в качестве обязательного предотврашает появление нулевых значений, нс имеющих однозначной трактовкн. Ограничения уникальности лучше всего реализуются СУБД; это обычно делается путем построения индексов. Есть два типа ограничений связи: ограничения ссылочной целоспюсти и ограничения кардинальности. Ограничения ссылочной целостности реализуются луч>не всего.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
