2
Оглавление
инвентарный номер;
год изготовления;
грузоподъемность;
износ;
род вагона;
район движения;
2. операции с вагоном:
станция отправитель;
станция получатель;
фронт получения/отправления;
груз;
вес груза;
операция;
3. вид работ:
вид работ;
единица измерения;
цена за единицу измерения
База данных должна отвечать следующим требованиям:
в БД должны быть представлены справочники по цехам, видам услуг, операциям, грузам, станциям, районам движения.
внедрение данной БД должно значительно сократить время на заполнение ведомостей и позволить вести легкий и удобный учет вагонов
в базе данных должна быть предусмотрена возможность исправлений, что очень важно при занесении информации.
в БД должна быть предусмотрена печать отчетов.
БД должна обеспечивать учет расходов на обслуживание вагонов, что позволит в будущем рассчитывать средства на обслуживание и эксплуатацию подвижного состава.
Задачи, решаемые с помощью системы:
Загрузка в систему информации о вагонах, обработка информации;
Ведения перечня используемых вагонов, хранение информации о выполненных работах;
Определение текущего местонахождения вагонов;
Ввод, хранение, поиск и вывод информации о вагонах на подъездных путях;
Расчет стоимости обслуживания вагонов;
Хранение, поиск и вывод информации об отправках вагонов (станции отправления и назначения, грузоотправитель, наименование и масса груза и т.п.);
Система учета вагонов - это новый уровень учета, который существенно увеличивает производительность персонала и обеспечивает экономию времени. Основные преимущества системы:
Автоматизированная обработка получаемой информации.
Централизованное хранение информации о подвижном составе. Таким образом, снижается риск потерять информацию и обеспечивает большее удобство доступа к ней.
Быстрый поиск информации. Поиск необходимой информации о вагоне занимает секунды.
Возможности по анализу информации. Система позволяет рассчитать затраты на обслуживание подвижного состава.
Удобный пользовательский интерфейс. Поиск осуществляется с помощью фильтров, параметры которых можно настроить таким образом, чтобы найти необходимую информацию, исключив при этом избыточные данные. Найденные данные представляются в виде отчета.
Разработанная ИС предназначена обеспечивать информационно-справочную поддержку функционирования основных служб железнодорожного цеха предприятия, а также учет нахождения вагонов на подъездных путях с регистрацией времени обслуживания по номерам вагонов, формирование ведомости обслуживания вагонов с расчетом стоимости услуг.
Вывод: Для компаний, деятельность которых связана с железнодорожными перевозками, эффективный учет подвижного состава - одна из составляющих успеха. Но ручная обработка информации и поиск необходимых данных в бумажных документах или разрозненных файлах - процесс длительный и трудоемкий, а анализ такой информации требует предварительного отбора данных и многочисленных вычислений.
Предлагаемое решение позволяет не только автоматизировать обработку данных о подвижном составе, но также обеспечить их централизованное хранение, ускорить поиск и облегчить анализ.
Глава 1. Основы проектирования программных продуктов
1.1. Характеристика программных продуктов
Все программы по характеру использования и категориям пользователей можно разделить на два класса - утилитарные программы и программные продукты (изделия).
Утилитарные программы ("программы для себя") предназначены для удовлетворения нужд их разработчиков. Чаще всего утилитарные программы играют роль сервиса в технологии обработки данных либо являются программами решения функциональных задач, не предназначенных для широкого распространения.
Программные продукты (ПП) предназначены для удовлетворения потребностей пользователей, широкого распространения и продажи.
Поскольку в дипломной работе разрабатывается информационная система учета вагонов на подъездном пути, что в конечном итоге является программным продуктом, рассмотрим этот класс программ более подробно.
Программный продукт - комплекс взаимосвязанных программ для решения определенной проблемы (задачи) массового спроса, подготовленный к реализации как любой вид промышленной продукции.[1]
Отличительной особенностью программных продуктов должна быть их системность - функциональная полнота и законченность реализуемых функций обработки, которые применяются в совокупности.
Как правило, программные продукты требуют сопровождения. Сопровождение программ массового применения сопряжено с большими трудозатратами - исправление обнаруженных ошибок, создание новых версий программ и т.п.
Сопровождение программного продукта - поддержка работоспособности программного продукта, переход на его новые версии, внесение изменений, исправление обнаруженных ошибок и т.п.
Основными характеристиками программ являются:
алгоритмическая сложность (логика алгоритмов обработки информации);
состав и глубина проработки реализованных функций обработки;
полнота и системность функций обработки;
объем файлов программ;
требования к операционной системе и техническим средствам обработки со стороны программного средства;
объем дисковой памяти;
размер оперативной памяти для запуска программ;
тип процессора;
версия операционной системы;
наличие вычислительной сети и др.
Показатели качества программных продуктов отражают следующие аспекты:
насколько хорошо (просто, надежно, эффективно) можно использовать программный продукт;
насколько легко эксплуатировать программный продукт;
можно ли использовать программный продукт при изменении условия его применения и др.
Характеристики качества программных продуктов:
Мобильность программных продуктов означает их независимость от технического комплекса системы обработки данных, операционной среды, сетевой технологии обработки данных, специфики предметной области и т.п.
Надежность работы программного продукта определяется работоспособностью и устойчивостью в работе программ, точностью выполнения предписанных функций обработки, возможностью диагностики возникающих в процессе работы программ ошибок.
Эффективность программного продукта оценивается как с позиций прямого его назначения - требований пользователя, так и с точки зрения расхода вычислительных ресурсов, необходимых для его эксплуатации. Расход вычислительных ресурсов оценивается через объем внешней памяти для размещения программ и объем оперативной памяти для запуска программ.
Учет человеческого фактора означает обеспечение дружественного интерфейса для работы конечного пользователя, наличие контекстно-зависимой подсказки или обучающей системы в составе программного средства, хорошей документации для освоения и использования заложенных в программном средстве функциональных возможностей, анализ и диагностику возникших ошибок и др.
Модифицируемость программных продуктов означает способность к внесению изменений, например расширение функций обработки, переход на другую техническую базу обработки и т.п.
Коммуникативность программных продуктов основана на максимально возможной их интеграции с другими программами, обеспечении обмена данными в общих форматах представления (экспорт/импорт баз данных, внедрение или связывание объектов обработки и др.).[1]
При создании программного продукта высокого качества все эти аспекты должны быть учтены и по возможности (с учетом приоритетных потребностей) должны быть реализованы при его производстве.
Следует также заметить, что создание программного продукта не одномоментное действие, а работа, занимающая некоторый период времени и включающая в себя различные этапы. Таким образом, мы приходим к понятию жизненного цикла программного продукта.
1.2. Жизненный цикл программного обеспечения (ЖЦ ПО)
ЖЦ ПО - это непрерывный процесс, который начинается с момента принятия решения о необходимости его создания и заканчивается в момент его полного изъятия из эксплуатации.
Основным нормативным документом, регламентирующим ЖЦ ПО, является международный стандарт ISO/IEC 12207 (ISO - International Organization of Standardization - Международная организация по стандартизации, IEC - International Electrotechnical Commission - Международная комиссия по электротехнике). Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО.
Стадия создания ПО - часть процесса создания ПО, ограничивающееся временными рамками и заканчивающееся выпуском конкретного программного продукта. Разработка ПО включает следующие стадии:
1. формирование требований (анализ)
2. проектирование
3. реализация (кодирование)
4. тестирование
5. внедрение
6. сопровождение
7. снятие с эксплуатации
Стадия анализа предназначена для изучения требований к создаваемому программному продукту, а именно:
определение состава и назначения функций обработки данных программного продукта;
установление требований пользователя к характеру взаимодействия с программным продуктом, типу пользовательского интерфейса (система меню, использование манипулятора мышь, типы подсказок, виды экранных документов и т.п.);
требование к комплексу технических и программных средств для эксплуатации программного продукта и т.д.
На данном этапе необходимо выполнить формализованную постановку задачи.
Проектирование структуры программного продукта связано с алгоритмизацией процесса обработки данных, детализацией функций обработки, разработкой структуры программного продукта (архитектуры программных модулей), структуры информационной базы (базы данных) задачи, выбором методов и средств создания программ - технологии программирования.
Реализация, тестирование и отладка программ являются технической реализацией проектных решений и выполняются с помощью выбранного инструментария разработчика (алгоритмические языки и системы программирования, инструментальные среды разработчиков и т.п.). Для больших и сложных программных комплексов, имеющих развитую модульную структуру построения, отдельные работы данного этапа могут выполняться параллельно, обеспечивая сокращение общего времени разработки программного продукта. Важная роль принадлежит используемым при этом инструментальным средствам программирования и отладки программ, поскольку они влияют на трудоемкость выполнения работ, их стоимость и качество создаваемых программ.
На стадии внедрения осуществляется внедрение компонентов ПО в эксплуатацию, в том числе конфигурирование базы данных и рабочих мест пользователей, обеспечение эксплуатационной документацией, проведение обучения персонала и т.д.
Эксплуатация программного продукта идёт параллельно с его сопровождением, при этом эксплуатация программ может начинаться и в случае отсутствия сопровождения или продолжаться в случае завершения сопровождения ещё какое-то время. В процессе эксплуатации программного продукта производится локализация проблем и устранение причин их возникновения, модификация ПО в рамках установленного регламента, подготовка предложений по совершенствованию, развитию и модернизации системы.
Снятие программного продукта с продажи и отказ от сопровождения происходят, как правило, в случае неэффективности работы программного продукта, наличия в нем неустранимых ошибок, отсутствия спроса.[1]
Длительность жизненного цикла для различных программных продуктов неодинакова. Для большинства современных программных продуктов длительность жизненного цикла измеряется в годах (2-3 года). Хотя достаточно часто встречаются на компьютерах и давно снятые с производства программные продукты.
Особенность разработки программного продукта заключается в том, что на начальных этапах принимаются решения, реализуемые на последующих этапах. Допущенные ошибки, например, при спецификации требований к программному продукту, приводят к огромным потерям на последующих этапах разработки или эксплуатации программного продукта и даже к неуспеху всего проекта. Так, при необходимости внесения изменений в спецификацию программного продукта следует повторить в полном объеме все последующие этапы проектирования и создания программного продукта.
Каждый процесс характеризуется определенными задачами и методами их решения, исходными данными, полученными на предыдущем этапе, и результатами. Результатами анализа, в частности, являются функциональные модели, информационные модели и соответствующие им диаграммы. Часто ЖЦ ПО носит итерационный характер: результаты очередного этапа часто вызывают изменения в проектных решениях, выработанных на более ранних этапах.
1.3. Модели жизненного цикла ПО
Модель жизненного цикла отражает различные состояния системы, начиная с момента возникновения необходимости в данной информационной системе и заканчивая моментом ее полного выхода из употребления. Модель жизненного цикла - структура, содержащая процессы, действия и задачи, которые осуществляются в ходе разработки, функционирования и сопровождения программного продукта в течение всей жизни системы, от определения требований до завершения ее использования.
В настоящее время известны и используются следующие модели жизненного цикла:
Каскадная модель предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем этапе.
Поэтапная модель с промежуточным контролем. Разработка ИС ведется итерациями с циклами обратной связи между этапами. Межэтапные корректировки позволяют учитывать реально существующее взаимовлияние результатов разработки на различных этапах; время жизни каждого из этапов растягивается на весь период разработки.
Спиральная модель. На каждом витке спирали выполняется создание очередной версии продукта, уточняются требования проекта, определяется его качество, и планируются работы следующего витка. Особое внимание уделяется начальным этапам разработки - анализу и проектированию, где реализуемость тех или иных технических решений проверяется и обосновывается посредством создания прототипов (макетирования).
На практике наибольшее распространение получили две основные модели жизненного цикла:
каскадная модель (характерна для периода 1970-1985 гг.);
спиральная модель (характерна для периода после 1986.г.).
В ранних проектах достаточно простых информационных систем каждое приложение представляло собой единый, функционально и информационно независимый блок. Для разработки такого типа приложений эффективным оказался каскадный способ. Каждый этап завершался после полного выполнения и документального оформления всех предусмотренных работ.[1]
Можно выделить следующие положительные стороны применения каскадного подхода:
на каждом этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности;
выполняемые в логической последовательности этапы работ позволяют планировать сроки завершения всех работ и соответствующие затраты.
Каскадный подход хорошо зарекомендовал себя при построении относительно простых информационных систем, когда в самом начале разработки можно достаточно точно и полно сформулировать все требования к системе. Основным недостатком этого подхода является то, что реальный процесс создания системы никогда полностью не укладывается в такую жесткую схему, постоянно возникает потребность в возврате к предыдущим этапам и уточнении или пересмотре ранее принятых решений. В результате реальный процесс создания информационной системы оказывается соответствующим поэтапной модели с промежуточным контролем.
Однако и эта схема не позволяет оперативно учитывать возникающие изменения и уточнения требований к системе. Согласование результатов разработки с пользователями производится только в точках, планируемых после завершения каждого этапа работ, а общие требования к информационной системе зафиксированы в виде технического задания на все время ее создания. Таким образом, пользователи зачастую получают систему, не удовлетворяющую их реальным потребностям.
Спиральная модель ЖЦ была предложена для преодоления перечисленных проблем. На этапах анализа и проектирования реализуемость технических решений и степень удовлетворения потребностей заказчика проверяется путем создания прототипов. Каждый виток спирали соответствует созданию работоспособного фрагмента или версии системы. Это позволяет уточнить требования, цели и характеристики проекта, определить качество разработки, спланировать работы следующего витка спирали. Таким образом, углубляются и последовательно конкретизируются детали проекта, и в результате выбирается обоснованный вариант, который удовлетворяет действительным требованиям заказчика и доводится до реализации.
Итеративная разработка отражает объективно существующий спиральный цикл создания сложных систем. Она позволяет переходить на следующий этап, не дожидаясь полного завершения работы на текущем и решить главную задачу - как можно быстрее показать пользователям системы работоспособный продукт, тем самым, активизируя процесс уточнения и дополнения требований.
Основная проблема спирального цикла - определение момента перехода на следующий этап. Для ее решения вводятся временные ограничения на каждый из этапов жизненного цикла, и переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. Планирование производится на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков.
1.4 Структурный подход к проектированию ПП
Проектирование любого программного продукта основано не только на выборе модели ЖЦ ПО и разделении работ по его созданию на стадиях проектирования, но и на выборе подхода к проектированию. В дипломной работе разработка информационно-справочной системы учета вагонов велась с помощью структурного подхода.
Сущность структурного подхода заключается в декомпозиции (разбиении) системы на автоматизируемые функции: система разбивается на функциональные подсистемы, которые в свою очередь делятся на подфункции, подразделяемые на задачи и так далее. Процесс разбиения продолжается вплоть до конкретных процедур. При этом автоматизируемая система сохраняет целостное представление, в котором все составляющие компоненты взаимоувязаны. При разработке системы "снизу-вверх" от отдельных задач ко всей системе целостность теряется, возникают проблемы при информационной стыковке отдельных компонентов.
Наиболее распространенные методологии структурного подхода базируются на ряде общих принципов. В качестве двух базовых принципов используются следующие:
принцип "разделяй и властвуй" - принцип решения сложных проблем путем их разбиения на множество меньших независимых задач, легких для понимания и решения;
принцип иерархического упорядочивания - принцип организации составных частей проблемы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне.
Выделение двух базовых принципов не означает, что остальные принципы являются второстепенными, поскольку игнорирование любого из них может привести к непредсказуемым последствиям (в том числе и к провалу всего проекта). Основными из этих принципов являются следующие:
принцип абстрагирования заключается в выделении существенных аспектов системы и отвлечения от несущественных;
принцип формализации заключается в необходимости строгого методического подхода к решению проблемы;
принцип непротиворечивости заключается в обоснованности и согласованности элементов;
принцип структурирования данных заключается в том, что данные должны быть структурированы и иерархически организованы.[1]
Методологии, технологии и инструментальные средства проектирования (CASE-средства) составляют основу проекта любой информационной системы. Методология реализуется через конкретные технологии и поддерживающие их стандарты, методики и инструментальные средства, которые обеспечивают выполнение процессов ЖЦ.
В структурном анализе используются в основном две группы средств, иллюстрирующих функции, выполняемые системой и отношения между данными. Каждой группе средств соответствуют определенные виды моделей (диаграмм), наиболее распространенными, среди которых являются следующие:
SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы;
DFD (Data Flow Diagrams) диаграммы потоков данных;
ERD (Entity-Relationship Diagrams) диаграммы "сущность-связь".
Наиболее распространенным средством моделирования данных являются диаграммы "сущность-связь" (ERD). Данное средство было использовано в дипломной работе для проектирования специализированной базы данных, на основе которой разрабатывалась система учета подвижного состава на подъездном пути. С помощью ER-диаграмм определяются важные для предметной области объекты (сущности), их свойства (атрибуты) и отношения друг с другом (связи). ERD непосредственно используются для проектирования реляционных баз данных, что соответствует выбранной модели базы данных, проектируемой в данной дипломной работе.[1]
Введем понятия сущности, атрибута и связи, поскольку на этих понятиях основано проектирование базы данных, которое будет рассмотрено в следующей главе.
Сущность - это реальный или воображаемый объект, имеющий сущностные значения для рассматриваемой предметной области, информация о котором подлежит хранению. Тип сущности характеризуется независимым существованием и представляет множество объектов реального мира с одинаковыми свойствами. Отдельные объекты, которые входят в данный тип, называют экземплярами объекта.
Атрибут - любая характеристика сущности, значимая для рассматриваемой предметной области и предназначенная для квалификации, идентификации, классификации, количественной характеристики или выражения состояния сущности.
Связь - поименованная ассоциация между двумя сущностями, значимая для рассматриваемой предметной области.[1]
Глава 2. Основные принципы проектирования базы данных
2.1 Понятие базы данных и системы управления базами данных
База данных (БД) - именованная совокупность данных, отражающая состояние объектов и их отношений в рассматриваемой предметной области, или иначе БД - это совокупность взаимосвязанных данных при такой минимальной избыточности, которая допускает их использование оптимальным образом для одного или нескольких приложений в определенной предметной области.[3]
В любом бизнесе имеются данные, что в свою очередь требует создания некоторого организованного метода или механизма управления этими данными. Такой механизм принято называть системой управления базами данных (СУБД). Основываясь на современных технологиях, доказавших свою пользу системы управления базами данных начали развиваться в других направлениях, отвечая требованиям растущего бизнеса, все возрастающих объемов корпоративных данных и, конечно же, технологий, связанных с Internet.
Современная волна информационных технологий управления основывается на использовании систем управления реляционными базами данных (СУРБД), которые являются развитием традиционных СУБД. Реляционные базы данных и технологии клиент/сервер являются типичной комбинацией, позволяющей современным компаниям успешно обрабатывать данные и оставаться конкурентоспособными в своих секторах рынка.
2.2 Основные свойства базы данных
Для успешной реализации системы на основе базы данных на первом месте стоит проектирование структуры данных, а затем только осуществляется разработка приложений. Плохо спроектированная база данных будет поставлять некорректную информацию, порождать ошибки, способные привести к принятию неправильных решений.
Проектируемая БД должна обладать определенными свойствами. Ниже перечислены основные свойства базы данных.
Целостность. В каждый момент существования базы данных сведения, содержащиеся в ней, должны быть непротиворечивы. Целостность БД достигается вследствие введения ограничений целостности, в частности, к ним относятся ограничения, связанные с нормализацией БД. Желательно отслеживать диапазон допустимых значений, соотношения между значениями в полях, особенности написания формата. Существуют ограничения, работающие только при удалении записей.
Восстанавливаемость. Данное свойство предполагает возможность восстановления БД после сбоя системы или отдельных видов порчи системы. Сюда относится проверка наличия файлов, составляющих приложение. В основном свойство восстанавливаемости обеспечивается дублированием БД и использованием техники повышенной надежности.
Безопасность. Безопасность БД предполагает защиту данных от преднамеренного и непреднамеренного доступа, модификации или разрушения. Применяется запрещение несанкционированного доступа, защита от копирования и криптографическая защита. Также необходимы и административные меры, например ограничение доступа к носителям информации.
Эффективность. Свойство эффективности обычно понимается как:
минимальное время реакции на запрос пользователя;
минимальные потребности в памяти;
сочетание этих параметров.
Предельные размеры и эксплуатационные ограничения. Предельные размеры, а также другие ограничения, накладываемые эксплуатацией данной БД, могут существенно повлиять на проектное решение.[3]
2.3. Трехуровневая архитектура базы данных
Проектирование БД связано с разрешением проблем представления данных и их обменом между конечными пользователями. Они продиктованы различными потребностями и задачами лиц, которые используют эти данные. Можно выделить четыре категории лиц, каждая из которых имеет свой круг интересов и связана с определенным этапом разработки и существования БД. Определим эти основные категории лиц, а также их роли и функции на разных стадиях существования баз данных:
администраторы данных и баз данных;
разработчики баз данных;
прикладные программисты;
конечные пользователи.
Данные - это важный ресурс организации, и ими надо умело управлять. Столь важная функция возложена на специалистов определенного рода - Администраторов данных (АД). Они работают с данными с самого начала процесса проектирования БД и отвечают за концептуальное и логическое проектирования БД, управление данными, разработку и сопровождение стандартов, бизнес-правил и деловых процедур.
Физическое проектирование и физическая реализация базы данных, обеспечение безопасности и целостности данных, обеспечение максимальной производительности приложений - это область действия компетенций Администратора базы данных (АБД). Как видно по сравнению с АД, обязанности АБД более связаны с решением технических проблем.
Разработчики баз данных - это такая группа специалистов, которая функционирует во время проектирования, создания и реорганизации базы данных и результатом деятельности которой является хорошо спроектированная БД, снабжающая достоверной и непротиворечивой информацией всех заинтересованных в этом лиц.
При проектировании больших БД все разработчики распадаются на две группы:
разработчики логической базы данных;
разработчики физической базы данных.
Разработчики логической БД занимаются выявлением интересующих объектов и их свойств, связей между объектами и тех ограничений, которые необходимо наложить на хранимые данные. Осуществление своей деятельности указанные разработчики выполняют в два этапа, которые в последующих главах будут рассмотрены подробно:
разработка концептуальной модели БД;
разработка логической модели БД.
Разработчики физической БД должны разбираться в функциональных возможностях выбранной СУБД, знать все варианты возможного физического воплощения полученной логической модели данных и понимать их достоинства и недостатки с тем, чтобы выбрать наиболее оптимальный вариант для данного случая и правильно выстроить всю стратегию хранения и использования данных.
Сразу после создания БД следует приступить к разработке приложений, предоставляющих пользователям необходимые им функциональные возможности. Именно эту работу выполняют прикладные программисты.
Пользователи. База данных проектируется, создается и поддерживается для того, чтобы обслуживать информационные потребности конечных пользователей. Для них разрабатываются такие приложения, которые позволяют в максимальной степени упростить выполняемые ими операции.
Чтобы различать представления данных конечными пользователями, программистами и АБД создаются разные уровни моделей данных. Их общая структура представлена на рисунке 2.1.
2
Рис.2.1. Уровни моделей данных
Основным назначением трехуровневой архитектуры является обеспечение независимости от данных. Суть этой независимости заключается в том, что изменения на нижних уровнях никак не влияют на верхние уровни.[3]
Основное различие между указанными выше тремя типами моделей данных (концептуальной, логической и физической) состоит в способах представления взаимосвязей между объектами. При проектировании БД требуется различать взаимосвязи между объектами, между свойствами одного объекта и между свойствами различных объектов.
2.4. Жизненный цикл базы данных
Как и любой программный продукт, база данных обладает собственным жизненным циклом (ЖЦ БД). Главной составляющей в жизненном цикле БД является создание единой базы данных и программ, необходимых для ее работы. Жизненный цикл системы базы данных определяет и жизненный цикл всей информационной системы организации, поскольку база данных является фундаментальным компонентом информационной системы.
ЖЦ БД включает в себя следующие основные этапы:
· планирование разработки базы данных;
· определение требований к системе;
· сбор и анализ требований пользователей;
· проектирование базы данных:
· концептуальное проектирование базы данных;
· логическое проектирование базы данных;
· физическое проектирование базы данных;
· разработка приложений;
· реализация;
· загрузка данных;
· тестирование;
· эксплуатация и сопровождение.
2.5. Модели представления данных
С ростом популярности СУБД в 70-80-х годах появилось множество различных моделей данных. У каждой из них имелись свои достоинства и недостатки, которые сыграли ключевую роль в развитии реляционной модели данных, появившейся во многом благодаря стремлению упростить и упорядочить первые модели данных.
Модель данных (МД) - это некоторая абстракция, в которой отражаются самые важные аспекты функционирования выделенной предметной области, а второстепенные - игнорируются. Модель данных включает в себя набор понятий для описания данных, связей между ними и ограничений, накладываемых на данные.
Существуют три основные МД и их комбинации, на которых основываются современные БД: реляционная модель данных (РМД), сетевая модель данных (СМД), иерархическая модель данных (ИМД).[3]
Основное различие между этими моделями данных состоит в способах описания взаимодействий между объектами и атрибутами. Взаимосвязь выражает отношение между множествами данных.
Используют взаимосвязи "один к одному", "один ко многим" и "многие ко многим". "Один к одному" - это взаимно однозначное соответствие, которое устанавливается между одним объектом и одним атрибутом. "Один ко многим" - это соответствие между одним объектом и многими атрибутами. "Многие ко многим" - это соответствие между многими объектами и многими атрибутами.
Рассмотрим эти модели данных более подробно.
реляционная БД представляет собой набор таблиц, с которыми пользователь привык работать;
не нужно помнить пути доступа к данным и строить алгоритмы и процедуры обработки своего запроса;
реляционные языки легки для изучения и освоения, в то время как языки общения с иерархической и сетевой моделями предназначены для программистов и мало пригодны для пользователей;
Достоинства обработки данных реляционной БД:
Связность. Реляционное представление дает ясную картину взаимосвязей атрибутов из различных отношений;
Точность. Направленные связи в реляционной БД отсутствуют. Отношения по своей природе обладают более точным смыслом и поддаются манипулированию с использованием таких средств, как алгебра и исчисление отношений, обеспечивающих наглядность и гибкость модели данных;
Гибкость. Операции проекции и объединения позволяют разрезать и склеивать отношения, так что программист может получать разнообразные файлы в нужной форме;
Секретность. Контроль секретности упрощается. Для каждого отношения имеется возможность задания правомерности доступа, засекреченные показатели можно выделить в отдельные отношения с проверкой прав доступа;
Простота внедрения. Физическое размещение однородных (табличных) файлов намного проще, чем размещение иерархических и сетевых структур;
Независимость данных. БД должна допускать возможность расширения, т.е. добавления новых атрибутов и отношений.[7]
Поскольку среди рассмотренных логических моделей данных реляционная обладает значительными преимуществами и малыми недостатками, то она и будет взята в основу для построения СУБД. Рассмотрим ее более подробно.
Имя таблицы - это имя, по которому к таблице можно обратиться в свойствах, методах и операторах SQL;
Столбцы таблицы - это колонка таблицы, содержащая все данные, относящиеся к заданному полю таблицы. Каждый столбец имеет имя и тип данного;
Табличные и столбцовые ограничения - ограничения целостности, определенные на уровне таблицы или на уровне столбца;
Данные таблицы - информация, которая сохранена в таблице. Все данные таблицы хранятся в строках, каждая из которых содержит порции информации в столбцах, определенных в структуре таблицы. Данные - та часть таблицы, к которой обычно должны иметь доступ пользователи приложения. На пересечении каждой строки с каждым столбцом таблицы содержится в точности одно значение данных.
Все значения, содержащиеся в одном и том же столбце, являются данными одного типа. Множество значений, которые могут содержаться в столбце, называется доменом этого столбца.
У каждого столбца в таблице есть своё имя, которое обычно служит заголовком столбца. Все столбцы в одной таблице должны иметь уникальные имена, однако разрешается присваивать одинаковые имена столбцам, расположенным в различных таблицах. Столбцы таблицы упорядочены слева направо, и их порядок определяется при создании таблицы. В любой таблице всегда есть как минимум один столбец. В стандарте ANSI/ISO не указывается максимально допустимое число столбцов в таблице, однако почти во всех коммерческих СУБД этот предел существует и обычно составляет примерно 255 столбцов.
В отличие от столбцов, строки таблицы не имеют определённого порядка. Это значит, что если последовательно выполнить два одинаковых запроса для отображения содержимого таблицы, нет гарантии, что оба раза строки будут перечислены в одном и том же порядке.
В таблице может содержаться любое количество строк. Вполне допустимо существование таблицы с нулевым количеством строк. Такая таблица называется пустой. Пустая таблица сохраняет структуру, определённую её столбцами, просто в ней не содержится данные. Стандарт ANSI/ISO не накладывает ограничений на количество строк в таблице, и во многих СУБД размер таблиц ограничен лишь свободным дисковым пространством компьютера. В других СУБД имеется максимальный предел, однако он весьма высок - около двух миллиардов строк, а иногда и больше.
2.6 Проектирование базы данных
база данных должна удовлетворять актуальным информационным потребностям организации. Получаемая информация должна по структуре и содержанию соответствовать решаемым задачам;
база данных должна обеспечивать получение требуемых данных за приемлемое время, то есть отвечать заданным требованиям производительности;
база данных должна удовлетворять выявленным и вновь возникающим требованиям всех пользователей;
база данных должна легко расширяться при реорганизации и расширении предметной области;
база данных должна легко изменяться при изменении программной и аппаратной среды.
преобразование концептуальной модели данных в логическую модель, в результате которого будет определена схема реляционной модели данных:
исключение связи типа "многие ко многим";
исключение сложных связей;
исключение рекурсивных связей (рекурсивная связь - это особый вид связи, в которой одни и те же экземпляры объекта участвуют несколько раз в разных ролях, поэтому с точки зрения их реализации относятся к нежелательным структурам);
исключение связей с атрибутами;
исключение множественных атрибутов;
исключение избыточных связей;
проверка модели с помощью концепций нормализации - целью применения этой процедуры является получение гарантий того, что каждое из отношений, полученных на основе концептуальной модели, находится, по крайней мере, в третьей нормальной форме;
проверка модели в отношении транзакций пользователей - созданная реляционная модель предметной области должна быть проанализирована в плане возможности выполнения всех транзакций, предусмотренных представлениями пользователя;
· проверка поддержки целостности данных:
возможность для атрибутов иметь пустые значения;
ограничения для доменов атрибутов;
категориальная целостность;
ссылочная целостность.
Построенная логическая модель данных в дальнейшем будет востребована на этапе физического проектирования, а также на этапе эксплуатации и сопровождения уже готовой системы, позволяя наглядно представить любые вносимые в базу данных изменения.[3]
Концептуальное и логическое проектирование - это итеративные процессы, которые включают в себя ряд уточнений, продолжающиеся до тех пор, пока не будет получен наиболее соответствующий структуре предприятия продукт.
создание описания набора реляционных таблиц и ограничений для них на основе информации, представленной в глобальной логической модели данных;
определение конкретных структур хранения данных и методов доступа к ним, обеспечивающих оптимальную производительность системы с базой данных;
разработка средств защиты создаваемой базы данных.
Физическая модель данных - модель, определяющая размещение данных на внешних носителях, методы доступа и технику индексирования. Она также называется внутренней моделью системы.[7]
Внешние модели (даталогические модели) никак не связаны с типом физической памяти, в которой будут храниться данные, и с методами доступа к этим данным. Внутренние модели (физические модели) наоборот определяют и оперируют размещением данных и их взаимосвязях на запоминающих устройствах.
Физическая организация данных оказывает основное влияние на эксплуатационные характеристики БД. Разработчики СУБД пытаются создать наиболее производительные физические модели данных, предлагая пользователям тот или иной инструментарий для настройки модели под конкретную БД.
Физическая модель данных является полностью компьютерно-ориентированной и конечные пользователи, а порой и прикладные программисты, не имеют никакого представления о том, каким образом данные запоминаются и извлекаются или каким способом организуются индексы в таблицах для быстрого поиска или ссылочная целостность.
Трехуровневая архитектура (инфологический, даталогический и физический уровни) позволяет обеспечить независимость хранимых данных от использующих их программ.
3.1 Требования к пользовательскому интерфейсу
Минимизация усилий пользователя при выполнении работы:
* сокращение длительности операций чтения, редактирования и поиска информации;
* уменьшение времени навигации и выбора команды;
* повышение общей продуктивности пользователя, заключающейся в объеме обработанных данных за определенный период времени;
* увеличение длительности устойчивой работы пользователя и др.[1]
Стилевая гибкость:
Возможность использовать различные интерфейсы с одним и тем же приложением, на практике реализуется с помощью таблицы стилей, в том числе возможность в выборе пользователем собственных установок пользовательского интерфейса (ПИ).
Наращивание функциональности:
Возможность развивать приложение без разрушения (т.е. оставаясь в рамках) существующего интерфейса.
Масштабируемость:
Возможность легко настраивать и расширять как интерфейс, так и само приложение при увеличении числа пользователей, рабочих мест, объема и характеристик данных.
Адаптивность к действиям пользователя:
Приложение должно допускать возможность ввода данных и команд множеством разных способов (клавиатура, мышь, другие устройства) и многовариантность доступа к прикладным функциям (иконы, "горячие клавиши", меню), кроме того, программа должна учитывать возможность перехода и возврат от окна к окну, от режима к режиму, и правильно обрабатывать такие ситуации.
Независимость в ресурсах:
Для создания пользовательского интерфейса должны предоставляться отдельные ресурсы, направленные на хранение и обработку данных, необходимых для поддержки пользователя (пользовательские словари, контекстно-зависимые списки, наборы данных по умолчанию или по последнему запросу, истории запросов и пр.)
Переносимость:
При переходе на другую аппаратную (программную) платформу, должен осуществляется автоматически перенос и пользовательского интерфейса, и конечного приложения.
3.1.1 Методы оценки пользовательского интерфейса
Для оценки необходимого уровня удобства интерфейса используются специальные экспертные анкеты, опросники, формуляры, check-листы.
В качестве методов используют:
* наблюдения за пользователями до использования ПИ, в процессе обучения и работы;
* отслеживание мотивации пользователя - мысли вслух, объяснение своих действий и намерений;
* постановка и протоколирование выполнения тестовых задач.
анализ производственной деятельности пользователя, определение и спецификация его бизнес-функций. Формулировка требований к работе пользователя;
построение пользовательской модели данных (ERD), формирование рабочих мест.
2. Проектирование ПИ
выбор показателей оценки пользовательского интерфейса;
разработка обобщенного сценария взаимодействия пользователя с системой (функциональной модели) и его предварительная оценка пользователями и Заказчиком (бумажный прототип ПИ);
корректировка и детализация сценария взаимодействия, выбор и дополнение стандарта (руководства) для построения прототипа;
разработка макетов и прототипов ПИ и их оценка в деловой игре, выбор окончательного варианта.
При проектировании пользовательского интерфейса приведенная выше последовательность не является строго обязательной. Проектировщик может представить диалог в экранных формах.[1]
Наиболее распространенной ошибкой разработчика является именно отсутствие четкой проработки выполняемых действий. Без этого дальнейшая реализация оказывается несогласованной и может оказаться не соответствующей квалификационным требованиям, а на практике требованиям пользователя.
3. Реализация ПИ
реализация ПИ в коде, создание тестовой версии (визуализация);
разработка средств поддержки пользователя (пользовательские словари, подсказки, сообщения, помощь и пр.) и их встраивание в программный код.
4. Испытания ПИ
тестирование тестовой версии ПИ по набору ранее определенных показателей;
подготовка пользовательской документации и разработка программы обучения.
3.2 Принципы проектирования эргономичного пользовательского интерфейса
Пользовательский интерфейс приложений базы данных является одним из важнейших компонентов системы. Интерфейс должен быть удобным и обеспечивать все функциональные возможности, предусмотренные в спецификациях требований пользователей.
При проектировании пользовательского интерфейса рекомендуется использовать следующие основные элементы и их характеристики:
содержательное название;
ясные и понятные инструкции;
логически обоснованные группировки и последовательности полей;
визуально привлекаемый вид окна или поля отчета;
легко узнаваемые имена полей;
согласованную терминологию и сокращения;
согласованное использование цветов;
визуальное выделение пространства и границ полей ввода данных;
удобные средства перемещения курсора;
средства исправления отдельных ошибочных символов и целых полей;
средства вывода сообщений об ошибках при вводе недопустимых значений;
особое выделение необязательных для ввода полей;
средства вывода пояснительных сообщений с описанием полей;
средства вывода сообщения об окончании заполнения формы.
Цель создания эргономичного интерфейса состоит в том, чтобы отобразить информацию настолько эффективно насколько это возможно для человеческого восприятия и структурировать отображение на дисплее таким образом, чтобы привлечь внимание к наиболее важным единицам информации. Основная же цель состоит в том, чтобы минимизировать общую информацию на экране и представить только то, что является необходимым для пользователя.
информация, на которую следует немедленно обратить внимание, должна всегда отображаться в видном месте, чтобы захватить внимание пользователя (например, предупреждающие сообщения и сообщения об ошибках);
информация, которая необходима не очень часто (например, средства справки) не должна отображаться, но должна быть доступна, когда потребуется;
менее срочная или менее необходимая информация не должна постоянно находиться перед пользователем, но должна быть доступна, когда понадобится;
отчеты и ссылки должны быть сгруппированы.
размещение информационных единиц на пространстве формы должно соответствовать логике ее будущего использования: это зависит от необходимой последовательности доступа к информационным единицам, частотой их использования, а также от относительной важности элементов;
важно использовать незаполненное пространство, чтобы создать равновесие и симметрию среди информационных элементов формы, для фиксации внимания пользователя в нужном направлении;
логические группы элементов необходимо отделять пробелами, строками, цветовыми или другими визуальными средствами;
взаимозависимые или связанные элементы должны отображаться в одной форме.
выбрать из предложенных альтернатив некую опцию или набор опций;
ввести некоторую информацию;
выбрать опцию из набора опций, которые могут изменяться в зависимости от текущего контекста;
подтвердить фрагмент введенной информации перед продолжением ввода.
Сообщения могут быть помещены в модальные диалоговые окна, которые вынуждают пользователя ответить на вопрос прежде, чем может быть предпринято любое другое действие. Это может быть полезно, когда система должна вынудить пользователя принять решение перед продолжением работы.
ошибки, которые основаны на неправильном понимании действия или порядка действий;
ошибки, которые возникли случайно, непреднамеренно, например опечатка при вводе текста.
Пользователь всегда будет делать ошибки, даже в отличной программной системе, поэтому в разрабатываемой системе всегда должна быть предусмотрена защита от ошибок:
принудительные действия в системе, которые предотвращают или затрудняют появление ошибок;
обеспечение хороших и информативных сообщений об ошибках;
использование обратимых действий, которые позволяют пользователям исправлять их собственные ошибки;
обеспечение нормальной диагностики системы, в процессе которой пользователю объясняется, в чем суть ошибки и пути ее исправления.[5]
4.1 Исследование предметной области применения и выявление требований конечных пользователей и решаемых задач
При разработке базы данных предполагается осуществить решение следующих задач:
1. Предоставление общей информации о вагонах. Это совокупность сведений о каждом вагоне, стоящем на подъездном пути. Включает в себя общую информацию такую как: номер вагона, инвентарный номер вагона, год изготовления, грузоподъемность, род вагона, износ, район движения.
2. Предоставление информации об имеющихся услугах.
3. Предоставление информации о том, какой цех является арендатором каждого вагона.
4. Предоставление информации об операциях с вагонами.
5. Предоставление информации о грузах, перевозимых вагонами.
6. Предоставление информации о районах движения вагонов.
7. Предоставление информации о стоимости услуг.
8. Ведение отчетности по вагонам.
Модель данных представлена в виде схемы данных на рис.4.1.
Рис.4.1. Инфологическая модель данных "сущность-связь"
Типы связей, их название, связанные сущности и атрибуты, по которым связаны сущности, представлены в таблице 4.1.
Таблица 4.1.
|
Тип связи |
Название связи |
Связь между сущностями |
Атрибуты |
|
|
Один ко многим |
относится |
Station, Operations_s_vagonom |
Id, key_Station_otpr |
|
|
Один ко многим |
относится |
Station, Operations_s_vagonom |
Id, key_Station_naznach |
|
|
Один ко многим |
относится |
Front, Operations_s_vagonom |
Id, key_Front_naznach |
|
|
Один ко многим |
относится |
Front, Operations_s_vagonom |
Id, key_Front_otpr |
|
|
Один ко многим |
относится |
Vagon, Operations_s_vagonom |
Id, key_vagon |
|
|
Один ко многим |
относится |
Rod_vagona, Vagon |
Id, key_rod_vagona |
|
|
Один ко многим |
относится |
Raion_dvizheniya, Vagon |
Id, key_Raion_dvizh |
|
|
Один ко многим |
относится |
Operations_s_vagonom, Uslugi_sv |
Id, key_vagon |
|
|
Один ко многим |
относится |
Operation, Operations_s_vagonom |
Id, key_operation |
|
|
Один ко многим |
относится |
Gruz, Operations_s_vagonom |
Id, key_Gruz |
|
|
Один ко многим |
состоит из |
Stoimost, Uslugi_sv |
Id, key_uslugi |
|
|
Один ко многим |
состоит из |
Ceha, Uslugi_sv |
Id, key_na |
|
|
Один ко многим |
относится |
Ceha, Uslugi_sv |
Id, key_s |
|
|
Один ко многим |
относится |
Vid_uslug, Stoimost |
Id, key_Vid_uslug |
|
|
Один ко многим |
относится |
Ves, Stoimost |
Id, key_ves |
|
4.2 Проектирование логической модели базы данных
В качестве даталогической модели базы данных была выбрана реляционная модель, поскольку она обладает всеми ранее перечисленными достоинствами представления структур данных и внутренних связей.
Инфологическая модель базы данных легко отображается в реляционную даталогическую модель, используя описанные ранее правила по переводу.
В результате получается четырнадцать таблиц реляционной базы данных, где каждая сущность напрямую отражается в отдельную таблицу, атрибуты каждой сущности становятся полями этой таблицы, а первичные ключи сущности становятся первичными ключами таблицы.
На данном этапе необходимо также провести нормализацию полученных таблиц с целью устранения избыточности данных. Эта процедура в дальнейшем значительно облегчит усилия, которые будут затрачиваться на поддержании таблиц базы данных в целостном состоянии.
Если проанализировать значения полей таблицы "Вагоны", то видно, что некоторые поля, такие как, Род_вагона, Район_движения принимают некоторые значения из ограниченного набора, кроме того, эти значения представляют собой текстовые константы, которые могут быть довольно большие по длине. Аналогичными свойствами обладают поля Станция_отправления, Станция_назначения, Фронт_отправления, Фронт_назначения, Операция, Груз, Вид_услуг, Цех_отправитель, Цех_получатель, Вес других таблиц. Такие значения лучше всего хранить в отдельной таблице со своими уникальными номерами, а вместо этих длинных строк подставлять значение уникальных номеров, которые назначены каждой строке. Это позволит сократить дисковое пространство для хранения данных. Пользователь, таким образом, может выбрать некоторые значения этих полей из предложенного в списке, что несколько ускорит процесс заполнения базы данных, поскольку освобождает его от набора длинной последовательности одних и тех же строк.
Правила нормализации, описанные ранее, предписывают для таких случаев заводить отдельную таблицу для каждого поля и хранить в ней все значения характерные только для одного поля. В этом случае таблицы базы данных будут нормализованы, что не накладывает требования на процедуры поддержания базы данных в целостном состоянии, даёт возможность "безболезненных изменений" в программном коде, что может существенно сократить время разработки в дальнейшем.
4.3 Проектирование физической модели базы данных
База данных организованна в популярном формате локальных баз данных Microsoft Access 2003. Основная цель при разработке Access 2003 состояла в упрощении построения и применения баз данных. Эта цель была достигнута благодаря предоставлению пользователям широкого круга средств, позволяющих легко отыскивать и применять большую часть возможностей продукта. К ним можно отнести: возможность речевого ввода, как для диктовки, так и для сценариев оперативного управления; благодаря новому дополнительному формату файлов Access 2003 ускоряется доступ пользователей и обработка больших баз данных; пользователь имеет возможность многократно отменять в конструкторе действия и восстанавливать результаты отмененного действия при работе с таблицами, запросами. Второй из основных целей разработки Access 2003 было упрощение доступа к важной информации и ее анализа, независимо от места расположения соответствующих данных. В приложении Access 2003 расширены возможности пользователя по доступу к информации баз данных корпоративного уровня, например Microsoft SQL Server.
В Access 2003 в полной мере реализовано управление реляционными базами данных. Система поддерживает первичные и внешние ключи и обеспечивает целостность данных, что предотвращает несовместимые операции обновления или удаления данных. Благодаря развитой системе определения ключевых полей и индексов при создании таблиц запросы будут выполняться с минимальными временными затратами. Кроме того, таблицы в Access 2003 снабжены средствами проверки допустимости данных, пре-дотвращающими некорректный ввод вне зависимости от того, как он осуществляется, а каждое поле таблицы имеет свой формат и стандартные описания, что существенно облегчает ввод данных. Access 2003 поддерживает все необходимые типы полей, в том числе, текстовый, числовой, счетчик, денежный, дата/время, MEMO, логический, гиперссылка и поля объектов OLE. Такое разнообразие типов данных может отвечать даже самым изысканным задачам, которым призвана служить создаваемая база данных. Кроме того, предусмотрена защита на уровне пользователя, что позволяет контролировать доступ к данным отдельных пользователей и целых групп.
База данных "Учет вагонов на подъездном пути на предприятии" представлена 13-ю таблицами (или по терминологии реляционных баз данных - 13-ю реляционными отношениями): Vagon, Operations_s_vagonom, Uslugi_sv, Stoimost, Station, Front, Rod_vagona, Raion_dvizheniya, Operation, Gruz, Ceha, Vid_uslug, Ves. Рассмотрим структуру каждой более подробно.
В таблице Vagon представлена общая информация о вагонах. Поля, их типы, и назначение представлены в таблице 4.2.
Таблица 4.2.
|
Имя поля |
Тип поля |
Назначение |
|
|
Id |
счетчик |
Код вагона |
|
|
myMonth |
текстовый |
Месяц |
|
|
myYear |
текстовый |
Год |
|
|
Nomer_vagona |
текстовый |
Номер вагона |
|
|
Invent_nomer |
числовой |
Инвентарный номер вагона |
|
|
Year_izgot |
текстовый |
Год изготовления вагона |
|
|
Gruzopodemnost |
числовой |
Грузоподъемность |
|
|
Key_Rod_Vagona |
числовой |
Код Рода вагона |
|
|
Iznos |
текстовый |
Износ |
|
|
Key_Raion_dvizh |
числовой |
Код Района движения |
|
Первичным ключом таблицы является поле Id, которое однозначно определяет каждую запись в таблице. Поле Id поддерживает ссылочную целостность с таблицей Operations_s_vagonom с помощью поля key_vagon.
Некоторые поля, обозначающие однотипную информацию, например, поля Key_Rod_Vagona, Key_Raion_dvizh, имеют целочисленный тип, в котором закодировано определенное значение. Значения этих кодов сведены в таблицы Rod_vagona и Raion_dvizheniya, что продиктовано соображениями экономии памяти на дисковом пространстве.
В таблице Operations_s_vagonov представлена информация об операциях, производимых с вагоном. Поля, их типы, и назначение представлены в таблице 4.3.
Таблица 4.3.
|
Имя поля |
Тип поля |
Назначение |
|
|
Id |
счетчик |
Код операции с вагоном |
|
|
Key_Station_otpr |
числовой |
Код станции отправления |
|
|
Key_Front_otpr |
числовой |
Код фронта отправления |
|
|
Key_Station_naznach |
числовой |
Код станции назначения |
|
|
Key_Front_naznach |
числовой |
Код фронта назначения |
|
|
myDate |
дата/время |
Дата проведения операции |
|
|
myTime |
текстовый |
Время проведения операции |
|
|
Key_Operation |
числовой |
Код операции |
|
|
Key_Gruz |
числовой |
Код груза |
|
|
Weight |
числовой |
Вес |
|
|
N_dor_ved |
числовой |
Номер дорожной ведомости |
|
|
N_ved |
числовой |
Номер ведомости |
|
|
Key_Vagon |
числовой |
Код вагона |
|
Первичным ключом является поле Id, однозначно определяющее любую запись в таблице. Поле Id поддерживает ссылочную целостность с таблицей Uslugi_sv с помощью поля key_vagon и показывает операции и услуги для каждого вагона. Поля, обозначающие однотипную информацию, например, поля Key_Station_otpr, Key_Front_otpr, Key_Station_naznach, Key_Front_naznach, Key_Operation, Key_Gruz, Key_Vagon. Имеют целочисленный тип, в котором закодировано определенное значение. Значения этих кодов сведены в таблицы Station, Front, Operation, Gruz и Vagon, что продиктовано соображениями экономии памяти на дисковом пространстве. Поля myDate, myTime, N_dor_ved, N_ved были введены для учета времени занесения информации в БД.
Таблица Uslugi_sv представляет собой список предоставляемых услуг с их конечной стоимостью. Поля, их типы, и назначение представлены в таблице 4.4.
Таблица 4.4.
|
Имя поля |
Тип поля |
Назначение |
|
|
Id |
числовой |
Код услуги со стоимостью |
|
|
Zakaz |
текстовый |
Номер заказа |
|
|
Key_vagon |
числовой |
Код вагона |
|
|
Key_uslugi |
числовой |
Код услуги |
|
|
Key_na |
числовой |
Код цеха получателя |
|
|
Key_s |
числовой |
Код цеха оправителя |
|
|
cena |
денежный |
Стоимость услуги |
|
Первичным ключом является поле Id, однозначно определяющее любую запись в таблице. Поля Key_vagon, Key_uslugi, Key_na, Key_s имеют целочисленный тип, в котором закодировано определенное значение. Значения этих кодов сведены в таблицы Vagon, Stoimost, Ceha, что продиктовано соображениями экономии памяти на дисковом пространстве. Поле Cena является вычисляемым полем.
В таблице Stoimost представлена информация о стоимости предоставления услуги за единицу измерения. Поля, их типы, и назначение представлены в таблице 4.5.
Таблица 4.5.
|
Имя поля |
Тип поля |
Назначение |
|
|
Id |
счетчик |
Код стоимости |
|
|
Key_Vid_uslug |
текстовый |
Код вида услуги |
|
|
Key_ves |
числовой |
Код единицы измерения |
|
|
Stoimost |
денежный |
Стоимость за единицу измерения |
|
Первичным ключом является поле Id. Поле key_uslugi поддерживает ссылочную целостность с таблицей Uslugi_sv и хранит код услуги. Поля Key_Vid_uslug и Key_ves имеют целочисленный тип, в котором закодировано определенное значение. Значения этих кодов сведены в таблицы Vid_uslug и Ves, что продиктовано соображениями экономии памяти на дисковом пространстве. Поле Stoimost является вычисляемым полем.
В таблице Station представляет собой список станций, по которым двигаются вагоны. Поля, их типы, и назначение представлены в таблице 4.6.
Таблица 4.6.
|
Имя поля |
Тип поля |
Назначение |
|
|
Id |
счетчик |
Код станции |
|
|
Station |
текстовый |
Название станции |
|
Первичным ключом является поле Id. Поля key_station_otpr и key_station_naznach поддерживают ссылочную целостность с таблицей Operations_s_vagonom.
В таблице Front представлен список фронтов прибытия и отправления. Поля, их типы, и назначение представлены в таблице 4.7.
Таблица 4.7.
|
Имя поля |
Тип поля |
Назначение |
|
|
Id |
счетчик |
Код фронта |
|
|
Front |
текстовый |
Фронт |
|
Первичным ключом является поле Id. Поля key_front_otpr и key_front_naznach поддерживают ссылочную целостность с таблицей Operations_s_vagonom. В таблице Rod vagona представлен список родов вагонов. Поля, их типы, и назначение представлены в таблице 4.8.
Таблица 4.8.
|
Имя поля |
Тип поля |
Назначение |
|
|
Id |
счетчик |
Код рода вагона |
|
|
Rod_vagona |
текстовый |
Род вагона |
|
Первичным ключом является поле Id. Поле key_Rod_vagona поддерживает ссылочную целостность с таблицей Vagon.
В таблице Raion_dvizheniya представлен список районов движения вагонов. Поля, их типы, и назначение представлены в таблице 4.9.
Таблица 4.9.
|
Имя поля |
Тип поля |
Назначение |
|
|
Id |
счетчик |
Код района движения |
|
|
Raion_dvizh |
текстовый |
Район движения |
|
Первичным ключом является поле Id. Поле key_Raion_dvizh поддерживает ссылочную целостность с таблицей Vagon. В таблице Operation представлен список предоставляемых операций. Поля, их типы, и назначение представлены в таблице 4.10.
Таблица 4.10.
|
Имя поля |
Тип поля |
Назначение |
|
|
Id |
счетчик |
Код операции |
|
|
Operation |
текстовый |
Наименование операции |
|
Первичным ключом является поле Id. Поле key_Operation поддерживает ссылочную целостность с таблицей Operations_s_vagonom. В таблице Gruz представлен список грузов, перевозимых вагонами. Поля, их типы, и назначение представлены в таблице 4.11.
Таблица 4.11.
|
Имя поля |
Тип поля |
Назначение |
|
|
Id |
счетчик |
Код груза |
|
|
Gruz |
текстовый |
Наименование груза |
|
Первичным ключом является поле Id. Поле key_Gruz поддерживает ссылочную целостность с таблицей Operations_s_vagonom. В таблице Ceha представлен список цехов, участвующих в операциях с вагонами. Поля, их типы, и назначение представлены в таблице 4.12.
Таблица 4.12.
|
Имя поля |
Тип поля |
Назначение |
|
|
Id |
счетчик |
Код цеха |
|
|
N_ceha |
текстовый |
Номер цеха |
|
|
Bal_schet |
числовой |
Балансовый счет цеха |
|
Первичным ключом является поле Id. Поля key_na и key_s поддерживают ссылочную целостность с таблицей Uslugi_sv. В таблице Vid uslug представлен список услуг, предоставляемых для работы с вагонами. Поля, их типы, и назначение представлены в таблице 4.13.
Таблица 4.13.
|
Имя поля |
Тип поля |
Назначение |
|
|
Id |
счетчик |
Код услуги |
|
|
Vid_uslug |
текстовый |
Вид услуги |
|
Первичным ключом является поле Id. Поле key_Vid_uslug поддерживает ссылочную целостность с таблицей Stoimost.
В таблице Ves представлен список единиц измерения для вычилсения стоимости услуг. Поля, их типы, и назначение представлены в таблице 4.14.
Таблица 4.14.
|
Имя поля |
Тип поля |
Назначение |
|
|
Id |
счетчик |
Код единицы измерения |
|
|
Ves |
текстовый |
Единица измерения |
|
Первичным ключом является поле Id. Поле key_ves поддерживает ссылочную целостность с таблицей Stoimost. Такой способ представления данных является наиболее удобным, поскольку позволяет легко сохранять целостность базы данных, т.к. данные находятся в одном месте, и при изменении значения нет необходимости изменять значения во всех записях таблицы, использующих это значение.
Глава 5. Реализация проекта
5.1 Набор компонентов, используемых для создания приложений
Созданная структура, схема которой представлена в Microsoft Access (рис. 5.1.), стала основой для разработки приложения, которое предоставит пользователям необходимые им функциональные возможности.
Рис. 5.1. Схема данных
Все описанные таблицы, составляющие основу базы данных, функционируют в рамках созданной системы управления базой данных по учету вагонов на подъездном пути. СУБД по учету вагонов на подъездном пути создана средствами среды программирования Delphi 7.0 и реализует все необходимые требования, которые предъявлялись в постановке задания, и выполняет полный круг задач, с которыми сталкиваются работники предприятия по учету компьютерного оборудования.
5.2 Работа с режимами программы Diplom
В данной дипломной работе описывается информационно-справочная система по учету нахождения вагонов на подъездном пути. Для того чтобы начать работу с программой необходимо включить системный блок и монитор ПК. Для работы программы необходимо наличие операционной системы Windows 98 или выше. После загрузки ПК следует скопировать программу на жесткий диск. Для этого следует установить носитель с программой в привод, затем:
если вы находитесь в операционной системе типа DOS в командной строке, вам необходимо указать путь к приводу, в котором находится носитель с программой, например: "а:". Затем произвести копирование с носителя в заранее созданный вами каталог на жестком диске;
если вы находитесь в операционной системе Windows вам следует дважды щелкнуть левой кнопкой мышки по иконке "Мой компьютер", затем дважды щелкнуть на иконке привода, в котором установлен носитель с программой, например: "Диск 3,5 (А)". Затем следует выделить и скопировать все файлы с носителя в созданную вами папку на жестком диске.
Процедура копирования выполняется один раз после приобретении данной программы.
После процедуры копирования вам следует зайти в папку, в которую вы скопировали программу, и щелкнуть дважды левую кнопку мышки на файле diplom.exe для запуска программы. На экране появится основная форма программы (рисунок 5.2).
Рисунок 5.2
На главной форме отображена информация обо всех вагонах на подъездных путях (месяц, год, номер вагона, инвентарный номер вагона, год изготовления, износ, род вагона, район движения). При первом запуске программы список вагонов пуст.
Меню главной формы: "Файл" и "Помощь".
При открытии меню "Файл" можно увидеть подменю "Выход" и подменю "Печать отчетов" (рисунок 5.3). Подменю "выход" предназначено для выхода из программы, так же для выхода можно использовать крестик (х), располагающийся на окне в правом верхнем углу.
Рисунок 5.3
Подменю "Печать отчетов" открывает форму отчетов (рисунок 5.4)
Рисунок 5.4
В этой форме представлена вся информация, необходимая для отчетности по вагонам. Форма содержит меню "Сортировка", "Фильтрация", "Полная", "Печать".
При нажатии клавишей мыши на меню "Сортировка" появится форма "Сортировка" (рисунок 5.5).
Рисунок 5.5
В этой форме можно отсортировать информацию в отчете по выбранному одному или нескольким выбранным критериям. Для этого следует выбрать сначала тип сортировки (по возрастанию или по убыванию), затем выбрать критерий сортировки. Если сортировка производится по одному критерию, то после его выбора следует нажать мышью кнопку "Close". Если сортировка будет производиться по нескольким критериям, то после выбора каждого из них следует нажимать кнопку "Next", после окончания выбора следует нажать кнопку "Close".
При открытии меню "Фильтрация", появляется подменю "В диапазоне" и "Вне диапазона". В зависимости от выбранного критерия фильтрации, будет отобрана информация, принадлежащая указанному диапазону (в диапазоне) или не принадлежащая диапазону (вне диапазона). При нажатии на какое-либо из подменю появляется форма "Фильтрация" (рисунок 5.6).
Рисунок 5.6
Информацию можно отфильтровать либо по одному полю, либо нескольким. Управление производится аналогично управлению формой "Сортировка". Диапазон указывается в нижних полях.
Меню "Полная" позволяет отобразить все имеющиеся в БД вагоны и информацию о них.
Меню "Печать" открывает форму отчета (рисунок 5.7).
Рисунок 5.7
В форме можно увидеть информацию, которая будет выведена на печать. Для вывода на печать следует кликнуть мышью значок принтера.
Меню "Помощь" содержит подменю "Справка" и "О программе" (рисунок 5.8)
Рисунок 5.8
При входе в подменю "О программе" появляется окно со справкой о программе (в данном случае фамилия разработчика) (рисунок 5.9). При входе в меню "Справка" открывается окно помощи по работе с программой (рисунок 5.10).
Рисунок 5.9
Рисунок 5.10
В главной форме (рисунок 5.1) при нажатии правой кнопки мыши на поле в списке вагонов, появляется всплывающее меню, которое состоит из следующих пунктов: "Добавить", "Удалить" и "Редактировать".
При нажатии пункта "Добавить" появляется диалоговое окно для ввода данных (рисунок 5.11). Вводимыми данными являются: месяц и год занесения данных, номер вагона, инвентарный номер вагона, год изготовления, грузоподъемность, литер, принадлежность, износ (%), род вагона, район движения.
Рисунок 5.11
Поля Номер, Инвентарный номер, Грузоподъемность являются числовыми, а потому вводить можно только числа. В противном случае появляется диало говое окно (рисунок 5.12), в котором следует нажать "ОК" и правильно ввести данные.
Рисунок 5.12
При помещении курсора в поле Род вагона, появляется диалоговое окно (рисунок 5.13), в котором можно выбрать требуемый род вагона.
Рисунок 5.13
Поля в этом диалоговом окне можно добавлять и удалять. Для добавления данных следует в поле Род вагона ввести наименование, после чего нажать "Оk" и данные будут добавлены в список. Для удаления следует правой клавишей мыши щелкнуть на строке, которую следует удалить и в появившемся меню нажать "Удалить" левой кнопкой мыши. Для выбора данных из списка следует левой кнопкой мыши щелкнуть на нужной строке. После этой откроется диалоговое окно (рисунок 5.14) "Район движения".
Рисунок 5.14
Это диалоговое окно также можно вызвать, поместив курсор в поле "Район движения" в диалоговом окне "Информация по вагону".
Поля в диалоговом окне "Район движения" можно добавлять и удалять. Для добавления данных следует в поле Район движения ввести наименование, после чего нажать "Оk" и данные будут добавлены в список. Для удаления следует правой клавишей мыши щелкнуть на строке, которую следует удалить и в появившемся меню нажать "Удалить" левой кнопкой мыши. Для выбора данных из списка следует левой кнопкой мыши щелкнуть на нужной строке.
После заполнения всех полей следует нажать кнопку "ОК". Если заполнены были не все поля, то появится сообщение (рисунок 5.15):
Рисунок 5.15
В сообщении следует нажать кнопку "Оk" левой клавишей мыши и заполнить все поля в диалоговом окне. После чего снова нажать " Оk ". Если такая запись уже есть, то появится сообщение об этом (рисунок 5.16):
Рисунок 5.16
В сообщении следует нажать "Оk" левой клавишей мыши и проверить введенную информацию и нажать кнопку "Оk" в диалоговом окне "Информация по вагону".
Если все было введено верно, то нижняя часть диалогового окна станет активной (рисунок 5.16)
Рисунок 5.16
Нижняя часть озаглавлена как "Операции с вагоном". Здесь находится список операций, проводимых с вагоном. Изначально список пуст. Для его заполнения нужно на поле данных щелкнуть правой кнопкой мыши и выбрать из появившегося меню "Добавить". Откроется диалоговое окно "Информация по вагону" (рисунок 5.17), где нужно внести данные: Номер ведомости, Номер дорожной ведомости, Дата проведения операции, Время проведения операции, Станция отправитель, Фронт отправления, Станция получатель, Фронт получения, Операция, Груз, Вес груза.
Рисунок 5.17
Поля Номер ведомости, Номер дорожной ведомости, Вес груза являются числовыми. Поэтому в случае ввода букв или символов появится сообщение (рисунок 5.18):
Рисунок 5.18
В появившемся окне необходимо нажать "Оk" и исправить неверно введенные данные.
Данные для заполнения полей Станция отправитель, Станция получатель берутся из списков (рисунок 5.19).
Рисунок 5.19
Для выбора станции нужно щелкнуть два раза левой клавишей мышки на нужной станции. Для того чтобы добавить в список станцию нужно ввести в поле Станция отправитель/получатель название станции и нажать "Оk", после чего новая станция появится в списке. Для того чтобы удалить из списка станцию, необходимо щелкнуть правой клавишей мыши на названии станции в поле данных и в появившемся меню выбрать "Удалить". Станция будет удалена.
Данные для заполнения полей Фронт отправления, Фронт получения берутся из списков (рисунок 5.20).
Рисунок 5.20
Для выбора фронта нужно щелкнуть два раза левой клавишей мышки на нужном фронте. Для того чтобы добавить в список фронт нужно ввести в поле Фронт отправитель/получатель название станции и нажать "Оk", после чего новый фронт появится в списке. Для того чтобы удалить из списка фронт, необходимо щелкнуть правой клавишей мыши на названии фронта в поле данных и в появившемся меню выбрать "Удалить". Фронт будет удален.
Данные для заполнения поля Операция берутся из списка (рисунок 5.21).
Рисунок 5.21
Для выбора операции нужно щелкнуть два раза левой клавишей мышки на нужной операции. Для того чтобы добавить в список операцию нужно ввести в поле Операция название операции и нажать "Оk", после чего новая операция появится в списке. Для того чтобы удалить из списка операцию, необходимо щелкнуть правой клавишей мыши на названии операции в поле данных и в появившемся меню выбрать "Удалить". Операция будет удалена.
Данные для заполнения поля Груз берутся из списка (рисунок 5.22).
Рисунок 5.22
Для выбора груза нужно щелкнуть два раза левой клавишей мышки на нужном грузе. Для того чтобы добавить в список груз нужно ввести в поле Груз название груза и нажать "Оk", после чего новый груз появится в списке. Для того чтобы удалить из списка груз, необходимо щелкнуть правой клавишей мыши на названии груза в поле данных и в появившемся меню выбрать "Удалить". Груз будет удален.
После ввода всех данных необходимо нажать кнопку "Оk" в диалоговом окне "Информация по вагону".
Если все было введено верно, то нижняя часть диалогового окна станет активной (рисунок 5.23)
Рисунок 5.23
Нижняя часть озаглавлена как "Перечень работ". Здесь находится список работ, проводимых с вагоном. Изначально список пуст.
Для его заполнения нужно на поле данных щелкнуть правой кнопкой мыши и выбрать из появившегося меню "Добавить". Откроется диалоговое окно "Заказ" (рисунок 5.24), где нужно внести данные: Номер заказа, Цех заказчик, Цех исполнитель и выбрать из предлагаемого списка в нижней части диалогового окна вид услуги.
Рисунок 5.24
Поле Номер заказа является числовым. Поэтому в случае ввода букв или символов появится сообщение (рисунок 5.25):
Рисунок 5.25
В появившемся окне необходимо нажать "Оk" и исправить неверно введенные данные.
Данные для заполнения полей Цех заказчик, Цех исполнитель берутся из списков (рисунок 5.26).
Рисунок 5.26
Для выбора цеха нужно щелкнуть два раза левой клавишей мышки на нужном номере цеха. Для того чтобы добавить в список цех нужно ввести в поле Цех заказчик/исполнитель номер цеха и нажать "Оk", после чего новый номер цеха появится в списке. Для того чтобы удалить из списка номер цеха, необходимо щелкнуть правой клавишей мыши на нужном номере цеха в поле данных и в появившемся меню выбрать "Удалить". Цех будет удален.
Чтобы выбрать необходимый вид услуги из списка в нижней части диалогового окна, нужно дважды щелкнуть левой кнопкой мыши по нужной услуге. После чего данные будут добавлены. Услуги можно добавлять, удалять и редактировать.
Для добавления услуги нужно правой кнопкой мыши нажать на поле данных и в появившемся меню выбрать "Добавить". После чего появится диалоговое окно "Справочник по ценам" (рисунок 5.27).
Рисунок 5.27
В этом окне можно добавить услугу, внеся данные по ней: Вид работы, Единица измерения, Цена за единицу измерения. Исходя из этих данных, рассчитывается стоимость услуги, оказанной для конкретного вагона. После ввода данных нужно нажать кнопку "Оk". После чего новый вид услуги появится в списке.
Данные для заполнения поля Вид работы берутся из списка (рисунок 5.28).
Рисунок 5.28
Для выбора вида услуги нужно щелкнуть два раза левой клавишей мышки на нужной услуге. Для того чтобы добавить в список новую услугу нужно ввести в поле Вид услуг название услуги и нажать "Оk", после чего новая услуга появится в списке. Для того чтобы удалить из списка услугу, необходимо щелкнуть правой клавишей мыши на названии услуги в поле данных и в появившемся меню выбрать "Удалить". Услуга будет удалена.
Данные для заполнения поля Единица измерения берутся из списка (рисунок 5.29).
Рисунок 5.29
Для выбора единицы измерения нужно щелкнуть два раза левой клавишей мыши на нужной единице измерения. Для того, чтобы добавить в список новую единицу измерения нужно ввести в поле Единица измерения название единицы измерения и нажать "Оk", после чего новая единица измерения появится в списке. Для того, чтобы удалить из списка единицу измерения, необходимо щелкнуть правой клавишей мыши на названии единицы измерения в поле данных и в появившемся меню выбрать "Удалить". Единица измерения будет удалена.
Для редактирования уже имеющейся услуги, необходимо правой кнопкой мыши щелкнуть на нужной строке и в появившемся меню выбрать "Редактировать". После чего появляется окно редактирования (рисунок 5.30).
Рисунок 5.30
В этом окне можно изменить вид работы, единицу измерения и цену за единицу измерения описанным выше способом.
Для удаления какой-либо услуги из списка необходимо правой клавишей мыши нажать на нужной строке и в появившемся меню выбрать "Удалить".
После введения всех данных, в главном диалоговом окне появляется новая строка с добавленной информацией.
Также информацию можно редактировать и удалять. Для этого на нужной строке необходимо щелкнуть правой клавишей мыши и выбрать в появившемся меню "Редактировать" или "Удалить". При выборе "Редактировать" открывается окно редактирования, где можно изменять информацию описанным выше способом. При выборе "Удалить" строка удаляется из списка.
Также в главной форме организован поиск. Для этого необходимо нажать сочетание клавиш ctrl+f, после чего появится окно поиска (рисунок 5.31).
Рисунок 5.31
Поиск производится по инвентарному номеру вагона. Для поиска необходимо в поле ввести инвентарный номер вагона и нажать кнопку "Ok".
6.1 Выбор аппаратных средств
При выборе аппаратных средств для разработки программного продукта (ПП) наибольшую роль играет фактор быстродействия работы ПЭВМ. Поскольку именно от него зависит время разработки ПП, а соответственно затраты на разработку и его себестоимости.
Требования, предъявляемые к операционной системе: операционная система Win 2K SP4 или WinXP с установленными MDAC (Microsoft Data Access Components) 2.6 и ранее, а также Microsoft Jet 4.0.
Требования к аппаратной части компьютера определяются установленной операционной системой.
6.2 ERwin - современное средство проектирования баз данных
Проектирование инфологической модели базы данных осуществлялось с помощью инструментов автоматизированного проектирования и создания программ, которые принято называть CASE-инструментами (Computer-Aided Software Engineering), а именно, ERwin компании Computer Associates. Использование CASE-инструментов способствует повышению производительности труда разработчиков и обеспечению эффективности самой разрабатываемой системы.
ERwin 4.0 - мощное и простое в использовании средство конструирования баз данных, завоевавшее широкое признание и популярность. Оно обеспечивает высочайшую продуктивность труда при разработке и сопровождении приложений с использованием баз данных. ERwin позволяет наглядно отобразить структуру и основные элементы БД. Благодаря интеграции с популярными средами разработки программ, ERwin позволяет ускорить создание приложений для обработки данных.
ERwin облегчает проектирование баз данных. Для этого достаточно создать графическую ER-модель (сущность-связь), удовлетворяющую всем требованиям к данным и ввести правила для создания логической модели, которая отображает все элементы, атрибуты, отношения и группировки. Можно расширить возможности ERwin, воспользовавшись уникальной поддержкой пользовательских свойств для ввода в модель любой дополнительной информации, значимой для деятельности предприятия.
ERwin - не просто инструмент для "рисования"; он автоматизирует процесс проектирования. Например, ERwin предусматривает возможность создания каталога наиболее часто используемых атрибутов, что обеспечивает согласованность имен и описаний по всему проекту. Представления БД поддерживаются как интегрированные компоненты модели, что позволяет автоматически отображать в их описаниях изменения, внесенные в базовые таблицы. Автоматический перенос ключей обеспечивает ссылочную целостность базы данных. Кроме того, ERwin позволяет работать с большими моделями общекорпоративного масштаба, разбивая их на фрагменты и легко управляемые подмножества, предоставляя отдельным специалистам возможность сосредоточить свои усилия в определенной области. Возможность сохранения отображений позволяет хранить множество представлений одной предметной области, ориентированных на различную целевую аудиторию. Созданные с помощью ERwin модели данных можно редактировать, просматривать и распечатывать различными способами.
ERwin - не только лучший инструмент для проектирования баз данных, но и средство для их быстрого создания. ERwin оптимизирует модель в соответствии с физическими характеристиками целевой базы данных. В отличие от других инструментальных средств ERwin автоматически поддерживает согласованность логической и физической схем и осуществляет преобразование логических конструкций, таких как отношения "многие ко многим", в их реализацию на физическом уровне.
ERwin устанавливает естественную динамическую связь между моделью и базой данных, что позволяет реализовать как прямой, так и обратный инжиниринг. Используя эту связь, ERwin автоматически генерирует таблицы, представления, индексы, правила поддержания целостности ссылок (первичных и внешних ключей), устанавливает значения по умолчанию и ограничения для доменов/столбцов.
ERwin интегрирует проектирование базы данных в процесс разработки приложения. Благодаря возможностям взаимодействия с популярными средствами разработки для архитектуры клиент/сервер и Web, ERwin поддерживает соответствие между серверной базой данных и формами в клиентской части, позволяя ускорить создание высококачественных приложений.
CASE-средство ERWin было выбрано в качестве средства проектирования базы данных по следующим причинам:
ERWin поддерживает прямое (создание БД на основе модели) и обратное (генерация модели по имеющейся базе данных) проектирование для 20 типов СУБД;
увеличивает производительность труда благодаря удобному интерфейсу и уменьшает число рутинных операций, облегчает и сокращает работу;
позволяет максимально повысить производительность информационной системы благодаря поддержке работы с БД на физическом уровне, учитывая особенности каждой конкретной СУБД;
поддерживает методологию структурного моделирования;
позволяет повторно использовать компоненты созданных ранее моделей, а также использовать наработки других разработчиков, что повышает эффективность работы;
позволяет переносить структуру БД из СУБД одного типа СУБД в другой;
позволяет документировать структуру БД (позволит получить отчеты презентационного качества);
продукт можно использовать на всех стадиях жизненного цикла баз данных: при проектировании, разработке, тестировании и поддержке;
позволяет получить точную и наглядную информацию, где хранятся данные и как получить к ним доступ;
позволяет, используя визуальные средства, описать структуру БД, а затем автоматически сгенерировать файлы данных для любого типа СУБД;
продукт легко освоить.[11]
6.3 Microsoft Access 2003
Microsoft Access 2003 представляет собой мощную и устойчивую 32-разрядную систему управления реляционными базами данных (СУРБД), которая предназначена для создания настольных приложений и приложений клиент/сервер, работающих под управлением Windows 2000 и XP, а также.
Microsoft Access со дня своего появления в 1992г. остается одним из наиболее гибких и эффективных приложений пакета Office. Об этом свидетельствует развитый набор средств, достоинства которых признаются даже самыми опытными пользователями баз данных, а простота использования, присущая всем приложениям Office, делает эти средства доступными и для начинающих пользователей. В приложении Access 2003 отмеченные качества получили дальнейшее развитие, предоставив в распоряжение разработчикам и опытным пользователям новые функциональные возможности, позволяющие осуществлять доступ к важным данным и производить их глубокий анализ, а также создавать эффективные новые решения в этой области. В то же время Access упрощает для начинающих пользователей знакомство с возможностями данного приложения.
Производительность и эффективность.
Применяется ли база данных для фиксации сведений о продажах в пределах компании или просто для ведения каких-либо списков для личного пользования, работа с ней зачастую далеко не так проста и интуитивно понятна, как хотелось бы. Основная цель при разработке Access 2003 состояла в упрощении построения и применения баз данных. Эта цель была достигнута благодаря предоставлению пользователям широкого круга средств, позволяющих легко отыскивать и применять большую часть возможностей продукта.
Доступ к информации и ее анализ.
Второй из основных целей разработки Access 2003 было упрощение доступа к важной информации и ее анализа, независимо от места расположения соответствующих данных. В приложении Access 2003 расширены возможности пользователя по доступу к информации баз данных корпоративного уровня, например Microsoft SQL Server. Кроме того, в этой версии приложения Access усовершенствованы способы анализа пользователями этих данных с помощью динамических сводных таблиц и сводных диаграмм, ранее имевшихся только в приложении Excel, а также с помощью страниц доступа к данным, позволяющих пользователям распространять приложения корпоративных баз данных в Internet.
Расширенные возможности программирования для разработчиков.
Третья основная цель создателей Access состояла в предоставлении разработчикам средств, необходимых для создания развитых сложных баз данных, легко интегрирующихся со структурой данных предприятия, обеспечивая при этом прямую и обратную совместимость с существующими и новыми решениями. Access 2003 предоставляет средства для создания решений, интегрирующих и использующих преимущества Internet-стандартов, таких как XML, XSL и динамические веб-страницы. Эти решения позволяют лучше учитывать возможности совместного использования и представления данных в интрасетях и Internet.
Поддержка нескольких языков.
Последняя из целей, поставленных при разработке Access 2003, состояла в предоставлении транснациональным корпорациям и организациям, в которых пользователи говорят на различных языках, удобных способов работы с приложением. Эта цель была достигнута благодаря усовершенствованиям, позволяющим работать с разноязычными текстами в базах данных, а также отображать и обрабатывать их.
В Access в полной мере реализовано управление реляционными базами данных:
· система поддерживает первичные и внешние ключи;
· обеспечивает целостность данных на уровне ядра, что предотвращает несовместимые операции обновления или удаления данных;
· таблицы в Access снабжены средствами проверки допустимости данных, предотвращающими некорректный ввод;
· поддерживает все необходимые типы полей;
· система обеспечивает полную поддержку пустых значений;
· система Access поддерживает обработку транзакций с гарантией их целостности;
· предусмотрена защита на уровне пользователя, что позволяет контролировать доступ к данным отдельных пользователей и целых групп;
· предусмотрена контекстно-зависимая справка;
· позволяет импортировать и экспортировать файлы многих известных форматов.[12]
В дипломной работе была использована также одна из самых мощных возможностей Access, одновременно являющейся и наиболее важной - создание запросов. После подобного связывания таблицы выступают уже как одно целое, и теперь можно строить запросы применительно к любым данным в них. Можно выбирать конкретные поля, определять порядок сортировки, создавать вычисляемые выражения и вводить критерии отбора нужных записей. Созданные таким образом запросы стали основой для проектирования пользовательского интерфейса.
6.4 Язык SQL как стандартный язык баз данных
Определение реляционной системы требует, чтобы весь диалог с базой данных велся на едином языке - иногда его называют общим подъязыком данных (comprehensive data sublanguage). В мире коммерческих систем управления базами данных такой язык получил название SQL.
Язык SQL стал стандартом языков запросов для работы с реляционными базами, для архитектуры файл-сервер, клиент-сервер, а также в условиях применения системы управления распределенными базами данных, достаточно мощный язык для взаимодействия с СУБД, которая обрабатывает запрос, находит требуемые данные и посылает их пользователю.
SQL используется для манипуляций с данными (data manipulation) выборки и модификации, определения данных (data definition) и администрирования данных (data administration).
SQL является инструментом, предназначенным для обработки и чтения данных, содержащихся в компьютерной базе данных. SQL - это сокращенное название структурированного языка запросов (Structured Query Language). Как следует из названия, SQL является языком программирования, который применяется для организации взаимодействия пользователя с базой данных. На самом деле SQL работает только с базами данных реляционного типа.
В вычислительной системе имеется база данных, в которой хранится важная информация. Компьютерная программа, которая управляет базой данных, называется системой управления базой данных (СУБД). Если пользователю необходимо прочитать данные из базы данных, он запрашивает их у СУБД с помощью SQL. СУБД обрабатывает запрос, находит требуемые данные и посылает их пользователю. Процесс запрашивания данных и получения результата называется запросом к базе данных.[10]
6.4.1 Функциональные возможности языка SQL
Сегодня SQL представляет собой нечто гораздо большее, чем простой инструмент создания запросов, хотя именно для этого он и был первоначально предназначен. Несмотря на то, что чтение данных по-прежнему остается одной из наиболее важных функций SQL, сейчас этот язык используется для реализации всех функциональных возможностей, которые СУБД предоставляет пользователю, а именно:
Организация данных. SQL дает пользователю возможность изменять структуру представления данных, а также устанавливать отношения между элементами базы данных.
Чтение данных. SQL дает пользователю или приложению возможность читать из базы данных, содержащиеся в ней данные, и пользоваться ими.
Обработка данных. SQL дает пользователю или приложению возможность изменять базу данных, т.е. добавлять в нее новые данные, а также удалять или обновлять уже имеющиеся в ней данные.
Управление доступом. С помощью SQL можно ограничить возможности пользователя по чтению и изменению данных и защитить их от несанкционированного доступа.
Совместное использование данных. SQL координирует совместное использование данных пользователями, работающими параллельно.
Целостность данных. SQL позволяет обеспечить целостность базы данных, защищая ее от разрушения из-за несогласованных изменений или отказа системы.[10]
Таким образом, SQL является достаточно мощным языком для взаимодействия с СУБД.
6.5 Среда Delphi как средство для разработки СУБД
При разработке системы учета компьютерного оборудования на предприятии главными критериями выбора программных средств разработки являлись:
скорость разработки приложений;
возможность быстрого внесения изменений в программу;
возможность редактирования и просмотра БД, используя средства разработки.
Среди большого разнообразия продуктов для разработки приложений Delphi занимает одно из ведущих мест. С помощью Delphi написано колоссальное количество приложений, десятки фирм и тысячи программистов разрабатывают для Delphi дополнительные компоненты.
В основе такой общепризнанной популярности лежит тот факт, что Delphi, как никакая другая система программирования, удовлетворяет изложенным выше критериям. Действительно, приложения с помощью Delphi разрабатываются быстро, причем взаимодействие разработчика с интерактивной средой Delphi оставляет ощущение комфорта. Delphi-приложения эффективны, если разработчик соблюдает определенные правила. Эти приложения надежны и при эксплуатации обладают предсказуемым поведением.
Пакет Delphi - продолжение линии компиляторов языка Pascal корпорации Borland. Pascal как язык очень прост, а строгий контроль типов данных способствует раннему обнаружению ошибок и позволяет быстро создавать надежные и эффективные программы.
Язык, на котором предстоит работать пользователю Delphi, отличается от Pascal не только наличием множества новых понятий и конструкций, но и идейно: в нем вместо минимизации числа понятий и использования самых простых конструкций, предпочтение отдается удобству работы профессионального пользователя. Язык Turbo Pascal существенно превосходит Basic за счет полноценного объектного ориентированного подхода (ООП). [2]
По сравнению с традиционными способами программирования ООП обладает рядом преимуществ. Главное из них заключается в том, что эта концепция в наибольшей степени соответствует внутренней логике функционирования операционной системы (ОС) Windows. Программа, состоящая из отдельных объектов, отлично приспособлена к реагированию на события, происходящие в ОС. К другим преимуществам ООП можно отнести большую надежность кода и возможность повторного использования отработанных объектов.
6.5.1 Высокопроизводительный компилятор в машинный код
Компиляторы языка Pascal компании Borland никогда не заставляли пользователя подолгу ждать результатов компиляции. Производители утверждают, что на сегодня данный компилятор - самый быстрый в мире. Компилятор, встроенный в Delphi позволяет обрабатывать 120 тыс. строк исходного текста в минуту на машине 486/33 или 350 тыс. - при использовании процессора Pentium/90. Он предлагает легкость разработки и быстрое время проверки готового программного блока, характерного для языков четвертого поколения (4GL) и в то же время обеспечивает качество кода, характерного для компилятора 3GL.
В смысле проектирования Delphi мало отличается от проектирования в интерпретирующей среде, однако после выполнения компиляции мы получаем код, который исполняется в 10-20 раз быстрее, чем код при помощи интерпретатора. В Delphi компиляция производится непосредственно в родной машинный код. Это не может не сказаться на фактическом быстродействии готового приложения.
По всей вероятности, такая высокая скорость объясняется в первую очередь отказом от демонстрации в процессе работы числа скомпилированных строк. Следует отметить также, что благодаря опции оптимизации сегментов удается существенно сократить размер выполняемого файла. Можно запустить компилятор в режиме проверки синтаксиса. При этом наиболее длительная операция компоновки и изготовления исполняемого файла выполняться не будет. Среда Delphi включает в себя такие технические средства - интегрированный отладчик, пакетный компилятор и утилиты WinSight и WinSpector. Основное назначение утилиты WinSight - наблюдение за системой передачи сообщений Windows. Утилита WinSpector - позволяет узнать причины ошибочного завершения того или иного приложения.[2]
6.5.2 Библиотека визуальных компонент
Delphi служит средством для быстрого создания широкого класса Windows-приложений. Delphi учитывает многие новейшие достижения в программировании и практике создания приложений и предназначен для визуального программирования, когда разработчик видит большую часть результатов непосредственно на экране монитора уже в процессе работы, связанной с созданием программы. Визуальное программирование позволяет быстрее создать интерфейс программы, сделать его более качественным за счет наилучшего расположения информации на экране монитора, избежать многих ошибок еще на этапе проектирования.
Все классы библиотеки визуальных компонентов произошли от группы базовых классов, которые лежат в основе иерархии Visual Component Library (VCL). Поэтому иерархия базовых классов VCL продумана чрезвычайно тщательно - ведь на их основе создано все множество компонентов, используемых в Delphi. Особое место среди базовых классов, помимо TObject, занимают TComponent (от него происходят все компоненты) и TControl (от него происходят все элементы управления). В целом иерархия базовых классов обеспечивает полноценную работу разработчиков в Delphi, позволяя проектировать любые типы приложений.
Вслед за классом TComponent в иерархии базовых классов располагается группа из трех классов, которые обеспечивают создание различных визуальных компонентов. Визуальные компоненты - это разнообразные стандартные для Windows и специальные (созданные разработчиками Inprise) элементы управления.
Визуальные компоненты должны уметь отобразить себя на экране монитора и реагировать на целый ряд новых событий (реакция на мышь и клавиатуру, движение курсора и т. д.). Для этого в них встроен специальный механизм, обеспечивающий взаимодействие компонентов с графической подсистемой ОС (GUI).
Впервые в составе Палитры компонентов Delphi 7 появились специализированные компоненты, позволяющие настраивать цветовую палитру всех возможных деталей пользовательского интерфейса одновременно. Все они представляют собой контейнер, содержащий цвета для раскраски различных деталей элементов управления. Разработчику необходимо лишь настроить эту цветовую палитру и по мере необходимости подключать к пользовательскому интерфейсу приложения.
поиск местоположения базы данных;
поиск таблицы, ее открытие и чтение служебной информации;
чтение данных в соответствии с форматом хранения данных и т. д.
Одним из традиционных способов взаимодействия приложения, созданного в среде разработки Delphi, и базы данных является использование процессора баз данных Borland Database Engine 5. Он представляет собой набор динамических библиотек, функции которых позволяют не только обращаться к данным, но и эффективно управлять ими на стороне приложения.
Для работы с источниками данных при посредстве BDE в Delphi имеется специальный набор компонентов, расположенных на странице BDE Палитры компонентов.
BDE взаимодействует с базами данных при посредстве драйверов (например, ODBC). Для особенно распространенных локальных СУБД разработан набор стандартных драйверов. Работа с наиболее распространенными серверами БД осуществляется при помощи драйверов системы SQL Links.
Однако BDE не претендует на всеобъемлющую универсальность и имеет некоторые недостатки. Это, например, снижение скорости работы приложения, недостатки реализации некоторых драйверов и т. д.
Наряду с традиционными инструментами доступа к данным Borland Database Engine и ODBC в приложениях Delphi можно применять технологию Microsoft ActiveX Data Objects (ADO) - точнее Microsoft Data Access Components (MDAC), которая основана на возможностях СОМ, а именно интерфейсов OLE DB, который превосходит ODBC по скорости.
Данными для ADO могут быть как привычные таблицы Access или серверные базы MS SQL или Oracle, а также Microsoft Active Directory Service, XML-файлы и т.п.
Технология ADO завоевала популярность у разработчиков, благодаря универсальности -- базовый набор интерфейсов OLE DB имеется в каждой современной операционной системе Microsoft.
В Палитре компонентов Delphi есть страница ADO, содержащая набор компонентов, позволяющих создавать полноценные приложения БД, обращающиеся к данным через ADO.[2]
7.1 Постановка задачи
Сосредоточенная однопроцессорная БД с параметрами: кор.оп./сек; бит; сек/запр; бит/запр; бит/такт.обм.; , использует при функционировании технологию интерактивного ЧМВ с требуемым циклом сек/цикл, причем максимальная сложность выполнения запроса оператора с реакцией сек/цикл возникает при условиях: запр/цикл; инстр/цикл при бит/инстр. Обосновать реализуемость применяемой в информационно-справочной АСОИУ технологии информационного обмена по результатам анализа параметра lсл_доп - предельно допустимой длины слова - при выполнении каждого из запросов к ОП.
7.2. Расчетные соотношения
1. Определение значения усредненной части объема КЭШа модуля ЦП, отведенной под запись программ в цикле обработки:
2. Определение значения части объема СОЗУ, заполняемой/опустошаемой данными:
3. Определение значения времени реакции БД на запрос чел/оп:
4. Определение значения эффективной интенсивности процесса сопутствующего информ. обмена:
5. Определение значений общего времени выполнения запроса информационного слова в ОП, максимальной интенсивности, длительности этапа разгона процессора в начале цикла обработки, номинальной интенсивности сопутствующего информационного обмена, длительности этапа торможения процессора, длительности этапа переключения процессора:
6. Определение значения такта процессора:
7. Определение значения такта системной шины:
8. Определение значения числа блоков данных, необходимого для передачи информационного слова из ОП в СОЗУ:
9. Определение значения предельно допустимой длины слова:
7.3 Вывод
Система реализуема, т.к. выполняется условие:
меньше
Глава 8. Расчет затрат на создание программного обеспечения и оценка технико-экономической эффективности разработанного программного обеспечения
8.1 Расчет затрат на разработку системы учета компьютерного вагонов на подъездном пути на предприятии
Расчет затрат на разработку необходим для обоснования экономической эффективности системы. Плановые затраты на разработку включают все расходы, связанные с ее выполнением, независимо от источника их финансирования. Определение затрат на разработку производится путем составления калькуляции плановой себестоимости. Она является основным документом, на основании которого осуществляется планирование и учет затрат на выполнение.
Смета затрат включает следующие статьи:
- основная заработная плата разработчиков информационной системы;
- дополнительная заработная плата разработчиков информационной системы;
- отчисления на социальные страхования;
- расчет затрат на амортизацию ЭВМ;
- расходы на электроэнергию, используемую при разработке информационной системы;
- накладные расходы.
Рассмотрим более подробно каждую из указанных статей затрат.
8.2 Расчет затрат на основную заработную плату разработчикам
Оплата труда представляет совокупность средств, выплаченных работникам в денежной и натуральной форме как за отработанное время, выполненную работу, так и в установленном законодательством порядке за неотработанное время.
Начисление основной заработной платы производится в зависимости от принятых на предприятии форм оплаты труда. При повременной оплате труда основная заработная плата начисляется работникам за фактически отработанное время, а при сдельной за фактически выполненную работу.
Повременная форма оплаты труда находит применение при расчете заработной платы рабочих, служащих, специалистов и руководителей. При этой форме оплаты труда заработная плата рассчитывается исходя из месячного должностного оклада за проработанное время. Необходимо учесть начисление доплат за сверхурочные работы. Доплата начисляется сверх повременного заработка из расчета 20% тарифной ставки рабочего- повременщика.
Затраты на основную заработную плату (Зосн.) при повременной форме оплаты труда рассчитываются по формуле (7.1.):
Зосн.=Омес.*Траб.*Кд/Др.мес., (7.1.)
где:
Омес. - месячный оклад разработчика программы;
Др.мес. - среднее количество рабочих дней в месяце;
Траб. - фактическое время участия в разработке программы;
Кд - коэффициент, учитывающий доплаты к основной зарплате.
При этом отношение Омес./Др.мес. характеризует среднюю дневную зарплату разработчика.
Примем в нашем проекте:
Омес. руководителя разработки программы = 7000 руб.
Омес. инженера - программиста = 5900 руб.
Омес. эксперта = 3600 руб.
Др.мес. = 21 день;
Кд = 1.2.
Результаты расчета затрат на основную заработную плату разработчиков программы представлены в таблице 8.1.
Таблица 8.1.
|
Исполнители |
Время работы, кол. дней |
Средняя дневная зарплата Омес./Др.мес., руб. |
Затраты на зарплату, руб. |
|
|
Руководитель |
30 |
333.33 |
12000 |
|
|
Инженер - программист |
20 |
280.95 |
10114.29 |
|
|
Эксперт |
10 |
171.43 |
6171.43 |
|
|
Итого |
28285.72 |
|||
8.3 Расчет дополнительной заработной платы разработчиков программы
В статье "Дополнительная заработная плата" планируются и учитываются выплаты, предусмотренные законодательством о труде или коллективными договорами за непроработанное на производстве (неявочное) время: оплата очередных и дополнительных отпусков, компенсация за неиспользованный отпуск, оплата льготных часов подросткам, оплата времени, связанного с выполнением государственных и общественных обязанностей и др. Она определяется в процентном отношении основной заработной платы.
Здоп. = Кдоп. * Зосн. (8.2.)
где:
Кдоп. - коэффициент, учитывающий величину дополнительной зарплаты разработчиков программы. Примем Кдоп. равным 0.25. На основе формулы (7.2.) определяем:
Здоп. = 0.25 * 28285.72 = 7071.43 руб.
8.4 Расчет отчислений на социальное страхование и обеспечение
В соответствии с законами Российской Федерации о пенсионном обеспечении, о занятости населения, о медицинском страховании, о государственном социальном страховании работники предприятий подлежат обязательному социальному страхованию и обеспечению.
Отчисления на социальное страхование включает в себя (в % к сумме основной и дополнительной заработной платы):
|
социальное страхование |
7.9 % |
|
|
медицинское страхование |
6 % |
|
|
пенсионный фонд |
14,0 % |
|
|
ИТОГО: |
27.9 % |
|
Таким образом, отчисления на социальное страхование и обеспечение, включаемые в состав затрат на производство рассчитывают по формуле:
Ос.с.о. = Кс.с.о. * (Зосн. + Здоп.) (8.3.)
где:
Кс.с.о. - коэффициент, учитывающий отчисления в фонд социального страхования, пенсионный фонд, медицинского страхования. На основании формулы 7.3. определяем:
Ос.с.о. = 0.279 * (28285.72 + 7071.43) = 9864.65 руб.
8.5 Расчет затрат на амортизацию ЭВМ, используемых при разработке системы учета компьютерного оборудования на предприятии
Амортизация - это процесс постепенного изнашивания основных средств и перенесения по установленным нормам их стоимости на произведенную продукцию (работы, услуги).
Начисление по установленным нормам амортизации основных средств называется амортизационными отчислениями. Нормы амортизационных отчислений установлены в процентах к балансовой (первоначальной) стоимости основных средств.
Нормы амортизации могут корректироваться в зависимости от отклонений от нормативных условий использования основных средств. Порядок их начисления определен Едиными нормами амортизационных отчислений на полное восстановление основных фондов народного хозяйства Российской Федерации, утвержденными постановлением Совета Министров СССР от 22 октября 1990 года N 1072.
Единые нормы амортизационных отчислений дифференцированы в зависимости от нормативного срока службы основных средств. Срок службы (Тсл.) - величина, обратная норме амортизационных отчислений, представляет собой отношение ста процентов к норме амортизации:
Тсл.=100/На (8.4.)
где:
На - норма амортизации в %.
Износ отражает моральное и физическое состояние объектов и является одним из критериев замены их на более совершенные, производительные, комфортабельные виды машин, оборудования и др. средств.
Расчет затрат на амортизац ию оборудования производится следующим образом:
Зам. = Сперв.*(На/100) * m * (tраб/Фд.о.) (8.5.)
где:
Сперв.- первоначальная стоимость ЭВМ, используемой при разработке программы;
На - норма амортизационных отчислений;
m - количество используемых ЭВМ;
tраб. - время работы ЭВМ;
Фд.о. - действительный годовой фонд времени работы ЭВМ.
Примем:
Сперв. = 18000 руб.,
На = 12.5 %,
m = 1 шт.,
tраб. = 30 дней * 8 ч. = 240 ч.,
Фд.о. = Кол.раб.дн. * Кол.смен * Продолж.смены =
= 252 дня* 1 смена* 8 ч. = 2016 ч.
На основе формулы (2.5) определяем:
Зам.= 267.86 руб.
Результаты расчета затрат на амортизацию ЭВМ, используемые при разработке программы, представлены в таблице 8.2.
Таблица 8.2.
|
Наименование оборудования |
Количество единиц оборудования m, шт |
Время работы оборудования tраб., ч |
Норма амортизационных отчислении, % |
Затраты на амортизацию, руб. |
|
|
IBM PC Pentium IV 1.4 ГГц |
1 |
240 |
12.5 |
267.86 |
|
8.6 Расчет затрат на электроэнергию, используемую ЭВМ в процессе разработки программы
Затраты на электроэнергию (Зэл.эн.) рассчитываются по формуле: Зэл.эн.=Цэ. * Р * m * tр (8.6.)
где:
Р - мощность ЭВМ, используемой при разработке программы;
tр - время работы ЭВМ, используемое при разработке программы;
m - количество используемых ЭВМ;
Цэ. - цена 1 кВт*ч электроэнергии.
Примем:
Р = 300 Вт;
tp = 240 ч;
m = 1 шт.;
Цэ. = 2.08 руб.
На основе формулы определяем Зэл.эн.:
Зэл.эн. = 149.76 руб.
Результаты расчета затрат на электроэнергию, используемую в процессе разработки программы, представлены в таблице 8.3.
Таблица 8.3.
|
Наименование оборудования |
Количество единиц оборудования m, шт |
Время работы оборудования tр.,ч |
Мощность оборудования, кВт |
Затраты на электро-энергию, руб. |
|
|
IBM PC Pentium IV 1.4 ГГц |
1 |
240 |
0.30 |
149.76 |
|
8.7 Расчет накладных расходов
В статью "Накладные расходы" включаются расходы на управление и хозяйственное обслуживание. По этой статье учитывается заработная плата аппарата управления и общехозяйственных служб, затраты на содержание и текущий ремонт зданий, сооружений, оборудования и инвентаря, амортизационные отчисления на их полное восстановление и капитальный ремонт, расходы по охране труда, научно-технической информации, изобретательству и рационализации. Величина накладных расходов определяется в процентах от основной и дополнительной заработной платы.
Накладные расходы (Рнакл.) рассчитываются по формуле:
Рнакл. = Кн * (Зосн.+Здоп.) (8.7.)
где:
Кн - коэффициент накладных расходов. Примем Кн равным 0.7. На основе формулы (7.7.) определяем:
Рнакл. = 0.7 * (28285.72+ 7071.43) = 24750.01 руб.
Результаты расчета затрат на разработку системы учета компьютерного оборудования на предприятии сведем в таблицу 8.4.
Таблица 8.4. Смета затрат на разработку системы учета компьютерного оборудования на предприятии
|
№ п/п |
Статьи затрат |
Затраты, руб. |
% к итогу |
|
|
1 |
Основная заработная плата разработчиков |
28285.72 |
40.18 |
|
|
2 |
Дополнительная заработная плата разработчиков |
7071.43 |
10.05 |
|
|
3 |
Отчисления на социальное страхование. |
9864.65 |
14.01 |
|
|
4 |
Амортизационные отчисления |
267.86 |
0.38 |
|
|
5 |
Расходы на электроэнергию |
149.76 |
0.21 |
|
|
6 |
Накладные расходы |
24750.01 |
35.16 |
|
|
Итого: |
70389.43 |
100% |
||
|
Затраты на разработку Сполн. |
70389.43 |
|||
8.8 Расчет затрат на эксплуатацию системы учета компьютерного оборудования на предприятии
Целью расчета затрат на эксплуатацию является получение необходимых данных для определения годового экономического эффекта от внедрения разработанной системы учета вагонов на подъездном пути на предприятии. В затраты на эксплуатацию разработанной системы включаются все расходы, связанные с ее эксплуатацией в течение года.
Смета затрат включает следующие статьи:
- основная заработная плата обслуживающего персонала системы учета компьютерного оборудования на предприятии;
- дополнительная заработная плата обслуживающего персонала системы;
- отчисления на социальные страхования;
- расчет затрат на амортизацию ЭВМ;
- расходы на электроэнергию, используемую при эксплуатации информационной системы;
- накладные расходы.
При расчетах используем те же формулы, что и в предыдущем разделе.
Примем в нашем проекте:
Омес. руководителя разработки программы = 7000 руб.
Омес. системного инженера, осуществляющего эксплуатацию информационной системы = 5900 руб.
Др.мес. = 21 день;
Кд = 1.2.
Результаты расчета затрат на основную заработную плату обслуживающего персонала информационной системы представлены в таблице 7.5.
Таблица 8.5.
|
Обслуживающий Персонал |
Время работы, дней |
Средняя дневная зарплата Омес./Др.мес, руб. |
Затраты на зарплату, руб. |
|
|
Системный инженер |
231 |
280.95 |
77880 |
|
|
Итого |
77880 |
|||
Расчет дополнительной заработной платы обслуживающего персонала программы.
Здоп. = 0.25 * 77880= 19470 руб.
Расчет отчислений на социальное страхование и обеспечение.
Ос.с.о. = 0.279*(77880+ 19470) = 27160.65 руб.
Расчет затрат на амортизацию ЭВМ, используемых при эксплуатации системы учета компьютерного оборудования на предприятии.
Примем:
Сперв. = 15000 руб.,
На = 12.5 %,
m = 6 шт.,
tраб. = 231 день * 8 ч. = 1848 ч.,
Фд.о. = 2016 ч.
На основе формулы (1.5.) определяем:
Зам.= 10312.5 руб.
Результаты расчета затрат на амортизацию ЭВМ, используемые при разработке программы, представлены в таблице 8.6.
Таблица 8.6.
|
Наименование оборудования |
Количество единиц оборудования m, шт |
Время работы оборудования tраб., ч |
Норма амортизационных отчислении, % |
Затраты на амортизацию, руб. |
|
|
CELERON 1.7 ГГц |
6 |
1848 |
25 |
10312.5 |
|
Расчет затрат на электроэнергию, используемую ЭВМ в процессе эксплуатации программы.
Примем:
Р = 300 Вт; tp = 1848 ч; m = 6;
Цэ. = 1.24 руб.
На основе формулы (1.6.) определяем Зэл.эн.:
Зэл.эн. = 4124.74 руб.
Результаты расчета затрат на электроэнергию, используемую в процессе эксплуатации программы, представлены в таблице 8.7.
Таблица 8.7.
|
Наименование оборудования |
Количество единиц оборудования m, шт |
Время работы оборудования tр.,ч |
Мощность оборудования, кВт |
Затраты на электро-энергию, руб. |
|
|
CELERON 1.7 ГГц |
6 |
1848 |
0.3 |
4124.74 |
|
Расчет накладных расходов.
Рнакл. = 0.7 * (77880 + 19470) = 68145 руб.
Результаты расчета затрат на эксплуатацию системы учета компьютерного оборудования на предприятии сведем в таблицу 8.8.
Таблица 8.8. Смета затрат на эксплуатацию системы учета компьютерного оборудования на предприятии
|
№ п/п |
Статьи затрат |
Затраты, руб. |
% к итогу |
|
|
1 |
Основная заработная плата обслуживающего персонала |
77880 |
35.82 |
|
|
2 |
Дополнительная заработная плата обслуживающего персонала |
19470 |
8.95 |
|
|
3 |
Отчисления на социальное страхование |
27160.65 |
12.49 |
|
|
4 |
Амортизационные отчисления |
20625 |
9.49 |
|
|
5 |
Расходы на электроэнергию |
4124.74 |
1.89 |
|
|
6 |
Накладные расходы |
68145 |
31.3 |
|
|
Итого: |
217405.4 |
100% |
||
|
Затраты на эксплуатацию Сэ.пр |
217405.4 |
|||
8.9 Расчет отпускной цены разрабатываемой системы учета компьютерного оборудования на предприятии
Отпускная цена разрабатываемой системы учета компьютерного оборудования на предприятии определяется как сумма полной себестоимости, планируемой прибыли и НДС.
Планируемая прибыль составляет 15% от полной себестоимости.
НДС составляет 18% от суммы полной себестоимости и планируемой прибыли.
ОЦ=Сполн.+Пр.пл.+НДС=70389.43+10558.41+12670.1=93617.94 руб.
8.10 Расчет окупаемости капитальных вложений
Расчёт окупаемости КВ производится по формуле:
Ток=КВ/(Пр.пл.*N)
где Ток - срок окупаемости;
КВ - капитальные вложения;
Пр.пл. - планируемая прибыль;
N - планируемый годовой объем продаж, шт.
Капитальные вложения равны затратам на разработку и составляют:
КВ=Сполн. = 70389.43 руб.,
Ток= 70389.43/(10558.41*20) = 0.33 года
Заключение
Таким образом, в настоящем разделе рассмотрены вопросы организационно-экономического обоснования процесса разработки и изготовления системы учета вагонов на подъездном пути на предприятии. Представлены оценки единовременных и капитальных затрат, времени окупаемости разработки, расчет основной и дополнительной заработной платы, отчисления в фонд социального страхования.
9.1 Требования к условиям эксплуатации вычислительной техники (ВТ)
|
Характеристика работы |
Наименьший размер объекта |
Контрастность объекта с фоном |
Искусственное освещение, лк |
Естественное освещение КЕО, % |
Совмещённое освещение, КЕО, % |
||||
|
При комбинированном освещении |
При общем освещении |
При верхнем или верхнебоковом |
При боковом |
При верхнем или верхнебоковом |
При боковом |
||||
|
Средней точности |
0,5-1,0 |
Малый, средний |
500 |
200 |
4 |
1,5 |
2,4 |
0,9 |
|
2. Искусственное освещение в помещениях эксплуатации ВТ должно осуществляться системой общего равномерного освещения. Допускается использование местного освещения, предназначенного для освещения зоны расположения документов.
3. Следует ограничивать прямую блесткость от источников освещения, при этом яркость светящихся поверхностей (окна, светильники и др.), находящихся в поле зрения, не должна быть более 200 кд/ кв.м.
4. Следует ограничивать неравномерность распределения яркости в поле зрения в поле зрения пользователя ВТ, при этом соотношение яркости между рабочими поверхностями не должно превышать 3:1 - 5:1, а между рабочими поверхностями и поверхностями стен и оборудования 10:1.
5. Освещенность на поверхности стола в зоне размещения рабочего документа должна быть 300 - 500 лк. Допускается установка светильников местного освещения для подсветки документов. Местное освещение не должно создавать бликов на поверхности экрана и увеличивать освещенность экрана более 300 лк.
6. Следует ограничивать отраженную блесткость на рабочих поверхностях за счет правильного выбора типов светильников и расположения рабочего места по отношению к источникам искусственного освещения. Яркость бликов на экране ВТ не должна превышать 40 кд/кв.м; яркость потолка, при применении системы отраженного освещения, не должна превышать 200 кд/кв.м.
7. Рекомендуемая освещенность для работы с экраном дисплея составляет 200 лк, а при работе с экраном в сочетании с работой над документами - 400 лк. Рекомендуемые яркости в поле зрения операторов должны лежать в пределах 1:5 - 1:10.
8. В качестве источников света при искусственном освещении должны применяться преимущественно люминесцентные лампы типа ЛБ. При устройстве отраженного освещения в административно-общественных помещениях допускается применение металлогалогенных ламп мощностью до 250 Вт. Допускается применение ламп накаливания в светильниках местного освещения. Наиболее приемлемыми являются люминесцентные лампы белого и тепло-белого света.
9. Общее освещение следует выполнять в виде сплошных или прерывистых линий светильников, расположенных сбоку от рабочих мест, параллельно линии зрения пользователя при рядном расположении ВТ. При периметральном расположении компьютеров линии светильников должны располагаться локализовано над рабочим столом, ближе к его переднему краю, обращенному к пользователю ВТ.
10. Яркость светильников общего освещения в зоне углов излучения от 50 до 90 градусов с вертикалью в продольной и поперечной плоскостях должна составлять не более 200 кд/кв.м, защитный угол светильников должен быть не менее 40 градусов.
11. Светильники местного освещения должны иметь не просвечивающий отражатель с защитным углом не менее 40 градусов.
12. Коэффициент запаса для осветительных установок общего освещения должен приниматься равным 1.4.
13. Коэффициент пульсации не должен превышать 5%, что должно обеспечиваться применением газоразрядных ламп в светильниках общего и местного освещения с высокочастотными пускорегулирующими аппаратами (ВЧ ПРА) для любых типов светильников. При отсутствии светильников с ВЧ ПРА лампы многоламповых светильников или рядом расположенные светильники общего освещения включать на разные фазы трехфазной сети.
14. Для обеспечения нормируемых значений освещенности в помещениях использования ВТ следует проводить чистку стекол оконных рам и светильников не реже двух раз в год и проводить своевременную замену перегоревших ламп.
|
Период года |
Категория работ |
Температура воздуха, град. С не более |
Относительная влажность воздуха, % |
Скорость движения воздуха, м/с |
|
|
Холодный |
легкая - 1а |
22 -24 |
40 - 60 |
0,1 |
|
|
легкая - 1б |
21 - 23 |
40 - 60 |
0,1 |
||
|
Теплый |
легкая - 1а |
23 - 25 |
40 - 60 |
0,1 |
|
|
легкая - 1б |
22 - 24 |
40 - 60 |
0,2 |
||
Примечания: к категории 1а относятся работы, производимые сидя и не требующие физического напряжения, при которых расход энергии составляет до 120 ккал/ч; к категории 1б относятся работы, производимые сидя, стоя или связанные с ходьбой и сопровождающиеся некоторым физическим напряжением, при которых расход энергии составляет от 120 до 150 ккал/ч.
2. Для повышения влажности воздуха в помещениях с ВТ следует применять увлажнители воздуха, заправляемые ежедневно дистиллированной или прокипяченной питьевой водой. В помещении ежедневно должна проводиться влажная уборка.
3. К вредным веществам, которые действуют в помещении с ВТ, относятся пыль и выделения паров спирта после профилактической чистки ВТ. Концентрация пыли в воздухе должна не превышать 0.5 мг/куб.м. Для снижения степени запыленности помещения, необходимо регулярно проветривать и осуществлять пылеуборку помещений.
4. Высокое напряжение на токоведущих частях схемы (15КВ) вызывают ионизацию воздуха с образованием положительных ионов, которые неблагоприятно воздействуют на человека. В 1куб.см воздуха содержится число положительных ионов в диапазоне от 200 до 6000. Воздействию ионизирующего излучения пользователь подвергается в процессе работы, находясь в непосредственной близости от монитора. При соблюдении требуемого расстояния между источником ионизирующих излучений и пользователем ВТ воздействие ионизирующего излучения на организм можно свести к минимуму. Уровни ионизации воздуха помещений представлены в таблице 9.3.
Таблица 9.3. Уровни ионизации воздуха помещений при эксплуатации ВТ
|
Уровни |
Число ионов в 1 см куб. воздуха |
||
|
n+ |
n- |
||
|
Минимальные |
400 |
600 |
|
|
Оптимальные |
1500 - 3000 |
300 - 5000 |
|
|
Максимально допустимые |
50000 |
50000 |
|
|
Наименование параметров |
ПДУ |
|
|
Напряженность электростатического поля |
15 кВ/м |
|
|
Напряженность электрического поля промышленной частоты (50 Гц) |
500 В/м |
|
|
Индукция/напряженность магнитного поля промышленной частоты (50 Гц) |
10мкТл/8А/м |
|
|
Напряженность электрического поля в диапазоне частот 0,03 - 300 МГц |
3 В/м |
|
4. Измерения уровней ЭМП на рабочем месте пользователя и в местах эксплуатации ВТ проводятся на расстоянии не менее 50 см от экрана на трех уровнях: 0,5 м; 1 ми 1,4 м от пола, не ранее, чем через 20 минут после включения ВТ. При этом на экране ВДТ должно быть типичное для данного вида работы изображение (текст, графики и др.). При проведении измерений должна быть включена вся вычислительная техника, ВДТ и другое используемое для работы электрооборудование, размещенное в данном помещении.
5. При превышении ПДУ ЭМП на рабочем месте пользователя и в местах эксплуатации ВТ в случае отсутствия санитарно-эпидемиологического заключения на данный тип ВТ или сомнения в качестве ВТ, по усмотрению санитарного врача, возможно проведение измерений параметров ЭМП ВТ.
6. Инструментальный контроль состояния рабочих мест пользователя и мест эксплуатации ВТ, следует производить при вводе ВТ в эксплуатацию, а затем 1 раз в 2 года силами лабораторий, аккредитованных в установленном порядке.
9.2 Требования к организации и оборудованию рабочих мест пользователей и мест эксплуатации ВТ
1. Схемы размещения рабочих мест с ВТ должны учитывать расстояния между рабочими столами с видеомониторами (в направлении тыла поверхности одного видеомонитора и экрана другого видеомонитора), которое должно быть не менее 2,0 м, а расстояние между боковыми поверхностями видеомониторов - не менее 1,2 м.
2. Рабочие места с ВТ в помещениях с источниками вредных производственных факторов должны размещаться в изолированных кабинах с организованным воздухообменом.
3. Оконные проемы в помещениях, где эксплуатируется ВТ, должны быть оборудованы регулируемыми устройствами типа: жалюзи, занавесей, внешних козырьков и др.
4. Рабочие места с ВТ при выполнении творческой работы, требующей значительного умственного напряжения или высокой концентрации внимания, рекомендуется изолировать друг от друга перегородками высотой 1,5 - 2,0 м.
6. При конструировании оборудования и организации рабочего места пользователя ВТ следует обеспечить соответствие конструкции всех элементов рабочего места и их взаимного расположения эргономическим требованиям с учетом характера выполняемой пользователем деятельности, комплектности технических средств, форм организации труда и основного рабочего положения пользователя.
7. Характеристики используемого рабочего места:
- высота рабочей поверхности стола 750 мм;
- высота пространства для ног 650 мм;
- высота сиденья над уровнем пола 450 мм;
- поверхность сиденья мягкая с закругленным передним краем;
- предусмотрена возможность размещения документов справа и слева;
- расстояние от глаза до экрана 700 мм;
- расстояние от глаза до клавиатуры 400 мм;
- расстояние от глаза до документов 500 мм;
- возможно регулирование экрана по высоте, по наклону, в левом и в правом направлениях.
8. Правильная установка рабочего стола:
- при фиксированной высоте - лучшая высота - 72 см;
- должен обеспечиваться необходимый простор для рук по высоте, ширине и глубине;
- в области сиденья не должно быть ящиков стола.
Таблица 9.5. Высота одноместного стола для занятий с ВТ
|
Рост человека в обуви, см |
Высота над полом, мм |
||
|
поверхность стола |
пространство для ног не менее |
||
|
116 - 130 |
520 |
400 |
|
|
131 - 145 |
580 |
520 |
|
|
146 - 160 |
640 |
580 |
|
|
161 - 175 |
700 |
640 |
|
|
выше 175 |
760 |
700 |
|
Примечание: ширина и глубина пространства для ног определяются конструкцией стола.
9. Правильная установка рабочего стула:
- высота должна регулироваться;
- конструкция должна быть вращающейся;
- правильная высота сиденья: площадь сиденья на 3 см ниже, чем подколенная впадина.
10. Конструкция монитора должна обеспечивать возможность фронтального наблюдения экрана путем поворота корпуса в горизонтальной плоскости вокруг вертикальной оси в пределах 30 и в вертикальной плоскости вокруг горизонтальной оси в пределах 30 с фиксацией в заданном положении.
11. Дизайн мониторов должен предусматривать окраску в спокойные мягкие тона с диффузным рассеиванием света.
12. Корпус монитора и ПЭВМ, клавиатура должны иметь матовую поверхность одного цвета с коэффициентом отражения 0,4 - 0,6 и не иметь блестящих деталей, способных создавать блики.
13. Конструкция ВДТ должна предусматривать наличие ручек регулировки яркости и контраста, обеспечивающие возможность регулировки яркости и контраста, обеспечивающие возможность регулировки этих параметров от минимальных до максимальных значений.
14. Конструкция клавиатуры должна предусматривать:
- исполнение в виде отдельного устройства с возможностью свободного перемещения;
- опорное приспособление, позволяющее изменять угол наклона поверхности клавиатуры в пределах от 5до 15;
- высоты среднего ряда клавиш не более 30 мм;
- расположение часто используемых клавиш в центре, внизу и справа, редко используемых - вверх и влево;
- выделение цветом, размером формой и местом расположения функциональных групп клавиш;
- минимальный размер клавиш - 13 мм, оптимальный - 15 мм;
- клавиши с углублением в центре и шагом 19 1 мм;
- расстояние между клавишами не менее 3 мм;
- одинаковый ход для всех клавиш с минимальным сопротивлением нажатию 0,25 Н и максимальной - не более 1,5Н;
- звуковую обратную связь от включения клавиш с регулировкой уровня звукового сигнала и возможностью его отключения.
9.3 Общие рекомендации к организации труда и отдыха при работе с ВТ
1. Режим труда и отдыха операторов непосредственно работающих с ВДТ, должен зависеть от характера выполняемой работы: при вводе данных, редактировании программ, чтении информации с экрана. Непрерывная продолжительность работы с ВТ не должна превышать 4-х часов при 8-ми часовом рабочем дне.
2. При 8-ми часовой рабочей смене основным перерывом является перерыв на обед. Дополнительно при работе с ВТ вводятся регламентированные перерывы: - для 1-ой категории работ (работа по считыванию информации с экрана ВДТ или ПЭВМ с предварительным запросом) через 2 часа от начала рабочей смены и через 2 часа после обеденного перерыва продолжительностью 15 минут каждый; - для 2-ой категории работ (работа по вводу информации) через 2 часа от начала рабочей смены и 1.5-2.0 часа после обеденного перерыва продолжительностью 15 минут каждый или продолжительностью 10 минут через каждый час работы; - для 3-ей категории работ (творческая работа в режиме диалога с ПЭВМ) через 1.5-2.0 часа от начала рабочей смены и 1.5-2.0 часа после обеденного перерыва продолжительностью 20 минут каждый или продолжительностью 15 минут через каждый час работы.
Таблица 9.6. Время регламентных перерывов в зависимости от продолжительности рабочей смены, вида и категории трудовой деятельности с ВТ
|
Категория работы с ВТ |
Уровень нагрузки за рабочую смену при видах работ с ВДТ |
Суммарное время регламентированных перерывов, мин |
||||
|
группа А, количество знаков |
группа Б, количество знаков |
группа В, час |
при 8 - ми часовой смене |
при 16 - ми часовой смене |
||
|
I |
до 20.000 |
до 15.000 |
до 2.0 |
30 |
70 |
|
|
II |
до 40.000 |
до 30.000 |
до 4.0 |
50 |
90 |
|
|
III |
до 60.000 |
до 60.000 |
до 6.0 |
70 |
120 |
|
Примечание: Время перерывов дано при соблюдении требований Санитарных правил и норм. При несоответствии фактических условий труда требованиям настоящих санитарных правил и норм, время регламентированных перерывов следует увеличить на 30 %.
3. Продолжительность непрерывной работы с ВТ без регламентированного перерыва не должна превышать 2-х часов.
4. Пользователи ВТ в производственных условиях должны проходить обязательные предварительные (при поступлении на работу) и периодические медицинские осмотры в порядке и в сроки, установленные Минздравом России.
5. К непосредственной работе с ВТ допускаются лица, не имеющие медицинских противопоказаний.
6. Женщины со времени установления беременности к выполнению всех видов работ, связанных с использованием ВТ, не допускаются. Трудоустройство беременных женщин следует осуществлять в соответствии с "Гигиеническими рекомендациями по рациональному трудоустройству беременных женщин".[15]
Заключение
В данной дипломной работе стояла задача разработки БД по учету вагонов на подъездном пути предприятия.
В процессе выполнения дипломной работы были достигнуты следующие результаты:
спроектирована концептуальная модель баз данных;
спроектирована логическая модель с учетом нормализации и ссылочной целостности данных;
осуществлена выборка СУБД и построена физическая модель, с определением полей и типов данных;
выбран комплекс технических средств;
реализованы основные программные модули системы;
На основании полученных материалов была разработана информационно-справочная система по учету вагонов на подъездном пути предприятия. Данная система направлена на автоматизацию процесса обработки информации по вагонам, а также для расчета затрат на обслуживание подвижного состава.
Список литературы
1. Вендров А.М. Проектирование программного обеспечения экономических информационных систем, Финансы и статистика, М, 2002 г.
2. Гэри Хансен, Джеймс Хансен. Базы данных. Разработка и управление, Бином, М, 2001 г.
3. Джен Л. Харрингтон. Проектирование реляционных баз данных Лори, 2006 г.
4. Джеффри Д. Ульман, Дженнифер Уидом. Основы реляционных баз данных, Лори, М, 2006 г.
5. Кен Хендерсон. Профессиональное руководство по SQL Server. Структура и реализация (+ CD-ROM), Вильямс, М, 2006 г.
6. Министерство здравоохранения Российской Федерации. Гигиенические требования к вычислительной технике, условиям и организации работы, М, 2002 г.
7. Питер Роб, Карлос Коронел. Системы баз данных: проектирование, реализация и управление, БХВ-Петербург, Сп-б, 2004 г.
8. Сорокин А.В. Разработка баз данных, Питер, Сп-б, 2005 г.
9. Томас Коннолли, Каролин Бегг, Анна Страчан. Базы данных. Проектирование, реализация и сопровождение. Теория и практика, Вильямс, М, 2001 г.
10. Шкрыль А.А. Разработка клиент-серверных приложений в Delphi, БХВ-Петербург, Сп-б, 2006 г.
11. Элисон Балтер. Профессиональное программирование в Microsoft Office Access 2003 (+CD-ROM), Вильямс, М, 2006 г.
unit Unit1;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs, Menus, ActnList, StdCtrls, Grids, DBGrids, OleServer, AccessXP, Qt {, QDialogs};
type
TForm1 = class(TForm)
MainMenu1: TMainMenu;
PopupMenu1: TPopupMenu;
ActionList1: TActionList;
N1: TMenuItem;
N3: TMenuItem;
GroupBox1: TGroupBox;
DBGrid1: TDBGrid;
add: TAction;
edit: TAction;
del: TAction;
N16: TMenuItem;
N17: TMenuItem;
N18: TMenuItem;
N2: TMenuItem;
N4: TMenuItem;
N10: TMenuItem;
N11: TMenuItem;
N12: TMenuItem;
procedure FormShow(Sender: TObject);
procedure addExecute(Sender: TObject);
procedure editExecute(Sender: TObject);
procedure delExecute(Sender: TObject);
procedure N4Click(Sender: TObject);
procedure N12Click(Sender: TObject);
procedure N10Click(Sender: TObject);
procedure DBGrid1KeyDown(Sender: TObject; var Key: Word;
Shift: TShiftState);
procedure N7Click(Sender: TObject);
procedure N2Click(Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
end;
var
Form1: TForm1;
implementation
uses Unit3, Unit4, Unit5, Unit2, Unit6, Unit7, Unit9;
{$R *.dfm}
procedure TForm1.FormShow(Sender: TObject);
begin
Tbl := Vagon;
ShowZapros;
end;
procedure TForm1.addExecute(Sender: TObject);
begin
Form6.Caption := Информация по вагону;
Tbl := Vagon;
ForEdit := -1;
Form6.ShowModal;
if ((EditMode=false)and(EditIns)) then
begin
EditMode:=true;
Form6.ShowModal;
end;
end;
procedure TForm1.editExecute(Sender: TObject);
begin
if (DataModule2.QShow[V.id]=Null) then
begin
ShowMessage(Нечего редактировать);
EditMode := false;
end
else
begin
EditMode:=True;
Form6.ShowModal;
end;
end;
procedure TForm1.delExecute(Sender: TObject);
begin
if (DataModule2.QShow[V.id]=Null) then
begin
ShowMessage(Нечего удалять);
EditMode := false;
end
else
begin
Tbl := Vagon;
pole1 := id;
pole2 := mymonth;
pole3 := myyear;
pole4 := nomer_vagona;
pole5 := invent_nomer;
pole6 := year_izgot;
pole7 := gruzopodemnost;
pole8 := liter;
pole9 := key_rod_vagona;
pole10 := iznos;
pole11 := prinadlezhnost;
pole12 := key_raion_dvizh;
pole13 := ;
ForDel := DataModule2.QShow[v.id];
DelZapros;
ShowZapros();
end;
end;
procedure TForm1.N4Click(Sender: TObject);
begin
ShowMessage(Бурцева Екатерина);
end;
procedure TForm1.N12Click(Sender: TObject);
begin
Form1.Close;
end;
procedure TForm1.N10Click(Sender: TObject);
begin
ForReport();
Form9.ShowModal;
end;
procedure TForm1.DBGrid1KeyDown(Sender: TObject; var Key: Word;
Shift: TShiftState);
var InputString: string;
begin
if ([ssCtrl] = Shift) and (key=key_F) then
begin
InputString := InputBox(Поиск, Введите инвентарный номер:, );
if InputString <> then
begin
if not DataModule2.QShow.Locate(invent_nomer,InputString,[]) then
begin
showmessage(Запись не найдена);
end;
end;
end;
end;
procedure TForm1.N7Click(Sender: TObject);
begin
{ For MyI:=0 to Form9.StringGrid1.RowCount-1 do
begin
Form9.StringGrid1.Cells[0,MyI] := Form1.DBGrid1.Columns[MyI].Title.Caption;
end; }
{ for tmpI:=0 to 10 do
Form9.StringGrid1.Cells[1,tmpI] := ;}
{ Form9.StringGrid1.Enabled := true;
Form9.Button1.Enabled := true;
Form9.Button1.Caption := Искать;
Form9.ShowModal();}
end;
procedure TForm1.N2Click(Sender: TObject);
begin
winhelp(Form1.Handle,help.hlp,HELP_CONTEXT,1);
end;
end.
unit Unit2;
interface
uses
SysUtils, Classes, DB, ADODB;
type
TDataModule2 = class(TDataModule)
ADOConnection1: TADOConnection;
Query1: TADOQuery;
DS1: TDataSource;
QShow: TADOQuery;
DSshow: TDataSource;
Qtmp: TADOQuery;
DStmp: TDataSource;
QOSV: TADOQuery;
DSOSV: TDataSource;
Quslugi: TADOQuery;
DSuslugi: TDataSource;
QSelUs: TADOQuery;
DSselUs: TDataSource;
QueryRep: TADOQuery;
DSQueryRep: TDataSource;
ADOQuery1: TADOQuery;
DataSource1: TDataSource;
private
{ Private declarations }
public
{ Public declarations }
end;
var
DataModule2: TDataModule2;
implementation
{$R *.dfm}
end.
unit Unit3;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs, StdCtrls, Grids, DBGrids, Menus, ActnList;
type
TForm3 = class(TForm)
GroupBox1: TGroupBox;
DBGrid1: TDBGrid;
Edit1: TEdit;
Button1: TButton;
Label1: TLabel;
Edit2: TEdit;
Label2: TLabel;
ActionList1: TActionList;
PopupMenu1: TPopupMenu;
del: TAction;
N1: TMenuItem;
procedure Button1Click(Sender: TObject);
procedure DBGrid1DblClick(Sender: TObject);
procedure FormShow(Sender: TObject);
procedure delExecute(Sender: TObject);
procedure FormClose(Sender: TObject; var Action: TCloseAction);
procedure DBGrid1CellClick(Column: TColumn);
private
{ Private declarations }
public
{ Public declarations }
end;
var
Form3: TForm3;
implementation
Uses Unit2, Unit4;
{$R *.dfm}
procedure TForm3.Button1Click(Sender: TObject);
begin
If (tbl=Ceha) then
begin
ToIns2 := Edit2.Text;
end;
ToIns := Edit1.Text;
InsertZapros();
ShowZapros();
Edit1.Clear;
Edit2.Clear;
end;
procedure TForm3.DBGrid1DblClick(Sender: TObject);
begin
SelTab();
Form3.Close;
end;
procedure TForm3.FormShow(Sender: TObject);
begin
Edit1.SetFocus;
Edit1.Clear;
Edit2.Clear;
If (tbl=Ceha) then
begin
Edit2.Visible := True;
Edit1.Width := 161;
Label2.Visible := True;
end
else
begin
Edit1.Width := 225;
Edit2.Visible := False;
Label2.Visible := False;
end;
end;
procedure TForm3.delExecute(Sender: TObject);
begin
ForDel := DataModule2.Query1[id];
DelZapros;
ShowZapros();
Edit1.Clear;
Edit2.Clear;
end;
procedure TForm3.FormClose(Sender: TObject; var Action: TCloseAction);
begin
InsEdit:=false;
ForEdit:=-1;
end;
procedure TForm3.DBGrid1CellClick(Column: TColumn);
begin
If (Tbl=Ceha) then
begin
Edit2.Text := SelectQ[pole3];
end;
Edit1.Text := SelectQ[pole2];
ForEdit:= SelectQ[pole1];
InsEdit := True;
end;
end.
unit Unit4;
interface
Uses ADODB;
var QueryString, TBL, pole1, pole2, Pole3, pole4, Pole5, pole6 : string;
pole7, pole8, pole9, pole10, pole11, pole12, pole13 : string;
ToIns, ToIns2, ToIns3, ToIns4, ToIns5, ToIns6, ToIns7, ToIns8 : string;
ToIns9, ToIns10, ToIns11, ToIns12, ToIns13, ForDel, ForEdit, ForOrder, Diap, TmpFiltr : string;
InsEdit,InsEdit2,InsEdit3,InsEdit4,InsEdit5 : boolean;
SelectQ : TADOQuery;
EditMode, ForSort, ForFiltr, EditMode2, EditMode3, EditMode4, EditIns, EditIns2 : boolean;
Procedure ShowZapros();
Procedure InsertZapros();
Procedure DelZapros();
Procedure SelTab();
Procedure ForReport();
implementation
Uses Dialogs, Unit2, Unit5, Unit6, Unit3, Unit7, Unit8, Unit1, Unit9, Unit10, DB;
Procedure ShowZapros();
var Polya, Tabli, Svyaz, MyKey : String;
begin
if ((Tbl=Operation)or(Tbl=Station)or(Tbl=Ceha)or
(Tbl=Front)or(Tbl=Gruz)or(Tbl=Rod_vagona)or
(Tbl=Raion_dvizheniya)or(Tbl=Ves)or(Tbl=Vid_uslug)) then
begin
QueryString := select * from + TBL + order by + pole2;
SelectQ := DataModule2.Query1;
end;
if (Tbl=Vagon) then
begin
QueryString := select * from Vagon V, Rod_vagona RV, Raion_dvizheniya RD where V.key_rod_vagona=RV.id and V.key_raion_dvizh=RD.id order by invent_nomer desc;
SelectQ := DataModule2.QShow;
end;
if (Tbl=Operations_s_vagonom) then
begin
MyKey := DataModule2.Qshow[v.id];
SelectQ := DataModule2.QOSV;
Polya := OSV.*, SNACH.*, SKON.*, FNACH.*, FKON.*, O.*, G.*;
Tabli := vagon V, station SNACH, station SKON, front FNACH, front FKON, operation O, gruz G, Operations_s_vagonom OSV;
Svyaz:= OSV.key_station_otpr=SNACH.id and OSV.key_front_otpr=FNACH.id and OSV.key_station_naznach=SKON.id and OSV.key_front_naznach=FKON.id and OSV.key_operation=O.id and OSV.key_gruz=G.id and OSV.key_vagon=V.id and OSV.key_vagon= + MyKey;
QueryString := select +Polya+ from +Tabli+ where +Svyaz;
end;
if (Tbl=Uslugi_sv) then
begin
MyKey := DataModule2.QOSV[OSV.id];
SelectQ := DataModule2.Quslugi;
Polya := USV.*, CNA.*, CS.*, ST.*, VU.*, V.*;
Tabli := Ceha CNA, Ceha CS, Uslugi_sv USV, Operations_s_vagonom OSV, Stoimost ST, Vid_uslug VU, Ves V;
Svyaz:= USV.key_uslugi=ST.id and USV.key_na=CNA.id and USV.key_s=CS.id and USV.key_vagon=OSV.id and ST.key_vid_uslug=VU.id and ST.key_ves=V.id and USV.key_vagon= + MyKey;
QueryString := select +Polya+ from +Tabli+ where +Svyaz;
end;
if (Tbl=Stoimost) then
begin
SelectQ := DataModule2.QSelUs;
Polya := VU.*, V.*, ST.*;
Tabli := Vid_uslug VU, Ves V, Stoimost ST;
Svyaz:= ST.key_vid_uslug=VU.id and ST.key_ves=V.id;
QueryString := select +Polya+ from +Tabli+ where +Svyaz;
end;
with SelectQ do
begin
Close;
SQL.Clear;
SQL.Add(QueryString);
Open;
end;
if (Tbl=Vagon) then
begin
SelectQ.Fields[0].Visible := false;
SelectQ.Fields[7].Visible := false;
SelectQ.Fields[9].Visible := false;
SelectQ.Fields[10].Visible := false;
SelectQ.Fields[12].Visible := false;
Form1.DBGrid1.Columns[0].Title.Caption :=Месяц;
Form1.DBGrid1.Columns[1].Title.Caption :=Год;
Form1.DBGrid1.Columns[2].Title.Caption :=№ вагона;
Form1.DBGrid1.Columns[3].Title.Caption :=Инв. №;
Form1.DBGrid1.Columns[4].Title.Caption :=Изгот.;
Form1.DBGrid1.Columns[5].Title.Caption :=Грузопод. т.;
Form1.DBGrid1.Columns[6].Title.Caption :=Износ %;
Form1.DBGrid1.Columns[7].Title.Caption :=Род вагона;
Form1.DBGrid1.Columns[8].Title.Caption :=Район движения;
end;
if (Tbl=Operations_s_vagonom) then
begin
SelectQ.Fields[0].Visible := false;
SelectQ.Fields[1].Visible := false;
SelectQ.Fields[2].Visible := false;
SelectQ.Fields[3].Visible := false;
SelectQ.Fields[4].Visible := false;
SelectQ.Fields[7].Visible := false;
SelectQ.Fields[8].Visible := false;
SelectQ.Fields[12].Visible := false;
SelectQ.Fields[13].Visible := false;
SelectQ.Fields[15].Visible := false;
SelectQ.Fields[17].Visible := false;
SelectQ.Fields[19].Visible := false;
SelectQ.Fields[21].Visible := false;
SelectQ.Fields[23].Visible := false;
Form6.DBGrid1.Columns[0].Title.Caption :=Дата;
Form6.DBGrid1.Columns[1].Title.Caption :=Время;
Form6.DBGrid1.Columns[2].Title.Caption :=Вес;
Form6.DBGrid1.Columns[3].Title.Caption :=№ дор. вед.;
Form6.DBGrid1.Columns[4].Title.Caption :=№ вед.;
Form6.DBGrid1.Columns[5].Title.Caption :=Станция отпр.;
Form6.DBGrid1.Columns[6].Title.Caption :=Станция пол.;
Form6.DBGrid1.Columns[7].Title.Caption :=Фронт отпр.;
Form6.DBGrid1.Columns[8].Title.Caption :=Фронт пол.;
Form6.DBGrid1.Columns[9].Title.Caption :=Операция;
Form6.DBGrid1.Columns[10].Title.Caption :=Груз;
end;
if (Tbl=Uslugi_sv) then
begin
SelectQ.Fields[0].Visible := false;
SelectQ.Fields[2].Visible := false;
SelectQ.Fields[3].Visible := false;
SelectQ.Fields[4].Visible := false;
SelectQ.Fields[5].Visible := false;
SelectQ.Fields[7].Visible := false;
SelectQ.Fields[10].Visible := false;
SelectQ.Fields[13].Visible := false;
SelectQ.Fields[14].Visible := false;
SelectQ.Fields[15].Visible := false;
SelectQ.Fields[17].Visible := false;
SelectQ.Fields[19].Visible := false;
Form7.DBGrid1.Columns[0].Title.Caption :=Заказ;
Form7.DBGrid1.Columns[1].Title.Caption :=Стоимость заказа;
Form7.DBGrid1.Columns[2].Title.Caption :=№ цеха исп.;
Form7.DBGrid1.Columns[3].Title.Caption :=БС ц.и.;
Form7.DBGrid1.Columns[4].Title.Caption :=№ цеха заказ.;
Form7.DBGrid1.Columns[5].Title.Caption :=БС ц.з.;
Form7.DBGrid1.Columns[6].Title.Caption :=Стоим. усл.;
Form7.DBGrid1.Columns[7].Title.Caption :=Вид услуги;
Form7.DBGrid1.Columns[8].Title.Caption :=Единица измерения;
end;
if (Tbl=Stoimost) then
begin
SelectQ.Fields[0].Visible := false;
SelectQ.Fields[2].Visible := false;
SelectQ.Fields[4].Visible := false;
SelectQ.Fields[5].Visible := false;
SelectQ.Fields[6].Visible := false;
Form8.DBGrid1.Columns[0].Title.Caption :=Вид услуги;
Form8.DBGrid1.Columns[1].Title.Caption :=Единица измерения;
Form8.DBGrid1.Columns[2].Title.Caption :=Стоимость;
end;
if ((Tbl=Operation)or(Tbl=Station)or(Tbl=Ceha)or
(Tbl=Front)or(Tbl=Gruz)or(Tbl=Rod_vagona)or
(Tbl=Raion_dvizheniya)or(Tbl=Ves)or(Tbl=Vid_uslug)) then
begin
SelectQ.Fields[0].Visible := false;
Form3.DBGrid1.Columns[0].Title.Caption := Form3.Label1.Caption;
If (tbl=Ceha) then
begin
Form3.DBGrid1.Columns[1].Title.Caption := Form3.Label2.Caption;
end;
end;
end;
Procedure InsertZapros();
var
QueryString, Polya: string;
YN : Boolean;
begin
YN := false;
if ((Tbl=Operation)or(Tbl=Station)or(Tbl=Ceha)or
(Tbl=Front)or(Tbl=Gruz)or(Tbl=Rod_vagona)or
(Tbl=Raion_dvizheniya)or(Tbl=Ves)or(Tbl=Vid_uslug)) then
begin
SelectQ := DataModule2.Query1;
with DataModule2.Query1 do
begin
First;
while (not Eof) do
begin
if (ForEdit <> SelectQ[id]) then
begin
if DataModule2.Query1[pole2] = ToIns then
begin
YN:=true;
Break;
end;
end;
Next;
end;
end;
if InsEdit then
begin
If (tbl=Ceha) then
begin
QueryString := UPDATE +TBL+ SET +pole2+=+#39+ToIns+#39+,+pole3+=+#39+ToIns2+#39+ where +pole1+=+ForEdit;
end
else
begin
QueryString := UPDATE +TBL+ SET +pole2+=+#39+ToIns+#39+ where +pole1+=+ForEdit;
end;
InsEdit := false;
end
else
begin
If (tbl=Ceha) then
begin
QueryString := insert into + TBL + (+pole2+,+pole3+) values (+#39+ToIns+#39+,+#39+ToIns2+#39+);
end
else
begin
QueryString := insert into + TBL + (+pole2+) values (+#39+ToIns+#39+);
end;
end;
end;
if (Tbl=Stoimost) then
begin
SelectQ := DataModule2.QSelUs;
pole1 := id;
pole2 := key_vid_uslug;
pole3 := key_ves;
pole4 := stoimost;
pole5 := ;
pole6 := ;
pole7 := ;
pole8 := ;
pole9 := ;
pole10 := ;
pole11 := ;
pole12 := ;
pole13 := ;
with SelectQ do
begin
First;
while (not Eof) do
begin
if (ForEdit <> SelectQ[ST.id]) then
begin
if ((SelectQ[pole2] = ToIns)and(SelectQ[pole3] = ToIns2)) then
begin
YN:=true;
Break;
end;
end;
Next;
end;
end;
if InsEdit2 then
begin
QueryString := UPDATE +TBL+ SET +pole2+=+#39+ToIns+#39+,+pole3+=+#39+ToIns2+#39+,+pole4+=+#39+ToIns3+#39+ where +pole1+=+ForEdit;
InsEdit2 := false;
end
else
QueryString := insert into + TBL + (+pole2+,+pole3+,+pole4+) values (+#39+ToIns+#39+,+#39+ToIns2+#39+,+#39+ToIns3+#39+);
end;
if (Tbl=Vagon) then
begin
pole1 := id;
pole2 := mymonth;
pole3 := myyear;
pole4 := nomer_vagona;
pole5 := invent_nomer;
pole6 := year_izgot;
pole7 := gruzopodemnost;
pole8 := key_rod_vagona;
pole9 := iznos;
pole10 := key_raion_dvizh;
pole11 := ;
pole12 := ;
pole13 := ;
SelectQ := DataModule2.QShow;
with SelectQ do
begin
First;
while (not Eof) do
begin
if (ForEdit <> SelectQ[v.id]) then
begin
if (SelectQ[pole5] = ToIns4) then
begin
YN:=true;
Break;
end;
end;
Next;
end;
end;
if InsEdit3 then
begin
QueryString := UPDATE +TBL+ SET +pole2+=+#39+ToIns+#39+,+pole3+=+#39+ToIns2+#39+,+pole4+=+#39+ToIns3+#39+,+pole5+=+#39+ToIns4+#39+,+pole6+=+#39+ToIns5+#39+,+pole7+=+#39+ToIns6+#39+,+pole8+=+#39+ToIns7+#39+,+pole9+=+#39+ToIns8+#39+,+pole10+=+#39+ToIns9+#39+ where +pole1+=+ForEdit;
InsEdit3 := false;
end
else
QueryString := insert into + TBL + (+pole2+, +pole3+, +pole4+, +pole5+, +pole6+, +pole7+, +pole8+, +pole9+, +pole10+) values (+#39+ToIns+#39+, +#39+ToIns2+#39+, +#39+ToIns3+#39+, +#39+ToIns4+#39+, +#39+ToIns5+#39+, +#39+ToIns6+#39+, +#39+ToIns7+#39+, +#39+ToIns8+#39+, +#39+ToIns9+#39+);
end;
if (Tbl=Operations_s_vagonom) then
begin
SelectQ := DataModule2.QOSV;
pole1 := id;
pole2 := key_station_otpr;
pole3 := key_front_otpr;
pole4 := key_station_naznach;
pole5 := key_front_naznach;
pole6 := mydate;
pole7 := mytime;
pole8 := key_operation;
pole9 := key_gruz;
pole10 := weight;
pole11 := n_dor_ved;
pole12 := n_ved;
pole13 := key_vagon;
with SelectQ do
begin
First;
while (not Eof) do
begin
if (ForEdit <> SelectQ[OSV.id]) then
begin
if ((SelectQ[pole11] = ToIns10)and(SelectQ[pole12] = ToIns11)) then
begin
YN:=true;
Break;
end;
end;
Next;
end;
end;
if InsEdit4 then
begin
QueryString := UPDATE +TBL+ SET +pole2+=+#39+ToIns+#39+,+pole3+=+#39+ToIns2+#39+,+pole4+=+#39+ToIns3+#39+,+pole5+=+#39+ToIns4+#39+,+pole6+=+#39+ToIns5+#39+,+pole7+=+#39+ToIns6+#39+,+pole8+=+#39+ToIns7+#39+,+pole9+=+#39+ToIns8+#39+,+pole10+=+#39+ToIns9+#39+,+pole11+=+#39+ToIns10+#39+,+pole12+=+#39+ToIns11+#39+,+pole13+=+#39+ToIns12+#39+ where +pole1+=+ForEdit;
InsEdit4 := false;
end
else
QueryString := insert into + TBL + (+pole2+, +pole3+, +pole4+, +pole5+, +pole6+, +pole7+, +pole8+, +pole9+, +pole10+, +pole11+, +pole12+, +pole13+) values (+#39+ToIns+#39+, +#39+ToIns2+#39+, +#39+ToIns3+#39+, +#39+ToIns4+#39+, +#39+ToIns5+#39+, +#39+ToIns6+#39+, +#39+ToIns7+#39+, +#39+ToIns8+#39+, +#39+ToIns9+#39+, +#39+ToIns10+#39+, +#39+ToIns11+#39+, +#39+ToIns12+#39+);
end;
if (Tbl=Uslugi_sv) then
begin
SelectQ := DataModule2.Quslugi;
pole1 := id;
pole2 := zakaz;
pole3 := key_vagon;
pole4 := key_uslugi;
pole5 := key_na;
pole6 := key_s;
pole7 := cena;
pole8 := ;
pole9 := ;
pole10 := ;
pole11 := ;
pole12 := ;
pole13 := ;
with SelectQ do
begin
First;
while (not Eof) do
begin
if (ForEdit <> SelectQ[USV.id]) then
begin
if (SelectQ[pole2] = ToIns) then
begin
YN:=true;
Break;
end;
end;
Next;
end;
end;
if InsEdit5 then
begin
Polya := pole2+=+#39+ToIns+#39+,+pole3+=+#39+ToIns2+#39+,+pole4+=+#39+ToIns3+#39+,+pole5+=+#39+ToIns4+#39+,+pole6+=+#39+ToIns5+#39+,+pole7+=+#39+ToIns6+#39;
QueryString := UPDATE +TBL+ SET +Polya+ where +pole1+=+ForEdit;
InsEdit5 := false;
end
else
QueryString := insert into + TBL + (+pole2+, +pole3+, +pole4+, +pole5+, +pole6+, +pole7+) values (+#39+ToIns+#39+, +#39+ToIns2+#39+, +#39+ToIns3+#39+, +#39+ToIns4+#39+, +#39+ToIns5+#39+, +#39+ToIns6+#39+);
end;
if (YN = false) then
begin
ShowMessage(QueryString);
with SelectQ do
begin
Close;
SQL.Clear;
SQL.Add(QueryString);
ExecSQL;
end;
end
else
ShowMessage(Либо такая запись есть, либо запись введена не корректно);
end;
Procedure DelZapros();
var
TmpString: string;
begin
TmpString := delete from + TBL + where + pole1 += + ForDel;
// ShowMessage(TmpString);
with DataModule2.Query1 do
begin
Close;
SQL.Clear;
SQL.Add(TmpString);
ExecSQL;
end;
end;
Procedure SelTab();
begin
if (Tbl = Rod_vagona) then
begin
Form6.Edit9.Text := SelectQ[pole2];
Form6.Edit9.Tag := SelectQ[pole1];
end;
if (Tbl = Raion_dvizheniya) then
begin
Form6.Edit10.Text := SelectQ[pole2];
Form6.Edit10.Tag := SelectQ[pole1];
end;
if (Tbl = Station)and(Form3.Caption = Станция отправитель) then
begin
Form7.Edit1.Text := SelectQ[pole2];
Form7.Edit1.Tag := SelectQ[pole1];
end;
if (Tbl = Station)and(Form3.Caption = Станция получатель) then
begin
Form7.Edit7.Text := SelectQ[pole2];
Form7.Edit7.Tag := SelectQ[pole1];
end;
if (Tbl = Front)and(Form3.Caption = Фронт отправитель) then
begin
Form7.Edit2.Text := SelectQ[pole2];
Form7.Edit2.Tag := SelectQ[pole1];
end;
if (Tbl = Front)and(Form3.Caption = Фронт получатель) then
begin
Form7.Edit8.Text := SelectQ[pole2];
Form7.Edit8.Tag := SelectQ[pole1];
end;
if (Tbl = Operation) then
begin
Form7.Edit9.Text := SelectQ[pole2];
Form7.Edit9.Tag := SelectQ[pole1];
end;
if (Tbl = Gruz) then
begin
Form7.Edit10.Text := SelectQ[pole2];
Form7.Edit10.Tag := SelectQ[pole1];
end;
if (Tbl = Ceha)and(Form3.Caption = Цех заказчик) then
begin
Form8.Edit2.Text := SelectQ[pole2];
Form8.Edit2.Tag := SelectQ[pole1];
end;
if (Tbl = Ceha)and(Form3.Caption = Цех исполнитель) then
begin
Form8.Edit3.Text := SelectQ[pole2];
Form8.Edit3.Tag := SelectQ[pole1];
end;
if (Tbl = Vid_uslug) then
begin
Form5.Edit1.Text := SelectQ[pole2];
Form5.Edit1.Tag := SelectQ[pole1];
end;
if (Tbl = Ves) then
begin
Form5.Edit2.Text := SelectQ[pole2];
Form5.Edit2.Tag := SelectQ[pole1];
end;
end;
Procedure ForReport();
var
Polya, Tabli, Tabli2, Svyaz, Svyaz2, QueryString : string;
begin
Polya := n_dor_ved,invent_nomer,OSV.mydate, OSV.mytime,STN.station as STN,FN.front as FN,CNA.n_ceha as NA,CNA.bal_schet as BSO,STK.station as STK,FK.front as FK,CS.n_ceha as CS,CS.bal_schet as CBS,G.gruz,VU.vid_uslug,VE.ves,weight,cena;
Tabli := Vagon V, Rod_vagona RV, Raion_dvizheniya RD, Operations_s_vagonom OSV, Uslugi_sv USV, Stoimost ST, Vid_uslug VU, Ves VE, Ceha CNA, Ceha CS, Station STN, Station STK;
Tabli2 := Front FN, Front FK, Operation OP, Gruz G;
Svyaz := V.key_rod_vagona=RV.id and V.key_raion_dvizh=RD.id and V.id=OSV.key_vagon and OSV.id=USV.key_vagon and ST.id=USV.key_uslugi and VU.id=ST.key_vid_uslug and VE.id=ST.key_ves and USV.key_na=CNA.id and USV.key_s=CS.id;
Svyaz2 := STN.id=OSV.key_station_otpr and STK.id=key_Station_naznach and FN.id=OSV.key_front_otpr and FK.id=OSV.key_front_naznach and OSV.key_operation=OP.id and OSV.key_gruz=G.id;
if ForSort then
begin
QueryString := select +Polya+ from +Tabli+ , + Tabli2 + where +Svyaz + and + Svyaz2 + order by + ForOrder;
end;
if ForFiltr then
begin
QueryString := select +Polya+ from +Tabli+ , + Tabli2 + where +Svyaz + and + Svyaz2 + and + TmpFiltr;
end;
if ((ForSort=false)and(ForFiltr=False)) then
begin
QueryString := select +Polya+ from +Tabli+ , + Tabli2 + where +Svyaz + and + Svyaz2 + order by invent_nomer desc;
end;
with DataModule2.QueryRep do
begin
Close;
SQL.Clear;
SQL.Add(QueryString);
if ForFiltr then
begin
Parameters.ParamByName(Par1).Value := Form10.Edit1.Text;
Parameters.ParamByName(Par2).Value := Form10.Edit2.Text;
end;
Open;
end;
Form9.DBGrid1.Columns[0].Title.Caption :=№ дор. вед.;
Form9.DBGrid1.Columns[1].Title.Caption :=Инвент. №;
Form9.DBGrid1.Columns[2].Title.Caption :=Дата;
Form9.DBGrid1.Columns[3].Title.Caption :=Время;
Form9.DBGrid1.Columns[4].Title.Caption :=Станция отпр.;
Form9.DBGrid1.Columns[5].Title.Caption :=Фронт отпр.;
Form9.DBGrid1.Columns[6].Title.Caption :=№ цеха отпр.;
Form9.DBGrid1.Columns[7].Title.Caption :=БС цеха отпр.;
Form9.DBGrid1.Columns[8].Title.Caption :=Станция заказ.;
Form9.DBGrid1.Columns[9].Title.Caption :=Фронт заказ.;
Form9.DBGrid1.Columns[10].Title.Caption :=№ цеха заказ.;
Form9.DBGrid1.Columns[11].Title.Caption :=БС цеха заказ.;
Form9.DBGrid1.Columns[12].Title.Caption :=Груз;
Form9.DBGrid1.Columns[13].Title.Caption :=Операция;
Form9.DBGrid1.Columns[14].Title.Caption :=Ед. изм.;
Form9.DBGrid1.Columns[15].Title.Caption :=Вес;
Form9.DBGrid1.Columns[16].Title.Caption :=Цена;
end;
end.
unit Unit5;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs, StdCtrls, Grids, DBGrids;
type
TForm5 = class(TForm)
GroupBox1: TGroupBox;
Edit1: TEdit;
Button1: TButton;
Edit2: TEdit;
Edit3: TEdit;
Label1: TLabel;
Label2: TLabel;
Label3: TLabel;
procedure Button1Click(Sender: TObject);
procedure FormShow(Sender: TObject);
procedure Edit1Enter(Sender: TObject);
procedure Edit2Enter(Sender: TObject);
procedure FormClose(Sender: TObject; var Action: TCloseAction);
procedure Edit3Exit(Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
end;
var
Form5: TForm5;
implementation
Uses Unit2, Unit4, Unit3;
{$R *.dfm}
procedure TForm5.Button1Click(Sender: TObject);
begin
ToIns := IntToStr(Edit1.Tag);
ToIns2 := IntToStr(Edit2.Tag);
ToIns3 := Edit3.Text;
If ((Edit1.Text<>)and(Edit2.Text<>)and(Edit3.Text<>)) then
begin
if EditMode4 then
begin
ForEdit := DataModule2.QSelUs[ST.id];
InsEdit2 := true;
InsertZapros();
ShowZapros();
end
else
begin
InsertZapros();
ShowZapros();
ForEdit := -1;
end;
Form5.Close;
end
else
ShowMessage(Все поля обязательны к заполнению!);
end;
procedure TForm5.FormShow(Sender: TObject);
begin
TBL:=Stoimost;
if EditMode4 then
begin
Edit1.Text := DataModule2.QSelUs[vid_uslug];
Edit1.Tag := StrToInt(DataModule2.QSelUs[key_vid_uslug]);
Edit2.Text := DataModule2.QSelUs[ves];
Edit2.Tag := StrToInt(DataModule2.QSelUs[key_ves]);
Edit3.Text := DataModule2.QSelUs[stoimost];
Form5.Edit3.SetFocus;
end
else
begin
Edit1.Text := ;
Edit2.Text := ;
Edit2.Tag := 0;
Edit3.Text := ;
Edit3.Tag := 0;
Button1.SetFocus;
end
end;
procedure TForm5.Edit1Enter(Sender: TObject);
begin
Form3.Caption := Вид услуг;
Form3.Label1.Caption:= Form3.Caption;
Tbl := Vid_uslug;
pole1 := id;
pole2 := vid_uslug;
pole3 := ;
pole4 := ;
pole5 := ;
pole6 := ;
pole7 := ;
pole8 := ;
pole9 := ;
pole10 := ;
pole11 := ;
pole12 := ;
pole13 := ;
ShowZapros;
Form3.ShowModal;
Tbl := Stoimost;
Form5.Edit2.SetFocus;
end;
procedure TForm5.Edit2Enter(Sender: TObject);
begin
Form3.Caption := Единица измерения;
Form3.Label1.Caption:= Form3.Caption;
Tbl := Ves;
pole1 := id;
pole2 := ves;
pole3 := ;
pole4 := ;
pole5 := ;
pole6 := ;
pole7 := ;
pole8 := ;
pole9 := ;
pole10 := ;
pole11 := ;
pole12 := ;
pole13 := ;
ShowZapros;
Form3.ShowModal;
Tbl := Stoimost;
Form5.Edit3.SetFocus;
end;
procedure TForm5.FormClose(Sender: TObject; var Action: TCloseAction);
begin
if EditMode4 then
begin
EditMode4:=false;
end;
TBL:=Uslugi_sv;
end;
procedure TForm5.Edit3Exit(Sender: TObject);
var ResVar : real;
E : integer;
begin
try
strtofloat(Edit3.Text);
except
ShowMessage(Здесь должно быть число!!... ну или поменяйте точку на запятую;));
Edit3.SetFocus;
end;
end;
end.
unit Unit6;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs, StdCtrls, Grids, DBGrids, ActnList, Menus, ComCtrls;
type
TForm6 = class(TForm)
GroupBox1: TGroupBox;
ComboBox1: TComboBox;
Edit2: TEdit;
Edit3: TEdit;
Edit5: TEdit;
Button1: TButton;
GroupBox2: TGroupBox;
DBGrid1: TDBGrid;
Label1: TLabel;
Label2: TLabel;
Label3: TLabel;
Label4: TLabel;
Label5: TLabel;
Label6: TLabel;
Label8: TLabel;
Label10: TLabel;
Edit8: TEdit;
Label12: TLabel;
Edit9: TEdit;
Edit10: TEdit;
PopupMenu1: TPopupMenu;
ActionList1: TActionList;
add: TAction;
edit: TAction;
del: TAction;
N1: TMenuItem;
N2: TMenuItem;
N3: TMenuItem;
DateTimePicker1: TDateTimePicker;
DateTimePicker2: TDateTimePicker;
procedure Button1Click(Sender: TObject);
procedure FormClose(Sender: TObject; var Action: TCloseAction);
procedure FormShow(Sender: TObject);
procedure Edit9Enter(Sender: TObject);
procedure Edit10Enter(Sender: TObject);
procedure addExecute(Sender: TObject);
procedure editExecute(Sender: TObject);
procedure delExecute(Sender: TObject);
procedure Edit2Exit(Sender: TObject);
procedure Edit3Exit(Sender: TObject);
procedure Edit5Exit(Sender: TObject);
procedure Edit8Exit(Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
end;
var
Form6: TForm6;
implementation
Uses Unit2, Unit4, Unit3, Unit7, DateUtils;
{$R *.dfm}
procedure TForm6.Button1Click(Sender: TObject);
var qtmp: string;
begin
ToIns := ComboBox1.Items[ComboBox1.ItemIndex];
ToIns2 := IntToStr(YearOf(DateTimePicker1.Date));
ToIns3 := Edit2.Text;
ToIns4 := Edit3.Text;
ToIns5 := IntToStr(YearOf(DateTimePicker2.Date));
ToIns6 := Edit5.Text;
ToIns7 := IntToStr(Edit9.Tag);
ToIns8 := Edit8.Text;
ToIns9 := IntToStr(Edit10.Tag);
If ((ComboBox1.Text<>)and(Edit2.Text<>)and(Edit3.Text<>)
and(Edit5.Text<>)and(Edit8.Text<>)and(Edit9.Text<>)and(Edit10.Text<>)) then
begin
if EditMode then
begin
ForEdit := DataModule2.QShow[V.id];
InsEdit3 := true;
InsertZapros();
ShowZapros();
end
else
begin
EditIns := true;
InsertZapros();
QueryString:=SELECT top 1 id from + TBL+ order by id desc;
with DataModule2.Qtmp do
begin
Close;
SQL.Clear;
SQL.Add(QueryString);
Open;
end;
qtmp := DataModule2.Qtmp[id];
Form6.Close;
ShowZapros();
DataModule2.QShow.Locate(v.id,qtmp,[]);
ForEdit := -1;
end;
Form6.Close;
end
| ! | Как писать дипломную работу Инструкция и советы по написанию качественной дипломной работы. |
| ! | Структура дипломной работы Сколько глав должно быть в работе, что должен содержать каждый из разделов. |
| ! | Оформление дипломных работ Требования к оформлению дипломных работ по ГОСТ. Основные методические указания. |
| ! | Источники для написания Что можно использовать в качестве источника для дипломной работы, а от чего лучше отказаться. |
| ! | Скачивание бесплатных работ Подводные камни и проблемы возникающие при сдаче бесплатно скачанной и не переработанной работы. |
| ! | Особенности дипломных проектов Чем отличается дипломный проект от дипломной работы. Описание особенностей. |
| → | по экономике Для студентов экономических специальностей. |
| → | по праву Для студентов юридических специальностей. |
| → | по педагогике Для студентов педагогических специальностей. |
| → | по психологии Для студентов специальностей связанных с психологией. |
| → | технических дипломов Для студентов технических специальностей. |
| → | выпускная работа бакалавра Требование к выпускной работе бакалавра. Как правило сдается на 4 курсе института. |
| → | магистерская диссертация Требования к магистерским диссертациям. Как правило сдается на 5,6 курсе обучения. |
| Дипломная работа | Формирование устных вычислительных навыков пятиклассников при изучении темы "Десятичные дроби" |
| Дипломная работа | Технологии работы социального педагога с многодетной семьей |
| Дипломная работа | Человеко-машинный интерфейс, разработка эргономичного интерфейса |
| Дипломная работа | Организация туристско-экскурсионной деятельности на т/к "Русский стиль" Солонешенского района Алтайского края |
| Дипломная работа | Разработка мероприятий по повышению эффективности коммерческой деятельности предприятия |
| Дипломная работа | Совершенствование системы аттестации персонала предприятия на примере офиса продаж ОАО "МТС" |
| Дипломная работа | Разработка системы менеджмента качества на предприятии |
| Дипломная работа | Организация учета и контроля на предприятиях жилищно-коммунального хозяйства |
| Дипломная работа | ЭКСПРЕСС-АНАЛИЗ ФИНАНСОВОГО СОСТОЯНИЯ ООО «АКТ «ФАРТОВ» |
| Дипломная работа | Психическая коммуникация |