Разработка базы данных и интерфейса информационно-справочной системы Производство

Содержание
Введение 3
1 Постановка задачи 5
2 Инфологическое проектирование базы данных 8
3 Датологическое проектирование базы данных 10
3.1 Первая нормальная форма 10
3.2 Вторая нормальная форма 11
3.3 Третья нормальная форма 11
4 Физическое проектирование базы данных 13
4.1 Проектирование таблиц 13
4.2 Обеспечение целостности данных 16
4.3 Проектирование форм 16
4.4 Проектирование запросов 19
4.4.1 Простой запрос 19
4.4.2 Многотабличный запрос 20
4.4.3 Запросы, использующие группировку и вычисления с условием и без условия 21
4.5 Создание отчета 25
4.6 Проектирование Главной формы 28
4.7 Проектирование макроса 28
4.8 Защита базы данных 29
Заключение 31
Список использованных источников 32
Приложение 1 33
Приложение 2 34
Приложение 3 39
Приложение 4 42

 

Введение
В данном курсовом проекте предлагается разработать базу данных и интерфейс информационно-справочной системы Производство.
Системы такого рода можно создавать с помощью различных средств программирования. Для этого можно использовать оболочки программирования Delphi, Borland C++ Builder, Microsoft Visual Basic и другие. Собственных систем управления базами данных эти оболочки не имеют, однако имеют большой набор компонент для связи со стандартными СУБД, такими как Interbase, MS SQL, Oracle, MySQL и др. В этом случае сама база данных находится в отдельно отведенном месте и управляется с помощью СУБД, а интерфейс пишется средствами выбранной оболочки.
Однако такой подход к проектированию несложных систем применяется редко. Для создания таких баз данных обычно используют либо Microsorf Visual FoxPRO, либо Microsoft Access, входящий в состав пакета Microsoft Office. 
Одной из основных причин такой популярности Access заключается в том, что, является по сути настольной СУБД, это приложение вобрало в себя многие возможности систем управления реляционными базами данных архитектуры клиент-сервер, называемой также SQL базой данных. Несмотря на то, что, Access включают в себя сложные функции и может послужить прекрасным инструментом для профессионального разработчика приложений БД, его использование не должно вызвать проблем и у непрофессиональной пользователей и даже тех, кто раньше не работал с СУБД. Кнопки на панелях инструментов дублируют основные команды меню, расширенный набор мастеров и настроек управляет практически всеми параметрами создания и изменения объектов БД (таблиц, форм, отчетов, запросов и т.д.). С помощью ACCESS можно создавать многопользовательских приложений, в которых файлы базы данных являются разделяемыми ресурсами в локальной сети. В ACCESS реализованного доступа к объектам базы данных. Microsoft Access для хранения объектов БД имеет собственную уникальную структуру для хранения всех связанных таблиц, форм, отчетов, запросов и макросов в одном файле. Также имеет возможность импорта и экспорта данных во многие широко распространенные форматы БД, электронных таблиц и текстовых файлов. ACCESS позволяет связывать БД с внешними таблицами в форматах dBase, FoxPro, Paradox и работать с ними в исходном формате. Также Access можно использовать в качестве клиентской части архитектуры клиент-сервер, что обеспечивает применение Microsoft Access не только в качестве профессиональной системы управления базы данных, но и как мощное инструментальное средство для создания приложений клиент-сервер.
Microsoft Access поддерживает реляционную модель баз данных и работает с отношениями, представляющими собой двумерные плоские таблицы. Для работы с данными Access использует запросы QBE или SQL, с помощью которых мы можем получить любые имеющиеся в базе данные в любом виде. Однако, для этого таблицы должны быть нормализованы и находиться, как минимум, в третьей нормальной форме.
 
1 Постановка задачи
Проектирование любой информационной системы, которой, в частности, является и база данных, начинается с постановки задачи. На этом этапе всесторонне и детально рассматривается и описывается информация, которая должна храниться в базе данных, оговариваются права лиц на доступ к информации, описываются задачи, которые будут решаться с помощью данной базы, с кратким описанием алгоритмов из решения, описываются входные документы, информация с которых поступает в базу данных и выходные документы, генерируемые на выходе.
Материалы постановки задачи закладываются в проект и находят свое отражение в структуре данных, представленных в соответствии с выбранной моделью данных.
Для постановки задачи используется системный анализ предметной области. В общем случае существует два подхода к выбору структуры данных: функциональный, когда задачи и функции системы известны, и предметный, когда функции задачи в общем случае не известны. В случае функционального подхода получается система с минимальным набором элементов и средств, она получается компактной, но специализированной. При предметном подходе система получается более универсальной, но и более громоздкой, с множеством, возможно, излишних функций и элементов.
Чаще всего применяется некоторый «гибридный» подход к проектированию, при котором база данных проектируется ориентированной на какие-то вполне определенные задачи, но оставляется возможность ее расширения, если набор решаемых задач и функций расширяется.
В нашем случае, так как задачи будущей базы данных определены полностью, целесообразно воспользоваться функциональным подходом и определить минимальный набор элементов и средств для описания структуры данных.
В базе данных Производство должна храниться следующая информация:
Код изделия;
Наименование изделия;
Комплектующие, необходимые для изготовления изделия;
Завод-поставщик комплектующих;
Его адрес;
Является ли изделие типовым;
Дата выпуска изделия по плану;
Объем выпуска;
Примечания.
Проектируемая система должна обеспечивать возможность:
Ввода, удаления, добавления, и изменения данных, используя удобные экранные формы;
Поддержку целостности данных;
Поиск данных по заданным пользователем ключам;
Подготовку отчета по плановому выпуску изделий и выдачу его на принтер;
Реализацию SQL запросов, позволяющих получить ответы на следующие вопросы:
Какие изделия выпускаются на данном предприятии?
Какие комплектующие нужны для производства выпускаемых изделий?
Сколько типов комплектующих необходимы для изделий?
Какие изделия по плану необходимо выпустить до указанной даты?
Какое количество комплектующих необходимо для выполнения плана?
Сколько заводов поставляют запчасти для изделия … ?
Кроме всего этого, система должна обеспечивать защищенность данных от несанкционированного вмешательства посредством авторизации перед ее использованием.
 
2 Инфологическое проектирование базы данных
Построим инфологическую модель нашей базы данных. Наиболее распространенной логической моделью в настоящее время является модель «сущность - связь» или ER-модель (Entity – Relation).
Исходя из названия этой модели, основными ее объектами являются сущности и связи между ними. В нашей базе данных можно выделить три сущности: Изделия, Комплектующие, Заводы-изготовители (или просто – Заводы).
Сущность Изделия характеризуются следующими свойствами: Код изделия, Наименование изделия, Является ли типовым, Комплектующие, Количество комплектующих, Дата выпуска по плану, Объем, Примечания.
Сущность Комплектующие – такими свойствами: Код комплектующей части изделия, Обозначение, Название, Единица измерения, Завод-изготовитель.
Сущность Завод имеет следующие свойства: Код завода, Название, Адрес.
Таким образом, инфологическая структура системы может быть представлена следующим образом (рис. 1):
 
Рисунок 1 – ER-диаграмма ИС Производство.
Описание свойств сущностей представлено в табл. 1.

Таблица 1
Описание свойств сущностей
Свойство Тип Примечания
Изделия
Код изделия Целое без знака Порядковый номер или счетчик (первичный ключ)
Наименование Текст 
Типовое? Логический 
Комплектующие Целое без знака (массив) Перечисление ссылок на комплектующие
Количество компл. Число (массив) Перечисление количеств компл.
Дата выпуска Дата 
Объем Число 
Примечания Мемо 
Комплектующие
Код Целое без знака Порядковый номер или счетчик (первичный ключ)
Обозначение Текст 
Название Текст 
Единица измерения Текст 
Завод-изготовитель Целое без знака Ссылка на Завод
Завод
Код Целое без знака Счетчик
Название Текст 
Адрес Текст 

 
3 Датологическое проектирование базы данных
Датологическое проектирование базы данных представляет собой описание объектов предметной области в терминах выбранной модели. 
Так как база данных Производство проектируется в СУБД Access, которая является реляционной СУБД, то результатом датологического проектирования является набор взаимосвязанных таблиц.
При проектировании таблиц было учтено следующее.
Для изготовления изделия может потребоваться более одной комплектующей части.
Одна и та же комплектующая часть может входить в разные изделия.
Одна и та же комплектующая часть может изготавливаться на разных заводах.
Завод может производить несколько видов комплектующих.
Процесс получения датологической модели представляет собой процесс нормализации отношений, описывающих сущности. Нормальных форм существует шесть, однако, в большинстве случаев достаточно привести исходные отношения к третьей нормальной форме, чтобы стало возможно работать с информацией посредством языка SQL.
3.1 Первая нормальная форма
Отношение находится в первой нормальной форме, если в нем отсутствуют неатомарные, повторяющиеся и вычисляемые поля.
Начнем с отношения Завод. Данное отношение находится в первой нормальной форме по определению.
Отношение Комплектующие также находится в первой нормальной форме.
Отношение Изделие не находится в первой нормальной форме, т.к. содержит повторяющиеся поля. Это – Комплектующие и Количество комплектующих. От таких полей необходимо избавиться, но без потери информации. Вместо этих полей следует включить поля: Комплектующая часть (ссылка) и Количество экземпляров (объем и т.п.) комплектующей части. Тогда реальная заполненная таблица станет несколько «уже», но «длиннее».
3.2 Вторая нормальная форма
Отношение находится во второй нормальной форме, если оно находится в первой нормальной форме и все не ключевые поля зависят от всего ключа.
Ключом в отношении Изделия является пара полей Код изделия – Дата выпуска – Объем. Для того, чтобы перейти ко второй нормальной форме, необходимо проанализировать зависимости всех не ключевых полей на предмет связи именно со ВСЕМ ключом: если поле зависит только от части ключа, его следует удалить из ЭТОГО отношения и перенести в новое вместе с копией того поля, от которого оно зависит. В целях сохранения непротиворечивости и целостности данных между исходным и вновь созданным отношением устанавливается связь по этому скопированному полю. 
Таким образом, проанализировав отношение Изделие, получим следующую вторую нормальную форму (рис. 2).
 
Рисунок 2 – Вторая нормальная форма отношения Изделие.
Отношения Комплектующие и Заводы, если в них ключом принять поле Код, находятся во второй нормальной форме.
3.3 Третья нормальная форма
Отношение находится в третьей нормальной форме, если оно находится во второй нормальной форме и все не ключевые поля зависят только от ключа.
Таким образом, в полученных отношениях, представляющих вторую нормальную форму необходимо проанализировать на предмет зависимости попарно все не ключевые поля. 
Проделав эту работу и попутно убрав связь «многие-ко-многим», которая не поддерживается в СУБД Access, получим такую схему данных (рис. 3):
 
Рисунок 3 – Третья нормальная форма
 
4 Физическое проектирование базы данных
4.1 Проектирование таблиц
Приведем структуры таблиц.
 
Рисунок 4 – Структура таблицы Изделие.
 
Рисунок 5 – Структура таблицы Комплектующие.
 
Рисунок 6 – Структура таблицы Состав.
 
Рисунок 7 – Структура таблицы План.
 
Рисунок 8 – Структура таблицы Заводы.
 
Рисунок 9 – Структура таблицы Единицы измерения.
Содержание таблиц приведено в прил 2.
 
4.2 Обеспечение целостности данных
Схема данных приведена в прил 1. На схеме видно, что все таблицы базы данных связаны между собой связями «один-ко-многим». Целостность данных подразумевает, что в ведущей таблице (например, со стороны «один») отсутствуют записи со значениями полей, отсутствующих в дочерней таблице (со стороны «многие»).
Аппарат поддержания целостности данных в СУБД Access – встроенный и реализуется на уровне установления связей между таблицами. На рис. 10 приведен пример обеспечения целостности данных между таблицами Изделие и Состав:
 
Рисунок 10 – Пример обеспечения целостности данных.
Аналогично настраиваются связи между остальными таблицами.
4.3 Проектирование форм
Для ввода, удаления, добавления и изменения данных в базе предлагаются следующие формы (рис. 11 – 16):
 
Рисунок 11 – Форма Изделие.
 
Рисунок 12 – Форма Комплектующие.
 
Рисунок 13 – Форма Состав.
 
Рисунок 14 – Форма План.
 
Рисунок 15 – Форма Заводы
 
Рисунок 16 – Форма Единицы измерения.
Следует отметить, что формы в Access предназначены не только для операций ввода и редактирования, но и для быстрого поиска информации. Для этого используется механизм фильтрации записей, который вызывается командой меню Записи – Фильтр… при активной форме.
4.4 Проектирование запросов
4.4.1 Простой запрос
Ответ на вопрос «Какие изделия выпускаются на данном предприятии?» относится к простым запросам. Это наиболее простые однотабличные запросы, которые реализуются за счет операций выборки и проекции.
Следует напомнить, что в СУБД Access есть возможность создавать запросы как на языке SQL, так и на языке QBE, что в большинстве случаев и делается. Поэтому, будем приводить обе транскрипции запросов, как в режиме конструктора, так и в режиме SQL.
 
Рисунок 16 – Простой запрос на выборку данных.
В SQL- представлении он выглядит так:
SELECT Изделие.Наименование, Изделие.Типовой, Изделие.Примечание FROM Изделие;
Результат запроса приведен в прил. 3.
4.4.2 Многотабличный запрос
Запрос «Какие комплектующие нужны для производства выпускаемых изделий?» - это уже многотабличный запрос и здесь необходимо использовать связывание таблиц.
 
Рисунок 17 – Многотабличный запрос.
В SQL-представлении:
SELECT Изделие.Наименование, Изделие.Типовой, Изделие.Примечание, Комплектующие.Артикул, Комплектующие.Название, Состав.Количество, Комплектующие.[Единица измерения] FROM Комплектующие INNER JOIN (Изделие INNER JOIN Состав ON Изделие.Код = Состав.Изделие) ON Комплектующие.Код = Состав.Комплектующие;
4.4.3 Запросы, использующие группировку и вычисления с условием и без условия
Для выполнения следующих запросов необходима группировка с вычислением, т.е. использование агрегирующих функций в выражениях SELECT и HAVING, а для некоторых применяется так называемые параметрический запрос, когда условие вводится при выполнении запроса.
Запрос «Сколько типов комплектующих необходимы для изделий?»
 
Рисунок 18 – Запрос в режиме Конструктора.
Select-предложение выглядит так:
SELECT Изделие.Код, Изделие.Наименование, Count(Комплектующие.Артикул) AS [Количество комплектующих] FROM Комплектующие INNER JOIN (Изделие INNER JOIN Состав ON Изделие.Код = Состав.Изделие) ON Комплектующие.Код = Состав.Комплектующие GROUP BY Изделие.Код, Изделие.Наименование;
Запрос «Какие изделия по плану необходимо выпустить до указанной даты?»
Данный запрос является параметрическим и в режиме конструктора имеет вид:
 
Рисунок 19 – Запрос План по дате.
SELECT Изделие.Наименование, План.Объем, План.[Дата изготовления] FROM Изделие INNER JOIN План ON Изделие.Код = План.Изделие WHERE (((План.[Дата изготовления])<[Введите дату]));
Запрос «Какое количество комплектующих необходимо для выполнения плана?»
В режиме SQL выглядит следующим образом:
SELECT Комплектующие.Артикул, Комплектующие.Название AS Комплектующие, ЕдИзмерения.Наименование AS [Единица измерения], Sum(Состав!Количество*План!Объем) AS Количество, Заводы.Название AS Изготовитель, Заводы.Адрес
FROM (Заводы INNER JOIN (ЕдИзмерения INNER JOIN Комплектующие ON ЕдИзмерения.Код=Комплектующие.[Единица измерения]) ON Заводы.Код=Комплектующие.Изготовитель) INNER JOIN ((Изделие INNER JOIN План ON Изделие.Код=План.Изделие) INNER JOIN Состав ON Изделие.Код=Состав.Изделие) ON Комплектующие.Код=Состав.Комплектующие
GROUP BY Комплектующие.Артикул, Комплектующие.Название, ЕдИзмерения.Наименование, Заводы.Название, Заводы.Адрес
HAVING (((Комплектующие.Артикул)=[Введите артикул]));
А в режиме конструктора – так:
 
Рисунок 20 – Запрос в режиме конструктора.
«Сколько заводов поставляют запчасти для изделия … ?»
Выполнить такой запрос с помощью одного предложения SQL нельзя: требуется делать вложенный запрос или использовать представление. В Access запросы уже являются представлениями (View), поэтому необходимо просто организовать запрос к подзапросу.
 
Рисунок 21 – Подзапрос Количество заводов
SELECT DISTINCT Изделие.Наименование, Комплектующие.Изготовитель, Изделие.Код
FROM Комплектующие INNER JOIN (Изделие INNER JOIN Состав ON Изделие.Код = Состав.Изделие) ON Комплектующие.Код = Состав.Комплектующие
WHERE (((Изделие.Наименование)=[Введите название изделия])) OR (((Изделие.Код)=[Введите код изделия]));
 
Рисунок 22 – Запрос Количество заводов.
SELECT [Кол заводов_Представление].Наименование, Count([Кол заводов_Представление].Изготовитель) AS [Count-Изготовитель]
FROM [Кол заводов_Представление]
GROUP BY [Кол заводов_Представление].Наименование;
4.5 Создание отчета
Для создания отчета по плану выпуска изделий необходимо сначало организовать запрос, в котором будет содержаться вся необходимая информация. На рис. 23 представлен такой запрос.
 
Рисунок 23 – Запрос для отчета.
SELECT План.[Дата изготовления], План.Код, Изделие.Наименование, Изделие.Типовой, Изделие.Примечание, План.Объем
FROM Изделие INNER JOIN План ON Изделие.Код = План.Изделие
ORDER BY План.[Дата изготовления], Изделие.Наименование;
Для создания самого отчета в СУБД Access есть специальный аппарат: отчеты можно создавать, как в режиме конструктора, так и в режиме Мастера (обычно они комбинируются). На рис. 24 приведен макет отчета в режиме конструктора.
 
Рисунок 24 – Макет отчета в режиме конструктора.
Сам отчет по данным системы представлен в прил. 4.
 

4.6 Проектирование Главной формы
Все действия, которые возможно производить с объектами базы данных обычно объединяются либо в меню, либо в кнопочную форму, которая так представляет собой своеобразное меню. Создадим такую форму для нашей ИС.
На рис. 25 представлен внешний вид Главной кнопочной формы, объединяющей все необходимые элементы управления.
 
Рисунок 25 – Главная кнопочная форма.
4.7 Проектирование макроса
Для того, чтобы при запуске приложения Главная форма появлялась сразу, необходимо спроектировать макрос autoexec, который и будет открывать нашу форму. Окно проектирования макроса представлено на рис.26.
 
Рисунок 26 – Проектирование макроса autoexec.
4.8 Защита базы данных
В СУБД Access существуют довольно развитые средства защиты данных. Они считаются одними из лучших для персональных компьютеров. ее идея основана на распространенном понятии Рабочей группы. 
В данном проекте ограничимся заданием пароля на всю базу в целом. Для этого база данных открывается в монопольном режиме и с помощью команды меню Сервис – Защита – Задать пароль базы данных... задается пароль. После этого при открытии базы данных система будет запрашивать пароль (рис. 27).
 
Рисунок 27 – Окно ввода пароля базы данных.

 
Заключение
В данной работе была спроектирована база данных Производство.
В процессе создания базы был пройден полный цикл проектирования, включающий:
Системный анализ, на основании которого была сформулирована постановка задачи;
Инфологическое проектирование системы и базы данных, на основании которого была выбрана логическая структура будущего проекта;
Датологическое проектирование отношений базы данных привело к созданию третьей нормальной формы отношения;
Физическое проектирование таблиц с использованием СУБД Access;
Проектирование форм ввода и вывода информации;
Проектирование запросов на получение информации;
Проектирование главной кнопочной формы, позволяющей управлять информационными процессами в системе;
Создан макрос, запускающий приложение на выполнение.
Несмотря на задание пароля при входе в базу данных, она остается открытой для изменения и дополнения. Расширение возможностей системы допустимо и основано на корректной нормализации исходных отношений. Оснащение информационной системы новыми функциями происходит добавлением новых таблиц данных и пользовательских форм. Конечно, в базе данных можно использовать и модули, написанные на других языках программирования (Assembler, C++, VBA), однако этого следует по возможности избегать, т.к. в Access достаточно средств для реализации наших требований и пожеланий.
 
Список использованных источников
А.Д. Хоменко «Основы современных компьютерных технологий». М. 2000г.
К.Дэйт «Введение в системы баз данных», К.2000г.
СУБД Microsoft Access “Шаг за шагом», М. 1995г.

 
Приложение 1
Схема данных ИС
 
 
Приложение 2
Содержимое таблиц.
Единицы измерения
 
Заводы
 
 

Изделие
 
 

Комплектующие
 
 

План
 
 
Состав
 
Приложение 3
Результаты запросов.
Запрос Изделия
 
Запрос Состав изделия
 
Запрос Количество частей
 
Запрос План по дате (на 01.03.09).
 
Запрос Количество комплектующих (артикул А 345)
 
Запрос Количество заводов (для «шорты»)
 
 
Приложение 4
Первый лист отчета План.
 


Второй лист отчета План