База данных по учёту видеокассет

БОЛЬШАЯ ЛЕНИНГРАДСКАЯ БИБЛИОТЕКА - РЕФЕРАТЫ - База данных по учёту видеокассет

База данных по учёту видеокассет

1. КОНЦЕПТУАЛЬНАЯ МОДЕЛЬ БАЗЫ ДАННЫХ "ОТДЕЛ СБЫТА ПРЕПРИЯТИЯ"

1.1 Основные понятия

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

Сущность - личности, факты, объекты реального мира, имеющие отношение к некоторой проблемной области. /1,2/

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

Экземпляр объекта - это один набор значений его элементов данных.

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

Связь - это функциональная зависимость между сущностями.

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

Концептуальная схема - это графическое представление данных на концептуальном уровне./2,3/

1.2 Описание предметной области

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

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

Определим первоначальные данные:

Договора - заключаются с поставщиками на определённый вид товара/7/.

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

Заказчики - в основном магазины, а также предприятия и организации, подающие заказ на приобретение того или иного товара.

Счета - ведутся на этапе заключения договором с поставщиками, а также с заказчиками.

Накладные - создаются на основании получения заказа о заказчика, для отгрузки.

Товар - присутствует на основании заявки и договора с поставщиком.

1.3 Каталог задач и запросов базы

Основываясь на описании предметной области (п.1.2), а также путём опроса экспертов и изучения документальных источников,/8,9,10/ определим круг запросов и задач, которые предполагается решать с использованием базы данных "Отдел Сбыта Преприятия".

Задачи:

· сведения о поставщиках и заказчиках;

· сведения о накладных, договорах и счетах;

· сведения о товарах;

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

· возможность при необходимости корректировать данные.

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

· по названию фирмы поставщика получение информации о всех заключенных договоров и счетов с этим поставщиком.

· по названию фирмы заказчика получение информации о всех полученных накладных от этого заказчика, также о всех оформленных счетах с этим заказчиком.

· по названию товара получение информации когда и в каких накладных и договорах участвовал этот товар.

· по номеру накладной или номеру договора получение полной информации о данном договоре или накладной.

1.4 Описание сущностей

Основываясь на описании предметной области (см.п.1.2) и определённых запросов и задач (см.п.1.3), выявляем сущности. Описание сущностей приведено в таблице (табл. 1.1).

Таблица 1.1

Описание сущностей

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

1.5 Описание атрибутов

На основании таблицы сущностей (см.табл.1.1) и каталога задач и запросов (см.п.1.3), а также путём опроса экспертов и изучения документальных источников,/11,12/ выделим все необходимые атрибуты.

В таблице (табл.1.2) приводится описание атрибутов:

Таблица 1.2

Описание атрибутов

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

1.6 Концептуальная модель

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

рис. 1.1

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

1.7 Описание связей

1. Многие ко многим. Один поставщик поставляет много товара и одно

наименование товара может поставлять много поставщиков.

2. Один ко многим. Один поставщик может заключить много договор на

поставку товара с оптовой базой и в одном договоре может участвовать

только один поставщик

3. Один ко многим. С одним поставщиком может заключаться много счетов и

определенный счет может быть только у одного поставщика.

4. Многие ко многим. В одной накладной много товара и одно наименование

товара может быть во многих накладных.

5. Один ко многим. В одной накладной может быть несколько счетов.

6. Один ко многим. Заказчик создает много накладных.

7. Многие ко многим. В одном договоре много товара и одно наименование товара может встречаться в нескольких договорах.

8. Многие ко многим. Один заказчик заказывает партию товара и одно наименование товара может быть заказано многими заказчиками.

9. Один ко многим. С одним заказчиком может заключаться много счетов и только каждый счет соответствует одному заказчику.

10. Один ко многим. Счет создается на партию товара.

11. Один к одному. Договор может содержать только один счет.

1.8 Итоги построения концептуальной модели

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

2. РЕЛЯЦИОННАЯ МОДЕЛЬ БАЗЫ ДАННЫХ

2.1 Выбор логической модели

Хранимые в базе данные имеют определённую логическую структуру, то есть модель. Различают следующие основные модели представления данных в базе данных:

- иерархическую

- сетевую

- реляционную

- объектно-ориентированную

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

В сетевой модели данные организуются в виде произвольного графа./4/ Достоинством этой модели является высокая скорость поиска и возможность адекватно представлять данные для решения множества задач в самых различных предметных областях. Высокая скорость поиска основывается на классическом способе реализации сетевой модели - на основе списков. Недостатком сетевой модели является жесткость структуры и высокая сложность ее организации.

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

Реляционная модель получила свое название от английского термина relation (отношение) и была предложена в 1970-х годах сотрудником фирмы IBM Эдгаром Коддом. Реляционная БД представляет собой совокупность таблиц, связанных отношениями. Разница между таблицей в привычном смысле и понятием отношения заключается в том, что в отношении нет порядка - это неупорядоченное множество записей. Порядок определяется не отношением, а конкретной выборкой из отношения. Связь между таблицами существует на логическом уровне и определяется предметной областью. Практически связь между таблицами устанавливается путем использования логически связанных данных в разных таблицах.

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

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

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

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

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

· представление данных в виде двухмерных таблиц проще, чем виде списков;

· большинство современных СУБД поддерживают реляционную модель данных, что облегчает нам выбор СУБД;

· реляционная модель проста, обладает гибкой структурой, удобна для реализации на компьютере.

Выбор объектно-реляционной модели решил бы проблемы с реализацией связей, однако возникли бы неоправданные проблемы с созданием математического представления и выбором СУБД./4/ Принимая во внимание всё вышесказанное, делаем выбор - реляционная модель данных.

2.2 Основные понятия

Реляционная модель данных - это представление данных в виде совокупности двумерных таблиц./4/

Свойства двумерных таблиц:

1) каждый элемент таблицы представляет собой один элемент данных, т.е. список не может быть значением;

2) все столбцы в таблице однородные, т.е. элементы столбца одной природы;

3) столбцам однозначно присвоены имена;

4) в таблице нет двух одинаковых строк;

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

Для математического описания реляционной модели нам понадобятся следующие понятия

Атомарные данные - это наименьшие единицы данных неразложимые с точки зрения модели.

Домен - это множество атомарных значений одного и того же типа.

Атрибут - это некоторое подмножество домена, имеющее уникальное имя.

Отношение на доменах D1, D2, ..Dn состоит из заголовка и тела.

R (A1, A2, ..An) D1D2D3

Заголовок состоит из такого фиксированного множества атрибутов

А1, A2, ..An , что существует отношение между атрибутами и их доменами.

Тело состоит из меняющихся во времени множества кортежей.

Кортеж состоит из значений каждого атрибута по одному значению на атрибут./6/

Таблица в реляционной теории соответствует отношению.

Строке соответствует кортеж.

Столбцу - атрибут.

Введем понятие ключа отношения.

Пусть А - множество атрибутов отношения

А = A1, A2,..An и пусть k - это подмножество А

k A

Возможным ключом отношения R является такое подмножество k, которое удовлетворяет следующему условию:

1) в произвольный момент времени никакие два различных картежа не имеют одного и того же значения для k

2) ни один из атрибутов не может быть исключен из k без нарушения первого условия.

2.3 Проектирование реляционной модели

Существует два основных метода проектирования реляционной модели:

1. метод декомпозиции (используется при количестве ключевых атрибутов не более 20);

2. на основе концептуальной модели.

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

Алгоритмы перехода от концептуальной модели к реляционной

1. Реализация частичной связи для одной сущности (рис.2.1).

Рис 2.1

В этом случае строится два отношения по одному на каждую сущность. Ключ сущности с необязательной связью добавляется в качестве атрибута в отношении для сущности с обязательной связью.

2. Реализация бинарной связи один-ко-многим (рис.2.2)

Рис.2.2

В этом случае строится 2 отношения, при этом ключ односвязной сущности добавляется в отношение для многосвязной сущности.

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

3. МАТЕМАТИЧЕСКОЕ ОПИСАНИЕ РЕЛЯЦИОННОЙ МОДЕЛИ

3.1 Описание доменов

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

Домен - это множество атомарных значений одного и того же типа.

Введем следующие понятия:

Length(x) - функция, возвращающая значение длины x;

String(x) - функция определения длины строки х;

Dom(x) - домен атрибута х;

По результатам описания сущностей (см.п.1.4) и созданной реляционной модели (см.п.2.3), можно сделать вывод о типичности отношений, что позволяет нам не описывать все отношения, а остановиться на конкретных примерах.

Текстовые атрибуты

К таким атрибутам можно отнести, например, атрибуты "Наименование заказчика" или "Адрес" и подобные им.

Dom (Отношение. Текстовый атрибут) = x ; где x - цепочка следующих друг за другом символов.

{String(x) = true, если Length(x) < С} or {String(x) = false, если Length(x) С},

где С-константа.

Её можно взять из таблицы атрибутов (см.табл.1.2). Приведём два примера.

1. Dom (Заказчики. Наименование заказчика) = String(x);

где x - цепочка следующих друг за другом символов.

{String(x) = true, если Length(x) < 20} or {String(x) = false, если Length(x) 20}

2. Dom (Поставщики. Адрес) = String(x); где x - цепочка следующих друг за другом символов.

{String(x) = true, если Length(x) < 20} or {String(x) = false, если Length(x) 20}

Это правило распространяется на все текстовые атрибуты. Отличие заключается в ограничение на длину строки. Конкретную цифру получаем из таблицы атрибутов в столбце "Метод контроля" (см.табл.1.2).

Числовые атрибуты

К этой категории относят атрибуты отношений, например "Код поставщика", "Цена", "Количество" и т.д. Домены числовых атрибутов записываются так:

Dom (Отношение. Числовой атрибут) = {с1..с2}, где с1 и с2 - соответственно начало и конец диапазона.

Например,

Dom (Заказчики. Код заказчика) = {0…10000}.

Диапазон значений {с1..с2} определяется для каждого атрибута описан в таблице атрибутов в столбце "Метод контроля" (см.табл.1.2).

Атрибуты Дата/Время

К этой категории относят атрибуты "Дата накладной", "Дата оформления счета", "Дата договора" и т.д.

Домены атрибутов Дата/Время записываются так:

Dom (Отношение. Атрибут Дата/Время) = {с1..с2},

где с1 и с2 - соответственно начало и конец диапазона.

Приведём примеры с атрибутами "Дата накладной", "Дата оформления счета"

Dom (Накладная. Дата накладной) = x

Dom (Счет. Дата оформления счета) = 01.01.1996 x 31.12.2025

Диапазон значений {с1..с2} определяется для каждого атрибута описан в таблице атрибутов в столбце "Метод контроля" (см.табл.1.2).

Денежный атрибут

К этой категории относят атрибуты "Сумма", "Цена за единицу", "НДС".

Домены Денежных атрибутов записываются так:

Dom(Отношение. Денежный атрибут) = {<C}

где С - константа

Приведем примеры с атрибутами "Сумма" и "Цена за единицу"

Dom (Накладная. Сумма) = {<0}

Dom (Договор. Цена за единицу) = {<0}

Значения для каждого атрибута взяты из Таблицы 1.2. столбца "Метод контроля"

3.2 Описание ключей

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

Пусть даны отношения R1 и R2. Пусть k1, - это первичный ключ отношения R1.

Если в отношении R2 присутствуют атрибуты k1, то для отношения R2, k1 - это внешний ключ

Рассмотрим математическое представление первичных ключей.

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

(x,y Отношение).[Код(x) = Код(y)] x = y

(x,y Отношение).[Номер(x) = Номер(y)] x = y.

Например,

(x,y Товар).[Код товара(x) = Код товара(y)] x = y

(x,y Накладная).[Номер накладной(x) = Номер накладной(y)] x =y

Остальные первичные ключи будут иметь такое же математическое представление.

3.3 Правила целостности

Различают целостность по сущностям и целостность по ссылкам. В целостности по сущностям не разрешается, чтобы какой-либо атрибут, участвующий в первичном ключе базового отношения принимал неопределенные значения./6/

Базовые отношения - это реально существующие модели отношения, которые соответствуют реальному объекту предметной области.

Целостность по ссылкам основана на понятии внешнего ключа.

Пусть даны отношения R1 и R2. Пусть k1, - это первичный ключ отношения R1.

Если в отношении R2 присутствуют атрибуты k1, то для отношения R2, k1 - это внешний ключ. Если базовое отношение R2 содержит внешний ключ k1, то каждое значение k1 в R2 должно быть либо равным какому-либо значению R1, либо полностью неопределенным.

Рассмотрим математическое представление целостности данных.

1. Целостность по сущностям имеет место, так как первичные ключи всех отношений не принимаю и не могут принимать неопределённые значения (см.табл.1.2).

2. Целостность по ссылкам достигнута при разработке реляционной модели (см.п.2.3). В качестве примера рассмотрим математическое представление целостности по ссылкам отношения Накладная (для отношений Договор и Счет аналогично (см.2.3)), отношение Заказчик(для отношения Поставщик аналогично).

Отношение Накладная

Одна и та же Накладная не может быть оформлена в разные даты.

(x,y Накладная).[Дата оформления(x) = Дата оформления(y)](Дата оформления(x) Дата оформления (y))

Одна и та же Накладная не может иметь разные номера.

(x,y Накладная).[Номер накладной(x) = Номер накладной(y)](Номер накладной (x) Номер накладной (y))

Одна и та же Накладная не может иметь разную сумму.

(x,y Накладная).[Сумма накладной(x) = Сумма накладной(y)](Сумма накладной (x) Сумма накладной (y))

Отношение Заказчик

Один и тот же Заказчик не может иметь разные наименования.

(x,y Заказчик).[Наименование заказчик(x) = Наименование заказчик (y)]

( Наименование заказчик (x) Наименование заказчик (y))

Отношение Счет

Один и тот же Счет не может иметь разные даты:

(x,y Счет).[Дата оформления(x) = Дата оформления(y)](Дата оформления(x) Дата оформления (y))

Один и тот же Счет не может иметь разную сумму.

(x,y Счет).[Сумма(x) = Сумма(y)](Сумма(x) Сумма(y))

Один и тот же Счет не может иметь разные номера.

(x,y Счет).[Номер счета(x) = Номер счета(y)](Номер счета (x) Номер счета (y))

3.4 Описание запросов

Для описания запросов необходимо рассмотреть специальную реляционную операцию реляционной алгебры селекция. Пусть С-любой допустимый оператор сравнения. Дано отношение R (А1, А2, А3, … , Аn). Селекцией отношения R по атрибутам Аj и Аk называется множество всех кортежей t таких, что аjtCаkt - истина. Вместо аkt может быть константа.

S (R, <условие>) - операция селекции.

Опишем определённые запросы (см.п.1.2).

Первый запрос реализуется через группу однотипных запросов. Например,S (Номер договора, Дата, Сумма, Номер счета, Дата, Сумма = x),

где x - это число, соответствующих коду поставщика.

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

Третий запрос реализуется через серию однотипных запросов. Например,

S (Номер договора, количество, цена за единицу, дата, номер накладной, количество, цена за единицу, дата =x),

где х - число соответствующие коду товара.

Четвертый запрос реализуется через серию однотипных запросов. Например,

S (Дата, количество, цена за единицу, наименование товара=х),

где х - число соответствующий номеру договора или счета.

4. ВЫБОР ТЕХНИЧЕСКИХ СРЕДСТВ С ТОЧКИ ЗРЕНИЯ БАЗ ДАННЫХ

Исходя из полученной реляционной (см.п.2.3) и её математического описания делаем выбор технических средств.

Выбираем платформу, на которой будет решаться задача. В соответствии с поставленной задачей, техническим заданием к курсовому проекту и учитывая экономичные требования, выбираем платформу IBM PC.

Выбор среды проектирования.

Так как поставленная задача должна быть решена в комплексе с передачей информации в другие системы, выбираем готовый программный продукт со встроенным языком программирования, поддержкой необходимого набора типов данных, работающую на платформе IBM PC, имеющую визуальные средства разработки и обеспечивающий защиту информации. Кроме того, выбор в качестве логической модели - реляционной модели заставляет нас искать СУБД с наиболее простой реализацией двухмерных таблиц и связей между ними. В данном случае выбираем систему Ассess 2000 c встроенным языком программирования SQL - Structured Query Language.

Описание типов данных системы Access 2000, которые будут использоваться в базе данных "Отдел Сбыта Преприятия" представлены в табл.4.1.

Таблица 4.1

Используемые типы данных Access 2000

Выбор ОС.

ОС выбираем исходя из выбранной платформы и программного продукта в котором мы решаем поставленную задачу проектирования. Учитываем также, чтобы ОС была современной, устойчиво работала и обеспечивала максимум удобства. В связи с выше перечисленными требованиями выбираем Windows XP.

Выбор материнской платы.

Выбор материнской платы включает в себя выбор центрального процессора, шины обмена и объема оперативной памяти. Быстро действие центрального процессора выбирается так, чтобы время ожидания расчетной задачи или обновления экрана по возможности не превышало трёх секунд. Таким образом, выбираем Celeron 400МГц. Материнскую плату выбираем так, чтобы она обеспечивала максимальную скорость обмена информацией. Объем оперативной памяти высчитывается по формуле:

V = Vос + Vут + Vср.пр. + Vдоп,

где V - объем оперативной памяти;

Vос - объем операционной системы;

Vут - объем оперативных утилит;

Vср.пр - объем среды проектирования;

Vдоп - дополнительный объем под решаемую задач.

V=128Мб+20Мб+12Мб+10Мб=170Мб.

Таким образом, для компьютера Celeron 400МГц выбираем объём ОП равный 256 Мб.

Выбор основных периферийных устройств.

Основные периферийные устройства это - устройства отображения информации (монитор), устройства хранения информации (винчестер), устройства обмена информацией (локальная сеть, дискета, оптические накопители).

Монитор должен отвечать требованиям безопасности, иметь экономичную стоимость и желательно высокую разрешающую способность. Исходя из требований высокой частоты обмена и по экономическим требованиям, выбираем 15ти дюймовый CRT-монитор.

Винчестер выбираем по трем параметрам: объем необходимый под ОС, объем памяти под программу, объем памяти под результаты работы.

Vв=Vос + Vпр + Vут,

где Vв - объем винчестера;

Vос - объем под ОС;

Vпр - объем памяти под программу Microsoft Access2000;

Vут - объем памяти под результаты работы. Определяется по табл.4.1.

Vв=1,5Гб+46Мб+20Мб=1622Мб.

Таким образом, для компьютера Celeron 400МГц, с ОП 256Мб винчестер на 20Гб, что устраивает для нашей задачи.

Устройства обмена.

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

Исходя из того, что необходимо вести архивы выбираем оптический пишущий накопитель, так как объём Vв больше объёма дискеты выбираем CD RW.

Дополнительное периферийное оборудование.

К дополнительным периферийным устройствам относят: устройство ввода информации, устройство получения твердых копий.

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

5. РЕАЛИЗАЦИЯ

На основе созданной концептуальной (см.п.1.7), реляционной модели (см.п.2.3) и её математического описания (см.п.3), используя выбранное оборудование (см.п.4), создаём в СУБД Microsoft Access таблицы и ключи.. На рис.5.1 представлены созданные таблицы.

рис 5.1

После создания таблиц, связываем их в единую схему данных используя средства Access 2000 в соответствие с описанием связей, см.п.1.6 и см.п.2.3. Полученная схема данных представлена на рис.5.2

В соответствии с каталогом задач и запросов (см. п. 1.3), были реализованы требуемые запросы (рис. 5.3).

рис 5.2

рис 5.3

Для организации диалога с пользователем была создана систем форм, представленная на рис.5.4. Интерфейс форм реализован с учётом специфики предметной области (см.п.1.2).

рис 5.4

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

Рис.5.6

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

6. РЕЗУЛЬТАТЫ РАБОТЫ БД " ОТДЕЛ СБЫТА ПРЕПРИЯТИЯ"

6.1 Приложение

В результате реализации реляционной модели на физическом уровне мы получаем систему форм, которая позволяет пользователю получать необходимые сведения согласно задачам и запросам (см.п.1.3). Рис.6.1 демонстрирует главную форму.

рис 6.1

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

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

рис 6.2

На главной форме также предусмотрена вкладка "Приложение" в которой пользователь может запустить необходимые для работы офисные приложения.

рис 6.3

Для быстроты и удобства работы с документами предусмотрена вкладка "Документы" представлена на рис 6.4

рис 6.4

рис 6.5

6.2 Запросы

Первый запрос

Описание запроса на языке SQL

SELECT Заказчики.[наименование заказчика], Заказчики.[ФИО руководителя], Заказчики.адрес, Заказчики.[телефо\факс], [Заказчики и накладные].[Номер накладной], [Заказчики и накладные].[Дата заключения], Накладные.Сумма

FROM Накладные INNER JOIN (Заказчики INNER JOIN [Заказчики и накладные] ON Заказчики.[код заказчика] = [Заказчики и накладные].[Код заказчика]) ON Накладные.[номер накладной] = [Заказчики и накладные].[Номер накладной]

WHERE (((Заказчики.[наименование заказчика])=[Заказчик]));

Представлении запроса в СУБД Microsoft Access 2000

рис 6.6

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

Третий запрос

Описание запроса на языке SQL

SELECT Товары.Наименование, Товары.[вес брутто (гр)], Товары.[вес нетто (гр)], Товары.[цена за еденицу], Товары.[вид упаковки], [Товары в договоре].[Номер договора], [Товары в договоре].Количество AS [Товары в договоре_Количество], [Товары в накладной].[Номер накладной], [Товары в накладной].Количество AS [Товары в накладной_Количество]

FROM (Товары INNER JOIN [Товары в накладной] ON Товары.[код товара] = [Товары в накладной].[Код товара]) INNER JOIN [Товары в договоре] ON Товары.[код товара] = [Товары в договоре].[Код товара]

WHERE (((Товары.Наименование)=[Товар]));

рис 6.7

Четвертый запрос реализуется так же как третий поэтому описывать его не будем.

6.3 Отчеты

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

Первый отчет

рис 6.8

Второй отчет

рис 6.9

ЗАКЛЮЧЕНИЕ

В результате проделанной работы по описанию предметной области мы разработали концептуальную модель, а на её основе реляционную модель по которой создали в СУБД Microsoft Access приложение. Разработанное приложение отвечает всем требованиям предметной области (см.п.1.2), а так же каталогу задач и запросов (см.п.1.3). Все поставленные задачи в техническом задании были выполнены полностью. База данных "Отдел Сбыта Преприятия" предназначена для частных фирм и крупных организаций занимающихся торгово - закупочной деятельностью.

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

СПИСОК ЛИТЕРАТУРЫ

Дж. Тельман, "Основы систем баз данных", Москва, Финансы и статистика, 1983г.

Дейт К. "Введение в системы баз данных", Москва, Hаука, 1980 г.

Горев А. Ахаян Р., Макашарипов С. "Эффективная работа с СУБД" СПб. Питер 1997-- 704 с.

Кириллов В.В. Структуризованный язык запросов (SQL). - СПб.: ИТМО, 1994. - 80 с.

Мейер М. Теория реляционных баз данных. М. Мир, 1987. - 608 с.

6. Ноздрева Р.Б., Цыгичко Л.И. Маркетинг: "Как побеждать на рынке" М.

ФиС 1991

7. Т.В. Тимошок "Самоучитель Microsoft Access 2003"

8. М.Ю. Горский "Организация и управление бизнесом", Москва 1998г.

9. Нефедов В.Н., Осипова В.А. Курс дискретной математики - М. 1992

10. Интернет - ресурс www.nix.ru

11. Интернет - ресурс www.lizard.ru

12. Интернет - ресурс www.library/buhg.ru