1. 代码100分首页

数据库设计范式及常用规范[通俗易懂]

小小码 • • 未分类 • 阅读 127
一键激活最新全家桶

数据库设计范式及常用规范[通俗易懂]数据库设计范式 数据库设计范式是指在关系型数据库中为了避免数据冗余和数据更新异常而特定的设计规则。目前，常用的数据库设计范式包括第一范式（1NF）、第二范式（2NF）、第三范式（3NF）以及BC范式等

数据库设计范式

数据库设计范式是指在关系型数据库中为了避免数据冗余和数据更新异常而特定的设计规则。目前，常用的数据库设计范式包括第一范式（1NF）、第二范式（2NF）、第三范式（3NF）以及BC范式等。

1、第一范式（1NF）

第一范式要求数据表的每个属性必须是原子的，即不能再分解为更小的数据项。通俗来说，就是数据表中的每个字段都只能存储单一的值，而不能存储多个值或者复杂的数据类型。例如，如果我们要存储一个员工的电话号码，就需要将它拆分成三个字段：区号、号码和分机号。

以下是一个不符合第一范式的数据表示例：

图书编号 书名 作者 ISBN
B0001 活着/许三观卖血记 余华 9787533945732, 9787020140888
B0002 围城/钱钟书文集/黄金时代 钱钟书,莫言,王小波

上述示例中，ISBN这个字段存储了多个数据项，因此不符合第一范式的要求。对于这种情况，我们需要将其拆分成多个记录，并为每个记录设置一个唯一的图书编号。

以下是符合第一范式的示例：

图书编号 书名 作者 ISBN
B0001 活着/许三观卖血记 余华 9787533945732
B0002 围城 钱钟书 9787020047378
B0003 钱钟书文集 钱钟书 9787108004359
B0004 黄金时代 王小波 9787530216781
B0005 许三观卖血记 余华 9787539971814

上述示例中，每个字段都只有单一的值，符合第一范式的要求。

2、第二范式（2NF）

第二范式要求在满足第一范式的基础上，非主键属性必须完全依赖于主键而非部分依赖。换句话说，就是数据表中的每个非主键属性必须和主键有直接关系，而不能只依赖于部分主键。

以下是一个不符合第二范式的示例：

订单编号 商品编号 商品名称 商品单价 购买数量 订单总额
O0001 P0001 电视 2000 2 4000
O0001 P0002 冰箱 3000 1 3000

上述示例中，订单总额这个字段依赖于商品单价和购买数量，而不是直接依赖于订单编号。为了符合第二范式的要求，我们需要将它拆分成多个数据表。

以下是符合第二范式的示例：

订单信息表(Order):

订单编号 订单日期 客户编号 订单金额
O0001 2022-01-01 C0001 7000

订单明细表(OrderDetail):

订单编号 商品编号 商品名称 商品单价 购买数量
O0001 P0001 电视 2000 2
O0001 P0002 冰箱 3000 1

在以上示例中，订单明细表中的每个字段都和订单编号有直接关系，没有部分依赖，因此符合第二范式的要求。

3、第三范式（3NF）

第三范式要求在满足第二范式的基础上，非主键属性之间不存在传递依赖关系。换句话说，就是数据表中的每个非主键属性都只依赖于主键，而不依赖于其他非主键属性。

以下是一个不符合第三范式的示例：

员工编号 部门名称 部门电话 部门主管
E0001 研发部 010-123456 A001
E0002 研发部 010-123456 A002
E0003 销售部 020-654321 B001

上述示例中，部门电话这个字段存在传递依赖关系，因为它依赖于部门名称而非员工编号。为了符合第三范式的要求，我们需要将其拆分成多个数据表。

以下是符合第三范式的示例：

员工信息表(Employee):

员工编号 员工姓名 部门编号 部门主管
E0001 张三 D0001 A001
E0002 李四 D0001 A001
E0003 王五 D0002 B001

部门信息表(Department):

部门编号 部门名称 部门电话 部门主管
D0001 研发部 010-123456 A001
D0002 销售部 020-654321 B001

在以上示例中，部门电话这个字段和主键有直接关系，不存在传递依赖关系，符合第三范式的要求。

4、BC范式

BC范式是指基于多值依赖的范式，它是所有范式中最严格的一种。它要求在满足第三范式的基础上，非主键属性之间不存在任何函数依赖关系。换句话说，就是数据表中的每个非主键属性都必须完全依赖于主键，不能依赖于其他非主键属性或者非主键组合。

以下是一个不符合BC范式的示例：

订单编号 用户编号 商品编号 商品名称 商品单价 购买数量 订单金额
O0001 U0001 P0001 电视 2000 2 4000
O0001 U0002 P0002 冰箱 3000 1 3000

上述示例中，订单金额这个字段依赖于商品单价和购买数量，而不是直接依赖于订单编号和用户编号。为了符合BC范式的要求，我们需要将其拆分成多个数据表。

以下是符合BC范式的示例：

订单信息表(Order):

订单编号 用户编号 订单日期 订单总额
O0001 U0001 2022-01-01 4000
O0001 U0002 2022-01-01 3000

订单明细表(OrderDetail):

订单编号 商品编号 商品名称 商品单价 购买数量
O0001 P0001 电视 2000 2
O0001 P0002 冰箱 3000 1

在以上示例中，订单金额没有出现在任何一个数据表中，符合BC范式的要求。

常用设计规范

1、命名规范

  1. 数据库名：使用小写字母和下划线组合，例如：my_database。
  2. 表名：使用小写字母和下划线组合，例如：my_table。
  3. 列名：使用小写字母和下划线组合，例如：my_column。

2、数据类型规范

  1. 整数类型：使用 INT 或 BIGINT，根据存储需求选择合适的数据类型。
  2. 浮点数类型：使用 FLOAT 或 DOUBLE，根据存储需求选择合适的数据类型。
  3. 字符串类型：使用 VARCHAR，长度根据存储需求选择合适的数据类型。
  4. 日期时间类型：使用 DATETIME 或 TIMESTAMP，根据存储需求选择合适的数据类型。
  5. 枚举类型：使用 ENUM，定义枚举值，避免使用字符串类型。
  6. 布尔类型：使用 BOOLEAN 或 TINYINT，根据存储需求选择合适的数据类型。

3、主键规范

  1. 主键名：使用 pk_ 开头，例如：pk_id。
  2. 主键类型：使用 INT 或 BIGINT，根据存储需求选择合适的数据类型。
  3. 主键值：使用自增长方式生成主键值。

4、索引规范

  1. 索引名：使用 idx_ 开头，例如：idx_name。
  2. 索引类型：根据查询需求选择合适的索引类型，例如：B+ 树索引、哈希索引等。
  3. 索引列：选择经常用于查询的列作为索引列。
  4. 索引数量：根据查询需求选择合适的索引数量，避免过多或过少的索引。

5、表关系规范

  1. 一对一关系：使用主键和外键建立关联。
  2. 一对多关系：在多的一方使用外键关联到一的一方的主键上。
  3. 多对多关系：使用中间表建立关联，中间表包含两个外键，分别关联到两个表的主键上。

6、表设计规范

  1. 表名：表名应该具有描述性，避免使用简单的单词或缩写。
  2. 列名：列名应该具有描述性，避免使用简单的单词或缩写。
  3. 列数量：避免过多或过少的列，适当地将列拆分成多个表。
  4. 表结构：避免过于复杂的表结构，尽可能简单明了。
  5. 表注释：为每个表添加注释，描述表的作用和设计意图。
  6. 列注释：为每个列添加注释，描述列的作用和设计意图。

7、安全规范

  1. 数据备份：定期备份数据库，避免数据丢失。
  2. 数据加密：对敏感数据进行加密，保障数据安全。
  3. 数据权限：对用户进行权限管理，避免非法操作和数据泄露。

8、性能规范

  1. 索引优化：根据查询需求优化索引，避免过多或过少的索引。
  2. 查询优化：优化查询语句，避免全表扫描和多次查询。
  3. 数据库缓存：使用缓存技术提高查询性能，避免频繁访问数据库。
  4. 数据库分区：对大表进行分区，提高查询性能。

Snake case 约定

Snake case 约定是一种常见的命名约定，用于将标识符（如变量、函数、表和列名）中的单词以下划线连接，形成类似于蛇的模样，因而得名。例如，snake case 格式的 “user_id” 和 “first_name” 的单词使用下划线连接。

这种命名约定通常用于编程语言中的变量和函数名，以及在数据库中的表和列名。与其他一些约定（如 camel case 或 Pascal case）相比，它在单词之间使用下划线分隔符，使其更易于阅读和识别单词。同时，它也可以消除大小写造成的歧义问题。

以下是 snake case 命名约定的一些主要特点：

  1. 将单词用下划线隔开：在 snake case 命名约定中，使用下划线作为单词之间的分隔符。这可以帮助提高识别单词的准确性，使其更易于阅读和理解。
  2. 所有字母均为小写：所有单词都必须使用小写字母。这减少了阅读时需要注意大小写所带来的负担，并且避免了大小写混淆的问题。
  3. 长度没有限制：snake case 命名约定没有任何长度限制，但是通常建议将标识符名称保持简短且易于理解。

版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
转载请注明出处: https://daima100.com/13778.html

赞 (0)
小小码小小码
0 0

相关推荐

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注