АвтоАвтоматизацияАрхитектураАстрономияАудитБиологияБухгалтерияВоенное делоГенетикаГеографияГеологияГосударствоДомДругоеЖурналистика и СМИИзобретательствоИностранные языкиИнформатикаИскусствоИсторияКомпьютерыКулинарияКультураЛексикологияЛитератураЛогикаМаркетингМатематикаМашиностроениеМедицинаМенеджментМеталлы и СваркаМеханикаМузыкаНаселениеОбразованиеОхрана безопасности жизниОхрана ТрудаПедагогикаПолитикаПравоПриборостроениеПрограммированиеПроизводствоПромышленностьПсихологияРадиоРегилияСвязьСоциологияСпортСтандартизацияСтроительствоТехнологииТорговляТуризмФизикаФизиологияФилософияФинансыХимияХозяйствоЦеннообразованиеЧерчениеЭкологияЭконометрикаЭкономикаЭлектроникаЮриспунденкция

Построение физической модели БД

Читайте также:
  1. II. Право на фабричные рисунки и модели (прикладное искусство), на товарные знаки и фирму
  2. Автокорреляция остатков модели регрессии. Последствия автокорреляции. Автокорреляционная функция
  3. Аддитивная и мульпликативная модели временного ряда
  4. Адекватность трендовой модели
  5. Алгоритм оценки и проверки адекватности нелинейной по параметрам модели (на примере функции Кобба-Дугласа).
  6. Алгоритм проверки адекватности множественной регрессионной модели (сущность этапов проверки, расчетные формулы, формулировка вывода).
  7. Алгоритм проверки адекватности парной регрессионной модели.
  8. Алгоритм проверки адекватности парной регрессионной модели.
  9. Алгоритм проверки значимости регрессоров во множественной регрессионной модели: выдвигаемая статистическая гипотеза, процедура ее проверки, формулы для расчета статистики.
  10. Альтернативные модели потребления.
  11. Анализ дискреционной налогово-бюджетной и кредитно-денежной политики с помощью модели «IS-LM».
  12. Анализ и моделирование функциональной области внедрения ИС.

Так как в концептуальной модели присутствует связь многие-ко-многим (Проекты – программисты), то в физическую схему БД была добавлена еще одна таблица, описывающая связь проектов и программистов: UsersOnProject.

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

Итоговая физическая модель БД приложения представлена на рис 2.

Рис. 2 Физическая модель БД

 

Описание хранимых процедур и триггеров

Триггеров и хранимых процедур в БД нет


 

Проектирование клиентской части

Архитектура ПО

В качестве архитектурного шаблона был выбран шаблон MVC

Model - view - controller (MVC, «Модель-представление-поведение», «Модель-представление-контроллер») — схема использования нескольких шаблонов проектирования, с помощью которых модель данных приложения, пользовательский интерфейс и взаимодействие с пользователем разделены на три отдельных компонента так, что модификация одного из компонентов оказывает минимальное воздействие на остальные. Данная схема проектирования часто используется для построения архитектурного каркаса.

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

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

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

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

Концепция MVC позволяет разделить данные, представление и обработку действий пользователя на три отдельных компонента:

· Модель (англ. Model). Модель предоставляет знания: данные и методы работы с этими данными, реагирует на запросы, изменяя своё состояние. Не содержит информации, как эти знания можно визуализировать.

· Представление, вид (англ. View). Отвечает за отображение информации (визуализация). Часто в качестве представления выступает форма (окно) с графическими элементами.

· Контроллер (англ. Controller). Обеспечивает связь между пользователем и системой: контролирует ввод данных пользователем и использует модель и представление для реализации необходимой реакции.

Представление, так и контроллер зависят от модели. Однако модель не зависит ни от представления, ни от контроллера. Тем самым достигается назначение такого разделения: оно позволяет строить модель независимо от визуального представления, а также создавать несколько различных представлений для одной модели


1 | 2 |

Поиск по сайту:

Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Студалл.Орг (0.003 сек.)