Системы управления базами данных
Комплекс программных средств, предназначенных для создания структуры новой базы, наполнения ее содержимым, редактирования содержимого и визуализации информации системой управления базами данных (СУБД).
Под визуализацией информации понимается отбор отображаемых данных в соответствии с заданным критерием, их упорядочение, оформление и последующая выдача на устройство вывода или передача по каналам связи.
Системы управления базами данных (СУБД) являются едва ли не самым распространенным видом программного обеспечения. СУБД имеют более чем тридцатилетнюю историю развития с сохранением преемственности и устойчивых традиций. Идеологическая ценность СУБД объясняется тем, что в основе программ такого рода лежит концепция модели данных, то есть некоторой абстракции представления данных. В большинстве случаев предполагается, что данные представлены в виде файлов, состоящих из записей. Структура всех записей в файлах одинакова, а количество записей в файле является переменным. Элементы данных, из которых состоит каждая запись, называются полями. Поскольку во всех записях имеются одни и те же поля (с разными значениями), полям удобно давать уникальные имена. Многие практически важные случаи хорошо укладываются в такое представление данных. Например, в отделе кадров информация о сотрудниках имеют такую природу. Сотрудников принимают на работу и увольняют, но форма личного листа по учету кадров остается неизменной для каждого сотрудника. Товарно-материальные ценности приходят и уходят, но форма инвентарной карточки остается неизменной. Число примеров без труда можно множить. Ясно, что СУБД является адекватным средством во всех случаях, когда исходную информацию можно представить в виде таблицы постоянной структуры, но неопределенной длины или в виде картотеки, содержащей неопределенное количество карточек постоянной структуры.
Все СУБД поддерживают в той или иной форме четыре основных операции:
Ÿ добавление в базу данных одной или нескольких записей;
Ÿ удаление из базы данных одной или нескольких записей;
Ÿ нахождение в базе данных одной или нескольких записей, удовлетворяющих заданному условию;
Ÿ обновление в базе данных значений некоторых полей.
Большинство СУБД поддерживают, кроме того, механизм связей между различными файлами, входящих в базу.
Любая СУБД должна выполнять три основные функции:
Ввод данных. В системе должна существовать структура, в которой могут накапливаться данные. Кроме того, в системе необходимо предусмотреть возможность просмотра этих данных и внесение в них изменений с тем, чтобы поддерживать актуальность информации.
Запросы по данным. Система должна предоставлять пользователю возможность отыскивать и просматривать отдельные части накопленной информации.
Составление отчетов. Время от времени следует обобщать информацию, хранимую в БД. Отчет отличается от запроса в двух отношениях. Во-первых, отчет обычно охватывает не какую-либо часть БД, а всю ее целиком. Во-вторых, при получении отчета информация, как правило, предварительно обрабатывается. Отчеты не просто отражают содержание БД, но и некоторым образом ее анализируют.
Создание базы данных
Простейшая база данных имеет хотя бы одну таблицу. Соответственно, структура простейшей базы данных тождественно равна структуре ее таблицы. Структуру двумерной таблицы образуют именованные столбцы и строки. Их аналогами в структуре простейшей базы данных являются поля и записи. Если записей в таблице пока нет, значит, ее структура образована только набором полей. Изменив состав полей базовой таблицы (или их свойства), мы изменяем структуру базы данных и, соответственно, получаем новую базу данных.
Базы данных Access могут содержать различные объекты: таблицы для сохранения данных, формы для просмотра, добавления и изменения данных в таблицах; запросы для поиска и извлечения только необходимых данных; отчеты для анализа и печати данных в определенном формате; макросы и модули,– но основными объектами любой базы данных являются таблицы (рис. 7.6.1).
Рис. 7.6.1. Окно базы данных с объектами
Определение структуры базы данных необходимо всегда начинать с создания ее таблиц. Таблицы создаются раньше любых других объектов базы данных. Все остальные объекты являются производными и создаются только на основе ранее подготовленных таблиц.
Сразу поясним, что если в базе нет никаких данных (пустая база), то это все равно полноценная база данных. Этот факт имеет методическое значение. Хотя данных в базе и нет, но информация в ней все-таки есть – это структура базы. Она определяет методы занесения данных и хранения их в базе. Простейший «некомпьютерный» вариант базы данных – деловой ежедневник, в котором каждому календарному дню выделено по странице. Даже если в нем не записано ни строки, он не перестает быть ежедневником, поскольку имеет структуру, четко отличающую его от записных книжек, рабочих тетрадей и прочей писчебумажной продукции.
С каждым объектом базы данных работы выполняется в отдельном окне, причем предусмотрено два режима работы:
1) оперативный режим, когда просматривается, изменяется или выбирается информация (рис.7.6.2);
Рис. 7.6.2. Окно таблицы базы данных в оперативном режиме
2) режим конструктора, когда создается или изменяется макет, структура объекта (например, структура таблицы (рис. 7.6.3)).
Рис. 7.6.3. Окно таблицы базы данных в режиме Конструктора
Нормализация
Большинство баз данных включают несколько таблиц. Например, в одной таблице могут храниться сведения о продуктах, во второй – сведения о заказах, а в третьей — сведения о клиентах (рис. 7.6.1.1).
Рис.7.6.1.1. Таблицы базы данных
Самое важное правило, которое нужно соблюдать при работе с БД, – все данные должны храниться только один раз.
Чтобы обеспечить наибольшую гибкость базы данных, необходимо распределить данные по таблицам так, чтобы избежать их избыточности (повторяющихся данных).
«Почему плохо иметь в таблицах поля с повторяющимися данными?» – может спросить неискушенный в области создания баз данных пользователь. Дело в том, что это очень неэффективный способ хранения данных. И не только потому, что они занимают лишнее место в памяти, этот аргумент в последнее время не является таким сильным, как раньше, из-за значительного снижения цен на микросхемы памяти. Основная причина – это то, что такие данные долго вводить и трудно анализировать. Если случайно при вводе значения пользователь сделал грамматическую ошибку или даже просто ввел лишний пробел, то при запросах и группировках такое значение будет рассматриваться как самостоятельное, и строка, содержащая это значение, не попадет в нужную группу или просто не выведется на экран. Именно поэтому при проектировании структуры базы данных стараются избегать повторения данных и создают для них отдельные таблицы.
Важно помнить, что данные необходимо разбивать на минимальные элементы. Имя следует разделять на две части: имя и фамилию, чтобы фамилия была доступна для использования. В целом, если требуется выполнять сортировку, поиск, вычисления или отчеты для отдельных элементов данных, эти элементы следует сохранять в отдельных полях.
Этот процесс называется нормализацией.
Задание первичных ключей
В теории реляционных баз данных таблица представляет собой изначально неупорядоченный набор записей. Единственный способ идентифицировать определённую запись в таблице – это указать набор значений одного или нескольких полей, который был бы определен для любой записи (строки) этой таблицы и различен для любых двух записей. Отсюда и происходит понятие первичного ключа. Первичным ключом называется атрибут (или набор атрибутов (столбцов, полей)), который может быть использован для однозначной идентификации конкретного кортежа (строки, записи), таблицы.
Ключевые поля должны быть первыми в таблице. СУБД автоматически производит сортировку записей по ключу.
Наличие ключей позволяет связать данные из разных таблиц в запросах, формах и отчетах. Ключ может быть простым, состоящим из одного поля, или составным, включающим несколько полей.
Например, для таблицы данных о студентах таким полем может служить номер студенческого билета. Для таблицы, в которой содержатся расписания занятий, такого поля можно и не найти, но его можно создать искусственным комбинированием полей «Время занятия» и «Номер аудитории». Эта комбинация неповторима, так как в одной аудитории в одно и то же время не принято проводить два различных занятия. Если в таблице вообще нет никаких полей, которые можно было бы использовать как ключевые, всегда можно ввести дополнительное поле типа Счетчик — оно не может содержать повторяющихся данных по определению.
Первичный ключ должен всегда иметь значение. Если столбец допускает неназначенное или отсутствующее значение, его не следует использовать в качестве компонента первичного ключа.
Значение первичного ключа не должно меняться, поэтому в качестве первичного ключа не рекомендуется выбирать фамилию или адрес, поскольку такие данные со временем могут измениться.
Рассмотрим процесс создания первичного ключа для отношения (таблицы) Сотрудник.
Здесь можно выделить следующие потенциальные ключи:
1. Табельный номер;
2. Номер паспорта;
3. Фамилия + Имя + Отчество.
Для того чтобы стать первичным, потенциальный ключ должен удовлетворять ряду требований:
1. Уникальность. Два экземпляра не должны иметь одинаковых значений возможного ключа. Потенциальный ключ № 3 (Фамилия + Имя + Отчество) является плохим кандидатом, поскольку в организации могут работать полные тезки.
2. Компактность. Сложный возможный ключ не должен содержать ни одного атрибута, удаление которого не приводило бы к утрате уникальности. Для обеспечения уникальности ключа № 3 дополним его атрибутами Дата рождения и Цвет волос. Если сочетание атрибутов Фамилия + Имя + Отчество + Дата рождения достаточно для однозначной идентификации сотрудника, то Цвет волос оказывается лишним, т. е. ключ Фамилия + Имя + Отчество + Дата рождения + Цвет волос не является компактным.
3. При выборе первичного ключа предпочтение должно отдаваться более простым ключам, т. е. ключам, содержащим меньшее количество атрибутов. В приведенном примере ключи № 1 и 2 предпочтительней ключа № 3.
4. Атрибуты ключа не должны содержать нулевых значений.
5. Значение атрибутов ключа не должно меняться в течение всего времени существования экземпляра сущности. Сотрудница организации может выйти замуж и сменить как фамилию, так и паспорт. Поэтому ключи № 2 и 3 не подходят на роль первичного ключа.
Установление связей между таблицами