Концептуальное, логическое и физическое проектирование данных
Цель проектирования: отображение предметной области в структуре хранимых данных. Требования: 1) полнота отображения и адекватность области; 2) эффективность использования.Эти требования противоречат друг другу.Общая схема проектирования: сбор информации ->требования ->концептуальное моделирование (инфологическое) ->логическое ->физическое.
Концептуальное проектирование: Исходная информация – результат сбора данных и анализа требований.Результат – концептуальная модель, спецификация, описание модели.Этапы:
1. Определение сущностей: основные и подчинённые. Если тип может автономно существовать, то он является сущностью, если же он не может существовать без других сильных сущностей, то она подчинённая.
2. Определение связей: для связей определяется множественность (кардинальность), обязательность.
3. Определение атрибутов: указываются свойства множественности, обязательности, атомарности. Определяются вычисляемые атрибуты.
4. Определение идентификаторов сущностей: определяются для основных сущностей, для слабых могут не определяться либо определяться локально.
5. Определение доменов: желательно с точки зрения теории, но на практике не всегда применяется.
По полученной модели может быть проведена проверка на выполнимость транзакций: проверяется связанность данных, используемых транзакцией.
Логическое проектирование: Исходные данные: концептуальная модель и тип логической модели.Результат: отношения для реляционной модели с их спецификацией.Этапы:
|
|
|
1. Преобразование в логическую модель, устранение свойств концептуальной модели, не соответствующие логической модели. Это осуществляется переходом к одноуровневым равноправным таблицам, заменой связей «многие ко многим» ассоциациями, выносом множественного атрибута в отдельное отношение с идентификатором.
2. Определение набора отношений:Сущности и ассоциации преобразуются в отношения, идентификаторы – в первичные ключи. Для неосновных сущностей вводятся внешние ключи, соответствующие первичным ключам связи. Идентификатор неосновной сущности состоит из набора внешних ключей и локального идентификатора.3. Проверка нормализованности отношений.4. Проверка выполнимости транзакций.5. Проверка на избыточность связей.6. Определение ограничений целостности.
Физическое проектирование:Назначение: определение конкретных структур данных в среде конкретной СУБД и в наборе ЗУ.
1. Выбор физических параметров хранения. 2. Определение структур хранения Д.3. Определениеиндексов. 4. Определение типов и размерностей хранения Д. 5. Определение необходимости изменения базы для улучшения характеристик:-введение дополнительных полей; - вертикальное или горизонтальное расщепление; -слияние таблиц. 6. Реализация ограничений. 7. Определение процедур управления хранением Д и доступом к Д. 8. Разработка представлений.
|
|
|
11. Разработка пользовательского интерфейса. Общие вопросы:
1) Необходимость постоянного согласования с пользователем. Формы согласования: - рисунок на начальной стадии, эскиз;- прототип по ходу разработки (внешний вид, навигация);- спецификация (описывает внешний вид, источники вх/вых Д, состав Д, назначение элементов управления ).
2) Интерфейс можно представить тремя видами моделей: - ментальная (чего ожидает пользователь);- декларативная (что предоставляет интерфейс);
- реализации (реальное поведение системы).
Декларативная должна максимально приближаться к ментальной, а реализация максимально прятаться.
3) Интерфейс должен учитывать уровень пользователя. Существует 3 уровня:
- начинающий пользователь. Его интересы – это то, для чего система предназначена, что может сделать. Интерфейс должен включать: - начальное окно; - интерактивные учебники; - помощь с описанием методологии и последовательность их использования, примеры и шаблоны.
|
|
|
- квалифицированный пользователь. Его интересы – как решить задачу, как выполнить операцию: -Контекстное меню; - Контекстная помощь; -Интерактивная помощь с полным индексом по операциям; - Активные средства подсказки; -Информативное оформление экранов.
- эксперт. Его интересы - как быстро выполнить задачу: - Горячие клавиши;-Макросы; - Настройка интерфейса и сохранение; -Командная строка; - отключение ненужных возможностей; - индивидуальная настройка; - несколько вариантов решения.
4) Интерфейс должен минимизировать действия пользователя:
- исключить все ненужные шаги, излишние подтверждения и предупреждения;
- по возможности заменить ввод на выбор из имеющихся Д;
- максимально автоматизировать постобработку, например, ввести автонумерацию, форматирование после ввода и т.д.
5) Интерфейс должен минимизировать умственные усилия пользователя:
- максимальная унификация; - стандартизация приёмов и горячих клавиш;
- единое оформление помощи;- информативность надписей, сообщений, подсказок; - естественность навигации и т.д.
При разработке интерфейса определяется общая архитектура организации кадров, определение элементов, а также средств поддержки пользователя.
|
|
|
Общая архитектура: Имеется несколько общепринятых стилей:
Классический интерфейс. Единое главное окно, использующее весь экран. Составляющие: меню, инструментальные панели, основное окно, строка статуса. Прочие окна открываются как дочерние.
Диалоговая панель – основное окно содержит элементы вызова задач (набор кнопок). Вызовы из главного окна соответствуют запуску отдельных процессов или работе с отдельными типами данных. Недостаток – трудно связывать между собой отдельные задачи.
Стиль-проект – главного окна нет, выводится меню, инструментальная панель, все задачи запускаются как самостоятельные приложения.
Дополнительные стили для работы с отдельными формами:
Рабочая книга (Builder, Excel) – набор вкладок, на которых размещаются Д и управляющие средства.
Проводник – навигатор по доступной информации;
Мастер (установка ПО) – последовательное развертывание по экранам решения задач. Большой объем поясняющего текста и вводимых Д.
Результат проектирования архитектуры – диаграмма последовательности экранных форм или схема диалога, где указывается: - условие перехода; - ограничение перехода;- действия при переходе.
В архитектуре может быть использован однодокументный и многодокументный интерфейс. В архитектуре может быть использован синхронный и асинхронный принцип. При синхронном принципе используется модульность форм, разрешается активировать только формы, соседние по связям. В асинхронном интерфейсе несколько форм инициализировано, свободный переход из одной формы в другую.
Информация на формах. БД на экранных формах представляются в виде:
Одной таблицы: - фактическая таблица (вывод и поиск всех данных). Рекомендуется форма для общего просмотра, отбора, поиска; - бланк (данные из одной записи). Рекомендуется для редактирования, просмотра больших записей; - комбинированный вариант (обе формы на одной экранной форме).
Двух таблиц со связью 1:1 – полезно объединить в одну виртуальную таблицу для удобного чтения.
Двух таблиц со связью 1:М: - управление с единичной стороны – вывод на форму родительской таблицы и перечня записей из дочерней таблицы, относящихся к ней; - управление с множественной стороны – вызов справки из ассоциации (родительской таблицы из дочерней) путем создания единой виртуальной таблицы или вывода отдельных полей для каждой записи.
Трех и более таблиц – выполняется разбивка на несколько последовательных форм, на каждой форме 1-2 таблицы. При показе двух таблиц возможно наложение данных по формам.
Выбор используемых элементов.Зависит от типа информации с учетом оптимальности применения к ментальности пользователя.
Для представления данных используются:
универсальный вариант – текстовое поле (с настройкой типа и формата для удобства пользователя);
ввод логических данных – индикатор, кнопка с фиксацией;
выбор одного из нескольких вариантов – комбо, список, радиокнопки;
выбор нескольких вариантов – список с пометкой, таблица с пометкой, набор флагов, сопряженные списки;
ввод даты-времени – специализированные компоненты, набор составляющих;
ввод числовых данных – текстовое поле с настройкой формата, разбивка на элементы.Средства поддержки:
Пассивные – не требуют специальных действий пользователя (названия, пояснения на формах, всплывающие подсказки, подсказки в меню по горячим клавишам, строка статуса);
Реактивные – требуют специальных действий пользователя (контекстная помощь, контекстное меню, кнопка «Что такое?»);
Активные – отслеживают работу пользователя, прогнозируют ход событий, пытаются создавать подсказки или управлять дальнейшим поведением пользователя (вывод подсказок по набору команд).
В данном случае сообщения об ошибках занимают промежуточное положение между пассивными и реактивными средствами.
Дата добавления: 2018-02-15; просмотров: 1080; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!