软件工程中**数据库设计E-R模型和软件设计基础模块化、耦合/内聚、设计原则、质量模型**两大核心知识点以下是简明清晰的归纳与补充说明✅E-R 图三要素实体Entity现实世界中可区分的对象如“学生”“课程”用矩形表示。属性Attribute实体的特征如“学号”“课程名”用椭圆表示主键加下划线如_学号_。联系Relationship实体间的关联用菱形表示并标注基数比1:1如“人—身份证”、1:N如“系—学生”一个系有多个学生、M:N如“学生—课程”需引入关联实体“选课”。✅模块化设计核心指标耦合Coupling模块间依赖程度 →低耦合如通过接口通信避免直接修改内部变量→ 易维护、易测试。内聚Cohesion模块内功能相关性 →高内聚如一个模块只负责用户登录验证不处理日志或数据库连接→ 职责清晰、复用性强。→ ✅高内聚 低耦合 优质模块化设计的黄金准则✅五大面向对象设计原则SOLID开闭原则OCP对扩展开放对修改关闭如用策略模式新增算法而不改原有类里氏替换原则LSP子类可替换父类且不破坏程序逻辑禁止子类重写父类关键行为导致异常依赖倒置原则DIP依赖抽象接口/抽象类而非具体实现高层模块不应依赖低层模块细节接口隔离原则ISP客户端不应依赖它不需要的接口拆分臃肿接口如将IWorker拆为IEater和ISleeper单一职责原则SRP一个类/模块只承担一个职责如UserValidator只校验不存库✅ISO/IEC 25010 软件质量模型6大特性特性关键子特性示例功能性适合性、准确性、互操作性是否满足用户需求能否与微信API对接可靠性成熟性、容错性、可恢复性系统崩溃后能否自动回滚并恢复数据易用性易理解、易学习、易操作新用户3分钟内能否完成注册效率时间特性、资源利用率并发1000用户时响应2sCPU占用70%维护性可分析、可修改、稳定性修改登录逻辑是否只需改1个模块可移植性适应性、易安装、共存性能否从Windows平滑迁移到Linux容器这些概念共同构成现代软件系统可演进、可维护、可扩展的设计基石。在E-R图中M:N多对多联系不能直接映射为关系数据库中的外键约束因关系表无法用单个外键表达双向多值依赖必须**引入一个独立的关联关系模式也称“桥接表”或“连接表”**来实现转换。以下是标准转换步骤与关键完整性约束✅ 一、转换步骤以“学生”和“课程”之间的M:N联系“选课”为例E-R元素转换方式关系模式示例实体“学生”Student主键学号→ 成为关联表的外键选课(学号, 课程号, 成绩, 选课时间)实体“课程”Course主键课程号→ 成为关联表的外键—联系“选课”Enrollment升格为独立关系模式主键由两端实体主键联合构成即复合主键主键(学号, 课程号)联系的属性如“成绩”“选课时间”全部作为该关联表的属性保留成绩 DECIMAL(4,1),选课时间 DATE 注若M:N联系本身有标识性属性如“选课序号”或需唯一标识每条联系实例且业务要求其可为空/可重复则仍以(学号, 课程号)为主键若需额外唯一性如允许同一学生多次重修同一门课并区分记录可添加代理键如enroll_id并设UNIQUE(学号, 课程号, 重修次数)等约束。✅ 二、必须保证的完整性约束约束类型具体要求SQL 示例以MySQL/PostgreSQL实体完整性关联表的主键学号, 课程号非空且唯一PRIMARY KEY (学号, 课程号)参照完整性外键约束学号必须存在于学生表课程号必须存在于课程表FOREIGN KEY (学号) REFERENCES 学生(学号) ON DELETE CASCADE,FOREIGN KEY (课程号) REFERENCES 课程(课程号) ON DELETE RESTRICT业务语义约束常通过CHECK或应用层控制如“成绩在0–100之间”、“选课时间不晚于当前日期”CHECK (成绩 BETWEEN 0 AND 100),CHECK (选课时间 CURRENT_DATE)参与约束可选但重要若E-R图中标注了完全参与双线则对应外键字段不可为空NOT NULL已由主键隐含保证若为部分参与则外键本身已是NOT NULL因是主键成分无需额外处理——但逻辑上应确保业务不插入孤立联系。⚠️ 特别注意禁止将M:N简化为两个1:N如在学生表加“课程号列表”字段这违反第一范式1NF导致查询困难、更新异常删除策略需审慎ON DELETE CASCADE删学生则删其所有选课记录常见但删课程时若设CASCADE可能误删大量记录宜用RESTRICT或SET NULL此时外键需允许NULL——但主键字段不可NULL故不适用因此M:N关联表中外键通常不可设为NULL必须严格参照。✅ 总结口诀“M:N必建桥两端主键作联合主键外键连实体级联删慎选属性全搬入约束保正确。”