Глава 7. Технологии хранения и обработки данных
Глава 7. Технологии хранения и обработки данных
Появление сети Интернет и развитие информационных систем привели к значительному увеличению объемов информации. В большинстве случаев информация плохо структурирована, не согласована и не привязана к определенному временному срезу, что влияет качество управления компанией и не позволяет принять взвешенные бизнес-решения. Для маркетинговой деятельности, которая основана на обработке мощных информационных потоков, поступающих как из внешней среды, так из многочисленных подразделений компаний, решение задач получения достоверной и адекватной информации особенно актуальны. Анализ накопленных информационных ресурсов, быстрота получения новых видов отчетности, возможность рассмотрения текущих и исторических данных - это основа эффективной работы современных маркетинговых служб.
Рис. 7.5. Структура информационной системы
Данные в информационных системах описывают определенную предметную область. Предметная область[49] – это область применения конкретной информационной системы: определенная отрасль знаний, предприятие или система предприятий определенной отрасли экономики, отдельные направления деятельности предприятий: производство, снабжение, обслуживание заказов.
База данных представляет собой совокупность взаимосвязанных и специальным образом организованных данных, хранимых во внешней памяти компьютера, которые отображают текущее состояние объектов и процессов в рассматриваемой предметной области.
Централизованное управление данными осуществляется системой управления базой данных(СУБД). Система управления базами данных – это общесистемное программное средство, предназначенное для создания, поддержания и использования базы данных. СУБД преобразует сформированные пользователями или прикладными программами запросы на получение или модификацию данных в команды обращения к базе данных.
СУБД обеспечивает надежное хранение больших объемов данных сложной структуры во внешней памяти компьютера и эффективный доступ к ним. Появление СУБД сняло с разработчиков информационных систем необходимость создавать каждый раз весьма сложные компоненты управления данными. К основным функциям СУБД относятся:
· Непосредственное управление данными во внешней и оперативной памяти и обеспечение эффективного доступа к данным в процессе решения задач.
· Поддержание целостности данных и управление транзакциями.
· Ведение системного журнала изменений в базе данных, что обеспечивает восстановление базы данных после технического или программного сбоя.
· Реализация поддержки языка описания данных и языка запросов к данным.
· Обеспечение безопасности данных.
· Обеспечение параллельного доступа к данным нескольких пользователей.
Архитектура баз данных
Реальные объекты и их взаимосвязи представлены в базе данных в виде некоторой целевой модели[50] предметной области, которая отражает только те факты о предметной области, которые необходимы для функционирования информационной системы.
При построении модели проводится последовательное абстрагирование и структурирование данных.
Сначала разрабатывается концептуальная модель базы данных, в которой на естественном языке с помощью диаграмм и других средств описываются объекты предметной области и их взаимосвязи. В концептуальной модели выделяется и описывается информация, которая должна быть представлена в базе данных. Концептуальная модель не зависит от конкретной используемой СУБД и служит основой для построения логической модели базы данных.
Модель данных, в которой на логическом уровне полностью описывается информационное содержание базы данных, называется логической моделью базы данных. Логическая модель является основой для всех пользователей информационной системы (прикладных программ и людей). Пользователи и прикладные программы обращаются к базе данных посредством СУБД только в терминах логической модели.
Логическая модель описывает всю базу данных как единое целое. Однако, как мы уже отмечали, у каждой группы пользователей базы данных есть свои специфические задачи, для решения которых нет необходимости знакомиться с глобальной моделью базы данных информационной системы. Кроме того, необходимое пользователю логическое представление данных может существенно отличаться от общей модели данных. Часто требуется также разделить группы пользователей по их правам доступа к определенным частям базы данных.
Отдельное логическое представление данных для каждого пользователя называется внешней моделью данных или пользовательским представлением.
Так, сотрудник, оформляющий заказы, работает с представлением, в котором основой является заказ и пункты заказа. Сотрудник, занимающийся работой с клиентами, должен иметь полную информацию о клиентах и их заказах. Его может интересовать, например, с какой частотой осуществляет заказы тот или иной клиент, его предпочтения и т. д. Руководитель отдела маркетинга должен работать с представлением, в котором в виде сводок представлена вся маркетинговая деятельность компании (товары, поставщики, клиенты, заказы, продажи) и имеется возможность проводить анализ этой деятельности.
Отметим, что логическая модель базы данных отражает ее информационное содержание и не содержит детали организации физического хранения данных во внешней памяти. Преобразование данных из физической базы данных в представления логической модели (и обратно) осуществляет система управления базами данных.
Однако СУБД тоже непосредственно не работает с данными, хранящимися на дисках. Как и все программы, она функционирует под управлением конкретной операционной системы (ОС), которая и осуществляет управление данными на физическом уровне ( в виде файлов и записей на дисках). СУБД оперирует с так называемой внутренней (физической) моделью данных, которая отображается в физическую базу данных средствами ОС.
Таким образом, мы приходим к трехуровневой архитектуре базы данных, представленной на рис. 7.6.
Рис. 7.6.Трехуровневая архитектура базы данных
На верхнем уровне располагаются внешние модели данных или пользовательские представления, они строятся с помощью СУБД на основе единой логической модели базы данных. Сама СУБД оперирует с некоторой внутренней моделью, содержащей описание форматов данных и дополнительных структур, необходимых для эффективного управления и доступа к данным.
Рис. 7.7. Жизненный цикл базы данных
В процессе создания информационной системы подготавливаются рабочие документы, которые служат основой для всех разработчиков и пользователей системы.
Рассмотриm этапы создания базы данных как важнейшей ее части информационной системы.
Проектирование
Этап проектирования является самым важным этапом в разработке информационной системы и ее базы данных, так как ошибки, допущенные на этом этапе, в дальнейшем бывает очень сложно или невозможно устранить. Без хорошо организованного проекта базы данных построенная на ее основе информационная система не сможет избежать различных трудностей, связанных с некорректностью и несогласованностью информации. Основные виды работ и выходные документы данного этапа представлены на рис. 7.8.
Рис. 7.8. Этап проектирования БД
Реализация
На этапе реализации производится создание базы данных и разработка программ (приложений) в выбранной СУБД. Описание базы данных, инструкции по ее эксплуатации сводятся в рабочий проект базы данных (рис. 7.9).
Рис. 7.9 Реализация БД
Эксплуатация и модификация
Эксплуатация начинается с заполнения базы данных реальными данными. На этапе эксплуатации необходимо выполнять ряд действий, поддерживающих базу данных в рабочем состоянии: проводить контроль непротиворечивости, резервное копирование, архивирование и т. д. Совокупность таких действий называется сопровождением базы данных.
По мере использования базы данных происходит выявление недоработок, уточнение и, возможно, изменение требований к базе данных: в результате может быть принято решение о ее модификации: разрабатывается новый проект и производится доработка системы. Вообще говоря, этапы эксплуатации и модификации могут сменять друг друга до тех пор, пока не будет принято решение о разработке принципиально новой системы. В этом случае старый проект либо включается в новый, либо используется только содержимое базы данных.
Участники разработки и сопровождения
Как на этапе проектирования, так и на других этапах жизненного цикла информационной системы на предприятии должны существовать две группы сотрудников: группа заказчика и группа разработчиков (рис.7.10).
Рис. 7.10 Участники разработки
Проект по созданию базы данных инициируется руководством компании. Для маркетинговой базы данных это должен быть руководитель отдела маркетинга. Именно он определяет цели и задачи, которые должна решать разрабатываемая система. В постановке задачи участвуют также сотрудники маркетинговой и других служб, являющиеся будущими пользователями системы. В дальнейшем при проектировании базы данных именно они предоставляют разработчику все сведения о бизнес-процессах и характеристики моделируемых объектов. Для разработчиков заказчик является основным носителем сведений о предметной области и о требованиях, предъявляемых к информационной системе.
Важно подчеркнуть, что успех разработки во многом определяется усилиями заказчика по четкому формулированию целей, описанию реалий бизнеса и определению уровня детализации информации. Например, если при создании базы данных Интернет-магазина не была сформулирована такая цель, как организация взаимоотношений с покупателем, ПОКУПАТЕЛЬ как моделируемый объект не будет выделен из объекта ЗАКАЗ, и в дальнейшем базу данных придется достраивать сведениями о покупателях, их покупках и предпочтениях.
На этапе эксплуатации группа заказчика выявляет степень соответствия системы поставленным целям и при необходимости определяет направления ее модификации.
Группу разработчика представляют, в основном, специалисты в области информационных систем, однако в ней обязательно должен быть консультант-экономист, знающий предметную область. Главным лицом является администратор базы данных. Администратор базы данных руководит всеми работами по проектированию и программной реализации базы данных. На стадии эксплуатации он отвечает за функционирование информационной системы и управляет режимом использования данных.
Основные задачи администратора БД при эксплуатации системы это:
· Разработка и реализация мер по обеспечению защиты данных и разграничению доступа к данным.
· Контроль за непротиворечивостью и достоверностью данных.
· Анализ эффективности использования ресурсов информационных систем.
· Координация работы системных программистов по улучшению эксплуатационных характеристик системы.
· Координация работы прикладных программистов, разрабатывающих новые приложения для работы с базой данных.
В зависимости от масштабов предприятия и сложности базы данных она может разрабатываться как силами собственного отдела информационных технологий, так и с помощью привлекаемых специалистов. В любом случае при эксплуатации требуется наличие специальной группы сопровождения базы данных. Особо следует подчеркнуть необходимость разработки подробной документации (техническое задание, технический и рабочий проекты, руководства пользователей и программистов), так как без нее невозможны сопровождение и доработка системы.
Рассмотрим вопросы проектирования и реализации баз данных на конкретном примере, имеющем маркетинговое приложение.
Проектирование баз данных
Общие аспекты
Проектирование базы данных заключается в многоступенчатом описании будущей базы данных с различной степенью детализации и формализации, в ходе которого производится уточнение и оптимизация ее структуры. Проектирование начинается с описания предметной области и задач информационной системы, идет к более абстрактному уровню логического описания данных и далее – к схеме физической (внутренней) модели базы данных. Трем основным уровням моделирования системы – концептуальному, логическому и физическому – различают три последовательных этапа детализации описания объектов базы данных и их взаимосвязей. На рис. 7.11 представлены этапы проектирования базы данных.
На концептуальном уровне проектирования производится смысловое (семантическое) описание информационного содержания предметной области, определяются границы предметной области, производится абстрагирование от несущественных для данной информационной системы деталей. В результате определяются моделируемые объекты, их свойства и связи. Выполняется структуризация знаний о предметной области, стандартизируется терминология. Затем строится концептуальная модель, описываемая на естественном языке. Для описания свойств и связей объектов применяют различные диаграммы.
Рис. 7.11. Этапы проектирования баз данных
Концептуальная модель служит основой для взаимодействия разработчиков системы и обеспечивает ее долговременную работу.
На следующем этапе принимается решение о том, в какой конкретно СУБД будет реализована база данных. Выбор СУБД является сложной задачей и должен основываться, в первую очередь, на потребностях с точки зрения информационной системы и пользователей. Определяющими здесь являются вид программного продукта и категория пользователей (профессиональные программисты или конечные пользователи, или и то, и другое). Другими показателями, влияющими на выбор СУБД, являются:
· удобство и простота использования;
· качество средств разработки, защиты и контроля базы данных;
· уровень коммуникационных средств в случае применения ее в сетях;
· фирма-разработчик;
· стоимость.
Каждая конкретная СУБД работает с определенной моделью данных. Под моделью данных понимается способ их взаимосвязи: в виде иерархического дерева, сложной сетевой структуры или связанных таблиц. В настоящее время большинство СУБД использует табличную модель данных, называемую реляционной, которая будет подробно описана ниже.
На логическом уровне производится отображение данных концептуальной модели в логическую модель в рамках той структуры данных, которая поддерживается выбранной СУБД. Логическая модель не зависит от конкретной СУБД (в рамках определенной модели данных). Так, построенная на основе таблиц логическая модель может быть реализована на любой СУБД реляционного типа.
На физическом уровне производится выбор рациональной структуры хранения данных и методов доступа к ним, которые обеспечивает выбранная СУБД. На этом уровне решаются вопросы эффективного выполнения запросов к базе данных, для чего строятся дополнительные структуры, например, индексы. В физической модели содержится информация обо всех объектах базы данных (таблицах, индексах, процедурах и др.) и используемых типах данных. Физическая модель зависит от конкретной СУБД. Одной и той же логической модели может соответствовать несколько разных физических моделей. Физическое проектирование является начальным этапом реализации базы данных.
Рассмотрим эти основные этапы проектирования баз данных на примере базы данных Интернет-магазина.
7.3.2. База данных Интернет-магазина: пример проектирования
Проведем последовательное проектирование базы данных для компании, осуществляющей розничную торговлю книгами через Интернет.
Интернет-магазин предлагает широкому кругу потребителей книги по различным разделам: деловая литература, научная, художественная, учебная и др., которые, в свою очередь, делятся на подразделы. Покупатель, зайдя на сайт магазина, выбирает книги в корзину заказов, определяет вид доставки и вид оплаты, после чего заполняет форму заказа (рис. 7.12). Заказ автоматически регистрируется на сервере магазина, данные заказа должны поступить в базу данных информационной системы магазина.
| |||
| Рис. 7.12. Форма заказа Интернет-магазина |
Постоянными пользователями базы данных будут операторы, обрабатывающие заказы и посылающие требования на нужные книги на склад, и сотрудники отдела доставки, распределяющие заказы между курьерами. Заметим, что рассмотрение важного и достаточно сложного вопроса организации системы логистики – управления снабжением и доставкой, выходит за рамки данного примера.
Однако подчеркнем особую важность использования базы данных специалистами в области маркетинга. Для руководителя и сотрудников отдела маркетинга база данных является основой для анализа товара, рынка и покупателя. Именно из базы данных маркетологи должны получать информацию об уровне реализации отдельных наименований, сводку доходности продуктов по различным разделам литературы, особенности и требования постоянных клиентов и др.
Пользователями баз данных являются и другие сотрудники компании, такие как руководитель компании, сотрудники бухгалтерии, менеджер по кадрам. Эта категория пользователей также должена получать информацию в определенной форме и степени структуризации в зависимости от цели: учета, анализа, планирования, управления кадрами. База данных заказов может быть основой для системы принятия решений и системы управления взаимоотношений с клиентами (CRM).
Развитие сети Интернет позволяет стать пользователями базы данных и самих покупателей, которые осуществляют поиск нужной книги по рубрике и заполняют данные своего заказа.
Точки зрения отдельных групп пользователей (различные пользовательские представления) должны быть учтены при проектировании, а их требования должны быть сведены в единую модель базы данных.
Рис. 7.13. Связи между сущностями
Базовыми типами связей сущностей являются: «один-к-одному», «один-ко-многим», «многие-ко-многим». При этом вместо стрелок на диаграмме можно указывать тип связи.
Связь «один-к-одному» (1:1) определяет такой тип связи между сущностями А и В, когда каждому экземпляру сущности А соответствует один и только один экземпляр сущности В и наоборот. Например, если покупатель в магазине оплачивает товары только с помощью одной кредитной карты, то связь между сущностями ПОКУПАТЕЛЬ и КРЕДИТНАЯ КАРТА является связью 1:1 (рис. 7.14).
 | Примечание |
| Сущность – это некоторая абстракция реального объекта, процесса или явления, информацию о котором необходимо хранить в системе. В нашей системе сущностями являются покупатели, заказы, книги. Атрибут сущности – это некоторая характеристика сущности, которая описывает одно из ее свойств. Атрибут имеет имя и принимает значение из некоторого множества значений. Например, у сущности КНИГА могут быть атрибуты: ISBN-код книги, Раздел литературы, Название, Авторы, Цена. Множество значений, разрешенных для данного атрибута, называется его доменом. Домен может насчитывать лишь несколько элементов или очень большое число элементов. Например, для сущности КНИГА домен атрибута Раздел литературы насчитывает около двадцати элементов, домен атрибута Название имеет очень большое число текстов возможных наименований, состоящих из не более чем 50-ти символов и т. д. Домен также указывает на тип возможных данных (число, текст, дата и др.) Для идентификации отдельных экземпляров сущностей должны существовать атрибуты или совокупность атрибутов, которые позволили бы отличать один экземпляр сущности от всех остальных. Такие атрибуты называются идентификаторами. |
Рис. 7.14 Связь «один-к-одному»
Связи «один-к-одному» на практике встречаются редко. В нашем примере целесообразно включить код карты как атрибут сущности ПОКУПАТЕЛЬ и рассматривать одну эту сущность.
Связь «один-ко-многим» (1: М) определяет такой тип связи между сущностями А и В, когда одному экземпляру сущности А может соответствовать ноль, один или несколько экземпляров сущности В, однако каждому экземпляру сущности В соответствует только один экземпляр сущности А.
Пример связи «один-ко-многим» – связь между сущностями ПОКУПАТЕЛЬ и ЗАКАЗ. ПОКУПАТЕЛЬ может размещать несколько заказов, но каждый заказ обязательно имеет ПОКУПАТЕЛЯ и только одного (рис. 7.15).
Рис. 7.15. Связь «один-ко-многим»
Связи «один-ко-многим» наиболее широко распространены.
Связи «многие-ко-многим» также широко распространены. К такому типу относится связь между сущностями ЗАКАЗ и КНИГА. В одном заказе может фигурировать несколько различных книг, в то же время каждая книга может встречаться во многих заказах (рис. 7.16).
Рис. 7.16. Связи «многие-ко-многим»
Проведем теперь проектирование базы данных путем совмещения представлений отдельных групп пользователей.
Для сотрудников отдела заказов есть две сущности: ЗАКАЗ и КНИГА. Как мы отметили, связь ЗАКАЗ – КНИГА является связью «многие-ко-многим». При анализе связи «многие-ко-многим» часто возникает необходимость ввода новых сущностей. В нашем примере непонятно, где хранить такую характеристику как Количество заказанных экземпляров. Это количество определяется книгой, которых может быть в заказе несколько, и не может быть атрибутом сущности ЗАКАЗ. В то же время количество заказанного товара не может быть и атрибутом сущности КНИГА, так как определяется заказом. Выходом из положения является ввод сущности КОРЗИНА ЗАКАЗА, которая связывает заказ с заказанными книгами.
Сущность ЗАКАЗ имеет атрибуты: Код заказа, Дата заказа, Покупатель, Телефон, Адрес электронной почты, Адрес доставки. Код заказа является идентифицирующим отдельный экземпляр сущности (то есть конкретный заказ) атрибутом.
Сущность КНИГА имеет атрибуты: ISBN-код книги, Название, Авторы, Издательство, Год издания, Цена. ISBN-код является международным стандартным номером книг, который присваивается каждой книге. Таким образом, он является естественным идентифицирующим атрибутом.
Сущность КОРЗИНА ЗАКАЗА имеет атрибуты: Код заказа, ISBN-код книги, Количество экземпляров в заказе. Определяющим экземпляр сущности признаком является совокупность полей Код заказа и ISBN-код книги.
Связь «многие-ко-многим» между сущностями ЗАКАЗ и КНИГА реализуется в такой схеме через сущность КОРЗИНА ЗАКАЗА (рис. 7.17). На рисунке помимо названий сущностей указаны ключевые атрибуты.
Рис. 7.17. Пользовательское представление сотрудников отдела заказов
С точки зрения сотрудников маркетинговой службы важным является анализ потребительского спроса, определение потребностей и предпочтений покупателей. Поэтому в представлении маркетолога ПОКУПАТЕЛЬ рассматривается как отдельная сущность, ее следует выделить из сущности ЗАКАЗ, оставив в заказе некоторый идентифицирующий покупателя атрибут, например, код покупателя. Атрибутами сущности ПОКУПАТЕЛЬ являются Код покупателя, Организация, Фамилия, Имя, Отчество, Телефон, Адрес электронной почты, Почтовый адрес. Атрибут Организация определяет, осуществляет ли заказ организация или частное лицо. Это атрибут-признак. Сущность ПОКУПАТЕЛЬ позволяет исследовать сегмент потребителей, выявлять постоянных клиентов и рационально организовать обратную связь с потребителем. Связь между сущностями ПОКУПАТЕЛЬ и ЗАКАЗ представлена на рис. 7.18.
Для выявления спроса на отдельную продукцию и группы продукции, а также для предоставления покупателям возможности поиска книги по разделу, важно ввести в описание сущности КНИГА атрибут Раздел литературы. В этом случае можно реализовать такие запросы, как получение информации об объемах и поступлениях от продаж книг различных разделов.
Сотрудники отдела доставки оперируют только с сущностью ЗАКАЗ. Для них важно обеспечить своевременное выполнение заказа и управление работой курьеров. Поэтому сущность ЗАКАЗ дополняется такими атрибутами как Дата доставки, Дата исполнения, Тип доставки, Цена доставки, Курьер. Курьеру бывают нужны дополнительные сведения: ближайшие станции метро, № маршрутов городского транспорта, как пройти/проехать, желательные часы доставки и т. п. Поэтому целесообразно включить также атрибут Примечание, в котором могут содержаться такие сведения.
Руководитель отдела доставки хотел бы иметь более полные личные данные по курьерам. Его представление состоит из двух сущностей: ЗАКАЗ и КУРЬЕР. Сущность ЗАКАЗ имеет атрибуты: Код заказа, Дата доставки, Дата исполнения, Тип доставки, Код курьера. Сущность КУРЬЕР определяется атрибутами Код курьера, Фамилия, Имя, Отчество, Дата рождения, Дата приема на работу, Рабочая смена. Сущности КУРЬЕР и ЗАКАЗ связаны соотношением один-ко-многим (рис. 7.20).
Рис. 7.18 Пользовательское представление сотрудников отдела маркетинга
Рис. 7.19 Пользовательское представление сотрудников отдела доставки
С точки зрения сотрудника бухгалтерии важным является, как именно будет произведена оплата: наличными курьеру, кредитной картой, через определенную платежную систему Интернет. Поэтому сущность ЗАКАЗ дополняется атрибутом Форма оплаты.
Полная концептуальная модель базы данных представляется теперь в виде пяти сущностей, связанных между собой связями «один-ко-многим» (рис. 7.20).
 |
| Рис. 7.20 Полная концептуальная модель базы данных Интернет-магазина |
Помимо схемы взаимосвязей сущностей в концептуальной модели описываются также атрибуты сущностей и их домены, то есть формируется так называемый Словарь атрибутов. Словарь атрибутов для нашего примера представлен в табл. 7.1. Идентифицирующие атрибуты выделены жирным шрифтом.
| Таблица 7.1 Словарь атрибутов концептуальной модели базы данных Интернет-магазина | |
| Атрибут | Домен |
| ПОКУПАТЕЛЬ | |
| Код покупателя | Целое число, уникальный номер |
| Организация | Да/Нет |
| Фамилия | Текст, не более 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 символов |
| Дата рождения | Дата |
| Дата приема на работу | Дата |
| Рабочая смена | Одно из: первая, вторая, обе |
Логическое проектирование
Если на этапе концептуального проектирования объектом исследования является предметная область, то на этапе логического проектирования в качестве объекта исследования выступают уже сами данные, их структура и правила построения.
Все возможные структуры данных подразделяются на несколько классов структур, представляющих собой структурные модели данных. Часто, говоря о логическом проектировании, эти модели называют просто моделями данных.
Классической и наиболее широко используемой в настоящее время моделью данных являются реляционная модель данных. Исторически ей предшествовали иерархическая и сетевая модели. Ряд СУБД иерархического и сетевого типов применяется до сих пор, так как многие корпорации имеют огромные базы данных, реализованные в этих системах.
Реляционная модель данных
Реляционная модель данных для систем управления базами данных была разработана сотрудником исследовательской лаборатории компании IBM Э. Ф. Коддом. Э. Ф. Кодд, будучи математиком, разработал теорию реляционных баз данных, свободную от недостатков прежних моделей. В 1970 г. он опубликовал статью, посвященную краткому описанию новой модели.
В отличие от предшествующих моделей реляционная модель имеет строгое математическое обоснование в виде теории множеств (реляционная алгебра) и исчислении предикатов (реляционное исчисление).
Основой реляционной модели является отношение (relation). Отношение содержит информацию об одной сущности (об одном классе объектов предметной области) и представляет собой множество элементов, называемых кортежами.
Наглядной формой представления отношения является таблица, в которой значения атрибутов представлены столбцами, а кортежи – строками. База данных представляет собой совокупность таких таблиц. Отметим, что при реализации базы данных в СУБД столбцы таблицы называют полями, а строки – записями.
В Табл.7.2 показан пример отношения ПОКУПАТЕЛЬ, содержащий несколько кортежей (строк, описывающих покупателей). Отметим, что здесь указаны не все атрибуты для сущности ПОКУПАТЕЛЬ из нашего примера.
| Таблица 7.2. Пример отношения ПОКУПАТЕЛЬ | ||||
| Код покупателя | Фамилия | Телефон | Адрес электронной почты | Почтовый адрес |
| Петрова | 125-15-97 | [email protected] | Москва, ул. Зеленая, 2-4 | |
| Краснов | 447-85-96 | [email protected] | Мытищи, ул. Новая, 11-5 |
Заголовочная строка таблицы содержит имена атрибутов отношения, остальные строки представляют собой кортежи, содержащие значения атрибутов для отдельных покупателей.
Реляционная модель данных некоторой предметной области представляет собой набор таких отношений или таблиц. Отношения строятся по определенным правилам, обеспечивающим минимальную избыточность хранения информации, целостность базы данных, легкость модификации базы данных.
Хотя отношения и представляются в форме таблиц, далеко не любая таблица может быть отношением. Основными правилами формирования отношений являются следующие:
· В таблице не может быть повторяющихся строк.
· Порядок строк и столбцов в таблице произвольный.
· На пересечении столбца и строки может находиться только одно значение. Наличие в отношении многозначных атрибутов не допускается.
Рассмотрим подробнее фундаментальные свойства отношений, построенных на этих правилах.
Отсутствие повторяющихся строк. У каждого отношения должен быть атрибут или набор атрибутов, значения которых однозначно определяют кортеж отношения. Конечно, совокупность всех атрибутов однозначно определяет кортеж, однако речь идет о минимальном наборе атрибутов. В связи с этим вводится понятие первичного ключа.
Первичный ключ – это атрибут или минимальный набор атрибутов, однозначно определяющих каждую строку. В примере (табл. 7.2) первичным ключом является Код покупателя.
Первичный ключ – важное понятием в реляционных базах данных. Поиск любого конкретного элемента данных производится по имени таблицы, первичному ключу строки и имени столбца (атрибута).
Первичные ключи используются в следующих целях:
· идентификации строк в таблице;
· ускорения работы со строками таблицы;
· связывания таблиц.
Отсутствие упорядоченности строк. Строки в таблице хранятся в той последовательности, в которой они вводятся. Ускорение поиска достигается путем создания дополнительных структур, называемых индексами. Индексирование нами буде рассмотрено в параграфе, посвященной физическому проектированию базы данных.
Отсутствие упорядоченности столбцов. Столбцы, представляющие значения атрибутов, могут быть размещены в таблице в произвольной последовательности. Для ссылки на значение атрибута используется имя атрибута, то есть заголовок столбца. Следовательно, можно добавлять новые атрибуты в отношение без каких-то существенных модификаций структуры базы данных и с минимальными изменениями в прикладных программах. Обычно первым столбцом является столбец первичного ключа.
Отсутствие многозначных атрибутов. Если атрибут имеет несколько значений в одной строке, то такие значения называются повторяющимися группами. Например, покупатель может указать несколько телефонов для связи. Наличие нескольких телефонов в одной строке для столбца Телефон недопустимо. В этом случае надо создавать новое отношение ТЕЛЕФОН ПОКУПАТЕЛЯ с атрибутами Код покупателя, Телефон.
Связи.Связи между сущностями представляются в реляционной модели связями между таблицами по значениям ключевых атрибутов. В Табл. 7.3. показана связь «один-ко-многим» между таблицами ПОКУПАТЕЛЬ и ЗАКАЗ по столбцу Код покупателя. Первичные ключи таблиц здесь выделены жирным шрифтом. Каждой строке таблицы ПОКУПАТЕЛЬ должны соответствовать одна или несколько строк таблицы ЗАКАЗ с тем же значением атрибута Код покупателя. Во взаимоотношении этих таблиц первую таблицу можно назвать главной, а вторую – подчиненной. Атрибут подчиненной таблицы, по которомуосуществляется связь, называется внешним ключомглавной таблицы.
| Таблица 7.3. Связь таблиц ПОКУПАТЕЛЬ – ЗАКАЗ | ||||
| ПОКУПАТЕЛЬ | ЗАКАЗ | |||
Наши рекомендации |