E-R图向关系模式的转换是数据库逻辑设计的关键步骤，目标是将概念模型（E-R图）无损、语义保真地映射为关系数据库中的表结构

E-R图向关系模式的转换是数据库逻辑设计的关键步骤目标是将概念模型E-R图无损、语义保真地映射为关系数据库中的表结构关系模式。以下是标准转换规则及对多值属性和弱实体的专门处理方法✅ 一、基本转换规则针对普通实体与联系E-R元素转换方式说明强实体有主键→ 单独一个关系模式实体名作关系名所有属性含主键作为属性主键属性标注下划线或标记PK。二元联系1:1、1:N、M:N——1:1联系可合并到任一端实体加对方主键作外键或单独建关系模式含两端主键1:N联系不单独建表将“1”端主键作为外键加入“N”端实体关系中M:N联系必须单独建关系模式包含两端实体的主键联合主键以及联系自身的属性。多元联系n元n≥3→ 单独关系模式模式包含所有参与实体的主键联合主键以及联系的属性各主键同时作为外键引用对应实体。⚠️ 二、特殊结构的处理1.多值属性Multi-valued Attribute如Employee的Phone可有多个号码非原子值→违反1NF不可直接作为列。✅正确做法新建一个独立关系模式以原实体主键 多值属性为组合主键。例如Employee(emp_id, name, ...)多值属性Phone→ 新表Employee_Phone(emp_id, phone_number)其中(emp_id, phone_number)为主键emp_id是外键。 本质将多值属性“扁平化”满足第一范式1NF要求。2.弱实体Weak Entity依赖于强实体存在无独立主键用双矩形表示联系为标识性联系Identifying Relationship带双线连接。✅正确做法弱实体不单独拥有主键其主键 强实体主键 自身部分码discriminator转换为关系模式时弱实体关系包含强实体主键作为外键 自身属性含部分码联合主键 强实体主键 部分码强实体主键在弱实体关系中必须作为外键引用强实体。 示例Order强–(has)→OrderItem弱依赖Order存在Order(order_id, ...)OrderItem(order_id, item_no, qty, ...)主键(order_id, item_no)外键order_id → Order(order_id)❗ 补充说明派生属性如Age由BirthDate计算不存入关系模式避免数据冗余与不一致复合属性如Address(street, city, zip)可展平为多个原子属性street,city,zip或保留为单属性若不参与查询/约束联系本身的属性如Works_In(since_date)必须放入对应联系所生成的关系模式中如M:N联系表或1:1独立表。-- 示例转换含弱实体与多值属性-- E-R片段Student(sid) ──(enrolls_in)── Course(cid) [M:N]-- Student(sid) ──(has)── Phone(phone) [多值]-- Order(oid) ──(contains)── OrderItem(oid,item_no) [弱实体]-- 转换后的关系模式CREATETABLEStudent(sidCHAR(10)PRIMARYKEY,nameVARCHAR(50));CREATETABLECourse(cidCHAR(8)PRIMARYKEY,titleVARCHAR(100));-- M:N 联系enrolls_inCREATETABLEEnrolls_In(sidCHAR(10)REFERENCESStudent(sid),cidCHAR(8)REFERENCESCourse(cid),gradeCHAR(2),PRIMARYKEY(sid,cid));-- 多值属性Phone → 独立表CREATETABLEStudent_Phone(sidCHAR(10)REFERENCESStudent(sid),phoneVARCHAR(20),PRIMARYKEY(sid,phone));-- 弱实体OrderItem依赖OrderCREATETABLEOrder(oidINTPRIMARYKEY,order_dateDATE);CREATETABLEOrderItem(oidINTREFERENCESOrder(oid),-- 外键也是主键一部分item_noINT,-- 部分码区分同一订单内不同项qtyINT,PRIMARYKEY(oid,item_no)-- 联合主键);E-R 模型用实体Entity、属性Attribute、联系Relationship三要素描述现实世界的信息结构E-R图是概念设计阶段的核心工具支持弱实体、多值属性、基数约束1:1/1:N/M:N等语义表达。关系代数形式化查询语言基础操作包括选择σ按条件筛选元组投影π提取指定属性列连接⋈尤其是θ连接、自然连接、外连接左/右/全其他并、差、笛卡尔积、重命名等所有SQL查询均可转化为关系代数表达式。SQL结构化查询语言。增INSERT、删DELETE、改UPDATE、查SELECT是DML核心视图VIEW是虚表提供逻辑数据独立性、安全性与查询简化不存储实际数据除非物化视图。范式理论用于消除数据冗余与更新异常。1NF属性原子不可分2NF1NF 消除非主属性对候选键的部分函数依赖3NF2NF 消除非主属性对候选键的传递依赖BCNF更严格要求所有函数依赖 X→Y 中 X 必为超键消除主属性对非超键的依赖。模式分解将一个关系模式分解为多个子模式。无损连接分解自然连接后能完全恢复原关系可通过Chase算法或矩阵法判定保持函数依赖分解所有原始FD在分解后的子模式中可逻辑蕴含未必总能同时满足无损保持FD。事务ACIDAAtomicity原子性——全做或全不做靠日志与回滚CConsistency一致性——事务前后数据库状态均满足完整性约束IIsolation隔离性——并发执行效果等价于某串行顺序靠并发控制机制保障DDurability持久性——提交后结果永久保存靠写入稳定存储。并发控制封锁S锁共享锁允许多事务读但阻塞写X锁排他锁独占阻塞其他任何锁读/写封锁粒度行/页/表、锁协议如静态/动态影响并发性能与死锁风险。两段锁协议2PL保证可串行化的经典协议。分为增长阶段只加锁不释放和收缩阶段只释放锁不加锁严格2PL释放仅在事务结束时进一步避免级联回滚。数据库安全授权GRANT/REVOKE基于角色或用户分配SELECT/INSERT等权限视图作为安全机制限制用户仅见其被授权的数据子集如隐藏敏感字段。索引加速数据访问的辅助数据结构。B树主流索引结构所有数据在叶子节点、叶子链表支持范围查询、高度平衡聚簇索引表数据物理顺序与索引键一致每张表至多一个如InnoDB主键索引非聚簇索引二级索引叶子存主键值。数据库设计阶段需求分析收集业务规则与数据流概念设计E-R建模独立于DBMS逻辑设计E-R→关系模式规范化处理物理设计索引、分区、存储参数等面向具体系统的优化。数据仓库DW面向分析的集成、主题导向、时变、非易失型数据库。OLAP联机分析处理支持多维分析切片、切块、钻取、旋转ETL抽取-转换-加载从异构源系统清洗、整合、加载至DW是DW建设核心流程。# 示例用SQL实现简单视图与授权CREATE VIEW employee_salary_view AS SELECT emp_id,name,salary FROM employees WHERE deptEngineering;GRANT SELECT ON employee_salary_view TO analyst_role;