1.3. Понятие отношения
В реляционных базах данных отношения (межтабличные связи) позволяют не создавать избыточные данные.
Существуют отношения трех типов. Тип отношения в создаваемой связи зависит от способа определения связываемых столбцов:
при отношении «один-к-одному» каждой записи ключевого поля в первой таблице соответствует только одна запись в связанном поле другой таблицы и наоборот (большинство данных, связанных таким образом, может быть помещено в одну общую таблицу). Отношения этого типа используются не очень часто. Иногда его можно использовать для разделения таблиц, содержащих много полей, для отделения части таблицы по соображениям безопасности, а также для выделения сведений, относящихся к подмножеству записей в главной таблице;
чаще всего используется отношение «один-ко-многим». Оно означает, что одной записи в первой таблице соответствует несколько записей во второй, но запись во второй таблице не может иметь больше одной связанной записи в первой таблице, то есть на стороне «один» должно выступать ключевое поле, содержащее уникальные, неповторяющиеся значения, а значения на стороне «многие» могут повторяться. Например, одно издательство может выпустить несколько книг, но одну книгу может выпустить только одно конкретное издательство;
отношение «многие-ко-многим» означает, что одной записи в первой таблице могут соответствовать несколько записей во второй таблице, а одной записи во второй таблице могут соответствовать несколько записей в первой. Такое отношение содержит в себе неопределенность, разрешить которую можно только с помощью третьей (связующей) таблицы. Первичный ключ связующей таблицы состоит из двух полей, которые являются внешними ключами первой и второй таблиц. Можно сказать, что отношение «многие-ко-многим» представляет собой два отношения «один-ко-многим» с третьей таблицей. Например, каждый автор может написать несколько книг, а каждая книга может иметь несколько авторов, но авторский коллектив каждой книги уникален, так же, как и список книг, написанных конкретным автором.
Глава 2. Проблемы проектирования баз данных
2.1. Проектирование баз данных
Результатом проектирования базы данных обычно является развернутая схема базы данных, которая должна исчерпывающе описывать ее логическую структуру (следует подчеркнуть, что логическая структура никаким образом не связана с физической структурой базы и способом записи данных). Схема базы данных должна включать названия таблиц, описывающих отдельные информационные объекты, названия и тип данных всех полей таблиц, а также связи между таблицами и их полями. Хотя процесс создания логической структуры базы данных может занять значительное количество времени, экономить его здесь однозначно не рекомендуется.
Проектирование базы данных является итерационным процессом, в ходе которого разработчик шаг за шагом приближается к желаемому результату. Иногда приходится «отступать» на несколько шагов назад, переделывая предыдущую работу с учетом вновь появившихся данных или вновь возникших обстоятельств.
Можно разбить последовательность проектирования базы данных на решение следующих общих задач:
I. Разработка технического задания. Техническое задание на проектирование базы данных должен предоставить заказчик. Однако для этого он должен владеть соответствующей терминологией и знать технические возможности основных систем управления базами данных. Обычно же используют следующие подходы:
демонстрируют заказчику работу аналогичной базы данных, после чего согласовывают спецификацию отличий;
если аналога нет, выясняют круг задач и потребностей заказчика, после чего помогают ему подготовить техническое задание.
При подготовке технического задания составляют:
список исходных данных, с которыми работает заказчик;
список выходных данных, которые необходимы заказчику для управления структурой своего предприятия;
список выходных данных, которые не являются необходимыми для заказчика, но которые он должен предоставлять в другие организации (в вышестоящие структуры, в органы статистического учета, прочие административные и контролирующие организации).
Так, например, при подготовке базы данных для учета абитуриентов и студентов в высшем учебном заведении необходимо не только изучить документооборот ректората и всех деканатов, но и понять, что хотели бы получить от базы данных службы. Следует изучить работу подразделений, распределяющих учебную нагрузку преподавателей, отвечающих за распределение аудиторного фонда, за проживание студентов в общежитии и других. В расчет должны приниматься и такие службы, как библиотека, отдел кадров и прочие. В любой момент может выясниться, например, что администрация библиотеки должна периодически поставлять кому-то отчеты, характеризующие читательскую активность студентов в зависимости от пола, возраста и социального положения.
II. Разработка структуры базы данных. Выяснив основную часть данных, которые заказчик потребляет или поставляет, можно приступать к созданию структуры базы, то есть структуры ее основных таблиц.
Работа начинается с составления генерального списка полей – он может насчитывать десятки и даже сотни позиций.
В соответствии с типом данных, размещаемых в каждом поле, определяют наиболее подходящий тип для каждого поля.
Далее распределяют поля генерального списка по базовым таблицам. На первом этапе распределение производят по функциональному признаку. Цель – обеспечить, чтобы ввод данных в одну таблицу производился, по возможности, в рамках одного подразделения, а еще лучше – на одном рабочем месте.
Наметив столько страниц, сколько подразделений охватывает база данных, приступают к дальнейшему делению таблиц. Критерием необходимости деления является факт множественного повтора данных в соседних записях. На рисунке показана таблица, у которой в поле «Наименование товара» наблюдается повтор данных. Это явное свидетельство того, что таблицу надо поделить на две взаимосвязанные таблицы.
Рис. 2.1. Взаимосвязанные таблицы
Закончив эту работу, следует проанализировать промежуточный результат по следующим направлениям:
насколько полно выбранные свойства характеризуют объект, нет ли среди них избыточных;
нет ли одинаковых свойств в разных таблицах;
целесообразно ли передать какое-то свойство к другому объекту (например, контактный телефон автора должен быть скорее в таблице Авторы, а не Книги, Издательства или др.);
нужны ли дополнительные объекты или свойства.
В каждой из таблиц намечают ключевое поле. В качестве такового выбирают поле, в котором данные повторяться не могут. Например, для таблицы данных о студентах таким полем может служить индивидуальный шифр студента.
Если в таблице вообще нет никаких полей, которые можно было бы использовать как ключевые, всегда можно ввести дополнительное поле типа Счетчик – оно не может содержать повторяющихся данных по определению.
Устанавливается схема данных (графическое представление структуры базы данных).
Существует несколько типов возможных связей между таблицами. Наиболее распространенными являются связи «один-к-одному» и «один-ко-многим». Связь между таблицами организуется на основе общего поля, причем в одной из таблиц оно обязательно должно быть ключевым, то есть на стороне «один» должно выступать ключевое поле, содержащее уникальные, неповторяющиеся значения. Значения на стороне «многие» могут повторяться.
Рассмотрим таблицу Клиенты (см. рис. 2.2). Поле Код клиента является ключевым. Это понятно, поскольку у каждого клиента должен быть свой уникальный код, идентифицирующий его однозначно. Если мы рассмотрим таблицу Доставки, то увидим, что в ней код клиента не может быть уникальным, поскольку каждый клиент мог сделать сколь угодно много заказов. На схеме данных эти поля соединены линией связи. Тип связи – «один-ко-многим».
Рис.2.2. Схема связей между таблицами
Про подобные таблицы говорят, что они связаны реляционными отношениями, т.е. связи между наборами данных реализованы на основании совпадения значений полей. Соответственно, системы управления, способные работать со связанными таблицами, называют системами управления реляционными базами данных, а схему данных могут называть схемой реляционных отношений.
Разработкой схемы данных заканчивается «бумажный» этап работы над техническим предложением. Эту схему согласовывают с заказчиком. На этом этапе завершается предварительное проектирование базы данных.
Предварительное опробование структуры базы данных. Если работа, описанная выше, проделана достаточно хорошо, можно создать таблицы базы данных, установить между ними связи и ввести в таблицы небольшой объем данных, достаточный для проверки структуры. Работа связей между таблицами может быть проверена созданием запросов, в результате выполнения которых должны получаться нужные сведения. Также можно создать черновые формы и отчеты и проверить, насколько хорошо они работают, отображают ли те сведения, которые ожидались. Выявленные ошибки можно исправить, вернувшись к предшествующему этапу проектирования. В любом случае, не следует начинать заполнять базу данными, пока не исправлены все ошибки и неточности в ее структуре.
В СУБД Microsoft Access существуют два инструмента, помогающие усовершенствовать структуру базы данных: Мастер анализа таблиц и Анализатор быстродействия. Первый из них позволяет проанализировать структуру таблицы, предложить подходящие новые структуры и связи, а также разделить таблицу на новые связанные таблицы, если это имеет смысл. Второе средство исследует всю базу данных и дает рекомендации по ее улучшению, а также может выполнить эти рекомендации (если вы дадите на это согласие). Если ваша проверочная база открыта, то запустить эти средства можно командой Сервис Анализ Таблица или Сервис Анализ Быстродействие. Так как они построены в виде мастеров, то появляющиеся диалоговые окна содержат пояснения и дают рекомендации для принятия решения.