Целью проектирования на данном этапе является создание описания СУБД-ориентированной модели БД. Следует учитывать, что на этой стадии разработки возможны возвраты на более ранние этапы ЖЦ БД. Например, решения, принимаемые на этапе физического проектирования с целью повышения производительности системы, могут привести к необходимости внести в структуру логической модели данных.
Действия, выполняемые на этом этапе, слишком специфичны для различных моделей данных, поэтому их сложно обобщить. Остановимся на реляционной модели данных, поскольку проектируемая база данных в данной дипломной работе опирается на реляционную модель данных. В этом случае под физическим проектированием подразумевается:
создание описания набора реляционных таблиц и ограничений для них на основе информации, представленной в глобальной логической модели данных;
определение конкретных структур хранения данных и методов доступа к ним, обеспечивающих оптимальную производительность системы с базой данных;
разработка средств защиты создаваемой базы данных.
Физическая модель данных – модель, определяющая размещение данных на внешних носителях, методы доступа и технику индексирования. Она также называется внутренней моделью системы.[7]
Внешние модели (даталогические модели) никак не связаны с типом физической памяти, в которой будут храниться данные, и с методами доступа к этим данным. Внутренние модели (физические модели) наоборот определяют и оперируют размещением данных и их взаимосвязях на запоминающих устройствах.
Физическая организация данных оказывает основное влияние на эксплуатационные характеристики БД. Разработчики СУБД пытаются создать наиболее производительные физические модели данных, предлагая пользователям тот или иной инструментарий для настройки модели под конкретную БД.
Физическая модель данных является полностью компьютерно-ориентированной и конечные пользователи, а порой и прикладные программисты, не имеют никакого представления о том, каким образом данные запоминаются и извлекаются или каким способом организуются индексы в таблицах для быстрого поиска или ссылочная целостность.
Трехуровневая архитектура (инфологический, даталогический и физический уровни) позволяет обеспечить независимость хранимых данных от использующих их программ.
Этапы проектирования базы данных с учетом рассмотренных выше аспектов:
1. Проектирование инфологической (концептуальной) модели базы данных:
а) исследование предметной области применения и выявление требований конечных пользователей и решаемых задач;
б) анализ данных: сбор основных данных (объекты, связи между объектами);
в) построение ER-диаграммы базы данных.
2. Проектирование даталогической модели базы данных (учитывать требования СУБД). Сбор информации о потенциальных возможностях использования данных.
3. Проектирование физической модели базы данных:
а) создание описания набора реляционных таблиц и ограничений для них;
б) определение конкретных структур хранения данных и методов доступа к ним, обеспечивающих оптимальную производительность системы с базой данных;
в) разработка средств защиты создаваемой системы.
4. Реализация базы данных (оценка при неудовлетворительных эксплуатационных характеристиках).[7]
По этой схеме производилась реализация базы данных для последующего создания информационной системы учета вагонов на подъездном пути предприятия, что является конечной целью данной дипломной работы.
Глава 3. Проектирование пользовательского интерфейса
Проектирование пользовательского интерфейса – это довольно длительный и трудоемкий процесс. В процессе дизайна интерфейса выделяются три основных этапа, а именно: первоначальное проектирование (часто оказывающееся и окончательным), создание прототипа и тестирование/модификация прототипа. Фактически процесс дизайна, чтобы быть успешным и безусловным, всегда стремится происходить по спиральной модели в такой последовательности: проектирование, затем создание прототипа, затем тестирование/модификация, затем опять тестирование/модификация и т.д. Т.е. основным этапом оказывается не дизайн, а полировка уже сделанного дизайна.
Важность первоначального проектирования трудно переоценить. На нем закладываются основные концепции системы, влияющие абсолютно на все показатели качества интерфейса. Чем больше внимания будет уделено проектированию, тем выше будет общее качество. Определим требования, предъявляемые к пользовательскому интерфейсу, и принципы проектирования пользовательского интерфейса.
Минимизация усилий пользователя при выполнении работы:
• сокращение длительности операций чтения, редактирования и поиска информации;
• уменьшение времени навигации и выбора команды;
• повышение общей продуктивности пользователя, заключающейся в объеме обработанных данных за определенный период времени;
• увеличение длительности устойчивой работы пользователя и др.[1]
Стилевая гибкость:
Возможность использовать различные интерфейсы с одним и тем же приложением, на практике реализуется с помощью таблицы стилей, в том числе возможность в выборе пользователем собственных установок пользовательского интерфейса (ПИ).
Наращивание функциональности:
Возможность развивать приложение без разрушения (т.е. оставаясь в рамках) существующего интерфейса.
Масштабируемость:
Возможность легко настраивать и расширять как интерфейс, так и само приложение при увеличении числа пользователей, рабочих мест, объема и характеристик данных.
Адаптивность к действиям пользователя:
Приложение должно допускать возможность ввода данных и команд множеством разных способов (клавиатура, мышь, другие устройства) и многовариантность доступа к прикладным функциям (иконы, "горячие клавиши", меню), кроме того, программа должна учитывать возможность перехода и возврат от окна к окну, от режима к режиму, и правильно обрабатывать такие ситуации.
Независимость в ресурсах:
Для создания пользовательского интерфейса должны предоставляться отдельные ресурсы, направленные на хранение и обработку данных, необходимых для поддержки пользователя (пользовательские словари, контекстно-зависимые списки, наборы данных по умолчанию или по последнему запросу, истории запросов и пр.)
Переносимость:
При переходе на другую аппаратную (программную) платформу, должен осуществляется автоматически перенос и пользовательского интерфейса, и конечного приложения.
Для оценки необходимого уровня удобства интерфейса используются специальные экспертные анкеты, опросники, формуляры, check-листы.
В качестве методов используют:
• наблюдения за пользователями до использования ПИ, в процессе обучения и работы;
• отслеживание мотивации пользователя - мысли вслух, объяснение своих действий и намерений;
• постановка и протоколирование выполнения тестовых задач.
Главной целью с точки зрения эргономики (науки об эффективном взаимодействии человека и техники), самое важное в приложении – создать такой пользовательский интерфейс, который сделает работу эффективной и производительной, а также обеспечит удовлетворенность пользователя от работы с программой.
Эффективность работы означает обеспечение точности, функциональной полноты и завершенности при выполнении производственных заданий на рабочем месте пользователя. Эффективность работы отражает объем затраченных ресурсов при выполнении задачи, как вычислительных, так и психофизиологических.
Создание ПИ должно быть нацелено на показатели эффективности человеко-машинной системы, которые можно измерить количественно и объективно:
· производительность труда
Определяется средним количеством решенных задач, полученным по результатам работы группы пользователей.
· точность работы (количество ошибок)
Показатель точности включает процент ошибок, которые совершил пользователь: число ошибок набора, варианты ложных путей или ответвлений, число неправильных обращений к данным, запросов и пр.
Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29
