在数据库设计中,所有结构和关系都是有一定方法可寻的,这些方法来自与客户沟通或在Internet上咨询行业知识时所学的。同样,数据库设计也从这些方法开始。那么数据库设计的方法有哪些?
数据库设计的方法:
Rule 1:将数据按照逻辑思维分成不同的块,让生活更简单
这个规则其实就是“三范式” 中的第一范式。这样设计的目标,是为了当你需要查询套多的字符串解析功能时,如子串,charindexetc,它能为你提供这项功能。
例如,如果你想查询某个学生的姓名,通过“Koirala”和“Harisingh”来进行区分。因此,更好的方法就是打破数据逻辑思维,以便我们编写更加简洁、容易查询的表单。
Rule 2:当数据太多时,rule 1不可用
开发者们的思维有时很单一,如果你告诉他们某种方式,他们会一直这么做下去,要知道过度的使用会造成不必要的麻烦。正如我们之前谈到的rule 1,首先要进行分解,明确自己的需求。例如,当你看到电话号码字段时,你可以在ISD代码上进行操作区分这些电话号码(直到满足你的需求)。尽管这是不错的方法,但会给你带来更多的并发症。
Rule 3:弄清(OLTP或OLAP)应用的本质是什么
当开始制作数据表单设计时,首先,要分析你数据库设计的这个程序的本质是什么?是事务性还是分析性的?你会发现许多开发者会默认应用常规化规则,随后才考虑性能问题而不考虑应用的本质。关于事务性和分析性,一起来看下两者区别。Transactional:这种应用,用户对CRUD较为感兴趣,即创建、读取、更新和删除记录。这种数据,官方名称之位OLTP。
Analytical:用户对分析、报告、预测等方面感兴趣。这类数据库很少有嵌入和更新。主要目的是为了尽快获取和分析数据。官方名称之为OLAP。
换句话说,如果你想以嵌入、更新、删除为重点,可选择常规化的表单设计或者创建一个简单的非常规化的数据架构。
Rule 4:当心数据依赖
观察该领域中的部分列表。假如我们创建了roll number和standard,可以看到教学科目紧密联系在一起,但与学生学习的科目没有直接关联。如果我们想给每位学生更新教学科目,这似乎看起来是不符合逻辑的,但是通过键入standard条目转换这些数据就可达到目的。这个规则告诉我们“所有的键入都应该依赖主键”。All keys should depend on the full primary key and not partially。
Rule 5:将重复、不统一的数据视作你最大的敌人
聚焦和重构复制数据。我比较担心的不是复制数据所需要的磁盘空间而是它因此而造成的混乱。
其中一个解决方法就是将不同的任务栏把相同的数据通过新建一个键入值联接在一起。如图。我们通过创建一个新的条目“Standards”即可将数据重新排,显示相同的部分。
Rule 6:注意被分隔符分割的数据
前面的规则1即“第一范式”提到避免数组重复。如果你看到教学大纲紧密排列在一起,这个领域中需要很多数据来填充,这种我们称之为“重复数组”。如果我们必须操纵这些数据,单凭查询是很困难的,我甚至还怀疑是否具备这个查询功能。这些带分隔符的数据需要特别注意,要利用更好的方法将这些数据移动到一个不同的任务栏中,以便更好的分类。