Концептуальная модель данных 


Мы поможем в написании ваших работ!



ЗНАЕТЕ ЛИ ВЫ?

Концептуальная модель данных



 

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

Основными объектами концептуальной модели являются сущности и связи.

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

¾ каждая сущность должна иметь уникальное имя, и к одному и тому же имени должна всегда применяться одна и та же интерпретация. Одна и та же интерпретация не может применяться к различным именам, если только они не являются псевдонимами;

¾ сущность обладает одним или несколькими атрибутами, которые либо принадлежат сущности, либо наследуются через связь;

¾ сущность обладает одним или несколькими атрибутами, которые однозначно идентифицируют каждый экземпляр сущности;

¾ каждая сущность может обладать любым количеством связей с другими сущностями модели.

Связь (Relationship) — ассоциация между двумя сущностями, значимая для рассматриваемой предметной области. Связи характеризуются двумя свойствами:

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

¾ мощность связи.

В соответствии со значением этого свойства связи между сущностями делятся на три вида:

¾ «один-к-одному», когда одному экземпляру первой сущности соответствует один экземпляр второй;

¾ «один-ко-многим», когда одному экземпляру первой сущности соответствует несколько экземпляров второй, а одному экземпляру второй – один экземпляр первой;

¾ «многие-ко-многим», когда одному экземпляру первой сущности соответствует несколько экземпляров второй, а одному экземпляру второй – несколько экземпляров первой.

Атрибутом является любая характеристика сущности, значимая для рассматриваемой предметной области и предназначенная для квалификации, идентификации, классификации, количественной характеристики или выражения состояния сущности. Экземпляр атрибута – это определенная характеристика отдельного элемента множества. Экземпляр атрибута определяется типом характеристики и ее значением, называемым значением атрибута. В ER-модели атрибуты ассоциируются с конкретными сущностями. Таким образом, экземпляр сущности должен обладать единственным определенным значением для ассоциированного атрибута.

То есть для построения модели сущность-связь необходимо произвести ряд действий:

¾ Формулирование сущностей;

¾ Назначение сущностям описательных атрибутов. Спецификация атрибутов заключается в указании для каждого атрибута множества значений, которые они могут принимать;

¾ Выбор идентифицирующего атрибута для каждой сущности. Правильный выбор ключа очень важен, так как он должен однозначно идентифицировать сущность и включать в свой состав минимальное количество атрибутов;

¾ Спецификация связей: с помощью связей выявляются зависимости между двумя и более сущностями.

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

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


Рис 2.3 Концептуальная модель информационной системы проведения интернет-аукционов


Логическая модель данных

Проектирование логической структуры БД предполагает:

¾ Выбор формы организации БД: централизованная или распределенная БД;

¾ Выбор архитектуры компьютерной сети: файловый сервер, сервер БД;

¾ Выбор СУБД и программных средств создания и ведения БД;

¾ переход от структуры данных логическое модели к структурам данных БД;

¾ Детализация структуры и свойств БД;

¾ Создание схемы данных.

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

Можно определить два подхода к созданию первичных ключей: естественный и суррогатный. У обоих подходов есть как преимущества, так и недостатки.

Естественный ключ представляет собой одно или несколько полей таблицы, которые относятся к предметной области и являются уникальными для данной сущности.

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

У естественных ключей можно выделить следующие преимущества:

¾ Первичный ключ несет смысловую нагрузку в таблице;

¾ Атрибуты внешних ключей также будут состоять из естественных значений, что во многих случаях приводит к упрощению SQL-запросов в операциях соединения;

¾ Отсутствует необходимость генерации уникального значения для каждой стоки таблицы.

¾ К достоинствам использования суррогатных ключей можно отнести:

¾ Уменьшение общего количества атрибутов в таблице;

¾ Более наглядное связывание таблиц в SQL-запросах по сравнению с естественными ключами;

¾ Отсутствует необходимость каскадного обновления внешних ключей, так как при любом изменении записи первичный ключ не меняется.

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

По способу установления связей между данными различают реляционную, иерархическую и сетевую модели. Для проектирования системы выбрана реляционная модель данных. Реляционная модель является простейшей и наиболее привычной формой представления данных в виде таблицы.[4]

В основе реляционной модели данных лежит понятие «отношения», которое используется для описания набора объектов. Отношение представляет собой таблицу, каждый столбец которой интерпретирует атрибуты объекта, а каждая строка (кортеж) описывает отдельный объект из набора.[4] Реляционная база данных – это набор отношений (R), которые имеют список имен атрибутов (схему отношения). При проектировании баз данных появляется множество альтернативных вариантов схемы отношения для каждого отношения, поэтому для выбора наиболее рационального варианта выполняется нормализация отношений.

Модель данных в реляционной базе данных может находиться в пяти нормальных формах (НФ). Каждая следующая нормальная форма обладает лучшими свойствами, чем предыдущая.

Первая НФ характеризуется тем, что значения всех атрибутов отношения атомарные.

Во второй НФ отношение находится, когда каждый не ключевой атрибут полностью зависит от составного ключа.

Отношение в третьей НФ не содержит транзитивных зависимостей не ключевых атрибутов от элементов составного ключа. Отношение находится в форме Бойса-Кодда, если отсутствуют зависимости элементов составного ключа от не ключевых атрибутов, которые в свою очередь находятся в полной функциональной зависимости от составного ключа. Четвертая НФ исключает наличие в отношении более одной многозначной зависимости. Способом перехода к НФ является декомпозиция исходного отношения на несколько новых.

Логическая структура базы данных проектируется на основе концептуальной и представлена на рис. 2.4.

В результате перехода к реляционной модели данных и ее нормализации были получены следующие отношения:

¾ «Users» – пользователи сайта;

¾ «Users_ attributes» – атрибуты пользователей;

¾ «Users_ attributes_contry» – страны;

¾ «Users_ attributes_city» – города;

¾ «Roles» – роли пользователя сайта;

¾ «User_Roles» – связь ролей и пользователей;

¾ «Pages» – страницы сайта;

¾ «User_Pages» – связь пользователей и страниц;

¾ «Lot_Bet» – ставки по лотам;

¾ «Basket» – корзина;

¾ «Template» – шаблоны страниц;

¾ «Snippets» – сниппеты на страницах;

¾ «Comment_User» – отзывы пользователей;

¾ «Category» – категории лотов;

¾ «Lots» – лоты;

¾ «Lot_attributes» – атрибуты лотов;

¾ «Lot_Statistics» – связь статистики и пользователей;

¾ «Statistics» – статистика завершившихся аукционов.

 

Рис.2.4 Логическая модель данных информационной системы

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

Для обеспечения уникальности записей в таблицы было добавлено поле, содержащее уникальный код каждого кортежа и однозначно определяющее всеполя, входящие в него. Таким образом, все отношения, полученные при декомпозиции, находятся в первой НФ и не содержат составных ключей, т.е. дальнейшая нормализация не требуется

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

Физическая модель данных – модель, определяющая размещение данных на внешних носителях, методы доступа и технику индексирования. Она также называется внутренней моделью системы. Внешние модели никак не связаны с типом физической памяти, в которой будут храниться данные, и с методами доступа к этим данным. Внутренние модели наоборот определяют и оперируют размещением данных и их взаимосвязей.

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

Таблица 2.1 – Таблицы разработанной базы данных

Название таблицы Описание таблицы
Users Содержит информацию о пользователях сайта
Roles Содержит информацию о ролях пользователей сайта
User_Roles Содержит информацию о принадлежности пользователя к какой-либо роли.
Pages Содержит информацию о страницах сайта
User_Pages Содержит информацию о том, кто из пользователей сайта является владельцем (создателем) страницы
User_attributes Содержит информацию о атрибутах пользователей
Template Содержит информацию о шаблонах страниц
Snippets Содержит информацию о подключаемых сниппетах
Lot_Bet Содержит информацию о ставках по лотам
Basket Содержит информацию о выбранных пользователем лотов
Comment_User Содержит информацию о отзывах о пользователях
Category Содержит информацию о категориях лотов
Lots Содержит информацию о лотах
Lot_attributes Содержит информацию о атрибутах лотов
Lot_Statistics Содержит информацию о принадлежности лотов статистике
Statistics Содержит статистическую информацию о завершенных аукционах
Users_ attributes_contry Содержит информацию о странах
Users_ attributes_city Содержит информацию о городах

 

Таблица 2.2 – Структура таблицы User

Название поля Тип данных Описание Ключе-вое поле Допустимость нулевого значения
User_ID int Идентификационный номер записи в таблице PK нет
Login varchar (100) Логин для авторизации на сайте   нет
Password varchar (100) Пароль для входа на сайт   нет

 

Таблица 2.3 – Структура таблицы User_attributes

Название поля Тип данных Описание Ключе-вое поле Допустимость нулевого значения
ID int Идентификационный номер записи в таблице PK нет
User_ID int Идентификационный номер пользователя FK нет
Full_name varchar (100) Полное имя пользователя   нет
E-mail varchar (100) E-mail пользователя   нет
Index int Почтовый индекс    
Fax int Факс    
Phone int Телефон    
City_ID int Идентификационный номер города FK нет
City_contry int Идентификационный номер страны FK нет
Sex binary Пол   нет

 

Таблица 2.4 – Структура таблицы Users_ attributes_contry

Название поля Тип данных Описание Ключе-вое поле Допустимость нулевого значения
ID int Идентификационный номер записи в таблице PK нет
Title varchar (100) Название страны   нет

Таблица 2.5 – Структура таблицы Users_ attributes_city

Название поля Тип данных Описание Ключе-вое поле Допустимость нулевого значения
ID int Идентификационный номер записи в таблице PK нет
Title varchar (100) Название города   нет

 

Таблица 2.6 – Структура таблицы Lot_Bet

Название поля Тип данных Описание Ключе-вое поле Допустимость нулевого значения
ID int Идентификационный номер записи в таблице PK нет
User_ID int Идентификационный номер пользователя FK нет
Lot_ID int Идентификационный номер лота   нет
Date datetime Время совершения ставки   нет
Price int Сумма ставки   нет

 

Таблица 2.7 – Структура таблицы Users_ Role

Название поля Тип данных Описание Ключе-вое поле Допустимость нулевого значения
ID int Идентификационный номер записи в таблице PK нет

Продолжение таблицы 2.7–таблицы Users_ Role

         
User_ID int Идентификационный номер пользователя FK нет
Role_ID int Идентификационный номер роли FK  

 

Таблица 2.8– Структура таблицы Role

Название поля Тип данных Описание Ключе-вое поле Допустимость нулевого значения
ID int Идентификационный номер записи в таблице PK нет
Title varchar (100) Название роли   нет
Right varchar (100) Права пользователя   нет

 

 

Таблица 2.9– Структура таблицы Page

Название поля Тип данных Описание Ключе-вое поле Допустимость нулевого значения
ID int Идентификационный номер записи в таблице PK нет
Parent_ID int Идентификационный номер родительского документа   нет
Menu_order int Порядок в меню   нет
Page_title varchar (200) Название страницы   нет
Page_header varchar (200) Заголовок страницы   нет
Content text Содержимое страницы    
Cache binary Кэшируемость документа   нет
Small_descr varchar (250) Краткое описание    
Meta_tags varchar (250) Метатеги    
Publish binary Опубликованный   нет
View_menu binary Видимость в меню   нет

 

Таблица 2.10– Структура таблицы User_Page

Название поля Тип данных Описание Ключе-вое поле Допустимость нулевого значения
ID int Идентификационный номер записи в таблице PK нет
Page_ID int Идентификационный номер страницы FK нет
User_ID int Идентификационный номер пользователя FK нет

 

Таблица 2.11– Структура таблицы Template

Название поля Тип данных Описание Ключе-вое поле Допустимость нулевого значения
ID int Идентификационный номер записи в таблице PK нет
Page_ID int Идентификационный номер страницы FK нет
Title varchar (200) Название шаблона   нет
Content text Содержимое шаблона    

 

Таблица 2.12– Структура таблицы Snippets

Название поля Тип данных Описание Ключе-вое поле Допустимость нулевого значения
ID int Идентификационный номер записи в таблице PK нет
Page_ID int Идентификационный номер страницы FK нет
Title varchar (200) Название сниппета   нет
Content text Содержимое сниппета    

 

 

Таблица 2.13– Структура таблицы Comment_user

Название поля Тип данных Описание Ключе-вое поле Допустимость нулевого значения
ID int Идентификационный номер записи в таблице PK нет
User_ID int Идентификационный номер пользователя FK нет
Aurhor_ID int Идентификационный номер автора   нет
Content text Содержимое отзыва   нет
Ball int Оценка пользователя   нет

 

Таблица 2.14– Структура таблицы Lots

Название поля Тип данных Описание Ключе-вое поле Допустимость нулевого значения
ID int Идентификационный номер записи в таблице PK нет
User_ID int Идентификационный номер пользователя FK нет
Content text Описание лота    
Title varchar (200) Название   нет
Small_descr varchar (250) Краткое описание    
Public binary Опубликованный   нет

 

Таблица 2.15– Структура таблицы Lot_attributes

Название поля Тип данных Описание Ключе-вое поле Допустимость нулевого значения
ID int Идентификационный номер записи в таблице PK нет
Lot_ID int Идентификационный номер лота FK нет
Status varchar (250) Состояние лота    
Price int Цена   нет
Min_price int Минимальная цена    
Data_start datetime Дата начала торгов   нет
Data_end datetime Дата окончания торгов   нет
Category_ID int Идентификационный номер категории FK нет
Contact text Контактные данные   нет
Location varchar (250) Местоположение    

 

 

Таблица 2.16– Структура таблицы Category

Название поля Тип данных Описание Ключе-вое поле Допустимость нулевого значения
ID int Идентификационный номер записи в таблице PK нет
Title varchar (200) Название   нет
Description text Описание   нет

 

Таблица 2.18– Структура таблицы Bascet

Название поля Тип данных Описание Ключе-вое поле Допустимость нулевого значения
ID int Идентификационный номер записи в таблице PK нет
User_ID int Идентификационный номер пользователя   нет
A_price int Текущая цена   нет
Lider_ID int Идентификационный номер лидера торгов    
Data datatime Дата окончание   нет

 

 

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


ТЕХНИЧЕСКОЕ ПРОЕКТИРОВАНИЕ

Выбор среды разработки

 

В качестве среды разработки информационной системы проведения интернет-аукционов была выбрана MODx CMF. В первую очередь несомненным достоинством MODx является ее молодость. При создании системы учитывались современные тенденции в создании сайтов и программировании. Многие конкурирующие системы разрабатывались достаточно давно, а с тех пор только модифицировались, но основные их принципы оставались неизменными. Раньше никто не задумывался о семантической верстке и поисковой оптимизации, и старые системы генерируют некачественный, по современным понятиям, код. В этом отношении MODx лучше соответствует требованиям сегодняшнего дня, и на ее основе легко создавать сайты в стиле WEB 2.0, с использованием AJAX, а также других современных технологий.

Пожалуй, самым главным преимуществом MODx является чрезвычайная гибкость системы. Программист, знакомый с языком PHP, сможет легко решать достаточно сложные задачи, используя имеющиеся функции API, то есть стандартные библиотеки, обеспечивающие доступ ко всем возможностям системы. Учитывая то, что система доступна в исходном коде, поле деятельности для программиста еще больше увеличивается.

Простои и понятный механизм, позволяющий использовать в качестве адресов страниц псевдонимы (ЧПУ), облегчает поисковое продвижение созданных сайтов. Также для поисковой оптимизации полезным оказывается качественная семантическая верстка, легко реализуемая в MODx. Вместе с тем для создания действительно качественных, с точки зрения поисковых систем, сайтов, от их разработчика потребуются специальные знания и серьезные усилия.

Немаловажным является то, что система поставляется совершенно бесплатно.



Поделиться:


Последнее изменение этой страницы: 2016-09-19; просмотров: 1388; Нарушение авторского права страницы; Мы поможем в написании вашей работы!

infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 3.134.87.95 (0.069 с.)