Анатолий Мотев СанктПетербург бхвпетербург 2006 удк 681 06 ббк 32. 973. 26018. 2 М85
 Скачать 4.25 Mb.
|
|
Èåðàðõè÷åñêàÿ ìîäåëü В иерархической модели отношения между объектами строятся в виде дере- ва. Данная модель характеризуется такими параметрами, как уровни, узлы, связи. Принцип работы модели таков: несколько узлов более низкого уровня соединяются при помощи связи с одним узлом более высокого уровня. Узел (сегмент дерева) — информационная модель элемента, находящегося на дан- ном уровне иерархии. В качестве примера можно привести базу данных университета (рис. В2). Университет I курс II курс III курс Группа 111 Группа 112 Отдельные студенты Рис. В2. Иерархическая модель Обучение в университете разделено на курсы, на каждом курсе есть какое-то количество групп, в состав каждой группы входят конкретные студенты. Рас- смотрев данный пример, мы можем выделить следующие свойства иерархи- ческой модели: несколько узлов низшего уровня могут быть связаны только с одним уз- лом высшего уровня; каждый узел имеет свое имя; у иерархического дерева имеется только одна вершина (корень), не подчи- ненная никакой другой вершине. Ñåòåâàÿ ìîäåëü Сетевая модель базы данных похожа на иерархическую. Она имеет те же ос- новные составляющие (узел, уровень, связь), однако характер их отношений принципиально иной. Сетевая модель основана на связях между наборами данных (агрегатами). Ââåäåíèå 16 В качестве примера можно привести базу данных преподавательского состава университета (рис. В3). Преподавательский коллектив Математика Иванов С. В. Физика Петров А. В. Философия Федоров П. А. Группа Н321 Группа И873 Группа Р125 Рис. В3. Сетевая модель Связь можно осуществить между элементами разных уровней. Ðåëÿöèîííàÿ ìîäåëü Реляционная база данных представляется как совокупность таблиц, связан- ных друг с другом. Для наглядности приведу пример таблицы, которая может появиться в базе данных книжного магазина (табл. В1). Òàáëèöà Â1. Êíèãè Код Название Автор 00001 Основы JavaScript Пол Уилтон 00002 Веб-дизайн Дмитрий Кирсанов 00003 Введение в XML Дэвид Хантер Другая таблица (табл. В2) вполне может существовать в базе данных какого- нибудь компьютерного магазина. Òàáëèöà Â2. Òîâàðû Артикул Наименование Модель Цена (руб.) M-0001 Модем ZyXEL Omni 56K 1500 V-0033 Монитор LG Flatron F700P 5000 A-0242 Колонки SVEN SPS-611 800 Ââåäåíèå 17 В части I мы более подробно рассмотрим специфику таблиц, а пока обратим внимание на их некоторые особенности. Любая таблица состоит из строки заголовков столбцов и одной или более строк с данными. Эти столбцы и строки должны иметь следующие свойства: каждому столбцу таблицы присваивается имя, которое должно быть уни- кальным для этой таблицы; столбцы таблицы упорядочиваются слева направо (т. е. самый первый слева столбец таблицы — это столбец 1, второй слева — столбец 2, ..., са- мый правый — столбец n), хотя упорядоченными они являются только с точки зрения пользователя. Порядок, в котором определены имена столб- цов, становится порядком, в котором в них должны вводиться данные; строки таблицы не упорядочены (их последовательность определяется лишь последовательностью ввода в таблицу); при выполнении операций с таблицей ее строки и столбцы можно обраба- тывать в любом порядке безотносительно к их информационному содер- жанию; в поле на пересечении строки и столбца любой таблицы всегда имеется только одно значение данных и никогда не должно быть множества значе- ний; всем строкам таблицы соответствует один и тот же набор столбцов, хотя любая строка может содержать пустые значения в некоторых столбцах; все строки таблицы обязательно отличаются друг от друга хотя бы одним значением, что позволяет однозначно определить любую строку такой таблицы. Так почему же модель называется реляционной? Все просто, отношение (англ. relation) — это математический термин, используемый для обозначения неупорядоченного набора (совокупности) однотипных записей или таблиц определенного вида. Реляционные системы берут свое начало в математиче- ской теории множеств. Они были предложены сотрудником компании IBM Э. Ф. Коддом (E. F. Codd) в 1968 г. Íåìíîãî òåðìèíîëîãèè Настало время определиться с терминами, используемыми при разработке БД. Основные термины и их описание: сущность (англ. entity) — то, что описано конкретной таблицей (пример: сущность "Книга"); Ââåäåíèå 18 поле (англ. field) — свойство описываемой сущности (примеры: поле "На- звание", поле "Автор"); запись (англ. record) — одна строка таблицы; связь (англ. relationship) — логическое отношение между двумя сущ- ностями. Итак, таблица описывает отдельную сущность. Сущность описывается поля- ми. Между сущностями бывает организована связь (такие сущности называ- ют связанными). ЧАСТЬ I Ïðîåêòèðîâàíèå áàçû äàííûõ Óðîê 1. Àíàëèç ïðåäìåòíîé îáëàñòè, ïðîáëåìû è ïóòè èõ ðåøåíèÿ Óðîê 2. Ôèçè÷åñêîå ïðîåêòèðîâàíèå òàáëèö, âèäû ñâÿçåé, íîðìàëèçàöèÿ Óðîê 3. Òèïû äàííûõ è òèïû òàáëèö Итак, теперь мы знаем, что такое база данных (БД) и для чего она может по- надобиться. Настало время приступить к проектированию БД. Рассмотрим этапы, которые нам необходимо пройти, прежде чем будут соз- даны БД и приложения, которые смогут использовать ее в своей работе: 1. Анализ предметной области. 2. Выбор модели данных (таблицы, связи). 3. Выбор СУБД. 4. Проектирование таблиц. 5. Проектирование приложений (модулей/программ), управляющих БД. 6. Реализация БД на компьютере. 7. Разработка средств администрирования БД (т. е. добавления, удаления, редактирования данных). 8. Эксплуатация БД. Пункты 2 и 3 нами уже продуманы — мы используем реляционную модель данных, реализуемую в СУБД MySQL. ÓÐÎÊ 1 Àíàëèç ïðåäìåòíîé îáëàñòè, ïðîáëåìû è ïóòè èõ ðåøåíèÿ Анализ предметной области — это анализ исходного набора данных. Пред- положим, перед нами стоит задача построения БД для какого-то магазина. Прежде всего, необходимо определить, какие данные нам понадобится хра- нить. Допустим, нам нужно знать: дату продажи; фамилию, имя и отчество продавца; фамилию, имя и отчество покупателя; адрес покупателя; товар; сумму покупки (в рублях). Представим все эти данные в виде таблицы (табл. 1.1). На первый взгляд, данная таблица вполне нам подходит, т. к. содержит все необходимые данные. Если же рассмотреть ее более тщательно, то можно заметить, что такой способ хранения данных повлечет за собой ряд проблем и сложностей. Во-первых, покупатель Петров встречается в таблице несколько раз — он постоянный клиент и довольно часто заходит в наш магазин. В итоге, при каждом его посещении нам приходится вносить одни и те же данные, напри- мер адрес его проживания. Следовательно, мы получаем избыточность дан- ных — повторный ввод информации. Кроме этого, при очередном вводе дан- ных о покупателе мы можем сделать ошибку, указав не тот номер дома или номер квартиры. Соответственно, у нас получится два разных покупателя. ×àñòü I. Ïðîåêòèðîâàíèå áàçû äàííûõ 22 Òàáëèöà 1.1. Áàçà äàííûõ ìàãàçèíà, ñîñòîÿùàÿ èç îäíîé òàáëèöû Дата продажи ФИО продавца ФИО покупателя Адрес покупателя Товар Сумма покупки (в рублях) 12.12.2004 Иванов Иван Иванович Сергеев Андрей Васильевич ул. Мира, д. 8, кв. 15 Телевизор SMK321 12000 12.12.2004 Васин Петр Сергеевич Петров Иван Иванович ул. Марата, д. 32, кв. 3 Лампа накаливания (60 Вт), удлинитель (10 м) 25 13.12.2004 Кузьмин Владимир Владимирович Мухина Анна Викторовна ул. Ленина, д. 21, кв. 14 Аудиосистема PS-911 4800 14.12.2004 Задорнов Виталий Петрович Петров Иван Иванович ул. Марата, д. 32, кв. 3 Чайник Tefal, сковорода Tefal 2340 14.12.2004 Соколов Сергей Александрович Ванин Герасим Андреевич пр. Науки, д. 45, кв. 26 Телефон Dect S115 1200 Во-вторых, если нам понадобится изменить данные, то придется менять их в нескольких местах. Допустим, в адрес закралась орфографическая ошибка или господин Петров решил его сменить. В этом случае нам придется изме- нить адрес столько раз, сколько упоминаний о нем есть в таблице. Напомню, что господин Петров заглядывает к нам довольно часто, чтобы сделать оче- редную покупку. И чем чаще это происходит, тем больше работы нам прихо- дится делать, чтобы поддерживать непротиворечивость данных. Таким обра- зом, получаем проблему обновления данных. На этом список проблем не заканчивается — есть сложности и при удалении данных. Если мы захотим удалить из таблицы какого-нибудь покупателя, то вместе с покупателем будет удалено все, что с ним было связано. Например, будут удалены сведения о товарах, которые он когда-то приобретал. Из всего этого следует, что структура хранения данных, представленная в табл. 1.1, нас совершенно не устраивает. Чтобы избавиться от всех этих сложностей, мы используем прием, называемый нормализацией. ÓÐÎÊ 2 Ôèçè÷åñêîå ïðîåêòèðîâàíèå òàáëèö, âèäû ñâÿçåé, íîðìàëèçàöèÿ Прежде чем приступить к нормализации, необходимо подробнее обсудить некоторые фундаментальные понятия реляционных баз данных. Данная мо- дель состоит из трех основных элементов: сущность; атрибут; связь. Сущности — это те вещи или объекты, данные о которых необходимо хра- нить. В модели данных сущность представляется в виде прямоугольника с заголовком. Заголовок является именем сущности или, если сказать проще, это название таблицы, хранящей данные. То есть сущность в БД — это таб- лица. Атрибуты (поля таблицы) описывают те данные, которые нам нужно знать о сущности. Значение атрибута может быть числом, строкой символов, датой, временем или другим базовым значением данных. Связями, как вы помните, называются логические взаимоотношения между сущностями. Но о связях мы поговорим позже. В нашем примере база данных содержит ряд объектов: покупатель, продавец, наименование товара, дата продажи и т. д. Какие из них являются сущностя- ми? Обратим внимание, что мы определили несколько видов данных (имя, адрес), относящихся к каждому покупателю. Без них невозможно описать покупателя. Поэтому покупатель является одним из объектов, которые мы хотели бы описать, т. е. сущностью. Давайте приступим к разработке модели данных с сущностью "Покупатель" (табл. 2.1). ×àñòü I. Ïðîåêòèðîâàíèå áàçû äàííûõ 24 Òàáëèöà 2.1. Ñóùíîñòü "Ïîêóïàòåëü" Покупатель Почему мы назвали нашу сущность "Покупатель", а не "Покупатели"? По обще- принятому соглашению имя сущности должно быть в единственном числе, т. к. каждая сущность дает имя ее экземпляру. Например, "Петров Иван Иванович" является экземпляром сущности "Покупатель", а не "Покупатели". У каждой сущности есть атрибуты, которые ее описывают. О покупателе нам могут понадобиться подробные сведения (табл. 2.2), например, если он поку- пает что-то в кредит. Òàáëèöà 2.2. Ñóùíîñòü "Ïîêóïàòåëü" ñ àòðèáóòàìè Покупатель ФИО покупателя Адрес Телефон Сергеев Андрей Васильевич ул. Мира, д. 8, кв. 15 362-23-32 Петров Иван Иванович ул. Марата, д. 32, кв. 3 352-48-69 Ванин Герасим Андреевич пр. Науки, д. 45, кв. 26 236-88-00 Вот теперь пришло время нормализации. Впервые понятие "нормализация" ввел Е. Ф. Кодд, занимавшийся исследова- ниями в компании IBM. Целью нормализации является устранение из БД не- которых нежелательных характеристик. В частности, ставится задача избе- жать избыточности данных, приводящей к сложностям при операциях добав- ления, изменения и удаления данных. Понятие нормализации включает пять нормальных форм. Мы рассмотрим три из них — этого достаточно, чтобы сделать структуру БД вполне работо- способной. Ïåðâàÿ íîðìàëüíàÿ ôîðìà (1ÍÔ) Сущность приведена к первой нормальной форме (1НФ), если все ее атрибу- ты имеют единственное значение. Если в каком-либо атрибуте есть повто- ряющиеся значения, то сущность не приведена к 1НФ. Посмотрев на нашу Óðîê 2. Ôèçè÷åñêîå ïðîåêòèðîâàíèå òàáëèö, âèäû ñâÿçåé, íîðìàëèçàöèÿ 25 базу данных (см. табл. 1.1), можно заметить, что в атрибуте "Товар" встреча- ется больше одного значения, т. е. БД не находится в 1НФ. Это означает, что мы упустили, по крайней мере, еще одну сущность. Атрибут "Товар" описы- вает сведения о купленном товаре. Возможно, он тоже является сущностью. Давайте внесем его в нашу модель и добавим другие атрибуты (табл. 2.3). Òàáëèöà 2.3. Ñóùíîñòü "Òîâàð" ñ àòðèáóòàìè Товар Наименование Производитель Цена (в рублях) Чайник Tefal 1145 Телевизор SMK321 Sony 12 000 Телефон Dect S115 Dialon 1200 Теперь у нас есть сущность, приведенная к 1НФ. Прежде чем переходить к рассмотрению второй нормальной формы, необхо- димо подробнее поговорить о связях между сущностями. Êëþ÷è è ñâÿçè У каждого экземпляра сущности должен быть уникальный идентификатор, который будет однозначно определять каждую запись. Какой же из атрибутов может быть таким идентификатором? Нам необходимо выбрать атрибут, ко- торый подчиняется следующим правилам: он уникален для каждой записи (экземпляра сущности); для каждой записи он имеет значение, отличное от NULL (отсутствие дан- ных); для каждой записи его значение не изменяется. Такой атрибут называется первичным ключом (primary key). Если ни один из атрибутов не удовлетворяет этим правилам, то нужно ввести новый атрибут или создать первичный ключ из нескольких атрибутов. Рассмотрим в качест- ве примера таблицу, описывающую сущность "Покупка" (табл. 2.4). В данной таблице ни один из атрибутов нельзя назначить ключевым, т. к. во всех полях данные могут повторяться. В каждом заказе может быть несколь- ко товаров, каждый товар может присутствовать во многих заказах (исклю- чение составляют магазины, торгующие уникальными товарами, но наш ма- газин таким не является). В этом случае можно задать составной ключ ×àñòü I. Ïðîåêòèðîâàíèå áàçû äàííûõ 26 (composite primary key), состоящий из полей "Номер заказа" и "Номер това- ра". Комбинация значений этих полей будет уникальной. Òàáëèöà 2.4. Ñóùíîñòü "Ïîêóïêà" ñ àòðèáóòàìè Покупка Номер заказа Номер товара Количество единиц товара 1 23 1 1 12 1 2 25 2 3 12 10 4 23 2 Выбор ключевого атрибута сущности играет очень важную роль при проек- тировании БД, т. к. он используется для моделирования связей. Если атрибут не удовлетворяет хотя бы одному из перечисленных правил, это может по- влиять на всю модель данных. Рассмотрим таблицу, описывающую покупателя (см. табл. 2.2). Можно попы- таться выбрать в качестве ключевого поле "ФИО". Но что если покупатель изменит фамилию (это вполне возможно)? В этом случае нарушается третье правило для ключевых атрибутов. Кроме того, значения могут оказаться не уникальными — в каждом большом городе найдется несколько Петровых Иванов Ивановичей. Тогда нарушится первое правило. Наконец, возможно, что, вводя данные о покупателе, вы не будете знать его фамилию, имя и отче- ство. Тогда нарушается второе правило, которое гласит, что значение ключа должно быть отличным от NULL Исходя из этого, для таблицы "Покупатель" лучше задать новые поля (табл. 2.5). Для наглядности мы будем подчеркивать имя ключевого атрибута в каждой таблице. Òàáëèöà 2.5. Ñóùíîñòü "Ïîêóïàòåëü" ñ êëþ÷åâûì àòðèáóòîì Покупатель Номер покупателя ФИО покупателя Адрес Телефон Óðîê 2. Ôèçè÷åñêîå ïðîåêòèðîâàíèå òàáëèö, âèäû ñâÿçåé, íîðìàëèçàöèÿ 27 В эту таблицу мы ввели новое поле "Номер покупателя", которое будет уни- кально определять каждого конкретного покупателя нашего магазина. Ключевые атрибуты сущностей (таблиц) позволяют моделировать связи, описывающие взаимоотношения между ними. Есть три типа связей: один к одному (1:1) — устанавливается между таблицами, если запись в первой таблице соответствует только одной записи во второй таблице; один ко многим (1:М) — устанавливается между таблицами, если запись в первой таблице соответствует одной или нескольким записям во второй таблице; многие ко многим (М:М) — устанавливается между таблицами, если одной записи в первой таблице соответствует несколько записей во второй таб- лице, а одной записи во второй таблице соответствует несколько записей в первой таблице. Последний вид связи в реляционных таблицах не реализуется. Связь "1:1" встречается довольно редко. Если при проектировании таблиц вы столкне- тесь с такой связью, следует еще раз внимательно рассмотреть свой проект. Возможно, сущности, между которыми установлена такая связь, являются на самом деле одной. В этом случае их следует объединить. Рис. 2.1. Связь между таблицами "Заказ" и "Продавец" Связь между таблицами, показанными на рис. 2.1, определена как "1:М". По номеру продавца мы можем узнать, какие заказы он обслуживал. Итак, таб- лицы "Продавец" и "Заказ" связаны по полю "Номер продавца". Поле, которое указывает на запись в другой таблице, связанную с данной записью, называется внешним ключом (foreign key). Например, в таблице "За- каз" внешним ключом является поле "Номер продавца". Иными словами, внешний ключ — это поле (или набор полей), значения ко- торого совпадают с имеющимися значениями первичного ключа другой таб- лицы. ×àñòü I. Ïðîåêòèðîâàíèå áàçû äàííûõ 28 Ññûëî÷íàÿ öåëîñòíîñòü Итак, мы уже знаем, что значения в ключевом поле должны быть уникаль- ными. Это является одним из правил ссылочной целостности. Некоторые СУБД могут контролировать уникальность первичных ключей — при попыт- ке присвоить первичному ключу значение, уже имеющееся в другой записи, СУБД сгенерирует диагностическое сообщение. Это сообщение в дальней- шем может быть передано в приложение, при помощи которого пользователь управляет данными. Если две таблицы являются связанными, то внешний ключ одной таблицы должен содержать только значения, имеющиеся среди значений первичного ключа другой таблицы. Допустим, если удалить запись из таблицы "Прода- вец", то в связанной с ней таблице "Заказ" будут присутствовать заказы, об- служенные несуществующим продавцом. |