Ничего из этого не нужно, особенно не , удваивающий столы . Это чистое безумие.
Введение
Поскольку Стандарт моделирования реляционных баз данных (IDEF1X) широко используется более 25 лет (по крайней мере, для рынка с высоким качеством и высокой производительностью), я использую эту терминологию. Дата и Дарвен, несмотря на 1 , согласующиеся с большой работой, проделанной ими для прогресса подавления модели отношений , они не знали о IDEF1X пока я не довел это до их сведения в 2009 году, и поэтому у него появилась новая терминология 2 для стандартной терминологии, которую мы использовали десятилетиями. Кроме того, новая терминология охватывает не все случаи, как это делает IDEF1X. Поэтому я использую установленную стандартную терминологию и избегаю новой терминологии.
Даже концепция «распределенного ключа» не может распознать лежащие в основе обычные отношения PK :: FK, их реализацию в SQL и их мощность.
Реляционная и, следовательно, IDEF1X концепция: Идентификаторы и их миграция.
Конечно, продавцы не совсем в курсе, и у них есть странные вещи, такие как «частичные индексы» и т. Д., Которые совершенно не нужны, когда понятны основы. Но знаменитые «академики» и «теоретики» придумали неполные новые концепции, когда концепция была стандартизирована и полностью рассмотрена 25 лет назад ... это неожиданно и неприемлемо.
Протест
IEC / ISO / ANSI SQL едва обрабатывает 3NF Кодда (Date & Darwen's 5NF) адекватно, и он вообще не поддерживает структуры Basetype-Subtype; для этого нет (и должно быть) декларативных ограничений.
- Поэтому, чтобы обеспечить полный набор правил, выраженных в модели данных, как Basetype :: Subtype и Subtype :: Basetype, нам нужно немного поиграться с
CHECK CONSTRAINT s и т. Д. (Я избегаю использовать триггеры для ряд причин).
Облегчение
Однако я все это учитываю. Для того чтобы я мог эффективно предоставлять услугу моделирования данных в StackOverflow без необходимости предварять это полным дискурсом, я намеренно предоставляю модели, которые могут быть реализованы способными людьми, использующими существующий SQL и существующие ограничения, в той степени, в которой они требуют. Он уже упрощен и содержит общий уровень исполнения. Если есть какие-либо вопросы, просто спросите, и вы получите.
Мы можем использовать как иллюстративный рисунок в связанном документе, так и вашу полностью совместимую с IDEF1X Модель данных датчика
Читатели, которые не знакомы со стандартом реляционного моделирования, могут найти IDEF1X примечание полезным.
Читателям, которые считают, что база данных может быть сопоставлена с объектами, классами и подклассами, рекомендуется, чтобы дальнейшее чтение могло причинить вред. Это дальше, чем прочитали Фаулер и Амблер.
Реализация ссылочной целостности для базового типа-подтипа
Существует два типа структур подтип Базовый тип.
Эксклюзивный подтип
Исключительно означает, что для каждой строки базового типа должна быть одна и только одна строка подтипа. В терминах IDEF1X должен быть столбец Discriminator в базовом типе, который идентифицирует существующую для него строку подтипа.
Для более чем двух подтипов это требуется, и я реализую столбец Дискриминатор.
Для двух подтипов, поскольку они легко выводятся из существующих данных (например, Sensor.IsSwitch - это дискриминатор для Reading), я не моделирую дополнительный явный столбец дискриминатора для Reading. Тем не менее, вы можете следовать Стандарту к письму и применять дискриминатор.
Я подробно рассмотрю каждый аспект.
TheДля столбца дискриминатора требуется CHECK CONSTRAINT, чтобы убедиться, что он находится в диапазоне значений, например: IN ("B", "C", "D").IsSwitch - это BIT, то есть 0 или 1, поэтому оно уже ограничено.
Поскольку PK базового типа определяет его уникальность, будет разрешена только одна строка базового типа.;никакая вторая строка базового типа (и, следовательно, никакая вторая строка подтипа) не может быть вставлена.
Следовательно, это избыточный, полностью избыточный, дополнительный ненужный индекс для реализации индекса, такого как (PK, Discriminator), в базовом типе, как рекомендует ваша ссылка.Уникальность в PK, и, следовательно, PK плюс все будет уникальным).
IDEF1X не требует Дискриминатор в таблицах подтипа.В Подтипе, который опять-таки ограничен уникальностью своего PK, согласно модели, если Дискриминатор был реализован как столбец в этой таблице, каждая строка в нем будет иметь одинаковое значение для Дискриминатора (каждая Книга будет "B "; каждый ReadingSwitch будет IsSwitch).Поэтому абсурдно использовать дискриминатор как столбец в подтипе.И снова, полностью избыточный, дополнительный ненужный Индекс для реализации Индекса, такого как (PK, Discriminator) в Подтипе: уникальность в PK, и, следовательно, PK плюс что-либо будет уникальным).
Метод, идентифицированный в ссылке, представляет собой неуклюжий и раздутый (массовое дублирование данных без цели) способ реализации ссылочной целостности.Вероятно, есть веская причина, по которой автор не видел эту конструкцию где-либо еще.Это основной недостаток понимания SQL и его эффективного использования , как и .Эти «решения» типичны для людей, которые следуют догме «SQL не может сделать ...» и, следовательно, не знают, что может делать SQL.Ужасы, вызванные слепыми «методами» Фаулера и Амблера, еще хуже.
Подтип PK - это также FK для Базового типа, то есть все, что требуется для гарантии того, что Подтип не существует без родительского Базового типа.
- Поэтому для любого данного PK, какой бы Базовый тип-Подтип был вставлен первым, будет успешным;и какой бы Базовый тип-Подтип не был предпринят после этого, произойдет сбой.Поэтому в таблице подтипов не о чем беспокоиться (вторая строка базового типа или вторая строка подтипа для того же PK запрещены).
.
SQL CHECK CONSTRAINT ограничен проверкой вставленной строки .Нам нужно сравнить вставленную строку с другими строками , либо в той же таблице, либо в другой таблице.Следовательно, требуется функция, определяемая пользователем.
Напишите простой UDF, который проверит наличие PK и Discriminator в базовом типе, и вернет 1если EXITS или 0, если NOT EXITS.Вам понадобится один UDF для каждого Базового типа (не для Подтипа).
В Подтипе реализуйте CHECK CONSTRAINT, который вызывает UDF, используя PK (который является и Базовым типом, иПодтип) и Дискриминатор значение .
Я реализовал это в десятках больших баз данных реального мира на разных платформах SQL.Вот «Определенный пользователем» Код функции и Код DDL для объектов, на которых он основан.
Этот конкретный синтаксис и код протестирован на Sybase ASE 15.0.2 (они очень консервативны в отношении соответствия стандартам SQL).
Я знаю, что ограниченияна «Пользовательские» Функции различны для каждой платформы SQL.Тем не менее, это самый простой из простых, и AFAIK каждая платформа позволяет эту конструкцию.(Понятия не имею, что делают не-SQL.)
да, конечно, этот умный маленький метод можно использовать для реализации любого нетривиального правила данных, которое вы можете нарисовать в модели данных.В частности, чтобы преодолеть ограничения SQL.Обратите внимание на мое предостережение во избежание двусторонних ограничений (циклические ссылки).
Следовательно, CHECK CONSTRAINT в Подтипе гарантирует, что в Базовом типе существует PK плюс правильный Дискриминатор. Это означает, что только этот подтип существует для базового типа (PK).
Любая последующая попытка вставить другой подтип (т. Е. Нарушить исключающее правило) завершится неудачей, поскольку в базовом типе отсутствует дискриминатор PK +.
Любая последующая попытка вставить другую строку того же подтипа предотвращается уникальностью ограничения PK.
Единственный пропущенный бит (не упомянутый в ссылке) - это правило "каждый базовый тип должен иметь хотя бы один подтип" не применяется. Это легко описывается в транзакционном коде (я не советую ограничения, идущие в двух направлениях, или триггеры); используйте подходящий инструмент для работы.
Неисключительный подтип
Базовый тип (родительский) может содержать более одного подтипа (дочерний)
Нет единого подтипа для идентификации.
Просто исключите CHECK CONSTRAINT, который вызывает UDF выше.
-
PRIMARY KEY, FOREIGN KEY и обычный диапазон CHECK CONSTRAINT с адекватно поддерживают все требования для неисключительных подтипов.
Ссылки
Для более подробной информации; схематический обзор, включая детали; и различие между таблицами подтипов и необязательных столбцов, см. этот документ подтипа .
Примечание
Меня тоже приняли постоянные ссылки С. Дж. Дейта и Хью Дарвена на "продвижение" реляционной модели . После многих лет взаимодействия, основанного на гору последовательных доказательств, я пришел к выводу, что их работа фактически сводит на нет ее. Они ничего не сделали для дальнейшей плодотворной работы д-ра Е. Ф. Кодда, реляционной модели , и всего, что может повредить и подавить ее.
У них есть частные определения для реляционных терминов, что, конечно, серьезно мешает любому общению. У них есть новая терминология для терминов, которые мы использовали с 1970 года, чтобы показать, что они «изобрели» ее. Типично для мошенников и воров.
Ответ на комментарий
Этот раздел может быть пропущен всеми читателями, которые не комментировали.
К сожалению, некоторые люди настолько обучены тому, чтобы делать вещи неправильно (как советуют уроды, которые называют «теоретиками» в этом пространстве), с огромными дополнительными затратами, что даже если их направить четко в правильном направлении, они не могут понимать это. Возможно, именно поэтому правильное образование нельзя заменить форматом вопросов и ответов.
Сэм:
Я заметил, что этот подход не мешает кому-либо использовать UPDATE для изменения значения дискриминатора базового типа. Как это можно предотвратить? FOREIGN KEY + дубликат столбца Дискриминатор в подходе подтипов, кажется, преодолевает это.
Да. Этот метод не запрещает кому-либо использовать UPDATE для изменения ключа или столбца в какой-либо не связанной таблице или головной боли. Он отвечает на конкретный вопрос, и ничего больше. Если вы хотите запретить определенные команды DML или что-то еще, используйте средство SQL, предназначенное для этой цели. Все это выходит за рамки этого вопроса. В противном случае каждый ответ должен касаться каждой не связанной проблемы.
Ответ. Поскольку мы должны использовать Стандарты открытой архитектуры , доступные с 1993 года, все изменения в БД осуществляются только через транзакции ACID. Это означает прямое INSERT/UPDATE/DELETE, все таблицы запрещены; данные сохраняют целостность и согласованность (терминология ACID). В противном случае, конечно, у вас кровоточащий беспорядок, такой как ваш например. и последствия. Эти уроды не понимают транзакции, они понимают только один файл INSERT/UPDATE/DELETE. Опять же, выходит за рамки. Если вам нужна более подробная информация, пожалуйста, откройте новый вопрос, и я отвечу на него подробно.
Кроме того, индекс FK + Duplicate D + Duplicate Index (и огромные затраты в нем!) Ничего подобного не делает, я не знаю, откуда у вас "кажется".
dtheodor:
Этот вопрос о ссылочной целостности. Ссылочная целостность не означает «проверить, что ссылка действительна при вставке и забыть об этом». Это означает «сохранить действительность ссылки навсегда». Метод дубликатов дискриминатор + FK гарантирует эту целостность, а ваш подход UDF - нет. Без сомнения, UPDATE s не должно нарушать ссылку.
Проблема здесь двоякая. Во-первых, вам необходимо базовое образование по другим областям по реляционным базам данных и стандартам открытой архитектуры. Во-вторых, вам нужно перепрограммирование, потому что, хотя я дал вам ответ, вы не понимаете его, вы рабски повторяете культовую мантру, что этот конкретный метод не делает того, что делает массово неэффективный метод культа. Если не повторять мою просьбу открыть новый вопрос и, таким образом, дать полный ответ на ту другую область реляционных баз данных, которую вы, очевидно, не понимаете (никто из культа Дейта и Дарвена не понимает основ реляционных баз данных), я действительно не знаю что делать.
Хорошо, короткий ответ, который действительно относится к другому вопросу Как дискриминатор в эксклюзивных подтипах защищен от недействительного обновления?
Clarity. Да, Ссылочная целостность не означает «проверить, что ссылка действительна при вставке, и забыть об этом» . Я не сказал, что это также означало.
Ссылочная целостность означает, что ссылки в базе данных FOREIGN KEY имеют целостность с PRIMARY KEY, на который она ссылается.
Декларативная ссылочная целостность означает объявленные Ссылки в базе данных ...
CONSTRAINT ИНОСТРАННЫЙ КЛЮЧ ... REFERENCES ...
CONSTRAINT CHECK ...
поддерживаются платформой СУБД, а не кодом приложения.
Это не означает «поддерживать действительность ссылки всегда».
Оригинальный Вопрос касается RI для Подтипов, и я ответил на него, предоставив DRI.
- Следует подчеркнуть тот факт, что крайне неэффективные структуры и дублированные таблицы, как «учат» ваши лидеры культа, не требуются.
Ваш вопрос не касается RI или DRI.
Ваш вопрос, хотя и был задан неправильно, поскольку вы ожидаете, что метод предоставит то, чего метод не предоставляет, и вы не понимаете, что ваше требование выполняется другими способами, - это Как действует дискриминатор? в эксклюзивных подтипах, защищенных от недействительного обновления?
Ответ: используйте стандарты открытой архитектуры, которые мы должны использовать с 1993 года. Это предотвращает все недействительные UPDATE с. Если вам надоело читать связанные документы и понимать их, ваша проблема не является проблемой, она не существует. Это короткий ответ.
Но вы не поняли короткий ответ в первый и второй раз, чтобы вам не пришлось повторять мантру в третий раз, мне придется объяснить это. Вот. Не в том месте.
Никто не имеет права подойти к базе данных и изменить столбец здесь или значение там.Использование SQL напрямую или приложение, которое использует SQL напрямую.Если это было разрешено, у вас не будет защищенной базы данных, у вас будет проститутка в дешевом борделе.
Все обновления (в нижнем регистре) базы данных (включая многорядные *)1363 *) реализованы как транзакции ACID SQL.И ничего кроме Транзакций. набор Транзакций представляет собой API базы данных , который доступен любому приложению, использующему базу данных.
SQL имеет транзакции ACID.Номера для SQL не имеют транзакций.Ваш культ любит не SQL.Они абсолютно ничего не знают о транзакциях, пусть алоэ Open Architecture.Их Не-архитектура - это монолитный стек.И «база данных», которая подвергается рефакторингу каждый месяц.
Поскольку единственные транзакции, которые вы пишете, будут вставлять подтип basetype + в одну транзакцию, в качестве единой логической единицы работы,Целостность (целостность данных, а не ссылочная целостность) отношения basetype :: subtype поддерживается и поддерживается в базе данных.Поэтому все обновления в базе данных будут действительными, недействительных обновлений не будет.
Поскольку вы не настолько глупы, чтобы писать код, который UPDATE содержит столбец Дискриминатор водна строка без оператора DELETE Previous_Subtype, поместите его в транзакцию и GRANT EXEC разрешение для пользователя ROLES, в базе данных не будет недопустимого дискриминатора.