РЕДАКТИРОВАТЬ : ORM, как правило, довольно тонкий шпон по базе данных.как правило, классы сопоставляются с таблицами, с экземплярами этих классов в виде строк в таблице.Таблица с именем 'USERS' с полем varchar с именем USERNAME может быть сопоставлена с классом с именем User со строковым свойством с именем username.
Все становится более интересным, когда две таблицы в сопоставленной базе данных связаны ограничением внешнего ключа.Таблица 'USERS' может иметь первичный ключ с именем 'ID', а вторая таблица, скажем, 'ADDRESSES', может содержать поле с именем 'USER_ID', ограниченное 'USERS'.'ID'.В таком случае Пользователи являются независимыми, а Адреса зависимыми.Строка в таблице пользователей может принимать любое значение, но строки в таблице адресов должны иметь соответствующую строку в таблице пользователей, иначе ограничение внешнего ключа не выполняется
Когда это сопоставляется с классами приложения, первичныеключи часто закрыты.В любом случае, приложение не заинтересовано идентификаторами.В приведенном выше примере мы действительно хотим, чтобы у сопоставленного класса Address было свойство типа User, то есть соответствующий сопоставленный пользователь для адреса.Точно так же мы могли бы хотеть, чтобы класс User имел свойство, представляющее собой коллекцию Addresses, которые зависят от него.
Независимая таблица вызывается в ORM родительским классом , и зависимая таблица сопоставлена с дочерним классом .Термины, которые мы используем при описании этих классов, означают, что дочерний класс принадлежит родительскому классу, что эквивалентно тому, что зависимая таблица имеет ограничение внешнего ключа на одном из своих полей с независимой таблицей в качествереферент.Родительский класс, соответственно, имеет дочерний класс, что эквивалентно тому, что независимая таблица является референтом в ограничении внешнего ключа для поля в зависимой таблице
Предположим, класс Aпринадлежит классу B. Такое отношение может иметь отношение один к одному, где каждый A может принадлежать ровно одному B, а каждый B может иметь ровно один A. Однако это наименее распространенный случай.В большинстве случаев это «Один ко многим», где каждый А принадлежит ровно одному В, но у каждого В может быть ноль, один или более одного А. Такое отношение называется «Один ко многим».Например, Пользователь может иметь более одного Адрес электронной почты .
Последний поворот заключается в том, что иногда эти два класса могут находиться в отношениях многих ко многим.Это почти всегда достигается с помощью третьей таблицы.Примером такого отношения являются вопросы переполнения стека, которые могут иметь много тегов, и каждый тег применяется ко многим вопросам.Некоторые ORM могут иметь представление, что один может принадлежать другому без рефлексивных отношений, но большинство ORM называют эту ситуацию " Имеет и принадлежит многим "