Основы теории баз данных - freevar.comsait.freevar.com › 05_004_102_87str_bd_lectures_vop_otv.pdfЛекция 7. Инфологическое моделирование

Основы теории баз данных

Учебно-практическое пособие в схемах

Содержание

ПРЕДИСЛОВИЕ………………………………………………………………….. 3

РАЗДЕЛ 1. ЭЛЕМЕНТЫ ПРОБЛЕМАТИКИ БАЗ ДАННЫХ….……………... 5

Лекция 1. Основные понятия…………………………………………….. 6

Лекция 2. Основные понятия……………………………………………... 11

Лекция 3. Системы управления базами данных……………………….... 20

Лекция 4. Технология проектирования баз данных………….................. 28

Контрольные вопросы к разделу 1…………………………………….... 34

РАЗДЕЛ 2. ИНФОЛОГИЧЕСКОЕ ПРОЕКТИРОВАНИЕ…………………….. 36

Лекция 5. Предпроектное обследование (системный анализ) предметной области……………………………………………………….. 37

Лекция 6. Инфологическое моделирование предметной

области…………………………………………………………………… 42

…

Лекция 7. Инфологическое моделирование предметной

области……………………………………………………………………. 49

..

Контрольные вопросы к разделу 2……………………………………... .. 58

РАЗДЕЛ 3. СИНТАКСИЧЕСКИЕ МОДЕЛИ ДАННЫХ…………………….. . 60

Лекция 8. Модели данных СУБД……………………………………….. . 61

Контрольные вопросы к разделу 3…………………………………….... 73

РАЗДЕЛ 4. РЕЛЯЦИОННЫЙ ПОДХОД К СОЗДАНИЮ

БАЗ ДАННЫХ…………………………………………………..... . 75

Лекция 9. Реляционная модель данных с точки зрения

пользователя…………………………………………………………… 76

…

Лекция 10. Формализация реляционной таблицы и базы

данных……………………………………………………………………. 81

Лекция 11. Правила преобразования ER-диаграмм в схему

реляционной базы 91

данных……………………………………………….

Лекция 12. Минимизация числа подсхем схемы базы данных. 100

Лекция 13. Обеспечение целостности базы 112

данных……………………

Контрольные вопросы к разделу 4……………………………………... 123

РАЗДЕЛ 5. СИСТЕМЫ И ЯЗЫКИ ЗАПРОСОВ.

РЕЛЯЦИОННАЯ АЛГЕБРА…………………………….... . . .. . . 126

Лекция 14. Системы запросов. Булевы операции над

отношениями…………………………………………………………….. 127

Лекция 15. Специальные реляционные операции ……………………. 135

Лекция 16. Реляционные выражения как форма

представления запросов………………………………………………… 146

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

в форме реляционных выражений……………………………..... . .. . . 152

Контрольные вопросы к разделу 5……………………………………... 158

175

СПИСОК ЛИТЕРАТУРЫ…………………………………………………….... 161

176


Раздел

1

Элементы проблематики баз данных

Лекция 1. Основные понятия

Лекция 2. Основные понятия

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

Лекция 4. Технология проектирования баз данных

Данный раздел включает в себя четыре лекции. Он посвящен знаком-

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

тий, требования к организации баз данных. Рассматривается классическая

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

фазы жизненного цикла и этапы проектирования баз данных. Вводится по-

нятие CASE-средства.

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

1, можно найти в литературе [1 − 9, 14]. Практические аспекты этих вопро-

сов можно отыскать в работах [10 – 13, 15, 16].

По завершению изучения раздела 1 надо знать основные понятия и

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

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

чем суть концепции баз данных и СУБД. Знания следует самостоятельно

проверить путем ответов на контрольные вопросы.

5


Лекция Основные понятия

Лекция 1

1 • Соотношение понятий «информация и данные»

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

теории баз данных

• Две составляющие данных, которые рассмат-

риваются в теории баз данных

• Основные функции и компоненты информаци-

онной системы

• Типы информационных систем по значимости

выполняемых функций

• Банк данных как разновидность информацион-

ной системы

Соотношение понятий «информация» и «данные»

Семантика

(с греч.) –

смысл,

содержание

Синтаксис

(с греч.) –

правила

записи

Информация

Первичное (неопреде-

ляемое) понятие

Данные

Информация, пред-

ставленная в форме, удобной

для хранения, передачи и об-

работки

6

Одни и те же

данные могут

быть различ-

ным образом

истолкованы.

Одну и ту же

информацию

можно пред-

ставить

(записать,

сохранить)

многообраз- ными спосо-

бами

Прав ил

о ин терп ре

-

та

ци

и да

нн

ы х

Ф

ор

м а пре

дс та

вл е-

ни

я ин

ф ор

м ации

α

β


Примеры

Лекция 1

α1

β1

α1

β2

Ставка подоход-

ного налога

13

Ставка подоход-

ного налога

Тринадцать

α2

β1

α2

β2

Угол поворота

вала

13

Угол поворота

вала

Тринадцать

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

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

Употребляется при

рассмотрении вопросов,

связанных с семантикой

данных

Другими словами,

это семантический

аспект

7

Датологическая

Употребляется при

рассмотрении вопросов,

связанных с организаци-

ей данных

Другими словами,

это синтаксический

аспект

Основы теории баз данных Лекция 1

Две составляющие данных, которые рассматриваются

в теории баз данных

α

Интерпретация (семан-

Активная

состав-

ляющая

тика) данных

Собственно сами дан-

ные, представленные в опре-

деленной форме

β

Пассивная

состав-

ляющая

Данные сами по себе пассивны.

Активность им придают прикладные

программы – программы ввода, вывода

и обработки данных. Только програм-

мы обеспечивают интерпретацию и

связность данных

Основные функции и компоненты информационной системы

Информационная система – это система, включающая

информационные,

программные,

технические,

лингвистические,

организационные

средства,

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

сбора,

накопления,

передачи,

поиска,

обработки данных

8

сост

ав

ф ун кции


Типы информационных систем по значимости выполняемых

функций

Информационно-поисковые

системы

Основная функция:

поиск данных

Информацион-

ная компонента (база

данных) OLTP-систем

очень часто обновля-

ется. Поэтому она не

должна содержать из- быточного дублирова-

ния данных. Большин-

ство действующих

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

тем – OLTP-системы

Информацион-

ная компонента OLAP-

систем, как правило,

не обновляется (ее

называют хранилищем

данных). Поэтому

здесь возможно избы-

точное дублирование

данных. Системы при-

нятия решений стро-

ятся в виде OLAP-

систем

Системы


Основная функция:

обработка данных

OLTP

(Online Transaction Processing)

Системы оперативной


Функции: обновление и


OLAP

(Online Analytical Processing)

Системы оперативного

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

Функции: накопление, анализ и


Тип информационной сис-

темы во многом предопределяет

требования к организации ее ин-

формационной составляющей!

9

Одни и те

же данные

могут

быть раз- личным


Лекция 1

Банк данных как разновидность информационной системы

Для построения информационных систем применяются

различные инструментальные средства, принципы и методоло-

гии. Если при создании и функционировании информационной

системы используется СУБД, то к ней иногда применяют тер-

мин «банк данных»

Банк данных

Это информационная система, построенная на основе

концепции баз данных и СУБД

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

или системой БД, т.е. данные организованы специальным об-

разом

Программные средства содержат систему управления

базами данных

Технические средства: персональный компьютер или

сеть. Здесь все так же, как в любой информационной системе

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

средствами СУБД:

• ЯОД – язык описания данных,

• ЯМД – языки манипулирования данными

Организационные средства – средства администрирова-

ния базы данных (обеспечение целостности данных, сопрово-

ждение программных средств и т.п.)

Понятие информаци-

онной системы шире, чем по-

нятие банка данных

10

База данных и банк

данных – это не синонимы.

База данных – это лишь одна из компонент банка данных


Лекция Основные понятия

2 • Две точки зрения на базу данных

Лекция 2

• База данных как информационная модель

предметной области

• База данных как «склад» (хранилище) данных

• Неизбыточность и непротиворечивость базы

данных

• Демонстрационный пример

• Независимость базы данных от приложений

• Два основных средства достижения независи-

мости, предоставляемые современными СУБД

• Схема связей между приложениями и базой

данных (механизм прохождения запроса в

СУБД)

• Трехуровневая схема представления

метаданных

Две точки зрения на базу данных

Буквально термин «база» означает

Основа,

опора

(базовый эле-

мент и т.п.)

База данных

Это динамически об-

новляемая информационная

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

(части реального мира)

11

Склад,

хранилище

(овощная база

и т.п.)


Это «склад» (хранили-

ще) данных, предназначенных

для коллективного (корпора-

тивного), многократного и

многоцелевого использования

Ин фол

ог

ич

еск ая

точ ка

зр ени

я

Д ат

олог ич

ес

ка

я

точ ка

зрен ия


База данных как информационная модель предметной области


Это динамически

Предметная

область

��

обновляемая информаци-

онная модель предметной

области

Моделирование


Объектом моделирова-

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

базы

ния являются информацион-

ные процессы, протекающие в

предметной области.

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

предполагает абстрагирование

и отражение самого сущест- венного (основного).

В базе данных подлежат

хранению только опорные

данные, из которых можно по-

лучить другие.

Здесь везде база данных

– основа, опора!

12

данных – моделирование

предметной области – созда-

ние семантических и синтак-

сических моделей разной сте-

пени формализации: от сло-

весного описания предметной

области до определения струк-

туры базы данных на фор-

мальном языке описания дан-

ных СУБД


База данных как «склад» (хранилище) данных


Лекция 2

Часто говорят,

что база дан-

ных – поиме-

нованная со-

вокупность

данных,

организован-

ная

по правилу

«Три НЕ»

Это «склад» данных,

предназначенных для кор-

поративного, многократ-

ного и многоцелевого

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

Если «склад» дан-

ных используется многи-

ми пользователями и для

многих целей, то он дол-

жен иметь единую орга-

низацию и единое управ-

ление, которые удовле-

творяют ряду требований

Каково

назначе-

ние базы

данных?

Как

устроена

база

данных?

Требования к организации

базы данных –

правило «Три НЕ»

НЕизбыточность

НЕпротиворечивость +

+ достоверность +

+ полнота = целостность

НЕзависимость

от приложений

13

Требования к управлению

базой данных

Защита данных

Эффективность

доступа для каждого

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


Неизбыточность и непротиворечивость базы данных

База данных неизбы-

точна, если удаление какого-

либо элемента данных ведет к

потере информации о пред-

метной области

База данных непроти-

воречива, если все хранящие-

ся в ней данные удовлетво-

ряют определенным условиям

Избыточность

базы

Условия,

которым

данных проявляется в воз- должны удовлетворять хра-

никновении дублирования нимые в базе данные, назы-

(повторения) данных.

Различают избыточное

вают ограничениями целост-

ности.

и неизбыточное дублирова- Всякое ограничение

ние данных.

При избыточном дуб-

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

просто данные, а информа-

ция о предметной области

Избыточное дублирова-

ние относится к нежелательным

свойствам базы данных, в осо-

бенности для OLTP-систем. Оно

ведет к увеличению объема па-

мяти, необходимого для физи-

ческого хранения базы данных,

и времени обработки. Но самое

неприятное последствие избы-

точного дублирования – появ-

ление проблем, связанных с об-

новлением базы данных. Эти

проблемы называют аномалия-

ми актуализации

целостности задает некоторое

логико-семантическое свой-

ство данных и определяется

спецификой предметной об-

ласти. Это семантическая со-

ставляющая данных

Если база данных содер-

жит противоречивые данные и

они со временем накапливают- ся, то, в конце концов, база дан-

ных разрушается как единое це-

лое. Она перестает быть адек-

ватной информационной моде-

лью предметной области. Такая

база данных теряет практиче-

скую значимость и полезность!

Всякая избыточность базы данных

должна быть контролируема!

14


Демонстрационный пример

Лекция 2

Таб.

но-

мер

Ф.И.О.

Год

поступ-

ления

База данных «Список рабочих завода»

Долж- Раз- Но- Название цеха

ность ряд мер

цеха

1 2 3 4 5 6 7

100 Иванов И.И.

101 Петров П.П.

105 Егоров Е.Е.

170 Иванов Н.Н.

200 Жуков Р.Р.

1950

1990

1975

2000

1990

Токарь

Токарь

Токарь

Кузнец

Кузнец

5

5

7

7

4

20 Сборочный



30 Литейный

30 Кузнечный

Возможные ограничения целостности базы данных:

• каждый рабочий имеет уникальный табельный номер;

• номер цеха однозначно определяет название цеха;

• номер цеха – двузначное положительное целое число;

• допустимые значения для каждого столбца таблицыСписок рабочих

База данных противоречиваТаб. Ф.И.О.: нарушено однозначное

соответствие Год Долж- Раз Но-

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

ность ряд мер

База данных мер ления цеха

избыточна: 100 Иванов И.И. 1950 Токарь 5 20

избыточное 101 Петров П.П. 1987 Токарь 5 20

дублирование 105 Егоров Е.Е. 1975 Токарь 7 20

имеет место в 170 Иванов Н.Н. 2000 Кузнец 7 30

столбце 7. 200 Жуков Р.Р. 1990 Кузнец 4 30

Например, ин-

формация о

том, что цех 20

является сбо-

рочным, повто-

ряется трижды.

Но-

мер

цеха

Список цехов

Название цеха

В столбцах 3 –

6 также наблю-

дается дубли-

рование дан-

ных, но оно не

является избы-

точным

Для устранения

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

данных следует

представить в виде

15

двух таблиц


30 Литейный


Независимость базы данных от приложений

Приложение

Лекция 2

Это программа, с помощью которой пользователь работает

с базой данных. С одной базой данных могут работать много раз-

личных приложений

Для обычных файловых систем характерно наличие структурной

зависимости и зависимости по данным. При структурной зависимости

доступ к файлу зависит от его структуры – изменение структуры файла

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

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

го-либо поля) необходимо внесение соответствующих изменений в

программы, работающие с этим файлом

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

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

Это требование составляет суть концепции баз данных и СУБД!

Оно заключается в следующем: возможность осуществ-

лять реструктуризацию базы данных или ее реорганизацию, не

меняя при этом приложения

Логическая независимость

Возможность изменения

Физическая независимость

Возможность измене-

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

ления данных одного прило-

ния физического

представления данных

уровня

жения без корректировки дру-

гих приложений

Логический уровень − это то, как

видит данные пользователь: ему

не важны детали представления

данных в памяти системы

16

Физический уровень – это то,

как «видит» данные компьютер:

особенности структур и распо-

ложения данных на внешних

носителях


Два основных средства достижения независимости,

предоставляемые современными СУБД

Независимость базы данных от приложений достигается в ос-

новном средствами СУБД.

Однако при программировании приложений прикладным про-

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

мости. Так, например, тривиальное фиксирование в приложении числа

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

несмотря на мощные усилия по данному поводу СУБД

Современные СУБД предоставляют два средства обеспече-

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

дополняют друг друга. Они р еализу ются в СУБД в виде

архитектурных решений

Средство 1

Раздельное

хранение

Средство 2

Многоуровневое

пред-

описания метаданных, собст-

венно данных и приложений.

При этом взаимодействие ме-

жду ними осуществляют СУБД

и операционная система

Абсолютная независимость

недостижима!

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

числу уровней описания дан-

ных различают одно-, двух- и

трехуровневые СУБД. Боль-

шинство современных СУБД

имеют трехуровневую схему

представления метаданных

Метаданные (данные о данных) − специальная составляющая в со-

ставе СУБД, предназначенная для централизованного хранения информа-

ции об организации базы данных (структурах и типах данных, кодах защи-

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

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

и т.п.). Метаданные иногда называют словарем данных

17


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

(механизм прохождения запроса в СУБД)

Приложение 1

Приложение 2

…

Приложение k

При выполнении запроса на чтение данных, выданного при-

ложением, СУБД выполняет ряд действий, включающих:

• интерпретацию запроса;

• поиск описаний всех данных, на которые выдан запрос;

• формирование команд, по которым операционная система

пересылает с запоминающих устройств в буфер СУБД содер-

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

• выделение из этих записей нужных данных, их форматирование

(по необходимости) и пересылку в рабочую область

приложения.

Аналогичные действия выполняются при обновлении и вводе

данных

Метаданные

Разумеется, что меха-

низм прохождения запроса в

реальных СУБД гораздо

сложнее. Но этот упрощен-

ный алгоритм показывает,

насколько серьезными явля-

ются усилия СУБД по обес-

печению независимости базы

данных от приложений

18


Запрос – обращение к

базе данных, содержащее за-

дание на поиск данных со-

гласно некоторому условию.

Возможны запросы на об-

новление данных


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

Лекция 2

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

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

нальным институтом стандартов ANSI (American National Standards

Institute). В настоящее время данная архитектура СУБД является

наиболее распространенной

Концептуальный уровень

позволяет централизован-

1

Уровень внешних

моделей

Определяет точку

но управлять базой данных зрения на базу данных

отдельных приложений

Уровни

1 и 2

обеспе-

чивают

логиче-

скую

Внешняя

модель

данных 1

Внешняя

модель

данных 2

Внешняя

модель

… данных k

Уровни

2 и 3

гаран-

тируют

физиче-

скую

незави-

симость

Концептуальная (логическая) модель

Физическая модель

незави-

симость

Физический уровень

Отражает описа-

3

2

Логический уровень

Здесь база данных пред-

ние данных на носите-

лях

19

ставлена в наиболее общем виде,

который объединяет точки зре-

ния всех приложений


Лекция

3

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

• Состав и назначение СУБД

• СУБД – «слуга двух господ»: пользователя и

базы данных (две основные функции СУБД)

• Структура языковых средств СУБД

• Категории пользователей базы данных

• Функции разработчика базы данных

• Функции администратора базы данных

• Классификация СУБД по моделям данных

• Классификация СУБД по числу конечных

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

Состав и назначение СУБД

Система управления базами данных (СУБД)

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

языковых и

программных,

средств,

предназначенных для

создания,

ведения и

совместного использования

базы данных

многими пользователями

20

сост

ав

наз нач

ен ие


СУБД – «слуга двух господ»: пользователя и базы данных

(две основные функции СУБД)

В соответствии с концептуальным требованием независи-

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

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

запросом или приложением, в котором сформулирован запрос) и

базой данных. Поэтому часто говорят, что СУБД – «слуга двух

господ»: пользователя и базы данных

Согласно своим посредническим функциям СУБД выступа-

ет в качестве:

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

• инструментальных средств создания и ведения базы данных.

Таким образом, СУБД выполняет следующие две основные

функции

Функция 1

Предоставление

Функция 2

Поддержка

базы

средств и услуг для всех

категорий пользователей

базы данных

Эти этапы характерны

для любого материализован-

ного результата человеческой

деятельности!

Наиболее сложный и

ответственный из них – про-

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

21

данных на всех этапах ее

жизненного цикла:

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

• реализация (созда-

ние),

• эксплуатация (веде-

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

модернизация и

развитие)


Структура языковых средств СУБД

Лекция 3

Для создания базы данных и работы с ней СУБД предостав-

ляет пользователям разнообразные языковые средства

Язык описания данных

(ЯОД)

Языки манипулирования

данными (ЯМД)

Язык высокого Языки высокого

уровня декларативного уровня для определения

типа. Предназначен для

описания логической

структуры (схемы) базы

действий над данными

ЯМД навигационного типа

Декларация (с лат.) – объяв-

Это

процедурный

ление

Процедура (с лат.) –

установленная последова-

тельность действий

Спецификация (с лат.) – пе-

речисление отличительных

свойств

Такими языками являются:

язык для разработки при-

ложений

ЯМД спецификационного

типа

Это язык запросов –

непроцедурный язык для

выражения запросов к базе

данных

• SQL (Structured Query Language) – структурированный язык за-

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

в реляционных СУБД,

• QBE (Query-by-Example) – язык запросов по образцу. Применяется

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

22


Категории пользователей базы данных

Лекция 3

На каждом этапе своего жизненного цикла база данных свя-

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

Р

Разработчик

Это категория пользователей, которые взаимодей-

ствуют с базой данной во время ее проектирования, соз-

дания и реорганизации

А

Администратор

Это категория пользователей, которые контактиру-

ют с базой данных на всех этапах ее жизненного цикла

П

Конечные пользователи

Это основная категория пользователей, в интересах

которых и создается база данных. В зависимости от

особенностей создаваемой информационной системы

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

Разграничения в лицах всех категорий пользователей

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

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

ции РАП выполняются, как правило, одним лицом: сам про-

ектирую, сам управляю, сам использую!

23


Функции разработчика баз данных

Лекция 3

Р

Разработчик – это лицо или группа лиц, осуществляющих

следующие основные функции

Анализ и моделирование предметной области

Выявление ограничений целостности базы данных

Проектирование структуры базы данных

Разработка способов защиты и других средств

администрирования базы данных

Разработка приложений

Оптимизация и реструктуризация базы данных

после накопления сведений о ее функционировании

В группу Р входят:

• системные аналитики (анализируют и моделируют предметную

область),

• проектировщики структур баз данных,

• прикладные программисты (создают приложения),

• администратор базы данных,

• администраторы приложений (координируют работу прикладных

программистов при разработке приложений)

24


Функции администратора базы данных

Лекция 3

А

Администратор – это лицо или группа лиц, отвечающих за

осуществление следующих функций

Первоначальная загрузка и ведение базы данных

Защита данных

Анализ эффективности функционирования базы

Архивирование, копирование и восстановление

базы данных после сбоев и потери целостности

Поддержка системных и технических средств

Реорганизация базы данных и подключение новых

приложений

В группу А входят:

• системные программисты,

• прикладные программисты,

• администраторы приложений,

• операторы и специалисты по техническому обслуживанию

25


Классификация СУБД по моделям данных

Лекция 3

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

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

поддерживаемой СУБД.

Модель данных в первую очередь определяет основные структу-

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

ния). Кроме этого она задает возможные операции над допустимыми

структурами и ограничения целостности – специальные требования, ко-

торым должны подчиняться структуры (например, емкость структуры

– вместимость «тары»)

Каждая СУБД поддерживает ту или иную модель данных.

В зависимости от этой модели выделяют следующие классы

СУБД

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

Сетевые

Реляционные

Постреляционные

Многомерные

Объектно-

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

26

Эти СУБД поддерживают

классические модели данных.

Исторически появились раньше

других. Сейчас встречаются

крайне редко

Эти СУБД используют со-

временные модели данных, ко-

торые являются расширением и

обобщением классических моде-

лей. Таких СУБД большинство

В некоторых современных

СУБД поддерживается несколь-

ко моделей данных одновре-

менно


Классификация СУБД по числу конечных пользователей

По числу пользователей СУБД подразделяют на два класса

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

Многопользовательские

Предназначены для Предназначены для

создания, ведения и экс-

плуатации персональных баз

данных

Характерные особенно-

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

СУБД:

• поддержка реляционной

или постреляционной мо-

дели данных,

• монопольный доступ к

базе данных,

• сравнительно невысокие

требования к техниче-

ским средствам,

• развитый и удобный ин-

терфейс,

• разнообразный инстру-

ментарий для разработки

готовых приложений без

программирования,

• отсутствие средств адми-

нистрирования базы,

• поддержка только внеш-

него уровня представле-

ния метаданных.

Потребность в таких

СУБД не иссякает ввиду их

низкой стоимости и простоты

27

создания, ведения и экс-

плуатации централизован-

ных или распределенных

баз данных, функциони-

р у ющих в сети и о бслужи-

вающих много пользовате-

лей. Имеют полный набор

функций

Характерные особенно-

сти многопользовательских

СУБД:

• поддержка нескольких

моделей данных,

• развитые средства адми-

нистрирования баз дан-

ных и средства защиты

хранимой в них инфор-

мации,

• способность работать на

компьютерах различной

архитектуры под управ-

лением разных операци-

онных систем,

• трехуровневая схема

представления метадан-

ных, обеспечивающая не-

зависимость данных от

приложений и др.


Лекция

4

Технология проектирования баз данных

• Цель проектирования

• Две основные задачи проектирования

• Этапы проектирования базы данных

• Цепочка семантических и синтаксических

моделей, возникающих в процессе создания

проекта

• Проблемы автоматизации проектирования баз

данных

• Возможности современных CASE-средств

Цель проектирования

Что такое проект? Это схема – чертеж, эскиз некоторого устрой-

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

ность. Что такое проект базы данных? Это ответы (желательно фор-

мальные) на следующие основные вопросы:

• Каким образом следует отобразить в базе данных объекты пред-

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

семантике предметной области?

• Как обеспечить эффективность выполнения запросов к базе дан-

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

СУБД, структурировать данные и расположить их во внешней

памяти?

Основная цель процесса проектирования состоит в получе-

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

свойствами

Адекватно

отображал

предметную

область

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

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

требованиям пользова-

телей

28

Соответство-

вал правилу

«Три НЕ»


Две основные задачи проектирования

Лекция 4

Исходные

данные

Словес-

ное опи-

сание

предмет- ной

области

Создание проекта базы данных

предполагает решение двух основ-

ных задач

Задача 1

Разработка структуры базы

данных

Задача 2

Разработка приложений.

Разработка средств адми-

нистрирования, не преду-

смотренных СУБД

Результа-

ты

Структура

базы дан-

ных в тер-

минах

ЯОД

Тексты

программ

на ЯМД

СУБД

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

задача 1. Решение задач 1, 2 – это отображение полностью неформализо-

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

обработки данных. Выполнить адекватно это отображение за один шаг в

общем случае не представляется возможным. Поэтому процесс проекти-

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

цепочки соответствующих отображений (моделей).

Этапы 1 – 2 образуют фазу инфологического проектирования.

Этапы 3 – 5 составляют фазу датологического проектирования

29


Этапы проектирования базы данных

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

Восприятие, Выявление ин-

изучение и описание формационных по-

информационных требностей пользова-

процессов предметной телей. Формулирова-

области ние требований к со-

держанию и обработ-

ке данных

Построение инфологической модели


Выбор модели данных и СУБД

Построение вариантов логической

структуры базы данных, их анализ и выбор

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

правилом «Три НЕ»

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

структуры базы данных, их анализ и выбо р

согласно требованиям к эксплуатационным

характеристикам базы данных: вр емя, па-

мять, уровень защиты данных

30

Лекция 4

1-й этап –

предпро-

ектное

обследова-

ние пред-

метной

области

2-й этап –

семантиче-

ская струк-

туризация

предмет- ной

области

3-й этап –

выбор пра-

вил струк-

турирова-

ния данных

и инстру-

ментария

4-й этап –

логическая

структури-

зация

данных

5-й этап –

физическая

структури-

зация

данных


Цепочка семантических и синтаксических моделей,

возникающих в процессе создания проекта

Семанти-

ческие

модели

предмет-

ной

области.

Строятся

на фазе

инфологи-

ческого

проектиро-

вания

Часто эту

модель на-

зывают концепту-

альной

Синтакси-

ческие

модели

данных.

Строятся

на фазе

датологи-

ческого

проектиро-

вания

S1

S2

M1

M2

Неформализованное словесное

описание предметной области с ис-

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

Дает ответ на вопросы:

• Что хранить в базе?

• Как обрабатывать данные?

Описание связей между данны-

ми с использованием некоторой фор-

мализованной системы нотаций (сис-

темы условных обозначений, языка за-

висимостей). Такое описание называ-

ют инфологической моделью предмет- ной области. Эта модель дает ответ на

вопрос:

• Как связаны между собой дан-

ные?

Эти связи – основа выбора модели

данных и проектных решений относи-

тельно структуризации данных

Логическая (машинно- и СУБД-

независимая) модель. Задает структуру

базы данных в терминах выбранной

модели данных (например, в терминах

таблиц). Дает ответ на вопрос:

• Как хранить данные?

Физическая модель. Определяет

структуру базы данных в терминах

ЯМД выбранной СУБД. Дает ответ на

вопрос:

• Как хранить данные?

Здесь указываются носители, методы

доступа и способы защиты данных

31


Проблемы автоматизации проектирования баз данных

Это творческий процесс!

Современные

Это скорее искусство, чем

наука!

Этапы 1 и 3

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

(средства автома-

тизации проекти-

рования) позволя-

ют создавать син-

таксические моде-

Процесс

формализуются.

На этапе 2 только

человек способен

построить в своей

голове инфологи-

ли базы данных на проектирования

ческую

модель

этапах 4 и 5, исхо-

дя из инфологиче-

ской модели пред-

метной области,

построенной чело-

веком на этапе 2

Комплексная автоматиза-

ция невозможна!

базы данных предметной облас-

ти. А лишь потом

для описания этой

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

соответствующие

CASE-средства

На всех этапах требуется

участие человека!

Проектирование базы данных с построением цепочки соответст-

вующих семантических и синтаксических моделей не является последова-

тельным процессом. Это скорее итеративный процесс с постоянной обрат-

ной связью для проверки предыдущих этапов. Решение о возврате на тре-

буемый этап принимает человек!

32


Возможности современных CASE-средств

Лекция 4

Термин CASE (Computer Aided Software Engineering) дословно

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

компьютера. В настоящее время этот термин получил более широкий

смысл, означающий автоматизацию разработки информационных сис-

тем

CASE-средства

Это программные средства, автоматизирующие некоторые

этапы разработки (инжиниринга) информационных систем.

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

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

цию и анализ вариантов логических и физических моделей базы

данных, создание приложений и т.п.

Современная CASE-индустрия объединяет сотни известных фирм

и компаний. В настоящее время практически все серьезные проекты

осуществляются с использованием CASE-средств. Общее число распро-

страняемых на рынке программных продуктов CASE-средств составля-

ет порядка 500 наименований.

Многие CASE-средства не ограничиваются только разработкой.

Они чаще всего обеспечивают повторную разработку – реинжиниринг

По ориентации на этапы проектирования выделяют сле-

дующие типы CASE-средств: инструменты анализа и моделиро-

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

средства разработки приложений.

По степени независимости от СУБД различают независи-

мые и встроенные CASE-системы

33


Раздел

2

Инфологическое проектирование

Лекция 5. Предпроектное обследование

(системный анализ) предметной области

Лекция 6. Инфологическое моделирование


Лекция 7. Инфологическое моделирование


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

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

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

мые на этой фазе, направлены на изучение, анализ и моделирование пред-

метной области, исходя из ее семантики. Эта фаза включает в себя первые

два этапа технологической цепочки проектирования базы данных: пред-

проектное обследование (или системный анализ) и инфологическое моде-

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

модели предметной области (словесное описание и инфологическая мо-

дель). Существует несколько систем нотаций для описания инфологиче-

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

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

мя стала фактически стандартом.

Главная задача данного раздела – освоение формализмов ЕR-модели

и отображение с их помощью семантической структуры предметной об-

ласти. Детально о ЕR-модели можно прочесть в работах [1 − 5].

В результате надо знать приемы анализа предметной области и пра-

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

знания в практике проектирования баз данных различного назначения.

Знания рекомендуется самостоятельно проверить путем ответов на кон-

трольные вопросы.

36


Контрольные вопросы к разделу 1

1. Являются ли синонимами понятия «информация» и «данные»? Укажи-

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

2. Что подразумевают под понятием «информационная система»? Назо-

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

назначение. Какие существуют основные разновидности информаци-

онных систем по значимости выполняемых ими функций?

3. Что представляет собой банк данных? Какие компоненты входят в его

состав?

4. Какое из понятий шире: «информационная система» или «банк дан-

ных»?

5. В чем специфика OLTP-систем? В чем специфика OLAP-систем?

6. Если база данных – информационная модель предметной области, то

что в этом случае является объектом моделирования?

7. Каково назначение базы данных? Каким образом должна быть устрое-

на база данных, чтобы служить «складом» корпоративных данных?

8. Что предполагает неизбыточность и непротиворечивость базы данных?

9. Каковы возможные последствия избыточности и противоречивости

базы данных?

10. Что означает избыточное дублирование данных?

11. Для каких типов информационных систем наиболее актуально устра-

нение избыточного дублирования?

12. Что предполагает целостность и непротиворечивость базы данных?

13. Каково назначение ограничений целостности? Приведите примеры

ограничений целостности базы данных.

14. Что понимается под приложением базы данных? В каких случаях воз-

никает необходимость его разработки?

34


15. Что такое независимость данных от приложений? Почему так важно ее

обеспечить?

16. Что предполагает логическая и физическая независимость базы данных

от приложений?

17. Какими двумя основными способами независимость достигается в

СУБД?

18. Что такое запрос к базе данных? Каков простейший механизм прохож-

дения запроса в СУБД?

19. Для чего предназначен словарь данных (метаданные)?

20. Как выглядит трехуровневая структура метаданных, предложенная

американским комитетом по стандартизации ANSI?

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

ми данных существуют? Укажите основные функции администратора

базы данных.

22. Сколько этапов имеет жизненный цикл базы данных? Каково их назна-

чение?

23. Каково назначение СУБД? Какими возможностями обладают совре-

менные СУБД? Объясните преимущества, которые несет в себе ис-

пользование СУБД.

24. Какие языки входят в состав языковых средств СУБД?

25. Каковы характерные особенности персональных СУБД? Приведите

примеры таких СУБД.

26. Чем многопользовательские СУБД отличаются от персональных? При-

ведите примеры таких СУБД.

27. Сколько этапов предусматривает технология проектирования баз дан-

ных? Укажите назначение этих этапов. На каких этапах возможно при-

менение современных CASE-средств?

28. Чем характеризуется современное состояние технологии баз данных?

Поясните суть концепции баз данных и СУБД.

35


Лекция Предпроектное обследование

Лекция 5

5

Цель

(системный анализ) предметной области

• Цель системного анализа

• Действующие лица и способ их

взаимодействия

• Основные вопросы

• Оформление результатов системного анализа


Цель системного анализа

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

сбор исходных данных для решения

двух основных задач проектирования

Проектирование Разработка приложений

структуры базы данных

Результатом достижения этой цели должна быть семан-

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

словесного описания. Необходимо, чтобы эта модель давала

ответы на вопросы:

• Что хранить в базе данных?

• Как обрабатывать данные?

Результат обследования официально оформляется в ви-

де технического задания на разработку с обоснованием эко-

номической целесообразности проекта

37


Действующие лица и способ их взаимодействия

Потенциальные конечные пользовате-

ли базы данных – основной источник

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

Лица, принимающие решения

(руководители предприятия,

подразделений)

Непосредственные исполнители

управленческих и

производственных функций

Способ взаимодействия

– интервью

Консультант по предметной

области

(играет роль переводчика)

Системный аналитик –

специалист в области

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

Лекция 5

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

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

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

о предметной области по принципу «от общего к частному». Качество

и глубина обследования во многом зависят от уровня системного мыш-

ления, опыта и интуиции системного аналитика!

38

Раз раб

от

чи

к

Вопросы

Отв ет

ы

Зак

аз чик


Основные вопросы

Лекция 5

В настоящее время не существует какой-либо единой методики

проведения системного анализа предметной области. Здесь можно

лишь рекомендовать следующий перечень вопросов, ответы на кото-

рые позволяют создать проект базы данных и разработать приложения

к ней

1. Каковы границы исследуемой предметной области?

Что следует учесть в настоящее время? Какие фрагменты пред-

метной области предполагается включить в дальнейшем?

2. Какой тип имеет информационная система, составляю-

щей которой будет разрабатываемая база данных?

Например, это информационно-поисковая система, OLTP-система

или OLAP система? База данных должна быть централизованной

или распределенной? Какие в рассматриваемой ситуации понадо-

бятся коммуникационные средства? Это будет инжиниринг (новая

разработка) или реинжиниринг (повторная разработка)?

3. Можно ли в принципе осуществить (технологически и

экономически) идею создания желаемой заказчиком базы дан-

ных? Другими словами, существует ли на рынке требуемое для

реализации плана оборудование, программное обеспечение, а на

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

сопровождения базы данных? Сколько для этого потребуется

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

идеи?

4. Кто составляет круг потенциальных пользователей бу-

дущей базы данных? Каковы информационные потребности

пользователей: кому и что требуется, в каком виде и как часто?

39


5. Какова модель движения важных материальных объек-

тов (продукции и/или денежных средств)? В чем специфика и

содержание существующего документооборота? Последнее

предполагает получение ответов на следующие частные вопросы:

• Каков перечень основных документов?

• Какой вид они имеют (бумажный или электронный)?

• Где и кем они создаются?

• Куда и кому они передаются?

• Каков перечень элементарных данных (атрибутов) для каж-

дого документа?

• Каково множество допустимых значений для каждого эле-

ментарного данного?

6. В чем заключаются особенности обработки и обновле-

ния данных? Это подразумевает получение ответов на следующие

вопросы:

• Каковы связи между документами и их элементарными дан-

ными?

• Какие данные являются исходными и какие вычисляемыми?

• По каким правилам и формулам идет расчет вычисляемых

данных?

• Где и кем они создаются?

• Какие данные обновляются одновременно и как часто?

7. Нужно ли обновлять технические средства? И если

нужно, то каким образом?

40

Одни и те

же данные

могут



Оформление результатов системного анализа


Техническое задание на разработку

Лекция 5

Это документ, в котором оформляются

результаты системного анализа предметной

области и определяются требования к базе

данных

Проходит

согласование и

утверждение у

Заказчика

ное

Неформаль-

описание

Требования к содержанию и

обновлению базы данных:

предметной об- • список атрибутов, значения ко-

ласти с использо-

ванием естествен-

ного языка, мате-

матических фор-

мул, схем, таблиц,

графиков и т.п.

Состав и

функции информа-

ционной системы

Требования к

эксплуатационным

характеристикам

базы данных:

• уровень защи-

ты данных;

• время реакции

на запросы

торых требуется хранить в базе

данных;

• связи между атрибутами;

• множество допустимых значе-

ний для каждого атрибута;

• одновременно обновляемые ат-

рибуты

Требования к техническим и

системным программным средст-

вам:

• архитектура сети;

• СУБД, тип операционной сис-

темы и т.п.

Технико-экономическое обосно-

вание:

• стоимость разработки;

• сроки разработки и окупаемости

41


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

6 предметной области

•Цель моделирования

Лекция 6

Цель

• Семантическая структуризация предметной

области

• Средства выражения результатов

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

• Общая характеристика ER-модели

• Сущность как конструктивный элемент

ER-модели

• Атрибуты и ключи сущностей

• Демонстрационный пример различных

способов задания атрибутов

Цель моделирования

Построение

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

(семантической структурной)

модели


Инфологическая модель строится на втором этапе процесса проек-

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

вающая структуру исследуемой предметной области. Она призвана вы-

явить логико-семантические связи между данными. Эти связи – основа

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

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

ления ограничений целостности будущей базы данных

42


Семантическая структуризация предметной области

Семантическая структурная модель включает в

себя две компоненты

Объектно-связное

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


Ограничения

целостности

Таким образом, семантическая структуризация

предполагает выполнение следующих действий

Выделение классов

однородных объектов

Определение

свойств (атрибутов) для

каждого класса объектов

Установление свя-

зей между классами объ-

ектов

Нахождение доме-

нов – множеств допусти-

мых значений атрибутов

Поиск ключей и

других связей типа «ат-

рибут-атрибут»

Однородность объ-

ектов означает наличие у

них одинаковых свойств

Для построения семантической структурной модели необ-

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

лить, как она устроена

43


Средства выражения результатов моделирования

После того как объектно-связное представление предметной облас-

ти выяснено, необходимо его описать.

С одной стороны, это описание должно быть настолько глубоким,

чтобы на его основании можно было генерировать различные логические

и физические модели базы данных.

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

понималось не только специалистами по базам данных.

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

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

ных является частью крупной корпоративной системы, то в этом процессе

участвуют различные специалисты. Поэтому глубокое, ясное и лаконич-

ное изображение предметной области весьма полезно для уточнения дета-

лей проекта и координации действий

Существует несколько систем

нотаций (условных обозначений, язы-

ков) для описания объектно-связного

Чертеж,

выполнен-

ный по

всем пра-

вилам

ЕСКД, по-

нятен лю-

бому ин-

женеру или

рабочему

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

Среди них преобладают средства гра-

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

напоминают язык блок-схем для о пи-

сания алгоритмов или правила оформ-

ления конструкторской документации.

Наиболее простые и понятные

обозначения имеет модель «сущность-

связь» или «Entity Relationship model»

(кратко ER-модель).

Объектно-связное представление

предметной области в терминах (обо-

значениях) ER-модели называется

ER-диаграммой

44

Описание

алгоритма

в виде

блок-

схемы мо-

жет быть

прочитано

всяким

програм-

мистом


Общая характеристика ER-модели

Лекция 6

ER-модель была предложена Питером Ченом в 1976 году. В

дальнейшем была развита К. Брахманом и Д. Ренером. В настоящее

время ER-модель стала фактически стандартом для семантической

структуризации предметной области. Многие современные CASE-

средства содержат инструменты описания предметной области в обо-

значениях этой модели (Erwin, BPwin и др.)

Инфологическая модель предметной области в терминах

ER-модели имеет две составляющие

ER-диаграмма

Ограничения целостности

ER-диаграмма изображается с помощью трех конструктив-

ных элементов

сущность

атрибут

связь

Фактор времени учитывается с помощью атрибутов.

Некоторые ограничения целостности задаются на

ER-диаграмме, другие описываются на естественном языке

Достоинства ER-модели

Язык обозначений

простой и понятный как

для разработчиков, так и

для заказчиков базы дан-

ных

45

Возможен переход

по формальным правилам

от ER-диаграммы к логи-

ческой структуре реляци-

онной базы данных


Сущность как конструктивный элемент ER-модели

В настоящий момент не существует единой общепринятой системы

обозначений для конструктивных элементов ER-модели и разные авторы

изданий и CASE-средства применяют разные графические нотации. Одна-

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

используется классическая система обозначений П. Чена

Конструктивный

элемент

Назначение

Обозначение

Имя типа

сущности.

Как прави-

ло, это имя

существи-

тельное

Параметры

Минималь-

ность заклю-

чается в том,

что удаление

любого атри-

бута из ключа

нарушает уни-

кальность его

значений

Сущность

Для задания класса однородных и различимых

между собой объектов предметной области

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

Тип сущности – класс объектов.

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

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

Экземпляры сущности должны быть различи-

мы, т.е. у сущности обязаны быть свойства,

уникальные для каждого экземпляра этой

сущности

Для всякой сущности на ER-диаграмме необ-

ходимо задать:

1. Имя типа сущности (должно быть уникаль-

ным в пределах одной ER-диаграммы).

2. Множество свойств (атрибутов).

3. Все возможные ключи сущности.

Ключ сущности – это минимальный набор ат-

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

ждого экземпляра

46


Атрибуты и ключи сущностей

Конструктивный Атрибут

элемент

Лекция 6



Имя

атрибута

Параметры

Для задания свойств сущностей и связей. Зна-

чения атрибутов представляют основную

часть информации, хранящейся в базе данных

Должность

Овал с именем атрибута внутри соединяется

линией с соответствующей сущностью или

связью. Иногда перечень имен атрибутов за-

писывается рядом с графическим обозначени-

ем сущности

Для всякого атрибута на ER-диаграмме требу-

ется указать:

1. Имя атрибута (должно быть уникальным в

пределах одной ER-диаграммы).

2. Семантику (толкование).

3. Домен – множество допустимых значений

атрибута.

Атр ибут, вхо дящий в со став какого-либо

ключа сущности, называется ключевым

Несколько замечаний

1. Всякая сущность обязательно имеет хотя бы один ключ.

2. Ключ, состоящий из нескольких атрибутов, называется составным.

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

качестве первичного, а остальные – потенциальных.

4. На ER-диаграмме все ключи выделяются подчеркиванием (каждый

ключ отдельной сплошной линией).

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

47


Демонстрационный пример различных способов

задания атрибутов

Способ обозначения атрибутов овалами

Лекция 6

Серия паспорта

Студент

Номер паспорта

Сущность

Студент имеет

два ключа, один из

которых составной.

Достоинство этого

способа: возмож-

Номер зачетной книжки

Ф.И.О. студента

Факультет

Номер группы

ность указания в

названии атрибута

его семантики, в

результате чего

ER-диаграмма хо-

рошо читается.

Недостаток: если

атрибутов много,

то наглядность

ER-диаграммы те-

ряется

Способ обозначения атрибутов списком

Студент

А1А2А3А4А5А6

Таблица со списком

атрибутов располагается

на полях ER-диаграммы

или прикладывается к

ней. Достоинство данно-

го способа: компактность

ER-диаграммы

Идентифика-

тор атрибута

А1

А2

А3

А4

А5

А6

48

Семантика

Серия паспорта

Номер паспорта

Номер зачетной

книжки

Ф.И.О.

Факультет

Номер группы

До-

мен

С(4)

N(6)

С(6)

С(30)

С(15)

С(5)


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

7 предметной области

Лекция 7

• Связь как конструктивный элемент ER-модели

• Бинарные связи, их параметры и обозначения

• Инфологическая модель фрагмента системы

управления кадрами в терминах ER-модели

• Инфологическая модель деятельности

городской службы по ремонту фасадов домов

• Методические рекомендации по построению

ER-диаграмм

Связь как конструктивный элемент ER-модели

Все в окружающем нас мире связано между собой. Это каса-

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

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

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

При ER-моделировании выделяют связи между свойствами

объектов и между классами объектов.

Связи между свойствами объектов описываются с помощью

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

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

всех других атрибутов однозначно зависят от значений ключа.

Отношения между классами объектов задаются с помощью

конструктивного элемента, называемого связью.

Особая важность для проектирования базы данных информа-

ции о связях требует особой тщательности в указании всех возмож-

ных параметров выявленных связей!

49


Конструктивный

элемент

Связь

Лекция 7



Имя

типа связи

(в глаголь-

ной форме)

Параметры

Степень

связи и

классы

принад-

лежности

задаются

только для

бинарных

связей

Для определения отношений между сущностями

Читает

Ромб с именем типа связи, соединяющий, ассо-

циированные сущности.

Тип связи отражает отношение между типами

сущностей (классами объектов).

Экземпляр связи описывает отношение между эк-

земплярами сущностей (конкретными представи-

телями классов объектов)

Для определения связи на ER-диаграмме следует

задать:

1. Имя типа связи (должно быть уникальным в

пределах одной ER-диаграммы).

2. Арность – число связываемых сущностей и их

типы.

3. Степень связи: «один-к-одному» (1 : 1 ),

«один-ко-многим» (1 : N), «многие-ко-многим»

(M : N).

4. Класс принадлежности к связи для каждой из

связываемых сущностей: обязательный или

необязательный.

5. Атрибуты связи, если они есть

Связь между двумя типами сущностей называется бинарной,

между тремя – тернарной, между четырьмя – кватернарной и в общем

случае – n-арной

50


Бинарные связи, их параметры и обозначения

Лекция 7

Человек в большинстве случаев мыслит на уровне бинарных

связей! Важнейшими параметрами таких связей являются степень свя-

зи (или кардинальное число) и класс принадлежности (или модаль-

ность связи)

Степень связи отражает однократность или многократность

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

зей

«Один-к-одному» (1 : 1)

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

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

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

одним экземпляром первой сущности

«Один-ко-многим» (1 : N)

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

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

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

ром первой сущности

«Многие-ко-многим» (M : N)

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

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

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

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

общий тип связи

51


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

иметь один из двух классов принадлежности

Обязательный

Соответствует модаль-

ности «должен». Это означа-

ет, что каждый экземпляр

сущности обязан (должен)

быть связан с каким-либо эк-

земпляром другой сущности

Необязательный

Соответствует модаль-

ности «может». Это означа-

ет, что каждый экземпляр

сущности может быть сво-

бодным от связи

r1

K1A1A2…An

r1

K1A1A2…An

r1

K1A1A2…An

1

1

M

s

s

s

1

N

N

r2

K2C1C2…Cm

r2

K2C1C2…Cm

r2

K2C1C2…Cm

Степень связи

(1 : 1) с обяза-

тельными класса-

ми принадлежно-

сти для обеих

сущностей


(1 : N) с обяза-

тельным классом

принадлежности

только для

сущности r2


(M : N) с необяза-

тельными класса-

ми принадлежно-

сти для обеих

сущностей

52


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

кадрами в терминах ER-модели

Это пример на чтение

ER-диаграммы!

Вуз

Иденти-

фикатор

А1

А2

А3

Семантика

Шифр вуза

Название

Город

До-

мен

С(15)

С(30)

С(15)

А1А2А3

M

Иденти-

фикатор

Т1

Т2

Семантика

Дата окончания

Серия и номер

До-

мен

D

С(30)

Атрибу-

ты

связи

Окончил

Т1Т2Т3

N

Служащий

Т3

Иденти-

фикатор

В1

В2

В3

диплома

Специальность

Семантика

Табельный номер

Ф.И.О.

Дата рождения

С(15)

До-

мен

N(6)

С(30)

D

В1В2В3В4В5 M

Имеет

N

В4

В5

Иденти-

фикатор

С1

Дата поступления

на предприятие

Должность

Семантика

Серия и номер

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

D

С(5)

До-

мен

С(30)

Ребенок

С1С2С3

С2

С3

рождении

Ф.И.О.

Дата рождения

С(30)

D

Ограничения целостности:

• домены всех атрибутов (см. в таблицах);

• ключи сущностей (см. на ER-диаграмме);

• связи типа «атрибут-атрибут»: ⟨значение В3⟩ < ⟨значение В4⟩,

⟨значение В3⟩ < ⟨значение Т1⟩, ⟨значение В3⟩ < ⟨значение С3⟩

53


Инфологическая модель деятельности городской службы

по ремонту фасадов домов

Это пример на составление

ER-диаграммы!

Объектом моделирования (предметной областью) высту-

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

Назначение базы данных:

• учет занятости мастеров,

• расчет оплаты труда мастеров.

В процессе системного анализа предметной области был уста-

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

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

Список атрибутов

Идентификатор

Тn

F

R

U

D

Р

С

Tr

Data

V

Семантика

Табельный номер мастера

Ф.И.О.

Номер квалификационного

разряда мастера

Название улицы

Номер дома

Площадь ремонта, м2

Категория сложности

ремонта

Тариф (оплата за 1 м2

ремонта согласно разряду)

Дата работы мастера

Объем работы, выполнен-

ной мастером за день, м2

54

Домен

N(6)

C(30)

N(2)

C(20)

С(4)

N(7.1)

N(3.1)

N(5.1)

D

N(5.1)


.

.

.

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

атрибутами:

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

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

мастера,

• учитывать следует только те дома, которые подлежат ремонту,

• номер разряда задает значение тарифа,

• каждый рабочий день мастер может работать на ремонте только од-

ного дома,

• один и тот же дом могут одновременно ремонтировать несколько

мастеров,

• некоторые мастера могут быть временно без работы,

• зарплата мастера за месяц начисляется (по сдельной форме) согласно

формуле

Tr ⋅ (∑ Vi⋅ Ci),

где суммирование берется по всем дням работы мастера в заданном

месяце, а значение Tr соответствует разряду мастера

Возможная ER-диаграмма

N 1

Мастер

N TnF

Имеет

1

Ремонт

Data

V

Дом

UDPC

Тарифная

сетка

RTr

Ограничения целостности:

• домены атрибутов (см. список атрибутов),

• ключи сущностей (см. ER-диаграмму),

• условие ⟨значение V⟩ < ⟨значение P⟩

55


Методические рекомендации по построению ER-диаграмм

Непротиворе-

чивость


Неизбыточ-

ность


Всякое имя на ER-диаграмме должно быть

уникальным

Всякий атрибут может быть отнесен

только к одной сущности или одной связи

Одна и та же сущность может участвовать в нескольких свя-

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

несколько связей с разными смысловыми нагрузками

Неоднознач-

ность выра-

жения

Определения конструктивных элементов

не отличаются особой конкретностью.

Поэтому два разработчика, моделируя одну

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

различные ER-диаграммы

Всякая построенная ER-диаграмма должна быть верифици-

рована (проверена) на возможность реализации всех запросов к

базе данных, определенных техническим заданием. Проверка вы-

полняется путем установления наличия на ER-диаграмме необхо-

димых атрибутов

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

пример, различными разработчиками, то предпочтение рекомен-

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

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

56


Проблема

Если предметная область обширна,

Лекция 7

размерности то ее рекомендуется разбивать на фрагменты

и проводить ER-моделирование в два этапа.

Этап 1: построение локальных представлений

(локальных ER-диаграмм).

Этап 2: объединение локальных представлений

в глобальное. Это выполняется с помощью

специальных правил композиции

(идентичность, агрегация, обобщение).

Подробнее см. в работе [6]

В локальном представлении рекомендуется использовать

не более 9 сущностей. Эта рекомендация основана на правиле

теории информации «магическое число 7 + 2», т.е. число взаимо-

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

человек, равно примерно семи

Очевидно,

что

даже

хорошо спроектированная

ER-диаграмма будет обязательно изменяться в процессе создания

и эксплуатации базы данных. ER-диаграмма – важнейшая часть

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

нейшем может быть улучшен и расширен.

Возможно, наибольшая выгода использования ER-диаграмм

состоит в понимании и документировании информационных про-

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

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

когда после достаточно продолжительной эксплуатации базы

данных наступает время ее реструктуризации

57



1. Какова цель предпроектного обследования предметной области? Как

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

предметной области?

2. Почему опрос потенциальных пользователей базы данных рекоменду-

ется вести «сверху вниз» − от руководителей к конкретным исполните-

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

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

предпроектное обследование предметной области?

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

следования? Какие разделы содержит этот документ?

5. Какие две компоненты содержит инфологическая модель предметной

области?

6. Что предполагает семантическая структуризация предметной области?

7. Кто является автором ER-модели?

8. Какие основные конструктивные элементы входят в ER-модель?

9. Что отражает ER-диаграмма?

10. Каково назначение конструктивного элемента «сущность»? Что значит

определить (задать) на ER-диаграмме сущность?

11. Какой набор атрибутов принято считать ключом сущности? Всякая ли

сущность имеет ключ?

12. Для чего предназначен конструктивный элемент «атрибут»? Что зна-

чит определить (задать) на ER-диаграмме атрибут?

13. Могут ли связи иметь атрибуты?

14. Какие атрибуты называются ключевыми?

15. Могут ли сущности не иметь ключевых атрибутов? Могут ли сущности

не иметь неключевых атрибутов?

58


16. Что описывает конструктивный элемент «связь»? Что значит опреде-

лить (задать) на ER-диаграмме связь между сущностями?

17. Сколько типов сущностей связывает бинарная связь? Какие параметры

имеет бинарная связь?

18. Может ли одна и та же сущность участвовать в нескольких связях?

19. Что отражает степень связи? Какие типы бинарных связей возможны?

20. Каким может быть класс принадлежности сущности к связи?

21. Как на ER-диаграммах обозначаются степень связи и классы принад-

лежности?

22. Как учитывается фактор времени на ER-диаграммах?

23. Могут ли на непустой ER-диаграмме отсутствовать какие-либо конст-

руктивные элементы ER-модели?

24. Известно, что всякий используемый на ER-диаграмме конструктивный

элемент ER-модели должен иметь уникальное имя. Что гарантирует это

требование?

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

сущности или одной связи. Какова цель этого условия?

26. Можно ли сказать, что всякой предметной области соответствует одна-

единственная ER-диаграмма?

27. Если предметная область обширна, то она разбивается на фрагменты и

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

этапы?

28. Известно, что в локальном представлении предметной области (ло-

кальной ER-диаграмме) рекомендуется использовать не более 9 сущно-

стей. На чем основана эта рекомендация?

29. Какие современные CASE-средства содержат инструменты описания

предметной области в обозначениях ER-модели?

30. В чем достоинства ER-модели?

31. Существуют ли ограничения на область применения ER-модели?

59


Раздел

3

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

Лекция 8. Модели данных СУБД

Развитие теории и практики проектирования и эксплуатации баз

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

рассматривались модели представления предметной области. В настоящем

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

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

мантический), а датологический (синтаксический) аспект рассмотрения

будущей базы данных. В этой связи модели данных часто называют син-

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

К классическим причисляют следующие модели данных: иерархиче-

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

других. Из них в настоящее время широко используется только реляцион-

ная модель. К современным моделям данных (моделям, которые появились

в последние годы) относят: постреляционную, многомерную, объектно-

ориентированную.

Характеристика классических и современных моделей приводится

ниже. В заключении данного раздела рассматривается третий этап тех-

нологической цепочки проектирования базы данных – этап выбора

средств реализации базы данных (модели данных, СУБД и средств разра-

ботки приложений).

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

найти в работах [1 − 3, 14]. Рекомендации по выбору СУБД приведены в

[1, 7]. По завершению изучения раздела 3 необходимо знать принципы

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

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

контрольные вопросы.

60


Лекция Модели данных СУБД

8 •Определение модели данных

•Компоненты модели

Лекция 8

• Языки программирования и модели данных

• Компоненты моделей данных СУБД

• Модели, представляющие исторический

интерес

• Наиболее распространенные модели

• Специальные модели

• Выбор средств реализации базы данных

Определение модели данных

Модель данных – некоторая абстракция, предназначенная

для определения:

①

②

③

правил структурирования данных,

процессов динамического изменения данных,

допустимых состояний взаимосвязанных данных

Понятие «модель данных» является концептуальным в области ин-

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

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

базируется на некоторой модели данных

61


Компоненты модели данных

Лекция 8

В соответствии со своим назначением, любая модель

данных состоит из трех компонент

①

②

③

Структурная компонента

Указывает основные структуры данных и правила

построения одних структур на основе других

Манипуляционная компонента

Определяет основные операции над допустимыми

структурами данных

Целостная компонента

Описывает ограничения целостности – специальные

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

данных (например, «вместимость» структуры)

Некоторые замечания

1. Основные компоненты модели данных тесно

взаимосвязаны и в различных конкретных моде-

лях могут быть реализованы различными спосо-

бами.

2. Для разработчиков информационных систем мо-

дель данных является средством логической (ма-

шинно-независимой) структуризации данных. В

первую очередь она задает виды «тары», в кото-

рую размещаются данные для хранения.

3. Не следует отождествлять понятия «модель дан-

ных» и «структура данных». Структура данных –

лишь одна из трех компонент модели данных

62


Языки программирования и модели данных

Лекция 8

Внутренний (машинный) язык каждой ЭВМ обладает

простой, но хорошо определенной моделью данных

Структурная

компонента

Допусти-

Манипуляционная


Набор ко-

Целостная


Разряд-

мые форматы манд над допус- ность машинного

данных (логиче-

ский, с фиксиро-

ванной точкой, с

плавающей точ-

кой и др.)

тимыми форма-

тами данных (ло-

гические коман-

ды, арифметика с

фиксированной

точкой, арифме-

тика с плаваю-

щей точкой и др.)

слова

Чем выше уро-

вень языковых

средств, тем

сложнее модель

данных!

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

нальную модель данных



Допусти-

мые типы дан-



Наборы

операций над до-

Целостная


Диапазоны

изменения целых

ных. Задаются пустимыми ти- и вещественных

декларативными пами данных. За- чисел, макси-

операторами

языка

даются импера-

тивными опера-

торами языка

63

мальная длина

строки символов

и др.


Компоненты моделей данных СУБД

Лекция 8

С позиции прикладного программиста любую СУБД

можно рассматривать как некоторый комплекс программ со

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

решению задачи. Отличие от обычных языков программи-

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

и операторы действий над данными разделены и оформле-

ны в виде двух самостоятельных языков: ЯОД и ЯМД. Од-

нако в концептуальном плане это не меняет ситуации. Ка-

ждая СУБД поддерживает свою особую модель данных



Допустимая

организация дан-



Набор опе-

раций, опреде-

Целостная


Ограниче-

ния на размеры и

ных. Задается ляемый операто- содержимое до-

операторами

ЯОД

рами и средства-

ми ЯМД проце-

дурного типа

пустимых струк-

тур данных

Все многообразие существующих моделей данных конкретных

СУБД можно подразделить на несколько типов. Далее будут рассмотрены

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

ке. К классическим обычно относят иерархическую, сетевую и реляцион-

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

хическую и сетевую называют теоретико-графовыми моделями данных, а

реляционную – теоретико-множественной.

Современные модели данных являются расширением и обобщением

классических. Многие эксплуатируемые в настоящее время СУБД под-

держивают несколько типов моделей данных

64


Модели, представляющие исторический интерес

Лекция 8

Первые СУБД использовали иерархическую модель данных.

Именно иерархическую модель поддерживала первая из зарегистриро-

ванных промышленных СУБД IMS (Information Management System)

фирмы IBM. Эта СУБД была создана для поддержки лунного проекта

«Аполлон». Появление иерархической модели связано с тем, что в ре-

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

объект выступает как основной, а с ним связано множество подчинен-

ных объектов


Основная структура данных – запись,

построенная из скалярных и составных

типов данных. Записи связываются

с помощью указателей в наборы –

корневые деревья. Корень дерева – это вы-

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

Иерархическая база данных представляет собой упорядоченную

совокупность экземпляров наборов (деревьев). Обход всех эле-

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


Типичные операторы:

• поиск указанного дерева,

• переход от одного дерева

к другому,

• переход от одной записи

к другой внутри дерева,

• вставка (удаление) записи и

т.п.

65


Правило иерархии:

потомок (подчиненная за-

пись) может иметь только

одного родителя (основ-

ную запись) – без него он

существовать не может, но

у некоторых родителей

может не быть потомков


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

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

выми СУБД являются: IDMS, db_VistaIII, СЕТЬ, КОМПАС. Сетевая

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

сями данных, обобщая тем самим иерархическую модель данных


Основная структура данных – запись

из скалярных и составных

типов данных. Записи связываются

с помощью указателей в наборы –

ориентированные графы. Каждый набор

имеет выделенную запись – владельца набора. Сетевая база дан-

ных – упорядоченная совокупность экземпляров наборов



Важнейшие

операции

Потомок не может

схожи с операциями иерархиче-

ской модели данных

существовать без родите-

ля (их в о бщем случае

может быть несколько)

Достоинства иерархической и сетевой моделей данных:

• быстрый поиск,

• экономное использование памяти.

Недостатки:

• сложность понимания для обычного пользователя (требуется вы-

сокий уровень знаний о физической организации данных),

• сложность контроля целостности связей,

• сложность реализации пользовательских запросов (только с по-

мощью высококвалифицированных программистов)

66


Наиболее распространенные модели

Лекция 8

Появление классической реляционной модели данных было пре-

допределено наступлением эры персональных компьютеров и настоя-

тельной потребностью пользователей в простых моделях данных.

Реляционная модель данных была предложена в 1970 году со-

трудником фирмы IBM Эдгаром Коддом и основывается на понятии

отношения (relation).

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

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

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

непрофессионалов, с одной стороны, и серьезное теоретическое обос-

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

модели. В 1981 году за реляционную модель Э. Кодд был удостоен

престижной премии Тьюринга в области теоретических основ вычис-

лительной техники


Основная структура данных –

A B … Z отношение – двумерная таблица,

в которой каждая строка имеет

… … … … одинаковое число полей,

все поля определены и атомарны

(недопустимы неопределенные и

составные значения).

Реляционная база данных – совокупность двумерных (реляцион-

ных) таблиц. Возможно указание ссылок между таблицами.

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

обычный «плоский» файл − файл записей

последовательного доступа. Все записи этого

файла имеют одинаковую длину и

. . . структуру. Каждое поле записи хранит только

одно атомарное (неделимое) значение

67



Лекция 8

Представлена двумя способами манипулирования

данными: реляционная алгебра, включающая в себя тео-

ретико-множественные операции над отношениями, и

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

Первый способ задает процедурный уровень обра-

ботки данных, а второй – спецификационный. Теорети-

чески доказана полнота и эквивалентность обоих спосо-

бов


Всякая реляционная таблица должна быть целост-

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

нормализованной. Это означает, что в ней не до лжно

быть:

• составных значений полей,

• неопределенных (пустых) полей,

• строк-дубликатов,

• избыточного дублирования данных

Достоинства классической реляционной модели:

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

• простота физической реализации,

• строгое теоретическое обоснование,

• высокая эффективность для OLTP-систем.


• отсутствие средств идентификации отдельных записей и

сложность описания сетевых и иерархических связей

между данными,

• примитивность для реализации OLAP-систем

68


Классическая реляционная модель накладывает жесткие

ограничения на целостность таблиц. Именно эти ограничения

обеспечивают удобство обновления оперативных баз данных в

OLTP-системах. Однако практика эксплуатации реляционных

СУБД показала, что в ряде случаев эти ограничения чрезвы-

чайно мешают эффективной обработке данных.

Постреляционная модель данных расширяет реляцион-

ную модель, снимая некоторые ограничения целостности. Так,

в постреляционной модели допускаются:

• неопределенные значения полей,

• составные и многозначные поля. Например, составное

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

бор значений многозначных полей – таблицей, встроен-

ной в основную таблицу,

• избыточное дублирование данных.

Кроме того, на длину полей и количество полей в запи-

сях таблицы не накладывается требований постоянства. Все

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

по сравнению с классической реляционной моделью

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

дублирование данных (ненормализованность таблиц), то возникает

проблема обеспечения целостности базы данных. В этом состоит не-

достаток данной модели. В настоящее время проблема целостности

решается путем включения в СУБД дополнительных механизмов –

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

жанию СУБД. Современные СУБД в большинстве своем являются

реляционными и постреляционными!

Подробно теоретическая основа реляционной мо-

дели данных рассматривается в разделах 4, 5

69


Специальные модели

Лекция 8

Многомерная модель данных – обобщение классической реляци-

онной модели. Многомерный подход к представлению данных появился

практически одновременно с реляционным. Однако реально работаю-

щих многомерных СУБД долгое время не было. Толчком к созданию

таких СУБД послужила программная статья Э. Кодда, в которой были

сформулированы 12 основных требований к OLAP-системам. Если ре-

ляционная модель хорошо приспособлена для OLTP-систем, то много-

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

нятия решений, т.е. OLAP-системы


Основная структура данных –

месяца

Декады

Филиалы банка

многомерная таблица. Как

правило, одной из координат

выступает время.

Многомерная база данных –

совокупность гиперкубов

различной размерности.

Пользователь по-прежнему

может работать с двумерными

таблицами, которые являются «срезами» многомерной таблицы.

Многомерную базу принято называть хранилищем данных


Помимо средств манипу-

лирования данными реляцион-

ной модели имеются также

специальные операции: фор-

мирование среза, замена коор-

динат и др.

70

Достоинство: удобство

и эффективность аналитиче-

ской обработки больших объе-

мов информации, связанных со

временем.

Недостатки: узкая спе-

циализация модели, сложность

контроля целостности храни-

лища данных

П

ок

аз ат

ели

раб от

ы


В объектно-ориентированной модели данных реализуются две

концепции: объектно-ориентированного программирования и концеп-

ции баз данных и СУБД. Такая модель данных была впервые описана в

рекомендациях стандарта ODMG-93 (Object Database Management

Group). Между тем эти рекомендации в полном объеме до сих пор пока

не реализованы в промышленных СУБД. Многие полнофункциональ-

ные современные СУБД содержат лишь некоторые механизмы объект- но-ориентированного программирования


Данные структурируются подобно иерархической модели

данных. Однако вершинами дерева выступают не записи, а объек-

ты. Между объектами и функциями их обработки устанавливают-

ся взаимосвязи. Это позволяет идентифицировать отдельные объ-

екты базы данных


Логические операции,

усиленные механизмами ин-

капсуляции, наследования и

полиморфизма. Для создания

базы данных применяются

операции, подобные командам

языка SQL

71

Достоинствами объект-

но-ориентированной модели

данных в сравнении с реляци-

онной моделью является воз- можность:

• отображения информации

о сложных взаимосвязях

объектов,

• идентификации отдель-

ных объектов и определе-

ния для них специфиче-

ских функций обработки.


• высокая понятийная

сложность,

• низкая скорость обработ- ки запросов

Одни и те

же данные

могут



Выбор средств реализации базы данных

Средства реализации базы данных

Модель данных Программная

платформа

СУБД Средства

разработки

Лекция 8

приложений

Выбор средств реализации выполняется на третьем этапе процесса

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

данных, а затем – программную платформу. Такой порядок действий

имеет следующее объяснение:

• выбор СУБД до инфологического моделирования предметной облас-

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

ет, что ему предстоит делать;

• отдать обоснованное предпочтение той или иной модели данных (с ее

структурами данных, операциями и ограничения целостности) можно

лишь после того, как построена ER-диаграмма предметной области и

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

«тару» можно только тогда, когда ясно, что подлежит хранению и ка-

кие операции надо будет выполнять над хранимыми объектами;

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

то выбор модели предопределяет класс СУБД, в котором следует ис-

кать подходящую СУБД. Для этих целей существует несколько мето-

дик;

• если в выбранной СУБД недостаточно средств ЯМД для разработки

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

этого привлекается соответствующий инструментарий (например,

Delphi или Visual Basic).

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

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

пользователям достаточно языков запросов

72



1. Для чего предназначена модель данных?

2. Почему модели данных часто называют синтаксическими моделями?

Что является объектом моделирования в этих моделях?

3. Какие компоненты содержит каждая модель данных?

4. Являются ли синонимами понятия «модель данных» и «структура

данных»?

5. В чем особенности компонент модели данных машинных языков?

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

7. Известно, что любая СУБД поддерживает свою особую модель

данных. Какие компоненты содержит модель данных СУБД?

8. Какие модели данных СУБД считаются классическими?

9. Какие модели данных используются в современных СУБД?

10. Какие модели данных относятся к теоретико-графовым и почему?

11. Почему реляционную модель данных принято называть теоретико-

множественной моделью данных?

12. Может ли СУБД поддерживать несколько типов моделей данных?

13. Что характерно для структурной, манипуляционной и целостной

компонент иерархической модели данных?

14. Что характерно для структурной, манипуляционной и целостной

компонент сетевой модели данных?

15. Почему иерархическая и сетевая модели данных не получили широко-

го распространения на практике?

16. В чем достоинства и недостатки иерархической и сетевой моделей

данных?

17. В какой из современных моделей данных нашли свое развитие идеи,

заложенные в теоретико-графовых моделях?

73


18. Кем и когда была предложена реляционная модель данных?

19. Что выступает в качестве основной структуры данных реляционной

модели?

20. Какие два способа манипулирования данными возможны в реляцион-

ной модели?

21. Каковы особенности целостной компоненты реляционной модели

данных?

22. Какие достоинства и недостатки имеет реляционная модель?

23. Для каких видов информационных систем реляционная модель высоко

эффективна и почему?

24. Постреляционная модель – это расширение классической реляционной

модели данных. В чем суть этого расширения?

25. Какой существенный недостаток характерен для постреляционной

модели данных?

26. Многомерная модель – это обобщение классической реляционной мо-

дели. Что выступает в качестве основной структуры данных многомер-

ной модели? Что такое хранилище данных?

27. Какие достоинства и недостатки имеет многомерная модель данных?

28. Многомерная модель – это модель данных специального назначения.

Для какого типа информационных систем она наиболее эффективна?

29. Что выступает в качестве основной структуры данных объектно-

ориентированной модели данных?

30. Какие достоинства и недостатки свойственны объектно-

ориентированной модели данных?

31. Что включают в себя средства реализации базы данных?

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

инфологического моделирования предметной области?

33. Что следует учитывать при выборе модели данных?

34. Какое приложение называют внешним?

74


Список литературы

Основная литература

1. Хомоненко А.Д. Базы данных: Учебник для высших учебных

заведений / А.Д. Хомоненко, В.М. Цыганков, М.Г. Мальцев. – СПб.:

КОРОНА принт, 2000. – 416 с.

2. Карпова Т.С. Базы данных: модели, разработка, реализация /

Т.С. Карпова. – СПб.: Питер, 2001. – 304 с.

3. Малыхина М.П. Базы данных: основы, проектирование,

использование / М.П. Малыхина. – СПб.: БХВ-Петербург, 2004. – 515 с.

Дополнительная литература

4. Джексон Г. Проектирование реляционных баз данных для

использования с микро-ЭВМ / Г. Джексон. – М.: Мир, 1991.

5. Роб П. Системы баз данных: проектирование, реализация и

управление / П. Роб, К. Коронел. – СПб.: БХВ-Петербург, 2004.

6. Четвериков В.Н. Базы и банки данных / В.Н. Четвериков, Г.И.

Ревунков, Э.Н. Самохвалов. – М.: Высш. шк., 1987.

7. Бойко В.В. Проектирование баз данных информационных систем

/ В.В. Бойко, В.М. Савинов. – М.: Финансы и статистика, 1989.

8. Дейт К. Введение в системы баз данных / К. Дейт. – К.:

Диалектика, 1998.

9. Хансен Г. Базы данных: разработка и управление / Г. Хансен,

Д. Хансен. – М.: БИНОМ, 1999.

10. Microsoft Office Access 2003. Шаг за шагом. – М.: СП ЭКОМ,

2004.

161


11. Шарон Б. SQL Server 2000. Энциклопедия программиста / Б.

Шарон, Г. Мэйбл. − ДиаСофт, 2001.

12. Бекаревич Ю.Б. Самоучитель Microsoft Access 2003 / Ю.Б.

Бекаревич, Н.В. Пушкина. − СПб: БХВ-Петербург, 2004.

13. Кошелев В.Е. Access 2003 / В.Е. Кошелев. − М.: ООО ”Бином-

Пресс”, 2003.

Методическая литература

14. Быкова В.В. Базы данных. Модели, проектирование: Учеб.

пособие / В.В. Быкова. – Красноярск, 2003. – 160 с.

15. Создание и использование баз данных с применением СУБД:

Лабораторный практикум / Краснояр. гос. ун-т; Сост. В.В. Быкова, С.Э.

Мишина. – Красноярск, 1994. – 50 с.

16. Баранова И.В. Основы теории баз данных: Лабораторный

практикум / И.В. Баранова. – Красноярск, 2007. – 64 с.

162


Приложение

Перечень основных терминов

Администратор базы данных – лицо или группа лиц, отвечающих

за выработку требований к базе данных, ее проектирование, создание, эф-

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

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

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

Актуализация базы данных – обновление (добавление, изменение

или удаление) данных.

Аномалии актуализации – принятое в англоязычной литературе по

базам данных название проблем обновления данных, вызванных избыточ-

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

ных таблиц.

Аномалия добавления – невозможность ввода одних данных из-за

отсутствия других.

Аномалия модификации – изменение значения одного данного ве-

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

Аномалия удаления – потеря информации, напрямую не связанной с

данными, которые удалены.

Атрибут (с лат.) – существенный признак.

Атрибут ключевой – атрибут, входящий в состав какого-либо

ключа.

Атрибут неключевой – атрибут, который не входит в состав

ключей.

Атрибут отношения – пара (A, D), где A – имя атрибута, а D –

множество допустимых значений этого атрибута. Множество D называют

доменом атрибута.

163


Атрибут сущности (связи) – конструктивный элемент ER-модели,

предназначенный для задания свойства сущности (связи).

База данных с датологической точки зрения – хранилище данных,

предназначенное для коллективного, многократного, многоцелевого ис-

пользования и организованное по правилу «Три НЕ».

База данных с инфологической точки зрения – динамически обнов-

ляемая информационная модель некоторой предметной области.

База данных персональная – централизованная база данных, экс-

плуатируемая одним пользователем.

База данных распределенная – децентрализованная (физически рас-

положенная в нескольких узлах сети) и эксплуатируемая многими пользо-

вателями база данных.

База данных реляционная – конечная совокупность реляционных

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

контроля целостности и обработки данных в интересах некоторых конеч-

ных пользователей.

База данных централизованная – база данных, физически сосредо-

точенная в одном месте.

Банк данных – разновидность информационной системы, в которой

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

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

данных.

Данные – информация, представленная в форме, удобной для хране-

ния, передачи и переработки.

Декартово произведение – операция реляционной алгебры, приме-

няемая к двум таблицам. В результате формируется таблица, строки кото-

рой получаются сцеплением каждой строки одной таблицы с каждой стро-

кой другой таблицы.

Домен атрибута – множество допустимых значений атрибута.

Жизненный цикл базы данных – история развития базы данных. Де-

лится на три этапа: проектирование, реализация, эксплуатация.

164


Журнал СУБД – отдельная база данных или часть основной базы

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

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

вом администрирования базы данных.

Запрос – специальным образом описанное обращение пользователя к

базе данных, содержащее задание на получение или изменения информа-

ции, хранящейся в базе.

Защита данных – средства предотвращения несанкционированного

доступа к базе данных.

Идентичность по структуре отношений – совпадение схем от-

ношений (имен и доменов атрибутов), порядка расположения атрибутов и

ключей.

Избыточное дублирование данных – повторение данных в базе, вы-

званное наличием зависимостей между ними. При избыточном дублирова-

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

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

данных, в особенности для OLTP-систем. Оно ведет к увеличению объема

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

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

– появление аномалий актуализации. Устраняется путем нормализации

таблиц.

Индекс – средство ускорения операции поиска строк в реляционной

таблице, а также выполнения других операций, использующих поиск: из-

влечение, модификация и т.д.

Индексный файл – файл, в котором хранится информация индекса.

Инфологическая модель предметной области – семантическая

структурная модель, отражающая классы однородных объектов, свойства

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

Информационная система – система, включающая в себя инфор-

мационные, программные, технические, языковые и организационные

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

поиска и обработки данных.

165


Информационная система типа клиент-сервер – система, в кото-

рой программы СУБД функционально разделены на две части, называемые

клиентом и сервером.

Информационно-поисковая система – информационная система,

основной функцией которой выступает поиск данных.

Информация – первичное (неопределяемое) понятие.

Класс принадлежности необязательный – возможны экземпляры

сущности, свободные от связи.

Класс принадлежности обязательный – каждый экземпляр сущно-

сти участвует в связи.

Класс принадлежности сущности к связи – характеристика бинар-

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

связи экземпляров сущности.

Ключ реляционной таблицы – минимальный набор атрибутов, од-

нозначно определяющих каждую строку таблицы. Если таблица имеет не-

сколько ключей, то один из них – первичный.

Ключ составной – ключ, состоящий из нескольких атрибутов.

Ключ сущности – минимальный набор атрибутов, значения которых

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

Ключ таблицы внешний – набор атрибутов одной (основной) таб-

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

для связывания реляционных таблиц.

Конечные пользователи – группа лиц, в интересах которой создает-

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

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

Кортеж отношения – элемент отношения, соответствующий стро-

ке реляционной таблицы.

Метаданные (данные о данных) – специальная компонента СУБД,

предназначенная для централизованного хранения информации об органи-

зации базы данных (структурах и типах данных, кодах защиты и разграни-

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

166


физических адресах размещения данных в памяти системы и т.п.). Мета-

данные иногда называют словарем данных.

Модель – описание или аналогия, используемая для представления

чего-либо, что не может быть рассмотрено непосредственно; упрощенные

абстракции событий или условий реального мира.

Модель данных – абстракция, предназначенная для определения

правил структурирования, процессов динамического изменения и допус-

тимых состояний взаимосвязанных данных.

Модель данных иерархическая – теоретико-графовая модель дан-

ных. Основная структура данных – списковая структура типа корневого

ориентированного графа (набора записей, связанных между собой указате-

лями, при этом выделенная запись – корень дерева – является владельцем

набора).

Модели данных классические – реляционная, сетевая, иерархиче-

ская модели данных.

Модели данных компоненты – основные структуры данных, мно-

жество операций над возможными структурами данных и ограничения це-

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

Модель данных многомерная – обобщение классической реляцион-

ной модели данных. Основная структура данных – многомерная таблица.

Относится к теоретико-множественным моделям данных.

Модель данных объектно-ориентированная – теоретико-графовая

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

Однако вершинами дерева выступают не записи, а объекты. Между объек-

тами и функциями их обработки устанавливаются взаимосвязи.

Модель данных постреляционная – расширение классической ре-

ляционной модели данных. Снимает ограничение нормализованности таб-

лиц. Допускает неопределенные и составные значения полей таблиц. От-

носится к теоретико-множественным моделям данных.

Модель данных реляционная – модель данных, основной структу-

рой данных которой является реляционная таблица. Относится к теорети-

ко-множественным моделям данных.

167


Модель данных сетевая – теоретико-графовая модель данных. Ос-

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

графа произвольного вида с выделенной вершиной.

Модель «сущность-связь» (ER-модель) – система условных обозна-

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

Независимость данных логическая – возможность изменения одно-

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

же базой данных.

Независимость данных от приложений – свойство базы данных,

обеспечивающее устойчивость ее к развитию. Предполагает логическую и

физическую независимость.

Независимость данных физическая – возможность переноса дан-

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

Неизбыточность базы данных – свойство, означающее, что в базе

данных нет ничего «лишнего», т.е. удаление из нее какого-либо элемента

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

Непротиворечивость базы данных – свойство базы данных, которое

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

условиям – ограничениям целостности.

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

ния того, что требуется, а не того, как это получить.

Нормализация – процесс приведения реляционной таблицы к неко-

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

Нормальная форма – некоторый образец, которому должна соответ-

ствовать реляционная таблица во избежание аномалий актуализации.

Объединение – операция реляционной алгебры, создающая теорети-

ко-множественное объединение двух таблиц, идентичных по структуре.

Ограничения целостности – условия, которым должны удовлетво-

рять хранимые в базе данные.

Ограничение целостности ссылок – условие, накладываемое на со-

держание взаимосвязанных реляционных таблиц: для каждого значения

168


внешнего ключа основной таблицы всегда должна найтись строка подчи-

ненной таблицы с таким же значением первичного ключа.

Отношение – представление реляционной таблицы на языке мате-

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

Пересечение – операция реляционной алгебры, создающая теорети-

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

Поддержка целостности базы данных – контроль целостности ба-

зы данных и восстановление базы в случае утраты ее целостного состоя-

ния.

Подсхема схемы реляционной базы данных – схема отношения,

входящего в базу данных.

Правило «Три НЕ» – три концептуальных свойства базы данных,

характеризующих особенности ее организации: неизбыточность, непроти-

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

Предметная область – часть реального мира, являющаяся объектом

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

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

автоматизацию обработки информации для прикладной задачи.

Приложения внешние – приложения, разработанные вне СУБД.

Приложения СУБД – приложения, разработанные с помощью язы-

ковых средств СУБД.

Проект базы данных логический – определение логической струк-

туры (схемы) базы данных в терминах модели данных.

Проект базы данных физический – определение запоминающих

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

базе данных.

Проектирование базы данных – первый этап жизненного цикла ба-

зы данных, во время которого создаются семантические и синтаксические

модели разной степени формализации: от словесного описания предметной

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

описания данных СУБД.

169


Проектирование базы данных датологическое – выбор модели

данных и СУБД, разработка логического и физического проектов (синтак-

сических моделей) базы данных.

Проектирование базы данных инфологическое – изучение, анализ и

моделирование предметной области – создание семантических моделей ба-

зы данных.

Проекция – операция реляционной алгебры, создающая таблицу пу-

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

Процедура (с лат.) – предписанная последовательность действий для

осуществления какого-либо дела.

Процедурный язык – язык, обеспечивающий пошаговый способ опи-

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

Разность – операция реляционной алгебры, создающая теоретико-

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

Разработчик базы данных – это категория пользователей, которые

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

реорганизации. Группу разработчиков составляют: системные аналитики

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

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

администратор базы данных, администраторы приложений (координируют

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

Реляционная алгебра – система запросов для реляционных баз дан-

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

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

– отношения. Отношение, как ответ на запрос, формируется по шагам на

основе реляционного выражения.

Реляционное выражение – выражение реляционной алгебры.

Реляционное исчисление – система запросов для реляционных баз

данных. Составляет теоретическую основу реальных непроцедурных язы-

ков манипулирования данными (например, SQL и QBE). Позволяет выра-

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

170


реляционного исчисления содержит лишь сведения о том, что необходимо

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

Реляционные операции – операции реляционной алгебры – опера-

ции над таблицами (отношениями).

Реляционная таблица – двумерная таблица, в которой представле-

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

области. Основная единица хранения данных в реляционной базе данных.

Связь – конструктивный элемент ER-модели, предназначенный для

указания отношения между сущностями.

Связь бинарная – связь, отражающая отношение между двумя типа-

ми сущностей.

Связывание реляционных таблиц – средство реляционных СУБД,

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

согласованного обновления.

Селекция – операция реляционной алгебры, выбирающая строки из

таблицы на основании заданного условия.

Семантика (с греч.) – смысл, содержание, толкование.

Семантика данных – смысл (информационное содержание) данных.

Сеть – совокупность компьютеров, объединенных средствами пере-

дачи данных.

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

значительное расстояние.

Сеть локальная – сеть, в которой компьютеры расположены на рас-

стоянии до нескольких километров и обычно соединены при помощи ско-

ростных линий связи.

Синтаксис (с греч.) – правила записи.

Система запросов – это формальная система выразительных

средств, предназначенных для записи запросов к базе данных. Всякая сис-

тема запросов − некоторый теоретический язык запросов.

171


Система обработки данных – информационная система, основной

функцией которой является обработка данных. Среди них выделяют

OLTP-системы и OLAP-системы.

Система управления базами данных – комплекс языковых и про-

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

использования баз данных.

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

СУБД, ориентированная на работу в сети с распределенными базами дан-

ных.

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

СУБД, предназначенная для создания, ведения и эксплуатации персональ-

ных баз данных.

Соединение (естественное соединение) – операция реляционной ал-

гебры, применяемая к двум таблицам. Строки результирующей таблицы

получаются сцеплением только тех строк исходных таблиц, для которых

имеет место равенство значений одноименных атрибутов.

Степень связи – характеристика бинарной связи, определяющая од-

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

Степень связи «многие-ко-многим» – один экземпляр первой сущ-

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

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

кими экземплярами первой сущности.

Степень связи «один-к-одному» – один экземпляр одной сущности

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

Степень связи «один-ко-многим» – один экземпляр первой сущно-

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

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

ром первой сущности.

Суперключ реляционной таблицы – набор атрибутов, однозначно

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

гие атрибуты таблицы.

172


Сущность – конструктивный элемент ER-модели, предназначенный

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

предметной области. Классу соответствует тип сущности, конкретному

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

Сущность слабая – сущность, которая не может существовать сама

по себе. Наследует часть ключа от других сущностей.

Схема отношения – множество имен атрибутов отношения.

Схема реляционной базы данных – список, содержащий имена ре-

ляционных таблиц базы данных. Для каждой таблицы указываются имена

атрибутов и множество ключей.

Трехуровневая схема представления метаданных – стандарт пред-

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

базы данных от приложений. Схема предложена американским националь-

ным институтом стандартов ANSI.

Файл – именованный набор связанных записей.

Целостность базы данных – свойство, означающее, что база дан-

ных содержит полную, достоверную и непротиворечивую информацию о


Целостность базы данных логическая – отсутствие логических

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

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

Целостность базы данных физическая – свойство базы данных,

предполагающее, что данные не утрачены.

Целостность реляционной таблицы – свойство, означающее, что

таблица имеет ключ и является нормализованной (все поля таблицы опре-

делены и атомарны, в таблице нет избыточного дублирования данных).

Язык манипулирования данными – совокупность конструкций,

обеспечивающих выполнение основных операций по работе с данными:

ввод, модификацию и выборку.

Язык манипулирования данными навигационного типа – проце-

дурный язык для разработки приложений.

173


Язык манипулирования данными спецификационного типа – язык

запросов (непроцедурный язык для выражения запросов к базе данных).

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

ного (спецификационного) манипулирования данными без знания кон-

кретной физической организации базы данных.

Язык определения данных – высокоуровневый язык декларативного

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

данных.

Язык реляционный – язык запросов, который имеет как минимум те

же возможности, что реляционная алгебра.

ANSI (American National Standards Institute) – американский нацио-

нальный институт стандартизации.

CASE-средство (Computer Aided Software Engineering) – инструмен-

тарий, обеспечивающий автоматизацию проектирования информационных

систем.

ER-диаграмма (Entity-Relationship diagram) – объектно-связное

представление предметной области в терминах ER-модели.

ER-модель (Entity-Relationship model) – модель «сущность-связь».

Это система условных обозначений для описания инфологической модели


OLTP (Online Transaction Processing) – системы оперативной обра-

ботки данных. Основными функции для них являются обновление и обра-

ботка данных.

OLAP (Online Analytical Processing) – системы оперативного анализа

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

Базируются на многомерной модели данных.

QBE (Query-by-Example) – язык запросов по образцу. Применяется

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

SQL (Structured Query Language) – структурированный язык запро-

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

ных СУБД.

174

176

Documents

Основы теории баз данных - freevar.comsait.freevar.com › 05_004_102_87str_bd_lectures_vop_otv.pdfЛекция 7. Инфологическое моделирование