База данных: проверка схемы

Question

Могу ли я получить информацию о следующем подмножестве схемы?

! [Альтернативный текст] [1]

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

Вот некоторые известные:

• Оба типа участников будут оплачивать вечеринки
• Членство может истечь, и важно проверить, когда членство должно наступить
• При отслеживании статуса дат членства необходимо будет публиковать даты подписки, чтобы участники могли видеть, и напоминания рассылались для возобновления членства
• Приостановленные члены все еще будут существовать в БД для повторной активации, но не будут иметь доступа до тех пор
• У каждого участника, независимо от его типа, будет свой уникальный идентификатор участника, и у каждого пользователя / организации может быть только одно членство

Таблица Membership_Types будет содержать информацию о том, является ли участник платящим участником, участником или участником какой-либо группы.

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

Будем весьма благодарны за любой вклад в хорошие или плохие конструкции. Спасибо

EDIT

Попытка # 2, пытающаяся принять во внимание информацию от dportas.

! [Альтернативный текст] [2]

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

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

Answer 1

"каждый пользователь / организация может иметь только одно членство"

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

Ваша вторая таблица - это история транзакций для каждого участника / пользователя / бизнеса.Обратите внимание, что акция входит в качестве платежа с 0,00 долларов.

«Таблица Membership_Types будет содержать информацию о том, является ли участник платящим или является членом компа или частью какого-либо членства в группе».

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

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

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

Answer 2

Две встроенные графики не отображаются в моих браузерах, поэтому я следую вашему тексту и ответу Кена.

Я не верю, что этот вопрос был полностью решен.

• Мне кажется, что ваш дескриптор Membership_Type является Subscription_Type

  • SubscriptionType содержит общую информацию о ценах, условиях и т. Д.

  • Подписка содержит информацию о конкретных ценах, сроках истечения и т. Д. Для Участника.

• Да, это классический случай для Подтипов Супертипа или Ортогонального дизайна (обычнотребуется, но, к сожалению, обычно не понимается)

• Член является супертипом;Пользователь и бизнес являются эксклюзивными подтипами.Относительный 1: 0 или 1, и для каждого члена должен существовать один подтип.

• UserId и BusinessId - это RoleNames для MemberId, реализованные как первичные ключи в подтипах, что такжевнешний ключ к члену;в подтипах нет дополнительного столбца Id.

• Легко реализуется декларативно в SQL

• Это чисто пятая нормальная форма

• Полная ссылочная целостность и целостность данных поддерживаются в любом стандартном SQL (код в не-SQL)

• Статус члена легко определяется из последней подпискистрока MAX(Subcription.Date).

  • Любой флаг или логическое значение в Member для этой цели является дублирующими данными и будет приводить к аномалии обновления (если в нормализованной модели их нет).

▶ Диаграмма отношений между субъектами членства ◀

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

Если вы предоставите информацию о группе :: Участник, я могу смоделировать это.

Answer 3

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

Этот шаблон также может быть полезен для вас: http://www.tdan.com/view-articles/5014