|
b>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] Стилевая гибкость: Возможность использовать различные интерфейсы с одним и тем же приложением, на практике реализуется с помощью таблицы стилей, в том числе возможность в выборе пользователем собственных установок пользовательского интерфейса (ПИ).Наращивание функциональности:Возможность развивать приложение без разрушения (т.е. оставаясь в рамках) существующего интерфейса. Масштабируемость: Возможность легко настраивать и расширять как интерфейс, так и само приложение при увеличении числа пользователей, рабочих мест, объема и характеристик данных. Адаптивность к действиям пользователя: Приложение должно допускать возможность ввода данных и команд множеством разных способов (клавиатура, мышь, другие устройства) и многовариантность доступа к прикладным функциям (иконы, "горячие клавиши", меню), кроме того, программа должна учитывать возможность перехода и возврат от окна к окну, от режима к режиму, и правильно обрабатывать такие ситуации.
Страницы: 1, 2, 3, 4, 5, 6, 7
|
