Что используется для обеспечения ссылочной целостности в подчиненной таблице

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Кортежи дочернего отношения, нарушающие это условие, называются висящими.

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

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

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

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

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

Проиллюстрируем применение этого правила следующим примером.

Пусть даны два отношения:

Мы видим, что кортежи дочернего отношения (2, …) и (2, …) ссылаются на кортеж (…, 2) родительского отношения, а кортеж (3, …) дочернего отношения ссылается на кортеж (…, 3) родительского отношения. Кортеж (100, …) дочернего отношения является висящим, он недопустим.

Здесь только кортежи родительского отношения (…, 1) и (…, 4) допускают обновление значений ключа и удаление кортежей, потому что на них не ссылается ни один из внешних ключей дочернего отношения.

Составим оператор создания базового отношения, включающего в себя объявление всех вышеназванных ключей:

Create table Родительское отношение

primary key (Primary_key)

Create table Дочернее отношение

foreign key (Foreign_key) references Родительское отношение (Primary_key)

on update Restrict

on delete Restrict

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

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

Create table Родительское отношение

primary key (Primary_key)

Create table Дочернее отношение

foreign key (Foreign_key) references Родительское отношение (Primary_key)

on update Cascade

on delete Cascade

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

Таким образом, действительно, правило Cascade обеспечивает каскадное обновление всех кортежей дочернего отношения в ответ на обновления отношения родительского.

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

Рассмотрим пример, который мы уже использовали ранее. Пусть нам даны два базовых отношения:

Как можно заметить, атрибуты дочернего отношения допускают Null-значения, следовательно, правило Set Null в данном конкретном случае применимо.

Допустим теперь, что из родительского отношения был удален кортеж (…, 1), а кортеж (…, 2) обновлен, как и в предыдущем примере. Таким образом, родительское отношение принимает следующий вид:

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

На кортеж (…, 1) не ссылался ни один ключ дочернего отношения, поэтому его удаление не влечет за собой никаких последствий.

Сам оператор создания базового отношения с использованием правила Set Null при объявлении внешних ключей отношения выглядит следующим образом:

Create table Родительское отношение

primary key (Primary_key)

Create table Дочернее отношение

foreign key (Foreign_key) references Родительское отношение (Primary_key)

on update Set Null

on delete Set Null

Итак, мы видим, что наличие трех различных правил поддержания ссылочной целостности обеспечивают то, что во фразах on update и on delete функции могут быть разными.

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

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

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

Данный текст является ознакомительным фрагментом.

Продолжение на ЛитРес

Приобретение ссылочной массы

Наращивание ссылочной массы и ожидания от поискового продвижения

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

Обеспечение ссылочной целостности с помощью индексов

Обеспечение ссылочной целостности с помощью индексов В определении индекса имеется еще одна опция - UNIQUE. Если ее указать, то индекс позволит заносить в таблицу только уникальные значения. Фактически это служит основой для реализации уникальных ключей (UNIQUffi KEY).

Расширенные возможности поддержки ссылочной целостности с помощью внешнего ключа

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

Глава 19. ПОДДЕРЖКА ЦЕЛОСТНОСТИ ВАШИХ ДАННЫХ

Глава 19. ПОДДЕРЖКА ЦЕЛОСТНОСТИ ВАШИХ ДАННЫХ РАНЕЕ В ЭТОЙ КНИГЕ, МЫ УКАЗЫВАЛИ НА ОПРЕДЕЛЕННЫЕ связи которые существуют между некоторыми полями наших типовых таблиц. Поле snum таблицы Заказчиков, например, соответствует полю snum в таблице Продавцов и таблице Порядков. Поле cnum

3.5. Контроль целостности с Xintegrity

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

Использование ссылочной целостности для поддержания непротиворечивости данных

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

3. Ограничение целостности по состоянию

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

Ограничения целостности

Ограничения целостности Ограничения целостности устанавливают правила, которые управляют состоянием доступных элементов данных или отношением между столбцом и таблицей, как целое - часто и тем, и другим. Примерами являются NOT NULL (не допускает ввод, содержащий

Ограничения целостности

Ограничения целостности Ограничение NOT NULL Firebird не поддерживает атрибут указания допустимости пустого значения, как это делают некоторые нестандартные СУБД. В соответствии со стандартами все столбцы в Firebird могут содержать пустое значение, если не будет явно указано

Действия триггеров по изменению правил целостности

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

Предложения действия ссылочной целостности

Предложения действия ссылочной целостности Триггеры ссылочной целостности являются модулями компилированного кода, создаваемыми ядром сервера, когда вы объявляете ограничение ссылочной целостности для ваших таблиц. Включив предложения действия ON UPDATE и ON DELETE В

Содержание важнее целостности

Этот слой содержит данные с естественными индексами UNIQUE и суррогатным ключом, который легко переносится.

Натуральные клавиши

В качестве альтернативы, две приведенные выше таблицы могут быть без ID и использовать фамилию и имя FirstName как естественные первичные ключи, как объяснил Майк Шеррилл. В этом случае предположим, что слой ниже ссылок varchar , а не int .

В этом слое используется составной индекс. Это значение может быть UNIQUE или PRIMARY , в зависимости от того, используется ли суррогатная клавиша в качестве Первичного ключа.

В этом слое отношения между людьми исследуются через таблицу ParentsOf .

Предполагая, что ссылочная целостность ОЧЕНЬ важна для меня в самом ее ядре, и у меня будет FOREIGN KEYS по этим индексам, чтобы я сохранил базу данных, ответственную за мониторинг ее собственной целостности на этом фронте, и что, если бы я был используйте ORM, это было бы похоже на Doctrine, у которого есть встроенная поддержка Compound Primary Keys.

Пожалуйста, помогите мне понять:

Список компромиссов, которые имеют место с использованием суррогатных ключей против естественных ключей на 1-м слое.

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

Мне не интересно слышать, что лучше, потому что я понимаю, что среди профессионалов есть серьезные разногласия по этой теме, и это будет причиной религиозной войны. Вместо этого я прошу, очень просто и объективно, насколько это возможно по-человечески, какие компромиссы вы будете принимать, передавая суррогатные ключи каждому слою и поддерживая первичные ключи (естественные/составные, или суррогатные/композитные). Любой сможет найти кого-то, кто говорит НИКОГДА или ВСЕГДА использовать суррогатные ключи на SO и других сайтах. Вместо этого, мотивированный анализ компромиссов - это то, что я больше всего ценю в ваших ответах.

EDIT: Было указано, что пример фамилии является плохим примером использования 6NF. Ради сохранения неповрежденного вопроса, я собираюсь это оставить. Если у вас возникли проблемы с представлением об этом прецедента, лучшим может быть список "Продуктов бакалеи". AKA:

Пример натурального композитного ключа:

Повторяю, это также просто пример. Это не то, как я бы рекомендовал продолжить, но это должно помочь проиллюстрировать мой вопрос.

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

Ниже приведены некоторые очень хорошие ответы, и если вам интересно, в каком направлении идти, прочитайте их.

END EDIT

ОТВЕТЫ

Ответ 1

Вот некоторые компромиссы:

Одиночный суррогат (искусственно создан):

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

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

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

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

Натуральные составные таблицы с ключами:

меньше индексов в базе данных

меньше столбцов в базе данных

проще/быстрее вставить тонну записей, так как вам не потребуется захватить генератор последовательности

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

Тогда есть другая категория: первичные ключи с искусственным композитом

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

Например, предположим, что у вас была база данных, в которой хранились данные для 50 000 клиентов, и каждый клиент не должен был видеть другие данные клиента - очень распространенный в разработке веб-приложений.

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

Первое, что нужно сделать, это настроить первичные и внешние ключи. Обычно таблица с полем id в качестве первичного ключа. Добавив client_id , ключ теперь является составным. И нужно переносить client_id на все дочерние таблицы.

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

После этого вы создадите представления (или, если используете Oracle EE setup Virtual Private Database) и другие различные структуры, чтобы база данных обеспечивала безопасность уровня строки (которая является темой, которой она владеет).

Предположим, что эта структура данных больше не нормализована до n-й степени. Поле client_id в каждом pk/fk денормализует нормальную модель в противном случае. Преимущество модели заключается в простоте обеспечения безопасности на уровне строк на уровне базы данных (что и должно делать базы данных). Каждый выбор, вставка, обновление, удаление ограничивается любым client_id вашим сеансом в данный момент. База данных имеет осведомленность о сеансе.

Резюме

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

Самое большое преимущество, на мой взгляд, следующее:

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

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

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

Натуральные ключи, особенно сложные NKey, делают код письма болью. Когда вам нужно присоединиться к 4 таблицам, предложение "where" будет намного длиннее (и проще испортить), чем когда были использованы одиночные SKey.

Суррогатные ключи - это "безопасный" маршрут. Естественные ключи полезны в нескольких местах, я бы сказал около 1% таблиц в db.

Ответ 2

Прежде всего, ваш второй уровень может быть выражен как минимум четырьмя различными способами, и все они имеют отношение к вашему вопросу. Ниже я использую псевдо-SQL, в основном с синтаксисом PostgreSQL. Для некоторых типов запросов потребуется рекурсия и несколько дополнительных индексов независимо от структуры, поэтому я больше не буду об этом говорить. Использование dbms, поддерживающего кластерные индексы, может повлиять на некоторые решения здесь, но не предполагайте, что шесть объединений кластеризованных индексов будут быстрее, чем просто считывать значения из одного, охватывающего индекса; тест, тест, тест.

Во-вторых, на первом уровне действительно не так много компромиссов. Внешние ключи могут ссылаться на объявленный столбец not null unique точно так же, как они могут ссылаться на объявленный столбец primary key . Суррогатный ключ увеличивает ширину таблицы на 4 байта; что тривиально для большинства, но не для всех приложений баз данных.

В-третьих, правильные внешние ключи и уникальные ограничения будут поддерживать ссылочную целостность во всех четырех этих проектах. (Но см. Ниже "О каскадах".)

а. Иностранные ключи для суррогатных ключей

В. Внешние ключи к натуральным клавишам

С. Внешние ключи к суррогатным клавишам, дополнительный ключ суррогата

Д. Внешние ключи к натуральным клавишам, дополнительный ключ суррогата

Теперь посмотрим на таблицу ParentsOf.

а. Внешние ключи для суррогатных ключей в A, выше

Чтобы получить имена для данной строки, вам понадобится четыре соединения. Вы можете напрямую присоединиться к таблицам "FirstNames" и "Surnames"; вам не нужно входить в таблицу "Люди", чтобы получить имена.

В. Внешние ключи к естественным клавишам в B, выше

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

С. Внешние ключи к суррогатным клавишам, дополнительный суррогатный ключ в C, выше

Чтобы получить имена, вы должны присоединиться к таблице "people". Вам понадобится в общей сложности шесть объединений.

Д. Внешние ключи к натуральным клавишам, дополнительный суррогатный ключ в D, выше

Эта конструкция имеет ту же структуру, что и в C, как указано выше. Поскольку таблица "people" в D, дальше выше, имеет естественные ключи, ссылающиеся на таблицы "FirstNames" и "Surnames", вам понадобятся только два соединения с таблицей "люди", чтобы получить имена.

Об ORM

ORM не создают SQL так, как SQL-разработчик пишет SQL. Если разработчик SQL записывает инструкцию SELECT, которая требует шести соединений для получения имен, ORM может выполнить семь простых запросов для получения одних и тех же данных. Это может быть проблемой; это может быть не так.

О каскадах

Суррогатные идентификационные номера делают каждую ссылку на внешний ключ неявным, необъявленным "ON UPDATE CASCADE". Например, если вы запустите это выражение обновления против своей таблицы фамилий.

тогда все Смиты станут Смитами. Единственный способ предотвратить это - отменить разрешения на обновление "фамилий". Неявный, необъявленный "ON UPDATE CASCADE" - это не всегда хорошая вещь. Отмена разрешений исключительно для предотвращения нежелательных неявных "каскадов" не всегда хорошая вещь.

Ответ 3

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

Вещи, которые могут повлиять на ваш выбор:

• как обращаться с отдельными записями, которые могут иметь одинаковые естественные ключи. Например, идентичное имя и фамилия.
• как веб-клиент или мобильный клиент сохраняют сложный графический граф, если сервер назначил суррогатные ключи (требуется какой-то слой отображения). Альтернатива заключается в том, чтобы избежать проблемы с отображением и использовать назначенные клиентом UUID v4.
• следуя вышеизложенному, как вы справляетесь с разрешением конфликтов в временно отключенных средах, таких как мобильные приложения или где клиенты могут находить/делиться друг с другом без предварительной синхронизации с сервером. Идентификация объектов - важная концепция поддержки и решения этих проблем.
• Масштабируемость через очертание вашей базы данных может быть легкой или сложной на основе выбора ключа. Автоматическое увеличение суррогатных ключей трудно очертить и требует выбора фиксированного количества осколков a-priori, поэтому ключи не сталкиваются, в то время как v4 UUID-суррогатные ключи легки и могут быть назначены клиентом. Композитные и естественные ключи сложны, потому что ключ, в то время как относительно стабильный может все же измениться, и для этого требуется возможность переноса записей с одного осколка на другой.
• Как ваши клиенты управляют идентификацией объекта? Часто пользовательские интерфейсы требуют создания локального графика моделей для дальнейшей стойкости к "серверу в облаке". За это время до настойчивости эти объекты нуждаются в идентификации, и после настойчивости должно быть соглашение или сопоставление между идентификатором объекта сервера и идентификатором объекта клиента.
• Вы вынуждаете все, что находится над базой данных (включая сервер приложений) для решения проблемы сопоставления идентичности, или создаете ее в дизайне ключа базы данных, а также помогаете решить задачу масштабирования /sharding для db, пока вы это используете?

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

Ответ 4

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

Ответ 5

Я видел этот список критериев для первичного ключа. Я считаю это довольно хорошей отправной точкой для такого обсуждения

• уникальный
• стабильный (необязательно непреложный)
• неприводимым
• просто
• знак

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

Один из недостатков суррогатных ключей состоит в том, что становится сложнее применять декларативные правила (большинство СУБД не поддерживают вспомогательные запросы в контрольных ограничениях). Я думаю о правилах вроде:

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

Ответ 6

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

Пример с таблицей пользователя:

Джон заполнил информацию, затем решил удалить ее и заполнить новую.

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

Он также быстрее восстанавливает индексы для целых чисел и занимает меньше места на диске.

Ответ 7

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

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

Но если в качестве ключа мы выберем суррогатный ключ, нам нужно будет найти другой способ предотвратить такое дублирование.

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

Ответ 8

Я думаю, вы неправильно поняли что-то фундаментальное в отношении данных:

1) Вы принимаете один идентификатор (имя человека - при условии, что оно однозначно идентифицирует человека), разделяя его на субатомные части, тогда из-за 6NF, помещая их в отдельные переменные отношения. Часто такой раскол делается по практическим соображениям, и первое имя/фамилия является распространенным примером; решение обычно делается по причине сложности, частоты и т.д. расщепления по сравнению с тем, что снова возвращает атрибут. Здесь раскол не практичен.

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

3) Для идентификаторов людей соединение с именами и фамилиями редко бывает адекватным. Идентификаторы обычно выбираются исходя из требуемого уровня доверия. Работодатель проверяет ссылки, квалификацию и т.д., Затем выдает ссылку на заработную плату. Полицейское предложение может потребовать осмотра водительских прав у дороги, но отпечатки пальцев будут приняты, если вы будете признаны виновными в совершении преступления. СУБД не может проверить человека, и поэтому числовое число с автоматическим добавлением также редко бывает адекватным.

Читайте также:

  
• Что из перечисленного не обозначало в россии 19 века места заключения осужденных
  
• Как нелегально попасть в турцию
  
• В каких случаях происходило безвозмездное выделение дарственных наделов
  
• Почему я должна платить за должников
  
• Пособие по восстановлению позо статических функций что это