термин непрофессионала для определения отношений

Question

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

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

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

ура!

Answer 1

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

Тогда, скажем, ссылочная таблица - это таблица с неидентифицирующим отношением.

Например, PhoneNumbers является дочерним из Users, потому что телефонный номер имеет идентифицирующую связь со своим пользователем (т. Е. Первичный ключ PhoneNumbers включает внешний ключ к первичному ключ Users).

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

Answer 2

Я думаю, принадлежит будет хорошим именем для идентифицирующих отношений.

«Тип слабого объекта» не имеет своего собственного ключа, просто «частичный ключ», поэтому каждый экземпляр объекта этого типа слабого объекта должен принадлежать некоторому другому экземпляру объекта, чтобы его можно было идентифицировать, и это "идентификация отношений". Например, арендодатель может иметь базу данных с квартирами и комнатами . комнату можно назвать кухня или ванная комната , и хотя это имя уникально в квартире, в базе данных будет много комнат с именем кухня , так что это всего лишь частичный ключ. Чтобы однозначно идентифицировать комнату в базе данных, нужно сказать, что это кухня в этой конкретной квартире. Другими словами, номера относятся к квартирам.

Answer 3

Ничто, абсолютно ничто в моделировании, где встречаются такие вещи, как «отношения» (я полагаю, ER), «технические», «точные» или «однозначные». И не может быть.

A) ER-моделирование всегда и по необходимости является неформальным, потому что оно никогда не может быть достаточным для захвата / выражения всего определения базы данных.

B) Существует так много разных диалектов ER, что для всех них просто невозможно использовать одинаковые термины с одинаковым значением. Недавно я даже обнаружил, что в каком-то британском университете, где преподается моделирование ER, термин «подтип сущности» используется для того же понятия, которое я всегда использовал для обозначения «супертипа сущности», и наоборот!

Answer 4

Я собираюсь порекомендовать термин "слабая сущность" из моделирования ER.

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

Если вы выполняете моделирование ER, существует некая сущность, называемая «слабой сущностью». Частью идентичности слабой сущности является идентичность более сильной сущности, к которой принадлежит слабая.

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

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

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

Answer 5

как насчет

• Ассоциация
• Ссылка
• Корреляция

Answer 6

Можно использовать connection.

У вас есть соединение между двумя таблицами, где идентификаторы одинаковы.

Такие вещи.