Я пытался найти в Google приличное объяснение слабых и сильного типа сущности , но я их не до конца понял.
Может ли кто-нибудь привести пример сильного и слабого типа сущности?
Слабая сущность - это та, которая может существовать только тогда, когда она принадлежит другой. Например: ROOM может существовать только в BUILDING . С другой стороны, TIRE может рассматриваться как сильная сущность, потому что она также может существовать без привязки к CAR .
Просто чтобы поиграть с ним, вопрос сильный тип сущности, а ответ слабый. Вопрос всегда есть, но для ответа требуется вопрос.
Пример: Не спрашивайте «Почему?«Если твой папа профессор химии
Страховой полис компании страхует работника и любых иждивенцев, ЗАВИСИМОСТЬ не может существовать без СОТРУДНИКА; то есть человек не может получить страховое покрытие в качестве иждивенца, если только он не является иждивенцем работника. ОТПРАВЛЕНИЕ - это слабая сущность в отношениях «У ЭМПОЙЕ есть ЗАВИСИМОСТЬ»
Слабая сущность - это сущность, которая не может быть полностью идентифицирована своими собственными атрибутами и принимает foreign key в качестве атрибута (обычно он берет первичный ключ сущности, с которой он связан) в сочетании.
Примеры
Наличие номеров полностью зависит от существования отеля. Таким образом, номер можно рассматривать как слабую сущность отеля. Другой пример - банковский счет конкретного банка не существует, если банка больше не существует.
Он может существовать без какой-либо другой сущности.
Пример
Customer(customerid, name, surname)
Это зависит от доминирующего субъекта, и оно не может существовать без сильного субъекта.
Пример
Adress(addressid, adressName, customerid)
Слабые сущности также называются зависимыми объектами, поскольку их существование зависит от других объектов. Такие объекты представлены прямоугольником с двойным контуром на диаграмме E-R.
Сильные сущности также называются независимыми субъектами.
./Database / DataModels / RelationalDataModel / WeakEntity
Это, вероятно, можно записать в двух факторах:
Если бы мы подумали о базе данных, в которой есть вопросы и ответы, то вопросы были бы сильной сущностью, а ответы - слабой сущностью. Итак, Вопрос (id, текст) и Ответ (номер, вопрос, текст) будут нашими таблицами. Но почему таблица Ответа слабая сущность?
Слабая сущность существует для решения проблемы многозначных атрибутов.
Существует два типа многозначных атрибутов. Одним из них является просто множество значений для таких объектов, как «хобби» как атрибут для ученика. У студента может быть много разных увлечений. Если мы оставим хобби в наборе студенческих образований, «хобби» больше не будет уникальным. Мы создаем отдельную сущность, установленную как хобби. Затем мы связываем хобби и студента, как нам нужно. Набор хобби-сущности теперь является набором ассоциативных сущностей. Что касается того, является ли он слабым или нет, нам необходимо проверить, имеет ли каждый объект достаточно уникальных идентификаторов для его идентификации. По мнению многих, хобби может быть достаточно, чтобы идентифицировать его.
Другой тип проблемы с многозначным атрибутом нуждается в слабом объекте, чтобы исправить это. Допустим, объект объекта установлен в системе продуктового инвентаря. Является ли элемент категорией или фактически элементом? Это важный вопрос, потому что клиент может купить один и тот же товар одновременно и на определенную сумму, но он также может купить один и тот же товар в другое время с другой суммой. Можете ли вы увидеть один и тот же элемент, но разных объектов. Элемент теперь является многозначным атрибутом. Мы решаем это, сначала отделяя элемент категории от фактического элемента. Теперь они представляют собой разные наборы сущностей. Элемент категории имеет описательные атрибуты элемента, как и элемент, который вы обычно думаете. Фактический элемент больше не может иметь описательных атрибутов, потому что у нас не может быть избыточной проблемы. Фактический товар может иметь только дату и сумму товара. Вы можете связать их по мере необходимости. Теперь давайте поговорим о том, является ли одно слабым существом другого. Описательных атрибутов более чем достаточно для идентификации каждого объекта в наборе объектов категории. Фактический товар имеет только дату и сумму. Даже если мы извлечем все атрибуты в записи, мы все равно не сможем идентифицировать сущность. Подумайте об этом просто время и количество. Фактический набор сущностей элемента является слабым набором сущностей. Мы идентифицируем каждую сущность в наборе с помощью дубликата первичного ключа из набора сущностей элемента категории.
Просматривая поисковые системы в течение нескольких часов, я наткнулся на сайт с отличным примером ERD здесь: http://www.exploredatabase.com/2016/07/description-about-weak-entity-sets-in-DBMS.html
Я воссоздал ERD. К сожалению, они не указали первичный ключ слабой сущности.
Если бы в здании могла быть только одна и только одна квартира, то, похоже, номер комнаты частичного дискриминатора не был бы создан (т.е. выброшенный).
Слабый тип объекта: Объект, экземпляры которого не могут быть выведены без связи с экземплярами какого-либо другого объекта, называется слабым типом объекта. Он не может существовать независимо. Например: наш компьютер зависит от нас, он не будет открываться или закрываться со своим собственным.
Сильный тип сущности: Субъект, связанный с экземплярами любого другого типа объекта, называется сильным типом объекта. Может выходить самостоятельно. Например: человек может делать все, что может, везде и использовать когда-либо
Объект данных, который может существовать без зависимости от существования другого объекта данных, известен как Сильный объект данных.
Первые сильные / слабые эталонные типы вводятся в ARC. В Non ARC используются assign / retain. Сильная ссылка означает, что вы хотите «владеть» объектом, на который вы ссылаетесь, с этим свойством / переменной. Компилятор позаботится о том, чтобы любой объект, который вы назначаете этому свойству, не был уничтожен, если вы указываете на него с сильной ссылкой. Только после того, как вы установите значение nil, объект будет уничтожен.
Слабая ссылка означает, что вы указываете, что не хотите контролировать срок службы объекта или не хотите «владеть» объектом. Объект, на который вы ссылаетесь, живет только потому, что по крайней мере один другой объект имеет сильную ссылку на него. Как только это перестанет иметь место, объект будет уничтожен, и ваше слабое свойство автоматически будет установлено на ноль. Наиболее частые случаи использования слабых ссылок в iOS для IBOutlets, делегатов и т. Д.
Для получения дополнительной информации см .: http://www.informit.com/articles/article.aspx?p = 1856389 & seqNum = 5