В последние годы в большинстве БД используются реляционные модели данных, и практически все современные СУБД ориентированны именно на такое представление информации. Реляционную модель можно представить как особый метод рассмотрения данных, который включает как собственно данные (в виде таблиц), так и способы работы и манипуляции с ними (в виде связей). Другими словами, в реляционной БД используется несколько таблиц, между которыми устанавливаются связи. Таким образом, информация, введенная в одну таблицу, может быть связана с одной или несколькими записями из другой таблицы.
Между записями двух таблиц (например, таблиц А и В) могут существовать следующие основные виды связей:
· " один к одному " (каждой записи из А соответствует одна определенная запись из В, например, работник получает зарплату, и только одну);
· " один ко многим " (каждой записи из А соответствует несколько записей из В, например, в доме проживает много жильцов);
· " многие к одному " (множеству записей из А соответствует одна определенная запись из В, например, несколько студентов учатся в одной группе);
· " многие ко многим " (множеству записей из А соответствует множество записей из В, например, у нескольких студентов занятия ведут разные преподаватели).
Важным понятием в теории реляционных БД является нормализация, принципы которой можно сформулировать в виде следующих основных правил, используемых при разработке структуры БД:
1. В каждом поле таблицы должен находиться уникальный вид информации, т.е. в одной и той же таблице не должны находиться повторяющиеся поля.
2. В каждой таблице должен быть первичный ключ или уникальный идентификатор, который однозначно определяет данную запись среди множества записей таблицы.
3. Каждому значению первичного ключа должна соответствовать исчерпывающая информация об объекте таблицы.
4. Изменение значения любого поля таблицы, не входящего в состав первичного ключа, не должно влиять на информацию в других ее полях.
Microsoft Access является СУБД реляционного типа. Достоинством Access является то, что она имеет очень простой графический интерфейс, который позволяет грамотному пользователю (не программисту) не только создавать собственные базы данных, но и разрабатывать приложения различной степени сложности. СУБД Access применяется в тех случаях, когда прикладная задача требует хранения и обработки разнородной информации о большом количестве объектов и предполагает возможность многопользовательского режима. Примером может служить задача ведения складского учета.
Работа с базой данных
Работа с БД делится на три этапа:
1. Проектирование
2. Программная реализация
3. Эксплуатация
На этапе проектирования закладываются основы будущей БД. Проектирование проводится на бумаге и требует очень тщательного подхода, так как именно здесь разрабатывается БД. Необходимо проделать следующие действия:
· собрать информацию о будущей работе, о ее структуре и движении документов, изучить задачи автоматизации, определить объекты системы и связи между ними;
· для каждого объекта выявить свойства и характеристики, по которым создаются поля таблиц;
· для каждого объекта назначить ключевые поля (первичные ключи), провести нормализацию исходных таблиц, установить связи.
Этап реализации выполняется на компьютере в следующем порядке:
· составляются структуры таблиц и вводятся в компьютер;
· разрабатываются запросы для отбора данных, отчеты для печати, создаются макросы и экранные формы для работы с данными;
· планируется порядок ведения и поддержания БД в рабочем состоянии.
Этап эксплуатации начинается с внесения в БД реальной информации, после чего происходит ее использование.
Проект базы данных
Рассмотрим этапы создания БД на примере фирмы, которая покупает товары, хранит их, а затем продает с некоторой наценкой.
Представление фирмы в таблицах
Задача состоит в том, чтобы всю деятельность фирмы представить в таблицах. Фирма закупает товар у определенного предприятия в определенном количестве и по определенной цене. За эту работу отвечает менеджер по поставкам. Менеджер по продажам этот же товар продает, но уже другому предприятию, в другом количестве и по другой цене. Таким образом, работу фирмы можно представить в таблице (Табл.1):
| Таблица 1. Деятельность фирмы | Дата про-дажи | |||
| Данные о менеджере по продажам | Телефон | |||
| Адре с | ||||
| Да т а рождения | ||||
| От че с т во | ||||
| Имя | ||||
| Фамилия | ||||
| Менеджер по продажам | ||||
| Цена про-дажи | ||||
| Коли-чество товара про-дажи | ||||
| Дан-ные о клиен-те | Телефон | |||
| А д р е с | ||||
| Наименование | ||||
| Клиент | ||||
| Дата покуп-ки | ||||
| Данные о менеджере по покупкам | Т е л ефо н | |||
| Адре с | ||||
| Да т а рождения | ||||
| От че с т во | ||||
| Имя | ||||
| Фамилия | ||||
| Менед-жер по покуп-кам | ||||
| Цена покуп-ки | ||||
| Коли-чество товара покуп-ки | ||||
| Дан-ные о постав-щике | Телефон | |||
| Адре с | ||||
| Наименование | ||||
| Постав-щик | ||||
| Дан-ные о товаре | Ед. и змерения | |||
| Ка т е г ория | ||||
| Наименование |
Работа с такой таблицей вызывает множество проблем:
· в каждую новую запись необходимо вводить повторяющиеся значения, что очень трудоемко и может вызвать ошибки при вводе информации;
· невозможно упорядочить записи, например, по поступающим товарам;
· в большой таблице не виден список всех имеющихся на фирме товаров с указанием их цены;
· нет возможности рассчитать сумму на закупки и продажу товара, получение дохода и т.п.
Для устранения этих недостатков служит БД. Необходимо переписать большую таблицу в виде нескольких таблиц, которые связаны между собой и подчиняются следующим правилам:
· каждая таблица содержит данные об одном предмете (например, таблица Товарвключает только сведения о товаре, а не о менеджере, который его купил);
· в таблице каждое поле содержит единственный элемент данных (например, фамилия, имя и отчество менеджера должны размещаться в трех столбцах);
· столбцы в таблице не должны повторяться;
· каждая таблица должна содержать дополнительное поле «Код », которое должно быть ключевым.
После разбивки большой таблицы, получаем две основные таблицы (Поставка товара, Продажа товара) и пять вспомогательных таблиц (Товар, Поставщики, Клиенты, Менеджеры по поставкам, Менеджеры по продажам).
Таблица 2. Поставка товара
| Код поставки (кл. поле) | Код товара | Код поставщика | Код менеджера поставки | Дата поставки | Количество товара поставки | Цена товара поставки |
Таблица 3. Продажа товара
| Код продажи (кл. поле) | Код товара | Код клиента | Код менеджера продажи | Дата продажи | Количество товара продажи | Цена товара продажи |
Таблица 4. Товар
| Код товара (кл. поле) | Наименование товара | Категория товара | Ед.измерения |
Таблица 5. Поставщики
| Код поставщика (кл. поле) | Наименование поставщика | Адрес поставщика | Телефон поставщика |
Таблица 6. Клиенты
| Код клиента (кл. поле) | Наименование клиента | Адрес клиента | Телефон клиента |
Таблица 7. Менеджеры по поставкам
| Код менеджера поставки (кл. поле) | Фамилия | Имя | Отчество | Дата рождения | Домашний адрес | Домашний телефон |
Таблица 8. Менеджеры по продажам
| Код менеджера продажи (кл. поле) | Фамилия | Имя | Отчество | Дата рождения | Домашний адрес | Домашний телефон |
При этом основные таблицы связаны со вспомогательными с помощью кодов:
| Поставка товара |
| Код поставки |
| Код товара |
| Код поставщика |
| Код менеджера поставки |
| Дата поставки |
| Количество товара поставки |
| Цена товара поставки |
| Поставщики |
| Код поставщика |
| Наименование поставщика |
| Адрес поставщика |
| Телефон поставщика |
| Менеджеры по поставкам |
| Код менеджера поставки |
| Фамилия |
| Имя |
| Отчество |
| Дата рождения |
| Домашний адрес |
| Домашний телефон |
| Товар |
 Код товара
|
| Наименование товара |
| Категория товара |
| Единица измерения |
| Продажа товара |
| Код продажи |
| Код товара |
| Код клиента |
| Код менеджера продажи |
| Дата продажи |
| Количество товара продажи |
| Цена товара продажи |
| Менеджеры по продажам |
| Код менеджера продажи |
| Фамилия |
| Имя |
| Отчество |
| Дата рождения |
| Домашний адрес |
| Домашний телефон |
| Клиенты |
| Код клиента |
| Наименование клиента |
| Адрес клиента |
| Телефон клиента |
Рис.1 Схема связей таблиц
Постановка задачи
Вся информация, с которой работает фирма, разнесена по таблицам. После этого необходимо изучить деятельность фирмы. То есть необходимо установить, что происходит с информацией внутри фирмы; какая документация ведется на фирме. Например, продажа товара сопровождается выпиской документа «Счет-фактура выданный». Таким образом, необходимо изучить какие пути проходит информация внутри фирмы. Результатом этого будет сформированный список задач, которые предстоит решать БД.
В процессе изучения деятельности фирмы сформулированы следующие задачи для будущей БД:
1. составление данных на приобретенный товар с учетом наименования предприятия, количества приобретенного товара, цены товара и даты покупки, что отражается в реестре «Счет-фактура выданный» и в «Книге покупок»;
2. сбор информации о проданном товаре с учетом наименования предприятия, количества проданного товара, цены товара и даты продажи, что отражается в реестре «Счет-фактура полученный» и в «Книге продаж»;
3. расчет остатков товаров на определенную дату;
4. расчет прибыли фирмы из расчета разности суммы, затраченной на приобретение товара, и суммы, полученной от продажи, по каждому наименованию товара и по каждой категории товара;
5. предусмотреть возможность вывода сведений о каждом товаре, поставщике и клиенте средствами поиска по заданным критериям;
6. сбор информации по количеству поступившего товара от каждого поставщика;
7. сбор информации по количеству проданного товара каждому клиенту;
8. предусмотреть возможность ввода нового товара, нового поставщика, нового клиента;
9. предусмотреть возможность вывода на экран и на печать отчетов и документов.
С учетом поставленных задач, необходимо создать две дополнительных таблицы: Счет-фактура выданный и Счет-фактура полученный, которые будут заполняться автоматически при продаже и покупке товара соответственно.