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

Процесс выделения информационных объектов предметной области, отвечающих требованиям нормализации, может производиться на основе интуитивного или формального подхода. Теоретические основы формального подхода были разработаны и полно изложены в монографиях по организации баз данных известного американского ученого Дж. Мартина. При интуитивном подходе легко могут быть выявлены информационные объекты, соответствующие реальным объектам. Однако, получаемая при этом информационно-логическая модель, как правило, требует дальнейших преобразований, в частности, преобразования много-многозначных (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-запросы, что приводит к обратному эффекту — замедлению работы базы данных. Поэтому иногда для упрощения запросов даже прибегают к обратной процедуре — денормализации.

Статьи к прочтению:

j-DESIGN.PRO — Частые способы выделения объектов в ZBrush

Похожие статьи: