Оптовый склад бытовой химии

Введение

 

С развитием компьютерных технологий возросла потребность хранения и обмена информацией. Для хранения больших объёмов информации были разработаны базы данных (БД).

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

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

Для достижения данной цели необходимо выполнить следующие  задачи:

- провести исследование предметной области;

- выполнить проектирование  структуры базы данных;

- разработать таблицы,  запросы, формы и отчеты;

- разработать главную  кнопочную форму.

Для реализации поставленных задач в работе будет использована СУБД Access.

 

 

 

 

 

Содержание

 

 

1. Исследование предметной области
1. Понятие БД и системы управления БД
2. Структура реляционной БД
3. Классификация СУБД
2. Проектирование структуры БД
1. Описание исходных данных
2. Нормализация исходной таблицы
3. Построение ER-диаграммы (инфологическая модель)
4. Нормализация таблиц
3. Реализация проекта БД
1. Разработка таблиц, форм, запросов, отчетов
2. Разработка главной кнопочной формы (интерфейсы
3. Описание технических и программных средств
4. Защита информации

Заключение

Глоссарий

Литература

 

 

 

 

 

 

 

 

 

Глава 1. Исследование предметной области

 

1. Понятие БД и системы управления БД

 

 

База данных — совокупность данных, хранимых в соответствии со схемой данных, манипулирование которыми выполняют в соответствии с правилами средств моделирования данных.

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

 

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

 

 

 

 

 

 

 

 

 

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

 

 

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

Строки таблицы называются записями. Все записи таблицы имеют одинаковую структуру - они состоят из полей (элементов данных), в которых хранятся атрибуты объекта (рис. 1). Каждое поле записи содержит одну характеристику объекта и представляет собой заданный тип данных (например, текстовая строка, число, дата). Для идентификации записей используется первичный ключ. Первичным ключом называется набор полей таблицы, комбинация значений которых однозначно определяет каждую запись в таблице.

 

 

Рис. 1. Названия объектов в таблице.

 

 

Для работы с данными  используются системы управления базами данных (СУБД). Основные функции  СУБД:

- определение данных;

- обработка данных;

- управление данными;

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

1.3 Классификации СУБД

 

По модели данных.

Примеры:  - иерархические;

- сетевые;

- реляционные;

- объектно-ориентированные;

- объектно-реляционные.

По степени  распределенности.

Локальные СУБД (все части  локальной СУБД размещаются на одном  компьютере).

Распределенные СУБД (части СУБД могут размещаться  на двух или более компьютерах).

По способу  доступа к БД.

 

Файл-серверные.

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

На данный момент файл-серверная технология считается устаревшей.

Примеры: Microsoft Access, Paradox, dBase, FoxPro, Visual FoxPro.

Клиент-серверные.

Клиент-серверная СУБД располагается на сервере вместе с БД и осуществляется доступ к  БД непосредственно, в монопольном  режиме. Все клиентские запросы на обработку данных обрабатываются клиент-серверной СУБД централизованно. Недостаток клиент-серверных СУБД состоит в в повышенных требованиях к серверу. Достоинства: потенциально низкая загрузка локальной сети; удобство централизованного управления; удобство обеспечения таких важных характеристик как надёжность, высокая доступность и высокая безопасность.

Примеры: Oracle, Firebird, Interbase, IBM DB2, Informix, MS SQL Server.

Встраиваемые

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

По степени  универсальности все СУБД делятся  на СУБД общего назначения и специализированные СУБД.

СУБД общего назначения не ориентируются на информационные потребности конкретной группы пользователей. Они могут быть использованы для  создания и использования баз  данных в любой предметной области (документоведение, образование, риэлтерская  деятельность и т.д.). К ним относят MS Access, MS FoxPro. Однако в некоторых случаях доступные СУБД общего назначения не позволяют добиться требуемых результатов. С этой целью используют специализированные СУБД, которые позволяют осуществить работу с данными, описывающие информационные потребности узкого круга пользователей.

 

Глава 2. Проектирование структуры БД

1. Описание исходных данных.

Имя поля	Тип поля		Размер поля	Ключевое поля	Индексируемое поля
Код заказа	Числовой		1-15	Да	Да
Код товара	Числовой		1-15	Нет	Нет
Количество опускаемого  товара	Числовой		1-15	Нет	Нет
Дата опускаемого товара	Дата/время		1-15	Нет	Нет
Код клиента	Числовой		1-15	Да	Да
Код клиента	Числовой		1-15	Нет	Нет
ФИО клиента	Текстовый		1-15	Нет	Нет
Адрес клиента	Тектовый		1-15	Нет	Нет
Код товара	Числовой		1-15	Да	Да
Код поставщика	Числовой		1-15	Нет	Нет
Количество поставки	Числовой		1-15	Нет	Нет
Дата продажи	Дата/время		1-15	Нет	Нет
ФИО	Текстовый		1-15	Нет	Нет
Код поставщика	Числовой		1-15	Да	Да
Адрес поставщика	Текстовый		1-15	Нет	Нет
Название поставки	Текстовый		1-15	Нет	Нет
Телефон поставщика	Числовой		1-15	Нет	Нет
Код товара	Числовой		1-15	Да	Да
Наименование	Текстовый	1-15		Нет	Нет
Цена (оптовая)	Денежный	1-15		Нет	Нет
Дата продажи	Дата/время	1-15		Нет	Нет

 

2. Нормализация исходной таблицы

 

 

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

Количество опускаемого  товара;

Дата опускаемого товара;

 

Код клиента;

ФИО клиента;

Адрес клиента;

 

 

Код товара;

Количество поставки;

Дата продажи;

ФИО;

Код поставщика;

Адрес поставщика

Название поставки;

Телефон поставщика;

Код товара;

Наименование;

Цена (оптовая);

Дата продажи;

 

 

 

Проверяем исходную таблицу  на соответствие критериям нормальных форм. 
- Таблица находится в 1НФ, если на пересечении любых строк и столбцов отсутствуют многозначные элементы, отсутствует дублирование.  
Считаем исходную таблицу соответствующей 1НФ строк и столбцов.

 

- Таблица находится в 2НФ, если она находится в 1НФ и в ней отсутствуют не ключевые поля, зависящие от части ключа. 
Так как ключевое поле составное, то необходимо проверить исходную таблицу на соответствие критериям 2НФ. 
Выделяем не ключевые поля связанные с частью ключа в отдельные таблицы. 
Код заказа

Таб.1 Заказ

Количество опускаемого  товара;

Дата опускаемого товара;

 

Код клиента

Таб.2 Клиент

ФИО клиента;

Адрес клиента;

 

Код товара

Таб.3 Накладная

Количество поставки;

Адрес;

Дата продажи;

ФИО;

 

Код поставщика

Таб.4 Поставщик

Адрес поставщика;

Название поставки;

Телефон поставщика;

 

Код товара

Таб.5 Прейскурант

Наименование;

Цена (оптовая);

Дата продажи;

 

 

 

 

- Таблица находится  в 3НФ, если она находится в  1НФ и 2НФ, и в ней отсутствуют  не ключевые поля, зависящие от других не ключевых полей.

Таблицы соответствуют критериям 3НФ так как все не ключевые поля не зависят друг от друга.

2.3. Построение ER-диаграммы

 

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

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

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

ER-модель является  одной из самых простых визуальных  моделей данных (графических нотаций). Она позволяет обозначить структуру «крупными мазками», в общих чертах. Это общее описание структуры называется ER-диаграммой или онтологией выбранной предметной области.

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 (рис.2 ER диаграмма)

 

2.4. Нормализация таблиц

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

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

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

Типы нормальных форм

Нормализация может  применяться к таблице, которая  представляет собой правильное отношение.

Первая нормальная форма (1НФ)