数据库规范化混乱？

Question

我有 5 张桌子：

1. tblProvince
2. tblDivison
3. tbl区
4. tblCity
5. tbl 选区

tblProvince:

• 身份证
• 姓名
• 区域

TblDivision:

• 身份证
• 姓名
• 区域
• Province_id

tblDistrict:

• 身份证
• 姓名
• 区域
• Province_id
• Division_id

tblCity:

• 身份证
• 姓名
• 区域
• Province_id
• Division_id
• District_id

TblConstituency:

• 身份证
• 姓名
• 区域
• Province_id
• Division_id
• District_id
• City_id

这是存储数据的正确方法吗？添加区域的完整细节。

或者我应该只保存前一个区域的 id（比如 city 是选区的容器）。要存储选区的详细信息，我应该用它来广告 city_id。

像这样……

tblCity
+-------------+
| ID          |
+-------------+
| Name        |
+-------------+
| Area        |
+-------------+
| District_id |
+-------------+

TblConstituency
+-------------+
| ID          |
+-------------+
| Name        |
+-------------+
| Area        |
+-------------+
| City_id     |
+-------------+

如果我想获得有关选区的完整详细信息，我可以得到城市的 id，从城市我可以得到区，从区我可以得到部门等等。

但是，我觉得这太过分了。每次我需要获取详细信息时，这将是一个很长的查询。

那么，最好的方法是什么？

P.S：抱歉我的问题描述不好。

Answer 1

永远不要将相同的信息存储两次。这意味着您必须手动保持该信息同步，并且同步很困难且容易出错。基本上，只要你有多个真相来源，你的真相来源就为零。

在这里考虑您的表格：

Division
+-------------+
| ID          |
+-------------+
| Name        |
+-------------+
| Area        |
+-------------+
| Province_id |
+-------------+



District
+-------------+
| ID          |
+-------------+
| Name        |
+-------------+
| Area        |
+-------------+
| Province_id |
+-------------+
| Division_id |
+-------------+

Division 已经在存储Province_id。那么为什么District 也需要存储它呢？如果District 存储的Province_id 与其对应的Division 记录不同，会发生什么情况？ District 哪个是正确的？

只需链接到直接父记录：

District
+-------------+
| ID          |
+-------------+
| Name        |
+-------------+
| Area        |
+-------------+
| Division_id |
+-------------+

与Division 表相关的信息已经存在并且可以查询。 （基本上，这就是JOIN 关键字的用途。）既然您已经掌握了这些信息，则无需重复。

Answer 2

通过 BCNF 进行标准化是基于函数依赖的。什么 数据中的函数依赖是这样的吗？什么是 候选键？

城市 州县城 -- 阿拉巴马派克特洛伊 阿肯色派克喜悦 佛罗里达湾斯普林菲尔德 缅因州佩诺布斯科特斯普林菲尔德

这里只有一个（微不足道的）函数依赖，而且只有一个 候选键。唯一的 FD 是 State, County, City -> State, County, 城市。唯一的候选键是 {State, County, City}。这种关系 至少处于 5NF。

你不能改善这种关系，但你可以改善 数据库。数据库不知道没有名为“洛斯”的县 洛杉矶”在阿拉巴马州。所以它会让你插入这个无效的行。

城市 州县城 -- 阿拉巴马州洛杉矶特洛伊

要修复那个问题，添加一个包含所有有效的关系 县，并设置外键引用。

县 状态 -- 阿拉巴马州奥陶加 阿拉巴马州鲍德温 ... 阿拉巴马派克 ... 加利福尼亚洛杉矶 ...

关系“Counties”是全键，没有非质数 属性。 “Counties”也至少在 5NF 中。

数据库仍然不知道它不应该允许这样的行。

城市 州县城 -- 威尔士派克特洛伊

美国没有名为威尔士的州。同解决这个问题 方式作为最后一个问题。

状态 -- 阿拉巴马州 阿肯色州 ... 加利福尼亚 ...

并设置从县到州的外键引用。

这是标准 SQL 中的样子，除了我没有 供应所有 50 个州或所有 3000 多个县。

create table states (
  state varchar(100) primary key
);

insert into states values 
('Alabama'), ('Arkansas'), ('California'), ('Florida'), 
('Maine'); -- and more . . .

create table counties (
  county varchar(100) not null,
  state varchar(100) not null,
  primary key (county, state),
  foreign key (state) references states (state)
    on update restrict on delete restrict
);

insert into counties values
('Autauga', 'Alabama'), ('Baldwin', 'Alabama'), ('Pike', 'Alabama'), 
('Pike', 'Arkansas'), 
('Los Angeles', 'California'),
('Bay', 'Florida'), 
('Penobscot', 'Maine'); -- and more . . .

create table cities (
  city varchar(100) not null,
  county varchar(100) not null,
  state varchar(100) not null,
  primary key (city, county, state),
  foreign key (county, state) references counties (county, state)
    on update restrict on delete restrict
);

insert into cities values 
('Troy', 'Pike', 'Alabama'),
('Delight', 'Pike', 'Arkansas'),
('Springfield', 'Penobscot', 'Maine'),
('Springfield', 'Bay', 'Florida'); -- and more . . .

现在你会发现无法插入无效元组 {Troy, Los Angeles, Alabama} 和 {Troy, Pike, Wales}。

使用代理 ID 号而不是自然键不会改变 正常形式。但它确实改变了数据库的工作方式。并不是 一定是好的。

使用上面的 SQL 表，此更新将失败。

update states
set state = 'Wibble'
where state = 'Alabama';

这是一件好事。

让我们用代理 ID 号来构建这些表。

create table states (
  state_id integer primary key,
  state varchar(100) not null unique
);

insert into states values 
(1, 'Alabama'), (2, 'Arkansas'), (3, 'California'), (4, 'Florida'), 
(5, 'Maine'); -- and more . . .

create table counties (
  county_id integer not null,
  county varchar(100) not null,
  state_id integer not null, 
  foreign key (state_id) references states (state_id) 
    on update restrict on delete restrict,
  primary key (county_id, state_id),
  unique (county, state_id)
);

insert into counties values
(1, 'Autauga', 1), (2, 'Baldwin', 1), (3, 'Pike', 1), 
(4, 'Pike', 2), 
(5, 'Los Angeles', 3),
(6, 'Bay', 4), 
(7, 'Penobscot', 5); -- and more . . .


create table cities (
  city_id integer not null,
  city varchar(100) not null,
  county_id integer not null,
  state_id integer not null,
  foreign key (county_id, state_id) references counties (county_id, state_id)
    on update restrict on delete restrict,
  primary key (city_id, county_id, state_id),
  unique (city, county_id, state_id)
);

insert into cities values 
(1, 'Troy', 3, 1),
(2, 'Delight', 4, 2),
(3, 'Springfield', 7, 5),
(4, 'Springfield', 6, 4); -- and more . . .

所有这三个表仍然至少处于 5NF。但是这个 （无效）更新现在将成功。

update states
set state = 'Wibble'
where state = 'Alabama';

这是一件坏事。

使用代理 ID 号使每个外键引用 具有与声明它们 on update cascade 相同的行为。恢复 on update restrict 的部分语义，你必须取 撤销更新权限的额外、不直观的步骤 引用的表。

几乎没有人正确理解这部分。

---

没有任何现实原则可以证明拆分主键的合理性 为了有一条您可以遵循的路径来恢复原件 关系。换句话说，没有关系原则 有理由改变这个......

城市 city_id 城市 County_id state_id -- 1 特洛伊 3 2

...到这个。

城市 city_id 城市 County_id -- 1 特洛伊 3 县 County_id 县 state_id -- 3 派克 1

不仅没有关系原则证明分裂是正当的 主键，它创建关系模型的问题之一 打算解决的数据。查找“IMS”，一个分层数据库 要求用户遵循路径的管理系统 数据文件。

Answer 3

只是为了澄清另一个答案并消除冗余，这可能会通过相应的查询/连接来澄清。我正在重命名列以确保澄清上下文，但可能缺少“区域”字段的上下文

tblProvince:     ( ID, ProvinceName, Area )
TblDivision:     ( ID, DivisionName, ProvinceID )
tblDistrict:     ( ID, DistrictName, DivisionID )
tblCity:         ( ID, CityName, DistrictID )
TblConstituency: ( ID, ConstituencyName, CityID )

select
      Con.ConstituencyName, 
      City.CityName,
      Dis.DistrictName,
      Div.DivisionName,
      Prov.ProvinceName,
      Prov.Area
   from
      tblConstituency Con
         JOIN tblCity City
            on Con.CityID = City.ID
            JOIN tblDistrict Dis
               on City.DistrictID = Dis.ID
               JOIN tblDivision Div
                  on Dis.DivisionID = Div.ID
                  JOIN tblProvince Prov
                     on Div.ProvinceID = Prov.ID

并注意从一个表到下一个表的 JOINS 层次表示。您会看到表的直接关联。如果您正在寻找有问题的特定区域，则只需应用 WHERE 子句。