Выделение информационных объектов предметной области

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

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

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

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

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

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

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

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

Пример проектирования БД "Учебный процесс"

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

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

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

Таблица "Кафедра"

Содержание поля	Имя поля	Тип поля	Наличие ключа
Код кафедры	ККАФ	Счетчик	Простой ключ
Название кафедры	НКАФ	Текстовый
Телефон кафедры	ТЕЛ	Текстовый
Заведующий кафедрой	ЗАВ	Текстовый
Фотография заведующего	ФОТО	OLE

Таблица "Группа"

Содержание поля	Имя поля	Тип поля	Наличие ключа
Номер группы	НГ	Текстовый	Простой ключ
Количество студентов	КОЛ	Числовой
балл успеваемости	СБАЛЛ	Числовой

 

Таблица "Предмет"

Содержание поля	Имя поля	Тип поля	Наличие ключа
Код предмета	КП	Счетчик	Простой ключ
Название предмета	НП	Текстовый
Всего учебных часов	ЧАСЫ	Числовой
Часов лекций	ЛЕК	Числовой
Часов практических занятий	ПР	Числовой
Число семестров	ЧС	Числовой
Программа курса	ПРОГ	МЕМО

Таблица "Преподаватель"

Содержание поля	Имя поля	Тип поля	Наличие ключа
Табельный номер	ТАБН	Счетчик	Простой ключ
Фамилия, имя, отчество	ФИО	Числовой
Ученая степень	СТ	Текстовый
Ученое звание	ЗВ	Текстовый
Код кафедры	ККАФ	Числовой

Таблица "Студент"

Содержание поля	Имя поля	Тип поля	Наличие ключа
Номер группы	НГ	Текстовый	Составной ключ
Номер студента в группе	НС	Числовой	Составной ключ
Фамилия, имя, отчество	ФИО	Текстовый
Год рождения	ГОДР	Дата
Адрес	АДР	Текстовый
Средний балл обучения	СБАЛЛ	Числовой

Таблица "Изучение"

Содержание поля	Имя поля	Тип поля	Наличие ключа
Номер группы	НГ	Текстовый	Составной ключ
Код предмета	КП	Числовой	Составной ключ
Табельный номер преподавателя	ТАБН	Числовой	Составной ключ
Вид занятия	ВИДЗ	Текстовый	Составной ключ
Часов по данному виду	ЧАСЫ	Числовой

Таблица "Успеваемость"

Содержание поля	Имя поля	Тип поля	Наличие ключа
Номер студента	НС	Числовой	Составной ключ
Номер группы	НГ	Текстовый	Составной ключ
Код предмета	КП	Числовой	Составной ключ
Табельный номер преподавателя	ТАБН	Числовой	Составной ключ
Вид занятия	ВИДЗ	Текстовый	Составной ключ
Оценка	ОЦЕНКА	Числовой

В рассмотренных таблицах добавлен столбец "Тип поля", являющийся характеристикой не информационного объекта, а таблицы БД. Он добавлен для иллюстрации особенностей реализации БД:

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

Реквизит НГ реализован как текстовое с максимальной длиной 6 символов, поскольку номер группы может содержать буквы и его можно использовать в качестве ключа.
Для реквизита ФОТО в таблице "Кафедра" используется "Поле объекта OLE" для обеспечения возможности выводить фотографию.
Реквизиту ПРОГ таблицы "Предмет" соответствует тип поля МЕМО для вывода сравнительно большого текста, такого, как программа обучения по предмету.
Следующим этапом проектирования БД является определение связей между информационными объектами. Связи устанавливаются последовательно между парами объектов. В данной задаче все связи имеют тип отношения "один ко многим".
Информационно-логическая модель БД "Учебный процесс", построенная в соответствии с выявленными информационными объектами и связями, показана на рисунке:

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

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

 

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

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

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

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

· ядро, которое отвечает за управление данными во внешней и оперативной памяти и журнализацию,

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

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

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

Классификация СУБД

По модели данных

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

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

· Сетевые

· Реляционные

· Объектно-реляционные

· Объектно-ориентированные

По архитектуре организации хранения данных

· локальные СУБД (все части локальной СУБД размещаются на одном компьютере)

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

По способу доступа к БД

· Файл-серверные

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

На данный момент файл-серверные СУБД считаются устаревшими.

Примеры: Microsoft Access, Paradox, dBase.

· Клиент-серверные

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

Примеры: Firebird, Interbase, IBM DB2, MS SQL Server, Sybase, Oracle, PostgreSQL, MySQL, ЛИНТЕР.

· Встраиваемые

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

 

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

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

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

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

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

Таблица 3. Пример избыточности в таблицах базы данных

Профессия	Сотрудник
"Инженер"	Гусев И.К.
"Инженер"	Иванов П.В.
"Рабочий"	Иванов К.Л.
"Рабочий"	Дружков П.К.
"Рабочий"	Фомичев В.М.

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

Таблица 4. Таблица профессий

Профессия	Первичный ключ
"Инженер"
"Рабочий"

Таблица 5. Таблица сотрудников

Профессия (внешний ключ)	Сотрудник
	Гусев И.К.
	Иванов П.В.
	Иванов К.Л.
	Дружков П.К.
	Фомичев В.М.

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

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