6.4 Язык SQL как стандартный язык баз данных
Определение реляционной системы требует, чтобы весь диалог с базой данных велся на едином языке – иногда его называют общим подъязыком данных (comdivhensive 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.4.2 Достоинства SQL

SQL - это легкий для понимания язык и в то же время универсальное программное средство управления данными. Успех языку SQL принесли следующие его особенности:
• независимость от конкретных СУБД;
• переносимость с одной вычислительной системы на другую;
• наличие стандартов;
• поддержка со стороны компании Microsoft (протокол ODBC);
• реляционная основа;
• высокоуровневая структура;
• возможность выполнения специальных интерактивных запросов;
• обеспечение программного доступа к базам данных;
• возможность различного представления данных;
• полноценность как языка, предназначенного для работы с базами данных;
• возможность динамического определения данных;
• поддержка архитектуры клиент/сервер.[10]
Все перечисленные выше факторы явились причиной того, что SQL стал стандартным инструментом для управления данными на персональных компьютерах, мини-компьютерах и больших ЭВМ.
SQL – это промышленный стандарт набора команд для управления базой данных, который используется средой разработки приложений Delphi.

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 появились специализированные компоненты, позволяющие настраивать цветовую палитру всех возможных деталей пользовательского интерфейса одновременно. Все они представляют собой контейнер, содержащий цвета для раскраски различных деталей элементов управления. Разработчику необходимо лишь настроить эту цветовую палитру и по мере необходимости подключать к пользовательскому интерфейсу приложения.

6.5.3 Технологии доступа к данным

Любое приложение баз данных имеет в своем составе или использует сторонний механизм доступа к данным, который берет на себя подавляющее большинство стандартных низкоуровневых операций работы с базами данных. Например, любое такое приложение при открытии таблицы БД должно выполнить примерно одинаковый набор операций:
поиск местоположения базы данных;
поиск таблицы, ее открытие и чтение служебной информации;
чтение данных в соответствии с форматом хранения данных и т. д.
Одним из традиционных способов взаимодействия приложения, созданного в среде разработки 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]

6.5.4 Элементы управления Windows XP

В Delphi 7.0 впервые появилась возможность настраивать пользовательский интерфейс приложений для использования в Windows XP. Это дополнение призвано обеспечить корректное взаимодействие элементов управления приложения с системной библиотекой ComCtl32.dll версии 6, используемой в Windows XP. Собственно все особенности работы приложений под управлением Windows XP вызваны именно появлением новой версии этой библиотеки. Визуальные стили, интегрированные в Windows ХР, управляют внешним видом и поведением элементов управления. При этом визуальный стиль использует настройки параметров пользовательского интерфейса, заданные текущей темой. Для управления темами визуального стиля операционная система использует менеджер тем.
Визуальный стиль позволяет настраивать внешний вид элементов управления в целом и его составных частей. Правила и методы отрисовки сохраняются в файле с расширением .mst, который входит в состав визуального стиля.

6.5.5 Генератор отчетов Rave Reports 5.0

Delphi 7 – не только многофункциональная среда для разработки форм, но и очень удобная среда для подготовки отчетной документации, что позволяет решить некоторые поставленные задачи в данной дипломной работе.
На первый взгляд кажется, что в сфере создания и печати отчетов в Delphi 7 произошла небольшая революция. Вместо старого генератора отчетов в состав Delphi 7 включен продукт Rave Reports 5.0 от фирмы Nevrona. В Rave Reports имеются и глобальный класс отчета, и классы полос, и компоненты преобразования данных. Существенным нововведением можно считать только визуальную среду создания отчетов, что несомненно облегчит жизнь создателей отчетов и сделает их работу эффективнее и приятнее. Тем не менее, в Delphi 7 генератор отчетов Rave Reports является основным средством создания отчетов и его компоненты устанавливаются в Палитре компонентов по умолчанию на странице Rave.
Ядро генератора отчетов обеспечивает предварительный просмотр или печать отчета. Визуальная среда создания отчетов позволяет разрабатывать самые разнообразные отчеты, в том числе использующие наборы данных из источников различных типов.
Набор компонентов предоставляет разработчику инструментарий для управления отчетом в приложении.

Глава 7. Обоснование реализуемости системы по результатам анализа предельно допустимой длины слова с помощью системы MathCad 2001i

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.

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. Смета затрат на разработку системы учета компьютерного оборудования на предприятии

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. Смета затрат на эксплуатацию системы учета компьютерного оборудования на предприятии

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. Экологическая часть

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

9.1 Требования к условиям эксплуатации вычислительной техники (ВТ)

9.1.1 Требования к помещениям для эксплуатации ВТ

1. Помещение для эксплуатации ВТ должны иметь естественное и искусственное освещение. В случаях производственной необходимости эксплуатация ВТ в помещениях без естественного освещения может проводиться только по согласованию с органами Государственного санитарно-эпидемиологического надзора.
2. Естественное освещение должно обеспечивать коэффициент естественной освещенности (КЕО) не ниже 1,2 % в зонах с устойчивым снежным покровом и не ниже 1,5% на остальной территории. Окна в помещениях, где эксплуатируется вычислительная техника, преимущественно должны быть ориентированы на север и северо-восток.
3. Площадь на одно рабочее место для взрослых пользователей ВТ должна составлять не менее 6,0 кв. м., а объем не менее 20,0 куб. м.
4. Для внутренней отделки интерьера помещений с ВТ должны использоваться диффузно-отражающие материалы с коэффициентом отражения для потолка  -  0,7-0,8; для стен - 0,5-0,6; для пола - 0,3-0,5.
5. Поверхность пола в помещениях эксплуатации ВТ должна быть ровной, без выбоин, нескользкой, удобной для очистки и для влажной уборки, обладать антистатическими свойствами.
6. Помещения, где эксплуатируется ВТ, должны оборудоваться системами отопления, кондиционирования воздуха или эффективной приточно-вытяжной вентиляцией.
7. ВТ должна иметь заземление в соответствии с техническими требованиями по ее эксплуатации.
8. Звукоизоляция ограждающих конструкций помещений, где расположена ВТ, должна обеспечивать нормируемые параметры шума.

9.1.2 Требования к освещению помещений и рабочих мест пользователей ВТ
1. При работе с ВТ, как правило, применяется естественное освещение. Желательно, чтобы световые проемы располагались слева от пользователя ВТ, допускается и правостороннее естественное освещение. В тех случаях, когда одного естественного освещения не хватает, устанавливается совмещенное освещение. При этом дополнительное искусственное освещение применяется не только в темное, но и в светлое время суток. Нормированные значения освещенности при естественном и совмещенном освещении приведены в таблице 9.1.
Таблица 9.1. Значения освещенности при естественном и искусственном освещении
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. Для обеспечения нормируемых значений освещенности в помещениях использования ВТ следует проводить чистку стекол оконных рам и светильников не реже двух раз в год и проводить своевременную замену перегоревших ламп.

9.1.3 Требования к шуму и вибрации в помещениях для эксплуатации ВТ

1. Шум создают системный блок, а точнее блок питания в системном блоке – менее 40 дБА (один метр от поверхности), источник бесперебойного питания – менее 40 дБА, принтер – менее 40 дБА. При выполнении основной работы в помещениях для эксплуатации ВТ, уровень шума не должен превышать 60 дБА.
2. В помещениях пользователей ВТ уровень шума не должен превышать 65 дБА.
3. На рабочих местах в помещениях для размещения шумных агрегатов вычислительных машин (АЦПУ, принтеры и др.) уровень шума не должен превышать 75 дБА.
4. Шумящее оборудование (АЦПУ, принтеры и др.), уровни шума которого превышают нормированные, должно находится вне помещения с ВТ.
5. Снизить уровень шума в помещениях с ВТ можно использованием звукопоглощающих материалов с максимальными коэффициентами звукопоглощения  в области частот 63-8000 Гц для отделки помещений (разрешенных органами и учреждениями Госсанэпиднадзора России), подтвержденных специальными акустическими расчетами.
6. Дополнительным звукопоглощением служат однотонные занавеси из плотной ткани, гармонирующие с окраской стен и подвешенные в складку на расстоянии 15 - 20 см от ограждения. Ширина занавеси должна быть в 2 раза больше ширины окна.

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

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

Таблица 9.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

9.1.5 Требования к уровням электромагнитных полей в помещениях для эксплуатации ВТ

1. Помещения, оборудованные ВТ, не допускается размещать вблизи источников электромагнитных полей  (ЭМП) промышленной частоты 50 Гц (силовые кабели, трансформаторные подстанции и др.).
2. В помещениях при организации рабочих мест, оборудованных мониторами (видео терминальными устройствами - ВДТ), необходимо проводить измерения фоновых уровней ЭМП промышленной частоты 50 Гц. При этом напряженность электрического поля  должна быть не более не более 500 В/м.
3. В производственных помещениях при выполнении основных или вспомогательных работ на рабочих местах, оборудованных ВТ, эксплуатация ВТ должна осуществляться при уровнях ЭМП, не превышающих предельно допустимые значения, представленных в таблице 9.4.
Таблица 9.4. Предельно допустимые уровни (ПДУ) ЭМП

Наименование параметров	ПДУ
Напряженность электростатического поля	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 г.

Приложение 1

Листинг программы
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
else
 ShowMessage('Все поля обязательны к заполнению!');
end;
procedure TForm6.FormClose(Sender: TObject; var Action: TCloseAction);
begin
  if EditMode then
        begin
          EditMode:=false;
        end;
end;
procedure TForm6.FormShow(Sender: TObject);
var i, k: integer;
begin
    EditIns := False;
if EditMode then
   begin
    DBGrid1.Visible := true;
    DateTimePicker1.Date := StrToDate('01.01.'+ DataModule2.QShow['myyear']);
    Edit2.Text := DataModule2.QShow['nomer_vagona'];
    Edit3.Text := DataModule2.QShow['invent_nomer'];
    DateTimePicker2.Date := StrToDate('01.01.'+ DataModule2.QShow['year_izgot']);
    Edit5.Text := DataModule2.QShow['gruzopodemnost'];
    Edit8.Text := DataModule2.QShow['iznos'];
    Edit9.Text := DataModule2.QShow['rod_vagona'];
    Edit9.Tag := DataModule2.QShow['rv.id'];
    Edit10.Text := DataModule2.QShow['raion_dvizh'];
    Edit10.Tag := DataModule2.QShow['rd.id'];
    For i:=0 to ComboBox1.Items.Count do
      begin
        ComboBox1.ItemIndex := i;
        if ComboBox1.Items[ComboBox1.ItemIndex] = DataModule2.QShow['mymonth'] then
            k := ComboBox1.ItemIndex;
      end;
    ComboBox1.ItemIndex := k;
    Tbl:='Operations_s_vagonom';
    ShowZapros();
   end
  else
   begin
    DateTimePicker1.Date := Date;
    DateTimePicker2.Date := StrToDate('01.01.1950');   
    Edit2.Text := '';
    Edit3.Text := '';
    Edit5.Text := '';
    Edit8.Text := '';
    Edit9.Text := '';
    Edit9.Tag := 0;
    Edit10.Text := '';
    Edit10.Tag := 0;
    DBGrid1.Visible := false;
   end;
    TBL:='Vagon';
end;
procedure TForm6.Edit9Enter(Sender: TObject);
begin
  Form3.Caption := 'Род вагона';
  Form3.Label1.Caption:=  Form3.Caption;
  Tbl := 'Rod_vagona';
  pole1 := 'id';
  pole2 := 'Rod_vagona';
  pole3 := '';
  pole4 := '';
  pole5 := '';
  pole6 := '';
  pole7 := '';
  pole8 := '';
  pole9 := '';
  pole10 := '';
  pole11 := '';
  pole12 := '';
  pole13 := '';
  ShowZapros;
  Form3.ShowModal;
  Tbl := 'Vagon';
  Edit10.SetFocus;
end;
procedure TForm6.Edit10Enter(Sender: TObject);
begin
  Form3.Caption := 'Район движения';
  Form3.Label1.Caption:=  Form3.Caption;
  Tbl := 'Raion_dvizheniya';
  pole1 := 'id';
  pole2 := 'Raion_dvizh';
  pole3 := '';
  pole4 := '';
  pole5 := '';
  pole6 := '';
  pole7 := '';
  pole8 := '';
  pole9 := '';
  pole10 := '';
  pole11 := '';
  pole12 := '';
  pole13 := '';
  ShowZapros;
  Form3.ShowModal;
  Tbl := 'Vagon';
  Button1.SetFocus;
end;
procedure TForm6.addExecute(Sender: TObject);
begin
  Form7.Caption := 'Информация по вагону';
  Tbl := 'Operations_s_vagonom';
  pole1 := 'id';
  pole2 := 'key_station_otpr';
  pole3 := 'key_front_otpr';
  pole4 := 'key_sttion_naznach';
  pole5 := 'key_front_naznach';
  pole6 := 'date';
  pole7 := 'time';
  pole8 := 'key_operation';
  pole9 := 'key_gruz';
  pole10 := 'weight';
  pole11 := 'n_dor_ved';
  pole12 := 'n_ved';
  pole13 := 'key_vagon';
  Form7.ShowModal;
  if ((EditMode2=false)and(EditIns2)) then
        begin
        EditMode2:=true;
        Form7.ShowModal;
        end;
end;
procedure TForm6.editExecute(Sender: TObject);
begin
if (DataModule2.QOSV['OSV.id']=Null) then
  begin
   ShowMessage('Нечего редактировать');
   EditMode2 := false;
  end
 else
  begin
   EditMode2 := True;
   Form7.ShowModal;
  end;
end;
procedure TForm6.delExecute(Sender: TObject);
begin
if (DataModule2.QOSV['OSV.id']=Null) then
  begin
   ShowMessage('Нечего удалять');
   EditMode2 := false;
  end
 else
  begin
    Tbl := 'Operations_s_vagonom';
    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';
    ForDel := DataModule2.QOSV['OSV.id'];
    DelZapros;
    ShowZapros();
    TBL:='Vagon';
  end; 
end;
procedure TForm6.Edit2Exit(Sender: TObject);
begin
try
strtoint(Edit2.Text);
except
ShowMessage('Здесь должно быть число!!');
Edit2.SetFocus;
end;
end;
procedure TForm6.Edit3Exit(Sender: TObject);
begin
try
strtoint(Edit3.Text);
except
ShowMessage('Здесь должно быть число!!');
Edit3.SetFocus;
end;
end;
procedure TForm6.Edit5Exit(Sender: TObject);
begin
try
strtoint(Edit5.Text);
except
ShowMessage('Здесь должно быть число!!');
Edit5.SetFocus;
end;
end;
procedure TForm6.Edit8Exit(Sender: TObject);
begin
try
strtoint(Edit8.Text);
//----далее команды если введённая вещь - число
except
ShowMessage('Здесь должно быть число!!');
Edit8.SetFocus;
end;
end;
end.
unit Unit7;
interface
uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, StdCtrls, ComCtrls, TabNotBk, Grids, DBGrids, Menus, ActnList;
type
  TForm7 = class(TForm)
    GroupBox1: TGroupBox;
    Label2: TLabel;
    Label3: TLabel;
    Label4: TLabel;
    Label5: TLabel;
    Label6: TLabel;
    Label7: TLabel;
    Label8: TLabel;
    Label9: TLabel;
    Label10: TLabel;
    Label11: TLabel;
Программные продукты (ПП) предназначены для удовлетворения потребностей пользователей, широкого распространения и продажи.
Поскольку в дипломной работе разрабатывается информационная система учета вагонов на подъездном пути, что в конечном итоге является программным продуктом, рассмотрим этот класс программ более подробно.
Программный продукт – комплекс взаимосвязанных программ для решения определенной проблемы (задачи) массового спроса, подготовленный к реализации как любой вид промышленной продукции.[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.
 SHAPE  \* MERGEFORMAT

Б А З А    ДА Н Н Ы Х

Отдельные пользователи БД Администратор БД

Физическая модель данных Описание хранимых данных

Даталогическая модель данных Описание на языке конкретной СУБД

Концептуальная модель данных Обобщенное, не привязанное к какой-либо ЭВМ и СУБД, описание предметной области (набор данных, их типов, связей и т.п.)

Модели и описания, используемые СУБД

Предметная область (часть реального мира, отражаемая в БД)

Рис.2.1. Уровни моделей данных
Основным назначением трехуровневой архитектуры является обеспечение независимости от данных. Суть этой независимости заключается в том, что изменения на нижних уровнях никак не влияют на верхние уровни.[3]
Основное различие между указанными выше тремя типами моделей данных (концептуальной, логической и физической) состоит в способах представления взаимосвязей между объектами. При проектировании БД требуется различать взаимосвязи между объектами, между свойствами одного объекта и между свойствами различных объектов.

2.4. Жизненный цикл базы данных

Как и любой программный продукт, база данных обладает собственным жизненным циклом (ЖЦ БД). Главной составляющей в жизненном цикле БД является создание единой базы данных и программ, необходимых для ее работы. Жизненный цикл системы базы данных определяет и жизненный цикл всей информационной системы организации, поскольку база данных является фундаментальным компонентом информационной системы.
ЖЦ БД включает в себя следующие основные этапы:
·          планирование разработки базы данных;
·          определение требований к системе;
·          сбор и анализ требований пользователей;
·          проектирование базы данных:
·                      концептуальное проектирование базы данных;
·                      логическое проектирование базы данных;
·                      физическое проектирование базы данных;
·          разработка приложений;
·          реализация;
·          загрузка данных;
·          тестирование;
·          эксплуатация и сопровождение.

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

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

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

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

2.4.3. Сбор и анализ требований пользователей

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

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

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

2.4.5. Разработка приложений

Параллельно с проектированием системы БД выполняется разработка приложений. Главные составляющие данного процесса – это проектирование транзакций и пользовательского интерфейса.

2.4.6. Реализация

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

2.4.7. Загрузка данных

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

2.4.8. Тестирование

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

2.4.9. Эксплуатация и сопровождение

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

2.5. Модели представления данных

С ростом популярности СУБД в 70-80-х годах появилось множество различных моделей данных. У каждой из них имелись свои достоинства и недостатки, которые сыграли ключевую роль в развитии реляционной модели данных, появившейся во многом благодаря стремлению упростить и упорядочить первые модели данных.
Модель данных (МД) – это некоторая абстракция, в которой отражаются самые важные аспекты функционирования выделенной предметной области, а второстепенные – игнорируются. Модель данных включает в себя набор понятий для описания данных, связей между ними и ограничений, накладываемых на данные.
Существуют три основные МД и их комбинации, на которых основываются  современные БД: реляционная модель данных (РМД), сетевая модель данных (СМД), иерархическая модель данных (ИМД).[3]
Основное различие  между этими моделями данных состоит в способах описания взаимодействий между объектами и атрибутами. Взаимосвязь выражает отношение между множествами данных.
Используют взаимосвязи "один к одному", "один ко многим" и "многие ко многим". "Один к одному" – это взаимно однозначное соответствие, которое устанавливается  между одним объектом и одним атрибутом. "Один ко многим" – это соответствие между одним объектом и многими атрибутами. "Многие ко многим" – это соответствие между многими объектами и многими атрибутами.
Рассмотрим эти модели данных более подробно.

2.5.1. Иерархическая модель данных

Основными информационными единицами в иерархической модели данных являются сегмент и поле. Поле данных определяется как наименьшая неделимая единица данных, доступная пользователю. Для сегмента определяются тип сегмента и экземпляр сегмента. Экземпляр сегмента образуется из конкретных значений полей данных. Тип сегмента – это поименованная совокупность входящих в него типов полей данных.
Иерархическая модель данных базируется на графовой форме построения данных. В ИМД вершине графа соответствует сегмент, а дугам – типы связей предок-потомок. В иерархических структурах сегмент-потомок должен иметь в точности одного предка.

2.5.2. Сетевая модель данных

Сетевая модель опирается на математическую структуру, которая называется направленным графом. Направленный граф состоит из узлов, соединенных ребрами. В контексте моделей данных узлы представляют собой объекты в виде типов записей данных, а ребра – связи между объектами со степенью кардинальности "один к одному" или "один ко многим".
Основное отличие графовых форм представления данных в сетевой структуре данных от иерархической структуры данных состоит в том, что потомок в графе может иметь любое число предков.

2.4.3. Реляционная модель данных
Недостатки иерархической и сетевой моделей привели к появлению новой, реляционной модели данных, созданной Коддом в 1970 году и вызвавшей всеобщий интерес. Реляционная модель была попыткой упростить структуру базы данных. В ней отсутствовали явные указатели на предков и потомков, а все данные были представлены в виде простых таблиц, разбитых на строки и столбцы.
Именно реляционная модель является результатом более развитых представлений о формировании и ведении баз данных, на которые наложен строгий математический аппарат. Реляционные модели наиболее логично и наглядно отражают структуру хранимой информации и внутренних связей, что позволяет более полно анализировать структуру базы данных при разработке. Это привело к тому, что именно реляционные модели баз данных наиболее распространены в настоящее время и являются стандартом, на который переводятся все существовавшие ранее базы данных с иерархической и сетевой моделью. Ещё одним веским доводом в пользу выбора реляционной модели является тот факт, что подавляющее большинство предоставляемых средств для разработки баз данных ориентированы исключительно на реляционную модель. Кроме того, реляционные базы данных в последствии легче расширять и интегрировать, что является неотъемлемой частью дальнейшего развития баз данных, с увеличением возлагаемых на них задач.
Реляционной называется база данных, в которой все данные, доступные пользователю, организованны в виде таблиц, а все операции над данными сводятся к операциям над этими таблицами.[7]
Приведенное определение не оставляет места встроенным указателям, имеющимся в иерархических и сетевых СУБД. Несмотря на это, реляционная СУБД также способна реализовать отношения предок/потомок, однако эти отношения представлены исключительно значениями данных, содержащихся в таблицах.
Достоинства реляционной модели можно разделить на две группы.
Достоинства для пользователя:
реляционная БД представляет собой набор таблиц, с которыми пользователь привык работать;
не нужно помнить пути доступа к данным и строить алгоритмы и процедуры обработки своего запроса;
реляционные языки легки для изучения и освоения, в то время как языки общения с иерархической и сетевой моделями предназначены для программистов и мало пригодны для пользователей;
Достоинства обработки данных реляционной БД:
Связность. Реляционное представление дает ясную картину взаимосвязей атрибутов из различных отношений;
Точность. Направленные связи в реляционной БД отсутствуют. Отношения по своей природе обладают более точным смыслом и поддаются манипулированию с использованием таких средств, как алгебра и исчисление отношений, обеспечивающих наглядность и гибкость модели данных;
Гибкость. Операции проекции и объединения позволяют разрезать и склеивать отношения, так что программист может получать разнообразные файлы в нужной форме;
Секретность. Контроль секретности упрощается. Для каждого отношения имеется возможность задания правомерности доступа, засекреченные показатели можно выделить в отдельные отношения с проверкой прав доступа;
Простота внедрения. Физическое размещение однородных (табличных) файлов намного проще, чем размещение иерархических и сетевых структур;
Независимость данных. БД должна допускать возможность расширения, т.е. добавления новых атрибутов и отношений.[7]
Поскольку среди рассмотренных логических моделей данных реляционная обладает значительными преимуществами и малыми недостатками, то она и будет взята в основу для построения СУБД. Рассмотрим ее более подробно.

 

2.5.3.1 Таблицы

Таблицы – фундаментальные объекты реляционной базы данных, в которых хранится основная часть данных приложения. Информация в таблице организуется в строки (записи) и столбцы (поля). Таблице присущи два компонента: структура таблицы и данные таблицы.
Структура таблицы (также называется определением таблицы) специфицируется при создании таблицы. Структура таблицы должна быть спроектирована и создана перед вводом в таблицу каких-либо данных. Она определяет, какие данные таблица будет хранить, а также правила, ассоциированные с вводом, изменением или удалением данных (бизнес-правила, или ограничения).
Структура таблицы включает следующую информацию:
Имя таблицы - это имя, по которому к таблице можно обратиться в свойствах, методах и операторах SQL;
Столбцы таблицы - это колонка таблицы, содержащая все данные, относящиеся к заданному полю таблицы. Каждый столбец имеет имя и тип данного;
Табличные и столбцовые ограничения - ограничения целостности, определенные на уровне таблицы или на уровне столбца;
Данные таблицы – информация, которая сохранена в таблице. Все данные таблицы хранятся в строках, каждая из которых содержит порции информации в столбцах, определенных в структуре таблицы. Данные – та часть таблицы, к которой обычно должны иметь доступ пользователи приложения. На пересечении каждой строки с каждым столбцом таблицы содержится в точности одно значение данных.
Все значения, содержащиеся в одном и том же столбце, являются данными одного типа. Множество значений, которые могут содержаться в столбце, называется доменом этого столбца.
У каждого столбца в таблице есть своё имя, которое обычно служит заголовком столбца. Все столбцы в одной таблице должны иметь уникальные имена, однако разрешается присваивать одинаковые имена столбцам, расположенным в различных таблицах. Столбцы таблицы упорядочены слева направо, и их порядок определяется при создании таблицы. В любой таблице всегда есть как минимум один столбец. В стандарте ANSI/ISO не указывается максимально допустимое число столбцов в таблице, однако почти во всех коммерческих СУБД этот предел существует и обычно составляет примерно 255 столбцов.
В отличие от столбцов, строки таблицы не имеют определённого порядка. Это значит, что если последовательно выполнить два одинаковых запроса для отображения содержимого таблицы, нет гарантии, что оба раза строки будут перечислены в одном и том же порядке.
В таблице может содержаться любое количество строк. Вполне допустимо существование таблицы с нулевым количеством строк. Такая таблица называется пустой. Пустая таблица сохраняет структуру, определённую её столбцами, просто в ней не содержится данные. Стандарт ANSI/ISO не накладывает ограничений на количество строк в таблице, и во многих СУБД размер таблиц ограничен лишь свободным дисковым пространством компьютера. В других СУБД  имеется максимальный предел, однако он весьма высок – около двух миллиардов строк, а иногда и больше.

 

2.5.3.2 Ключевые поля

Мощь реляционных баз данных заключается в том, что с их помощью можно быстро найти и связать данные из разных таблиц при помощи запросов, форм и отчетов. Для этого каждая таблица должна содержать одно или несколько полей, однозначно идентифицирующих каждую запись в таблице. Эти поля называются ключевыми полями таблицы. Ключевые поля ещё также называют первичным ключом. Можно выделить три типа ключевых полей: счетчик, простой ключ и составной ключ.
Поскольку строки в реляционной таблице не упорядочены, нельзя выбрать строку по ее номеру в таблице. В таблице нет "первой", "последней" или "тринадцатой" строки.
Ключевое поле можно задать таким образом, чтобы при добавлении каждой записи в таблицу в это поле автоматически вносилось порядковое число, т.е. организовать счётчик. Это наиболее простой способ создания ключевых полей.
Составной ключ применяется в случаях, когда невозможно гарантировать уникальность значений каждого отдельного поля. Чаще всего такая ситуация возникает для таблицы, используемой для связывания двух таблиц в отношении "многие ко многим".
Первичный ключ для каждой строки таблицы является уникальным, поэтому в таблице с первичным ключом нет двух совершенно одинаковых строк. Таблица, в которой все строки отличаются друг от друга, в математических терминах называется отношением. Именно этому термину реляционные базы данных и обязаны своим названием, поскольку в их основе лежат отношения.

 

2.5.3.3 Индексы

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

 

2.5.3.4 Отношения предок/потомок

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

 

2.5.3.5 Внешние ключи

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

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

2.6.1 Нормализация как особенность проектирования базы данных

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

2.6.1.1 Процесс нормализации

Нормальная форма - это мера глубины, до которой должна быть выполнена нормализация базы данных. Формально существует пять форм, но обычно в процессе нормализации используются следующие три нормальные формы:
·          первая нормальная форма;
·          вторая нормальная форма;
·          третья нормальная форма.
В этой последовательности нормальных форм каждая последующая зависит от результатов нормализации, выполненных предыдущей.
Первая нормальная форма
Целью первой нормальной формы является разделение базы данных на логические единицы, называемые таблицами. После того как таблицы будут сформированы, для большинства из них будут назначены ключевые поля. Каждое из полей таблицы должно быть неделимым и не должно содержать никаких повторяющихся групп.
Вторая нормальная форма
Целью второй нормальной формы является выделение данных, только отчасти зависящих от ключа, и помещение этих данных в другую таблицу. Вторая нормальная форма получается из первой нормальной формы в результате дальнейшего разделения таблиц на более мелкие таблицы.
Третья нормальная форма
Для того чтобы таблица была приведена к третьей нормальной форме, нужно, чтобы все неключевые поля полностью зависели от первичного ключа таблицы и не зависели друг от друга. Таким образом, к квалификации второй нормальной формы добавляется требование независимости каждого неключевого поля таблицы от других неключевых полей.
Соглашения о присвоении имен
Соглашения о присвоении имен оказываются исключительно важными для проведения нормализации. Имена баз данных должны быть информативными и соответствовать типу хранимой в них информации. Могут быть установлены и внутрикорпоративные соглашения об именах, которые могут касаться не только имен таблиц внутри базы данных, но и имен пользователей, файлов и других подобных объектов. Разработка и внедрение соглашений об именах должно быть одним из первых шагов компании в направлении успешного управления базами данных.[7]

 

2.6.1.2 Преимущества нормализации

Нормализация имеет целый ряд преимуществ:
• лучшая общая организация базы данных;
• сокращение числа ненужных повторений данных;
• согласованность данных внутри базы данных;
• более гибкая структура базы данных;
• эффективные возможности обеспечения безопасности и надежности базы данных.
Процесс нормализации улучшает организацию базы данных, облегчая работу с базой данных всем, начиная от простых пользователей до администратора, который отвечает за общее управление объектами базы данных. Уменьшается число повторений данных, что упрощает структуру данных и экономит дисковое пространство. Из-за сокращения дублирования данных уменьшается вероятность их несогласованности. Поскольку в результате нормализации база данных разделяется на ряд более мелких таблиц, модифицировать существующие структуры становится проще. Наконец, повышается безопасность в том смысле, что администратор базы данных получает возможность разрешить различным пользователям доступ только к ограниченному списку таблиц. Нормализация упрощает управление безопасностью.
Целостность данных — это гарантия согласованности и надежности данных в базе данных.
Ссылочная целостность
Ссылочная целостность попросту означает зависимость значений столбца одной таблицы от значений столбца другой таблицы. С помощью требований целостности можно также задавать ограничения на диапазон допустимых для столбца значений. Требования целостности должны задаваться при создании таблицы. Ссылочная целостность обеспечивается обычно с помощью ключевых полей и внешних ключей.

 

2.6.1.3 Недостатки нормализации

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

2.6.2 Концептуальное проектирование базы данных

После завершения начальных этапов ЖЦ БД, таких как: планирование разработки БД, определение требований к системе, сбор и анализ требований пользователей, начинается процесс проектирования базы данных. Этот процесс включает в себя полный цикл разработки базы данных и начинается с концептуального проектирования.
Первая фаза процесса проектирования базы данных заключается в создании анализируемой части предприятия концептуальной (инфологической) модели данных. Построение ее осуществляется в определенном порядке: в начале создаются подробные модели пользовательских представлений данных; затем они интегрируются в концептуальную модель данных. Концептуальное проектирование приводит к созданию концептуальной схемы базы данных.
Существуют два основных подхода к проектированию систем баз данных: "нисходящий" и "восходящий".
При восходящем походе, который применяется для проектирования простых баз данных с относительно небольшим количеством атрибутов, работа начинается с самого нижнего уровня – уровня атрибутов, которые на основе анализа существующих между ними связей группируются в отношения.
Проектирование сложных баз данных с большим количеством атрибутов осуществляется использованием нисходящего подхода. Начинается этот подход с разработки моделей данных, которые содержат несколько высокоуровневых сущностей и связей, затем работа продолжается в виде серии нисходящих уточнений низкоуровневых сущностей, связей и относящихся к ним атрибутов.
Нисходящий подход демонстрируется в концепции модели "сущность-связь". Данная  модель данных относится к высокоуровневым моделям и базируется на ряде концепций, используемых для описания структуры базы данных.[7]

 

2.6.2.1 Концептуальная модель данных

Предметная область – часть реального мира отражённая в базе данных. Объединяя частные представления о содержимом базы данных, полученные в результате опроса пользователей, и свои представления о данных, которые могут потребоваться в будущих приложениях, АБД сначала создает обобщенное неформальное описание создаваемой базы данных. Концептуальной моделью данных называется описание, выполненное с использованием естественного языка, математических формул, таблиц, графиков и других средств, понятных всем людям, работающих над проектированием базы данных.[3]
Целью концептуального моделирования является обеспечение наиболее естественных для человека способов сбора и представления той информации, которую предполагается хранить в создаваемой базе данных. Поэтому концептуальную модель данных пытаются строить по аналогии с естественным языком. Основными конструктивными элементами концептуальных моделей являются сущности (объекты), их атрибуты и связи между ними. В первой главе были приведены понятия данных элементов концептуальной модели.
При определении концептуальной модели необходимо принимать во внимание следующее:
база данных должна удовлетворять актуальным информационным потребностям организации. Получаемая информация должна по структуре и содержанию соответствовать решаемым задачам;
база данных должна обеспечивать получение требуемых данных за приемлемое время, то есть отвечать заданным требованиям производительности;
база данных должна удовлетворять выявленным и вновь возникающим требованиям всех пользователей;
база данных должна легко расширяться при реорганизации и расширении предметной области;
база данных должна легко изменяться при изменении программной и аппаратной среды.

 

2.6.2.2 Инфологическая модель данных "сущность-связь"

Цель моделирования данных состоит в обеспечении разработчика ИС концептуальной схемой базы данных в форме одной модели или нескольких локальных моделей, которые относительно легко могут быть отображены в любую систему баз данных.
Наиболее распространенным средством моделирования данных являются диаграммы "сущность-связь" (ERD). С их помощью определяются важные для предметной области объекты (сущности), их свойства (атрибуты) и отношения друг с другом (связи). ER-модели получили широкое распространение в системах CASE, поддерживающих автоматизированное проектирование реляционных баз данных.

2.6.3 Логическое проектирование базы данных

Цель второй фазы проектирования базы данных состоит в создании логической модели данных для исследуемой части предприятия. Процесс проектирования БД должен опираться на определенную модель данных (реляционная, сетевая, иерархическая), которая определяется типом предполагаемой для реализации информационной системы СУБД. После чего сама концептуальная модель данных уточняется и преобразуется в логическую модель данных. Дальнейшее проектирование базы данных в дипломной работе будет опираться на реляционную модель данных, поэтому на этапе логического проектирования рассмотрим более подробно проектирование реляционной базы данных.
Созданная логическая модель базы данных должна пройти проверку с использованием процедуры последовательной нормализации, а также должна пройти контроль на возможность выполнения всех необходимых пользователю транзакций. Таким образом, данная фаза логического проектирования предполагает следующие действия:
преобразование концептуальной модели данных в логическую модель, в результате которого будет определена схема реляционной модели данных:
исключение связи типа "многие ко многим";
исключение сложных связей;
исключение рекурсивных связей (рекурсивная связь – это особый вид связи, в которой одни и те же экземпляры объекта участвуют несколько раз в разных ролях, поэтому с точки зрения их реализации относятся к нежелательным структурам);
исключение связей с атрибутами;
исключение множественных атрибутов;
исключение избыточных связей;
проверка модели с помощью концепций нормализации – целью применения этой процедуры является получение гарантий того, что каждое из отношений, полученных на основе концептуальной модели, находится, по крайней мере,  в третьей нормальной форме;
проверка модели в отношении транзакций пользователей – созданная реляционная модель предметной области должна быть проанализирована в плане возможности выполнения всех транзакций, предусмотренных представлениями пользователя;
·                     проверка поддержки целостности данных:
возможность для атрибутов иметь пустые значения;
ограничения для доменов атрибутов;
категориальная целостность;
ссылочная целостность.
Построенная логическая модель данных в дальнейшем будет востребована на этапе физического проектирования, а также на этапе эксплуатации и сопровождения уже готовой системы, позволяя наглядно представить любые вносимые в базу данных изменения.[3]
Концептуальное и логическое проектирование – это итеративные процессы, которые включают в себя ряд уточнений, продолжающиеся до тех пор, пока не будет получен наиболее соответствующий структуре предприятия продукт.

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

Целью проектирования на данном этапе является создание описания СУБД-ориентированной модели БД. Следует учитывать, что на этой стадии разработки возможны возвраты на более ранние этапы ЖЦ БД. Например, решения, принимаемые на этапе физического проектирования с целью повышения производительности системы, могут привести к необходимости внести в структуру логической модели данных.
Действия, выполняемые на этом этапе, слишком специфичны для различных моделей данных, поэтому их сложно обобщить. Остановимся на реляционной модели данных, поскольку проектируемая база данных в данной дипломной работе опирается на реляционную модель данных. В этом случае под физическим проектированием подразумевается:
создание описания набора реляционных таблиц и ограничений для них на основе информации, представленной в глобальной логической модели данных;
определение конкретных структур хранения данных и методов доступа к ним, обеспечивающих оптимальную производительность системы с базой данных;
разработка средств защиты создаваемой базы данных.
Физическая модель данных – модель, определяющая размещение данных на внешних носителях, методы доступа и технику индексирования. Она также называется внутренней моделью системы.[7]
Внешние модели (даталогические модели) никак не связаны с типом физической памяти, в которой будут храниться данные, и с методами доступа к этим данным. Внутренние модели (физические модели) наоборот определяют и оперируют размещением данных и их взаимосвязях на запоминающих устройствах.
Физическая организация данных оказывает основное влияние на эксплуатационные характеристики БД. Разработчики СУБД пытаются создать наиболее производительные физические модели данных, предлагая пользователям тот или иной инструментарий для настройки модели под конкретную БД.
Физическая модель данных является полностью компьютерно-ориентированной и конечные пользователи, а порой и прикладные программисты, не имеют никакого представления о том, каким образом данные запоминаются и извлекаются или каким способом организуются индексы в таблицах для быстрого поиска или ссылочная целостность.
Трехуровневая архитектура (инфологический, даталогический и физический уровни) позволяет обеспечить независимость хранимых данных от использующих их программ.

2.6.5 Этапы проектирования базы данных

Этапы проектирования базы данных с учетом рассмотренных выше аспектов:
1.                Проектирование инфологической (концептуальной) модели базы данных:
а) исследование предметной области применения и выявление требований конечных пользователей и решаемых задач;
б) анализ данных: сбор основных данных (объекты, связи между объектами);
в) построение ER-диаграммы базы данных.
2.                Проектирование даталогической модели базы данных (учитывать требования СУБД). Сбор информации о потенциальных возможностях использования данных.
3.                Проектирование физической модели базы данных:
а) создание описания набора реляционных таблиц и  ограничений для них;
б) определение конкретных структур хранения данных и методов доступа к ним, обеспечивающих оптимальную производительность системы с базой данных;
в) разработка средств защиты создаваемой системы.
4.                Реализация базы данных (оценка при неудовлетворительных эксплуатационных характеристиках).[7]
По этой схеме производилась реализация базы данных для последующего создания информационной системы учета вагонов на подъездном пути предприятия, что является конечной целью данной дипломной работы.

Глава 3. Проектирование пользовательского интерфейса
Проектирование пользовательского интерфейса – это довольно длительный и трудоемкий процесс. В процессе дизайна интерфейса выделяются три основных этапа, а именно: первоначальное проектирование (часто оказывающееся и окончательным), создание прототипа и тестирование/модификация прототипа. Фактически процесс дизайна, чтобы быть успешным и безусловным, всегда стремится происходить по спиральной модели в такой последовательности: проектирование, затем создание прототипа, затем тестирование/модификация, затем опять тестирование/модификация и т.д. Т.е. основным этапом оказывается не дизайн, а полировка уже сделанного дизайна.
Важность первоначального проектирования трудно переоценить. На нем закладываются основные концепции системы, влияющие абсолютно на все показатели качества интерфейса. Чем больше внимания будет уделено проектированию, тем выше будет общее качество. Определим требования, предъявляемые к пользовательскому интерфейсу, и принципы проектирования пользовательского интерфейса.

3.1 Требования к пользовательскому интерфейсу

Минимизация усилий пользователя при выполнении работы:
•        сокращение длительности операций чтения, редактирования и поиска информации;
•        уменьшение времени навигации и выбора команды;
•        повышение общей продуктивности пользователя, заключающейся в объеме обработанных данных за определенный период времени;
•        увеличение длительности устойчивой работы пользователя и др.[1]
Стилевая гибкость:
Возможность использовать различные интерфейсы с одним и тем же приложением, на практике реализуется с помощью таблицы стилей, в том числе возможность в выборе пользователем собственных установок пользовательского интерфейса (ПИ).
Наращивание функциональности:
Возможность развивать приложение без разрушения (т.е. оставаясь в рамках) существующего интерфейса.
Масштабируемость:
Возможность легко настраивать и расширять как интерфейс, так и само приложение при увеличении числа пользователей, рабочих мест, объема и характеристик данных.
Адаптивность к действиям пользователя:
Приложение должно допускать возможность ввода данных и команд множеством разных способов (клавиатура, мышь, другие устройства) и многовариантность доступа к прикладным функциям (иконы, "горячие клавиши", меню), кроме того, программа должна учитывать возможность перехода и возврат от окна к окну, от режима к режиму, и правильно обрабатывать такие ситуации.
Независимость в ресурсах:
Для создания пользовательского интерфейса должны предоставляться отдельные ресурсы, направленные на хранение и обработку данных, необходимых для поддержки пользователя (пользовательские словари, контекстно-зависимые списки, наборы данных по умолчанию или по последнему запросу, истории запросов и пр.)
Переносимость:
При переходе на другую аппаратную (программную) платформу, должен осуществляется автоматически перенос и пользовательского интерфейса, и конечного приложения.

3.1.1 Методы оценки пользовательского интерфейса
Для оценки необходимого уровня удобства интерфейса используются специальные экспертные анкеты, опросники, формуляры, check-листы.
В качестве методов используют:
•        наблюдения за пользователями до использования ПИ, в процессе обучения и работы;
•        отслеживание мотивации пользователя - мысли вслух, объяснение своих действий и намерений;
•        постановка и протоколирование выполнения тестовых задач.

3.1.2 Цели и критерии оценки пользовательского интерфейса

Главной целью с точки зрения эргономики (науки об эффективном взаимодействии человека и техники), самое важное в приложении – создать такой пользовательский интерфейс, который сделает работу эффективной и производительной, а также обеспечит удовлетворенность пользователя от работы с программой.
Эффективность работы означает обеспечение точности, функциональной полноты и завершенности при выполнении производственных заданий на рабочем месте пользователя. Эффективность работы отражает объем затраченных ресурсов при выполнении задачи, как вычислительных, так и психофизиологических.
Создание ПИ должно быть нацелено на показатели эффективности человеко-машинной системы, которые можно измерить количественно и объективно:
·                                                производительность труда
Определяется средним количеством решенных задач, полученным по результатам работы группы пользователей.
·                                                точность работы (количество ошибок)
Показатель точности включает процент ошибок, которые совершил пользователь: число ошибок набора, варианты ложных путей или ответвлений, число неправильных обращений к данным, запросов и пр.
·                                                функциональная полнота
Определяется тем, в какой степени произведенный пользователем продукт (результат работы), соответствует предъявленным к нему требованиям; отражает степень использования первичных и обработанных данных, списка необходимых процедур обработки или отчетов, число пропущенных технологических операций или этапов при выполнении поставленной пользователю задачи. Этот показатель может определяться через процент применения отдельных функций в работе.
·                                                завершенность работы
Описывает степень исполнения производственной задачи средним пользователем за определенный срок или период, долю (или длину очереди) неудовлетворенных (необработанных) заявок, процент продукции, находящейся на промежуточной стадии готовности, а также число пользователей, которые выполнили задание в фиксированные сроки.
·                                                простота освоения
Определяется временем освоения интерфейса, выхода на производительный уровень.
Требования к удобству и комфортности интерфейса возрастают с увеличением сложности работ и ответственности пользователя за конечный результат. Высокая удовлетворенность от работы достигается в случае:
•        прозрачной для пользователя навигации и целевой ориентации в программе. Главное, чтобы было понятно, куда идем, и какую операцию программа после этого шага произведет;
•        ясности и четкости понимания пользователем текстов и значения икон. В программе должны быть те слова и графические образы, которые пользователь знает или обязан знать по характеру его работы или занимаемой должности;
•        быстроты обучения при работе с программой, для чего необходимо использовать преимущественно стандартные элементы взаимодействия, их традиционное или общепринятое их расположение;
•        наличия вспомогательных средств поддержки пользователя (поисковых, справочных, нормативных), в том числе и для принятия решения в неопределенной ситуации (ввод по умолчанию, обход "зависания" процессов и др.).
Удобный интерфейс помогает пользователю справиться с усталостью и напряжением при работе в условиях высокой ответственности за результат.

3.1.3 Этапы проектирования интерфейса

Разработка пользовательского интерфейса ведется параллельно разработке программного продукта в целом и в основном предшествует его внедрению. Процесс разработки эргономичного ПИ разбивается на следующие этапы:
1. Анализ производственной деятельности
анализ производственной деятельности пользователя, определение и спецификация его бизнес-функций. Формулировка требований к работе пользователя;
построение пользовательской модели данных (ERD), формирование рабочих мест.
2. Проектирование ПИ
выбор показателей оценки пользовательского интерфейса;
разработка обобщенного сценария взаимодействия пользователя с системой (функциональной модели) и его предварительная оценка пользователями и Заказчиком (бумажный прототип ПИ);
корректировка и детализация сценария взаимодействия, выбор и дополнение стандарта (руководства) для построения прототипа;
разработка макетов и прототипов ПИ и их оценка в деловой игре, выбор окончательного варианта.
При проектировании пользовательского интерфейса приведенная выше последовательность не является строго обязательной. Проектировщик может представить диалог в экранных формах.[1]
Наиболее распространенной ошибкой разработчика является именно отсутствие четкой проработки выполняемых действий. Без этого дальнейшая реализация оказывается несогласованной и может оказаться не соответствующей квалификационным требованиям, а на практике требованиям пользователя.
3. Реализация ПИ
реализация ПИ в коде, создание тестовой версии (визуализация);
разработка средств поддержки пользователя (пользовательские словари, подсказки, сообщения, помощь и пр.) и их встраивание в программный код.
4. Испытания ПИ
тестирование тестовой версии ПИ по набору ранее определенных показателей;
подготовка пользовательской документации и разработка программы обучения.

3.2 Принципы проектирования эргономичного пользовательского интерфейса

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

3.2.1 Размещение информации на экране

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

3.2.2 Непротиворечивость и стандартизация

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

3.2.3 Тексты и диалоги

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

3.2.4 Средства управления графического интерфейса пользователя

"Управление" - общий термин для компонентов интерфейса типа слайдеров, кнопок, кадров (фреймов), переключателей и т.д., которые служат, чтобы заместить объекты, являющимися знакомыми пользователям из реального мира.
Кнопки используются, чтобы выбрать опцию или вызвать событие (например, запуск подпрограммы).
Переключатели подобны кнопкам выбора, в которых пользователь выбирает значение из фиксированного списка, но в данном случае, пользователь может выбрать более чем одно значение из списка.
Слайдеры – обычно это элемент 'полоса прокрутки', они могут быть помещены или в горизонтальную или вертикальную линейку на экране.
Метки и текстовые блоки используются для текстовой информации. Различие между ними - текстовые поля, позволяют пользователю вводить текстовые данные в поля, в то время как метки - поля не редактируемые, используемые только для отображения текста, типа подсказок, команд пользователя и т.д.
Списки - специализированные средства управления, которые отображают раскрывающиеся списки значений (часто с присоединенными слайдерами, чтобы перемещаться вверх или вниз по списку) и позволяют пользователю выбирать значение из списка, или вводить другое значение в присоединенное текстовое поле. Списки – удобный и компактный элемент интерфейса, который занимает минимум места на экране и в то же время несет большую информационную нагрузку.[1]

3.2.5 Меню

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

3.2.6 Формы

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

3.2.7 Организация системы навигации и системы отображения состояний

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

3.2.8 Проектирование сообщений

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

3.2.9 Предотвращение, обнаружение и исправление ошибок

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

Глава 4. Построение концептуальной модели базы данных

4.1 Исследование предметной области применения и выявление требований конечных пользователей и решаемых задач

При разработке базы данных предполагается осуществить решение следующих задач:
1.  Предоставление общей информации о вагонах. Это совокупность сведений о каждом вагоне, стоящем на подъездном пути. Включает в себя общую информацию такую как: номер вагона, инвентарный номер вагона, год изготовления, грузоподъемность, род вагона, износ, район движения.
2.  Предоставление информации об имеющихся услугах.
3.  Предоставление информации о том, какой цех является арендатором каждого вагона.
4.  Предоставление информации об операциях с вагонами.
5.  Предоставление информации о грузах, перевозимых вагонами.
6.  Предоставление информации о районах движения вагонов.
7.  Предоставление информации о стоимости услуг.
8.  Ведение отчетности по вагонам.

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

Построение концептуальной модели данных проводилось методом нисходящего проектирования. Анализ определенных выше задач позволяет выделить таблицы проектируемой базы данных. В результате анализа были определены следующие объекты базы данных:
1. Общая информация о вагонах (ID, Месяц, Год, Номер_вагона, Инвентарный_номер, Год Изготовления, Грузоподъемность, Код_Род_Вагона, Износ, Код_Район_Движения).
Имя данной таблицы в Access задано как Vagon, что позволит без изменений вставить это название в базу данных (названия для остальных таблиц также будут приведены на английском языке). Эта таблица отводится для хранения основных сведений о вагонах. Поле ID - уникальный числовой идентификатор, счетчик. Поля Месяц и Год предназначены для определения даты появления вагона на предприятии. Поле Номер_Вагона предполагает ввод номера вагона в составе. Поле Инвентарный_номер является уникальным номером вагона. Поле Год_Изготовления указывает на год изготовления каждого вагона. Поле Грузоподъемность является количественной характеристикой вагона. Поле  Код_Род_Вагона указывает на род вагона, определённый в таблице "Род вагона". Поле Износ определяет степень износа вагона в процентах. Поле Код_Район_Движения указывает на район движения, определённый в таблице "Район движения".
2. Операции с вагоном (ID, Код_Станция_отправления, Код_Фронт_отправления, Код_Станция_назначения, Код_Фронт_назначения, Дата, Время, Код_Операции, Код_Груза, Вес, Номер_дорожной_ведомости, Номер_ведомости, Код_Вагона)
Определим название этой таблицы в Access как Operations_s_vagonom. Поле ID - уникальный числовой идентификатор, счетчик. Поля Код_Станция_отправления и  Код_Станция_назначения указывают на станции отправления и назначения, определенные в таблице "Станция". Поля Код_Фронт_отправления и Код_Фронт_назначения указывают на фронты отправления и прибытия, определенные в таблице "Фронт". Поля Дата и Время определяют дату и время проведения операции над вагоном. Поле Код_Операции указывает на операцию, определенную в таблице "Операция". Поле Код_Груза указывает на тип груза, определенный в таблице "Груз". Поле Вес хранит вес груза. Поля Номер_дорожной_ведомости и Номер_ведомости хранят номера ведомостей. Поле Код_Вагона указывает на вагон, определенный в таблице "Вагон".
3. Оказываемые услуги  (ID, Заказ, Код_вагона, Код_Услуги, Код_Цеха_отправителя, Код_Цеха_получателя, Цена)
Название этой таблицы в Access – Uslugi_sv. Поле ID - уникальный числовой идентификатор, счетчик. Поле Заказ определяет номера заказа. Поле Код_вагона указывает на  номер вагона, определенный в таблицы "Вагон". Поле Код_Услуги указывает вид услуги, определенный в таблице "Вид услуг". Поля Код_Цеха_отправителя и Код_Цеха_получателя указывают на номера цехов, определенные в таблице "Цеха". Поле Цена хранит стоимость обслуживания вагона, является вычисляемым полем.
4. Стоимость (ID, Код_вид_услуг, Код_веса, Стоимость)
Данная таблица (Stoimost) содержит информацию о стоимости предоставляемых услуг. Поле ID - уникальный числовой идентификатор, счетчик. Поле Код_вид услуг указывает на вид услуг, определенный в таблице "Вид услуг". Поле Код_веса указывает на единицу измерения объема выполняемых работ, определенную в таблице "Вес". Поле Стоимость хранит в себе стоимость  услуги, является вычисляемым полем.
5. Станции (ID, Станция)
Название таблицы в Access задано как Station. Данная таблица отводится для хранения списка станций. ID – уникальный идентификатор, счетчик. Поле Станция отводится под список станций.
6. Фронты (ID, Фронт)
Название таблицы  в Access определено как Front. ID – уникальный идентификатор, счетчик. Поле Фронт отводится под список фронтов.
7. Род вагона (ID, Род_вагона)
Данная таблица (Rod_vagona) представляет информацию о типах вагонов. ID – уникальный идентификатор, счетчик. Поле Род_вагона отводится под список типов вагонов.
8. Район движения (ID, Район_движения)
Таблица  Район движения (Raion_dvizheniya) содержит перечень районов, по которым двигаются вагоны. ID – уникальный идентификатор, счетчик. Поле Район движения отводится под список районов.
9. Операции (ID, Операция)
Таблица Операции (Operation) содержит список операций, производимых с вагоном. ID – уникальный идентификатор, счетчик. Поле Операция отводится под перечень операций.
10. Груз (ID, Груз)
Таблица Груз (Gruz) содержит список грузов, перевозимых вагонами. ID – уникальный идентификатор, счетчик. Поле Груз отводится под перечень грузов.
11. Цеха (ID, Номер_цеха, Балансовый_счет)
Таблица Цеха (Ceha) содержит список цехов, участвующих в операциях с вагонами. ID – уникальный идентификатор, счетчик. Поле Номер_цеха отводится под список цехов. Поле Балансовый_счет хранит номер балансового счета каждого цеха.
12. Вид услуг (ID, Вид_услуг)
Таблица Вид услуг (Vid_uslug) содержит список услуг, предоставляемых для работы с вагоном. ID – уникальный идентификатор, счетчик. Поле Вид_услуг отводится под перечень услуг.
13. Вес (ID, Вес)
Таблица Вес (Ves) предназначена для хранения единиц измерения для высчитывания стоимости предоставляемых услуг. ID – уникальный идентификатор, счетчик. Поле Вес отводится под перечень единиц измерения.

4.1.2 Инфологическая модель данных "сущность-связь"

Для построения инфологической модели данных использовалось CASE-средство MS Access 2003, которое позволяет проектировать реляционные модели данных. MS Access – является одновременно и CASE-средством, и средой разработки , и очень мощным визуальным средством создания отчетности, ядром СУБД и средой исполнения.
Наиболее распространенным средством моделирования данных являются диаграммы "сущность-связь" (ERD). С их помощью определяются важные для предметной области объекты (сущности), их свойства (атрибуты) и отношения друг с другом (связи).
Модель данных представлена в виде схемы данных на рис.4.1.

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

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. Поля key_station_otpr и key_station_naznach поддерживают ссылочную целостность с таблицей Operations_s_vagonom.
В таблице Front представлен список фронтов прибытия и отправления. Поля, их типы, и назначение представлены в таблице 4.7.
Таблица 4.7.
Первичным ключом является поле 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. Поля key_na и key_s поддерживают ссылочную целостность с таблицей Uslugi_sv. В таблице Vid uslug представлен список услуг, предоставляемых для работы с вагонами. Поля, их типы, и назначение представлены в таблице 4.13.
Таблица 4.13.
Первичным ключом является поле Id. Поле key_Vid_uslug поддерживает ссылочную целостность с таблицей Stoimost.
В таблице Ves представлен список единиц измерения для вычилсения стоимости услуг. Поля, их типы, и назначение представлены в таблице 4.14.
Таблица 4.14.
Первичным ключом является поле 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. Выбор инструментальных средств

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, одновременно являющейся и наиболее важной -  создание запросов. После подобного связывания таблицы выступают уже как одно целое, и теперь можно строить запросы применительно к любым данным в них. Можно выбирать конкретные поля, определять порядок сортировки, создавать вычисляемые выражения и вводить критерии отбора нужных записей. Созданные таким образом запросы стали основой для проектирования пользовательского интерфейса.