ПОСТАНОВКА ЗАДАЧИ

1.1 Формулировка задачи

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

1.2 Исходные данные

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

1.3 Результат

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

1.4 Требования к ПП

Полученная база данных «Кондитерские фабрики Украины» должна:

-обеспечивать хранение и предоставление по требованию данных;

-обеспечивать возможность добавления, изменение и удаления данных;

-обеспечивать возможность обработки данных: поиска, подбора данных по запросам, систематизацию информации и фильтрацию данных по определенному условию;

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

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

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

контролировать целостность, непротиворечивость, сохранность и достоверность информации;

-предусматривать архивацию и восстановление данных.

ОПИСАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ

2.1 Предметная область «Кондитерские фабрики»

Почти в каждом городе Украины существует либо кондитерская фабрика, либо филиал этой фабрики. Фабрика имеет название, которое уникально. Имеет также дату введения в строй, т. е. дату открытия фабрики. В зависимости от владельца, фабрики разделяются по типу: открытое акционерное общество (ОАО), закрытое акционерное общество (ЗАО), госпредприятие (ГП), частный предприниматель (ЧП).

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

Чтобы точно фиксировать поставки продуктов магазин (потребитель) имеет № накладной (уникален), количество поступившего товара, цену за единицу товара, дату поставки, ФИО директора.

Это позволяет систематизировать работу фабрик: фиксировать дату выпуска и дату сбыта продукции, ее тип, название; легко узнать данные магазина (потребителя), которой произвел импорт товара. Также с помощью этих данных можно быстро и удобно использовать информацию о поставках.

2.2 Схема объект – отношение

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

«Фабрика» имеет свойства – названии фабрики, дате введения в строй;

«Тип предприятия» имеет свойства – название типов предприятий;

«Город» имеет свойства – название городов;

«Продукция» имеет свойства – тип продукции (карамель, ирис, шоколад и т. п.), название изделия;

«Магазин» имеет свойства –№ магазина, названии магазина, ФИО директора;

Для данной предметной области ниже изобразим на рисунке 2.1схему объект – отношение

Рисунок 2.1 – Схема объект-отношение

Объекты «Тип» - «Фабрика» и «Тип» - «Потребитель» связаны отношением 1: ∞, так как многие фабрики и потребители (магазины) могут иметь один тип. Объекты «Город» - «Фабрика» имеют отношение 1: ∞, так как несколько фабрик могут находиться в одном городе. Объекты «Фабрика» - «Продукция» имеют отношение ∞: ∞, так как многие фабрики могут выпускать разную продукцию. Объекты «Продукция» - «Потребитель» имеют тип связи ∞: ∞, так как многая продукция может поставляться в разные магазины.

2.3 Обоснование выбора модели данных

БД может быть основана на одной модели или на совокупности нескольких моделей. Любую модель данных можно рассматривать как объект, который характеризуется своими свойствами (параметрами), и над ней, как над объектом, можно производить какие-либо действия.

Любая модель должна обеспечивать такие операции над БД:

- поиск указанного элемента базы;

- переход от одних данных к другим;

- движение по записям;

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

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

Узел – информационная модель элемента, находящегося на данном уровне иерархии.

Свойства иерархической модели данных:

- несколько узлов низшего уровня связано только с одним узлом высшего уровня;

- иерархическое дерево имеет только одну вершину (корень), не подчиненную никакой другой вершине;

- каждый узел имеет свое имя (идентификатор);

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

Фабрика

Продукция

Потребитель

Рисунок 2.3.1 – Иерархическая модель данных

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

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

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

Основной структурой в сетевых моделях данных является «сеть». При таком представлении существует несколько входов в сеть – неоднозначность доступа к данным.

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

Рисунок 2.3.2 – Сетевая модель данных

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

К достоинствам СМД относят:

- возможность создания произвольных связей (например растения произрастают на закрепительном участке и закрепительный участок имеет растения);

- эффективную реализацию с точки зрения затрат времени и памяти.

Недостатки такие:

- сложность и жесткость схемы;

- сложность в установлении и проверке целостности данных.

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

«Реляционный» (от латинского relatio – отношение) указывает, прежде всего, на то, что такая модель хранения данных построена на взаимоотношении составляющих ее частей.

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

Реляционная модель данных имеет следующие свойства:

- каждый элемент таблицы – один элемент данных;

- каждое поле имеет уникальное имя;

- все поля в таблице являются однородными, т.е. имеют один тип;

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

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

Одним из достоинств РМД это простота и удобство физической реализации, а недостатки – сложность в описании иерархических и сетевых связей, стандартных средств идентификации отдельных записей. На рисунке 2.3.3 изображена РМД.

Реляционная модель строилась следующим образом: в таблице, где связь 1-∞ связь ставится от первичного ключа к альтернативному. Если связь ∞-∞, то создается дополнительная таблица, где связь будет 1-∞ и ∞-1.

Фабрика Город Тип

#КФ

Название фабрики

Дата веления в строй

КТ#

КГ#

#КГ

Название

#КТ

Название типа

Продукция Тип продукции Выпуск

#КП

Название продукции

КТ#

#КТ

Название типа продукции

#КВ

Количество

Дата выпуска

КФ#

КП#

Потребитель Поставка

#№ Магазина

Название

ФИО директора

КТ#

Номер накладной

Количество товара

Цена за ед. товара

Дата поставки

№ Магазина

КП#

КВ#

Рисунок 2.3.3 – Реляционная модель данных

2.4 Обоснование выбора СУБД

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

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

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

Для решения многих задач достаточно использовать такие объекты Access, как формы, запросы, отчеты. Эти объекты легко создаются в диалоговом режиме. Для реализации целостного приложения пользователя в некоторой предметной области возникает необходимость в создании макросов и модуле на языке Visual Basic for Applications (VBA).

3 ОПИСАНИЕ КОНЦЕПТУАЛЬНОЙ МОДЕЛИ

3.1 Концептуальная модель данных «Кондитерские фабрики Ураины» представлена на рисунке 3.1.1:

Рисунок 3.1.1 - Концептуальная модель базы данных “Кондитерские фабрики Украины ”

Как видно из рисунка 3.1.1, концептуальная модель данных разрабатываемого проекта состоит из 8 таблиц – «Поставка», «Продукция», «Выпуск», «Фабрика», «Потребитель», «Города», «Тип предприятия», «Тип продукции». Таблицы «Города», «Тип предприятия» являются справочниками для таблицы «Фабрика». Она связана с ними с помощью внешних ключей «Код города» и «Код предприятия». Таблица «Тип предприятия» также является справочником для таблицы «Потребитель». «Продукция» - справочник для «Выпуск», «Поставка». «Фабрика» и «Выпуск» связаны отношением 1-Ґ и имеют объединение всех записей из «Фабрика» и только тех записей из «Выпуск», в которых связанные поля совпадают. Это предназначено для того, чтобы каждая фабрика была связана с выпуском продукции и, соответственно, с самой продукцией, так как «Продукция» и «Выпуск» имеют подобные параметры объединения.

3.1.2 Таблица с данными

№	Название фабрики	Дата введения в строй	Тип фабрики	Название города	Название продукции	Тип продукции	Количество	Дата выпуска	ФИО директора	Название магазина	Тип Агазина	Номер накладной	Количество товара	Дата поставки	Цена за е т	№ маг
N2	С 20	N6	C 10	C 20	C 20	C 15	N6	N6	C 20	C 20	C 10	N3	N6	N6	N6	N3
1	Рошен	10. 05.91	ЗАО	Киев	Свиточ	шоколад	1000	10.09.05	Иванов С.В	Свитанок	ЧП	135	500	10.09.05	1.1	22
2	Киев Конти	03.05.85	ОАО	Донецк	Буратино	печенье	500	05.06.05	Сидоров К.М	Легенда	Гп	34	300	05.12.05	0.5	23
3	Свиточ	10.11.45	ОАО	Луганск	Мальвина	конфеты	100	02.02.05	Батурин С.В.	РИФ	ЧП	112	1341	14.01.05	12.2	24
4	Свиточ	10.11.45	ОАО	Донецк	Гуливер	конфеты	200	02.02.05	Батурин С.В.	У Алены	ЧП	233	12313	14.04.05	12.5	25
5	Рошен	10. 05.91	ЗАО	Харьков	Чипалино	мармелад	1000	10.09.05	Петров С.В	Рассвет	ЧП	132	200	10.09.05	1.1	26
6	Киев Конти	03.05.85	ОАО	Донецк	Мечта	печенье	500	15.06.05	Шкиря К.М	Детство	Гп	343	100	23.02.05	8.5	27
7	Свиточ	10.11.45	ОАО	Горловка	Мальвина	конфеты	200	03.02.05	Кищкань В.В	Марина	ЧП	121	1341	14.01.05	4.2	28
8	Свиточ	10.11.45	ОАО	Донецк	Гуливер	конфеты	200	02.02.02	Батурин С.В.	У Алены	ЧП	233	123	02.04.05	2.5	25
9	АВК	12. 02.98	ЗАО	Донецк	Сказка	шоколад	900	10.04.05	Кава С.В	Ранок	ЧП	235	200	12.04.05	1.1	30
10	Стирол	13.05.85	ОАО	Горловка	Мечта	конфеты	300	01.06.05	Махмед К.М	У Ашота	ЧП	342	100	05.06.05	3.5	31
11	Улыбка	11. 05.91	ЗАО	Харьков	милениум	шоколад	450	20.09.05	Зуйко С.В	Свитанок	ЧП	131	500	10.09.05	21.1	22
12	Киев Конти	03.05.85	ОАО	Донецк	Рачки	конфеты	500	15.06.05	Сидоров К.М	Легенда	Гп	44	300	25.06.05	12.5	23
13	Свиточ	10.11.45	ОАО	Луганск	Забава	печенье	230	02.11.05	Батурин С.В.	РИФ	ЧП	112	1341	14.11.05	12.2	24
14	Свиточ	10.11.45	ОАО	Донецк	Крекер	печенье	200	02.04.05	Батурин С.В.	У Алены	ЧП	673	1231	14.04.05	12.5	25
15	АВК	12. 02.98	ЗАО	Харьков	Умка	конфеты	345	10.05.05	Зубов В. В.	Шанс	ЧП	348	4545	01.01.05	12.4	36

3.3 Функциональные зависимости

Рисунок 3.3.1 – Схема функциональных зависимостей в 1 нормальной форме

Рисунок 3.3.2 – Схема функциональных зависимостей во 2 нормальной форме

Рисунок 3.3.3 – Схема функциональных зависимостей в 3 нормальной форме

Все отношения в базе данных находятся в первой нормальной форме, т.к. все значения полей – неделимы (в каждом из полей таблиц БД нет повторений).

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

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

4 ГРУПЫ ПОЛЬЗОВАТЕЛЕЙ И УРОВНИ ДОСТУПА

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

Установка пароля при открытии базы данных – самый распространенный способ защиты. После установки пароля, при открытии базы данных появляется диалоговое окно, предлагающее пользователю ввести пароль. Открыть базу данных смогут лишь те пользователи, которые введут правильный пароль. Этот способ достаточно надежен (MS Access шифрует пароль таким образом, что к нему нет прямого доступа при чтении файла базы данных), но он применяется только при открытии базы данных. После открытия базы данных все объекты становятся доступными для пользователя (пока не определена защита на уровне пользователей). Для базы данных, которой совместно пользуется небольшая группа пользователей или на автономном компьютере, установка пароля обычно оказывается достаточной.

Наиболее гибким и распространенным способом защиты базы данных является защита данных на уровне пользователей. Этот способ защиты подобен способам, используемым в большинстве сетевых систем. От пользователей требуется идентифицировать себя и ввести пароль, когда они запускают MS Access. Внутри файла рабочей группы они идентифицируются как члены группы. MS Access по умолчанию создает две группы: администраторы (группа «Admins») и пользователи (группа «Users»). Допускается также определение других групп. Группам и пользователям предоставляются разрешения на доступ, ограничивающие возможность доступа к каждому объекту базы данных.

Следует отметить три главных преимущества защиты на уровне пользователей:

программа защищается как интеллектуальная собственность;

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

защищаются конфиденциальные сведения в базе данных.

СУБД «Кондитерские фабрики Украины» работают различные пользователи. В зависимости от конкретного пользователя определяются уровни доступа для каждого. Выбор пользователя обеспечивается следующим образом: при запуске БД «Кондитерские фабрики Украины» открывается форма «Пуск» (рисунок 4.1) с кнопками 3 – х различных уровней доступа к данным базы: «Гость», «Пользователь», «Администратор».

Рисунок 4.1 – Форма «Пуск»

При нажатии на каждую из этих кнопок появляется окошко с запросом пароля (рисунок 4.2). Для каждого уровня доступа свой пароль. При вводе не правильного пароля – окно об ошибке ввода.

Рисунок 4.2 – Окно с запросом пароля

5 ФУНКЦИОНИРОВАНИЕ СИСТЕМЫ БАЗ ДАННЫХ

5.1 Схема функционирования форм:

Рисунок 5.1.1 – Схема функционирования форм

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

5.2 Описание программных модулей

Первый модуль «add» контролирует уникальность значения элемента в символьном поле. В таблице "Города", перед добавлением названия нового города, проверяет, не встречается ли она ранее в списке городов.

Sub ADD()

Dim str, tmp1, tmp2 As String

Dim c, i, t, f As Integer

str = ""

Do While str = ""

str = InputBox("Введите название города", "Добавление города")

If str = "" Then

t = MsgBox("Строка не может быть пустой")

End If

Loop

DoCmd.OpenForm "Города", acNormal

c = [Forms]![Город]![Название города].ListCount

Set ctllist = [Forms]![Город]![Название]

Dim varitem

For i = 0 To 100

varitem = ctllist.Column(1, i)

If UCase(Trim(varitem)) = UCase(Trim(str)) Then

f = 1

t = MsgBox("Такой город уже есть добавление невозможно")

Exit Sub

End If

Next i

If f = 0 Then

t = MsgBox("Вы действительно хотите добавить город?", vbYesNo)

If t = 6 Then

Dim sql As String

sql = "Insert into Город([Название]) values (" & str & ")"

DoCmd.RunSQL sql

ctllist.Requery

z = MsgBox("Добавлен новый город" & str, vbInformation)

ElseIf t = 7 Then

t = MsgBox("Прервано пользователем", vbOKOnly + vbCritical, "Error")

End If

End If

DoCmd.Close

End Sub

Для управления параметрами элементов форм в зависимости от уровня пользователя создан модуль «User». Он контролирует доступ к данным для обеспечения безопасности информации.

Public User As String