Вопросы Теги

В чем разница между идентифицирующими и неидентифицирующими отношениями?

Другое решение без регулярного выражения, которое хорошо работает на Python 3 

# Split strings and keep separator
test_strings = ['<Hello>', 'Hi', '<Hi> <Planet>', '<', '']

def split_and_keep(s, sep):
   if not s: return [''] # consistent with string.split()

   # Find replacement character that is not used in string
   # i.e. just use the highest available character plus one
   # Note: This fails if ord(max(s)) = 0x10FFFF (ValueError)
   p=chr(ord(max(s))+1) 

   return s.replace(sep, sep+p).split(p)

for s in test_strings:
   print(split_and_keep(s, '<'))


# If the unicode limit is reached it will fail explicitly
unicode_max_char = chr(1114111)
ridiculous_string = '<Hello>'+unicode_max_char+'<World>'
print(split_and_keep(ridiculous_string, '<'))
761
задан pnuts 4 January 2019 в 00:08
поделиться

5 ответов

  • Идентифицирующая связь - это когда существование строки в дочерней таблице зависит от строки в родительской таблице. Это может сбивать с толку, поскольку в наши дни принято создавать псевдоключ для дочерней таблицы, но , а не , делают внешний ключ родительской частью первичного ключа дочернего элемента. Формально, «правильный» способ сделать это - сделать внешний ключ частью первичного ключа ребенка. Но логическое отношение состоит в том, что ребенок не может существовать без родителя.

    Пример: A Человек имеет один или несколько телефонных номеров. Если бы у них был только один номер телефона, мы могли бы просто сохранить его в столбце Person . Поскольку мы хотим поддерживать несколько телефонных номеров, мы создаем вторую таблицу PhoneNumbers , первичный ключ которого включает в себя person_id , ссылающийся на таблицу Person .

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

  • A non- отношение идентификации - это когда атрибуты первичного ключа родительского объекта не должны становиться атрибутами первичного ключа дочернего объекта. Хорошим примером этого является справочная таблица, такая как внешний ключ в Person.state , ссылающийся на первичный ключ States.state . Персона является дочерней таблицей в отношении состояний . Но строка в Person не идентифицируется атрибутом state . Т.е. состояние не является частью первичного ключа Person .

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

См. также мой ответ на Все еще не уверен в идентификации и неидентификации отношений

1024
ответ дан 22 November 2019 в 21:24
поделиться

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

Число, которое идентифицирует позицию, идентифицирует ее только в контексте одного заказа. Первая позиция в каждом заказе - это позиция "1". Полная идентификация позиции - это номер позиции вместе с номером заказа, частью которого она является.

Следовательно, родительские дочерние отношения между заказами и позициями являются идентифицирующими отношениями. Тесно связанная с этим концепция в ER-моделировании носит название «субъединица», где позиция - это субстанция порядка. Как правило, у субъекта есть обязательная идентификационная связь между дочерним и родительским объектами, которой он подчиняется.

В классическом проектировании базы данных первичным ключом таблицы LineItems будет (OrderNumber, ItemNumber). Некоторые из современных дизайнеров присваивают элементу отдельный ItemID, который служит первичным ключом и автоматически внедряется СУБД. В этом случае я рекомендую классический дизайн.

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

В классическом проектировании базы данных первичным ключом таблицы LineItems будет (OrderNumber, ItemNumber). Некоторые из современных дизайнеров присваивают элементу отдельный ItemID, который служит первичным ключом и автоматически внедряется СУБД. В этом случае я рекомендую классический дизайн.

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

В классическом проектировании базы данных первичным ключом таблицы LineItems будет (OrderNumber, ItemNumber). Некоторые из современных дизайнеров присваивают элементу отдельный ItemID, который служит первичным ключом и автоматически внедряется СУБД. В этом случае я рекомендую классический дизайн.

1
ответ дан 22 November 2019 в 21:24
поделиться

Вот хорошее описание:

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

http://www.sqlteam.com/article/database-design-and-modeling-fundamentals

Вот простой Пример идентифицирующего отношения: 

Parent
------
ID (PK)
Name

Child
-----
ID (PK)
ParentID (PK, FK to Parent.ID) -- notice PK
Name

Вот соответствующее неидентифицирующее отношение: 

Parent
------
ID (PK)
Name

Child
-----
ID (PK)
ParentID (FK to Parent.ID) -- notice no PK
Name
14
ответ дан 22 November 2019 в 21:24
поделиться

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

Неидентифицирующие отношения определяют регулярную связь между объектами, 1: 1 или 1: n кардинальности.

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

24
ответ дан 22 November 2019 в 21:24
поделиться

Есть еще одно объяснение из реального мира:

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

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

872
ответ дан 22 November 2019 в 21:24
поделиться
Другие вопросы по тегам:

Похожие вопросы: