Глава I

Теория баз данных

Введение

Весь окружающий нас мир состоит из предметов. Любое событие или ситуацию

можно рассматривать как результат взаимодействия определённого числа предметов,

обладающих фиксированным набором свойств. Попытка описать весь окружающий

нас

мир

во

всём

его

многообразии,

т.е.

создать

его

полную

модель

–

занятие

бессмысленное и бесполезное. Непонятно, насколько детально, подробно и с какой

степенью точности необходимо описывать объект (при решении конкретной задачи

по физике мы пренебрегаем силой трения, весом, либо размером определённых тел,

но при других условиях подобные предположения приведут к ошибке).

Знания об объектах и изменении их свойств нам необходимы в любой области,

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

интересует

тот

мир,

в

котором

существуют

наши

предметы,

т.е.

замкнутая,

в

пределах поставленной задачи, система объектов – предметная область (ПО).

Решение целого класса задач связано с большими объёмами информации. Далеко

не

все

задачи

алгоритмические.

Решение

многих

задач

сводится

к

управлению

потоками

информации,

анализу

данных.

Любая

справка,

глава

книги,

письмо,

квитанция — это данные, оформленные на листе бумаги, в таблице. Любые знания —

это своего рода данные, которыми обладает человек. Если для решения наших задач

нам необходимы знания об однотипных объектах или повторяющихся явлениях, то

нам стоит использовать базу данных. База данных (БД) – это структурированные

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

журнала, мы сталкиваемся с большим объёмом однотипных знаний об учащихся

(адрес,

фамилии

родителей,

дата

рождения

и

т.д.)

и

процессе

обучения

(типы

проводимых

работ,

предметы

и

др.).

Для

решения

этой

задачи

использование

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

файлах

электронных

таблиц.

В

одной

школе

одновременно

учится

около

1500

учащихся. Если всё правильно организовать, то, используя специальную структуру

каталогов и подкаталогов, можно справиться с несколькими сотнями электронных

таблиц. В этом случае человек, который работает с таблицами, является диспетчером

БД. Но оценки мы получаем практически каждый день, и, в конце концов, даже

самый

педантичный

человек

запутается

или

уволится.

Столкнувшись

с

такой

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

данных

человека.

Именно

для

этой

цели

служит система

управления

базами

данных (СУБД)

–

комплекс

языковых,

программных

и

технических

средств,

предназначенных для организации взаимодействия пользователя и БД. Эти системы

не

привязываются

к

решению

конкретных

проблем.

В

них

автоматизированы

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

1

стоит на месте, то в каждой новой версии или новом варианте СУБД реализовано всё

большее количество подобных процедур.

Информационные системы

Решение

задач

посредством

СУБД

приводит

к

созданию

информационных

систем (ИС).

По сферам применения различают два основных класса ИС: информационно-

поисковые системы (ИПС) и системы обработки данных (СОД).

Информационно-поисковые системы ориентированы, как правило, на извлечение

подмножества

хранимых

сведений,

удовлетворяющих

некоторому

поисковому

критерию. Причём пользователей интересуют не столько результаты обработки этих

сведений, сколько сама извлекаемая информация.

Обращение пользователей к системам обработки данных чаще всего приводит к

обновлению

информации.

Вывод

информации

может

вовсе

отсутствовать

или

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

сведения. Примером системы обработки данных может быть ИС сберегательного

банка

города.

Она

содержит

сведения

о

вкладах

жителей

города,

большинство

обработок банковской информации предполагает обновление сумм вкладов, расчёт

процентов, подведение итогов за некоторый период работы и т.д.

Локальное пользовательское представление

Задача – составление школьного журнала

Решение этой задачи на первый взгляд кажется очень простым. Любой из нас

представляет себе, что такое школьный журнал.

Соберём

все

данные:

сам

журнал

в

нескольких

экземплярах

(каждый

преподаватель

заполняет

его

по-своему)

и

все

документы,

составленные

на

его

основе. Казалось бы, мы можем приступить к моделированию, однако документов

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

совсем разная информация.

Решая задачу составления школьного журнала, мы рассматриваем её с точки

зрения ученика, однако не стоит забывать, что представление учителя, директора или

РОНО

может

существенно

отличаться

от

нашего.

Каждый

из

них

имеет

своё

представление о предметной области. Составляя систему из разнородных данных, мы

получим сложную, с дублирующейся информацией, и частично ошибочную схему. И

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

придётся расширять и углублять предметную область. Поэтому нам необходимо

изначально быть очень осторожными, чтобы создаваемая нами схема не начинала

2

напоминать хитросплетения паутины. Только ясные и простые описания предадут

системе необходимую гибкость.

Чтобы

разобраться

в

задаче,

нам

необходимо

структурировать

информацию

(рис. 1.1):



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

наша задача;



определить участников событий и пересечение их интересов;



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

которую занимает наша задача.

ДРУГИЕ

ШКОЛЫ

РОНО

РОДИТЕЛИ

ВУЗЫ

ОРГАНЫ

ВЛАСТИ

ШКОЛА

ПРЕПОДАВАТЕЛЬ

МЕТОДИКА

МАТЕРИАЛЬНО

ФИНАНСОВАЯ

ДЕЯТЕЛЬНОСТЬ

ШКОЛЬНЫЙ

ЖУРНАЛ

РЕЗУЛЬТАТЫ

ОБУЧЕНИЯ

УЧЕНИК

Рис. 1.1. Схема пересечения предметных областей

При

проектировании

ИС

взгляды

отдельных

пользователей

на

предметную

область называют локальными пользовательскими представлениями (ЛПП).

Сведение этих взглядов в единую систему, выявление пересекающихся эпизодов

и определение той части, которая необходима для решения поставленной задачи,

разработчик ни в коей мере не может перекладывать на плечи пользователя. Этот этап

является одним из основных при построении ИС. Его реализация невозможна без

изучения

тех

процессов,

которые

протекают

в

изучаемой

предметной

области

(рис. 1.2).

Завершение этапа приведёт к формированию глобального пользовательского

представления (ГПП), т.е. будет отражать точку зрения администратора БД.

Методика обучения

Преподаватель

Обучение

Результаты обучения

Работа с родителями

РОНО

Поступление в другие

учебные заведения

или на работу

Рис. 1.2. Схема учебного процесса

3

Последовательность проектирования ИС

Процесс проектирования ИС состоит из:



сбора данных;



составления частных ЛПП;



унификации пересекающихся эпизодов;



составления ГПП;



формирования

модели

предметной

о б л а с т и

( и н ф о л о г и ч е с к о е

проектирование);



с о с т а в л е н и я

с х е м ы

с

у ч ё т о м

используемого

СУБД

(концептуальное

проектирование);



физического проектирования.

А отображение реального мира можно

представить последовательностью

представлений (рис. 1.3).

Рис. 1.3. Последовательность проектирования

Упражнение 1.1

Для задачи «Школьный журнал»:



Перечислить объекты, подлежащие описанию;



Перечислить свойства объектов, данные о которых необходимы для решения

задачи.

Следует обратить внимание, что каждый предмет имеет своё чёткое название, и на

различных этапах обучения будет называться по-разному. Например: «математика»,

«алгебра», «алгебра и начала анализа».

4

Предметная

область

ЛПП1

ЛПП2

ЛПП3

Г П П

Инфологическая

модель

Концептуальная

модель

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

БД

Программы

СУБД

Инфологическое моделирование

Приступая

к

следующему

этапу

проектирования,

необходимо

помнить,

что

решаемая

задача

составляет

только

часть

предметной

области.

Если

мы

хотим

построить

гибкую

легко

наращиваемую

систему,

то

в

первую

очередь

следует

выделить

наименьший

неделимый,

в

пределах

нашей

задачи,

объект

описания

(минимальный объект описания).

Для нашей задачи этим объектом является не ученик, а его текущая оценка.

Однако, как жизнь невозможна без законов, так и моделирование не существует

без правил. На данном этапе проектирования представление предметной области

сводится в модель, выполненную без ориентации на используемые в дальнейшем

программные и технические средства – инфологическую модель.

Какими

же

средствами

воспользоваться

для

составления

инфологического

описания предметной области? На этот вопрос нет однозначного ответа. Существует

несколько

методик,

и

соответственно

применяются

разные

инструментальные

средства.

Составляемая

модель

должна

быть

проста,

наглядна,

содержать

все

сведения для дальнейших этапов проектирования, легко преобразовываться в модели

баз данных для распространённых СУБД. Исходя из этих требований, в описываемой

методике проектирования используется модель, названная «сущность-связь» (или

«объекты-связи»).

Модель «сущность-связь» позволяет моделировать объекты предметной области

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

Она определяется в терминах: сущность, атрибут, связь.

Сущность – абстракция реально существующего объекта,

процесса или явления. Наименование сущности должно быть

уникально во всей модели. Графическое представление – рис. 1.4.

Тип сущности – определяет набор однородных объектов.

Экземпляр сущности – конкретный объект из этого набора.

Например:

Сущность

«Ученик»

определяет

всю

информацию

об

учениках

вообще. Конкретный ученик Ваня Иванов является экземпляром сущности «Ученик»,

а совокупность всех учеников составляет тип сущности.

Атрибут

–

свойство

сущности

(объекта).

Его

имя

должно

быть

уникально

в

рамках

одной

сущности.

Графическое представление – рис. 1.5.

Экземпляр атрибута – конкретное значение.

Например:

Сущность

«Ученик»

определяется

атрибутами: «Фамилия ученика», «Класс» и т.п. То есть

для каждого конкретного ученика (экземпляра сущности) мы должны определить

экземпляры атрибутов (их конкретные значения). Продолжим с нашим примером:

экземпляр сущности «ученик» Ваня Иванов имеет экземпляр атрибута «фамилия

ученика» – «Ваня Иванов» и экземпляр атрибута «Класс» –

«8А».

Идентифицирующий атрибут (идентифицирующая

совокупность

атрибутов

(ИСА))

–

атрибут

(несколько

атрибутов), значение которого определяет уникальность

экземпляра

сущности.

То

есть

как

любой

человек,

обладает набором качеств, отличающим его от себе подобных, и среди них мы можем

5

Наименование

сущности

Рис. 1.4.

Наименование

атрибута

Рис. 1.5.

Наименование

атрибута

Рис. 1.6.

выявить те, по которым найдём нужного человека (например: полный адрес), так и

любая сущность должна обладать подобным набором. Другими словами, у нас есть

несколько экземпляров одной сущности, и нам необходимо найти один или несколько

атрибутов,

значение

которых

может

встречаться

только

один

раз

среди

всех

экземпляров

этой

сущности.

Например:

Для

сущности

«Человек»

мы

можем

определить атрибут «Фамилия». Но возможно ли, чтобы он был идентифицирующим

атрибутом? Нет, т.к. мы можем встретить несколько людей с одинаковой фамилией. И

тогда

возникает

вопрос

как

одного

«Иванова

Ивана»

отличить

от

другого?

Следовательно, нужно добавить такой атрибут, значения которого гарантированно

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

«Человек» такими атрибутами могут быть «Серия паспорта»+«Номер паспорта».

Графическое представление идентифицирующего атрибута – рис. 1.6.

Связь

позволяет

моделировать

отношения

между

объектами

предметной

области. Наименование связи должно быть уникально во всей модели.

Существует 4 типа связей:

1.

«Один-к-одному» (обозначается – T(A,B)=1:1) – любому экземпляру сущности

А соответствует только один экземпляр сущности В, и наоборот.

1

1

Рис. 1.7. Графическое представление

связи «один-к-одному»

Ученик

Характеристика

Иванов

Отличник

Петров

Хорошист. Вертится на уроках

Сидоров

Болеет за «Зенит»

Рис. 1.8. Пример связи «один-к-одному»

У ученика только одна характеристика (рис. 1.8).

2.

«Один-ко-многим»

(обозначается

–

T(A,B)=1:M)

–

любому

экземпляру

сущности А соответствует 0, 1 или несколько экземпляров сущности В, но

любому

экземпляру

сущности

В

соответствует

только

один

экземпляр

сущности А.

1

М

Рис. 1.9. Графическое представление

связи «один-ко-многим»

Ученик

Дата оценки

Оценка

Иванов

20/10/01 13:40

5

Петров

18/10/01 8:20

4

Сидоров

20/10/01 13:38

4

18/10/01 8:22

4

20/10/01 8:24

5

Рис. 1.10. Пример связи «один-ко-многим»

Ученику ставят много оценок; поставленная оценка принадлежит только одному

ученику (рис. 1.10).

3.

«Многие-к-одному»

(обозначается

– T(A,B)=M:1)

-

любому

экземпляру

сущности А соответствует только один экземпляр сущности В, но любому

экземпляру

сущности

В

соответствует

0,

1

или

несколько

экземпляров

сущности А.

М

1

Рис. 1.11. Графическое представление

6

связи «многие-к-одному»

Преподаватель

Кабинет

Рымкевич

38

Мирошенков

36

Лукошкина

37

Разина

Сусанина

Рис. 1.12. Пример связи «многие-к-одному»

Преподаватель работает только в одном кабинете; рабочий кабинет может быть

закреплен за несколькими преподавателями (рис. 1.12).

Какая же разница между связями «один-ко-многим» и «многие-к-одному»? Такая

же, как между фразами «портфель ученика» и «ученик портфеля». То есть важно, кто

во взаимоотношении двух объектов главный – ученик или портфель. Суть отношений

двух объектов отражается в имени связи.

Если при определении связи вам сложно выделить подчиненность, то вывод

только один: вы плохо разобрались в предметной области.

4.

«Многие-ко-многим»

(обозначается

– T(A,B)=M:M)

–

любому

экземпляру

сущности А соответствует 0, 1 или несколько экземпляров сущности В и

любому экземпляру сущности В соответствует 0, 1 или несколько экземпляров

сущности А.

М

М

Рис. 1.13. Графическое представление

связи «многие-ко-многим»

Ученик Иванов учится у преподавателя Рымкевич, Петров проходит обучение у

двух преподавателей, а Сидоров – у трёх. Нагрузка учителя истории Разиной –

наименьшая, она обучает только Сидорова, Лукошкина – двух учеников, а математик

Рымкевич трудится, не покладая рук.

Ученик

Преподаватель

Иванов

Рымкевич

Петров

Лукошкина

Сидоров

Разина

Рис. 1.14. Пример связи «многие-ко-многим»

Рассматривая

пример

приведённый

на

рис. 1.10.

можно

заметить,

что

при

удалении даты оценки связь между сущностями преобразуется к типу «многие-ко-

многим».

Вернёмся к рассматриваемой нами задаче и составим инфологическую модель в

её первом приближении (рис. 1.15). Выделим основные сущности и определим их

связи:

7

Ученик

Преподаватель

Кабинет

Оценка

М

М

М

1

1

1

Рис. 1.15 Модель для задачи «Школьный журнал»

в первом приближении



Сущность «Ученик» содержит все личные данные учащегося.



Сущность

«Кабинет»

содержит

информацию

о

техническом

уровне,

состоянии, количестве мест.



Сущность

«Преподаватель»

содержит

информацию

об

уровне

подготовки,

заслугах, разряду и личных данных учителя.



Сущность «Оценка» содержит информацию об оценке, полученной учеником

по

определённому

предмету,

выставленную

преподавателем

в

конкретный

день.

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

Получает(ученик, оценка)=1:М – без сомнения, в ходе обучения любой ученик

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

ученику.

Работает_в(преподаватель,

кабинет)=М:1

–

в

нашей

школе

за

каждым

преподавателем закреплен конкретный кабинет. Но в одном кабинете (в разное время)

могут работать несколько преподавателей.

Ставится(оценка,

преподаватель)=М:1

–

любой

преподаватель

в

ходе

своей

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

рукой.

После первого этапа составления инфологической модели вы можете получить

различные результаты. Единственное, что в ваших моделях должно быть идентично –

это минимальный объект описания.

Теперь

попытаемся

составить

полную

инфологическую

модель

задачи

«Школьный

журнал».

Для

этого

перечислим

те

правила,

которым

должна

удовлетворять модель «сущность-связь»:

1.

модель должна давать полное представление о предметной области;

2.

должны быть перечислены все необходимые для реализации задачи сущности

и их атрибуты соответственно;

3.

имена сущностей должны быть уникальны;

4.

имена атрибутов в пределах одной сущности должны быть уникальны;

5.

мы должны гарантировать однозначную трактовку модели;

8

6.

в каждой сущности должна быть выделена идентифицирующая совокупность

атрибутов;

7.

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

без существенных изменений существующей модели.

Представленная

на

рис. 1.16

модель

позволяет

решить

основные

задачи

школьного журнала. Она является одним из многих возможных вариантов решения.

Её

составление

шло

для

вымышленной

школы

(для

вашей

школы

результат

моделирования задачи может существенно отличаться). Более того, представленная

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

одному

предмету

выставить

сразу

несколько

оценок.

Обойти

такое

ограничение

можно

введением

абстрактного

атрибута

«№

оценки».

Этот

атрибут

не

несёт

смысловой

нагрузки,

кроме

количественной,

однако,

определив

его

как

идентифицирующий, мы избежим трудностей при выставлении оценок.

9

Ученик

Преподаватель

Кабинет

Оценка

М

М

М

1

1

1

Специализация

класса

Фамилии

родителей

Классный

руководитель

Место работы

родителей

Номер уч/билета

Класс

Адрес

Предмет

Преподаватель

Номер уч/билета

Оценка

Дата

Фамилия ученика

Телефон

Фамилия

преподавателя

Адрес

преподавателя

Разряд

Заслуги

Количество

мест

Технический

уровень

№ кабинета

Состояние

Рабочий

кабинет

Рис. 1.16. Полная инфологическая модель задачи «Школьный журнал»

10

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

На

этапе

концептуального

проектирования

преобразуется

инфологическая

модель в схему, поддерживаемую конкретной СУБД. Так какую из систем управления

базами данных предпочесть? На практике этот вопрос возникает практически всегда,

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

можно классифицировать по поддерживаемой модели данных: реляционная, сетевая,

иерархическая.

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

Почти все современные системы основаны на реляционной (relational) модели

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

в

такой

базе

данных

содержит

информацию,

относящуюся

только

к

одному

конкретному объекту.

В

реляционной

СУБД

все

обрабатываемые

данные

представляются

в

виде

таблиц. Информация об объектах определённого вида представляется в табличном

виде: в столбцах таблицы сосредоточены различные атрибуты объектов, а строки

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

Модель,

созданная

на

этапе

инфологического

моделирования,

в

наибольшей

степени

удовлетворяет

принципам

реляционности.

Однако

для

приведения

этой

модели

к

реляционной,

необходимо

выполнить

процедуру,

называемую

нормализацией.

Теория нормализации оперирует с пятью нормальными формами. Эти формы

предназначены

для

уменьшения

избыточности

информации,

поэтому

каждая

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

некоторым

дополнительным

условиям.

При

практическом

проектировании

баз

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

рассмотрением первых четырёх нормальных форм.

Введём понятия, необходимые для понимания процесса приведения модели к

реляционной схеме.

Отношение – абстракция описываемого объекта как совокупность его свойств.

Проводя инфологический этап проектирования, мы говорили об абстракции объектов

и

приписывали

им

некоторые

свойства.

Теперь

же,

проводя

концептуальное

проектирование, мы переходим к следующему уровню абстракции. На данном этапе

объектов, как таковых, уже не существует. Мы опелируем совокупностью свойств

которые и определяют объект.

Экземпляр отношения – совокупность значений свойств конкретного объекта.

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

этих атрибутов уникально в данном отношении. Не существует двух экземпляров

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

Простой атрибут – атрибут, значения которого неделимы.

11

Сложный

атрибут

–

атрибут,

значением

которого

является

совокупность

значений нескольких различных свойств объекта или несколько значений одного

свойства.

Нормализация отношений

Первая нормальная форма

Отношение называется приведённым к первой нормальной форме, если все

его атрибуты простые.

Адрес

Фамилия

ученика

Специали-

зация

класса

Классный

руководитель

Класс

Место работы

родителей

Фамилии

родителей

Номер

ученического

билета

Брянцева

д.12, кв. 7

Иванов

Иван

Математи-

ческий

Рымкевич

Владимир

Анатольевич

7Б

ЛОМО

Электросила

Иванов И.И.

Иванова Е.В.

1

Брянцева

д.16, кв. 81

Петров

Петр

Гуманитар -

ный

Разина

Светлана

Ивановна

8А

р/к

«Пищевик»

Петров П.С.

2

Учительская

ул. д.16, кв.

53

Смирнова

Анна

Математи-

ческий

Рымкевич

Владимир

Анатольевич

7Б

Ч.п.

«Смирнов и

К

о

»

Домохозяйка

Смирнов А.Е.

Смирнова Т.В.

4

Брянцева

д.1, кв. 20

Гончарова

Ирина

Не

специализи-

рованный

Лукошкина

Дарья

Федоровна

6В

О/М №63

Д/с №145

Сидоров О.Н.

Гончарова С.Ю.

3

ис. 1.17. Отношение «Ученик»

Улица

Контекст

адреса

Фамилия

ученика

Специали-

зация

класса

Классный

руководитель

Класс

Место

работы

родителей

Фамилии

родителей

Номер

уч/билета

Брянцева ул.

д.12, кв. 7

Иванов

Иван

Математи-

ческий

Рымкевич

Владимир

Анатольевич

7Б

ЛОМО

Иванов И.И.

1

Брянцева ул.

д.12, кв. 7

Иванов

Иван

Математи-

ческий

Рымкевич

Владимир

Анатольевич

7Б

Электросила

Иванова Е.В.

1

Брянцева ул.

д.16, кв. 81

Петров

Петр

Гуманитар -

ный

Разина

Светлана

Ивановна

8А

р/к

«Пищевик»

Петров П.С.

2

Учительская

ул.

д.16, кв. 53

Смирнова

Анна

Математи-

ческий

Рымкевич

Владимир

Анатольевич

7Б

Ч.п.

«Смирнов и

К

о

»

Смирнов А.Е

4

Учительская

ул.

д.16, кв. 53

Смирнова

Анна

Математи-

ческий

Рымкевич

Владимир

Анатольевич

7Б

Домохозяйка

Смирнова Т.В.

4

Брянцева ул.

д.1, кв. 20

Гончарова

Ирина

Не специа-

лизиро-

ванный

Лукошкина

Дарья

Федоровна

6В

О/М №63

Сидоров О.Н.

3

Брянцева ул.

д.1, кв. 20

Гончарова

Ирина

Не специа-

лизиро-

ванный

Лукошкина

Дарья

Федоровна

6В

Д/с №145

Гончарова С.Ю.

3

ис. 1.18. Отношение «Ученик», приведённое к первой нормальной форме

При

приведении

отношения

«Ученик»

к

первой

нормальной

форме

мы

выполнили два действия:



Атрибут «Адрес» состоит из значений двух свойств. Мы разбили его на

атрибуты «Улица» и «Контекст адреса».



Значения атрибута «Фамилии родителей» содержит один или два значения

«Родитель», поэтому мы разделили на несколько значений, что привело к

увеличению числа экземпляров отношения.

12

Полученное отношение не полностью приведено к первой нормальной форме.

Придерживаясь

правила,

следовало

бы

разбить

атрибуты

«Фамилия

ученика»,

«Классный руководитель», «Фамилии родителей» на «Фамилия», «Имя», «Отчество»

каждый.

Однако

каждый

из

исходных

атрибутов

по

сути

нашей

задачи

будет

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

формальный подход к процессу нормализации неуместен. Разбивая атрибут «Адрес»

на

два

атрибута,

мы

также

рассуждали

неформально.

Разработка

ведется

для

районной

школы

учащиеся

которой

живут

поблизости,

и

следовательно

спектр

задействованных

улиц

невелик.

Вполне

вероятно

возникновение

задач,

использующих

улицу

как

отдельное

значение,

но

вряд

ли

возникнут

задачи,

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

Вторая нормальная форма

Отношение находится во второй нормальной форме, если оно находится в первой

нормальной

форме,

и

значения

в

каждом

неключевом

атрибуте

однозначно

определяются значением первичного ключа.

Значения

в

не

ключевых

атрибутах

«Улица»,

«Контекст

адреса»,

«Фамилия

ученика», «Специализация класса», «Классный руководитель», «Класс» отношения

«Ученик»

однозначно

определяется

значениями

одного

из

атрибутов

первичного

ключа

(«Номер

ученического

билета»).

При

приведении

данного

отношения

ко

второй нормальной форме оно разделяется на два отношения: «Родители» и «Личные

данные ученика». Первичным ключом отношения «Родители» является совокупность

атрибутов «Фамилии родителей» и «Номер ученического билета», т.к. только она

уникально определяет экземпляры отношения. Первичный ключ отношения «Личные

данные

ученика»

–

атрибут

«Номер

ученического

билета»,

т.к.

он

уникально

определяет экземпляры отношения.

Место работы родителей

Фамилии

родителей

Номер

ученического

билета

ЛОМО

Иванов И.И.

1

Электросила

Иванова Е.В.

1

р/к «Пищевик»

Петров П.С.

2

Ч.п. «Смирнов и К

о

»

Смирнов А.Е

4

Домохозяйка

Смирнова Т.В.

4

О/М №63

Сидоров О.Н.

3

Д/с №145

Гончарова С.Ю.

3

Рис. 1.19. Отношение «Родители»

Улица

Контекст

адреса

Фамилия ученика

Специализация

класса

Классный руководитель

Класс

Номер

уч/билета

Брянцева ул.

д.12, кв. 7

Иванов Иван

Математический

Рымкевич Владимир

Анатольевич

7Б

1

Брянцева ул.

д.16, кв. 81

Петров Петр

Гуманитарный

Разина Светлана

Ивановна

8А

2

Учительская ул.

д.16, кв. 53

Смирнова Анна

Математический

Рымкевич Владимир

Анатольевич

7Б

4

Брянцева ул.

д.1, кв. 20

Гончарова Ирина

Не специализи-

рованный

Лукошкина Дарья

Федоровна

6В

3

ис. 1.20. Отношение «Личные данные ученика»

13

Третья нормальная форма

Отношение находится в третьей нормальной форме, если оно находится во

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

В

отношении

«личные

данные

ученика»

после

приведения

его

ко

второй

нормальной

форме

неключевые

атрибуты

«Специализация

класса»

и

«Классный

руководитель»

зависят

от

неключевого

атрибута

«Класс».

Для

устранения

этой

зависимости выделим из отношения «личные данные ученика» отношение «Класс».

Первичным ключом созданного отношения будет атрибут «Класс».

Место работы родителей

Фамилии

родителей

Номер

ученического

билета

ЛОМО

Иванов И.И.

1

Электросила

Иванова Е.В.

1

р/к «Пищевик»

Петров П.С.

2

Ч.п. «Смирнов и К

о

»

Смирнов А.Е

4

Домохозяйка

Смирнова Т.В.

4

О/М №63

Сидоров О.Н.

3

Д/с №145

Гончарова С.Ю.

3

Рис. 1.21. Отношение «Родители»

Улица

Контекст

адреса

Фамилия ученика

Класс

Номер

уч/билета

Брянцева ул.

д.12, кв. 7

Иванов Иван

7Б

1

Брянцева ул.

д.16, кв. 81

Петров Петр

8А

2

Учительская ул.

д.16, кв. 53

Смирнова Анна

7Б

4

Брянцева ул.

д.1, кв. 20

Гончарова Ирина

6В

3

Рис. 1.22. Отношение «Личные данные ученика»

Специализация класса

Классный руководитель

Класс

Математический

Рымкевич Владимир Анатольевич

7Б

Гуманитарный

Разина Светлана Ивановна

8А

Не специализированный

Лукошкина Дарья Федоровна

6В

Рис. 1.23. Отношение «Класс»

Четвертая нормальная форма

Отношение находится в четвёртой нормальной форме, если оно находится в

третьей

нормальной

форме,

и

если

в

нём

не

содержатся

независимые

группы

атрибутов, между которыми существует отношение «многие-ко-многим».

Рассматриваемый

нами

пример

соответствует

четвёртой

нормальной

форме.

Рассмотрим

приведение

к

четвёртой

нормальной

форме

на

примере

отношения

«вылет» (рис. 1.24), описывающего какой тип самолета, в какой день и по какому

рейсу летит.

Рейс

День недели

Тип самолета

111

Понедельник

700

111

Понедельник

710

111

Четверг

700

111

Четверг

710

222

Среда

600

222

Среда

615

Рис. 1.24. Отношение «Вылет»

14

Рейс - День недели

Рейс - Тип самолета

Рейс

День недели

Рейс

Тип самолета

111

Понедельник

111

700

111

Четверг

111

710

222

Среда

222

600

222

615

Рис. 1.25. Отношения, приведённые к четвёртой нормальной форме

Отношение «Вылет» содержит независимые, по сути, атрибуты «День недели» и

«Тип самолета». В случае, если бы в понедельник и четверг рейс 111 обслуживался

не одинаковыми типами самолетов (рис. 1.26), то приведение к четвёртой нормальной

форме этого отношения не требовалось.

Рейс

День недели

Тип самолета

111

Понедельник

700

111

Понедельник

710

111

Четверг

700

222

Среда

600

222

Среда

615

Рис. 1.26. Отношение «Вылет», не требующее

приведения к четвёртой нормальной форме

Требования к реляционным моделям

Рациональные

варианты

концептуальной

схемы

базы

данных

должны

удовлетворять третьей нормальной форме, а также следующим требованиям:



выбранный

перечень

отношений

должен

быть

минимален.

Отношение

используется, если только его необходимость обусловлена задачами.



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

в отношение только в том случае, если он будет использоваться.



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

исключить ни один атрибут из идентифицирующей совокупности атрибутов,

не нарушив при этом однозначной идентификации.



при выполнении операций над данными не должно возникать трудностей.

Отношение «Класс» содержит атрибут

«

Специализация класса». В нашей школе

не

один

математический

класс.

Если

необходима

корректировка

названия

специализации,

то

изменения

придётся

вносить

неоднократно.

Целесообразно

выделение отношения «Справочник специализаций».

Специализация класса

Классный руководитель

Класс

1

Рымкевич Владимир Анатольевич

7Б

2

Разина Светлана Ивановна

8А

3

Лукошкина Дарья Федоровна

6В

Рис. 1.27. Отношение «Класс»

Специализация класса

№

Математический

1

Гуманитарный

2

Не специализированный

3

Рис. 1.28. Отношение «Справочник специализаций»

Последний совет, который можно дать при составлении реляционной модели

данной задачи и сведении к минимуму объёмов памяти, необходимых для хранения

15

информации, – заменить ключевые атрибуты со сложным написанием экземпляров,

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

Например:

Отношение

«Класс»

содержит

атрибут

«классный

руководитель».

Введя

в

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

существенно уменьшим место, необходимое для хранения экземпляров отношения

«класс».

Графическая интерпретация реляционной схемы

Концептуальная модель, реализованная в виде реляционной схемы, имеет свои

правила графического представления.



Отношение

представляется

в

виде

полоски,

содержащей

имена

всех

атрибутов. Имя отношения пишется над ней.



Первичный ключ отношения должен быть выделен жирной рамкой.



Связи, определённые между отношениями, должны быть показаны линиями,

проведёнными

между

связующими

атрибутами.

Значения

экземпляров

связующих атрибутов должны совпадать.

Теория

проектирования

реляционных

баз

данных

относится

к

разделу

математики, называемому теорией множеств, а правила и символы, определяемые в

ней, реляционной алгеброй. Наш курс и так насыщен теоретическими терминами и

понятиями. В рамках данного курса не предполагается изучение высшей математики.

Описанных

выше

правил

достаточно

для

понимания

общих

принципов

моделирования.

На

рис. 1.29

приведена

реляционная

модель

той

части

задачи

школьного

журнала,

нормализацией

которой

мы

занимались

на

предыдущих

страницах.

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

именно такой вид представления наиболее удобен для проведения дальнейших этапов

проектирования.

Понимая

это,

условимся

в

дальнейшем

проводить

этап

инфологического проектирования с учётом требований к реляционным моделям.

«Родители»

Фамилии родителей

Номер ученического билета

Место работы родителей

«Личные данные ученика»

Номер уч/билета

Улица

Контекст адреса

Фамилия ученика

Класс

«Справочник улиц»

№

Улица

«Класс»

Класс

Специализация класса

Классный руководитель

«Справочник специализаций»

№

Специализация класса

Рис. 1.29. Фрагмент реляционной модели

Упражнение 1.2

16

Составление реляционной модели для задачи «Школьный журнал»

.

Таблица соответствий понятий на этапах проектирования

ЛПП

Инфологическое

проектирование

Концептуальное

проектирование

Предметная область

Модель «сущность-

связь»

Реляционная схема

Объект

Сущность

Отношение

Свойство

Атрибут

Атрибут

Взаимоотношение объектов

Связь

Связь

Конкретный объект

Экземпляр сущности

Экземпляр

отношения

Конкретное значение свойства

объекта

Экземпляр атрибута

Экземпляр

атрибута

Набор свойств, определяющих

конкретный объект

Идентифицирующая

совокупность

атрибутов

Первичный ключ

пражнение 1.3

Приведение отношения «Библиотека» к реляционному виду (файл library.xls).

17

Сетевая модель

Рассмотрим пример поставки деталей для сборки изделий. Данная задача легко

вписывается в сетевую схему, представленную на рис. 1.30.

Поставщик

Деталь

Изделие

дуги

узлы

Рис. 1.30. Пример сетевой схемы

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

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

изделие собирается из нескольких деталей, причём деталь может использоваться в

нескольких изделиях.

П1

П2

П3

Д1

Д2

Д3

Д4

Д5

И1

И2

И3

Уровень 1

Уровень 2

Уровень 3

Рис. 1.31. Экземпляр сетевой схемы

В приведённом примере связь между первым и третьим уровнем отсутствовала.

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

Если наша фирма занимается не только сборкой, но и продажей, то нам могут

поставляться не только детали , но и готовые изделия (рис. 1.32).

П1

П2

П3

Д1

Д2

Д3

Д4

Д5

И1

И2

И3

Уровень 1

Уровень 2

Уровень 3

Рис. 1.32. Экземпляр сетевой схемы поставок для продаж

Другим примером задачи, реализующейся сложной сетевой структурой, является

реализация схемы (рис. 1.33), по которой составляется родословная щенков. Данный

18

пример иллюстрирует циклические связи (рис. 1.34), в которых один и тот же тип

выступает в роли и родителя и подчинённого (рис. 1.35).

Собака 1

Собака 2

Собака 3

Собака 4

Собака 5

Собака 6

Собака 7

Собака 8

Собака 9

Собака 10

Собака 11

Собака 12

Собака 13

Собака 14

Собака 15

Собака 16

Собака 17

Собака 18

Собака 19

Собака 20

щенок

2 колено

1 колено

3 колено

Рис. 1.33. Экземпляр сетевой схемы родословных

Щенок

Мама

Папа

Циклическая связь

(щенок вырастает)

Рис. 1.34. Иллюстрация сетевой схемы родословных

Собака

Вырастает

Является

родителем

Рис. 1.35. Сетевая схема родословных

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

Иерархическая,

иначе

называемая древовидной

модель

имеет

более

жёсткие

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

(рис. 1.36). Её вершина всегда начинается с единственной корневой записи. Любая

промежуточная

запись

имеет

одну

или

несколько

дочерних

и

только

одну

родительскую. Доступ к записи осуществляется только через исходную корневую, и

путь прохождения по иерархии – единственный.

19

А

B

C

D

E

F

G

H

I

Корневая (исходная)

Порожденные записи

Подобные записи

Иерархический

путь доступа к

записи I

Порождающая

связь

Рис. 1.36. Экземпляр иерархической модели

Упражнение 1.4

Приведите сетевую структуру представленную на рис. 1.37, к иерархической.

Житель

Поликлиника

Организация

Банк

Рис. 1.37.

Существенным

недостатком

подобного

перевода

является

неизбежная

повторяемость данных.

Упражнение 1.5

Приведение структуры представленной на рис. 1.37 к реляционной.

Упражнение 1.6

Приведение структуры представленной на рис. 1.30 к реляционной.

Упражнение 1.7

*

Приведение структуры представленной на рис. 1.35 к реляционной.

Совет:



Определить состав отношений;



Определить связи;



Привести отношения к третьей нормальной форме.

20

Глава II

Проектирование информационных

систем

Задача. Вы

получили

заказ

создать

приложение

для

небольшой

фирмы. Эта фирма занимается сборкой и продажей компьютерных

систем

и

их

комплектующих

по

заказам,

а

также

установкой

сопутствующего программного обеспечения.

Из условий задачи следует, что каждый заказ может содержать несколько систем,

отдельных

комплектующих

и

экземпляров

программного

обеспечения;

в

свою

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

Сказанное

выше

очень

удобно

проиллюстрировать,

воспользовавшись

сетевой

моделью (рис. 2.1).

Заказ

Комплектующие

или системы

входят

собираются из

Рис. 2.1.

Представленная

модель

отражает

представление

на

предметную

область

человека,

занимающегося

сборкой

заказа.

Для

дальнейшего

проектирования

мы

должны

рассмотреть

взгляды

других

пользователей

либо

найти

другие

методы

решения задачи.

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

Первый:



Изучение производственных процессов;



Составление пользовательских представлений;



Составление схемы пересечения областей;



Определение данных, необходимых конечному пользователю;



Составление структуры данных.

Второй:



Составление задач, подлежащих решению;



Объединение задач в тематические группы;



Определение методов решения задач;



Определение полного перечня данных, необходимых для решения задач;



Объединение данных в группы.

21

Первый подход подробно рассматривался в главе I и начинался с анализа данных.

Второй, противоположный ему, начинается с определения задач. Для того, чтобы

окончательно решить каким из подходов воспользоваться, необходимо определить:

1.

Тип ИС (ИПС или СОД);

2.

Квалификацию конечных пользователей (в ряде случаев служащие доходят до

абсурда,

зная

только

последовательную

цепочку

действий,

либо

и

вовсе

определяя параметры «на глазок»).

Использование

второго

метода

более

логично

в

нашем

случае.

Однако,

не

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

конечных

пользователей

о

составе

задач,

методах

их

решения

и

ожидаемых

результатах.

При реальном проектировании обычно применяется комбинированный метод.

Постановка задачи

Перед началом работы над конкретным приложением стоит затратить некоторое

время

на

составление списка всех основных задач, которые должны были бы, в

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

будущем могут встать перед вами.

Итак, фирме необходимо решать следующие задачи:



регистрация заказов;



расчёт стоимости (при оформлении заказов);



выставление счетов клиентам;



учёт платежей клиентов;



ведение информации о заказанных у поставщиков комплектующих;



расчёт задолженности поставщикам;



оплата счетов поставщиков;



анализ ежеквартальных объёмов продаж;



выпуск каталогов продукции.

Помимо

этого,

как

и

в

любой

фирме,

сотрудники

должны

вести

учёт

поставщиков,

клиентов,

комплектующих

деталей,

выпускать

прайс-листы,

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

Конечно же, этот список можно продолжить. Однако остановимся пока только на

предложенных задачах.

Группировка

задач

и

графическое

представление

последовательности

их

выполнения помогут вам определить «естественный» порядок выполнения задач. На

рис. 2.2 представлена схема связей между задачами для нашего примера.

22

Определить

поставщиков

Определить

компоненты

Сделать каталог

изделий

Определить клиентов

и торговых агентов

Ввести заказы

Напечатать документы

Выяснить статистику

продаж

Рис. 2.2. Схема связи между задачами

рассматриваемого примера

Анализ данных

После

того

как

вы

сформировали

список

задач,

наиболее

важным

этапом

является

составление

для

каждой

задачи

подробного перечня

всех

данных,

необходимых для её решения.

В нашем примере:



данные о поставщиках;



данные о компонентах;



каталог изделий;



данные о клиентах;



данные о заказах;



данные о торговых агентах;



данные об ежемесячных продажах.

Составление модели данных

Составляя обобщённую инфологическую модель, представленную на рис 2.3, мы

придерживались следующих рассуждений:



Любая фирма предпочитает поддерживать отношения со своими клиентами и,

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



Для каждого клиента мы будем выполнять много заказов, и каждый заказ

исполняется для единственного заказчика.



Фирма

содержит

штат

менеджеров

(агентов),

работающих

с

клиентами.

Именно этот человек ответственен за исполнение заказа, однако он может

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

поэтому не будем закреплять клиента за менеджером.



Заказываемые изделия выбираются из каталога (прайса фирм).



В свою очередь каждое изделие прайса собирается из компонентов.



Данные

об

ежемесячных

продажах

мы

получим,

проанализировав

информацию о текущих заказах.

23

Поставщик

Компонент

Каталог

Заказ

Клиент

Торговый

агент

Рис. 2.3. Обобщённая инфологическая модель

Итак,

обобщенная

модель

составлена.

Далее

мы

должны

перечислить

все

атрибуты сущностей, выделить ИСА.

Сущность «Поставщик»

содержит

всю

информацию

о

поставщике.

Её

атрибуты:

имя поставщика – фамилия или название фирмы поставщика;

адрес

–

страна,

обозначение

штата

(области,

провинции),

почтовый

индекс,

город, улица, дом, квартира;

телефон/факс – номер телефона и факса;

задолженность

поставщику

–

сумма

текущей

задолженности

поставщику

(поставки производятся без предоплаты);

дата оплаты – дата нашей следующей выплаты поставщику;

сумма выплаты – сумма следующей выплаты поставщику.

Сущность «клиент» содержит всю информацию о заказчике. Её атрибуты:

имя клиента – ФИО представителя заказчика;

имя фирмы – наименование фирмы клиента;

адрес

–

юридический

адрес:

название

страны

клиента,

обозначение

штата

(области, провинции), почтовый индекс, город, улица, дом, квартира;

телефон/факс – номер телефона и факса;

кредит – предел допустимого кредита, определённый для клиента;

задолженность – общая сумма задолженности;

дата оплаты – дата последней оплаты.

Сущность «Торговый

агент»

содержит

всю

информацию

о

менеджере

по

продажам. Ее атрибуты:

фамилия/имя и второе имя агента – фамилия, имя и второе имя торгового агента;

код e-mail – адрес электронной почты;

адрес

–

страна,

обозначение

штата

(области,

провинции),

почтовый

индекс,

город, улица, дом, квартира;

телефон/пейджер – номер телефона и пейджера.

Сущность «Компонент»

содержит

всю

информацию

о

заказываемых

у

поставщиков компонентах. Её атрибуты:

описание – название компонента;

изготовитель – название фирм-производителя;

24

тип продукции – тип продукции, к которому относится данный компонент;

стоимость – стоимость компонента;

в наличии – количество компонентов, имеющихся в наличии;

минимум

запаса

–

минимальное

количество

компонента.

Если

в

наличии

меньшее количество, необходимо оформить заказ новой партии у поставщика;

оптимальная партия – оптимальный размер заказываемой у поставщика партии;

подробное описание – подробное описание характеристик компонента.

Сущность «Каталог» содержит прайс фирмы, все продаваемые компоненты,

системы и ПО. Её атрибуты:

описание – название изделия в каталоге;

тип продукции – тип продукции, к которому относится изделие;

наша стоимость – стоимость изделия в соответствии с закупочной стоимостью

компонентов;

цена – розничная (продажная) стоимость изделия;

дней на сборку – количество дней, необходимое для сборки изделия;

в наличии – количество уже собранных изделий;

изображение – изображение изделия;

подробное описание – подробное описание изделия;

компоненты

–

перечень

названий

компонентов,

входящих

в

изделие

(через

запятую);

штук – количество каждого вида компонента (через запятую).

Сущность «Заказ» содержит перечень всех заказываемых клиентом изделий и

другие данные о заказе. Её атрибуты:

дата исполнения – дата исполнения заказа;

имя клиента – ФИО клиента или название фирмы-заказчика;

имя получателя – ФИО человека, которому доставляется заказ;

адрес

–

адрес

доставки:

страна,

обозначение

штата

(области,

провинции),

почтовый индекс, город, улица, дом, квартира;

торговый

агент

–

фамилия

торгового

агента,

ответственного

за

выполнение

заказа;

даты

заказа/поставки/оплаты

–

дата

оформления

заказа,

дата

доставки,

дата

последнего платежа;

скидка – скидка на данный заказ;

процент налога – налог на данный заказ (%);

транспортные расходы – сумма, израсходованная на доставку данного заказа;

условия оплаты – условия, по которым производится оплата;

выписка счёта – выписывался ли счёт по данному заказу (да/нет);

примечание – особые примечания к данному заказу;

название изделия – перечисленные названия изделий, входящие в заказ (через

запятую);

количество – перечисленные количества изделий;

договорная цена – перечисленные договорные стоимости, в соответствии с их

заказанным количеством;

особые

условия

–

особые

условия,

поставленные

клиентом

по

каждому

из

заказанных изделий.

25

Прежде

чем

приступать

к

формированию

реляционной

модели,

рассмотрим

подробнее некоторые сущности.

Сущность

«Поставщик»

кроме

непосредственных

данных

о

поставщике

содержит информацию о поставляемых партиях и об их оплате. Логично будет

выделить из понятия «поставщик» понятия «поставка» и «оплата». При отсутствии

предоплаты возможны отсрочки платежей, а также частичная оплата или по итогам

квартала.

Следовательно,

не

следует

связывать

поставку

с

конкретной

оплатой

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

суммарных «стоимостей» поставок и суммарной выплаты.

Поставщик

Поставка

Оплата за

поставки

Имя

поставщика

Адрес

Дата поставки

Комплект

поставки

Стоимость

Дата оплаты

Сумма выплаты

Рис. 2.4. Фрагмент инфологической модели

на начальной стадии составления

Сущность «Клиент» содержит информацию о сумме долга и дате последней

выплаты нашей фирме. Так как задолженность клиента формируется в результате

неоплаты выполненных заказов, а вся необходимая информация уже содержится в

сущности «заказ», то «дата оплаты» вычисляется как последняя «дата оплаты» из

выполненных для клиента заказов. Наша фирма не принимает частичной оплаты

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

можно

вычислить

как

сумму

стоимости

заказов,

«дата

оплаты»

которых

не

проставлена.

Упражнение 1.8

Составить полную инфологическую модель. Определить идентифицирующие

совокупности атрибутов. Определить тип связей. Назначить имена связей.

Следующим

этапом

будет

нормализация

отношений

и

формирование

реляционной схемы.

Упражнение 1.9

Попробуйте с помощью преподавателя составить реляционную схему и сравните

полученный результат с представленным в приложении.

Все правила, и принципы нормализации подробно рассматривались в главе I и,

ваших знаний достаточно для решения подобной задачи.

26