当前位置:文档之家› 对数据库当中的逻辑数据模型的个人理解

对数据库当中的逻辑数据模型的个人理解

对数据库当中的逻辑数据模型的个人理解
对数据库当中的逻辑数据模型的个人理解

对数据库的个人理解

年级: 大二

学号: 11214030216

姓名: 盛斐

专业: 信息管理与信息系统

二零一三年九月

摘要:访问数据库中的数据取决于数据库实现的数据模型。数据库模型描述了在数据库中结构化和操纵数据的方法,模型的结构部分规定了数据如何被描述(例如树、表等);模型的操纵部分规定了数据的添加、删除、显示、维护、打印、查找、选择、排序和更新等操作......

导读:什么是数据模型,数据库和数据模型的关系是什么,我们最常用的数据库有哪些?近期出现的新的数据模型和以往我们使用的数据库有什么不同,现在世界上数据库数据模型的发展趋势是什么?

一、什么是数据库

数据库是依照某种数据模型组织起来并存放二级存储器中的数据集合。这种数据集合具有如下特点:尽可能不重复,以最优方式为某个特定组织的多种应用服务,其数据结构独立于使用它的应用程序,对数据的增、删、改和检索由统一软件进行管理和控制。从发展的历史看,数据库是数据管理的高级阶段,它是由文件管理系统发展起来的。

数据库的基本结构分三个层次,反映了观察数据库的三种不同角度。

(1)物理数据层。它是数据库的最内层,是物理存贮设备上实际存储的数据的集合。这些数据是原始数据,是用户加工的对象,由内部模式描述的指令操作处理的位串、字符和字组成。

(2)概念数据层。它是数据库的中间一层,是数据库的整体逻辑表示。指出了每个数据的逻辑定义及数据间的逻辑联系,是存贮记录的集合。它所涉及的是数据库所有对象的逻辑关系,而不是它们的物理情况,是数据库管理员概念下的数据库。

(3)逻辑数据层。它是用户所看到和使用的数据库,表示了一个或一些特定用户使用的数据集合,即逻辑记录的集合。

二、数据库和数据模型有什么关系

访问数据库中的数据取决于数据库实现的数据模型。数据库模型描述了在数据库中结构化和操纵数据的方法,模型的结构部分规定了数据如何被描述(例如树、表等);模型的操纵部分规定了数据的添加、删除、显示、维护、打印、查找、选择、排序和更新等操作。数据模型会影响客户端通过API对数据的操作。不同的数据模型可能会提供或多或少的功能。一般而言,数据模型不会直接提供过多的功能,许多功能必须由客户端自行实现。

三、常用的的数据模型

目前最常用的数据库模型是关系数据库,关系实际上就是关系模式在某一时刻的状态或内容。也就是说,关系模式是型,关系是它的值。关系模式是静态的、稳定的,而关系是动态的、随时间不断变化的,因为关系操作在不断地更新着数据库中的数据。

关系模型对比其他模型具有如下的优点:

(1)数据结构单一

关系模型中,不管是实体还是实体之间的联系,都用关系来表示,而关系都对应一张二维数据表,数据结构简单、清晰。

(2)关系规范化,并建立在严格的理论基础上

构成关系的基本规范要求关系中每个属性不可再分割,同时关系建立在具有

坚实的理论基础的严格数学概念基础上。

(3)概念简单,操作方便

关系模型最大的优点就是简单,用户容易理解和掌握,一个关系就是一张二维表格,用户只需用简单的查询语言就能对数据库进行操作。

但是随着因特网的出现,关系数据库不能与因特网完美的融合,需要在因特网和数据库之间加入大量的中间件,这就在无形的当中加大了数据库基于网络应用的难度,在以HTTP为基础,HTML为文件格式的因特网的需求条件下,关系数据库暴露出了如下的缺点:

(1)关系数据库建立在一个严格的二维表上, 在列的维度上, 对于每个属性其长度和类型是事先定义并且很难扩展的; 在行的维度上, 每一条记录(行为record) 都不完全相同。

(2)关系数据库以二维表的方式管理数据, 数据以一条条记录的方式存储, 每一记录内部包括许多字段, 字段名不可重复, 对每一记录的每一字段具有惟一值, 字段中不支持子字段。关系数据库在数据类型上主要管理各种字符型、数值型数据, 虽然后来也提供了对于一些超长文本、图像、声音等多媒体以及面向对象的扩充, 但对这些数据类型的扩充仅仅停留在简单的存储与输出上, 对于数据的深层次的检索或其他需求必须通过特别的开发和处理, 必然对系统的效率产生负面影响。

(3)数据库最核心的技术之一就是数据的检索技术。对于任何一个数据库系统, 数据检索都是其核心内容和精髓所在, 而进行数据检索之前必须建立索引。只有建立了严密的索引, 才能使数据库强大的检索功能得以发挥。数据库索引方式的差异决定了数据库的检索方式及检索能力。现有关系数据库支持的索引

只限于单字段索引、复合索引(多字段索引) 等几种方式。对数据库的检索主要基于结构化查询语言(SQL) , 用户通过构造SQL查询表达式和设置各种查询条件, 实现对关系数据库的检索, 因为受到关系数据库的索引限制, 其数据查询能力也受到很大的限制。

(4)因特网的迅猛发展使数据库应用环境发生了巨大的变化。以因特网为平台的Internet/ Web应用向数据库领域提出了前所未有的挑战。电子商务、Web医院、远程教育、数字图书馆、移动计算等都需要新的数据库技术支持。由于关系数据库从一开始就没有考虑网络时代的应用需求, 因而对于网络环境下应用, 如各种非结构化文档信息、多媒体信息以及全文检索需求显得力不从心。虽然后来关系数据库对于这些需求作出了一些适应性调整, 但对于网络环境应用不可或缺的检索效率、全文检索能力等却无法解决。关系数据库从设计之初并没有也不可能考虑到以HTTP为基础HTML为文件格式的因特网的需求, 只是在因特网出现后才作出相应的调整, 因此关系数据库在基于因特网应用时, 由于结构模型等原因的限制, 不能与因特网完全融合, 需在Web服务器与数据库之间加入大量的中间件, 从而在无形中加大了数据库基于网络应用的难度, 给数据库的因特网应用带来了新的网络瓶颈, 应用服务器端由于与数据库频繁交互, 因其本身的效率和数据库检索的效率造成因特网应用在应用服务器端的阻塞。

四、最新的出现的数据库有哪些

在最近面对因特网的潮流大势,关系数据库模型已经不能满足人们的需求,所以一种新的数据库模型诞生,这就是非结构化数据库,

(1)非结构化数据库的二维表却不是严格的, 在列的维度上, 对于每个属性

是可以伸展的, 即属性的长度是可变的。

(2)在非结构化数据库中, 字段内容是可重复的, 这表现在两个方面: 一是一个字段支持重复字段, 即字段在列这个级别上是可重复的; 二是在同一个字段内部允许出现不同的子字段,即字段在行级别上, 内容是分层次的。总之, 对于一个字段, 可以在行、列方向上有多个值, 即非结构化数据库具有支持重复字段(多值) 、子字段(子项) 的能力。这种能力, 使得非结构化数据库可以在记录中实现二维嵌套, 避免由于关系(二维表) 连接导致的系统性能问题。

(3)非结构化数据库在数据类型上不仅可以支持字符型、数值型数据, 而且由于其强大的外部文件支持功能, 更可以支持任何文件类型, 如超长文本、图像、声音等扩展型数据类型, 同时, 非结构化数据库对于文本、RTF、超文本文档、DOC等具有检索意义的外部文件类型还能提供强大的索引和全文检索功能。由于有着灵活的数据结构, 非结构化数据库中支持的索引方式比关系数据库要丰富得多, 可以满足极其复杂检索的需要。其中字段索引兼容关系数据库的索引, 子字段索引和全文索引(英文单词索引和中文单汉字索引) 是非结构化数据库的特色, 非结构化数据库甚至可以支持人工标引索引, 中、英文混合索引等方式。配合非结构化数据库的格式化语言, 可以对同一字段进行若干种不同的索引, 以满足特殊检索的需求。数据库系统能够提供的检索方式, 是和其对数据库内容建立的索引密切相关的。高度灵活的索引方式造就了高度灵活的检索方式, 非结构化数据库对中文的全文检索效率比关系型数据库要高得多。例如, 国信贝斯软件有限公司开发的iBASE非结构化数据库目前支持8种索引方式, 可以涵盖所有的关系数据库所提供的90%以上的检索方式, 同时还提供了大量的关系数据库不具备的检索方式, 包括简单检索、组合检索、字段检索、右截断检索、全文检索、

扩展检索、相关检索(ANY词检索) 、集合检索、二次顺序检索、禁用词顺序检索等。iBASE非结构化数据库采用B3树的索引机制, 定位一条记录最多限于7次定位操作。

(4)利用非结构化数据库全部基于因特网的数据库结构模型, 采用网络服务器和数据库服务器紧密集成的方法, 可以将目前传统数据库厂商由C/ S结构扩展来的浏览器/Web服务器+应用服务器/数据库服务的三层体系结构,集成为浏览器/网上资源发布系统式的因特网计算结构,使数据库系统成为因特网的一个重要有机组成部分, 实现在单一平台上融合所有数据库和应用服务器的功能。这不仅大大减少了用户对额外硬件、中间件和其他昂贵的集成业务的需求, 而且极大地缩短了用户开发和采用基于因特网应用的时间。同时非结构化数据库还有效解决了关系型数据库在因特网应用上出现的检索效率低、全文检索能力差等弊端。从这个意义上来说, 非结构化数据库是真正的网络数据库。

(5)非结构化数据库处理的对象多为海量数据库, 不仅检索功能强而且检索速度快, 在检索速度方面一般不受文献量的影响。以iBASE非结构化数据库为例, 每个数据库最大记录数可达1 000万条, 每条记录的最大长度可达32000个汉字, 每个数据库最多可有800个字段, 每个字段的最大长度可达32000个汉字。

五、未来数据库的发展趋势是什么

对于未来的数据库,是关系数据库浴火重生,还是非结构化数据库一统江山,或者二者二分天下,到目前为止也是一个没有定论的事情,关系数据库面对传统数据的强大优势,和非结构化数据库对日新月异的新技术的集成性,二者在目前的数据库来说都不可缺少。

后关系时代数据库,面对信息的复杂性,处理的高效性,应用的灵活性这三个关系数据库的短板,在这里我查到了几种数据库的发展方向:

1、XML语言的出现,给数据库系统的发展开辟了新的天地,它包含下面四个重要的特性

XML语言的出现,给数据库系统的发展开辟了一片新的天地。XML的全称是“可扩展的标识语言”。XML有下列重要特性:

(1)、XML是一种表意而非表形的元语言。采用不同的显示页就可以做到同一数据源却有不同途径的显示结果。

(2)、XML是Internet的标准语言,因而具有跨操作平台、跨区域的特点。

(3)、由于XML能为机器所解读,使得“服务器对服务器”的应用成为可能。

(4)、XML是一种可自我描述定义的元语言,所以它可以大量用于制定行业内及行业间数据交换的标准。

其中代表就是IBM的新一代数据库DB29,它第一次实现了关系型引擎与层次型引擎的结合,实现了混合数据库。这种一方面在原有的系统基础上,增加对非结构化话数据的支持,实现系统无缝平稳的过渡,是用户最能接受的一种形式。

2、面对新的时代要求,有人提出了内容信息库的概念,从而却带传统的数据库,所谓“信息库”,其实就是利用一个统一的数学模型,对目前的数据库技术(DataBase)和企业内容管理系统(ecm)进行整合,从而在一个统一的平台上,有效地实现对结构化数据和非结构化数据的集中统一管理。

在IBM的访问中,认为信息库包含以下的内容

(1)、完善的系统架构

“信息库”技术需要考虑如何实现灵活高效的数据模型,如何实现完善的访问控制管理,以及如何支持大量数据的存储和上千的并发用户。

(2)、数据模型

数据模型的能力直接表现出一个平台适应用户需求的能力。丰富元数据的模型不是一蹴而就的,这就要求一个面向客户全部信息管理的通用数据模型,以适应客户不断变化的需求。

(3)、检索查询等功能的完备。对于“信息库”技术的最终用户来说,如何高效准确地找到自己所需要的资源是首要课题。

(4)、内容管理的API。完整的API支持是区别“信息库”技术和一般的内容管理应用软件的重要依据。

3、而最后一种理论在我看来是十分的大胆,他们提出的概念就是让数据库消失,面对网络时代的大流,云计算的蓬勃发展,大数据步步紧逼,Web时代数据技术将向哪个方向走呢?有一种看法是,它将向把数据本身、语义本身结构化的方向发展,不是在库这个容器中刻划出维度来处理数据,而是要对语言本身进行结构化处理,把维度内嵌到数据本身之中,这也是第三代互联网的神髓。

从研究的角度出发,Web上的信息确实就是一个数据库,一个更大、更复杂的数据库。Web上的每一个站点就是一个数据源,每个数据源都是异构的,这就构成一个巨大的异构数据库环境。

充分利用有用的数据,对尽可能多的数据进行有效的存储、管理、分析和挖掘,这本身就是数据库技术思想的基础。但是,用Web来取代数据库,可能在很多方面还不成熟,包括如进行数据的更新和维护,如何对数据进行保密,毕竟

不是每一个用户都愿意将自己的所有数据存放在网络上。

4、通过上面三种对数据库未来潮流的讨论,实际上也就表现出了数据库在如下四个方面的革新目标:

数据库技术发展和大多数领域发展一样,必将是应用驱动和技术驱动相结合。传统的关系数据库,由于其自身的局限性,在使用中受到了很多限制,在搜索、多媒体、企业内容管理、计算机辅助设计等方面,数据库技术几乎很少涉足,如能在以下4个方面完善数据库技术,数据库将获取更大市场。

方向1.实现非结构化数据管理

企业在信息化过程中需要处理大量报表、账单、影像、电子文档、图片、音频、视频等非机构化数据,这些数据难以用传统的关系型数据库管理。随着XML 技术的出现,数据库实现对非结构化数据的管理已经成为可能。

“如果谁能控制、支持和存储所有类型的数据,那么这样的厂商也就有能力扩展自己其他产品和服务的市场空间。因此整合XML、对象数据、多媒体数据,将所有数据类型放在一个平台上将是传统的关系数据库发展的一大趋势。”

不过,处理结构化数据的关系型数据库从理论到技术上经历了30多年发展,已经相当成熟,而非结构化数据的复杂程度远远高于结构化数据,所以非结构化数据的存储还存在很多有待解决的难题,比如,如何很好地解决多种异构数据源的存储和查询就是其中的关键问题。虽然有人认为将来XML数据库将能比较好地解决非结构化数据的管理问题,但将现有文档映射到XML文档的工作才刚刚开始,XML查询语言也远不如SQL成熟。

方向2.实现对Web数据的挖掘

近年来,随着Internet技术的快速普及和迅猛发展,使各种信息可以以非

常低的成本在网络上获得,由于Internet在全球互连互通,可以从中取得的数据量难以计算,而且Internet的发展趋势继续看好,特别是电子商务的蓬勃发展为网络应用提供了强大支持,如何在Internet这个全球最大的数据集合中发现有用信息无疑将成为数据挖掘研究的热点。

数据库技术应用于Web挖掘主要是为了解决Web信息的管理和查询问题。这些问题可以分为三类:Web信息的建模和查询;信息抽取与集成;Web站点建构和重构。

从数据库的观点进行Web内容挖掘主要是试图建立Web站点的数据模型并加以集成,以支持复杂查询,而不止是简单的基于关键词的搜索。这要通过找到Web文档的模式、建立Web数据仓库或Web知识库或虚拟数据库来实现。相关研究主要是基于半结构化数据进行的。

长期以来,由于在数据库观点下数据的表示方法比较特殊,其中包含了关系层次和图形化的数据,所以大部分建立在扁平数据集合之上的数据挖掘方法不能直接使用。目前已经有人针对多层数据库挖掘算法进行研究。

方向3.对智能搜索技术的支撑

搜索技术是现在互联网的热门应用,不过由于速度慢和并发性差等瓶颈限制,数据库和搜索技术长期以来都是“大路朝天,各走一边”。据陈华介绍,在目前的搜索技术中,出于速度等方面的考虑,搜索过程中很少有使用数据库工具的情况。不过随着搜索技术对智能化要求的提高,大量的匹配信息、描述语句出现在搜索过程中,数据库技术如何配合未来的智能搜索,也逐渐被大家关注。

现代网络系统中存在大量的有用数据,例如,每天有几千万个研究。然而,得到这些数据却非常困难。据了解,google目前正在尝试建立一个体系结构

能够支持新的关于海量Web数据的研究。为了支持新研究,Google以压缩的形式保存了实际所抓到的文档。Google的目标之一就是要建立一个环境使其他研究者能够很快进入这个领域,处理海量Web数据,在这样的情况下,无疑需要数据库技术来对这种系统进行有效的支持。

大型Web搜索引擎将是个非常复杂的系统,为了提高搜索效率,需要覆盖大约1亿个网页。我们必须有一个巧妙的算法来决定哪些旧网页需要重新抓取,哪些新网页需要被抓取。受需求驱动,用代理cache创建搜索数据库正在成为目前一个有前途的研究领域。

方向4.辅助软件工程及制造系统的应用

关系数据库技术是为传统的事务处理而开发的,如库存控制、工资、账目等。但是人们很少将关系数据库技术用于计算机辅助设计、辅助工程、辅助软件工程及辅助制造(CAD,CAE,CASE和CAM)系统及其应用。

传统的数据库系统所支持的事务模型不适合于交互式、协作设计环境下所必须的长事务(Long-duration)。传统的数据库系统也不提供表示和管理数据库的临时变化,包括如像模式的时间和版本变化以及变化的通报(notification)方面的一些工具。

其实,在计算机辅助设计过程中、制造过程中,会出现大量的结构信息数据,包括参数、图形、描述、表格、文档等。有效构建相应结构信息的数据库,对所有的结构信息、载荷信息和技术资料进行合理的存储,并对这些信息资料设计专用检索程序,可以极大的优化设计工作效果。

结束语:因为个人对数据库的知识浅薄,所以在文章中引用的大段的资料和论文,只有在最后总结的时候才表示出了自己的主要想法,在这篇论文当中,描述主要两种数据库模型,一种是关系数据库,作为传统数据库的代表,在现在已经开始显示出颓势,另一方面是在2000年左右提出的关系数据库的概念,在现在日新月异的发展。面对新技术的需求,甲骨文、微软、IBM、谷歌都拿出了自己的理论的数据库模型,但是关键点还是在于继续对传统的关系数据库进行修补,进一步加入模块,通过最新的XML语言、云计算让关系数据库重新散发生机,还是推倒重来,让非结构化数据库成为未来的主流,毕竟在与互联网的融合程度上,非关系数据库拥有不可或缺的优势,还是更加大胆一些,放弃数据库,让WEB技术取代数据库,但是这一方面目前阻力非常大。通过这篇论文的写作,我也对数据库有了一个更加清晰的认识,通过这篇论文,明白了以前很多感觉疑惑的事情,相信我通过以后的学习,一定可以写出一篇真正的属于自己数据库论文。

参考文献

[1]百度文库.《数据库未来技术发展方向》、《下一代数据库技术》、《数据

库数据模型的发展及方向》、《数据库最新技术》

[2]百度百科. 《关系数据库》、《数据库模型》.

[3]CSDN. 《云计算一周热文回顾:五大主流数据库模型》. 2012年3月

[4]google. 《解析全球级分布式数据库Google Spanner》. 2012年09月19日

[5]李慧颜显森. 《数据库技术发展的新方向》. 武汉大学信息管理学院硕士

论文. 2000年11月:287—288页

概念数据模型,逻辑数据模型,物理数据模型 (原创)

概念数据模型设计与逻辑数据模型设计、物理数据模型设计是数据库及数据仓库模型设计的三个主要步骤。 在数据仓库领域有一个概念叫conceptual data model,中文一般翻译为“概念数据模型”。 概念数据模型是最终用户对数据存储的看法,反映了最终用户综合性的信息需求,它以数据类的方式描述企业级的数据需求,数据类代表了在业务环境中自然聚集成的几个主要类别数据。 概念数据模型的内容包括重要的实体及实体之间的关系。在概念数据模型中不包括实体的属性,也不用定义实体的主键。这是概念数据模型和逻辑数据模型的主要区别。 概念数据模型的目标是统一业务概念,作为业务人员和技术人员之间沟通的桥梁,确定不同实体之间的最高层次的关系。 在有些数据模型的设计过程中,概念数据模型是和逻辑数据模型合在一起进行设计的。 在数据仓库领域有一个概念叫logical data model,中文一般翻译为“逻辑数据模型”。 逻辑数据模型反映的是系统分析设计人员对数据存储的观点,是对概念数据模型进一步的分解和细化。逻辑数据模型是根据业务规则确定的,关于业务对象、业务对象的数据项及业务对象之间关系的基本蓝图。 逻辑数据模型的内容包括所有的实体和关系,确定每个实体的属性,定义每个实体的主键,指定实体的外键,需要进行范式化处理。 逻辑数据模型的目标是尽可能详细的描述数据,但并不考虑数据在物理上如何来实现。 逻辑数据建模不仅会影响数据库设计的方向,还间接影响最终数据库的性能和管理。如果在实现逻辑数据模型时投入得足够多,那么在物理数据模型设计时就可以有许多可供选择的方法。 在数据仓库领域有一个概念叫physical data model,中文一般翻译为“物理数据模型”。 物理数据模型是在逻辑数据模型的基础上,考虑各种具体的技术实现因素,进行数据库体系结构设计,真正实现数据在数据库中的存放。 物理数据模型的内容包括确定所有的表和列,定义外键用于确定表之间的关系,基于用户的需求可能进行发范式化等内容。在物理实现上的考虑,可能会导致物理数据模型和逻辑数据模型有较大的不同。

数据仓库模型的设计.doc

2.5数据仓库模型的设计 数据仓库模型的设计大体上可以分为以下三个层面的设计151: .概念模型设计; .逻辑模型设计; .物理模型设计; 下面就从这三个层面分别介绍数据仓库模型的设计。 2.5.1概念模型设计 进行概念模型设计所要完成的工作是: <1>界定系统边界 <2>确定主要的主题域及其内容 概念模型设计的成果是,在原有的数据库的基础上建立了一个较为稳固的概念模型。因为数据仓库是对原有数据库系统中的数据进行集成和重组而形成的数据集合,所以数据仓库的概念模型设计,首先要对原有数据库系统加以分析理解,看在原有的数据库系统中“有什么”、“怎样组织的”和“如何分布的”等,然后再来考虑应当如何建立数据仓库系统的概念模型。一方面,通过原有的数据库的设计文档以及在数据字典中的数据库关系模式,可以对企业现有的数据库中的内容有一个完整而清晰的认识;另一方面,数据仓库的概念模型是面向企业全局建立的,它为集成来自各个面向应用的数据库的数据提供了统一的概念视图。 概念模型的设计是在较高的抽象层次上的设计,因此建立概念模型时不用考虑具体技术条件的限制。 1.界定系统的边界 数据仓库是面向决策分析的数据库,我们无法在数据仓库设计的最初就得到详细而明确的需求,但是一些基本的方向性的需求还是摆在了设计人员的面前: . 要做的决策类型有哪些?

. 决策者感兴趣的是什么问题? . 这些问题需要什么样的信息? . 要得到这些信息需要包含原有数据库系统的哪些部分的数据? 这样,我们可以划定一个当前的大致的系统边界,集中精力进行最需要的部分的开发。因而,从某种意义上讲,界定系统边界的工作也可以看作是数据仓库系统设计的需求分析,因为它将决策者的数据分析的需求用系统边界的定义形式反映出来。 2,确定主要的主题域 在这一步中,要确定系统所包含的主题域,然后对每个主题域的内容进行较明确数据仓库建模技术在电信行业中的应用的描述,描述的内容包括: . 主题域的公共码键; . 主题域之间的联系: . 充分代表主题的属性组。 2.5.2逻辑模型设计 逻辑建模是数据仓库实施中的重要一环,因为它能直接反映出业务部门的需求,同时对系统的物理实施有着重要的指导作用。在这一步里进行的工作主要有: . 分析主题域,确定当前要装载的主题; . 确定粒度层次划分; . 确定数据分割策略; . 关系模式定义; . 记录系统定义 逻辑模型设计的成果是,对每个当前要装载的主题的逻辑实现进行定义,并将相关内容记录在数据仓库的元数据中,包括: . 适当的粒度划分;

Oracle关系数据库的逻辑模型

关系数据库的逻辑模型 在关系数据库的设计阶段,需要为它建立逻辑模型。关系数据库的逻辑模型可以通过实体和关系组成的图来表示,这种图表称为“E-R 图”,使用E-R 图表示的逻辑模型被称为“ER 模型”。一个典型的ER 模型由如下三部分组成:实体、联系和属性。 1.实体和属性 客观存在并可相互区分的事物称为实体。实体可以指实际的对象,也可以指某些概念,例如,一个雇员、一个职位都是实体。在E-R 模型中,实体是用矩形表示,矩形框内写明实体名,以区分现实世界中其他对象。 每个实体有一组属性来表示,其中的某一部分属性可以惟一标识实例,如雇员编号。实体集是具有相同属性的实体集合,例如,学校所有教师具有相同的属性,因此教师的集合可以定义为一个实体集;而学生具有相同的属性,因此学生的集合可以定义为另一个实体集。 在数据库中,每个实体集都对应于一个表,实体集中的每个实体都是表中的一条记录,而实体的每个属性就是表中的一个字段。例如,企业中的雇员、职位和部门可以分别定义为三个实体集,这些实体集分别对应表EMPLOYEES 、JOBS 和DEPARTMENTS 。每个实体又具有它自己的属性,这些属性组成了表的字段。比如,雇员实体具有雇员编号、姓名、电话号码、职位、薪水、所属部门等属性。 2.联系 实际应用中的实体之间是存在联系的,这种联系必须在逻辑模型中表示出来。在E-R 模型中,联系用菱形表示,菱形框内写明联系名,并用无向边分别与有关实体连接起来,同时在无向边旁标注上联系的类型。两个实体之间的联系可以分为三类: ● 一对一 若对于某个实体集A 中的每一个实体,实体集B 中至多有一个实体与之 相关;反之亦然,则称实体集A 与实体集B 具有一对一的联系,记为1:1。 ● 一对多 若对于实体集A 中的每一个实体,实体集B 中有多个实体与之相关,反 过来,对于实体集B 中的每一个实体,实体集A 中至多有一个实体与之相关,则称实体集A 与实体集B 有一对多的联系,记为1:n 。 ● 多对多关系 若对于实体集A 中的每一个实体,实体集B 中有多个实体与之相关, 反过来,对于实体集B 中的每一个实体,实体集A 中也有多个实体与之相关,则称为实体集A 与实体集B 具有多对多的联系,记为m :n 。 例如,一个雇员只能属于一个部门,而一个部门可以同时对应于多个雇员,因此,雇员与部门之间具有一对多的联系,在E-R 模型中的表示如图1-1所示。 部门 职工从属 1 n 部门号部门名 部门负表人 职工编号姓名职位部门

概念数据模型,逻辑数据模型,物理数据模型

概念数据模型,逻辑数据模型,物理数据模型 概念数据模型设计与逻辑数据模型设计、物理数据模型设计是数据库及数据仓库模型设计的三个主要步骤。 在数据仓库领域有一个概念叫conceptual data model,中文一般翻译为“概念数据模型”。 概念数据模型是最终用户对数据存储的看法,反映了最终用户综合性的信息需求,它以数据类的方式描述企业级的数据需求,数据类代表了在业务环境中自然聚集成的几个主要类别数据。 概念数据模型的内容包括重要的实体及实体之间的关系。在概念数据模型中不包括实体的属性,也不用定义实体的主键。这是概念数据模型和逻辑数据模型的主要区别。 概念数据模型的目标是统一业务概念,作为业务人员和技术人员之间沟通的桥梁,确定不同实体之间的最高层次的关系。 在有些数据模型的设计过程中,概念数据模型是和逻辑数据模型合在一起进行设计的。 在数据仓库领域有一个概念叫logical data model,中文一般翻译为“逻辑数据模型”。 逻辑数据模型反映的是系统分析设计人员对数据存储的观点,是对概念数据模型进一步的分解和细化。逻辑数据模型是根据业务规则确定的,关于业务对象、业务对象的数据项及业务对象之间关系的基本蓝图。 逻辑数据模型的内容包括所有的实体和关系,确定每个实体的属性,定义每个实体的主键,指定实体的外键,需要进行范式化处理。 逻辑数据模型的目标是尽可能详细的描述数据,但并不考虑数据在物理上如何来实现。 逻辑数据建模不仅会影响数据库设计的方向,还间接影响最终数据库的性能和管理。如果在实现逻辑数据模型时投入得足够多,那么在物理数据模型设计时就可以有许多可供选择的方法。 在数据仓库领域有一个概念叫physical data model,中文一般翻译为“物理数据模型”。 物理数据模型是在逻辑数据模型的基础上,考虑各种具体的技术实现因素,进行数据库体系结构设计,真正实现数据在数据库中的存放。

概念模型、逻辑模型、物理模型区别(HZQ)

数据库设计 概念模型、逻辑模型、物理模型区别 侯在钱 目录 1.模型种类 (2) 1.1.概念模型 (2) 1.2.逻辑模型 (3) 1.3.物理模型 (3) 1.4.模型区别 (3) 1.4.1.对象转换 (4) 1.4.2.其它对比 (4) 2.常用工具 (5) 2.1.ERWIN (5) 2.1.1.逻辑模型 (5) 2.1.2.物理模型 (5) 2.1.3.常用操作 (6) 2.2.PowerDesigner (8) 2.2.1.概念模型 (8) 2.2.2.逻辑模型 (9) 2.2.3.物理模型 (9) 2.2.4.常用操作 (10)

1.模型种类 一般在建立数据库模型时,会涉及到几种模型种类:概念模型、逻辑模型、物理模型。数据库设计中概念模型和逻辑模型区别比较模糊,所以在数据库设计工具ERWIN中只提供了逻辑模型和物理模型,而在PowerDesigner早期版本中也只提供了概念模型和物理模型两种模型,只是在PowerDesigner15版本中提供了三种模型:概念模型、逻辑模型、物理模型。 1.1.概念模型 概念模型是对真实世界中问题域内的事物的描述,不是对软件设计的描述。 表示概念模型最常用的是"实体-关系"图。 E-R图主要是由实体、属性和关系三个要素构成的。在E-R图中,使用了下面几种基本的图形符号。 实体,矩形 E/R图三要素属性,椭圆形 关系,菱形

关系:一对一关系,一对多关系,多对多关系。 1.2.逻辑模型 逻辑数据模型反映的是系统分析设计人员对数据存储的观点,是对概念数据模型进一步的分解和细化。 1.3.物理模型 物理模型是对真实数据库的描述。数据库中的一些对象如下:表,视图,字段,数据类型、长度、主键、外键、索引、是否可为空,默认值。 概念模型到物理模型的转换即是把概念模型中的对象转换成物理模型的对象。 1.4.模型区别

数据库-逻辑结构设计

1、关系模型与ER模型:(一个关系就是一张二维表) 关系模式:→二维表 ER模型:→ER图 2、关系模型的基本概念: 教师(教师编号,A, B, 姓名,性别,所在系)--主表 课程(课程号,课程名,上课教师,教师编号)--从表 关系名:实体与实体间的联系 元组----记录---行(非空) 字段----数据项---列(属性) 键----关键字----标识属性(主键,外键,候选键) 主从关系:以该属性为主键的表就是主表,以该属性为外键的表就是从表。 3、将ER模型转换成二维表,以下面为例: ER模型: 实体: 教师(教师编号,姓名,性别,所在系) 课程(课程号,课程名,教师编号,上课教室) 学生(学号,姓名,年龄,班级) 联系: 讲授(教师编号,课程号) 选修(学号,课程号,成绩)

二维表: ①将实体转为关系表 (实体名--关系名,实体属性--关系属性,即列,实体键--关系键) ②将实体的联系转为关系表(关系模式) 1:1的联系--可以转为一个独立的关系模式,也可以与任一实体合并 1:n的联系--可以转为一个独立的关系模式,也可以与n端实体合并 m:n的联系--可以转为一个关系模式 3个或3个以上实体之间的多元化的联系--可以转为一个关系模式 相同的键的关系模式可以合并 4、关系规范化:(5个等级----5个范式-----1NF→5NF)Form ①规范化原因:消除不合适的数据依赖,即关系模式中会存在以下弊端: 数据重复(冗余) 数据不一致性 数据插入异常 数据删除异常…. ②范式规范化的判定条件: 1NF:实体中的属性不能再分解 实例: 学生1(学号,姓名,性别,出生日期,系部代码,入学时间,家庭成员)不属于1NF 更改后: 学生1(学号,姓名,性别,出生日期,系部代码,入学时间,家庭) 家庭(学号,家庭成员姓名,亲属关系) 2NF:实体中的非键属性完全依赖键属性 实例: 属于1NF,不属于2NF 分析: 系部代码----由学号决定,出生日期---由学号决定,成绩---由学号+课程号决定 更改后: 3NF:没有一个非键属性传递依赖于键(关键字→非关键字1....→非关键字n) 实例: 属于2NF 分析: 姓名,性别,出生日期,入学时间---由学号唯一决定 系部代码,系名,系宿舍楼----不是由学号唯一决定,相互递推出来不属于3NF (例如:系部代码----由学号或者系名或者系宿舍楼推出) 更改后:

实验 数据库概念模型和逻辑模型

实验建立数据库概念模型(CDM)和物理模型(PDM) 一、实验目的 1.了解用PowerDesigner工具建立简单的数据库概念模型CDM的方法和过程; 2.了解用PowerDesigner工具由CDM生成物理数据模型PDM的方法和过程。 二、实验内容 1.用PowerDesigner工具建立“出版公司信息系统”概念数据模型CDM; 2.用PowerDesigner工具将“出版公司信息系统”概念数据模型CDM生成物理数据模 型PDM。 三、实验要求 1.完成“出版公司信息系统”的概念数据模型CDM; 2.将“出版公司信息系统”的CDM转换成物理数据模型PDM; 3.按“Ctrl+Print Screen SysRq”,以屏幕打印的方式将完成实验所得到的图,以实验报告的形式提交。 案例背景 本实验以某“出版公司信息系统”为例。 在某“出版公司信息系统”中,相关的实体包括作品(Title)、作者(Author)、版税(Roysched)、出版社(Publisher)、发票(Invoice)、书店(Store)、折扣(Discount)。主要存在的业务问题包括不同的作者对于同样的作品有不同的版税,每个作品必须选定一个出版社来出版,不同的书店根据销售情况可以享受不同的折扣率。 “出版公司信息系统”的E-R图如图1-1所示,实体与实体之间的联系如表1-1所示(图中省略了属性)。 表1-1 “出版公司信息系统”实体与实体间的联系 表2-2 “出版公司信息系统”实体与实体之间的联系

图2-2 “出版公司信息系统”E-R 图图1-1 出版公司信息系统E-R 图 四、实验步骤 1. 进入CDM 建模界面 (1)启动PD ,进入CDM 界面。 单击工具栏中“文件(File )-新建模型(New Model )”,单击“模型类型(Model Types )”框中的“Conceptual Data Model (概念数据模型)”,并“确定(OK )”,即进入CDM 界面。 (2)定义CDM 模型。 单击“模型(Model)—模型属性(Model Properties )”,出现如图1-2所示的CDM 属性窗口,键入“出版公司信息系统”等属性,“确定(OK )”并保存模型,进入CDM 工作界面,CDM “Palette ”主要模型工具的用途如表1-2所示。 图1-2 概念数据模型CDM 的属性窗口

数据库逻辑结构图

数据库逻辑结构图 一、实体的关系模型 1)、管理员(用户名,密码) 2)、个人(帐号,密码,姓名,年龄,出生日期,电话号码)3)、备忘录(时间,地点,事件) 4)、通讯录(姓名,城市,备注,工作地点,联系方式) 5)、日记(日期,地点,人物,事情) 6)、财务(标志,消费项目,消费时间,消费金额,剩余金额,总收入) 其中有下划线的是主键。 二、关系模型合并 1)、管理员(用户名,密码) 2)、个人(帐号,密码,姓名,年龄,出生日期,电话号码)3)、备忘录(时间,地点,事件) 4)、通讯录(姓名,城市,备注,工作地点,联系方式) 5)、日记(日期,地点,人物,事情) 6)、财务(标志,消费项目,消费时间,消费金额,剩余金额,总收入) 三、关系模型的函数依赖关系 1)、用户名——>密码 2)、(帐号,密码)——>姓名,(帐号,密码)——>年龄,(帐号,密码)——>出生日期,(帐号,密码)——>电话号码

3)、时间——>地点,时间——>事件 4)、姓名——>城市,姓名——>备注,姓名——>工作地点,姓名——>联系方式; 5)、日期——>地点,日期——>人物,日期——>事情 6)、标志——>消费时间,消费时间——>消费项目,消费时间——>消费金额,标志——>总收入,标志——>剩余金额。 其中6不是第一范式其他都是第一范式,且6为第二范式. 四、优化 1)、管理员(用户名,密码) 2)、个人(帐号,密码,姓名,年龄,出生日期,电话号码)3)、备忘录(时间,地点,事件) 4)、通讯录(姓名,城市,备注,工作地点,联系方式)5)、日记(日期,地点,人物,事情) 6)、财务(标志,消费时间,剩余金额,总收入) 消费(消费时间,消费项目,消费金额)

数据库设计实例需求分析概念结构逻辑结构完整版

数据库设计实例需求分 析概念结构逻辑结构 HEN system office room 【HEN16H-HENS2AHENS8Q8-HENH1688】

数据库设计实例分析 一、需求分析实例 现要开发高校图书管理系统。经过可行性分析和初步的需求调查,确定了系统的功能边界,该系统应能完成下面的功能: (1)读者注册。 (2)读者借书。 (3)读者还书。 (4)图书查询。 1、数据流图 顶层数据流图反映了图书管理系统与外界的接口,但未表明数据的加工要求,需要进一步细化。根据前面图书管理系统功能边界的确定,再对图书管理系统顶层数据流图中的处理功能做进一步分解,可分解为读者注册、借书、还书和查询四个子功能,这样就得到了图书管理系统的第0层数据流图 从图书管理系统第0层数据流图中可以看出,在图书管理的不同业务中,借书、还书、查询这几个处理较为复杂,使用到不同的数据较多,因此有必要对其进行更深层次的分析,即构建这些处理的第1层数据流图。下面的图8-7分别给出了借书、还书、查询子功能的第1层数据流图 2、数据字典 数据项 数据项名称:借书证号 别名:卡号 含义说明:惟一标识一个借书证 类型:字符型 长度:20 …… 数据结构 (1)名称:读者类别 含义说明:定义了一个读者类别的有关信息 组成结构:类别代码+类别名称+可借阅数量+借阅天数+超期罚款额 (2)名称:读者 含义说明:定义了一个读者的有关信息 组成结构:姓名+性别+所在部门+读者类型 (3)名称:图书 含义说明:定义了一本图书的有关信息

组成结构:图书编号+图书名称+作者+出版社+价格 …… 数据流 (1)数据流名称:借书单 含义:读者借书时填写的单据 来源:读者 去向:审核借书 数据流量:250份/天 组成:借书证编号+借阅日期+图书编号 (2)数据流名称:还书单 含义:读者还书时填写的单据 来源:读者 去向:审核还书 数据流量:250份/天 组成:借书证编号+还书日期+图书编号 …… 数据存储 (1)数据存储名称:图书信息表 含义说明:存放图书有关信息 组成结构:图书+库存数量 说明:数量用来说明图书在仓库中的存放数 (2)数据存储名称:读者信息表 含义说明:存放读者的注册信息 组成结构:读者+卡号+卡状态+办卡日期 说明:卡状态是指借书证当前被锁定还是正常使用 (3)数据存储名称:借书记录 含义说明:存放读者的借书、还书信息 组成结构:卡号+书号+借书日期+还书日期 说明:要求能立即查询并修改 …… 处理过程 (1)处理过程名称:审核借书证 输入:借书证 输出:认定合格的借书证 加工逻辑:根据读者信息表和读者借书证,如果借书证在读者信息表中存在并且没有被锁定,那么借书证是有效的借书证,否则是无效的借书证。 …… 二、概念结构设计实例

数据库设计:逻辑结构设计

5.3逻辑结构设计 逻辑结构设计的任务就是把概念模型转换为某个具体的数据库管理系统所支持的数据模型。 具体来讲就是从E-R模型到关系模型的转换。 (1)根据E-R模型设计关系模式; (2)选择适当的范式对所得到的关系模式进行规范化; (3)将得到的关系模型转换为具体DBMS支持的数据模型,设计关系数据库模式。 (4)依据关系的完整性约束来设计用户视图。 1、关系模型 关系模型是指用二维表的形式表示实体和实体间联系的数据模型。关系模型中无论是实体还是实体间的联系均由单一的结构类型——关系来表示。在实际的关系数据库中的关系也称表。一个关系数据库就是由若干个表组成。 关系模型数据结构 (1)关系 一个关系也就是通常所说的一张表。 关系具有以下特征: 1.关系中不能有任意两条完全相同的记录。 2.关系中的记录是非排序的。 3.关系中记录的字段是非排序的。 4.字段名称不能相同。 5.字段不可再分。 (2)元组 每一横行称为一个元组。 (3)属性 属性:每一竖列称为一个属性,在DBMS中常被称作字段。在一个关系中,有

一个关系名,同时每个属性都有一个字段名 (4)码(键) 能唯一标识元组的属性或属性集称为码。码分为以下几种: 候选码:如果在关系的一个码中不能移去任何一个属性,否则它就不是这个关系的键,则称这个被指定的候选键为该关系的候选键或者候选码。 例如下列学生表中“学号”或“图书证号”都能唯一标识一个元组,则“学号”和“图书证号”都能唯一地标识一个元组,则“学号”和“图书证号”都可作为学生关系的候选键。 主键(主码):在一个关系的若干候选键中指定一个用来唯一标识该关系的元组,则称这个被指定的候选码称为主关键字,或简称为主键、关键字、主码。每一个关系都有并且只有一主键,通常用较小的属性组合作为主键。 外键(外码):关系中的某个属性虽然不是这个关系的主键,或者只是主键的一部分,但它却是另外一个关系的主键时,则称之为外键或者外码。 例如学生表,选定“学号”作为数据操作的依据,则“学号”为主键。而在选课表中,主键为(学号,课程号),外码为“学号”。 (5)关系模式 关系模式是对关系的描述,关系是关系模式的一个实例关系模式包括关系名、各属性名,通常简记为: R(A1,A2,…,An) 其中R为关系名,A1,A2,…,An为各属性名。 例如:学生(学号*,姓名,性别,出生日期,院系) 其中标“*”号的属性为主键 (6)关系完整性约束

数据库逻辑结构设计

数据库逻辑结构设计 该系列计划包括5部分:完整性约束理论及应用、范式理论及应用、需求分析、概念结构设计、逻辑结构设计。本文是第五部分,介绍逻辑结构设计的内容,包括E-R图向关系模型的转换、数据模型的优化、用户子模式的设计等问题。1.逻辑设计概述 概念结构是独立于任何一种数据模型的,在实际应用中,一般所用的数据库环境已经给定(如SQL Server或Oracel或MySql),本文讨论从概念结构向逻辑结构的转换问题。 由于目前使用的数据库基本上都是关系数据库,因此首先需要将E-R图转换为关系模型,然后根据具体DBMS的特点和限制转换为特定的DBMS支持下的数据模型,最后进行优化。 2.E-R图向关系模型的转换 2.1 一个例子 E-R图如何转换为关系模型呢?我们先看一个例子。 图2.1是学生和班级的E-R图,学生与班级构成多对一的联系。根据实际应用,我们可以做出这个简单例子的关系模式: 学生(学号,姓名,班级) 班级(编号,名称) “学生.班级”为外键,参照“班级.编号”取值。 这个例子我们是凭经验转换的,那么里面有什么规律呢?在2.2节,我们将这些经验总结成一些规则,以供转换使用。 2.2 转换规则 (1) 一个实体型转换为一个关系模式 一般E-R图中的一个实体转换为一个关系模式,实体的属性就是关系的属性,实体的码就是关系的码。

(2) 一个1:1联系可以转换为一个独立的关系模式,也可以与任意一端对应 的关系模式合并。 图2.2是一个一对一联系的例子。根据规则(2),有三种转换方式。 联系单独作为一个关系模式 此时联系本身的属性,以及与该联系相连的实体的码均作为关系的属性,可以选择与该联系相连的任一实体的码属性作为该关系的码。结果如下: 职工(工号,姓名) 产品(产品号,产品名) 负责(工号,产品号) 其中“负责”这个关系的码可以是工号,也可以是产品号。 )与职工端合并 职工(工号,姓名,产品号) 产品(产品号,产品名) 其中“职工.产品号”为外码。 i)与产品端合并 职工(工号,姓名) 产品(产品号,产品名,负责人工号) 其中“产品.负责人工号”为外码。 (3) 一个1:n联系可以转换为一个独立的关系模式,也可以与n端对应的关 系模式合并。

数据库逻辑结构设计

数据库逻辑结构设计 该系列计划包括5部分:完整性约束理论及应用、范式理论及应用、需求分析、概念结构设计、逻辑结构设计。本文就是第五部分,介绍逻辑结构设计的内容,包括E-R图向关系模型的转换、数据模型的优化、用户子模式的设计等问题。1.逻辑设计概述 概念结构就是独立于任何一种数据模型的,在实际应用中,一般所用的数据库环境已经给定(如SQL Server或Oracel或MySql),本文讨论从概念结构向逻辑结构的转换问题。 由于目前使用的数据库基本上都就是关系数据库,因此首先需要将E-R图转换为关系模型,然后根据具体DBMS的特点与限制转换为特定的DBMS支持下的数据模型,最后进行优化。 2.E-R图向关系模型的转换 2、1 一个例子 E-R图如何转换为关系模型呢?我们先瞧一个例子。 图2、1就是学生与班级的E-R图,学生与班级构成多对一的联系。根据实际应用,我们可以做出这个简单例子的关系模式: 学生(学号,姓名,班级) 班级(编号,名称) “学生、班级”为外键,参照“班级、编号”取值。 这个例子我们就是凭经验转换的,那么里面有什么规律呢?在2、2节,我们将这些经验总结成一些规则,以供转换使用。 2、2 转换规则 (1) 一个实体型转换为一个关系模式 一般E-R图中的一个实体转换为一个关系模式,实体的属性就就是关系的属性,实体的码就就是关系的码。

(2) 一个1:1联系可以转换为一个独立的关系模式,也可以与任意一端对应 的关系模式合并。 图2、2就是一个一对一联系的例子。根据规则(2),有三种转换方式。 联系单独作为一个关系模式 此时联系本身的属性,以及与该联系相连的实体的码均作为关系的属性,可以选择与该联系相连的任一实体的码属性作为该关系的码。结果如下: 职工(工号,姓名) 产品(产品号,产品名) 负责(工号,产品号) 其中“负责”这个关系的码可以就是工号,也可以就是产品号。 )与职工端合并 职工(工号,姓名,产品号) 产品(产品号,产品名) 其中“职工、产品号”为外码。 i)与产品端合并 职工(工号,姓名) 产品(产品号,产品名,负责人工号) 其中“产品、负责人工号”为外码。 (3) 一个1:n联系可以转换为一个独立的关系模式,也可以与n端对应的关 系模式合并。

数据库系统原理04735课后习题参考答案

数据库系统原理课后习题 第一章. 数据库系统基本概念 1.1.名词解释 DB——DB是长期存储在计算机内、有组织的、统一管理的相关数据的集合。DB能为各种用户共享,具有较小冗余度、数据间联系紧密而又有较高的数据独立性等特点。 DBMS——是位于用户与操作系统之间的一层数据管理软件,它为用户或应用程序提供访问DB的方法,包括DB的建立、查询、更新及各种数据控制。 DBS——是实现有组织地、动态地存储大量关联数据、方便多用户访问的计算机硬件、软件和数据资源组成的系统,即它是采用数据库技术的计算机系统。 联系——是实体间的相互关系。 联系的元数——与一个联系有关的实体集个数。 1:1联系——如果实体集E1中每个实体至多和实体集E2中一个实体有联系,反之亦然,那么实体集E1和E2的联系称为“一对一联系”,记为“1:1”。 1:N联系——如果实体集E1中的每个实体可以与实体集E2中的任意个(0个或多个)实体有联系,而E2中的每个实体至多和E1中的一个实体有联系,那么称E1对E2的联系是一对多联系,记作:“1:N ”。 M:N联系——如果实体集E1中的每个实体可以与实体集E2中的任意个(0个或多个)实体有联系,反之亦然,那么称E1和E2的联系是“多对多联系”,记作“M:N”。 数据模型——在数据库技术中,我们用数据模型的概念描述数据库的结构和语义,对现实世界的数据进行抽象。根据数据抽象级别定义了四种模型:概念数据模型、逻辑数据模型、外部数据模型和内部数据模型。 概念模型——表达用户需求观点的数据全局逻辑结构的模型。 逻辑模型——表达计算机实现观点的DB全局逻辑结构的模型。主要有层次、网状、关系模型等三种。 外部模型——表达用户使用观点的DB局部逻辑结构的模型。 内部模型——表达DB物理结构的模型。 层次模型——用树型(层次)结构表示实体类型及实体间联系的数据模型。 网状模型——用有向图结构表示实体类型及实体间联系的数据模型。 关系模型——是由若干个关系模式组成的集合。关系模式相当于记录类型,它的实例是关系,每个关系实际上是一张二维表格。 外模式——用户与数据库系统的接口,是用户用到的那部分数据的描述。外模式由若干个外部记录类型组成。逻辑模式——是数据库中全部数据的整体逻辑结构的描述。它由若干个逻辑记录类型组成,还包含记录间联系、数据的完整性、安全性等要求。 内模式——是数据库在物理存储方面的描述,定义所有内部记录类型、索引和文件的组织形式,以及数据控制方面的细节。 外模式/逻辑模式映像——存在于外模式和逻辑模式之间,用于定义外模式和逻辑模式之间的对应性,一般放在外模式中描述。 逻辑模式/内模式映像——存在于逻辑模式和内模式之间,用于定义逻辑模式和内模式之间的对应性,一般放在内模式中描述。 数据独立性——是指应用程序和数据库的数据结构之间相互独立,不受影响。在修改数据结构时,尽可能不修改应用程序。分物理数据独立性和逻辑数据独立性两个级别。 物理数据独立性——对内模式修改时,对逻辑模式/内模式像作相应修改,可以尽量不影响逻辑模式。 逻辑数据独立性——逻辑模式修改时,对外模式/逻辑模式映像作相应修改,可以使外模式和应用程序保持不变。主语言——在数据库技术中,用于编写应用程序的高级程序设计语言。 DDL——数据定义语言。DBMS提供DDL定义数据库的三级结构、两级映像,定义数据的完整性约束、保密限制等约束。 DML——数据操纵语言。DBMS提供DML实现对数据的操作。基本的数据操作有两类:检索(查询)、更新(插入、删除、修改)。分为过程性DML和非过程DML两种。 过程性DML——是指用户编程时,不仅需要指出“做什么”(需要什么样的数据),还需要指出“怎么做”(怎

数据库设计详细过程,逻辑模型,物理模型

第四章数据库设计 4.1 原理 数据库设计是指对于一个给定的应用环境,构造最优的数据库模式,建立数据库及其应用系统,使之能够有效地存储数据。 数据库设计是一个软件项目成功的基石,但很多从业人员都认为,数据库设计其实不那么重要,现实中的情景也相当雷同,开发人员的数量是数据库设计人员的数倍。因为多数人使用数据库中的一部分,所以也会把数据库设计想的如此简单,其实不然,数据库设计是值得深入研究的,因为其完全决定了系统的优化程度。 完整的数据库设计一般包如下部分: 1.需求分析; 2.概念结构设计; 3.逻辑结构设计; 4.物理结构设计; 5.验证阶段; 6.运行与维护。 在讲解数据库设计之前,先大概的说说数据库系统设计的原则,其实,关于数据库设计的原则,版本居多,不同的人根据不同的场景不同的需求不同的系统去描述,可定会出现不一致,但万变不离其宗,所有数据库设计的原则无例外是为了实现数据库的最优,从这个宗旨出发我们自己探讨出了以下几条关系数据库设计的原则: 1.明白自己的系统为OLTP系统还是OLAP系统 不同的系统其侧重点是不一样的,OLTP系统最注重的是数据增删改查操作的效率,而OLAP系统注重的是分析处理,所以不同的系统数据库设计也不一样; 2.降低对数据库功能的依赖 功能的实现,一般要求通过程序来实现,而不是大量的依赖数据库。 3.严格遵从数据库三范式 严格遵从数据库三范式,避免数据的冗余等问题产生; 4.尽量保证记录的唯一标识存在; 5.严格遵循概念模型到逻辑模型的转换规则; 6.星型模型、雪花模型的合理运用。 4.1.1 概念结构设计 早期的数据库设计,在需求分析阶段后,就直接进行逻辑结构设计,由于此时既要考虑现实世界信息的联系与特征,又要满足特定的数据库系统的约束要求,因而对于客观世界的描述受到一定的限制,同时,由于设计时要同时考虑多方面的问题,也使设计工作变得十分复杂。1976年P.P.S.Chen提出在逻辑结构设计之前先设计一个概念模型,并提出了数据库设计的实体--联系方法

相关主题
相关文档 最新文档