Электронный маркетинг

Вид материала

Реферат

Содержание Проектирование баз данных Рис. 7.57. Этапы проектирования баз данных База данных Интернет-магазина: пример проектирования Рис. 7.58. Форма заказа Интернет-магазина Концептуальное проектирование Раздел литературы, Название, Авторы, Цена Рис. 7.60 Связь «один-к-одному» Код заказа, Дата заказа, Покупатель, Телефон, Адрес электронной почты, Адрес доставки ISBN-код книги, Название, Авторы, Издательство, Год издания, Цена Код заказа, ISBN-код книги, Количество экземпляров в заказе Рис. 7.63. Пользовательское представление сотрудников отдела заказов Руководитель отдела доставки Рис. 7.64 Пользовательское представление сотрудников отдела маркетинга Рис. 7.66 Полная концептуальная модель базы данных Интернет-магазина Таблица 7.7 Словарь атрибутов концептуальной модели базы данных Интернет-магазина Код покупателя Код заказа Корзина заказа ISBN-код книги Код курьера ... Полное содержание

Подобный материал:

• Методические указания для преподавателей курса "Электронный маркетинг", 282.69kb.
• Программа курса Введение в электронный маркетинг, 182.23kb.
• Электронный учебно-методический комплекс «Педагогическая психология: интенсивный курс», 651.89kb.
• Темы рефератов для самостоятельной работы по курсу "Электронный маркетинг", 43.79kb.
• А. И. Герцена Экономический факультет Кафедра прикладной экономики Опорный конспект, 485.36kb.
• Финансово-экономический институт, 326.61kb.
• Темы докладов и рефератов Роль маркетинга в становлении социально-ориентированного, 27.86kb.
• Н. П. Кущ, О. М. Мамалига, 95.41kb.
• Электронный маркетинг, 771.4kb.
• Электронный маркетинг, 38.92kb.

Проектирование баз данных

1. Общие аспекты

Проектирование базы данных заключается в многоступенчатом описании будущей базы данных с различной степенью детализации и формализации, в ходе которого производится уточнение и оптимизация ее структуры. Проектирование начинается с описания предметной области и задач информационной системы, идет к более абстрактному уровню логического описания данных и далее – к схеме физической (внутренней) модели базы данных. Трем основным уровням моделирования системы – концептуальному, логическому и физическому – различают три последовательных этапа детализации описания объектов базы данных и их взаимосвязей. На рис. 7.11 представлены этапы проектирования базы данных.

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



Рис. 7.57. Этапы проектирования баз данных

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

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

• удобство и простота использования;
  
• качество средств разработки, защиты и контроля базы данных;
  
• уровень коммуникационных средств в случае применения ее в сетях;
  
• фирма-разработчик;
  
• стоимость.
  

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

На логическом уровне производится отображение данных концептуальной модели в логическую модель в рамках той структуры данных, которая поддерживается выбранной СУБД. Логическая модель не зависит от конкретной СУБД (в рамках определенной модели данных). Так, построенная на основе таблиц логическая модель может быть реализована на любой СУБД реляционного типа.

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

Рассмотрим эти основные этапы проектирования баз данных на примере базы данных Интернет-магазина.

2. База данных Интернет-магазина: пример проектирования

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

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

Рис. 7.58. Форма заказа Интернет-магазина

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

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

Пользователями баз данных являются и другие сотрудники компании, такие как руководитель компании, сотрудники бухгалтерии, менеджер по кадрам. Эта категория пользователей также должена получать информацию в определенной форме и степени структуризации в зависимости от цели: учета, анализа, планирования, управления кадрами. База данных заказов может быть основой для системы принятия решений и системы управления взаимоотношений с клиентами (CRM).

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

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

3. Концептуальное проектирование

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

На этапе концептуального проектирования создается неформальная модель, описывающая взаимоотношения между объектами предметной области. Для построения концептуальной модели в настоящее время широко применяется подход ER-модели, предложенной Ченом в 1976 г. Модель ER (Entity-Relationship – Сущность-Связь) основана на описании предметной области с помощью графических диаграмм, включающих небольшое число разнородных компонентов. ER-модель дает наглядное представление концептуальных схем баз данных.Основными понятиями ER-модели являются сущность, атрибут и связь.

Для сущности КНИГА атрибут ISBN-код книги является идентификатором отдельной книги (экземпляра сущности). Атрибуты Раздел литературы, Название, Авторы, Цена описывают свойства сущности.

Связи представляют отношения между сущностями. На рис. 7.13 приведен пример диаграммы связи сущностей ПОКУПАТЕЛЬ и КНИГА.



Рис. 7.59. Связи между сущностями

Базовыми типами связей сущностей являются: «один-к-одному», «один-ко-многим», «многие-ко-многим». При этом вместо стрелок на диаграмме можно указывать тип связи.

Связь «один-к-одному» (1:1) определяет такой тип связи между сущностями А и В, когда каждому экземпляру сущности А соответствует один и только один экземпляр сущности В и наоборот. Например, если покупатель в магазине оплачивает товары только с помощью одной кредитной карты, то связь между сущностями ПОКУПАТЕЛЬ и КРЕДИТНАЯ КАРТА является связью 1:1 (рис. 7.14).

Примечание

Сущность – это некоторая абстракция реального объекта, процесса или явления, информацию о котором необходимо хранить в системе. В нашей системе сущностями являются покупатели, заказы, книги. Атрибут сущности – это некоторая характеристика сущности, которая описывает одно из ее свойств. Атрибут имеет имя и принимает значение из некоторого множества значений. Например, у сущности КНИГА могут быть атрибуты: ISBN-код книги, Раздел литературы, Название, Авторы, Цена. Множество значений, разрешенных для данного атрибута, называется его доменом. Домен может насчитывать лишь несколько элементов или очень большое число элементов. Например, для сущности КНИГА домен атрибута Раздел литературы насчитывает около двадцати элементов, домен атрибута Название имеет очень большое число текстов возможных наименований, состоящих из не более чем 50-ти символов и т. д. Домен также указывает на тип возможных данных (число, текст, дата и др.) Для идентификации отдельных экземпляров сущностей должны существовать атрибуты или совокупность атрибутов, которые позволили бы отличать один экземпляр сущности от всех остальных. Такие атрибуты называются идентификаторами.

Рис. 7.60 Связь «один-к-одному»

Связи «один-к-одному» на практике встречаются редко. В нашем примере целесообразно включить код карты как атрибут сущности ПОКУПАТЕЛЬ и рассматривать одну эту сущность.

Связь «один-ко-многим» (1: М) определяет такой тип связи между сущностями А и В, когда одному экземпляру сущности А может соответствовать ноль, один или несколько экземпляров сущности В, однако каждому экземпляру сущности В соответствует только один экземпляр сущности А.

Пример связи «один-ко-многим» – связь между сущностями ПОКУПАТЕЛЬ и ЗАКАЗ. ПОКУПАТЕЛЬ может размещать несколько заказов, но каждый заказ обязательно имеет ПОКУПАТЕЛЯ и только одного (рис. 7.15).



Рис. 7.61. Связь «один-ко-многим»

Связи «один-ко-многим» наиболее широко распространены.

Связи «многие-ко-многим» также широко распространены. К такому типу относится связь между сущностями ЗАКАЗ и КНИГА. В одном заказе может фигурировать несколько различных книг, в то же время каждая книга может встречаться во многих заказах (рис. 7.16).



Рис. 7.62. Связи «многие-ко-многим»

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

Для сотрудников отдела заказов есть две сущности: ЗАКАЗ и КНИГА. Как мы отметили, связь ЗАКАЗ – КНИГА является связью «многие-ко-многим». При анализе связи «многие-ко-многим» часто возникает необходимость ввода новых сущностей. В нашем примере непонятно, где хранить такую характеристику как Количество заказанных экземпляров. Это количество определяется книгой, которых может быть в заказе несколько, и не может быть атрибутом сущности ЗАКАЗ. В то же время количество заказанного товара не может быть и атрибутом сущности КНИГА, так как определяется заказом. Выходом из положения является ввод сущности КОРЗИНА ЗАКАЗА, которая связывает заказ с заказанными книгами.

Сущность ЗАКАЗ имеет атрибуты: Код заказа, Дата заказа, Покупатель, Телефон, Адрес электронной почты, Адрес доставки. Код заказа является идентифицирующим отдельный экземпляр сущности (то есть конкретный заказ) атрибутом.

Сущность КНИГА имеет атрибуты: ISBN-код книги, Название, Авторы, Издательство, Год издания, Цена. ISBN-код является международным стандартным номером книг, который присваивается каждой книге. Таким образом, он является естественным идентифицирующим атрибутом.

Сущность КОРЗИНА ЗАКАЗА имеет атрибуты: Код заказа, ISBN-код книги, Количество экземпляров в заказе. Определяющим экземпляр сущности признаком является совокупность полей Код заказа и ISBN-код книги.

Связь «многие-ко-многим» между сущностями ЗАКАЗ и КНИГА реализуется в такой схеме через сущность КОРЗИНА ЗАКАЗА (рис. 7.17). На рисунке помимо названий сущностей указаны ключевые атрибуты.



Рис. 7.63. Пользовательское представление сотрудников отдела заказов

С точки зрения сотрудников маркетинговой службы важным является анализ потребительского спроса, определение потребностей и предпочтений покупателей. Поэтому в представлении маркетолога ПОКУПАТЕЛЬ рассматривается как отдельная сущность, ее следует выделить из сущности ЗАКАЗ, оставив в заказе некоторый идентифицирующий покупателя атрибут, например, код покупателя. Атрибутами сущности ПОКУПАТЕЛЬ являются Код покупателя, Организация, Фамилия, Имя, Отчество, Телефон, Адрес электронной почты, Почтовый адрес. Атрибут Организация определяет, осуществляет ли заказ организация или частное лицо. Это атрибут-признак. Сущность ПОКУПАТЕЛЬ позволяет исследовать сегмент потребителей, выявлять постоянных клиентов и рационально организовать обратную связь с потребителем. Связь между сущностями ПОКУПАТЕЛЬ и ЗАКАЗ представлена на рис. 7.18.

Для выявления спроса на отдельную продукцию и группы продукции, а также для предоставления покупателям возможности поиска книги по разделу, важно ввести в описание сущности КНИГА атрибут Раздел литературы. В этом случае можно реализовать такие запросы, как получение информации об объемах и поступлениях от продаж книг различных разделов.

Сотрудники отдела доставки оперируют только с сущностью ЗАКАЗ. Для них важно обеспечить своевременное выполнение заказа и управление работой курьеров. Поэтому сущность ЗАКАЗ дополняется такими атрибутами как Дата доставки, Дата исполнения, Тип доставки, Цена доставки, Курьер. Курьеру бывают нужны дополнительные сведения: ближайшие станции метро, № маршрутов городского транспорта, как пройти/проехать, желательные часы доставки и т. п. Поэтому целесообразно включить также атрибут Примечание, в котором могут содержаться такие сведения.

Руководитель отдела доставки хотел бы иметь более полные личные данные по курьерам. Его представление состоит из двух сущностей: ЗАКАЗ и КУРЬЕР. Сущность ЗАКАЗ имеет атрибуты: Код заказа, Дата доставки, Дата исполнения, Тип доставки, Код курьера. Сущность КУРЬЕР определяется атрибутами Код курьера, Фамилия, Имя, Отчество, Дата рождения, Дата приема на работу, Рабочая смена. Сущности КУРЬЕР и ЗАКАЗ связаны соотношением один-ко-многим (рис. 7.20).



Рис. 7.64 Пользовательское представление сотрудников отдела маркетинга



Рис. 7.65 Пользовательское представление сотрудников отдела доставки

С точки зрения сотрудника бухгалтерии важным является, как именно будет произведена оплата: наличными курьеру, кредитной картой, через определенную платежную систему Интернет. Поэтому сущность ЗАКАЗ дополняется атрибутом Форма оплаты.

Полная концептуальная модель базы данных представляется теперь в виде пяти сущностей, связанных между собой связями «один-ко-многим» (рис. 7.20).

Рис. 7.66 Полная концептуальная модель базы данных Интернет-магазина

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

Таблица 7.7 Словарь атрибутов концептуальной модели базы данных Интернет-магазина
Атрибут	Домен
ПОКУПАТЕЛЬ
Код покупателя	Целое число, уникальный номер
Организация	Да/Нет
Фамилия	Текст, не более 30 символов, содержащий фамилии
Имя	Текст, не более 20 символов, содержащий имена
Отчество	Текст, не более 20 символов, содержащий отчества
Телефон	Текст, не более 15 символов, содержащий 10-ти значный номер
Адрес электронной почты	Текст, не более 30 символов, содержащий символ @
Почтовый адрес	Текст, не более 255 символов
ЗАКАЗ
Код заказа	Целое число, уникальный номер
Код покупателя	Целое число
Форма оплаты	Одно из: наличными курьеру; кредитной картой; платежную систему CyberPlat ; платежную систему WebMoney; платежную систему КредитПилот. Список может расширяться
Дата заказа	Дата
Дата доставки	Дата
Дата исполнения	Дата
Тип доставки	Одно из: курьером по Москве; курьером по Московской области; курьером по Санкт-Петербургу; почтой наложенным платежом; почтой по предоплате. Список может расширяться
Цена доставки	Вещественное число, денежный формат, определяется видом доставки
Код курьера	Целое число
Адрес доставки	Текст, не более 255 символов
Примечание	Текст, не более 255 символов
КОРЗИНА ЗАКАЗА
Код заказа	Целое число
ISBN-код книги	Текст, не более 25 символов
Количество экземпляров в заказе	Целое число, не более 1000
КНИГА
ISBN-код книги	Текст, не более 25 символов
Раздел литературы	Текст, не более 50 символов
Название	Текст, не более 255 символов
Авторы	Текст, не более 255 символов
Издательство	Текст, не более 50 символов
Год издания	Целое число от 2000 до 2100
Цена	Вещественное число, денежный формат
КУРЬЕР
Код курьера	Целое число
Фамилия	Текст, не более 30 символов
Имя	Текст, не более 20 символов
Отчество	Текст, не более 20 символов
Дата рождения	Дата
Дата приема на работу	Дата
Рабочая смена	Одно из: первая, вторая, обе

4. Логическое проектирование

Если на этапе концептуального проектирования объектом исследования является предметная область, то на этапе логического проектирования в качестве объекта исследования выступают уже сами данные, их структура и правила построения.

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

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

Иерархическая и сетевая модели данных

Первой СУБД, построенной на базе иерархической модели стала система IMS, выпущенная компанией IBM в 1968 г. В этой системе начали утверждаться принципы управления базами данных.

Иерархическая модель построена в виде древовидной структуры с корневым сегментом, имеющим указатели на другие сегменты (рис. 7.21). При поиске данных дерево всегда просматривается сверху вниз.

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

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

Рис. 7.67. Иерархическая модель

В экономических информационных системах информация, как правило, организована в многосвязные структуры и редко укладывается в иерархическую схему.

Почти одновременно с иерархической моделью была сформирована сетевая модель данных. Сетевой подход является расширением иерархического. В сетевой модели происходит объединение нескольких различных иерархий. В примере на рис. 7.22 объединены две иерархии: Заказ и Покупатель.

Рис. 7.68. Сетевая модель

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

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

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

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

Реляционная модель данных

Реляционная модель данных для систем управления базами данных была разработана сотрудником исследовательской лаборатории компании IBM Э. Ф. Коддом. Э. Ф. Кодд, будучи математиком, разработал теорию реляционных баз данных, свободную от недостатков прежних моделей. В 1970 г. он опубликовал статью, посвященную краткому описанию новой модели.

В отличие от предшествующих моделей реляционная модель имеет строгое математическое обоснование в виде теории множеств (реляционная алгебра) и исчислении предикатов (реляционное исчисление).

Основой реляционной модели является отношение (relation). Отношение содержит информацию об одной сущности (об одном классе объектов предметной области) и представляет собой множество элементов, называемых кортежами.

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

В Табл.7.2 показан пример отношения ПОКУПАТЕЛЬ, содержащий несколько кортежей (строк, описывающих покупателей). Отметим, что здесь указаны не все атрибуты для сущности ПОКУПАТЕЛЬ из нашего примера.

Таблица 7.8. Пример отношения ПОКУПАТЕЛЬ
Код покупателя	Фамилия	Телефон	Адрес электронной почты	Почтовый адрес
4551	Петрова	125-15-97	lpetr@newmail.ru	Москва, ул. Зеленая, 2-4
4552	Краснов	447-85-96	igor@home.com	Мытищи, ул. Новая, 11-5

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

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

Хотя отношения и представляются в форме таблиц, далеко не любая таблица может быть отношением. Основными правилами формирования отношений являются следующие:

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

Рассмотрим подробнее фундаментальные свойства отношений, построенных на этих правилах.

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

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

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

Первичные ключи используются в следующих целях:

• идентификации строк в таблице;
  
• ускорения работы со строками таблицы;
  
• связывания таблиц.
  

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

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

Отсутствие многозначных атрибутов. Если атрибут имеет несколько значений в одной строке, то такие значения называются повторяющимися группами. Например, покупатель может указать несколько телефонов для связи. Наличие нескольких телефонов в одной строке для столбца Телефон недопустимо. В этом случае надо создавать новое отношение ТЕЛЕФОН ПОКУПАТЕЛЯ с атрибутами Код покупателя, Телефон.

Связи. Связи между сущностями представляются в реляционной модели связями между таблицами по значениям ключевых атрибутов. В Табл. 7.3. показана связь «один-ко-многим» между таблицами ПОКУПАТЕЛЬ и ЗАКАЗ по столбцу Код покупателя. Первичные ключи таблиц здесь выделены жирным шрифтом. Каждой строке таблицы ПОКУПАТЕЛЬ должны соответствовать одна или несколько строк таблицы ЗАКАЗ с тем же значением атрибута Код покупателя. Во взаимоотношении этих таблиц первую таблицу можно назвать главной, а вторую – подчиненной. Атрибут подчиненной таблицы, по которому осуществляется связь, называется внешним ключом главной таблицы.

Таблица 7.9. Связь таблиц ПОКУПАТЕЛЬ – ЗАКАЗ
ПОКУПАТЕЛЬ					ЗАКАЗ
1					m
Код покупателя	Фамилия	Телефон		Код заказа	Код покупателя	Дата доставки
4551	Петрова	125-15-97		0991	4552	08/06/2001
4552	Краснов	447-85-96		0992	5875	09/06/2001
…				…
5875	Иванова	345-67-89		1858	4552	21/07/2001

В данном случае внешним ключом таблицы ПОКУПАТЕЛЬ во взаимосвязи ПОКУПАТЕЛЬ  ЗАКАЗ является атрибут Код покупателя таблицы ЗАКАЗ.

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

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

Требования целостности. Любая реляционная СУБД должна обеспечивать два базовых требования целостности реляционной модели данных: целостность сущностей и целостность по ссылкам.

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

Требование целостности по ссылкам означает, что для связанных отношений каждому значению внешнего ключа должна найтись запись в главной таблице с таким же значением первичного ключа. В нашем примере каждому значению кода покупателя в таблице ЗАКАЗ должна соответствовать строка с данным кодом покупателя в таблице ПОКУПАТЕЛЬ. Требование целостности по ссылкам также называют требованием внешнего ключа.

Целостность по ссылкам должна поддерживаться СУБД при выполнении операций модификации первичного ключа и удаления кортежа.

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

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

Выбор варианта зависит от требований предметной области и существующих бизнес-правил. Так, при отмене заказа очевидно следует произвести удаление записи об этом заказе из таблицы ЗАКАЗЫ и всех соответствующих записей из таблицы КОРЗИНА ЗАКАЗА, то есть применить каскадное удаление. Для связи между таблицами ПОКУПАТЕЛЬ и ЗАКАЗ (по коду покупателя) нельзя удалять запись о покупателе, который оформил хотя бы один заказ.

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

Структурной частью реляционной модели данных является нормализованное отношение.

Достоинства реляционной модели

• Одним из важных достоинств реляционного подхода является его простота и доступность для понимания конечным пользователем. Единственной информационной конструкцией является таблица.
  
• При проектировании реляционных баз данных применяются строгие правила, базирующиеся на математическом аппарате.
  
• Реляционная модель обеспечивает полную независимость данных. При изменении структуры реляционной базы данных изменения, которые требуется произвести в прикладных программах, как правило, минимальны.
  
• Манипулирование данными на уровне языка СУБД производится ненавигационно, поэтому для построения запросов и написания прикладных программ нет необходимости знания конкретной организации базы данных во внешней памяти. Конечно, при исполнении запросов на физическом уровне выполняется навигация по записям таблиц, однако эти действия производятся процедурами самой СУБД.
  

Недостатки реляционной модели

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

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

5. Проект реляционной базы данных Интернет-магазина

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

• свести к минимуму избыточность хранения информации;
  
• обеспечить целостность базы данных при выполнении операций модификации данных;
  
• минимизировать возможные изменения в наборе отношений при добавлении новых атрибутов.
  

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

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

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

Применим этот подход к построению логической модели базы данных Интернет-магазина.

Концептуальная модель (рис. 7.20 и табл.7.1) дает пять сущностей, из которых три – КНИГА, ПОКУПАТЕЛЬ и КУРЬЕР – выступают во взаимоотношениях только как «один-ко-многим». Первичные ключи для них уже определены: это ISBN-код книги, Код покупателя и Код курьера соответственно.

Сущность ЗАКАЗ выступает во взаимоотношении «многие-к-одному» с сущностями ПОКУПАТЕЛЬ и КУРЬЕР и во взаимоотношении один-ко-многим с сущностью КОРЗИНА ЗАКАЗА. Атрибуты Код покупателя и Код курьера сущности ЗАКАЗ являются первичными ключами сущностей ПОКУПАТЕЛЬ и КУРЬЕР и поэтому являются внешними ключами отношения ЗАКАЗ.

Первичным ключом отношения ЗАКАЗ является Код заказа.

Сущность КОРЗИНА ЗАКАЗА выступает во взаимоотношении «многие-к-одному» с сущностями ЗАКАЗ и КНИГА. Атрибуты Код заказа и ISBN-код книги сущности КОРЗИНА ЗАКАЗА являются первичными ключами сущностей ЗАКАЗ и КНИГА и поэтому являются внешними ключами отношения КОРЗИНА ЗАКАЗА.

Первичным ключом отношения КОРЗИНА ЗАКАЗА является совокупность атрибутов Код заказа, ISBN-код книги.

Логическая схема совокупности полученных отношений представлена на рис.7.23. Здесь жирным шрифтом выделены первичные ключи, а курсивом – внешние ключи.

Рис. 7.69 Логическая схема отношений

Теперь нужно проверить соответствие отношений третьей нормальной форме. Для нее должны быть выполнены следующие условия:

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

Многозначность атрибутов снята на этапе концептуального проектирования. Так, мы предположили, что для каждого покупателя будет записан только один телефон, а не несколько. Если желательно вводить несколько телефонов, то нужно создавать новое отношение ТЕЛЕФОН и связывать его с отношением ПОКУПАТЕЛЬ. То же относится и к авторам книг. Все авторы книги будут вводиться одной строкой, и, следовательно, анализ продаж книг по отдельным авторам будет затруднителен. Если же такой анализ необходим, следует включить в базу данных дополнительное отношение АВТОРЫ. Для простоты картины мы этого делать не будем.

Неполная зависимость атрибутов. На этапе концептуального проектирования мы также устранили неполную зависимость атрибутов от первичного ключа для сущности ЗАКАЗ. Если в описание заказа включить заказанные книги, то первичным ключом будет совокупность атрибутов Код заказа, ISBN-кода книги. Тогда такие атрибуты как Дата заказа, Покупатель зависят только от кода заказа, а атрибут Количество экземпляров книги в заказе определяется и заказом и ISBN-кодом книги, то есть является атрибутом новой сущности КОРЗИНА ЗАКАЗА (см.рис. 7.18).

Зависимость от неключевых атрибутов. Рассмотрим отношение ЗАКАЗ из нашего примера. В нем присутствуют неключевые атрибуты Тип доставки и Цена доставки, причем цена доставки определяется типом доставки. Здесь мы имеем избыточность данных, так как цена доставки хранится для каждого заказа, хотя достаточно было ввести ее один раз при описании доставки данного типа. Кроме того, имеется так называемая аномалия модификации: при изменении в записи заказа значения атрибута Тип доставки всякий раз нужно изменять значение цены доставки.

Для устранения этих аномалий нужно устранить функциональную зависимость между неключевыми атрибутами. В результате исходное отношение разбивается на два, представленные в табл. 7.4, - ЗАКАЗ и ЦЕНА ДОСТАВКИ. Здесь для отношения ЗАКАЗ приведены не все неключевые атрибуты. Дублирование данных по ценам доставки и аномалия корректировки вида доставки здесь устранены. Цены для каждого вида доставки вводятся и корректируются независимо от конкретного заказа.

Таблица 7.10 Результат приведения отношения ЗАКАЗ к третьей нормальной форме
ЗАКАЗ						ЦЕНА ДОСТАВКИ
Код заказа	Код покупа-теля	Дата доставки	Тип доставки	Адрес доставки	Код курьера		Тип доставки	Цена доставки
0991	02345	08/06/2001	Курьером по Москве	ул. Зеленая, 2-4	004		Курьером по Москве	35
0992	01784	08/06/2001	Курьером по Москве	ул. Новая, 11-5	001		Курьером по области	45
0993	00589	09/06/2001	Курьером по области	Зеленоград, ул. Новаторов, 3	006		Курьером по С.-Пб.	30
0994	00045	09/06/2001	Курьером по С.-Пб.	Московский пр-т 12-125	012
0995	01258	09/06/2001	Курьером по Москве	Пл. Ильича,15-68	004

Таким образом, мы получили реляционную логическую модель базы данных Интернет-магазина из семи отношений, приведенных к третьей нормальной форме:

ПОКУПАТЕЛЬ (Код покупателя, Организация, Фамилия, Имя, Отчество, Адрес электронной почты, Почтовый адрес)

ПОКУПАТЕЛЬТЕЛЕФОН (Код покупателя, Телефон)

КНИГА ( ISBN-код книги, Раздел литературы, Название, Авторы, Издательство, Год издания, Цена)

ЗАКАЗ (Код заказа, Код покупателя, Форма оплаты, Дата заказа, Дата доставки, Дата исполнения, Тип доставки, Код курьера, Адрес доставки, Примечание)

ЦЕНА ДОСТАВКИ (Тип доставки, Цена доставки)

КОРЗИНА ЗАКАЗА (Код заказа, ISBN-код книги, Количество экземпляров в заказе)

КУРЬЕР (Код курьера, Фамилия, Имя, Отчество, Дата рождения, Дата приема на работу, Рабочая смена)

Здесь ключевые атрибуты выделены жирным шрифтом, а внешние ключи – курсивом.

Связи между отношениями и соответствующие первичные и внешние ключи представлены на рис. 7.24.

Рис. 7.70. Логическая модель базы данных Интернет-магазина

6. Физическое проектирование

Главными вопросами физического проектирования являются оптимизация времени выполнения основных запросов к базе данных и обеспечение безопасности данных.

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

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

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

Словарь данных

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

В словаре данных обычно отражены следующие сведения:

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

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

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

Индексирование

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

Для повышения производительности реляционные СУБД используют специальные объекты, называемые индексами. Индекс содержит набор записей из двух элементов: {значение ключевого поля; указатель на соответствующую запись в таблице}. Индекс упорядочен по значению ключевого поля, что позволяет быстро находить нужные значения. Для оптимизации поиска в индексах используются специальные алгоритмы. Упорядоченный индекс можно просматривать во много раз быстрее, чем саму неупорядоченную таблицу. Фактически индексная структура является «оглавлением» таблицы. В таблице 7.5. приведен индекс к таблице КНИГА и записи самой таблицы.

Таблица 7.11 Схема индексирования
Индекс		Таблица КНИГА
ISBN-код		ISBN-код	Автор	Наименование
5-272-00046-3		966-03-1257-1	Глушаков С.В.	Базы данных. Учебный курс
5-279-02346-9		5-272-00046-3	Мелихова Л.	Энциклопедия Интернет
…			…
966-03-1257-1		5-279-02346-9	Попов В. М.	Бизнес-план инвестиционного проекта

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

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

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

Если в информационной системе предполагается часто выполнять поиск по полям, не входящим в первичный ключ, можно задать дополнительные индексы для этих полей. Например, для таблицы КНИГА можно провести индексирование записей по полю Раздел литературы. В этом случае ускоряется выполнение всех запросов, связанных с поиском книг определенного раздела.

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

В нашем примере для таблицы ЗАКАЗ СУБД автоматически создаст индекс для первичного ключа Код заказа. Также целесообразно создать индексы для внешних ключей Код покупателя, Тип доставки, Код курьера. Если известно, что будет часто проводиться поиск заказов по дате, то целесообразно построить дополнительный индекс по полю Дата заказа.

Разделение таблиц

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

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

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

В этом случае целесообразно создать новые связанные между собой таблицы АРХИВ ЗАКАЗОВ и АРХИВ КОРЗИН ЗАКАЗОВ, в которые нужно переписать все записи о заказах, произведенных месяц назад или ранее, кроме записей о невыполненных заказах. Основная работа будет вестись с таблицами ЗАКАЗ и КОРЗИНА ЗАКАЗА, содержащими относительно небольшой объем записей. Операцию перезаписи в архивные таблицы надо будет проводить ежемесячно.

При проведении горизонтального разделения таблицы следует изменить запросы, относящиеся ко всем записям. Теперь они должны включать операцию объединения двух таблиц. Например, при установлении количества заказов, доставленных по Москве за последний год, поиск должен проводиться по временно создаваемой таблице, полученной в результате объединения таблиц ЗАКАЗ и АРХИВ ЗАКАЗОВ. Такие запросы будут выполняться значительно медленнее, чем поиск в каждой таблице в отдельности. Разделение таблиц оправдано, если запросы к записям архивных таблиц будут выполняться значительно реже, чем к записям основных таблиц.

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

Например, таблицу, содержащую информацию о сотрудниках:

СОТРУДНИК (Табельный номер, Фамилия, Имя, Отчество, Должность, Отдел, Дата рождения, Дата приема на работу, Образование, Специальность, Семейное положение, Количество детей)

можно разделить на две:

СОТРУДНИК (Табельный номер, Фамилия, Имя, Отчество, Должность, Отдел);

СОТРУДНИК-АНКЕТА (Табельный номер, Дата рождения, Дата приема на работу, Образование, Специальность, Семейное положение, Количество детей).

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

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

Условия на значения полей и значения по умолчанию

На этапе концептуального проектирования было введено понятие домена как множество разрешенных значений атрибута. При создании физической модели базы данных домен находит свое выражение в виде задания каждому полю таблицы определенного типа данных. Кроме того, большинство СУБД позволяет накладывать ограничения на значения данных в виде некоторого условия, что позволяет снизить ошибки ввода. При вводе данных производится автоматическая проверка их соответствия указанным типам и проверка выполнения заданных условий. Например, при описании поля Дата рождения ему присваивается тип Дата и задается интервал возможных значений, например: >01/01/1920 и < 01/01/2000.

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