Разработка базы данных

Перви́чный  ключ (англ. primary key) — в реляционной модели данных один из потенциальных ключей отношения, выбранный в качестве основного ключа (или ключа по умолчанию).

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

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

Исторически термин «первичный ключ» появился и  стал использоваться существенно ранее  термина «потенциальный ключ». Вследствие этого множество определений в реляционной теории были изначально сформулированы с упоминанием первичного (а не потенциального) ключа, например, определения нормальных форм. Так же термин «первичный ключ» вошёл в формулировку 12 правил Кодда как основной способ адресации любого значения отношения (таблицы) наряду с именем отношения (таблицы) и именем атрибута (столбца).

Использование

Первичный ключ в таблице является базовым  уникальным идентификатором для записей. Значение первичного ключа используется везде, где нужно указать на конкретную запись. На использовании первичных ключей основана организация связей между таблицами реляционной БД. Чтобы организовать между двумя таблицами связь типа «один к одному» или «один ко многим (многие к одному)» в одну из связываемых таблиц добавляют поле (поля), содержащее (-ие) значение первичного ключа записи в связанной таблице (такое поле называют внешним ключом). Для организации связи типа «многие ко многим» создают отдельную таблицу (так называемую «таблицу связи» или «таблицу ассоциации»), каждая запись которой содержит первичные ключи двух связанных записей в разных таблицах.

Понятие функциональной зависимости  в данных.

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

На практике построение логической модели базы данных, независимо от используемой модели данных, выполняется с учетом двух основных требований: исключить избыточность и максимально повысить надежность данных. Эти требования вытекают из требования коллективного использования данных группой пользователей. Формальных средств описания данных, необходимых для проверки правильности заполнения конструкций моделей, явно недостаточно. Выбор сущностей, атрибутов и фиксация взаимосвязей между сущностями зависит от семантики предметной области и выполняется системным аналитиком субъективно в соответствии с его личным пониманием специфики прикладной задачи. Разные люди определяют и представляют данные по-разному.

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

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

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

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

Определение 1. Пусть r (A1, A2, ..., An) - схема отношения R, a X и Y - подмножества r. Говорят, что Х функционально определяет Y, если каждому значению атрибутов кортежа отношения из Х соответствует не более одного значения атрибутов того же кортежа отношения из Y. Такая ФЗ обозначается как  .

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

Четыре  правила нормализации таблиц.

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

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

Правило 1: Каждое поле любой  таблицы должно быть уникальным.

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

Правило 2. Первичные ключи. База данных хорошо спроектирована тогда, когда каждая запись в любой таблице является уникальной. Это означает, что значение некоторого поля (или нескольких полей) не повторяется ни в одной записи в таблице. Такой идентификатор называется первичным ключом (или просто ключом).

Правило 2: Каждая таблица  должна иметь уникальный идентификатор, или  первичный ключ, который  может состоять из одного или нескольких полей.

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

Правило 3. Функциональная зависимость. Если вы определили для каждой таблицы первичный ключ, то можно проверить, включены ли в таблицы все сведения, относящиеся к соответствующим объектам. Кроме того, следует убедиться, что каждое поле функционально зависит от первичного ключа таблицы.

Правило 3: Для каждого  значения первичного ключа значения в  столбцах данных должны относиться к объекту таблицы и полностью его описывать.

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

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

Правило 4: Изменение значений любого поля (не входящего  в первичный ключ) должно выполняться  без воздействия  на данные других полей. 
 

Эффективность связей. Создание связей между таблицами.

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

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

Между таблицами можно установить связи  одного из трех видов: один-ко-многим (one-to-many), многие-ко-многим (many-to-many) и один-к-одному (one-to-one).

• Один-ко-многим (one-to-many). Является наиболее часто употребляемым видом связи. В этом случае каждой записи таблицы А может соответствовать много записей таблицы Б (или ни одной). В свою очередь, каждой записи таблицы Б соответствует в точности одна запись таблицы А. Таблица А в такой связи называется главной, а таблица Б — связанной или подчиненной.
• Многие-ко-многим (many-to-many). Многим записям из таблицы А может соответствовать много записей из таблицы Б (и наоборот). Такую связь в Microsoft Access можно организовать при помощи третьей вспомогательной таблицы, в которой каждому первичному ключу из таблицы А сопоставлен первичный ключ из таблицы Б. По сути, связь типа многие-ко-многим (many-to-many) представляет собой две связи типа один-ко-многим (one-to-many). При этом таблицы А и Б расположены со стороны один (one), а вспомогательная таблица — со стороны многие (many). Такой тип связи используется реже, но существуют ситуации, когда без нее не обойтись. В учебной базе данных Борей (Northwind) примером связи многие-ко-многим (many-to-many) является связь между таблицами Заказы (Orders) и Товары (Products), организованная при помощи таблицы Заказано (Order Details).
• Один-к-одному (one-to-one). Одной записи таблицы А соответствует в точности одна запись таблицы Б и наоборот. Этот тип связи практически никогда не применяется. Единственный случай, когда применение этого типа связи оправданно — разбивка таблицы, содержащей очень большое количество полей, на несколько частей.

Для любого из перечисленных  выше типов связей существует три  способа объединения. Установленный тип объединения влияет на результаты выборки данных из связанных таблиц.

• Внутреннее объединение (Inner Join). Объединяются только те записи из таблиц, связанные поля которых совпадают. Остальные записи в итоговую выборку не попадут. Например, таблицы Товары (Products) и Типы (Categories) связаны между собой по полям Код Категории (CategoryW). При выборке записей из этих таблиц в итоговую выборку попадут только те записи из таблицы Типы (Categories), ссылка на которые есть в таблице Товары (Products). Этот тип объединения используется в подавляющем большинстве случаев.
• Левое внешнее объединение (Left Join). Объединяются все записи таблицы со стороны один (one) и только те записи таблицы со стороны многие (many), значения связанного поля которых совпадают со значениями соответствующего поля первой таблицы. Попросту говоря, к результатам выборки по внутреннему объединению добавятся все записи из таблицы со стороны один (one), первоначально в нее не вошедшие. Соответствующие поля этих записей второй таблицы в выборке будут иметь пустое (Null) значение.
• Правое внешнее объединение (Right Join). Аналогично левому внешнему объединению, но таблицы со стороны один (one) и со стороны многие (many) меняются ролями, т.е. к результатам выборки по внутреннему объединению добавятся не вошедшие в нее записи из таблицы со стороны многие (many).