* Реляционные БД. Здесь данные хранятся в наборе таблиц и столбцов. Реляционные базы данных сочетают преимущества плоских файлов и иерархических баз данных, обеспечивая хорошую производительность и гибкость в хранении данных. Благодаря возможности определять связи между таблицами на основании уникальных значений, реляционные базы данных -- одни из самых популярных. Однако важно понимать, что другие модели также применяются и что разработчикам систем масштаба предприятия иногда приходится работать с несколькими типами баз данных одновременно. В реляционной модели основное внимание уделяется хранению, выборке и обеспечению целостности данных. Структурированный язык запросов SQL (Structured Query Language) позволяет эффективно извлекать связанные элементы данных вне зависимости от того, в одной или нескольких таблицах они хранятся. Целостность данных обеспечивается механизмом правил (rules) и ограничений (constraints).

В Белгородском филиале МЭСИ в настоящее время для хранения дынных применяется Microsoft SQL Server 2000. Поэтому для системы было выбрано предпочтение реляционной базе данных. Физическая модель отражает целевую среду реализации.

В процессе логического дизайна были проанализированы варианты использования системы для определения объектов-сущностей и атрибутов. Сущности и атрибуты формируют базис логического дизайна и используются в процессе физического дизайна для моделирования физического дизайна будущего продукта. Логический дизайн позволяет гарантировать, что дизайн данных решения корректно отражает концептуальные требования. Однако реальная инфраструктура хранения данных оптимизируется для среды, в которой предполагается реализовать физическую модель данных.

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

Определение таблиц

Таблицы являются физическим представлением объекте в-сущностей в реляционной базе данных. Они способны хранить самые разные данные -- имена, адреса, изображения, аудио и видео файлы, документы Microsoft Word и т.п. Благодаря своей гибкости базы данных применяются для хранения не только простых текстовых данных, но и корпоративной базы знаний предприятия, независимо от формы этих знаний. База данных представляет связи между различными элементами данных.

Данные в таблице хранятся в виде строк, или записей, каждая из которых должна быть уникальной.

Традиционный формат взаимодействия с реляционными данными -- ANSI строки, а язык -- SQL. Этот язык, напоминает английский и представляет операции, выполняемые с базой данных, в виде понятных человеку выражений, таких, как Insert (вставка), Update (обновление) и Delete (удаление). Большинство баз данных удовлетворяют ANSI-стандарту SQL, хотя его версии и расширения в разных системах отличаются.

Определение столбцов

Данные в каждой таблице хранятся в столбцах (колонках), или полях, которые определяются на основании атрибутов объекта-сущности, представленной и виде таблицы. Каждое поле содержит различные элементы данных, например имя пользователя.

В ходе анализа диаграммы сущность-связь были определены следующие таблицы:

1. Users.

2. UserRoles

3. Roles

4. Form

5. Common

6. Question

7. Answer

8. Survey

9. Results

Таблица Users содержит описание пользователей.

Таблица № 3.1

Таблица Roles содержит описание ролей пользователя

Таблица № 3.2

Сущности Пользователь и Роли состоят в отношениях один ко многим, поэтому в результате нормализации была выделена таблица UserRoles, в которой определенному пользователю соответствует определенная роль.

Таблица №3.3

Таблица Form содержит необходимую информацию об анкете

Таблица № 3.4

Таблица Question содержит список вопросов

Таблица № 3.5

Таблица Answer содержит список ответов на конкретный вопрос

Таблица № 3.6

Так как Анкета состоит из множества вопросов, а один и тот же вопрос может присутствовать в разных анкетах, то в результате нормализации была выделена таблица Common, в которой содержится список ответов на конкретный вопрос.

Таблица № 3.7

Таблица Survey содержит опубликованные анкеты по которым в данный момент происходит анкетирование

Таблица № 3.8

Рис. 3.11. Физическая модель данных

4. Разработка

4.1. Общие сведения этапа разработки

«Разработка» -- третья стадия модели процесса разработки MSF. Она следует за стадией «Планирование», которая завершается одобрением плана проекта. До сих пор проектная группа занималась в основном концепцией, архитектурой продукта и планированием. На стадии «Разработка» основная задача -- выполнение проекта.

Главный вопрос, которым задается проектная группа на этой стадии: как организовать разработку, чтобы создать спроектированный продукт в запланированные сроки? Ответ на этот вопрос основан на понимании концепции продукта с учетом необходимости выпуска работающего приложения.

Стадия «Разработка» завершается написанием кода и выпуском первой версии приложения. Результаты этапа «Завершение разработки» таковы:

? все необходимые функциональные возможности приложения реализованы (хотя, вероятно, и не самым оптимальным образом);

? продукт прошел первоначальное тестирование; продолжается устранение выявленных ошибок (завершение этой работы на данном этапе не обязательно);

? проектная группа и другие участники проекта согласны с тем, что все реализованные функциональные возможности отвечают концепции и функциональным спецификациям, и реализованы успешно;

? завершена подготовка к тестированию производительности продукта и его стабилизации.

Фаза «Разработка» во многом схожа с другими стадиями модели процесса разработки MSF. Например, фаза «Планирование» завершается подготовкой функциональных спецификаций. Эти документы становятся исходными для стадии «Разработка». Кроме того, они необходимы для оценки различных характеристик процесса разработки. Помните, что эти документы не остаются неизменными -- они вполне могут претерпевать изменения по мере выполнения стадии «Разработка». Эта стадия завершается, когда подготовлены пересмотренные варианты этих документов, а также:

? исходный код и исполняемые модули проекта;

? результаты исследования производительности;

? основные составляющие процесса тестирования.

Стадию «Разработка» программисты часто называют «настоящей работой». Действительно, основная ее задача - создание работающего продукта.

Проектирование архитектуры продукта на стадии «Проектирование» определяет успех его реализации на стадии «Разработка». Стив Мак-коннелл в своей книге «Software Project Survival Guide» описывает связь этих стадий, сравнивая их с движением против течения реки и по течению. Разработка архитектуры на стадии «Планирование», считает он, похожа на движение вверх по течению -- чем выше вы заберетесь, тем проще будет сплавляться вниз на стадии «Разработка». Этот процесс, начинающийся по завершении стадии проектирования и заканчивающийся выпуском продукта, будет тем успешнее и проще, чем лучше продумана архитектура.

Страницы: 1, 2, 3, 4, 5, 6, 7, 8