72189

Базы данных: учебно-методический комплекс

Книга

Информатика, кибернетика и программирование

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

Русский

2014-11-19

3.24 MB

40 чел.

Северо-Западный государственный заочный технический университет

БАЗЫ  ДАННЫХ

Учебно-методический комплекс

Санкт-Петербург

2010


ПЕРВОЕ ВЫСШЕЕ ТЕХНИЧЕСКОЕ УЧЕБНОЕ ЗАВЕДЕНИЕ РОССИИ

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ

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

«НАЦИОНАЛЬНЫЙ МИНЕРАЛЬНО-СЫРЬЕВОЙ УНИВЕРСИТЕТ «ГОРНЫЙ»

Кафедра информационных систем и вычислительной техники

БАЗЫ  ДАННЫХ

Учебно-методический комплекс

Институт информационных систем и вычислительной техники

Специальности:

230101.65 – вычислительные машины, комплексы, системы и сети

230102.65 – автоматизированные системы обработки информации и управления

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

230106.51 – техническое обслуживание средств вычислительной техники и компьютерных сетей

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

230100.62 – информатика и вычислительная техника

Санкт-Петербург

2012


Утверждено редакционно-издательским советом университета

УДК 681.3

Базы данных: учебно-методический комплекс /сост.: М.В. Копейкин,  В.В. Спиридонов, Е.О. Шумова. - СПб.: Изд-во СЗТУ, 2012. – 175 с.

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

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

Рассмотрено на заседании кафедры автоматизированных систем обработки информации и управления 13.05.2010 г.; одобрено методическим советом института информационных систем и вычислительной техники 17.06.2010 г.

Рецензенты: кафедра автоматизированных систем обработки информации и управления СЗТУ (зав. кафедрой И. В. Иванова, д-р техн. наук, проф.); А. М. Заяц, канд. техн. наук, проф., зав. кафедрой Информатики и информационных систем СПбГЛТА.

Составители: М.В. Копейкин, канд. техн. наук, доц.,

В.В. Спиридонов, канд. техн. наук, доц.,

Е.О. Шумова, доц.

Северо-Западный государственный заочный технический университет, 2011

Копейкин М.В., Спиридонов В.В., Шумова Е.О., 2011


1. Информация о дисциплине

1.1. Предисловие

Дисциплина «Базы данных» изучается студентами специальностей 230101.65, 230102.65, 230105.65, 230106.51 и  направления подготовки бакалавра 230100.62, всех форм обучения в одном семестре. Дисциплина охватывает следующие разделы: «Назначение и основные компоненты системы баз данных»; «Архитектура банка данных»; «Модели и типы данных в БД»; «Базовые элементы реляционных БД»; «Язык структурированных запросов SQL»; «Использование баз данных», объем лекционных и лабораторных часов определяется формой обучения. Завершается изучение дисциплины защитой курсового проекта и экзаменом.

Целью изучения дисциплины «Базы данных» является приобретение студентами знаний и навыков в области проектирования и использования баз данных, взаимодействия их программных и аппаратных средств.

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

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

Иметь представление:

  •  о методологии и этапах проектирования баз и банков данных;
  •  о моделях и типах данных;
  •  о нормализации отношений в базах данных (БД);
  •  о структурных элементах и типах связей в базах данных;
  •  о системах управления базами данных.

Знать:

  •  методологию использования и эксплуатации БД;
  •  методологию нормализации отношений в БД;
  •  методологию проектирования БД;
  •  основы проектирования и эксплуатации БД.

Уметь:

  •  создавать информационно-логическую модель БД;
  •  проводить нормализацию отношений в базе данных;
  •  формировать логическую структуру таблиц БД;
  •  создавать формы, запросы и отчеты;
  •  создавать простейшие интегрированные системы.

Владеть методами:

  •  приведения отношений к нормальной форме;
  •  работы с основными объектами баз данных;
  •  оценки производительности отдельных компонент БД.

Место дисциплины в учебном процессе

Теоретической и практической основами дисциплины являются курсы “Математика”, “Информатика”, “Дискретная математика”, “Программирование на языке высокого уровня”, “Математическая логика и теория алгоритмов”, “Операционные системы”, ”Организация ЭВМ и систем”, “Объектно-ориентированное программирование”, часть из которых изучается параллельно с данной дисциплиной.

Приобретенные студентами знания будут непосредственно использованы при изучении следующих дисциплин различными специализациями: “Сети ЭВМ и телекоммуникации”, “Проектирование информационных систем”, “Системотехника и системное проектирование”, “Экспертные системы” и используются в курсовом и дипломном проектировании.

1.2. Содержание дисциплины и виды учебной работы

Содержание дисциплины по ГОС

Назначение и основные компоненты системы баз данных; обзор современных систем управления базами данных (СУБД); уровни представления баз данных; понятия схемы и подсхемы; модели данных; иерархическая, сетевая и реляционная модели данных; схема отношения; язык манипулирования данными для реляционной модели; реляционная алгебра и язык SQL; проектирование реляционной базы данных, функциональные зависимости, декомпозиция отношений, транзитивные зависимости, проектирование с использованием метода сущность - связь; изучение одной из современных СУБД по выбору; создание и модификация базы данных; поиск, сортировка, индексирование базы данных, создание форм и отчетов; физическая организация базы данных; хешированные, индексированные файлы; защита баз данных; целостность и сохранность баз данных.

1.2.1. Объем дисциплины и виды учебной работы

Вид учебной работы

Всего часов

Форма обучения

Очная

Очно-заочная

Заочная

Общая трудоемкость дисциплины (ОТД)

140

Работа под руководством преподавателя

(включая ДОТ)

84

84

84

В т.ч. аудиторные занятия:

лекции

практические занятия (ПЗ)

лабораторные работы (ЛР)

34

8

28

16

4

16

4

4

8

Самостоятельная работа студента (СР)

56

56

56

Промежуточный контроль, количество

7

7

7

В т. ч.: курсовой проект

1

1

1

Вид итогового контроля (зачет, экзамен)

Экзамен

1.2.2. Перечень видов практических занятий и контроля:

- тесты (тренировочные и контрольные по разделам дисциплины);

- практические занятия – 8 (для очной формы), 4 часа (для остальных форм);

- лабораторные работы – 28 (для очной формы), 16 (для очно-заочной формы),  8 (для заочной формы);

- курсовой проект;

- экзамен.


2. Рабочие учебные материалы

2.1. РАБОЧАЯ ПРОГРАММА

(объем дисциплины  140 часов)

Введение (2 часа)

[1], с. 38...63, [6] с. 8...36

Цель и задачи курса, его роль в подготовке специалистов по АСОИУ и взаимосвязь с другими дисциплинами специальности.

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

Раздел 1. Назначение и основные компоненты системы баз данных (12 часов)

1.1. СУБД – основа информационных систем (8 часов)

[1], с. 73...103

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

1.2. Современные архитектуры ИС (4 часа)

[1], с. 1010...1056; [2], с. 140...164; [3], с. 99…123, [4], c. 210…235

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

Раздел 2. Архитектура банка данных(20 часов) 

2.1. Уровни представления баз данных (5 часов)

[1], с. 145...176, [4], c. 33…60

Роль и место банков данных в информационных системах. Основная терминология. Стандарт ANSI\SPARC. Уровни представления баз данных. Понятия схемы и подсхемы. Банк данных как автоматизированная система. Классификация СУБД. Информация и данные. Жизненный цикл информационной системы. Планирование разработки базы данных. Определение требований к системе. Преимущества и недостатки централизованного и децентрализованного управления данными.

2.2. Категории пользователей банков данных (5 часов)

[4], c. 63…106

Инфологическое, концептуальное, внутреннее и внешнее проектирование базы данных. Языки описания данных и языки манипулирования данными. Независимость данных: логическая независимость, физическая независимость. Проектирование приложения. Использование CASE-инструментов. Критерии оценки систем управления базами данных (СУБД). Выбор СУБД. Пользователи банков данных и администратор базы данных.

2.3. Концепции и этапы проектирования баз данных (10 часов)

[1], 222…257; [2], с. 114...138, [4], c. 130 …208

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

Моделирование данных: модели данных, структуры данных, основные операции над данными, ограничения целостности.

Раздел 3. Модели и типы данных в БД (24 часа)

3.1. Представление концептуальной модели средствами СУБД (14 часов)

[1], с. 420...470; [6], с. 27...44

Общие представления о моделях данных СУБД. Моделирование информационных объектов и связей предметной области. Типы ассоциаций и их фиксация в концептуальной модели. Проектирование с использованием метода сущность – связь. Моделирование информационных объектов посредством отношений. Формирование схемы и подсхемы. Языки описания и манипулирования данными в промышленных СУБД..

3.2. Типовые модели данных СУБД (10 часов)

[4], c. 261   327; [6], с. 27...44

Типы моделей данных. Классификация моделей данных. Выбор модели данных. Иерархическая, сетевая и реляционная модели данных. Типы структур. Языки описания и манипулирования данными. Достоинства и недостатки иерархических, сетевых и реляционных баз данных. Реляционная и постреляционная модель данных. Многомерная модель данных.

Раздел 4. Базовые элементы реляционных БД (25 часов)

[4], с. 331...340; [1], c. 655…722; [6], с. 45...64

4.1. Проектирование реляционной базы данных (9 часов)

Свойства и виды отношений. Моделирование информационных объектов посредством отношений. Структурные элементы реляционных БД. Поле и его характеристики. Понятия записи, отношения и файла. Простые и составные ключи. Схема отношения. Проектирование реляционной базы данных, функциональные зависимости, декомпозиция отношений, транзитивные зависимости. Язык манипулирования данными для реляционной модели. Реляционная алгебра и язык SQL: операции реляционной алгебры. Манипулирование данными

4.2. Нормализация отношений в БД (16 часов)

Теория отношений и теория нормализации. Понятие о нормальных формах. Декомпозиция и синтез схем реляционных схем баз данных. Формальные методы синтеза и декомпозиции нормальных форм.

Раздел 5. Язык структурированных запросов SQL (28 часов)

5.1. Язык манипулирования данными для реляционной модели (8 часов)

Назначение языка SQL. Терминология и диалекты SQL. Стандарты SQL и синтаксис языка. Операторы языка SQL. Создание баз данных. Создание и удаление таблиц. Виртуальные и хранимые таблицы. Определение данных. Указание ограничений поддержки целостности данных в операторе создания таблиц. Язык манипулирования данными для реляционной модели.

5.2. Реализация запросов в языке SQL (20 часов)

[2] c. 309 …329; [3] c. 225…323

Изучение одной из современных СУБД по выбору. Создание и модификация базы данных; поиск, сортировка, индексирование базы данных, создание форм и отчетов, триггеры. Создание индексов. Простые запросы. Сортировка результатов. Использование обобщающих функций языка SQL. Агрегатные функции. Группирование результатов. Подзапросы. Многотабличные запросы. Изменение содержимого базы данных. Создание и удаление представлений. Понятие интерактивного и вложенного SQL.

Раздел 6. Использование баз данных (28 часов)

6.1. Программирование и управление транзакциями. (14 часов)

[4], с. 331...340; [1], c. 655…722

Модель транзакции. Свойства транзакции. Журнализация. Проблемы многопользовательских систем. Блокировка. Алгоритмы блокировки. Целостность и восстановление баз данных. Управление обменом с внешней памятью, дисциплины обслуживания обращений к внешним ЗУ. Физическая организация базы данных. Хешированные, индексированные файлы. Свойства ACID транзакций.

Системы управления базами данных типа dBASE. Архитектура систем. Системы RBASE, PARADOX, FOXPRO, ORD, ALASKA, DELPFI. Системы управления базами данных типа ORACLE, INFORMIX, MsSQL, MуSQL. Создание баз данных и программирование в среде СУБД для ПЭВМ.

6.2. Защита баз данных. Целостность и сохранность баз данных (6 часов)

[4], с. 360...369; [1], c. 603…617; [3] c. 337…394

Создание и удаление баз данных. Защита баз данных. Управление учетными записями и правами доступа. Резервное копирование и восстановление баз данных. Контролируемая избыточность данных. Обеспечение защиты данных в банках данных. Обеспечение целостности и достоверности данных. Целостность и сохранность баз данных.

6.3. Современные тенденции построения и использования баз данных. (8 часов)

[3], с. 7...30; [1], c. 847…884

Проблема адекватности отображения предметных областей в модели данных. Проблема избыточности и независимости данных. Проблема статичности реляционной модели данных. Реорганизация модели данных и идентификация объектов в базе данных. Объектно-реляционный подход к проектированию моделей баз данных. Предпосылки и достоинства подхода. Средства идентификации объектов в модели и средства моделирования. Этапы проектирования объектно-реляционной модели. Обзор промышленных СУБД. Классификация современных промышленных СУБД. Использование СУБД (MуSQL) в Web технологиях.

Заключение (1 час)

[1], с. 888...1000

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


2.2. Тематические планы дисциплины

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

№ п/п

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

раздела

(отдельной темы)

Кол-во часов по очной форме обучения

Виды занятий и контроля

Лекции

ПЗ (С)

ЛР

Самостоятель-ная работа

Тесты

Контрольные работы

ПЗ (С)

ЛР

Курсовые проекты

аудит.

ДОТ

аудит.

ДОТ

аудит.

ДОТ

ВСЕГО

140

34

8

8

2

28

4

56

6

-

3

3

1

В

Введение

2

2

1.

Раздел 1. Назначение и основные компоненты системы баз данных

12

4

1

4

3

№1

№1

1.1

СУБД – основа информационных систем 

8

2

1

4

1

1.2

Современные архитектуры ИС

4

2

2

2.

Раздел 2. Архитектура банка данных

20

6

1

2

11 

№2

2.1

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

5

2

3

2.2

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

5

2

3

2.3

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

10

2

1

2

5

№1

3.

Раздел 3. Модели и типы данных в БД

24

6

2

4

12 

№3

3.1

Представление концептуальной модели средствами СУБД

14

2

1

4

7

№1

3.2

Типовые модели данных СУБД

10

4

1

5

4.

Раздел 4. Базовые элементы реляционных БД

25

6

2

6

2

9

4

4.1

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

9

4

1

2

1

1

№2

4.2

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

16

2

1

4

1

8

№3

5.

Раздел 5. Язык структурированных запросов SQL

28

4

1

8

15

5

23

5.1

Язык манипулирования данными для реляционной модели

8

2

1

5

5.2

Реализация запросов в языке SQL

20

2

8

10

6.

Раздел 6. Использование БД

28

6

1

12

4

5

6

6.1

Программирование и управление транзакциями

14

2

8

4

3

6.2

Защита баз данных. Целостность и сохранность баз данных 

6

2

1

3

6.3

Современные СУБД. Тенденции построения и использования баз данных.

8

2

4

2

№3

З

Заключение

1


2.2.2. Тематический план дисциплины для студентов очно-заочной формы обучения

№ п/п

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

раздела

(отдельной темы)

Кол-во часов по очной форме обучения

Виды занятий и контроля

Лекции

ПЗ (С)

ЛР

Самостоятель-ная работа

Тесты

Контрольные работы

ПЗ (С)

ЛР

Курсовые проекты

аудит.

ДОТ

аудит.

ДОТ

аудит.

ДОТ

ВСЕГО

140

16

36

4

4

16

8

56

6

-

3

3

1

В

Введение

2

2

1.

Раздел 1. Назначение и основные компоненты системы баз данных

12

2

4

4

2

№1

№1

1.1

СУБД – основа информационных систем

8

1

2

4

1

1.2

Современные архитектуры ИС

4

1

2

1

2.

Раздел 2. Архитектура банка данных

20

3

6

2

9

№2

2.1

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

5

1

2

2

2.2

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

5

1

2

2

2.3

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

10

1

2

2

5

№1

3.

Раздел 3. Модели и типы данных в БД

24

2

7

15

№3

3.1

Представление концептуальной модели средствами СУБД

14

1

3

10

3.2

Типовые модели данных СУБД

10

1

4

5

4.

Раздел 4. Базовые элементы реляционных БД

25

2

5

2

4

12

4

4.1

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

9

1

2

1

5

№2

4.2

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

16

1

3

1

4

7

№3

5.

Раздел 5. Язык структурированных запросов SQL

28

2

6

8

12

5

23

5.1

Язык манипулирования данными для реляционной модели

8

1

2

5

5.2

Реализация запросов в языке SQL

20

1

4

8

7

6.

Раздел 6. Использование БД

28

3

8

4

8

5

6

6.1

Программирование и управление транзакциями

14

1

4

4

4

1

3

6.2

Защита баз данных. Целостность и сохранность баз данных 

6

1

2

3

6.3

Современные СУБД. Тенденции построения и использования баз данных.

8

1

2

4

1

№3

З

Заключение

1

1


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

№ п/п

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

раздела

(отдельной темы)

Кол-во часов по очной форме обучения

Виды занятий и контроля

Лекции

ПЗ (С)

ЛР

Самостоятель-ная работа

Тесты

Контрольные работы

ПЗ (С)

ЛР

Курсовые проекты

аудит.

ДОТ

аудит.

ДОТ

аудит.

ДОТ

ВСЕГО

140

4

48

4

8

8

12

56

6

-

3

3

1

В

Введение

2

2

1.

Раздел 1. Назначение и основные компоненты системы баз данных

12

1

8

2

1

№1

1

1.1

СУБД – основа информационных систем

8

1

4

2

1

1.2

Современные архитектуры ИС

4

4

2.

Раздел 2. Архитектура банка данных

20

8

1

2

9

№2

2.1

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

5

4

2.2

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

5

2

2.3

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

10

2

1

№1

3.

Раздел 3. Модели и типы данных в БД

24

1

8

15

№3

3.1

Представление концептуальной модели средствами СУБД

14

1

4

3.2

Типовые модели данных СУБД

10

4

4.

Раздел 4. Базовые элементы реляционных БД

25

1

8

2

6

8

4

4.1

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

9

1

4

1

2

№2

4.2

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

16

4

1

4

№3

5.

Раздел 5. Язык структурированных запросов SQL

28

8

6

14

5

2

5.1

Язык манипулирования данными для реляционной модели

8

4

5.2

Реализация запросов в языке SQL

20

4

6

6.

Раздел 6. Использование БД

28

1

8

1

6

5

7

6

6.1

Программирование и управление транзакциями

14

4

1

4

5

3

6.2

Защита баз данных. Целостность и сохранность баз данных 

6

2

6.3

Современные СУБД. Тенденции построения и использования баз данных.

8

1

2

2

№3

З

Заключение

1

1


2.3. Структурно-логическая схема дисциплины


2.4. Временной график изучения дисциплины

Название раздела (темы)

Продолжительность

изучения раздела (темы) в днях

(из расчета – 4 часа в день)

1

Раздел 1. Назначение и основные компоненты системы баз данных

3 дн.

2

Раздел 2. Архитектура банка данных 

5 дн.

3

Раздел 3. Модели и типы данных в БД 

6 дн.

4

Раздел 4. Базовые элементы реляционных БД

6 дн.

5

Раздел 5. Язык структурированных запросов SQL

7 дн

6

Раздел 6. Использование БД. Заключение

7 дн

7

В том числе курсовой проект

9 дн

ИТОГО

35 дн.


2.5. Практический блок

Практические занятия (очная форма обучения)

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

Раздела (темы)

Наименование тем практических занятий

Кол-во часов

ауд

ДОТ

Тема 2.3

№1. Этапы проектирования моделей баз данных

2

Тема 4.1

2. Нормализация базы данных

4

1

Тема 4.2

№3. Построение схемы модели базы данных

2

1

Практические занятия (очно-заочная)

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

Раздела (темы)

Наименование тем практических занятий

Кол-во часов

ауд

ДОТ

Тема 2.3

№1. Этапы проектирования моделей баз данных

1

Тема 4.1

2. Нормализация базы данных

2

4

Тема 4.2

№3. Построение схемы модели базы данных

1

Практические занятия (заочная формы обучения)

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

Раздела (темы)

Наименование тем практических занятий

Кол-во часов

ауд

ДОТ

Тема 2.3

№1. Этапы проектирования моделей баз данных

1

2

Тема 4.1

2. Нормализация базы данных

2

4

Тема 4.2

№3. Построение схемы модели базы данных

1

2

Лабораторные работы  (очная форма обучения)

Номер и название раздела (темы)

Наименование лабораторной работы

Кол-во часов

ауд

ДОТ

Тема 1.1

№1. Инсталляция СУБД. Изучение структуры и принципов работы инструментальной оболочки СУБД

4

Раздел 5. Тема 5.1, 5.2 

№2. Использование языка PHP и SQL для взаимодействия  с хранимой информацией

12

Тема 6.1, 6.3

№3. Программирование в среде CУБД на  ПЭВМ

12

4

Лабораторные работы  (очно-заочная форма обучения)

Номер и название раздела (темы)

Наименование лабораторной работы

Кол-во часов

ауд

ДОТ

Тема 1.1

№1. Инсталляция СУБД. Изучение структуры и принципов работы инструментальной оболочки СУБД

4

Раздел 5.Тема 5.1, 5.2 

№2. Использование языка PHP и SQL для взаимодействия  с хранимой информацией

8

4

Тема 6.1, 6.3

№3. Программирование в среде CУБД на  ПЭВМ

4

4

Лабораторные работы  (заочная форма обучения)

Номер и название раздела (темы)

Наименование лабораторной работы

Кол-во часов

ауд

ДОТ

Тема 1.1

№1. Инсталляция СУБД. Изучение структуры и принципов работы инструментальной оболочки СУБД

2

1

Раздел 5. Тема 5.1, 5.2 

№2. Использование языка PHP и SQL для взаимодействия  с хранимой информацией

4

6

Тема 6.1, 6.3

№3. Программирование в среде CУБД на  ПЭВМ

2

5


2.6. Балльно-рейтинговая система

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

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

Тесты содержат 8, 9, 9, 9, 9 и 8 вопросов соответственно по первому, второму, третьему, четвертому, пятому и шестому разделам (всего 52 вопроса). Ответ на каждый вопрос оценивается в 0,5 балла. Итого по тестам можно получить в сумме 26 баллов.

Ответы на вопросы тренировочных тестов по разделам, приведенных в УМК, не оцениваются. Однако настоятельно советую Вам отвечать на них, так как эти тесты – репетиция сдачи контрольных  тестов.

По курсу предусмотрено выполнение трех лабораторных работ, за правильное выполнение первой работы начисляется 3 балла, второй – 3, а третьей – 14 баллов. Итого за выполнение цикла лабораторных работ можно получить 20 баллов.

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

Выполнение курсового проекта позволяет получить 36 баллов за  проект.

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

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

В лабораторной работе №3 из 14 тем студент выбирает только семь, связанных тематикой курсового проекта, что стимулирует студента к более глубокому изучению дисциплины.

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

При наличии  ошибок в программном коде по каждой теме лабораторной работы №3 снимаются 2 балла, итого: 14.

За каждую принципиальную ошибку в курсовом проекте снимаются 5 баллов. При наличии 3-х и более принципиальных ошибок студент не получает баллов по курсовому проекту. Защита курсового проекта на «отлично» дает дополнительно 10 бонусных баллов.

Все бонусные баллы добавляются только тогда, когда общая сумма баллов (вместе с бонусными) меньше 100. 

Итого максимальная сумма баллов, которую можно получить по дисциплине составляет 100 баллов. Для получения допуска к экзамену необходимо выполнить курсовой проект и набрать более двух третьих от этой суммы. Для получения допуска к экзамену необходимо набрать не менее 67 баллов. Если их окажется меньше, то предстоят повторная сдача тестов по дисциплине с набором не менее 20 баллов и дополнительное собеседование по материалу дисциплины. Если же сумма баллов больше или равна 67, то студент получает допуск к экзамену, который сдает преподавателю в обычном порядке: получает экзаменационный билет (3 вопроса), готовится и отвечает устно.

При наборе студентом 90 и более баллов количество вопросов в экзаменационном билете уменьшается до двух.


3. Информационные ресурсы дисциплины

3.1. Библиографический список

Основной:

1. Дейт, К. Введение в системы баз данных / К. Дейт. - 8-е издание. – М.: Вильямс, 2006, 2008. – 1248 c.

2. Веллинг, Л. Разработка Web-приложений с помощью PHP и MySQL / Л. Веллинг, Л. Томсон. - 3-е издание. – М.: Вильямс, 2008, 2010. – 875 c.

3. Кузнецов, С.Д. Базы данных: языки и модели: учебник / С.Д. Кузнецов. – M.: Бином-Пресс, 2008. – 720 c.

Дополнительный:

4. Малыхина, М. П. Базы данных: основы, проектирование, использование / М.П. Малыхина. - 2-е издание. - СПб.: БХВ-Петербург, 2007. – 517 с.

5. Преснякова, Г.В. Проектирование интегрированных реляционных баз данных / Г.В. Преснякова. – М.,СПб.: “КДУ” Петроглиф, 2007. – 223 с.

6. Мальцев, М.Г. Базы данных: учеб. пособие / М.Г. Мальцев, А.Д. Хомоненко, В.М. Цыганков. – СПб.: Корона принт, 2007. - 736 с.

7. Копейкин, М. В. Базы данных. Основы SQL реляционных баз данных: учеб. пособие / М.В. Копейкин, В.В. Спиридонов, Е.О. Шумова. – СПб.: Изд-во СЗТУ, 2006. – 177 c.

8. Копейкин, М. В. Базы данных. Концепция баз данных: учеб. пособие / М.В. Копейкин, В.В. Спиридонов, Е.О. Шумова. – СПб.: Изд-во СЗТУ, 2006. – 117 c.

9. Копейкин, М.В. Базы данных. Инфологические модели баз данных: учеб. пособие / М.В. Копейкин, В.В. Спиридонов, Е.О. Шумова. – СПб.: Изд-во СЗТУ, 2004. – 190 c.

10. Мейер, М. Теория реляционных баз данных / М. Мейер. – М.: Мир, 1987. – 608 с.

11. Базы данных: метод. указания к курсовому проектированию / сост.: М.В. Копейкин, В.В. Спиридонов, Е.О. Шумова. – СПб.: Изд-во СЗТУ, 2005. - 172 c.

12. Конноли, Т. Базы данных: проектирование, реализация и сопровождение: теория и практика / Т. Конноли, К. Бегг. - 3-е издание. – М.: Вильямс, 2003. – 1439 c.

13. Проектирование объектно-реляционных баз данных / Г.П. Воронин; под ред. О. А. Петухова. – Л.: Судостроение, 1986. – 180 c.

14. Базы данных: рабочая программа: метод. указания к выполнению лаб. работ / сост.: М.В. Копейкин, В.В. Спиридонов, Е.О. Шумова. – СПб.: Изд-во СЗТУ, 2004. - 100 c.

15. Базы данных: метод. указания к выполнению лаб. работ / сост.: М.В. Копейкин, В.В. Спиридонов, Е.О. Шумова. – СПб.: Изд-во СЗТУ, 2010. - 281 c.

16. Вагнер Г. Основы исследования операций. Том 2. – М.: Мир, 1973.- 488 c.

17. Копейкин, М.В. Базы данных. Книга 1: учеб. пособие / М.В. Копейкин, В.В. Спиридонов, Е.О. Шумова. – СПб.: Изд-во СЗТУ, 2010. – 247 c.

18. Копейкин, М.В. Базы данных. Книга 2: учеб. пособие / М.В. Копейкин, В.В. Спиридонов, Е.О. Шумова. – СПб.: Изд-во СЗТУ, 2010. – 219 c.

Средства обеспечения освоения дисциплины (ресурсы Internrt)

1. http://www.mysql.com

2. http://www.ord.com.ru


3.2. Опорный конспект

ВВЕДЕНИЕ

Вы начинаете изучение дисциплины “Базы данных”.

Современная жизнь немыслима без эффективного использования информации. Важной категорией являются системы обработки информации, от которых во многом зависит эффективность работы любого предприятия. Такая система должна: обеспечивать получение общих и/или детализированных отчетов по итогам работы; позволять легко определять тенденции изменения важнейших показателей; обеспечивать получение информации, критической по времени, без существенных задержек; выполнять точный и полный анализ данных.

Основу современной информационной технологии, обеспечивающей  управление информацией, составляют базы данных (БД) и системы управления базами данных (СУБД).

История развития СУБД насчитывает более 40 лет. В 1968 году была введена в эксплуатацию первая промышленная СУБД система IMS фирмы IBM. В 1975 году появился первый стандарт ассоциации по языкам систем обработки данных — Conference of Data System Languages (CODASYL), который определил ряд фундаментальных понятий в теории систем баз данных.

В дальнейшее развитие теории баз данных большой вклад был сделан американским математиком Э. Ф. Коддом, который является создателем реляционной модели данных.

Изучение курса БД невозможно без разбора таких понятий, как информация и информационная система (ИС).

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

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

В этом смысле ИС – это предприятие, вуз, отдел банка и т.д. В теории БД термин ИС употребляют по отношению к автоматизированной ИС.

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

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

В курсе также уделяется внимание вопросам иллюстрации принципов организации и функционирования  СУБД на примере их использования в локальных и глобальных сетях (WEB приложениях с применением языка PHP - “Hypertext Preprocessor (Препроцессор Гипертекста)").

Схема работы с разделом 1

Раздел 1. Назначение и основные компоненты системы баз данных

Первый раздел курса включает две темы: “ СУБД – основа информакионных систем” и “ Современные архитектуры ИС. После изучения каждой темы Вам следует ответить на вопросы для самопроверки.

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

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

http://www.citforum.ru/database/osbd/contents.shtml,

http://web.dklab.ru/ 

или к главе 1 учебника [1] или главам 1, 2 учебника [3].

1.1. СУБД – основа информационных систем

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

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

Если Вы испытываете затруднения в ответе на какой-либо вопрос, обратитесь к материалам главы 1 учебника [1] или [3].

1.1.1. Эволюция развития систем управления данными

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

В большинстве случаев при создании собственной ИС невозможно обойтись без использования баз данных. Чем отличается "база данных" от какого бы то ни было набора данных, поддерживаемого в файлах операционной системы? Основное отличие состоит в том, что набором данных, входящих в состав базы данных управляет специальная программа, обычно называемая "системой управления базами данных (СУБД)", которая обладает знаниями по взаимосвязи между разнородными данными предметной области. Например, в случае ИС управления ВУЗом, СУБД, управляющая соответствующей базой данных, должна знать, что для экзаменационной ведомости не могут появиться фамилии студентов, не сдавших необходимые зачеты. Такого типа свойства называются целостностью базы данных. При создании базы данных ИС разработчик сообщает СУБД, какого рода ограничения целостности система должна поддерживать в базе данных, а далее ответственность берет на себя СУБД, без требования вмешательства прикладной программы.

Второй важной особенностью СУБД является обеспечение выполнения так называемых "незапланированных" запросов к базе данных. Представим себе, что при проектировании информационной системы, предназначенной для автоматизации управления ВУЗом, было запланировано выполнение запросов об успеваемости учебных групп, а впоследствии понадобилась информация об успеваемости в разрезе, например, возрастного или полового признака студентов. При отсутствии СУБД понадобилась бы переделка ИС. Однако СУБД, обладая достаточными знаниями о предметной области (например, о структуре и смысле объектов ИС), включающая универсальный язык запросов (например, язык SQL Structured Query Languague), позволяющий сформулировать произвольный запрос на выборку информации из соответствующей базы данных, в некоторой степени повышает жизненный цикл ИС. Такой запрос может быть в любой момент подан с терминала или встроен в одну из прикладных программ, входящих в ИС.

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

Сегодня развитые компьютерные архитектуры обычно относятся к одной из двух категорий (или к их комбинации): информационно-вычислительный сервер (mainfraim) с более чем одним подключенным к нему терминалом или информационно-вычислительная сеть серверов и клиентских рабочих станций, обеспечивающая совместное использование ресурсов.

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

Специфика информационных программных систем

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

Во-первых, любая ИС предназначена для сбора, хранения и обработки информации. Поэтому в основе любой ИС лежит среда хранения и доступа к данным. Среда должна обеспечивать уровень надежности хранения и эффективность доступа, которые соответствуют области применения ИС.

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

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

1.1.2. Локальная  технология

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

Свойства технологии:

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

Рис. 1.1.  Локальная архитектура

Подобная архитектура использовалась в первых версиях СУБД DB2, Oracle, ORD, Ingres.

Многопользовательская технология работы обеспечивалась либо режимом мультипрограммирования (одновременно могли работать процессор и внешние устройства – например, пока в прикладной программе одного пользователя шло считывание данных из внешней памяти, программа другого пользователя обрабатывалась процессором), либо режимом разделения времени (пользователям по очереди выделялись кванты времени на выполнении их программ). Такая технология была распространена в период больших ЭВМ (IBM-370 и ЕС ЭВМ в СССР). Основным недостатком этой модели является  снижение производительности при увеличении числа пользователей.

Как правило, в основу ИС закладывается реляционная база данных (см. раздел 3, 4). Все подходы к организации ИС базируются на общей архитектуре "клиент-сервер". Различие состоит только в том, что делают клиенты и серверы. Тем не менее, широко применяется более узкое разделение на “файл-сервер”, непосредственно “клиент-сервер”, “Intranet”.

1.1.3. Архитектура с сетью и файловым сервером

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

Рис. 1.2.  Архитектура "файл-сервер"

Свойства технологии:

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

В рамках архитектуры "файл-сервер" были выполнены первые версии популярных так называемых настольных СУБД, таких, как Clipper, FoxBase и Microsoft Access. В подобных СУБД на файл-сервере гораздо проще вносить изменения в отдельные таблицы базы, минуя приложения, непосредственно из инструментальных средств (например, из утилиты Database Desktop фирмы Borland для файлов Paradox и dBase); подобная возможность облегчается тем обстоятельством, что фактически у таких СУБД база данных – набор отдельных таблиц (файлов), хранящихся в отдельном каталоге на диске.

В литературе указываются следующие основные недостатки данной архитектуры:

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

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

1. Дайте определение ИС и назначение и роль БД в ИС.

2. Что такое сервер и клиент.

3. Что такое файл серверная технология?

4. Что такое выделенный сервер?

5. Поясните, чем отличается локальная архитектура от файл-серверной?

6. Что такое монопольный и разделяемый режим обработки информации?

7. Где производится обработка приложений бизнес логики в рассмотренных архитектурах?

8. Что понимается под мэйнфреймом?

9. Что такое трафик сети?

1.2. Современные архитектуры ИС

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

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

Если Вы испытываете затруднения в ответе на какой-либо вопрос, обратитесь к материалам главы 2 учебника [1] или главы 28 учебника [3].

1.2.1. Архитектура "клиент – сервер"

Использование технологии "клиент – сервер" предполагает наличие некоторого количества компьютеров, объединенных в сеть, один из которых выполняет особые управляющие функции (является сервером сети), а остальные статус клиента.

Приложение-клиент формирует запрос к серверу, на котором расположена БД, на структурном языке запросов SQL или QBE. Удаленный сервер принимает запрос и переадресует его SQL-серверу БД. SQL-сервер – специальная программа, управляющая удаленной базой данных. SQL-сервер обеспечивает интерпретацию запроса, его выполнение в базе данных, формирование результата выполнения запроса и выдачу его приложению-клиенту. При этом ресурсы клиентского компьютера не участвуют в физическом выполнении запроса; клиентский компьютер лишь отсылает запрос к серверной БД и получает результат, после чего интерпретирует его необходимым образом и представляет пользователю. Клиентскому приложению посылается только результат выполнения запроса (только те данные, которые необходимы клиенту), а не вся таблица (ы), как это происходит в стандартной файл-серверной архитектуре. В итоге снижается нагрузка на сеть и повышается быстродействие системы. Кроме того, SQL-сервер, если это возможно, оптимизирует полученный запрос таким образом, чтобы он был выполнен в минимальное время с наименьшими накладными расходами. Архитектура подхода представлена на рис. 1.3.

Поскольку правила целостности данных определяются в базе данных на сервере и являются едиными для всех приложений, использующих эту БД, повышается безопасность системы. Мощный аппарат транзакций, поддерживаемый SQL-серверами, позволяет исключить одновременное изменение одних и тех же данных различными пользователями и предоставляет возможность откатов к первоначальным значениям при внесении в БД изменений, закончившихся аварийно.

Функции приложения-клиента:

  •  Посылка запросов серверу.
  •  Интерпретация результатов запросов, полученных от сервера.
  •  Представление результатов пользователю в некоторой форме (интерфейс пользователя).

Функции серверной части:

  •  Прием запросов от приложений-клиентов.
  •  Интерпретация запросов.
  •  Оптимизация и выполнение запросов к БД.
  •  Отправка результатов приложению-клиенту.
  •  Обеспечение системы безопасности и разграничение доступа.
  •  Управление целостностью БД.
  •  Реализация стабильности многопользовательского режима работы.

Рис. 1.3. Архитектура удаленных БД "клиент – сервер"

Работа в архитектуре "клиент – сервер" построена следующим образом:

  •  База данных (файл) в виде набора таблиц находится на жестком диске специально выделенного компьютера (сервера сети).
  •  СУБД располагается только на сервере сети.
  •  Существует локальная сеть, состоящая из клиентских компьютеров, на каждом из которых установлено клиентское приложение для работы с БД.
  •  На каждом из клиентских компьютеров пользователи имеют возможность запустить приложение. Используя предоставляемый приложением пользовательский интерфейс, он формирует SQL запрос к СУБД, расположенной на SQL сервере, на выборку/обновление информации.  Т.е. по сети от клиента к серверу передается лишь текст запроса.
  •  СУБД инкапсулирует внутри себя все сведения о физической структуре БД, расположенной на сервере.
  •  СУБД инициирует обращения к данным, находящимся на сервере, в результате которых на сервере осуществляется вся обработка данных и лишь результат выполнения запроса копируется на клиентский компьютер, который, используя пользовательский интерфейс, отображает результат выполнения запросов.

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

В архитектуре "клиент – сервер" работают так называемые "промышленные" СУБД. Промышленными они называются из-за того, что именно СУБД этого класса могут обеспечить работу информационных систем масштаба среднего и крупного предприятия. К разряду коммерческих промышленных СУБД принадлежат MS SQL Server, Oracle, Gupta, Informix, Sybase, DB2, ряд других.

Как правило, SQL-сервер обслуживается отдельным сотрудником или группой сотрудников (администраторы SQL-сервера). Они управляют физическими характеристиками баз данных, производят оптимизацию, настройку и переопределение различных компонентов БД, создают новые БД, изменяют существующие и т.д., а также выдают привилегии (разрешения на доступ определенного уровня к конкретным БД, SQL-серверу) различным пользователям.

Основные достоинства данной архитектуры по сравнению с архитектурой "файл-сервер":

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

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

В рамках направления "клиент-сервер" существуют два основных направления: "тонкий" и "толстый" клиент.

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

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

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

1.2.2. Трехзвенная  архитектура "клиент – сервер"

Трехзвенная (в некоторых случаях многозвенная) архитектура  представляет собой дальнейшее совершенствование технологии "клиент – сервер". Рассмотрев архитектуру "клиент – сервер", можно заметить, что она является 2-х звенной: первое звено – клиентское приложение, второе звено – сервер БД + сама БД. В этой архитектуре, кроме клиентской части системы и сервера (ов) базы данных, вводится промежуточный сервер приложений. На стороне клиента выполняются только интерфейсные действия, а вся логика обработки информации (ранее входившая в клиентские приложения) поддерживается в сервере приложений (бизнес-правила можно реализовать как на сервере используя механизмы программирования сервера хранимые процедуры, триггеры, представления и т.п.).

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

Рис. 1.4. Трехзвенная архитектура "клиент-сервер" с выделенным сервером приложений

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

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

  •  Клиентское приложение реализует главным образом интерфейс с пользователем. Никаких объемных вычислений, никаких непосредственных обращений к базе данных. Как следствие - невысокие требования к аппаратным ресурсам;
  •  Сервер приложений реализует все прикладные расчеты, связанные с обращением к базе данных. И при этом не имеет никакого прикладного интерфейса с пользователем;
  •  Сервер базы данных занимается только хранением данных в файлах базы данных и обеспечением их целостности. И никаких функций, выходящих за эти рамки, он практически не реализует.

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

Клиент занимается только организацией интерфейса с пользователем, сервер баз данных - только стандартизованной обработкой данных. Для реализации логики обработки данных архитектура предусматривает отдельный выделенный сервер (сервер приложений), который в некоторых случаях может  размещаться на клиенте в качестве динамической библиотеки. Данная архитектура позволила соединить достоинства тонкого и толстого клиентов: хорошая переносимость соединяется в ней с невысокими требованиями к клиенту.

Свойства архитектуры:

  •  База данных в виде набора файлов находится на жестком диске специально выделенного компьютера (сервера сети).
  •  СУБД располагается также на сервере сети.
  •  Существует специально выделенный сервер приложений, на котором располагается программное обеспечение (ПО) делового анализа (бизнес-логика).
  •  Существует множество клиентских компьютеров, на каждом из которых установлен так называемый "тонкий клиент" – клиентское приложение, реализующее интерфейс пользователя.
  •  На каждом из клиентских компьютеров пользователи имеют возможность запустить приложение – тонкий клиент. Используя предоставляемый приложением пользовательский интерфейс, он инициирует обращение к ПО делового анализа, расположенному на сервере приложений.
  •  Сервер приложений анализирует требования пользователя и формирует запросы к БД. Для общения используется специальный язык запросов SQL, т.е. по сети от сервера приложений к серверу БД передается лишь текст запроса.
  •  СУБД инкапсулирует внутри себя все сведения о физической структуре БД, расположенной на сервере.
  •  СУБД инициирует обращения к данным, находящимся на сервере, в результате которых результат выполнения запроса копируется на сервер приложений.
  •  Сервер приложений возвращает результат в клиентское приложение (пользователю).
  •  Приложение, используя пользовательский интерфейс, отображает результат выполнения запросов.

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

Однако, разработчики и пользователи информационных систем, основанных на архитектуре "клиент-сервер", часто бывают неудовлетворены постоянно существующими сетевыми накладными расходами, которые следуют из потребности обращаться от клиента к серверу с каждым очередным запросом. На практике возможна ситуация, когда для эффективной работы отдельной клиентской составляющей информационной системы в действительности требуется только небольшая часть общей базы данных. Это приводит к идее поддержки локального кэша (части общей базы данных) на стороне каждого клиента.

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

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

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

1. Архитектура с несколькими процессами

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

2. Многопоточная архитектура

Эта архитектура использует только один исполняемый файл, с несколькими потоками исполнения. Главное преимущество – более скромные требования к оборудованию, чем для архитектуры с несколькими процессами. Здесь сервер берет на себя разделение времени между отдельными потоками, иногда давая преимущество некоторым задачам над другими. Кроме того, отпадает необходимость в сложном механизме взаимодействия процессов. По этой архитектуре реализованы MS SQL Server и Sybase SQL Server.

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

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

1.2.3. Архитектура Intranet-приложений

Появление Internet (совокупность взаимосвязанных компьютерных сетей мирового масштаба) естественным образом повлияло на технологию создания корпоративных ИС, которая получила название Intranet. Intranet  - это прежде всего корпоративная - локальная или территориально распределенная сеть, закрытая от внешнего доступа из Internet, но использующая сервисы Всемирной Сети Internet (e-mail, http, ftp, telnet, WWW и т.д.).

Применение Internet и WWW-технологий в корпоративной сети, изолированной от Internet, принято называть Intranet-технологией.

Архитектура Intranet-приложений является, по сути, продолжением и разновидностью трехслойной архитектуры клиент-сервер. Архитектура Intranet использует среду Internet, которая обладает глобальной доступностью для пользователей, является платформенно-независимой и для нее существует большое количество мощных и удобных средств разработки Web-приложений, что позволяет быстро и эффективно создавать клиентскую часть ИС. На этой архитектуре строятся все более распространяющиеся Internet-магазины, системы заказа билетов и т.д.

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

Хотя в общем случае в Intranet-системе могут использоваться все возможные службы Internet, наибольшее внимание привлекает гипертекстовая служба WWW. Видимо, для этого имеются две основные причины.

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

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

Рис. 1.5. Взаимодействие с базой данных в технологии интранет.

Разграничение функций между Web-браузером и Web-сервером является очень четким. Web-сервер предоставляет HTML-страницы, а браузер отображает эти страницы путем интерпретации тегов HTML.

Однако, при всех своих преимуществах (простота организации, стандартность интерфейсов и т.д.) эта схема обладает ограничениями.

Прежде всего, как видно из рис. 1.5, в информационной системе отсутствует прикладная обработка данных. Все, что может пользователь, это только просмотреть информацию, поддерживаемую Web-сервером. Далее, гипертекстовые структуры трудно модифицируются. Для того, чтобы изменить наполнение Web-сервера, необходимо приостановить работу системы, внести изменения в HTML-код и только затем продолжить нормальное функционирование. Наконец, далеко не всегда достаточен поиск информации в стиле просмотра гипертекста. Базы данных и соответствующие средства выборки данных по-прежнему часто необходимы.

Язык HTML позволяет вставлять в гипертекстовые документы формы для ввода и редактирования информации. Когда браузер ‘натыкается’ на форму, он предлагает пользователю заполнить ее, а затем посылает серверу сообщение, содержащее введенные параметры. Как правило, к форме приписывается некоторая внешняя процедура сервера. При получении сообщения от клиента сервер вызывает эту внешнюю процедуру с передачей параметров пользователя. Понятно, что такая внешняя процедура может, в частности, играть роль шлюза между Web-сервером и сервером баз данных. В этом случае параметры должны специфицировать запрос пользователя к базе данных. В результате получается конфигурация информационной системы, схематически изображенная на рис. 1.6.

Рис. 1.6. Доступ к базе данных в Intranet-системе

На принципах использования внешних процедур основывается также возможность модификации документов, поддерживаемых Web-сервером, и создание временных "виртуальных" HTML-страниц.

Даже начальное введение в Intranet было бы неполным, если не упомянуть про возможности языка Java. Java - это интерпретируемый объектно-ориентированный язык программирования, созданный на основе языка Си++. Мобильные коды (апплеты), полученные в результате компиляции Java-программы, могут быть привязаны в HTML-документу. В этом случае они поступают на сторону клиента вместе с документом и выполняются либо автоматически, либо по явному указанию. Апплет может быть, в частности, специализирован как шлюз к серверу баз данных (или к какому-либо другому серверу). При применении подобной техники доступа к базам данных схема организации Intranet-системы становится такой как показано на рисунке 1.7, 1.8.

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

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

Рис. 1.7. Доступ к базе данных на стороне клиента Intranet-системы

Рис. 1.8. Трехуровневая архитектура клиент-сервер Intranet-системы

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

Программы расширения серверной части

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

Существует три категории расширений серверной части: с обычным CGI, с гибридным CGI и с API.

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

1. Найдите сходства первого и современного этапов развития ИС.

2. Что такое Web сервер.

3. Что лежит в основе клиент-серверной технологии?

4. Что такое гипертекст и тег гипертекста?

5. Зачем нужен браузер?

6. Поясните, зачем нужен язык SQL?

7. Что потенциально быстрее – файловая система или база данных реализованная с использованием SQL?

8. В чем отличие понятия интернет от интарнет?

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

10. Что такое сервер приложений?

11. Поясните назначение и принцип работы Router.

12. В чем различия между потоковой и процессной архитектурой процессора БД?

Резюме

Современный этап развития баз данных характеризуется появлением новой технологии доступа к данным — интернет. Основное отличие этого подхода от технологии клиент-сервер состоит в том, что отпадает необходимость использования специализированного клиентского ПО. Для работы с удаленной базой данных используется стандартный Браузер Интернета, например Microsoft Internet Explorer или Netscape Navigator, и для конечного пользователя процесс обращения к данным происходит аналогично скольжению по Всемирной Паутине (см. рис. 1.8), используя маршрутезатор (роутер от англ. Router) - сетевое устройство, на основании информации о топологии сети и определённых правил принимающее решения о пересылке пакетов сетевого уровня между различными сегментами сети.

При этом встроенный в загружаемые пользователем HTML-страницы код, написанный обычно на языке PHP, Java-script, Perl и других, отслеживает все действия пользователя и транслирует их в низкоуровневые SQL-запросы к БД, выполняя, таким образом, ту работу, которой в технологии клиент-сервер занимается клиентская программа. Важно понимать, что Java-программа хоть и загружается с web-сервера, но исполняется на компьютере посетителя (не на сервере), а PHP-программа исполняется на сервере.

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

Схема работы с разделом 2

Раздел 2. Архитектура банка данных

Второй раздел курса включает три темы: “Уровни представления баз данных”, “Категории пользователей банков данных” и Этапы проектирования моделей баз данных”. После изучения каждой темы Вам следует ответить на вопросы для самопроверки.

Работа с разделом 2 завершается сдачей контрольного теста.

Для того, чтобы Вы смогли успешно ответить на вопросы контрольного теста, Вам предоставляется возможность поработать с репетиционным тестом. Если Вы испытываете затруднения в ответе на какой-либо вопрос, обратитесь к главе 5 учебника [1] или к учебному пособию [7].

2.1. Уровни представления баз данных

При изучении данной темы Вы должны уяснить роль и место банков данных в информационных системах. Уровни представления (отображения) информации в моделях базах данных на основе стандарта ANSI/SPARC. Понятия схемы и подсхемы и особенности  архитектуры современных СУБД.

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

Если Вы испытываете затруднения в ответе на какой-либо вопрос, обратитесь к главе 2 учебника [1] или к  учебному пособия [8].

2.1.1. Основная терминология

Современные авторы часто употребляют термины "банк данных" и "база данных" как синонимы, однако в общеотраслевых руководящих материалах по созданию банков данных Государственного комитета по науке и технике (ГКНТ), изданных в 1982 г., эти понятия различаются. Там приводятся следующие определения банка данных, базы данных и СУБД:

Банк данных (БнД) — это система специальным образом организованных данных — баз данных, программных, технических, языковых, организационно-методических средств, предназначенных для обеспечения централизованного накопления и коллективного многоцелевого использования данных.

База данных (БД) — именованная совокупность данных, отражающая состояние объектов и их отношений в рассматриваемой предметной области.

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

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

Модель данных характеризуется тремя компонентами:

  1.  Структура данных, предназначенная для представления точки зрения пользователя на БД.
  2.  Множество допустимых операций, выполняемых в структуре данных, составляющее основу языка данных модели.
  3.  Ограничения для контроля целостности.

Программы, с помощью которых пользователи работают с БД, называются приложениями. В общем случае с одной БД могут работать множество различных приложений. Например, если БД моделирует некоторое предприятие, то для работы с ней может быть создано приложение, которое обслуживает подсистему учета кадров, другое приложение может быть посвящено работе подсистемы расчета заработной платы сотрудников, третье приложение работает как подсистемы складского учета и т.д. При рассмотрении приложений, работающих с одной БД, предполагается, что они могут работать параллельно и независимо друг от друга, и именно СУБД призвана обеспечить работу множества приложений с единой базой данных таким образом, чтобы каждое из них выполнялось корректно, но учитывало все изменения в БД, вносимые другими приложениями.

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

2.1.2. Архитектура базы данных.

В процессе научных исследований, посвященных тому, как именно должна быть устроена СУБД, предлагались различные способы реализации. Самым жизнеспособным из них оказалась предложенная американским комитетом по стандартизации ANSI (American National Standards Institute) трехуровневая система организации БнД, изображенная на рис. 2.1.

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

Концептуальный уровень — центральное управляющее звено, здесь база данных представлена в наиболее общем виде, который объединяет данные, используемые всеми приложениями, работающими с данной базой данных. Фактически концептуальный уровень отражает обобщенную модель предметной области (объектов реального мира), для которой создавалась база данных. Как любая модель, концептуальная модель отражает только существенные, с точки зрения обработки, особенности объектов реального мира. В источниках по базам данных  понятия схемы и подсхемы связываются с концептуальным и внешним уровнем соответственно.

Рис. 2.1.  Трехуровневая модель СУБД, предложенная ANSI\SPARC

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

Эта архитектура позволяет обеспечить логическую (между уровнями 1 и 2) и физическую (между уровнями 2 и 3) независимость при работе с данными. Логическая независимость предполагает возможность изменения одного приложения без корректировки других приложений, работающих с этой же базой данных. Физическая независимость предполагает возможность переноса хранимой информации с одних носителей на другие при сохранении работоспособности всех приложений, работающих с данной базой данных. Реализация принципа независимости данных является центральным в теории и практике баз данных. Это именно то, чего не хватало при использовании файловых систем.

Выделение концептуального уровня позволило разработать аппарат централизованного управления базой данных.

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

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

2.1.3. Процесс прохождения пользовательского запроса в СУБД

Рис. 2.2 иллюстрирует взаимодействие пользователя, СУБД и ОС при обработке запроса на получение данных. Под рабочей областью здесь понимается область оперативной памяти ЭВМ, доступная для пользовательского приложения.

Цифрами помечена последовательность взаимодействий.

Пользователь посылает СУБД запрос на получение данных из БД (стрелка 1).

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

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

Рис. 2.2. Схема прохождения запроса к БД

СУБД запрашивают информацию о части концептуальной модели.

СУБД получает информацию о запрошенной части концептуальной модели.

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

В СУБД возвращается информация о местоположении данных в терминах операционной системы.

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

ОС осуществляет перекачку информации из устройств хранения и пересылает ее в системный буфер.

ОС оповещает СУБД об окончании пересылки.

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

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

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

Механизм прохождения запроса в реальных СУБД гораздо сложнее, но и эта упрощенная схема показывает, насколько серьезными и сложными должны быть механизмы обработки запросов, поддерживаемые реальными СУБД.

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

1. Из каких составляющих складывается понятие банка данных?

2. В качестве чего используются запоминающие устройства с произвольным доступом в БД?

3. Что дает многоуровневая архитектура БнД?

4. Чем определяется скорость исполнения запроса?

5. Что такое внешняя, концептуальная и внутренняя модель данных?

6. Что такое база метаданных? Для каких целей ее применяют и где она хранится?

7. Что такое логическая и физическая независимость данных?

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

При изучении данной темы Вы должны уяснить роль администратора  БД в автоматизированных информационных системах (АИС). Эффективность АИС определяется не только использованным оборудованием и программным обеспечением, она напрямую зависит от уровней представления информации в моделях базах данных, т.е. от квалификации администратора  БД.

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

Если Вы испытываете затруднения в ответе на какой-либо вопрос, обратитесь к главе 2 учебника [1] или к  учебному пособию [8].

2.2.1. Классификация пользователей БнД

Как любой программно-организационно-техничеcкий комплекс, банк данных существует во времени и в пространстве. Он имеет определенные стадии своего развития:

  •  Проектирование.
  •  Реализация.
  •  Эксплуатация.
  •  Модернизация и развитие.
  •  Полная реорганизация.

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

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

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

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

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

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

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

В составе группы администратора БД должны быть:

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

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

2.2.2. Основные функции группы администратора БД

1. Анализ предметной области: описание предметной области, выявление ограничений целостности, определение статуса (доступности, секретности) информации, определение потребностей пользователей, определение соответствия "данные—пользователь", определение объемно-временных характеристик обработки данных.

2. Проектирование структуры БД: определение состава и структуры файлов БД и связей между ними, выбор методов упорядочения данных и методов доступа к информации, описание БД на языке описания данных (ЯОД).

3. Задание ограничений целостности при описании структуры БД и процедур обработки БД:

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

- определение динамических ограничений целостности, присущих предметной области в процессе изменения информации, хранящейся в БД;

- определение ограничений целостности, вызванных структурой БД;

- разработка процедур обеспечения целостности БД при вводе и корректировке данных;

- определение ограничений целостности при параллельной работе пользователей в многопользовательском режиме.

4. Первоначальная загрузка и ведение БД:

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

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

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

5. Защита данных:

- определение системы паролей, принципов регистрации пользователей, создание групп пользователей, обладающих одинаковыми правами доступа к данным;

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

- разработка средств фиксации доступа к данным и попыток нарушения системы защиты;

- тестирование системы защиты;

- исследование случаев нарушения системы защиты и развитие динамических методов защиты информации в БД.

6. Обеспечение восстановления БД:

- разработка организационных средств архивирования и принципов восстановления БД;

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

7. Анализ эффективности функционирования БД:

- анализ показателей функционирования БД;

- анализ обращений пользователей БД: сбор статистики по характеру запросов, по времени их выполнения, по требуемым выходным документам;

- планирование реструктуризации (изменение структуры физической организации базы данных) БД и реорганизации БнД.

8. Работа с конечными пользователями:

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

- сбор информации об оценке работы БД;

- обучение пользователей, консультирование пользователей;

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

9. Подготовка и поддержание системных средств:

- анализ существующих на рынке программных средств и анализ возможности и необходимости их использования в рамках БД;

- разработка требуемых организационных и программно-технических мероприятий по развитию БД;

- проверка работоспособности закупаемых программных средств перед подключением их к БД;

- курирование подключения новых программных средств к БД.

10. Организационно-методическая работа по проектированию БД:

- выбор или создание методики проектирования БД;

- определение целей и направления развития системы в целом;

- планирование этапов развития БД;

- разработка общих словарей-справочников проекта БД и концептуальной модели;

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

- курирование подключения нового приложения к действующей БД;

- обеспечение возможности комплексной отладки множества приложений, взаимодействующих с одной БД.

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

1. Приведите классификацию пользователей БД?

2. Кто такой администратор приложений?

3. Кто и как определяет права доступа к БД?

4. Каким образом администратор БД определяет информационные потребности предприятия?

5. Что такое структурные ограничения целостности и ограничения бизнес логики?

6. В какой из моделей (внешней, концептуальной или внутренней) фиксируютя структурные ограничения?

7. Что такое логическая и физическая независимость данных?

8. Перечислите основные функции администратора БнД.

9. Из каких компонент состоит модель данных?

2.3. Концепции и этапы проектирования баз данных

При изучении данной темы Вы должны рассмотреть концепцию жизненного цикла БД  и методы, используемые при проектировании моделей баз данных различных уровней поддерживаемых СУБД.

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

При затруднениях в ответе на какой-либо вопрос следует обратиться к главе 14 учебника [1] или к материалам  учебного пособия [9].

2.3.1. Жизненный цикл БД

Основные функции администратора базы данных, рассмотренные выше, тесно связаны с понятием жизненного цикла системы (процессов проектирования, сопровождения и расширения ИС). Главной составляющей в жизненном цикле БД является создание единой (интегрированной) базы данных и программ, необходимых для ее функционирования.

Основной целью создания и использования моделей данных в различных ИС (предназначенных для удовлетворения информационных потребностей предприятия), является снижение затрат на разработку и эксплуатацию ИС, что достигается частичной автоматизацией процессов связанных с различными стадиями жизненного цикла системы (рис.2.5.).

База данных, как информационная модель предметной области, представляет собой описание состояния предметной области на формальном языке. Соотнесение представления объектов в базе данных их реальным прообразам достигается только посредством описания состояния предметной области на естественном языке. Введение формального языка приводит к необходимости однозначного перевода описания на одном языке (естественном или формальном) в описание на другом языке и к необходимости их эквивалентной интерпретации.

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

При этом принято считать, что:

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

Эквивалентная интерпретация достигается введением абстрактных состояний предметной области, определяемых формально и служащих однозначной интерпретацией описания состояния, как на естественном, так и на формальном языке (соответствующие функции интерпретации на рис. 2.3 обозначены IЕА и IФА). Описания состояний на естественном и формальном языке эквивалентны, если одно из них является результатом перевода другого, и если их интерпретацией является одно и то же абстрактное состояние.

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

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

Рис. 2.4. Уровни отображения информации

Задача проектирования модели ПО сводится к последовательному эквивалентному отображению одного уровня абстракции в другой с учетом критериев к моделям каждого уровня. Практически во всех литературных источниках, связанных с базами данных, приводится подробный и обширный список критериев предъявляемых к различным моделям, но в качестве общепринятых выделяют:

  •  достоверность – соответствие способу определения и организации информации в данной ПО;
  •  отсутствие избыточности – исключение излишней информации;
  •  расширяемость – логическая независимость от данных. Способность развиваться и включать новые требования с минимальным воздействием на работу уже существующих моделей. Такие изменения концептуальной схемы, как добавление или удаление новых сущностей, атрибутов или связей, должны осуществляться без необходимости внесения изменений в уже существующие внешние схемы для других групп пользователей.

Отметим, что не в одной из существующих СУБД принцип логической и физической независимости данных не реализован полностью.

Следует также отметить, что важный критерий производительности СУБД (точнее, тех средств, что использует АИС для доступа к данным) - скорость исполнения транзакции (выполнение запросов по модели), зависит непосредственно от организации структуры физической модели и архитектуры рассмотренной в разделе 1 информационной системы.

Ниже на рис.2.5. показан жизненный цикл базы данных.

2.3.2. Общая структура процесса проектирования БД

Проектирование (моделирование) базы данных представляет собой многоэтапный процесс. Основные этапы этого процесса приведены на рис. 2.6).

Рис. 2.5. Жизненный цикл БД

Подробно действия, отраженные на приведенном рисунке, рассмотрены в  учебном пособии [7]. На рис. 2.6 представлены три этапа проектирования: проектирование информационной схемы информационной базы, выбор средств реализации и этап эксплуатации и сопровождения  БД.

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

Описание внешней модели часто называют подсхемой. Кроме того, термин подсхема ассоциируется с понятием формы (документа), посредством которой пользователь наполняет базу хранимыми данными. Для задания подсхемы применяется схема БД и алгоритмы соответствующих прикладных программ (приложений) реализуемых на внутреннем языке  целевой СУБД. Например, для СУБД Qracle таким языком является PL\SQL, а для Acsess – язык VBA (Visual Basic).

Каждый из этапов разбивается на несколько шагов проектирования (рис. 2.6). Очень важным является выбор СУБД, от которого в значительной степени зависит работоспособность построенной базы данных.

Рис. 2.6. Этапы проектирования БД

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

1. Что такое жизненный цикл БД?

2. Назовите и раскройте суть основных этапов проектирования БД.

3. Что такое ILM и чем она отличается от концептуальной модели?

4. Назовите критерии выбора СУБД?

5. В какой из моделей фиксируются ограничения бизнес логики?

6. Поясните, что Вы понимаете под избыточностью данных?

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

Резюме

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

Схема работы с разделом 3

Раздел 3. Модели и типы данных в БД

Третий раздел курса включает две темы: “Представление концептуальной модели средствами СУБД”, и Типовые модели данных СУБД”. После изучения каждой темы Вам следует ответить на вопросы для самопроверки.

Работа с разделом 2 завершается сдачей контрольного теста.

Для того, чтобы Вы смогли успешно ответить на вопросы контрольного теста, Вам предоставляется возможность поработать с репетиционным тестом. Если Вы испытываете затруднения в ответе на какой-либо вопрос, обратитесь к главе 5 учебника [1] или к учебному пособию [7].

3.1. Представление концептуальной модели средствами СУБД

При изучении данной темы Вы должны рассмотреть концепцию моделей БД и методы, используемые при проектировании моделей баз данных различных уровней поддерживаемых СУБД.

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

При затруднениях в ответе на какой-либо вопрос следует обратиться к главе 14 учебника [1] или к материалам  учебного пособия [9].

3.1.1. Общие представления о моделях данных СУБД

В соответствии с рис.2.6 после построения ILM выбирается СУБД, с помощью которой будет организована база данных и работа с ней. Каждая СУБД поддерживает определенные виды и типы данных, а также средства представления связей между данными, составляющими модель данных СУБД.

Вторая стадия – это отображение ILM в концептуальную модель данных целевой СУБД. Этот этап часто называют логическим проектированием базы данных или построением схемы модели. Под схемой базы данных будем понимать ее описание средствами языка определения данных.

Модель данных – это способ структурирования и формализации данных прикладной области для возможности их обработки.

Объекты, которыми оперирует модель, представляют собой сущности ILM. Сущности находятся во взаимосвязи друг к другу. Модель, таким образом, представляет собой совокупность элементов: объектов и связей и атрибутов их раскрывающих. Указанные элементы имеют содержательную (смысловую) интерпретацию только в ILM.

Связи (их иногда называют ассоциациями, отношениями, структурными связями) характеризуются кардинальными числами, и подразделяют на: один к одному (1:1), один ко многим (1:M), многие ко многим (M:N) (рис.3.1).

Рис. 3.1. Пример объектов и атрибутов их составляющих, с ассоциациями между ними

Каждый атрибут описывается как поле с типом (типы данных - numeric, char, date и т.д. Понятие тип данных в модели данных полностью адекватно понятию типа данных в языках программирования.) и характеристиками, возможными в выбранной СУБД.

В дальнейшем нам потребуются следующие термины:

  •  Элемент данных (поле) – наименьшая поименованная единица данных. Используется для представления значения атрибута.
  •  Запись – поименованная совокупность полей. Используется для представления совокупности атрибутов сущности (записи о сущности).
  •  Экземпляр записи – запись с конкретными значениями полей.
  •  Первичный ключ – минимальный набор полей записи, однозначно идентифицирующих экземпляр записи файла (таблицы, отношения).
  •  Файл – поименованная совокупность экземпляров записей одного типа на внешнем устройстве. Используется для представления однородного набора сущностей.
  •  Группа – это поименованная совокупность элементов данных и других групп, обобщающая понятия "файл" и "запись".
  •  Групповое отношение – поименованное бинарное отношение, заданное на двух множествах экземпляров рассматриваемых групп. По характеру бинарных связей различают групповые отношения вида 1:1, 1:M, M:1, M:N. В групповом отношении один член группы назначается владельцем отношения, другой – членом. Групповое отношение - иерархическое отношение между записями двух типов. Родительская запись (владелец группового отношения) называется исходной записью, а дочерние записи (члены группового отношения) - подчиненными.
  •  Ограничения целостности концептуальной модели. Используются для реализации как структурных ограничений концептуальной модели, так и внутренних ограничений модели данных.
  •  В качестве основных элементарных операций обычно рассматриваются следующие: поиск записи с заданным значением ключа, чтение нужной записи, добавление записи, корректировка, удаление.

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

3.1.2. Классификация моделей данных

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

Понятие "данные" в концепции баз данных — это набор конкретных значений, характеризующих объект, условие, ситуацию или любые другие факты, пригодные для переработки в некотором процессе. Информация – это смысл, который придается данным при их представлении.

Примеры данных: Иванов Иван Иванович, $7 и т. д. Данные не обладают структурой, данные становятся информацией тогда, когда пользователь задает им определенную структуру, то есть осознает их смысловое содержание. Поэтому центральным понятием в области баз данных является понятие модели.

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

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

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

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

Рис. 3.2. Классификация моделей данных

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

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

Модели, основанные на языках разметки документов, связаны прежде всего со стандартным общим языком разметки — SGML (Standart Generalised Markup Language), который был утвержден ISO в качестве стандарта еще в 80-х годах.

Этот язык предназначен для создания других языков разметки, он определяет допустимый набор тегов (ссылок), их атрибуты и внутреннюю структуру документа. Контроль за правильностью использования тегов осуществляется при помощи специального набора правил, называемых DTD-описаниями, которые используются программой клиента при разборе документа. Для каждого класса документов определяется свой набор правил, описывающих грамматику соответствующего языка разметки в некотором стандартизованном формате. Одним из клонов SGML являются языки HTML и XML (Extensible Markup Language), которые в настоящее время является основным механизмом представления информации в Интернете.

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

В качестве элемента гипертекстовой базы данных, описываемой HTML, используется текстовый файл, который может легко передаваться по сети с использованием протокола HTTP.

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

Дескрипторные модели — сопоставляют каждому документу дескриптор — описатель. Этот дескриптор описывает документ (например, патент) в соответствии с теми характеристиками, которые требуются для работы с документами в разрабатываемой документальной БД.

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

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

1. Дайте определение модели данных  БД

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

3. Зачем нужна ILM и чем она отличается от концептуальной модели?

4. Перечислите основные типы моделей данных?

5. Что такое данные и тип данных?

6. Поясните, что Вы понимаете под информацией в БД?

7. Что такое гипертекстоваая БД и в каком формате она представлена?

3.2. Типовые модели данных СУБД

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

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

Если Вы испытываете затруднения в ответе на какой-либо вопрос, обратитесь к главе 4 учебника [4].

3.2.1. Иерархическая и сетевая модель данных

Иерархическая модель данных является наиболее простой среди всех моделей. Исторически она появилась первой среди всех моделей: именно эту модель поддерживает первая из зарегистрированных промышленных СУБД IMS фирмы IBM (1969 г).

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

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

Рис. 3.3. Иерархическая модель данных

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

Аномалия включения: В БД (модель 1) невозможно включить не оперировавшего хирурга.

Аномалия удаления: так как при удалении узла исключаются и все его подузлы, то при удалении хирурга из БД (модель 2) исчезают все его пациенты.

Иерархическая модель обладает следующими свойствами.

  1.  Существует корень. В базе столько деревьев, сколько объектов в ILM.
  2.  Узел содержит атрибуты.
  3.  Исходный и зависимый узлы находятся в отношении «непосредственный предок и потомок». Узлы добавляются горизонтально и вертикально.
  4.  Потомок соединен единственной связью с предком.
  5.  Предок может иметь несколько потомков.
  6.  Доступ к данным производится через предка.
  7.  Может существовать множество экземпляров узла.
  8.  При удалении узла удаляется все его поддерево.

Основной недостаток – невозможность реализации отношения «многие к многим» в рамках одной базы данных.

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

Сетевая модель основана на рекомендациях рабочей группы по базам данных КОДАСИЛ (CODASYL) (1969-1978 гг.).

Согласно рекомендациям, база данных делится на области, те – на записи, состоящие из полей. С другой стороны, база состоит из наборов, а те – из записей (рис. 3.4).

Связь «пациент-операция» означает «пациент перенес операцию», «хирург-операция» – «хирург выполнил операцию».

Отношение «пациент-хирург» – это отношение M:N, и для его реализации вводится добавочный связующий файл. При этом объекты пациент и хирург объявляются владельцами набора, а операция – членом набора. Наборы-владельцы (ключевые наборы - хэш таблицы), как и наборы-члены (детальные наборы) реализованы в виде отдельных файлов, структура которых различна.

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

Достоинства

  •  Реализуется отношение "многие к многим".
  •  Высокая производительность.

Недостатки

  •  Основной недостаток сетевой модели – трудность реорганизации базы данных, то есть изменения ее структуры. Обычно реорганизация требует выгрузки данных с последующей их загрузкой в БД с новой структурой. При этом важно не только не потерять данные, но и корректно определить ссылки, в противном случае часть информации будет недоступной.

Для организации физического размещения сетевых и иерархических данных в памяти ЭВМ могут использоваться следующие группы методов:

  •  представление линейным списком с последовательным распределением памяти;
  •  представление связными линейными списками (методы, использующие указатели и справочники).

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

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

3.2.2. Реляционная и постреляционная модель данных

Реляционная модель (как и любая рассмотренная выше и ниже) предназначена для отображения ILM в концептуальную модель СУБД. Если реализация СУБД позволяет четко разграничить логические и физические аспекты доступа и управления БД, использует алгебраическую систему (<носитель, множество операций>) как основы концептуальной схемы, то ее принято относить к СУБД реляционного типа.

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

В качестве носителя (структурной единицы) в реляционной модели выбрано отношение (relation) n-го порядка: при соответствующих операторах (реализованных в SQL или QBE) и концептуальном представлении в виде таблиц оно позволяет приблизиться к реализации принципа независимости данных.

Отношение n-го порядка – математическое множество, в котором порядок строк не имеет значения. Заметим, что понятие реляционная БД несколько шире, чем табличная: во втором случае предполагается, что к строке можно добраться по номеру, следовательно, порядок строк имеет значение. Традиционно позиционирование данных определялось адресами в памяти, в реляционной модели адресный способ выбора данных заменен ассоциативным. Каждая единица информации в реляционных БД  ассоциируется с уникальной тройкой: именем отношения, значением ключа, именем атрибута (рис.3.5). При таком подходе  закладывается непроцедурный  путь доступа к данным.

Напомним, что модель данных – это не только структура, это комбинация, по крайней мере, трех составляющих:

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

Структурная часть реляционной модели состоит из следующих компонент:

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

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

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

Достоинства.

  •  простота и доступность для понимания;
  •  объекты и связи представляются единым образом в виде отношений (плоских таблиц);
  •  встроенная оптимизация реализации алгоритмов поиска данных;
  •  наличие формального аппарата конструирования концептуальной модели и способов поиска данных (реляционная алгебра и реляционное исчисление).

Рис. 3.5. Таблица СОТРУДНИК

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

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

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

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

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

Существует несколько коммерческих постреляционных СУБД, самыми известными из которых являются системы Adabas, ORD и Universe.

3.2.3. Многомерная модель данных

В развитии концепций ИС можно выделить следующие два направления:

  •  системы транзакционной (оперативной) обработки (OLTP - On-Line Transaction Processing. Ежедневные операции: покупки, заказы, производство, регистрация и т.п.);
  •  системы аналитической обработки (системы поддержки принятия решений) OLAP - On-Line Analytical Processing.

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

В основе концепции OLAP - лежит многомерное представление данных. Термин OLAP ввел Кодд (E. F. Codd) в 1993 году. В своей статье он рассмотрел недостатки реляционной модели, в первую очередь невозможность "объединять, просматривать и анализировать данные с точки зрения множественности измерений, то есть самым понятным для корпоративных аналитиков способом", и определил общие требования к системам OLAP, расширяющим функциональность реляционных СУБД и включающим многомерный анализ как одну из своих характеристик.

"Сервер OLAP" — не определяют физического механизма хранения данных.

Хотя часто в публикациях аббревиатурой OLAP обозначается не только многомерный взгляд на данные, но и хранение самих данных в многомерной БД.

Многомерное концептуальное представление является наиболее естественным взглядом управляющего персонала на объект управления. Оно представляет собой множественную перспективу, состоящую из нескольких независимых измерений, вдоль которых могут быть проанализированы определенные совокупности данных. Одновременный анализ по нескольким измерениям данных определяется как многомерный анализ. Каждое измерение включает направления консолидации данных, состоящие из серии последовательных уровней обобщения, где каждый вышестоящий уровень соответствует большей степени агрегации данных по соответствующему измерению.

Многомерные СУБД (МБД) являются узкоспециализированными СУБД, предназначенными для интерактивной аналитической обработки информации.

Раскроем основные понятия, используемые в этих СУБД: агрегируемость, историчность и прогнозируемость данных.

Агрегируемость данных означает рассмотрение информации на различных уровнях ее обобщения. В ИС степень детальности представления информации для пользователя зависит от его уровня: аналитик, руководитель,оператор.

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

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

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

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

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

Рис. 3.6. Многомерная модель. Вариант агрегации данных по Avg (среднее)

По сравнению с реляционной моделью многомерная организация данных обладает более высокой наглядностью и информативностью. Для иллюстрации на рис. 3.7 приведено реляционное представления одних и тех же данных  агрегированных в многомерной модели рис. 3.6.

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

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

Измерение (Dimension) – это множество однотипных данных, образующих одну из граней гиперкуба. Примерами наиболее часто используемых временных измерений являются Дни, Месяцы, Кварталы и Годы. В качестве географических измерений широко употребляются Города, Районы, регионы и Страны. В многомерной модели данных измерения играют роль индексов, служащих для идентификации конкретных значений в ячейках гиперкуба.

Ячейка (Cell) или показатель – это поле, значение которого однозначно определяется фиксированным набором измерений. Тип поля чаще всего определен как цифровой. В зависимости от того, как формируются значения некоторой ячейки, обычно она может быть переменной (значения изменяются и могут быть загружены из внешнего источника данных или сформированы программно) либо формулой (значения, подобно формульным ячейкам электронных таблиц, вычисляются по заранее заданным формулам).

Рис. 3.7. Реляционная модель и многомерная модель.

В существующих МБД используются два основных варианта (схемы) организации данных: гиперкубическая и поликубическая.

В поликубической схеме предполагается, что в БД может быть определено несколько гиперкубов с различной размерностью и с различными измерениями в качестве граней. Примером системы, поддерживающей поликубический вариант БД, является сервер Oracle Express Server.

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

В случае многомерной модели данных применяется ряд специальных операций: формирование «среза», «вращение», агрегация и детализация.

 Roll up:  агрерация данных: по иерархии(-ям) до полного исключения измерения.

 Drill down: детализация: от обощенных данных к более детальным, от верхних уровней измерений – к нижним, детализация данных по дополнительным измерениям.

 Slice and dice: проекции и выборки – выборка нужных элементов кубика

 Pivot (rotate): вращение куба, визуализация, выборка и ориентация одно-, двух-, трехмерных срезов для визуального анализа.

 Другие операции:

 drill across: кросс-детализация (условно – смена кубов при drilldown).

 drill through: переход с самого нижнего уровня детализации OLAP-куба, к фактам из выбранной ячейки (из исходной реляционной таблицы).

«Срез» (Slice) представляет собой подмножество гиперкуба, полученное в результате фиксации одного или нескольких измерений. Формирование «срезов» выполняется для ограничения используемых пользователем значений, так как все значения гиперкуба практически никогда одновременно не используются.

Операция «вращение» (Rotate) применяется при двухмерном представлении данных. Суть ее заключается в изменении порядка измерений при визуальном представлении данных. Так, «вращение» двухмерной таблицы, показанной на рис. 3.7, приведет к изменению ее вида таким образом, что по оси X будут показаны предметы, а по оси Y – студенты.

Операцию «вращение» можно обобщить и на многомерный случай, если под ней понимать процедуру изменения порядка следования измерений. В простейшем случае, например, это может быть взаимная перестановка двух произвольных измерений.

Операции «агрегация» (Drill Up) и «детализация» (Drill Down) означают соответственно переход к более общему и к более детальному представлению информации пользователю из гиперкуба.

Основным достоинством многомерной модели данных является удобство и эффективность аналитической обработки больших объемов данных, связанных со временем. Недостатком многомерной модели данных является ее громоздкость для простейших задач обычной оперативной обработки информации.

Примерами систем, поддерживающих многомерные модели данных, являются Essbase (Arbor Software), Media Multi-matrix (Speedware), Oracle Express Server (Oracle) и Cache (InterSystems).

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

1. Что такое OLTP и OLAP БД?

2. Назовите и раскройте суть основных операций МБД.

3. Что такое измерение в многомерной модели?

4. Назовите критерии использования OLTP и OLAP.

5. Что такое отношение?

6. Поясните, что Вы понимаете под постреляционной БД?

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

8. Что такое кортеж?

9. Что такое кординальное число и степень отношения?

10. Определите понятие домена и атрибута?

Резюме. Описаны основные категории моделей данных используемые при проектировании концептуальной модели СУБД.

Схема работы с разделом 4

Раздел 4. Базовые элементы реляционных БД

Четвертый раздел курса включает две темы: “Проектирование реляционной базы данных”, “Нормализация отношений в БД”. После изучения каждой темы Вам следует ответить на вопросы для самопроверки.

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

Работа с разделом 4 завершается сдачей контрольного теста. Кроме того, по данному разделу выполняются практические задания 3 и 4, а также лабораторные работы № 1 и № 2.

Для того, чтобы Вы смогли успешно ответить на вопросы контрольного теста, Вам предоставляется возможность поработать с репетиционным тестом. Если Вы испытываете затруднения в ответе на какой-либо вопрос, обратитесь к главам 5-7, 11-13 учебника [1] или к материалам электронного учебного пособия [7]  и пособия [8].

4.1. Проектирование реляционной базы данных

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

По данной теме выполняется лабораторная работа № 3, а также раздел “Концептуальное проектирование” курсового проекта. Рекомендации по выполнению этих заданий приведены в методических указаниях 3.4.

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

Если Вы испытываете затруднения в ответе на какой-либо вопрос, обратитесь к главам 11, 12 учебника [1] или к материалам учебного пособия [8, 9].

4.1.1. Свойства и виды отношений

Отношения

Пусть  имеется  n  множеств  {D1, D2,...,Dn}.

R  есть отношение на этих множествах, если оно представляет собой множество элементов вида < d1, d2, . . . , dn > , где di  Di (i = 1, . . n).

Более строго, R - это подмножество декартова произведения указанных множеств и формально записывается:

R  D1  D2  ... Dn,

где - математический символ нестрогого включения;

- математический символ операции декартова произведения.

В исходные множества Di принято называть доменами (областями определения) R, а элементы R  < d1, d2, ..., dn > - кортежами  или  выборками (на рис.3.5 раскрывается суть некоторых понятий, связанных с отношением R).

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

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

Отношение обладает следующими свойствами:

  •  Отношение имеет имя, отличающее его от других отношений.
  •  Каждый атрибут имеет уникальное имя.
  •  Значения атрибута берутся из одного и того же домена.
  •  Каждый кортеж является уникальным, т.е. в отношении не может быть дублированных строк.
  •  Атрибут (или набор атрибутов), уникально идентифицирующий каждый кортеж, является первичным (primary) ключом отношения.
  •  Атрибут (или множество атрибутов) называется внешним (foreign) ключом, если в другом отношении он является первичным.

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

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

Примем следующие обозначения. Будем обозначать первыми заглавными латинскими буквами (A, B, ...) имена атрибутов, буквами R, Q – схемы атрибутов, строчными первыми (a, b, ...) – атрибуты, строчными r, q – состояние отношения. Схему R={A1, A2, ..., An} будем обозначать R[A1, A2, ..., An] или A1A2...An , отношение r со схемой R обозначим r(R) или r(A1A2...An).

Значение кортежа t на атрибуте A будем называть A-значением кортежа t. Если XR, будем называть t(X) X-значением кортежа t. Предполагается, что существует значение : t()= для каждого кортежа t, t1()=t2().

Ассоциации между отношениями и внутри отношений коротко рассмотрены в теме 3.1.1.

4.1.2. Реляционная алгебра

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

Как известно, алгебра есть множество вида

А: < H, S >  , где

H -носитель  (в данном случае - множество нормализованных отношений);

S -сигнатура (в данном случае - множество операций над отношениями).

Все множество S операций реляционной алгебры разбиты на два подмножества:

Стандартные теоретико-множественные операции:

- объединение U  Rrez=R1 U R2,

- пересечение ∩  Rrez=R1 ∩ R2,

- разность   \   Rrez=R1  \  R2,

- декартово произведение Rrez= R1 R2.

Специальные операции:

- проекция  Rrez (А) = R[A],

- ограничение Rrez  = R1[булевское выражение],

- соединение Rrez  = R1[булевское выражение]R2,

- деление  Rrez  = R1    R2.

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

Пример с указанными операциями представлен на рис. 3.8. Для имен атрибутов приняты следующие сокращения: ШД – шифр детали, ШМ – шифр материала, ЕИ – единица измерения, НР – норма расхода, НМ – наименование материала, ШМ"шифр материала на складе.

Исходные отношения R1, R2 и R3:

R1 (ШД, ШМ, ЕИ, НР)  R2 (ШД, ШМ, ЕИ, НР)  R3 (ШМ", НМ)

д1  м2      1   15           д2     м5      3    3          м2       ст-5

д2  м5      3    3           д2     м3      2   15          м9       ст-7

д2  м9      3    5

д3  м2      1   10

На рис. 3.9 представлен пример декартова произведения отношений R2 и R3.

Rrez (ШД, ШМ, ЕИ, НР, ШМ", НМ)

д2     м5     3       3    м2       ст-5

д2     м3     2     15    м2       ст-5

д2     м5     3       3    м9       ст-7

д2     м3     2     15    м9       ст-7

Рис. 3.9. Декартово произведение двух отношений

Специальные операции

ПРОЕКЦИЯ 

Операция унарна и предназначена для уменьшения степени отношения.

Пусть имеется исходное отношение  R1(A1,..., An) и список атрибутов А. Проекция отношения R1 на список А обозначается следующим образом:

Rrez (A) = R1 [A]  или  A(r) { t(A) | tr }.

где - [ ] (квадратные скобки) являются операционными (или A(r)), т.е. используются для обозначения операции ПРОЕКЦИЯ (рис.10.a).

Рис. 3.8. Теоретико-множественные операции над отношениями.

ОГРАНИЧЕНИЕ (СЕЛЕКЦИЯ)

Операция ОГРАНИЧЕНИЕ (селекция, выборка) также, как и проекция, является унарной операцией, но в отличие от проекции ориентирована на выделение нужных строк отношения.

Пусть исходное отношение задано схемой:  R1 (A1, . . . , An).

Селекцией A = a(r) называется отношение r (R) = A = a(r){tr | t(A)=a}.

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

Операцию ограничения также записывают следующим образом:

Rrez (A1, ..., An) = R1[булевское выражение для значений атрибутов R1].

На интуитивном уровне операцию ограничения лучше всего представлять как взятие некоторой "горизонтальной" вырезки из отношения-операнда (R1 из рис.3.9).

Rrez (A) = R1 [ШМ, ЕИ]                          Rrez (A) =  ШМ = ”м2” OR  ЕИ = ”1”

Результат     Результат

м2      1     м2     1

м5      3

м9      3      

a) A(r) – проекция                       b) селекция – R1 [ШМ=”м2” OR  ЕИ=”1” ]

Рис. 3.10. Пример операции проекции (a) и селекции (b)

СОЕДИНЕНИЕ

Операция СОЕДИНЕНИЕ двух и более отношений является важнейшей операцией. При этой операции кортежи одного отношения конкатенируют (соединяются) с выборками другого, точно также, как и при декартовом произведении двух отношений, но при условии, что булевское выражение, в каждый терм которого входят атрибуты обоих отношений, принимает значение "истина".

Пусть r(R) и s(S) – отношения. Соединением r и s называется отношение

r s = q(RS) = {t(RS) | tr  r, ts  s : tr = t(R), ts = t(S)}.

Итак, для двух исходных отношений, заданных схемами:

R1 (A1, ..., An)  и  R2 (B1, ..., Bm), в результате операции соединения получается отношение со схемой

Rrez (A1, . . . , An, B1, . . . ,Bm)  =  R1 [булевское выражение] R2.

В булевском выражении термы имеют вид:

(Ai    Bj), где - атрибуты  Аi  и  Bj  определены на одном домене, а термы сравнения () выбираются из множества: { = , < > , > , < , >= , <= }.

Очень часто булевское выражение состоит из единственного терма. Если таким термом является "=" (знак равенства), то этот частный случай называется операцией   эквисоединения  двух отношений по атрибутам Ai и Bj.

Если r(R), s(S) – отношения, Ai R , Bi S  и dom(Ai) = dom(Bi), 1 i n (Ai и Bi могут быть одинаковыми). Эквисоединением r и s по A1, A2,…,An и B1, B2,…, Bm называется отношение q(RS) = {t | tr r, tss, t(R) = tr, t(S) = ts, t(Ai) = t(Bi)}.

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

(A1=B1)  AND  (A2=B2) AND  ...  AND  (Akk).

Если RS = {B1B2Bl} = , то соединение rs, результатом которого является множество кортежей t(A1A2Ak C1C2Cm), таких, что t(A1A2Ak)r и t(C1C2Cm)s, называется декартовым произведением отношений r и s и  обозначается r  s.

Смысл операции соединения двух отношений более четко можно выразить сведением операции к ранее введенным:

Rrez(A1, ..., An, B1, ..., Bm) = R1 [(булевское  выражение)] R2 =

=  (R1 R2) [(булевское выражение)],

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

На рис. 3.11 представлен пример операции эквисоединения отношений R1 и R3, исходное состояние которых показано на рис.3.8.

Rrez (ШД, ШМ, ЕИ, НР, ШМ", НМ)  =  [R1.ШМ=R3. ШМ"].

д1      м2      1    15       м2    ст-5

д2      м9      3     5        м9    ст-7

д3      м2      1    10       м2    ст-5

Рис. 3.11. Пример операции эквисоединения R1 и R3

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

ДЕЛЕНИЕ

Пусть r(R) и s(S) – отношения, SR. Положим R = R - S. Тогда r, разделенное на s – это отношение r(R)={t | tss trr: tr(R)=t & tr(S)=ts}.

Отношение rrez – частное от деления r на s, что обозначается rrez = rs. Иначе rs – это максимальное подмножество rrez множества rrez(r), такое, что rrez  s r. Соединение – здесь декартово произведение.

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

Пусть задано отношение R1(ШД, ШМ) (рис. 3.12.а), которое задает возможные варианты изготовления деталей из разных материалов. И задано отношение R2 (рис. 3.12.b), указывающее, какие материалы хранятся на складе.

Рис. 3.12. R1 - Варианты изготовления. R2 - Материалы на складе

Если необходимо определить детали, которые могут быть изготовлены из  всех материалов, хранимых на складе, то неформально мы можем определить, что такой деталью является только деталь д2, она может быть изготовлена как из материала м5, так и из м9.

Фактически R2 есть подмножество материалов, из которых может быть сделана деталь  д2: {м5, м9}    {м3, м5, м9}.

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

Rrez (ШД) = R1[ШМ ШМ"]R2  , где    - символ операции деления.

Рассмотрим пример использования алгебры отношений при составлении запросов к базе данных. Пусть БД содержит отношения  R1(ШД, ШМ, НР) и R2(ШМ", НМ).

Запрос. Перечислить шифры материалов (ШМ) и их наименования (НМ), которые идут на изготовление одной  детали  в количестве большем чем 25 кг.

На языке реляционной алгебры запрос будет реализован на основе следующих операций:

Rrez (ШМ, НМ) = ((R1[НР > 25]) [ШМ]) [ШМ=ШМ"] R2[ШМ, НМ]

Круглые скобки определяют последовательность действий:

1) Ограничение отношения R1;

2) Проектирование промежуточного отношения;

3) Эквисоединение с R2;

4) Проектирование полученного результата.

Нетрудно видеть, что при таком подходе закладывается "процедурность" запроса, поэтому для языков манипулирования данными (ЯМД), построенных на алгебре отношений принято говорить как о процедурных языках.

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

1. Дайте определение понятию атомарный атрибут.

2. Какой смысл имеет в теории баз данных понятие схемы отношения?

3. Приведите определение понятия ‘отношение’.

4. Какие существуют разновидности ассоциаций между отношениями?

5. Что такое реляционная алгебра?

6. Приведите пример унарной и бинарной алгебраической операции?

7. На какие группы подразделяются алгебраические операции?

8. Что такое состояние отношения и схема БД?

9. Перечислите бинарные операции реляционной алгебры.

4.2. Нормализация отношений в БД

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

По данной теме выполняется лабораторная работа № 3, а также раздел “Концептуальное проектирование” курсового проекта. Рекомендации по выполнению этих заданий приведены в методических указаниях 3.4.

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

Если Вы испытываете затруднения в ответе на какой-либо вопрос, обратитесь к главам 11, 12 учебника [1] или к материалам учебного пособия [8].

4.2.1. Понятие о нормальных формах

Как отмечалось в предыдущей, теме второй составляющей алгебры является ее носитель. В реляционной модели носителем является набор специальным образом сконструированных нормализованных отношений – то, что на концептуальном уровне и является собственно базой данных. Важнейшие цели, которым служит база данных – это снижение избыточности данных и повышение достоверности отображения информации. Любое априорное знание об ограничениях на данные может служить этим целям. Один из методов формализации этих знаний основан на теории нормализации – установление ограничений между данными, которые частично отражает их семантику. Проектирование реляционной базы это фактически выделение нормальных форм.

Этот метод основан на фундаментальном в теории реляционных баз данных понятии зависимости (FD) между атрибутами отношений и выводимым из него понятия - реляционного ключа (RK).

Определение FD

В схеме отношения R (X, Y, …) атрибут X функционально определяет атрибут Y (условное обозначение XY), если в любой момент времени любому элементу проекции R[X] соответствует только один элемент проекции R[Y], в любом экземпляре схемы R.

Стрелка "" разделяет ФЗ на левую и правую части. При этом левую часть ФЗ, иногда называют детерминантой.

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

Полный набор имен атрибутов {A1, …, An} отношения R принято обозначать символом UR,  Ai  UR, (i=1, ..., n где n – степень отношения), а множество постулированных на R ограничений (функциональных, многозначных  зависимостей и зависимостей соединений) обозначают FR.

FR может связывать и совокупность атрибутов: f: {A1, ..., An}  {B1, ..., Bm}.

Для вывода из заданного множества FR замыкания множества зависимостей (всех зависимостей присущих R, обозначается F+R) или получения минимального покрытия набора FR (такого набора зависимостей H, что H+=F+R и удаление любой зависимости из H приводит к нарушению этого равенства), используют аксиомы Армстронга или их расширения и правила вывода построенные на этих аксиомах.

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

1. Рефлексивность. Если Y  X  UR, то зависимость X  Y логически следует из FD. Зависимость вида X  X называют тривиальной.

2. Пополнение. Если справедлива зависимость X  Y и Z  UR, то также будет справедлива и зависимость XZ YZ.

3. Транзитивность (транзитивные зависимости). Если справедлива зависимость X  Y  и Y  Z, то также справедлива и зависимость X  Z.

Доказано что перечисленные выше аксиомы являются непротиворечивыми и надежными, поэтому выделенные из UR (на основе аксиом и постулированных FR) заключения (проекции на R) являются истинными.

В отличие от математического определения отношения, отношение R в реляционной модели нормализовано, что подразумевает использование в качестве элементов кортежа атомарных значений (элемент кортежа не может быть множеством, мощность которого превышает единицу).

Отношение, обладающее свойством атомарности элементов его составляющих, называется нормализованным или, что то же самое, находящимся в первой нормальной форме (1НФ). Нормальные формы, в которых находятся отношения, составляют иерархию, в которой формы с большими номерами не обладают некоторыми нежелательными свойствами, характерными для форм с меньшими номерами. В теории нормальных форм для реляционных БД рассматривается пять уровней нормализации: 1НФ – 5НФ и форма Бойса-Кодда (промежуточная между 3НФ и 4НФ). Каждый из следующих уровней ограничивает типы допустимых FD отношения.

Для отношений, не находящихся в нормальных формах, существуют аномалии модификации. Различают аномалии добавления, изменения и удаления.

Как отмечается во всех руководствах по проектированию реляционных схем, выделенные множества UR, F+R являются исходными (входными) данными для автоматизированных методов построения реляционных баз данных (см. параграф 4.2.2). Однако если процессы построения F+R, RK  удается формализовать полностью, то процесс формирования FR не поддается полной формализации.

4.2.2. Формальные методы синтеза и декомпозиции нормальных форм

Неформально задача проектирования схемы реляционной базы данных ставится следующим образом. Пусть имеется некоторая схема базы данных SO, надо получить новую схему SD, эквивалентную в некотором смысле старой, но в чем-то лучше ее.

Для построения ‘хорошей’ реляционной реализации концептуальной схемы базы данных (т.е. такой, в которой выполнялась бы свойство соединения без потерь информации и свойство сохранения функциональных зависимостей для результирующего набора нормализованных отношений), которая бы находилась хотя бы в 3НФ, используют следующие методы: декомпозиции, синтеза, метод ER-диаграмм (проектирование с использованием метода сущность – связь) и их комбинации.

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

Наибольшее развитие в этом методе получил алгоритм Фейджина для приведения отношений к 4НФ.

Метод синтеза, состоящий в конструировании (синтезе) набора декомпозиционных подсхем, удовлетворяющих определенным свойствам, из заданного множества атрибутов UR выбранной предметной области  на основе заданного множества функциональных зависимостей FD, заданных на этих атрибутах.

Формально задача проектирования реляционной базы данных ставится следующим образом: необходимо устранить избыточность данных путем разбиения исходного отношения на несколько проекций, являющихся нормализованными отношениями, с условием восстановления исходного отношения из полученные проекций.

,  при ограничении  R = R1  R2   Rn.

В настоящее время (табл. 4.1) используются автоматизированные подходы к построению схемы реляционной базы данных, формирующих схему модели данных как совокупность схем отношений, находящихся в 3НФ и 4НФ.

Авторы метода

Фэйджин

Делобель-Кейси

Бернштейн

Ислур

Неклюдова-Цаленко

Дьяков

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

Мз

Фз

Фз

Фз

Фз

Фз

Нормальная форма схемы SD

4НФ

3НФ

3НФ

3НФ

3НФ

3НФ

Вычислительная сложность алгоритма

NP

NP

O(|FD|2)

O(|FD|2)

NP

-

Таблица 4.. Характеристики методов проектирования реляционных схем

Обозначения: NP-алгоритм включает решение NP – полной задачи, |FD|- длина строки литер необходимая для записи всех FD.

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

При этом каждый экземпляр исходной  схемы r(R) является естественным соединением его проекций на все декомпозиционные подсхемы.

Свойство сохранения зависимостей в наборе декомпозиционных подсхем {Sch(R1), …, Sch(Rn)} относительно исходного набора FR, состоит в том, что из объединения всех зависимостей принадлежащих проекциям FR  на Sch(Ri), i=1, .., n  логически следуют все зависимости из FR :

, где  - проекция множества функциональных зависимостей на множество атрибутов принадлежащих , т.е. множество зависимостей (AB)FD+ таких что A, B.

4.2.3. Проектирование с использованием метода сущность – связь

Характеристики перечисленных выше алгоритмов для методов декомпозиции и синтеза сведены в таблицу () из которой видно, что ни один из алгоритмов автоматизации проектирования реляционных схем, не имеет преимущества над остальными по всем характеристикам. Из данных методов, только методы Неклюдовой–Цаленко и Дьякова дают количественно оптимальную схему. Принципиальная невозможность построения “абсолютно лучшего” алгоритма следует из существования таких исходных Sch(R), для которых отсутствует синтаксическое разложение в 4НФ с выполнением свойств сохранения зависимостей и соединения без потерь [12, 15].

Следующий метод, применяемый при проектировании реляционных схем, основан на технологии ER-моделирования и носит название метод ER-диаграмм (или проектирование с использованием метода сущность – связь [9]). Метод основывается на методологии представления данных в виде набора сущностей (Entity) и связей (Relationship) (модель ‘сущность-связь’), и в его основу положены определенные правила формирования результирующих отношений, в зависимости от типов связей (ассоциаций) и класса принадлежности сущностей.

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

Однако, как отмечается в [8, 12] данному методу присущи определенные недостатки, самым серьезным из которых является отсутствие гарантии соединения без потерь информации для результирующего набора схем отношений. Т.е. для метода ER-диаграмм всегда необходимо проверять результирующие схемы отношения на свойство соединения без потерь информации.

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

Резюме

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

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

1. Какие цели теории нормализации?

2. Дайте определение функциональной зависимости атрибутов.

3. Чем различаются метод декомпозиции и синтеза?

3. Что такое ER-технология?

4. Какие существуют разновидности нормальных форм?

5. Включает ли реляционная алгебра операции модификации данных?

6. Как описываются структурные ограничения целостности?

7. Что такое свойство сохранения зависимостей?

Схема работы с разделом 5

Раздел 5. Язык структурированных запросов SQL

Пятый раздел курса включает две темы: “ Язык манипулирования данными для реляционной модели ” и “Реализация запросов в языке SQL. После изучения каждой темы Вам следует ответить на вопросы для самопроверки.

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

Работа с разделом 5 завершается сдачей контрольного теста. Кроме того, по данному разделу выполняются практические задания 3 и 4, а также материал используется в лабораторных работах № 2 и № 3.

Для того, чтобы Вы смогли успешно ответить на вопросы контрольного теста, Вам предоставляется возможность поработать с репетиционным тестом. Если Вы испытываете затруднения в ответе на какой-либо вопрос, обратитесь к главам 5-7 учебника [1] или к материалам электронного учебного пособия [7] и пособия [11].

5.1. Язык манипулирования данными для реляционной модели

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

По данной теме выполняется лабораторная работа № 2,3 а также раздел “Разработка схемы модели” курсового проекта. Рекомендации по выполнению этих заданий приведены в методических указаниях [7] и 3.3.

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

Если Вы испытываете затруднения в ответе на какой-либо вопрос, обратитесь к главе 4 учебника [1] или к материалам учебного пособия [7].

5.1.1. Назначение и история языка SQL

Рассмотренная алгебра (основанная на теории множеств) требует от пользователя четкого представления (алгоритма) выполнения операций алгебры, возлагая тем самым на пользователя вопросы эффективности реализации запроса. Указанный недостаток в некоторой мере устранен в реляционном исчислении (в БД его принято называть SQL), который, базирующееся на математической логике (точнее, на исчислении предикатов первого порядка).

Все механизмы манипулирования данными (как в алгебре так и в исчислении) обладают одним важным свойством: они замкнуты относительно понятия отношения. Это означает, что выражения реляционной алгебры и формулы реляционного исчисления определяются над отношениями реляционных БД и результатом вычисления также являются отношения. В результате любое выражение или формула могут интерпретироваться как отношения, что позволяет использовать их в других выражениях или формулах.

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

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

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

Сами по себе данные в компьютерной форме не представляют интерес для пользователя, если отсутствуют средства доступа к ним. Доступ (поиск) осуществляется в виде запросов, которые формулируются на стандартном языке запросов. Сегодня для большинства СУБД таким языком является SQL.

Его появление и развитие как средства описания доступа к базе данных связано с созданием теории реляционных  баз данных. Прообраз языка возник в 1970 году в лаборатории Санта-Тереза  фирмы IBM в рамках научно-исследовательского проекта System/R. Первоначально он назывался SEQUEL(Structured English Query Language), потом SEQUEL/2, а затем просто – SQL. Сегодня - это фактический стандарт интерфейса с современными СУБД. Популярность его настолько велика, что разработчики нереляционных СУБД (например, ADABAS), снабжают свои системы SQL-интерфейсом.

Язык SQL имеет официальный стандарт - ANSI/ISO. Большинство разработчиков придерживаются этого стандарта, однако часто расширяют его для реализации новых возможностей обработки данных.

SQL не является языком программирования в традиционном представлении. На нем пишутся не программы, а запросы к базе данных. Это означает, что с его помощью можно сформулировать, что необходимо получить (сортировка, индексирование базы данных, создание форм, отчетов) из БД. В частности, в отличие от процедурных языков программирования (Си, Паскаль), в языке SQL отсутствуют конструкции цикла, условного переходы и т.д.

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

Неполнота стандарта SQL-89 привела к появлению в 1992 г. следующей версии языка SQL. SQL-92 охватывает практически все необходимые проблемы: манипулирование схемой базы данных, управление транзакциями и сессиями, динамический SQL. Появление новых требований пользователей к СУБД и обрабатываемым данным привели к тому, что в настоящее время используется SQL3. Эта версия языка имеет в своем составе механизм хранимых процедур и триггеров, определение произвольного типа данных, некоторые объектные расширения.

Повторяем, что SQL- это язык запросов, поэтому на нем невозможно написать достаточно сложные прикладные программы, которые работают с базой данных. Для этой цели в современных СУБД используют язык четвертого поколения (4FGL - Forth Generation Language), обладающий как основными возможностями процедурных языков третьего поколения (Си, Паскаль), так и возможностью встроить в текст программы операторы SQL, так и средствами управления интерфейсом пользователя (создание форм и отчетов, меню, вводом пользователя и т.д.).

5.1.2. Операторы языка SQL

Предположим, что мы работаем с базой данных, обладающей схемой СОТРУДНИКИ (СОТР_НОМ, СОТР_ИМЯ, СОТР_ЗАРП, ОТД_НОМ) и ОТДЕЛЫ (ОТД_НОМ, НАЧ_ОТД, ФОНД_ЗАРПЛАТЫ_ОТДЕЛА), и хотим узнать имена и номера сотрудников, являющихся начальниками отделов с фондом зарплаты больше 250.

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

Rrez  = СОТРУДНИКИ [СОТР_НОМ=((ОТДЕЛЫ [ФОНД_ЗАРПЛАТЫ_ОТДЕЛА > 250]) [НАЧ_ОТД]) ] ОТДЕЛЫ [СОТР_ИМЯ, НАЧ_ОТД ]

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

  •  ограничить отношение ОТДЕЛЫ по условию ФОНД_ЗАРПЛАТЫ_ОТДЕЛА > 250;
  •  спроецировать результат предыдущей операции на атрибут ОТД_НАЧ.
  •  выполнить соединение отношений СОТРУДНИКИ и ОТДЕЛЫ по условию СОТР_НОМ = НАЧ_ОТД;
  •  спроецировать результат предыдущей операции на атрибут СОТР_ИМЯ, НАЧ_ОТД.

Мы четко сформулировали последовательность шагов выполнения запроса, каждый из которых соответствует одной реляционной операции. Если же сформулировать тот же запрос с использованием SQL, которому посвящается этот раздел, то мы получили бы формулу (выражение):

SELECT (СОТР_ИМЯ, НАЧ_ОТД)

FROM ОТДЕЛЫ, СОТРУДНИКИ

WHERE СОТР_НОМ = НАЧ_ОТД AND ФОНД_ЗАРПЛАТЫ_ОТДЕЛА > 250;

В этой формулировке мы указали лишь характеристики результирующего отношения, но ничего не сказали о способе его формирования. В этом случае система должна сама решить, какие операции и в каком порядке нужно выполнить над отношениями СОТРУДНИКИ и ОТДЕЛЫ.

Существуют два вида (формы) SQL: ИНТЕРАКТИВНЫЙ и ВСТРОЕННЫЙ. Конструкции этих форм работают одинаково, но используются различно. Интерактивный SQL используется для функционирования непосредственно в БД, чтобы производить вывод на экран дисплея или принтер информацию из БД для использования ее пользователем. В этой форме SQL, когда Вы введете команду, она сейчас же выполнится, и можно увидеть вывод - немедленно.

Встроенный (вложенный) SQL состоит из команд SQL, помещенных внутри другой программной среды. То есть, интерфейс обеспечивает среда другого языка, а SQL выполняет запросы, поступающие из программы. В чистом виде это реализовано, например, в среде Delphi, PHP, а FoxPro даже включает операторы SQL в автономный (базовый) язык.

Это делает эти программы более мощными и эффективными. Однако, допуская эти возможности, приходится иметь дело со структурой SQL и стилем управления данных, который требует некоторых расширений к интерактивному стандарту SQL.

Независимо от вида SQL (согласно рекомендации ANSI), SQL состоит из следующих разделов:

-Язык Определения Данных (ЯОД или DDL),

-Язык Манипулирования Данными (ЯМД или DML),

-Язык Управления Данными (DCL).

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

Data Definition Language (DDL).

Эта составляющая языка содержит операторы, позволяющие создавать,  модифицировать и уничтожать базы данных и объекты внутри них (таблицы, представления) (см. таблицу 5.1).

Операторы DDL.       Таблица 5.1.

Оператор

Описание

CREATE  TABLE

Добавление новой таблицы к базе данных

DROP TABLE

Удаление таблицы из базы данных

ALTER TABLE

Изменение структуры имеющейся таблицы

CREATE  VIEW

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

DROP VIEW

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

CREATE INDEX

Создание нового индекса

DROP INDEX

Удаление существующего индекса

Data Manipulation Language (DML).

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

Операторы DML.      Таблица 5.2.

Оператор

Описание

SELECT

Выбор данных

INSERT

Вставка данных

DELETE

Удаление данных

UPDATE

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

Иногда оператор SELECT относят к отдельной категории Data Query Language (DQL).

Transaction Control Language (TCL).

Операторы данного класса (см. табл. 5.3) применяются для управления изменениями, выполняемыми группой операторов DML.

Операторы TCL.       Таблица 5.3 .

Оператор

Описание

COMMIT

Завершение транзакции и сохранение изменений в базе данных

ROLLBACK

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

SET TRANSACTION

Установка параметров доступа к данным в текущей транзакции

Data Control Language (DCL).

Операторы Data Control Language (см. табл. 5.4), иногда называемые операторами Access Control Language, применяются для осуществления административных функций, присваивающих или отменяющих право (привилегию) использовать базу данных, таблицу базы данных, а также выполнять те или иные операторы SQL.

Операторы DCL.       Таблица 5.4.

Оператор

Описание

GRANT

Присвоение привилегии

REVOKE

Отмена привилегии

Все операторы SQL имеют вид, представленный на рис.5.1.

 

 

Рис.5.1 Структура оператора SQL

5.1.3. Модификация хранимых отношений в СУБД

Оператор UPDATE

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

UPDATE таблица

SET столбец1= выражение1 [, столцец2= выражение2] […]

[WHERE условие]

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

UPDATE Счет

SET баланс=баланс+1000.00

WHERE баланс>0

Оператор DELETE

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

 DELETE

FROM таблица

[WHERE условие]

Предложение WHERE не является обязательным, однако, если его не включить, то будут удалены все записи таблицы. Полезно использовать оператор SELECT c тем же синтаксисом, что и оператор DELETE, чтобы предварительно проверить, какие записи будут удалены.

Оператор INSERT

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

INSERT INTO

([список столбцов]

{VALUES ({DEFAULT|NULL|выражение}

} [,..]

)

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

1. Для каких целей создавался язык SQL?

2. Какие основные отличия реляционной алгебры и исчисления отношений?

3. Что такое интерактивный и вложенный SQL?

4. Каковы основные этапы формирования стандарта SQL?

5. Является ли SQL языком программирования?

6. Какие особенности присущи языку 4GL?

7. Как можно ускорить выполнение операции в SQL?

8. Почему SQL считается реляционно-полным?

9. Из каких разделов состаит язык SQL?

5.2. Реализация запросов в языке SQL

При изучении данной темы Вы должны познакомиться с организацией процесса выполнения операторов SQL в СУБД и особенностями их реализации в конкретной (по выбору) СУБД.

По данной теме выполняется лабораторная работа №3, а также раздел “Разработка внешней модели” курсового проекта. Рекомендации по выполнению этих заданий приведены в методических указаниях [7] и [9], а также в методических указаниях к лабораторным занятиям в разделе 3.3.

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

Если Вы испытываете затруднения в ответе на какой-либо вопрос, обратитесь к главам 8 и 10 учебника [1] или к материалам учебного пособия [7].

5.2.1. Примеры запросов

Определение таблиц – это разовая работа, изменение структуры – эпизодическая, а манипулирование данными – деятельность постоянная. И если изменение содержания базы данных большой сложности не представляет, то выборка необходимой информации может быть довольно замысловатой. Именно на запросы расходуется наибольшее время работы с БД. Поэтому основу языка SQL составляют запросы к базе данных. Запросы определяются командой Select. (см. приложение 1).

5.2.2. Агрегатные функции

Функции агрегирования возвращают единственное (скалярное) значение для группы кортежей. Всего различают пять таких функций:

  •  COUNT – количество непустых строк или значений атрибутов, отличных от null, удовлетворяющих заданному условию;
  •  SUMсумма значений атрибута;
  •  AVG – среднее значение атрибута;
  •  MAX – максимальное значение атрибута;
  •  MIN – минимальное значение атрибута.

В команде Select они используются в списке выбираемых полей наряду с именами атрибутов. Их аргументы – имена атрибутов, причем, для SUM и AVG допустимы аргументы только числового типа.

Рассмотрим подробнее функцию COUNT. Она подсчитывает количество всех непустых атрибутов, даже если их значение повторяется. Для исключения повторений используется опция Distinct. Вариант COUNT(*) подсчитывает количество строк в выборке, включая и пустые, и повторяющиеся. Применять Distinct здесь нельзя. Вариант All позволяет считать все непустые значения атрибута, включая повторяющиеся.

Агрегатные функции применимы не только к атрибутам, но и к выражениям, содержащим атрибуты. В этом случае опция Distinct запрещена.

Пример

Подсчитать количество продавцов, которые выполняли заказы:

Select COUNT(Distinct ном_прод) From Заказы;

Подсчитать количество продавцов:

Select COUNT(*) From Продавцы;

Подсчитать количество непустых сумм:

Select COUNT(All сумма) From Заказы;

Подсчитать общую сумму заказов в тысячах рублей:

Select SUM(сумма/1000) From Заказы;

5.2.3. Хранимые запросы

Триггеры и хранимые процедуры и представления являются неотъемлемой частью серверных СУБД.

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

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

Преимущества представлений:

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

обеспечение безопасности данных (возвращение пользователям данных в зависимости от категории (имени) пользователя);

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

Хранимые процедуры

Хранимые процедуры – скомпилированный набор SQL предложений, сохраненный в базе данных как именованный объект и выполняющийся как единый фрагмент программного кода. Отдельные процедуры могут иметь параметры и возвращать значения. Созданная пользователем процедура компилируется сервером, а затем откомпилированный программный код может быть использован любым пользователем (рис. 5.1).

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

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

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

Кроме процедур, используемых в клиентских приложениях, СУБД имеет системные хранимые процедуры; они могут использоваться для выполнения следующих задач:

вывод и изменения глобальных конфигураций сервера;

получение сведений о поддерживаемых типах данных;

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

вывод статистики СУБД;

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

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

Триггеры

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

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

Рис. 5.2. Автоматический вызов триггера

Триггер всегда выполняет некоторое действие и никогда не возвращает пользователю данные.

Области применения триггеров и хранимых процедур

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

содержать логику обработку (в некоторой степени) в самой БД, управляемой СУБД, а не прикладным программными приложениями;

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

включить в состав БД инструменты, при помощи которых события и условия обеспечивали бы запуск логики внутри самой БД (рис. 5.3). В создании активных сред помогают несколько основных конструкций баз данных: триггеры, ограничения и хранимые процедуры.

Рис. 5.3. Активная система баз данных

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

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

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

1. Каковы основные функции оператора SELECT?

2. Какие варианты реализации DML существуют?

3. Что такое агрегатные функции?

4. Каковы основные этапы выполнения команды SELECT?

5. Чем различается выполнение команд Insert, Delete, Update?

6. Зачем нужны триггеры и хранимые процедуры?

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

8. К чему приводит выполнение команды COMMIT?

9. Для чего служат активные БД?

10. Приведите примеры необходимости использования опции Distinct.

11. Назовите достоинства и недостатки SQL.

Резюме

В современных СУБД обычно поддерживается единый интегрированный язык, содержащий все необходимые средства для работы с базой данных, начиная от ее создания и обеспечивающий базовый пользовательский интерфейс с базами данных. Наиболее популярным для реляционных СУБД является язык SQL, разработанный фирмой IBM и реализованный впервые в реляционной СУБД System R, а впоследствии и в коммерческой системе DB2. Другим примером языков этого класса могут служить: язык Quel системы Ingres, созданный Калифорнийским университетом, языковые средства большинства СУБД для персональных ЭВМ, например, язык  dBase семейства СУБД фирмы  Asthon - Tate и многочисленных совместимых с ним систем.

Некоторые СУБД располагают такими языками, которые не только реализуют функции определения и манипулирования данными, но и обладают управляющими структурами и другими средствами, свойственными традиционным языкам программирования. Такие языки называют автономными. В качестве примера приведем ранее упоминавшийся язык dBase, http://www.hotsoft.ru/ADS/  адаптированный к стилю клиент-серверной технологии.

Схема работы с разделом 6

Раздел 6. Использование БД

Шестой раздел курса включает три темы: “ Программирование и управление транзакциями, “Защита баз данных. Целостность и сохранность баз данных,Современные тенденции построения баз данных. После изучения каждой темы Вам следует ответить на вопросы для самопроверки.

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

Работа с разделом 6 завершается сдачей контрольного теста.

Для того, чтобы Вы смогли успешно ответить на вопросы контрольного теста, Вам предоставляется возможность поработать с репетиционным тестом. Если Вы испытываете затруднения в ответе на какой-либо вопрос, обратитесь к учебнику [1].

6.1. Программирование и управление транзакциями

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

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

Если Вы испытываете затруднения в ответе на какой-либо вопрос, обратитесь к главе 15 учебника [1] или к материалам учебного пособия [11].

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

Понятие транзакции

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

Транзакция представляет собой последовательность операторов языка манипулирования данными (например, SQL), которая рассматривается как некоторое логически неделимое действие над базой данных, осмысленное с точки зрения пользователя. Она может быть представлена отдельной программой, являться частью алгоритма программы или даже отдельной командой (например, командой insert или update) и включать произвольное количество операций, выполняемых в базе данных.

Например, если имеется таблица данных следующего вида: «Сотрудник (Номер, фамилия, телефон, должность, зарплата)», то простейшей транзакцией может быть модификация зарплаты определенного работника.

Транзакция характеризуется четырьмя свойствами: атомарности (Atomicity), согласованности (Consistency), изолированности (Isolation) и долговечности (устойчивости) (Durability) - ACID. Эти свойства означают следующее:

свойство атомарности выражается в том, что транзакция должна быть выполнена в целом или не выполнена вообще;

свойство согласованности предполагает, что транзакция должна переводить данные из одного согласованного состояния в другое – на практике ответственность возлагается на разработчиков приложений;

свойство изолированности означает, что конкурирующие за доступ к базе данных транзакции физически обрабатываются последовательно, изолированно друг от друга, но для пользователей это выглядит так, как будто они выполняются параллельно; промежуточные результаты незавершенной транзакции не должны быть доступны другим транзакциям;

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

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

Возможны два варианта завершения работы транзакции. Если все операторы выполнены успешно и в процессе выполнения транзакции не произошло никаких сбоев программного или аппаратного обеспечения, транзакция фиксируется. Фиксация транзакции (COMMIT TRANSACTION)- это действие, обеспечивающее запись на диск изменений в базе данных, которые были сделаны в ходе выполнения транзакции. До тех пор, пока транзакция не зафиксирована, возможно произвести отмену всех изменений и восстановить базу данных в исходное, на момент начала транзакции, состояние. Фиксация означает, что все результаты выполнения транзакции становятся постоянными и доступными другим пользователям системы. Надо отметить, что до момента фиксации транзакции пользователи имеют дело с данными, в том виде, в котором они находились на момент начала выполнения текущей транзакции.

Если же в процессе работы случилось нечто, что делает выполнение транзакции невозможным, база данных возвращается в исходное состояние. Откат транзакции (ROLLBACK TRANSACTION)- это действие, обеспечивающее аннулирование всех изменений данных, которые были сделаны операторами запроса (SQL) в теле текущей незавершенной транзакции.

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

В стандарте ANSI/ISO SQL транзакция связана с операторами COMMIT и ROLLBACK. Стандарт определяет, что транзакция начинается с первого SQL-оператора, инициируемого пользователем в программе, т.е. c команды BEGIN TRANSACTION. Все последующие операторы составляют тело транзакции. Транзакция завершается одним из четырех возможных вариантов (рис. 6.1):

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

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