数据库设计范式的应用之我见

本文探讨了数据库设计中的范式原则,强调了遵循第一、第二及第三范式的必要性,同时也指出了在实际应用中适度冗余的重要性。此外,还讨论了数据库设计在表达复杂对象关系时的局限性。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

个人意见:数据库的存在,在不久的将来会变成文物!

  但是我逃脱不了目前数据库存在,我是生活在它的统治下,所以既然要击倒他,那么第一步应该是充分的了解他!


  数据库的第一范式是我们研究的最小单元,也是最小可控单元!当你的研究和可控单元增大或者减小时候,如果单元本身不变,这就不符合第一范式了!

  第二和第三范式都是讲的是依赖关系,对于关键字之间和关键字与非关键字之间以及非非关键字之间的传递依赖的依赖关系,他们都一概否决掉!所以当你发现这些不正当的依赖关系时,得警惕了!

  在设计时候,我们可以先按照范式要求一步一步的设计完成。但是现实中并不要求那么完美,可以存在冗余!所以,我们在为了给一些性能等等让步,就可以在适当的范围内添加冗余了!

  这里引用别人的结论:

写道
满足范式要求的数据库设计是结构清晰的,同时可避免数据冗余和操作异常。这并意味着不符合范式要求的设计一定是错误的,在数据库表中存在1:1或1:N关系这种较特殊的情况下,合并导致的不符合范式要求反而是合理的。

写道
目地:规范化目的是使结构更合理,消除存储异常,使数据冗余尽量小,便于插入、删除和更新
原则:遵从概念单一化 "一事一地"原则,即一个关系模式描述一个实体或实体间的一种联系。规范的实质就是概念的单一化。
方法:将关系模式投影分解成两个或两个以上的关系模式。
要求:分解后的关系模式集合应当与原关系模式"等价",即经过自然联接可以恢复原关系而不丢失信息,并保持属性间合理的联系。

 

   在我们设计数据库的时候,一定要时刻考虑范式的要求。


这里我看到了数据库在反应现实问题时的鸡肋了!对于关系表达很弱!在上升到对象层,那种复杂的关系,必然得通过数据库访问层的转化!这种途增的复杂性是不符合面向对象的理念的!

  面向对象是不怎么适合数据库的,但是目前还没有真正意义上的替代产物!

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值