Теория и практика построения баз данных (1088289), страница 60
Текст из файла (страница 60)
Во многих СУБД разработчик может также устанавливать пароли и использовать другие средства контроля и безопасности. Как будет показано в главе 11, существует множество различных стратегий обеспечения безопасности. В одних стратегиях обьектами контроля являются структуры данных (например, таблица защищается паролем), в других — пользователи (обладатель пароля Х может читать и обновлять таблицы Т1 и Т2). Распределение пространства на физических носителях Кроме определения структуры базы данных, разработчик должен выделить место лля базы данных на физическом носителе.
И вновь конкретные действия зависят от того, какая имешю СУБД используется. В случае персональной базы данных нсе, что требуется сделать, — это присвоить базе данных каталог на диске и дать сй имя. После этого СУБД автоматически выделит пространство для хранения данных. Другие СУБД, в особенности предназначенные для серверов и больших ЭВМ, «ребукгг болыцих усилий. Чтобы повысить быстродействие и улучшить контроль, необходимо тшательно спроектировать распределение информации в базе данных по дискам и каналам. Например, в зависимости от специфики обработки приложений, может оказаться, гго определенные таблицы лучше размсгцать на одном и том же диске. И наоборот, может быть важно, чтобы определенные таблицы не находились на одном н том же диске, Рассмо~рим, например, объект-заказ, скомпонованный из таблиц ЗАКАЗ, СТРОКА ЗАКАЗА и ТОВАР.
Предположим, что при обработке заказа приложение считывает одну строку из таблицы ЗАКАЗ, несколько строк нз таблицы СТРОКА ЗАКАЗА и по одной строке из таблицы ТОВАР для каждой строки из таблицы СТРОКА ЗАКАЗА. Далее, строки из таблицы СТРОКА ЗАКАЗА, относящиеся к одному и тому же заказу, обычно сгруппированы вместе, а строки в таблице ТОВАР не сгруппированы никак. Эту ситуацию иллюстрирует рис. 8.3. Теперь представим, что организация параллельно обрабатывает множество заказов и что у нее есть два диска: один большого объема и быстродействующий, а другой — меныцего объема и более медленный. Разработчик должен определить наилучшее место для хранения данных.
Возможно, производительность улучив<тся, если таблица ТОВАР будет храниться на большом диске с быстрым 280 Глава 8. Основы построения реляционных баз данных Манипулирование реляционными данными 281 доступом, а таблицы СТРОКА ЗАКАЗА и ЗАКАЗ вЂ” на диске меньшего размера и бы- стродействия. А может быть, производительность будет выше, если поместить данные из таблиц ЗАКАЗ и СТРОКА ЗАКАЗА за предьщуцпте месяцы на более мед- ленньш диск, а за текущий месяц — на более быстрый. Таблица СТРОКА ЗАКАЗА Таблица ЗАКАЗ Таблица ТОВАР Код Товара Описание Товара Номер Номер Номер Заказа Строки Строки Номер Заказа Обратите внимание: для любого заказа соответствующие строки в таблице СТРОКА ЗАКАЗА находятся рядом, а в таблице ТОВАР разбросаны пс разным местам Рис.
8.3. Данные для трех таблиц, представляющих заказ Составление плана обслуживания базы данных План обслуживания (ша)пгепапсе р1ап) базы данных — это расписание процедур, которые необходимо выполнять ца регулярной основе. Этн процедуры включают в себя резервное копирование базы данных, сброс содержимого журнала базы Мы не можем ответить на эти вопросы здесь, поскольку ответ зависит от объема данных, характеристик СУБД и операционной системы, размера и быстродействия дисков и каналов, а также от требований приложений, использующих эту базу данных. Смысл состоит в том, что все эти факторы необходимо принимать во внимание при выделении пространства для базы данных на физическом носителе. Кроме местоположения и объема пространства для данных пользователя, разработчику, возможно, потребуется также указать, должно ли это пространство увеличиваться по мере необходимости, ц если да, то на какую величину.
Как правило, величина такого приращения указывается либо в виде фиксированного значения, либо в виде процентов от первоначального объема занимаемого пространства. При создании базы данных разработчику понадобится выделить файловое пространство для журналов базы данных. О ведении журналов вы узнаете в главах 11 — 13; ца данном этапе вам просто следует знать, что СУБД ведет журнал изменений в базе данных, который потом, в случае необходимости, можно использовать для восстановления базы. Файловое пространство для журналов выделяется на этапе создания базы данных. данных в архивные файлы, проверка на наличие нарушений ссылочной целостности, оптимизация дискового пространства для данных пользователя и индексов и т.
д. К этим вопросам мы также обратимся в главе 11, но имейте в виду, что план обслуживания базы данных должен составляться в процессе ее создания или вскоре после него. Заполнение базы данных информацией Когда база данных описана и для ее хранения выделено пространство на физическом носителе, можно начинать заполнение базы данных информацией. То, каким путем это делается, зависит от требования приложений и возможностей СУБД.
В лучшем случае все данные уже находятся в формате, воспринимаемом компьютером, а в СУБД имеются возможности и средства, позволяк>щие упростить импорт данных с магнитных носителей. В худшем случае все данные должны вводиться вручную через клатгатуру с помощькт прикладных программ, созданных разработчиками «с нуля». Большинство ситуаций, где необходимо конвертирование данных, находятся в промежутке между этими двумя крайними случаями. Когда данные введены, необходимо проверить их корректность.
Такая проверка утомительна и требует больших трудозатрат, однако она весьма важна. Загастую, особенно в больших базах данных, есть смысл в написании специальных программ для проверки данных. Преимущества от использования этих программ вполне окупят время и деньш, затраченные командой разработчиков на их создание. Такие программы занимаются тем, что подсчитывают количество строк а различных категориях, вычисляк>т контрольные суммы, выполняют проверки допустимости значений данных и другие процедуры контроля.
Манипулирование реляционными данными Мы обсудили проектирование реляционных баз данных и способы, при помощи которых структура базы данных описывается для СУБД. До сих пор, говоря об операциях с отношениями, мы рассуждали в обобщенной и интуитивной манере. Такая манера хороша, пока речь илет о проекте, но для реализации приложении нам нужен четкий и непротиворечивый язык, выражающий логику обработки.
Такие языки носят название языкое манипулироеаггия даггггыми (г)ага птапгрц!аооп 1апяцаяез, Т) МЬ). Категории языков манипулирования реляционными данными На сегодняшний лель предложено четыре стратепш манипулирования реляционными данными. Первая из стратегий, реляциоггггая алгебра (ге!айова! а1йеЬга), определяет операторы, действующие на отношения (они подобны операторам 282 Глава 6. Основы построения реляционных баз данных Манипулирование реляционными данными 283 высшей алгебры ч-, — и т. д.) Эти операторы позволяют манипулировать отношениями для достижения желаемого результата. Но реляционная алгебра трудна в использовании, отчасти потому, что она является процедурной. Это значит, что при использовании реляционной алгебры мы лолжны знать нс только то, что мы делаем, но н то, кпк это лелается. Реляционная алгебра не исполъзуется в коммерческих системах обработки баз данных, Хотя нп одна коммерчески успеп>ная СУБД не включает в себя инструментарий реляционной алгебры, мы будем обсуждать ее здесь, поскольку это поможет яснее представить себе манипулирование реляционными даннь>ми и заложит основу для изучения БС4Ь.
Реляционное исчисление (ге!айопа! са!сц!цэ) — вторая стратегия манипулирования реляционными данными. Реляционное исчисление нс является процедурным; оно представляет собой язык, выражаюгцнй то, ч>ло мы хотим сделать, без указания на то, как этого достичь. Вспомните переменную интегрирования в интегралъпом исчислении: эта переменная принимает значения пз того диапазона, по которому происходит интегрирование. В реляционном исчислении сеть подобная переменная.
В кортежпо-реляционном исчислении областью значений этой переменной являются кортежи отношения, а в доменно-реляционном исчислении — значения домена. В основе реляционного исчисленпя лежит область математики, называемая исчислением предикатов. Если вы не собираетесь становиться теоретиком реляционной технологии, вам, скорее всего, не понадобится изучать реляцпошюе исчисление. Оно никогда не используется в коммерческих системах обработки баз да>шых, и в его изучении для наших целей нет необходимоспт.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
