Белорусский государственный университет информатики и радиоэлектроники Кафедра программного обе

Работа добавлена на сайт samzan.net:

PAGE 82

Учреждение образования «Белорусский государственный университет информатики и радиоэлектроники»

Кафедра программного обеспечения информационных технологий

Куликов Святослав Святославович

доцент кафедры ПОИТ

Электронный учебно-методический комплекс по дисциплине

«Базы данных»

(часть 1)

Для студентов специальности

40 01 01 - Программное обеспечение информационных технологий

(дистанционная форма обучения)

Минск 2011

ОБЩИЕ СВЕДЕНИЯ

Сведения об ЭУМК

ЭУМКД по дисциплине «Базы данных» для студентов специальностей: 40 01 01 - Программное обеспечение информационных технологий (дистанционная форма обучения) предназначен для изучения студентами ФНиДО дисциплины «Базы данных» (в т.ч.: изучения теоретической части и выполнения практических работ).

ЭУМКД по дисциплине «Базы данных» для студентов специальностей: 40 01 01 - Программное обеспечение информационных технологий (дистанционная форма обучения) разработан в соответствии с учебным планом и рабочей программой дисциплины «Базы данных» специальности 40 01 01 - Программное обеспечение информационных технологий.

Автор ЭУМКД: доцент кафедры ПОИТ, к.т.н., доцент, Куликов С.С.

В практических материалах курса использованы материалы, предоставленные ассистентом кафедры ПОИТ Фадеевой Е.Е.

ЭУМКД рекомендован к изданию на заседании кафедры ПОИТ (протокол № 17 от 07.02.2011) и заседании методической комиссии ФКСиС (протокол № 10 от 08.02.2011).

Методические рекомендации по изучению дисциплины

Целью изучения курса

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

В результате изучения курса студент должен знать:

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

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

• способы нормализации отношений;

• принципы работы транзакций;

• принципы построения компиляторов SQL;

• основы функционирования распределенных, объектно-ориентированных СУБД.

Овладев курсом, студент должен уметь:

• реализовывать запросы к СУБД с использованием стандартного языка запросов SQL и прикладных систем разработки ПО;

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

• создавать модели базы данных с использованием современных CASE-средств (например, Power Designer, Rational Rose, Erwin);

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

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

Рабочая учебная программа

Учреждение образования

«Белорусский государственный университет

информатики и радиоэлектроники»

БАЗЫ ДАННЫХ

Рабочая учебная программа

для специальности

1-40 01 01 Программное обеспечение информационных технологий

Факультет непрерывного и дистанционного обучения

Кафедра программного обеспечения информационных технологий

Составил доцент каф. ПОИТ, Куликов С.С.

Рабочая учебная программа составлена на основе типовой учебной программы "Базы данных", утвержденной Министерством образования Республики Беларусь 24.09.2009, регистрационный № ТД-1.079/тип и учебного плана специальности 1-40 01 01 Программное обеспечение информационных технологий.

Рассмотрена и рекомендована к утверждению на заседании кафедры программного обеспечения информационных технологий (протокол № 29 от 08.06.2009).

Одобрена и рекомендована к утверждению Советом факультета компьютерных систем и сетей Учреждения образования «Белорусский государственный университет информатики и радиоэлектроники» (ротокол № 16 от 22.06.2009)

ПОЯСНИТЕЛЬНАЯ ЗАПИСКА

Цель преподавания дисциплины.

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

Задачи изучения дисциплины.

В результате изучения дисциплины обучаемый должен:

знать:

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

уметь:

реализовывать запросы к СУБД с использованием стандартного языка запросов SQL и прикладных систем разработки ПО;
владеть алгоритмами хеширования, сжатия и поиска данных;
создавать модели базы данных с использованием современных CASE-средств (например, Power Designer, Rational Rose, Erwin);
создавать клиентские приложения, генерировать отчеты.

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

№ пп	Название дисциплины	Раздел, тема
1.	Основы алгоритмизации и программирования	Теория алгоритмизации
2.	Организация и функционирование ЭВМ	Формы представления логических функций
3.	Конструирование программ и языки программирования	Язык программирования C

СОДЕРЖАНИЕ ДИСЦИПЛИНЫ

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

№ пп	Название темы	Содержание	Объем в часах
1	2	3	4
1.	Введение в базы данных, содержание и цели курса, основные понятия.	Вводная лекция. Знакомство с курсом. Основные цели и задачи курса.	4
2.	История развития представлений о БД.	Начальные этапы развития представлений о БД. Формирование основных подходов к построению БД. Возникновение теории реляционных БД.	4
3.	Основные термины и определения теории БД. Виды БД и их отличия.	База данных как информационная модель. Модели данных, выбор модели данных. Язык SQL. Диалекты языка SQL. Существующие виды БД, их отличия, преимущества и недостатки.	4
4.	Реляционные БД. Понятие «сущности» и «связи».	Понятия «сущность», «связь», «индекс», «ключ». Целостность данных. Нормализация данных. Виды нормальных форм. Стандартные приёмы использования связей вида «один ко многим» и «многие ко многим». Хранение иерархических структур (деревьев) в реляционной БД.	4
5.	Многоуровневая архитектура БД. Понятие физического и логического уровней БД.	Особенности организации логического и физического уровня БД, назначение уровней. Преимущества многоуровневой архитектуры. Типы данных, понятие «домена».	4
6.	Механизмы обработки и хранения данных в БД.	Обеспечение целостности и непротиворечивости данных, решение ситуаций конкуренции за данные, стратегии хранения данных.	4
7.	Стандарты разработки БД.	Стандарты языка SQL. Методологии проектирования БД. Зарубежные и отечественные стандарты в области разработки, внедрения и сопровождения БД.	4
8.	Средства автоматизированного проектирования БД.	Обзор существующих средств автоматизированного проектирования БД. Современные версии ПО для автоматизированного проектирования БД. Возможности средств автоматизированного проектирования БД для взаимодействия с СУБД и решения стандартных задач.	8
9.	Особенности проектирования БД на логическом и физическом уровне.	Логический и физический уровни БД, отличия на стадии проектирования. Автоматическое построение физического уровня БД при формировании логического уровня. Выбор типов данных при проектировании физического уровня БД.	8
10.	Прямое и обратное проектирование БД.	Прямое и обратное проектирование БД. Синхронизация модели БД и существующей БД. Построение модели БД по существующей БД. Модернизация БД в процессе эксплуатации.	8
11.	Повышение качества БД на стадии проектирования.	Повышение надёжности, безопасности и быстродействия БД на стадии проектирования. Требования к качеству БД в зависимости от области применения БД.	4
12.	Обзор существующих СУБД.	Обзор современных версий СУБД ведущих производителей данного класса ПО. Классификация СУБД. Возможности современных СУБД.	8
13.	СУБД начального уровня.	Назначение и возможности СУБД начального уровня. Обзор современных версий СУБД MySQL, PostgreSQL, MS-Access.	8
14.	СУБД корпоративного уровня.	Назначение и возможности СУБД корпоративного уровня. Обзор современных версий СУБД Oracle, MS-SQL, DB2.	8
15.	Способы взаимодействия ПС с СУБД.	Организация взаимодействия ПС с СУБД под управлением ОС семейства Windows и Unix. Организация удалённого взаимодействия с СУБД. Понятие тонкого и толстого клиента, использование хранимых процедур.	4
16.	Современные тенденции развития СУБД.	Современные тенденции развития СУБД. Решение проблемы репликации данных. Распределённые СУБД. Хранилища данных.	8
17.	Настройка и администрирование СУБД.	Настройка и администрирование СУБД MySQL под управлением ОС семейства Windows и Unix. Особенности использования СУБД MySQL при создании веб-ориентированных приложений. Настройка и администрирование СУБД Oracle под управлением ОС семейства Windows и Unix.	8
18.	Повышение надёжности БД.	Обеспечение целостности и непротиворечивости данных на стадии эксплуатации СУБД. Резервное копирование данных. Зеркалирование данных.	4
19.	Повышение производительности БД.	Оптимизация БД по быстродействию: способы и алгоритмы. Реконструкция модели БД как способ повышения производительности. Оптимальный выбор типов данных как способ повышения производительности.	4
20.	Повышение безопасности БД.	Разграничение прав доступа на уровне администрирования СУБД. Шифрование данных средствами СУБД как средство повышения защищённости данных. Защищённые протоколы взаимодействия ПС с СУБД.	4
21.	Модернизация БД в процессе эксплуатации.	Эволюционное и революционное развитие БД. Модернизация БД без вывода БД из эксплуатации. Слияние БД. Преобразование БД в хранилище данных.	4
Итого	114

2 ПЕРЕЧЕНЬ ТЕМ ИПР

ИХ НАИМЕНОВАНИЕ И ОБЪЕМ В ЧАСАХ

№ пп	Название темы	Содержание	Объем в часах
1	2	3	4
1.	Методы физической организации данных.	Методы упорядоченного размещения и сортировки.	8
2.	Виртуальный метод доступа VSAM.	Организация виртуального физического метода доступа VSAM.	8
Итого	16

3 ПЕРЕЧЕНЬ ТЕМ КОНТРОЛЬНЫХ РАБОТ

ИХ НАИМЕНОВАНИЕ И ОБЪЕМ В ЧАСАХ

№ пп	Название темы	Содержание	Объем в часах
1	2	3	4
1.	Хеширование.	Хеширование как метод физической организации данных.	12
2.	Поиск по ключам.	Организация эффективного хранения и поиска данных.	12
Итого	24

4. КУРСОВАЯ РАБОТА, ЕЕ ХАРАКТЕРИСТИКА

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

ПЕРЕЧЕНЬ ТЕМ КУРСОВЫХ РАБОТ

БД электронной библиотеки.
БД электронного каталога товаров.
БД информационного интернет-ресурса.
БД бухгалтерского ПС.
БД учреждения образования.
БД учреждения здравоохранения.
БД коммерческой фирмы.
БД ПС обмена сообщениями.
Библиотека функций для взаимодействия с БД на языке высокого уровня.
Библиотека функций для организации репликации с БД.
ПС администрирования БД.
Библиотека функций для автоматического импорта данных в БД на основе языка разметки XML.
Библиотека функций для автоматического импорта данных в БД на основе языка разметки CSV.
Библиотека функций для автоматического импорта данных в БД на основе языка разметки RSS.
ПС тестирования производительности БД.
ПС нагрузочного тестирования БД.
ПС стрессового тестирования БД.
ПС тестирования устойчивости БД к входным данным.
ПС конвертации формата БД.

5. ЛИТЕРАТУРА

5.1 Основная

5.1.1. Дунаев В.Ф. Базы данных. Язык SQL для студента. BHV-CПб, 2006.

Кузнецов М.А., Симдянов И.В. MySQL 5. BHV-CПб, 2006.

5.1.2. Мотев А.А. Уроки MySQL. BHV-CПб, 2006.

Ли Д., Уэр Б. Использование Linux, Apache, MySQL и PHP для разработки Web-приложений. Диалектика, 2004.

5.1.3. Купцевич Ю.Е. Альманах программиста. Том 1. Microsoft ADO.NET, Microsoft SQL Server. Доступ к данным из приложений. Русская редакция, 2006.

5.1.4. Дибетта П. Знакомство с Microsoft SQL Server 2005. Русская редакция, 2006.

5.1.5. Станек У.Р. Microsoft SQL Server 2005. Справочник администратора. Русская редакция, 2006.

5.1.6. Гешвинде Э., Шениг Г.-Ю. PostgreSQL. ДиаСофт, 2005.

5.2 Дополнительная

5.2.1. МакДональд К. Oracle PL/SQL для профессионалов: практические решения. Диасофт-ЮП, 2005.

5.2.2. Васвани В. Полный справочник по MySQL. Вильямс, 2006.

5.2.3. Михеев Р.Н. MS SQL Server 2005 для администраторов. BHV-CПб, 2006.

5.2.4. Пирогов В.Ю. SQL Server 2005: программирование клиент-серверных приложений. BHV-CПб, 2006.

6. ПЕРЕЧЕНЬ КОМПЬЮТЕРНЫХ ПРОГРАММ, НАГЛЯДНЫХ И ДРУГИХ ПОСОБИЙ, МЕТОДИЧЕСКИХ УКАЗАНИЙ И МАТЕРИАЛОВ И ТЕХНИЧЕСКИХ СРЕДСТВ ОБУЧЕНИЯ

6.1. Необходимые для работы с СУБД операционные системы: MS-Windows XP, MS-Windows Vista, Fedora Core, Mandriva, FreeBSD.

6.2. Необходимые для изучения курса СУБД: MySQL, PostgreSQL, Oracle, DB2, Informix, MS-Access.

6.3. Необходимые для изучения курса среды разработки на языках программирования: C++, C#, ASP.NET, Java, PHP.

6.4. Необходимые для выполнения лабораторных и курсовых проектов веб-серверы: Apache, IIS.

6.5. Оборудование: IBM-совместимые компьютеры, производительность которых позволит выполняться программному обеспечению, перечисленному в пунктах 6.1-6.4.

7. Учебно-методическая карта дисциплины

Номер недели	Номер темы	Название вопросов, которые изучаются на лекциях	Практические (семинарские) занятия	Лабораторные занятия	Литература (номера)	Наглядные и методические пособия (номера)	Самостоятельная работа студентов (часы)	Форма контроля знаний студентов

1	2	3	4	5	6	7	8	9
1	1	Вводная лекция. Знакомство с курсом. Основные цели и задачи курса.	-	-	5.1.1-5.1.6, 5.2.1-5.2.4	6.1-6.5	8	Текущий опрос
2	2	Начальные этапы развития представлений о БД.	-	1	5.1.1-5.1.6, 5.2.1-5.2.4	6.1-6.5	8	ИПР 1, текущий опрос
3	2	Формирование основных подходов к построению БД.	-	1	5.1.1-5.1.6, 5.2.1-5.2.4	6.1-6.5	8	ИПР 1, текущий опрос
4	2	Возникновение теории реляционных БД.	-	1	5.1.1-5.1.6, 5.2.1-5.2.4	6.1-6.5	8	ИПР 1, текущий опрос
5	3	База данных как информационная модель. Модели данных, выбор модели данных.	-	1	5.1.1-5.1.6, 5.2.1-5.2.4	6.1-6.5	8	ИПР 1, текущий опрос
6	3	Язык SQL. Диалекты языка SQL. Существующие виды БД, их отличия, преимущества и недостатки.	-	2	5.1.1-5.1.6, 5.2.1-5.2.4	6.1-6.5	8	ИПР 1, текущий опрос
7	4	Понятия «сущность», «связь», «индекс», «ключ». Целостность данных. Нормализация данных. Виды нормальных форм.	-	2	5.1.1-5.1.6, 5.2.1-5.2.4	6.1-6.5	8	ИПР 1, текущий опрос
8	4	Стандартные приёмы использования связей вида «один ко многим» и «многие ко многим». Хранение иерархических структур (деревьев) в реляционной БД.	-	2	5.1.1-5.1.6, 5.2.1-5.2.4	6.1-6.5	8	ИПР 1, текущий опрос
9	5	Особенности организации логического и физического уровня БД, назначение уровней. Преимущества многоуровневой архитектуры. Типы данных, понятие «домена».	-	2	5.1.1-5.1.6, 5.2.1-5.2.4	6.1-6.5	8	ИПР 1, текущий опрос
10	6	Обеспечение целостности и непротиворечивости данных, решение ситуаций конкуренции за данные, стратегии хранения данных.	-	3	5.1.1-5.1.6, 5.2.1-5.2.4	6.1-6.5	8	ИПР 1, текущий опрос
11	7	Стандарты языка SQL. Методологии проектирования БД. Зарубежные и отечественные стандарты в области разработки, внедрения и сопровождения БД.	-	3	5.1.1-5.1.6, 5.2.1-5.2.4	6.1-6.5	8	ИПР 1, текущий опрос
12	8	Обзор существующих средств автоматизированного проектирования БД. Современные версии ПО для автоматизированного проектирования БД.	-	3	5.1.1-5.1.6, 5.2.1-5.2.4	6.1-6.5	8	ИПР 1, текущий опрос
13	8	Возможности средств автоматизированного проектирования БД для взаимодействия с СУБД и решения стандартных задач.	-	3	5.1.1-5.1.6, 5.2.1-5.2.4	6.1-6.5	8	ИПР 1, текущий опрос
14	9	Логический и физический уровни БД, отличия на стадии проектирования. Автоматическое построение физического уровня БД при формировании логического уровня.	-	4	5.1.1-5.1.6, 5.2.1-5.2.4	6.1-6.5	6	ИПР 1, текущий опрос
15	9	Выбор типов данных при проектировании физического уровня БД.	-	4	5.1.1-5.1.6, 5.2.1-5.2.4	6.1-6.5	6	ИПР 1, текущий опрос
16	10	Прямое и обратное проектирование БД. Синхронизация модели БД и существующей БД	-	4	5.1.1-5.1.6, 5.2.1-5.2.4	6.1-6.5	8	ИПР 1, текущий опрос
17	10	Построение модели БД по существующей БД. Модернизация БД в процессе эксплуатации.	-	4	5.1.1-5.1.6, 5.2.1-5.2.4	6.1-6.5	8	ИПР 1, текущий опрос
18	11	Повышение надёжности, безопасности и быстродействия БД на стадии проектирования.	-	4	5.1.1-5.1.6, 5.2.1-5.2.4	6.1-6.5	8	ИПР 1, текущий опрос
19	11	Требования к качеству БД в зависимости от области применения БД.	-	4	5.1.1-5.1.6, 5.2.1-5.2.4	6.1-6.5	8	ИПР 1, текущий опрос
20	12	Обзор современных версий СУБД ведущих производителей данного класса ПО.	1	5	5.1.1-5.1.6, 5.2.1-5.2.4	6.1-6.5	8	ИПР 2, текущий опрос
21	12	Классификация СУБД. Возможности современных СУБД.	1	5	5.1.1-5.1.6, 5.2.1-5.2.4	6.1-6.5	8	ИПР 2, текущий опрос
22	13	Назначение и возможности СУБД начального уровня. Обзор современных версий СУБД MySQL, PostgreSQL, MS-Access.	2	5	5.1.1-5.1.6, 5.2.1-5.2.4	6.1-6.5	8	ИПР 2, текущий опрос
23	14	Назначение и возможности СУБД корпоративного уровня. Обзор современных версий СУБД Oracle, MS-SQL, DB2.	2	6	5.1.1-5.1.6, 5.2.1-5.2.4	6.1-6.5	8	ИПР 2, текущий опрос
24	15	Организация взаимодействия ПС с СУБД под управлением ОС семейства Windows и Unix.	3	6	5.1.1-5.1.6, 5.2.1-5.2.4	6.1-6.5	8	ИПР 2, текущий опрос
25	15	Организация удалённого взаимодействия с СУБД. Понятие тонкого и толстого клиента, использование хранимых процедур.	3	6	5.1.1-5.1.6, 5.2.1-5.2.4	6.1-6.5	8	ИПР 2, текущий опрос
26	16	Современные тенденции развития СУБД. Решение проблемы репликации данных.	4	6	5.1.1-5.1.6, 5.2.1-5.2.4	6.1-6.5	8	ИПР 2, текущий опрос
27	16	Распределённые СУБД. Хранилища данных.	5	7	5.1.1-5.1.6, 5.2.1-5.2.4	6.1-6.5	8	ИПР 2, текущий опрос
28	17	Настройка и администрирование СУБД MySQL под управлением ОС семейства Windows и Unix. Особенности использования СУБД MySQL при создании веб-ориентированных приложений. Настройка и администрирование СУБД Oracle под управлением ОС семейства Windows и Unix.	5	7	5.1.1-5.1.6, 5.2.1-5.2.4	6.1-6.5	8	ИПР 2, текущий опрос
29	18	Обеспечение целостности и непротиворечивости данных на стадии эксплуатации СУБД. Резервное копирование данных. Зеркалирование данных.	6	7	5.1.1-5.1.6, 5.2.1-5.2.4	6.1-6.5	8	ИПР 2, текущий опрос
30	19	Оптимизация БД по быстродействию: способы и алгоритмы. Реконструкция модели БД как способ повышения производительности. Оптимальный выбор типов данных как способ повышения производительности.	6	8	5.1.1-5.1.6, 5.2.1-5.2.4	6.1-6.5	8	ИПР 2, текущий опрос
31	20	Разграничение прав доступа на уровне администрирования СУБД. Шифрование данных средствами СУБД как средство повышения защищённости данных. Защищённые протоколы взаимодействия ПС с СУБД.	7	8	5.1.1-5.1.6, 5.2.1-5.2.4	6.1-6.5	8	ИПР 2, текущий опрос
32	21	Эволюционное и революционное развитие БД. Модернизация БД без вывода БД из эксплуатации. Слияние БД. Преобразование БД в хранилище данных.	8	8	5.1.1-5.1.6, 5.2.1-5.2.4	6.1-6.5	8	ИПР 2, текущий опрос
								Экзамен

ТЕОРЕТИЧЕСКИЙ РАЗДЕЛ

1. Введение в курс

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

1.1.1. О чём этот курс

Курс состоит из двух частей.

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

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

1.1.2. Основные определения

«База Данных (БД, database)» – структурированный организованный набор данных, описывающих характеристики какой-либо физической или виртуальной системы.

«Базой данных» часто упрощённо или ошибочно называют Системы Управления Базами Данных (СУБД, database management system, DBMS).

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

Несмотря на то, что подавляющее количество времени мы будем говорить о БД, следует упомянуть о ещё одной базе – безе знаний.

База знаний, БЗ (knowledge base, KB) – специфический набор программных средств, разработанный для управления знаниями (метаданными), то есть сбором, хранением, поиском и выдачей знаний.

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

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

Основное отличие БЗ от БД строится на отличии данных от знаний.

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

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

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

Т.о. мы получаем два очевидных факта:

БЗ может строиться на основе БД, но БЗ – более широкое и сложное понятие, нежели просто БД.
На основе БЗ может быть построена экспертная система.

Экспертная система (ЭС, expert system) – программное обеспечение, способное заменить специалиста-эксперта в разрешении проблемной ситуации.

ЭС начали разрабатываться исследователями искусственного интеллекта в 1970-х годах, а в 1980-х получили коммерческую поддержку.

Предельно упрощённый аналог ЭС каждый из вас видел в своей жизни – это всевозможные «мастера» (wizards), применяемые для установки и настройки того или иного ПО, а также для выполнения тех или иных действий.

Главное отличие «мастеров» от «нормальной ЭС» – отсутствие базы знаний; все действия жёстко запрограммированы.

Настоящая же ЭС способна по тем или иным входным данным выдать ответ на поставленный вопрос так или почти так, как это сделал бы эксперт, обладающий всеми теми же знаниями, которые хранятся в БЗ этой ЭС.

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

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

БЗ всемирного масштаба – например, Интернет;
БЗ национального масштаба – например, национальные разделы Википедии;
БЗ отраслевые – например, автомобильная или медицинская энциклопедия;
БЗ отдельных организаций;
БЗ экспертных систем.

1.1.3. Способы организации знаний в базах знаний

Как можно организовывать знания в БЗ?

С использованием:

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

Сейчас мы рассмотрим эти способы…

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

Знания отображаются совокупностью таких формул, а получение новых знаний сводится к реализации процедур логического вывода. В основе логических моделей представления знаний лежит понятие формальной теории, задаваемое кортежем: S = <B, F, A, R>, где:

B – множество базовых символов (алфавит);

F – множество формул;

A – выделенное подмножество априори истинных формул (аксиом);

R – множество отношений между формулами, называемое правилами вывода.

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

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

Продукционная модель знаний – модель, основанная на правилах, позволяющих представить знание в виде предложений типа «Если (условие), то (действие)».

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

Продукционная модель обладает тем недостатком, что при накоплении достаточно большого числа (порядка нескольких сотен) продукций они начинают противоречить друг другу. В общем случае продукционную модель можно представить в следующем виде: I = <S;L;A à B;Q> , где:

S – описание класса ситуаций;

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

A à B – ядро продукции;

Q – постусловие продукционного правила.

Фрейм – абстрактный образ для представления некоего вида информации.

Различают фреймы-образцы, фреймы-экземпляры, фреймы-структуры, фреймы-роли, фреймы-сценарии, фреймы-ситуации.

Система связанных фреймов может образовывать семантическую сеть.

Структура фрейма, если сказать предельно упрощённо, такова: он состоит из слотов и имени.

Слоты содержат конкретные знания об атрибутах фрейма. Имя выражает смысл самого фрейма как целого.

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

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

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

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

Рассмотрим на рисунке…

Рисунок 1.1.3.1 – Семантическая сеть

1.1.4. Применение баз знаний

Итак, возвращаемся к базам знаний.

Применение баз знаний

Хранение данных об организации: документации, руководств, статей технического обеспечения. Главная цель создания таких баз – помочь менее опытным людям найти существующее описание способа решения какой-либо проблемы предметной области.
Машинное обучение. БЗ модифицируется в процессе работы интеллектуальной системы, адаптируясь к проблемной области аналогично человеческой способности «набирать опыт».
Автоматическое доказательство. Система выводит новые знания из старых, находит закономерности в БЗ.
Интроспекция, т.е. нахождение противоречий, нестыковок в БЗ, слежение за правильной организацией БЗ.
Доказательство заключения. Система «объясняет» ход её рассуждений по нахождению решения.

1.1.5. Виды моделей баз данных

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

Организация структуры БД формируется, исходя из следующих соображений:

Адекватность описываемому объекту или системе – на уровне концептуальной и логической модели.
Удобство использования для ведения учёта и анализа данных – на уровне так называемой физической модели.

Виды концептуальных (инфологических) моделей БД:

«сущность-связь»;
семантические модели;
графовые модели.

Виды логических (даталогических) моделей БД:

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

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

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

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

Модель «сущность-связь» была предложена в 1976 г. Питером Пин-Шэн Ченом.

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

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

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

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

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

Мы рассмотрели самую «верхушку» теории БД. Сейчас мы рассмотрим несколько моментов исторического развития, а затем вернёмся к классификации БД на более глубоком уровне.

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

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

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

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

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

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

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

2.1.2. Базы данных и информационные системы

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

Сразу на всякий случай вспомним: чем автоматическая система отличается от автоматизированной?

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

2.1.3. История развития баз данных

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

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

Обычно такие системы имеют дело с большими объемами информации, имеющей достаточно сложную структуру.

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

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

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

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

Магнитные барабаны (они ближе всего к современным магнитным дискам с фиксированными головками) давали возможность произвольного доступа к данным, но имели малый объём хранимой информации.

Эти ограничения не являлись слишком существенными для чисто численных расчётов.

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

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

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

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

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

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

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

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

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

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

А что пришло на смену файлам?

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

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

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

Рекомендуется для саморазвития найти и изучить информацию о наиболее распространённых ФС: NTFS, EXT2(3,4), ReiserFS(4), HPFS.

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

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

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

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

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

Поэтому при изменении структуры файла требовалось изменять структуру программы.

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

К слову, эта ситуация сохраняется и сейчас в случае «обычных программ» (вспомните форматы mp3, divx/xvid, «офисных» фалов и т.д.)

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

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

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

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

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

В большинстве современных систем управления файлами применяется подход к защите файлов, впервые реализованный в ОС UNIX.

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

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

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

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

Если все пользователи собираются только читать файл, ничего страшного не произойдёт.

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

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

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

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

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

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

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

2.1.4. Этапы развития баз данных

Первый этап развития БД – базы данных на больших ЭВМ

История развития СУБД насчитывает более 30 лет.

В 1968 году была введена в эксплуатацию первая промышленная СУБД IMS фирмы IBM.

В 1975 году появился первый стандарт ассоциации по языкам систем обработки данных – Conference of Data System Languages (CODASYL), который определил ряд фундаментальных понятий в теории систем баз данных, которые и до сих пор являются основополагающими для сетевой модели данных.

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

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

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

Первый этап развития СУБД связан с организацией баз данных на больших машинах типа IBM 360/370, ЕС-ЭВМ и мини-ЭВМ типа PDP11 (фирмы Digital Equipment Corporation – DEC), разных моделях HP (фирмы Hewlett Packard).

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

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

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

Особенности этого этапа развития выражаются в следующем:

все СУБД базируются на мощных мультипрограммных операционных системах (MVS, SVM, RTE, OSRV, RSX, UNIX), поэтому в основном поддерживается работа с централизованной базой данных в режиме распределённого доступа;
функции управления распределением ресурсов в основном осуществляются операционной системой;
поддерживаются языки низкого уровня манипулирования данными, ориентированные на навигационные методы доступа к данным;
значительная роль отводится администрированию данных;
проводятся серьёзные работы по обоснованию и формализации реляционной модели данных;
проводятся теоретические работы по оптимизации запросов и управлению распределённым доступом к централизованной БД, было введено понятие транзакции;
появляются первые языки высокого уровня для работы с реляционной моделью данных, однако отсутствуют стандарты для этих первых языков.

Второй этап – «эпоха персональных компьютеров»

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

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

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

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

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

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

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

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

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

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

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

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

Но и в этот период появлялись любители, которые вопреки здравому смыслу разрабатывали собственные БД, используя стандартные языки программирования.

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

Особенности этого этапа таковы:

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

Вам это всё ничего не напоминает?

Да-да, Microsoft Access.

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

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

Яркие представители этого семейства – очень широко использовавшиеся до недавнего времени СУБД Dbase (DbaseIII+, DbaseIV), FoxPro, Clipper, Paradox.

Также по непонятным причинам до сих пор используется уже упомянутый MS-Access, на котором, по хорошему, можно построить именно однопользовательскую БД или БД на «отдел из 2-3 человек» (и то уже могут быть проблемы).

Третий этап – распределённые базы данных

После процесса «персонализации» начался обратный процесс – интеграция.

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

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

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

Особенности данного этапа:

практически все современные СУБД обеспечивают поддержку полной реляционной модели;
большинство современных СУБД рассчитаны на многоплатформенную архитектуру, то есть они могут работать на компьютерах с разной архитектурой и под разными операционными системами, при этом для пользователей доступ к данным, управляемым СУБД на разных платформах, практически неразличим;
необходимость поддержки многопользовательской работы с базой данных и возможность децентрализованного хранения данных потребовали развития средств администрирования БД с реализацией общей концепции средств защиты данных;
потребность в реализации новых СУБД вызвала создание серьёзных теоретических трудов по оптимизации распределённых БД и работе с распределёнными транзакциями и запросами;
чтобы не потерять клиентов, которые ранее работали на настольных СУБД, практически все современные СУБД имеют средства подключения клиентских приложений, разработанных с использованием настольных СУБД, и средства экспорта данных из форматов настольных СУБД второго этапа развития;
именно к этому этапу можно отнести разработку ряда стандартов в рамках языков описания и манипулирования данными начиная с SQL89, SQL92, SQL99 (и т.д.) и технологий по обмену данными между различными СУБД, к которым можно отнести и протокол ODBC (Open DataBase Connectivity), предложенный фирмой Microsoft;
именно к этому этапу можно отнести начало работ, связанных с концепцией объектно-ориентированных БД – ООБД.

Первыми представителями СУБД, относящимся к этому этапу, можно считать Oracle7.3, Oracle 8.4 MS SQL6.5, MS SQL7.0, System 10, System 11, Informix, DB2, SQL Base и т.п.

Четвёртый этап – дальнейшее развитие

Этот этап характеризуется появлением новой технологии доступа к данным – «интернет/интранет-доступ».

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

Для работы с удалённой БД используется стандартный веб-браузер.

При этом код, написанный обычно на т.н. «языках веб-программирования» (Java, PHP, Perl, C#, ASP.Net) отслеживает все действия пользователя и транслирует их в низкоуровневые SQL-запросы к базе данных, выполняя, таким образом, ту работу, которой в технологии клиент-сервер занимается клиентская программа.

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

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

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

2.2. Основные термины и определения теории БД, виды БД и их отличия

2.2.1. Классификация БД

По модели представления данных БД классифицируются как:

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

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

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

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

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

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

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

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

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

К основным понятиям сетевой модели БД относятся: уровень, элемент (узел), связь.

Узел – это совокупность атрибутов данных, описывающих некоторый объект.

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

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

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

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

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

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

Примеры сетевых СУБД: Cerebrum, CronosPlus.

Иерархическая модель БД состоит из объектов с указателями от родительских объектов к потомкам, соединяющих вместе связанную информацию.

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

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

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

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

Объект «покупатель» будет иметь указатели от каждого заказчика к физическому расположению заказов покупателя в объект «заказ».

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

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

Известные иерархические СУБД:

Иерархической базой данных является файловая система.
Типичным представителем (наиболее известным и распространённым) является Information Management System (IMS) фирмы IBM. Первая версия появилась в 1968 г.
Time-Shared Date Management System (TDMS) компании Development Corporation.
Mark IV Multi - Access Retrieval System компании Control Data Corporation.
System - 2000 разработки SAS-Institute.
Серверы каталогов, такие, как LDAP и Active Directory (допускают чёткое представление в виде дерева).
По принципу иерархической БД построен и реестр Windows.

Реляционная БД – БД, основанная на реляционной модели. Теория реляционных баз данных была разработана доктором Коддом из компании IBM в 1970 году.

В реляционных БД все данные представлены в виде простых таблиц, разбитых на строки и столбцы, на пересечении которых расположены данные.

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

Кратко особенности реляционных БД можно сформулировать следующим образом:

Данные хранятся в таблицах, состоящих из столбцов («атрибутов») и строк («записей», «кортежей»).
На пересечении каждого столбца и строчки стоит в точности одно значение.
У каждого столбца есть своё имя, которое служит его названием, и все значения в одном столбце имеют один тип.
Запросы к базе данных возвращают результат в виде таблиц, которые тоже могут выступать как объект запросов.
Строки в реляционной базе данных неупорядочены – упорядочивание производится в момент формирования ответа на запрос.

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

Многомерные БД – один из наиболее распространённых переводов термина OLAP (On-line Analytical Processing).

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

Это ПО позволяет реализовать множество различных представлений данных и характеризуются тремя основными чертами:

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

Объектно-ориентированная БД – БД, в которой данные оформлены в виде моделей объектов, включающих прикладные программы, которые управляются внешними событиями.

Характеристики ООБД:

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

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

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

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

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

2.3. Реляционные БД, понятие сущности и связи

2.3.1. Общие определения

Реляционная БД (relational database) – БД, основанная на реляционной модели.

Реляционная модель данных (relational data model) – логическая модель данных, строгая математическая теория, описывающая структурный аспект, аспект целостности и аспект обработки данных в реляционных базах данных.

Структурный аспект (structure aspect) – данные в базе данных представляют собой набор отношений.

Аспект целостности (integrity aspect) – отношения отвечают определённым условиям целостности. РМД поддерживает декларативные ограничения целостности уровня домена (типа данных), уровня отношения и уровня базы данных.

Аспект обработки (манипулирования) (manipulation aspect) – РМД поддерживает операторы манипулирования отношениями (реляционная алгебра, реляционное исчисление).

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

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

Термин «реляционный» означает, что теория основана на математическом понятии отношение (relation).

2.3.2. Факты о реляционной модели данных

Для лучшего понимания РМД следует отметить следующие факты:

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

2.3.3. Достоинства реляционной модели данных

Достоинства реляционной модели

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

2.3.4. Недостатки реляционной модели данных

Недостатки реляционной модели

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

2.3.5. Целостность БД

Целостность базы данных (database integrity) – соответствие имеющейся в базе данных информации её внутренней логике, структуре и всем явно заданным правилам.

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

Примеры таких правил:

вес детали должен быть положительным;
количество знаков в телефонном номере на должно превышать N;
возраст родителей не может быть меньше возраста их ребёнка (и, по логике вещей, не может быть «чуть-чуть больше возраста ребёнка»).

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

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

Таким образом, не следует путать целостность БД с достоверностью БД.

Достоверность (истинность) БД (database reliability) – соответствие фактов, хранящихся в базе данных, реальному миру.

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

Для определения целостности БД требуется лишь обладание знаниями о содержимом БД и о заданных правилах.

Поэтому СУБД может (и должна) контролировать целостность БД, но принципиально не в состоянии контролировать достоверность БД.

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

2.3.6. Отношения

Отношение (relation) – фундаментальное понятие реляционной модели данных.

N-арным отношением R, или отношением R степени n, называют подмножество декартового произведения множеств D1, D2, … , Dn (n≥1), не обязательно различных.

Исходные множества D1, D2, ... ,Dn называют в модели доменами (в СУБД используется понятие «тип данных»).

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

Число строк (кортежей) n, называют кардиальным числом отношения, или мощностью отношения.

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

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

Под атрибутом здесь понимается вхождение домена в отношение.

Обратите внимание! Только что перечисленные свойства – это свойства ОТНШОЕНИЯ. Ниже приведены два примера: первый – отношение, представленное визуально в виде таблицы; второй – таблица, НЕ являющаяся отношением.

ФИО	Тел1	Тел2
Иванов И.И.	123-45-67	123-45-00
Петров П.П.	123-45-88	123-45-11
Фёдоров Ф.Ф.	123-45-99	123-45-22

Рисунок 2.3.6.1 – Отношение

ФИО	Тел	Тел
Иванов И.И.	123-45-67	123-45-00
Иванов И.И.	123-45-67	123-45-00
Фёдоров Ф.Ф.	123-45-99	123-45-22

Рисунок 2.3.6.2 – НЕ отношение

2.3.7. Кортежи и отношения

Кортеж (tuple) – элемент отношения («строка таблицы»).

Заголовок (схема) отношения r (Hr) – конечное множество упорядоченных пар вида <A, T>, где A называется именем атрибута, а T обозначает имя некоторого базового типа или ранее определённого домена, то есть множества допустимых значений.

SQL-пример: uid int(11)

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

Кортеж tr, соответствующий заголовку Hr – множество упорядоченных триплетов вида <A, T, v>, по одному такому триплету для каждого атрибута в Hr.

Третий элемент – v – триплета <A, T, v> должен являться допустимым значением типа данных или домена T.

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

SQL-пример:

INSERT INTO `users` (`uid`,`name`) VALUES (1,’John Smith’);

Тело Br отношения – неупорядоченное множество различных кортежей tr.

Пример тела отношения:

Иванов И.И.	123-45-67	123-45-00
Петров П.П.	123-45-88	123-45-11
Фёдоров Ф.Ф.	123-45-99	123-45-22

Рисунок 2.3.7.1 – Тело отношения

Значение Vr отношения r – пара множеств Hr и Br.

Пример значения отношения:

ФИО	Тел1	Тел2
Иванов И.И.	123-45-67	123-45-00
Петров П.П.	123-45-88	123-45-11
Фёдоров Ф.Ф.	123-45-99	123-45-22

Рисунок 2.3.7.2 – Значение отношения

2.3.8. Связи

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

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

Именно о ключах мы сейчас и поговорим…

2.3.9. Ключи отношений

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

Первичный ключ (primary key) – минимальное множество атрибутов, являющееся подмножеством заголовка данного отношения, составное значение которых уникально определяет кортеж отношения.

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

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

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

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

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

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

Простой первичный ключ (simple key) – первичный ключ, состоящий из единственного поля таблицы (атрибута отношения), значения которого уникальны для каждой записи.

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

Рисунок 2.3.9.1 – Первичный ключ

Составной первичный ключ (compound key, composite key, concatenated key) – первичный ключ, состоящий из нескольких полей таблицы (атрибутов отношения).

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

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

Рисунок 2.3.9.2 – Составной первичный ключ

Что ещё (какие поля) можно добавить в такую таблицу?

Например: «вид родства» (усыновлён, родной ребёнок и т.п.)

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

Такой первичный ключ называют естественным ключом.

На практике использование естественных ключей наталкивается на определённые сложности:

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

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

Чаще всего таким ключом является целочисленное поле, на которое налагается функция автоинкрементирования.

Рисунок 2.3.9.3 – Синтетический первичный ключ

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

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

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

Это может делаться при помощи триггеров (типичный способ порождения ключей в Oracle).

В ряде СУБД (например, Sybase, MySQL или SQL Server) существует специальный тип данных для таких полей – числовое поле, в которое при добавлении записи в таблицу автоматически записывается уникальное для этой таблицы числовое значение – т.н. «автоинкремент» (autoincrement).

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

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

Так, например, проще написать запрос:

SELECT * FROM p, c WHERE p.primary_key = c.foreign_key;

Чем

SELECT * FROM p, c WHERE p.id1 = c.fk1 AND p.id2 = c.fk2 AND p.id3 = c.fk3;

Кроме того, первый вариант работает быстрее.

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

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

Каждый возможный ключ, кроме выбранного первичным, называется так же альтернативным ключом (alternative key).

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

Один из возможных ключей таблицы выбирается в качестве её первичного ключа.

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

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

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

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

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

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

Рисунок 2.3.9.3 – Интеллектуальный ключ

Особенности интеллектуальных ключей

По сути, интеллектуальный ключ является естественным составным ключом, поэтому ему присущи все недостатки естественного ключа.

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

Кроме того, интеллектуальный ключ не всегда может гарантировать уникальность, например, если в только что рассмотренную таблицу таблицу добавится запись «Петров Евгений Васильевич»:

Рисунок 2.3.9.4 – Нарушение уникальности интеллектуального ключа

На практике интеллектуальные ключи часто используются в качестве т. н. «магических кодов» (magic codes) – идентификаторов, отражающих те или иные данные.

Например, идентификатор события «03-40123» в формате «FY-XNNNN», где:

FY = 2 цифры финансового года;
X = 1 цифра, задающая тип события;
NNNN = 4 цифры, задающие порядковый номер события данного типа в этом финансовом году.

Ничего не напоминает?

Это – хэш. Т.е. один из видов примитивного хэша.

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

если при вводе данных произошла ошибка, и ключ оказался неверным (например, событие было типа 3, а не 4), то в системе это событие уже известно как «03-40123», и для исправления ситуации необходимы будут каскадные изменения данных;
в систему вносятся ограничения, основанные на предположениях о максимальных значениях полей:
- количество событий в году не более 10000;
- типов событий не более 10;
- две цифры для года – вспомним «проблему 2000».
такие ключи неудобно реализовывать;
далеко не всегда существует необходимость знать значения атрибутов записи непосредственно из её ключа.

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

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

Пусть имеются таблицы «A» и «B».

Таблица «A» содержит поля «a», «b», «c», «d», из которых поле «a» – первичный ключ.

Таблица «B» содержит поля «x», «y», «z». В поле «y» содержится значение поля «a» одной из записей таблицы «A».

В таком случае поле «y» называется внешним ключом таблицы «A» в таблице «B».

Вот такой SQL-запрос вернёт все связанные пары записей из таблиц «A» и «B»:

select * from A, B where A.a = B.y

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

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

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

Пример только что описанных таблиц «A» и «B».

Рисунок 2.3.9.5 – Пример описанных таблиц

Пример рекурсивного внешнего ключа.

Хранимая структура:

Рисунок 2.3.9.6 – Хранимая структура

Пример рекурсивного внешнего ключа.

Таблица:

Рисунок 2.3.9.7 – Табличное представление хранимой структуры

2.3.10. Ссылочная целостность

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

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

Таким образом, всегда имеется возможность выполнить две операции:

определить, с каким кортежем в отношении B связан определённый кортеж отношения A;
найти все кортежи отношения A, имеющие связи с определённым кортежем отношения B.

Ссылочная целостность может быть проиллюстрирована следующим образом: Дана пара отношений «A» и «B», связанных внешним ключом.

Первичный ключ отношения «B» – атрибут «B.key». Внешний ключ отношения «A», ссылающийся на отношение «B» – атрибут «A.b».

Ссылочная целостность для пары отношений «A» и «B» имеет место тогда, когда выполняется условие: для каждого кортежа отношения «A2 существует соответствующий кортеж отношения «B», то есть кортеж, у которого (B.key = A.b).

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

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

Такая БД не может нормально эксплуатироваться, так как в ней разорваны логические связи между зависимыми друг от друга фактами.

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

Рассмотрим пример. Основная таблица «Адрес» содержит непосредственно номер дома и квартиры, а вместо имени улицы в поле «улица» имеет внешний ключ, ссылающийся на таблицу «Улицы» – справочник улиц.

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

Рисунок 2.3.10.1 – Ссылочная целостность и её нарушение

Две записи таблицы «Адрес» (id = 887 и id = 994) имеют в поле «улица» так называемые «висящие ссылки» – значения, которым не соответствуют записи в таблице «Улицы» (эти ссылки показаны красным цветом).

Из-за этого результат SQL-запроса, выбирающего адреса (полные, по равенству полей) не будет содержать этих двух записей – для них условие запроса не выполнится.

И ещё одна запись не будет выбрана таким запросом (id = 85).

Это вариант намеренного (и, в некоторых случаях, легального) нарушения ссылочной целостности – в поле внешнего ключа записан NULL (показано синим цветом).

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

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

Пустые внешние ключи

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

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

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

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

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

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

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

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

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

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

При описании таблиц БД программист явно описывает, какие поля таблиц являются внешними ключами и на какие таблицы они ссылаются.

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

При этом:

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

2.3.11. Консистентность данных

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

Консистентность данных (data consistency, data validity) – согласованность данных друг с другом, целостность данных, а также внутренняя непротиворечивость.

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

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

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

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

Условия целостности данных (integrity constraints) стали записывать в виде правил и ввели триггеры – процедуры, которые вызываются до и/или после выполнения запроса.

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

После выполнения запроса (триггер типа AFTER) проверяется, что состояние базы данных удовлетворяет условиям целостности.

Если один из триггеров не срабатывает (или срабатывает с ошибкой), то транзакция откатывается (roll-back) (отменяется). Если же все триггеры сработали успешно, транзакция подтверждается (commit) (завершается).

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

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

Сейчас же мы рассмотрели основы этих вопросов и переходим к последовательному рассмотрению структуры БД…

2.4. Многоуровневая архитектура баз данных, понятие физического и логического уровней баз данных

2.4.1. Определения

Проектирование БД начинается с этапа «концептуального проектирования».

Концептуальное проектирование – это сбор, анализ и редактирование требований к данным. Для этого осуществляются следующие мероприятия:

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

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

Эта модель будет нас интересовать на «инфологическом уровне» схемы, представленной на следующем рисунке.

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

Следующий этап – логическое проектирование.

Логическое проектирование – преобразование требований к данным в структуры данных.

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

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

Эта модель будет нас интересовать на «даталогическом уровне» схемы, представленной на следующем рисунке.

Следующий этап – физическое проектирование.

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

На выходе этого этапа мы получаем «физическую модель» базы данных.

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

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

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

2.4.2. Многоуровневая структура баз данных

В наших дальнейших рассуждениях о БД и её уровнях мы будем отталкиваться от следующей схемы.

Рисунок 2.4.2.1 – Схема уровней БД

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

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

Т.о. «метод доступа» можно рассматривать как некий аналог «драйвера».

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

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

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

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

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

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

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

Вся эта информация используется методом доступа, а не непосредственно СУБД.

Предположим, что структура хранения включает хранимый файл PART, где каждый экземпляр хранимой записи состоит из номера детали (Р#), наименования детали (PNAME), цвета (COLOR) и веса (WEIGHT).

Часть определения структуры хранения в этом случае может иметь следующий вид:

STORED FILE PART {Р#, PNAME, COLOR, WEIGHT)

SEQUENCED ASCENDING P#

INDEXED Р#

Это определение говорит о следующем:

существует хранимый файл PART;
хранимая запись имеет конкретную структуру;
экземпляры хранимой записи упорядочены в возрастающем порядке значений Р# (механизм упорядочения здесь НЕ задаётся);
поле Р# индексировано, так что прямой доступ может выполняться по некоторому значению, соответствующему этому полю.

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

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

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

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

2.4.3. Постоянная и переменная длина записи

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

Для файлов с постоянной длиной записи адрес размещения записи с некоторым номером K может быть вычислен по формуле:

ВА + (К- 1) * LZ + 1

где ВА – базовый адрес, LZ – длина записи.

Вопрос: что в таком случае сильнее всего влияет на скорость доступа к записи?

Ответ: особенности устройства. Так, например, у винчестеров время позиционирования и скорость линейного чтения могут зависеть от номера цилиндра.

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

Вопрос: чем плохи такие файлы?

Ответ: в реальных БД очень часто приходится хранить поля с переменной длиной («ФИО», «улица», «биография» и т.д.) Для хранения таких полей (пусть даже каждое поле таблицы хранится в своём отдельном файле, что часто – очень неэффективно) придётся отводить под каждую запись «максимально возможное количество байт», что приводит к потере памяти.

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

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

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

В силу того, что каждая запись такого файла занимает произвольный объём памяти, простым вычислением получить адрес записи сразу и гарантированно – НЕВОЗМОЖНО.

2.4.4. Способы представления данных

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

Рисунок 2.4.4.1 – Пример сохраняемой таблицы

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

2.4.5. Простейший вариант – плоский файл

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

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

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

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

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

2.4.6. Факторизация по значениям поля

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

Рисунок 2.4.6.1 – Факторизация по значению поля

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

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

Единственным преимуществом этого варианта представления в сравнении с предыдущим является экономия памяти.

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

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

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

2.4.7. Индексирование по полям

Если запрос «найти всех поставщиков из данного города» является важным, мы можем выбрать вариант представления, изображенный на следующем рисунке:

Рисунок 2.4.7.1 – Индексирование по полям

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

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

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

Интересным свойством этого представления является то, что файл городов служит индексом для файла поставщиков (индекс, управляемый СУБД, но не методом доступа).

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

В этом случае (поскольку индекс – плотный) индексируемый файл не должен содержать индексируемое поле (в этом примере файл поставщиков не включает поле города).

Мы рассмотрим «неплотное» индексирование чуть-чуть позже.

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

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

Рисунок 2.4.8.1 – Комбинация простых представлений

2.4.9. Использование цепочек указателей

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

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

Рисунок 2.4.9.1 – Использование цепочек указателей

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

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

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

Преимущество этого варианта представления состоит в простоте внесения изменений.

Недостатком является то, что для данного города единственным способом доступа к n-му поставщику является последовательное прохождение по цепочке от первого ко второму и т.д. до (n-1)-го поставщика.

Если каждая операция доступа включает операцию поиска, то время доступа к n-му поставщику может стать достаточно большим.

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

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

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

2.4.10. Многосписочные структуры

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

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

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

2.4.11. Инвертированная организация

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

Рисунок 2.4.11.1 – Инвертированная организация

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

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

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

2.4.12. Иерархическая организация

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

Рисунок 2.4.12.1 – Иерархическая организация

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

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

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

2.4.13. Хэш-аресация

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

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

Подробнее о хэш-функциях – в конце этой темы.

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

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

Рассмотрим пример хэш-адресации.

Предположим, что значениями S# являются S100, S200, S300, S400, S500 (вместо S1, S2, S3, S4, S5).

Рассмотрим хэш-функцию:

АдресХранимойЗаписи = S# % 13

(остаток от деления значения S# на 13)

Это простой пример общего класса хэш-функций – «деление/остаток» (делителем обычно является простое число).

Адресами хранимых записей в данном случае будут 9, 5, 1, 10, 6 соответственно.

Рисунок 2.4.13.1 – Хэш-адресация

Теоретически возможно использовать числовое значение первичного ключа в качестве адреса хранимой записи.

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

Например, предположим, что номера поставщиков являются трёхзначными, как это было определено ранее.

Теоретически это допускает 1000 различных поставщиков, в то время как на практике может существовать, допустим, 10.

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

Чтобы учесть возможное расширение в будущем диапазон обычно увеличивают на 20%.

Так, в только что рассмотренном примере мы выбрали функцию, которая генерирует значения в диапазоне 0-12, а не в диапазоне 0-9.

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

Фактически хранимый файл с хэш-адресацией обычно рассматривается как неупорядоченный.

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

Например, предположим, что в наш пример включён поставщик со значением номера равным S1400.

Хранимые записи этого поставщика и поставщика S100 будут иметь, в соответствии с использованной нами хэш-функцией, одинаковый адрес хранимой записи – 9.

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

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

В этом случае для того, чтобы добавить запись о поставщике S1400 осуществляется поиск свободного места вперёд, начиная с позиции, определяемой адресом хранимой записи – 9.

В данном случае запись о новом поставщике будет размещена по адресу 11. При последующей выборке поставщика S1400 выполняются аналогичные действия.

2.4.14. Промежуточный итог

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

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

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

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

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

Рисунок 2.4.14.1 – Виды файлов БД

2.4.15. Методы индексирования

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

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

Физическое следование записей является важным средством установления порядка экземпляров хранимых записей в хранимом файле за счёт:

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

Это имеет следующее значение для разработки индексов.

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

При этом соблюдаются следующие условия:

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

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

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

Последовательность групп представлена последовательностью элементов в индексе.

Термин «неплотный» (неплотный индекс) отражает тот факт, что индекс не содержит элементов для каждого экземпляра хранимой записи в индексируемом файле.

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

Алгоритм поиска здесь таков:

Поиск по индексу ключа (первый найденный ключ ≥ требуемого ключа).
Переход на найденную область памяти.
Физически последовательный просмотр области памяти.

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

Наличие физического упорядочения позволяет строить многоуровневые индексы (древовидные индексы).

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

Однако всё ещё необходимо последовательно просматривать если и не сам файл, то, по крайней мере, индекс.

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

Решение проблемы – создать «индекс для индекса».

Простой пример такого индекса изображён на следующем рисунке:

Рисунок 2.4.15.1 – Двухуровневый индекс

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

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

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

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

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

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

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

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

Рассмотрим их…

2.4.16. Индексирование по комбинации полей

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

Рисунок 2.4.16.1 – Индексирование по комбинации полей

С помощью такого индекса мы можем ответить на такие вопросы, как «найти всех поставщиков в Париже со статусом 10» за один просмотр индекса.

Если комбинированного индекса не существует, ответ на этот вопрос потребует:

поиска всех поставщиков в Париже;
поиска всех поставщиков со статусом 10;
выделения поставщиков, общих для обоих списков.

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

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

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

2.4.17. Селективный индекс

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

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

Например, рассмотрим файл «Служащие», в котором 5% служащих освобождено от уплаты налогов и 95% такого освобождения не имеют.

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

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

2.4.18. Индексация по методу сжатия

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

Эти методы могут быть использованы везде, где доступ к данным должен осуществляться последовательно, например, в пределах индекса или в пределах одной «группы» файла, для которого существует неплотный индекс.

Рассмотрим в качестве примера один блок индекса гипотетического файла «Служащие».

Предположим, что первые четыре элемента в этом блоке соответствуют следующим служащим:

ROBERTON
ROBERTSON
ROBERTSTONE
ROBINSON

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

2.4.19. Фронтальное сжатие

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

Суть метода состоит в том, что у каждого элемента все первые (фронтальные) символы, совпадающие с соответствующими фронтальными символами предшествующего элемента, замещаются соответствующим счётчиком.

Результатом применения этого метода будет:

0 – ROBERTON****
6 – SON***
7 – TONE*
3 – INSON****

Все завершающие пробелы в дачном случае обозначены *.

2.4.20. Сжатие окончания

Вторым методом сжатия является сжатие окончания.

Один способ использования сжатия окончания для данного примера заключается в устранении всех завершающих пробелов (опять-таки посредством их замещения соответствующим счётчиком).

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

Применение этого метода даёт:

0 – 7 – ROBERTO
6 – 2 – SO
7 – 1 –Т
3 –1 – I

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

Заметим, однако, что в данном случае имеет место потеря информации из индекса, т.е. после распаковки элементы будут иметь вид:

ROBERTO?????
ROBERTSO????
ROBERTST????
ROBI????????

где ? представляет собой неизвестный знак.

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

2.4.21. Символьные указатели

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

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

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

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

Если метод доступа упорядочивает хранимый файл с помощью индекса по некоторому полю, то недостаточно, чтобы индекс содержал только значения из этого поля. Нужны ещё и вполне «числовые» параметры (файл, смещение и т.п.), т.к. иначе использование индекса не будет иметь смысла.

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

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

Рисунок 2.4.22.1 – Использование символьных указателей

2.4.23. Индексно-последовательная организация

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

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

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

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

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

Для работы с индексно-последовательным файлом можно использовать два режима обработки:

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

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

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

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

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

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

Рисунок 2.4.23.1 – Индексы для последовательно расположенных записей

Рисунок 2.4.23.2 – Индексы для произвольно расположенных записей

2.4.24. Сбалансированные деревья

Построение В-деревьев (balanced trees, сбалансированных деревьев) связано с простой идеей построения индекса над уже построенным индексом.

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

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

Количество обращений к диску при этом для поиска любой записи одинаково и равно количеству уровней в построенном дереве.

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

2.4.25. Ведение файла

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

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

На следующем рисунке показано включение четырёх новых записей в последовательный файл.

Рисунок 2.4.25.1 – Ведение файла

При добавлении записи оказались в т.н. «области переполнения». Затем будет произведена реорганизация основного файла и индексов, в результате чего новые записи займут своё место в последовательной организации.

Однако, как несложно понять, процесс реорганизации файлов и индексов – это долгий процесс.

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

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

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

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

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

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

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

Однако данный метод не позволяет полностью избежать выполнения процедуры ведения («пустые записи» могут закончиться; добавленные данные могут оказаться расположенными с нарушением упорядоченности).

Метод, основанный на включении пропусков в файле, называется «методом распределённой свободной памяти» (distributed free space).

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

2.4.26. Хэширование

Хэширование (hashing) – преобразование входной последовательности данных произвольной длины в выходную битовую строку фиксированной длины.

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

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

Простейшими примерами хэш-функций может служить контрольная сумма.

В общем случае однозначного соответствия между исходными данными и хэш-кодом нет.

Поэтому существует множество массивов данных, дающих одинаковые хэш-коды – так называемые коллизии.

Вероятность возникновения коллизий играет немаловажную роль в оценке «качества» хэш-функций.

2.4.27. Хэш-таблицы

Хэш-таблица – это структура данных, реализующая интерфейс ассоциативного массива.

Она позволяет хранить пары (ключ, значение) и выполнять три операции:

добавление новой пары по ключу;
поиск пары по ключу;
удаление пары по ключу.

Существует два варианта хэш-таблиц:

с прямой адресацией;
с открытой адресацией.

Хэш-таблица содержит некоторый массив H, элементы которого – это:

пары (хэш-таблица с открытой адресацией);
списки пар (хэш-таблица с прямой адресацией).

Выполнение операции в хэш-таблице начинается с вычисления хэш-функции от ключа.

Получающееся хэш-значение

i = hash(key)

играет роль индекса в массиве H.

Затем выполняемая операция (добавление, удаление или поиск) перенаправляется объекту, который хранится в соответствующей ячейке массива H[i].

Ситуация, когда для различных ключей получается одно и то же хэш-значение, называется коллизией (collision).

Число хранимых элементов делённое на размер массива H (число возможных значений хэш-функции) называется коэффициентом заполнения хэш-таблицы (load factor) и является важным параметром, от которого зависит среднее время выполнения операций.

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

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

Существует несколько способов разрешения колизий.

Рассмотрим самые простые.

Прямая адресация

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

Массив H после этого должен быть реорганизован.

Открытая адресация

В массиве H хранятся сами пары. В случае возникновения коллизии, алгоритм поиска (удаления, добавления) объекта просто перемещается на ячейку вправо до момента разрешения коллизии.

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

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

2.4.28. Итог

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

В следующих темах мы рассмотрим более сложные «готовые решения».

2.5. Алгоритмы хэширования

2.5.1. Введение

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

2.5.2. Хэширование

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

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

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

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

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

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

В настоящее время известно много различных методов хэширования в применении к СУБД.

Мы же рассмотрим основные…

2.5.2. Факторы эффективности хэширования

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

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

От оптимального выбора этих факторов зависит эффективность работы СУБД.

2.5.3. Размер участка памяти

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

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

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

Допустим также, что можно изменять объём гнезда (т.е. можно изменять число шариков, которое помещается в каждое гнездо).

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

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

Если число гнёзд равно 10 и объём каждого гнезда также равен 10, то в область переполнения будет попадать значительно меньшее число шариков, чем в первом случае.

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

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

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

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

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

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

2.5.4. Плотность заполнения

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

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

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

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

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

С этой целью можно снизить среднее число записей в области переполнения до 1%.

2.5.5. Алгоритмы хэширования

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

Если ключ не цифровой, он преобразуется в соответствующее цифровое представление таким образом, чтобы, исключить потерю информации, содержащейся в ключе. Например, буквенные знаки должны переводиться в цифровой код; допускается также представление символьного ключа в виде строки битов.
Ключи (в цифровом или битовом представлении) преобразуются в совокупность произвольно распределённых чисел, значения которых имеют тот же порядок, что и значения адресов основной области памяти. Желательно, чтобы набор ключей был распределён как можно равномернее в диапазоне, переводимом в допустимые адреса.
Полученные числа умножаются на константу, что позволяет разместить их строго в диапазоне значений адресов основной области. Например, пусть в результате выполнения этапа 2 мы получаем четырёхзначные числа, а в основной области имеется 7000 пакетов. Тогда четырёхзначные числа следует умножать на 0.7, что позволит распределить получаемые адреса в интервале от 0000 до 6999. Этот относительный номер участка преобразуется в машинный адрес участка.

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

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

Метод квадратов

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

Для получения номера участка достаточно умножить полученное число на соответствующую константу (в примере, рассмотренном выше, эта константа равна 0.7).

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

Например, пусть ключ записей состоит из шести цифр, а число участков в основной области равно 7000. Если ключ записи равен 172 148, то его квадрат равен 029 634 933 904. Четыре центральные цифры составляют число 3493. Номер участка равен 3493*0.7=2445.

Деление

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

Например, если число участков равно 7000, то в качестве делителя можно использовать число 6997. Пусть ключ записи равен 172 148. Остаток от деления 172 148 на 6997, равный 4220, будет взят в качестве относительного адреса участка, в который направляется запись с ключом 172 148.

При использовании данного метода в область переполнения направляется меньшее число записей. Одна из причин этого заключается в том, что ключи часто задаются в определенной последовательности (например, возрастающей). Тогда и остатки от деления на число (например, на 6997) также будут иметь соответствующую последовательность, что обеспечит равномерное заполнение участков.

Сдвиг разрядов

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

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

Рассмотрим рисунок…

Рисунок 2.5.5.1 – Сдвиг разрядов

Складывание

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

Рассмотрим на рисунке…

Рисунок 2.5.5.1 – Складывание

Анализ отдельных разрядов ключа

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

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

Преобразование основания системы счисления

После преобразования системы счисления выделяются младшие разряды числа.

Рассмотрим пример (перевод в 11-ричную систему счисления). Пусть ключ равен 172 148. Тогда

1*11^5+7*11^4+2*11^3+1*11^2+4*11^1+8 = 266 373

Младшие разряды: 6373.

Выравнивание адреса: 6373*0.7 = 4461

Метод Лина

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

Рассмотрим пример. Ключ 172 148 поразрядно преобразуется в двоичную строку: 0001 0111 0010 0001 0100 1000.

После этого осуществляется перегруппировка строки по три разряда: 000 101 110 010 000 101 001 000=05 620 510.

Затем осуществляется деление числа 05 620 510 на константу q по правилам деления десятичных чисел. Остаток от деления даёт номер участка.

Деление полиномов

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

Например, ключ 172 148 может быть представлен полиномом

1x^5+7x^4+2x^3+1x^2+4x^1+8x^0

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

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

2.5.6. Размещение записей в области переполнения

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

Записи располагаются в области переполнения, отделённой от основной области.
Записи располагаются в области переполнения, хранимой в пределах основной области.

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

Существуют два основных метода реализации этих подходов.

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

2.5.7. Итог

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

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

2.6. Механизмы обработки и хранения данных в БД

2.6.1. Введение

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

Нам с вами предстоит рассмотреть принципы физической организации данных в MS SQL Server, а также такие методы физической организации данных как: ISAM, VSAM, MyISAM, InnoDB.

Рассмотрение этой части нашего курса мы начнём с классической СУБД, стоящей «посередине» по степени сложности, но в то же время дающей хорошее представление о механизмах хранения и обработки данных, – MS SQL Server.

2.6.2. Механизмы обработки и хранения данных в MS-SQL 6.0-6.5

В версии 6.0 и 6.5 MS SQL Server структура хранения данных рассматривается в следующей иерархии.

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

Сервер может управлять 256 устройствами.

Главное устройство называется Master: на нём хранятся системные базы данных: Master, Model, Pubs, TcodepDb.

Устройство Master имеет номер 0 (ноль).

Каждое устройство разбивается не более чем на 16’777’216 виртуальных страниц (virtual page) по 2 Кб.

Максимальный размер устройства – 32 Гб.

Первые 4 страницы устройства Master заняты под блок конфигурации (configuration block) – там хранятся все параметры конфигурации сервера.

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

Каждая страница БД имеет свой уникальный номер.

Физически используются 3 единицы хранения данных:

страница (page);
блок (extent) – 16Кб из 8 следующих друг за другом страниц;
единица размещения (allocation unit) – 512 Кб из 32 последовательных блоков (256 страниц).

При создании новой базы данных пространство для неё отводится единицами размещения. Минимальный объём базы данных для данной версии сервера равен 1 Мб, то есть составляет 2 единицы размещения.

Страницы бывают пяти типов:

страницы размещения (allocation page);
страницы данных (data page);
индексные страницы (index page);
текстовые страницы (text/image page);
статистические страницы (distribution page).

Любая страница имеет заголовок, занимающий 32 байта.

Заголовок содержит:

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

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

Первая страница каждой единицы размещения (allocation unit) является страницей размещения (allocation page).

Таким образом, все страницы, кратные 256, начиная с 0, являются страницами размещения.

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

Страница размещения содержит 32 16-байтовых структуры, по одной на каждый блок. Каждая структура содержит следующую информацию:

идентификатор объекта (владельца блока);
номер следующего блока в цепи;
номер предыдущего блока в цепи;
битовую карту распределения блока (allocation bitmap);
битовую карту перераспределения блока (deallocation bitmap);
идентификатор индекса (если таковой есть), размещённого на блоке;
статус.

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

Если бит равен 1, то страница в данный момент содержит данные, если 0 – страница свободна.

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

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

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

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

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

Рассмотрим на рисунке…

Рисунок 2.6.2.1 – Структура страницы

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

Размер страницы равен 2048 байт, 32 байта занимает заголовок.

Кроме того, в таблице смещения отводится по 2 байта на каждую строку на странице.

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

Данные хранятся на страницах в виде строк (кортежей). Каждая строка данных кроме собственно данных хранит дополнительную форматирующую информацию.

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

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

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

Структура строки таблицы приведена на следующем рисунке…

Рисунок 2.6.2.2 – Структура строки таблицы

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

Таблица смещений (column offset table) состоит из:

таблицы подстройки смещений (offset table adjust bytes) – по 1 дополнительному байту на каждое поле, смещение которого превышает 256 байт;
указателя на местоположение таблицы смещений;
указателя на местоположение полей переменной длины (1 байт на каждое поле).

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

Таблица смещения строк

Местоположение строки на странице определяется таблицей смещения строк (row offset table).

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

Чтобы найти строку с заданным номером, SQL Server считывает из соответствующей ячейки смещение, которое и является адресом требуемой строки. Ячейка таблицы однозначно связана с определённым номером строки.

Удалённые строки имеют нулевое смещение. Поэтому из примера на следующем рисунке видно, что строки 1 и 4 удалены.

У этой модели есть недостаток. После удаления строки в таблице смещения всё равно остаётся ссылка на неё, которая занимает 1 байт.

Однако при добавлении новой строки SQL Server проверяет таблицу смещений, и новой строке присваивается номер удалённой, а в соответствующую ячейку таблицы смещений заносится адрес новой строки.

Рисунок 2.6.2.3 – Таблица смещений строк

В SQL Server 6.5 используется понятие кластерного индекса.

В таблице, для которой создаётся кластерный индекс, данные хранятся строго упорядоченно по полю, для которого создан этот кластерный индекс.

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

При заполнении таблиц с кластерным индексом вводится параметр, соответствующий проценту заполнения страницы (fill-factor). Если страница заполнена, то данные заносятся на последнюю страницу в цепочке страниц, занятых этой таблицей.

На одной текстовой странице хранятся только данные одной строки основной таблицы (см. следующий рисунок).

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

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

Рисунок 2.6.2.4 – Хранение тестовых данных

2.6.3. Механизмы обработки и хранения данных в MS-SQL 7.0 и более поздних версиях

SQL Server 7.0 организует следующую иерархию хранения:

База данных – некоторый объём физического пространства, на котором размещаются данные, принадлежащие одной логической базе данных.
Файл. Каждая база данных содержит не менее двух файлов. Один из них отводится под журнал транзакций. В отличие от версии 6.5 в новой версии журнал транзакций не может располагаться в одном файле с данными. И ещё одно принципиальное отличие – в версии 7.0 каждый файл может принадлежать только одной базе данных.
Страница. Файлы делятся на страницы размером по 8 Кб каждая. Логический номер страницы складывается из внутреннего номера базы данных, номера файла и номера страницы в файле. В рамках БД файлы нумеруются, начиная с 1, и так же нумеруются страницы в рамках файла.
Блоки (экстенты, extents). Пространство под объекты отводится блоками по 8 следующих друг за другом страниц. Блок является основной единицей отведения пространства. Поэтому при создании БД можно указывать размер файла с точностью до 64 Кбайт.

В отличие от версии 6.5 объекты БД не обязательно занимают целый блок. На начальном этапе заполнения объект может занимать внутри блока несколько страниц. Поэтому существуют два типа блоков:

однородные (uniform) – все страницы однородного блока принадлежат одному объекту БД;
- смешанные (mixed) – разные страницы в блоке принадлежат разным объектам.

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

В SQL 7.0 существует уже 7 типов страниц:

страница данных (data page);
индексные страницы (index page);
страницы журнала транзакций (log page);
текстовые страницы (text/image page);
карты распределения блоков (global allocation map page);
карты свободного пространства (free space page);
индексные карты размещения (index allocation map page).

Все страницы имеют заголовок размером 96 байт.

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

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

номер страницы в формате «номер файла, номер страницы»;
идентификатор объекта, которому принадлежит страница;
номер индекса, которому принадлежит страница;
уровень внутри индексного дерева, которому принадлежит страница;
количество отведённых строк на странице, количество заполненных слотов;
общий объём свободного пространства на странице;
указатель на расположение свободного пространства после последней строки на странице;
минимальная длина строки на странице;
объём зарезервированного пространства.

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

Новыми в архитектуре дисковой памяти являются страницы размещения. В этих страницах хранятся сведения о размещении данных.

SQL Server 7.0 использует три типа страниц размещения:

карты распределения блоков;
карты свободного пространства;
индексные карты размещения.

SQL Server 7.0 хранит информацию размещения на разных уровнях:

на уровне блоков;
на уровне страниц;
на уровне объектов.

Такой разносторонний мониторинг помогает СУБД оптимизировать работу в соответствии с требованиями конкретного запроса.

Карты распределения блоков

В данных картах хранится информация о распределении блоков. Карта распределения блоков состоит из стандартного заголовка и одного битового массива в 64 000 битов.

Каждый бит характеризует один блок. Поэтому одна страница карты распределения описывает пространство в 64 000 блоков или 4 Гб данных.

Карты распределения блоков делятся на два типа:

глобальная карта распределения (global allocation map, GAM) – хранит информацию об использовании блоков, если бит установлен в 0, то блок занят данными, если в 1 – то блок свободен;
вторичная глобальная карта распределения (secondary global allocation map, SGAM) – хранит информацию о типе блоков, если бит установлен в 1, то блок смешанный и минимум одна страница в нём свободна, в остальных случаях (блок свободен, блок смешанный, но свободных страниц нет, блок однородный) бит равен 0.

Карты свободного пространства

Степень заполнения страниц в отслеживает специальный механизм – карты свободного пространства (page free space, PFS). Каждая PFS-страница хранит информацию о 8000 страниц, по 1 байту на страницу.

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

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

Страница 1 состоит из двух частей. После стандартного заголовка страницы следует заголовок файла, содержащий его описание, затем размещается блок PFS. Страницы PFS повторяются через каждые 8000 страниц, если размер файла превосходит один блок.

Страница 2 – это GAM, страница 3 – это SGAM. Карты распределения блоков повторяются через каждые 512 000 страниц. Кроме того, каждая девятая страница первичного файла – это загрузочная страница БД (database boot page), содержащая описание БД и параметры конфигурации.

Карты размещения

Для организации связи между блоками и расположенными на них объектами используются индексные карты размещения (index allocation map, IAM).

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

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

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

Каждая IAM описывает некоторый диапазон блоков и представляет собой битовую карту: если бит установлен в 1, то в данном блоке есть страницы, принадлежащие данному объекту, если в 0 – то нет.

Страницы данных

Страница данных делится на 3 зоны:

заголовок;
область данных;
таблицу смещений.

В отличие от SQL Server 6.5 в новых версиях страницы данных не связаны друг с другом в цепочки. За связь между страницами и объектами отвечает новая специальная структура – карты размещения.

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

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

В SQL Server, начиная с версии, 7.0 поддерживается классический термин слот (slot) – место размещения строки на странице.

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

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

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

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

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

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

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

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

Максимальное количество полей в строке 1024, в версии 6.5 только 256.

Текстовые страницы

В версии 7.0 изменены принципы хранения текстовых полей. Строки данных по-прежнему содержат 16-байтные указатели на текстовые данные. Однако хранение самих текстовых данных производится иначе.

Текстовая страница теперь может содержать несколько текстовых полей. Собственно данные хранятся в виде сбалансированного дерева (B-tree). Строка данных содержит указатель на корневую структуру (root structure) размером 84 байта.

Данные длиной менее 64 байт хранятся в корневой структуре. Для данных до 32 Кб корневая структура (root structure) может адресовать 4 блока данных до 8 Кб каждый.

Блоки наращиваются до 8 Кб (реально на одной текстовой странице может быть размещено 8080 байт).

Например, если первая порция данных составляет 4 Кб, то отводится один блок. Если в дальнейшем данные увеличиваются до 6 Кб, то первый блок увеличивается до 6 Кб, а второй блок имеет размер всего 2 Кб.

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

В версии 7.0 текстовая страница может содержать данные нескольких текстовых полей, как показано на следующем рисунке…

Рисунок 2.6.3.1 – Текстовая страница

Страницы журнала транзакций

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

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

Архитектура разделяемой памяти

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

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

Разделяемая память, управляемая СУБД, состоит из нескольких типов буферов:

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

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

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

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

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

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

На этом мы закончили рассмотрение физических моделей, применяемых в MS SQL Server.

Физические модели большей частью скрыты от пользователей. Однако в SQL существует команда создания индексных файлов. При этом по умолчанию стандартно создаются индексные файлы для первичных ключей, для вторичных ключей индексные файлы создаются дополнительной командой CREATE INDEX.

2.6.4. Метод доступа ISAM

ISAM (indexed sequential access method, индексно-последовательный метод доступа).

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

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

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

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

С другой стороны, допускается расположение области переполнения за пределами этого цилиндра.

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

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

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

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

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

Метод ISAM допускает многоуровневое (плотное или неплотное) индексирование. См. предыдущую тему данного курса.

Сейчас – рисунки…

Рисунок 2.6.4.1 – Области переполнения в конце цилиндров

Рисунок 2.6.4.2 – Независимая область переполнения

2.6.5. Метод доспута MyISAM

MyISAM – подсистема низкого уровня (метод доступа) в MySQL.

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

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

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

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

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

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

Индексные файлы имеют расширение .MYI (MYIndex). Файлы с расширением .MYD (MYData) содержат данные, а с расширением .frm – схему таблицы.

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

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

Индексы создаются в виде двоичных деревьев.

Разрешается индексировать столбцы типа BLOB и TEXT, а также столбцы, допускающие значения NULL.

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

Недостатки MyISAM

отсутствие самовосстановления по журналу при сбоях;
отсутствие блокировок областей меньших, чем целые таблицы, что приводит к отсутствию масштабируемости, т.е. к сильной деградации производительности с повышением нагрузки;
отсутствие средств резервного копирования (утилита mysqldump является не инструментом резервного копирования, а инструментом экспорта в текст);
слабая реализация сортировки (MyISAM сортирует данные слиянием, с использованием qsort для первоначально сливаемых небольших регионов, что требует неоптимального по дисковому вводу/выводу создания на каждую операцию сортировки 2 временных файлов.

Данные недостатки проявляются в заметной степени на нагрузке порядка полутысячи клиентов, исполняющих сложные запросы по базе данных размером в 2-4 Гб.

2.6.6. Метод доступа VSAM

VSAM (virtual sequential access method, виртуально-последовательный метод доступа) – весьма схож с методом доступа ISAM, за исключением того, что организация VSAM не зависит от типа оборудования и поэтому не оперирует такими категориями, как дорожки и цилиндры.

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

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

Подобно индексу дорожек метода доступа ISAM, в методе доступа VSAM используется индекс управляемых интервалов, который называется «набором указателей».

Подобно тому как в методе ISAM имеется один индекс дорожек на цилиндр, так и в методе VSAM имеется один набор указателей на одну управляемую область.

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

Эта иерархия указателей носит название «набора индексов».

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

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

При поиске по методу доступа VSAM, как и по методу ISAM, последовательно сверху вниз просматриваются блоки набора индексов.

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

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

Кроме этого, внутри управляемой области некоторые управляемые интервалы остаются свободными.

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

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

При удалении записей из такого файла оставшиеся в интервале записи уплотняются к его левой границе.

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

Удаление записей может привести к тому, что управляемый интервал освободится полностью. В этом случае в элементе набора указателей, соответствующем данному интервалу, появляется метка FREE.

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

Расщепление памяти

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

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

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

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

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

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

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

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

В таком случае осуществляется расщепление управляемой области, аналогичное расщеплению управляемого интервала.

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

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

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

Метод расщепления группы записей иногда называют клеточным делением: процесс расщепления памяти в некоторой степени напоминает размножение микроорганизмов путем деления.

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

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

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

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

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

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

Набор индексов может иметь многоуровневую структуру.

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

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

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

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

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

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

2.6.7. Включение записей в *SAM-файлы

Сейчас мы ещё раз кратко рассмотрим сведения о методах включения записей в индексно-последовательные файлы.

Новые записи могут быть включены:

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

Способы включения:

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

Размещение области переполнения:

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

Методы адресации в области переполнения:

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

Свободная память:

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

Расщепление памяти:

расщепление физических блоков (управляемых интервалов);
расщепление групп блоков (управляемых областей).

2.6.8. Размещение индексов для *SAM-файлов

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

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

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

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

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

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

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

2.6.9. Метод доступа InnoDB

InnoDB – одна из выбираемых подсистем низкого уровня (метод доступа) в СУБД MySQL.

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

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

Основные достоинства InnoDB:

Скорость:

построчные блокировки (вместо блокировки целых таблиц как в MyISAM);
эффективное использование памяти;
мощные индексы.

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

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

Проверенность:

распространяется в составе MySQL с 2001 года широко используется в различных крупных проектах.

InnoDB в MySQL 5.1

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

2.6.10. Итог

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

2.7. Физическое представление древовидных и сетевых структур

2.7.1. Введение

В этой теме мы рассмотрим конкретные алгоритмы хранения сложных (древовидных и сетевых) структур данных в файлах.

2.7.2. Древовидные структуры

Усложнённый двумерный файл

Одним из самых простых способов представления древовидных структур является т.н. «усложнённый двумерный файл».

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

Рассмотрим рисунок…

Рисунок 2.7.2.1 – Усложнённый двумерный файл

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

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

У разработчика алгоритма хранения имеются три возможности.

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

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

Главный и детальный файлы

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

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

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

Рисунок 2.7.2.2 – Главный и детальный файлы

Левосписковые структуры

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

Рассмотрим на рисунке…

Рисунок 2.7.2.3 – Левосписковые структуры

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

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

Использование указателей только на порождённые записи привело бы к необходимости формировать набор указателей переменной длины.

Рассмотрим на рисунке…

Рисунок 2.7.2.4 – Указатели на исходные записи

Рисунок 2.7.2.5 – Указатели на порождённые и подобные записи

Оптимизация включения и удаления записей

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

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

Рассмотрим два таких решения.

Справочники деревьев

Справочник – это файл, в котором хранится информация о связях между записями в других файлах.

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

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

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

Битовые отображения

Битовые отображения позволяют хранить информацию о структуре дерева в предельно компактной форме, а также позволяют ОЧЕНЬ быстро производить поиск с использованием обычных логических операций над бинарными данными.

Рассмотрим пример битового отображения на рисунке…

Рисунок 2.7.2.6 – Битовое отображение

2.7.3. Сетевые структуры

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

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

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

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

Мы будем рассматривать физическое хранение структуры, представленной на рисунке…

Рисунок 2.7.3.1 – Сетевая структура

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

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

Например, можно использовать физически последовательное размещение для представления связей А->С или связей В->С, но не тех и других одновременно, если только не повторять записи С. Хотя их, всё равно, иногда приходится повторять, как, например, показано на рисунке (запись C14).

Рисунок 2.7.3.2 – Отображение сетевой структуры в файлы

2.7.4. Итог

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

3. Проектирование БД

3.1. Стандарты разработки БД

3.1.1. Вспомним несколько определений

«База Данных (БД)» – структурированный организованный набор данных, описывающих характеристики какой-либо физической или виртуальной системы.

«Базой данных» часто упрощённо или ошибочно называют Системы Управления Базами Данных (СУБД).

3.1.2. Структура БД

Организация структуры БД формируется, исходя из следующих соображений:

Адекватность описываемому объекту/системе - на уровне концептуальной и логической модели.
Удобство использования для ведения учёта и анализа данных - на уровне так называемой физической модели.

3.1.3. Стандарты разработки БД

Основные отечественные стандарты:

ГОСТ Р ИСО/МЭК 9075-93 (принят постановлением N 169 от 08.07.1993, действует с 1.07.1994, «Информационная технология. Язык баз данных SQL с расширением целостности»);
ГОСТ 7.70-96 («Описание баз данных и машиночитаемых информационных массивов. Состав и обозначение характеристик.»).

Основные международные стандарты:

ISO 6160:1979 – Языки программирования (PL/1);
ISO/IEC 6522:1992 – Информационные технологии. Языки программирования. Подмножество языка общего назначения PL/1;
ISO/IEC 9075-1:2003 – Информационные технологии. Языки баз данных. Язык структурированных запросов (SQL). Часть 1. Структура (SQL/структура);
ISO/IEC 9075-2:2003 – Информационные технологии. Языки баз данных. Язык структурированных запросов (SQL). Часть 2. Основы (SQL/основы);
ISO/IEC 9075-3:2003 – Информационные технологии. Языки баз данных. Язык структурированных запросов (SQL). Часть 3. Прикладной программный интерфейс уровня вызовов (SQL/CLI);
ISO/IEC 9075-4:2003 – Информационные технологии. Языки баз данных. Язык структурированных запросов (SQL). Часть 4. Модули постоянного хранения (SQL/PSM);
ISO/IEC 9075-9:2003 – Информационные технологии. Языки баз данных. Язык структурированных запросов (SQL). Часть 9. Управление данными от внешнего источника (SQL/MED);
ISO/IEC 9075-10:2003 – Информационные технологии. Языки баз данных. Язык структурированных запросов (SQL). Часть 10. Привязка объектного языка (SQL/OLB);
ISO/IEC 9075-11:2003 – Информационные технологии. Языки баз данных. Язык структурированных запросов (SQL). Часть 11. Схемы информации и определения (SQL/Schemata);
ISO/IEC 9075-13:2003 – Информационные технологии. Языки баз данных. Язык структурированных запросов (SQL). Часть 13. Процедуры и типы SQL с использованием языка программирования Java (SQL/JRT);
ISO/IEC 9075-14:2006 – Информационные технологии. Языки баз данных. Язык структурированных запросов (SQL). Часть 14. Спецификации, связанные с XML (SQL/XML);
ISO/IEC 10967-1:1994 – Информационные технологии. Арифметика, не зависимая от языка. Часть 1. Арифметические действия, с целыми числами и с плавающей запятой;
ISO/IEC 10967-2:2001 – Информационные технологии. Арифметика, не зависимая от языка. Часть 2. Элементарные числовые функции;
ISO/IEC 10967-3:2006 – Информационные технологии. Арифметика, не зависимая от языка. Часть 3. Арифметика комплексных целых чисел и чисел с плавающей запятой и комплексные элементарные числовые функции;
ISO/IEC 11404:2007 – Информационные технологии. Типы данных общего назначения;
ISO/IEC 13249-1:2007 – Информационные технологии. Языки базы данных. SQL-мультимедиа и пакеты прикладных программ. Часть 1. Структура;
ISO/IEC 13249-2:2003 – Информационные технологии. Языки базы данных. SQL-мультимедиа и пакеты прикладных программ. Часть 2. Полнотекстовые базы данных;
ISO/IEC 13249-3:2006 – Информационные технологии. Языки базы данных. SQL-мультимедиа и пакеты прикладных программ. Часть 3. Пространственные средства;
ISO/IEC 13249-5:2003 – Информационные технологии. Языки базы данных. SQL-мультимедиа и пакеты прикладных программ. Часть 5. Статическое изображение;
ISO/IEC 13249-6:2006 – Информационные технологии. Языки базы данных. SQL-мультимедиа и пакеты прикладных программ. Часть 6. Извлечение информации;
ISO/IEC 14977:1996 – Информационные технологии. Синтаксический метаязык. Расширенный BNF;
ISO/IEC TR 10176:2003 – Информационные технологии. Руководящие указания по подготовке стандартов, касающихся языков программирования;
ISO/TR 9547:1988 – Процессоры языков программирования. Методы испытаний. Руководящие указания по разработке и приемке;

3.1.4. Стандарты разработки БД/СУБД

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

Отечественные стандарты:

ГОСТ 34.601-90. ЕКС АС. Автоматизированные системы. Стадии создания;
ГОСТ 34.602-89. ЕКС АС. Техническое задание на создание автоматизированной системы;
РД 50-680-88. Автоматизированные системы. Основные положения;
ГОСТ 34.201-89. ЕКС АС. Виды, комплектность и обозначение документов при создании автоматизированных систем;
РД 50-34.119-90 Архитектура локальных вычислительных сетей в системах промышленной автоматизации.

Международные стандарты:

ANSI/IEEE 1012 - 1986. Планирование проверки (оценки) (verification) и подтверждения достоверности (validation) программных средств.
ANSI/IEEE 829 - 1983. Документация при тестировании программ.
ANSI/IEEE 1008 - 1986. Тестирование программных модулей и компонентов ПС.
ANSI/IEEE 983 - 1986. Руководство по планированию обеспечения качества программных средств.
ANSI/IEEE 1042 - 1987. Руководство по планированию управления конфигурацией программного обеспечения.
IEEE 1063-1987 (подтвержден 1993) - Пользовательская документация на программное обеспечение.
IEEE 1074-1995 - Процессы жизненного цикла для развития программного обеспечения.
ISO 12207:1995. Процессы жизненного цикла программных средств.
ISO 9000-3:1991. Общее руководство качеством и стандарты по обеспечению качества. Ч.3: Руководящие указания по применению ISO 9001 при разработке, поставке и обслуживании программного обеспечения.
ISO 9126:1991. ИТ. Оценка программного продукта. Характеристики качества и руководство по их применению.
ISO 9646 - 1-6: 1991. ИТ. ВОС. Методология и основы аттестационного тестирования ВОС.
ISO 12119:1994. ИТ. Требования к качеству и тестирование.
ISO 687:1983. ИТ. Управление конфигурацией программного обеспечения.
IEEE 1219-1993 - Сопровождение программных средств.
ISO 6592:1986. ОИ. Руководство по документации для вычислительных систем.
ISO 9294-1990-TO. ИТ. Руководство по управлению документированием программного обеспечения (ГОСТ Р - 1993).
ISO 9127:1987. ИТ. Пользовательская и рекламная документация на пакеты программ.

Методологии

ABB – Activity Based Budgeting – планирование бюджета на основе выполняемых функций или операционное планирование бюджета – планирование бюджета компании или инвестиционного проекта с использованием принципов, средств и методов ABC. Фактически представляет собой обратное проектирование ABC системы.

ABC – Activity Based Costing – функционально-стоимостной анализ – метод определения стоимости и других характеристик изделий и услуг на основе функций и ресурсов, задействованных в бизнес-процессах.

ABM – Activity Based Management – управление на основе ABC-информации или операционное управление – методология, описывающая средства и способы управления организацией для совершенствования бизнес-процессов и повышения прибыльности на основе информации, предоставляемой в результате ABC- анализа.

ARP – Activity Resource Planning – функциональное планирование ресурсов – метод планирования ресурсов компании на основе анализа функций, задействованных в бизнес-процессах и данных ABC-анализа.

BPR – Business Process Reengenering – реорганизация бизнес-процессов – направление деятельности, включающее «фундаментальное переосмысление и радикальное перепланирование критических бизнес-процессов с целью улучшения их эффективности в отношении затрат, качества выполнения и скорости».

CPI – Continuous Process Improvement – непрерывное совершенствование процессов – один из подходов к совершенствованию качества бизнес-процессов в рамках TQM.

CPN – Color Petri Nets – раскрашенные сети Петри – методология создания динамической модели бизнес-процесса, позволяющая проанализировать зависящие от времени характеристики выполнения процесса и распределение ресурсов, для входящих потоков различной структуры.

DFD – Data Flow Diagrams – диаграммы потоков данных – методология структурного анализа, описывающая внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных и хранилища данных к которым осуществляется доступ.

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

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

IDEF1X – Методология информационного моделирования, являющаяся составной частью SADT и основанная на концепции «сущность-связь» (entity-relationship).

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

IDEF4 – методология объектно-ориентированного проектирования сложных систем, описывающая структуру, поведение и реализацию систем в терминах класса объектов.

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

SADT – Structured Analysis and Disign Technique – технология структурного анализа и проектирования.

STD – State Transition Diagrams – диаграммы переходов состояний – методология моделирования последующего функционирования системы на основе её предыдущего и текущего функционирования.

TQM – Total Quality Management – глобальное управление качеством – направление деятельности, изучающее бизнес-процесс с целью такой их организации, которая гарантирует идеальное качество продукции.

3.1.5. SQL и его стандарты

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

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

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

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

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

В последние годы таким повсеместно принятым языком стал язык реляционных БД SQL – Structured Query Language (теперь всё чаще название языка понимается как Standard Query Language).

До появления SQL в СУБД (независимо от того, на какой модели они основывались) приходилось поддерживать по крайней мере три языка, которые обычно имели мало общего:

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

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

Следует отметить, что к достоинствам языка SQL относится наличие международных стандартов. Первый международный стандарт был принят в 1989 г., и соответствующая версия языка называется SQL-89.

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

Наиболее важными достижениями стандарта SQL-89 являются:

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

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

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

Этот стандарт существенно более полный и охватывает практически все необходимые для реализации аспекты:

манипулирование схемой БД;
управление транзакциями и сессиями (сессия – это последовательность транзакций, в пределах которой сохраняются временные отношения);
подключение к БД;
динамический SQL.

В стандарте представлены три уровня языка:

базовый;
промежуточный;
полный.

В течение нескольких лет после принятия стандарта производители СУБД, утверждавшие совместимость своих продуктов со стандартом, на самом деле в лучшем случае поддерживали промежуточный уровень языка SQL-92 (естественно, с собственными расширениями).

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

Наконец, одновременно с завершением работ по определению стандарта SQL-92 была начата разработка стандарта SQL3.

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

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

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

Часть 1 – SQL/Структура (SQL/Framework) – определяет общие требования соответствия и фундаментальные понятия SQL.
Часть 2 – SQL/Основы (SQL/Foundation) – определяет синтаксис и операции SQL.
Часть 3 – SQL/Интерфейс вызовов (SQL/Call-Level Interface) – определяет интерфейс программного взаимодействия приложений с SQL.

Часть 4 – SQL/Встроенные модули (SQL/Persistent Stored Modules) – определяет управляющие структуры, лежащие в основе SQL-программ. Часть 4 определяет и модули, содержащие SQL-программы.
Часть 5 – SQL/Языковая привязка к серверу (SQL/Host Language Bindings) – определяет возможности встраивания операторов SQL в приложения, созданные на основе стандартных языков программирования.

SQL3 позволяет использовать два минимальных уровня взаимодействия, которые может объявить СУБД:

поддержка ядра SQL (Core SQL Support);
поддержка расширенного SQL (Enhanced SQL Support).

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

И, наконец, наиболее современным на текущий момент стандартом, который до сих пор находится в разработке, является т.н. SQL-2008.

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

Прежде всего, претерпела некоторые изменения общая организация стандарта. Часть 5 (SQL/Bindings) больше не существует; соответствующие спецификации включены в часть 2. Раздел части 2, посвященный информационной схеме, выделен в отдельную часть 11. Появились две новые части - 13 и 14. Часть 13 полностью называется «SQL Routines and Types Using the Java Programming Language» («Использование подпрограмм и типов SQL в языке программирования Java»).

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

Наиболее серьёзные изменения языка SQL, специфицированные в части 2 стандарта SQL-2003, касаются следующих аспектов:

типы данных;
подпрограммы, вызываемые из SQL;
расширенные возможности оператора CREATE TABLE;
новый объект схемы – генератор последовательностей;
новые виды столбцов – идентифицирующие столбцы (identity column) и генерируемые столбцы (generated column);
новый оператор MERGE.

В SQL-2003 произошли некоторые изменения в системе типов SQL. Некоторые типы удалены, а другие добавлены.

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

3.1.6. Использование методологии IDEF1X

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

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

Методология IDEF1X – один из подходов к семантическому моделированию данных, основанный на концепции «сущность-связь» (Entity-Relationship). Это инструмент для анализа информационной структуры систем различной природы.

Информационная модель, построенная с помощью IDEF1X-методологии, отображает логическую структуру информации об объектах системы.

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

Основными объектами концептуальной модели являются сущности и связи.

Сущность (entity) – некоторый обособленный объект или событие моделируемой системы, имеющий определённый набор свойств – атрибутов (attributes).

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

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

Правила для атрибутов сущности:

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

Сущность изображается на ER-диаграмме в виде прямоугольника, в верхней части которого приводится её название; далее следует список атрибутов. Ключевые атрибуты могут быть выделены подчеркиванием или иным способом.

Стандарт IDEF1X описывает способы изображения двух типов сущностей – независимой и зависимой, и связей (relationships) – идентифицирующих (identifying) и неидентифицирующих (non-identifying).

Рисунок 3.1.6.1 – Стандарт IDEF1X

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

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

Сущность называется зависимой, если однозначная идентификация её экземпляра зависит от его связей с другими сущностями.

Сущность может обладать атрибутами, которые наследуются через связь с родительской сущностью. Последние обычно являются внешними ключами (FK, foreign keys) и служат для организации связей между сущностями.

Если внешний ключ сущности используется в качестве её первичного ключа (PK, primary key) или как часть составного первичного ключа, то сущность является зависимой от родительской сущности.

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

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

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

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

Связи даётся имя, выражаемое грамматической формой глагола. Для связи дополнительно может присутствовать указание мощности: какое количество экземпляров сущности-потомка может существовать для сущности-родителя.

Имя связи всегда формируется с точки зрения родителя, так что может быть образовано предложение, если соединить имя сущности родителя, имя связи, выражение мощности и имя сущности-потомка (например «много СТУДЕНТов - сдают – ЭКЗАМЕН»).

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

3.1.7. Пример логической и физической схемы в ErWin

Сейчас мы рассмотрим пример простенькой БД, логическая и физическая схема которой построена с использованием CASE-средства разработки БД – AllFusion ErWin Data Modeler.

Рисунок 3.1.7.1 – Логическая схема БД

Рисунок 3.1.7.2 – Физическая схема БД

3.1.8. Минимальный набор стандартных таблиц

В большинстве SQL-серверов есть т.н. «системный каталог» – набор стандартных таблиц, содержащих информацию обо всех объектах сервера и базы данных.

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

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

Поэтому, желательно создать в БД собственный системный каталог, полностью описывающий структуру базы и взаимосвязи её объектов.

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

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

Структура данных

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

Для описания структуры данных, потребуется три основных таблицы: DataTypes, Tables и Columns.

Примерное строение этих таблиц (здесь и далее - синтаксис MS SQL Server):

create table [DataTypes]

(

[Id] int not null identity primary key,

[Parent] int references [DataTypes]([Id]),

[Name] varchar(120) not null unique,

[Note] varchar(250),

[SQLType] varchar(250) not null

)

create table [Tables]

(

[Id] int not null identity primary key,

[Name] varchar(120) not null unique,

[Note] varchar(250),

[Key] int references [Columns]([Id])

)

create table [Columns]

(

[Id] int not null identity primary key,

[Table] int not null references [Tables]([Id]),

[Name] varchar(120) not null,

[Note] varchar(250),

[DataType] int not null references [DataTypes]([Id]),

[Size] int not null,

[LinkTable] int references [Tables]([Id]),

[Default] varchar(250),

[Obligatory] bit not null defaul(0),

[Unique] bit not null defaul(0)

)

Таблица DataTypes хранит названия и описания всех типов данных, используемых в базе. Она должна содержать не только основные типы, но и дополнительные: автонумеруемое поле (identity), ссылка (поле, содержащее значение ПК другой таблицы) и т.п. Поле Parent позволяет показать наследование одного типа от другого.

Таблица Tables содержит имена и описания всех таблиц базы. Key определяет поле, являющееся первичным ключом каждой таблицы.

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

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

Пользователи

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

Пользователи, входящие в одну группу, как правило, выполняют сходные действия и обладают одинаковыми правами. Для описания пользователей понадобится две таблицы: People и Users.

create table [People]

(

[Id] int not null identity primary key,

[LastName] varchar(120) not null,

[FirstName] varchar(120) not null,

[MiddleName] varchar(120) not null,

[Note] varchar(250)

)

create table [Users]

(

[Id] int not null identity primary key,

[Name] varchar(120) not null unique,

[Note] varchar(250),

[Person] int references [People]([Id])

)

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

Пользователь может включаться в несколько групп (в общем случае), поэтому понадобится ещё две таблицы: Groups и UsersInGroups.

create table [Groups]

(

[Id] int not null identity primary key,

[Name] varchar(120) not null unique,

[Note] varchar(250)

)

create table [UsersInGroups]

(

[Group] int not null references [Groups]([Id]),

[User] int not null references [Users]([Id])

constraint [UserInGroup] primary key ([Group], [User])

)

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

Журнал изменений

Часто бывает нужно организовать хранение истории изменений записей с возможностью просмотра и отката этих изменений.

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

create table [Transactions]

(

[Id] int not null identity primary key,

[Date] datetime not null default(getdate()),

[User] int not null references [User]([Id])

)

create table [Changes]

(

[Id] int not null identity primary key,

[Transaction] int not null references [Transactions]([Id]),

[Entity] int not null,

[Column] int not null references [Columns]([Id]),

[OldValue] varchar(4000)

)

Таблица Transactions хранит дату транзакции и Id пользователя, совершившего её. Таблица Changes, кроме транзакции, содержит значение ПК изменяемой записи, ссылку на изменяемое поле и прежнее значение поля, преобразованное в строку.

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

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

Перечисления

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

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

create table [Enumerations]

(

[Id] int not null identity primary key,

[Parent] int references [Enumerations]([Id]),

[Code] varchar(120) not null unique,

[Name] varchar(120) not null

)

Поле Code может являться как кодом целого набора, так и кодом значения в наборе.

Параметры

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

Например, пути к другим базам/серверам, имена административных файлов, величины процентов налогов и т.п. Для хранения значений параметров, разбитых по категориям, потребуется таблица Parameters:

create table [Parameters]

(

[Id] int not null identity primary key,

[Category] int not null references [Enumerations]([Id]),

[Name] varchar(120) not null unique,

[DataType] int not null references [DataTypes]([Id]),

[Value] varchar(4000)

)

Сообщения

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

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

create table [Messages]

(

[Id] int not null identity primary key,

[Category] int not null references [Enumerations]([Id]),

[Name] varchar(120) not null unique,

[Text] varchar(4000)

)

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

3.1.8. Итог

В завершение можно еще раз перечислить все таблицы, которые потребовались для системного каталога:

Структура данных

DataTypes – типы данных

Tables – таблицы

Columns – поля в таблицах

Пользователи

People – люди

Users – пользователи системы

Groups – группы пользователей

UsersInGroups – вхождения пользователей в группы

Журнал изменений

Transactions – транзакции

Changes – изменения, произведенные транзакциями

Перечисления

Enumerations – наборы значений

Параметры

Parameters – параметры

Сообщения

Messages – сообщения

3.2. Средства автоматизированного проектирования БД

3.2.1. Введение

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

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

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

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

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

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

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

3.2.2. CASE-технологии

CASE-технология (Computer-Aided Software/System Engineering) представляет собой совокупность методологий анализа, проектирования, разработки и сопровождения сложных систем и поддерживается комплексом взаимоувязанных средств автоматизации.

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

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

С самого начала CASE-технологии развивались с целью преодоления этих ограничений путём автоматизации процессов анализа и интеграции поддерживающих средств.

3.2.3. Достоинства CASE-технологий

Единый графический язык

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

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

Единая БД проекта

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

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

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

Интеграция средств

На основе репозитория осуществляется интеграция CASE-средств и разделение системной информации между разработчиками.

При этом возможности репозитория обеспечивают несколько уровней интеграции:

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

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

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

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

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

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

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

Генерация документации

Многая документация по проекту генерируется автоматически на базе репозитория.

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

Примечание: да, не 100% документации может быть сгенерировано автоматически. Но очень много «шаблонных, рутинных действий» по её генерации может быть автоматизировано.

Верификация проекта

CASE-технология обеспечивает автоматическую верификацию и контроль проекта на полноту и состоятельность на ранних этапах разработки, что влияет на успех разработки в целом.

По некоторым статистическим данным ошибки проектирования и кодирования составляют соответственно 2/3 и 1/3 от общего числа ошибок, а ошибки проектирования примерно в 100 раз труднее обнаружить на этапе сопровождения ПО, чем на этапе анализа требований.

Другой подход к анализу распределения ошибок показывает, что до 50% ошибок зарождается на стадии разработки требований. Ещё до 25% – на стадии проектирования. На стадию кодирования приходится около 10% ошибок.

Автоматическая генерация объектного кода

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

Сопровождение и реинжиниринг

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

3.2.4. Промежуточные выводы и определения

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

В процессе проектирования возникает необходимость создания описания, необходимого для построения ещё не существующего объекта.

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

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

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

Типичными аспектами в описаниях технических объектов являются: функциональный, конструкторский и технологический.

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

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

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

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

Типичными иерархическими уровнями функционального проектирования являются:

Функционально-логический

Функциональные и логические схемы.

Схемотехнический

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

Компонентный

Проектирование элементов и их размещение (в программных проектах – проектирование модулей, компонентов и т.п.)

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

Наиболее трудоёмкими этапами разработки ИС являются этапы анализа и проектирования, в процессе которых CASE-средства обеспечивают качество принимаемых технических решений и подготовку проектной документации.

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

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

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

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

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

Классификация по типам отражает функциональную ориентацию CASE-средств на те или иные процессы жизненного цикла ПО.

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

Помимо этого, CASE-средства можно классифицировать по следующим признакам:

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

Классификация по типам в основном совпадает с компонентным составом CASE-средств и включает следующие основные типы:

средства анализа («Upper CASE»), предназначенные для построения и анализа моделей предметной области: Design/IDEF (Meta Software), BPwin (Logic Works);
средства анализа и проектирования («Middle CASE»), поддерживающие наиболее распространённые методологии проектирования и использующиеся для создания проектных спецификаций: Vantage Team Builder (Cayenne), Designer/2000 (ORACLE), Silverrun (CSA), PRO-IV (McDonnell Douglas), CASE.Аналитик (МакроПроджект).

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

средства проектирования баз данных, обеспечивающие моделирование данных и генерацию схем баз данных (как правило, на языке SQL) для наиболее распространённых СУБД. К ним относятся: ERwin (Logic Works), S-Designor (SDP) и DataBase Designer (ORACLE).

Средства проектирования баз данных имеются также в составе CASE-средств Design/IDEF, Vantage Team Builder, Designer/2000, Silverrun и PRO-IV.

средства разработки приложений. К ним относятся: средства 4GL (Uniface (Compuware), JAM (JYACC), PowerBuilder (Sybase), Developer/2000 (ORACLE), New Era (Informix), SQL Windows (Gupta), Delphi (Borland) и др.) и генераторы кодов, входящие в состав Vantage Team Builder, PRO-IV и частично - в Silverrun;

средства реинжиниринга, обеспечивающие анализ программных кодов и схем баз данных и формирование на их основе различных моделей и проектных спецификаций. Средства анализа схем БД и формирования ERD входят в состав Vantage Team Builder, Design/IDEF, PRO-IV, Silverrun, Designer/2000, ERwin и S-Designor.

В области анализа программных кодов наибольшее распространение получили объектно-ориентированные CASE-средства, обеспечивающие реинжиниринг программ на языке С++ (Rational Rose (Rational Software), Object Team (Cayenne)).

Вспомогательные типы включают:

средства планирования и управления проектом (SE Companion, Microsoft Project и др.);
средства конфигурационного управления (PVCS (Intersolv));
средства тестирования (Quality Works (Segue Software));
средства документирования (SoDA (Rational Software)).

3.2.5. Методологии структурного моделирования

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

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

В настоящее время успешно используются такие методологии, как структурный системный анализ Гейна-Сарсона, структурный анализ и проектирование Йордана-де Марко, SADT и другие.

Диаграммы потоков данных. Нотация Йордана-де Марко. Нотация Гейна-Сарсона.

Диаграммы потоков данных (DFD – Data Flow Diagramm) являются основным средством моделирования функциональных требований проектируемой системы.

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

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

Для изображения DFD традиционно используются две различные нотации: Йордана-де Марко и Гейна-Сарсона.

Диаграммы потоков данных строятся из элементов, представленных в таблице:

Элемент	Нотация Йордона–де Марко	Нотация Гейна-Сарсона
Функция
Поток данных
Хранили-ще данных
Внешняя сущность

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

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

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

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

Назначение функции состоит в продуцировании выходных потоков из входных потоков в соответствии с действием, задаваемым именем функции.

Это имя должно содержать глагол в неопределённой форме с последующим дополнением (например, «ВЫЧИСЛИТЬ МАКСИМАЛЬНУЮ ВЫСОТУ»).

Кроме того, каждая функция должна иметь уникальный номер для ссылок на него внутри диаграммы.

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

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

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

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

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

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

Внешняя сущность представляет сущность вне контекста системы, являющуюся источником или приёмником системных данных. Её имя должно содержать существительное, (например, «СКЛАД ТОВАРОВ»).

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

Функции, хранилища и внешние сущности на DFD-диаграмме связываются дугами, представляющими потоки данных.

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

При интерпретации DFD-диаграммы используются следующие правила:

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

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

Именно эта информация является исходной на следующем этапе проектирования – построении модели «сущность-связь».

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

Рассмотрим пример…

Рисунок 3.2.5.1 – Пример схемы БД

Здесь представлена DFD-диаграмма для предприятия, строящего свою деятельность по принципу «изготовление на заказ».

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

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

Эта диаграмма представляет самый верхний уровень функциональной модели. Естественно, это весьма грубое описание предметной области.

Уточнение модели производится путём детализации необходимых функций на DFD- диаграмме следующего уровня.

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

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

3.2.6. Методология SADT (IDEF0)

Методология SADT (Structured Analisys and Design Technique) разработана Дугласом Т. Россом в 1969-73 годах.

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

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

Рисунок 3.2.6.1 – Пример схемы в нотации IDEF0

В терминах IDEF0 система представляется в виде комбинации блоков и дуг.

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

Правила интерпретации модели (см. рисунок):

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

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

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

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

Дуги могут разветвляться и соединяться. Разветвление означает множественность (идентичные копии одного объекта) или расщепление (различные части одного объекта).

Соединение означает объединение или слияние объектов.

Каждый блок IDEF0-диаграммы может быть представлен несколькими блоками, соединенными интерфейсными дугами, на диаграмме следующего уровня.

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

Число уровней не ограничивается, зато рекомендуется на одной диаграмме использовать не менее 3 и не более 8 блоков.

Рассмотрим пример…

Рисунок 3.2.6.1 – Детализация схемы в нотации IDEF0

На рисунке представлена IDEF0-модель деятельности предприятия, описанного в предыдущем примере.

Методология SADT может использоваться для моделирования широкого круга систем и определения требований и функций.

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

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

3.2.7. Методологии информационного моделирования

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

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

В 1983 году в рамках проекта военного ведомства США «Интегрированные системы информационной поддержки» (ICAM) была создана методология семантического моделирования данных IDEF1X (расширение методологии IDEF1), позволяющая логически объединять в сеть неоднородные вычислительные системы.

Методология IDEF1X – один из подходов к семантическому моделированию данных, основанный на концепции «сущность-связь».

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

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

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

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

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

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

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

Наибольшее распространение получили следующие нотации, используемые при построении ER-диаграмм: нотация Чена, нотация Мартина, нотация IDEF1X, нотация Баркера.

3.2.8. Нотация Чена

№	Элемент	Значение	№	Элемент	Значение
1		Незави-симая сущность	6		Атрибут
2		Зависимая сущность	7		Первич-ный ключ
3		Родитель-ская сущность	8		Внешний ключ
4		Связь	9		Много-значный атрибут
5		Иденти-фициру-ющая связь	10		Наследу-емый атрибут

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

Рисунок 3.2.8.1 – Пример фрагмента концептуальной схемы в нотации Чена

3.2.9. Нотация Мартина

Элемент	Значение
	Независимая сущность
	Зависимая сущность
	Родительская сущность

№	Обозначение	Кардиналь-ность	№	Обозначение	Кардиналь-ность
1		Нет	4		M,N
2		1,1	5		0,N
3		0,1	6		1,N

Рисунок 3.2.9.1 – Пример фрагмента концептуальной схемы в нотации Мартина

3.2.10. Нотация IDE1X

Элемент	Значение
	Независимая сущность
	Зависимая сущность
	Идентифицирующая связь
	Неидентифицирующая связь

Кардинальность связей:

Элемент	Значение
	1,1
	0,M
	0,1
	1,M
	N,N

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

Рисунок 3.2.10.1 – Пример сущности в нотации IDEF1X

Отношение полной категоризации (сущности-категории составляют полное множество потомков родительской сущности):

Рисунок 3.2.10.2 – Отношение полной категоризации IDEF1X

Отношение неполной категоризации (сущности-категории составляют неполное множество потомков родительской сущности):

Рисунок 3.2.10.3 – Отношение неполной категоризации IDEF1X

3.2.11. Нотация Баркера

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

Рисунок 3.2.11.1 – Схема данных в нотации Баркера

Кардинальность связей:

Элемент	Значение
	0,1
	1,1
	0,N
	1,N

Для обозначения отношения категоризации вводится элемент «дуга»

Рисунок 3.2.11.2 – Отношение категоризации в нотации Баркера

3.2.12. Язык информационного моделирования

Иногда применяется менее наглядный, но более содержательный язык концептуального моделирования (ЯКМ), в котором сущности и связи представляются предложениями вида: СУЩНОСТЬ (атрибут 1, атрибут 2 , ..., атрибут n) СВЯЗЬ [СУЩНОСТЬ S1, СУЩНОСТЬ S2, ...] (атрибут 1, атрибут 2, ..., атрибут n), где S - степень связи, а атрибуты, входящие в ключ, должны быть отмечены с помощью подчёркивания.

Рассмотрим пример (фрагмент концептуальной схемы в нотации Чена):

Рисунок 3.2.11.1 – Фрагмент концептуальной схемы в нотации Чена

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

Врач (Номер_врача, Фамилия, Имя, Отчество, Специальность)

Пациент (Регистрационный_номер, Номер койки, Фамилия, Имя, Отчество, Адрес, Дата рождения, Пол)

Лечащий_врач [Врач (1,1), Пациент (1,M)] (Номер_врача, Регистрационный_номер)

Консультант [Врач (1,M),Пациент (1,N)] (Номер_врача, Регистрационный_номер).

3.2.13. CASE-средства

Наиболее распространёнными CASE-средствами моделирования данных на текущий момент являются:

All Fusion ERWin Data Modeler
Sparx Enterprise Architect
IBM Rational Data Architect
SDP S-Designer
Oracle DataBase Designer
Vantage Team Builder
Silverrun

3.2.14. Процесс создания модели БД в ErWin

Начинаем создание модели с указания, какие уровни и для какой СУБД создавать. Уровни – выбираем сразу «Логический/физический», а в качестве СУБД или ту, с которой и будем работать, или SQL-Server (7, 2000, 2005) как «наиболее усреднённый вариант» диалекта SQL.

Рисунок 3.2.14.1 – Создание новой модели БД в ErWin

Рисунок 3.2.14.2 – Установка параметров модели БД в ErWin

Разработку начинаем с ЛОГИЧЕСКОЙ модели. Тогда ErWin САМ строит физическую (в которой, конечно, придётся делать правки, но не очень много).

Рисунок 3.2.14.3 – Выбор уровня модели БД в ErWin

Основные, инструменты, которые нам понадобятся, – инструменты создания сущностей (таблиц) (1) и связей: идентифицирующий 1-M (2), M-M (3), неидентифицирующих 1-M (4).

Рисунок 3.2.14.4 – Основные инструменты создания модели БД в ErWin

Создаём сущность (таблицу)…

Рисунок 3.2.14.5 – Создание сущности в ErWin

Именуем её…

Рисунок 3.2.14.6 – Именование сущности в ErWin

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

Рисунок 3.2.14.7 – Переход к формированию списка атрибутов сущности в ErWin

Создаём новый атрибут…

Рисунок 3.2.14.8 – Создание атрибута сущности в ErWin

Указываем его домен («обобщённый» тип данных) и имя…

Рисунок 3.2.14.9 – Указание типа атрибута сущности в ErWin

На закладке «General» можно указать, входит ли этот атрибут в состав первичного ключа.

Рисунок 3.2.14.10 – Указание свойств атрибута сущности в ErWin

На закладке «Datatype» можно указать конкретный тип данных атрибута.

Рисунок 3.2.14.11 – Указание явного типа атрибута сущности в ErWin

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

Рисунок 3.2.14.12 – Логическая модель БД в ErWin без связей

Теперь проводим связи ОТ РОДИТЕЛЬСКОЙ СУЩНОСТИ К ДОЧЕРНЕЙ!

Рисунок 3.2.14.13 – Установка связей между сущностями в ErWin

Обратите внимание, что связи M-M оставлять в таком виде НЕЛЬЗЯ! Их нужно преобразовывать в две связи 1-M с промежуточной таблицей.

Рисунок 3.2.14.14 – Установка связей М-М между сущностями в ErWin

Для этого в ErWin есть специальный пункт в контекстном меню связи.

Рисунок 3.2.14.15 – Преобразование связей М-М между сущностями в ErWin

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

Рисунок 3.2.14.16 – Дополнительные поля в связи М-М между сущностями

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

Рисунок 3.2.14.17 – Переключение на физический уровень моделирования БД в ErWin

Здесь уже многое готово, но есть недочёты…

Рисунок 3.2.14.18 – Исходный вид физической модели БД в ErWin

Подправляем типы данных – и всё, модель БД готова!

Рисунок 3.2.14.19 – Конечный вид физической модели БД в ErWin

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

Рисунок 3.2.14.20 – Инструменты прямого и обратного проектирования модели БД в ErWin

Если вы хотите экспортировать модель в MySQL (который не поддерживается ErWin’ом), это можно сделать «обходным путём»: создать SQL-скрипт для генерации БД в MS-SQL, немного подправить его и выполнить в MySQL.

Рисунок 3.2.14.21 – Инструменты прямого и обратного проектирования модели БД в ErWin в меню

В общем случае никаких опций менять не надо, достаточно просто нажать «Preview».

Рисунок 3.2.14.22 – Генерация кода для формирования БД

И вот – готовый набор SQL-запросов…

Рисунок 3.2.14.22 – Код для формирования БД

3.2.15. Процесс создания модели БД в Sparx EA

Создаём новый проект…

Рисунок 3.2.15.1 – Создание нового проекта в Sparx EA

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

Рисунок 3.2.15.2 – Выбор компонентов проекта в Sparx EA

В «шаблонной» схеме уже есть две таблицы. Можно редактировать их (и добавлять новые), а можно их удалить и начать всё «с нуля».

Рисунок 3.2.15.3 – Удаление шаблонной части схемы в Sparx EA

Добавляем сущность (таблицу)…

Рисунок 3.2.15.4 – Добавление сущности в Sparx EA

Указываем имя таблицы и вид СУБД…

Рисунок 3.2.15.5 – Указание параметров сущности в Sparx EA

В контекстном меню таблицы выбираем «Attributes»…

Рисунок 3.2.15.6 – Переход к созданию атрибутов сущности в Sparx EA

Указываем все необходимые свойства атрибута и нажимаем «Save»…

Рисунок 3.2.15.7 – Создание атрибутов сущности в Sparx EA

После добавления всех атрибутов таблица «Students» примет вот такой вид…

Рисунок 3.2.15.8 – Сущность в Sparx EA

После создания всех таблиц получаем такую схему…

Рисунок 3.2.15.9 – Схема БД в Sparx EA без связей

Для установки связи между таблицами используем инструмент «Association»…

Рисунок 3.2.15.10 – Установка связи между сущностями в Sparx EA

Теперь связь нужно «настроить»…

Рисунок 3.2.15.11 – Установка параметров связи между сущностями в Sparx EA

Долгая и мучительная работа с этим контекстным меню покажет, что мы кое-что забыли. Возвращаемся к редактированию таблицы «Students» и вручную добавляем атрибут gr_id (integer). Теперь указываем его в качестве поля внешнего ключа, ещё немного играем с настройками связи (тип линии, кардинальность и т.п.)

Примечание: в Sparx EA в отличие от ErWin связи нужно проводить ОТ ДОЧЕРНЕЙ СУЩНОСТИ К РОДИТЕЛЬСКОЙ.

В итоге мы получим вот такое…

Рисунок 3.2.15.12 – Связь между сущностями в Sparx EA

Продолжая в том же духе, создаём (вручную!) промежуточную таблицу для связи M-M между «Students» и «Subjects», устанавливаем связи и т.д.

Наконец, когда схема готова (обратите внимание, Sparx EA не делает различия между логическим и физическим уровнем схемы), её можно экспортировать в SQL-скрипт, пригодный для генерации реальной БД в, например, MySQL.

Выполняем такие действия…

Рисунок 3.2.15.13 – Генерация схемы БД в Sparx EA

Рисунок 3.2.15.14 – Экспорт схемы БД в Sparx EA в файл

И, наконец, получаем готовый аккуратный скрипт в диалекте SQL нужной нам СУБД (в данном случае – MySQL).

Вот первые несколько строк скрипта для генерации БД, создание модели которой мы рассматривали…

И, наконец, получаем готовый аккуратный скрипт в диалекте SQL нужной нам СУБД (в данном случае – MySQL).

Вот первые несколько строк скрипта для генерации БД, создание модели которой мы рассматривали…

DROP TABLE IF EXISTS Students;

DROP TABLE IF EXISTS Subjects;

DROP TABLE IF EXISTS Groups;

CREATE TABLE Students

( st_id INTEGER NOT NULL,

st_fio VARCHAR(200) NOT NULL,

st_birthdate INTEGER,

st_address VARCHAR(50),

st_isbudget BIT NOT NULL DEFAULT 1,

gr_id INTEGER,

PRIMARY KEY (st_id),

KEY (gr_id));

CREATE TABLE Subjects

( sb_id INTEGER NOT NULL,

sb_name VARCHAR(250),

PRIMARY KEY (sb_id));

CREATE TABLE Groups

( gr_id INTEGER NOT NULL,

gr_code VARCHAR(10),

PRIMARY KEY (gr_id));

ALTER TABLE Students ADD CONSTRAINT FK_Students_Groups

FOREIGN KEY (gr_id) REFERENCES Groups (gr_id);

3.2.16. Итог

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

Теперь нам предстоит ознакомиться с особенностями проектирования БД на логическом (инфологическом) и физическом (даталогическом) уровнях.

3.3. Особенности проектирования БД на логическом и физическом уровнях

3.3.1. Введение

Терминология в СУБД, да и сам термин «база данных» (и «банк данных») частично заимствован из финансовой деятельности.

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

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

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

Рассмотрим рисунок…

Рисунок 3.3.1.1 – Модель БД

3.3.2. Модель БД

Уровень внешних моделей – самый верхний уровень, где каждая модель имеет своё «видение» данных.

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

Например, система распределения работ использует сведения о квалификации сотрудника, но её не интересуют сведения об окладе, домашнем адресе и телефоне сотрудника, и наоборот, именно эти сведения используют подсистему отдела кадров.

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

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

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

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

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

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

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

3.3.4. Банки данных

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

По назначению банки данных бывают:

информационно-поисковые;
специализированные по отдельным областям науки и техники;
банки данных АСУ для организационно-экономической информации;
банки данных для систем автоматизации научных исследований и производственных испытаний;
банки данных для систем автоматизированного проектирования.

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

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

По языку общения пользователя с БД различают системы с базовым языком (открытые системы) и с собственным языком (закрытые системы).

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

3.3.5. Модели данных

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

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

Примеры данных: Пупкин Василий Васильевич, $30, красный.

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

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

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

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

Рисунок 3.3.5.1 – Модели данных

В соответствии с рассмотренной ранее трёхуровневой архитектурой мы сталкиваемся с понятием модели данных по отношению к каждому уровню.

Действительно, каждая модель данных оперирует категориями, касающимися организации тех или иных «объектов модели» на том или ином (своём!) уровне.

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

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

Кроме трёх рассмотренных уровней абстракции при проектировании БД существует ещё один уровень, предшествующий им.

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

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

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

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

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

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

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

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

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

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

Такое представление уровней данных – не единственное. Существуют и другие варианты многоуровневого представления данных.

Так, в соответствии с рекомендациями ANSI/X3/SPARC, а также CODASYL (Conference on Data Systems Languages), как правило, выделяется три уровня представления данных:

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

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

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

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

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

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

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

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

Внешний уровень – это, как правило, словесное описание входных и выходных сообщений, а также данных, которые целесообразно сохранять в БД.

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

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

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

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

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

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

Логический (концептуальный) уровень построен с учётом специфики и особенностей конкретной СУБД.

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

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

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

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

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

От параметров физической модели зависят такие характеристики функционирования БД как объём занимаемой памяти и время отклика на команду.

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

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

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

Рисунок 3.3.6.1 – Схема взаимосвязи уровней представления данных в БД

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

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

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

Каждый этап проектирования рассматривается как определённая последовательность итеративных процедур, в результате которых формируется определённая модель БД.

3.3.7. Проектирование БД: внешний уровень

Внешний уровень – это подготовительный этап инфологического проектирования.

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

Существуют два подхода к проектированию баз данных на внешнем уровне:

«от предметной области»;
«от запроса».

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

Иногда этот подход называют еще объектным или непроцессным.

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

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

При таком подходе БД проектируется для выполнения текущих задач управления без учёта возможности расширение системы и возникновение новых задач управления.

Преимущество подхода «от предметной области» – его объективность, системность и стойкость информационной модели, возможность реализации большого количества прикладных программ и запросов, в том числе незапланированных при создании БД.

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

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

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

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

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

Поэтому при проектировании БД целесообразно совместно использовать эти два подхода.

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

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

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

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

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

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

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

Изучение и анализ оперативных первичных документов.

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

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

Изучение нормативно-справочных документов.

На третьем шаге изучают и анализируют всю нормативно-справочную документацию. К такой документации относятся различные классификаторы, сметы, договоры, нормативы, законодательные акты, плановая документация и т.п.

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

Следует различать и учитывать технологии создания и ведения файлов «условно-постоянной информации» и файлов «оперативной информации».

Изучение процессов преобразования входных данных в выходные.

Прежде всего изучаются все выходные данные, которые выдаются на печать или на экран и сохраняются в виде выходных массивов во внешней памяти.

Это необходимо для того, чтобы определить, какие из атрибутов входных сообщений нужно сохранять в БД для получения выходных сообщений.

Кроме того, на этом этапе определяются те показатели, которые получаются во время решения задачи в результате выполнения определённых вычислений.

По каждому показателю следует определить алгоритм его формирования и убедиться в том, что этот показатель можно получить на основе атрибутов оперативной и нормативно-справочной информации, которые были определены на втором и третьем шагах.

Если некоторых данных не хватает для полного выполнения расчётов, необходимо возвратиться назад, провести дополнительное исследование и определить, где и каким способом можно получить атрибуты, которых не хватает.

Кроме того, нужно определиться, какие из расчётных показателей целесообразно сохранять в БД.

Показатели, полученные расчётным путем, как правило, в БД не сохраняются. Исключением являются случаи, когда расчётный показатель нужно использовать для решения других задач или для данной задачи, но в следующие календарные периоды.

При проведении проектных работ на внешнем уровне надо учитывать то, что для выполнения определённых функций в БД необходимо сохранять дополнительные данные, которые не отображены в документах.

Обобщённая схема процесса изучения документов и данных при проектировании на внешнем уровне изображена на рисунке.

Рисунок 3.3.7.1 – Обобщённая схема процесса изучения документов и данных при проектировании на внешнем уровне

Такое изучение необходимо провести по каждой функциональной задаче или их комплексу, которые будут решаться с помощью БД.

Результатом проектирования на внешнем уровне будет перечень атрибутов (реквизитов) оперативной и условно-постоянной информации, которые необходимо хранить в БД, с указанием источников их получения и формы представления.

Однако этот перечень не исключает возможности существования в нём избыточности, дублирования, несогласованности и других недостатков.

Поэтому на этом процесс не заканчивается, а осуществляется переход к этапу инфологического проектирования.

3.3.8. Проектирование БД: инфологический уровень

Основными составными элементами инфологической модели являются сущности (информационные объекты), связи между ними и их атрибуты (свойства).

Сущность – любой различимый объект (объект, который мы можем отличить от другого), информацию о котором необходимо хранить в базе данных.

Сущностями могут быть люди, места, самолеты, рейсы, вкус, цвет и т.д.

Необходимо различать такие понятия, как «тип сущности» и «экземпляр сущности». Понятие «тип сущности» относится к набору однородных личностей, предметов, событий или идей, выступающих как целое.

Экземпляр сущности относится к конкретной вещи в наборе. Например, типом сущности может быть ГОРОД, а экземпляром – Минск, Москва, Киев и т.д.

Атрибут – поименованная характеристика сущности.

Его наименование должно быть уникальным для конкретного типа сущности, но может быть одинаковым для различного типа сущностей (например, ЦВЕТ может быть определён для многих сущностей: СОБАКА, АВТОМОБИЛЬ, ДЫМ и т.д.).

Атрибуты используются для определения того, какая информация должна быть собрана о сущности.

Примерами атрибутов для сущности АВТОМОБИЛЬ являются ТИП, МАРКА, НОМЕРНОЙ ЗНАК, ЦВЕТ и т.д.

Здесь также существует различие между типом и экземпляром. Тип атрибута ЦВЕТ имеет много экземпляров или значений: красный, синий, зелёный и т.д., однако, каждому экземпляру сущности присваивается только одно значение атрибута.

Абсолютное различие между типами сущностей и атрибутами отсутствует. Атрибут является таковым только в связи с типом сущности. В другом контексте атрибут может выступать как самостоятельная сущность. Например, для автомобильного завода цвет – это только атрибут продукта производства, а для лакокрасочной фабрики цвет – тип сущности.

Ключ – минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый экземпляр сущности. Минимальность означает, что исключение из набора любого атрибута не позволяет идентифицировать сущность по оставшимся.

Связь – ассоциирование двух или более сущностей.

Если бы назначением базы данных было только хранение отдельных, не связанных между собой данных, то её структура могла бы быть очень простой.

Однако одно из основных требований к организации базы данных – это обеспечение возможности отыскания одних сущностей по значениям других, для чего необходимо установить между ними определённые связи.

А так как в реальных базах данных нередко содержатся сотни или даже тысячи сущностей, то теоретически между ними может быть установлено очень много связей.

Наличие такого множества связей и определяет сложность инфологических моделей.

Требования и подходы к инфологическому проектированию.

Целью инфологического проектирования является создание структурированной информационной модели ПО, для которой будет разрабатываться БД. При проектировании на инфологическом уровне создается информационно-логическая модель (ИЛМ), которая должна отвечать следующим требованиям:

обеспечение наиболее естественных для человека способов сбора и представления той информации, которую предполагается хранить в создаваемой базе данных;
корректность схемы БД;

простота и удобство использования на следующих этапах проектирования, то есть ИЛМ может легко отображаться на модели БД, которые поддерживаются известными СУБД (сетевые, иерархические, реляционные и др.);
ИЛМ должна быть описана языком, понятным проектировщикам БД, программистам, администратору и будущим пользователям.

Суть инфологического моделирования, таким образом, состоит в выделении сущностей, которые подлежат хранению в БД, а также в определении атрибутов объектов и взаимосвязей между ними.

Существует два подхода к инфологическому проектированию: анализ объектов и синтез атрибутов.

Подход, который базируется на анализе объектов, называется нисходящим, а на синтезе атрибутов – восходящим.

3.3.9. Проектирование БД: даталогический уровень

Проектирование БД на даталогическом уровне связано с использованием конкретных языков управления СУБД. В контексте реляционной модели мы будем говорить об SQL и его диалектах.

Различия в диалектах SQL (различиях в реализации SQL в той или иной СУБД) обусловлены некоторыми фактами:

Попытками производителей упростить реализацию стандарта в своей СУБД.
Попытками производителей – наоборот – расширить стандарт в своей СУБД.
Попытками сохранить совместимость с предыдущими версиями СУБД.
И т.д. Причин много.

3.3.10. Уровни SQL

Язык SQL, соответствующий последним стандартам, – это очень богатый и сложный язык, все возможности которого трудно сразу осознать и тем более понять.

Поэтому приходится разбивать язык на уровни или слои, такие, что каждый уровень языка включает все конструкции, входящие в более низкие уровни.

В стандарте определяется несколько способов разбиения языка на уровни.

В одной из классификаций язык разбивается на «базовый» («entry»), «промежуточный» («intermediate») и «полный» (full) уровни.

Эта классификация ориентирована, прежде всего, на производителей СУБД, в которых поддерживается SQL.

Реализация базового уровня языка является обязательным условием хотя бы какого-то соответствия стандарту.

Реализация промежуточного уровня желательна, и обычно именно такой уровень языка поддерживается ведущими компаниями-производителями SQL-ориентированных СУБД.

Наконец, полный уровень языка является целью, к достижению которой следует стремиться.

В данной классификации критерием отнесения той или иной возможности языка к некоторому уровню является оцениваемая создателями стандарта SQL техническая сложность реализации этой возможности.

Для понимания языка SQL это разбиение на уровни несущественно.

Другая классификация показана на рисунке.

Среди всех конструкций языка SQL можно выделить такие конструкции, которые можно было использовать при «прямом» («direct») взаимодействии конечного пользователя с СУБД (например, в интерактивном режиме). В некотором смысле этот уровень также является базовым, поскольку соответствующие средства языка в наибольшей степени отражают его ориентированность на работу с множествами.

На следующем уровне, уровне «встраиваемого» («embedded») SQL, язык расширяется конструкциями, позволяющими использовать возможности прямого SQL в программах, написанных на традиционных языках программирования.

Наконец, на уровне «динамического» («dynamic») SQL во встраиваемый SQL добавляются конструкции, позволяющие приложениям обращаться к СУБД с конструкциями прямого SQL, которые динамически образуются во время выполнения программы.

Рисунок 3.3.10.1 – Уровни SQL

Возникает вопрос: а куда относятся такие явления как PL/SQL, T-SQL и им подобное? Это – функциональные расширения языка SQL. В общем случае можно относить их к уровню динамического SQL. Путаницы добавляет то, что каждое из этих функциональных расширений базируется на диалекте «своей» СУБД.

Например:

MS SQL - T-SQL
Oracle - PL/SQL
PostgreSQL - PLpg/SQL
Sybase ASA – WatcomSQL

Отметим также важный момент: функциональные расширения SQL не являются «диалектами друг друга» и, как правило, совершенно несовместимы друг с другом.

3.3.11. Проектирование БД: физический уровень

Физический уровень мы рассматривали с вами подробно в предыдущем разделе курса.

Сейчас мы только кратко рассмотрим существующие методы хранения данных на физическом уровне:

BDAM – basic direct access method, метод доступа с прямым чтением и записью;

BSAM – basic sequential access method, базовый последовательный метод доступа;

QSAM – queued sequential access method, очерёдно-последовательный метод доступа;

BPAM – basic partitioned access method, базовый раздельный метод доступа;

ISAM – indexed sequential access method, индексно-последовательный метод доступа;

VSAM – virtual sequential (storage) access method, виртуально-последовательный метод доступа (метод доступа к виртуальным хранилищам);

OAM – object access method, метод доступа к объектам (используется для обработки больших объёмов бинарных данных).

Подавляющее большинство рассмотренных методов было представлено когда-то компанией IBM.

Выбор конкретного метода хранения данных зависит от конкретных задач, решаемых разработчиками БД.

3.3.12. Итог

Итак, мы рассмотрели основные идеи проектирования баз данных на различных уровнях.

В следующей теме мы подробнее рассмотрим процесс прямого проектирования баз данных, а также обратного проектирования (анализа) уже готовых БД с целью их модификации.

3.4. Прямое и обратное проектирование БД

3.4.1. Введение

О начальных этапах проектирования БД мы поговорили в предыдущей теме.

Сейчас представим, что некоторые начальные данные у нас уже есть, и нам необходимо разработать инфологическую модель БД.

Здесь нам предстоит столкнуться с таким понятием как «нормализация».

Итак…

3.4.2. Понятие нормализации

Нормализация отношений информационной модели предметной области является механизмом создания логической модели реляционной БД.

С математической точки зрения задача построения как информационной модели предметной области, так и логической модели реляционной БД является результатом решения следующих комбинаторных задач:

группировки атрибутов в отношении предметной области;
распределения атрибутов по отношениям базы данных.

Такие задачи имеют решения, допускающие большое число вариантов, и приводят к проблеме выбора рационального варианта из множества альтернативных вариантов схем отношений.

Выбор наиболее рационального варианта обусловлен соблюдением различного рода соглашений и требований.

3.4.3. Требования нормализации

Перечень наиболее важных требований:

1. Первичные ключи отношений должны быть минимальными (требование минимальности первичных ключей).

2. Число отношений базы данных должно по возможности давать наименьшую избыточность данных (требование надёжности данных).

3. Число отношений базы данных не должно приводить к потере производительности системы (требование производительности системы).

4. Данные не должны быть противоречивыми, т.е. при выполнении операций включения, удаления и обновления данных их потенциальная противоречивость должна быть сведена к минимуму (требования непротиворечивости данных).

5. Схема отношений базы данных должна быть устойчивой, способной адаптироваться к изменениям при её расширении дополнительными атрибутами (требование гибкости структуры базы данных).

6. Разброс времени реакции на различные запросы к базе данных не должен быть большим (требование производительности базы данных).

7. Данные должны правильно отражать состояние предметной области базы данных в каждый конкретный момент времени (требование актуальности данных).

Создание БД, одновременно удовлетворяющей всем вышеназванным требованиям, представляет собой сложную оптимизационную задачу, которая подчас не имеет однозначного решения.

Многие из требований находятся в противоречии друг к другу. Так, например, требование производительности находится в противоречии к требованию гибкости.

Требование минимизировать число отношений в базе данных находится в противоречии к требованию надёжности данных.

В процессе эксплуатации реляционной БД происходит модификация данных: в отношениях добавляются или удаляются кортежи, в результате опредёленных событий изменяются значения некоторых атрибутов кортежей и т.п.

После манипулирования данными значения некоторых атрибутов могут дублироваться, порождая избыточность данных, значения некоторых атрибутов могут удаляться, исчезая из базы данных, хотя потребность в этих значениях остаётся, некоторые значения атрибутов не могут быть добавлены, поскольку их значения неизвестны, т.е. данные в базе данных с течением времени становятся несогласованными и противоречивыми.

Потенциальная противоречивость (или аномалии) при выполнении операций манипулирования данными в базе данных зависит как от типа функциональной зависимости между атрибутами, так и от группировки этих атрибутов по отношениям.

3.4.4. Примеры аномалий

Рассмотрим типичные примеры аномалий, возникающих при выполнении операций включения, удаления и модификации данных.

Пусть у нас есть отношение:

ПОСТАВКИ (Поставщик, Адрес, Товар, Количество, Стоимость)

Обновление. Если Поставщик поставляет несколько видов товара, то значение атрибута Адрес повторяется для каждого кортежа и, следовательно, при изменении адреса поставщика необходимо изменить значение этого атрибута во всех этих кортежах. Иначе будет нарушена целостность данных.

Удаление. Если Поставщик прекращает поставку товаров на некоторое время, то кортежи со всеми его поставками удаляются. При этом происходит потеря реквизитов поставщика – Адреса и Наименования.

Вставка. Если договор на поставку уже заключён, а поставка ещё не произведена, то невозможно включить в рассматриваемое отношение значения атрибутов Поставщик и Адрес, поскольку нет сведений о поставках (проблема интерпретации нуль-значений).

Подобные аномалии в данных лишь отчасти дают ответ на вопрос, почему логическая структура реляционной БД может быть неудовлетворительной.

Некоторые проблемы избыточности данных можно разрешить, заменив, например, исходное отношение ПОСТАВКИ на два новых отношения:

отношение

ПОСТАВЩИК (Поставщик, Адрес)

и отношение

ПОСТАВКА (Поставщик, Товар, Количество, Стоимость)

Однако в целом остаётся ряд вопросов, на которые теория реляционных БД не даёт удовлетворительных ответов:

Как найти хорошую замену для плохой схемы отношений?
Как определить, является ли выбранная замена выгодной?
Как создать схему, обеспечивающую наилучшую производительность?

Например, для того чтобы выполнить запрос, использующий данные из двух таблиц, необходимо построить соединение этих таблиц, которое является дорогостоящей операцией с точки зрения числа выполняемых операций ввода/вывода.

3.4.5. Нормальные формы

Теория функциональных зависимостей (ФЗ) позволяет установить определённые требования к схемам отношений в реляционной БД.

Эти требования формулируются в терминах свойств отношений и называются нормальными формами схем отношений.

Каждая нормальная форма отношений связана с определённым классом ФЗ, которые представлены в отношениях.

Одним из очевидных способов устранения потенциальной противоречивости данных в отношениях логической модели реляционной БД является их разбиение на два или более отношения, в каждом из которых присутствует только одна ФЗ.

Это возможно, поскольку теория ФЗ утверждает, что существует минимальное покрытие множества ФЗ базы данных, т.е. минимальный набор ФЗ, из которых можно вывести все остальные.

Каждой ФЗ из минимального покрытия можно отвести по самостоятельному отношению.

Однако:

во-первых, для заданного множества ФЗ может существовать несколько минимальных покрытий (выбор среди возможных альтернатив);
во-вторых, для практики важно иметь наглядный способ построения минимального покрытия.

Процесс устранения потенциальной противоречивости и избыточности данных в отношениях реляционной БД называется нормализацией исходных схем отношений.

Нормализация отношений заключается в выполнении декомпозиции или синтеза отношений и назначении ключей отношений в соответствии с определёнными правилами, гарантирующими целостность отношений БД.

Требование минимальности числа отношений, т.е. построения минимального покрытия ФЗ обычно является опциональным.

Но! На минимальном покрытии, как правило, не может быть достигнута высокая производительность обработки запросов.

Почему нормализация схем отношений важна для проектирования реляционных БД?

Многочисленные испытания показали, что нормализация схем отношений даёт наилучший результат при моделировании предметной области с использованием реляционной модели данных.

При этом не вводится большого числа ограничений, не искажаются данные.

Таким образом, нормализация отношений является методом удаления из отношения ФЗ, которые приводят к аномалиям модификации данных.

Иными словами, нормализация отношений помогает проектировать реляционную БД, которая не содержит избыточных данных и гарантирует целостность данных.

Язык нормальных форм констатирует наличие или отсутствие определённых ФЗ в отношениях реляционной БД и указывает на уровень избыточности и надёжности данных в нормализованных отношениях.

Методы нормализации отношений основываются на применении понятия ФЗ и способов манипулирования ими.

При выполнении реляционных операций над отношениями в БД каждый тип ФЗ может порождать опредёленный тип аномалий, который будет нарушать целостность данных в БД.

Нормальная форма (НФ) представляет собой ограничение на схему базы данных, вводимое с целью устранения определённых нежелательных свойств при выполнении реляционных операций.

Различают несколько типов нормальных форм. Каждая из них ограничивает присутствие определённого класса ФЗ в отношении и устраняет присущие этому классу ФЗ аномалии в выполнении реляционных операций.

Примечание. Глагол «ограничивает» в терминологии баз данных означает набор процедур, направленных на достижение определённых свойств объекта путем сужения области его действия.

3.4.6. Зависимости

Функциональная зависимость

Если даны два атрибута X и Y некоторого отношения, то Y функционально зависит от X, если в любой момент времени каждому значению X соответствует ровно одно значение Y.

Функциональная зависимость обозначается X à Y.

Отметим, что X и Y могут представлять собой не только единичные атрибуты, но и группы, составленные из нескольких атрибутов одного отношения.

Пример:

Номер паспорта à Фамилия

ID_сотрудника à СтажРаботыВФирме

Избыточная функциональная зависимость

Избыточная функциональная зависимость – зависимость, заключающая в себе такую информацию, которая может быть получена на основе других зависимостей, имеющихся в базе данных.

Пример:

ID_сотрудника à ПаспортныеДанные à ФИО

Полная функциональная зависимость

Функциональная зависимость X à Y является ПОЛНОЙ, если Y не зависит функционально от любого подмножества X.

Пример:

{МестоОтправки, МестоНазначения, ВидГруза, ВесГруза} à СтоимостьДоставки

Частичная функциональная зависимость

Функциональная зависимость X à Y является ЧАСТИЧНОЙ, если Y зависит функционально от некоторого подмножества X.

Пример:

{НомерКузова, НомерГосрегистрации} à Владелец

Транзитивная функциональная зависимость

Функциональная зависимость X à Y является транзитивной, если существуют зависимости X à Z и Z à Y, но отсутствует прямая зависимость X à Y.

Пример:

ID_сотрудника à ID_Офиса à ТелефонОфиса

Многозначная зависимость

Многозначная зависимость X àà Y существует в том и только в том случае, если множество значений Y, соответствующее паре значений X и Z, зависит только от X и не зависит от Z (то есть если для каждого значения атрибута X существует множество соответствующих значения атрибута Y).

В общем случае в отношении R (A,B,C) существует многозначная зависимость R.A àà R.B в том и только в том случае, когда существует многозначная зависимость R.A àR.C.

Пример:

Отношение: R(Проект, Сотрудник, Задание)

Многозначные зависимости:

Проект àà Сотрудник

Проект àà Задание

3.4.6. Первая нормальная форма

Отношение находится в первой нормальной форме (1НФ), если все атрибуты отношения являются атомарными, т.е. не имеют компонентов.

Иными словами, домен атрибута должен состоять из неделимых значений и не может включать в себя множество значений из более элементарных доменов.

В большинстве случаев выполнить это требование достаточно просто. Каждый простой атрибут должен иметь свою колонку в таблице. Однако это часто приводит к дублированию данных в отношении.

На рисунке слева представлено ненормализованное (до 1НФ) отношение, справа – нормализованное.


Рисунок 3.4.6.1 – Ненормализованное (до 1НФ) и нормализованное отношения

Вопрос об атомарности атрибутов решается на основе семантики данных, то есть их смыслового значения.

Атрибут атомарен, если его значение теряет смысл при любом разбиении на части или переупорядочивании.

И наоборот, если какой-либо способ разбиения на части не лишает атрибут смысла, то атрибут неатомарен.

Одно и то же значение может быть атомарным или неатомарным в зависимости от смысла этого значения.

Например, значение «4286» является

атомарным, если его смысл — «пин-код кредитной карты» (при разбиении на части или переупорядочивании смысл теряется);
неатомарным, если его смысл — «чётные цифры» (при разбиении на части или переупорядочивании смысл не теряется).

Хорошим способом принятия решения о необходимости разбиения атрибута на части является вопрос: «будут ли части атрибута использоваться по отдельности?» Если да, то атрибут следует разделить (но так, чтобы сохранились осмысленные части атрибута).

3.4.7. Вторая нормальная форма

Отношение находится во второй нормальной форме (2НФ), если она находится в 1НФ, и при этом любой её атрибут, не входящий в состав первичного ключа, функционально полно зависит от первичного ключа.

Функционально полная зависимость означает, что атрибут функционально зависит от всего первичного составного ключа, но при этом не находится в функциональной зависимости от какой-либо из входящих в него атрибутов (частей).

Или другими словами: в 2НФ нет неключевых атрибутов, зависящих от части составного ключа (+ выполняются условия 1НФ).

Пусть наличие компьютера у сотрудника по правилам фирмы зависит от должности (начальник – есть компьютер, подчинённый – нет компьютера). Тогда приведённое на рисунке отношение НЕ находится во 2НФ, т.к. допускает указание наличия компьютера у подчинённого.

Рисунок 3.4.7.1 – Отношение, НЕ находящееся во 2НФ

Чтобы привести это отношение ко 2НФ, нужно разбить его на два отдельных:

Рисунок 3.4.7.2 – Новая схема БД, соответствующая 2НФ

Таким образом, процедура приведения отношения ко 2НФ состоит в выполнении двух действий:

пересмотру состава ключа отношения;
созданию подчинённого отношения, в которое будут вынесены все те неключевые атрибуты исходного отношения, которые не зависят от ключа исходного отношения.

3.4.8. Третья нормальная форма

Отношение находится в третьей нормальной форме (3НФ), если она находится во второй нормальной форме (2НФ) и при этом любой её неключевой атрибут нетранзитивно зависит от первичного ключа.

Таким образом, отношение находится в 3NF тогда и только тогда, когда оно находится во 2НФ и отсутствуют транзитивные зависимости неключевых атрибутов от ключевых.

Вспомним: транзитивной зависимостью неключевых атрибутов от ключевых называется следующая: A à B и B à C, где A – набор ключевых атрибутов (ключ), B и С – различные множества неключевых атрибутов.

При решении практических задач в большинстве случаев третья нормальная форма является достаточной. Процесс проектирования реляционной базы данных, как правило, заканчивается приведением к 3НФ.

Более того: после нескольких лет работы с БД почти невозможно «заставить своё сознание» создать модель БД, не находящейся в 3НФ.

Пусть в некоторой фирме на отдел приходится один телефон. Тогда хранить информацию о телефоне в таблице с сотрудниками – бессмысленно, т.к. она будет дублироваться.

Т.о. приведённое ниже отношение НЕ находится в 3НФ.

Рисунок 3.4.8.1 – Отношение, НЕ находящееся в 3НФ

Разбив это отношение на два отдельных, мы получим 3НФ:

Рисунок 3.4.8.2 – Схема БД, соответствующая 3НФ

3.4.9. Нормальная форма Бойса-Кодда

Отношение находится в нормальной форме Бойса-Кодда (НФБК), если оно находится в 3НФ, и в нём отсутствуют зависимости ключевых атрибутов (или их частей) от неключевых атрибутов.

НФБК можно определить и так:

Детерминант – любой атрибут, от которого функционально-полно зависит некоторый другой атрибут.

Отношение находится в НФБК, если оно находится в 3НФ и каждый детерминант является возможным ключом.

Рассмотрим следующее отношение:

Рисунок 3.4.9.1 – Отношение, НЕ находящееся в НФБК

Курсовые проекты ведут несколько преподавателей по различным дисциплинам, и каждый студент закреплён за одним из них.

Студент выполняет только один проект, а одну и ту же тему проекта могут выполнять несколько студентов, но у разных преподавателей.

Возможные ключи:

Преподаватель, Тема;

Предмет, Тема.

Функциональные зависимости:

Преподаватель, Тема à Студент (от ключа)

Предмет, Тема à Студент (от ключа)

Студент à Тема.

Это отношение находится в 3НФ, так как в нём отсутствуют частичные и транзитивные зависимости неключевых атрибутов от ключа.

Однако имеется зависимость части составного ключа Тема от неключевого атрибута Студент, что порождает следующие аномалии:

существует проблема контроля непротиворечивости данных, так как изменение преподавателя по дисциплине требует просмотра всего отношения с целью поиска и изменения кортежей, содержащих данные о преподавателе этой дисциплины;
данные о студенте и его проекте не могут быть занесены в БД до тех пор, пока не назначен руководитель проекта;
и наоборот, если необходимо удалить руководителя, то будут удалены данные о руководимом им студенте.

Устранение этих аномалий достигается устранением функциональной зависимости части составного ключа от неключевого атрибута (Студент à Тема).

После преобразования мы получим такой набор отношений:

Рисунок 3.4.9.2 – Схема БД, соответствующая НФБК

Вопрос: в чём здесь будет проблема?

Ответ: теперь каждый преподаватель может вести курсовые строго по одному предмету. Если так и надо – OK. Если нет – нужно дальше перерабатывать модель БД.

Однако, есть ещё проблема:

Допустим, у нас есть отношение, в котором хранится информация о бронировании теннисных кортов. По правилам фирмы, каждому корту сопоставлен строго свой тариф.

Приведённое на рисунке отношение находится в НФБК, но позволяет допустить ошибку: вписать не тот тариф не тому корту.

Рисунок 3.4.9.3 – Отношение в НФБК, допускающее внесение ошибочных данных

Здесь по бизнес-правилам есть только один первичный ключ – {Корт, Сеанс, Тариф}.

Разобьём отношение на два так, чтобы исключить возможность возникновения только что описанной ошибки.

Рисунок 3.4.9.4 – Схема БД, не допускающая внесения ошибочных данных

Обратите внимание!

В первой таблице у нас первичный ключ: Корт + Сеанс (т.к. по здравому смыслу эта комбинация полей должна иметь уникальные значения).

Во второй таблице у нас первичный ключ: Корт + Тариф (т.к. по правилам фирмы эта комбинация полей должна иметь уникальные значения).

Но! При установлении связей осуществляется миграция ВСЕГО первичного ключа из родительской таблицы в дочернюю.

Т.о. мы получим исходное отношение + потеряем автоматическую реализацию вышеназванных правил фирмы и здравого смысла.

«Выкрутиться» можно так: связать отношения ТОЛЬКО по ключу Корт, ввести в таблицу Сеанс суррогатный первичный ключ, а выполнение правил «навесить» на триггеры или хранимые процедуры.

3.4.10. Четвёртая нормальная форма

Отношение находится в 4НФ, если оно находится в 3НФ или НФБК и не содержит многозначных зависимостей.

Многозначная зависимость не является функциональной и существует в том случае, когда из факта, что в таблице содержится «строка со значением некоторого поля, равным X», следует, что в таблице обязательно существует «строка со значением некоторого поля, равным Y».

Т.о., отношение находится в 4НФ, если все его зависимости являются функциональными.

Предположим, что рестораны производят разные виды пиццы, а службы доставки ресторанов работают только в определённых районах города.

Составной ключ таблицы такого отношения включает три поля:

{Ресторан, ВидПиццы, РайонДоставки}.

Такая таблица не соответствует 4НФ, так как существует многозначная зависимость:

{Ресторан} →→ {Вид пиццы}

{Ресторан} →→ {Район доставки}

То есть, например, при добавлении нового вида пиццы придётся внести по одной новой записи для каждого района доставки.

Возможна логическая аномалия, при которой определённому виду пиццы будут соответствовать лишь некоторые районы доставки из обслуживаемых рестораном районов.

Для предотвращения аномалии нужно разбить многозначную зависимость – разместить независимые факты в разных таблицах.

Переработаем такое отношение…

Рисунок 3.4.10.1 – Отношение, НЕ находящееся в 4НФ

… в такую схему:

Рисунок 3.4.10.2 – Схема БД, соответствующая 4НФ

К слову, здесь мы видим ещё один способ решения ситуации, возникшей при нормализации до НФБК: когда у таблиц все поля являются частями составных первичных ключей.

Мы можем создать отдельную промежуточную таблицу.

3.4.11. Пятая нормальная форма

Отношение находится в 5НФ, если оно находится в 4НФ и любая многозначная зависимость соединения в нём является тривиальной.

Пятая нормальная форма в большей степени является теоретическим исследованием и практически не применяется при реальном проектировании баз данных.

Это связано со сложностью определения самого наличия зависимостей соединения, поскольку утверждение о наличии такой зависимости должно быть сделано для всех возможных состояний БД.

Зависимость соединения

Отношение R (X, Y, ... ,Z) удовлетворяет зависимости соединения * (X, Y, ... ,Z) в том и только в том случае, когда R восстанавливается без потерь путём соединения своих проекций на X, Y, Z.

Иными словами: если отношение R декомпозировать на набор отношений, поработать с такой БД, а потом вдруг восстановить отношение R из имеющегося набора отношений, то результат должен быть таким же, как если бы мы работали с исходным отношением R.

Очень редко таблица, находящаяся в 4НФ, не соответствует 5НФ.

Это те ситуации, в которых реальные правила, ограничивающие допустимые комбинации атрибутов, никак не выражены в структуре таблицы (например, правила определённого бизнеса).

В таком случае, если таблица не приведена к 5НФ, бремя обеспечения логической целостности данных отчасти переляжет на приложение, отвечающее за добавление, удаление и изменение данных таблицы.

В этом случае существует риск возникновения аномалий данных. Пятая нормальная форма исключает возникновение таких аномалий.

Предположим, что продавец может торговать продукцией нескольких фирм, ассортимент у фирм различен, причем продавец может предлагать только часть товаров конкретной фирмы.

Отношение {Продавец, Фирма, Вид товара} соответствует 4НФ, однако не отражает ограничения, связанного с ассортиментом продукции фирм. Может возникнуть кортеж, в котором фирме будет соответствовать вид товара, который она не выпускает.

В данном случае (для приведения к 5НФ) отношение должно быть разбито на три: {Продавец, Фирма}, {Фирма, Вид товара}, {Продавец, Вид товара}.

3.4.12. Доменно-ключевая нормальная форма

Отношение находится в ДКНФ, если оно не имеет аномалий модификации.

Другими словами, что бы ни менялось — ничего не потеряется, если соблюдены все ограничения относительно ключей и доменов.

На примере эти правила действуют примерно так: нельзя просто удалить категорию из таблицы категорий, если с этой категорией связаны, например, продукты из таблицы продуктов. Прежде чем удалять категорию, необходимо выполнить предварительные действия в таблице продуктов (например, поле отвечающее за ID категории этого товара нужно сделать NULL).

3.4.13. Ещё раз, кратко, все нормальные формы

1НФ - все атрибуты отношения атомарны;

2НФ - отношение находится в 1НФ и не содержит частичных ФЗ;

3НФ - отношение находится во 2НФ и не содержит транзитивных ФЗ от ключа;

НФБК - отношение находится в 3НФ и не содержит ФЗ ключей от неключевых атрибутов;

4НФ, применяется при наличии более чем одной многозначной ФЗ - отношение находится в НФБК или 3НФ и не содержит многозначных ФЗ;

5НФ - отношение находится в 4НФ и удовлетворяет зависимости по соединению относительно своих проекций.

ДКНФ - отношение не имеет аномалий модификации.

3.4.14. Ещё раз, кратко, в ErWin

Шаг 0. Ужасное отношение.

Рисунок 3.4.14.1 – Ужасное отношение

Шаг 1. 1НФ: делаем атрибуты атомарными

Рисунок 3.4.14.2 – Отношение в 1НФ

Шаг 2. 2НФ: убираем частичные ФЗ

Рисунок 3.4.14.3 – Отношения во 2НФ

Шаг 3. 3НФ: убираем транзитивные ФЗ

Рисунок 3.4.14.4 – Отношения в 3НФ

Шаг 4. Приводим к удобной для реальной работы форме…

Рисунок 3.4.14.5 – Итоговый вид схемы БД

3.4.15. Обратное проектирование БД

Об обратном проектировании БД мы скажем всего два слова: оно сводится к построению схемы БД на основе существующей БД. Это можно сделать вручную или (лучше) с помощью специальных инструментальных средств.

После построения такой схемы с ней можно (иногда – нужно) выполнить все только что рассмотренные операции.

Когда схема «приведена в норму», её можно дорабатывать, т.е. заниматься прямым проектированием БД.

3.4.16. Итог

На этом мы заканчиваем рассмотрение теоретических основ работы с базами данных.

У нас осталась только одна тема в этом разделе – посвящённая качеству БД.

3.5. Повышение качества БД на стадии проектирования

3.5.1. Памятки разработчикам БД

Поскольку в первую очередь качество результата разработки любого проекта зависит от процесса разработки, рассмотрим несколько памяток, которые помогут этот процесс улучшить…

(На основе текста «10 заповедей разработчика» by Виноградов С.А.)

Здесь перечислены общие рекомендации по избежанию наиболее распространённых ошибок, совершаемых начинающими разработчиками БД.

Нарушение перечисленных рекомендаций, как правило, приводит к резкому увеличению времени разработки, росту количества ошибок, неоправданным сложностям в сопровождении и в конечном итоге, к провалу всего проекта.

Памятка 1. Стандартные имена или «не перегружайте никому мозги»

Одной сущности должно соответствовать всегда одно имя – это правило, в котором не может быть исключений.

Написание имён должно быть максимально стандартизировано. Регистр букв также важен, даже если средство разработки его не учитывает (зато регистр хорошо учитывается людьми).

Лучше всего использовать слова английского языка без сокращений. Большинство средства разработки не поддерживает идентификаторы, состоящие из букв других языков – и правильно делает.

Немногочисленные стандартные аббревиатуры и сокращения должны быть описаны в специальном словаре.

Пример: если типу объекта соответствует имя ObjectType, то в обращении не должно быть имён вида ObjType, Objecttype или OBJ_TYPE.

Использование стандартных имён позволяет сэкономить много времени, необходимого на поиск нужного имени, а также избежать возможных недоразумений.

Памятка 2. Отсутствие загадочных значений или «что это такое?»

Часто неопытные разработчики используют некоторые поля для хранения значений вроде 0, 1, 2 и т.п.

Эти поля не ссылаются на другую таблицу, зато используются где-нибудь в выражениях: if State = 2 then ... else ... Всё ведь понятно, не правда ли?

Немногим лучше выглядит и такой вариант: <U>, <T>, <S>. Кто угадает, что здесь означает <U>?

Правильным решением будет создание отдельной таблицы (Id, Code, Name, Note), содержащей набор возможных значений для этого поля.

В поле же надо хранить идентификатор (Id) значения из этой таблицы, при необходимости используя код и наименование значения.

Отсутствие загадочных значений освобождает память разработчика от ненужного мусора и уменьшает вероятность возникновения ошибок и непонимания.

Памятка 3. Поменьше ограничений или «не создавайте граблей на пустом месте»

Таблицы и поля стоит создавать с достаточно большим «запасом прочности», чтобы не было потом мучительно больно.

Если в задании написано, что какой-нибудь код содержит 17 символов, совсем необязательно понимать это буквально и объявлять поле как char(17).

Ведь завтра требования могут измениться, и уже понадобится 22 символа или больше. Гораздо лучше выглядит varchar(120), а места оно занимает не больше.

Когда создаётся таблица с предполагаемым числом записей не больше нескольких тысяч, вполне разумным кажется использование smallint (2-хбайтовое целое) поля в качестве первичного ключа.

А что же будет, если количество записей всё-таки превысит 32 тысячи? Придется менять первичный ключ в этой таблице и все внешние ключи, ссылающиеся на неё. Этого можно было бы избежать, сразу сделав первичный ключ размером в 4 байта.

Кажется, что всегда можно легко произвести любые необходимые изменения в структуре базы данных, однако это далеко не так. База может находиться в круглосуточной работе, в репликации, может быть уже заполненной многогигабайтными данными и т.п. И экономия на байтах здесь не уместна.

Отсутствие мелочных ограничений позволяет разработчику не думать о них и создавать более устойчивые и гибкие структуры.

Памятка 4. Одинаковые ключи или «надо быть проще»

В качестве первичных ключей для всех таблиц сущностей лучше всего использовать суррогатные ключи достаточно большого размера (4-16 байт).

При этом, все такие ключи должны быть одного типа. Благодаря этому, многие проблемы уходят и никогда не возвращаются.

Так как ключ суррогатный, то отпадает необходимость поиска и использования естественного ключа (часто – составного).

Из-за большого размера ключа не возникает ситуация его переполнения. Наличие у всех сущностей идентификатора одного типа позволяет организовать стандартную работу с этими сущностями.

Единственной проблемой может стать наличие двусторонней репликации между базами данных. Но это легко решается использованием глобального идентификатора в качестве ключа либо разделением диапазонов выделенных для ключей в разных БД.

Одинаковые ключи дают возможность работать с разными сущностями одинаковыми методами, часто используя один и тот же код.

Памятка 5. Независимость данных или «надо быть гибче»

Нормализация и ещё раз нормализация – вот залог жизнеспособности любой базы данных.

Как учат классики, все отдельные сущности должны быть выделены в отдельные таблицы. При этом связь с ними осуществляется по первичному ключу.

Одинаковые сущности, наоборот, сводятся в одну таблицу.

Зависимости между разными сущностями должны быть минимальны.

Из-за несовершенства SQL (и особенно его реализаций), полностью нормализованная БД может оказаться плохо приспособленной к получению сложных запросов. Поэтому, в исключительных случаях, допускается некоторое дублирование информации для ускорения выборок.

Независимость отдельных сущностей может упростить проект и добавить ему гибкости.

Памятка 6. Неповторяющийся код или «долой Copy&Paste!»

Казалось бы, тривиальное правило, гласящее, что повторяющийся код надо выносить в отдельные функции, знает даже самый неграмотный программист.

Однако в случае с SQL всё не так просто. Дело в том, что SQL изначально не предназначен для создания функций, процедур, триггеров и, соответственно, не предполагает для них никакого стандарта.

Поэтому у всех SQL-серверов есть свои собственные расширения для написания бизнес-логики. Эти расширения не совместимы друг с другом, а их уровень варьируется от достаточно высокого до совершенно убогого (лишь бы было).

Иногда даже опытные разработчики, впервые столкнувшись с неадекватными SQL-расширениями, впадают в какой-то ступор и забывают все свои навыки, пытаясь использовать навязанные им приемы работы.

При этом, часто пишут кучу однообразных триггеров и процедур, выполняющих одинаковые действия для разных таблиц. Тем не менее, правило повторного использования кода никто ещё не отменял, и обычно его везде можно применять, хотя и не всегда очевидным образом (например, передавая имя таблицы в качестве параметра).

Повторное использование улучшает качество кода и рекомендуется к применению везде, даже если средство разработки этого не поощряет.

Памятка 7. Обработка ошибок или «Invalid programmer is detected. Abort, Remove?»

Такое же стандартное правило, как и предыдущее – если хочешь, чтобы программа делала то, что нужно, необходимо проверять результат выполнения каждой функции (и каждого SQL-оператора).

В клиентском приложении должны везде проверяться коды ошибок вызываемых функций. При возникновении ошибки, её стоит записать в лог-файл, а пользователю должно быть показано уже обработанное внятное сообщение на человеческом языке.

То есть вместо «Network link failure #7244» надо вывести «Произошло отключение от сервера, дальнейшая работа невозможна».

Если в приложении всё более-менее понятно, то при написании процедур на SQL-сервере разработчики, видимо, надеются, что сервер сам прекратит выполнение процедуры при возникновении ошибки.

После каждого SQL-оператора обязательно должен проверяться и обрабатываться код последней ошибки.

Правильность работы программы не может быть обеспечена без тотальной обработки ошибок.

Памятка 8. Короткие транзакции или «скажи блокировкам – НЕТ!»

Большинство SQL-серверов используют технологию блокировок при любой модификации данных.

То есть, данные, изменённые в транзакции одним из пользователей, недоступны для других пользователей до завершения этой транзакции.

Совсем избежать блокировок нельзя, однако можно уменьшить продолжительность транзакций.

Для этого перед выполнением транзакции для неё должны быть уже подготовлены все необходимые данные. Внутри транзакции не должно быть никаких обращений к внешним устройствам (файлам, сети и т.п.) – только к базе данных.

Ситуация, когда внутри транзакции происходит диалог с пользователем, тем более недопустима.

Короткие транзакции дают возможность большему числу пользователей одновременно работать с базой данных, не конфликтуя друг с другом.

Памятка 9. Наличие метаданных или «кому нужна база без головы?»

Метаданные описывают структуру базы данных и взаимосвязи её объектов.

При некоторых манипуляциях с базой данных может потребоваться информация о том, какие сущности хранятся в этой базе, в каких таблицах и полях, как они связаны друг с другом.

Частично эту информацию можно получить из системного каталога SQL-сервера. Но системный каталог предназначен скорее не для разработчика, а для внутреннего использования самим сервером, поэтому найти там что-либо весьма проблематично.

При этом, его структура может меняться даже в разных версиях одного сервера, не говоря уже об отсутствии какой-либо совместимости с другими SQL-серверами.

Даже довольно неполные метаданные имеют широкую область применения. Но чаще всего они используются для упрощения собственной работы программистов, вплоть до автоматической генерации приложения и объектов БД.

Наличие метаданных даёт полную информацию о базе данных, облегчая разработчикам решение многих задач.

Памятка 10. Хранение истории или «кто владеет прошлым – тот владеет будущим»

Большинство объектов, хранящихся в базе данных, могут меняться с течением времени.

К сожалению, почти все современные СУБД не хранят историю изменений и не позволяют получить состояние объектов на определённую дату. Об этом должен позаботиться разработчик базы данных.

Только база данных, которая хранит всю историю изменений всех своих объектов, может претендовать на полноту и завершённость.

Иначе простейший запрос, вроде «Дайте список объектов в том виде, в котором они были на 01.05.2007 г» так и останется без ответа.

База данных, хранящая изменяемые объекты, должна содержать полную историю всех их изменений.

3.5.2. Показатели качества БД

Ниже будут приведены и рассмотрены показатели качества БД на основе:

ГОСТ 20886-85 – Организация данных в системах обработки данных.
ГОСТ 28195-99 – Оценка качества программных средств. Общие положения.
ГОСТ ИСО/МЭК 9126-99 – Оценка программной продукции. Характеристики качества и руководства по их применению.

Номенклатура показателей качества и метрик БД ИС

Наименование характеристики	Наименование подхарактеристики	Метрика
		Признак	Метод	Оценка
1	2	3	4	5
1 Показатели функциональной пригодности БД ИС
1.1 Полнота реализации	1.1.1 Полнота концептуальной модели	1.1.1.1 Степень соответствия состава объектов БД и взаимосвязей между ними информационным потребностям пользователя.	экспертн.	0-1
		1.1.1.2 Соответствие категориям пользователей	экспертн.	0-1
	1.1.2 Прослеживаемость	Коэффициент прослеживаемости	расчетный	Кpr=Nre/Nse,~0-1 где: Nre-число элементов (объектов, атрибутов) реализованных в БД ИС; Nse-число элементов БД ИС определенных на этапе анализа предметной области
1.2 Корректность	Корректность логической структуры БД ИС	Степень отображения в БД ИС элементов логической структуры, определенных в спецификации проекта	расчетный	Кkr=Nre/Nsp,~0-1 где: Nre-число элементов (объектов, атрибутов) реализованных в БД ИС; Nsp-число элементов БД ИС определенных в спецификации проекта
1.3 Способность БД ИС в реконструктиризации	Возможность изменения	1.3.1 Возможность изменения структуры БД.	экспертн.	0-1
		1.3.2 Возможность изменения структуры БД ИС	экспертн.	0-1
2 Показатели надежности БД ИС.
2.1 Работоспособность	Восстанавливаемость	2.1.1 Степень децентрализованного размещения БД ИС на внешних носителях.	экспертн.	0-1
		2.1.2 Оценка по среднему времени восстановления	расчетный	О = О~0-1 где: Твд – допустимое время восстановления готовности; Тв= среднее время восстановления; Тi – время восстановления после i-го отказа; N – число восстановлений
2.2 Безопасность	2.2.1 Целостность данных	Исследование способов сохранения целостности.	экспертн.	0-1
	2.2.2 Защищенность данных	Наличие средств установления уровней доступа для отдельных пользователей и задач.	экспертн.	0-1
	2.2.3 Согласованность	Наличие средств блокировки данных	экспертн.	0-1
3 Показатели удобства использования БД ИС
3.1 Легкость освоения	3.1.1 Документированность	3.1.1.1 Наличие документации на БД ИС в соответствии с ГОСТ	расчетный	D=Ngf/Nf,~ 0-1, где: Nf- число требуемых документов для оценки качества БД ИС в соответствии с ГОСТ ; Ngf-число представленных документов
		3.1.1.2 Отсутствие ошибок в документации	экспертн.	0-1
		3.1.1.3 Удобства использования документации на БД ИС	экспертн.	0-1
	3.1.2 Обучаемость	3.1.2.1 Трудоемкость освоения БД ИС пользователем.	экспертн.	0-1
		3.1.2.2 Наличие средств обучения при эксплуатации БД ИС	экспертн.	0-1
3.2 Удобство эксплуатации (простота)	3.2.1 Управляемость	Степень влияния логической структуры БД на сложность ее ведения.	экспертн.	0-1
	3.2.2 Коммуникативность	Степень влияния логической структуры БД ИС на сложность формирования запросов	экспертн.	0-1
4 Показатели эффективности БД ИС
4.1 Временная эффективность	4.1.1 Скорость обработки	4.1.1.1 Время реализации	расчетный	R= R~0-1 где: Те – время начала ответа; Tb – время конца ввода запроса; Tmax – максимально допустимое время реакции
		4.1.1.2 Оборотное время	расчетный	W= W~0-1 где: Тf – время получения; Tb – время конца ввода запроса; Tmax – максимально допустимое оборотное время
		4.1.1.3 Время на генерацию отчета	расчетный	G= G~0-1, где: То – время конца формирования документа; Tb – время конца ввода запроса; Tmax – максимально допустимое время на генерацию отчета
	4.1.2 Производительность	4.1.2.1 Пропускная способность	расчетный	P=Nt/(Nmax*T), где: Nt – количество выполняемых транзакций; Nmax – необходимое количество транзакций; Т – длина интервала времени выполнения транзакции
		4.1.2.2 Интегральный показатель производительности	расчетный	, где: Wi – относительная частота появления запросов i-го типа; Ti – среднее время обслуживания запроса i-го типа; N – количество типов запросов
		4.1.2.3 Информационная производительность	расчетный	Ip=I/T, где:- среднее количество выходной информации; Рl – вероятность запроса l-го информационного элемента; L – общее число информационных элементов; , где: Тl – время доступа к записи с l-м информационным элементом
4.2 Ресурсоемкость	Занятость ресурсов	Используемость внешней памяти	расчетный	Rv=Vs/Vmax, где: Vs – текущий объем внешней памяти; Vmax – максимально отведенный под БД ИС объем внешней памяти
4.3 Эффективность транзакций	4.3.1 Качество транзакций	4.3.1.1 Степень загруженности запроса пользователя	расчетный	, где: m – число массивов БД; Ni – число обрабатываемых элементов в i-том массиве; М – общее число элементов БД ИС
		4.3.1.2 Степень функциональной сложности запроса пользователя	экспертн.	0-1
		4.3.1.3 Относительное число транзакций, использующих группы данных монопольно	расчетный	Q = 1-Npm/Np, где: Npm – число транзакций, использующих группы данных монопольно; Np – общее число транзакций
		4.3.1.4 Степень функциональной специализации транзакций	расчетный	Sf=Ntf/Nt, где: Ntf – число функционально специализированных транзакций; Nt – общее число транзакций
5 Показатели сопровождаемости БД ИС
5.1 Структурность	5.1.1 Структурная сложность	5.1.1.1 Доступность вершины графа БД ИС	расчетный	D=, где: А(Мi) - доступность i-той вершины, смежной с определяемой вершиной; С(Мi) – общее число вершин, достижимых из определяемой вершины
		5.1.1.2 Сложность уровня графа БД ИС	расчетный	Su=E-T, где: Е – число ребер между точкой вызова и i-м уровнем; Т – число вершин между самым верхним и i-м уровнем
		5.1.1.3 Ясность уровня графа БД ИС	расчетный	U=1-T/E.
		5.1.1.4 Сложность иерархии уровней графа БД ИС	расчетный	Si=Тобщ/N, где: Тобщ – общее число вершин графа; N – максимальное число уровней
		5.1.1.5 Структурная сложность графа БД ИС	расчетный	С=Еобщ/Тобщ, где: Еобщ – общее число ребер графа
		5.1.1.6 Достижимость графа БД ИС	расчетный	, где: М – число вершин в графе; Npi – число маршрутов, пересекающих i-тую вершину
		5.1.1.7 Средняя достижимость графа БД ИС	расчетный	Dср – D/M, где: D – достижимость графа БД; М – общее число вершин графа
		5.1.1.8 Длина максимального маршрута графа БД ИС	расчетный	Lmax=max(Li), i=1, N, где: Li – длина i-того маршрута; N – число маршрутов графа
		5.1.1.9 Длина минимального маршрута графа	расчетный	Lmin=min (Li), i=1, N
		5.1.1.10 Средняя длина маршрута графа БД ИС	расчетный	.
		5.1.1.11 Цикломатическое число графа БД ИС	расчетный	Cg=E-N+2*P, где: Е – число ребер графа; N – число вершин графа; P – число связанных компонентов графа
5.2 Простота конструкции	5.2.1 Показатели Холстеда для языка обработки данных (ЯОД)	5.2.1.1 Размер словаря	расчетный	Rs=N1+N2, где: N1 – количество операторов различных типов, встречающихся в данной реализации; N2 - количество операндов различных типов, встретившихся в данной реализации
		5.2.1.2 Наблюдаемая длина реализации	расчетный	N=N3+N4, где: N3 – количество операторов, встречающихся в данной реализации; N4 – количество операндов, встречающихся в данной реализации
		5.2.1.3 Вычисленная длина реализации	расчетный	DL = N1log2N1 + N2log2N2
		5.2.1.4 Объем операторов определения данных на ЯОД	расчетный	VD = N*log2Rs
		5.2.1.5 Уровень модуля операторов данных на ЯОД	расчетный	UD=(2N2)/(N1N3)
		5.2.1.6 Сложность модуля операторов определения данных на ЯОД	расчетный	SD=VD/UD
5.3 Наглядность	5.3.1 Комментируемость схемы БД ИС	Коэффициент комментируемости модулей ЯОД	расчетный	К=N/Rя, где: N – число комментариев в модуле; Rя – число операторов в модуле
	5.3.2 Оформление ЯОД	Мнемоническая совместимость элементов логической схемы БД ИС и соответствующих им объектов предметной области	экспертн.	0-1
6 Показатели адаптированности БД ИС
6.1 Гибкость	Гибкость структуры данных	6.1.1 Отсутствие синонимов среди атрибутов БД ИС	экспертн.	0-1
		6.1.2 Отсутствие омонимов среди атрибутов БД ИС	экспертн.	0-1
		6.1.3 Избыточность БД ИС	экспертн.	0-1
		6.1.4 Степень нормализации отношений БД ИС	экспертн.	0-1
6.2 Мобильность	6.2.1 Способность к взаимодействию	Возможность использования БД ИС с другими СУБД	экспертн.	0-1
	6.2.2 Совместимость	6.2.2.1 Совместимость типов данных	расчетный	Fs=Nc/Na, где: Nc – число совместимых типов данных; Na – общее число типов данных
		6.2.2.2 Совместимость форматов данных	расчетный	Fs=Nfc/Nfa, где: Nfc – число совместимых форматов данных; Nfa – общее число форматов данных
		6.2.2.3 Совместимость по числу записей в БД ИС	экспертн.	0-1

Основные характеристики качества БД ИС и соответствующие им свойства

Наименование характеристики	Характеризуемое свойство характеристики
1. Показатели функциональной пригодности БД ИС	Набор атрибутов, определяющих состав и свойства БД ИС с точки зрения удовлетворения исходных требований пользователей
1.1 Полнота реализации	Степень удовлетворения информационных потребностей пользователя для выбранной предметной области
1.2 Корректность	Степень соответствия объектов предметной области и их характеристик, определенных в спецификациях проекта, объектам, реализованным в БД ИС
1.3 Способность к реструктуризации	Способность БД ИС к изменению логической структуры
2. Показатели надежности БД ИС	Способность БД ИС поддерживать свое состояние при определенных условиях за заданный интервал времени
2.1 Работоспособность	Способность БД ИС к восстановлению после возникновения отклонений, вызванных аппаратными и программными сбоями
2.2 Безопасность	Наличие средств, позволяющих предотвратить: запоминание некорректных данных в БД ИС; доступ к данным лиц, не имеющих на это права; несанкционированное раскрытие данных
3. Показатели удобства использования БД ИС	Характеризуют свойства БД ИС по ее освоению, применению и эксплуатации с минимальными трудозатратами, с учетом характера решаемых задач и квалификации обслуживающего персонала
3.1 Легкость освоения	Предоставление документации и БД ИС в виде, способствующем пониманию логики функционирования системы БД ИС в целом и ее частей
3.2 Удобство эксплуатации (простота)	Степень независимости эксплуатационных свойств БД ИС от ее логической структуры
4 Показатели эффективности БД ИС	Степень удовлетворения потребности пользователя в обработке данных с учетом используемых ресурсов
4.1 Временная эффективность	Свойства БД ИС обеспечить выполнение транзакций за заданные интервалы времени
4.2 Ресурсоемкость	Минимально необходимые вычислительные ресурсы для эксплуатации БД ИС
4.3 Эффективность транзакций	Степень эффективности реализации транзакций на существующей структуре БД ИС
5. Показатели сопровождаемости БД ИС	Характеризуют технологические аспекты, обеспечивающие простоту устранения ошибок в БД, документации и поддержке БД ИС в актуальном состоянии
5.1 Структурность	Организация взаимосвязанных частей БД ИС в единое целое с использованием логических структур
5.2 Простота конструкции	Определяет простоту использования языка определения данных
5.3 Наглядность	Наличие и представление в наиболее легко воспринимаемом виде исходных модулей операторов определения логической структуры БД ИС и транзакций
6 Показатели адаптированности БД ИС	Характеризует адаптируемость БД ИС к новым функциональным требованиям, возникающим в следствии изменения области применения или других условий функционирования
6.1 Гибкость	Свойство БД ИС, направленное на отделение несходных данных друг от друга и устранение семантической избыточности с целью обеспечения большей степени независимости данных друг от друга и обрабатывающих их программ
6.2 Мобильность	Свойство БД ИС выполнять свои функции при изменении внешней среды и условий функционирования, а также простоту сопряжения с уже существующими системами

3.5.3. Итог

Итак, с теоретическими основами работы с БД – всё. Впереди – только практика: язык SQL и его применение для решения конкретных задач.

ПРАКТИЧЕСКИЙ РАЗДЕЛ

Контрольные работы

Контрольная работа № 1

Общие теоретические сведения

Главы Учебного пособия, которые необходимо изучить перед выполнением контрольной работы: 2.4.1 – 2.4.14, 2.4.26 – 2.4.28, 2.5 целиком.

Размещаемые записи идентифицируются с помощью ключа — поля фиксированной длины, располагаемого в каждой записи в одной и той же позиции. Ключ д.б. уникальным.

Хеширование — один из методов, позволяющих по первичному ключу записи получить ее физический адрес.

Ключ записи преобразуется в квазислучайное число, которое используется для определения местоположения записи. Число может указывать на адрес по которому расположена запись или на область в которой расположена группа записей. Область, в которой расположена группа записей называется участком записей или пакетом записей.

При первоначальной загрузке, адрес, по которому д.б. размещена запись определяется следующим образом:

– Ключ записи преобразуется в квазислучайное число от 0 до N, где N — количество пакетов записей;

– Полученное число преобразуется в физический адрес пакета;

– Если в пакете есть свободное место, то запись располагается в нем;

– Если нет, размещается в области переполнения.

Факторами, влияющими на эффективность размещения являются:

– Размер пакета;

– Плотность заполнения (отношение количества записей в пакете к максимальной вместимости пакета);

– Алгоритм преобразования ключа в адрес;

– Организация области переполнения.

Алгоритм преобразования ключа в физический адрес пакета выполняется в 3 этапа:

1. Ключ преобразуется в цифровое представление;

2. Цифровое представление ключа преобразуется в совокупность произвольно-распределенных чисел по возможности равномерно в диапазоне допустимых адресов. Ключ преобразуется в адрес;

3. Адрес умножается на константу для размещения адресов в основной памяти, т.е. фактическое масштабирование адреса.

АЛГОРИТМЫ

1. Метод деления: ключ делится на простое число (или число не имеющее малых делителей) близкое по значению к числу пакетов N. Остаток от деления — относительный адрес пакета.

2. Метод средних квадратов: ключ возводится в квадрат, выбираются центральные цифры. Умножаются на константу.

3. Метод сдвига разрядов: числовое значение ключа делится на две части, младшая часть складывается со старшей. Описанный процесс продолжается до тех пор, пока количество цифр результата не окажется равным количеству цифр числа пакетов N. Результат — относительный адрес пакета.

4. Метод складывания: число разбивается на 3 части; центральная содержит столько же цифр, сколько цифр в числе пакетов N, первая и третья заворачиваются и складываются.

5. Метод преобразования системы счисления: преобразуется основание системы счисления. Число представляется в новой системе счисления. Последние цифры числа — относительный адрес пакета.

6. Метод анализа отдельных разрядов ключа: из числа вычеркиваются те разряды, которые имеют распределение сильно отличающееся от равномерного.

ОРГАНИЗАЦИЯ ОБЛАСТИ ПЕРЕПОЛНЕНИЯ

Цепочки участков переполнения

Для связи основой области памяти с областью переполнения используются цепочки адресов. Т.е. пакет в основной области хранит адрес пакета (записи) в области переполнения.

Метод распределенной области переполнения

Пакеты переполнения размещены через определенные интервалы среди первичных пакетов. Если первичный пакет переполнен, направленная в него запись направляется в ближайший пакет переполнения, следующий за данным первичным пакетом. Достоинства — пакеты переполнения располагаются в непосредственной близости к первичным пакетам — отпадает необходимость в частом перемещении головок чтения-записи дискового устройства.

Алгоритмы перемешивания (хеширования) осуществляют преобразование ключа к номеру первичного пакета. Однако алгоритм, преобразующий номер первичного пакета в его машинный адрес, должен учитывать наличие пакетов переполнения между первичными пакетами.

Если каждый 10-й пакет — пакет переполнения, то адрес текущего N-го пакета записей будет определяться по формуле:

Адрес пакета = B0 + B(N+[N/9]) , где

B0 — адрес первого байта;

B — размер пакета в байтах;

N — номер пакета, полученный на выходе алгоритма хеширования

Метод открытой адресации (Петерсона)

Происходит рассеивание записей переполнения в основной области.

Если пакет переполнен, то запись помещается в следующий за ним пакет.

Данный метод уменьшает время поиска записей т.к. обычно смежные пакеты расположены друг за другом на расстоянии, не превышающем длины дорожки. Однако если размер пакетов невелик, то это приводит к необходимости последовательного перебора пакетов в поисках свободного места. При размерах пакета более 10 записей этот метод эффективен при периодической реорганизации БД. Позволяет увеличивать плотность заполнения.

Справочник свободных пакетов.

Организуется специальный справочник, который содержит сведения о том, какие пакеты еще не заполнены. Если первичный пакет заполнен, то с помощью справочника определяется свободный пакет и после занесения в него записи в первичный пакет заносится ссылка на него. Необходимость в справочнике возрастает в случае частой модификации файлов. В качестве справочника может использоваться простой список заполнения пакетов.

Метод эффективен, если размер пакета более 20 записей. Оптимизация предполагает загрузку файла, когда в основной области помещаются наиболее часто используемые записи.

Практическая часть

Произвести анализ двух методов хеширования в соответствии с вариантом задания, предложенным преподавателем. Для этого:

Разместить 1- м из двух методов, файл содержащий последовательность записей. Каждая запись состоит минимум из трех полей: ключевое поле и несколько информационных полей. Длина последовательности не менее
1 000 000 элементов. Ключевое поле символьное (6 символов, ключ уникален). Из информационных полей одно строковое, другое числовое. При размещении место выделить под 1 200 000 записей (20% прибавляется на расширение базы и несовершенство алгоритма хеширования). Размещение производить по ключу, изменяя количество пакетов по следующему правилу:

– от 20 до 200 с шагом 20;

– от 200 до 2000 с шагом 200;

– от 2000 до 20000 с шагом 2000;

– от 20000 до 200000 с шагом 20000.

При каждом изменении числа пакетов длина пакета должна автоматически пересчитываться. Например, если пакетов 20, то число записей в пакете
60 000, если пакетов 200 000, то в каждом по 6 записей. При каждом переразмещении оценить плотность заполнения основной области и процентное отношение записей, попавших в область переполнения к общему числу записей. На основании полученных данных построить график. Результат каждого размещения поместить в отдельный файл.

Те же действия проделать с этим же исходным файлом, но для второго метода хеширования.

Сравнив два графика оценить эффективность каждого метода для хеширования символьных ключей.

Выдвинуть предположение об оптимальном соотношении числа пакетов и записей в пакете.

Указания по выбору варианта

Номер варианта соответствует последней цифре номера зачётной книжки. Если номер зачётной книжки оканчивается на ноль, выполняется 10-й вариант.

1. Методы хеширования: "метод средних квадратов", "метод складывания" Область переполнения в виде цепочек пакетов переполнения.

2. Методы хеширования: "метод деления", "метод преобразования системы счисления". Распределенная область переполнения.

3. Методы хеширования: "сдвиг разрядов", " метод деления".
Область переполнения в виде цепочек пакетов переполнения.

4. Методы хеширования: "метод деления", "метод складывания".
Распределенная область переполнения.

5. Методы хеширования: "метод деления", "анализ отдельных разрядов ключа". Область переполнения в виде цепочек пакетов переполнения.

6. Методы хеширования: "метод средних квадратов", "сдвиг разрядов" Организация области переполнения методом открытой адресации (Петерсона)

7. Методы хеширования: "метод преобразования системы счисления", "метод складывания". Организация области переполнения методом открытой адресации (Петерсона)

8. Методы хеширования: "сдвиг разрядов", "анализ отдельных разрядов ключа". Организация области переполнения методом открытой адресации (Петерсона)

9. Методы хеширования: "метод средних квадратов", "метод преобразования системы счисления". Распределенная область переполнения.

10. Методы хеширования: "метод деления", "анализ отдельных разрядов ключа". Распределенная область переполнения.

Индивидуальные практические работы

Индивидуальная практическая работа № 1

Общие сведения

В стандартной реализации записи упорядочены по возрастанию значений ключа. Рассмотрим некоторые стандартные алгоритмы сортировки ключей.

МЕТОДЫ СОРТИРОВКИ КЛЮЧЕЙ:

Быстрая сортировка. Выбирается какой-нибудь (например средний) элемент и все элементы переставляются так, чтобы слева от выбранного оказались только элементы с меньшим значением ключа, а справа с большим значением ключа (тем самым выбранный элемент окажется на своем окончательном месте), после чего необходимо рекурсивно применить этот метод к левой и правой частям списка.

Карманная сортировка. Сортируются ключи, содержащие более одной цифры. Выделяются карманы. Число карманов соответствует числу существующих значений каждого разряда ключа. Ключи последовательно сортируются по каждому разряду. Сначала происходит сортировка по младшему разряду. После этого содержимое разных карманов объединяется так, чтобы элементы из кармана с меньшим весом были слева, а карманы с большим — справа. Далее происходит сортировка по карманам предпоследнего разряда ключа с последующим объединением карманов и т.д.

Пример: Дана последовательность ключей

42 23 74 11 65 57 94 36 99 87 70 81 61

карманы: 0 1 2 3 4 5 6 7 8 9

70 11 42 23 74 65 36 57 99

81 94 87

После объединения карманов:

70 11 81 61 42 23 74 94 65 36 57 87 99

Следующий шаг:

0 1 2 3 4 5 6 7 8 9

11 23 36 42 57 61 70 81 94

65 74 87 99

Объединяя карманы, заканчиваем сортировку:

11 23 36 42 57 61 65 70 74 81 87 94 99

Каждый карман рациональнее всего представлять в виде динамической очереди.

Сортировка слиянием. Слияние означает объединение двух (или более) последовательностей в одну единственную упорядоченную последовательность с помощью повторяющегося выбора из доступных в данный момент элементов. Сортировка выполняется путем многократного выполнения попарных слияний. Например 16 последовательностей в результате попарного слияния образуют 8 последовательностей. Которые после попарного слияния образуют 4 последовательности и т.д.

Для слияния 2к последовательностей требуется к шагов. Каждую последовательность, содержащую n записей можно реализовать как состоящую из n последовательностей по 1-й записи. Расчленение исходной последовательности на подпоследовательности можно выполнить с учетом внутренних упорядоченностей.

Недостатком является большой объем памяти, требуемый для реализации алгоритма.

Сортировка с помощью бинарного дерева. Алгоритм состоит из 2-х этапов:

1. Построение дерева обеспечивает вставку новых записей

2. Обход дерева

В результате будет сформирована упорядоченная последовательность.

Сортировка Шелла. Основная идея метода заключается в том, чтобы вначале устранить массовый беспорядок в массиве, сравнивая далеко отстоящие друг от друга элементы. Постепенно интервал между сравниваемыми элементами уменьшается до единицы. Это означает, что на последних стадиях сортировка сводится просто к перестановкам соседних элементов (если в этом есть необходимость). Интервал между сравниваемыми элементами, как правило, рассчитывают по формуле:

Необходимо учесть, что шаги формула рассчитывает в обратном порядке.

Практическая часть

Произвести анализ двух методов сортировки в соответствии с вариантом задания, предложенным преподавателем. В качестве исходного файла использовать файл, созданный при выполнении первой контрольной работы. Необходимо:

– Отсортировать в порядке возрастания 800000 записей из исходного файла по значениям строкового информационного поля первым методом. Результат сортировки сохранить в файл. Исходный файл оставить неизменным;

– Отсортировать в порядке возрастания 800000 записей из исходного файла по значениям строкового информационного поля вторым методом. Результат сортировки сохранить в файл. Исходный файл оставить неизменным;

– Отсортировать в порядке возрастания 800000 записей из исходного файла по значениям числового информационного поля первым методом. Результат сортировки сохранить в файл. Исходный файл оставить неизменным;

– Отсортировать в порядке возрастания 800000 записей из исходного файла по значениям числового информационного поля вторым методом. Результат сортировки сохранить в файл. Исходный файл оставить неизменным;

– Оценить быстродействие двух предложенных методов сортировки ключей и объем памяти, требуемой для сортировки.

Указания по выбору варианта

1. Сортировка слиянием. Быстрая сортировка.

2. Сортировка Шелла. Карманная сортировка.

3. Сортировка слиянием. Бинарное дерево.

4. Быстрая сортировка. Бинарное дерево.

5. Быстрая сортировка. Карманная сортировка.

6. Сортировка Шелла. Быстрая сортировка.

7. Бинарное дерево. Карманная сортировка.

8. Сортировка Шелла Бинарное дерево.

9. Карманная сортировка. Сортировка слиянием.

10. Быстрая сортировка. Бинарное дерево.

Индивидуальная практическая работа № 2

Общие сведения

Главы Учебного пособия, которые необходимо изучить перед выполнением лабораторной работы: 2.6.6 – 2.6.8

Произвести размещение последовательности из 1000 000 записей методом VSAM. В качестве исходного файла №1 взять файл, полученный в ходе выполнения предыдущей лабораторной работы, содержащий отсортированные строковые информационные поля. В качестве исходного файла №2 взять файл, полученный в ходе выполнения предыдущей лабораторной работы, содержащий отсортированные числовые информационные поля.

Размещение производить в соответствии со следующим алгоритмом

Шаг 1: Сгенерировать файл для размещения. Элементы файла – записи, состоящие из двух полей. В качестве ключевого поля необходимо выбрать из исходного файла №1 информационное строковое поле, а в качестве неключевого атрибута – поле первичного ключа исходного файла №1.

Шаг 2: Произвести размещение 800000 отсортированных по ключевому полю записей методом VSAM в структуры согласно варианту, заданному преподавателем

Шаг 3: Произвести поэлементное добавление оставшихся 200000 записей

Шаг 4: Сгенерировать файл для размещения. Элементы файла – записи, состоящие из двух полей. В качестве ключевого поля необходимо выбрать из исходного файла №2 информационное числовое поле, а в качестве неключевого атрибута – поле первичного ключа исходного файла №2.

Шаг 5: Произвести размещение 800000 отсортированных по ключевому полю записей методом VSAM в структуры согласно варианту, заданному преподавателем

Шаг 6: Произвести поэлементное добавление оставшихся 200000 записей

Предусмотреть возможность визуального просмотра процесса добавления записей.

Указания по выбору варианта

№ варианта	Общее число интервалов в одной управляемой области	Номера свободных интервалов при первоначальном заполнении	Свободная доля интервала при первоначальном заполнении (в %)
1	12	4,8,12	15
2	15	5,10,15	15
3	21	7,14,21	15
4	16	4,8,12,16	10
5	20	5,10,15,20	10
6	18	6,12,18	15
7	24	6,12,18,24	10
8	40	10,20,30,40	10
9	45	15, 30, 45	15
10	24	6,18,32	25

Эмпирическим путем подобрать оптимальную длину интервала для вариантов 1 – 7 из диапазона 100 – 400 записей; для вариантов 8,9 из диапазона 50 – 200 записей.

Практическая часть

Шаг 1: Произвести поиск всех записей, размещенных с помощью шагов 2 и 3 текущей лабораторной работы в соответствии с введенным с клавиатуры значением ключа.

Шаг 2: В каждой найденной записи выделить неключевое поле и, выбрав его в качестве первичного ключа, произвести поиск в файле, хранящем данные, размещенные с помощью алгоритма хеширования. (контрольная работа 2). Результат поиска – информационные поля найденных записей выдать на экран.

Шаг 3: Произвести поиск всех записей, размещенных с помощью шагов 5 и 6 текущей лабораторной работы в соответствии с введенным с клавиатуры значением ключа.

Шаг 4: Определить пересечение множеств записей, найденных на шаге 1 и шаге 3 (должны совпадать неключевые поля)

Шаг 5: В каждой найденной записи выделить неключевое поле и, выбрав его в качестве первичного ключа, произвести поиск в файле, хранящем данные, размещенные с помощью алгоритма хеширования. (контрольная работа 2). Результат поиска – информационные поля найденных записей выдать на экран.

1. Институт необходимой обороны в уголовном праве РФ
2. Элементная база компьютер
3. Реферат- Психологическое воздействие компьютера на человека
4. Вариант 6 А1 В каком слове неверно выделена буква обозначающая ударный гласный звук 1 средствАми
5. Решение задач методом северо-западного угла, рапределительного, минимального и максимального элемента по строке
6. Задачи курса- познакомить студентов с профессией моделью современного специалиста или бакалавра в сф
7. авторські новотвори в поезії Т
8. 12 адресов открытых крыш все в центре Комментарии проверяющих крыш по всем адресам Фотографии видов с
9. Сущность и понятие права современные подходы и решения
10. Права и обязанности сторон в арбитражном процессе
11. Введение в дисциплину
12. Ростов н-Д-Феникс 2002
13. ПО ТЕМЕ 6- Патофизиология воспаления Дисциплина- ПАТОФИЗИОЛОГИЯ ~ пф головы и шеи СТОМАТОЛОГИЧЕСК
14. по генетическим признакам делятся на терригенные хемогенные и органогенные Болото участок земной пов
15. Органы обеспечения безопасности
16. Системный клещевой боррелиоз
17. Технологии и системы эксплуатации ВС ЭКЗАМЕНАЦИОННЫЙ БИЛЕТ ’ 1 по дисциплине- государстве.html
18. Кировский сельскохозяйственный техникум Методические указания для самостоятель
19. тематики и практический психолог
20. Представьте в виде квадрата двучлена А Б В

Материалы собраны группой SamZan и находятся в свободном доступе