为以下设计架构的最佳方法是什么？

Question

为以下设计架构的最佳方法是什么？ 要求？

需要存储国家，州，县和县可以划分 进入地区。然后，区域可以具有各种数据点的人 报告。

区域也可以进一步划分为分区 喜欢分组人。因此，区域1可以具有A区，B区 与每个部门的人员。地区和部门各有 与国家，州和县不同的不同元数据集。

报告将涉及与人和类似人员相关的数据 谷歌分析与从国家深入挖掘所有 通往区域和部门。

注意：地区可以有10人，1人有4人，其余6人 与任何分工无关。

Answer 1

脱离我的头顶：

• 国家，州，县，城市都有fk到地区。
• 州有fk到国家
• 县有fk到州
• 城市有fk到县
• 地区有fk到分部
• 人们有fk到divisions_people
• divisions_people对人和部门有fk

• 部门有fk到divisions_people

  country <- state <- county <- city
    ^          ^         ^      ^
     \          \        /     /
                 regions
                    ^
                    |
                divisions
                    ^
                    |   
                   \|/
              divisions_people (1 person in multiple divisions)
                    ^
                    |
                  people
  

Answer 2

听起来每个人都可以拥有一个且只有一个区域。

如果您正在进行事务处理（而不是数据挖掘/仓储），那么我会使用RegionID外键将该人链接到该区域。

就（可选）部门而言，您可以使用链接表将人员链接到某个部门：PersonID，DivisionID或者如果您不介意NULL { {1}}，你可以拥有一把外键。

就地理区域的层次结构而言，我会毫不犹豫地对此进行建模，直到我更多地了解各国的限制以及这些结构所代表的含义。虽然很高兴认为所有内容总是达到一个新的水平，但我已经处理了很多层次结构，其中跳过了级别，并且这些层次结构的建模方式截然不同。此外，像英国这样的许多国家通常不会拥有国家（除非您打算使用英格兰，苏格兰，威尔士和北爱尔兰）。 France is even more complex

对于报告/汇总方面（或者如果你只是进行数据挖掘/仓储），我会转换为一个单独的维度模型，它将“锁定”其他东西作为属性，并使其更容易做到卷起来。因此，星型模式将锁定不同级别的维度ID。

Answer 3

国家/地区的表格： country_id，country_name，population

状态表： state_id，state_name，country_id，population

县的表： county_id，county_name，state_id，population

区域表： region_id，region_name，county_id，population

分区表： division_id，division_name，region_id，population

在您的代码中或通过触发约束（取决于您的RDBMS）验证您在一个只有50人的区域内没有300人的分区。为了让一个地区的人不在一个区域，你的地区人口将是500，而其划分的总和只有450（在一个地区只剩下50人，但是没有部门）。