Моделирование данных: упражнение по логическому моделированию

Question

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

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

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

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

Вот список вещей, которые я хочу запечатлеть в этой концептуальной модели. Редактировать для V1.2

1. Цель этого - перечислить группы, их участников и события, на которых они будут появляться, а также предложить музыку и другие товары для продажи
2. Участники смогут встретиться с друзьями
3. Участники могут писать отзывы о группах, их музыке и их событиях.
   • На каждый элемент может быть только один отзыв на каждого участника, хотя они могут редактировать свои обзоры, и история будет сохранена.
   • BandMembers будет иметь возможность написать один комментарий на отзывы о группе, с которой они связаны. Коллективно, как группа, допускается только один комментарий к обзору.
   • Участники могут затем оценивать все отзывы и комментарии, но только один раз за данный экземпляр
4. Участники могут выбирать свои любимые группы, музыку, товары и события
5. Группы, песни и события будут классифицированы по типу жанра, а затем подкатегорированы в поджанре при необходимости. Для группы или события вполне допустимо попадание в более чем одну комбинацию жанра / поджанра.
6. Дата, время и место события будут опубликованы для данной группы, и участники могут показать, что они будут присутствовать на мероприятии. Событие может состоять из нескольких групп, и несколько событий могут проходить в одном месте в один и тот же день.
7. Каждая сторона будет привязана как минимум к одному адресу, и история адресов должна сохраняться. Каждая сторона также может быть привязана к нескольким адресам за раз (т.е. выставление счетов, доставка, физический адрес)
8. Там будут храниться профили для Bands, BandMembers и общих участников.

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

РЕДАКТИРОВАТЬ v1.1 В ответ на PerformanceDBA

U.3) Это означает, что в базе данных нет других товаров, кроме товаров группы. Правильно? Это была моя первоначальная мысль, но ты заставил меня задуматься.Возможно, сайт захочет продать свой товар или даже другой товар от групп.Не уверен, что мод, чтобы сделать для этого.Требуется ли полная переработка раздела Каталога или только идентификационные отношения, существующие с Группой?Попытка мод продать как полные альбомы или песни.В любом случае они оба будут в электронном формате, доступном только для скачивания.Вот почему я перечислил Альбом как состоящий из Песен, а не двух отдельных сущностей.

U.5) Я понимаю, что вы упоминаете о круговых отношениях с Фаворитом.Я хотел бы перейти к этому «Это либо одна сущность с некоторой формой дифференциации (FavoriteType), которая определяет ее обработку», но как мне это не понятно.Что мне здесь не хватает?

u.6) «Бизнес-правила Это, вероятно, единственная область, в которой вы слабы».
Спасибо за честный ответ.Я переадресовываю их, но я надеюсь сначала устранить некоторую путаницу в моей голове с ответами, которые я отправил вам обратно.

Q.1) Да, я хотел бы, чтобы вас приняли,Отклонено и заблокировано.Я не уверен, что вы имеете в виду, как это изменит логическую модель?

Q.2) Человек не обязательно должен быть пользователем.Они могут существовать только как BandMember.Это то, что вы спрашиваете?

Незначительный выпуск

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

M.4) Зависит от того, планируете ли вы OrderPurchase в будущем.Можете ли вы расширить, что вы имеете в виду здесь?

EDIT V1.2 В ответ на вход PerformanceDBA ...

Извлеченные уроки.

1. Я смешивал концепцию Идентификации / Неидентификации и Кардинальности (т. Е. Жанр / Поджанр) и делал непоследовательные действия, чтобы ухудшить ситуацию.
2. Ассоциативные таблицы не требуются в логических диаграммах, так как их отношения «многие ко многим» могут быть изображены, а затем расширены в физической модели.
3. Я упускал из виду кардинальность во многих отношениях
4. Важность чтения отношений с использованием эффективных глагольных фраз, чтобы успокоить Я моделирую то, чего хочу достичь.

U.2) В концепции этой модели требуется только отслеживать место проведения в качестве места проведения события.Больше никаких данных не нужно собирать.С учетом вышесказанного, события будут происходить в определенную дату события и будут проводиться в месте проведения.Места будут принимать несколько событий и, возможно, несколько событий в определенный день.В моей новой модели я думал, что EventDate уже привязан к Event.Следовательно, для Venue не понадобятся отношения с EventDate.5-я и 6-я пули, которые вы перечислили в разделе U.2), заставляют меня задуматься.Я что-то здесь упускаю?

U.3) Не пора ли вместо этого переместить связь между Предметом и Группой до Предмета и Группы?При нынешнем дизайне я не вижу возможности продавать товары, не привязанные к группе, как вы воспитали.

U.5) Я оставил в соответствии с вашим входом, вместо того чтобы сделать его дискретным отношением Супертип / Подтип, так как я не вижу преимущества такого типа свертывания.

Дополнительные редакции

AR.1) После выполнения упражнения для FavoriteItem, я чувствую, что пункт для проверки требует многомного отношений, так что указано.Необходимо?

Хорошо, мы идем на v1.3

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

На данный момент я признаю, что все еще не понимаю, как идентифицировать и не идентифицировать отношения.В моей модели я должен был использовать неидентифицирующие отношения с ненулевыми значениями, чтобы объединить отношения, которые я хотел моделировать.Много читая по этому вопросу, кажется, есть много разногласий и нерешительности по этому вопросу, поэтому я сделал то, что, по моему мнению, представляло правильные вещи в моей модели.Когда принуждать (идентифицировать) и когда быть свободным (не идентифицировать)?У кого-нибудь есть входы?

РЕДАКТИРОВАТЬ V1.4

Хорошо взял входы V1.3 и очистил все для этого V1.4

В настоящее время работает над V1.5 для включения атрибутов.

РЕДАКТИРОВАТЬ V1.6

ХорошоПрошло некоторое время с тех пор, как я разместил здесь, но работа над этим проектом все еще продолжается.Я публикую V1.6 сейчас, который включает ряд изменений по сравнению с последней публикацией V1.4.Эта версия показывает дальнейшее развитие ключей.Это все еще не включает атрибуты или любые AK или IE.Я начал работать над физической моделью и использовал ее, чтобы помочь проработать атрибуты и попытаться пролить некоторый свет на проблемы, возникающие у меня с определением AK и IE.Следующая публикация логической модели будет включать эти ключи и атрибуты.

Answer 1

Благодарность

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

Метод

Учитывая вашу заявленную цель и ваши продемонстрированные возможности (не говоря уже о том, что я первым разобрался с SO на вопросы Db Design, который разместил ERD вместо набора DDL), я не буду давать ответы.Я дам вам указания и указания, и вам придется совершенствовать свою собственную модель.

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

Я не ответил на основную предметную область, потому что мы все еще имеем дело с Идентификационными объектами.Когда это будет решено, Reviews и т. Д. Будет легче;сущности транзакции зависят от идентифицирующих сущностей.

Направление

D.1) Я знаю, что заявил, что мне нужно увидеть всю модель.Есть одно исключение.Исторические или временные данные или данные аудита (например, редактирование и сохраненные версии).На этой ранней стадии их можно отложить в сторону;быть реализованным непосредственно перед завершением логической модели.Это означает, что (а) они являются простыми иждивенцами какого-либо родителя; (б) родители должны сначала смоделировать по отношению ко всем остальным таблицам, и (в) исключить ненужные осложнения и, таким образом, позволить нам сосредоточиться на соответствующихfield.

• в частности, вы можете игнорировать время в глагольных фразах (в любом месте таблицы версий в противном случае потребуется Has/Had).Оставайтесь в настоящем времени, пока фокусируется на моделировании, а не на архивировании.

Unresolved

U.1) Необязательный Родитель
Это полностьюнеразрешенный.Не только IDEF1X, но и любым представлением о целостности.Если ссылка FK определена, то должен быть родитель.Чтобы разрешить дополнительных родителей, ссылка FK должна быть удалена (или не реализована).Такое условие исключит результат из определения «Реляционная база данных» по определению.Например.Address:Order.

• Конечно, в развитых странах Order должно иметь Address по юридическим или налоговым соображениям;это отдельная проблема стандартного требования.
  .

U.2) Событие
Party::PartyAddress является правильным;Address::PartyAdress правильно.Event::Address нужна работа.Адрес - идентификационная справочная таблица;если используется, это будет родитель, Event будет дочерним.Я оставляю вам право идентифицировать / смоделировать несколько Events для местоположения и Events в одном или нескольких местоположениях.

• Возможно, задействовано место проведения.Или EventOccurrence

• Но если это универсальный Event, который происходит в нескольких местах, который не нуждается в сущности, Address уже находится в Order.

U.3) Предполагая, что Catalog - это запись в традиционном смысле (JCPenney 2011), список предметов для продажи или проката.

• OrderSaleItem правильно

• Критическая точка.Catalog является зависимым и может существовать только в контексте Band, как Assset.Хорошо.Это означает, что в базе данных нет других товаров, кроме товаров группы.Правильно?

• Я вижу, как «Вечернее представление с Братьями Блюз» - это Event, который можно заказать, выставить счет и оплатить.Также рассмотрены, прокомментированы и т. Д.

• Я не вижу, как Song вписывается в это.Группы продают альбомы, песни или и то, и другое?

• Нет ли другой продукции группы: сувениры для концертов / мероприятий;плакат;рюмки с гравировкой?

• В соответствии с соглашениями об именах, на которые вы ссылаетесь, и с остальной частью базы данных, Catalog (cotent) должен называться Item (строка). Вы уже (естественно?) Использовали это в OrderSaleItem (в отличие от OrderSaleCatalog.

U.4) Жанр

• Нет проблем с an Item is classified by one-to-many Genres.

• Я думаю, что дополнительно a Genre classifies one-to-many Items. Отношение один-ко-многим (которое будет преобразовано в ассоциативную таблицу, когда мы перейдем к физическому).

U.5) Избранное
Мощность Item::Favorite перевернута. Когда вы исправите это, предметная область Favorite потребует дальнейшего моделирования.

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

• Либо Band::Favorite xor Item::Favorite правильно, но не оба.

• Item::Favorite кажется правильным, потому что Band уже идентифицирован в Item

• Аналогично, один Favorite Сущность для групп и товаров не звучит солидно. Каждый идентификатор в единственном объекте Favorite является Party. Он сломается, когда мы нормализуем, может также потребовать уточнения идентификаторов на этом этапе. Это либо одна сущность с некоторой формой дифференциации (FavoriteType), которая определяет ее обращение; или один Favorite для полос и другой для товаров, в этом случае дифференциация не требуется, двусмысленность устраняется.

U.6) Бизнес-правила Вероятно, это единственная область, в которой вы слабы. Общий ответ. Вы выполнили задачи отдельно (все моделирование и написание БР). Они не соответствуют модели. Когда вы пройдете следующий цикл, примите бизнес-правила в качестве директив и модулируйте их одновременно, как с сущностями, отношениями и глагольными фразами.

Вопрос

Q.1) Пользователь / Друг
У вас есть суть этого прекрасно. И кардинальность отношений. (Полное лечение на этом.) Это верно для Принято Friend.

• поэтому время должно пройти (идти с рядами большинства)

• Requested и в ожидании Accepted составляют меньшинство. Легко реализуется в IsAccepted бит или логическое значение.

• Позже у вас может быть IsRejected или IsBlocked (последний должен быть отдельной сущностью).

• Это то, что вам нужно?

Q.2) На чем основывается Person is zero-to-many Users?

Незначительный выпуск

M.1) Только в единственном числе.

М.2) Party Has zero-to-many Addresses. Я думаю, у них должен быть один, чтобы вести бизнес (но, возможно, не для всех Users).

М.3) Order May Have zero-to-many Payments. «Требуется» означает, что первый Payment должен быть вставлен одновременно с Order.

• Аналогично, для любых обязательных детей (один-ко-многим, а не ноль-ко-многим) этот первый ребенок должен быть вставлен одновременно с родителем. Это делается с помощью транзакций в корпоративных базах данных, поскольку Немедленная проверка ограничений ( not Deferred); и маленький конец города борется за глупые вещи, такие как Отложенная проверка ограничений «лучше», а затем тратит половину своей жизни на выяснение того, как не попасть в бесконечные петли, которые они создали, которые заманивают их в ловушку. MyNonSQL не имеет вообще ничего, так что не стоит беспокоиться об этой реализации.

M.4) OrderSaleItem должно быть OrderItem xor Order должно быть OrderSale. Зависит, если вы планируете OrderPurchase в будущем.

▶ Пример предметной области ◀

Читатели, не знакомые со Стандартом моделирования реляционных баз данных, могут найти ▶ IDEF1X ◀ полезным.

Какзаявлено, я не предоставляю готовую модель данных, только руководство. Это только одна последовательность одной выбранной предметной области. Оно не является «правильным» или полным в любом случае.

• Ваши глагольные фразы превосходны. Я предоставил вам альтернативные варианты, которые не являются «правильными» или «лучше». вам нужно выбрать прогресс их или свой собственный. Цель - быть максимально лаконичным и точным ПО в каждом конкретном случае.

• Нет предположения, что Person правильно и User неверно, что ожидает вашего ответа. Но я должен был что-то использовать в модели; поскольку вы смоделировали их как отдельные, может быть интересно оценить контрапункт.

Хорошо, продолжайте, продолжайте модель, затем отправьте сообщение снова (просто отредактируйте вопрос, оставив параметры заголовка и заменив остальные).

V1.1 и ответ

Это, безусловно, прогрессия.

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

U.3) Требуется ли полная переработка раздела Каталога или только идентификационные отношения, которые существуют с группой?

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

• Прямо сейчас Предмет существует только в контексте группы. Это зависит. Чтобы разрешить внеполосный товар, он должен быть независимым. И тогда существующий кластер супер / подтип требует доработки.

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

• Ok. Но теперь вы можете продавать только альбомы, а не песни.

, а не 2 отдельных объекта.

• Не уверен, что вы имеете в виду (у вас есть две отдельные сущности).

• Похоже, вы не видели мой ▶ Пример предметной области ◀ . Обратите внимание , что если вы откроете его сейчас, он содержит биты, которые у меня есть добавлен V1.1 ; У меня не изменилось что было вчера, ответ V1.0.

• На самом деле это означает, что вы должны снова пройти через мой ответ V1.0 при просмотре примера.

U.5) ... но как мне не понятно. Что мне здесь не хватает?

• Примером одной сущности с дифференциацией является любой из имеющихся у вас кластеров Супертип / Подтип. Фаворитом является Supertype, BandFavourite и ItemFavourite являются подтипами; позволяя каждому ссылаться на Band xor Item соответственно.

• Вы смоделировали ItemFavourite. Теперь вопрос в том, означает ли факт ItemFavourite, что группа является фаворитом; или BandFavourite - это отдельный факт? В этом примере я смоделировал последний без структуры Favorite :: ItemFavourite / BandFavourite.

Q.1) Да, я хотел бы, чтобы вас приняли, отклонили и заблокировали. Я не уверен, что вы имеете в виду, как это изменит логическую модель?

• Без изменений (я уже говорил, что оно довольно завершено) до V1.0, но вам может понадобиться дополнительная сущность.

• Вам нужны три Битовых или Булевых индикатора в Friend. Это будет обслуживать эти статусы:

  • Requested (но не принято)
  • Requested & Accepted
    ,
• Но заблокированный не является другом (или мог быть другом ранее, но не с момента блокировки). Таким образом, либо имя сущности должно быть изменено, чтобы отразить, что (без изменений двух отношений) xor Заблокированный должен быть отдельным сущностью. Два отдельных значения для второго отношения приводят к сложности, поэтому я бы пошел с последним.

С первым у нас есть дополнительные статусы:

• Blocked
  ,
  • Тогда глагольные фразы нуждаются в изменении (и я добавлю RoleName для ясности), и один из них имеет альтернативное значение. ,
  • (Это будет намного яснее на модели уровня атрибутов, поэтому мы моделируем изображениями, а не словами; поэтому я включил его.)

Q.2) Лицо не обязательно должно быть пользователем. Они могут существовать только как BandMember. Это то, что вы спрашиваете?

• Нет. Почему мы должны различать человека и пользователя? Каковы отдельные действия или атрибуты? Пока я вижу Личность и Пользователя как одну и ту же сущность; Персона является Пользователем без активности.

• Это последний пункт, удерживающий нас от работы с основной предметной областью.

M.3) Мне нужно больше узнать о проверке ограничений, чтобы убедиться, что я все понимаю.

• Не беспокойся об этом сейчас; Я дал вам причину, чтобы сделать это простым (NonSQLs, кажется, упрощают вещи, но на самом деле они делают это более сложным). MyNonSQL не обладает ни одной из этих возможностей, поэтому вы можете исключить возможность рассмотрения платформы и просто разумно смоделировать кардинальность.

M.4) Зависит от того, планируете ли вы OrderPurchase в будущем. Можете ли вы расширить, что вы имеете в виду здесь?

• В контексте модели. Вы предоставляете структуры для создания SalesOrders (из Предметов). Поэтому Item, Order и OrderItem.

• Но если вы также предоставили структуры для отслеживания заказов на покупку (для покупки предметов, а также канцелярских товаров, аренды и т. Д.), То вам необходимо различать заказы на продажу и заказы на покупку. Поэтому:

  • Пункт
  • OrderSale и OrderSaleItem
  • OrderPurchase и OrderPurchaseItem

Версия 1.1

U.2) Событие выполнено

• EventDate выглядит хорошо. Я бы определил отношение как Event Was Perfromed On EvenDate.

• В то время как ItemGenre совершенен, Event :: Venue нуждается в работе. Это ошибка, которую вы делаете постоянно, поэтому требуется объяснение.

  • Вы правильно смоделировали Venue, он независим и существует вне контекста Event. Но Event May Be [Held] At zero-to-many [Independent] Venues невозможно.

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

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

  • EventDate - хороший кандидат. У нас уже есть это и дата. Просто добавьте место и перемешайте. Я бы назвал вещь, которая происходит между событием и местом проведения, спектаклем.

• Аналогично, EventAddress прогрессировал, но не завершен.

  • У событий есть адреса или у мест есть адреса? (смоделируйте, слова не нужны)

  • Если Место проведения: вам нужны все исторические Адреса для Места проведения (например, Партия) или только текущий (как Заказ)?

M.5) SubGenre.Можете ли вы объяснить, почему SubGenre является (а) независимым и (б) отношение неидентифицирующее.

M.6) Item Is zero-to-many Favourites.Поэтому: Item Is a Favourite of zero-to-many Users.Точно так же, Each User Chooses zero-to-many Favourites.Следовательно, Each User Chooses zero-to-many Favourite Items.

V1.2 и Ответ

Большой прогресс.

U.2) Событие, продолжающееся в дальнейшем

Также и в вашем редактированиикак новые требования, некоторые да, а некоторые нет.Все остальные предметные области модели данных в значительной степени завершены (для логики), эта область запутана, а не почти решена.Частично из-за добавленных требований (никаких претензий, которые случаются в реальной жизни; речь идет о том, как вы справляетесь с этим).

Главное, что я здесь укажу, это то, что Модель данных всегда должна моделировать реальный мир,в отличие только от бизнес-требований.Это (а) изолирует DM от эффекта изменения и (б) обеспечивает надежную платформу для дополнительных требований.Это не означает, что вы должны моделировать весь реальный мир, но его части, которые вы моделируете, должны отражать реальность, а не сдавливаться, чтобы выполнить только Требование.

Во-вторых, отсутствует ясность в отношенииразличия между Событием, Band-Event, Исполнением и т. д. Сейчас событие - это Party-Band-Item-Event.Это нормально, но это не работает для нового стиля Событие в соответствии с Требованием.

В-третьих, у вас есть хорошая ручка для Адреса Сторон и Порядка, но не для Места проведения.

• Поскольку вы принимаете стандартную модель и, следовательно, обработку, адрес является справочной таблицей.

  • Независимо (квадратные углы)

  • На самом деле, вы можете разместить Адрес и все, что выше него, на первой странице;делая эту часть страницы модели второй, и на этой странице есть только Адрес.

  • Правильно смоделировано: Сторона имеет историю адресов.У них должен быть хотя бы один текущий {IsBilling |IsShipping |IsPhysical} Адрес, основанный на том, какое действие выполняется.

  • Правильно смоделировано: у заказа есть один адрес IsBilling (если вам нужен IsShipping, вам нужно добавить отдельное отношение).

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

• На самом деле Address :: Order является подозрительным.(Q.3) Хотите, чтобы Заказ указывал на какой-либо действительный Адрес или конкретный адрес Стороны, выполняющей Заказ?

• Назад к событию.Принятие EventDate как объявлено.Это хорошо, но тогда Обзоры и т. Д. Относятся к общему концерту, а не к единственному концерту, который они исполняли на грибах.Перейти на V1.3.

  • Ваша терминология относительно события и т. Д. Соответствует требованиям и т. Д., Но не поддерживает указанное требование.

  • Итак, давайте начнем использовать «событие» так, как оно используется в реальном мире, и смоделировать его таким образом.То, что мы называем «Событием», Party-Band-Item, на самом деле является Производительностью.И не общий, который запланирован, а один на определенном объекте.

  • Это либо то, что вы имели в виду с EventDate, либо EventDate преобразуется в Performance.

Если вы не возражаете, я не буду печатать тысячу слов и дам вам картинку. ▶ Пример предметной области V1.2 ◀

• Обратите внимание, что разрешены несколько полос на одно событие.

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

U.3) Не пора ли вместо этого переместить связь между Предметом и Группой до Предмета и Группы?При нынешнем дизайне я не вижу возможности продавать товары, не привязанные к группе, как вы воспитали.

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

• Во-вторых, мы не можем достичь этого, "двигая Отношение".

• Вы должны смоделировать внеполосные товары: как вы собираетесь их продавать;отслеживать это;получить за это деньги.Нужны ли вам обзоры, отзывы и т. Д. Я не понимаю, какое отношение имеет к этому партия, и сейчас мы продаем предметы группы, а не предметы партии.Рассмотрим проблемы ссылочной целостности.

Версия 1.2

AR.1) После выполнения упражнения для FavoriteItem я чувствую, чтоЭлемент для обзора требует отношения многих ко многим, так что это указано.Необходимо?

• В версии 1.1 у предмета было много обзоров, и отзыв был об одном предмете.Человек сгенерировал много отзывов (по одному на каждую вещь)Это логично.

• A Review is about many Items недопустимо.

• Во всяком случае, теперь, когда FavouriteItem / FavouriteBand разрешен, Review также необходимо разрешить.и различие: нужно ли отличать BandReview от ItemReview;хороший / плохой ItemReview указывает на хороший / плохой BandReview или они дискретны?

  • Обзор (в его нынешнем виде) не может быть о либо группа или предмет.Это означает, что два Иностранных Ключа, и один из Воля Нулевой, и Нулевых FK не допускаются.Предмет и полоса уже дифференцированы, и эта дифференциация является зрелой.

  • Обзоры предметов можно суммировать и т. Д., Но это другая история.

U.7) Это оставляет нам новую проблему для решения.Если рецензия может касаться группы, альбома, песни или исполнения, как мы можем обеспечить ссылочную целостность.Нам не нужен AlbumReview для ссылки на SongReview и т. Д. Моделируйте его.

R.5) В настоящее время модель предоставляет жанр на уровне элемента, это означает, что альбом и песня (товары могут быть запрещены с помощью ограничения CHECK).Не группа.Этого может быть достаточно, учитывая, что (a) группы меняются со временем, (b) такая классификация на уровне Предметов является более точной, и (c) жанр группы может быть легко получен из их альбомов или песен.

• Если вам нужны отдельные жанры групп, вам нужно добавить это.

• А как насчет Event Genre?Если вам это нужно, я думаю, что это будет один Жанр на Событие.

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

  • Мальчики из хранилища данных должны добавить это как Измерения к своим фактам;в правильно смоделированной базе данных они уже существуют как измерения фактов. Покажите мне все места с запланированными мероприятиями "Народная музыка", которые собрали более 10 000 человек. очень просто.
    .
• Точка обсуждения.Не сказать, что выше это неправильно.То, что я нашел и в базах данных, и в iTunes, - это точность.Почему Laissez Faire Жанр :: Несколько вещей, когда вы можете иметь Жанр :: Конкретные вещи.Если у вас был только Genre :: Song, а у Song только один жанр, то Album и Band - точные свертки.То, как мы это имеем сейчас, зависит от музыкальных знаний человека, занимающегося вводом данных, и Genre :: Thing очень много, поэтому он бесполезен.Жанр :: Песня жесткая.

R.6) участники могут показать, что они будут присутствовать на Событии не моделируется.Также уточните проценты против бронирования против посещаемости.

R.8) Не моделируется.

M.3) Проблема закрыта, но глагольная фраза остается неизменной.

M.7) Логическая модель в сравнении с ассоциативными таблицами.Теперь, когда эта проблема закрыта, удалите все ассоциативные таблицы для логической модели;любые оставшиеся таблицы (между двумя родителями) будут содержать данные.Это означает, что просмотрите все зависимые таблицы и удалите все, у которых нет данных.Таким образом, V1.3 должен быть менее загроможденным.

M.8) Item is OrderItem.

M.9) Теперь, когда Party-Person-User разрешен.Для структуры Exclusive Subtype требуется Discriminator , а Constrainst будет использоваться для обеспечения целостности.Там, где их много, PartyType - это путь.Но только для двух вполне достаточно столбца IsBand или IsPerson.

M.10) Вы исправили ошибку, связанную с кардинальностью, но некоторые глагольные фразы все еще идут не в ту сторону.

27 января 11

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

Q.3) Заказ: Адрес подозрительный.Ограничение не совсем корректно, потому что это позволило бы заказу иметь любой адрес, а не адрес, специфичный для стороны, выполняющей заказ.

Но так как вы являетесь MyNonSQL, который имеетнет ссылочной целостности, вы можете не знать, как это делается в реальном SQL, поэтому я предоставлю определения FK, которые также являются ограничениями RI.Как-то несправедливо ожидать, что вы поймете мои краткие утверждения, которые основаны на RM, нормализации и поддерживаются SQL, когда у вас нет SQL.

• Для того, чтобы два ограничениябыть правдой, так как Party должен быть одинаковым в каждом Ограничении (имеется только один Order.PartyId), будет разрешено только подмножество PartyAddress, которое принадлежит PartyId.

▶ Пример квалификации адреса ◀

Продолжение в части II ...

Answer 2

... Часть II

V1.3 и Ответ

Святой Толедо!Вы готовите с газом, молодой парень.Все проблемы либо незначительны, либо связаны с новым шагом, который вы изучаете.

Идентификаторы и столбцы идентификаторов

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

• Вот пример ▶ Пример: , проверьте вопрос подробно первый .Обратите внимание, что Марк вполне способен, но полностью застрял. Затем прочитайте мой ответ, затем посмотрите на модель данных.(Пожалуйста, сделайте это сейчас, это обеспечивает контекст)

• Идея состоит в том, чтобы или смоделировать данные как данные, которые мы делаем, и вы в конечном итоге получитебаза данных, xor stick Id столбцы на всем, что движется, что мешает моделированию и нормализации, и вы получите кучу электронных таблиц, "связанных" друг с другом с огромным дублированием и без производительности.

• Поэтому удалите все столбцы формы [Table]Id из всех таблиц (оставьте Мигрированные ключи в покое, они правильные), , за исключением в следующих таблицах (это основных идентификаторов, отраженных во всей базе данных. Обратите внимание, как ERwin исправит все дочерние, внучатые и т. д. таблицы:
  Party
Address
Item

реляционные / IDEF1X идентификаторы

Вы изучаете идентификаторы. Это естественные ключи. Либо ключи, которые использует пользователь, либо ключи, которые имеютМигрировали из парене для ребенка, как иностранные ключи.Поэтому они не только идентифицируют отношение, но также идентифицируют ребенка.Ваша фамилия говорит мне не только о вас, но и о вашем отце, а также о том, что вы сын своего отца.Хотите сделать это уникальным?Нет проблем, просто добавьте имя.

Вы читали мои ответы, просматривали мои модели данных, а затем добавляли идентификаторы в вашу модель.Это ** намного * проще, чем это.ERwin (поскольку он реализует IDEF1X) делает это за вас.

• Take Party, Band and Person.Идентификатор стороны: PartyId
  (хорошо, это суррогатный ключ, а не естественный ключ; но естественный ключ Lastname, FirstName,BirthDate и т. Д. Очень длинный, если мы используем его в качестве первичного ключа)., это будет перенесено на детей, внуков, правнуков, что нежелательно, поэтому мы добавляем короткий суррогатный ключ и делаем его первичным ключом)

• Когда вы создаете подтипы в ERwin и указываете отношение, оно автоматически поместит PartyId в Band и Person в качестве PK;он будет помечен как "(FK)".(Примечание: я использую жирный шрифт для обозначения (FK) в моих моделях.)

• Вот и все, все готово.Party :: Band - 1: 0-1, первичный ключ диапазона - PartyId.Поскольку это подтип, ERwin обеспечит, чтобы отношение равнялось Идентификация , и, следовательно, родительский PK окажется в дочернем PK, а у зависимого дочернего элемента закругленные углы.подтипы были не задействованы, это было бы то же самое, за исключением того, что отношение не может быть 1 :: 0-1, это может быть 1 :: 1-n.В этом случае вам нужно добавить еще один элемент, чтобы сделать его уникальным, например, f FirstName или SequenceNo

• И вы должны указать ERwin, что вы хотите Идентификация Связь.(Если вы этого не сделаете, то это обычный FK, и столбцы будут ниже линии; таблица будет независимой; квадрат углов).
• И если в какой-то момент вы решите использовать этиFK столбцы, чтобы сформировать PK, вы просто нажимаете на Relation и изменяете его с Неидентификация на Идентификация;столбцы будут перемещены выше линии;углы будут круглыми.

Роль

• Теперь для следующего шага.Мы знаем, что Band :: Party равен 1 :: 1;эта группа - дитя партии;что Band.PartyId является идеальным PK (столбец Id не требуется).То же самое для человека.Но это глупые имена, или, другими словами, Band на самом деле - это другая Роль к Человеку, и они оба - Партия.Поэтому мы хотим четко идентифицировать Роль.

  • В Band мы хотели бы назвать PartyId, BandId, чтобы отразить ее Роль.Отредактируйте Отношение между символом подтипа и дочерним элементом, а не таблицей.В диалоговом окне введите RoleName как BandId.Вот и все.Вы сделали.

  • Таким образом, следующее изменение с ... на: <pre> FloorItem.ItemId FloorItemId BandItem.ItemId BandItemId Следовательно ... <pre> Other.BandItemId OtherId Album.BandItemId AlbumId Song.BandItemId SongId Performance.BandItemId PerformanceId

• Удаление всех столбцов [Table]Id оставит следующие таблицы без PK.А пока добавьте столбец Name в качестве PK.Позже вы можете сказать мне, что пользователь хотел бы для естественного ключа, Идентификатор для этих таблиц: Событие
  Жанр

• PartyAddress является примером (т.е. смоделирован правильно) того, чтовсе что я обсуждал выше.У него не было PartyAddressId.PartyId и AddressId вместе образуют ПК.Оба Отношения являются Идентификационными.

Идентификация против Неидентифицирующих Отношений

При прочтении большого количества материала на эту тему, кажется,много разногласий и нерешительности по теме

• Да.К сожалению, любой человек с клавиатурой и модемом может «публиковать» в эти дни.Люди публикуют мнения как факты;они публикуют глупости о предметах, о которых они ничего не знают.Это сбивает с толку людей, которые пытаются учиться.

• Это наука, а не магия или черное искусство, а не мнение.

• При обучении,читать только определения и слушать только тех людей, которые четко передают науку (а не тех, кто смущен или относится к науке, как к искусству или к тому, что она подчиняется мнению).Мы изучаем факты, законы физики, а не мнения о законах;законы действуют одинаково для всех на всей планете.Вы не можете учиться у того, кто считает факт мнением.

• Давайте возьмем его сверху:

  1. Отношение - этоопределение критериев (делает ребенка независимым / зависимым), а не наоборот.

  2. A Отношение всегда является FK в дочернем элементе родительского PK.

  3. В Идентификации Отношение, что FK - это PK (или первая часть PK, где PK - это составной ключ).И ребенок является зависимой таблицей.

  4. В неидентифицирующем отношении, что FK является столбцом не-PK, а ребенок Независимо (оно может быть вызвано в Зависимость некоторым другим отношением).

  5. Все подтипы имеют идентифицирующие отношения из супертипа.В противном случае они не были бы подтипами, они были бы независимы от супертипа.

  6. Все отношения 1: 0-1 являются идентифицирующими.

поэтому я сделал то, что, как мне казалось, представляло правильные вещи в моей модели.

• Возможно, именно поэтому вы в итоге добавили [Table]Id ключи.

Когда вызывать (идентифицировать) и когда освобождать (не идентифицировать)?

• Никогда не заставлять что-либо повторно моделировать (База данных и функция)), особенно повторные данные.Это неконтролируемое, что мы хотим администрировать, управлять, формировать, контролировать и т. Д. Но чтобы сделать это эффективно, мы должны сначала понять это.Мы ничего не можем понять, когда заставляем это.Принудительное лишение лишает его возможности разоблачать себя и лишает нас возможности замечать тонкости и ароматы (потому что мы «знаем» это).Пусть он будет свободным, но ограниченным, как лошадь в загоне, а не как заключенный в конюшне.

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

• Как указано выше, именно Отношение является Идентифицирующим или нет;не является ли Компания независимой или нет, это является следствием.

Сделайте это в реляционном стиле / IDEF1X / ERwin style:

1. Вы хотите создать сущность, нарисуйте сущность.Назови это.Если это не первая сущность на холсте, не добавляйте ключи .

2. Теперь рассмотрим его отношения.Как сущности, которые вы уже смоделировали, относятся к этой новой сущности?Нарисуйте эту связь (отношения родителя с ребенком).

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

4. Если вы думаете, нет, нет, я хочу, чтобы это было независимо , тогда вам лучше иметь вескую причину,Ключевой вопрос здесь заключается в том, существует ли эта сущность полностью самостоятельно, существует ли она вне контекста других независимых сущностей?AFAIC, в вашей модели их пять:
   Адрес
   Партия
   Предмет
   Событие
   Жанр

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

   • Напомним, у нас был Item как Независимый ранее;тогда у нас была новая форма Предмета;который сделал старый Item, BandItem;что сделало BandItem зависимым от нового Item.

   • У нас был отличный Идентификатор в ItemId, который был не только в (тогда) кластере Item, но и во всем, в OrderItem, Reviewи т. д.

   • Мы изменили контекст Предмета (создал Предмет более высокого порядка), и из-за Идентификационных Отношений , что было затем перенесено повсюду, иНовый BandItem был перенесен в своем контексте.

   • Новый ItemId продолжает оставаться отличным Идентификатором.BandItemId в точности ItemId, но играет определенную роль, это подмножество / подтип ItemId.

5. Так что, если это действительно Независимая сущность, продолжайте и дайте ей новый PK.

   • Но на этом этапе, а не столбец Id, что-то значимое, что идентифицирует сущность.Event.Name, Customer.Code.Никто из людей не идентифицирует Клиента как номер 123456, нет, они думают о «IBM», «3M» и т. Д. Позже, по мере развития модели, мы позаботимся о том, чтобы у нас были действительно хорошие Ключи;Прямо сейчас с новой сущностью мы заботимся о том, чтобы у нее был Идентификатор.

   • Исключение.Что касается Адреса, Партии, Предмета, вы знали, что в версии 1.0 у вас их будут миллионы, тысячи, тысячи;что это были основные идентификаторы, которые будут интегрированы по всей базе данных;что истинный ПК был очень длинным;и что вам нужен короткий суррогатный ключ в качестве ПК;таким образом, вы создали это с самого начала, и вы не получили никаких аргументов от меня.

     • Если вы готовы к Доменам, тогда INT, INTOR SMALLINT, SMALLINT.

     • В противном случае Name, CHAR (30).

6. Следующим шагом является завершение PK на новом объекте.Если количество элементов родительского элемента равно 1 :: n, у него уже есть PK родительского элемента, просто добавьте элемент, чтобы сделать PK уникальным.Давайте посмотрим на порядок.У него уже есть PartId, поэтому OrderNo может быть в пределах PartyId.Просто измените порядок столбцов PK на (1) PartyId, (2) OrderNo.

7. Единственный раз, когда мы делаем небольшое принуждение, это когда число столбцов, образующих PK, становится слишком большим, илиобщая ширина PK становится слишком широкой, чтобы мигрировать как FK в детей.Тогда, и только тогда, мы создаем дополнительный суррогатный ключ в форме [Table]Id (они всегда дополнительные, мы не можем потерять настоящий PK или уникальность, потому что он поддерживает другие требования).

   • AFAIC, это магическое число равно семи (на самом деле магическое нет для многих вещей; даже этот элемент отображается как число семь), и эта максимальная ширина составляет 30 байтов. Это было сделано с самого начала с помощью адреса (уже оптимизированного), стороны (иначе 64 байта), элемента (более 30 байтов).

   • Если мы собираемся сломать внутреннюю Реляционную силу, нам нужна боль от того, что эта Реляционная сила сама по себе является действительно плохой, и ни по какой другой причине. Даже не приближаясь к этому в вашей модели.

Обзор кластера

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

1. Работа с кластером обзора как есть. Нам нужны SongReview и AlbumReview. И избавьтесь от ItemReview (который инкапсулирует все Предметы, что означает, что мы удваиваемся). Я думал, что мы исключаем Обзоры для предметов, не принадлежащих группе.

2. Разрешить non-BandReview быть о любом BandItem, например. изменить ItemReview FK с Item на BandItem. Это инкапсулирует все BandItems в ItemReview. Избавьтесь от PerformanceReview.

   • Конечно, вы не хотите, чтобы BandItem.Other был рассмотрен; это может быть ограничено другими средствами. Но если вы хотите быть строгим, тогда вам нужно (1).

Цвет

Здорово, что вы приняли мою цветовую схему.

• Значение, визуальная релевантность не проявляется в крошечной модели (большинство моих моделей на SO); он отображается только на более крупных моделях, таких как ваша.

• Поскольку вы проделали такую ​​замечательную работу с V1.3, у учителя есть ▶ яблоко для вас ◀ . На самом деле, документ ▶ IDEF1X ◀ стоит прочитать еще раз, он очень сжатый, и мне говорят, что люди получают больше пользы от него, когда читают его после моделирует что-то. Что мне нужно знать, так это то, делают ли Естественная Иерархия и Цвет что-нибудь для вас.

• Это просто завершает логический уровень сущности.

Вы можете продолжить с уровня логического ключа (единственные атрибуты - это FK, и мы знаем, что это такое). Но не стесняйтесь начинать определять атрибуты (в этом случае покажите уровень атрибутов).

Необязательный столбец

U.1) Необязательный родитель вернулся в модель. PartyAddress is shipped for Order не является Nullable.

• Если вы намеревались смоделировать, что адрес доставки является необязательным, то вам нужен объект OrderShipAddress, который является дочерним по отношению к Order, и количество элементов составляет 1 :: 0-1.

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

Minor

M.11) Они были правильными в V1.2
Отзыв :: Комментарий 1 :: 0-1
BandMember :: Комментарий 1: 0-n

M.12) Event :: Person - это n :: n (и столбцы не будут отображаться на логическом уровне)

V1.4 и ответ

Очень хороший прогресс. Довольны ли вы Идентификаторами, Ключами?

U.8) (Если вы сделаете это первым, остальное будет легко выполнено.) Ограничение ERwin. Поздравляем, вы создали модель, которая достигла ограничений возможностей ERwin в области логического моделирования. Чтобы быть ясным, это на самом деле не предел, поскольку он разрешается в физической модели, и, конечно, это не ограничение в IDEF1X или реляционных базах данных. Но сейчас, в Logical, это мешает вашему обучению и прогрессу.

• В BandItem мы хотим, чтобы PK был (BandItemId, BandId). Но ERwin не допустит этого, потому что говорит, что Подтип ПК должен быть Супертипом ПК и ничего, кроме . На самом деле, пока Супертип PK является ведущим Идентификатором, приемлемо другое Идентификационное Отношение. Чтобы обойти это:

  • отбросить символ подтипа
  • создать два идентифицирующих элемента отношения :: FloorItem и Item :: BandItem

• Отношения, которые мы должны были сделать Неидентифицирующими, теперь могут быть Идентифицирующими.

• ERwin теперь разрешает перенесенные PK как FK, без дублирования.

• Да, забросьте Роли обратно.

U.9) Теперь я понимаю, что вы пытаетесь сделать с кластером обзора, поэтому сначала позвольте мне сказать, что вы смоделировали его правильно, вплоть до рейтинга.

• Но в самом Review есть основная проблема. С PK ReviewerId одному Рецензенту будет разрешен только один отзыв. Конечно, вам нужен один обзор на рецензента на группу / BandItem, но это скрыто в подтипе. В основном использование Supertype-Subtype здесь слишком ограничено. Приятно понимать, что на этом раннем этапе, но теперь нам нужно выйти за рамки этого.
  • Вместо кластера обзора создайте две таблицы обзора: BandReview и ItemReview.
  • Отношения будут Person :: BandReview и Band :: BandReview, а Person :: ItemReview и BandItem :: ItemReview
  • Тогда у каждого из них будут дети% Rating,% Comment,% CommentRating.

M.13) Order :: OrderShipAddress равен 1 :: 0-1, правильно. PartyAddress :: Порядок 1 :: 0-n, правильный Поэтому адрес доставки должен быть PartyAddress :: OrderShipAddress 1 :: 0-n

M.14) Платеж в настоящее время допускает только один платеж для каждого Заказа, который может быть тем, что вам требуется, но соотношение 1: 1-n. Если вам нужно больше, добавьте SequenceNo на ПК.

M.15) Жанр в порядке. Но SubGenre нужно что-то в ПК, чтобы позволить более одного жанра. Теперь я бы изменил Genre.Name на Genre.Genre и добавил SubGenre в SubGenre PK. - это также исправит Event.GenreId.

M.16) Место проведения пока требует Имя для ПК. Если вы готовы к лучшим ключам, тогда ShortName и Name перемещаются вниз как атрибут.

Q.4) Подтверждение. Поскольку у нас есть идентифицирующая связь в порядке и PK (PartyId, OrderNo), следовательно, OrderNo - это порядковый номер в PartyId, верно?

Перейти на V1.5 . Включите некоторые атрибуты. Лучший способ определить их - это запустить функциональную модель (и теперь работать с ней вместе с моделью данных) или, по крайней мере, проработать все функции для всех экранов.

Приветствия