Основные компоненты системы базы данных

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

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

База данных

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

Данные пользователя

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

Столбцы таблицы содержат поля (или атрибуты), а строки содержат записи об объектах делового мира.

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

Метаданные

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

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

Например, в СУБД InterBase метаданные хранятся в 32-х системных таблицах, названия которых начинаются с символов RDB$…

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

СУБД

Разные СУБД различаются по своим характеристикам. Первые СУБД были разработаны для больших ЭВМ в конце 1960-х годов.

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

Основные функции СУБД:

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

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

Прикладные программы

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

Этапы проектирования БД

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

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

2. Инфологическое проектирование - описание объектов предметной области в терминах модели “сущность-связь”.

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

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

Основные цели моделирования данных состоят в изучении значения

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

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

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

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

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

Критерии оценки модели данных:

- Структурная достоверность - соответствие способу определения и организации информации на данном предприятии

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

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

- Целостность - согласованность со способом использования и управления информацией внутри предприятия

- Выразительность – способность представлять различия между данными, связи между данными и ограничения

Существуют два основных подхода к проектированию систем баз данных:

нисходящий и восходящий. При восходящем подходе работа начинается с самого

нижнего уровня атрибутов (т.е. свойств сущностей и связей), которые на основе

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

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

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

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

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

Модель сущность связь.

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

В результате системного анализа получают:

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

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

² описание входных документов, по которым заполняется БД;

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

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

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

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

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

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

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

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

Первый вариант модели “сущность-связь” был предложен в 1976 г. Питером Ченом. С тех пор она многократно расширялась и модифицировалась. Эта модель является средством для записи пользовательской модели данных.

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

Для графического представления модели “сущность-связь”, кроме традиционных символов, могут применяться символы языка UML (Unified Model Language - унифицированный язык моделирования).

Элементы модели “сущность-связь”

Ключевыми элементами модели “сущность-связь” являются сущности, атрибуты, идентификаторы и связи. Рассмотрим каждый из этих элементов.

Сущности

Сущность (entity) - это некоторый объект, идентифицируемый в мире пользователя, нечто такое, за чем пользователь хотел бы наблюдать. Каждая сущность имеет уникальное имя. Примеры сущностей: СОТРУДНИК Петров Иван Ефимович, КЛИЕНТ 12345, ЗАКАЗ 1000, ПРОДУКТ А4500.

Сущности одного и того же типа группируются в классы сущностей. Например, класс сущностей СОТРУДНИК является совокупностью всех сущностей СОТРУДНИК.

Важно понимать разницу между классом сущностей и экземпляром сущности. Класс сущности - это совокупность сущностей, составляющих этот класс. Он описывается перечнем атрибутов. Экземпляр сущности - это конкретная сущность (например, КЛИЕНТ 12345). Он описывается значениями атрибутов.

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

Пример сущности СОТРУДНИК:

Пример класса		Пример экземпляра класса
СОТРУДНИК		СОТРУДНИК
Табельный номер Фамилия Имя Отчество Количество детей		12345 Петров Иван Ефимович

Атрибуты

У сущностей есть атрибуты, или, как их еще называют, свойства, которые описывают характеристики сущности. Примеры атрибутов: ИмяСотрудника, ДатаНайма, КодТовара.

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

Композитными атрибутами называются атрибуты, состоящие из группы атрибутов (например, атрибут Адрес состоит из атрибутов Город, Улица, Номер дома, Индекс).

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

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

Идентификаторы

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

Идентификатор экземпляра сущности может состоять из нескольких атрибутов сущности. Например, {Код Региона, Местный Номер}, {Название Проекта, Название Задачи}. Такие идентификаторы называются композитными.

Связи

Взаимоотношения сущностей выражаются связями (relationship). Модель “сущность-связь” включает в себя классы связей и экземпляры связей. Классы связей - это взаимоотношения между классами сущностей, а экземпляры связей - взаимоотношения между экземплярами сущностей. У связей могут быть атрибуты.

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

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

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

ПРЕПОДАВАТЕЛЬ

Табельный номер

Фамилия Имя Отчество Кафедра

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

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

Этот способ требует слишком много места и поэтому используется редко.

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

Примеры связей:

Связь степени 2 (бинарная связь) Связь степени 3

Наиболее распространены бинарные связи - связи степени 2.