Я создаю концептуальную диаграмму [да, я знаю, что я включил атрибуты и ключи - но это только для меня, чтобы консолидировать то, что я делаю во время обучения] - поэтому, пожалуйста, рассматривайте ее как концептуальную с акцентом на отношения и а не таблицы как на диаграмме;)

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

Прежде всего, ПРАВИЛА:

• Один или несколько профилей могут быть членами / друзьями одной или нескольких организаций ; и наоборот.
• Один или несколько профилей могут быть членами / друзьями других профилей.
• Одна или несколько организаций могут быть членами / друзьями других организаций.

Друг и Участник отличаются тем, что Друзья похожи только на чтение, а Участники [в зависимости от уровня] имеют полный доступ к изменениям.

Чтобы усложнить ситуацию, у Местоположений есть свой собственный набор «дополнительных» обновляемых правил, например, Организации принадлежит два Местоположения , но в зависимости от правил Местоположения, Участник [ Профиль ] этой Организации может иметь полный доступ в одном Местоположении, но ограниченный доступ в разное. [Извините: вам, скорее всего, придется открыть изображение в другом окне для лучшего размера просмотра.]

Таким образом, как вы можете видеть, концепция профилей и организаций во многом совпадает с концепцией друзей и членов, которую еще предстоит смоделировать [... которая, я думаю, будет обрабатываться так же, как текущие промежуточные таблицы с настройкой Owner / Admin / Member / Friend и т.д. в записи]. Следовательно, почему я думаю о следующей концепции:

См. Option.2 на изображении выше: это приведет к удалению текущих таблиц Organization и Organization_Locations и их связей, заменив их на Организационную таблицу Option.2 в качестве несколько рекурсивных отношений с Profile .

Я полагаю, суть вопроса в том, слишком ли я программно склонен к полиморфизму в ущерб простоте и гибкости, полностью запутываясь в этом процессе;)

Заранее спасибо за мысли, высоко ценится - М :).

Пересмотренная схема:

В ответ на вопросы MDCCL:

1. Да, профиль составлен из одного человека и имеет то же значение - хотя, куда направлено ваше обоснование - я считаю, что вы правы: организация и человек могут быть подтипами профиля ; следовательно, профиль состоит из одного человека или одной организации.
2. Один адрес электронной почты на профиль.
3. Да. Как указано выше, у организации должен быть хотя бы адрес электронной почты.
4. Правильно, один фиксированный адрес.
5. Это возможность, но редкость - хотя из того, что я изучаю, - поэтому следует смоделировать это для будущего долголетия и т. Д., И просто для подтверждения, что Местоположение может принадлежать более чем одному человеку.

6. Местоположение определенно является неотъемлемой частью между большинством других. Возможно, я проясню, что можно сделать кратко, а затем позволю вам прочитать хотя бы другие мои ответы, которые, мы надеемся, сначала будут иметь полезные дополнения к этому вопросу [ затем посмотрите мой ответ на # 6 в конце ];) Re: Владелец роли. An **Organization** can be an Owner of zero or more **Locations**. A Person can be an owner of zero of more Locations[следовательно, как вы и предполагали ранее; Проще говоря, профиль может быть владельцем одного или нескольких местоположений.

7. Да, профиль , который является владельцем из Откуда принимает весь Role Permissions [супер пользователь]; профиля , что является Администратор может изменить некоторые детали Места , но в основном помогает / редактирует деталь / данные , подаваемые с помощью все другой Profile / с - это в первую очередь будет поставляться на «Basic Member / s» упомянутого Местонахождение / с; который оставляет Основной Участник , который может только для чтения все связанные детали Местоположения и предоставляет данные, которые должны проверяться Администратором / Владельцем . Помимо этого, любой профиль[Organization / Person] во многом похожа на базового участника «только для чтения» - давайте называть его « Гость», но только в том случае, если Местоположение установлено как « Открытое» (а не « Частное» ), хотя они не могут предоставлять входные данные, как базовый участник может ,

8. Верный.
9. Ваша интуиция удивительна! Да, it is foreseen that a single Location could contain one to many LocationTypes- чтобы еще больше усложнить ситуацию - ожидается, что эти отдельные LocationTypes могут иметь различные разрешения для профилей, связанных с «родительским» местоположением; из которых разрешения будут фильтроваться от Location до LocationType / s [так же, как разрешения безопасности папки ОС]. Я отмечаю, что через вашу диаграмму вы можете ссылаться на тип больше как описание?
10. Да.
11. Смотрите 12.
12. Правильно, способность Profile1 [Персона или Организация] воздействовать на Местоположения, принадлежащие Profile2 [Персона или Организация] [если они являются Другом / Участником с правильными разрешениями], имеет первостепенное значение.
13. Очень разумно - а) согласен. б) согласен c) Да, хм? ... Возможно, это должно быть примерно так же, как профиль [person] для Profile [person] = Friends . Каким бы ни было описание, оно будет вращаться вокруг Местоположения , так как Организация будет действовать в отношении другого Местоположения Организации ; хотя с семантической точки зрения, я сомневаюсь, что какая-либо Организация захочет стать подчиненной в качестве «члена» организации этого местоположения, чтобы иметь возможность «независимо от того, насколько хороша причина».

[6]. Это все еще немного серо для меня, но здесь идет ... Возможно, к моему ущербу, сходство между отношениями между членами и друзьями настолько близко, что я подумал объединить их; Оглядываясь назад на вашу диаграмму и интерпретацию, вы, возможно, правы, если будете разделять их [ я собирался разграничить отдельные отношения с помощью свойства enum: Owner / Admin / Member / Friend ]. Ваша концепция, например, такая: Местоположение, которое принадлежит Организации, будет иметь ноль, чтобы множество Профилей [Персона или Организация] воздействовали на него, хотя должна быть четкая разница между тем, как Профили действуют на местоположение через его отношение [Участник или Друг. ] обозначается через роли.So perhaps, the default relation between any Profile is Friend [much like Guest at Answer#7], enabling them to view the read-only Location data and msg/email the Location Owner/Admin - but not allow them to receive Location updates, news, etc., as a Member would.

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

Предварительная модель данных и предполагаемые бизнес-правила

Я определил список бизнес-правил, которые я принял после прочтения вашего вопроса и тщательного изучения ваших диаграмм, чтобы описать мое недопонимание ваших спецификаций. После определения такого списка я получил модель данных IDEF1X ^[1], которую я решил загрузить в виде документа .PDF на внешнюю платформу (Dropbox), поскольку из-за своего формата эта модель данных плохо вписывается во встроенное изображение. Эти два инструмента будут полезны в качестве ссылок на некоторые важные моменты, которые я перечислю ниже в разделе, озаглавленном Аспекты, которые необходимо решить, чтобы продолжать двигаться вперед .

Во-первых, вот ...

• Организации и профили Предварительная модель данных .

Поскольку только это, предварительно, рассмотрите это как средство, помогающее нам создать желаемую конечную модель данных.

Предполагаемые бизнес-правила

Упомянутая предварительная модель данных была получена из набора бизнес-правил (выведенных из вашего вопроса), которые я перечислю следующим образом:

Организации и профили

Обратите внимание, что Profileв настоящее время понимается как синоним для Person.

• Ан Organizationдруг один ко многим Profiles .
• Ан Organizationдруг один ко многим Organizations .
• Ан Organizationявляется членом один ко многим Organizations .
• А Profileявляется членом одного ко многимOrganizations .
• А Profileдруг один ко многим Profiles .
• А Profileявляется членом одного ко многим Profiles .

Расположение и адреса

• А Organizationвладеет один ко многим Locations .
• А Locationклассифицируется как один ко многим LocationTypes ( только один в данный момент времени).
• LocationМожет иметь один-ко-многим Addresses ( один Physical , один за Shipping, один за Billing, или один , который служит все указанные цели, или один , который сочетает в себе две цели и другой , который служит только один из них).

• AddressМожет храниться один-ко-многим Profiles , или, иначе говоря, Profileдержит один-ко-многим Addresses .

• Конкретный Addressможет быть использован один-ко-многим Profiles (служит Physicalдля одного Profile , используется для Billingна другой один , и т.д.). Таким образом, Addressработает аналогичным образом для Locationsи Profiles.

  • Таким образом, индивидуум Addressможет быть одновременно и типа Physical, Shipping и Billing .

Расположение и роли

• А Locationоткрывает один ко многим Roles .
• А Roleможет быть выполнено в один ко многим Locations .
• A Profile(как только он был установлен как Membera Organization) может выполнять один ко многим Roles , один ко многим Locations (но только по одному конкретному Roleв каждом из них Locationв определенный момент времени, т. Е. Никогда не два или более Roles одновременно ).

Аспекты, чтобы решить, чтобы продолжать двигаться вперед

Чтобы продолжать продвижение в разрешении вашей модели данных, вот список важных моментов, которые, как только мы их разработаем, помогут нам достичь этой цели:

1. Я предположил, что термин Profileв вашем контексте имеет такое же (или то же самое) значение, что и термин Person, но он может быть немного другим. Таким образом, вы бы сказали, что в вашем сценарии сущности Organizationи Personподтипы Profile?

2. Может ли Profile(или Person) самостоятельно один-ко-многим EmailAddresses , или является Profile(или Person) крепится к ровно один EmailAddress ?

3. Вы хотели бы , чтобы предоставить возможность для Organizationдля контакта с помощью Telephoneи Email, или вы хотите ограничить , что возможно только для Profile(или Person)?

4. Я предполагаю, что a Locationявляется точным к одному Address из типов Physical, это правильно?

5. Возможно ли для Locationдля совместного использования одного ко многим отличается Organizations или , в противном случае Locationможет принадлежать только один Organization ?

6. Вы заявили в комментариях, что факт существования a Memberи a Friend- это одно и то же. Как вы можете видеть в моей предложенной предварительной модели данных, я следовал за вами оригинальными спецификациями и изобразил все возможные комбинации членства и дружбы между Organizationи Profile(или Person) в разных организациях, поскольку я думаю, что это может быть полезным в определении наилучших возможных структура для этой части вашего сценария. В этом смысле:

   • Я предполагаю, что утверждение an Organization is a Member of another Organizationимеет иные эффекты, чем утверждение в a Profile (or Person) is a Member of an Organizationотношении вызываемой сущности Location.
   • Как вы можете видеть в модели данных, я думаю , что Roleиз Ownerдействительна только для Organizationи, мне, действительный Rolesдля Profile(или Person) Внутри Locationесть Adminи Member. Что вы думаете обо всем этом? Поскольку вы находитесь в прямом контакте с бизнес-правилами, применимыми к вашей ситуации, вы должны сообщить мне, верны ли мои предположения.

7. Может ли Profile(или Person) играть по-разному Rolesвнутри одного и того же Location? то есть, может ли Personбыть, в то же время, Adminа также Memberодного и того же Location? Каковы правила в этом отношении?

8. Я думаю, что одно и то же Profile(или Person) может играть по-разному Rolesв разных Locations. Например: конкретный Profile(или Person) - это «Администратор» в Location«1», и этот же Profile(или Person) - это « Member» в Location«2», в то же время. Я прав?

9. Возможно ли, Locationчтобы конкретное LocationTypesлицо отличалось в одно и то же время, или индивидууму Locationназначено удерживать ровно одно LocationType?

10. Organization.WebsiteПредставляет ли атрибут адрес веб-сайта конкретной организации, например, «dba.stackexchange.com»?

11. Если Profile«1» (понимается Person) является Member(или Friend) от Profile«2», это возможно для Profile«1» , чтобы провести Roleв Locationпринадлежащей Profile«2»? Я считаю, что такие сценарии действительны только для отношений между Organizationи, Member Personтак что вы думаете?

12. Аналогичным образом, если Organization«1» является Member(или Friend) из Organization«2», это возможно для Organization«1» осуществлять Roleв Locationпринадлежащей Organization«2»? Опять же, я думаю, что такого рода сценарии действительны только для отношений между a Organizationи a Member Person, верно ли это?

13. В связи с этим -когда я пишу эту вопросы- я думаю , что было бы разумно сказать , что есть только три различные виды отношений с участием Organizationsи Persons, и мы можем определить:

    • (а) Отношения между Organizationи Personкак « Membership».
    • (б) Отношения между а Personи другим отличаются Personкак « Friendhip».
    • (c) Нам еще предстоит найти осмысленное имя, чтобы описать отношения между человеком Organizationи другим человеком Organization.
    • Итак, дайте мне знать, что вы думаете о (а), (б) и (в).

14. Возможно ли одновременно Organizationбыть Friend(или а Member) из одного ко многим разным Organizations? Или это возможно Organizationтолько иметь отношения только с одним другимOrganization?

Последовательная модель данных, изображающая первое продвижение

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

• Организации и профили Предварительная модель данных - первый шаг .

Хотя мне пока не очень комфортно с этим, новая модель данных выражает следующие бизнес-правила:

• ProfileЯвляется либо Organization илиPerson . ^[2]
• A Profileможет быть другом одного ко многим FriendProfiles , а a Profileможет быть другом одного ко многим FriendProfiles . ^[3]
• А Locationможет состоять из одного ко многим Locations . ^[4]

Ответы на ваши последующие конкретные комментарии

Мне действительно интересно отметить / усугубить разделение интересов [например, LocationAddress и ProfileAddress] - поскольку я, очевидно, хотел ворваться и удержать их всех без правильных отношений [как ни странно, это было не так с моей первоначальной ERD].

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

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

И, да, когда что-то не кажется правильным или естественным , это может быть признаком того, что нужно приложить больше усилий, чтобы понять соответствующие данные. Таким образом, Addressсущность - это одна из тех вещей, которые, на мой взгляд, нуждаются в большем внимании, поскольку я считаю, что отношения между a Profileи a Address можно обрабатывать посредством Locationсущности (поскольку каждый Locationдолжен иметь хотя бы одну физическую Address), поэтому мы могли бы уволить ProfileAddressассоциативную сущность , изображенную в последней модели, но вы должны продолжать эти пункты анализируя и дайте мне знать ваши идеи.

Кроме того, является ли распространенной практикой в ​​IDEF1X изменение обозначений PK / FK в сущностях для лучшей читаемости [например, ProfileId - LocationOwnerProfileId]?

Да, это очень умное замечание с вашей стороны, поскольку IDEF1X рекомендует использовать имена ролей для обозначения FOREIGN KEYS, чтобы уловить значение таких атрибутов в соответствии с сущностью, в которой они используются. Стоит также отметить, что это также тесно связано с концепцией миграции первичных ключей . Фактически, использование имен ролей предшествует IDEF1X, так как оно было первоначально представлено доктором Э. Ф. Коддом в его оригинальном тексте 1970 года. Таким образом, можно четко увидеть, насколько стандарт IDEF1X соответствует реляционной модели .

Я был бы заинтригован, чтобы узнать, что вам не особенно нравится / чувствует, что это не моделирует, с / в решении?

Помимо подробностей, уже описанных выше об Addressобъекте, я не уверен , эквивалентны ли Rolesвыполняемые данным Profileв конкретном или . С моей точки зрения, сначала нужно связать с , а затем это назначило бы сказанное для выполнения в конкретном , но вы лучше знаете сценарий, поэтому эти правила могут быть ненужными. В связи с этим, я буду настаивать на том , о том , что было бы очень полезно для меня , чтобы знать контекстное описание или значение , что пользователи в будущем этой структуру данных Отдать , иLocationOrganizationPersonPersonOrganizationOrganizationPersonRoleLocationOrganizationProfileLocation, но я понимаю, что это может считаться конфиденциальной информацией, поэтому это будет ограничением.

С текущей структурой кажется, что каждый ( Organizationили Person) может быть связан с кем-либо (снова Organizationили Person) и может / делать что угодно ( Role) где угодно ( Location), но, вероятно, это именно то, что вы и пользователи ожидаете от этой базы данных , для которого вы, конечно, предоставите четко определенные ограничения. Если это так, то мы почти предоставляем окончательное решение. Поскольку, естественно, ваше мнение имеет решающее значение в этой ситуации, вам также следует проанализировать эти идеи, а затем сообщить мне ваши выводы, чтобы мы могли сделать последние шаги.

Возможное второе продвижение

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

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

Предварительная модель данных организаций и профилей - второй шаг вперед

Как видно из такой модели данных, я удалил отношение « многие ко многим», которое я изобразил в предыдущих моделях, между « Profileи» Address, поскольку данное Profileуже связано с « один ко многим» Addresses через принадлежащее ему Locations.

Другое изменение, проиллюстрированное в этом новом прогрессе, заключается в том, что теперь он включает в себя возможность того, что данное Locationможет принадлежать одному-многим Profiles . Следовательно, я изменил LocationПЕРВИЧНЫЙ КЛЮЧ (отклонив LocationOwnerProfileIdатрибут), а затем добавил ассоциативную сущность ( многие ко многим ), которая связана Profileс Location.

Заметки

_{1. IDEF1X - это очень рекомендуемая методика моделирования данных, которая была определена в качестве стандарта в декабре 1993 года Национальным институтом стандартов и технологий США ( NIST ).}

_{2. Это вхождение (супер) кластера подтипа типа . Если вам интересно, вот ответ, в котором я более подробно расскажу о таких отношениях.}

_{3. Пример иерархического отношения «многие ко многим» , очень похожий на структуру, которая дала окончательное решение «Проблемы исследования деталей» . Такое решение, конечно же, было представлено доктором Эдгаром Фрэнком Коддом в его чрезвычайно влиятельной работе 1970 года «Реляционная модель данных для больших общих банков данных» .}

_{4. Как таковой, это пример иерархического отношения один-ко-многим (или многие-к-одному) .}

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

Реляционная модель как таковая не поддерживает наследование, не говоря уже о полиморфизме. Это означает, что при моделировании реальной жизненной ситуации необходимо использовать довольно специализированный шаблон проектирования, который легко обрабатывается наследованием и полиморфизмом в объектной модели. Подробнее об этом особом шаблоне дизайна позже.

Когда модель ER была впервые разработана, она должна была быть независимой от реализации альтернативой реляционному моделированию. Сначала у него тоже не было ничего похожего на наследство. Но какое-то время, в 1980-х или 1990-х годах, модель была расширена, чтобы обеспечить некоторые из тех же выразительных возможностей, которые вы получаете с наследованием. Это было известно как «расширенная модель ER», но сегодня для всех практических целей модель ER включает в себя функции EER.

Одна особенность EER называется «обобщение / специализация». Вы можете найти и прочитать об этой концепции в Интернете. Gen-spec предоставляет те же возможности выразительности, что и классы и подклассы в объектной модели. Однако Gen-spec не занимается проблемами, связанными с дизайном реляционных таблиц для ситуации Gen-spec. Подробнее об этом позже.

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

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

Двигаясь дальше, я замечаю, что вы объединяете свою реляционную модель и модель ER в единую модель. Большинство опытных архитекторов баз данных делают это. Но я советую вам держать две модели отдельно (хотя и примириться друг с другом), пока вы не овладеете навыком.

Наконец, как можно спроектировать реляционные таблицы, которые представляют ситуацию gen-spec? Попробуйте найти эти два шаблона проектирования «наследование таблиц классов» и «наследование отдельных таблиц». В Stackoverflow есть два тега для них. Есть также несколько хороших презентаций шаблонов в Интернете. Мне особенно нравится лечение Мартина Фаулера. Кажется, он знает, как думают объектные моделисты. Надеюсь это поможет.