СУБД и проектирование данных
СУБД: классификация, основные понятия и термины
Набор специальных программных средств, необходимых для создания, изменения базы данных и обеспечения доступа к ним, принято называть системой управления базами данных (СУБД).
Для обеспечения пользовательского интерфейса используют системы управления базами данных, средства администрирования и клиентские интерфейсы. Системы управления базами данных (СУБД) выполняют следующие функции:
управление данными во внешней памяти (на дисках);
управление данными в оперативной памяти с использованием дискового кэша;
журнализация изменений, резервное копирование и восстановление базы данных после сбоев;
поддержка языков БД (язык определения данных, язык манипулирования данными).
Можно выделить следующие типы СУБД:
Файл-серверные;
Клиент-серверные;
Встраиваемые.
В файл-серверных СУБД файлы данных располагаются централизованно на файл-сервере. СУБД располагается на каждом клиентском компьютере (рабочей станции). Доступ СУБД к данным осуществляется через локальную сеть. Синхронизация чтений и обновлений осуществляется посредством файловых блокировок.
Преимуществом этой архитектуры является низкая нагрузка на процессор файлового сервера.
Недостатки: потенциально высокая загрузка локальной сети; затруднённость или невозможность централизованного управления; затруднённость или невозможность обеспечения таких важных характеристик как высокая надёжность, высокая доступность и высокая безопасность. Применяются чаще всего в локальных приложениях, которые используют функции управления БД; в системах с низкой интенсивностью обработки данных и низкими пиковыми нагрузками на БД.
Клиент-серверная СУБД располагается на сервере вместе с БД и осуществляет доступ к БД непосредственно, в монопольном режиме. Все клиентские запросы на обработку данных обрабатываются клиент-серверной СУБД централизованно.
Недостаток клиент-серверных СУБД состоит в повышенных требованиях к серверу.
Достоинства: потенциально более низкая загрузка локальной сети; удобство централизованного управления; удобство обеспечения таких важных характеристик как высокая надёжность, высокая доступность и высокая безопасность.
Встраиваемая СУБД — СУБД, которая может поставляться как составная часть некоторого программного продукта, не требуя процедуры самостоятельной установки. Встраиваемая СУБД предназначена для локального хранения данных своего приложения и не рассчитана на коллективное использование в сети. Физически встраиваемая СУБД чаще всего реализована в виде подключаемой библиотеки. Доступ к данным со стороны приложения может происходить через SQL либо через специальные программные интерфейсы.
В сетевых СУБД важную роль играют обеспечение коллективной работы пользователей и безопасности данных.
Просто хранить данные в БД недостаточно, необходимо обеспечить доступ к ним. Подразумевается, что СУБД должна выдать пользователю набор записей, удовлетворяющих его запросу. Термин «доступ к данным» означает, что в некоторых таблицах базы данных следует найти те записи, которые нужны пользователю, так что поиск информации сводится к поиску конкретных записей в таблицах.
Для того чтобы найти нужную запись в таблице, используется метод ключей поиска. Он состоит в нахождении записи с помощью значения одного из ее полей. Это поле называется ключом. Одно и то же поле у нескольких записей в таблице может иметь одно и то же значение. Поэтому такой ключ не является универсальным. Если один из ключей уникален, т. е. его значения не повторяются среди всех записей в таблице, то он называется первичным ключом. Этот ключ всегда указывает только на одну запись в отличие от остальных ключей, которые указывают на определенное множество записей (возможно, вообще ни на какие записи) и значения которых могут повторяться. Обычно в роли первичного ключа выступает специальное числовое поле, значение которого автоматически увеличивается с помощью СУБД путем добавления записей в таблицу. Такое поле принято называть идентификатором.
Кроме того, принято различать также потенциальные, внешние, естественные и суррогатные ключи. Потенциальный ключ - подмножество атрибутов отношения, удовлетворяющее требованиям уникальности и минимальности. Первичный ключ является один из потенциальных ключей, выбранный в качестве основного. Внешний ключ – ключ, значения которого должны совпадать у связываемых таблиц. Естественный ключ представляет собой поле, хранящее полезную информацию, суррогатный – искусственно введенное поле.
При рассмотрении СУБД применяется еще несколько терминов для обозначения соответствующих объектов, непосредственно связанных с базой данных:
Запрос - объект, задающий правило выбора нужных данных из базы. Его результатом является набор записей, т. е. некоторая временная таблица, не существующая в базе данных. Записи в этой таблице, вообще говоря, не обязательно совпадают с записями, хранимыми в базе; они могут отличаться как по количеству полей, так и по их названиям и типам;
Форма - объект, позволяющий отображать и редактировать данные в удобном для пользователя виде. Кроме данных форма может содержать и другие элементы, например рамки, линии, геометрические элементы (дуги, окружности). Можно также располагать в форме текст, метки и даже кнопки, позволяющие запускать команды (например, команды перехода в другую форму или расчета некоторых значений);
Отчет - объект, позволяющий получать данные в пригодном для вывода на принтер виде. Он может содержать различные элементы оформления, например линии и рамки (одинарные и двойные), колонтитулы с поясняющим текстом, номера страниц, элементы группировки данных;
Макрос - объект, дающий возможность с помощью одной операции выполнять некоторую последовательность команд;
Модуль - объект, позволяющий выполнять сложные действия, которые не могут быть реализованы другим способом. Модуль представляет собой программу на каком-либо языке программирования, реализующую некоторый алгоритм обработки данных в базе.
Главным средством обеспечения коллективной работы с базой данных является репликация. Это средство организации работы одного или нескольких пользователей с одним и тем же документом, базой данных или другими-файлами на разных компьютерах независимо, без одновременного доступа к файлам, но когда требуется поддерживать некоторую общую версию изменяемых файлов, содержащую в себе все последние исправления, сделанные независимо. Более конкретно, репликация — это процесс создания копий файлов, между которыми может осуществляться обмен обновляемыми данными или объектами. Такие копии называются репликами, а такой обмен — синхронизацией. Для систем, поддерживающих роли пользователей и схемы, реплики создаются после инициализации пользователя в соответствии с его полномочиями.
Для защиты базы данных большая часть СУБД использует также механизм транзакций. Транзакция – разбитый на несколько этапов процесс внесения изменений в базу данных или ее реплику, при котором на каждом этапе контролируется правильность выполнения действий. Если на каком-то этапе произошел сбой, то транзакция отменяется, и система возвращается в исходное состояние. Если транзакция осуществлена корректно, то изменения вносятся в базу данных. Пример транзакции – работа с банкоматом или инфокиоском.
Создание и управление базой данных для персональных компьютеров может быть обеспечено еще двумя способами:
с помощью языков программирования (обычно этот способ применяется при создании новых уникальными программистами);
с помощью прикладных программ программирования таких, как Visual Basic, Turbo Pascal.
Этапы проектирования и создания базы данных
Для проектирования базы данных необходимо располагать описанием выбранной предметной области, которое должно охватывать реальные объекты и процессы, определять все необходимые источники информации для обеспечения предполагаемых запросов пользователя и решаемых в приложении задач. Определение состава и структуры данных, которые должны быть загружены в базу данных, осуществляется на основе анализа предметной области. Структура данных предметной области может отображаться информационно-логической моделью (ИЛМ). Если при построении такой модели обеспечены требования нормализации данных и она, соответственно, представлена в каноническом виде, далее легко определяется проект логической структуры нормализованной базы данных. На основе канонической модели можно создать реляционную базу без дублирования данных.В процессе разработки канонической модели данных предметной области для проектирования реляционной базы данных необходимо выделить информационные объекты (ИО), соответствующие требованиям нормализации данных, и определить связи между ИО с типом отношений 1 : М.
При определении проекта логической структуры реляционной базы данных каждый информационный объект канонической модели предметной области адекватно отображается реляционной таблицей, а связям между двумя информационными объектами соответствуют логические связи между парой соответствующих таблиц.
Такие связи устанавливаются по уникальному ключу главной таблицы. Во второй таблице, которая является подчиненной, поле связи может быть либо частью ее уникального ключа, либо не входить в состав ключа вовсе.
В процессе создания базы данных на компьютере сначала осуществляется конструирование ее таблиц средствами Access. Для поддержания целостности данных в каждой таблице определяется ключевое поле и правила проверки значений данных в полях. Далее создается схема данных, в которой устанавливаются логические связи таблиц. В схеме данных базы могут быть заданы параметры поддержания связной целостности данных.
Связная целостность данных означает, что в базе данных установлены и корректно поддерживаются взаимосвязи между записями разных таблиц при загрузке, добавлении и удалении записей в связанных таблицах, а также при изменении значений ключевых полей. При обеспечении связной целостности в подчиненной таблице не может существовать запись, для которой отсутствует связанная запись в главной таблице.
После формирования в Access схемы данных можно приступать к вводу данных в базу — загрузке c документов предметной области, являющихся источниками данных. В практических приложениях пользователя обычно не используется ввод непосредственно в таблицы, а применяются специально создаваемые экранные формы, играющие роль интерфейса пользователя. Фактически новый документ готовится (заполняется) на компьютере и сохраняется в базе данных.
Проектирование базы данных, основанное на построении нормализованной модели данных предметной области, позволяет легко получить логическую структуру реляционной базы данных Access, в которой автоматически поддерживается целостность и непротиворечивость данных.
Построение информационно-логической модели данных
Информационно-логическая модель (ИЛМ) отображает данные предметной области в виде совокупности информационных объектов (ИО) и связей между ними. Эта модель представляет данные, подлежащие хранению в базе данных. Каждый информационный объект в модели данных должен иметь уникальное имя.
Информационный объект — это информационное описание некоторой сущности предметной области: реального объекта, процесса, явления или события. Информационный объект является совокупностью логически взаимосвязанных реквизитов, представляющих качественные и количественные характеристики сущности.
Информационный объект имеет множество реализаций — экземпляров объекта. Экземпляр объекта должен однозначно определяться среди всего множества экземпляров, т. е. идентифицироваться значением уникального (первичного) ключа информационного объекта. Уникальность ключа означает, что любое значение ключа не может повториться в каком-либо другом экземпляре объекта. Простой ключ состоит из одного реквизита.
Составной ключ — из нескольких реквизитов. Таким образом, реквизиты информационного объекта подразделяются на ключевые и описательные, которые являются функционально зависимыми от ключа.
Информационные объекты могут быть выделены на основе описания предметной области путем определения функциональных зависимостей между реквизитами предметной области. Функциональная зависимость реквизитов информационного объекта устанавливает соответствие значений ключевых (определяющих) и неключевых (определяемых) реквизитов.
Требования нормализации
Реквизиты каждого информационного объекта канонической модели данных должны отвечать требованиям, соответствующим третьей нормальной форме реляционной модели данных:
информационный объект должен содержать уникальный идентификатор — ключ;
все описательные реквизиты должны быть взаимонезависимы, т. е. между ними не должно быть функциональных зависимостей;
все реквизиты, входящие в составной ключ, также должны быть взаимонезависимы;
каждый описательный реквизит должен функционально полно зависеть от ключа, т. е. каждому значению ключа должно соответствовать только одно значение описательного реквизита, а при составном ключе описательные реквизиты должны зависеть целиком от всей совокупности реквизитов, образующих ключ;
каждый описательный реквизит должен зависеть от ключа нетранзитивно, т. е. не должен зависеть через другой промежуточный реквизит.
Выполнение требований нормализации обеспечивает построение канонической модели данных и создание на ее основе реляционной базы данных без дублирования описательных данных, а также возможность автоматического поддержания связной целостности данных средствами СУБД при обновлении базы данных — добавлении и удалении записей, изменении значений в ключевых полях.
Выделение информационных объектов предметной области
Процесс выделения информационных объектов предметной области, отвечающих требованиям нормализации, может производиться как на основе интуитивного, так и формального (аналитического) подхода. При интуитивном подходе сразу устанавливаются информационные объекты, соответствующие реальным объектам.
Однако получаемая при этом информационно-логическая модель, как правило, требует дальнейших преобразований, в частности, преобразования много-многозначных связей между объектами. При отсутствии достаточного опыта использования такого подхода возможны существенные ошибки. Последующая проверка выполнения требований нормализации обычно показывает необходимость уточнения структуры информационных объектов.
Информационный анализ и определение логической структуры информации
Информационный анализ включает:
структурирование информации предметной области;
формализацию и моделирование данных.
Структура информации внемашинной сферы находит отражение в ее представлении отдельными структурными единицами — реквизитами, их группировке в документах-источниках и упорядочении по классификационным признакам.
Определим важнейшие виды структурных единиц информации:
реквизит — простейшая структурная единица информации, неделимая на смысловом уровне, отражающая количественную или качественную характеристику сущности (объекта, процесса и т. п.) предметной области. Можно выделить реквизиты-признаки и реквизиты-основания:
реквизит-признак позволяет выделить (идентифицировать) объект из множества однотипных объектов (как правило, символьное представление);
реквизит-основание содержит количественную характеристику объекта, процесса или другой сущности, определяющую их состояние (как правило, числовое значение).
составная единица информации (СЕИ) — логически взаимосвязанная совокупность реквизитов. Примером составной единицы информации может служить документ.
Семантика и размещение реквизитов в форме документа определяют роль реквизитов в структуре информации, содержащейся в документе. В процессе информационного семантического (смыслового) анализа нужно вы- явить функциональную зависимость реквизитов и определить реквизитный состав информационных объектов.
На основе описания предметной области необходимо выявить документыисточники и их реквизиты, подлежащие хранению в базе данных. Затем надо перейти к информационному анализу этих документов для определения функциональных зависимостей и выявления информационных объектов.
Связи информационных объектов
Следующим шагом проектирования после выявления информационных объектов является определение связей между ними. Связь устанавливается между двумя информационными объектами. Наличие связи, как правило, определяется природой реальных объектов, процессов или явлений, отображаемых этими информационными объектами. Связь между объектами существует, если логически взаимосвязаны экземпляры этих информационных объектов.
Логическая структура реляционной базы данных
Логическая структура реляционной базы данных Access является адекватным отображением полученной информационно-логической модели предметной области. Для канонической модели не требуется дополнительных преобразований. Каждый информационный объект модели данных отображается соответствующей реляционной таблицей. Структура реляционной таблицы определяется реквизитным составом соответствующего информационного объекта, где каждый столбец (поле) соответствует одному из реквизитов объекта. Ключевые реквизиты объекта образуют уникальный ключ реляционной таблицы. Для каждого столбца таблицы (поля) задается тип, размер данных и другие свойства. Строки (записи) таблицы соответствуют экземплярам объекта и формируются при загрузке таблицы.
Связи между объектами модели данных реализуются одинаковыми реквизитами — ключами связи в соответствующих таблицах. При этом ключом связи типа 1 : M всегда является уникальный ключ главной таблицы. Ключом связи в подчиненной таблице является либо некоторая часть уникального ключа в ней, либо поле, не входящее в состав первичного ключа. Ключ связи в подчиненной таблице называется внешним ключом.