ключ в реляционном отношении может

Ключ отношения

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

Содержание

Смысл

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

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

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

Классификация

Простые и составные ключи

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

Естественные и суррогатные ключи

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

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

Источник

Ключ в реляционном отношении может

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

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

Понятие первичного ключа

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

Данные таблицы «Преподаватель»

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

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

Реляционные отношения (связи) между таблицами базы данных

Существует три разновидности связей между таблицами базы данных:

Отношение «один-ко-многим» имеет место, когда одной записи родительской таблицы может соответствовать несколько записей в дочерней таблице.

Связь «один-ко-многим» является самой распространенной для реляционных баз данных.

В широко распространенной нотации структуры баз данных IDEF 1 X отношение « один-ко-многим » изображается путем соединения таблиц линией, которая на стороне дочерней таблицы оканчивается кружком или иным символом. Поля, входящие в первичный ключ для данной ТБД, всегда расположены вверху и отчеркнуты от прочих полей линией.

Отношение «один-к-одному» имеет место, когда одной записи в родительской таблице соответствует одна запись в дочерней таблице.

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

Отношение «многие-ко-многим» имеет место, когда:

а) записи в родительской таблице может соответствовать больше одной записи в дочерней таблице;

б) записи в дочерней таблице может соответствовать больше одной записи в родительской таблице.

Например, каждой студент изучает несколько дисциплин. Каждая дисциплина изучается несколькими студентами.

Многие СУБД (в частности Access ) не поддерживают связи «многие-ко-многим» на уровне индексов и ссылочной целостности. Считается, что всякую связь «многие-ко-многим» можно заменить на одну или более связей «один-ко-многим».

Ссылочная целостность и каскадные воздействия

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

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

· изменение значения поля связи в записи родительской таблицы без изменения значений полей связи в соответствующих записях дочерней таблицы;

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

Чтобы предотвратить потерю ссылочной целостности, используется механизм каскадных изменений. Он состоит в обеспечении следующих требований:

· необходимо запретить изменение поля связи в записи дочерней таблицы без синхронного изменения полей связи в родительской таблице;

· при изменении поля связи в записи родительской таблице, следует синхронно изменить значения полей связи в соответствующих записях дочерней таблицы;

· при удалении записи в родительской таблице, следует удалить соответствующие записи в дочерней таблице.

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

Понятие внешнего ключа

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

Индексы и методы доступа

Индексы представляют собой механизмы быстрого доступа к данным в таблицах БД.

Сущность индексов состоит в том, что они хранят значения индексных поле (т.е. полей, по которым построен индекс) и указатель на запись в таблице.

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

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

Определение первичных и внешних ключей таблиц БД приводят к созданию индексов по полям, объявленным в составе первичных или внешних ключей.

Нормализация таблиц при проектировании БД

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

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

Первая нормальная форма (1НФ) требует, чтобы каждое поле таблицы БД:

· не содержало повторяющихся групп.

Неделимость поля означает, что значение поля не должно делиться на более мелкие значения. Например, если в поле «Подразделение» содержится название факультета и название кафедры, требование неделимости не соблюдается и необходимо из данного поля выделить или название факультета, или кафедры в отдельное поле.

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

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

Третья нормальная форма (ЗНФ) требует, чтобы значение любого поля таблицы, не входящего в первичный ключ, не зависело от значения другого поля, не входящего в первичный ключ.

Пример логической модели базы данных «Сессия»

Источник

Ключ в реляционном отношении может

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

называется потенциальным ключом.

Потенциальный ключ играет роль адреса кортежа (строки) в отношении (таблице). В одной таблице может быть несколько потенциальных ключей.

Пример таблицы с несколькими потенциальными ключами

Есть очень маленькая вероятность того, что на одном заводе будут работать два человека с однинаковыми ФИО, родившиеся в одном месте одновременно. Пренебрежём этим событием.

Определение. Первичным ключом называется потенциальный ключ, выделенный особо и не содержащий значения NULL.

Остальные потенциальные ключи называются альтернативными.

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

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

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

Такая дополнительная колонка называется суррогатным ключом. Она нужна только для идентификации строк таблицы.

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

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

Пример. Сущности Факультет и Кафедра имеют связь типа один ко многим. Им соответствуют таблицы Fak и Kaf. Для отображения связи один ко многим служат первичный ключ ID в таблице Fak и внешний ключ IdFak в в таблице Kaf.

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

Формальное определение внешнего ключа выглядит очень абстрактно.

Множество атрибутов FK, принимающее значения только из значений множества PK, называется внешним ключом.

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

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

Использование составных ключей для связи таблиц увеличивает вероятность нарушения целостности базы данных по сравнению с использованием простых ключей. В приведённом примере при изменении номера цеха придётся вносить изменения в две таблицы: Участок и План. Количество участков в цехе невелико, обычно меньше десяти, а в таблице План придётся изменить сотни строк. При использовании простых ключей вносить изменения в таблицу План не потребовалось бы.

ЦЕЛОСТНОСТЬ БАЗЫ ДАННЫХ

Любая реальная база данных содержит в себе огромное количество семантических и синтаксических связей. Нарушение хотя бы одной из них может привести к получению неверных результатов запросов пользователей. Лёгкость, с которой база данных может быть приведена в негодное для эксплуатации состояние отображается в термине целостность. Базу данных без принятия очень трудоёмких мер легко «разбить», привести в негодность. Точное определение целостности дать практически невозможно. Существует множество толкований этого понятия. Вот одно из таких толкований.

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

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

Нарушение целостности атрибута

К этой группе нарушений целостности относится пример 1, в котором дата 43.25.2016 имеет недопустимые значения дня и месяца. Эта проблема легко устраняется правильным выбором типа данных. Но проблема контроля даты сложнее, чем может показаться на первый взгляд. Например дата 03-25-12 в формате, принятом в США, читается так: 25-е марта 2012 года. Существует большое количество форматов дат. В разных СУБД форматы дат различны. Для текстовой информации очень важен выбор кодировки. При неправильном выборе кодировки на экране монитора вместо русских букв (кириллицы) появятся странные значки (крякозябры).

Эффективным средством предотвращения ошибок при вводе данных является предложение пользователю выбрать, если это возможно, значение из списка, т.е. домена атрибута. Примеры практически возможных доменов: все научные степени и звания преподавателя, все регионы России, все факультеты одного вуза (см. Лабораторная работа № 1. ).

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

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

Самостоятельно постройте реляционную модель, соответствующую инфологической модели расписания, приведённой в лекции Модель сущность-связь

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

Практические приёмы поддержания целостности данных

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

Рассмотрим три приема поддержания целостности данных.

1. Теоретический домен, в котором находятся все возможные значения атрибута, заменяется на таблицу-справочник.

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

Таблица Численность населения

Создадим таблицу Страна состоящую из двух столбцов: КодСтраны и Название, а в таблице Численность населения заменим название страны на её код из таблицы Страна. Теперь, если изменится название страны, его придётся менять только один раз в таблице Страна.

Таблица Численность населения

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

2. Неудаляемые записи. Для устранения возникших по злому умыслу или случайно нарушений целостности даннных можно использовать такую организацию данных, при которой записи не удаляются, а лишь помечаются как удалённые и становятся невидимыми пользователю. Для этого в таблицу добавляются столбцы Ngr и priznak. Когда в таблице появляется новая запись, ей присваивается уникальный номер группы и признак d (действующая). При редактировании в этой записи меняется лишь признак на s (старая), а результаты редактирования помещаются в новую запись с тем же номером группы и признаком d (действующая). Запись которую пытается удалить пользователь, помечается признаком u (удалённая). При выборке все записи с признаками s и u игнорируются. При обнаружении искажения данных администратор базы данных читает все записи, в том числе и исправленные и удалённые. Чтобы установить виновного в ошибке, к таблице добавляются ещё два столбца: Кто и Когда, в которых фиксируется пользователь, внёсший запись, и дата внесения. В приведённом примере сделка с акциями эмитента Алмаз была создана, затем дважды отредактирована. Сделка с акциями змитента Сапфир удалена.

Пример таблицы с неудаляемыми записями

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

Источник

Основы реляционной алгебры

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

Так что если вы собираетесь начать свое обучение в этой области или вам просто стало интересно, прошу под кат.

Реляционная база данных

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

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

таблица PRODUCTS

Таблица состоит из 4х строк, строка в таблице является кортежем в реляционной теории. Множество упорядоченных кортежей называется отношением.
Перед тем как дать определение отношения, введем еще один термин — домен. Домены применительно к таблице это столбцы.

Для ясности, теперь введем строгое определение отношения.

Ключи в отношениях

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

Видно, что в организации может быть несколько водителей, и чтобы однозначно идентифицировать водителя необходимо и значение из столбца “Название организации” и из “Имя водителя”. Такой ключ называется составным.

В реляционной БД таблицы взаимосвязаны и соотносятся друг с другом как главные и подчиненные. Связь главной и подчиненнной таблицы осуществляется через первичный ключ (primary key) главной таблицы и внешний ключ ( foreign key ) подчиненной таблицы.
Внешний ключ это атрибут или набор атрибутов, который в главной таблице является первичным ключем.

Этой подготовительной теории будет достаточно для знакомства с основными операциями реляционной алгебры.

Операции реляционной алгебры

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

Условимся, что в этой таблице ID это внешний ключ, связанный с первичным ключом таблицы PRODUCTS.

Для начала рассмотрим самую простую операцию — имя отношения. Её результатом будет такое же отношение, то есть выполнив операцию PRODUCTS, мы получим копию отношения PRODUCTS.

Проекция

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

Синтаксис операции:
π _{(ID, PRICE)} PRODUCTS

В результате этой операции получим отношение:

Выборка

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

Синтаксис операции:
σ _(PRICE>90) PRODUCTS

В условии выборки мы можем использовать любое логическое выражение. Сделаем еще одну выборку с ценой больше 90 и ID товара меньше 300:

σ _{(PRICE>90 ^ ID π COMPANY σ (PRICE 123ПеченькиООО ”Темная сторона”190123OOO “Дарт”156ЧайООО ”Темная сторона”60156ОАО ”Ведро”123ПеченькиООО ”Темная сторона”190156ОАО ”Ведро”156ЧайООО ”Темная сторона”60123OOO “Дарт”}

Для примера использования этой операции представим себе необходимость выбрать продавцов с ценами меньше 90. Без произведения необходимо было бы сначала получить ID продуктов из первой таблицы, потом по этим ID из второй таблицы получить нужные имена SELLER, а с использованием произведения будет такой запрос:

Источник