Создание базы данных 'Поставки' для фирмы 'Легион'

Курсовая работа

Дисциплина

Математические основы баз данных

Исполнитель

Нестеров В.П

 

Введение

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

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

управление затраты база данный

Общая часть

 

1. Аксиоматика функциональных зависимостей

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

На этапе инфологического моделирования была построена модель «сущность-связь», и с помощью алгоритма перехода к реляционной модели получена схема БД (Рис. 1.1), т.е. был начат этап логического проектирования. Для продолжения процесса проектирования необходимо проверить полученную схему БД на отсутствие избыточных функциональных зависимостей и при необходимости нормализовать схему БД.

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

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

Построение схемы БД может быть выполнено двумя путями:

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

• путем синтеза, то есть путем компоновки из заданных исходных элементарных зависимостей между объектами предметной области схемы БД.

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

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

 

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

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

Функциональные зависимости определяют не текущее состояние БД, а все возможные ее состояния. то есть они отражают те связи между атрибутами, которые присуши реальному объекту, моделируемые в БД.

Функциональная зависимость. Атрибут Y некоторого отношения функционально зависит от X (атрибуты могут быть составными), если в любой момент времени каждому значению X соответствует одно значение Y. Функциональная зависимость обозначается X →Y.

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

Полная функциональная зависимость.

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

Транзитивная функциональная зависимость. Пусть X, Y, Z - три атрибута некоторого отношения. При этом X → Y и Y → Z, но обратное соответствие отсутствует, т.е. Z -/-> Y и Y -/-> X. Тогда Z транзитивно зависит от X.

Многозначная зависимость. Пусть X. Y, Z - три атрибута отношения R. В отношении R существует многозначная зависимость R.X -» R.Y только в том случае, если множество значений Y. соответствующее паре значений X и Z. зависит только от X и не зависит от Z.

В общем случае необходимо проводить нормализацию к пятой нормальной форме (5НФ). На практике зачастую оказывается достаточным приведение к третьей нормальной форме (ЗНФ).

Первая нормальная форма (1НФ): отношение находится в 1НФ. если значения всех его атрибутов атомарны.

Иначе можно сказать, что в каждой позиции пересечения столбца и строки таблицы расположено в точности одно значение, а не набор значений. Отношения в 1НФ часто называются просто нормализованными отношениями.

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

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

Пример ненормализованного и нормализованного (в 1НФ) отношений приведен на рис. 1.2.

Рис. 1.2 Пример нормализации отношения

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

Если какой-либо атрибут зависит от части составного первичного ключа, то необходимо:

• создать новое отношение, атрибутами которого будут:

• часть составного ключа (первичный ключ нового отношения)

• атрибут, зависящий от нового ключа

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

То есть, если имеется отношение R(kl, k2, al, а2), находящееся в 1НФ, где kl, k2 - составной первичный ключ, a al и а2 - неключевые атрибуты отношения R, и имеются функциональные зависимости:

Kl, k2 → al (атрибут al функционально полно зависит от первичного ключа kl, k2),

kl →а2 (атрибут а2 зависит от части первичного ключа kl, т.е. имеется неполная функциональная зависимость)

Для приведения отношения R к 2НФ. это отношение декомпозируется на два отношения: Rl(kl, а2) и R2(k1,k2, al). Отношения R1 и R2 будут иметь связь один - ко многим по атрибуту kl.

Пример: Дано отношение Поставки(КодПоставщика, КодПродукта, ЕдиницаИзмерения). Поставщик может поставлять различные продукты, один и тот же продукт может поставляться разными поставщиками. Тогда первичным ключом отношения будут атрибуты КодПоставщика и КодПродукта. Значит, существует функциональная зависимость:

КодПоставшика, КодПродукта → ЕдиницаИзмерения

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

КодПродукта → ЕдиницаИзмерения

После исключения неполной функциональной зависимости получим отношения:

Поставки(КодПоставщика. КодПродукта) и Продукты(КодПродукта. ЕдиницаИзмерения)

При неполной функциональной зависимости возникают аномалии:

• включения (пока поставщиком не будет поставлен продукт, нельзя указать единицу измерения)

• удаления (исключение поставщика может привести к потере единицы измерения продукта)

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

Третья нормальная форма (ЗНФ): Отношение находится в ЗНФ. если оно находится во 2НФ и каждый неключевой атрибут нетранзитивно зависит от первичного ключа.

То есть, если имеется отношение R(kl, al, а2). находящееся в 2НФ. где kl - первичный ключ, a al и а2 - неключевые атрибуты отношения R, и имеются функциональные зависимости:

K1 → al

A1 → а2

тогда атрибут а 2 транзитивно зависит от k1.

Для приведения отношения R к ЗНФ. это отношение декомпозируется на два отношения: Rl(k1. A1) и R2(a1, а2). Отношения R1 и R2 будут иметь связь многие-к-одному по атрибуту al.

Пример: Дано отношение Группы(Группа. Специальность. Факультет) с первичным ключом Группа. Группа однозначно определяет специальность, а специальность однозначно определяет факультет. Т.е. существуют следующие функциональные зависимости:

Группа → Специальность (и наоборот, Специальность -/-> Группа)

Специальность → Факультет (Факультет -/-> Специальность)

После исключения транзитивной функциональной зависимости получим отношения:

Группы(Группа, Специальность) и Специальности(Специальность, Факультет)

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

То есть, если имеется отношение R(al. а2. аЗ. а4). находящееся в ЗНФ. где al. а2 - возможный ключ. а2. аЗ - возможный ключ, а а4 - неключевой атрибут отношения R. и имеются функциональные зависимости:

→a3

а3 → al,a2→a4

Для приведения отношения R к НФБК. это отношение декомпозируется на два отношения:

(a1, а3) и R2(al, а2, а4)

или Rl(a3. al) и R2(a2, a3, а4).

Пример: Дано отношение Экзамен(№ зачетки, № паспорта, Дисциплина, Дата, Оценка). Возможными ключами будут атрибуты: № зачетки, Дисциплина, Дата и № паспорта, Дисциплина, Дата. Имеются следующие функциональные зависимости:

№ зачетки. Дисциплина. Дата → Оценка

№ паспорта. Дисциплина. Дата → Оценка

№ зачетки → № паспорта

№ паспорта → № зачетки

После приведения отношения к НФБК могут быть получены отношения:

Студент(№ зачетки, № паспорта), Экзамен(№ зачетки. Дисциплина. Дата, Оценка)

или

Студент (№ паспорта, № зачетки), Экзамен(№ паспорта, Дисциплина, Дата, Оценка)

Четвертая нормальная форма (4НФ): Отношение находится в 4НФ, если оно находится в НФБК, и в нем отсутствуют многозначные зависимости, не являющиеся функциональными зависимостями.

или

Отношение R находится в 4НФ в том случае, если в случае существования многозначной зависимости А -» В все остальные атрибуты R функционально зависят от А.

То есть, если имеется отношение R(al. а2, аЗ), находящееся в НФБК и имеются функциональные зависимости:

• зависимость множества значений атрибута а2 от множества значений атрибута al (al -» а2)

♦ зависимость множества значений атрибута а3 от множества значений ключевого атрибута al (al -» аЗ)

Для приведения отношения R к 4НФ это отношение декомпозируется на два отношения: Rl(al,a2) и R2(al,a3).

Пример: Дано отношение Khиги (ISBN, Название, Автор, Область знаний). Книга имеет уникальный идентификатор ISBN, книга может быть написана коллективом авторов, книга может относиться к нескольким областям знаний (Таблица 2-6).

Таблица 2-6

ISBN	Название	Автор	Область знаний
5-123-12345-1	Информатика для экономистов	Иванов А.В.	Информатика
5-123-12345-1	Информатика для экономистов	Иванов А.В.	Экономика
5-123-12345-1	Информатика для экономистов	Петров СМ.	Информатика
5-123-12345-1	Информатика для экономистов	Петров СМ.	Экономика

Существуют следующие функциональные зависимости:

ISBN → Название

ISBN -» Автор

ISBN -» Область знаний

После приведения отношения к 4НФ будут получены отношения:

Kниги(ISBN, Название)

Авторы Kниг(ISBN, Автор)

ОбластиЗнанийКниг(ISBN, Область знаний)

Отношение R (X. Y.....Z) удовлетворяет зависимости соединения *(Х. Y.....Z) в том и только в том случае, когда R восстанавливается без потерь путем соединения своих проекций на X. Y..... Z, где X, Y.....Z - наборы атрибутов отношения R.

Пятая нормальная форма (5НФ): Отношение R находится в 5НФ в том и только в том случае, когда любая зависимость соединения в R следует из существования некоторого возможного ключа в R.

То есть, если имеется отношение R(kl, k2, k3). находящееся в 4НФ. где kl, к2, кЗ - составной первичный ключ, и имеется зависимость соединения:

*({kl.k2}. {kl.k3}. {к2.кЗ})

Для приведения отношения R к 5НФ, это отношение декомпозируется на три отношения: Rl(kl, k2), R2(kl, k 3) и R3(k2, k 3).

НФ редко используется на практике. Очень тяжело определить само наличие зависимостей «проекции-соединения», потому что утверждение о наличии такой зависимости делается для всех возможных состояний БД, а не только для текущего экземпляра отношения R.

2. Проектная часть

 

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

Согласно поставленному заданию можно представить, что экономическим объектом является торговое предприятие, специализирующееся на продаже компьютерной техники. В дальнейшем фирма будет зваться ООО «Легион».

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

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

Основные цели для достижения, которых создана эта база данных:

Ø Обеспечение более быстрого и удобного поиска работниками необходимой информации;

Ø  Точный учет договоров на предприятии;

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

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

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

В данной предметной области можно выделить следующие укрупненные спецификации:

Ø Сведения о каждом поставщике;

Ø  Сведения об изделии;

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

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

Сведения о поставщике:

·        Наименование поставщика

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

Сведения об изделии:

· Код изделия

·        Наименование изделия

·        Цена

Сведения о договоре:

· № п/п

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

·        Код изделия

·        Количество

·        Стоимость

Организационная структура ООО «Легион»

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

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

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

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

Бухгалтерия осуществляет организацию бухгалтерского учета хозяйственно-финансовой деятельности.

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

Основные задачи, которые решает эта база данных:

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

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

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

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

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

Разрабатываемая база данных автоматизирует данный документооборот.

2.2 Инфологическое моделирование

Связью между двумя сущностями является сущность «договор».

                                     Договор

m                                                                               n

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

Таблица 2.1 Договор

№ п/п	Наименование	Символическое обозначение	Сущность
1	Договор	DOG	Название документа
2	№ п/п	NPP	Реквизит
3	Поставщик	POST	Включенное отношение
4	Изделие	IZD	Включенное отношение

(NPP, KPOST, KIZD, KOL, STOIM) - Ключевое поле

Таблица 2. Получатель.

POST (KPOST, NPOST, ADRES)

KPOST (Код поставщика) - Ключевое поле

Таблица 3. Груз.

IZD (KIZD, NIZD, CENA)

KIZD (Код изделия) - Ключевое поле

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

 

2.3 Разработка ER-модели предметной области

Моделирование данных - это первый шаг на пути проектирования БД, это переход от объектов реального мира к компьютерной модели БД.

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

Структура записей таблиц

«Поставщик»

№п/п	Идентификатор		Тип данных			Размер данных
1 2 3	KOD POSTAVSHIKA NAIMENOVANIE POL ADRES POSTAVSHIKA		INT CHAR CHAR
«Изделие»
№п/п		Идентификатор		Тип данных	Размер данных
1 2 3		KOD IZDELIYA NAIMENOVANIE IZDELIYA CENA		INT CHAR INT	5 50 16

«Договор»

№п/п	Идентификатор	Тип данных	Размер данных
1 2 3 4 5	NOMER PODPYNKTA KOD POSTAVSHIKA KOD IZDELIYA KOLICHESTVO STOIMOST	INT INT INT INT INT	5 5 5 16 16

Процесс проектирования БД является итеративным, а не линейным или последовательным. Термин «итеративный» означает «повторяющийся».

Схема данных представлена на следующем рисунке

 

2.4 Проектирование базы данных реляционного типа

Нормализация отношений

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

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

Спроектированная база данных содержит три таблицы: Договор(DOG), Поставщик(POST), Изделие(IZD).Все ограничения целостности данных при подготовке программных средств для загрузки и корректировки базы данных были соблюдены. Также предусмотрена защита базы данных от несанкционированного доступа и разрушения.

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

В первой нормальной форме все атрибуты сущности атомарны, т.е. неделимы. Это условие выполнено.

Ненормализованное отношение имеет вид:

(NPP#, POST (KPOST#, NPOST, ADRES), IZD (KIZD#, NIZD, CENA), KOL, STOIM)

Результат нормализации:

(NPP#, KPOST#, KIZD#, KOL, STOIM)(KPOST #, NPOST, ADRES)(KIZD#, NIZD, CENA)

Нормализация отношений

Шаг 0. Иерархическая структура может рассматриваться как ненормализованное отношение DOG0 и еще на двух доменах элементы, которых не является атомарным: POST0, IZD0.

Ненормализованное отношение имеет вид:

DOG0 (NPP#, POST0 (KPOST#, NPOST, ADRES), IZD0 (KIZD#, NIZD, CENA), KOL, STOIM)

Полное множество всех нормализованных и ненормализованных отношений имеет вид:

(NPP#, KPOST0, KIZD0, KOL, STOIM)(KPOST#, NPOST, ADRES)(KIZD#, NIZD, CENA)

Шаг 1. Приведем этот набор совокупности отношений к первой нормальной форме.

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

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

Получим совокупность отношений в первой нормальной форме:

(NPP#, KPOST#, KIZD#, KOL, STOIM)(KPOST#, NPOST, ADRES)(KIZD#, NIZD, CENA)

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

Отношение находится в 3-й нормальной форме, т.к. оно находится во 2 ой нормальной форме и не имеет транзитивных зависимостей.

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

Запросы

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

1. SELECT Изделие.[Код изделия], Изделие.[Наименование изделия], Изделие.ЦенаИзделие(((Изделие.[Код изделия])=[Введите код изделия]));

Такой запрос называется запросом с параметром. Параметром является код изделия. Значение параметра вводится в диалоговом окне.

После нажатия кнопки «OK», получаем информацию о конкретном изделии.

Еще один пример запроса с параметром:

. SELECT Поставщик.[Код поставщика], Поставщик.[Наименование поставщика], Поставщик.[Адрес поставщика]Поставщик(((Поставщик.[Код поставщика])=[Введите код поставщика]));

После ввода кода поставщика выводятся сведения о данном поставщике.

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

 

2.5 Создание сетевой модели

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

На связи в сетевой модели накладываются два ограничения: они должны быть бинарными и находиться в соотношении 1:М. Если хотя бы одно из этих ограничений не выполняется, то делают соответствующие преобразования и добиваются выполнения этих ограничений. В данной базе данных эти ограничения выполняются, и преобразования не требуются.

Графическое представление предметной области в сетевой модели -

Диаграмма Бахмана - выглядит следующим образом:

1, P2 - сингулярные наборы, т.е. владельцем является одна запись «система».

S1, S2 - физические наборы данных, которые будут содержать той или иной тип записи.

C - означает то, что записи вычисляемые, поэтому зная значение ключа KPOST или KIZD можно найти соответствующую запись по значению ключа.

V - записи типа «договор» можно получить только через набор S1 или S2.

POSTAVKI {‘POSTAVKI.DAT’ CONTAINS SYSTEM, POST, IZD, DOG;‘POSTAVKI.KEY’ CONTAINS KPOST, KIZD, NPP;POST

{int KPOST [5];NPOST [50];ADRES [50];

}IZD

{int KIZD [5];NIZD [50];CENA [16];

{int NPP [5];KPOST [5];KIZD [5];KOL [16];STOIM [16];

}P1

{LAST;SYSTEM;POST;

}P2

{LAST;SYSTEM;IZD;

}S1

{LAST;POST;DOG;

}S2

{LAST; IZD;

MEMBER DOG;

}

}

2.6 Запросы к проектируемой базе данных

1.      Для данного поставщика получить сведения о договорах:

D_OPEN();(KPOST);_KEYFIND(KPOST);_SETOR(S2);(D_FINDFM(S2); DB_STATUS==S_OKAY; D_FINDNM(S2));

{ D_RECREAD(&DOG);

<ОБРАБОТКА> }_CLOSE();

2.      Для данного изделия получить сведения о договорах:

D_OPEN();(KIZD);_KEYFIND(KIZD);_SETOR(S1);(D_FINDFM(S1); DB_STATUS==S_OKAY; D_FINDNM(S1));

{ D_RECREAD(&DOG);

<ОБРАБОТКА> }_CLOSE();

 

2.7 Реализация базы данных

Семантическая модель данных (SDM) позволяет моделировать как данные, так и их отношения в единой структуре, называемой объектом. Поскольку основной структурой модели является объект, модель SDM получила название объектно-ориентированной модели базы данных (object oriented database model, OODM). В свою очередь OODM стала основой создания объектно-ориентированной модели БД (OODMB), управление которой осуществляется с помощью системы управления объектно-ориентированной базой данных

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

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

o  набор данных не является больше пассивным;

o   данные и процедуры, будучи связанные друг с другом, образуют объект;

o   объект может воздействовать на самого себя.

Рис.1.Обмен сообщениями между объектами

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

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

Рис.2. Представление класса POST

Рис.3. Пример представления класса IZD

Определим класс с именем IZD для хранения объектов-изделий. Все объекты класса IZD используют одинаковую структуру (атрибуты) и отвечают на одинаковые сообщения (с помощью методов). Каждый экземпляр класса представляет собой объект с уникальным OID и каждый объект ‘знает’, какому классу он принадлежит.

Рис.4. Иерархия классов

 должна обладать следующими свойствами:

·  поддерживать представление сложных объектов;

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

·        поддерживать инкапсуляцию, т.е. представление данных и реализация методов должны быть скрыты от внешних объектов;

·        поддерживать наследование, т.е. любой объект может наследовать свойства (данные и методы) других объектов;

·        обеспечивать идентификацию объекта (OID).

Кроме того, можно кратко сформулировать следующие основные положения:

·  OOMD сущности реального мира моделируются объектами;

·        каждый объект состоит из атрибутов и набора методов;

·        каждый атрибут может ссылаться на другой объект или множество объектов;

·        атрибуты и реализации методов скрыты (инкапсулированы) от других объектов;

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

·        схожие объекты группируются в класс, который содержит описание данных (атрибуты или переменные экземпляров) и реализации методов;

·        класс описывает тип объекта;

·        классы организованы в иерархию классов;

·        каждый объект класса наследует все свойства своего суперкласса в иерархии классов.

Пространство объектов (object space) или схема объектов (object schema) используется для представления состояния объекта в данный момент времени.

Состояние объекта для экземпляра класса DOG, использующего ATD

 

2.8 Проектирование основных процедур созданной базы данных

Ввод, просмотр и изменение данных производиться с помощью экранных форм. При запуске базы данных «Поставки» автоматически запускается форма “Главная”, которая позволяет перейти к любой таблице, форме или отчету.

Форма “Главная форма”

Форма “Изделие”

Форма “Поставщик”

Форма “Договор”

 

2.9 Руководство пользователя

 

2.9.1 Администрирование БД

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

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

Деятельность администратора должна охватывать следующие направления:

1.      Управление доступом пользователей. Эта функция предназначена для ограничения доступа к БД и должна включать следующие процедуры:

а)  определение каждого пользователя в БД. Это достигается на двух уровнях: на уровне ОС и на уровне СУБД. На уровне ОС администратор может потребовать создания регистрационного имени пользователя (logon user ID), которое разрешает пользователю регистрироваться в системе. На уровне СУБД администратор может либо создать другое регистрационное имя пользователя, либо использовать то же самое имя;

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

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

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

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

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

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

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

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

2.9.2 Шифрование и дешифрование базы данных

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

Чтобы приступить к шифрованию базы данных Microsoft Access, необходимо быть либо ее владельцем, либо, если база данных защищена, членом группы «Admins» в файле рабочей группы, который содержит учетные записи, используемые для защиты базы данных. Кроме того, базу данных надо открыть в монопольном режиме, для чего необходимо иметь разрешения «открытие/запуск» и «монопольный доступ».

У шифрования базы данных имеется два негативных побочных эффекта:

§ Снижается её быстродействие процентов на 10-15;

§  Зашифрованную базу данных нельзя сжимать такими программами, как PKZip, LHA, Stacker и DriveSpace (сжимать можно, только в этом нет смысла - её размер уменьшится незначительно).

Дешифрование базы данных - это операция, обратная шифрованию.

 

2.9.3 Защита базы данных

Защита безопасности базы данных заключается в том, что право выполнять некоторые действия дается только определенным пользователям и в определенное время. Эта цель труднодостижима, и чтобы хоть в какой-то степени к ней приблизится, команда разработчиков должна на стадии определения требований к проекту установить для всех пользователей права и обязанности по обработке (processing rights and responsibilities). Реализация этих требований безопасности может обеспечиваться соответствующими возможностями СУБД, а при их недостаточности - логикой прикладных программ.

Существуют различные приемы управления доступом к базе данных Microsoft Access и ее объектам. Эти приемы кратко описаны ниже в порядке усиления безопасности.

Отображение и скрытие объектов в окне базы данных

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

Использование параметров запуска

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

Использование пароля

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

Чтобы установить пароль, необходимо открыть базу данных с монопольным доступом и выбрать пункт меню Сервис - Защита - Задать пароль базы данных.

Использование защиты на уровне пользователя

Наиболее гибкий и распространенный способ защиты базы данных называют защитой на уровне пользователя.

Двумя основными причинами использования данного способа являются:

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

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

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

 

2.9.4 Организация работы БД в корпоративной локальной сети

Внутри фирмы «Легион» существует локальная вычислительная сеть. Данная база данных используется на различных рабочих местах в бухгалтерии, а также в отделе материально-технического снабжения. База данных расположена на отдельном сервере.

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

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

Клиент-сервер - программная архитектура. Экранная форма или клиент и база данных (сервер) находятся на разных компьютерах. Клиент и сервер соединены ЛВС.

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

Программа производит манипуляции с БД, хранящейся на сервере, в соответствии с запросом, формирует результат и передаёт его клиенту.

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

Заключение

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

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

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

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