WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!


Pages:     || 2 | 3 | 4 | 5 |   ...   | 10 |
Федеральное агентство по образованию Тверской государственный технический университет Г.П. Виноградов, Н.В. Кирсанова ПРОЕКТИРОВАНИЕ СТРУКТУРЫ И СОЗДАНИЕ РЕЛЯЦИОННЫХ БАЗ ДАННЫХ СРЕДСТВАМИ СУБД Access Учебное пособие Издание первое Тверь 2006 2 УДК 681.3.01(075.8) ББК 32.973-018.2Я7 Виноградов Г.П., Кирсанова Н.В. Проектирование структуры и создание реляционных баз данных средствами СУБД Access: Учебное пособие. 1-е изд. Тверь: ТГТУ, 2006. 84 с.

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

Рецензенты: доктор физ.-мат. наук, профессор ТГУ А.А. Андреева;

кандидат технических наук, профессор АВН Н.М. Расолько.

ISBN 5-7995-0341-4 ©Тверской государственный технический университет, 2006 3 СОДЕРЖАНИЕ Введение......................................................................................................4 1. Реляционные базы данных.....................................................................5 2. Проектирование нормализованных баз данных..................................7 3. Создание базы данных.........................................................................11 4. Создание таблиц...................................................................................13 5. Модификация структуры таблицы.....................................................32 6. Свойства полей.....................................................................................35 7. Печать структуры таблицы..................................................................48 8. Основные операции с таблицами в окне базы данных.....................9. Определение связей между таблицами..............................................10. Работа с информацией в таблицах. Режим Таблицы......................11. Работа со связанными таблицами.....................................................12. Варианты заданий...............................................................................Библиографический список..................................................................... ВВЕДЕНИЕ Почти все современные информационные системы основаны на реляционной модели управления базами данных. Название «реляционная» связано с тем, что каждая запись в такой базе данных содержит сведения, относящиеся только к одному конкретному объекту.

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

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

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

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

1. РЕЛЯЦИОННЫЕ БАЗЫ ДАННЫХ Теория реляционных баз данных была разработана в начале 70-х годов Кодом на основе математической теории отношений. В реляционной базе данных все данные хранятся в виде таблиц, при этом все операции над базой данных сводятся к манипулированию таблицами. Основными понятиями являются: таблица, отношение, строка, столбец, первичный и внешний ключи.

Таблица состоит из строк и столбцов и имеет уникальное имя в базе данных. База данных содержит множество таблиц, связь между которыми устанавливается с помощью совпадающих полей - ключей. В каждой из таблиц содержится информация о каких-либо объектах одного типа (группы). В качестве примера рассмотрим базу данных, предназначенную для учета заказов покупателей и состоящую из двух таблиц: Клиенты (табл.1) и Заказы (табл.2). В первой таблице содержится информация о покупателях (фамилия, имя, отчество, адрес, телефон и т.п.), а во второй таблице содержится информация о заказах различных покупателей.



Таблица 1. Таблица 2.

Структура таблицы Клиенты Структура таблицы Заказы Первичный ключ Ключ связи Наименование Ключ связи Наименов Тип 1 Код клиента Счетчик 1 Код товара Числовой 2 Фамилия Текстовый 2 Код клиента Числовой 3 Дата заказа Текстовый 3 Имя Текстовый 4 Заказано Текстовый 4 Отчество Текстовый 5 Дата продажи Текстовый 5 Телефон Текстовый 6 Продано Текстовый 6 Адрес Текстовый 7 Цена Денежный 7 Предприятие Текстовый 8 Примечание Memo 8 Руководитель Текстовый 9 Категория Числовой 10 Наименование Текстовый 9 Кредит Денежный товара 10 Примечание Меmо С помощью этой базы данных можно получить информацию о каждом клиенте (таблица Клиенты) и сделанных им заказах (таблица Заказы). Каждая запись в таблицах идентифицирует один объект группы (покупатель или сделанный заказ).

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

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

MS Access поддерживает четыре типа отношений между таблицами: один– к–одному, один–ко–многим, много–к–одному, много–ко–многим.

1.1. Отношение один-к-одному Отношение один-к-одному означает, что каждая запись в одной таблице соответствует только одной записи в другой таблице.

В качестве примера рассмотрим отношение между группами полей Физические лица (табл. 3) и Сотрудники (табл. 4).

Таблица 3. Структура Таблица 4. Структура таблицы Физические лица таблицы Сотрудники № Наименование Тип № Наименование Тип 1 КодФизЛица Счетчик 1 Код сотрудника Счетчик 2 Фамилия Текстовый 2 Должность Текстовый 3 Имя Текстовый 3 Разряд Числовой 4 Отчество Текстовый 4 Зарплата Числовой 5 Телефон Текстовый 5 Рейтинг Числовой 6 Адрес Текстовый 6 Дата приема Дата/время 7 ДатаРождения Дата/время 8 Фотография OLE 7 Примечание Memo 9 Примечание Memo В табл. 3 содержатся данные о личности сотрудника, а в табл. 4 - профессиональные сведения. Между таблицами Физические лица и Сотрудники существует отношение один-к-одному, поскольку для одного человека может существовать только одна запись, содержащая профессиональные сведения.

Связь между этими таблицами поддерживается при помощи совпадающих полей: Код сотрудника (табл. 4) и КодФизЛица (табл. 3). Отметим, что эти поля имеют разные наименования, но один и тот же тип данных. Связь между таблицами устанавливается на основании значений совпадающих полей, но не их наименований.

1.2. Отношение много-к-одному Отношение много-к-одному аналогично рассмотренному ранее типу одинко-многим. Тип отношения между объектами зависит от вашей точки зрения.

Например, если мы будем рассматривать отношение между сделанными заказами и клиентами, то получим отношение много-к-одному.

1.3. Отношение много-ко-многим Отношение много-ко-многим возникает между двумя таблицами в тех случаях, когда:

одна запись из первой таблицы может быть связана более чем с одной записью из второй таблицы;

одна запись из второй таблицы может быть связана более чем с одной записью из первой таблицы.

В качестве примера обратимся к магазину оптовой торговли.

Рассмотрим две группы объектов.

1. В таблице Поставки товаров (табл. 5) представлен список товаров, производимых предприятиями-поставщиками.

2. В таблице Заказы потребителей (табл. 6) содержится список товаров, заказанных потребителями, Таблица 5. Структура таблицы Таблица 6. Структура таблицы Заказы потребителей Поставки товаров Тип № Наименование № Наименование Тип 1 Код предприятия Числовой 1 Код потребителя Числовой 2 Код товара Числовой 2 Код товара Числовой 3 Цена поставки Денежный 3 Цена продажи Денежный 4 Количество Числовой Между таблицами Поставки товаров и Заказы потребителей существует отношение много-ко-многим, так как каждый поставляемый товар может входить в несколько заказов. Аналогично каждый заказанный товар может производиться более чем одним предприятием. Связь между таблицами устанавливается на основании значений в совпадающих полях Код товара.

2. ПРОЕКТИРОВАНИЕ НОРМАЛИЗОВАННЫХ БАЗ ДАННЫХ При проектировании реляционной базы данных необходимо решить вопрос о наиболее эффективной структуре данных. Основные цели проектирования:

обеспечить быстрый доступ к данным таблицы;

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

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

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





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

В качестве примера рассмотрим таблицу Продажи (табл.7).

Таблица 7. Структура таблицы Продажи № Наименование Тип 1 Код клиента Числовой 2 Фамилия Текстовый 3 Имя Текстовый 4 Отчество Текстовый 5 Телефон Текстовый 6 Факс Текстовый 10 Адрес Текстовый 11 Предприятие Текстовый 12 Руководитель Текстовый 13 Кредит Денежный 14 Примечание Memo 15 Код товара Числовой 16 Дата заказа Дата/время 17 Заказано Числовой 18 Дата продажи Дата/время 19 Продано Числовой 20 Цена Денежный 21 Примечание к заказу Memo 22 Категория Числовой 23 Наименование товара Текстовый Таблицу Продажи можно рассматривать как однотабличную базу данных. Основная проблема заключается в том, что в ней содержится значительное количество повторяющейся информации. Например, сведения о покупателе повторяются для каждого сделанного им заказа. Такая структура данных является причиной следующих проблем, возникающих при работе с базой данных:

значительные затраты времени на ввод повторяющихся данных.

Например, для всех заказов, сделанных одним из покупателей, придется каждый раз вводить одни и те же данные о покупателе;

при изменении адреса или телефона покупателя необходимо корректировать все записи, содержащие сведения о заказах этого покупателя;

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

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

2.1. Первая нормальная форма Табл. 7 является ненормализованной таблицей.

Требования к таблице в первой нормальной форме:

1. Таблица не должна иметь повторяющихся групп полей;

2. В таблице должны отсутствовать повторяющиеся записи.

Для выполнения условия пункта 2 каждая таблица должна иметь первичный ключ. Таблица Продажи (табл. 7) не содержит первичного ключа, что допускает наличие в ней повторяющихся записей. Для выполнения условия 2 добавим поле Код клиента, которое будет содержать значение первичного ключа.

Требование 1 постулирует устранение повторяющихся групп полей.

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

Поэтому надо разбить таблицу Продажи на две отдельные таблицы Клиенты и Заказы и определить поля Код клиента в качестве ключей связи. Структуры таблиц Клиенты и Заказы приведены на рис.1. Тип связи между таблицами Клиенты и Заказы будет один-ко-многим.

Таким образом, для таблицы Клиенты решена проблема повторяющихся групп полей.

Клиенты Заказы Код клиента Код клиента Фамилия Код товара Имя Дата заказа Отчество Заказано Телефон Дата продажи Продано Цена Примечание к заказу Категория Наименование товара Рис.1. Первая нормальная форма Таблица Заказы содержит сведения о товарах, включенных в конкретный заказ. Для исключения повторяющихся записей можно воспользоваться одним из способов:

1) добавить в таблицу новое уникальное ключевое поле Код заказа, что позволит однозначно идентифицировать каждый из заказов. Однако при работе с Ms Access это далеко не лучший метод, так как при разработке многотабличных форм и отчетов связь между таблицами осуществляется посредством ключевых полей с совпадающими значениями;

2) использовать уникальный составной ключ, состоящий из полей Код клиента, Код товара и Дата заказа.

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

Структура связей между таблицами называется схемой данных.

2.2. Вторая нормальная форма Таблица находится во второй нормальной форме, если:

она удовлетворяет условиям первой нормальной формы;

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

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

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

Pages:     || 2 | 3 | 4 | 5 |   ...   | 10 |










© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.