第一范式、第二范式、第三范式

转自百度百科

第一范式

        如果一个关系模式R的所有属性都是不可分的基本数据项,则R∈1NF。简单的说,就是每一个列(属性)只有一个,没有重复。
        第一范式(1NF)是指数据库表的每一列都是不可分割的基本数据项,同一列中不能有多个值,即实体中的某个属性不能有多个值或者不能有重复的属性。

第二范式

       它的规则是要求数据表里的所有数据都要和该数据表的主键有完全依赖关系;如果有哪些数据只和主键的一部份有关的话,它就不符合第二范式。同时可以得出:如果一个数据表的主键只有单一一个字段的话,它就一定符合第二范式(前提是该数据表符合第一范式)。

第三范式

      每个非关键字列都独立于其他非关键字列,并依赖于关键字,第三范式指数据库中不能存在传递函数依赖关系。

### 数据库设计中的范式 #### 第一范式 (1NF) 第一范式规定数据库表的每一列都是不可分割的基本数据项,同一列中不能有多个值,即实体中的某个属性不能有多个值或者不能是复合属性。这确保了每行记录唯一标识一条信息。 例如,在学生选课系统中,“课程编号, 课程名称, 学生姓名”这样的组合应该被拆分为单独的字段存储[^1]: | ID | CourseID | StudentName | |----|----------|-------------| | 1 | C001 | Alice | 这种做法可以减少重复的数据条目并简化查询逻辑。 #### 第二范式 (2NF) 当关系已经处于第一范式,并且所有的非主属性完全依赖于整个主键而不是部分主键时,则该关系达到了第二范式。这意味着对于多列组成的联合主键情况,任何单一非主属性都不能仅由其中一部分决定。 考虑订单详情表的例子,这里`OrderID`和`ProductID`共同构成主键。为了达到2NF标准,需要将产品价格等细节移到独立的产品表里去处理[^2]: ```sql -- 订单明细表 OrderDetails CREATE TABLE OrderDetails ( OrderID INT NOT NULL, ProductID INT NOT NULL, Quantity INT, PRIMARY KEY(OrderID, ProductID), FOREIGN KEY(ProductID) REFERENCES Products(ProductID) ); -- 商品表 Products CREATE TABLE Products( ProductID INT PRIMARY KEY, Price DECIMAL(8,2), Name VARCHAR(50) ); ``` 这样做有助于消除冗余的信息复制以及保持更新的一致性。 #### 第三范式 (3NF) 如果一个关系既满足第二范式又消除了所有非主属性之间的传递依赖关系,则认为其符合第三范式的要求。具体来说就是除开直接关联到主键外,其他非主属性间不应该再有任何相互影响的关系存在。 继续上面提到的学生选修课程案例,假设现在有一个额外的需求是要记录授课教师的名字。如果不加思考地把老师名字加入原表会造成不必要的复杂度;而通过创建一个新的教员表并与之建立适当联系则更加合理[^3]: ```sql -- 教师表 Teachers CREATE TABLE Teachers ( TeacherID INT PRIMARY KEY, Name VARCHAR(50) ); -- 修改后的课程表 Courses ALTER TABLE Courses ADD COLUMN TeacherID INT; ALTER TABLE Courses ADD CONSTRAINT FK_Teacher FOREIGN KEY(TeacherID) REFERENCES Teachers(TeacherID); ``` 以上措施不仅提高了系统的灵活性也增强了维护上的便利程度。
评论 3
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值