Размещено на http://www.allbest.ru/

Введение

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

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

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

ОАО "Первомайский электромеханический завод им. К. Маркса" является ведущим производителем взрывобезопасных двигателей на территории Украины. Для продвижения своей продукции на мировые рынки руководством предприятия было принято решение провести сертификацию системы качества на соответствие стандарту ISO 9001:2000. Наличие сертификата качества является необходимым условием для успешной работы на зарубежных рынках и дополнительным преимуществом в конкурентной борьбе.

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

Целью написания курсовой работы является проектирование базы данных подсистемы анализа качества продукции ОАО «Первомайский электромеханический завод им. К. Маркса». Целью написания курсовой работы является создание базы данных подсистемы анализа качества продукции.

Поставленная цель потребовала решения следующего круга задач:

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

- разработка концептуальной модели базы данных;

- разработка логической модели данных;

- разработка модели «сущность - связь»;

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

- физическое проектирование таблиц базы данных;

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

- разработка отчетов;

- проектирование управляющей программы.

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

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

база данное таблица запрос

ОАО "Первомайский электромеханический завод им. К. Маркса" производит двигатели для угольной, химической, газовой, нефтедобывающей и нефтеперерабатывающей отраслей промышленности и осуществляет их гарантийное и послегарантийное обслуживание. ОАО «ПЭМЗ им. Карла Маркса» выпускает двигатели мощностью от 2,2 до 400 кВт, напряжением 380, 660, 1140, 6000 В, частотой вращения от 500 до 3600 мин^-1. Электродвигатели применяют в своей деятельности промышленные предприятия более чем 34 стран мира. Продукцию завода оценили на международном уровне, о чем свидетельствуют награды, полученные на престижных выставках «Электро» в г. Москва, «Уголь» в г. Донецке.

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

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

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

Если при испытаниях был обнаружен брак, то бракованный узел направляется обратно в цех для исправления брака. После исправления (перемотки, доработки) производится повторное испытание узла.

Количество материалов, пошедшие на производство узлов и исправление брака фиксируются на местах проведения работ (возникновения затрат).

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

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

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

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

- оборудование (инвентарный номер, цех, участок, дата ввода в эксплуатацию, норма выработки, дата следующего планового ремонта);

- электродвигатели (номер, наименование, тип исполнения, серия, мощность, частота вращения, масса, напряжение);

- личные данные персонала (табельный номер, фамилия, имя, отчество, дата рождения, домашний адрес, телефон домашний);

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

- материалы (код, наименование, ГОСТ, цена, поставщики);

- сборочные единицы (код, номер двигателя, наименование, работник, контролер, осуществивший прием).

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

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

- результаты испытаний за определенный период;

- количество брака на каждой стадии производства за определенный период;

- количество поставок некачественной продукции от определенных поставщиков;

- на какие двигатели приходит наибольше количество рекламаций;

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

- работников и подразделения, по вине которых произошел брак продукции.

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

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

- заключения входного контроля материалов, деталей;

- протоколы результатов замеров, проб, испытаний материалов;

- рекламации покупателей;

- акты технического обследования электродвигателей;

- результаты испытаний узлов двигателей;

- акты приема электродвигателей.

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

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

- отчеты о качестве продукции за определенный период;

- отчеты по материалам и поставщикам;

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

- динамика производственного брака;

- отчеты по работникам предприятия, ответственным за выпуск бракованной продукции;

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

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

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

2. Моделирование структур данных

2.1 Разработка концептуальной модели базы данных

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

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

- материалы;

- поставщики;

- заказчики;

- рабочие;

- контролер;

- расходники;

- узлы двигателя;

- двигатели;

- рекламации.

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

Сущность Поставщики характеризуется следующими атрибутами: код поставщика, наименование, адрес, телефон.

Сущность Заказчики характеризуется следующими атрибутами: код заказчика, наименование, адрес, телефон.

Сущность Материалы характеризуется следующими атрибутами: код, название, код поставщика, единица измерения, ГОСТ или ТУ, цена поставки.

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

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

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

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

Сущность Двигатели характеризуется следующими атрибутами: номер двигателя, тип, серия, ГОСТ, мощность, частота вращения, масса, рабочее напряжение.

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

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

Сущность Рабочие связана с сущностями Узлы и Двигатели связями Производит (1 ко многим). Сущность Контролер связана с сущностями Узлы, Двигатели и Материалы связями Проверяет (1 ко многим), с сущностью Рекламации связью Принимает (1 ко многим).

Графическое представление концептуальной модели дано в приложении Б.

2.2 Разработка логической модели данных

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

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

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

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

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

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

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

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

В данной модели предметной области затраты на оплату труда не учитываются.

Взаимосвязь добавленных сущностей с уже описанными будет следующая.

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

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

Сущность Прием двигателя связана с сущностями Контролер, Двигатели связью один ко многим.

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

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

Графическое представление логической модели дано в приложении Б.

2.3 Разработка модели “сущность - связь”

Основными понятиями модели «сущность - связь» являются:

- сущность;

- связь;

- атрибуты.

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

Объект, соответствующий понятию сущности, имеет свой набор атрибутов - характеристик, определяющих его свойства.

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

Сущность “Материалы” имеет одно ключевое поле - код материала.

Сущности “Рабочие” и “Контролер” имеют одно ключевое поле - табельный номер.

Сущность “Поставщики” имеет одно ключевое поле - код поставщика.

Сущность “Заказчики” имеет одно ключевое поле - код заказчика.

Сущность “Узлы двигателя” имеет одно ключевое поле - код узла.

Сущность “Двигатели” имеет одно ключевое поле - код двигателя.

Сущности “Испытания узлов”, “Прием двигателей”, “Расходники”, “Исправление узлов”, “Поставки” не имеют ключевых полей.

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

3. Проектирование базы данных

3.1 Преобразование модели “сущность связь” в реляционную модель данных

Преобразование модели «сущность-связь» в реляционную модель данных осуществляется путем последовательного выполнения ряда шагов.

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

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

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

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

3.2 Физическое проектирование таблиц базы данных

В ходе решения задачи была выбрана платформа Windows 9x/NT от всемирно известного производителя корпорации Microsoft. Эта платформа была выбрана по нескольким причинам:

1) широкое распространение этой ОС в нашей стране

2) удобный, интуитивно понятный интерфейс

3) отсутствие проблем с совместимостью аппаратного обеспечения

4) работа в защищенном режиме

5) поддержка русского языка.

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

Access входит в состав самого популярного пакета Microsoft Office. Основные преимущества: знаком многим конечным пользователям и обладает высокой устойчивостью данных, прост в освоении, может использоваться непрофессиональным программистом, позволяет готовить отчеты из баз данных различных форматов. Предназначен для создания отчетов произвольной формы на основании различных данных и разработки некоммерческих приложений.

В данной среде разработки были созданы следующие таблицы.

1. Поставщики. Данная таблица имеет следующие поля: код поставщика (числовое, длинное целое), наименование (текст, 50 символов), адрес(текст, 50 символов), телефон (числовое, длинное целое).

2. Поставки: код поставщика (числовое, длинное целое), код материала (числовое, длинное целое), дата (дата), процент брака (числовое, целое), контролер (числовое, целое).

3. Материалы: код материала (числовое, длинное целое), название (текст, 50 символов), ед. измер. (текст, 10 символов), ГОСТ (текст, 30 символов), цена (числовое, целое).

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

5. Испытания узлов: код узла (подстановка из табл. Сборочные узлы, поле код узла), дата (дата/время), контролер (подстановка из табл. Контролер, поле Таб номер.)

6. Исправление узлов: код узла (подстановка из табл. Сборочные узлы, поле код узла), дата (дата/ время), операция (текстовое, 50 симв.), рабочий (подстановка из табл. Работники, поле Таб номер.), причина брака (текстовое, 50 симв.).

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

8. Контролер: таб. номер(числовое, целое), категория (числовое, байт), ФИО (текст, 70 символов).

9. Рабочие: табельный номер (числовое, целое), разряд(числовое, байт), профессия (текст, 20 символов), разряд (числовое, байт), ФИО (текст, 70 символов), цех(числовое, байт), участок(числовое, байт).

10. Рекламации: код заказчика (числовое, целое), дата (дата/время), описание (поле МЕМО), контролер (подстановка из табл. Контролер, поле Таб номер.), номер двигателя (подстановка из табл. Двигатели, поле номер двигателя).

11. Двигатели: номер двигателя (числовое, целое), Тип Исполнение (текст, 20 символов), серия (текст, 20 символов), гост (текст, 20 символов), мощность (числовое, целое), частота (числовое, целое), масса (числовое, одинарное с плавающей точкой), примечания (текст, 70 символов), сборщик (подстановка из табл. Работники, поле Таб номер.).

12. Прием двигателей: номер двигателя (подстановка из табл. Двигатели, поле номер двигателя), дата (дата/время), контролер (подстановка из табл. Контролер, поле Таб номер.), замечания (текст, 70 символов).

13. Заказчики: код заказчика (числовое, целое), наименование (текст, 70 символов), адрес (текст, 70 символов), телефон (числовое, целое).

Схема данных соединяющая таблицы базы данных связями представлена в приложении.

3.3 Разработка запросов к базе данных

3.3.1 Разработка встроенных запросов

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

1. Запрос “Анализ бракованных узлов по видам брака” предоставляет информацию за определенный период по видам брака конкретного узла, например статора.

Текст запроса на языке SQL.

SELECT ИспытанияУзлов.Результат, Count (ИспытанияУзлов.Результат) AS Количество, [Сборочные узлы].Наименование

FROM [Сборочные узлы] INNER JOIN ИспытанияУзлов ON [Сборочные узлы].КодУзла = ИспытанияУзлов.КодУзла

WHERE (((ИспытанияУзлов.Дата)>#1/1/2004#)) GROUP BY ИспытанияУзлов.Результат, [Сборочные узлы]. Наименование

HAVING (((ИспытанияУзлов. Результат)<>"норма") AND (([Сборочные узлы].Наименование)="статор"))

ORDER BY Count(ИспытанияУзлов.Результат) DESC;

Рисунок 3.1 - Результат запроса

2. Запрос “Стоимость исправления брака” отражает информацию за определенный период по стоимости материалов, пошедших на исправление бракованных.

Текст запроса на языке SQL:

SELECT [Исправленный брак].[Причина брака], Sum([Материалы]! [Цена]*[Расходники]![Чистый вес]) AS Стоимость, [Сборочные узлы].Наименование, Двигатели.НомерДвигателя, Двигатели.ТипИсполнение

FROM Двигатели INNER JOIN (Материалы INNER JOIN (([Сборочные узлы] INNER JOIN Расходники ON [Сборочные узлы].КодУзла = Расходники.КодУзла) INNER JOIN [Исправленный брак] ON (Расходники.[Дата передачи в цех] = [Исправленный брак].ДатаИсправления) AND (Расходники.КодУзла = [Исправленный брак].КодУзла)) ON Материалы.Код = Расходники.КодМатериала) ON Двигатели.НомерДвигателя = [Сборочные узлы].НомерДвигателя

GROUP BY [Исправленный брак].[Причина брака], [Сборочные узлы].Наименование, Расходники.[Исправление брака], Двигатели. Номер Двигателя, Двигатели.ТипИсполнение

HAVING (((Расходники.[Исправление брака])=True))

ORDER BY Sum([Материалы]![Цена]*[Расходники]![Чистый вес]) DESC;



Рисунок 3.2 - Результат запроса.

3. Запрос “Анализ поставок” предоставляет информацию о поставках некачественных материалов за определенный период.

Текст запроса на языке SQL.

SELECT Поставщики.КодПоставщика, Поставщики.Наименование, Поставки.ПроцентБрака, Материалы.Код, Материалы.Название, Поставки.Дата

FROM Материалы INNER JOIN (Поставщики INNER JOIN Поставки ON (Поставщики.КодПоставщика = Поставки.КодПоставщика)) ON Материалы.Код = Поставки.КодМатерала

GROUP BY Поставщики.КодПоставщика, Поставщики.Наименование, Поставки.ПроцентБрака, Материалы.Код, Материалы.Название, Поставки.Дата

HAVING (Поставки.ПроцентБрака)<>0)AND((Поставки.Дата)>#1/1/2004#)

ORDER BY Поставщики.КодПоставщика;



Рисунок 3.3 - Результат запроса.

4. Запрос “Анализ работников” предоставляет информацию о работниках, допустивших брак в течение определенного периода с указанием бракованного узла, и причины брака.

Текст запроса на языке SQL:

SELECT [Сборочные узлы].Рабочие, Рабочие.ФИО, [Сборочные узлы].КодУзла, [Сборочные узлы].Наименование, Рабочие.Цех, Рабочие.Участок, ИспытанияУзлов.Результат AS [Причина брака], ИспытанияУзлов.Дата

FROM ИспытанияУзлов INNER JOIN (Рабочие INNER JOIN [Сборочные узлы] ON Рабочие.ТабНомер = [Сборочные узлы].Рабочие) ON ИспытанияУзлов.КодУзла = [Сборочные узлы].КодУзла

GROUP BY [Сборочные узлы].Рабочие, Рабочие.ФИО, [Сборочные узлы].КодУзла, [Сборочные узлы].Наименование, Рабочие.Цех, Рабочие.Участок, ИспытанияУзлов.Результат, ИспытанияУзлов.Дата

HAVING (((ИспытанияУзлов.Результат)<>"норма"));



Рисунок 3.4 - Результат запроса.

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

Текст запроса на языке SQL:

SELECT Двигатели.НомерДвигателя, Двигатели.ТипИсполнение, Двигатели.Серия, [Сборочные узлы].КодУзла, [Сборочные узлы].Наименование, ИспытанияУзлов.Результат, ИспытанияУзлов.Дата

FROM Двигатели INNER JOIN ([Сборочные узлы] INNER JOIN ИспытанияУзлов ON ([Сборочные узлы].КодУзла = ИспытанияУзлов.КодУзла) AND ([Сборочные узлы].КодУзла = ИспытанияУзлов.КодУзла) AND ([Сборочные узлы].КодУзла = ИспытанияУзлов.КодУзла)) ON Двигатели.НомерДвигателя = [Сборочные узлы].НомерДвигателя

WHERE (((ИспытанияУзлов.Результат)<>"норма"))

ORDER BY Двигатели.НомерДвигателя;



Рисунок 3.5 - Результат запроса.

• 6. Запрос на выборку “Перерасход материалов” показывает перерасход материалов по видам в натуральном и стоимостном выражении за определенный период.
• Текст запроса на языке SQL.
• SELECT Материалы.Код, Материалы.Название, Материалы.Цена, Sum(([Расходники]![Чистый вес]-[Расходники]![Норма])) AS [В натуральном выражении], Sum(([Расходники]![Чистый вес]-[Расходники]![Норма])*[Цена]) AS [В стоимостном выражении], [Сборочные узлы].КодУзла, Расходники.[Исправление брака], Расходники.[Дата передачи в цех]
• FROM [Сборочные узлы] INNER JOIN (Материалы INNER JOIN Расходники ON Материалы.Код = Расходники.КодМатериала) ON [Сборочные узлы].КодУзла = Расходники.КодУзла
• GROUP BY Материалы.Код, Материалы.Название, Материалы.Цена, [Сборочные узлы].КодУзла, Расходники.[Исправление брака], Расходники.[Дата передачи в цех]
• HAVING (((Sum(([Расходники]![Чистый вес]-[Расходники]![Норма])))<>0) AND ((Расходники.[Дата передачи в цех])>#1/1/2004#));
• Рисунок 3.6 - Результат запроса.
• 7. Запрос “Увеличение стоимости двигателей” показывает, на сколько увеличилась стоимость двигателей в результате возникновения брака.
• Текст запроса на языке SQL.
• SELECT [Сборочные узлы].НомерДвигателя, [Сборочные узлы].Наименование AS [Бракованный узел], Двигатели.ТипИсполнение, Двигатели.Серия, Sum([Материалы]![Цена]*[Расходники]![Чистый вес]) AS [Cтоимость материалов]
• FROM Двигатели INNER JOIN (([Исправленный брак] INNER JOIN (Материалы INNER JOIN Расходники ON (Материалы.Код = Расходники.КодМатериала) AND (Материалы.Код = Расходники.КодМатериала)) ON ([Исправленный брак].ДатаИсправления = Расходники.[Дата передачи в цех]) AND ([Исправленный брак].КодУзла = Расходники.КодУзла)) INNER JOIN [Сборочные узлы] ON [Исправленный брак].КодУзла = [Сборочные узлы].КодУзла) ON Двигатели.НомерДвигателя = [Сборочные узлы].НомерДвигателя
• WHERE (((Расходники.[Исправление брака])=True))
• GROUP BY [Сборочные узлы].НомерДвигателя, [Сборочные узлы].Наименование, Двигатели.ТипИсполнение, Двигатели.Серия;

• Рисунок 3.7 - Результат запроса.
• 8. Запрос на выборку “Рекламации по двигателям” показывает данные по пришедшим рекламациям на завод за определенный период.
• Текст запроса на языке SQL.
• SELECT DISTINCTROW Заказчики.Наименование AS Заказчик, Двигатели.ТипИсполнение, Двигатели.Серия, Рекламации.НомерДвигателя AS НомерДвигателя, Рекламации.Описание AS [Описание неисправности], Рекламации.Дата FROM Заказчики INNER JOIN (Двигатели INNER JOIN Рекламации ON Двигатели.НомерДвигателя = Рекламации.НомерДвигателя) ON Заказчики.КодЗаказчика = Рекламации.КодЗаказчика
• WHERE (((Рекламации.Дата)>#1/1/2004#));
• Рисунок 3.8 - Результат запроса.
• 9. Запрос на обновление записей “Обнуление стоимости” обнуляет поле “Cтоимость” таблицы “Сборочные узлы” за определенный период.
• Текст запроса на языке SQL.

UPDATE [Сборочные узлы] RIGHT JOIN ИспытанияУзлов ON [Сборочные узлы].КодУзла = ИспытанияУзлов.КодУзла SET[Сборочные узлы].Стоимость =0

WHERE (((ИспытанияУзлов.Дата)>#1/1/2004#));

• 10. Запрос на обновление записей “Определение стоимости узлов” заполняет поле “Cтоимость” таблицы “Сборочные узлы” за определенный период при условии, что данное поле имеет нулевое значение.
• Текст запроса на языке SQL.

UPDATE [Сборочные узлы] INNER JOIN (Материалы INNER JOIN Расходники ON Материалы.Код = Расходники.КодМатериала) ON [Сборочные узлы].КодУзла = Расходники.КодУзла SET [Сборочные узлы].Стоимость = [Сборочные узлы]![Стоимость]+[Материалы]![Цена]*[Расходники]![Чистый вес]

WHERE ((([Сборочные узлы].Стоимость)=0) AND ((Расходники.[Дата передачи в цех])>#1/1/2004#));

3.3.2 Разработка динамических запросов

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

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

В запросе “Анализ бракованных узлов по видам брака” изменяемыми параметрами являются вид брака и наименование сборочного узла.

В запросах “Стоимость исправления брака”, “Перерасход материалов”, “Рекламации” изменяемым параметром выступает период.

Запрос на выборку “Анализ поставок” можно провести по конкретному материалу, поставщику, периоду времени.

Запрос на выборку “Анализ работников” можно провести по определенному периоду, цехам, участкам.

В запросе “ Инфа по испытаниям узлов двигателя ” изменяемыми параметрами являются период, тип двигателя, серия.

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

3.4 Разработка отчетов

В базе данных предусмотрены отчеты, которые составляются по результатам выполнения запросов. Отчеты имеют форму выходных документов, принятую на предприятии, показаны на рисунках 3.8- 11

Рисунок 3.9 - Отчет по поставкам.

Рисунок 3.10 - Отчет по затратам.

Рисунок 3.11 - Перерасход материалов.

Рисунок 3.12 - Испытания узлов двигателей.

4. Проектирование управляющей программы

4.1 Разработка форм для ввода данных

В качестве средства реализации проекта был выбран программный продукт от Microsoft - Visual Basic 6.0 поскольку он имеет такие возможности:

1) легкость и удобство построения пользовательского интерфейса

2) наличие мастера создания форм

3) небольшой размер исполняемых файлов

4) совместимость с MS Windows

5) высокая скорость компиляции

6) поддержка формата mdb.

7) широкий выбор моделей доступа к данным

8) совместимость с MS Access

9) удобная печать.

Для доступа к данным бала выбрана модель ADO (ActiveX Data Object). Это обусловлено универсальностью моделей OLE DB, использованием их в Internet, простым доступом, как к локальным, так и к удаленным данным.

Формы для ввода данных были созданы с применением встроенного инструмента Data Form Wizard.

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

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

Рисунок 4.1 - Форма для ввода данных в таблицу “Поставки”

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

Рисунок 4.2 - Форма для ввода данных в таблицу “Поставки”

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

Рисунок 4.3 - Вид формы ввода после выбора материала.

После заполнения остальных полей и нажатия кнопки Update новые данные вносятся в базу данных.

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

• Рисунок 4.4 - Сообщение программы.

4.2 Разработка интерфейса пользователя

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

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

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

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

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

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

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



Рисунок 4.5 - Диалоговое окно динамического запроса “Анализ поставок”.

Рисунок 4.6 - Окно программы с результатами запроса.

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

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

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

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



Рисунок 4.7 - Сообщение “О программе”.

При выборе пункта меню Выход происходит завершение работы программы.

4.3 Разработка средств администрирования базы данных

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

Рисунок 4.8- Ввод пароля и сообщения программы.

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

При входе в систему считывается пароль с текстового поля и выполняется подключение к базе данных с помощью модели DAO. Если в результате подключения произошла ошибка 3031 “Неверный пароль”, то пользователю выводится сообщение о некорректности пароля, если другая ошибка - сообщение с ее описанием, на экране остается окно “Вход в систему”.

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

В меню Сервис определены следующие функции по администрированию базы данных.

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

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

Уплотнение. При выборе данного пункта, на экране появляется диалоговое окно “Уплотненная база данных”, где пользователь может указать имя и путь новой (уплотненной) базы данных.

Изменение пароля. При выборе данного пункта, на экране появляется диалоговое окно “Изменение пароля”, где пользователь может ввести новый пароль, который присвоится базе данных.

При нажатии кнопки Cancel во всех 4-х подменю никаких действий и изменений с базой данных не происходит.

Выводы

В результате выполнения курсовой работы было дано описание предметной области - ОАО "Первомайский электромеханический завод им. К. Маркса". На основании описания предметной области в результате концептуального моделирования была разработана концептуальная модель базы данных, затем - логическая модель, модель “сущность-связь”, реляционная модель базы данных. Была проведена нормализация базы данных.

Было осуществлено физическое проектирование базы данных с использованием СУБД Access 2000. Созданная база данных содержит 13 таблиц, целостность данных в которых обеспечивается связями между ними. В базе данных реализованы 8 запросов на выборку записей и 2 на добавление. На основании запросов на выборку сформированы 4 отчета. База данных занимает 4,5 Мб дискового пространства.

Для разработки управляющей программы база данных из версии Access 2000 была преобразована к предыдущей версии - Access 97. Полученная база данных имеет размер 400 Кб.

Была создана управляющая программа в среде разработки Visual Basic 6.0. Она выполнена в виде исполняемого файла, не требует инсталляции. Для работы программы необходимо наличие на компьютере системного DSN, подключенного к базе данных версии Access 97 с именем источника данных “Kyrsaki”.

При разработке форм для ввода данных использовался стандартный инструмент Data Form Wizard, для составления отчетов применялся компонент Data Report. В программе реализованы ограничения на вводимые значения на уровне форм, обеспечена целостность и непротиворечивость вводимых данных.

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

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

Программа занимает 200 Кб дискового пространства, во время выполнения занимает 4,62 Мб оперативной памяти. Программа работает стабильно и не вызывает сбоев в работе системы.

Перечень ссылок

1. Майкл Амудсен, Кэртис Смит. Программирование баз данных на Visual Basic 5. Освой самостоятельно. Пер. с англ. - М.: ЗАО «Издательство БИНОМ», 1998. - 896 с.: ил.

2. Т. Конноли, К. Бегг, А. Страчан. Базы данных: Проектирование, реализация и сопровождение. Теория и практика.: Пер. с англ. - СПб: ЗАО «Издательство Питер», 1999. - 1139 с. : ил.

3. Мак-Манус Дж.П. Обработка баз данных на Visual Basic 6: Пер. с англ.-К.;М.;СПб.: Издательский дом «Вильямс», 2001. - 672 с.: ил. Парал.тит.англ.

4. Дженнингс Р. Руководство разработчика баз данных на Visual Basic 6: Пер. с англ.-К.;М.;СПб.: Издательский дом «Вильямс», 2001. - 976 с.: ил. Парал.тит.англ.

5. И. Харитонова, В. Михеева Microsoft Access 2000 в подлиннике. : Пер. с англ. - М. : ЗАО «Издательство БИНОМ», 1999. -1100 с. : ил.

Размещено на Allbest.ru