Я створюю концептуальну схему [так, я знаю, що я включив атрибути та ключі, але це тільки для мене, щоб закріпити те, що я роблю, навчаючись], тому, будь ласка, розглядайте це як концептуальне з акцентом на відносини та таблиці, а не як схему;)

Моя перешкода: я намагаюся з’ясувати найкращий спосіб моделювати взаємозв'язки профілю, місця розташування та організації.

Перш за все, ПРАВИЛА:

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

Друг та Член відрізняються тим, що "Друзі" схожі лише на читання, а члени [залежно від рівня] мають повний доступ до змін.

Щоб ще більше ускладнити справи, Місцеположення має власний набір "подальших" правил удосконалення, наприклад, Організація володіє двома Місцеположеннями , але залежно від правил розташування, Член [ Профіль ] цієї Організації може мати повний доступ до однієї Місцеположення, але обмежений доступ у інший. [Вибачте: вам, швидше за все, доведеться відкрити зображення в іншому вікні для кращого розміру перегляду.]

Отже, як ви бачите, концепція профілів та організацій майже однакова, і це ще не модельоване поняття «Друзі та члени» [... яке, я думаю, буде оброблятися подібно до поточних таблиць посередників із встановленням Власника / Адміністратор / член / друг тощо в записі]. Отже, чому я думаю про таку концепцію:

Дивіться варіант 2 на наведеному вище зображенні: що видалить поточні таблиці " Організація" та " організації_розміщення" та їх взаємозв'язки, замінивши його таблицею "Опція 2", як дещо рекурсивні відносини з " Профілем" .

Я припускаю, що суть справи полягає в тому, чи я занадто програмно налаштований на поліморфізм на шкоду простоті та гнучкості, цілком заплутавшись у цьому процесі;)

Заздалегідь дякую за ваші думки, дуже вдячний - M :).

Переглянута схема:

У відповідь на запитання 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» згаданого Місцезнаходження / с; який залишає базового учасника , який може лише для читання всіх пов’язаних даних про місцезнаходження та надання даних, які повинні перевіряти адміністратор / власник . Крім цього, будь-який профіль[Організація / Особа] схожа на базового члена "лише для читання" - давайте назвемо їх Гість - але тільки якщо Місце розташування встановлено як Публічне [, а не Приватне ], хоча вони не можуть надати введення, як Основний Член може .

8. Правильно.
9. Ваша інтуїція дивовижна! Так, it is foreseen that a single Location could contain one to many LocationTypes- для подальшого ускладнення - очікується, що ці окремі типи місцеположення можуть мати різні дозволи для профілів, пов’язаних із "батьківським" розташуванням; з яких, дозволи дозволить відфільтрувати з Location до LocationType / s [подібно до дозволів безпеки папки ОС]. Зауважу, через вашу діаграму ви могли б посилатися на тип більше як опис?
10. Так.
11. Див. 12.
12. Правильно, можливість профілю1 [особа чи організація] діяти на профілі2 [особа чи організація], що належать місцям розташування [якщо вони є другом / учасником з правильними дозволами], є першорядною.
13. Дуже розумно - а) згоден. б) погоджуються. в) Так, хм? ... Можливо, це має бути приблизно так само, як Профіль [особа] в Профілі [людина] = Друзі . Незалежно від опису, він буде обертатися навколо Місцеположення , оскільки Організація (и) буде діяти на інших Місцеположениях Організації ; хоч семантично, я сумніваюсь, що будь-яка Організація хотіла б виглядати підпорядкованою як "Член" Організації цієї локації, щоб мати можливість цього робити, "незалежно від того, наскільки хороша справа".

[6]. Це все ще для мене сірий тад, але тут ідеться ... Можливо, на мій шкоду, схожість між відносинами член / друг настільки близька, що я думав поєднувати їх; з огляду на вашу діаграму та інтерпретацію, схоже, ви можете бути правильними для того, щоб їх було окремо [ Я збирався розмежувати єдине відношення за допомогою власності enum: Власник / Адміністратор / Член / Друг ]. Ваша концепція, наприклад: Місцезнаходження, яке належить Організації, матиме нуль для багатьох профілів [Особа чи Організація], які діють на неї, хоча має бути чітка різниця між тим, як Профілі діють на місце розташування через його відношення [Член або Друг ] позначається через ролі.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 .
• A Profileє другом одного на багатьох Profiles .
• А Profileє членом одного до багатьох Profiles .

Місцеположення та адреси

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

• Дозвіл Addressможе зберігатися одним-багатьом Profiles або, кажучи іншим способом, Profileзберіганням одного-до-багатьох Addresses .

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

  • Таким чином, індивідуум Addressможе бути, в той же час , типу Physical, Shipping і Billing .

Місцеположення та ролі

• A Locationвідкриває один-до-багатьох Roles .
• А Roleможе бути здійснено у множині Locations .
• A Profile(після того, як його встановлено як Member" 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, і ми можемо визначити:

    • (a) Зв'язок між " Organizationa" Personяк " Membership".
    • (b) Зв'язок між a Personта іншим, відмінним Personвід " Friendhip".
    • (c) Ми ще не повинні знайти значущого імені, щоб описати стосунки між людиною Organizationта іншим іншим Organization.
    • Отже, дайте мені знати, що ви думаєте про (a), (b) та (c).

14. Чи можливо, Organizationщоб a Friend(або a Member) одного-до-багатьох різних Organizationsодночасно? Або можливо лише для того, Organizationщоб мати лише стосунки з виключно одним різнимOrganization?

Послідовна модель даних із зображенням першого заздалегідь

Зважаючи на ваші відповіді та рішення на майбутні аспекти, які я перелічив вище, я створив наступне…

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

Хоча я до цього часу не відчуваю себе досить комфортно, ця нова модель даних виражає такі ділові правила:

• ProfileЄ або Organization чиPerson . ^[2]
• А Profileможе бути другом, який пропонує одного, до багатьох FriendProfiles , а 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 рекомендує використовувати імена ролей для позначення ІМЕЧНИХ КЛЮЧІВ, щоб зафіксувати значення таких атрибутів відповідно до сутності, в якій він використовується. Варто також зазначити, що це також сильно пов'язане з концепцією міграції первинних ключів . Власне кажучи, використання імен ролей передує IDEF1X, оскільки воно було спочатку представлене доктором Е.Ф. Коддом у його семінарському тексті 1970 року. Таким чином можна чітко побачити вірність, яку дотримується стандарт IDEF1X щодо реляційної моделі .

Мене б заінтригувало, щоб дізнатися, що вам не подобається / відчуваєте, що це не моделює, з / у рішенні?

Окрім уже описаних вище деталей про Addressсутність, я не впевнений, чи Rolesздійснені даними Profileу певній частині, Locationє рівнозначними для Organizationабо та Person. З моєї точки зору, Personспочатку потрібно пов’язати з Organization, а потім це Organizationпризначить, що кажуть, Personщоб виконати певну Roleроль Location, але ви краще знаєте сценарій, тому ці правила можуть бути непотрібними. У зв'язку з цим, я буду наполягати на тому , про те , що було б дуже корисно для мене , щоб знати контекстне опис або значення , що користувачі в майбутньому цієї структуру даних Віддати Organization, ProfileіLocation, але я розумію, що це може вважатися конфіденційною інформацією, тому це було б обмеженням.

З існуючою структурою, схоже, що кожен ( Organizationабо Person) може бути пов'язаний з ким-небудь (знову, Organizationабо Person) і може бути / робити все, що Roleзавгодно ( Location), але, перхарп, це точно те, що ви і користувачі очікуєте від цієї бази даних , для чого, звичайно, ви забезпечите чітко визначені обмеження. Якщо це так, то ми майже пропонуємо остаточне рішення. Оскільки, природно, ваша думка є вирішальною у цій ситуації, ви також повинні проаналізувати ці ідеї, а потім повідомити мені ваші висновки, щоб ми могли зробити останні кроки.

Можливий другий заздалегідь

На жаль, спілкування припинилося кілька тижнів тому, я думаю, через робочі зобов’язання, які ви повинні виконати, що цілком розумно. Я був би набагато більше задоволений, якби ми розробили більш стабільну та надійну модель, але, завдяки нашим попереднім взаємодіям, я можу припустити, що я зміг направити вас у правильному напрямку.

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

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

Як видно з такої моделі даних, я видалив відносини " багато до багатьох", які я зобразив у попередніх моделях між, Profileі Address, оскільки дана інформація Profileвже пов'язана з " багатьма" Addresses через її власність Locations.

Ще одна зміна, проілюстрована в цьому новому авансі - це той факт, що він тепер включає можливість того, що даною Locationособою може володіти людина Profiles . Отже, я змінив LocationPRIMARY KEY (по відхиляючи LocationOwnerProfileIdатрибут) , а потім додав асоціативний об'єкт ( багато-до-багатьох ) , що пов'язано Profileз Location.

Примітки

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

_{2. Це виникнення кластеру (супер) типу підтипу . У випадку, якщо вас цікавить, ось відповідь, в якій я більш детально розглядаю подібні відносини.}

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

_{4. Таким чином, це примірник ієрархічного відношення «один до багатьох» (або «багато хто до одного») .}

Я думаю, що ви намагаєтесь поєднати між собою поняття від об'єктного моделювання та концепції моделювання даних таким чином, що не допомагає вам з’ясувати власне розуміння проблеми. Я сподіваюсь, що зможу трохи очистити безлад, не надто сильно брязкаючи.

Реляційна модель як така не підтримує спадкування, не маючи на увазі поліморфізм. Це означає, що для моделювання реальної життєвої ситуації, яка легко справляється за допомогою спадкування та поліморфізму в об'єктній моделі, слід використовувати досить спеціалізовану модель дизайну. Детальніше про цю спеціальну схему дизайну пізніше.

Коли модель ER була вперше розроблена, вона повинна була бути агностичною альтернативою реляційному моделюванню. Спочатку вона не мала нічого подібного до спадщини. Але деякий час у 1980-х або 1990-х роках модель була розширена, щоб забезпечити деякі ті ж виразні можливості, які ви отримуєте з успадкуванням. Це було відоме як "розширена модель ER", але для всіх практичних цілей сьогодні модель ER включає функції EER.

Одна особливість EER має назву "узагальнення / спеціалізація". Ви можете шукати та читати за цією концепцією в Інтернеті. Gen-spec забезпечує майже таку ж виразність, яку надають класи та підкласи в об'єктній моделі. Однак Gen-spec не займається питаннями, що стосуються дизайну реляційних таблиць для ген-спец-ситуації. Детальніше про це пізніше.

У моделюванні ER взаємини завжди включають одні й ті самі сутності. Тому відносини друзів між організацією та профілем - це не те саме, що відносини друга між профілем та іншим профілем. Два стосунки потребують різних імен. Ви просто зав'яжете себе у вузли, якщо не будете дотримуватися цього правила.

Або це, або вам потрібно створити узагальнену сутність, організація, профілі та, можливо, локації - це все спеціалізації. Я не розумію вашої справи досить добре, щоб допомогти вам у цьому.

Просуваючись далі, я помічаю, що ви поєднуєте свою реляційну модель та свою ER модель разом в єдину модель. Більшість досвідчених архітекторів баз даних роблять це. Але я раджу тримати дві моделі окремо (хоча й узгоджені між собою), поки ви не набудете знання.

Нарешті, як складається одна реляційна таблиця, яка представляє ген-специфічну ситуацію? Спробуйте знайти ці два шаблони дизайну: "Наспадство класів-таблиць" та "Спадкування однієї таблиці". Для цього в Stackoverflow є два теги. Також є досить непогані презентації шаблонів в Інтернеті. Мені особливо подобається лікування Мартіна Фаулера. Він, здається, знає, як думають модельєри об'єктів. Сподіваюсь, це допомагає.