数据库常用的数据模型有层次模型、网状模型、关系模型三种。
1、层次模型
层次模型是数据库系统最早使用的一种模型,它的数据结构Q是一棵"有向树"。根结点在最上端,层次最高,子结点在下,逐层排列。层次模型的特征是:有且只有一个根结点;其他结点有且仅有一个父结点网状模型。
2、网状模型
以网状结构表示实体与实体之间的联系。网中的每一个结点代表一个记录类型,联系用链接指针来实现。网状模型可以表示多个从属关系的联系,也可以表示数据间的交叉关系,即数据间的横向关系与纵向关系,它是层次模型的扩展。网状模型可以方便地表示各种类型的联系,但结构复杂,实现的算法难以规范化。其特征是:允许结点有多于一个父结点;可以有一个以上的结点没有父结点。
3、关系模型
关系模型以二维表结构来表示实体与实体之间的联系,它是以关系数学理论为基础的。关系模型的数据结构是一个“二维表框架"组成的集合。每个二维表又可称为关系。在关系模型中, *** 作的对象和结果都是二维表。关系模型是目前最流行的数据库模型。支持关系模型的数据库管理系统称为关系数据库管理系统,Access就是一种关系数据库管理系统。
描述的—致性,不仅用关系描述实体本身,而且也用关系描述实体之间的联系;可直接表示多对多的联系。关系必须是规范化的关系,即每个属性是不可分的数据项,不许表中有表。关系模型是建立在数学概念基础上的,有较强的理论依据。
S➡D,D➡M,可以推出S➡M;所以存在传递依赖;
第三范式规定不存在函数依赖,所以不满足第三范式;
属性不可再分,满足第一范式;
第一范式基础上,不存在部分函数依赖,所以满足第二范式,即2NF;
你可能对部分函数依赖不理解,我解释一下:S➡D,意味着D依赖于S,也就是S的内容决定着D的内容;如果{A,B}➡M,同时有B➡M,那就有部分函数依赖了,因为{A,B}中的一个子集是B,B是集合中的一部分;这就是部分函数依赖。
简而言之,数据库是面向事务的设计,数据仓库是面向主题设计的。
数据库一般存储在线交易数据,数据仓库存储的一般是历史数据。
数据库设计是尽量避免冗余,一般采用符合范式的规则来设计,数据仓库在设计是有意引入冗余,采用反范式的方式来设计。
数据库是为捕获数据而设计,数据仓库是为分析数据而设计,它的两个基本的元素是维表和事实表。维是看问题的角度,比如时间,部门,维表放的就是这些东西的定义,事实表里放着要查询的数据,同时有维的ID。
单从概念上讲,有些晦涩。任何技术都是为应用服务的,结合应用可以很容易地理解。以银行业务为例。数据库是事务系统的数据平台,客户在银行做的每笔交易都会写入数据库,被记录下来,这里,可以简单地理解为用数据库记帐。数据仓库是分析系统的数据平台,它从事务系统获取数据,并做汇总、加工,为决策者提供决策的依据。比如,某银行某分行一个月发生多少交易,该分行当前存款余额是多少。如果存款又多,消费交易又多,那么该地区就有必要设立ATM了。
显然,银行的交易量是巨大的,通常以百万甚至千万次来计算。事务系统是实时的,这就要求时效性,客户存一笔钱需要几十秒是无法忍受的,这就要求数据库只能存储很短一段时间的数据。而分析系统是事后的,它要提供关注时间段内所有的有效数据。这些数据是海量的,汇总计算起来也要慢一些,但是,只要能够提供有效的分析数据就达到目的了。
数据仓库,是在数据库已经大量存在的情况下,为了进一步挖掘数据资源、为了决策需要而产生的,它决不是所谓的“大型数据库”。那么,数据仓库与传统数据库比较,有哪些不同呢让我们先看看WHInmon关于数据仓库的定义:面向主题的、集成的、与时间相关且不可修改的数据集合。
“面向主题的”:传统数据库主要是为应用程序进行数据处理,未必按照同一主题存储数据;数据仓库侧重于数据分析工作,是按照主题存储的。这一点,类似于传统农贸市场与超市的区别—市场里面,白菜、萝卜、香菜会在一个摊位上,如果它们是一个小贩卖的;而超市里,白菜、萝卜、香菜则各自一块。也就是说,市场里的菜(数据)是按照小贩(应用程序)归堆(存储)的,超市里面则是按照菜的类型(同主题)归堆的。
“与时间相关”:数据库保存信息的时候,并不强调一定有时间信息。数据仓库则不同,出于决策的需要,数据仓库中的数据都要标明时间属性。决策中,时间属性很重要。同样都是累计购买过九车产品的顾客,一位是最近三个月购买九车,一位是最近一年从未买过,这对于决策者意义是不同的。
“不可修改”:数据仓库中的数据并不是最新的,而是来源于其它数据源。数据仓库反映的是历史信息,并不是很多数据库处理的那种日常事务数据(有的数据库例如电信计费数据库甚至处理实时信息)。因此,数据仓库中的数据是极少或根本不修改的;当然,向数据仓库添加数据是允许的。
数据仓库的出现,并不是要取代数据库。目前,大部分数据仓库还是用关系数据库管理系统来管理的。可以说,数据库、数据仓库相辅相成、各有千秋。
补充一下,数据仓库的方案建设的目的,是为前端查询和分析作为基础,由于有较大的冗余,所以需要的存储也较大。为了更好地为前端应用服务,数据仓库必须有如下几点优点,否则是失败的数据仓库方案。
1效率足够高。客户要求的分析数据一般分为日、周、月、季、年等,可以看出,日为周期的数据要求的效率最高,要求24小时甚至12小时内,客户能看到昨天的数据分析。由于有的企业每日的数据量很大,设计不好的数据仓库经常会出问题,延迟1-3日才能给出数据,显然不行的。
2数据质量。客户要看各种信息,肯定要准确的数据,但由于数据仓库流程至少分为3步,2次ETL,复杂的架构会更多层次,那么由于数据源有脏数据或者代码不严谨,都可以导致数据失真,客户看到错误的信息就可能导致分析出错误的决策,造成损失,而不是效益。
3扩展性。之所以有的大型数据仓库系统架构设计复杂,是因为考虑到了未来3-5年的扩展性,这样的话,客户不用太快花钱去重建数据仓库系统,就能很稳定运行。主要体现在数据建模的合理性,数据仓库方案中多出一些中间层,使海量数据流有足够的缓冲,不至于数据量大很多,就运行不起来了。
数据库管理其实不难,前提是有一个公司的标准管理规范。对数据库的 *** 作有可遵循的流程。
首先是数据库的规范。数据库命名,字符集,必须都要严格统一。命名一定要有规范,包含层次,业务系统等,望文生义。
其次表名要规范,事实表,维度表要分清,按业务类型分好表。表的字段命名要规范尽量不要用拼音,过长的单词可以用缩写。相同的含义的字段在不同表中命名要保持一致,字段类型要统一,长度统一,字段有注释说明,并且每建一个表都要做好数据字典归档,所有的表都能找到字段的含义。
存储过程,触发器也一样,命名要能够区分是什么业务系统的什么类型的功能。
数据库用户管理采取最小权限管理。所有当前权限之外的 *** 作必须申请权限才能放开。所有对现有表做修改 *** 作应该提交申请,做好改动表设计对数据上下游影响的评估。
数据的治理,可以对表做好数据分层,数据经过etl的流转最终统一存储到数据集市,数据仓库中。应用层再从中取数。
好的数据库系统一定是可用的,安全的。需要设计好容灾处理,定期检查备份,做好数据库高可用。设置安全级别更高的数据库访问方式,启用SSL等
数据库的层次模型应满足的条件是(C)。
A允许一个以上的结点无双亲,也允许一个结点有多个双亲
B必须有两个以上的结点
C有且仅有一个结点无双亲,其余结点都只有一个双亲
D每个结点有且仅有一个双亲
数据库简介:
数据库就是把一定的数据按照一定的逻辑关系存储起来的文件的集合,狭义的数据库仅仅是指存储数据的文件,广义的数据库还包括建立、管理数据文件的软件呢如foxpro,sqlserver。
一个构建得相对完善数据库的作用其实是难以用语言去表达的呢,比如说简单点的,全校师生的自然情况,一个商店所有商品的货源、进价、数量、进货日期、采购员……。
这些其实都是很简单的数据库,复杂点的就是一个大型网络游戏所有的成员的账号密码,或者是某个大工程所有参加人员和工程车辆的统计表,一个国家的工业企业设备的能力……建好的数据库对数据进行统计、查询、计算等等是非常方便快速。
可以实现数据共享。数据共享就包含了所有用户可同时存取数据库中的数据,也包括用户可以用各种方式去通过接口使用数据库,并且提供数据共享。
可以减少数据的冗余度。与文件系统相比,由于数据库实现了数据的共享,从而呢避免了用户各自建立应用文件。也减少了大量得重复数据,减少了数据的冗余,就维护了数据的一致性。
体现了数据的独立性。数据的独立性就包括了逻辑独立性和物理独立性。
用树形结构表示实体之间联系的模型叫层次模型。层次模型是最早用于商品数据库管理系统的数据模型。其典型代表是于1969问世、由IBM公司开发的数据库管理系统IMS(Information Management System)。
1231 层次模型的结构
层次模型的表示方法是:树的结点表示实体集(记录的型),结点之间的连线表示相连两实体集之间的关系,这种关系只能是“1一M”的。通常把表示1的实体集放在上方,称为父结点,表示M的实体集放在下方,称为子结点。层次模型的结构特点是:
(1) 有且仅有一个根结点。
(2) 根结点以外的其它结点有且仅有一个父结点。
因而层次模型只能表示“1一M”关系,而不能直接表示“M—M”关系。
在层次模型中,一个结点称为一个记录型,用来描述实体集。每个记录型可以有一个或多个记录值,上层一个记录值对应下层一个或多个记录值,而下层每个记录值只能对应上层一个记录值。例如,系记录型有:计算机系、电信系等记录值。而计算机系的下层记录值有软件、结构、应用等研究室和数据结构、 *** 作系统、数据库等课程,软件研究室下层又有员工和项目记录值,
关于层次模型中实体集之间多对多的联系的处理,解决的方法是引入冗余结点。例如,学生和课程之间的多对多的联系,引入学生和课程的冗余结点 转换为两棵树:一棵树的根是学生,子结点是课程,它表现了一个学生可以选多门课程;一棵树的根是课程,子结点是学生,它反映了一门课程可以被多个学生选。
1232层次模型的数据 *** 作
层次模型的数据 *** 作特点是必须从根结点入手,按层次顺序访问。首先介绍层次顺序中的两个概念。
(1) 记录类型码 对层次模型中的记录型树,按照从上到下,从左到右的顺序给每个记录类一个编号,称为记录类型码,以表示记录类在树中的位置。
(2) 顺序域 为了确定同一记录类下的各个记录值的位置,指定记录中某字段的值作为记录值的排序的依据,该字段称为顺序域。
(3) 层次顺序和路径 有了记录类型码和顺序域,就可以对所有的记录值进行排序,首先按类型码排序,同一类型码下的各个记录值再按顺序域排序。这种从上到下、从左到右的排列顺序就是层次顺序。从根结点开始到目标结点之间所有直系祖先的类型码和顺序域组成该结点的层次路径。如图119所示,D(Department)、S(Section)、C(Course)、F(Faculty)和P(Project)分别表示系、研究室、课程、员工和项目。D02的层次顺序: D02S01F01F02S02F03F04S03F05F06F07023056C01C02C03。
GU DEPT(DEPT#=’D02’)
SECTION(SEC#=’S03’)
FACULTY(FAC#=’F06’)
层次模型中的更新 *** 作之前,一般都先执行一个查询,再执行相应 *** 作。所以层次模型数据 *** 作的特点是通过层次路径定位记录,一次仅能访问一条记录。
1234 层次模型的物理存储
层次模型的物理存储有两种实现方法:
(1) 顺序法
按照层次顺序把所有的记录邻接存放,即通过物理空间的位置相邻来实现层次顺序。
(2) 指针法
各个记录存放时不是按层次顺序,而是用指针按层次顺序把它们链接起来。
1235 层次模型的约束
层次模型的限制是:
(1) 层次模型的树是有序树(层次顺序)。对任一结点的所有子树都规定了先后次序,这一限制隐含了对数据库存取路径的控制。
(2) 树中父子结点之间只存在一种联系,因此,对树中的任一结点,只有一条自根结点到达它的路径。
(3) 不能直接表示多对多的联系。
(4) 树结点中任何记录的属性只能是不可再分的简单数据类型。
数据库的开发对于后台编程程序员来说是必备能力之一了,而今天我们就一起来了解一下,关于数据库开发的设计规范都有哪些类型,北京北大青鸟希望通过对本文的阅读,大家对于数据库开发有更多的了解。
一、数据库命令规范
所有数据库对象名称必须使用小写字母并用下划线分割
所有数据库对象名称禁止使用mysql保留关键字(如果表名中包含关键字查询时,需要将其用单引号括起来)
数据库对象的命名要能做到见名识意,并且后不要超过32个字符
临时库表必须以tmp_为前缀并以日期为后缀,备份表必须以bak_为前缀并以日期(时间戳)为后缀
所有存储相同数据的列名和列类型必须一致(一般作为关联列,如果查询时关联列类型不一致会自动进行数据类型隐式转换,会造成列上的索引失效,导致查询效率降低)
二、数据库基本设计规范
1、所有表必须使用Innodb存储引擎
没有特殊要求(即Innodb无法满足的功能如:列存储,存储空间数据等)的情况下,所有表必须使用Innodb存储引擎(mysql55之前默认使用Myisam,56以后默认的为Innodb)Innodb支持事务,支持行级锁,更好的恢复性,高并发下性能更好
2、数据库和表的字符集统一使用UTF8
兼容性更好,统一字符集可以避免由于字符集转换产生的乱码,不同的字符集进行比较前需要进行转换会造成索引失效
3、所有表和字段都需要添加注释
使用comment从句添加表和列的备注从一开始就进行数据字典的维护
4、尽量控制单表数据量的大小,建议控制在500万以内
500万并不是MySQL数据库的限制,过大会造成修改表结构,备份,恢复都会有很大的问题
可以用历史数据归档(应用于日志数据),分库分表(应用于业务数据)等手段来控制数据量大小
5、谨慎使用MySQL分区表
分区表在物理上表现为多个文件,在逻辑上表现为一个表谨慎选择分区键,跨分区查询效率可能更低建议采用物理分表的方式管理大数据
6、尽量做到冷热数据分离,减小表的宽度
MySQL限制每个表多存储4096列,并且每一行数据的大小不能超过65535字节减少磁盘IO,保证热数据的内存缓存命中率(表越宽,把表装载进内存缓冲池时所占用的内存也就越大,也会消耗更多的IO)更有效的利用缓存,避免读入无用的冷数据经常一起使用的列放到一个表中(避免更多的关联 *** 作)
以上就是关于数据库常用的数据模型有哪三种全部的内容,包括:数据库常用的数据模型有哪三种、数据库如何判断规范化程度、数据仓库在数据库里处于什么层级等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)