3.4.3 Создание физической модели данных

База данных (БД) — это особым образом организованный набор значений данных, а схема БД определяет, как именно организованы данные в БД. В процессе физического дизайна члены проектной команды создают схему БД, чтобы определить, что именно нужно создавать, о том же, какими инструментами это будет реализовываться, следует думать позже.

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

В начале разработки схемы БД она сильно связана с логической моделью объектов. Схема определяет главные объекты-сущности, необходимые для будущего решения, их атрибуты и связи между этими сущностями. В большинстве методов моделирования данных сущность определяется как абстрактное представление объекта реального мира. Как правило, объекты базы данных моделируются в диаграммах «сущность-связь». Логический дизайн базы данных был рассмотрен на стадии логического проектирования.

Типы физических моделей данных

Помимо определения логического дизайна базы данных необходимо выбрать технологию физического хранении данных. Физическая модель данных системы управления базами данных (СУБД) определяет внутреннюю структуру, которая применяется в СУБД для управления данными. В этой структуре отражены типы таблиц базы данных, которые разрешается создавать, а также скорость доступа и универсальность базы данных. Далее перечислены наиболее распространенные типы физических моделей данных.

• БД на плоских файлах, или неструктурированные БД. В такой базе данных все данные располагаются в одном файле в виде набора строк и столбцов. В этой архитектуре отсутствует связь между различными плоскими файлами, поскольку ни одна из этих БД ничего не знает об остальных. Она поддерживает быстрое обновление и чтение данных за счет метода индексирования ISAM (indexed sequential access method — индексно- последовательны и метод доступа). Технология ISAM применяется в унаследованных мэйнфреймовых БД и небольших базах данных, располагающихся на ПК.

• Иерархические БД способны хранить самую разнообразную информацию в самом различном формате. Их отличает расширяемость и гибкость, поэтому подобные БД используются, когда требования по хранению информации могут сильно отличатся или изменяться. Пример иерархической базы данных — сервер Microsoft Exchange, способный хранить самые различные типы информации в формате, который удовлетворяет требованиям приложений обмена сообщениями и поддержки совместной работы. Эти требования заключаются в возможности инкапсуляции в сообщениях самой разнородной информации.

• Реляционные БД. Здесь данные хранятся в наборе таблиц и столбцов. Реляционные базы данных сочетают преимущества плоских файлов и иерархических баз данных, обеспечивая хорошую производительность и гибкость в хранении данных. Благодаря возможности определять связи между таблицами на основании уникальных значений, реляционные базы данных — одни из самых популярных. Однако важно понимать, что другие модели также применяются и что разработчикам систем масштаба предприятия иногда приходится работать с несколькими типами баз данных одновременно. В реляционной модели основное внимание уделяется хранению, выборке и обеспечению целостности данных. Структурированный язык запросов 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

Поле таблицы Тип данных Описание
UserID INTEGER Уникальный идентификатор пользователя
Login: VARCHAR(20) Логин пользователя
Password VARCHAR(100) Пароль пользователя
LastName VARCHAR(100) Фамилия
Email VARCHAR(100) Электронная почта
FirstName VARCHAR(100) Имя пользователя

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

Таблица № 3.2

Поле таблицы Тип данных Описание
RoleID INTEGER Уникальный идентификатор
RoleName VARCHAR(100) Название роли
Description VARCHAR(100) Описание роли

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

Таблица №3.3

Поле таблицы Тип данных Описание
UserRoleID INTEGER Уникальный идентификатор
UserID VARCHAR(100) Идентификатор пользователя
RoleID VARCHAR(100) Идентификатор роли

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

Таблица № 3.4

Поле таблицы Тип данных Описание
FormID INTEGER Уникальный идентификатор пользователя
FormName VARCHAR(250) Название анкеты
CreatedDate DATETIME Дата создания
Author VARCHAR(100) Идентификатор пользователя (автора)

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

Таблица № 3.5

Поле таблицы Тип данных Описание
QuestionID INTEGER Уникальный номер вопроса
QuestionType INTEGER Тип вопроса
QuestionText TEXTt Текст вопроса

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

Таблица № 3.6

Поле таблицы Тип данных Описание
AnswerID INTEGER Уникальный идентификатор ответа
AnswerText TEXT Текст ответа
QuestionID INTEGER Идентификатор вопроса, определяет к какому вопросу соответствует ответ

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

Таблица № 3.7

Поле таблицы Тип данных Описание
FormID INTEGER Уникальный идентификатор анкеты
QuestionID INTEGER Идентификатор вопроса

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

Таблица № 3.8

Поле таблицы Тип данных Описание
SurveyID INTEGER Уникальный идентификатор ответа
AnswerText TEXT Текст ответа
QuestionID INTEGER Идентификатор вопроса, определяет к какому вопросу соответствует ответ

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



Информация о работе «Автоматизированная система проведения маркетинговых исследований в Белгородском филиале МЭСИ»
Раздел: Информатика, программирование
Количество знаков с пробелами: 97537
Количество таблиц: 15
Количество изображений: 21

Похожие работы

Скачать
87374
8
17

... предприятия. Для дальнейшего развития Системы необходимо рассчитать экономическую эффективность проекта. Для этого необходимо выбрать направление распространения Системы. Заказчиком системы выступало закрытое акционерное общество "Белгородский бройлер". Произведем расчет экономической эффективности проекта с точки зрения заказного проекта. Структура экономической части при создании программного ...

Скачать
57100
0
6

... посильный вклад в изучение организации маркетинга в сфере образовательных услуг на примере Белгородского филиала Современного Гуманитарного Института. 1. Маркетинг образовательных услуг 1.1. Теория и практика маркетинга в сфере образовательных услуг Маркетинг образовательных услуг имеет свои особенности только в сфере практического применения, а все основные теоретические выкладки в нем ...

0 комментариев


Наверх