ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ОБРАЗОВАНИЮ
РОССИЙСКОЙ ФЕДЕРАЦИИ
МОСКОВСКИЙ ГОСУДАРСТВЕННЫЙ ИНСТИТУТ
РАДИОТЕХНИКИ, ЭЛЕКТРОНИКИ И АВТОМАТИКИ
(ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ)
Кафедра конструирования и производства РЭС
Курсовая работа
по предмету: "Информационные технологии в проектировании РЭС"
на тему: Методы построения баз данных для информационных систем
(Основы построения реляционных баз данных)
Выполнил
студент гр.ВК-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). Логический ключ — это уникальный идентификатор, а физический ключ — это столбец, для которого с целью увеличения быстродействия создан индекс или другая структура данных.