Yad*_*ada 35 sql database terminology database-normalization
我理解数据库规范化的概念,但总是很难用简单的英语解释它 - 特别是对于求职面试.我已阅读维基百科帖子,但仍然觉得很难向非开发人员解释这个概念."以不会获得重复数据的方式设计数据库"是首先想到的.
有没有人用简单的英语解释数据库规范化的概念？有什么好的例子可以显示第一,第二和第三范式之间的差异？
假设你去面试并且这个人问: 解释规范化的概念以及如何设计规范化的数据库.
面试官在寻找什么关键点？
Far*_*ruz 24
好吧,如果我不得不向我的妻子解释它,那就是这样的:
主要思想是避免重复大数据.
我们来看看他们来自的人员和国家名单.我们只是拿着一个引用国家表格的数字,而不是像每个人那样持有"波斯尼亚和黑塞哥维那"这个国家的名字.所以我们不是拿着100"波斯尼亚和黑塞哥维那",而是拿着100#45.现在将来,巴尔干国家经常发生这种情况,它们分裂为两个国家:波斯尼亚和黑塞哥维那,我将不得不在一个地方改变它.好吧,有点儿.
现在,为了解释2NF,我会改变这个例子,让我们假设我们保留每个人访问过的国家列表.而不是像这样的表:
Person CountryVisited AnotherInformation D.O.B.
Faruz USA Blah Blah 1/1/2000
Faruz Canada Blah Blah 1/1/2000
我本来会创建三个表,一个表包含国家列表,一个表包含人员列表,另一个表用于连接它们.这给了我最大的自由,我可以获得改变人的信息或国家信息.这使我能够按照规范化期望"删除重复的行".
Jac*_*esB 16
一对多关系应表示为由外键连接的两个单独的表.如果您尝试将逻辑一对多关系推送到单个表中,那么您违反了规范化,这会导致危险的问题.
假设您有一个朋友和他们的猫的数据库.由于一个人可能有一只以上的猫,我们在人与猫之间有一对多的关系.这需要两个表:
Friends
Id | Name | Address
-------------------------
1 | John | The Road 1
2 | Bob | The Belltower
Cats
Id | Name | OwnerId
---------------------
1 | Kitty | 1
2 | Edgar | 2
3 | Howard | 2
(Cats.OwnerId是外键Friends.Id)
上述设计完全标准化,符合所有已知的标准化水平.
但是说我试图在一个表中代表上述信息,如下所示:
Friends and cats
Id | Name | Address | CatName
-----------------------------------
1 | John | The Road 1 | Kitty
2 | Bob | The Belltower | Edgar
3 | Bob | The Belltower | Howard
(如果我习惯使用Excel工作表而不是关系数据库,这可能是我设计的那种设计.)如果我希望数据保持一致,单表方法会强制我重复一些信息.这种设计的问题在于,一些事实,例如Bob的地址为"钟楼"的信息被重复两次,这是多余的,并且使查询和更改数据以及(最差)可能引入逻辑不一致变得困难.
例如.如果鲍勃移动我必须确保我更改两行中的地址.如果Bob得到另一只猫,我必须确保重复名称和地址,就像在其他两行中输入一样.例如,如果我在其中一行中的Bob的地址中输入拼写错误,则数据库突然显示有关Bob所处位置的不一致信息.非规范化数据库不能防止引入不一致和自相矛盾的数据,因此数据库不可靠.这显然是不可接受的.
规范化不能阻止您输入错误的数据.规范化防止的是数据不一致的可能性.
值得注意的是,规范化取决于业务决策.如果您有一个客户数据库,并且您决定只为每个客户记录一个地址,那么表格设计(#CustomerID, CustomerName, CustomerAddress)就可以了.但是,如果您决定允许每个客户注册多个地址,则相同的表设计不会标准化,因为您现在在客户和地址之间存在一对多的关系.因此,您不能只查看数据库以确定它是否已规范化,您必须了解数据库背后的业务模型.
这不是一个彻底的解释,但正常化的一个目标是允许增长而不是尴尬.
例如,如果您有一个user表,并且每个用户将只有一个电话号码,那么phonenumber在该表中有一列可以.
但是,如果每个用户都将有一个可变数目的电话号码,那会很尴尬有样柱phonenumber1,phonenumber2等,这是出于两个原因:
phonenumber3并且有人需要添加第四个数字,则必须向表中添加一列.相反,您需要一个phonenumber表,其中每一行包含一个电话号码和一个外键引用,该引用user属于它所属的表中的哪一行.不需要空白列,每个用户可以根据需要拥有少量或多个电话号码.
一边一点需要注意规范化:一个完全规范化的数据库是空间高效的,但不一定是最时间视使用模式数据的有效安排.
跳过多个表以从非规范化位置查找所有信息需要时间.在高负载情况下(每秒数百万行,数千个并发客户端,比如信用卡事务处理),时间比存储空间更有价值,适当的非规范化表可以提供比完全规范化表更好的响应时间.
有关这方面的更多信息,请查找Ken Henderson编写的SQL书籍.
我会说规范化就像保持笔记有效地做事情,可以这么说:
如果你有一张说明你必须购买冰淇淋而没有标准化的便条,你会有另一张便条,说你必须去购买冰淇淋,每个口袋里只有一个.
现在,在现实生活中,你永远不会这样做,为什么要在数据库中呢？
对于设计和实现部分,那就是当你可以回到"语言"并远离外行术语时,但我认为你可以简化.你会先说出你需要的东西,然后当归一化时,你会说你会确定以下内容:
我认为如果你谈论非规范化,并且你不能总是拥有最好的结构并且处于正常形式这一事实,那可能会更令人印象深刻.
小智 5
规范化是一组用于设计通过关系连接的表的规则.
它有助于避免重复输入,减少所需的存储空间,从而无需重新构建现有表以适应新数据,从而提高查询速度.
第一范式:数据应以最小单位分解.表不应包含重复的列组.每行用一个或多个主键标识.例如,"自定义"表中有一个名为"名称"的列,它应该分为"名字"和"姓氏".此外,"自定义"应该有一个名为"CustiomID"的列来标识特定的自定义.
第二范式:每个非关键列应与整个主键直接相关.例如,如果"自定义"表格中有一个名为"城市"的列,则该城市应该有一个单独的表格,其中定义了主键和城市名称,在"自定义"表格中,将"城市"列替换为"城市ID",让'CityID'成为故事中的外键.
第三范式:每个非键列不应该依赖于其他非键列.例如,在订单表中,"总计"列取决于"单价"和"数量",因此应删除"总计"列.