编辑“︁数据库设计原则”︁

= 数据库设计原则 =

数据库设计原则是构建高效、可靠数据库系统的核心准则。良好的数据库设计能确保数据一致性、减少冗余、优化查询性能，并适应未来业务需求变化。本章将系统介绍关系型数据库设计的核心方法论。

== 核心概念 ==
'''数据库设计'''是将现实世界业务需求转化为结构化数据模型的过程，主要包含以下阶段：
* '''概念设计'''：通过ER模型描述业务实体和关系
* '''逻辑设计'''：将概念模型转换为关系模式
* '''物理设计'''：实现具体数据库对象的存储结构

== 基本原则 ==

=== 第一范式（1NF） ===
确保每列都是'''原子性'''的不可分割的最小数据单元，消除重复组。

'''示例：不符合1NF的表'''
{| class="wikitable"
|-
! 订单ID || 产品列表
|-
| 1001 || 手机, 耳机, 充电器
|}

'''修正为1NF：'''
{| class="wikitable"
|-
! 订单ID || 产品名称
|-
| 1001 || 手机
|-
| 1001 || 耳机
|-
| 1001 || 充电器
|}

=== 第二范式（2NF） ===
在满足1NF基础上，消除'''部分函数依赖'''（非主键字段必须完全依赖于整个主键）。

<mermaid>
erDiagram
    ORDERS ||--o{ ORDER_ITEMS : contains
    ORDERS {
        int order_id PK
        date order_date
    }
    ORDER_ITEMS {
        int order_id PK,FK
        int product_id PK,FK
        int quantity
    }
</mermaid>

=== 第三范式（3NF） ===
在满足2NF基础上，消除'''传递依赖'''（非主键字段间不能存在依赖关系）。

'''示例：'''
{| class="wikitable"
|-
! 学生ID (PK) || 学生姓名 || 学院 || 学院地址
|-
| 101 || 张三 || 计算机学院 || 科技楼A座
|}

应拆分为：
{| class="wikitable"
|-
! 学生ID (PK) || 学生姓名 || 学院ID (FK)
|-
| 101 || 张三 || 1
|}

{| class="wikitable"
|-
! 学院ID (PK) || 学院名称 || 学院地址
|-
| 1 || 计算机学院 || 科技楼A座
|}

== 高级设计原则 ==

=== 反范式化 ===
为优化查询性能，在'''受控情况下'''故意违反范式原则：

<syntaxhighlight lang="sql">
-- 订单总金额的冗余存储
CREATE TABLE orders (
    order_id INT PRIMARY KEY,
    customer_id INT,
    total_amount DECIMAL(10,2),  -- 反范式化字段
    FOREIGN KEY (customer_id) REFERENCES customers(customer_id)
);
</syntaxhighlight>

=== 索引设计 ===
合理使用索引提高查询效率：

<syntaxhighlight lang="sql">
-- 多列索引示例
CREATE INDEX idx_customer_order ON orders(customer_id, order_date DESC);

-- 覆盖索引
CREATE INDEX idx_order_covering ON orders(order_id) INCLUDE (total_amount, status);
</syntaxhighlight>

== 设计模式 ==

=== 星型模式 ===
数据仓库常用设计：

<mermaid>
erDiagram
    FACT_SALES ||--o{ DIM_PRODUCT : references
    FACT_SALES ||--o{ DIM_TIME : references
    FACT_SALES ||--o{ DIM_STORE : references
    FACT_SALES {
        int sales_id PK
        decimal amount
    }
    DIM_PRODUCT {
        int product_id PK
        varchar name
    }
</mermaid>

=== 实体-属性-值（EAV） ===
适用于稀疏属性场景：

<syntaxhighlight lang="sql">
CREATE TABLE products (
    product_id INT PRIMARY KEY,
    name VARCHAR(100)
);

CREATE TABLE product_attributes (
    entity_id INT,
    attribute_name VARCHAR(50),
    attribute_value TEXT,
    PRIMARY KEY (entity_id, attribute_name),
    FOREIGN KEY (entity_id) REFERENCES products(product_id)
);
</syntaxhighlight>

== 性能考量 ==
* '''读写比例'''：OLTP vs OLAP系统设计差异
* '''数据量级'''：分区策略 <math>P(hash(key) \% N)</math>
* '''并发控制'''：乐观锁 vs 悲观锁实现

== 案例研究 ==
'''电商平台数据库设计'''
1. 用户服务：满足3NF的规范化设计
2. 商品目录：使用JSON字段存储可变属性
3. 订单系统：适当反范式化存储衍生数据

<syntaxhighlight lang="sql">
-- JSON字段使用示例（PostgreSQL）
CREATE TABLE products (
    id SERIAL PRIMARY KEY,
    name TEXT NOT NULL,
    attributes JSONB,
    price NUMERIC(10,2)
);

-- 查询JSON字段
SELECT name FROM products 
WHERE attributes->>'color' = 'red' 
AND (attributes->>'weight')::numeric > 500;
</syntaxhighlight>

== 最佳实践 ==
# 始终从'''业务需求'''出发设计数据模型
# 前期规范化设计，后期按需反范式化
# 为每个表设计'''单列自增主键'''
# 使用外键约束保证'''引用完整性'''
# 考虑数据'''生命周期'''管理策略

== 常见错误 ==
{{Warning|1=
* 过度规范化导致复杂查询
* 滥用EAV模式造成性能问题
* 忽视索引维护成本
* 缺少版本控制机制
}}

通过遵循这些原则，您可以构建出既满足当前业务需求，又具备良好扩展性的数据库结构。实际设计中需要根据具体场景权衡不同原则的应用强度。

[[Category:计算机科学]]
[[Category:数据库与信息系统]]
[[Category:数据库基础]]