发布网友
共2个回答
懂视网
创建数据库里最基本的应该就是建表,建索引、存储过程等一系列操作了。谈到表就不得不谈到实体。
一、数据实体
什么是实体,客观存在并且可以相互区别的事物称为实体。这里我们就简单的把它理解为一个表吧,描述实体的特性,我们就把他们称为了属性。也可以说当我们把一个数据库表当作一个实体,那么它里面的所有字段是不是就是一个属性了呢?结果是肯定的。
二、实体间的联系
我想说的是,很简单,数据库里表跟表间的关系莫过于三种:一对一;多对多;一对多。
一对一其实就是说我们建的主表跟相关联的表之间是一一对应的,比如说,我建了一个学生基本信息表:t_student,然后我又建了一个成绩表,里面有个外键,studentID,学生基本信息表里的字段studentID和成绩表里的studentID就是一对一。
一对多,也是类似,我另外建一个班级表,而每个班级有多个学生,每个学生就对应一个班级,对班级来说当然就是一对多了。
多对多,我还举这个例子,我建个选课表,可能有许多科目,每个科目有很多学生选,而每个学生又可以选择多个科目。这就是多对多了。
三、基本表的完整性
(1) 原子性。基本表中的字段是不可再分解的。
(2) 原始性。基本表中的记录是原始数据(基础数据)的记录。
(3) 演绎性。由基本表与代码表中的数据,可以派生出所有的输出数据。
(4) 稳定性。基本表的结构是相对稳定的,表中的记录是要长期保存的。
这是基本表的完整性,也是它特有的。这里我想说的是,在数据库里还有几种表也是常用的那就是中间表和临时表。
1、中间表
中间表是针对多对多关系的,就比如做公交查询系统。里面有两个表,分别是车站表、线路表。这里我们起个名字叫:t_busstation 、t_road,根据常识我们也知道,一个站有多个线路经过,而每个线路又有多个车站,怎么才能将两个表联系起来呢,如果是一对一,一对多,我们一个表,两个表就可以将他们实现了,但是多对多呢,这样我们就必须借助中间表用来连接两个表。一般中间表都是有一个本表的自增主键,还有另外两个表的主键。中间表是没有属性的因为它不是一个基本表。
2、临时表
首先所使用的数据库要支持临时表。
临时表:其实就是那些以#号开头为名字的数据表,它主要是用来存放临时数据的,当用户断开连接但没有出去临时表里的数据时,系统会自动把临时表里的数据清空。这里要说一点,临时表是放在系统数据库tempdb中的,而不是当前数据库。
临时表总共是分两种:本地临时表和全局临时表。
(1)这里我们需要了解的就是,在数据库中本地临时表是以一个#开头的,这种临时表只对当前的数据库用户可见,而其他的用户是不可见的。当数据库实例断开后当然也就丢失了数据了,不管是显式清空还是系统回收。
(2)还有一个就是全局临时表。它是以“##”开头的,而且是对于所有的用户都是可见的,当你断开数据库实例连接时,只要还有别的系统项目在引用它,连着数据库,那么数据就存在,只有当别的系统也断开连接时,系统才会清除全局临时表的数据。
现在就来看看三大范式。
第一范式:如果每列(或者每个属性)都是不可再分的最小数据单元(也称为最小的原子单元),则满足第一范式.比如一个工人的基本信息表,里面有工人的工号,性别,年龄,这些属性都是不可分割的,所以这个表就符合了第一范式。
第二范式: 就是在第一范式的基础上延伸,使之表里的每个字段都与主键发生关系。假如一个关系满足第一范式,并且除了主键以外的其它字段,都依赖于该主键,则满足第二范式.
例如:订单表(订单编号、产品编号、定购日期、价格、……),"订单编号"为主键,"产品编号"和主键列没有直接的关系,即"产品编号"列不依赖于主键列,这个列我们就可以把它删除。
第三范式:在第二范式的基础上更进一步,也就是为了实现表里的列都与主键列直接相关,不是间接相关。这个我们可以用“Armstrong 公理”中的传递规则来推理。
我们来看一下它的定义:
设U是关系模式R 的属性集,F 是R 上成立的只涉及U 中属性的函数依赖集。若X→Y 和 Y→Z在R 上成立,则X →Z 在R 上成立。因此我们就来看在网上搜索到的例子:例如:订单表(订单编号,定购日期,顾客编号,顾客姓名,……),初看该表没有问题,满足第二范式,每列都和主键列"订单编号"相关,再细看你会发现"顾客姓名"和"顾客编号"相关,"顾客编号"和"订单编号"又相关,最后经过传递依赖,"顾客姓名"也和"订单编号"相关。为了满足第三范式,应去掉"顾客姓名"列,放入客户表中。
这里其实就是为了说明数据库的表里步要出现冗余,在顾客表里已经有了"顾客姓名"了,而在订单表里就别出现了,而直接根据顾客编号相关联就可以,否则造成资源浪费。
热心网友
数据库是整个软件应用的根基,是软件设计的起点,它起着决定性的质变作用,因此我们必须对数据库设计高度重视起来,培养设计良好数据库的习惯,是一个优秀的软件设计师所必须具备的基本素质条件! 那么我们要做到什么程度才是对的呢?下面就说说数据库设计的原则: (1)、数据库设计最起码要占用整个项目开发的40%以上的时间
数据库是需求的直观反应和表现,因此设计时必须要切实符合用户的需求,要多次与用户沟通交流来细化需求,将需求中的要求和每一次的变化都要一一体现在数据库的设计当中。如果需求不明确,就要分析不确定的因素,设计表时就要事先预留出可变通的字段,正所谓“有备无患”。 (2)、数据库设计不仅仅停留于页面demo的表面 页面内容所需要的字段,在数据库设计中只是一部分,还有系统运转、模块交互、中转数据、表之间的联系等等所需要的字段,因此数据库设计绝对不是简单的基本数据存储,还有逻辑数据存储。 (3)、数据库设计完成后,项目80%的设计开发在你脑海中就已经完成了 每个字段的设计都是有他必要的意义的,你在设计每一个字段的同时,就应该已经想清楚程序中如何去运用这些字段,多张表的联系在程序中是如何体现的。换句话说,你完成数据库设计后,程序中所有的实现思路和实现方式在你的脑海中就已经考虑过了。如果达不到这种程度,那当进入编码阶段后,才发现要运用的技术或实现的方式数据库无法支持,这时再改动数据库就会很麻烦,会造成一系列不可预测的问题。 (4)、数据库设计时就要考虑到效率和优化问题 一开始就要分析哪些表会存储较多的数据量,对于数据量较大的表的设计往往是粗粒度的,也会冗余一些必要的字段,已达到尽量用最少的表、最弱的表关系去存储海量的数据。并且在设计表时,一般都会对主键建立聚集索引,含有大数据量的表更是要建立索引以提供查询性能。对于含有计算、数据交互、统计这类需求时,还要考虑是否有必要采用存储过程。 (5)、添加必要的(冗余)字段 像“创建时间”、“修改时间”、“备注”、“操作用户IP”和一些用于其他需求(如统计)的字段等,在每张表中必须都要有,不是说只有系统中用到的数据才会存到数据库中,一些冗余字段是为了便于日后维护、分析、拓展而添加的,这点是非常重要的,比如黑客攻击,篡改了数据,我们便就可以根据修改时间和操作用户IP来查找定位。 (6)、设计合理的表关联 若多张表之间的关系复杂,建议采用第三张映射表来关联维护两张表之间的关系,以降低表之间的直接耦合度。若多张表涉及到大数据量的问题,表结构尽量简单,关联也要尽可能避免。 (7)、设计表时不加主外键等约束性关联,系统编码阶段完成后再添加约束性关联 这样做的目的是有利于团队并行开发,减少编码时所遇到的问题,表之间的关系靠程序来控制。编码完成后再加关联并进行测试。不过也有一些公司的做法是干脆就不加表关联。 (8)、选择合适的主键生成策略