当前位置: 首页 > 科技观察

Java开发中数据库设计的14个技巧,你知道几个?

时间:2023-03-12 04:39:12 科技观察

1。原始文档和实体之间的关系可以是一对一、一对多或多对多。一般来说,它们是一对一的关系:即一份原始文件对应一个且仅一个实体。在特殊情况下,它们可能是一对多或多对一的关系,即一个原始文档对应多个实体,或者多个原始文档对应一个实体。这里的实体可以理解为基础表。理清了这个对应关系之后,对我们设计输入界面大有裨益。〖例1〗:一个员工简历数据对应人力资源信息系统中的三个基本表:员工基本信息表、社会关系表、工作履历表。这是“一份原始文件对应多个实体”的典型例子。2.主键和外键一般来说,一个实体不可能既没有主键也没有外键。在E-R图中,叶子部分的实体可以定义主键也可以不定义(因为它没有后代),但必须有外键(因为它有父亲)。主键和外键的设计在全局数据库的设计中起着重要的作用。当全球数据库设计完成时,一位美国数据库设计专家说:“钥匙无处不在,除了钥匙什么都没有。”系统核心(数据模型)的思想高度抽象。因为:主键是对实体的高度抽象,主键和外键的配对代表了实体之间的联系。3.基本表的性质基本表不同于中间表和临时表,因为它具有以下四个特点:原子性。基表中的字段不可分解。独创性。基表中的记录是原始数据(基础数据)的记录。演绎的。所有输出数据都可以从基本表和代码表中的数据中导出。稳定。基本表的结构比较稳定,表中的记录必须长期保存。了解了基本表的性质后,在设计数据库时就可以区分基本表和中间表、临时表了。4.范式标准基本表及其字段的关系应尽可能满足第三范式。然而,满足第三范式的数据库设计往往不是最好的设计。为了提高数据库的运行效率,往往需要降低范式标准:适当增加冗余,以达到以空间换取时间的目的。〖例2〗:有一张存储商品的基本表,如表一所示,存在“金额”字段说明该表的设计不满足第三范式,因为“金额”可以获取用“单价”乘以“数量”,说明“数量”是冗余字段。但是,增加冗余字段“金额”可以提高查询统计的速度,也就是用空间换取时间的做法。在Rose2002中,有两种规定的列:数据列和计算列。“金额”等列称为“计算列”,“单价”和“数量”等列称为“数据列”。表1商品表的表结构5.三种范式的共同理解三种范式的共同理解对数据库设计大有裨益。在数据库设计中,为了更好的应用三种范式,需要通俗的理解三种范式(通俗的理解就够了,不是最科学准确的理解):第一范式:1NF是属性的原子性约束要求属性是原子的,不能被分解;第二种范式:2NF是对记录的唯一约束,要求记录具有唯一标识,即实体的唯一性;第三范式:3NF是域的冗余性约束,即任何域都不能从其他域派生出来,它要求域内不存在冗余。没有冗余的数据库设计可以做到这一点。但是,没有冗余的数据库不一定是最好的数据库。有时为了提高运行效率,需要降低范式标准,适当保留冗余数据。具体做法是:在设计概念数据模型时遵循第三范式,在设计物理数据模型时考虑降低范式标准的工作。减少范式就是增加字段并允许冗余。6、善于识别并正确处理多对多关系。如果两个实体之间存在多对多关系,则应消除这种关系。消除它的方法是在两者之间添加第三个实体。这样,原来的一对多关系现在变成了两个一对多关系。将原来两个实体的属性合理分配给三个实体。这里的第三个实体其实是一个比较复杂的关系,它对应一个基本表。一般来说,数据库设计工具不识别多对多关系,但可以处理多对多关系。〖例3〗:在“图书馆信息系统”中,“图书”是一个实体,“读者”也是一个实体。这两个实体之间的关系是典型的多对多关系:一本书可以在不同时间被多个读者借到,一个读者可以借到多本书。为此,应在两者之间加入第三个实体。实体名为“借还书”,其属性为:借还时间、借还标志(0为借书,1为还书),同时应有两个外键(主键为“books”,“readers”的主键),以便它可以与“books”和“readers”连接。7、主键PK的取值方法PK是程序员在表与表之间使用的连接工具。可以是一个没有物理意义的数字串,由程序自动加1实现。也可以是具有物理意义的字段名或字段名的组合。但前者优于后者。当PK为字段名组合时,建议字段数不要太多。如果字段太多,索引不仅会占用大量空间,还会变慢。8、正确理解数据冗余。多个表中主键和外键的重复出现不属于数据冗余。这个概念一定要清楚。其实很多人还不清楚。非关键字段的重复就是数据冗余!而且是低级冗余,即重复冗余。高级冗余不是字段的重复出现,而是字段的派生出现。〖例4〗:商品中的“单价、数量、金额”三个字段中,“金额”是“单价”乘以“数量”得出的,属于冗余,是一个高级冗余。冗余的目的是提高处理速度。只有低级别的冗余才会增加数据的不一致性,因为相同的数据可能从不同的时间、地点和角色被多次输入。因此,我们提倡高层冗余(derivedredundancy),反对低层冗余(repetitiveredundancy)。9、E-R图没有标准答案信息系统的E-R图没有标准答案,因为它的设计和绘制方法不是唯一的,只要覆盖系统需求的业务范围和功能内容即可,是可行的。否则,修改E--R图。虽然它没有一个统一的标准答案,但不代表可以随意设计。一个好的ER图的标准是:结构清晰、关联简洁、实体数量适中、属性分布合理、无低级冗余。10、视图技术在数据库设计中非常有用。与基本表、码表、中间表不同,视图是依赖于数据源真实表而存在的虚拟表。视图是程序员使用数据库的窗口,是基表数据合成的一种形式,是数据处理的一种方式,是用户数据保密的手段。为了进行复杂的处理,提高计算速度和节省存储空间,定义的视图深度一般不超过三层。如果三层视图还是不行,应该在视图上定义一个临时表,然后在临时表上定义视图。这样,重叠的定义就重复了,视图的深度就不受限制了。对于一些关系到国家政治、经济、技术、军事和安全利益的信息系统,视图的作用更为重要。这些系统的基础表物理设计完成后,立即在基础表上建立一级视图。该层视图的数量和结构与基本表的数量和结构完全相同。并且规定所有程序员只允许对视图进行操作。只有数据库管理员,拥有多人共享的“安全钥匙”,才能直接对基础表进行操作。请读者想一想:这是为什么呢?11.中间表、报表和临时表中间表是存储统计数据的表。它专为数据仓库、输出报告或查询结果而设计。有时它没有主键和外键(数据仓库除外)。临时表是程序员个人设计的,用来存放个人使用的临时记录。基表和中间表由DBA维护,临时表由程序员自己自动维护。12、完整性约束体现在域完整性的三个方面:使用Check来实现约束。在数据库设计工具中,定义字段的取值范围时,有勾选按钮来定义字段的值。参照完整性:通过PK、FK和表级触发器实现。用户自定义完整性:是一些业务规则,用存储过程和触发器实现。13、防止数据库设计被打补丁的方法是“三少原则”1、数据库中的表越少越好。只有表数少才能体现系统的E-R图小而精,去除多余的冗余实体,形成对客观世界的高度抽象,进行系统的数据集成以防止打补丁。2、一张表的字段越少越好。因为主键的作用,一是建立主键索引,二是作为分表的外键,所以减少了组合主键的字段数,不仅节省了运行时间,也节省了索引存储空间;3.表格中字段越少越好。只有字段数少,才能说明系统中没有数据重复,数据冗余很少。更重要的是,督促读者学会“变列为行”,这样可以防止子表中的字段被拉入到主表中,而在主表中留下许多空置字段。所谓“列转行”,就是把主表中的部分内容拉出来,单独建一个子表。这个方法很简单,但有些人就是不习惯,不采纳,不执行。数据库设计的实用原则是在数据冗余和处理速度之间找到合适的平衡点。“三少”是一个整体的概念,一个综合的观点,不能孤立地遵循一定的原则。原则是相对的,不是绝对的。“三个以上”的原则肯定是错误的。试想:如果覆盖系统相同的功能,一百个实体(共一千个属性)的E-R图肯定比两百个实体(共两千个属性)的E-R图好很多。提倡“三少”原则,就是要求读者学会使用数据库设计技术进行系统的数据集成。数据集成的步骤是将文件系统集成到应用数据库中,应用数据库集成到主题数据库中,主题数据库集成到全局综合数据库中。集成度越高,数据共享越强,信息孤岛现象越少,整个企业信息的全局E-R图中实体数量、主键数量、属性数量越少系统。提倡“三少”原则的目的是为了防止读者使用补丁技术不断对数据库进行增删改查,使企业数据库成为随机设计的数据库表的“垃圾堆”,或“大码”的数据库表。数据库中的基础表、码表、中间表、临时表杂乱无章、数不胜数,企事业单位信息系统无法维护、瘫痪。任何人都可以实现“三多”原则,这是一种“打补丁法”设计数据库的谬论。“三少”原则就是少而精的原则。它需要很高的数据库设计技巧和艺术,这是任何人都做不到的,因为这个原则是避免使用“打补丁的方法”来设计数据库的理论基础。14、提高数据库运行效率的途径在给定的系统硬件和系统软件条件下,提高数据库系统运行效率的途径是:在数据库的物理设计上,减少范式,增加冗余,少用触发器,多用存储过程。当计算非常复杂,记录数非常多时(比如1000万条),复杂的计算首先要在数据库外进行,在C++语言中计算处理完成后以a的形式文件系统,最后存入数据库,添加到表中。这是电信计费系统设计的经验。如果发现某个表的记录过多,比如超过1000万条记录,就应该对表进行水平拆分。水平拆分的方法是根据表的主键PK的某个值,将表的记录水平拆分成两个表。如果发现一个表的字段太多,比如超过八十个,则垂直拆分表,将原表分解为两个表。对数据库管理系统DBMS进行系统优化,即优化各种系统参数,比如缓冲区的数量。在使用面向数据的SQL语言进行编程时,尽量使用优化算法。综上所述,要提高数据库的运行效率,必须在数据库系统级优化、数据库设计级优化、程序实现级优化三个层面同时发力。以上十四种技巧,是很多人在大量的数据库分析和设计实践中逐渐总结出来的。对于这些经验的运用,读者不要死记硬背,而要消化理解,实事求是,灵活掌握。并逐步做到:在应用中开发,在开发中应用。