根据

数据库设计

关系数据库的建议E-R模型，必须根据产品经理的设计规划，提取模型和关系，并创建表结构。这是项目开始的第一步

在开发中，有很多设计数据库的软件，如power designer、db desinger等，这些软件可以直观地看到实体和实体的关系

数据库的设计可以由专业的数据库设计人员进行，也可以由开发团队的成员进行。通常由项目经理带领团队成员进行

虽然现阶段不需要独立完成数据库设计，但请注意积累这方面的经验

经过

三范式

研究和使用中的问题总结，对设计数据库提出了一些规范。这些规范被称为范式(Normal Form )

现在找的东西共有八种范式，一般需要遵守三种范式

强调第一范式(1NF ) )列的原子性，即不能将列分为其他几列。

想想这样的表吧。【联系方式】(姓名、性别、电话)在实际情况下，如果一个人的联系方式有家庭电话和公司电话，则该表的结构设计达不到1NF。要配合1NF，分割列(电话)就可以了。即【联系方式】(姓名、性别、家庭电话、公司电话)。 1NF容易分辨，但2NF和3NF容易混淆。

第二范式(2NF ) :首先是1NF，包含另外两个部分。一是表格需要主键。第二，不在主键中的列完全依赖于主键，不能只依赖于主键的一部分。

想想订单明细表吧。【订单详细信息】(OrderID、ProductID、UnitPrice、Discount、Quantity、ProductName )。因为知道一个订单可以订购多个产品，所以只有一个OrderID不能成为主键。主键必须为(订单id，产品id )。显然，“Discount (折扣)”、“Quantity (质量)”和“数量”完全取决于主键(OderID、ProductID ) )，而“UnitPrice”和“ProductName”仅取决于产品id。所以订单详细信息表不适合2NF。不符合2NF标准的设计容易产生冗馀的数据。

将【OrderDetail】表更改为【OrderDetail】(OrderID、ProductID、Discount、Quantity )和【Product】) ProductID、UnitPrice、Product

第三范式(3NF )首先是2NF，非主键列必须直接依赖主键，不能存在事务依赖。这意味着，非主键列a可能依赖于非主键列b，而非主键列b可能依赖主键。

认为订单表单【Order】(OrderID、OrderDate、CustomerID、CustomerName、CustomerAddr、CustomerCity )的主键为) OrderID 其中，OrderDate、CustomerID、CustomerName、CustomerAddr、CustomerCity等非主键列都依赖于主键(OrderID )，因此为2NF 但是，问题是客户名称、客户addr、客户city不是直接依赖主键，而是直接依赖客户id (非主键列)，因为它只有传递后才依赖主键，所以3nn 【Order】为【Order】(OrderID，OrderDate，Customer )和【Customer】(CustomerID，CustomerName，CustomerAddr，customerer ) 区分它们的密钥是2NF )非主键列完全依赖于主键还是部分主键。 3NF )非主键列是直接依赖于主键，还是直接依赖于非主键列？

不遵循1NF

。

不遵循2NF

。

不遵循3NF

。

最终表

。

E-R模型

E表示条目、实体和设计实体。指定从什么方面编写对象，以及将实体转换为数据库中的表，就像定义类一样

r表示关系，关系和关系表示两个图元之间的对应规则，关系类型包括一对一、一对多和多对多

关系也是数据，必须通过字段存储在表中

如果实体a和实体b一对一，则会在表a或表b中创建一个字段，其中包含另一个表的主键值

实体a对实体b是一对多：在表b中创建一个字段，其中包含表a的主键值

实体a和实体b是多对多的，它们创建一个新的表c，只有两个字段，一个字段是存储a的主键值，另一个表c只有存储b的主键值

请考虑：举几个例子，满足一对一、一对多、多对多的对应关系

逻辑删除

我不想物理删除重要数据。一旦删除，就无法取回数据

删除方案设置isDelete的列。类型为bit，表示逻辑删除。默认值为0

对于不重要的数据，可以物理删除

数据的重要性必须根据实际开发来决定

样品

设计两张表：班级表、学生表

类表classes

名字

isdelete

学生表students

名字

二进制

性别者

clsid