And*_*ini 3 sql database sql-server database-design sql-server-2005
在我们的数据库模型中,我们有一个受益人实体.受益人可以是自然人或公司受益人; 一个物理受益人有许多属性,如姓名,性别等; 此外,受益人(公司或自然人)可以是外国的,也可以不是; 这种进一步的区别转化为"共同"属性集的不同域值(例如,在我居住的意大利,税ids可能具有与英国税ids不同的数据格式).
我们现在正在重新设计受益人表,因为最初从事数据库分析和建模工作的开发人员做了一个(IMO)短视选择.他将主键约束放在属性BeneficiaryName上,用于存储公司名称(例如"Microsoft Corporation")(如果是公司受益人)或姓氏(例如Smith)用于实际受益人.这样我们就有了(不可接受的)约束,我们的数据库中不能有超过1名姓氏为"Smith"(或名为"Smith"的公司)的受益人.
我对这种"重新分解"的方法将引入受益人实体的概括; 我会
这应该解决上述BeneficiaryName的唯一性问题.到目前为止似乎还可以吗？
我遇到的真正问题是:我该怎样/应该如何处理这个模型中"外来"属性所增加的复杂性？我应该留下外国,即受益人的旗帜属性吗？如果是这样,我如何处理对于概念上类似的信息(即邮政编码,税号)以及重复属性(zipcode_foreign,zipcode,taxid_foreign,taxid等)的不同属性的需求？我是否真的应该努力将不同的域值容纳到一个字段中？
任何建议都会受到欢迎......
"清洁受益人表,只保留共同数据;"
究竟是做什么的.
"将一个代理主键添加到受益人表中,我们称之为BeneficiaryID;"
可能有用,但不要忘记,如果存在"自然"标识符,那么也应该强制执行此操作的唯一性.
"拆分受益人表,创建两个子实体(CorporateBeneficiary&PhysicalBeneficiary")
对.注意到很难强制执行"绝对"数据完整性(在所有NaturalBeneficiaries都是受益人的同时执行,所有非自然受益人也是受益人,并且所有受益人都是自然或非自然受益人).
"主受益人表中的旗帜歧视"
不.不会这样做.该标志是冗余的,冗余增加了复杂性而没有增加值.如果您想知道受益人是自然人还是非自然人,请查看记录该事实的表格.
"查找(有意义的)CorporateBeneficiary&PhysicalBeneficiary的主键;"
如果您一般为Benficiaries引入代理,则无需在这些其他表中复制自然标识符.这又是冗余,增加了复杂性而没有增加价值.
"我遇到的真正问题是:我该如何处理这个模型中"外来"属性所引起的进一步复杂化？""
您可以应用相同的方法,区分National和ExtraNational(针对公司和物理Benficiaries),如果数据完整性至关重要,例如至少是National Benficiaries,那么这可能是从建议到绝对必要的任何事情.例如,根据国家规则,可能适用法律强制您验证国家SSN号码或国家公司识别号码是否"有效".如果此类法律适用,则可能必须由 DBMS 检查此类规则,而不仅仅是您的应用程序.当然,对于非国民,通常也不需要类似的检查,或者甚至一般不可能.
如果在数据库结构中考虑国家和非国家之间的这种区别,你很可能也想创建一个"联合"两个(国家和非国家)在一起的视图,然后你将不得不将您的数据"转换"为"统一"的"通用"格式,这可能只是CHAR(即使您知道,例如,对于National PhysicalBeneficiaries,内容将是他们的SSN号码,您知道它包含一些固定数字数字).
如果您不必在数据库结构中考虑国家和非国家之间的这种区别,那么您将被迫在单个表中使用相同的"统一""通用"格式来保存数据国内和国外.