Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
Дипломный проект
Раздел ”Производственная и экологическая безопасность”
Государственный комитет РФ по высшему образованию
Московский Институт Электронной Техники
(Технический Университет)
Факультет МПиТК
Кафедра ИПОВС
Пояснительная записка
к дипломному проекту на тему
“Автоматизация процесса учета движения товаров на складе малого предприятия”.
Дипломант Малютин П.В. ( __________ )
Руководитель проекта Полосухин Б.М. ( __________ )
Консультант ______________ ( __________ )
Консультант по технологической
части ______________ ( __________ )
Консультант по организационно-
экономической части Костина Г.Д. ( __________ )
Консультант по технике
безопасности Каракеян В.И. ( __________ )
1999 г.
МИЭТ
Часть 1
Специальный раздел.
Руководитель:_______Полосухин Б.М.
Выполнил: Малютин П.В.
1999 г.
Литературный обзор. 6
2.1. БАЗЫ ДАННЫХ, ОТНОШЕНИЯ И РЕЛЯЦИОННЫЕ БАЗЫ ДАННЫХ 6
2.1.1. Базовые концепции 9
2.1.2. Определение отношения
2.1.3 Определение реляционной БД 12
3. Постановка задачи 18
3.1. Требования, предъявляемые к системе автоматизированного учета 18
4. Технический проект 21
4.1. Общая структура системы 22
4.2. Структура данных 22
4.3. Связи между объектами 23
4.4. Лингвистическое описание 23
4.5. Алгоритмические связи 24
4.6. Информационные потребности пользователя 24
4.7. Ограничение целостности 24
4.8. Даталогическая можель данных 25
5. Рабочий проект
5.1. Конфигурация техничесикх средств 27
5.2. Алгоритмы предварительной работы программы 28
5.2.1. Структура программы 29
5.2.2. Иерархия форм 30
5.2.2.1. Main 31
5.2.2.2. Service 40
5.2.2.3 About 41
6. Заключение 41
Развитие современной компьютерной техники и программного обеспечения для нее в условиях жесткой конкуренции делает необходимым максимальную автоматизацию различных производственных процессов и делопроизводства с использованием самых совершенных компьютеров, которые позволяют ускорить и облегчить работу человека, а следовательно, и снизить себестоимость товаров или предоставляемых услуг и повысить их качество.
Одной из задач которую постоянно приходится решать современным предприятиям и торговым фирмам, является проблема учета движения товаров. Целью настоящего проекта является разработка пользовательской среды, позволяющей бухгалтерам и заведующему складом быстро и эффективно вносить новые данные в базу товаров, гибко реагировать на изменение цен, быстро получать всю информацию о хранящихся на складе товарах, ценах на них, поставщиках, другую полезную информацию, а также выводить отчеты как на экран ЭВМ, так и на бумагу.
Программа разрабатывалась при государственном предприятии ”Зеленоградский Школьный Комбинат Питания” (ШКП).
Основанием для работы послужили аналогичные программные продукты Зеленоградского Вычислительного Центра, возникшая необходимость расширения функций ПО, установленного в ШКП, совмещения функций выполняемых несколькими программами в одной пользовательской среде, а так же необходимость перевода документооборота на платформу Windows.
Функционирование программы позволило сократить трудовые и временные затраты работников бухгалтерии Школьного Комбината Питания по учету товародвижения на складе и на этой основе повысить качество и скорость обслуживания клиентов ШКП.
Для облегчения понимания поставленной задачи и методов её решения, был сделан литературный обзор по важнейшим понятиям, использованным при разработке и описании данного дипломного проекта.
Данный литературный обзор поясняет общие концепции, определение, содержание и методику разработки баз данных (БД), отношения, описываемые БД, так же подробно рассмотрен пример реляционной БД, аналогичной по структуре той, которая была создана в результате дипломного проектирования
2.1. БАЗЫ ДАННЫХ, ОТНОШЕНИЯ И РЕЛЯЦИОННЫЕ БАЗЫ ДАННЫХ
2.1.1. Базовые концепции
Базу данных можно определить как унифицирован ную совокупность данных, совместно используемую всем персоналом предприятия, банка или учебного заведения. Задача БД состоит в хранении всех пред ставляющих для некоторого предприятия интерес дан ных в одном месте, причем таким способом, который заведомо исключает их избыточность. Хранение мно жественных копий данных в различных местах пред приятия чревато возникновением рассогласований между предположительно идентичными наборами дан ных. В хорошо спроектированной БД избыточность данных исключается, и вероятность сохранения проти воречивых данных минимизируется.
В больших компьютерных системах к данным, хранящимся в БД, доступ может осуществляться од новременно сотней и более пользователей. БД в та ких случаях может иметь сотни полей данных с мил лионами единиц информации. Такие системы могут содержать буквально все данные, требующиеся для управления предприятием. БД на микрокомпьютерных системах имеют гораздо меньший масштаб. Здесь к конкретной БД в некоторый момент времени обычно осуществляет доступ один пользователь и каждая БД содержит только некоторое подмножество данных, требующихся предприятию. Одна БД разрабатывается, скажем, для хранения финансовой информации, дру гая - данных о персонале. Будет ли разрабатываемая БД размещаться на большой ЭВМ или на микроком пьютере - функции СУБД в обоих случаях одинако вы. СУБД представляет собой программно-аппаратный пакет, обеспечивающий пользователям простой доступ к БД. Программная часть СУБД, которую некоторые изготовители называют менеджером БД, выступает в качестве интерфейса между пользователем и БД (рис. 1.1). Менеджер БД обеспечивает программные средства, необходимые для создания, загрузки, запро са и обновления данных. Менеджер также контроли рует все действия, связанные с управлением вводом-выводом и памятью БД, а на больших ЭВМ на него возлагается и решение проблем безопасности и совме стного использования данных. Короче говоря, хорошо спроектированная СУБД обеспечивает программное обес печение, упрощающее для пользователя общение с БД.
Рис 1.1 Основные компоненты архитектуры СУБД
Другое сходство между большими и малыми СУБД заключается в том, что в обоих случаях сама БД должна быть хорошо спроектирована, если мы хотим, чтобы система баз данных как единое целое функци онировала должным образом. Цель книги состоит в выделении и описании некоторых базовых процедур проектирования для определенного типа БД, а именно реляционных. Предполагается, что пользователь будет устанавливать БД на микрокомпьютерной системе; одна ко, те же алгоритмы проектирования применимы к БД, проектируемым для больших компьютерных систем.
2.1.2. Определение отношения
Математически отношение определяется следующим образом.
Пусть даны "N" множеств Dl, D2, ...,DN, тогда R есть отношение над этими множествами, если R есть множество упорядоченных п-кортежей вида <dl, d2, ..., dn>, где dl - элемент из Dl, d2 - элемент из D2,... и dn - элемент из DN. Dl, D2, ..., DN назы ваются доменами отношения R.
Рис. 1.2. Отношение с математической точки зрения
Смысл данного определения наиболее просто пояс нить графически (рис. 1.2). Здесь показаны 4 домена. Домен D1 - это множество целых чисел; D2 - символьных строк, представляющих собой названия пред метов; D3 - символьных строк, представляющих собой меру измерения; D4 - еще одно множество чисел. Отношение R состоит из 4 кортежей. Каждый кортеж - из 4 элементов, которые выбираются каж дый из своего домена. Обратите внимание на порядок элементов в кортеже: первый элемент каждого корте жа выбран из домена Dl, второй элемент - из доме на D2 и т. д.
Сущность "реального мира" Атрибут сущности
(Имя файла) (Поле в записи)
ТОВАР
|
дном |
Дназв |
изм |
цена |
|
101 |
Яйцо |
Десяток |
4,00 |
|
102 |
Картофель |
Кг |
4,00 |
|
103 104 |
Огурцы Виноград |
Кг Кг |
11,98 62,50 |
Одна запись Значение атрибута
(Значение поля в записи)
Файл
Рис. 1.3. Отношение с точки зрения обработки данных
Взгляд на отношение с точки зрения обработки данных характеризует рис. 1.3. Четыре домена, пред ставленные на рис. 1.2, соотносятся с четырьмя эле ментами реального мира: номером товара, его назва нием, измерением кол-ва товара и ценой. Отношение принимает вид таблицы или файла, где кортежи - строки таблицы или записи в файле.
Имена столбцов (с точки зрения обработки данных - поля в записи) называются атрибутами, а индиви дуальные значения, появляющиеся в отдельных кортежах, - значениями атрибутов. Таким образом, пер вый элемент первого кортежа имеет значение атрибу та, равное 101 и взятое из домена дном. Следующие наборы терминов будут использоваться поочередно:
1. отношение, таблица и файл;
2. кортеж, строка и запись;
3. атрибут, столбец и поле;
так же как и в большей части документации по микрокомпьютерным БД.
Следует сделать одно замечание по поводу разли чия между математическим определением отношения и действительным хранением отношений в микроком пьютерных системах БД. По определению отношение не может иметь два идентичных кортежа. Несмотря на то что большинство больших СУБД не допускают хранения идентичных кортежей (записей) в отноше нии (файле), многие микрокомпьютерные СУБД это допускают (если не используется специальная техника программирования, предотвращающая возникновение указанной ситуации).
Следует упомянуть два дополнительных термина, касающихся отношений. Число столбцов в отношении называют степенью. Текущее число кортежей в отно шении называется мощностью. Степень отношения обычно не изменяется после создания отношения, но мощность будет колебаться по мере добавления новых и удаления старых кортежей.
2.1.3 Определение реляционной БД
Реляционная БД представляет собой не что иное, как совокупность отношений, содержащих всю информа цию, которая должна храниться в БД. На рис. 1.4 приведен пример очень маленькой БД, названной По ставщик—Детали.
Эта база содержит три типа информации о строи тельной компании*):
_________________________________________________________
*) БД Поставщик-Детали - хороший пример небольшой по объему реляционной БД, часто используемый в литературе.
Деталь ПТ
|
Дном |
Дназв |
изм |
Цена |
пном |
пфам |
статус |
Город |
|
|
101 102 103 104 105 106 |
Болт Муфта Винт Гайка Муфта Болт |
Черный Синий Красный Зеленый Красный Оранжевый |
3 9 11 4 13 21 |
П1 П2 П3 П4 П5 |
Смит Джонс Эддер Хаус Блэйк |
20 15 10 30 20 |
Лондон Детройт Чикаго Париж Париж |
|
ПД
|
Пном |
Дном |
Шт |
|
П1 П1 П1 П1 П2 П2 П2 П2 П3 П3 П3 П3 П3 П3 П4 П4 П5 П5 |
101 102 103 106 101 102 105 106 101 102 103 104 105 106 103 106 103 104 |
9 4 2 3 3 8 11 9 7 13 6 1 2 5 7 13 8 9 |
Рис. 1.4. База данных Поставщик-Детали
2. Информация о деталях, используемых на пред приятии. Сюда относятся номер детали, являющийся уникальным, название, цвет и вес, не являющиеся уникальными. Эта информация содержится в отноше нии ДЕТАЛЬ.
3. Информация о номерах и количестве деталей от каждого поставщика. Эта информация содержится в отношении ПД.
Каждое отношение в БД хранится в отдельном файле. Структура файла, используемого для хранения отношения, довольна проста, поскольку все записи имеют одинаковый формат. В больших СУБД каждое отношение сохраняется в виде индексированного фай ла, где индекс представляет собой атрибут или набор атрибутов, специфицированный при конструировании отношения.
Набор атрибутов, используемый в качестве индек са, называется первичным ключом отношения. Пер вичный ключ определяется как такой атрибут, или набор атрибутов, который может быть использован для однозначной идентификации конкретного кортежа. Первичный ключ не должен иметь дополнительных атрибутов. Это значит, что если произвольный единичный атрибут исключить из первичного ключа, ос тавшихся атрибутов будет недостаточно для однознач ной идентификации отдельных кортежей. В БД По ставщик—Детали первичными ключами являются <пном> для отношения ПОСТАВЩИК, <дном> для отношения ДЕТАЛЬ и пара атрибутов <пном, дном> для отношения ПД.
Читатель может убедиться, что каждый первичный ключ является достаточным для однозначной иденти фикации каждого кортежа в отношении. Например, в отношении ПД, если пном ~ П1 и дном = 101, мож но найти не более одного кортежа с указанными зна чениями атрибутов. На рис. 1.4 данные значения со держит кортеж <П1,101,9>. Попытка сохранить дру гой кортеж с тем же первичным ключом, скажем, <П1,101,11>, приводит к возникновению конфликт ной ситуации, поскольку становится неясным сколько деталей с номером 101 поставляет П1 - 9 или 11 (а может быть 20?). В полностью разработанной СУБД при попытке пользователя записать кортеж, имеющий первичный ключ, совпадающий с первичным ключом другого кортежа, уже включенного в отношение, ге нерируется сообщение об ошибке. Во многих реализациях СУБД, предназначенных для микрокомпьютеров, кортежи с совпадающими первичными ключами и да же полностью идентичные кортежи могут быть зане сены в отношение, и это не приводит к возникнове нию ошибки СУБД. В связи с этим могут возникнуть некоторые проблемы.
Во многих СУБД индекс файла, содержащего отно шение, не создается автоматически, и пользователь должен выполнить команду INDEX для его создания. Индексирование файлов значительно ускоряет выпол нение некоторых команд. Возможно индексирование отношения с использованием атрибутов, отличных от первичного ключа. Данный тип индекса называется вторичным индексом и применяется в целях умень шения времени доступа при нахождении данных в отношении. Простой пример индексного файла приве ден на рис. 1.5. Обратите внимание, что если само отношение не упорядочено каким-либо образом и в нем могут присутствовать строки, оставшиеся после удаления некоторых кортежей, то индексный файл, напротив, отсортирован. Структура индексного файла может быть разной, но обычно используется некото рый вариант древовидной структуры, обеспечивающей быстрый поиск. Для пояснения выбрана структура ин дексного файла, показанного на рис. 1.5, но ее не следует воспринимать как образец практического про ектирования.
Поставщикх (Индексный файл) Поставщик (Файл данных)
|
Номер записи |
Файл Поставщик пном Номер записи |
Номер записи |
Пном пфам статус город |
|
|
0001 0002 0003 0004 0005 |
П1 0006 П2 0004 ПЗ 0003 П4 0001 П5 0002 |
0001 0002 0003 0004 0005 0006 |
П4 Хаус 30 Париж П5 Блейк 20 Париж ПЗ Зддер 10 Чикаго П2 Джонс 15 Детройт Эта запись была удалена П1 Смит 20 Лондон |
Рис. 1.5. Простой пример индексного файла
Число отношений в БД и конкретные атрибуты, приписываемые каждому отношению, определяются в процессе проектирования. Собственно процесс проек тирования может быть довольно продолжительным. Однако после завершения этапа проектирования со здание БД средствами СУБД можно выполнить до вольно быстро. В случае БД Поставщик—Детали структура ее полностью специфицируется коротким набором предложений, приведенным на рис. 1.6. Это сжатое описание называется концептуальной моделью БД и содержит всю информацию, необходимую для создания полной структуры БД вне зависимости от того, какая конкретно СУБД будет использована. На рис. 1.7 приводится пример создания отношения ПО СТАВЩИК в dBase II вместе с индексным файлом для отношения ПОСТАВЩИК, в котором индекс пе рекрывает первичный ключ. Каждое из отношений в БД Поставщик-Детали будет создаваться аналогичным образом. Обратите внимание на то, что вся информа ция, необходимая для создания ПОСТАВЩИК, содер жится в концептуальной модели.
Название БД: Поставщик_детали
Атрибуты и тип:
пном симв(З),
пфам симв(6),
статус целый,
город симв(10),
дном целый,
дназв симв(6),
цвет симв(6),
вес целый,
шт целый.
Отношения и <Первичные ключи>:
Поставщик(пном, пфам, статус, город) <пном>,
ПД(пном, дном, шт) <пном, дном>,
Деталь(дном, дназв, цвет, вес) <дном>.
Рис. 1.6. Концептуальная модель БД Поставщик—Детали
Листинг содержимого отношения или всех отноше ний в БД, подобный тому, который приведен на рис. 1.4 ' для БД Поставщик—Детали, следует рассматривать как фотографию вида отношений в некоторый момент времени. Следует помнить, что содержимое всех отно шений динамически изменяется, поскольку кортежи могут быть добавлены, удалены или модифицированы в течение жизненного цикла отношений. Отдельный листинг некоторого отношения в определенный мо мент времени называется экземпляром этого отноше ния.
3. Постановка задачи
Теперь можно уточнить постановку задачи. Требуется написать систему, которая представляет собой пользовательскую среду, обеспечивающую выполнение следующих функций:
Система должна работать под управлением Windows95, реализована в среде разработки Borland Delphi 3 и должна состоять из двух компонентов – системы управления БД и и пользовательской оболочки над ним. Система включает в себя:
Набор интерфейсов для ввода данных и печати
База данных (БД), состоящей из файлов, хранящих списки:
Поставщиков;
Цен;
Процедуры управления базой данных
Сервис: печать отчетов, настройка принтера, help.
В качестве операционной среды, в которой реализовался данный дипломный проект, была выбрана среда Windows’95 (Windows NT). Причины этого следующие:
Распространенность этих ОС, в связи с чем получается охват большого числа возможных пользователей;
Возможность работы с большими массивами данных, реализация чего в среде Windows 3.1 или в среде MS-DOS представляет нетривиальную и трудновыполнимую задачу;
Удобство графического интерфейса дает возможность при минимизации затрат на его реализацию максимизировать удобство работы пользователя с программой. Интерфейс интуитивно понятен и стандартизован, соответственно пользователь не потратит много времени на освоение программы и в дальнейшем количество возможных ошибок в его действиях будет минимизировано.
32-разрядность систем Windows’95 и Windows NT увеличивает скорость работы с соответствующими числами.
В качестве среды программирования была выбрана среда Borland Delphi 3, сочетающая в себе как все преимущества всех средств, относящихся к RAD1, так и свои собственные преимущества:
Простота и надежность создания и отладки программы;
Использование всех преимуществ операционных систем Windows’95 и Windows NT, включая 32-разрядность, многозадачность, удобный интерфейс и прочее;
Использование обработки исключений (exceptions), что позволяет повысить надежность работы программного продукта;
Наличие и доступность большого количества компонент, реализующих многие стандартные функции.
Таким образом, в качестве платформы для реализации была выбрана связка Windows’95 (NT) - Borland Delphi 3.
4. Технический проект
Учитывая специфику задачи и возможности операционной системы, разрабатываемая система должна иметь следующую структуру, показанную на рис.1.7
Рис.1.7. Структура системы.
База данных реализована в виде некриптованных текстовых файлов, это сделано специально по следующим причинам: снижение требований к установленному ПО на компьютере, содержащем систему (отпадает необходимость в содержании и обслуживании сервера запросов к специализированной базе данных, таком как, например: InterBase, Microsoft SQL server и тому подобные), во-вторых, повышается надежность (чем меньше программ участвуют в обработке БД, тем меньше вероятность, что одна из них “зависнет” или “совершит некорректную операцию”) и в-третьих снижаются требования к обслуживающему персоналу, для которого отпадает необходимость обучения работе с сервером баз данных и остаются лишь требования знания основ работы с Windows системой, тем самым уменьшаются расходы на эксплуатацию системы в целом, что является важнейшим фактором в текущем экономическом состоянии нашей страны.
Входные и выходные данные хранятся и обрабатываются непосредственно в текстовом формате. Описание объектов:
Рис.1.8 Структура объектов базы данных.
4.3. Связи между объектами
Связи между объектами так же хранятся в текстовом формате, в виде последовательности строк содержащих тройки:
Рис.1.9. Связи между объектами.
4.4. Лингвистическое описание
База данных описывает некоторый список товаров, поэтому одним из объектов, входящих в базу, является объект ТОВАР. Признаками данного объекта являются
Индекс товара, необходим для упрощения обработки базы с помощью ЭВМ.
обозначение товара - статический атрибут, который показывает, под каким псевдонимом выступает товар в различных выходных формах системы, например, в форме сводки цен кладовой (см приложения к дипломному проекту);
измерение - статический атрибут, целью которого является пояснение – в какой, собственно, количественной мере описывается объем данного товара на складе. В частности, это могут быть килограммы или десятки;
количество - динамическое свойство, описывает собственно объем (массу или т.п.) занимаемую товаром на складе;
цена товара - динамический атрибут, показывает текущую отпускную цену на товар со склада.
Объект «Поставщик» - описывает известных системе поставщиков товаров. Признаки данного объекта следующие:
индекс поставщика – используется внутри СУБД для упрощения расчетов
поставщик - свойство, описывает наименование фирмы, поставившей товар, необходимо для представления информации в виде удобной для восприятия пользователем;
Примечание: данный объект представлен с минимально-необходимым набором атрибутов. В дальнейшем возможно снабдить объект дополнительными свойствами не носящими смысловой нагрузки для программы, но полезными для пользователей, например адрес и/или телефон поставщика.
Кроме этого в базе существуют объекты, которые описывают логическую структуру модели.
Объект «Связи». Синонимом данного объекта также является «Links», этот объект располагается в файле links.
Объект “Связи” имеет следующие свойства:
обозначение индекса товара Iт - признак, который берется из файла ТОВАРЫ (“goods”);
Индекс поставщика Iп;
объем поставки – собственно свойство связующее первый и второй параметр.
Порядковый номер в переменной равен номеру уникальной комбинации значений индексов, от которых зависит экономическая переменная. Номера в переменной вычисляются по взаимосвязи переменной с индексами.
Значение индекса = минимальное значение + i * шаг изменения, i - некоторое целое число, при условии, что значение индекса меньше либо равно максимальному значению индекса.
4.6. Информационные потребности пользователя
Пользователю очень важно знать все значения экономических параметров, чтобы на основании всех полученных данных успешно планировать закупочную политику и создавать отчеты.
Во всех объектах системы свойство Index является целым и неотрицательным, поскольку при отрицательном значении оно не имеет смысла. Нулевой Index принадлежит первому элементу объекта.
В объекте «Товар» значения полей “Количество” и “Цена товара” должны быть неотрицательными действительными числами.
В объекте «Связи» свойство “объем поставки” является положительным действительным числом.
Под даталогической моделью (ДЛМ) подразумевается отображение конечных связей между реальными объектами предметной области к их смысловому содержанию в среде хранения. ДЛМ строится в терминах информационных единиц, предусмотренных в конкретной системе управления базами данных.
Все объекты и связи между объектами в нашем случае можно выразить следующими соотношениями:
Товар (обозначение товара, описание товара, единица измерения кол-ва, количество хранимого товара в единицах измерения, цена товара) - таблица Goods.txt;
Поставщик (Index поставщика, описание поставщика) - таблица Vendors.txt;
Связи (Index товара, Index поставщика, объем поставленного товара в единицах измерения ) - таблица Links.txt;
В приведенных отношениях номер сочетания индексов и порядковый номер в переменной - это одно и то же. Данное разбиение позволяет избежать избыточности - таблица, построенная на первом отношении будет содержать не изменяющиеся данные и, если в модель не добавлять новых переменных, будет служить неким неизменяемым справочником.
На уровне таблиц это выглядит следующим образом:
В приведенных ниже таблицах обозначение вида «X» в колонке «№», где X - номер поля, означает, что данное поле является ключевым.
Goods.txt
|
№ |
Имя |
Тип |
Комментарий |
|
“1” |
Ig |
Integer |
Обозначение индекса |
|
2 |
Good |
String |
Наименование товара |
|
3 |
Izm |
String |
Единица измерения |
|
4 |
Count |
Real |
Количество товара |
|
5 |
Price |
Real |
Цена товара |
Vendors.txt
|
№ |
Имя |
Тип |
Комментарий |
|
“1” |
Iv |
Integer |
Index поставщика |
|
2 |
Vendor |
String |
Поставщик |
Links.txt
|
№ |
Имя |
Тип |
Комментарий |
|
“1” |
Ig |
Integer |
Index товара |
|
“2” |
Iv |
Integer |
Index поставщика |
|
3 |
Post |
Integer |
Объем поставки |
В этом разделе рассматриваются алгоритмы клиентской части реализации доступа к данным в архитектуре клиент/сервер.
Требования к составу и параметрам технических средств соответствуют требованиям к программному продукту - системе моделирования макроэкономики.
Минимально необходимое оборудование:
PC 80486 SX2-66;
RAM 12 MB;
HDD 50 MB свободных;
Screen Color VGA.
Printer.. Любой матричный
Рекомендуемое оборудование:
PC Pentium 133 МГц;
RAM 32 MB;
HDD 30 MB свободных;
Screen Color SVGA;
Printer HP LASER JET
Необходимое программное обеспечение:
ОС Windows’95;
Драйвера для принтера.
Общий алгоритм работы программы:
Структура программы представлена на риc.1.10.
Рис.1.10. Структура программы.
Формы баз данных Delphi можно разделить на четыре следующих функциональных класса.
1. Редактирование и ввод. Простая форма, представляющая одну запись одной таблицы.
2. Сетка. Форма, которая отображает несколько строк одной таблицы, как это делается в программах электронных таблиц (каждая строка таблицы базы данных занимает одну строку на экране).
3. Управляющая сетка. Форма, которая отображает несколько строк одной таблицы (каждая строка таблицы базы данных занимает несколько строк экрана).
4. Главная-подчиненная. Форма, которая показывает строки двух или более связанных таблиц.
При разработке приложения прежде всего создаются и сохраняются в хранилище объектов Delphi формы-предки. Затем на их основе создаются все формы, являющиеся потомками.
Рис.1.11. Иерархия форм.
Главная форма MAIN содержит процедуры реализующие “Акт приема товара”, “Акт снятия товара”, вызовы дочерних форм (посредством выбора одного из пунктов меню).
Рис. 1.12 Главная форма перед началом работы.
Выбор режима работы происходит с помощью меню:
Рис 1.13. Пример работы с меню.
После выбора режима работы, появляется одна из панелей. Рассмотрим работу программы на примере режима “Акт приёма товара”:
Рис 1.14 Режим “Акт приёма товара”
Работа с формой происходит следующим образом:
Пользователь выбирает из списка поставщика, в случае отсутствия поставщика в списке, его можно добавить, все изменения в составе поставщиков немедленно отображаются в Базе Данных.
Затем пользователь вводит наименование товара поступившего от поставщика, единицы измерения товара, цену за единицу и количество поставленных единиц, нажимая на кнопку “добавить” (справа) пользователь заносит информацию во временную таблицу.
Реализована так же вспомогательная автоматическая функция подсчета общей суммы, уплаченной за товар
После окончательного формирования акта поставки нажимается
Кнопка “Записать в книгу” и запись из временной таблицы переносится в Базу Данных.
Приведем участок текста программы, реализующий этот алгоритм
procedure TForm1.N5Click(Sender: TObject);
var f:TextFile;
s:string;
begin
// Блокируем ненужные пункты меню
N1.enabled:=false;
N2.enabled:=false;
N3.enabled:=false;
N4.enabled:=false;
// Открываем файл БД ПОСТАВЩИК
assignfile(f,'vendors.txt');
reset(f);
listbox.Items.Clear;
// Заполняем список ПОСТАВЩИКов
while not eof(f) do
begin
readln(f,s);
listbox.items.add(s);
end;
// Показываем Панель
panel1.Visible:=True;
// Закрываем файл БД ПОСТАВЩИК
closefile(f);
end;
// Процедура отображения выбранного поставщика в заголовке
// Акта Приёма Товара
procedure TForm1.ListBoxClick(Sender: TObject);
var i:integer;
begin
i:=0;
while not listbox.selected[i] do inc(i);
Vend.Caption:='Поставщик : '+Listbox.Items.Strings[i];
canAccept:=(canAccept or 1);
if canAccept=3 then btAccept.Enabled:=True;
end;
// Пользователь выбрал ОТМЕНА
procedure TForm1.btCancelClick(Sender: TObject);
begin
Panel1.Visible:=False;
N1.enabled:=true;
N2.enabled:=true;
N3.enabled:=true;
N4.enabled:=true;
end;
// Добавляем строку в список ПОСТАВЩИКов и – одновременно в БД
procedure TForm1.btAdd1Click(Sender: TObject);
var f:TextFile;
begin
assignfile(f,'vendors.txt');
Append(f);
ListBox.Items.Add(Edit3.Text);
Writeln(f,Edit3.Text);
closefile(f);
btAdd1.Enabled:=false;
end;
// Удаляем строку из списка
procedure TForm1.btDeleteClick(Sender: TObject);
var f:TextFile;
i:integer;
begin
assignFile(f,'vendors.txt');
rewrite(f);
i:=0;
while not listbox.selected[i] do inc(i);
ListBox.Items.Delete(i);
for i:=0 to ListBox.Items.Count-1 do
writeln(f,Listbox.Items[i]);
closefile (f)
end;
// Добавляем строку во временную таблицу
procedure TForm1.btAdd2Click(Sender: TObject);
begin
Table.Cells[0,CurrentRow]:=Goods.Text;
Table.Cells[1,CurrentRow]:=Izm.Text;
Table.Cells[2,CurrentRow]:=Price.Text;
Table.Cells[3,CurrentRow]:=Count.Text;
Table.Cells[4,CurrentRow]:=intToStr(strToint(Price.Text)*strToint(Count.Text));
inc(currentRow);
btAdd2.Enabled:=false;
entered:=0;
canAccept:=(canAccept or 2);
if canAccept=3 then btAccept.Enabled:=True;
end;
// Делаем окончательную запись в БД
procedure TForm1.btAcceptClick(Sender: TObject);
var f:textfile;
i,j:integer;
buff: string;
flag:boolean;
begin
assignfile(f,'goods.txt');
FileMode:=2;
i:=0;
while i<CurrentRow do
begin
reset(f);
flag:=true;
while flag do
begin
readln(f,buff);
if pos(Table.Cells[0,i],buff)>0 then
begin
flag:=false;
writeln(f,Table.Cells[0,i]+' '+Table.Cells[1,i]+' '+Table.Cells[2,i]+' '+Table.Cells[3,i]+' '+Table.Cells[4,i]+' '+Table.Cells[5,i]);
end
else
if flag and eof(f)then
begin
closefile(f);
append(f);
flag:=false;
writeln(f,' '+Table.Cells[0,i]+' '+Table.Cells[1,i]+' '+Table.Cells[2,i]+' '+Table.Cells[3,i]+' '+Table.Cells[4,i]+' '+Table.Cells[5,i]);
end;
end;
inc(i);
closefile(f);
end;
end;
Еще один из режимов работы системы – печать сводки цен, вот как выглядит панель, иллюстрирующая этот режим:
Рис. 1.15. Режим Печать сводки цен кладовой
Процедура, заполняющая список в панели из базы данных:
procedure TForm1.N25Click(Sender: TObject);
var f:textfile;
i,t,j:integer;
s:string;
begin
AssignFile(f,'goods.txt');
i:=0;
ReSet(f);
while not eof(f) do
begin
readln(f,s);
delete(s,1,1);
for j:=0 to 1 do
begin
t:=pos(' ',s);
Prices.Cells[j,i]:=Copy(s,1,t);
delete(s,1,t);
end;
Prices.Cells[2,i]:=s;
inc(i);
Prices.rowCount:=Prices.RowCount+1;
end;
closefile(f);
Panel2.Visible:=True;
end;
Покажем так же насколько элегантно и просто в Windows – Delphi реализована процедура вызова панели настройки принтера:
Рис 1.16. Настройка принтера
Cоответствующая процедура:
procedure TForm1.N36Click(Sender: TObject);
begin
PrinterSetupDialog.execute
end;
Действительно очень простая и в тоже время важная процедура.
Форму Service мы здесь рассматривать не будем, потому что функции реализованные в той части программы не являются специфичными ни с математической, ни с программистской точки зрения и представляют собой лишь готовые шаблоны-заготовки печатаемых финансовых документов.
Еще одна, третья и последняя форма, входящая в состав автоматизированной системы учета товаров является форма About.
Вызов её из основной формы производится следующей процедурой:
procedure TForm1.N37Click(Sender: TObject);
begin
Form3:=TForm2.Create(Self);
Form3.Show;
end;
В данном разделе в части литературного обзора были рассмотрены общие положения, применяемые разработчиками СУБД, даны основные подходы создания реляционных баз данных показан простейший пример реляционной БД Поставщик-Детали.
В разделе “Постановка задачи” были рассмотрены требования к системе автоматизированного учета товаров на складе.
Технический проект содержит общую структуру системы, структуру данных, связи между объектами, лингвистическое описание, алгоритмические связи, информационные поребности пользователей, ограничения целостности и даталогическую модель данных.
В рабочем проекте дана конфигурация технических средств, алгоритмы работы программы, структурная схема работы программы показана иерархия форм, включая примеры диалога с пользователем и участки программного кода, описывающие важные процедуры системы автоматического учета товаров.
В целом представлена полная и объективная картина, отражающая содержание выполненных работ по проектированию Базы Данных, созданию алгоритмов управления БД и их программной реализации.
1 RAD - Rapid Application Development - быстрая разработка приложений. Такие средства, благодаря своей реализации, позволяют за минимально короткое время создать и отладить программный продукт со сложным графическим интерфейсом.
________________________________________________________________________________
-34-
Малютин П.В. Кафедра ИПОВС 1999г.
EMBED Visio.Drawing.4
EMBED Visio.Drawing.4
EMBED Visio.Drawing.4