Домой	Поиск	Войти	Контакты		Добавить в избранное
					Сделать стартовой

ГЛАВНАЯ

ИНФОБЛОК

НОВОСТИ

ВОЙТИ

КОНТАКТЫ

БОЛЬШАЯ ЛЕНИНГРАДСКАЯ БИБЛИОТЕКА

МЕНЮ

Главная

Технология

Уголовное и уголовно-исполнительное право

Строительство и архитектура

Спорт и туризм

Социология и обществознание

Сельское лесное хозяйство и землепользование

Религия и мифология

Разное

Психология

Производство и технологии

Программирование компьютеры и кибернетика

Начертательная геометрия

Не сортированные

Оккультизм и уфология

Программирование и комп-ры

Экологическое право

Экология

Экономика

Экономико-математическое моделирование

Экономическая география

Финансовый менеджмент финансовая математика

Финансы деньги кредит

Разработка информационно-справочной системы по учету вагонов на подъездном пути предприятия

БОЛЬШАЯ ЛЕНИНГРАДСКАЯ БИБЛИОТЕКА - РЕФЕРАТЫ - Разработка информационно-справочной системы по учету вагонов на подъездном пути предприятия

Разработка информационно-справочной системы по учету вагонов на подъездном пути предприятия

Аннотация

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

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

При проектировании базы данных использовалось CASE-средство как ERwin 4.0. Также использовалась система управления реляционными базами данных Microsoft Access 2003. Среда Delphi 7.0 была выбрана в качестве средства для разработки СУБД

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

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

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

Annotation

This degree work is devoted to a theme "The development of the information system under the account of account materials and conduction statistics of a press". The system will be a real boon to companies that use both own and rented vehicles: it will allow you to automate the vehicles tracking process. The data base is freely distributed. The Case tool Erwin 4.0, Microsoft Access 2003, Delphi 7.0 were used at designing of database. This program has the clear interface adapted for simple and easy process of a press in company.

The following results have been reached during performance of system: the principal model of database, the logic normalized model of database were designed, the physical model of database was constricted, the technical tools were chosen, the basic program modules of system were realized, the ecological and ergonomic requirements were analyzed at designing the interface.

The information system has been developed on the basis of the received materials. This system is directed on automation the vehicles tracking process.

Оглавление

Аннотация 2
Annotation 3
Введение 6
Постановка задачи 9
Глава 1. Основы проектирования программных продуктов 12

1.1. Характеристика программных продуктов 12
1.2. Жизненный цикл программного обеспечения (ЖЦ ПО) 15
1.3. Модели жизненного цикла ПО 18
1.4. Структурный подход к проектированию ПП 20

Глава 2. Основные принципы проектирования базы данных 24

2.1. Понятие базы данных и системы управления базами данных 24
2.2. Основные свойства базы данных 24
2.3. Трехуровневая архитектура базы данных 26
2.4. Жизненный цикл базы данных 28

2.4.1. Планирование разработки базы данных 29
2.4.2. Определение требований к системе 30
2.4.3. Сбор и анализ требований пользователей 30
2.4.4. Проектирование базы данных 30
2.4.5. Разработка приложений 31
2.4.6. Реализация 31
2.4.7. Загрузка данных 32
2.4.8. Тестирование 32
2.4.9. Эксплуатация и сопровождение 33

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

2.5.1. Иерархическая модель данных 34
2.5.2. Сетевая модель данных 34
2.4.3. Реляционная модель данных 34

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

2.6.1. Нормализация как особенность проектирования базы данных 41
2.6.2. Концептуальное проектирование базы данных 44
2.6.3. Логическое проектирование базы данных 46
2.6.4. Физическое проектирование базы данных 48
2.6.5. Этапы проектирования базы данных 49

Глава 3. Проектирование пользовательского интерфейса 51

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

3.1.1. Методы оценки пользовательского интерфейса 53
3.1.2. Цели и критерии оценки пользовательского интерфейса 53
3.1.3. Этапы проектирования интерфейса 55

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

3.2.1. Размещение информации на экране 57
3.2.2. Непротиворечивость и стандартизация 58
3.2.3. Тексты и диалоги 58
3.2.4. Средства управления графического интерфейса пользователя 59
3.2.5. Меню 59
3.2.6. Формы 60
3.2.7. Организация системы навигации и системы отображения состояний 61
3.2.8. Проектирование сообщений 61
3.2.9. Предотвращение, обнаружение и исправление ошибок 62

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

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

4.1.1. Определение объектов базы данных и связей между объектами 63
4.1.2. Инфологическая модель данных "сущность-связь" 66

4.2. Проектирование логической модели базы данных 68
4.3. Проектирование физической модели базы данных 69

Глава 5. Реализация проекта 76

5.1. Набор компонентов, используемых для создания приложений 76
5.2. Работа с режимами программы Diplom 77

Глава 6. Выбор инструментальных средств 102

6.1. Выбор аппаратных средств 102
6.2. ERwin - современное средство проектирования баз данных 102
6.3. Microsoft Access 2003 105
6.4. Язык SQL как стандартный язык баз данных 108

6.4.1. Функциональные возможности языка SQL 109
6.4.2. Достоинства SQL 110

6.5. Среда Delphi как средство для разработки СУБД 110

6.5.1. Высокопроизводительный компилятор в машинный код 112
6.5.2. Библиотека визуальных компонент 113
6.5.3. Технологии доступа к данным 114
6.5.4. Элементы управления Windows XP 115
6.5.5. Генератор отчетов Rave Reports 5.0 116

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

7.1. Постановка задачи 117

Глава 8. Расчет затрат на создание программного обеспечения и оценка технико-экономической эффективности разработанного программного обеспечения 122

Введение 122
8.1. Расчет затрат на разработку системы учета компьютерного вагонов на подъездном пути на предприятии 122
8.2. Расчет затрат на основную заработную плату разработчикам 123
8.3. Расчет дополнительной заработной платы разработчиков программы 124
8.4. Расчет отчислений на социальное страхование и обеспечение 125
8.5. Расчет затрат на амортизацию ЭВМ, используемых при разработке системы учета компьютерного оборудования на предприятии 126
8.6. Расчет затрат на электроэнергию, используемую ЭВМ в процессе разработки программы 127
8.7. Расчет накладных расходов 128
8.8. Расчет затрат на эксплуатацию системы учета компьютерного оборудования на предприятии 129
8.9. Расчет отпускной цены разрабатываемой системы учета компьютерного оборудования на предприятии 132
8.10. Расчет окупаемости капитальных вложений 132

Заключение 134
Глава 9. Экологическая часть 136

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

9.1.1. Требования к помещениям для эксплуатации ВТ 137
9.1.2. Требования к освещению помещений и рабочих мест пользователей ВТ 138
9.1.3. Требования к шуму и вибрации в помещениях для эксплуатации ВТ 140
9.1.4. Требования к микроклимату, содержанию аэроионов и вредных химических веществ в воздухе помещений эксплуатации ВТ 141
9.1.5. Требования к уровням электромагнитных полей в помещениях для эксплуатации ВТ 143

9.2. Требования к организации и оборудованию рабочих мест пользователей и мест эксплуатации ВТ 144
9.3. Общие рекомендации к организации труда и отдыха при работе с ВТ 147

Заключение 150
Список литературы 152
Приложение 1 154
Введение
За последние годы в мире произошли значительные перемены, которые не могли не затронуть области информатики и вычислительной техники. Еще несколько лет назад работа с базами данных и электронными таблицами была уделом профессиональных программистов. Сами системы не были предназначены для широкого пользования. С появлением огромного числа банков, акционерных обществ и частных компаний ситуация резко изменилась.
В настоящее время обработка и хранение информации не является чисто умозрительной задачей. Потеря информации или ее несвоевременное получение могут обернуться потерей денег. Именно этими обстоятельствами можно объяснить столь бурный рост компьютерной техники и стремительное развитие электронных таблиц и систем управления базами данных (СУБД). Для оперативного, гибкого и эффективного управления предприятиями, фирмами и организациями различных форм собственности широко внедряются системы автоматизированного управления, ядром которых являются базы данных (БД). При большом объеме информации и сложности производимых с ней операций проблема эффективности средств организации хранения, доступа и обработки данных приобретает особое значение.
Данная дипломная работа посвящена теме "Разработка информационно-справочной системы по учету вагонов на подъездном пути предприятия".
Система учета подвижного состава предназначена для предприятий, использующих как собственный, так и арендованный подвижной состав, и позволяет автоматизировать процесс его учета. Помимо того, что система существенно облегчает и ускоряет определение местонахождения подвижного состава, она также позволяет анализировать затраты на стоимость его обслуживания.
База данных, разрабатываемая в данной дипломной работе, является свободно распространяемой, без каких-либо жестких ограничений. Это требование является желательным, поскольку не всегда руководители предприятий готовы пойти на уступки и оплачивать покупку того или иного программного обеспечения.
Разработанная база данных позволит автоматизировать обработку информации и оперативно реагировать на обстановки, что особенно важно в таком динамичном сегменте рынка как грузоперевозки. Кроме того, она сократит долю ручного труда при ведении учета и позволит автоматизировать процесс составления документов.
Для удобства учета программу можно разместить на внутреннем сервере компании, что позволит нескольким сотрудникам одновременно вводить информацию в одну БД. Это обеспечит равномерное распределение нагрузки на работников.
При проектировании базы данных использовалось такое мощное CASE-средство как ERwin 4.0, поскольку от того, насколько хорошо спроектирована база данных, зависит удобство ее дальнейшего использования и администрирования. Также использовалась система управления реляционными базами данных Microsoft Access 2003, которая предоставляет пользователям функциональные возможности, позволяющие осуществлять доступ к важным данным, и производить их глубокий анализ, а также является серьезной средой разработки приложений.
Среда Delphi 7.0 была выбрана в качестве средства для разработки СУБД, поскольку она отвечает следующим критериям: высокая скорость разработки приложений; возможность быстрого внесения изменений в программу; возможность редактирования и просмотра БД, используя средства разработки.
Программа обладает интуитивно понятным интерфейсом, полностью адаптированным к простому и необременительному процессу печати в компании.
Постановка задачи
Темой дипломной работы является "Разработка информационно-справочной системы по учету вагонов на подъездном пути предприятия" и пользовательского интерфейса к ней. Вопрос автоматизации процесса учета вагонов до сих пор остается открытым и актуальности терять не собирается. Данная информационная система (ИС) позволит специалистам оперативно получать и анализировать данные о наличии, состоянии и точном местонахождении вагонов.
Информационная система должна представлять собой базу данных, позволяющую вести учет вагонов на подъездном пути предприятия и обеспечивать расчет затрат на обслуживание вагонов и интерфейс к ней.
ИС должна обеспечивать выполнение всех этих действий, а также должна обладать удобным и простым для восприятия интерфейсом и справочной системой.
Исходными данными БД являются:
1. вагон:

инвентарный номер;

год изготовления;

грузоподъемность;

износ;

род вагона;

район движения;

2. операции с вагоном:

станция отправитель;

станция получатель;

фронт получения/отправления;

груз;

вес груза;

операция;

3. вид работ:

вид работ;

единица измерения;

цена за единицу измерения

База данных должна отвечать следующим требованиям:

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

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

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

в БД должна быть предусмотрена печать отчетов.

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

Задачи, решаемые с помощью системы:

Загрузка в систему информации о вагонах, обработка информации;

Ведения перечня используемых вагонов, хранение информации о выполненных работах;

Определение текущего местонахождения вагонов;

Ввод, хранение, поиск и вывод информации о вагонах на подъездных путях;

Расчет стоимости обслуживания вагонов;

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

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

Автоматизированная обработка получаемой информации.

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

Быстрый поиск информации. Поиск необходимой информации о вагоне занимает секунды.

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

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

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

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

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

Глава 1. Основы проектирования программных продуктов

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

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

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

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

Основными характеристиками программ являются:

алгоритмическая сложность (логика алгоритмов обработки информации);

состав и глубина проработки реализованных функций обработки;

полнота и системность функций обработки;

объем файлов программ;

требования к операционной системе и техническим средствам обработки со стороны программного средства;

объем дисковой памяти;

размер оперативной памяти для запуска программ;

тип процессора;

версия операционной системы;

наличие вычислительной сети и др.

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

насколько хорошо (просто, надежно, эффективно) можно использовать программный продукт;

насколько легко эксплуатировать программный продукт;

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

Характеристики качества программных продуктов:

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

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

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

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

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

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

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

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

1.2. Жизненный цикл программного обеспечения (ЖЦ ПО)

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

Основным нормативным документом, регламентирующим ЖЦ ПО, является международный стандарт ISO/IEC 12207 (ISO - International Organization of Standardization - Международная организация по стандартизации, IEC - International Electrotechnical Commission - Международная комиссия по электротехнике). Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО.

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

1. формирование требований (анализ)

2. проектирование

3. реализация (кодирование)

4. тестирование

5. внедрение

6. сопровождение

7. снятие с эксплуатации

Стадия анализа предназначена для изучения требований к создаваемому программному продукту, а именно:

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

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

требование к комплексу технических и программных средств для эксплуатации программного продукта и т.д.

На данном этапе необходимо выполнить формализованную постановку задачи.

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

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

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

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

Снятие программного продукта с продажи и отказ от сопровождения происходят, как правило, в случае неэффективности работы программного продукта, наличия в нем неустранимых ошибок, отсутствия спроса.[1]

Длительность жизненного цикла для различных программных продуктов неодинакова. Для большинства современных программных продуктов длительность жизненного цикла измеряется в годах (2-3 года). Хотя достаточно часто встречаются на компьютерах и давно снятые с производства программные продукты.

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

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

1.3. Модели жизненного цикла ПО

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

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

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

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

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

На практике наибольшее распространение получили две основные модели жизненного цикла:

каскадная модель (характерна для периода 1970-1985 гг.);

спиральная модель (характерна для периода после 1986.г.).

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

Можно выделить следующие положительные стороны применения каскадного подхода:

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

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

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

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

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

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

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

1.4 Структурный подход к проектированию ПП
Проектирование любого программного продукта основано не только на выборе модели ЖЦ ПО и разделении работ по его созданию на стадиях проектирования, но и на выборе подхода к проектированию. В дипломной работе разработка информационно-справочной системы учета вагонов велась с помощью структурного подхода.
Сущность структурного подхода заключается в декомпозиции (разбиении) системы на автоматизируемые функции: система разбивается на функциональные подсистемы, которые в свою очередь делятся на подфункции, подразделяемые на задачи и так далее. Процесс разбиения продолжается вплоть до конкретных процедур. При этом автоматизируемая система сохраняет целостное представление, в котором все составляющие компоненты взаимоувязаны. При разработке системы "снизу-вверх" от отдельных задач ко всей системе целостность теряется, возникают проблемы при информационной стыковке отдельных компонентов.
Наиболее распространенные методологии структурного подхода базируются на ряде общих принципов. В качестве двух базовых принципов используются следующие:
принцип "разделяй и властвуй" - принцип решения сложных проблем путем их разбиения на множество меньших независимых задач, легких для понимания и решения;
принцип иерархического упорядочивания - принцип организации составных частей проблемы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне.
Выделение двух базовых принципов не означает, что остальные принципы являются второстепенными, поскольку игнорирование любого из них может привести к непредсказуемым последствиям (в том числе и к провалу всего проекта). Основными из этих принципов являются следующие:
принцип абстрагирования заключается в выделении существенных аспектов системы и отвлечения от несущественных;
принцип формализации заключается в необходимости строгого методического подхода к решению проблемы;
принцип непротиворечивости заключается в обоснованности и согласованности элементов;
принцип структурирования данных заключается в том, что данные должны быть структурированы и иерархически организованы.[1]
Методологии, технологии и инструментальные средства проектирования (CASE-средства) составляют основу проекта любой информационной системы. Методология реализуется через конкретные технологии и поддерживающие их стандарты, методики и инструментальные средства, которые обеспечивают выполнение процессов ЖЦ.
В структурном анализе используются в основном две группы средств, иллюстрирующих функции, выполняемые системой и отношения между данными. Каждой группе средств соответствуют определенные виды моделей (диаграмм), наиболее распространенными, среди которых являются следующие:
SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы;
DFD (Data Flow Diagrams) диаграммы потоков данных;
ERD (Entity-Relationship Diagrams) диаграммы "сущность-связь".
Наиболее распространенным средством моделирования данных являются диаграммы "сущность-связь" (ERD). Данное средство было использовано в дипломной работе для проектирования специализированной базы данных, на основе которой разрабатывалась система учета подвижного состава на подъездном пути. С помощью ER-диаграмм определяются важные для предметной области объекты (сущности), их свойства (атрибуты) и отношения друг с другом (связи). ERD непосредственно используются для проектирования реляционных баз данных, что соответствует выбранной модели базы данных, проектируемой в данной дипломной работе.[1]
Введем понятия сущности, атрибута и связи, поскольку на этих понятиях основано проектирование базы данных, которое будет рассмотрено в следующей главе.
Сущность - это реальный или воображаемый объект, имеющий сущностные значения для рассматриваемой предметной области, информация о котором подлежит хранению. Тип сущности характеризуется независимым существованием и представляет множество объектов реального мира с одинаковыми свойствами. Отдельные объекты, которые входят в данный тип, называют экземплярами объекта.
Атрибут - любая характеристика сущности, значимая для рассматриваемой предметной области и предназначенная для квалификации, идентификации, классификации, количественной характеристики или выражения состояния сущности.
Связь - поименованная ассоциация между двумя сущностями, значимая для рассматриваемой предметной области.[1]
Глава 2. Основные принципы проектирования базы данных
2.1 Понятие базы данных и системы управления базами данных
База данных (БД) - именованная совокупность данных, отражающая состояние объектов и их отношений в рассматриваемой предметной области, или иначе БД - это совокупность взаимосвязанных данных при такой минимальной избыточности, которая допускает их использование оптимальным образом для одного или нескольких приложений в определенной предметной области.[3]
В любом бизнесе имеются данные, что в свою очередь требует создания некоторого организованного метода или механизма управления этими данными. Такой механизм принято называть системой управления базами данных (СУБД). Основываясь на современных технологиях, доказавших свою пользу системы управления базами данных начали развиваться в других направлениях, отвечая требованиям растущего бизнеса, все возрастающих объемов корпоративных данных и, конечно же, технологий, связанных с Internet.
Современная волна информационных технологий управления основывается на использовании систем управления реляционными базами данных (СУРБД), которые являются развитием традиционных СУБД. Реляционные базы данных и технологии клиент/сервер являются типичной комбинацией, позволяющей современным компаниям успешно обрабатывать данные и оставаться конкурентоспособными в своих секторах рынка.
2.2 Основные свойства базы данных
Для успешной реализации системы на основе базы данных на первом месте стоит проектирование структуры данных, а затем только осуществляется разработка приложений. Плохо спроектированная база данных будет поставлять некорректную информацию, порождать ошибки, способные привести к принятию неправильных решений.
Проектируемая БД должна обладать определенными свойствами. Ниже перечислены основные свойства базы данных.
Целостность. В каждый момент существования базы данных сведения, содержащиеся в ней, должны быть непротиворечивы. Целостность БД достигается вследствие введения ограничений целостности, в частности, к ним относятся ограничения, связанные с нормализацией БД. Желательно отслеживать диапазон допустимых значений, соотношения между значениями в полях, особенности написания формата. Существуют ограничения, работающие только при удалении записей.
Восстанавливаемость. Данное свойство предполагает возможность восстановления БД после сбоя системы или отдельных видов порчи системы. Сюда относится проверка наличия файлов, составляющих приложение. В основном свойство восстанавливаемости обеспечивается дублированием БД и использованием техники повышенной надежности.
Безопасность. Безопасность БД предполагает защиту данных от преднамеренного и непреднамеренного доступа, модификации или разрушения. Применяется запрещение несанкционированного доступа, защита от копирования и криптографическая защита. Также необходимы и административные меры, например ограничение доступа к носителям информации.
Эффективность. Свойство эффективности обычно понимается как:
минимальное время реакции на запрос пользователя;
минимальные потребности в памяти;
сочетание этих параметров.
Предельные размеры и эксплуатационные ограничения. Предельные размеры, а также другие ограничения, накладываемые эксплуатацией данной БД, могут существенно повлиять на проектное решение.[3]
2.3. Трехуровневая архитектура базы данных
Проектирование БД связано с разрешением проблем представления данных и их обменом между конечными пользователями. Они продиктованы различными потребностями и задачами лиц, которые используют эти данные. Можно выделить четыре категории лиц, каждая из которых имеет свой круг интересов и связана с определенным этапом разработки и существования БД. Определим эти основные категории лиц, а также их роли и функции на разных стадиях существования баз данных:
администраторы данных и баз данных;
разработчики баз данных;
прикладные программисты;
конечные пользователи.
Данные - это важный ресурс организации, и ими надо умело управлять. Столь важная функция возложена на специалистов определенного рода - Администраторов данных (АД). Они работают с данными с самого начала процесса проектирования БД и отвечают за концептуальное и логическое проектирования БД, управление данными, разработку и сопровождение стандартов, бизнес-правил и деловых процедур.
Физическое проектирование и физическая реализация базы данных, обеспечение безопасности и целостности данных, обеспечение максимальной производительности приложений - это область действия компетенций Администратора базы данных (АБД). Как видно по сравнению с АД, обязанности АБД более связаны с решением технических проблем.
Разработчики баз данных - это такая группа специалистов, которая функционирует во время проектирования, создания и реорганизации базы данных и результатом деятельности которой является хорошо спроектированная БД, снабжающая достоверной и непротиворечивой информацией всех заинтересованных в этом лиц.
При проектировании больших БД все разработчики распадаются на две группы:
разработчики логической базы данных;
разработчики физической базы данных.
Разработчики логической БД занимаются выявлением интересующих объектов и их свойств, связей между объектами и тех ограничений, которые необходимо наложить на хранимые данные. Осуществление своей деятельности указанные разработчики выполняют в два этапа, которые в последующих главах будут рассмотрены подробно:
разработка концептуальной модели БД;
разработка логической модели БД.
Разработчики физической БД должны разбираться в функциональных возможностях выбранной СУБД, знать все варианты возможного физического воплощения полученной логической модели данных и понимать их достоинства и недостатки с тем, чтобы выбрать наиболее оптимальный вариант для данного случая и правильно выстроить всю стратегию хранения и использования данных.
Сразу после создания БД следует приступить к разработке приложений, предоставляющих пользователям необходимые им функциональные возможности. Именно эту работу выполняют прикладные программисты.
Пользователи. База данных проектируется, создается и поддерживается для того, чтобы обслуживать информационные потребности конечных пользователей. Для них разрабатываются такие приложения, которые позволяют в максимальной степени упростить выполняемые ими операции.
Чтобы различать представления данных конечными пользователями, программистами и АБД создаются разные уровни моделей данных. Их общая структура представлена на рисунке 2.1.
2
Рис.2.1. Уровни моделей данных
Основным назначением трехуровневой архитектуры является обеспечение независимости от данных. Суть этой независимости заключается в том, что изменения на нижних уровнях никак не влияют на верхние уровни.[3]
Основное различие между указанными выше тремя типами моделей данных (концептуальной, логической и физической) состоит в способах представления взаимосвязей между объектами. При проектировании БД требуется различать взаимосвязи между объектами, между свойствами одного объекта и между свойствами различных объектов.
2.4. Жизненный цикл базы данных
Как и любой программный продукт, база данных обладает собственным жизненным циклом (ЖЦ БД). Главной составляющей в жизненном цикле БД является создание единой базы данных и программ, необходимых для ее работы. Жизненный цикл системы базы данных определяет и жизненный цикл всей информационной системы организации, поскольку база данных является фундаментальным компонентом информационной системы.
ЖЦ БД включает в себя следующие основные этапы:
· планирование разработки базы данных;
· определение требований к системе;
· сбор и анализ требований пользователей;
· проектирование базы данных:
· концептуальное проектирование базы данных;
· логическое проектирование базы данных;
· физическое проектирование базы данных;
· разработка приложений;
· реализация;
· загрузка данных;
· тестирование;
· эксплуатация и сопровождение.
2.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 Этапы проектирования базы данных
Этапы проектирования базы данных с учетом рассмотренных выше аспектов:
Проектирование инфологической (концептуальной) модели базы данных:
а) исследование предметной области применения и выявление требований конечных пользователей и решаемых задач;
б) анализ данных: сбор основных данных (объекты, связи между объектами);
в) построение ER-диаграммы базы данных.
Проектирование даталогической модели базы данных (учитывать требования СУБД). Сбор информации о потенциальных возможностях использования данных.
Проектирование физической модели базы данных:
а) создание описания набора реляционных таблиц и ограничений для них;
б) определение конкретных структур хранения данных и методов доступа к ним, обеспечивающих оптимальную производительность системы с базой данных;
в) разработка средств защиты создаваемой системы.
Реализация базы данных (оценка при неудовлетворительных эксплуатационных характеристиках).[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 - уникальный идентификатор, счетчик. Поле Номер_цеха отводится под список цехов. Поле Балансовый_счет хранит номер балансового счета каждого цеха.

	НОВОСТИ

Изменения

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

	СЧЕТЧИК

БОЛЬШАЯ ЛЕНИНГРАДСКАЯ БИБЛИОТЕКА
	© 2010