Курсовик - Методы построения баз данных для информационных систем

18

ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ОБРАЗОВАНИЮ

РОССИЙСКОЙ ФЕДЕРАЦИИ

МОСКОВСКИЙ ГОСУДАРСТВЕННЫЙ ИНСТИТУТ

РАДИОТЕХНИКИ, ЭЛЕКТРОНИКИ И АВТОМАТИКИ

(ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ)

Кафедра конструирования и производства РЭС

Курсовая работа

по предмету: "Информационные технологии в проектировании РЭС"

на тему: Методы построения баз данных для информационных систем

(Основы построения реляционных баз данных)

Выполнил

студент гр.ВК-1-04 Катков Лев Владимирович

Проверил

доцент кафедры КПРЭС Горобец Алексей Иванович

Москва 2008

Содержание

Основы построения реляционных баз данных

Описание реляционных данных

Обзор терминологии

Термин «ключ»

Индексы

Реализация реляционной базы данных

Описание структуры базы данных для СУБД

Распределение пространства на физических носителях

Составление плана обслуживания базы данных

Заполнение базы данных информацией

Манипулирование реляционными данными

Категории языков манипулирования реляционными данными

Интерфейсы языков манипулирования данными

Манипулирование данными посредством форм

Интерфейс языка запросов и обновлений

Хранимые процедуры

Интерфейс прикладных программ

Заключение

Список литературы

Основы построения реляционных баз данных

Описание реляционных данных

В процессе построения реляционной базы данных должны быть решены несколько задач. Во-первых, необходимо описать структуру базы данных для СУБД. Для этого разработчик использует язык описания данных или какой-либо эквивалентный способ описания структуры (например, графическое отображение). Затем база данных записывается на тот или иной физический носитель и заполняется данными. Рассмотрим каждую из этих задач, но сначала познакомимся с реляционной терминологией.

Обзор терминологии

Реляционная база данных — база данных, основанная на реляционной модели. Слово «реляционный» происходит от английского «relation» (отношение).

Отношение — это таблица, обладающая определенными свойствами.

1. Записи в отношении могут иметь только одиночные значения; множественные значения не допускаются. Следовательно, на пересечении строки и столбца находится только одно значение.

2. Все записи в одном столбце имеют один и тот же тип. Например, один столбец может содержать имена покупателей, а другой — их даты рождения. Каждый столбец имеет уникальное имя, и порядок следования столбцов несуществен. Столбцы отношения носят название атрибутов. Каждый атрибут имеет свой домен, который представляет собой физическое и логическое описание множества допустимых значений.

3. В отношении не может быть двух одинаковых строк, и порядок следования строк несуществен (рис. 1). Строки отношения называются также кортежами.

Рис.1. Отдельный экземпляр реляционной структуры PATIENT.

Рисунок 1 являет собой пример, или отдельный экземпляр, реляционной структуры, содержащей сведения о пациенте клиники. Обобщенный формат, PATIENT (Name, Birth Date, Gender, AccountNumber, Physician) — это структура отношения; именно ее большинство людей имеют в виду под термином отношение. Если мы добавим в структуру отношения ограничение на возможные значения данных, мы получим реляционную схему (relational schema). Все эти термины приведены в табл. 1.

Таблица 1.

Обзор реляционной терминологии.

Термин «ключ»

Термин ключ зачастую является источником недоразумений, так как он имеет различные значения на стадиях проектирования и реализации. В процессе проектирования под ключом понимается один или несколько столбцов, однозначно определяющих строку отношения. Известно, что каждое отношение имеет хотя бы один ключ, поскольку каждая строка является уникальной; в предельном случае ключ представляет собой комбинацию всех столбцов отношения. Обычно ключ состоит из одного-двух столбцов.

На стадии реализации термин ключ используется в другом значении. В большинстве реляционных СУБД ключом называется столбец, на базе которого СУБД формирует индекс и другие структуры данных. Это делается для того, чтобы обеспечить быстрый доступ к значениям из данного столбца. Эти ключи не обязаны быть уникальными, и зачастую они действительно таковыми не являются. Они создаются только для повышения быстродействия.

Рассмотрим, например, отношение ЗАКАЗ (НомерЗаказа, ДатаЗаказа, НомерКли-ента, Количество). С точки зрения проектирования, ключом этого отношения является НомерЗаказа, так как выделение жирным шрифтом означает, что данный атрибут однозначно определяет строку отношения. С точки зрения реализации, ключом может быть любой из четырех столбцов данного отношения. Это может быть, например, атрибут ДатаЗаказа. В таком случае СУБД создаст структуру данных, обеспечивающую быстрый доступ к данным из отношения ЗАКАЗ по значению даты заказа. Скорее всего, конкретному значению атрибута ДатаЗаказа будет соответствовать много строк. В данном смысле определение атрибута в качестве ключа не говорит ничего о его уникальности.

Иногда, чтобы различать два значения слова ключ, употребляются термины логический ключ (logical key) и физический ключ (physical key). Логический ключ — это уникальный идентификатор, а физический ключ — это столбец, для которого с целью увеличения быстродействия создан индекс или другая структура данных.

Индексы

Поскольку физический ключ обычно является индексом, некоторые оставляют за термином ключ значение логического ключа, а за термином индекс — значение физического ключа. В данном реферате термин ключ мы будем использовать в значении «логический ключ», а термин индекс — в значении «физический ключ».

В пользу создания индексов есть три соображения. Одно из них состоит в том, чтобы обеспечить ускоренный доступ к строкам по значению индексируемого атрибута. Другое заключается в упрощении сортировки строк по этому атрибуту. Например, в отношении ЗАКАЗ в качестве ключа может быть определен атрибут ДатаЗаказа, в результате чего отчеты, в которых заказы отсортированы по дате, будут генерироваться быстрее.

Третья цель построения индексов — обеспечение уникальности. Индексы не обязаны быть уникальными, но когда разработчик хочет, чтобы какой-то столбец был уникальным, СУБД создает для этого столбца индекс. В большинстве реляционных СУБД столбец или группу столбцов можно сделать уникальными, если при определении столбца в таблице указать ключевое слово UNIQUE.

Реализация реляционной базы данных

Для описания структуры базы данных мы используем реляционную модель. Поэтому от проектирования базы данных мы можем непосредственно переходить к ее реализации. Нет нужды как-либо преобразовывать структуру па стадии реализации: все, что требуется сделать, — это описать существующую реляционную структуру для СУБД.

При реализации баз данных с использованием СУБД, основанных не на реляционной модели, дело обстоит иначе. Например, реализуя базу данных на основе модели DL/I, мы должны преобразовать реляционную структуру в иерархическую, а затем описать для СУБД преобразованную структуру.

Описание структуры базы данных для СУБД

Есть несколько способов, с помощью которых структура базы данных описывается для СУБД. Эти способы зависят от того, какая конкретно СУБД используется. В некоторых продуктах создается текстовый файл, который описывает структуру базы данных. Язык, используемый для определения такой структуры, иногда называется языком определения данных (data definition language, DDL). В текстовом DDL-файле перечислены названия таблиц базы данных, указаны названия столбцов этих таблиц и описано их содержимое, определены индексы, а также описаны другие структуры (ограничения, меры безопасности). В листинге 1 с помощью типичного языка определения данных описана простая реляционная база данных для гипотетической СУБД. Более реалистичные примеры создаются с использованием стандарта под названием SQL.

Листинг 1. Пример текстового DDL-файла определения данных.

Некоторые СУБД не требуют, чтобы структура базы данных была определена с помощью DDL в текстовом формате. Наиболее распространенная альтернатива — это графический способ задания структуры базы данных. Например, в Access 2002 разработчику дается графическая структура в виде списка, в соответствующих местах которой нужно ввести имена таблиц и столбцов.

Вообще говоря, графические средства описания данных распространены в СУБД, предназначенных для работы на персональных компьютерах. На серверах и больших ЭВМ применяются как графические, так и текстовые средства. Например, в Oracle и SQL Server для определения данных могут применяться оба способа. На рис. 2 представлена общая схема процесса описания данных для СУБД.

Рис.2. Процесс описания данных для СУБД.

При любом способе определения структуры данных разработчик должен дать название каждой таблице, определить столбцы для этой таблицы и описать физический формат данных в каждом столбце (скажем, TEXT 10). Кроме того, в зависимости от возможностей используемой СУБД, разработчик может указать ограничения, которые должны реализовываться СУБД. Значения столбцов могут определяться, например, как NOT NULL (не пустой) или UNIQUE (уникальный). Некоторые продукты позволяют также устанавливать ограничения на возможные значения (атрибут Часть может принимать значения, меньшие 10 000, а атрибут Цвет может принимать одно из значений ['Красный'/Зеленый'/Синий']). Наконец, могут быть введены ограничения целостности по внешнему ключу. Приведем пример такого ограничения: «Значение атрибута НомерОтдела в таблице СОТРУДНИК должно быть равно значению атрибута НомерОтдела в таблице ОТДЕЛ».

Во многих СУБД разработчик может также устанавливать пароли и использовать другие средства контроля и безопасности. Существует множество различных стратегий обеспечения безопасности. В одних стратегиях объектами контроля являются структуры данных (например, таблица защищается паролем), в других — пользователи (обладатель пароля X может читать и обновлять таблицы Т1 и Т2).

Распределение пространства на физических носителях

Кроме определения структуры базы данных, разработчик должен выделить место для базы данных на физическом носителе. И вновь конкретные действия зависят от того, какая именно СУБД используется. В случае персональной базы данных все, что требуется сделать, — это присвоить базе данных каталог на диске и дать ей имя. После этого СУБД автоматически выделит пространство для хранения данных.

Другие СУБД, в особенности предназначенные для серверов и больших ЭВМ, требуют больших усилий. Чтобы повысить быстродействие и улучшить контроль, необходимо тщательно спроектировать распределение информации в базе данных по дискам и каналам. Например, в зависимости от специфики обработки приложений, может оказаться, что определенные таблицы лучше размещать на одном и том же диске. И наоборот, может быть важно, чтобы определенные таблицы не находились на одном и том же диске.

Рассмотрим, например, объект-заказ, скомпонованный из таблиц ЗАКАЗ, СТР0КА_ ЗАКАЗА и ТОВАР. Предположим, что при обработке заказа приложение считывает одну строку из таблицы ЗАКАЗ, несколько строк из таблицы СТР0КА_ЗАКАЗА и по одной строке из таблицы ТОВАР для каждой строки из таблицы СТР0КА_ЗАКАЗА. Далее, строки из таблицы СТР0КА_ЗАКАЗА, относящиеся к одному и тому же заказу, обычно сгруппированы вместе, а строки в таблице ТОВАР не сгруппированы никак. Эту ситуацию иллюстрирует рис. 3.

Рис.3. Данные для 3-х таблиц, представляющих заказ.

Теперь представим, что организация параллельно обрабатывает множество заказов и что у нее есть два диска: один большого объема и быстродействующий, а другой — меньшего объема и более медленный. Разработчик должен определить наилучшее место для хранения данных. Возможно, производительность улучшится, если таблица ТОВАР будет храниться на большом диске с быстрым доступом, а таблицы СТРОКА_ЗАКАЗА и ЗАКАЗ — на диске меньшего размера и быстродействия. А может быть, производительность будет выше, если поместить данные из таблиц ЗАКАЗ и СТРОКА_ЗАКАЗА за предыдущие месяцы на более медленный диск, а за текущий месяц — на более быстрый.

Мы не можем ответить на эти вопросы здесь, поскольку ответ зависит от объема данных, характеристик СУБД и операционной системы, размера и быстродействия дисков и каналов, а также от требований приложений, использующих эту базу данных. Смысл состоит в том, что все эти факторы необходимо принимать во внимание при выделении пространства для базы данных на физическом носителе.