Базы данных Access.

1. Базы данных Access.

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

3. Таблицы, ключи, схемы, отношения, индексы.

4. Проектирование баз данных. Этапы проектирования.

5. Базовые принципы проектирования базы данных.

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

Реляционные базы данных основаны на мощном теоретическом базисе реляционной алгебры. Алгебраическую теорию не надо знать для использования этих баз, но надо владеть основными понятиями о базах. Модель реляционной базы создана в 1970 году Коддом (E.F. Codd) из корпорации IBM, который также разработал язык запросов, впоследствии названный SQL.

Таблицы

Реляционные базы данных построены на основе отношений, обычно называемых таблицами. Таблица представляет собой таблицу с данными.

Пример: простой таблицы с именами и адресами клиентов книжного магазина "Book-O-Rama".

Таблица КЛИЕНТЫ

КлиентID	Имя	Адрес	Город
1	Джулия Смит	25 Oak Street	Airport West
2	Алан Вонг	1/47 Haines Avenue	Box Hill
3	Мишель Артур	357 North Road	Yarraville

Таблица имеет название Клиенты.

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

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

Значения. Каждая строка состоит из набора персональных значений, соответствующих столбцам. Каждому значению отвечает тип данных, задаваемый столбцом.

Ключи

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

Можно отличить Джулия от других, задав строку c ее адресом "Джулия Смит, 25 Oak Street, Airport West". Но такая строка слишком длинная, в одном столбце таблицы ее не поместить и звучит слишком официально.

Лучше каждому клиенту присвоить свой уникальный КлиентID (идентификатор клиента). Принцип аналогичный, как в банке, где выдают номер счета, или в клубе, где каждый имеет собственную членскую карточку. При этом условии информацию о клиенте легче разместить в базе данных, а искусственный номер претендует на звание уникального. Причем, для присвоения этого номера не обязательно располагать большой информацией о клиенте.

Столбец идентификации в таблице называется ключом или первичным ключом. Ключ может состоять из нескольких столбцов. Если, например, мы захотим идентифицировать Джулия как "Джулия Смит, 25 Oak Street, Airport West", то ключ составят столбцы Имя, Адрес, Город, и его уникальность будет сложно гарантировать.

В базах данных обычно содержится несколько таблиц, и ключ является связующим звеном между ними.

Таблица КЛИЕНТЫ

КлиентID	Имя	Адрес	Город
1	Джулия Смит	25 Oak Street	Airport West
2	Алан Вонг	1/47 Haines Avenue	Box Hill
3	Мишель Артур	357 North Road	Yarraville

Таблица ЗАКАЗЫ

ЗаказID	КлиентID	Сумма	Дата
1	3	27.50	02-Апр-2000
2	1	12.99	15-Апр-2000
3	2	74.00	19-Апр-2000
4	1	6.99	01-Май-2000

Таблица Заказы содержит заказы, сделанные клиентами. Каждая строка в таблице Заказы один заказ, сделанный одним клиентом. Какой клиент сделал заказ ясно из сохраняемого его КлиентID (идентификатора клиента). Например, посмотрев на заказ ЗаказID 2, можно узнать его осуществил клиент с КлиентID 1. Обратившись затем к таблице Клиенты, узнаем, что КлиентID 1 принадлежит клиенту по имени Джулия Смит.

По терминологии реляционных таблиц такое отношение называют внешним ключом. КлиентID – первичный ключ в таблице Клиенты, а в другой таблице Заказы он уже становится внешним ключом.

Схемы

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

Схемы могут представляться в виде диаграмм как выше, в виде диаграмм "сущность-отношение" или в форме текста, например:

Клиенты (КлиентID, Имя, Адрес, Город)

Заказы (ЗаказID, КлиентID, Сумма, Дата)

Подчеркнутые элементы в схеме являются первичными ключами, а элементы, подчеркнутые пунктиром, - внешними ключами.

Отношения

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

В реляционной базе данных существует 3 основных типа отношений, классифицируемых в зависимости от количества элементов по каждую сторону отношения:

"один к одному", "один ко многим", "многие ко многим".

• Отношение "один к одному" означает, что в отношении с каждой стороны участвует ровно одна запись. Например, если поместить адреса не в таблицу Клиенты, а в другую таблицу Адрес, между таблицами будет отношение "один к одному". От Адрес к Клиенты может лежать внешний ключ или другой похожий вариант (не обязательно оба вместе). Или, например, информация о финансовом состоянии клиента должна быть отделена от остальных сведений о нем.

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

• Отношение "многие ко многим" означает, что несколько строк одной таблицы ссылаются на несколько строк другой. Например, существуют две таблицы Книги и Авторы. Одну книгу могли написать несколько авторов, каждый из которых написал и другие книги, причем некоторые из них могли быть написаны в соавторстве с другими. Такой тип отношений, как правило, полностью замыкает все таблицы друг на друга, так что у вас могут быть и Книги, Авторы, и Книги_Авторов. Третья таблица Книги_Авторов будет содержать только ключи из других таблиц в качестве попарных внешних ключей для показа какие авторы, к каким книгам имеют отношение.

Классическим примером отношения "многие ко многим" является таблица товаров, приобретенных покупателями. Каждый покупатель может приобрести множество различных товаров, и каждый товар может быть приобретен различными покупателями.

Индексы

Индексы – это структуры, определяющие порядок записей в таблице. Обычно данные в таблице не упорядочены. На практике же, возникает необходимость обращаться к ним в определенном порядке. Например, при печати списка имен заказчиков надо печатать их в алфавитном порядке. Если печатаются почтовые наклейки, то, вероятно, их надо печатать в порядке почтового индекса. Тип обработки, выполняемый над базой, определяет порядок, в котором должны быть расположены строки таблицы. Это главное для таблицы, которая будет по-разному использоваться в различным операциях.

Если запрос обуславливает различный порядок строк в таблице, то их придется реорганизовывать. Но для этого требуется слишком много времени. Решение проблемы состоит в поддержке маленьких таблиц, называемых индексами, которые определяют последовательность чтения записей из таблицы. Индексный файл не содержит информацию, непосредственно появляющуюся в таблице, а содержит только числа, определяющие порядок записей.

Пусть 5-я запись в таблице должна появится первой, когда строки таблицы запрошены в алфавитном порядке. Тогда первый элемент индексного файла содержит значение 5. Значит, при извлечении строк заданной таблицы из базы сначала будет извлечен 5-й элемент.

Таблицы может иметь более одного индекса. Для этого надо задать поля, на которых будет основан индекс.

Когда индексация не нужна?

При модификации записи индексы также должны модифицироваться, что заметно увеличивает время модификации записи. Индексы также увеличивают занимаемый объем памяти и, значит, время и ресурсы, необходимые для обычного резервирования.

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

Проектирование баз данных

Перед созданием с помощью Microsoft Access таблиц, форм и других объектов, составляющих базу данных, важно уделить время проектированию базы данных. При использовании как базы данных Microsoft Access, так и проекта Microsoft Access, хорошая структура является основой создания базы данных, успешно, точно и эффективно выполняющей поставленные задачи.

Этапы проектирования базы данных: