1. 项目概述为什么我们需要分解关系模式在数据库设计的漫长旅途中我们常常会遇到一张“臃肿不堪”的表。这张表可能包含了来自不同业务实体的所有属性字段众多关系复杂。直接使用它不仅查询效率低下更会带来数据冗余、更新异常插入异常、删除异常、修改异常等一系列让人头疼的问题。想象一下你管理着一个员工信息表里面同时存着员工基本信息、部门信息和项目信息。每当一个部门地址变更你需要更新这个部门所有员工的记录当一个员工还没有参与项目时你甚至无法录入他的基本信息——这就是典型的“大表”困境。“数据库关系模式分解”正是为了解决这个困境而生的核心手术。它的目标很明确将一个不符合更高级范式如第一范式1NF之后的关系模式通过投影运算拆分成多个更小、更规范的关系模式集合。但手术不是乱切的我们必须确保两个至关重要的术后生命体征第一无损连接性意味着分解后的表通过自然连接能毫无损失地还原回原来的表不能多也不能少第二保持函数依赖性意味着原表中存在的所有数据约束函数依赖在分解后的各个小表中依然得以保持数据的完整性和一致性不能丢。这不仅仅是理论上的优美更是实践中确保数据库系统稳健、高效、易维护的基石。无论是设计一个新的业务系统还是优化一个历史遗留的庞杂数据库掌握关系模式分解的准则与方法都是数据库工程师和系统架构师必须精通的看家本领。接下来我们就深入拆解这场“外科手术”的每一个关键步骤。2. 核心概念与前置知识拆解在动刀之前我们必须彻底理解手中的“手术刀”和“人体解剖图”。关系模式分解建立在关系数据库理论的坚实基础上几个核心概念必须厘清。2.1 什么是函数依赖函数依赖是关系中属性间的一种约束是现实世界数据语义的体现。它的定义是在关系模式R(U)中X和Y是属性集U的子集。如果对于R的任意一个可能的关系rr中不可能存在两个元组在X上的属性值相等而在Y上的属性值不等则称X函数确定Y或Y函数依赖于X记作 X → Y。通俗地说就是知道了X的值就能唯一确定Y的值。例如在关系模式员工(工号姓名部门号部门名称)中工号 → 姓名成立因为一个工号唯一对应一个员工姓名。部门号 → 部门名称也成立因为一个部门号唯一对应一个部门名称。但姓名 → 部门号很可能不成立因为可能有重名的员工在不同部门。函数依赖分为多种类型完全函数依赖如果X→Y并且对于X的任何真子集X‘X’→Y都不成立。例如(学号课程号)→成绩单独学号或课程号都不能决定成绩。部分函数依赖如果X→Y但Y不完全依赖于X即存在X的真子集X‘使得X’→Y成立。这通常是产生数据冗余的主要原因。例如在(学号姓名课程号成绩)中(学号课程号)→姓名就是一个部分依赖因为学号→姓名单独成立。传递函数依赖如果X→YY→Z且Y不函数依赖于XZ不是Y的子集则称Z传递依赖于X。例如工号→部门号部门号→部门经理则工号→部门经理是传递依赖。理解这些依赖类型是判断一个关系模式好坏属于第几范式和如何进行有效分解的关键。2.2 范式的阶梯从1NF到BCNF范式是衡量关系模式规范化程度的准则。如同打怪升级我们需要一步步来。第一范式所有属性都是不可再分的原子项。这是关系数据库的基本要求。第二范式在满足1NF的基础上消除非主属性对候选键的“部分函数依赖”。第三范式在满足2NF的基础上消除非主属性对候选键的“传递函数依赖”。BC范式在满足3NF的基础上消除主属性对候选键的“部分与传递函数依赖”。BCNF的定义更严格关系模式R中如果每一个决定因素都包含候选键则R属于BCNF。我们的分解手术目标通常就是将一个低范式如仅满足1NF或2NF的关系模式通过无损且保持依赖的分解提升到3NF或BCNF。2.3 无损连接与保持依赖分解的黄金法则这是本次讨论的绝对核心两个目标有时可以兼得有时却需要权衡。无损连接分解设关系模式R分解为ρ{R1 R2 ... Rk}如果对R的任何一个关系r都有 r Π_R1(r) ⋈ Π_R2(r) ⋈ ... ⋈ Π_Rk(r)其中⋈是自然连接则称分解ρ具有无损连接性。简单说拆开再拼回去数据不多不少和原来一模一样。检验无损连接性的通用方法是Chase算法或针对二元分解的简易判定定理。保持函数依赖分解设关系模式R上的函数依赖集为F分解ρ{R1 R2 ... Rk}如果F在每一个Ri上的投影的并集逻辑蕴含F中的所有函数依赖则称分解ρ保持函数依赖。简单说原来的所有数据约束规则在分解后的各个小表里依然有效不需要跨表连接来验证约束。注意一个常见的误解是保持依赖意味着F中的每个依赖都必须完整地出现在某个Ri中。实际上只要F中的依赖可以被分解后各子模式上的依赖集所逻辑蕴含即可。例如F中有A→B和B→C分解后R1中有A→BR2中有B→C这依然是保持依赖的因为通过传递律可以推导出A→C。3. 分解的算法与实战推演理论铺垫完毕现在进入实战环节。我们将通过一个经典案例手把手演示两种最重要的分解算法分解为3NF且保持依赖和无损的算法以及分解为BCNF且保持无损的算法。3.1 案例设定一个“问题”关系模式假设我们有一个关系模式 R(U, F)其中属性集 U {A, B, C, D, E, G}函数依赖集 F {AB → C, C → A, BC → D, ACD → B, D → EG, BE → C, CG → BD, CE → AG}我们的任务是分析这个模式并将其规范化。第一步求候选键这是分解的起点。我们需要找出能唯一标识整个元组的属性组合。找出只在函数依赖左边出现的属性B。找出既在左边出现又在右边出现的属性A C D E G。计算(B)的闭包从B出发根据F推导。初始{B}根据BE→C但E还未在闭包中暂时无法用。先看其他。似乎没有直接以B为左边或包含B的依赖。我们尝试组合。实际上通过观察BE是一个可能的超键因为BE→C然后C→A得到A再结合AB→C已有ACD→B已有ACBD→EG得到DEG。因此(BE) {A B C D E G} U。故BE是候选键。检查是否有更小的检查B(B)可能不含E不行。检查E(E)可能不含B不行。检查CE(CE)CE→AG得到AGC→A已有现在有ACEGAB→C有ABB不在ACD→B有ACDD不在BE→C有BEB不在CG→BD有CG得到BD。关键推导从CE→AG得到AG结合C→A已有现在我们有CEAG。利用CG→BD因为C和G都在闭包里所以可以得到B和D。因此(CE) {A B C D E G} U。所以CE也是候选键。因此候选键是{BE CE}。第二步判断R最高属于第几范式检查非主属性主属性是{B E C}所有候选键的并集。非主属性是{A D G}。检查部分依赖对于候选键BE非主属性A、D、G是否部分依赖于BE例如A是否依赖于B或E单独从F看没有B→A或E→A。但存在C→A而C是主属性这不是非主属性对候选键的部分依赖。需要检查更复杂的例如由于CE也是键且C→A这意味着非主属性A传递依赖于候选键BE吗因为BE→C通过BE→C和C→A且C不依赖于BE等等BE→C是直接依赖所以A对BE是传递依赖BE→C C→A且C不依赖于BE这里C确实不函数依赖于BE因为BE是候选键C是非主属性错了C是主属性。所以A对BE的依赖是BE→C主属性C→A非主属性依赖于主属性。这属于非主属性A传递依赖于候选键BE。这违反了3NF的定义3NF要求非主属性不能传递依赖于候选键。因此R不属于3NF。结论R最高属于2NF因为看起来没有非主属性对候选键的部分依赖但存在传递依赖。3.2 算法一分解为3NF保持依赖且具有无损连接性这个算法是标准化的可以保证结果既保持函数依赖又具有无损连接性。算法步骤求F的最小覆盖Fc。这一步是为了简化依赖消除冗余。右部属性单一化F已是。去掉多余的函数依赖检查AB→C计算G F - {AB→C}下(AB)。在G中(AB)AB本身无其他依赖左部为AB子集所以(AB){AB}不包含C。故AB→C不多余。检查C→A计算去掉后(C)。在G‘F-{C→A}中(C)C本身根据BC→D左部BC不全ACD→B不全CG→BD需要GCE→AG需要E。似乎没有直接推导。实际上从C本身在没有C→A的情况下得不到A。所以C→A不多余。类似地检查其他依赖过程略假设我们经过计算得到最小覆盖Fc与F相同或简化为演示我们暂用原F但实际中BC→D可能冗余因为D→EG但BC→D左部不含D...这是一个复杂计算过程。我们假设一个简化后的Fc用于示例比如Fc {AB→C C→A BC→D D→E D→G BE→C CG→B CG→D CE→A CE→G}。注意这里我们把原依赖拆解并去掉了冗余如ACD→B可能由其他推导出。 为了清晰我们采用一个经典教材常用的简化案例来演示算法因为原F计算最小覆盖过程过于冗长。设 R(U F) U{A B C D} F{A→B B→C B→D C→A}。 候选键A C。 最小覆盖Fc经过计算可为{A→B B→C B→D C→A}无冗余。将Fc中所有函数依赖按左部相同者分组每一组形成一个子关系模式Ri。Fc分组{A→B} {B→C B→D} {C→A}。得到子模式R1(A B) R2(B C D) R3(C A)。检查候选键。计算候选键为{A C}。如果这些子模式中没有一个包含候选键则单独添加一个由候选键构成的子模式Rk。检查R1包含属性ABR2包含BCDR3包含CA。属性A和C分别出现在R1和R3中但单独的A或C不是候选键候选键是单个属性A和C在我们这个简化例子中是的A和C都是候选键。实际上R1包含A候选键R3包含C候选键。所以已经包含了所有候选键属性。去除冗余关系模式。如果一个子模式Ri的属性集完全包含在另一个子模式Rj中则去掉Ri。检查R1(AB) R2(BCD) R3(CA)。没有包含关系。最终分解结果ρ {R1(A B) R2(B C D) R3(C A)}。验证保持依赖Fc中的每个依赖都落在了某个Ri上A→B在R1 B→C和B→D在R2 C→A在R3。完美保持。无损连接可以通过Chase算法验证。构造初始表行为分解模式列为所有属性A B C D R1 a1 a2 b13 b14 R2 b21 a2 a3 a4 R3 a1 b32 a3 b34根据A→B在R1修改R2的B列为a2因为R1中Aa1时Ba2而R2中Ab21不等于a1不修改Chase算法是看依赖是否适用于某行并尽量使符号相等。更系统的方法是根据B→CR2中Ba2Ca3R1中Ba2Cb13将b13改为a3。根据C→AR2和R3中C都是a3A应相等R2中Ab21R3中Aa1将b21改为a1。此时R2行变为(a1 a2 a3 a4)。现在第一行(R1)和第三行(R3)在A上都是a1根据A→B它们B列都是a2没问题。检查是否有一行全为aR2行已全为a。因此分解是无损的。实操心得求最小覆盖是此算法中最繁琐但至关重要的一步。冗余的依赖会导致分解出多余的表增加系统复杂度。在实际工程中对于复杂的依赖集可以借助工具或编写脚本计算属性闭包来辅助判断。一个技巧是优先检查那些右部属性多的依赖拆分它们右部单一化后再进行判断往往更容易发现冗余。3.3 算法二分解为BCNF保持无损连接但不一定保持依赖BCNF的要求比3NF更严格。分解为BCNF的算法不能保证保持函数依赖但可以保证无损连接。算法描述递归分解法输入关系模式R 函数依赖集F。 输出R的一个无损连接分解ρ其中每个子模式属于BCNF。 方法初始化ρ {R}。检查ρ中所有子模式是否都属于BCNF。若是算法结束。若存在一个子模式S∈ρ不属于BCNF即在S上存在一个非平凡函数依赖X→Y且X不是S的超键则 a. 在S上计算X关于F在S上的投影的闭包。 b. 将S分解为两个子模式S1 X ∩ Attr(S) S2 (Attr(S) - (X - X))。简单说S1包含X和所有被X函数确定的属性S2包含X和那些不被X函数确定的属性。 c. 用S1和S2替换ρ中的S即ρ (ρ - {S}) ∪ {S1 S2}。 d. 回到步骤2。用之前的简化案例演示R(A B C D) F{A→B B→C B→D C→A}。候选键A C。初始ρ {R(A B C D)}。检查R是否属于BCNF。找出一个违反BCNF的依赖B→C。B→C是非平凡依赖但B不是R的超键B的闭包B {B C D A}实际上B包含所有属性所以B是超键等等计算一下B→C B→D 然后C→A所以B {B C D A} U。所以B是超键那B→C并不违反BCNF。再找A→BA是超键吗A{A B C D}U是超键。C→AC是超键吗C{C A B D}U是超键。B→DB是超键。在这个F下R竟然属于BCNF因为每一个函数依赖的左部A B C都是超键。这提醒我们同一个关系模式在不同函数依赖集下可能属于不同范式。我们原F的推导显示有传递依赖违反3NF但经过最小覆盖简化后在新的Fc下可能直接满足BCNF。为了演示BCNF分解我们换一个更典型的违反BCNF的例子 设R(学生 课程 教师) 语义每位教师只教一门课每门课有多位教师学生选课后对应一位教师。 函数依赖F { (课程教师) → 学生 教师 → 课程 }。 候选键(学生课程) 和 (学生教师)。因为(学生课程)学生课程根据教师→课程需要教师但教师未知。实际上(学生教师)学生教师根据教师→课程得到课程所以全有。故候选键是(学生教师)和(学生课程)。检查BCNF依赖教师→课程左部“教师”不是超键教师不能决定学生所以违反BCNF。开始分解ρ {R(学生 课程 教师)}。找到违反BCNF的依赖教师→课程。计算教师关于F的闭包{教师 课程}。分解S1 教师∩ Attr(R) {教师 课程}S2 (Attr(R) - (教师-教师)) {学生 课程 教师} - {课程} {学生 教师} 不对正确公式是 S2 X ∪ (Attr(S) - X) 即 {教师} ∪ ({学生课程教师} - {教师课程}) {教师} ∪ {学生} {学生 教师}。但S2(学生教师)包含了函数依赖教师→课程的决定因素“教师”却未包含“课程”这会导致该依赖丢失。这正是BCNF分解可能不保持依赖的体现。用S1和S2替换Rρ {R1(教师 课程) R2(学生 教师)}。检查ρ中每个子模式R1(教师 课程)函数依赖是教师→课程。左部“教师”是R1的超键吗在R1中教师{教师课程}U(R1)所以是超键。因此R1属于BCNF。R2(学生 教师)在R2上函数依赖集是什么从原F投影教师→课程不适用因为课程不在R2中。(课程教师)→学生也不适用。可能存在(学生教师)→学生平凡。没有非平凡依赖。所以R2只有平凡依赖属于BCNF。分解完成。ρ {R1(教师 课程) R2(学生 教师)}。验证无损连接可以通过连接验证。R1 ⋈ R2基于教师连接得到(学生教师课程)与原R一致。保持依赖原依赖(课程教师)→学生被丢失了吗在分解后的模式中R1有(教师课程)R2有(学生教师)。要验证(课程教师)→学生需要将R1和R2连接起来才能判断这违反了保持依赖的定义依赖应能在单个子模式上验证。因此这个分解不保持函数依赖。注意事项BCNF分解是一个递归过程不同的违反依赖选择顺序可能导致不同的分解结果但都保证无损。在实际数据库中如果强函数依赖业务规则无法在单个表中保持就需要在应用层通过事务来维护这会增加编程复杂性。因此有时为了保持依赖我们会妥协只分解到3NF。4. 实战中的决策、陷阱与优化理论算法给出了路径但真实世界的数据库设计充满了权衡和陷阱。4.1 无损连接的检验Chase算法详解当分解模式多于两个时判定无损连接最可靠的方法是Chase算法追赶算法。我们通过一个例子来具体操作。假设R(A B C D E) 分解为ρ{R1(AD) R2(AB) R3(BE) R4(CDE) R5(AE)}。函数依赖集F{A→C B→C C→D DE→C CE→A}。Chase算法步骤构造初始表格T每一行对应一个子模式Ri每一列对应一个属性Aj。如果Aj在Ri中则T[i][j]填上小写字母a加上下标j如a1 a2...否则填上小写字母biji是行号j是列号。A B C D E R1 a1 b12 b13 a4 b15 R2 a1 a2 b23 b24 b25 R3 b31 a2 b33 b34 a5 R4 b41 b42 a3 a4 a5 R5 a1 b52 b53 b54 a5反复应用F中的每一个函数依赖X→Y修改表格直到表格不再变化或有一行全为a。应用A→C寻找在A列上值相等的行。R1、R2、R5的A列都是a1。检查它们的C列R1是b13R2是b23R5是b53。将这些符号统一为最小的那个比如b13。假设统一为b13。则修改R2的C列为b13R5的C列为b13。应用B→C寻找B列相等的行。R2和R3的B列都是a2。它们的C列R2现在是b13R3是b33。统一为b13更小修改R3的C列为b13。应用C→D寻找C列相等的行。现在R1、R2、R3、R5的C列都是b13。检查它们的D列R1是a4R2是b24R3是b34R5是b54。将这些D列统一为a4因为存在a4。修改R2、R3、R5的D列为a4。应用DE→C寻找D列和E列都相等的行。R1(Da4 Eb15) R2(Da4 Eb25) R3(Da4 Ea5) R4(Da4 Ea5) R5(Da4 Ea5)。其中R3、R4、R5在(DE)上相等都是a4a5。检查它们的C列R3是b13R4是a3R5是b13。统一为a3因为存在a3。修改R3和R5的C列为a3。应用CE→A寻找C列和E列都相等的行。修改后R3(Ca3 Ea5) R4(Ca3 Ea5) R5(Ca3 Ea5)。检查它们的A列R3是b31R4是b41R5是a1。统一为a1。修改R3和R4的A列为a1。检查现在表格变为A B C D E R1 a1 b12 b13 a4 b15 R2 a1 a2 b13 a4 b25 R3 a1 a2 a3 a4 a5 - 这一行全为a R4 a1 b42 a3 a4 a5 R5 a1 b52 a3 a4 a5R3行已全为a。算法终止判定分解ρ具有无损连接性。实操心得Chase算法在依赖多、模式多时手工计算极易出错。在工程实践中对于重要的分解我会编写一个简单的脚本或利用数据库设计工具来验证。一个常见的陷阱是在统一符号时要优先使用已有的“a”类符号这能加速全a行的出现。4.2 保持依赖的检验与补救检验分解ρ是否保持依赖本质是检验FF的闭包中的每一个依赖是否可以被G ∪ π_Ri(F) 所逻辑蕴含。一个实用的方法是对于F中的每一个依赖X→Y计算X关于G的闭包记作(X)G。检查Y是否包含在(X)G中。如果是则X→Y被保持。如果F中所有依赖都通过测试则分解保持依赖。如果发现分解不保持依赖特别是对于BCNF分解我们需要评估丢失的依赖的重要性。如果丢失的依赖是关键的业务规则如外键约束、重要的一致性规则我们有几种选择接受不保持依赖在应用层维护通过应用程序代码在插入、更新操作时进行额外的检查或者使用数据库触发器来模拟该约束。这会增加开发复杂度和运行时开销。退而求其次采用3NF分解3NF分解算法能保证保持依赖。虽然理论上3NF可能还存在一些数据冗余但在绝大多数实际应用中3NF和BCNF在性能和冗余控制上的差异微乎其微而保持依赖带来的维护简便性优势巨大。重新审视函数依赖集有时不保持依赖是因为最初总结的函数依赖集不准确或不完整。与业务专家再次确认可能会发现丢失的依赖可以通过其他已保持的依赖推导出来或者该依赖本身就不是一个强约束。4.3 性能与规范的权衡不要为了范式而范式规范化理论为我们提供了消除冗余和异常的理想蓝图但在物理数据库设计中有时需要反规范化。反规范化的常见场景频繁的复杂连接查询如果多个高度规范化的表需要频繁地进行多表连接才能完成一个核心业务查询连接操作可能成为性能瓶颈。此时可以考虑将有紧密关联的表适度合并引入部分冗余用空间换时间。历史快照或报表需求对于需要保持历史状态的数据如订单完成后商品价格不应随主表更新而改变通常会将相关数据冗余存储在业务表中而不是通过连接去查询时刻在变化的维度表。极简的读优化场景在一些对读取速度要求极高、写入很少的场景如某些监控指标看板甚至可能使用完全扁平化的宽表。决策流程建议首先基于范式理论进行逻辑设计得到一个规范的、无损且尽可能保持依赖的3NF或BCNF设计。这是你的“理想模型”。进行性能预估与测试针对核心业务查询路径分析连接次数、数据量。有选择地、谨慎地反规范化仅针对已证实的性能瓶颈点进行反规范化。记录下反规范化的原因和引入的冗余依赖以便后续维护。使用物化视图在许多现代数据库系统中物化视图是平衡规范与性能的利器。它可以维护一个预连接、预聚合的冗余表并自动或定期刷新既保持了基表的规范性又提供了查询性能。记住数据库设计的终极目标不是追求理论上的完美范式而是在数据一致性、完整性、维护成本和查询性能之间取得最佳平衡。5. 常见问题排查与经验技巧实录即使理解了所有原理在实际操作中依然会踩坑。下面是我从多年实践中总结的一些典型问题和解决技巧。5.1 问题一分解后查询语句变得异常复杂且低效现象按照范式理论分解后原本简单的SELECT * FROM 大表变成了需要连接五六个表的复杂查询执行计划显示大量嵌套循环连接性能急剧下降。根因分析这是过度规范化或未考虑查询模式的典型结果。分解时只考虑了数据依赖没有考虑数据的访问路径。解决方案查询分析使用数据库的性能分析工具如EXPLAIN/EXPLAIN ANALYZEin PostgreSQL/MySQL找出消耗最大的连接操作。索引优化确保连接键通常是主键和外键上建立了有效的索引。这是成本最低的优化手段。引入反规范化如上一节所述对于性能瓶颈最严重的连接路径考虑将某些表合并。例如将频繁与主表连接的、记录数不多的代码表如部门表字段冗余到主表员工表中。使用物化视图创建一个包含连接结果的物化视图并设置合理的刷新策略如定时刷新或增量刷新。重新评估分解粒度有时将两个具有一对一关系或极其紧密依赖的表合并并不会引入显著的更新异常却能极大提升查询效率。5.2 问题二如何确定候选键属性闭包计算总出错现象在判断范式和进行分解时第一步求候选键就卡住了属性闭包计算混乱。排查技巧系统化方法不要凭感觉。遵循以下步骤 a.列出所有属性。 b.分类属性 - L类只出现在函数依赖左边的属性。 - R类只出现在函数依赖右边的属性。 - N类左右均未出现的属性极少。 - LR类左右都出现的属性。 c.求候选键 - 计算L类和N类属性的闭包。如果闭包等于全集U则它们就是候选键。 - 如果不等于则依次添加LR类属性计算其闭包直到等于U。所添加的最小属性集就是候选键。利用工具对于复杂的依赖集手动计算极易出错。可以使用在线的函数依赖闭包计算器或者自己写一段简单的程序如Python脚本来计算确保准确性。一个快速检查技巧候选键的闭包必须包含所有属性。如果一个属性集合的闭包不包含某个属性那它肯定不是超键。5.3 问题三BCNF分解后重要的业务规则函数依赖丢失了现象如前文“学生-课程-教师”例子BCNF分解导致(课程教师)→学生这个依赖无法在单个表中检查可能插入(学生1 教师甲)和(学生2 教师甲)而教师甲只教一门课这违反了“一位教师教一门课”的语义但数据库无法阻止。解决方案首选3NF如果该业务规则至关重要优先采用“分解为3NF且保持依赖和无损”的算法。3NF允许“主属性对候选键的传递依赖”存在但能保证所有依赖都被保持。在绝大多数情况下3NF的冗余是可接受的。应用层约束如果必须使用BCNF分解则必须在应用程序的业务逻辑中在执行插入或更新操作前显式执行一个检查例如在插入R2(学生教师)前先去R1(教师课程)中检查该教师对应的课程然后确保(课程学生)组合不违反其他约束如果还有的话。或者使用数据库触发器来实现同样的检查。使用数据库断言部分高级数据库系统支持CREATE ASSERTION语句来定义跨表的约束但性能开销大且并非所有数据库都支持。5.4 问题四在已有系统中进行重构如何安全实施模式分解现象面对一个已经存在大量数据和应用程序的“大表”明知其设计不合理但不敢轻易改动。安全重构步骤备份与分析完整备份原表。彻底分析现有所有应用程序的SQL查询、存储过程、视图和触发器识别出所有对该表的访问。创建新结构在同一个数据库中按照规划好的分解方案如3NF创建新的、规范化的表结构。数据迁移与同步编写数据迁移脚本将原表数据拆分、转换并插入到新表中。关键点必须在一个事务中完成确保数据一致性。迁移后严格对比新旧数据总量及关键关联的正确性。创建兼容性视图创建一个与原表同名的视图该视图是新闻表的自然连接。这样那些未经修改的、只读的旧查询可以暂时继续工作。逐步迁移应用分批次修改应用程序代码将直接操作原表或视图的代码改为直接操作新的规范化表。每修改一个模块进行充分测试。监控与切换所有应用迁移完成后在低峰期移除兼容性视图彻底切换到新表结构。持续监控系统性能和错误日志。这个过程的核心是保证平滑过渡和快速回滚能力。每一步都要有回退方案。关系模式分解是数据库设计的精髓它要求我们在理论的严谨性与工程的实用性之间反复权衡。从我个人的经验来看没有放之四海而皆准的最优解。对于联机事务处理系统倾向于更高的规范化以减少更新异常对于联机分析处理或报表系统则允许更低的规范化以优化查询速度。最好的设计永远是那个最能贴合当前业务需求、团队维护能力和未来扩展预期的设计。理解无损连接和保持依赖这两个黄金法则能让你在做出任何设计决策时清楚地知道自己在 trade-off 什么从而做出更明智的选择。