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

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