备考软考系统架构设计师的人十有八九会在一开始低估数据库这块的复习量。我在准备这个考试时也是同样的感觉觉得知识点耳熟能详结果一刷真题选择题错误率惊人。尤其是第六章数据库设计基础知识它不像算法那样烧脑也不像架构风格那样抽象但它是一大堆细碎概念的集合——概念辨析、模型转换、范式判定、综合应用题哪一环没吃透考场就是丢分。这篇博客我结合自己的复习过程把这一章的重点拆开揉碎尽量说人话帮你把基础部分一次性夯实。这篇主要适合两类人一类是刚开始备考、需要按章梳理知识点的同学另一类是已经刷过几套题、发现在概念辨析和范式的题目上反复出错的人。对于前者这是一份能对着看的提纲对于后者这更像一份避坑备忘录。我先从章节定位和考查方式讲起再逐步深入到数据模型、E-R设计、规范化理论这些核心最后总结一些我踩过的坑和记忆技巧。这一篇先讲“上”的部分也就是基础概念、数据模型、E-R图和范式理论。1. 先弄明白这一章到底考什么1.1 数据库设计知识在软考架构中的权重与考查方式在系统架构设计师上午的客观题里数据库相关内容通常能占 6 到 10 分左右具体分布不一定但基本稳定。分布式数据库、NoSQL、数据仓库这些偏进阶的内容偶尔会单独出题而第六章提到的数据库设计基础知识则是所有数据库相关题目共同的“地基”。有些同学觉得这章简单因为内容里没有高难度的数学推导但它的坑恰恰藏在那些“貌似简单”的概念里。这一章的考查方式主要有三种一是概念辨析型选择题比如问“数据库系统与数据库管理系统的区别”“三级模式对应的概念不正确的是哪一项”二是原理计算型题目比如给一个关系模式让判断它达到第几范式或者判断某个函数依赖是否成立三是案例分析题中的数据库设计子问题比如根据需求画出E-R图再转换成关系模式并指出主键、外键。考试不会只靠背诵过线而是需要灵活运用。我自己在复习时最大的教训是不要以为自己做过表单、写过SQL就觉得数据库设计没问题。软考架构考的并不是单表增删改查而是从现实世界抽象出数据模型的能力再把这个模型一步步递进到可落地的关系模式。整个过程一环扣一环概念不牢后面案例分析会非常吃力。1.2 上篇的边界与复习主线既然标题是“基础知识上”就得先清晰地划个范围。我认为这一篇对应的核心内容是数据库基本概念、数据模型、数据库系统的体系结构、E-R模型及其向关系模型的转换、关系规范化理论函数依赖、范式与模式分解。至于事务管理、并发控制、数据库恢复、数据库安全这些内容属于数据库系统运行与维护层面的知识更适合放在“下篇”去展开。这样一章内容比较多拆成上下两篇复习压力也小一些。复习主线建议按照“现实世界→信息世界→机器世界”的抽象过程来走。这个过程不是教条而是数据库设计的基本思路先分析需求用概念模型典型就是E-R模型描述现实问题再把概念模型变成逻辑模型关系模式最后落在物理存储层。软考中大部分题目其实都在考这条链路上的某一个节点。抓住这条链路你会发现很多题目是“串起来”的而不是一个个孤立的知识点这会让后续的记忆负担小很多。另一个容易忽略的复习策略是以真题为导向。我复习时先把近五年的数据库相关真题全部摘出来按知识点分类发现最高频的考点依次是范式与函数依赖、三级模式结构、E-R 图与关系模式转换、数据模型的分类与特征。这个排序直接影响我后面分配精力的比例也建议你试试别抱着整本书从头到尾平均用力。2. 高频基础概念辨析四个名称绝不能混2.1 数据、数据库、数据库管理系统与数据库系统的区别这四个概念几乎每年都有题目在绕。我给你一个比较粗但好用的记忆框架数据是原料数据库是存数据的容器数据库管理系统DBMS是管理容器的工具数据库系统则是“工具容器数据人硬件”构成的整体系统。准确一点说数据是对现实世界事物特征的符号记录比如“张三28岁”就是一条数据数据库是长期存储在计算机内、有组织、可共享的数据集合它强调三个特点——长期存储、有组织、可共享DBMS是位于用户与操作系统之间的一层数据管理软件具有数据定义、数据操纵、数据库的运行管理、数据组织存储与管理、数据库的建立与维护六大功能数据库系统通常指引入了数据库技术后的整个计算机系统由数据库、DBMS、应用程序、数据库管理员和用户组成。真题喜欢这样考给出一个说法让你判断哪个概念对应哪个词。比如“数据库系统不仅是指数据库本身也不仅仅是指DBMS而是包括了硬件、软件、人员和数据在内的整体。”这种说法是正确的但很多同学看到“系统”两个字就往“数据库管理系统”上靠这就错了。关键词是“整体”和“环境”对应的一定是数据库系统。我在复习这个知识点时用了一个类比把数据库比作一个仓库DBMS是仓库的管理员和一整套出入库流程数据库系统则是“仓库管理员货物物流公司客户”的整个商业体系。这个类比不太严谨但对于选择题的快速辨析是够用的。2.2 三级模式结构与两级映射三级模式结构是数据库系统体系结构最核心的题目来源几乎每年选择题都会出场。所谓三级模式是指外模式子模式/用户模式、模式概念模式/逻辑模式、内模式存储模式。它们的层级关系是这样的模式是数据库的整体逻辑结构属于中间层描述所有实体、属性和联系外模式是用户可以看到和使用的局部逻辑结构一个数据库可以有多个外模式但通常只有一个模式内模式是数据在物理存储层面的结构描述比如用哪种文件组织方式、是否索引。这里的高频考点是各级模式与“视图/表/存储文件”之间的对应关系。外模式对应视图模式对应基本表内模式对应存储文件。需要注意的是索引是内模式的一部分但它既不属于模式也不属于外模式而属于内模式范畴的物理存储细节。有的题目会故意说“索引属于模式”这明显是错的。两级映射分别是外模式/模式映像和模式/内模式映像。前者保证了数据的逻辑独立性当模式改变时只要修改外模式/模式映像外模式就可以保持不变应用程序不受影响。后者保证了数据的物理独立性当内模式存储结构改变时只要修改模式/内模式映像模式就可以保持不变应用程序同样不受影响。我在做真题时发现一个高频陷阱题目会把“逻辑独立性”和“物理独立性”的定义互换让你判断哪个是哪个。关键在于抓住“谁变了、谁不变”。变的是概念模式时靠外模式/模式映像来隔离这是逻辑独立性变的是内模式时靠模式/内模式映像来隔离这是物理独立性。只需要抓住映像方向这个知识点就不会失分。3. 数据模型从现实世界到机器世界的桥梁3.1 三层次模型的区分数据模型在数据库设计里有两种理解角度一种是概念数据模型又称信息模型它面向用户、面向现实世界典型代表是E-R模型另一种是基本数据模型包括层次模型、网状模型、关系模型、面向对象模型等它是面向机器世界的逻辑模型。答题时如果题目问“用实体-联系方法描述现实世界的是哪种模型”要毫不犹豫选择概念模型如果问“数据库系统中真正用于数据组织和存储的模型”则选基本数据模型。基本数据模型里层次模型用树状结构表示实体及其联系有且仅有一个根结点且非根结点仅有一个父结点网状模型允许一个以上的结点无父结点也允许一个结点有多个父结点整个结构是一个有向图关系模型用二维表格表示实体和联系是目前主流模型面向对象模型则融合了对象、封装、继承等概念在非传统领域如工程设计中使用。软考在这部分经常考查各模型间的差异。一个经典问法“层次模型和网状模型最主要的不同是什么”本质区别就在于父结点数量的限制。层次模型结构清晰、查询效率高但难以表达多对多关系网状模型表达能力强、存取效率较高但结构复杂用户难以理解和使用关系模型结构简单、集合操作完备、数据独立性高是应用最广泛的模型。我推荐用一张小表来辅助记忆这样复习后期不需要翻阅笔记就能快速回忆模型核心结构父结点限制主要优点主要缺点层次模型树单父结点结构清晰、查询效率高难以表达多对多网状模型有向图允许多父结点表达能力更强结构复杂、使用困难关系模型二维表无结构简单、集合操作查询需连接有时性能较低3.2 E-R图三要素与联系类型E-R图是概念模型最常考的载体。三个核心要素是实体、属性、联系。实体是客观存在且可相互区别的事物在E-R图中用矩形表示属性是实体或联系所具有的某一特性用椭圆表示联系是实体之间的关联用菱形表示在联系上标注 1:1、1:n 或 m:n。考点很细节比如联系也可能有属性比如“学生选课”这个联系可以有“成绩”这个属性。这在转换为关系模式时非常关键。因为当联系具有属性时往往需要把联系转换成一个单独的关系模式而不是简单地把两方主键合并进某一方。另一种考查方式是判断实体、属性和联系能否相互转换。从概念上讲实体和属性之间没有绝对的界限随着需求不同可以调整。经典例子“职工”和“部门”若一个部门只有一个职工可以担任负责人通常“负责人”可作为职工的属性若有多个负责人则需要把“部门”提升为实体并与“职工”建立联系。真题有时会设置“稳定的属性判定”这类代换型选择题本质是考模型抽象能力这需要多做练习靠背是背不下来的。联系类型中1:1、1:n、m:n是三个基础形式。1:1常见如“班级与正班长”1:n如“部门与职工”m:n如“学生与课程”。其中1:1和1:n最容易在关系模式转换时被忽略的细节是转换时如何选择“一方”和“多方”。一般规则是“多方关系加外键”即把一方的关键字段加到多方的关系模式中对于1:1可以把任意一方的主键放入另一方作为外键而对于m:n必须单独生成一个关系模式主键通常是两端主键的联合。这个规则在案例分析题里几乎是必考动作。我的经验是做题时先用铅笔在题目旁边写出实体数量、联系类型和哪些联系带属性再动手画模式否则很容易漏掉某些实体导致主键外键判断全错。我见过很多同学的答案结构完整但就是少了“选课”这个联系模式白白丢掉好几分。3.3 E-R图向关系模式的转换规则E-R图转换成关系模式分两条路走实体变关系、联系变关系但具体要不要把联系单独变关系取决于联系的类型。1:1 联系可将联系合并到任意一端归入哪一方就在那一方加入另一方的主键作为外键也可以单独转换。1:n 联系将“1”方的主键并入“n”方作为外键同时把联系自身可能带有的属性并入不单独成立关系模式。m:n 联系单独转换为一个关系模式其主键为双方实体的主键组合联系属性则作为该关系模式的属性。在做转换题时要注意属性命名是否冲突两个关系模式中如果出现同名但含义不同的属性需要区分清楚否则外键会写错。另一个细节是组合主键的语义要清楚比如“学生选课”模式中的主键学号课程号但真正表示一次选课记录时这个组合主键不能为空这又引出了下一节要讲的实体完整性规则。我在复习时自己动手整理了一张转换速查表从实践中很管用也分享给你联系类型转换策略关系模式主键常见陷阱1:1并入任一方并入方原主键遗漏另一侧外键1:n并入多方多方原主键忘记把一方主键放入多方m:n单独生成两端主键组合忽略联系自身属性4. 关系规范化理论重难点里的重难点4.1 函数依赖的定义与类型函数依赖是范式判定的基础概念其实不复杂设X、Y是关系R的两个属性集合当任意两条记录在X上的取值相同在Y上的取值也必相同时称Y函数依赖于X记作X→Y读作“X决定Y”。生活化理解学号决定姓名因为一个学号必然对应一个姓名不会出现两个姓名。这里的“决定”更像是一种约束关系而不是程序里的因果关系。函数依赖分为非平凡函数依赖和平凡函数依赖。若X→Y且Y是X的子集称为平凡函数依赖比如学号课程号→学号就是平凡的因为它恒成立没有实际约束意义。通常讨论的都是非平凡依赖即Y不是X的子集。真题里偶尔会直接考“以下哪个属于非平凡函数依赖”这时只要看右侧属性是不是左侧属性的子集即可。完全函数依赖与部分函数依赖是第二范式的直接判据。若X→Y同时X的任何真子集都推不出Y则称Y完全函数依赖于X否则称Y部分函数依赖于X。比如在“选课”关系里成绩不仅取决于学号还取决于课程号单独学号或单独课程号都推不出成绩所以它是完全依赖而姓名由学号决定在学号课程号组合下姓名又是部分函数依赖。传递函数依赖则是第三范式的判据若X→YY→Z且Y不能决定X则称Z传递依赖于X。注意判定传递依赖的必要条件是Y不是X的子集且Y不能推出X否则可能出现伪传递导致对NF误判。我在复习时给自己编了一个自查步骤拿到一个关系模式先列出所有函数依赖再标注主键最后按依赖类型判断范式。这个过程建议写成纸面笔记不要只在脑子里想。因为软考案例分析题需要写出判断过程平时习惯用纸笔推导考场就不至于手生。4.2 范式的判定标准范式层次从低到高依次是1NF、2NF、3NF、BCNF。这个递进关系不是可逆的满足高级范式一定满足低级范式反之不一定。1NF的要求是属性不可再分即表的每个字段都是原子值不能是集合或数组。这个判断很简单但真题常拿它出“陷阱题”一个表中某个属性保存了多个电话号码这个表就不满足1NF。很多同学看到主键完好就误以为满足了更高范式其实是连第一范式都没有达到。2NF在1NF基础上要求消除非主属性对候选键的部分函数依赖。判断方法很直接先找到候选键再看是否存在某个非主属性只依赖候选键的真子集。如果存在就不满足2NF。比如关系模式R学号课程号姓名成绩候选键是学号课程号但姓名只依赖于学号属于部分依赖因此不满足2NF。这时要拆成R1学号姓名和R2学号课程号成绩。3NF在2NF基础上要求消除非主属性对候选键的传递函数依赖。判断方法是是否存在“候选键→非主属性XX→非主属性Y”的传递链。存在则不是3NF。经典例子是R学号系号系名学号→系号系号→系名系名属于非主属性且通过系号传递依赖学号所以只满足2NF不满足3NF需要分解为学号系号和系号系名。BCNF要求对于每一个非平凡函数依赖X→YX都包含候选键。换句话说所有决定因素必须是超键。这是比3NF更强的形式。真题中经常出现“满足3NF但不满足BCNF”的反例比如R学生课程教师假设教师→课程且学生课程→教师候选键之一是学生课程但依赖“教师→课程”的左侧教师并不包含候选键因此不满足BCNF。这个例子几乎年年有人问我建议直接记住这个结构考场上能省不少时间。为了方便对比我把各级范式用一个表格简化范式核心要求需要消除的问题典型判断句1NF属性不可再分非原子属性这个字段还能拆吗2NF非主属性完全函数依赖于候选键部分函数依赖只靠候选键的一部分能推出来吗3NF非主属性不传递依赖于候选键传递函数依赖能通过B推到C吗BCNF所有决定因素都包含候选键非超键决定属性X→Y里X是超键吗4.3 模式分解与无损连接模式分解只在范式判断不达目标时使用考点通常落在“无损连接”和“保持函数依赖”两个性质上。无损连接指分解后的关系通过自然连接能恢复到原关系不产生多余的元组保持函数依赖指分解后的各关系模式函数依赖的并集能够蕴含原模式的全部函数依赖。真题中常给出一个关系模式和函数依赖集合再给一个分解方案要求判断分解是否具有无损连接性和是否保持函数依赖。这种题型有固定的解法用判定表或者循环推导来验证无损连接性用依赖是否存在于某个分解后的关系模式中来验证保持依赖。我用做题经验提醒一句话两个性质并不是总能同时满足。3NF分解能够同时满足无损连接和保持函数依赖这属于定理可以直接用BCNF分解能保证无损连接但不一定能保持函数依赖。有的同学看到候选答案里“分解为BCNF且保持函数依赖”就认为是标准最优解实际上未必满足要看题目条件别被“高级范式”迷惑。如果实在推不明白无损连接判定算法可以换一个思路——简单情况下如果分解是两个关系模式R1和R2只要它们的交集是R1或R2的候选键那么这个二元分解就是无损连接。很多选择题只考二元分解这个简化规则能直接秒杀。以后碰到更复杂的多路分解再回到通用判定表也不迟。5. 实战考点“前车之鉴”与复习工具箱5.1 常见选择题陷阱实录我把平时刷题遇到的陷阱整理了一下这些坑比较典型考试也喜欢反复用第一概念类陷阱。题干说“数据库系统是数据库与数据库管理系统的合称”这个说法是错的因为少了硬件、人员和应用程序显得“系统”没那么系统。说“数据库管理系统是数据库系统的核心”才是对的。经常有一半的同学选错就是因为被“核心”两字吓住其实它就是核心。第二模式映射类陷阱。题干说“外模式/模式映像保证了物理独立性”错。物理独立性对应的是模式/内模式映像。两个映像的方向一旦与独立性的名称错位整道题就凉了。建议做题时先把“逻辑-外/模式”“物理-模式/内”写上。第三E-R转换类陷阱。题干说“1:n联系必须单独转换成一个关系模式”错。答案一般是并入多方。单独转换只对m:n联系和少数特殊情况必要。很多同学把m:n的规则推广到了所有联系这是最常见的失分原因。第四范式判断类陷阱。给出一个关系模式它没有主键或者主键设计不合理导致看似满足2NF实际1NF都有问题。判断顺序永远是从1NF往BCNF逐级走不要跳级。我见过有人直接说“这明显是3NF”结果连候选键都没找对。5.2 适合反复使用的复习技巧对于概念类题目我建议把每个知识点转成一个可以脱口而出的短句比如“外模式是视图模式是表内模式是存储文件”“逻辑独立看外映射物理独立看内映射”“m:n必须拆1:n并多方1:1随便放”。这些短句不是用来背诵的而是用来在考场上快速排除错误选项的。对于函数依赖和范式建议自己出几道题练手。把一张学生选课表、一张订单表分别写成关系模式手动列出函数依赖判断范式再写出满足3NF的分解方案整个过程控制在十分钟内。这种训练如果连续做七到十天范式题的正确率会有一个明显的提升因为判定过程会内化成一种习惯。对于E-R图一个有效的方法是看到生活中的业务场景就习惯性地画一画。比如“一个医生可以看多个病人一个病人可以找多个医生看病每次就诊产生一个病历”马上画出实体和联系类型思考关系模式怎么定哪些属性放哪张表。这种练习不用大量刷题重点是理解和熟练这套抽象思路。我复习时每天画两个这样的小场景坚持两周之后案例分析里的E-R题基本没有障碍了。最后再分享一个我个人的实操体会做数据库设计基础题目时我习惯在每个关系模式旁边先写清楚候选键再画一条依赖线把所有函数依赖都标在纸上。这样不管题目怎么变我都不会被冗长的属性列表带偏。很多考场上出错的题并非不会做而是因为处理信息太随意没有养成规范化的读题和推导习惯。考前如果想要一个高性价比的加强项不妨就从这里开始把每一个基础概念都练到闭着眼都能写对的程度。