Базы данных. Учебное пособие

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

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

2.5.2. Получение реляционной схемы из ER-схемы

Шаг 1. Каждая простая сущность превращается в таб- лицу. Простая сущность - сущность, не являющаяся подтипом и не имеющая подтипов. Имя сущности становится именем таблицы.

Шаг 2. Каждый атрибут становится возможным столб- цом с тем же именем; может выбираться более точный фор- мат. Столбцы, соответствующие необязательным атрибутам, могут содержать неопределенные значения; столбцы, соот- ветствующие обязательным атрибутам, - не могут.

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

Шаг 4. Связи многие-к-одному (и один-к-одному) ста- новятся внешними ключами. То есть делается копия уникаль- ного идентификатора с конца связи "один", и соответствую- щие столбцы составляют внешний ключ. Необязательные свя- зи соответствуют столбцам, допускающим неопределенные значения; обязательные связи - столбцам, не допускающим неопределенные значения.

41

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

Шаг 6. Если в концептуальной схеме присутствовали подтипы, то возможны два способа (табл 2.1):

а) все подтипы в одной таблице; б) для каждого подтипа - отдельная таблица.

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

42

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

2.6. Модели внутреннего уровня

Внутренний уровень является третьим уровнем архитек- туры БД. На нижнем уровне (см. рис. 2.12) находится внутрен- няя схема, которая является полным описанием внутренней модели данных.

Для каждой базы данных существует только одна внут- ренняя схема.

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

üраспределение дискового пространства для хранения данных и индексов;

üописание подробностей сохранения записей (с указанием реальных размеров сохраняемых элементов данных);

üсведения о размещении записей;

üсведения о сжатии данных и выбранных методах их

шифрования.

На уровне физической модели электронная база данных представляет собой файл или их набор в формате TXT, CSV, Excel, DBF, XML либо в специализированном формате кон- кретной СУБД. Также в СУБД в понятие физической модели включают специализированные виртуальные понятия, суще-

ствующие в её рамках — таблица, табличное пространство, сегмент, куб, кластер и т. д.

43

2.7.Проектирование данных

Втеории проектирования ИС проектирование данных есть последовательное представление предметной области в том виде:

1) как она реально существует и как её понимают поль- зователи (таких представлений может быть несколь- ко);

2) как ее воспринимает проектировщик базы данных; 3) как она может быть описана с помощью символов.

То есть проектируя данные, мы имеем дело с реально- стью, описанием реальности (представлением) и с данными, которые отражают это представление.

Данные, используемые для описания предметной облас- ти, представляются в виде трехуровневой схемы (модель

ANSI/SPARC):

Внешняя схема

Рис 2.12. Проектирование данных

Внешнее представление (внешняя схема) данных явля- ется совокупностью требований к данным со стороны пользо- вателей.

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

Внутренняя схема - это сама база данных.

Отсюда вытекают основные этапы, на которые разбива- ется процесс проектирования базы данных.

44

1.Внешнее проектирование - сбор, анализ и редактиро-

вание требований к данным. Для этого осуществляются сле- дующие мероприятия:

üобследование предметной области, изучение ее ин-

формационной структуры

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

процессами над информационными объектами

üмоделирование и интеграция всех представлений. По

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

2.Логическое проектирование - преобразование требо-

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

a)адекватность описываемому объекту/системе — на уровне концептуальной и логической модели;

b)удобство использования для ведения учёта и анализа

данных — на уровне так называемой физической мо- дели.

Известны следующие модели:

üтеоретико-графовые: иерархическая модель, сетевая модель;

üтеоретико-множественные: реляционная модель

(ER-модель), многомерная модель;

üобъектно-ориентированные: объектная модель;

üоснованные на инвертированных файлах.

Внастоящее время наибольшее распространение полу- чили реляционные базы данных. Сетевые и иерархические базы данных считаются устаревшими, объектно- ориентированные пока никак не стандартизированы и не по-

45

лучили широкого распространения. Некоторое возрождение

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

3. Физическое проектирование - определение особенно-

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

Следует понимать, именно СУБД отвечает за установ-

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

Различие уровней представления данных на каждом этапе проектирования представлено в табл. 2.2:

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

46

Вопросы для самопроверки

1.Изобразите схематично трёхуровневую архитектуру

ANSI/SPARC.

2.Как трехуровневая архитектура поддерживает принцип независимости программ и данных?

3.Почему на внешнем уровне существует несколько пред- ставлений?

4.В чем, по вашему мнению, заключаются основные про- блемы разработки внешнего представления?

5.Что означает понятие инфологическая модель?

6.Какие даталогические модели данных вы знаете?

7.Кто ответственен за внешнее представление данных?

8.Кем разрабатывается модель данных на физическим уровне?

9.В чем недостатки и достоинства:

žиерархической модели?

žсетевой модели?

žреляционной модели?

10.Какие элементы используются в ER диаграммах?

11.В чем заключаются основные отличия иерархической и сетевой моделей?

12.В чем вы видите преимущества реляционной модели?

13.Изложите поэтапно процесс перевода ER - модели в реляционную.

14.Что определяется на внутреннем уровне модели

ANSI/SPARC?

15.Изложите последовательность перевода ER модели в реляционную модель данных.

16.Какова последовательность проектирования БД?

47

Задание на построение даталогической модели

Создать базу данных Студент.

1.Создать три таблицы:

1.Таблица Каталог студентов

2. Создать связь между таблицами.

3. Добавить в таблицу Успеваемость_1 поля Физика и Хи- мия.

4. Удалить таблицу Успеваемость_2.

5. Заполнить таблицы.

48

ГЛАВА 3. СУБД

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

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

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

3.управление данными. Можно указать, кому разрешено знакомиться с данными, корректировать их или добавлять новую информацию. Можно также определять правила кол- лективного доступа.

Рассмотрим подробнее, какие задачи решает СУБД

3.1.Основные функции СУБД

Конкретизируем функции СУБД, с точки зрения разра- ботчика:

žуправление данными во внешней памяти;

žуправление буферами оперативной памяти;

žуправление транзакциями;

žжурнализация и восстановление базы данных после сбо- ев;

žподдержание языков баз данных.

Функция управления данными во внешней памяти вклю-

чает в себя обеспечение необходимых структур внешней па-

49

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

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

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

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

ния буферами оперативной памяти. При управлении буфе-

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

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

Функция управления транзакциями - необходимое условие даже однопользовательских СУБД, тем более для многополь- зовательских. Транзакция есть единица активности пользова- теля при работе с БД.

Одно из основных требований к СУБД – ее надеж- ность. То есть СУБД должна восстанавливать последнее со-

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

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

50