kyrs_lekcii

Государственное бюджетное образовательное учреждение Астраханской области
среднего профессионального образования «Астраханский колледж вычислительной техники»
Курс лекций за 1 семестр
Учебная дисциплина Базы данных
основной профессиональной образовательной программы по специальности (ей)
Авторы Ю.С. Ветлугина. Ю.С. Демина
(базовый уровень среднего профессионального образования)
Астрахань
2
Оглавление
Раздел 1 Технология проектирования баз данных ........................................................................................................... 3
Лекция 1 Проектирование базы данных как элемент информационной технологии ............................................... 3
Лекция 2 Теоретические основы проектирования БД. ................................................................................................... 4
Лекция 3 Покрытия функциональных зависимостей ..................................................................................................... 7
Лекция 4 Распределенная обработка данных.................................................................................................................. 12
Раздел 2 ПРОЕКТИРОВАНИЕ КОНЦЕПТУАЛЬНОЙ МОДЕЛИ ДАННЫХ .......................................................... 16
Лекция 1 Анализ данных ..................................................................................................................................................... 16
Лекция 2 Нормализация отношений ................................................................................................................................ 17
Лекция 3 Графическое представление.............................................................................................................................. 25
Лекция 4 Иерархическая модель данных ........................................................................................................................ 27
Лекция 5 Логическая модель данных. Отображение на иерархическую модель данных ...................................... 33
Лекция 6 Логическая модель данных. Отображение на сетевую модель данных ................................................... 43
3
Раздел 1 Технология проектирования баз данных
Вопросы:
Проектирование базы данных как элемент информационной технологии;
Теоретические основы проектирования БД;
Синтез БД.
Лекция 1 Проектирование базы данных как элемент информационной технологии
Как видно из материалов предыдущих лекций основу большинства информационных технологий составляют большие массивы накопленной информации. Основной формой организации хранения данных в информационных системах являются базы данных. В курсе “Автоматизированные системы обработки учетной информации” мы рассмотрели основные понятия, связанные с моделями данных, теоретические основы разработки простейших баз данных и жизненный цикл баз данных. Теперь, рассматривая БД как часть информационной технологии, необходимо по новому взглянуть на проблему проектирования базы.
Проблемы проектирования связаны с функциями БД в программно - технологической среде, поддерживающей информационные технологии. В общем случае место БД можно отразить следующей схемой:
Приложения поддержки
информационных
технологий
База
данных
Прочие
приложения
Операционная система
Аппаратная
среда
Поскольку база данных является связующим звеном между пользовательскими приложениями и аппаратными средствами, ее проектирование можно разделить на два направления: проектирование структуры и пользовательских приложений и распределение данных по аппаратным средствам (в случае баз данных на сетях). В
данном разделе мы рассмотрим вопросы проектирования структуры базы данных. В дисциплине АСОЭИ, рассматривая основы реляционной алгебры и разработки реляционных моделей, мы коснулись вопросов проектирования реляционных баз данных. Одной из распространенных технологий разработки БД является следующая:
сбор данных о предметной области;
анализ представлений пользователей;
интеграция представлений пользователей;
разработка сетевой модели;
преобразование сетевой модели в первую нормальную форму реляционной модели;
нормализация отношений путем преобразования их к третьей нормальной форме.
4
В результате получается модель реляционной базы данных, которая представляет собой совокупность
взаимосвязанных отношений.
Построение сетевой модели связано, скорее, с потребностью разработчика графически представить взаимосвязь данных, полученных в результате интеграции представлений пользователей. Преобразование сетевой модели в реляционную дает первую нормальную форму последней. Напомним, что отношение R находится в первой нормальной форме, если значения в dom(A) являются атомарными для каждого атрибута А в R .
Вторая и третья нормальные формы позволяют избежать аномалий при обновлении данных и избавится от
информационной избыточности в отношениях. Напомним, что отношение R нормальной форме, если оно
находится в первой нормальной форме и каждый атрибут, не являющийся ключом, полностью зависит от любого ключа в R. И отношение R находится в третьей нормальной форме, если оно находится во 2НФ и каждый
атрибут, не являющийся первичным ключом, не транзитивно зависит от любого возможного ключа.
Недостатком такого подхода является то, что в моделях, имеющих десятки и сотни атрибутов очень
трудно имперически построить модель, все отношения которой заданы в третьей нормальной форме и связаны
между собой таким образом, что составляют единое целое.
Пример.
А В С
D F G H
G V M N
B M T X
Другим подходом является возможность формального синтеза модели на основании априорно установленных зависимостей между атрибутами. Зависимости между атрибутами устанавливаются на основании смысловой
связи.
Пример.
НОМЕР_ЗАЧЕТКИ - ИМЯ_СТУДЕНТА
НОМЕР_РЕЙСА - ДАТА_ВЫЛЕТА
Безусловно такой подход к разработке модели базы данных предпочтительнее, так как позволяет автоматизировать процесс моделирования. Для реализации этого подхода необходимо расширение теоретической базы,
полученной в курсе АСОЭИ.
Лекция 2 Теоретические основы проектирования БД.
Основные понятия.
Поскольку рассматриваемый подход к разработке реляционной модели базируется на формальной логике,
то в его основе должны лежать некоторые фундаментальные формализации. В теории реляционных баз данных к
ним относятся понятия атрибута, отношения, ключа и функциональной зависимости.
Атрибутом будем называть поименованное свойство объекта и обозначать Аi , где 1  i  n . Домен атрибута Аi обозначим dom(Аi). Тогда отношением R называется конечное множество атрибутов  A1, A2 ,..., An . Ключ
отношения R является подмножеством К =  B1, B 2 ,..., Bm  R со следующим свойством. Для любых двух различных кортежей t1 и t2 в R существует такое B  R , что t1(B)  t2(B). Другими словами , не существует двух
кортежей, имеющих одно и то же значение на всех атрибутах из К . Таким образом, достаточно знать К - значение кортежа, чтобы идентифицировать кортеж однозначно.
5
Пример.
СТУДЕНТ[НОМЕР_ЗАЧЕТКИ,ИМЯ,КУРС,ГРУППА]
Ключи, явно указанные в модели называются выделенными. Могут быть ключи отличные от выделенных и
называемые неявными ключами. Например ИМЯ в предыдущем прмере.
Под функциональной зависимостью атрибутов или F-зависимостью понимают такую связь между атрибутами, когда значения кортежа на одном множестве атрибутов единственным образом определяют эти значения на
другом множестве атрибутов. Так в отношении:
ГРАФИК[ПИЛОТ,РЕЙС,ДАТА,ВРЕМЯ]
ПИЛОТ функционально зависит от {РЕЙС,ДАТА}
F-зависимости принято обозначать {РЕЙС,ДАТА}-> ПИЛОТ и говорят, что РЕЙС и ДАТА функционально
определяют ПИЛОТ.
В терминах теории множеств и реляционной алгебры F-зависимость определяется так. Пусть R отношение
и X, Y подмножества атрибутов в R. Отношение R удовлетворяет функциональной зависимости X -> Y, если
Y(X-x®) имеет не более чем один кортеж для каждого Х - значения х. В F-зависимости X->Y подмножество X
называется левой частью, а Y - правой частью.
Такая интерпретация функциональной зависимости является основой алгоритма SATISFIES, приводимого
ниже.
SATISFIES
Вход: Отншение R и F-зависимость X->Y.
Выход: истина, если R удовлетворяет X->Y, ложь - в противном случае.
SATISFIES(R,X->Y)
Отсортировать отношение R по Х-столбцам так, чтобы собрать кортежи с равными Х-значениями вмести.
Если каждая совокупность кортежей с равными Х-значениями имеет также равные Y-значения, то на выходе
получаем истину, а в противном случае - ложь.
Этот алгоритм проверяет, удовлетворяет ли отношение R F-зависимости X -> Y.
Пример. В результате выполнения алгоритма SATISFIES выясним удовлетворяет ли F-зависимость РЕЙС > ВРЕМЯ_ВЫЛЕТА следующему отношению
ГРАФИК
ПИЛОТ
А...
П...
А...
Р...
П...
С...
П...
С...
РЕЙС
ДАТА
9 авг
11 авг
10 авг
12 авг
8 авг
9 авг
12 авг
15 авг
83
83
116
116
281
281
301
412
ВРЕМЯ_ВЫЛЕТА
10:15
10:15
13:25
13:25
5:50
5:50
18:35
13:25
Однако F-зависимость ВРЕМЯ_ВЫЛЕТА -> РЕЙС согласно этому алгоритму не выполняется для этого отношения
ГРАФИК
ПИЛОТ
РЕЙС
ДАТА
ВРЕМЯ_ВЫЛЕТА
6
П...
С...
А...
П...
А...
Р...
С...
П...
281
281
83
83
116
116
412
301
8 авг
9 авг
9 авг
11 авг
10 авг
12 авг
15 авг
12 авг
5:50
5:50
10:15
10:15
13:25
13:25
13:25
18:35
Для разработки модели базы данных необходимо знать полное множество F-зависимостей. Чтобы найти их,
необходимы семантические знания об исходном отношении R. Поэтому можно считать семейство F-завсимостей
заданным. Обозначим его F. Однако при таком подходе нельзя быть уверенным, что найдены все F-зависимости
отношения R. Для того, чтобы найти все F-зависимости, если известны некоторые из них, можно воспользоваться
аксиомами вывода. Возможность получения новых F-зависимостей с помощью аксиом вывода базируется на следующем правиле. Мнжество F-зависимостей F влечет за собой F-зависимость X -> Y (обозначение: F = X -> Y ), если
каждое отношение удовлетворяющее всем зависимостям в F, удовлетворяет также зависимости X -> Y. Аксиома
вывода - это правило, устанавливающее, что если отношение удовлетворяет определенным F-зависимостям, то оно
должно удовлетворять и некоторым другим F-зависимостям. Существует шесть аксиом вывода:
Рефлексивность: X -> X.
Пополнение: X -> Y влечет за собой XZ -> y.
Аддитивность: X -> Y и X -> Z влечет за собой X -> YZ.
Проективность: X -> YZ влечет за собой X -> Z.
Транзитивность: X -> Y и Y -> Z влечет за собой X -> Z.
Псевдотранзитивность: X -> Y и YZ -> W влечет за собой XZ -> W.
Пример.
Пусть дано отношение R , а X , Y и Z подмножества R . Предположим, что отношению удовлетворяет XY > Z и X -> Y . Согласно аксиоме псевдотранзитивности получим XX -> Z или X -> Z.
Если даны аксиомы рефлексивности, пополнения и псевдотранзитивности, то из них можно вывести все
остальные. Иногда их называют аксиомами Армстронга.
Пусть F-множество F-зависимостей для отношения R . Замыкание F , обозначаемое F+ , - это наименьшее
содержащее F множество, такое что при применении к нему аксиом Армстронга нельзя получить ни одной F - зависимости, не принадлежащей F.
Пример.
Пусть F = {AB -> C, C -> B } - множество F-зависимостей на R(ABC). F+ = {A -> A, AB -> A, AC -> A, ABC
-> A, B -> B, AB -> B, BC -> B, ABC -> B, C -> C, AC -> C, BC -> C, ABC -> C, AB -> AB, ABC -> AB, AC -> AC,
ABC -> AC, BC -> BC, ABC -> BC, ABC -> ABC, AB -> C, AB -> AC, AB -> BC, AB -> ABC, C -> B, C -> BC, AC > B, AC -> AB}
Таким образом, если известно множество F-зависимостей удовлетворяющих отношению R, можно найти все
F- зависимости, удовлетворяющие этому отношению. Говорят, что F = X -> Y ,если
X -> Y  F+ .
Получение замыкания F+ не обязательно для установления
F = X -> Y.
Для этого достаточно воспользоваться алгоритмом MEMBER .
Алгоритм MEMBER.
Вход: Множество F-зависимостей F и F-зависимость X -> Y.
Выход: истина, если F = F = X -> Y, ложь в противном случае.
7
MEMBER(F, X -> Y)
begin
if Y  CLOSURE(X,F) then return (истина)
else return(ложь)
end
Здесь CLOSURE алгоритм, позволяющий выявить список атрибутов входящих в множество F, который
имеет вид.
Алгоритм CLOSURE.
Вход: Множество атрибутов Х и множество F-зависимостей F.
Выход: Замыкание Х над F.
CLOSURE(X,F)
begin
OLDDEP = 0; NEWDEP = X
while NEWDEP  OLDDEP do begin
OLDDEP = NEWDEP
for каждая F- зависимость W -> Z в F do
if NEWDEP  W then
NEWDEP = NEWDEP
Z
end
return(NEWDEP)
end
Пример работы алгоритма MEMBER
Пусть F = {НОМЕР_РЕЙСА ДАТА_ВЫЛЕТА -> КОЛИЧЕСТВО_МЕСТ,
НОМЕР_РЕЙСА -> ПУНКТ_ОТПРАВЛЕНИЯ, НОМЕР_РЕЙСА ДАТА_ВЫЛЕТА -> ПИЛОТ} и необходимо установить F |= НОМЕР_РЕЙСА -> ПИЛОТ
Используем для этого алгоритм MEMBER
Лекция 3 Покрытия функциональных зависимостей
Для формирования БД, как системы взаимосвязанных отношений на основании известных (из семантических соображений) F-зависимостей необходимо иметь способ минимизации первоначального множества Fзависимостей. Это необходимо для минимизации дублирования данных, обеспечения их согласованности и целостности. Теоретической основой для построения такого способа является теория покрытий функциональных
зависимостей.
Определение.
Два множества F-зависимостей F и G над отношением R эквивалентны, F  G , если F+ = G+ . Если
F  G , то F есть покрытие для G. Предполагается, что имеет смысл рассматривать в качестве покрытий такие
множества F, которые не превосходят множество G по числу F-зависимостей.
8
Из этого определения следует, что для установления факта, что множество функциональных зависимостей
F является покрытием G , необходимо определить эквивалентность F и G. Практически это достигается путем
использования следующего алгоритма:
Алгоритм EQUIV
Вход: два множества F- зависимостей F и G.
Выход: истина, если F  G ; ложь в противном случае.
EQUIV(F,G)
begin
v=DERIVES(F,G) and DERIVES(G,F);
return(v)
end
Здесь DERIVES алгоритм проверяет условие F |= G и имеет вид:
Алгоритм DERIVES
Вход: два множества F- зависимостей F и G.
Выход: истина, если F |= G; ложь в противном случае.
DERIVES(F,G)
begin
v= истина
for каждая F-зависимость X -> Y из G do
v = v and MEMBER(F, X -> Y)
end
return(v)
end
Множество F-зависимостей F не избыточно, если у него нет такого собственного подмножества F’ , что
F’  F . Если такое множество F’ существует, то F избыточно. F является не избыточным покрытием G, если F
есть покрытие G и F не избыточно.
Пример. Пусть G = { AB -> C, A -> B, B -> C, A -> C}. Множество F= {AB -> C, A -> B, B -> C} эквивалентно G, но избыточно, потому что F’ = {A -> B, B -> C} также является покрытием G. Множество F’ представляет
собой не избыточное покрытие G.
Действительно, согласно алгоритму EQUIV F  G , так как DERIVES(F,G) дает истину и DERIVES(G,F)
так же истина. То же самое можно сказать относительно F’ и G.
(Подробнее)
Множество F не избыточно, если в нем не существует F-зависимости X -> Y, такой, что F - { X -> Y} |= X > Y . Назовем F-зависимость из F избыточной в F , если F - { X -> Y} |= X -> Y.
Для любого множества F-зависимостей G существует некоторое подмножество F, такое, что F является не
избыточным покрытием G. Если G не избыточно, то F=G. Для определения не избыточного покрытия множества
F- зависимостей G существует алгоритм NONREDUN, который имеет вид:
Вход: множество F-зависимостей G.
Выход: не избыточное покрытие G.
NONREDUN(G)
begin
F=G
9
for каждая зависимость X -> Y из G do
if MEMBER(F-{X->Y],X->Y) then F=F-{X->Y}
end
return(F)
end
Пример: Пусть G= {A -> B, B -> A, B -> C, A -> C}.
Результатом работы алгоритма является множество:
{A -> B, B -> A, A -> C}.
Если бы G было представлено в порядке {A -> B, A -> C, B -> A , B -> C} , то результатом работы алгоритма было бы
{A -> B, B -> A, B -> C}.
Из примера видно, что множество F-зависимостей G может иметь более одного неизбыточного покрытия.
Могут так же существовать неизбыточные покрытия G, не содержащиеся в G. В приведенном примере таким
неизбыточным покрытием будет множество
F = {A -> B, B -> A, AB -> C}.
Если F-неизбыточное множество F-зависимостей, то в нем нет “лишних” зависимостей в том смысле, что
нельзя уменьшить F , удалив некоторые из них. Удаление любой F-зависимости из F приведет к множеству, не
эквивалентному F. Однако размер можно уменьшить, удалив некоторые атрибуты F-зависимостей F.
Определение. Пусть F-множество F-зависимостей над R и X -> Y есть F-зависимость из F. Атрибут А из R
называется посторонним в X -> Y относительно F, если
X  AZ , X  Z и (F - {X -> Y})  {Z -> Y}  F или
Y = AW, Y  W и (F - {X -> Y})  {X -> W}  F.
Иными словами, А - посторонний атрибут, если он может быть удален из правой или левой части X -> Y
без изменения замыкания F.
Пример. Пусть G = {A -> BC,B -> C,AB -> D}. Атрибут С является посторонним в правой части A -> BC, а
атрибут B - в левой части AB -> D.
Определение. Пусть F - множество F-зависимостей над R и X -> Y принадлежит F. F-зависимость X -> Y
называется редуцированной слева, если Х не содержит постороннего атрибута А и редуцированной справа, если
Y не содержит атрибута А , постороннего для X -> y. Зависимость X -> Y называется редуцированной, если она
редуцирована слева и справа и Y   . Редуцированная слева F-зависимость называется также полной Fзависимостью.
Определение. Множество F-зависимостей F называется редуцированным (слева, справа), если каждая Fзависимость из F редуцирована (соответственно слева, справа).
Пример. Множество G = {A -> BC, B -> C, AB -> D} не является редуцированным ни справа, ни слева.
Множество G1 = {A -> BC, B -> C, A -> D} редуцировано слева, но не справа, а G2 = {A -> B, B -> C, AB -> D} редуцировано справа, но не слева. Множество G3 = {A -> B, B -> C, A -> D} редуцировано слева и справа, следовательно, поскольку правые части не пусты, редуцировано.
Для нахождения редуцированных покрытий используется алгоритм:
REDUCE
Вход: множество F-зависимостей G.
Выход: редуцированное покрытие G.
10
REDUCE(G)
begin
F = RIGHTRED(LEFTRED(G))
удалить из F все F-зависимости вида X -> 
return(F)
end
здесь RIGHTRED и LEFTRED алгоритмы редуцирования соответственно справа и слева, которые имеют
вид:
RIGHTRED
Вход: множество F-зависимостей G.
Выход: редуцированное справа покрытие G.
RIGHTRED(G)
begin
F=G
for каждая зависимость X -> Y из G do
for каждый атрибут А из Y do
if MEMBER(F - {X -> Y}  {X ->(Y - A)}, X -> A) then
удалить А из Y в X -> Y из F
end
end
return(F)
end
Алгоритм LEFTRED
Вход: множество F-зависимостей G.
Выход: редуцированное слева покрытие G.
Begin
F=G
for каждая зависимость X -> Y из G do
for каждый атрибут А из Х do
if MEMBER(F,{X - A) -> Y) then
удалить А из X в X -> Y из F
end
end
return(F)
end
Пример. Пусть G’= {A -> C, AB -> DE, AB ->CDI, AC -> J}.Из LEFTRED(G’) получаем G” = {A -> C, AB ->
DE, AB -> CDI, A -> J} и из RIGHTRED(G”) получаем F= {A -> C, AB -> E, AB -> DI, A -> J}, уже редуцированное.
Далее потребуется находить разбиение множества F- зависимостей, заданных на отношении R на подмножества, которые представляют собой классы F- зависимостей с эквивалентной левой частью.
Определение: два множества атрибутов X и Y называются эквивалентными на множестве F- зависимостей
F, если F |= X->Y и F |= Y ->X.
11
Например пусть дано F={A -> BC, B -> A, AD -> E}, найдем все F- зависимости эквивалентные левой части
первой, т.е. А. Левая часть второй F- зависимости (В) эквивалентна А ? Проверим F |= A -> B и F |= B -> A . Это
действительно так. Следовательно А эквивалентно В и первые две F- зависимости можно объединить в один
класс эквивалентности, который обозначается в общем случае ЕА(Х). Множество классов эквивалентности для
заданного множества F- зависимостей обозначается E F . Сокращенным способом записи F- зависимостей с эквивалентными левыми частями является составная функциональная зависимость (CF-зависимость), которая имеет
вид:
(X1, X2, ..., Xk) -> Y
где X1, X2, ..., Xk , множество эквивалентных левых частей F- зависимостей, а Y объединение правых частей
F- зависимостей.
Синтез реляционных баз данных
База данных состоит из множества атрибутов и ключей. С точки зрения теоретико-множественного описания реляционной базой данных d называется такая совокупность отношений {R1, R2, ...,Rp}, в которой каждое отношение имеет вид Ri= (Si,Ki), где Si- множество атрибутов, а Ki - множество атрибутов образующих ключ.
Предположим на входе задано множество F- зависимостей F над R. С их помощью требуется создать базу
данных R=( R1, R2, ...,Rp). Эта БД должна удовлетворять следующим требованиям:
1. множество F полностью характеризуется с помощью R , т.е.
F  {K  Ri | Ri  R
где К – выделенный ключ Ri}
2. Каждое отношение Ri находится в третьей нормальной форме.
3. Не существует базы данных с меньшим числом отношений, удовлетворяющим пунктам 1 и 2.
4. Соединение всех полученных отношений Ri дает исходное отношение R.
Алгоритм порождающий базу данных из заданных F-зависимостей называется алгоритмом синтеза.
Определение. Если R – база данных и на ней задано множество F-зависимостей G, то в ней существует по крайней
мере |EG| отношений. Это означает, что в R столько же отношений, сколько и классов эквивалентности. Из этого
следует следующее.
Пусть F - множество F – зависимостей. Любая база данных должна иметь |EF’| отношений, где F’ неизбыточное
покрытие для F.
Исходя из этого строится способ построения структуры базы данных.
Сначала находится неизбыточное покрытиеF’ для F и в EF’ вычисляем классы эквивалентности. Для каждого EF’(X)
строим отношение, состоящее из всех атрибутов, появляющихся в EF’(X). При этом атрибуты левой части каждого
класса эквивалентности образуют выделенный ключ.
Реализация этого способа позволяет получить алгоритм SYNTHESIZE
Вход: множество F – зависимостей F над R.
Выход: полная схема баз данных для F.
1. Наити для F редуцированное минимальное покрытие G.
2. Для каждой CF – зависимости (X1,X2,…,Xk) Y из G построить отношение Rj= X1X2…XkY с выделенными
ключами K={X1,X2,…Xk).
3. Вернуться к п. 2.
Пример.
12
A
B1B2C1C2DEI1I2I3J
B1B2C1
AC2DEI1I2I3J
B1B2C2
E
AC1DEI1I2I3J
I1I2I3
C1D
J
C2D
J
I1I2
I3
I2I2
I1
I1I3
I2
И пусть R= AB1B2C1C2DEI1I2I3J
Множество минимально, но не редуцировано. Редуцируя F , получим
F’= {A
B1B2C1C2DE
B1B2C1
A
B1B2C2
C1D
J
C2D
J
I1I2
I3
I2I2
I1
E
I1I2
A
I1I3
I2}
Образуя классы эквивалентности имеем
G={ (AB1B2C1 ,B1B2C2)
(E)
DE
I1I2
(C1D)
J
(C2D)
J
(I1I2, I2I2, I1I3)}
Преобразуя каждую CF – в отношения с выделенными ключами, получим
R1=AB1B2C1C2DE K1= {AB1B2C1 ,B1B2C2}
R2= EI1I2
K2={E}
R3= C1DJ
K3={C1D}
R4= C2DJ
K4={C2D}
R5= I1I2I3
K5={ I1I2, I2I2, I1I3}
Окончательная схема БД будет R=( R1, R2, R3, R4 ,R5)
Лекция 4 Распределенная обработка данных
Под распределенной обработкой данных понимается такой способ хранения и обработки данных, когда отдельное приложение может обрабатывать данные,, распределенные на множестве различных баз данных, управление которыми осуществляют различными СУБД, работающие на различных машинах с различными операционными системами, соединенных коммуникационными системами. Распределенная база данных (РБД) является виртуальным объектом, части которого расположены на удаленных базах данных, связанных каналами связи.
Физически РБД состоит из набора узлов, связанных коммуникационной сетью, в которой:

Каждый узел обладает своими собственными системами баз данных;

Узлы работают согласованно, поэтому пользователь может получить доступ к данным на любом узле
сети, как будто все данные находятся на собственном узле.
Каждый узел обладает своими собственными базами данных, собственными локальными пользователями,
собственной СУБД и программным обеспечением для управления транзакциями, а так же собственным диспетчером
передачи данных. Распределенная СУБД может рассматриваться как некий способ совместной работы отдельных
локальных СУБД, расположенных на разных локальных узлах. Причем новый компонент программного обеспече-
13
ния на каждом узле поддерживает все необходимые функции совместной работы. Комбинация этого компонента и
существующей СУБД называется Распределенной Системой Управления Базами Данных (РСУБД).
В основе распределённых баз данных лежат следующие требования:
1. Локальная автономия;
2. Независимость от центрального узла;
3. Непрерывное функционирование;
4. Независимость от расположения;
5. Независимость от фрагментации;
6. Независимость от репликации;
7. Обработка распределённых запросов;
8. Управление распределёнными транзакциями;
9. Независимость от аппаратного обеспечения;
10. Независимость от операционной системы;
11. Независимость от сети;
12. Независимость от СУБД.
Локальная автономия
В распределенной системе узлы следует делать автономными. Локальная автономия означает, что
функционирование любого узла Х не зависит от успешного выполнения операций на некотором узле У . В
противном случае выход из строя узла У может привести к невозможности выполнения операций на узле Х .
Из принципа локальной автономии следует, что владение и управление данными осуществляется локально
вместе с локальным ведением учета. В действительности цель локальной автономии достигается не полностью, поскольку часто узел Х должен представлять некоторую часть управления узлу У , поэтому говорят не
о полной, а о максимально возможной автономии.
Независимость от центрального узла.
Под локальной автономией понимается, что все узлы должны рассматриваться как равные. Следовательно, не должно существовать никакой зависимости и от центрального «основного» узла с некоторым централизованным обслуживанием, например централизованной обработкой запросов, централизованным управлением транзакциями или централизованным присвоением имен. Зависимость от центрального узла нежелательна по двум причинам. Во-первых, центральный узел может быть «узким» местом всей системы, а вовторых, более важно то, что система в целом становится уязвимой, т.е. при повреждении центрального узла
может выйти из строя вся система.
Непрерывное функционирование
Одним из преимуществ распределенных систем является то, что они обеспечивают более высокую
надежность и доступность.
 Надежность (вероятность того, что система выполняет свойственные ей функции в заданный
момент времени) повышается благодаря работе распределенных систем не по принципу «все или
ничего», а в постоянном режиме; т.е. работа системы продолжается , хотя и на более низком
уровне, даже в случае неисправности некоторого отдельного компонента, например узла.
 Доступность (вероятность того, что система исправна и работает в течение некоторого промежутка времени) повышается частично по той же причине, а частично благодаря возможности
репликации данных.
Независимость от расположения
Эта цель предполагает обеспечение такого режима работы с данными, при котором пользователю не
нужно знать, на каком узле находятся требуемые данные. При этом значительно упрощаются пользовательские программы, а также не требуется их изменения при перемещении данных в системе.
14
Независимость от фрагментации
В системе поддерживается фрагментация данных, если некоторое отношение из соображений физического хранения необходимо разделить на части или фрагменты. Фрагментация желательна для повышения
производительности системы, поскольку данные лучше хранить в том месте, где они наиболее часто используются. При такой организации многие операции становятся локальными, а объем передаваемых в сети данных снизится.
Существует два типа фрагментации – горизонтальная и вертикальная, которые связаны с операциями
селекции и проекции соответственно, т.е. горизонтальный фрагмент может быть получен с помощью операции селекции, а вертикальный – проекцией. Реконструкцию исходного отношения на основе его фрагментов
можно осуществить с помощью операций соединения (для вертикальных фрагментов) и объединения (для горизонтальных фрагментов).
В фрагментированной системе необходимо обеспечить поддержку независимости от фрагментации, т.е.
пользователь не должен «ощущать» фрагментацию данных.
Независимость от репликации
В системе поддерживается независимость от репликации, если заданное отношение или фрагмент могут
быть представлены различными копиями (репликами) хранимыми на разных узлах. Репликация полезна по
двум причинам. Во-первых, благодаря ей достигается большая производительность, т.к. приложения могут
работать с локальными копиями , не обмениваясь данными с удаленными узлами. Во-вторых, репликация позволяет обеспечить большую доступность, т.к. реплицированный объект остается доступным для обработки до
тех пор, пока остается хотя бы одна его реплика. Главный недостаток репликации заключается в том, что при
обновлении реплицируемого объекта, все его копии должны синхронизироваться.
В системе, которая поддерживает репликацию данных, должна также поддерживаться независимость от
репликации, т.е. пользователь не должен касаться проблем связанных с созданием и синхронизацией копий.
Обработка распределенных запросов
При обработке в распределенной системе запроса необходимо выработать эффективную стратегию его
реализации. Например, запрос на объединение отношений Rx , расположенного на узле X , и отношения Ry ,
хранимого на узле Y , может быть выполнен с помощью перемещения отношения Rx на узел Y , перемещения
отношения Ry на узел X или перемещения этих двух отношений на третий узел Z и т.д. Это означает, что при
выполнении запроса на распределенной БД необходим его предварительный анализ с последующим выбором
оптимальной стратегии его реализации.
Управление распределенными транзакциями
В распределенной системе выполнение транзакции связано с исполнением программных кодов на нескольких узлах. Транзакция это логическая единица работы, которая включает всю совокупность действий,
необходимых для реализации запроса. Транзакция считается неделимым процессом, т.е. если какое либо из
составляющих действий окажется не выполненным, то вся транзакция считается не выполненной. Каждый
программный код, исполняемый на каком либо узле при выполнении транзакции, называется агентом. Таким
образом, транзакция состоит из нескольких агентов, т.е. процессов реализующих транзакцию.
В процессе управления транзакцией выделяют управление восстановлением и управление параллельной
обработкой. Первое из них базируется на протоколе двухфазной фиксации. В грубом приближении в соответствии с этим протоколом в начале транзакции устанавливается точка фиксации данных, т.е. как бы создается
копия данных, которые предполагается изменить в результате транзакции. Если транзакция завершена нормально, то точка фиксации сохраняется до выполнения следующей транзакции. Если же произошел сбой, то
система возвращает состояние данных в точку фиксации, позволяя не допустить необратимого неправильного
изменения БД. Управление параллельной обработкой предполагает установку блокировок на отношения,
группы записей с целью не допустить изменение данных другим пользователем во время выполнения транзакции.
15
Независимость от аппаратного обеспечения
Используемые в настоящее время компьютеры характеризуются большим разнообразием. В связи с
этим существует необходимость интеграции данных на всех системах и создания для пользователя представления единой системы. Должна иметься возможность запуска одной и той же СУБД на разном аппаратном
обеспечении.
Независимость от операционной системы
Эта цель является следствием предыдущей. Необходимо, чтобы одна и та же СУБД могла работать под
управлением разных ОС.
Независимость от сети
Если система в состоянии поддерживать несколько узлов с разным аппаратным обеспечением и разными операционными системами, то желательно, чтобы в ней поддерживались разные типы сетей.
Независимость от СУБД
Эта цель означает, что желательно, чтобы распределенная БД допускала использование различных
СУБД разными пользователями. Это возможно только если эти СУБД поддерживают некоторый общий стандарт представления данных, например, официальный стандарт языка SQL.
16
Раздел 2 ПРОЕКТИРОВАНИЕ КОНЦЕПТУАЛЬНОЙ МОДЕЛИ ДАННЫХ
Проектирование концептуальной модели основано на анализе решаемых предприятием задач по обработке данных. Концептуальная модель включает описания объектов и их взаимосвязей, представляющих интерес в рассматриваемой предметной области и выявляемых в результате анализа данных. Здесь имеются в виду данные, используемые как в уже разработанных прикладных программах, так и в тех, которые только будут реализованы.
При разработке концептуальной модели может оказаться полезным аппарат реляционного подхода, не зависящий от особенностей реализации. Концептуальная модель предметной области может быть впоследствии отображена на реляционную,
иерархическую или сетевую модель данных.
Концептуальная модель учитывает требования к обрабатываемым данным многих прикладных программ, а не каждой в отдельности. Как уже указывалось в предыдущих главах, представление отдельного прикладного программиста называется внешней моделью. Концептуальная модель не зависит от прикладных программ используемой СУБД, технических средств, на которых базируется система, и от внутренней модели данных, реализуемой в физической памяти.
При проектировании концептуальной модели все усилия разработчика должны быть направлены в основном на структуризацию данных и выявление взаимосвязей между ними без рассмотрения особенностей реализации и вопросов эффективности
обработки [4].
Лекция 1 Анализ данных
1.1. Сбор информации о данных, используемых в существующих прикладных программах
Сбор информации о данных является трудоемкой задачей и требует непременного участия руководства. АБД должен разработать план проведения обследования предприятия. Ему нужно составить списки данных, необходимые работникам всех уровней
управления (исполнительного, функционального и эксплуатационного). Причем на различных уровнях данные могут обрабатываться или накапливаться. Затем АБД предстоит проанализировать все направления использования данных на предприятии.
Сбор данных следует начинать с изучения существующих форм документов, отчетов, имеющихся файлов и программ. Основной вопрос, требующий первоочередного решения – какие именно данные должны быть представлены в новой базе данных.
При этом необходимо учитывать, что подлежащие хранению данные редко однозначно соответствуют данным, отображаемым в
формах и отчетах.
Анализ должен содержать: имя объекта данных, имя элемента данных, описание, атрибуты, источники, уровни конфиденциальности, показатели важности, а также взаимосвязи между элементами и между объектами.
1. Имя и описание объекта данных. Указываются основное имя и синонимы. Примеры: «Счета», «Журнал регистрации продукции», «Форма учета счетов». Дается вербальное описание смыслового содержания имени, даже если его смысл представляется очевидным. В общих чертах описывается функциональное назначение и использование объекта в функциональных и структурных подразделениях предприятия, а также за их пределами.
2. Элементы данных. Для каждого элементарного данного, входящего в конкретный объект, указывается:
1) его имя и описание. Перечисляются имена, синонимы и дается их расшифровка. Приводится полное вербальное описание
элемента;
2) источник. Перечисляются источники элемента в структуре предприятия, например заказчик, внутренние документы, отдел сбыта;
3) атрибуты. Указываются тип значения атрибута (числовой, алфавитный, текстовый), единицы измерения (доллары, рубли),
а при необходимости и допустимые диапазоны значений (например, от 100 до 500);
4) использование элемента данных. Примеры «Содержит сведения об адресе», «Используется для определения количества»,
«Используется в шкале платежей»;
5) ограничения безопасности/чувствительности. Перечисляются связанные с данным элементом ограничения, включая допущенных к нему лиц и разрешенный им вид обработки, например доступ, чтение и/или выдача;
6) степень важности. Указывается степень важности данного элемента. Она должна определяться значением элемента данных для реализации или расширения функций предприятия. Следует избегать негативных формулировок типа «Без этого элемента данных невозможно выполнить то-то» Рекомендуется приводить аргументы, основываясь на использовании элемента данных
(пункт 4);
7) взаимосвязи элемента данных. Описываются способы совместного использования данного элемента с другими, не обязательно принадлежащими рассматриваемому объекту. Примеры взаимосвязей: номер детали – наименование, код операции –
трудозатраты, номер заказа – номер поставки.
3. Продолжительность хранения и условия перевода в архив. Указывается период времени, в течение которого должны
храниться значения элемента данных, и способ хранения. По возможности также указывается основание для хранения (правительственные распоряжения, указания администрации предприятия).
АБД должен исследовать информационные потоки. Целью такого исследования является разработка модели предприятия. В
результате АБД получает представление о документообороте предприятия, определяет пути и способы передачи данных.
Следующий и, вероятно, наиболее важный этап – анализ организации хранения данных. АБД разрабатывает графическую
схему объектов и элементов данных, на которой указываются исходные данные, формирующие их подразделения или виды дея-
17
тельности, результирующие данные и использующие их подразделения (рис 1).
Рис. 1
Выявленный документооборот отражается на специальных схемах. Простейшая схема данных показывает их движение от
источника к конечному пользователю. В процессе разработки схемы данных АБД неизбежно встретится с противоречиями,
ошибками и неточностями в исходных описаниях, которые он обязан обнаружить и устранить. Удобным средством при анализе
данных может оказаться словарь данных.
АБД уточняет степень важности отдельных данных для конечного пользователя, сопоставляя выдвигаемые пользователем
требования к объектам и элементам с реально существующими.
1.2. Сбор информации о данных для перспективных приложений
Сбор информации для планирования перспективного использования базы данных – одна из наиболее важных и сложных задач АБД. Обычно после ввода базы данных в эксплуатацию пользователи, оценив на практике ее значение для принятия решений
и обработки информации, предъявляют более высокие требования к составу реализуемых функций, вносят предложения по введению новых перекрестных ссылок и улучшению операционных характеристик системы. Если основу проектирования составляют только текущие требования к базе данных, то это может затруднить реализацию новых. Для того чтобы подобные проблемы в
будущем не возникали, АБД должен заранее учитывать возможные пути использования информации. Информация о вероятных
путях перспективного использования данных не только необходима для проектирования концептуальной и логической модели,
но может оказать определенное влияние на выбор способа физической реализации базы данных. Выбор физической модели в
особенности зависит от оценок будущих объемов информации.
Лекция 2 Нормализация отношений
В процессе нормализации элементы данных группируются в таблицы, представляющие объекты и их взаимосвязи. Теория
нормализации основана на том, что определенный набор отношений обладает лучшими свойствами при включении, модификации и удалении данных, чем все остальные наборы отношений, с помощью которых могут быть представлены те же данные.
Введение нормализации отношений при разработке концептуальной модели обеспечивает ее работоспособность. Это вовсе
не означает, что ненормализованная концептуальная модель обязательно окажется неработоспособной. Однако ненормализованная модель может вызвать определенные трудности реализации прикладных программ, модифицирующих базу данных. Обнаружив отклонения от нормализованной схемы, АБД должен решить, насколько эти отклонения ухудшают характеристики базы
данных при модификации.
Ненормализованная модель данных включает записи в том виде, в котором они используются прикладными программами.
Первый шаг при нормализации заключается в образовании двумерной таблицы, содержащей элементы данных. Для этого практически нужно лишь исключить повторяющиеся группы. Например, если в декларацию заносится имя сотрудника, его идентификационный номер, имя его супруги и имена его детей (предполагается не более десяти), то сведения о нем могут быть представлены с помощью таблицы, состоящей из десяти строк и четырех столбцов. В каждой строке записывается имя сотрудника, его
номер, имя супруги и имя одного из детей. Таким образом, в десяти строках таблицы будут находиться имена всех десяти детей.
Исключение повторяющихся групп является предварительным этапом нормализации, после чего можно перейти к получению
второй нормальной формы.
Второй шаг нормализации состоит в том, чтобы выделить ключи и зависящие от них атрибуты. Каждый кортеж отношения,
находящегося в первой нормальной форме, полностью зависит от совокупности ключевых атрибутов. Для того чтобы привести
отношение ко второй нормальной форме, нужно выделить группы атрибутов, зависящие от частей составного ключа. Эти группы
18
могут образовать отдельные отношения (таблицы). Выделение из отношения, находящегося в первой нормальной форме, таких
отношений, в которых неключевые атрибуты зависят только от ключа в целом, называется приведением ко второй нормальной
форме.
На третьем шаге нормализации следует выделить из отношений, находящихся во второй нормальной форме, те атрибуты,
которые, хотя и зависят от ключа какого-либо отношения, тем не менее могут существовать в базе данных независимо от остальных атрибутов этого отношения. Выделение атрибутов позволяет вводить их значения вне зависимости от взаимосвязей, в которых они участвуют.
В любой модели данных для представления объектов и их взаимосвязей необходимо некоторым образом сгруппировать
элементы данных. При обработке групп элементов возникают три общих проблемы. Устранение этих проблем требует приведения отношений к одной из трех нормальных форм. Таким образом, процесс нормализации, выполняемой по определенным правилам, состоит в группировке элементов данных в ряде отношений. Различия между тремя нормальными формами поясняются
рис. 2.
Рис. 2
Каждое отношение в первой нормальной форме является особым случаем ненормализованного отношения. Но каждое ненормализованное отношение не находится в первой нормальной форме. Каждое отношение во второй нормальной форме – особый случай отношения в первой нормальной форме, но не наоборот. Отношения в третьей нормальной форме – особый случай
отношений второй нормальной формы.
Все нормализованные отношения находятся в первой нормальной форме. Ряд отношений первой нормальной формы находится во второй нормальной форме и, наконец, некоторые из отношений второй нормальной формы находятся в третьей нормальной форме. Цель процесса нормализации – приведение отношений к третьей нормальной форме.
Отношения в третьей нормальной форме представляют объекты и взаимосвязи между объектами рассматриваемой предметной области.
Приведение отношений к первой, второй и третьей нормальной форме последовательно устраняет аномалии при включении, удалении и модификации записей соответствующей базы данных.
Выше мы рассмотрели в общих чертах, каким образом ненормализованные отношения приводятся к третьей нормальной
форме. Теперь перейдем к более подробному изучению процесса нормализации.
Обратимся к примеру, приведенному на табл. 1. Элементами данных или атрибутами здесь являются «Номер пациента»,
«Имя пациента», «Адрес пациента», «Номер патента хирурга», «Имя хирурга», «Дата операции», «Операция», «Препарат, назначенный после операции», и «Побочный эффект» от применения препарата. В процессе обсуждения будут поясняться допущения
и ограничения, принятые в рассматриваемой упрощенной информационной системе госпиталя.
Таблица 1 – ГОСПИТАЛЬ
Номер
Номер
Дата опе- Имя па- Адрес пациента Имя
Операция
Препарат,
назна- Побочный
пациента патента
рации
циента
хирурга
ченный после опе- эффект
хирурга
рации
1111
145
01.01.77
Джон
15 Нью стрит, Бет Литл Удаление кам- Пенициллин
Сыпь
Уайт
Нью-Йорк, Н -И
ней из желчного
пузыря
1111
311
12.06.77
Джон
15 Нью стрит, Майкл
Удаление кам- –
–
Уайт
Нью-Йорк, Н -И Даймонд ней из почек
19
1234
243
05.04.76
1234
467
10.05.77
2345
189
08.01.78
4876
145
05.11.77
5123
145
10.05.77
6845
243
05.04.76
6845
243
15.12.76
Мэри
Джонс
Мэри
Джонс
10 Мэйн стрит, Чарльз
Удаление ката- Тетрациклин
Рай, Н-И
Филд
ракты
10 Мэйн стрит, Патри- ция Удаление тром- –
Рай, Н-И
Голд»
ба
Чарльз
Догвуд
Лэйн,
Браун
Харисон, Н -И
Хол Кейн 55 Бостон Пост
роуд,
Честер,
Конн
Пол Ко- Блайнд
Брук
шер
Мамаронек, Н И
Энн
Хилтон
род,
Худ
Ларчмонт, Н -И
Энн Худ Хилтон
роуд,
Ларчмонт, Н -И
Лихорадка
–
Дэвид
Розен
Бет Литл
Операция
на Цефалдспорин
открытом сердце
Удаление желч- Демициллин
ного пузыря
–
Бет
Литл
Чарльз
Филд
Чарльз
Филд
Удаление кам- –
ней из желчного
пузыря
Замещение
ро- Тетрациклин
говицы глаза
Удаление ката- –
ракты
–
–
Лихорадка
–
Столбец (или несколько столбцов) называется возможным ключом, если его значения однозначно определяют строки таблицы. Например, строка таблицы однозначно определяется номером пациента, номером патента хирурга и датой операции. Поскольку это единственный возможный ключ, он является первичным.
Первая нормальная форма. Отношение, находящееся в первой нормальной форме, представляет собой таблицу. На пересечении столбца и строки может быть только одно значение. Существование групп значений на пересечении строк и столбцов не
допускается.
Рассмотрим ненормализованное отношение, показанное на табл. 2. На пересечении строк и столбцов имеется более одного
значения. Это свидетельствует о том, что значения первичного ключа неоднозначно определяют неключевые атрибуты.
Таблица 2 - НЕНОРМАЛИЗОВАННОЕ ПРЕДСТАВЛЕНИЕ
Номер
Номер
Дата опе- Имя па- Адрес пациента Имя хипациента патента
рации
циента
рурга
хирурга
1111
145
01.01.77 Джон
15 Нью стрит, Бет Литл
311
12.06.77 Уайт
Нью-Йорк, Н -И Майкл
Даймонд
1234
243
467
05.04.76
10.05.77
2345
189
08.01.78
4876
145
05.11.77
5123
145
10.05.77
6845
243
05.04.76
15.12.76
Мэри
Джонс
10 Мэйн стрит, Чарльз
Рай, Н-И
Филд
Патр.
Голд
Чарльз
Догвуд
Лэйн, Дэвид
Браун
Харисон, Н-И
Розен
Хол Кейн 55 Бостон Пост Бет Литл
роуд,
Честер,
Конн
Пол Ко- Блайнд
Брук, Бет
шер
Мамаронек, Н - Литл
И.
Энн
Хилтон
роуд, Чарльз
Худ
Ларчмонт, Н -И Филд
Операция
Препарат,
назна- Побочный
ченный после опе- эффект
рации
Удаление камней Пенициллин
Сыпь
из
желчного
пузыря
Удаление камней
из почек
Удаление ката- Тетрациклин
Лихорадка
ракты
Удаление тромба
Операция
на Цефалдепорин
открытом сердце
Удаление желч- Демициллин
ного пузыря
–
Удаление камней –
из
желчного
пузыря
Замещение
рого- Тетрациклин
вицы глаза
Удаление катаракты
–
–
Лихорадка
На пересечении некоторых столбцов и строк находится более одного значения. Выявить первичный ключ непросто. Допустим, что первичным ключом является «номер пациента». Определенному значению первичного ключа соответствует несколько
столбцов, например для номера пациента 1111 имеется несколько значений на пересечении с номером патента хирурга (145 и
311), датой операции (01.01.77 и 12.06.77) и т.д. Это означает, что здесь значения неключевых атрибутов не могут быть однозначно определены по значению первичного ключа.
Нормализуем данное отношение (табл. 3). С этой целью продублируем значения атрибутов «Номер пациента», «Имя пациента» и «Адрес пациента», а в одном случае – «Номер патента хирурга» и «Имя хирурга». Отношение на табл. 5.3 находится в
20
первой нормальной форме. На пересечении строк и столбцов теперь имеется только по одному значению. Рис 3 представляет это
отношение в виде диаграммы.
Таблица 3 - ПЕРВАЯ НОРМАЛЬНАЯ ФОРМА
Номер
пациента
Дата опе- Имя па- Адрес пациента
рации
циента
1111
Номер
патента
хирурга
145
Имя
рурга
хи- Операция
01.01.77
Джон
Уайт
15 Нью стрит, Бет Литл
Нью Йорк, Н -И
1111
311
12.06.77
Джон
Уайт
15 Нью стрит, Майкл
Нью Йорк, Н И Даймонд
Препарат,
назна- Побочный
ченный после опе- эффект
рации
Удаление кам- Пенициллин
Сыпь
ней из желчного
пузыря
Удаление кам- –
–
ней из почек
1234
243
05.04.76
Мэри
Джонс
10 Мэйн стрит, Чарльз
Рай, Н И
Филд
Удаление
ракты
1234
467
10.05.77
Мэри
Джонс
10 Мэйн стрит, Патриция
Рай, Н И
Голд
Удаление тром- –
ба
–
2345
189
08.01.78
Чарльз
Браун
Догвуд
Лэйн, Дэвид
Харисон, Н И
Розен
Операция
на Цефалдспорин
открытом сердце
–
4876
145
05.11.77
Удаление желч- Демициллин
ного пузыря
–
5123
145
10.05.77
Хол Кейн 55 Бостон Пост Бет Литл
роуд.
Честер,
Конн
Пол Ко- Блайнд
Брук, Бет Литл
шер
Мамаронек, Н И
–
6845
243
05.04.76
Энн Худ
Хилтон
роуд, Чарльз
Ларчмонт, Н И Филд
Удаление кам- –
ней из желчного
пузыря
Замещение ро- Тетрациклин
говицы глаза
6845
243
15.12.76
Энн Худ
Хилтон
роуд, Чарльз
Ларчмонт, Н И Филд
Удаление
ракты
–
ката- Тетрациклин
ката- –
Лихорадка
Лихорадка
21
Рис. 3
Отношение в третьей нормальной форме. Если заданы номер пациента, номер патента хирурга и дата операции, можно
найти все значения атрибутов, расположенные по периметру. Чтобы выяснить побочный эффект от применения препарата при
заданном номере пациента, номере патента хирурга и дате операции, необходимо сначала установить, какой препарат был назначен после операции, а затем уже определить, какой побочный эффект имело его применение.
Если значения, которые принимают атрибуты «Номер пациента», «Номер патента хирурга» и «Дата операции», известны, то
одновременно известны и значения атрибутов «Имя пациента», «Адрес пациента», «Имя хирурга», «Операция», «Препарат,
назначенный после операции» и «Побочный эффект» от его применения. Таким образом, в состав первичного ключа войдут атрибуты «Номер пациента», «Номер патента хирурга» и «Дата операции». Других возможных ключей данного отношения нет. Все
неключевые атрибуты находятся в функциональной зависимости от первичного ключа. Следовательно, значения первичного
ключа однозначно определяют значения неключевых атрибутов.
Аномалии включения, обновления и удаления отношений в первой нормальной форме. Запоминание экземпляров отношения,
которое находится в первой форме, связано со следующими аномалиями (табл. 3).
Аномалия включения (тип 1). Вполне возможно, что вновь поступивший пациент никогда раньше не подвергался операциям
и не приписан еще ни к одному из хирургов. Поэтому кортеж, в котором находятся сведения о новом пациенте, не может быть
введен в базу данных.
Предположим, что нам необходимо ввести сведения об имени и адресе пациента. При этом вовсе не нужно знать номер патента хирурга и дату операции. Это означает, что два компонента первичного ключа – «Номер патента хирурга» и «Дата операции» – для однозначной идентификации имени пациента и его адреса необязательны. Данную аномалию включения можно
устранить, если выделить в отдельное отношение атрибуты «Номер пациента», «Имя пациента» и «Адрес пациента» (табл. 4).
Таблица 4 - ПАЦИЕНТ
Номер
Имя
…
…
Адрес
…
Отношение во второй нормальной форме. Первичным ключом является «Номер пациента». Неключевые атрибуты «Имя пациента» и «Адрес пациента». Для их однозначной идентификации требуется весь первичный ключ. Имя пациента и его адрес
содержатся только в этом отношении.
Аномалия включения (тип 2). Допустим, в госпиталь приходит новый хирург, который еще не сделал ни одной операции.
Следовательно, в кортеже, содержащем сведения об этом хирурге, не будет ни значения имени пациента, ни его номера, ни даты
операции. «Номер патента хирурга» – это только часть первичного ключа, в который еще входит «Номер пациента» и «Дата операции». В результате ввести новый кортеж, т. е. запомнить информацию о хирурге, невозможно. В данном случае неключевой
атрибут «Имя хирурга» однозначно определяется составным первичным ключом: «Номер пациента»+ «Номер патента хирурга» +
<Дата операции». Однако для однозначной идентификации имени хирурга достаточно только части первичного ключа – атрибута
«Номер патента хирурга». Если выделить «Имя хирурга» и «Номер патента хирурга» в отдельное отношение, как это показано на
табл. 5, рассмотренная аномалия включения будет устранена.
Таблица 5 - ХИРУРГ
22
Номер патента …
Имя
…
Отношение во второй нормальной форме. Первичным ключом служит «Номер патента хирурга». Для однозначной идентификации неключевого атрибута (имени хирурга) требуется весь первичный ключ. Имя хирурга содержится только в этом отношении.
Аномалии включения связаны с тем, что в то время как составной первичный ключ однозначно определяет весь кортеж, отдельные столбцы (домены) зависят только от части этого ключа.
Аномалия обновления. Если Джон Уайт поступает в госпиталь в третий раз, и между вторым и третьим поступлением он
изменил место жительства, необходимо изменить значение его адреса во всех кортежах, содержащих сведения о нем. (Из соображений обеспечения непротиворечивости хранимых данных желательно, чтобы в базе данных содержались только самые последние сведения об именах и адресах пациентов. Предполагается, что устаревшие сведения в системе госпиталя не требуются)
Этот пример показывает, что изменять значения атрибутов отношения, находящегося в первой нормальной форме, не так просто,
поскольку число кортежей, в которые необходимо внести изменения, меняется со временем. Хуже всего, если в результате внесения изменений в одних кортежах будет храниться старое значение адреса пациента, а в других – новое.
Рассмотренная аномалия устраняется, если значение адреса пациента хранится только один раз. Этого можно достичь, выделив имя, адрес и номер пациента в отдельное отношение.
Аномалия удаления (тип 1). Предположим, что после смерти пациента сведения о нем уничтожаются. Так, если пациент
Чарльз Браун скончался (табл. 3), то кортеж, в котором содержатся сведения о нем, удаляется. Однако одновременно уничтожается информация и о хирурге Давиде Розене, так как единственным пациентом, которого он оперировал, был умерший. В ряде
приложений потеря информации такого рода может иметь серьезные последствия. Поскольку удаленный кортеж мог быть единственным источником информации о Давиде Розене, мы рискуем потерять все сведения об этом хирурге. Во избежание подобных потерь пользователь должен позаботиться о том, чтобы осуществлялась проверка, не является ли удаляемый кортеж единственным источником информации о хирурге.
Один из способов решения проблем этого типа состоит в разделении информации, т. е. сведения о хирурге не должны зависеть от сведений о пациенте и наоборот Если, как это показано на табл. 4 и 5, ввести два отношения – ПАЦИЕНТ и ХИРУРГ,
рассмотренная аномалия будет устранена.
Аномалия удаления (тип 2). В том случае, когда между неключевыми атрибутами одного отношения существует функциональная зависимость, возникают аномалии другого типа. Побочный эффект от применения препарата функционально зависит
только от конкретного препарата, назначенного после операции. Возможно, что сыпь, появившаяся у Джона Уайта под воздействием пенициллина, окажется настолько серьезной, что ему будут назначены иные лекарства. Тогда значения атрибутов в соответствующем кортеже придется изменить и ввести наименование нового препарата, а может быть и новый побочный эффект от
его применения. В результате такого изменения информация о том, что у данного пациента инъекции пенициллина вызвали сыпь,
теряется. Это, конечно, нежелательно, поскольку рассматриваемый кортеж может быть единственным источником сведений
подобного рода.
Если выделить сведения о пациентах в отношение ПАЦИЕНТ, а сведения о хирургах – в отношение ХИРУРГ, как это показано на табл. 4 и 5, то эти аномалии будут устранены. Первичным ключом отношения ПАЦИЕНТ является номер пациента, а
отношения ХИРУРГ – номер патента хирурга. Оставшиеся атрибуты образуют отношение ПАЦИЕНТ-И-ХИРУРГ (табл. 6), в
котором первичный ключ составлен из атрибутов «Номер пациента», «Номер патента хирурга» и «Дата операции».
Таблица 6 - ПАЦИЕНТ И ХИРУРГ
Номер паци- Номер па- Дата опера- Операция
ента
тента хирур- ции
га
…
…
…
…
Препарат
Побочный
назначенэффект
ный после
операции
…
…
Отношение во второй нормальной форме. Первичным ключом служит «Номер пациента»+ «Номер патента хирурга»+ «Дата
операции». Для однозначной идентификации каждого неключевого атрибута («Операция», «Препарат, назначенный после операции», «Побочный эффект») требуется полный первичный ключ.
Отношения, показанные на табл. 4, 5 и 6, находятся во второй нормальной форме. Информацию, содержащуюся в одном отношении первой нормальной формы (табл. 3) предпочтительнее представлять с помощью трех отношений, находящихся во второй нормальной форме, так как при этом удается устранить ряд аномалий включения, обновления и удаления, присущих первой
23
нормальной форме. На рис. 4 три отношения, находящиеся во второй нормальной форме, изображены в виде диаграммы.
Рис. 4
Три отношения во второй нормальной форме. Первичным ключом отношения ПАЦИЕНТ является «Номер пациента», первичным ключом отношения
ХИРУРГ – «Номер патента хирурга». Первичный ключ отношения ОПЕРАЦИЯ – «Номер пациента»+ «Номер патента хирурга»+ «Дата операции».
Отношение во второй нормальной форме. Отношение находится во второй нормальной форме, если все неключевые атрибуты полностью функционально зависят от первичного ключа, или, другими словами, для однозначной идентификации каждого
неключевого атрибута требуется весь первичный ключ. Соответственно, отношение не находится во второй нормальной форме,
если существуют неключевые атрибуты, не имеющие полной функциональной зависимости от первичного ключа.
Всякое отношение во второй нормальной форме одновременно является и отношением в первой нормальной форме.
Аномалии включения, обновления и удаления отношений, находящихся во второй нормальной форме. На табл. 4, 5, 6 представлены три отношения во второй нормальной форме. После того, как отношение, находящееся в первой нормальной форме
(оно показано на табл. 3), привели ко второй нормальной форме, ряд аномалий удалось устранить.
Включение (тип 1). Теперь можно ввести сведения о пациенте, который ни разу не подвергался операции в данном госпитале и который не приписан ни к одному хирургу. Информация вводится в отношение, показанное на табл. 4.
Включение (тип 2). Вводя новый кортеж в отношение, показанное на табл. 5, можно запомнить сведения о новом хирурге,
еще не выполнившем ни одной операции в данном госпитале.
Удаление (тип 1). После смерти Чарльза Брауна могут быть удалены соответствующие кортежи из отношений, представленных на табл. 4 и 5. Информация о хирурге Дэвиде Розене по-прежнему хранится в отношении, показанном в табл. 5.
Обновление. Если Джон Уайт поступает в госпиталь в третий раз и его адрес в промежутке между вторым и третьим поступлениями изменился, то сведения о его адресе будут изменены только в отношении, показанном на табл. 4. Изменения не
затронут отношение, показанное на табл. 5. Однако еще не все аномалии устранены.
Аномалия включения. До тех пор, пока конкретный препарат не назначен какому-либо пациенту, сведения о побочном эффекте, вызываемом его применением, ввести невозможно. Так, нельзя ввести новый кортеж в отношение на табл. 6 до тех пор,
пока пациента не прооперируют и не назначат ему препарат.
Аномалия удаления. По-прежнему имеется аномалия удаления, связанная с функциональной зависимостью одного неключевого атрибута отношения от другого. Если в результате инъекций пенициллина у Джона Уайта возникла серьезная сыпь, и после
24
этого ему был назначен другой препарат, то при изменении атрибутов «Препарат, назначенный после операции» и «Побочный
эффект» сведения о том, что применение пенициллина вызывает сыпь, будут потеряны. Поскольку рассматриваемый кортеж
является единственным источником такой информации, потеря ее нежелательна.
Аномалия обновления. Побочный эффект от применения препарата появляется в отношении, показанном на табл. 6, в нескольких кортежах. Если изготовитель конкретного препарата изменит его формулу, то изменится и побочный эффект При этом
возникает альтернатива: либо полностью просматривать отношение, показанное на табл. 6 и изменять значение атрибута «Побочный эффект» всякий раз, когда назначается данный препарат, либо идти на нарушение непротиворечивости данных, когда в
некоторых кортежах побочный эффект будет изменен, а в некоторых – нет (это – чисто иллюстративный пример). Аномалии
включения, удаления и обновления связаны в этом случае с тем, что неключевой атрибут «Побочный эффект» зависит от другого
неключевого атрибута – «Препарат, назначенный после операции». Зависимость такого рода называется транзитивной (рис 5).
Рис. 5
Указанные проблемы удается разрешить, если разбить отношение, показанное на рис. 6, на два отношения (табл. 7 и 8).
Таблица 7 - ПЕРВОЕ ОТНОШЕНИЕ
Номер пациен- Номер патента Дата операции Операция
та
хирурга
…
…
…
…
Препарат,
назначенный
после операции
…
Таблица 8 - ВТОРОЕ ОТНОШЕНИЕ
Препарат,
Побочный
назначенный
эффект
после операции
…
…
Необходимо отметить, что приведение отношений, находящихся во второй нормальной форме, к третьей нормальной форме
происходит точно так же, как переход от первой нормальной формы ко второй, только в первом случае рассматриваются неключевые атрибуты. При приведении отношений в первой нормальной форме ко второй нормальной форме исследуются зависимости неключевых атрибутов от ключевых. Если же отношение во второй нормальной форме приводится к третьей нормальной
форме, рассматриваются взаимосвязи между неключевыми атрибутами.
Отношение в третьей нормальной форме. Считается, что отношение находится в третьей нормальной форме, если устранена функциональная транзитивная зависимость между неключевыми атрибутами. (Когда один неключевой атрибут может быть
специфицирован одним или несколькими другими неключевыми атрибутами, то говорят о наличии транзитивной функциональной зависимости. Побочный эффект определяется назначенным препаратом, поэтому между ними имеется транзитивная функциональная зависимость.) Соответственно если имеются неключевые атрибуты, между которыми существует функциональная зависимость, то отношение не находится в третьей нормальной форме.
В результате разделения отношения, представленного на табл. 5.6, на два новых отношения, удается устранить аномалии.
Включение. Теперь можно ввести сведения о конкретном препарате и побочном эффекте, который вызывает его применение, вне зависимости от того, был ли назначен данный препарат пациенту.
Удаление. Если Джону Уайту после появления сыпи в результате инъекций пенициллина назначается другой препарат, то
факт, что применение пенициллина вызывает появление сыпи, может быть отражен в отношении, показанном на табл. 8.
Обновление. Побочный эффект от применения препарата запоминается в отношении, приведенном на табл. 8, только один
раз.
Важно отметить, что преобразование отношения, находящегося в первой нормальной форме, в ряд отношений, находящихся в третьей нормальной форме, не приводит к потере информации. Другими словами, вся информация, которая может быть
получена из исходного отношения (табл. 3), может быть получена и из отношений, которые показаны на табл. 4, 5 и 7, 8. Кроме
того, необходимо указать, что процесс нормализации отношений базируется на анализе взаимосвязей между типами атрибутов и
25
никак не связан с возможными значениями их экземпляров.
При проведении нормализации отношений разработчик базы данных должен четко представлять себе семантику данных,
используемых в соответствующей предметной области. В зависимости от того, как будет задана структура функциональных
зависимостей между атрибутами, изменится и схема отношений, находящихся в третьей нормальной форме, получаемая после
нормализации (рис. 6).
Рис. 6
В результате нормализации мы получили четыре отношения, находящиеся в третьей нормальной форме. Они представляют именно те объекты и их взаимосвязи, которые соответствуют нашему представлению о рассматриваемой предметной области: ПАЦИЕНТ, ХИРУРГ, ОПЕРАЦИЯ и ПРЕПАРАТ. Эти отношения и составляют концептуальную модель
предметной области.
Лекция 3 Графическое представление
Каждый студент университета слушает несколько курсов. В свою очередь каждый курс лекций посещает ряд студентов. Сведений только о курсах и студентах явно недостаточно, поскольку неясно, какая оценка получена конкретным студентом по данному курсу. С другой стороны, сведений только о курсах и об оценках также недостаточно. Необходимо знать, какие оценки получены каждым из студентов по каждому прослушанному им курсу (рис. 7).
Рис. 7
Взаимосвязи между СТУДЕНТОМ, КУРСОМ и ОЦЕНКОЙ. Данный студент может изучать несколько курсов. Данный курс могут изучать несколько студентов. Оценка показывает степень усвоения курса студентом.
На рис. 8 представлена концептуальная модель предметной области, взаимосвязи между объектами которой изображены на
рис. 7 и могут интерпретироваться следующим образом: каждый студент может посещать несколько курсов;
• по каждому курсу могут заниматься несколько студентов;
26
• каждая конкретная оценка может и должна быть выставлена только одному студенту и только по одному курсу;
• двойная стрелка, связывающая студентов и оценки, отражает тот факт, что студент может иметь нуль, одну или несколько оценок в зависимости от числа курсов, которые он прослушал. Двойная стрелка обозначает взаимосвязь типа «ко
многим». Мы воспользуемся здесь схематическим представлением концептуальной модели. Рассмотрим, как выявляются
объекты, взаимосвязи между элементами данных, отражающими свойства объектов и взаимосвязи между самими объектами.
Рис. 8
Концептуальные требования основаны на следующих предположениях:
1. Студенту соответствует один идентификационный номер.
2. Идентификационный номер студента однозначно определяет его имя и статус, главный и второстепенный предметы
и куратора.
3. Курс с одним и тем же номером может быть прочитан в течение различных семестров и в различных университетских городках. При чтении курса его название может меняться. Преподаватели, ведущие курс, от семестра к семестру могут меняться. Точно так же могут меняться университетский городок, аудитория и период, в течение которого читается данный курс.
4. В данный семестр определенный курс читает конкретный преподаватель. Занятия проводятся в конкретных университетском городке и аудитории. Зафиксирована также продолжительность курса и число зачетов, которые будут приняты по
этому курсу.
5. Студент вправе определить, сколько он собирается сдавать зачетов по данному курсу в данном семестре. Слушатели, т. е. студенты, не сдающие экзамены по данному курсу, сдают по нему и меньше зачетов.
Все эти предположения должны быть отражены в нашей концептуальной модели.
Эти отношения после нормализации могут быть представлены следующим образом:
1. СЕМЕСТР – ДНАЧСЕМ, ДКОНСЕМ.
2. НОМ-СТУДЕНТА – ИМЯ-СТУДЕНТА, СТАТУС, ГЛАВНЫЙ, ВТОРОСТЕПЕННЫЙ, КУРАТОР.
3. СЕМЕСТР*НОМ-КУРСА – НАЗВ-КУРСА, ИМЯ-ПРЕП, ГОРОДОК, ДЕНЬ-ВРЕМЯ, ЗДАНИЕ-НОМ-АУДИТОРИИ.
4. СЕМЕСТР*НОМ-КУРСА*НОМ-СТУДЕНТА – ЗАЧЕТЫ.
Тогда имеем следующее:
1. Каждое отношение, первичный ключ которого содержит один элемент данных, представляет объект. Отношения 1
и 2 представляют объекты СЕМЕСТР и СТУДЕНТ. Объекты .такого типа размещаются на первом уровне (рис. 5.9).
Внутри прямоугольников перечисляются имена элементов данных. Первичные ключи объектов подчеркиваются. Если
прямоугольник не содержит всех элементов данных, представляющих свойства объекта, то пропуски обозначаются тремя
дефисами (---).
2. Отношения, в первичные ключи которых входят два элемента, являющиеся первичными ключами отношений,
представляют взаимосвязи между этими объектами. Если же один из ключевых элементов не является ключом одного из
отношений, то генерируется новое отношение, представляющее объект. Например, составной ключ отношения 3 представляет взаимосвязь между объектами СЕМЕСТР и КУРС. Элемент НОМ-КУРСА не является первичным ключом ни
одного из отношений. Образуется новое отношение КУРС, представляющее соответствующий объект; оно изображается
прямоугольником на уровне 1. Взаимосвязь между двумя объектами выражается с помощью объекта СЕМЕСТР+КУРС,
изображаемого прямоугольником, находящимся на втором уровне. Вновь образованный объект выделяется пунктирной
линией.
Одинарная и двойная стрелки, соединяющие объекты, представленные отношениями 1 и 3, и объект КУРС, выделенный пунктиром, отражают тот факт, что в течение семестра читается несколько курсов и что курс может читаться в течение нескольких семестров.
3. Процедура, выполненная для второго уровня, выполняется на третьем уровне, где имеются отношения, ключ которых состоит из трех элементов данных, и т. д.
Полученная в результате диаграмма для отношений 1, 2, 3 и 4 приведена на рис. 9, что и будет являться графическим
представлением концептуальной модели данных.
27
Рис. 9
Разработав концептуальную модель, АБД может приступить к созданию логической модели (реляционной, иерархической или сетевой).
Лекция 4 Иерархическая модель данных
В повседневной жизни мы часто имеем дело с иерархическими структурами. Поэтому нетрудно уяснить, что же представляет собой иерархия.
Рассмотрим генеалогическое древо. Родители могут иметь одного или нескольких детей, либо вовсе их не иметь. Дети, в
свою очередь, в будущем также могут иметь детей. Генеалогическое древо можно рассматривать как иерархическую структуру,
если считать, что из каждого узла удален один родитель. Терминология иерархической модели во многом использует рассмотренную аналогию. Компоненты базы данных, основанной на иерархической модели, показаны на рис. 1.
28
Рис. 1
1. Иерархическая древовидная структура
Иерархическая древовидная структура строится из узлов и ветвей. Узел представляет собой совокупность атрибутов данных, описывающих некоторый объект. Наивысший узел в иерархической древовидной структуре называется корнем. Зависимые
узлы располагаются на более низких уровнях дерева. Уровень, на котором находится данный узел, определяется расстоянием от
корневого узла (рис. 2). (Иерархическое дерево представляет собой перевернутое обычное дерево: корень находится наверху, а
ветви растут вниз.)
1.
2.
3.
4.
Рис. 2
Узлы и ветви образуют иерархическую древовидную структуру. Узел является совокупностью атрибутов, описывающих
объект. Наивысший в иерархии узел называется корневым (это главный тип объекта). Корневой узел находится на первом
уровне. Зависимые узлы (подчиненные типы объектов) находятся на втором, третьем и т д. уровнях.
Иерархическая модель данных организует данные в виде иерархической древовидной структуры. Каждый экземпляр корневого узла образует начало записи логической базы данных, т. е. иерархическая база данных состоит из нескольких деревьев. В
иерархической модели данных узлы, находящиеся на уровне 2, называются порожденными узла на уровне 1. Узел на уровне 1
называется исходным для узлов на уровне 2. Узлы, находящиеся на уровне 3, считаются порожденными узла уровня 2, который
для них является исходным, и т. д.
Иерархическая древовидная структура всегда удовлетворяет следующим условиям:
Иерархия неизменно начинается с корневого узла.
Каждый узел состоит из одного или нескольких атрибутов, которые описывают объект в данном узле.
На низших уровнях могут находиться зависимые узлы. Узел, находящийся на предшествующем уровне, является исходным
для новых зависимых узлов. Зависимые узлы могут добавляться как в вертикальном, так и в горизонтальном направлении без
всяких ограничений (см. рис. 4.4). (Исключение. На первом уровне может находиться только один узел, называемый корневым.)
Каждый узел, находящийся на уровне 2, соединен с одним и только одним узлом на уровне 1. Каждый узел, находящийся на
29
5.
6.
7.
уровне 3, соединен с одним и только одним узлом, находящимся на уровне 2, и т. д. Поскольку между двумя узлами может существовать лишь одна дуга (соединение), дуги не нуждаются в метках.
Исходный узел может иметь в качестве зависимых один или несколько порожденных узлов. Если узел не имеет ни одного
зависимого узла, он не является исходным.
Доступ к каждому узлу, за исключением корневого, происходит через исходный узел. Выборка каждого узла, представленного в иерархии, осуществляется через его исходный узел, поскольку это в действительности отражает семантику данных. В связи с
этим в иерархической модели данных пути доступа к каждому узлу являются уникальными (рис. 4.6). (Например, доступ к узлу I
может осуществляться только по пути A-G-H-I, а доступ к узлу D — только по пути A-B-D.) Поэтому иерархическая модель данных обеспечивает только линейные пути доступа.
Возможно существование любого числа экземпляров узлов каждого уровня. Каждый экземпляр узла (за исключением
корневого) соединен с экземпляром исходного узла, т. е. может существовать много экземпляров узла А. Каждый экземпляр узла
А начинает логическую запись. Для каждого экземпляра узла А может существовать нуль, один или несколько экземпляров узла
В и т. д.
Рис. 3
Рассмотрим в качестве примера информацию, содержащуюся в отношениях ПАЦИЕНТ, ХИРУРГ, ПАЦИЕНТ - И - ХИРУРГ и ПРЕПАРАТ. Информация в иерархической модели данных может быть представлена различными способами. Один из
вариантов показан на рис. 4.7. Корневой узел представляет объект ПАЦИЕНТ. Объекты ХИРУРГ, ОПЕРАЦИЯ и ПРЕПАРАТ
объединены в порожденный узел.
Рис. 4
Для каждого пациента имеется экземпляр корневого сегмента. В рассматриваемый момент в базе данных содержатся записи
для пациентов Джона Уайта (1111), Мэри Джонс (1234), Чарльза Брауна (2345), Хола Кейна (4876), Пола Кошера (5123) и Энн
Худ (6845). Экземпляр записи базы данных для Джона Уайта (1111) показан на рис. 4 Тип узла второго уровня, приведенный на
рис. 3, на рис. 4 имеет два экземпляра. Иерархическая модель позволяет для каждого пациента представить сведения о нескольких операциях и нескольких хирургах.
Иерархическая модель, представленная на рис. 4, содержит еще пять записей базы данных для пациентов Мэри Джонс,
Чарльза Брауна, Хола Кейна, Пола Кошера и Энн Худ.
Рис. 5
30
Запись базы данных содержит сведения о Джоне Уайте. Здесь имеются два экземпляра зависимого (порожденного) узла, в
которых содержатся сведения об операциях удаления камней из желчного пузыря и из почек.
Экземпляр записи базы данных для пациента Хола Кейна показан на рис. 6.
Рис. 6
Запись базы данных содержит сведения о пациенте Холе Кейне. Имеется один экземпляр зависимого узла, в котором содержатся сведения об операции удаления желчного пузыря.
Информация о ПАЦИЕНТЕ, ХИРУРГЕ, ПАЦИЕНТЕ - И - ХИРУРГЕ и ПРЕПАРАТЕ может быть представлена с помощью
другой версии иерархической модели данных (рис. 7).
Рис. 8
Представление с помощью иерархической модели данных базы данных ХИРУРГ, в которой содержатся сведения обо всех
операциях, проведенных хирургами. Здесь узел ХИРУРГ находится на более высоком уровне, чем узел ПАЦИЕНТ. Такая структура отражает намерение АБД реализовать между ХИРУРГОМ и ПАЦИЕНТОМ взаимосвязь «один ко многим».
Корневой узел соответствует объекту ХИРУРГ. Для каждого хирурга имеется экземпляр корневого узла. В некоторый момент времени база данных содержит записи для хирургов Бет Литл (145), Дэвида Роузена (189), Чарльза Филда (243), Майкла
Даймонда (311) и Патриции Голд (467). Запись базы данных для Бет Литл (145) показана на рис. 9.
Иерархическая модель данных позволяет представлять сведения о нескольких пациентах для каждого хирурга.
Рис. 9
Экземпляр записи иерархической базы данных, которая описывается моделью данных, представленной на рис. 9. Запись базы данных содержит сведения о хирурге Бет Литл. Зависимый (порожденный) узел имеет три экземпляра, в которые включены
сведения о пациентах Джоне Уайте, Холс Кейне и Поле Кошере.
Иерархические модели данных, представленные на рис. 3 и 6, отличаются друг от друга, хотя и являются моделями одной и
той же предметной области. Различия между ними определяются способами представления взаимосвязей между объектами. На
рис. 3 ПАЦИЕНТ находится на более высоком уровне иерархии, чем ХИРУРГ. Это означает, что АБД трактует взаимосвязь
между ПАЦИЕНТОМ и ХИРУРГОМ как взаимосвязь «один ко многим». На рис 6 ХИРУРГ находится на более высоком уровне
иерархии по сравнению с ПАЦИЕНТОМ. Здесь АБД рассматривает взаимосвязь между ХИРУРГОМ и ПАЦИЕНТОМ как взаи-
31
мосвязь «один ко многим». Выбор иерархической модели данных должен определяться операционными характеристиками.
С помощью модели, представленной на рис. 10, могут быть изображены другие взаимосвязи между теми же данными.
Рис. 10
Представление с помощью иерархической модели данных базы данных ХИРУРГ, в которой содержатся сведения обо всех
днях проведения операций и обо всех операциях, проведенных в конкретный день.
Экземпляр записи базы данных, описываемой моделью рис. 10, изображен на рис. 11. В этом примере для каждого экземпляра узла второго уровня имеется только один экземпляр узла третьего уровня. Однако вполне вероятно, что однажды хирург
сделает операцию более чем одному пациенту. В рассматриваемой упрощенной модели имеется только по одному узлу второго и
третьего уровня, хотя иерархическая модель позволяет для каждого хирурга представить несколько дат проведения операций и
несколько пациентов, перенесших операцию в указанный день.
Рис. 11
Экземпляр записи иерархической базы данных, модель которой представлена на рис 11. Запись базы данных содержит сведения о хирурге Бет Литл. В 1977 г. Бет Литл провела по одной операции в день: 1 января, 10 мая и 5 ноября. 1 января пациентом
был Джон Уайт, 10 мая – Пол Кошер, 5 ноября – Хол Кейн.
2. Включение и удаление данных
В иерархической модели на рис. 3 исходным узлом является ПАЦИЕНТ, а порожденным, в котором хранятся сведения о
лечении пациента – ХИРУРГ. Если один хирург оперирует более одного пациента, то сведения о хирурге дублируются для каждого Пациента. Например, в записях базы данных (см. рис. 4 и 5) информация о хирурге с номером патента 145 (Бет Литл) является избыточной.
Включение данных. Экземпляр порожденного узла не может существовать в отсутствие экземпляра исходного узла. Если
иерархическая модель данных подобна представленной на рис. 3, то в такую базу данных невозможно включить сведения о хирурге, который не оперировал ни одного пациента.
Удаление данных. При удалении экземпляра исходного узла также удаляются и все экземпляры порожденных узлов. Например, в иерархической модели данных, показанной на рис. 8, при удалении экземпляра узла ХИРУРГ одновременно удаляются и
все экземпляры узлов, содержащих сведения о пациентах, прооперированных данным хирургом. Это приводит к потере информации о прооперированных пациентах.
Аномалии запоминания и удаления связаны с тем, что в иерархической модели данных взаимосвязи «многие ко многим»
непосредственно не поддерживаются, а реализуется только взаимосвязь «один ко многим». Эти аномалии могут быть частично
устранены за счет введения двух иерархических моделей, связанных между собой так, как показано на рис. 12.
32
Рис. 12
В первой модели данных корневым узлом является ПАЦИЕНТ, а на втором уровне расположен узел ОПЕРАЦИЯ. Во второй модели данных корневой узел – ХИРУРГ, а узел ОПЕРАЦИЯ находится на втором уровне. Узел ОПЕРАЦИЯ второго уровня
первой модели связывается с корневым узлом ХИРУРГ второй модели. Узел ОПЕРАЦИЯ второго уровня второй модели связывается с корневым узлом ПАЦИЕНТ первой модели В подобной «комбинированной» иерархической модели данных информация
о дате операции и об ОПЕРАЦИИ хранится с избыточностью, однако таким путем удается устранить аномалии включения и
удаления сведений о ПАЦИЕНТЕ и об ОПЕРАЦИИ. В системах управления базами данных, основанных на иерархической модели, проблемы избыточности данных решаются различными способами.
3. Достоинства модели
Главные достоинства иерархической модели данных:
• наличие хорошо зарекомендовавших себя систем управления базами данных, основанных на ее применении;
• простота понимания и использования. Пользователи систем обработки данных хорошо знакомы с иерархическими структурами;
• обеспечение определенного уровня независимости данных. Так, с помощью двух иерархических моделей, показанных на
рис 12, можно реализовать различные представления пользователей (рис. 13);
• простота оценки операционных характеристик благодаря заранее заданным взаимосвязям.
Рис. 13



Представление прикладного программиста, которое в терминологии ANSI (Американский национальный институт стандартов) называется внешней моделью.
4. Недостатки модели
Взаимосвязи «многие ко многим» в иерархической модели могут быть реализованы искусственно, но структура становится
громоздкой. При этом может потребоваться хранение избыточных данных. Известно, что на логическом уровне избыточность не
обязательно недостаток, напротив, она обеспечивает простоту. Однако на физическом уровне избыточность нежелательна.
Из-за строгой иерархической упорядоченности объектов модели значительно усложняются операции включения и удаления.
Удаление исходных объектов влечет удаление порожденных. Поэтому выполнение операции УДАЛИТЬ требует особой
осторожности.
33


Особенности иерархических структур обусловливают процедурность операций манипулирования данными.
Корневой тип узла является главным. Доступ к любому порожденному узлу возможен только через исходный.
Лекция 5 Логическая модель данных. Отображение на иерархическую модель данных
Рис. 0
Преобразование концептуальной модели в логическую иерархическую модель данных сложнее, поскольку при этом
существует кажущаяся свобода выбора конкретных решений и, как правило, в таких случаях единственно верного решения быть не может. Однако преобразование модели можно разбить на этапы и определить для каждого из них критерии
выбора решения. Различают основные этапы:
1. Вывод обобщенной иерархической модели, в которой не учитываются ограничения, накладываемые используемой
СУБД.
2. Трансформация полученной модели с учетом, ограничений, накладываемых конкретной СУБД.
3. Модификация трансформированной модели с учетом «очевидных» соображений, влияющих на производительность.
4. . Упрощение имен ключей.
5. . Реализация взаимосвязей, не отображенных в логической модели, но на самом деле существующих.
Устранение транзитивности.
В концептуальной модели имеется транзитивная зависимость, если удаление взаимосвязи между А и С не приводит к потере информации (рис. 3). Отношение между А и С может быть выведено из отношений между А и В и между
В и С.
1.1.
Рис. 1
После удаления взаимосвязи между А и С можно видоизменить рис. 1 так, как это показано на рис. 2.
34
Рис. 2
Перед тем, как удалить какую-либо взаимосвязь, необходимо проанализировать, не приведет ли это к потере информации. Обратимся к примеру на рис. 3.
Рис. 3
Здесь взаимосвязь 1 между СТУДЕНТОМ и ПРЕПОДАВАТЕЛЕМ отражает отношение между студентами и их
научными руководителями. Взаимосвязь 2 отражает отношения между студентами и преподавателями в ходе выполнения
проектов. Преподаватель может одновременно быть научным руководителем у одной группы студентов и консультантом
проекта у другой. В этом примере нельзя удалить первую взаимосвязь, так как это приведет к потере определенной информации.
1.2. Выявление взаимосвязей типа «исходный-порожденный».
В концептуальной модели прямоугольники представляют узлы, а стрелки – взаимосвязи между исходными и порожденными узлами. На рис. 0 корневые узлы изображены в виде прямоугольников, находящихся на первом уровне
(СТУДЕНТ, КУРС и СЕМЕСТР). На втором уровне находится узел СЕМЕСТР+КУРС, который может быть порожденным либо для узла СЕМЕСТР, либо для узла КУРС. Здесь имеется два корневых узла, т. е. два иерархических дерева, которые соединяются между собой с помощью узла СЕМЕСТР+КУРС. Необходимо решить, какой же узел – СЕМЕСТР или
КУРС – будет исходным для узла СЕМЕСТР+КУРС.
Рассмотрим ту часть рис. 0, где имеются узлы СЕМЕСТР, СЕМЕСТР+ КУРС и СЕМЕСТР+КУРС+СТУДЕНТ. Узел
СЕМЕСТР+КУРС+СТУДЕНТ может быть порожденным либо для узла СЕМЕСТР+КУРС второго уровня, либо для узла
СТУДЕНТ первого уровня.
На этом этапе выявляются возможные взаимосвязи типа «исходный- порожденный». Окончательный выбор осуществляется на следующем этапе.
1.З. Устранение множественного родительства.
При отображении концептуальной модели на иерархическую необходимо, чтобы у каждого порожденного узла
остался ровно один исходный. Например, нужно решить, какой узел является исходным для узла СЕМЕСТР+КУРС,СЕМЕСТР или КУРС.
В рассматриваемой концептуальной модели имеется два типа исходных узлов. Одни из них представляют реальные
отношения в третьей нормальной форме, полученные на основе анализа требований к данным (к таким узлам относятся,
например, СТУДЕНТ и СЕМЕСТР, другие же были «сгенерированы» при синтезе концептуальной модели.
Выбор исходных узлов зависит от следующих комбинаций.
1.3.1. Оба исходных узла являются отношениями в третьей нормальной форме и не были созданы искусственно.
35
Рис. 4
На рис. 4 узлы Х и Y – исходные, а Z —порожденный. Здесь возможны два варианта выбора исходного узла. Либо Х
принимается за исходный узел, а Y и Z объединяются и становятся порожденным узлом, либо Y принимается за исходный, а X и Z объединяются. И в том, и в другом случаях возникает избыточность данных. Поэтому, следует решить, всегда ли необходимо наличие двух исходных узлов или же ценой введения избыточности можно объединить один из предполагаемых исходных узлов с порожденным. Существует и третий вариант – объединить исходные и порожденный в один
узел, например X, Y и Z.
1.3.2. Один из исходных узлов – истинное отношение в третьей нормальной форме, а другой образован искусственно.
Следует удалить тот исходный узел, который был «сгенерирован» при синтезе концептуальной модели. На рис. 5а
таким «сгенерированным» узлом является КУРС, в то время как СЕМЕСТР представляет собой результат приведения исходных отношений к третьей нормальной форме. Единственным атрибутом КУРСА служит номер курса (НОМ-КУРСА).
Этот атрибут имеется также и в узле СЕМЕСТР+КУРС. Если удалить узел КУРС, как показано на рис. 5,6, то никакая информация не теряется. При этом единственным исходным для узла СЕМЕСТР+КУРС остается узел СЕМЕСТР. Удаляя
узел, не следует упускать из виду его связи с остальными узлами модели.
а
б
Рис. 5
1.З.З. Оба исходных узла образованы искусственно.
36
Исходные узлы Х и Y «сгенерированы». Оба они могут быть удалены при устранении ситуации «несколько исходных».
а
Рис. 6
б
Окончание рис. 6
На рис. 6а узлы Х и Y «сгенерированы» и являются исходными. Порожденный узел – Z. Можно объединить X, Y и Z
в один новый тип узла. Поскольку и X, и Y удаляются, можно переместить объединенный узел, X, Y и Z на более высокий
уровень иерархии, как это показано на рис. 6,б.
1.3.4. Если согласно А.3.1—А.З.З не достигнуто решение, выбор произволен.
Если в процессе проектирования выясняется, что обязательно наличие двух исходных узлов, следует использовать
СУБД, поддерживающую несколько исходных узлов. Узел СЕМЕСТР+КУРС имеет два исходных узла. Допустим, что мы
принимаем решение остановиться на логической модели, показанной на рис. 6.
Этапы преобразования в п. 1.3.1—1.З.З можно последовательно применять к узлам, расположенным на нижних
уровнях: рассматриваются исходные узлы второго уровня и порожденные третьего и т. д.
Теперь можно учесть ограничения, которые накладывает используемая СУБД.
2. Трансформация полученной модели данных с учетом ограничений, накладываемых конкретной СУБД.
Иерархическую модель данных поддерживает целый ряд СУБД. Одна из них – система IMS, поставляемая IBM. Эта
система поддерживает и некоторые сетевые структуры. Использование системы IMS накладывает следующие ограничения на модель данных:
1. Возможно существование .не более 255 типов узлов, которые в системе IMS называются «типами сегментов».
2. Допускается не более 15 уровней иерархии.
3. Порожденный сегмент может иметь максимум два исходных сегмента. Один из исходных сегментов, в иерархии которого находится порожденный, называется «физически исходным». Другой исходный называется «логически исходным». На логически порожденные сегменты накладывается следующее ограничение.
4. Логически порожденный не может иметь логически порожденного.
Ни одно из перечисленных ограничений на рис. 7 не нарушено. Поэтому никаких трансформаций логической модели не требуется. Эта модель может быть реализована в системе IMS. Единственный вопрос, который остается решить,
касается расположения логически порожденного сегмента СЕМЕСТР + КУРС + СТУДЕНТ. Последний может быть физически порожденным либо сегмента СЕМЕСТР, либо сегмента СЕМЕСТР+КУРС.
37
Рис. 7
3. Модификация трансформированной модели данных с учетом «очевидных» соображений, влияющих на эффективность обработки.
Можно ли улучшить эксплуатационные характеристики будущей базы данных путем объединения сегментов и сокращения числа уровней, разбиения сегментов с целью более эффективной передачи данных или обеспечения их безопасности, объединения или разделения иерархий и других структурных изменений?
На перечисленные вопросы невозможно ответить, не имея ряда количественных характеристик, например частоты
использования различных путей в иерархии, среднего числа экземпляров сегментов каждого типа, длин сегментов. Их
рассмотрение относится скорее к физическому проектированию базы данных. Однако и в процессе логического проектирования можно принять в этой части ряд решений, основанных на «очевидных» соображениях.
3.1. Исходный сегмент, обладающий только одним порожденным типом сегмента, может с ним объединяться.
На рис. 7 у сегмента СЕМЕСТР только один порожденный СЕМЕСТР+ КУРС. Необходимо сделать выбор между
требованиями повышения производительности и уменьшения избыточности данных. В сегменте СЕМЕСТР всего два поля: ДНАЧСЕМ (дата начала семестра) и ДКОНСЕМ (дата окончания семестра). Если принять сегмент СЕМЕСТР в качестве исходного для сегмента СЕМЕСТР+КУРС, то для каждого семестра останется лишь один экземпляр сегмента СЕМЕСТР, т. е. даты его начала и окончания будут запоминаться в течение семестра всего один раз. Но при этом должен
храниться по крайней мере один указатель на первый принадлежащий данному семестру экземпляр курса. Кроме того,
хранятся указатели, связывающие экземпляры семестров. Следует рассмотреть время, затрачиваемое на обновление указателей и на доступ к отдельным сегментам СЕМЕСТР и СЕМЕСТР+КУРС.
Одно из решений состоит в объединении сегментов СЕМЕСТР и СЕМЕСТР+КУРС, что порождает избыточность по
значениям ДНАЧСЕМ (дата начала семестра) и ДКОНСЕМ (дата окончания семестра). Если в данном семестре читается
50 различных курсов, им соответствует 50 экземпляров сегмента СЕМЕСТР+КУРС, в каждом из которых для каждого
курса хранятся поля ДНАЧСЕМ и ДКОНСЕМ. Избыточность данных приводит к увеличению требуемых объемов памяти.
Более серьезную проблему может представлять обеспечение целостности избыточно хранимых данных. Основным вопросом, который следует рассматривать при введении избыточности, является частота обновления данных. Часто обновляемые данные должны храниться с минимальной избыточностью. В нашем примере дата начала семестра и дата его окончания в течение семестра не изменяются. Обновление этих значений происходит достаточно редко. Поэтому интуитивно
представляется вполне оправданным объединить сегмент СЕМЕСТР и его порожденный сегмент СЕМЕСТР+КУРС.
Мы решили, что сегмент СЕМЕСТР+КУРС+СТУДЕНТ будет для сегмента СТУДЕНТ физически порожденным, а
для сегмента СЕМЕСТР+КУРС –логически порожденным.
3.2. Следует ли сохранить логическую взаимосвязь или объединить логически исходный и логически порожденный
сегменты?
Пусть логически исходный сегмент СЕМЕСТР+КУРС имеет логически порожденный СЕМЕСТР+КУРС+СТУДЕНТ.
В системе IMS с каждого корневого сегмента начинается новая база данных. Мы имеем два иерархических дерева и соответственно две базы данных. Всякий раз, когда прикладной программе потребуются сведения о курсах, которые изучает
какой-либо студент, система IMS должна осуществить доступ к двум различным базам данных: базе данных СТУДЕНТ и
базе данных СЕМЕСТР и КУРС.
Главная причина, по которой такого объединения делать не следует, заключается в том, что оно приводит к избыточности часто обновляемой информации о курсах. В такой базе данных сведения о курсе будут повторяться для каждого
38
изучающего этот курс студента. Подобная избыточность может привести к нарушениям непротиворечивости данных. Поэтому мы оставляем два иерархических дерева.
Если же оставить только одно иерархическое дерево, то тем самым сократится число физических баз данных. С точки зрения производительности, уменьшение числа физических баз данных весьма существенный фактор. При этом учитываются такие количественные характеристики, как частота использования различных путей в иерархии, среднее число
экземпляров сегментов различных типов, длины сегментов.
4. Упрощение имен ключей.
Имена ключей порожденных сегментов можно упростить, удалив те части имени, которые встречаются в имени исходного сегмента (см. средний рис. 8). В иерархии ключ физически порожденного сегмента косвенно подразумевает ключ
исходного. Однако составные ключи, которые идентифицируют логически порожденные сегменты, связывающие исходные сегменты, принадлежащие различным иерархическим путям, сохраняются (см. правый рис. 8).
Рис. 8
На рис. 7 единственный сегмент, в котором можно упростить ключ,- это СЕМЕСТР+КУРС+СТУДЕНТ – логически
порожденный сегмент. Он связывает исходные сегменты, принадлежащие различным иерархическим путям. Нам приходится использовать составной ключ с атрибутами СЕМЕСТР, НОМ-КУРСА и НОМ-СТУДЕНТА.
5. Реализация взаимосвязей, неотраженных в логической модели, но, на самом деле, существующих.
Усовершенствованная логическая модель, представленная на рис. 7, удовлетворяет функциональным требованиям и
обеспечивает, очевидно, более высокую производительность, чем первоначальная концептуальная модель, показанная на
рис. 0. На этом можно было бы считать логическое конструирование, включающее отображение в иерархическую модель
данных, завершенным. Однако проектировщик может пожелать его продолжить и добавить ряд внутренних (скрытых)
взаимосвязей, существующих между данными. Речь идет о реально существующих взаимосвязях, определяемых организационными или физическими характеристиками моделируемой предметной области, но явно не сформулированных в
концептуальных требованиях. Основная причина реализации упомянутой взаимосвязи состоит в том, что база данных
должна обеспечивать получение ответов на произвольные запросы и легко адаптироваться для будущих применений.
Логическая модель данных для системы IMS, представленная на рис. 7, не нуждается в каких-либо изменениях.
39
Сетевая модель данных
Составляющие базы данных, описываемой сетевой моделью, показаны на рис. 1 и 2.
Рис. 1
База данных состоит из нескольких областей. Область содержит записи. В свою очередь запись состоит из полей. Набор, который объединяет записи, может размещаться в одной или нескольких областях.
Рис. 2
Область – это поименованная часть базы данных, в которой могут содержаться экземпляры записей и наборов или частей
наборов. Каждая область может обладать собственными уникальными физическими характеристиками Области могут обрабатываться как по отдельности, так и вместе с другими областями.
Рассмотрим основные компоненты сетевой модели данных: записи и наборы.
В сетевой модели данных объекты предметной области объединяются в «сеть». Графически сетевая модель представляется с
помощью прямоугольников и стрелок. Каждый тип записи может содержать нуль, один или несколько атрибутов (употребляются
также термины «элемент данных» и «поле»).
Поясним различие между типом и экземпляром записи. ПАЦИЕНТ является типом записи, а строка символов «I 111 Джон
Уайт 15 Нью-Стрит, Нью-Йорк, Н.-Й.» – экземпляром типа записи ПАЦИЕНТ (рис. 3 и 4). Таким образом, в базе данных может
иметься один или несколько экземпляров записи некоторого типа.
Рис. 3
В наборе ПАЦИЕНТ-ПЕРЕНЕС-ОПЕРАЦИЮ владельцем является запись ПАЦИЕНТ, а членом – запись ОПЕРАЦИЯ.
40
Рис. 4
Экземпляр набора ПАЦИЕНТ ПЕРЕНЕС ОПЕРАЦИЮ содержит один экземпляр записи владельца и два экземпляра записи
члена. Набор реализован в виде кольцевой структуры. Имеются и другие способы его реализации.
Направленные стрелки соединяют два или более типов записей и служат для изображения типов набора. Тип записи, из которого исходит стрелка, называется владельцем набора, а тип записи, к которому направлена стрелка – членом набора. Стрелка,
направленная от владельца набора к его члену, обозначает тип набора. Тип набора представляет логическую взаимосвязь «один
ко многим» между владельцем и членом набора (рис 3). При этом не предполагается, что экземпляры членов набора должны
располагаться вблизи экземпляра владельца набора в физической памяти, хотя это и возможно.
• Набор – это поименованная совокупность связанных записей.
• В каждом экземпляре набора имеется только один экземпляр владельца.
• Экземпляр набора может содержать нуль, один или несколько записей-членов.
• Набор считается пустым, если ни один экземпляр записи-члена не связан с соответствующим экземпляром записивладельца.
• Экземпляр набора существует после запоминания записи-владельца.
Каждому типу набора присваивается имя, что позволяет одной и той же паре типов объектов участвовать в нескольких взаимосвязях.
Необходимо различать тип и экземпляр набора. В примере на рис. 4 тип набора – ПАЦИЕНТ ПЕРЕНЕС ОПЕРАЦИЮ. Экземпляр этого типа набора представлен экземпляром типа записи-владельца ПАЦИЕНТ «I 111 Джон Уайт 15 Нью-стрит, НьюЙорк, Н-Й» и экземплярами типа записи-члена «01.01.77, Удаление камней из желчного пузыря, Пенициллин, Сыпь» и «12.06.77,
Удаление камней из почек, — ,—». Таким образом, экземпляр типа набора состоит из одного экземпляра типа записи-владельца
и нуля или более экземпляров типа записи-члена данного типа набора. Между экземпляром типа записи-владельца и экземплярами типа записи-члена существует взаимосвязь «один ко многим». Определенный экземпляр типа записи-члена в экземпляре данного типа набора не может одновременно принадлежать более чем одному экземпляру типа записи-владельца. Иными словами
уникальность владельца типа набора обязательна.
1. Представление взаимосвязи «один ко многим»
В модели данных, представляющей взаимосвязь «один ко многим», тип записи - владелец «владеет» 0-п экземплярами типа
записи-члена.
В свою очередь тип записи - член в другом типе набора может играть роль типа записи-владельца. Запись-владелец данного
набора может играть ту же роль в нескольких наборах. Такая структура представляет собой иерархию. Следовательно, иерархическая модель данных является частным случаем сетевой модели.
Рис. 5
На рис. 5 приведены сведения о пациенте, перенесшем несколько операций, и о конкретном типе операции, сделанной не-
41
скольким пациентам. Операция, которой подверглись несколько пациентов, будет одновременно членом в двух или более экземплярах одного и того же типа набора, что нарушает правило уникальности владельца. Взаимосвязь «многие ко многим» может
быть реализована двумя взаимосвязями «один ко многим».
В структуре такого типа нарушается правило уникальности владения, поскольку операция, перенесенная двумя или более
пациентами, может быть членом одновременно в двух или более экземплярах одного набора.
Типами объектов здесь служат: ПАЦИЕНТ, ХИРУРГ и ОПЕРАЦИЯ. Один хирург может прооперировать нескольких пациентов. Один пациент мог быть в свое время прооперирован несколькими хирургами. ПАЦИЕНТ, ХИРУРГ и ОПЕРАЦИЯ образуют сеть. Между ПАЦИЕНТОМ и ХИРУРГОМ существует взаимосвязь «многие ко многим. ПАЦИЕНТ и ХИРУРГ могут рассматриваться как различные типы записей. Для того чтобы преобразовать взаимосвязь «многие ко многим» между ПАЦИЕНТОМ и ХИРУРГОМ в две взаимосвязи «один ко многим», воспользуемся в качестве связки записью ОПЕРАЦИЯ, которая характеризуется датой операции, видом операции, назначенным после операции препаратом и побочным эффектом от его применения.
Отметим, что запись-связка может и не содержать никаких данных. В большинстве случаев она, как правило, включает некоторую полезную информацию, описывающую взаимосвязь между двумя остальными записями.
На рис. 6 показаны два типа записи: ПАЦИЕНТ и ОПЕРАЦИЯ. В сетевой модели данных на рис. 7 два типа записей образуют набор.
Записи ПАЦИЕНТ и ОПЕРАЦИЯ образуют набор ПАЦИЕНТ ПЕРЕНЕС ОПЕРАЦИЮ. Владельцем является запись ПАЦИЕНТ, а членом — запись ОПЕРАЦИЯ. Записи ХИРУРГ и ОПЕРАЦИЯ образуют набор ОПЕРАЦИЯ-ПАЦИЕНТА.
а
б
Рис 6
Здесь «а» - один экземпляр набора, в котором содержатся сведения об удалении камней из желчного пузыря; «б» - два экземпляра набора, в которых владельцами являются пациенты Джон Уайт и Пол Кошер, и имеется один и тот же экземпляр записи-члена – удаление камней из желчного пузыря.
Запись ХИРУРГ называется владельцем, а запись ОПЕРАЦИЯ — членом этого набора.
Каждый экземпляр набора ПАЦИЕНТ-ПЕРЕНЕС-ОПЕРАЦИЮ представляет иерархическую взаимосвязь между пациентом
и операцией. Существенное различие между сетевой и иерархической моделями данных состоит в том, что в сетевой модели
каждая запись может участвовать в любом числе наборов и играть роль как владельца, так и члена набора.
42
Рис. 7
Представление данных с помощью сетевой модели взаимосвязи «многие ко многим» реализуется двумя типами наборов:
1)
ПАЦИЕНТ-ПЕРЕНЕС-ОПЕРАЦИЮ (запись-владелец ПАЦИЕНТ, запись-член ОПЕРАЦИЯ);
2)
ОПЕРАЦИЯ-ПАЦИЕНТА (запись-владелец ХИРУРГ, запись-член ОПЕРАЦИЯ).
2. Дополнительные классы наборов
Кроме обычных наборов существуют также наборы второго и третьего классов. Второй класс включает наборы, состоящие
из трех или более записей. Такой набор называется многочленным. Записью-владельцем здесь является ПАЦИЕНТ, а записямичленами — ОПЕРАЦИЯ и ЗАБОЛЕВАНИЕ (см. рис. 8). Показаны один экземпляр записи владельца и. пять экземпляров записей
членов.
Рис. 8
Третий класс представлен так называемыми сингулярными наборами. Этот класс также определяется в терминах записивладельца и записи-члена. Однако в отличие от рассматривавшихся случаев в базе данных может содержаться только один экземпляр сингулярного набора. Такую структуру можно использовать двояко:
1. С помощью сингулярного набора можно объединить записи, у которых нет естественного владельца.
2. В сингулярный набор можно включать записи, которые при вводе в базу данных не имеют владельца, но могут его
приобрести впоследствии. Тогда определенная запись исключается из сингулярного набора и включается в экземпляр набора с
новым владельцем.
3. Операции включения и удаления в сетевой модели данных
Включение. Допускается добавление новой записи ХИРУРГ в качестве экземпляра владельца в экземпляр набора ОПЕРАЦИЯ-ПАЦИЕНТА, в котором экземпляр ОПЕРАЦИЯ отсутствует. При этом вводятся сведения о хирурге, не прооперировавшем
ни одного пациента. Аналогичным образом можно вводить сведения о пациенте вне зависимости от сведений о хирурге.
Удаление. При удалении экземпляра владельца ХИРУРГ удаляются все указатели, связывающие операции, выполненные
43
хирургом в экземпляре набора ОПЕРАЦИЯ-ПАЦИЕНТА. Информация же о пациентах, которых оперировал данный хирург, не
уничтожается. Удаляется информация только о соответствующем хирурге.
Аналогично при удалении экземпляра владельца ПАЦИЕНТ удаляются все указатели, связывающие перенесенные данным
пациентом операции в экземпляре набора ПАЦИЕНТ-ПЕРЕНЕС-ОПЕРАЦИЮ. Информация же о хирургах, оперировавших
данного пациента, остается неизменной.
4. Достоинства модели
Главными достоинствами сетевой модели данных являются:
• наличие успешных реализации систем. управления базами данных, обеспечивающих эту сетевую модель (как и в иерархической модели);
• простота реализации часто встречающихся в реальном мире взаимосвязей «многие ко многим».
5. Недостатки модели
Основной недостаток сетевой модели состоит в ее сложности. Прикладной программист должен детально знать логическую
структуру базы данных, поскольку ему необходимо осуществлять навигацию среди различных экземпляров наборов и экземпляров записей. Другими словами, программист должен представлять «свое» текущее положение в экземплярах наборов при «продвижении» по базе данных.
Недостатком является также возможная потеря независимости данных при реорганизации базы данных. Кроме того, в сетевой модели данных представление, используемое прикладной программой, сложнее, чем в иерархической модели. Поэтому и
составление прикладных программ может оказаться сложнее.
Лекция 6 Логическая модель данных. Отображение на сетевую модель данных
Отображение концептуальной модели на сетевую модель данных представляет собой сложный процесс. Здесь также
имеется ряд альтернатив, нет очевидного наилучшего решения и требуется выполнение следующих основных этапов:
1.
Формирование обобщенной сетевой модели данных, в которой не учитываются ограничения, накладываемые
используемой СУБД.
2.
Трансформация обобщенной сетевой модели с учетом ограничений, накладываемых конкретной СУБД.
3.
Модификация трансформированной модели с учетом «очевидных» соображений, влияющих на производительность.
4.
Упрощение имен ключей.
5.
Реализация взаимосвязей, не отраженных в логической модели, но на самом деле существующих.
1. Формирование обобщенной сетевой модели данных, в которой не учитываются ограничения, накладываемые используемой СУБД.
1.1. Определение взаимосвязей «владелец— член».
В концептуальной модели прямоугольники представляют типы записей, а стрелки – связи между ними. При обсуждении сетевой модели воспользуемся так называемыми стрелками Бахмана. На рис. 1 приведена концептуальная модель,
изображенная с использованием стрелок Бахмана.
44
Рис. 1
Концептуальная модель, представленная на рис. 1, изображена с помощью стрелок Бахмана. Эту модель мы примем
за исходную при разработке логической модели. Здесь сделаны следующие предположения:
1. НАЗВ-КУРСА зависит от СЕМЕСТРА и НОМ-КУРСА. Возможно, что от семестра к семестру НАЗВ-КУРСА с
данным НОМ-КУРСА будет изменяться.
2. ЗАЧЕТЫ зависят от СЕМЕСТРА, НОМ-КУРСА и НОМ-СТУДЕНТА. Студент сам определяет, сколько зачетов он
сдает по данному курсу в данном семестре.
Присвоим наборам имена:
Набор I – ЗАЧЕТЫ-СТУДЕНТА: владелец – СТУДЕНТ, член – СЕМЕСТР + КУРС + СТУДЕНТ.
Набор
II
–
ЗАЧЕТЫ-ПО-КУРСУ-В-СЕМЕСТРЕ:
владелец
–
СЕМЕСТР+КУРС,
член
–
СЕМЕСТР+КУРС+СТУДЕНТ.
Связь между наборами I и II осуществляет запись-член СЕМЕСТР+КУРС+СТУДЕНТ.
Набор III – КУРСЫ-СЕМЕСТРА: владелец – СЕМЕСТР, член— СЕМЕСТР + КУРС.
Набор IV – СЕМЕСТРЫ-КУРСА: владелец – КУРС, член – СЕ-МЕСТР+КУРС.
Запись-член СЕМЕСТР+КУРС связывает наборы III и IV. Она одновременно состоит членом наборов III и IV и владельцем набора II.
Преобразование концептуальной модели, приведенной на рис. 1, в логическую модель, основанную на сетевой модели данных, осуществляется достаточно просто. Полученная в результате сетевая модель не предполагает использования
какой-либо конкретной СУБД.
1.2. Устранение множественного владения.
Из рассмотренного выше мы знаем, что член набора не может иметь более одного владельца в одном и том же наборе. В модели на рис. 1 это правило не нарушено, поэтому никаких преобразований здесь не требуется.
2. Трансформация обобщенной сетевой модели с учетом ограничений, накладываемых конкретной СУБД.
Целый ряд СУБД базируется на использовании спецификаций КОДАСИЛ, например системы IDS/11, IDMS, DBMS10 и DBMS-20. Все четыре конструкции наборов на рис. 1 не противоречат спецификациям КОДАСИЛ. Однако, если используемая СУБД не поддерживает все спецификации КОДАСИЛ, могут потребоваться некоторые модификации этой сетевой модели данных.
3. Модификация трансформированной модели с учетом «очевидных» соображений, влияющих на производительность.
Логическая модель на рис. 1 удовлетворяет всем функциональным требованиям. Выясним теперь, можно ли улучшить эксплуатационные характеристики создаваемой базы данных, например объединить некоторые записи и за счет этого сократить число наборов, или, наоборот, из соображений обеспечения безопасности данных разнести их в большее
число записей, одновременно увеличив число наборов, или внести другие структурные изменения.
В сетевой модели данных в отличие от большинства других моделей АБД должен указывать способы размещения
45
записей. Выбор способа размещения существенно влияет на эксплуатационные характеристики базы данных. Например,
экземпляры типа записи СЕМЕСТР + КУРС + СТУДЕНТ могут размещаться либо через набор ЗАЧЕТЫ-СТУДЕНТА, либо через набор ЗАЧЕТЫ-ПО-КУРСУ-В-СЕМЕСТРЕ. Выбор может определяться тем, по какому пути доступ осуществляется быстрее. (Вне зависимости от того, через какой набор размещаются записи, доступ к ним может производиться через
любой из двух наборов.)
Указанные проблемы эффективнее решаются на основе анализа количественных характеристик, например частот использования удельных наборов, средних чисел экземпляров каждого типа записей, длин записей. Поэтому окончательный
выбор производится на стадии физического проектирования базы данных. Но уже на этапе логического проектирования
можно принять некоторые решения, основываясь на перечисленных ниже «очевидных» соображениях, влияющих на эксплуатационные характеристики базы данных.
3.1. Не следует усложнять структуру.
Шаг 1. Можно удалить владельцев или членов набора, которые не содержат собственных данных. Вероятнее всего
будут удалены «сгенерированные» записи. На рис. 6.9 запись-владелец в типе набора IV не содержит никаких данных
кроме НОМ-КУРСА. Те же данные можно обнаружить в записи-члене СЕМЕСТР + КУРС. Оставлены следующие типы
наборов:
Тип набора I – ЗАЧЕТЫ-СТУДЕНТА: владелец – СТУДЕНТ,. член – СЕМЕСТР+КУРС+СТУДЕНТ.
Тип набора II – ЗАЧЕТЫ-ПО-КУРСУ-В-СЕМЕСТРЕ: владелец – СЕМЕСТР+КУРС, член – СЕМЕСТР+КУРС+СТУДЕНТ.
Тип записи-члена СЕМЕСТР+КУРС+СТУДЕНТ осуществляет связь между типами наборов I и II.
Тип набора III – КУРСЫ-СЕМЕСТРА: владелец – СЕМЕСТР, член –СЕМЕСТР+КУРС.
Шаг 2. Записи-владельцы, участвующие в этом качестве в небольшом числе типов наборов и содержащие только
тривиальные данные, могут быть объединены с записями-членами, если их содержимое не слишком часто обновляется.
СЕМЕСТР, владелец типа набора III (рис. 2), содержит только ДНАЧСЕМ (дата начала семестра) и ДКОНСЕМ (дата
окончания семестра) и участвует только в одном типе набора (рис. 2). Он вполне может быть объединен с членом данного
набора СЕМЕСТР+ -1- КУРС. Полученная в результате модель показана на рис. 3. (В действительности даты начала и
окончания семестра используются очень редко, и в базе данных их можно не хранить. Эти даты могут храниться в отдельных таблицах.) В типе набора 1 владельца СТУДЕНТ не следует объединять с членом СЕМЕСТР+КУРС+СТУДЕНТ.
Тип записи СТУДЕНТ содержит важные сведения о студентах. Комбинированный тип записи из записей СЕМЕСТР и
СЕМЕСТР+КУРС (рис. 3) также не следует объединять с членом типа набора II СЕМЕСТР+КУРС+СТУДЕНТ.
Рис. 2
Модель, приведенная на рис. 3, содержит два типа набора:
Тип набора I – ЗАЧЕТЫ-СТУДЕНТА: владелец – СТУДЕНТ, член – СЕМЕСТР+КУРС+СТУДЕНТ.
Тип набора II – ЗАЧЕТЫ-ПО-КУРСУ-В-СЕМЕСТРЕ: владелец – СЕМЕСТР+КУРС,
МЕСТР+КУРС+СТУДЕНТ. Тип записи СЕМЕСТР+КУРС+СТУДЕНТ связывает типы наборов I и II.
член
–
СЕ-
46
Рис. 3
4. Упрощение имен ключей.
В конструкции набора могут иметь следующие имена ключей (см. левый рис. 4):
Рис. 4
Изъяв из имени ключа каждой записи-члена часть, входящую в состав ключа записи-владельца, .можно упростить
ключи так, как показано на правом рис. 4.
После упрощения имен ключей логическая модель (рис. 3) приобретает вид, показанный на рис. 5. Здесь представлены два типа наборов:
Тип набора I – ЗАЧЕТЫ-СТУДЕНТА: владелец – СТУДЕНТ, член – СЕМЕСТР+ КУРС + СТУДЕНТ.
Тип набора II – ЗАЧЕТЫ-ПО-КУРСУ-В-СЕМЕСТРЕ: владелец – СЕМЕСТР+КУРС, член – СЕМЕСТР+КУРС+СТУДЕНТ. Тип записи СЕМЕСТР+КУРС+СТУДЕНТ связывает типы наборов I и II.
5. Реализация взаимосвязей, которые не отражены в логической модели, но на самом деле существуют.
Вводить какие-либо новые взаимосвязи в представленную на рис. 3 модель нет никакой необходимости.
47
Рис. 5
Таким образом, на рис. 5 получена улучшенная логическая модель, в которой из записи
МЕСТР+КУРС+СТУДЕНТ исключены элементы СЕМЕСТР, НОМ-КУРСА и НОМ-СТУДЕНТА (см. рис. 3).
СЕ-