数据库:模式验证

时间:2011-01-12 03:18:33

标签: database database-design database-schema

我可以获得以下模式子集的输入吗?

![alt text] [1]

此数据库的目标之一是能够存储两种完全不同类型的成员的成员资格信息。在这个模式中,我只是将它们命名为用户和企业。我对这个数据库的设计已经足够了,并且知道用户和企业将来自这里所示的不同表。关注的是跟踪其会员信息。

以下是一些知识:

  • 两类会员都是付费方
  • 会员资格可能会失效,检查会员资格何时到期非常重要
  • 在跟踪会员日期的状态时,需要发布订阅日期,供会员查看和发送续约会员的提醒
  • 暂停的成员仍将存在于数据库中以便重新激活,但在此之前无法访问
  • 每个成员,无论何种类型,都有自己唯一的成员ID,每个用户/企业只能拥有一个成员资格

Membership_Types表将保存有关会员是付费会员还是会员或任何团体会员资格的信息。

在User_Memberships和Business_Memberships表中,我确定了一个member_status属性,因为我需要快速查看成员资格的活动状态。我不应该在这里使用布尔状态,而应该使用membership_suspended_date将其切换出来,然后执行计算呢?

对此设计的好坏的任何输入将不胜感激。感谢

修改

尝试考虑来自dportas的输入#2。

![alt text] [2]

由于只有成员(用户或企业)的给定唯一实例,我添加了membership_change_date来捕获成员的历史记录,如果他们要从免费转为付费再免费等等。

此处的任何输入仍在考虑上面列出的原始标准。

3 个答案:

答案 0 :(得分:1)

“每个用户/企业只能拥有一个会员资格”

您显示的表格设计似乎“过度标准化”,并且不会对您描述的内容进行建模。关键的见解是,任何类型的成员只会被记录一次,无论他们是企业还是“用户”,并且他们永远保留他们的帐户,即使它已经失效并重复恢复。这意味着您只跟踪一件事:users = members = enterprises。到目前为止,这意味着一张桌子。

您的第二个表是每个成员/用户/业务的交易历史记录。请注意,comp作为0.00美元的付款。

“Membership_Types表格将保存有关会员是付费会员或会员或任何团体会员资格的信息。”

好的,这是第三个会员类型表,其中包含定价的详细信息。

在我说出如何解决这些问题之前,你必须告诉我们更多关于团体会员资格的信息。

至于其余大部分要求,它们都是关于通知的,它们来自交易表。

答案 1 :(得分:1)

这两个内嵌图形没有出现在我的浏览器中,因此我将按照您的文字和Ken的回答。

我不相信这个问题已得到充分处理。

  • 您认为Membership_Type的desc是Subscription_Type

    • SubscriptionType包含通用信息定价,条款等

    • 订阅会保留会员的具体定价,到期日等信息。

  • 是的,这是Supertype-Subtypes或Orthogonal Design的典型案例(通常需要,但遗憾的是不常理解)

  • 会员是超级型;用户和业务是独家子类型。 Relational为1 :: 0-or-1,每个Member

  • 必须存在一个Subtype
  • UserId和BusinessId是MemberId的RoleNames,在子类型中实现为主键,也是成员的外键;子类型中没有其他Id列。

  • 在SQL中以声明方式轻松实现

  • 这是纯粹的第五范式

  • 在任何标准SQL(非SQL中的代码)中维护完整参照和数据完整性

  • 会员的状态很容易从最新的订阅行MAX(Subcription.Date)派生。

    • 为此目的,Member中的任何标志或布尔值都是重复数据,并将引入更新异常(其中规范化模型没有)。

▶Membership Entity Relation Diagram◀

不熟悉关系数据库建模标准的读者可能会发现▶IDEF1X Notational◀有用。

如果您提供Group :: Member信息,我可以对其进行建模。

答案 2 :(得分:0)

我建议您为两种类型的成员资格(类型代码,状态,日期,持续时间)共有的所有数据创建一个新的超类型表。作为一项规则,我认为这些列出现在一个表而不是两个表中会更好。事实上,这条规则有一个名称:The Principle of Orthogonal Design

此模式可能对您有用:http://www.tdan.com/view-articles/5014