Базы данных ACCESS

Оглавление

 

 

Введение.

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

Основные функции СУБД – это описание структуры базы данных, обработка данных и управление данными.

База данных – это  совокупность сведений о реальных объектах, процессах, событиях или явлениях, относящихся  к определённой теме или задаче, организованная таким образом, чтобы обеспечить удобное представление этой совокупности, как в целом, так и любой её части. Реляционная база данных представляет собой множество взаимосвязанных таблиц, каждая из которых содержит информацию об объектах определённого типа. Каждая строка таблицы содержит данные об одном объекте (например, клиенте, автомобиле, документе), а столбцы таблицы содержат различные характеристики этих объектов – атрибуты (например, наименования и адреса клиентов, марки и цены автомобилей). Строки таблицы называются записями, все записи имеют одинаковую структуру – они состоят из полей, в которых хранятся атрибуты объекта. Каждое поле в записи содержит одну характеристику объекта и имеет строго определённый тип данных (например, текстовая строка, число, дата). Все записи имеют одни и те же поля, только в них содержатся разные значения атрибутов.

Любая СУБД позволяет  выполнять четыре простейшие операции с данными:

- добавить в таблицу  одну или несколько записей;

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

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

 

1. Цель проекта.

 

Целью создания автоматизированной системы управления формирования и обработки заказов является:

• структурирование информации;
• осуществление быстрого поиска оперативной информации;
• получение данных за любой заданный период времени;
• получение документов в соответствии с установленным стандартом;
• быстрое обслуживание клиентов;
• предоставление исчерпывающей отчётной документации;
• вычисление промежуточных и итоговых данных;
• защита информации от случайных лиц;
• контроль достоверности данных;
• надёжное хранение данных.

2. Описание предметной области.  Постановка задачи. Функции решаемой  задачи. Используемые в задаче  документы.

 

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

- ремонт;

- доп. услуги;

- формирование заказа;

- учёт платежей по  заказам;

- диагностика.

Функции, проектируемой  задачи:

В данном проекте рассматривается  задача «Формирование и обработка заказов». Предполагается наличие одного склада, работа с постоянными заказчиками, и ориентация на определённую группу товаров – банные принадлежности.

Функции, проектируемой  задачи:

- оформление заказа;

- ввод данных и их  редактирование;

- ведение журнала заказов;

- поиск информации  по номеру накладной, по коду  товара, по дате, по названию организации;

- вычисление итоговых  данных по готовности машины  заказчика.

Исходные документы:

1) заказ (счёт);

2) клиент;

3) мастер;

4) мастерская;

5) номенклатура работ;

6) работы заказа;

7) чеки;

Ограничения, принятые в  проекте:

• - в одном заказе может быть несколько наименований товара,
• - условие формирования заказа – отсутствие задолженности у заказчика

3 Логическое проектирование

3.1. Разработка информационного обеспечения задачи

Результатом логического  проектирования информационного обеспечения  задачи должна быть ИЛМ БД.

3.1.1. Анализ документов

Рассмотрим информацию, содержащуюся в документах, относящихся  к данной задаче. Её можно разделить на две группы: условно-постоянную (заказчики) и оперативно-учётную (запчасти и работы).

Оперативно-учётная информация о формировании заказа находится  в документе «заказ», данные об оплате товаров заказчиками находятся документе «чек».

 

Документ «Заказ» содержит в себе информацию:

1. Номер заказа,

2. Код мастерской,

3. Номер машины,

4. Дата исполнения,

5. Сумма заказа,

        Документ «Клиент» содержит в себе информацию:

1. Номер машины;

2. Марка машины;

3. Имя клиента;

4. Телефон клиента;

Документ «Мастер» содержит:

1. Код мастера
2. ФИО мастера
3. Код работы

Документ «Мастерская» содержит:

1. Код мастерской
2. Наименование мастерской
3. Адрес мастерской
4. Телефон мастерской

Документ «Номенклатура  работ» содержит:

1.  Код работы

2. Наименование работы
3. Стоимость работ

        Документ «Работы заказа» содержит:

1. Номер работы
2. Номер заказа
3. Код работы
4. Код мастера
5. Стоимость работ

        Документ «Чекодержит:

1. Номер чека
2. Дата чека
3. Номер заказа
4. Сумма чека

 

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

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

Используя процессный подход к разработке БД, для определения  состава только тех данных, которые  необходимы для получения выходных документов.

Рассмотрим Чек Рис.1

Рис. 1 «Чек»

 

В анкетной части Чека содержатся номер чека, дата чека, код мастерской, мастер, который работает по определенным видам работ. Так в чеке указываются: адрес и телефон мастерской, номер и марка машины, номер заказа и сумма чека.

Документ «Заказ» определяется первичным ключом – код заказа (счетчик). А в подчиненной форме  «Заказа» вторичный код – код заказа и код товара. Функциональные зависимости реквизитов документа «Заказ» показаны на Табл. 1.

 

Таблица 1.

Функциональные зависимости  реквизитов документа «Заказ»

 

Наименование  реквизита	Функциональные  зависимости
номер заказа	Номер машины; сумма заказа
код мастерской	Наименование_мастерской Адрес_мастерской Телефон_мастерской
номер машины	Марка машины Имя клиента Телефон клиента
дата исполнения	Номер заказа;
сумма заказа	Марка машины;

 

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

3.1.2. Выделение информационных объектов

 

Функциональные зависимости, выявленные при анализе документов, позволяют выделить объекты рассматриваемой  предметной области и описать их реквизиты (имя, тип, длина поля, признак ключа). Для признака ключа используются следующие сокращения: П – простой; У – уникальный (первичный); С – составной (состоит из двух или нескольких реквизитов), В – вторичный (используется для связи с главной таблицей). Для описания объекта будем использовать названия реквизитов документа, добавляя,  при необходимости, имя объекта. Не будем употреблять пробел между словами в имени реквизита. Описание объектов приведено в Табл. 2.

 

 

 

 

Таблица 2.

Имя реквизита	Признак ключа	Тип данных	Длина поля	Название объекта
Номер_заказа	П,У	счетчик	12	Заказ
Дата_заказа		дата	50
Код_мастерской		число	50
Номер_машины		текст	15
Дата исполнения		дата	12
Сумма заказа		денежн	12
Номер машины	П, У	текст	10	Клиент
Марка машины		текст	20
Имя клиента		текст	10
Телефон клиента		текст	15
Код мастера	П, У	счетч	20	Мастер
ФИО мастера		текст	50
Код работы		число	20
Код мастерской	П, У	счетч	8	Мастерская
Наименование мастерской		текст	20
Адрес мастерской		текст	50
Телефон мастерской		число	12
Код работы		счетч	4	Номенклатура работ
Наименование работы		текст	20
Стоимость работ		число	5
Номер работы	П, У	счетч	20	Работы заказа
Номер заказа		число	20
Код работы		число	20
Код мастера		число	20
Стоимость работ		денежн	12
Номер чека	П, У	cчетч	20	Чеки
Дата  чека		дата	12
Номер заказа		число	20
Сумма чека		денежн	12

 

3.1.3. Определение связей и построение  ИЛМ

 

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

 

Таблица 3

Логические связи между  объектами предметной области “автомастерская”

Ключ связи	Главный объект	Подчинённый объект	Тип отношения
1	2	3	4
Код мастерской	Мастерская	Заказ	1:М
Номер заказа	Заказ	Чек	1:М
Номер заказа	Заказ	Работы заказа	1:М
Номер машины	Клиент	Заказ	1:М
Код работы	Номенклатура работ	Работы заказа	1:М
Код работы	Номенклатура работ	Мастер	1:М
Код мастера	Мастер	Работы заказа		1:М

Графическое изображение  ИЛМ наглядно показывает уровни подчинённости  объектов друг другу на Рис. 2.

 

Рис. 2 « Схема базы данных»

3.1.4. Определение логической структуры  реляционной базы данных

Логическая структура  реляционной базы данных определяется совокупностью логически взаимосвязанных  нормализованных таблиц. Каждая реляционная  таблица имеет структуру, определённую реквизитным составом информационного объекта, который входит в состав ИЛМ. Логические связи таблиц соответствуют связям между объектами. Логическая структура БД, строится на основе ИЛМ. Визуально логическая структура должна совпадать со схемой данных, построенной при реализации проекта, на основе разработанной ИЛМ. Логическая структура БД должна показывать структуру каждого объекта предметной области и связи, построенные с помощью ключевых атрибутов объектов.

3.2. Разработка алгоритмов и технологии  решения задачи

 

Поступающие заказы должны оформляться на компьютере при условии что заказчик не имеет задолженности по предыдущим заказам, эта информация накапливается в базе данных, и на основании её выдаётся заказчику документ «Заказ», по которому заказчик оплачивает заказ наличными(чек). Таким образом, должно быть предусмотрено: