数据库规范化——这个例子是否违反了 1NF？答案

【问题标题】：Database normalization -- does this example violate 1NF?数据库规范化——这个例子是否违反了 1NF？
【发布时间】：2012-01-25 10:16:16
【问题描述】：

我正在使用 Access 2010。我正在为一个公共艺术项目开发一个数据库——我们在墙上绘制大型壁画。该数据库跟踪城市中的空白墙壁作为壁画的潜在地点。它包括有关建筑物本身和周围财产的信息，例如墙壁所面对的地段。

我的主要问题是关于 WallsMaster 表。如您所见，大约有 30 个字段……我正在考虑添加大约 10-15 个字段，从而产生 45 个字段，甚至更多。就数据库性能而言，将它们分成多个表还是将它们全部放在一个表中更好？也就是说，我是否应该拆分 WallsMaster 并在此表中创建另一个涵盖我的一般类别的表……。可能称为Damage，一种称为Obstruction，一种称为FacesLot 等……然后在它们和WallsMaster 之间建立FK 关系？

我正在考虑规范化规则……只是不确定这些是否符合 1NF 的相关/重复数据组。我的理解是，更多的是没有一个包含 AuthorName、Book1、Book2、Book3 等内容的表格。

这是我的数据库的粗略架构：

Table: WallsMaster
WallID (PK)
StreetAddress
City
State
Zip
BldgName
Occupied_or_Vacant
Faces_Direction (NSEW)
Residential_or_Commercial
Historical_Property (Yes/No)
Visible_to_traffic (Yes/No)
Faces_Parking (Yes/No)
Faces_Fenced_Lot (Yes/No)
Faces_Abandoned_Lot (Yes/No)
Faces_Garden (Yes/No)
Faces_ParkPlayground (Yes/No)
Faces_street (Yes/No)
Wall_Surface (Lookup: Brick, Stucco, etc)
Damage_Water (Yes/No)
Damage_Crumbling (Yes/No)
Damage_Graffiti (Yes/No)
Damage_Other (Yes/No)
Obstruction_Trees (Yes/No)
Obstruction_Powerlines (Yes/No)
Obstruction_Other (Yes/No)
Number_Stories
Height
Width
Image (Link)
GoogleStreetView (Link)
Notes (memo field)

Table: WallContacts
ContactID (PK)
WallID (FK)  many:many.  i.e., one wall can have many contacts (owner, manager, tenant) and one contact can be affiliated with many properties (i.e., one owner owns several walls)
FirstName
LastName
Address
City
State
Zip
ContactType (Lookup: Owner, Manager, Neighbor, etc.)
Phone
Email

Table: WallInteraction  (Catalogs each time our staff talks to someone affiliated with that wall or conducts an inspection of the property, etc)
InteractionID(PK)
WallID (FK)
StaffName
Date
InteractionStatus
Notes
(this may expand to include more fields as we work with this more)

谢谢！！

【问题讨论】：

标签： database database-design ms-access database-normalization

【解决方案1】：

我不会将 WallMaster 拆分为多个表，如果这些字段是您需要为墙建模的字段，则将它们包含在墙表中。

如果建筑物可以有多个墙壁，那么我会将地址等因素放入单独的 Building 表中，并以一对多的关系将其链接到 WallMaster（建筑物可以有许多墙壁，但墙壁只能属于一个建筑物） .
您可能需要考虑将 Notes 分解（在与 WallsMaster 的一对多中），因为这将使您能够输入多个便笺并保留历史记录，而不是可能覆盖现有便笺。
考虑在 WallInteraction 上使用 StaffID 外键而不是 StaffName。
另外，我个人会将“WallMaster”重命名为“Wall”。

【讨论】：