搜档网
当前位置:搜档网 › 数据库设计详细过程,逻辑模型,物理模型

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

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

第四章数据库设计

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提出在逻辑结构设计之前先设计一个概念模型,并提出了数据库设计的实体--联系方法

(Entity--Relationship Approach)。这种方法不包括深的理论,但提供了一个简便、有效的方法,目前成为数据库设计中通用的工具。有许多商业软件支持E-R模型,如PowerDesigner、ERwin。

概念模型E-R图主要是便于和需求人员进行交流沟通,它形式简单明了,可以简单清晰的描述需求中的各种概念及他们之间的关系.

使用E-R模型来进行概念模型的设计通常分两步进行,首先是建立局部概念模型,然后综合局部概念模型,成为全局概念模型。

E-R图设计

E-R图分为局部E-R图和全局E-R图。

E-R模型基本符号:

实体的表示:用长方形;

联系的表示:用菱形,如1:1、1:n (m:1)、(m:n);

属性的表示:用椭圆形。

确定实体与属性的原则:

1.能作为属性的尽量作为属性而不要划为实体;

2.作为属性的数据元素与实体之间的联系只能是1:n的联系;

3.作为属性的数据项不能再用其他属性加以描述,也不能与其他实体或属性发生联系。

例如某公司员工信息的E-R图:

4.1.2 逻辑结构设计

所谓逻辑结构设计就是将基本E-R图转换为与选用DBMS产品所支持的数据模型相符合的逻辑结构的过程。

逻辑结构设计的过程分为以下几点:

1.将概念结构转换为现有DBMS支持的关系、网状或层次模型中的某一种数据模型;

2.从功能和性能要求上对转换的模型进行评价,看它是否满足用户要求;

3.对数据模型进行优化。

逻辑结构设计的原则:

1.一个实体型转换为一个关系模型,实体的属性就是关系的属性,实体的键

就是关系的键;

2.一个联系转换为一个关系模式,与该联系相连的每个实体型的键以及联系的属性都转换为关系的属性。

关于逻辑结构设计时实体之间的关系,有四种情况,分别做一说明(注:图片来自网络):

1.若联系为1:1,则相连的每个实体型的键均是该关系模式的侯选键。如图:

2.若联系为1:n,则联系对应的关系模式的键取n端实体型的键:

3.若联系为m:n,则联系对应的联模式的键为参加联系的诸实体型的键的组合,如图:

4.若实体与实体之间存在依赖关系,那么联系就是代表了两个实体之间的联系,如图:

4.1.3 物理结构设计

根据特定数据库管理系统所提供的多种存储结构和存取方法等,依赖于具体计算机结构的各项物理设计措施,对具体的应用任务选定最合适的物理存储结构(包括文件类型、索引结构和数据的存放次序与位逻辑等)、存取方法和存取路径等。这一步设计的结果就是所谓“物理数据库”。

4.2 ERwin应用说明

Erwin的全称是AllFusion ERwin Data Modeler,是CA公司 AllFusion品牌下的建模套件之一,用于数据库建模。是关系数据库应用开发的优秀工具。ERwin可以方便地构造实体和联系,表达实体间的各种约束关系,并根据模板创建相应的存储过程、包、触发器、角色等,还可编写相应的PB扩展属性,如编

辑样式、显示风格、有效性验证规则等,同时可以实现将已建好的ER模型到数据库物理设计的转换,即可在多种数据库服务器(如Oracle,Sql Server,mysql 等)上自动生成库结构,提高了数据库的开发效率。

4.2.1实体

Erwin中的实体有两种:独立实体和依赖实体。实体被指定作为独立实体,或依赖实体,取决于其键的获得方式。

独立实体由方角盒来指定,独立实体不依赖于模型中任何其它实体来标识;依赖实体被指定为圆角盒,依赖实体依存于模型中的其它实体,如图:

4.2.2 实体间的关系

实体间的三种关系:

1.标识关系(identifying relationship);

2.多对多关系(many- to- many relationship);

3.非标识关系(non-identifying relationship )。

标识关系是指把实体1中的主键作为实体2中的外键,且作为实体2的主键,如图:

非标识关系是指把实体1中的主键作为实体2中的外键,但不作为实体2

的主键,如图:

4.2.3 Erwin建模

Erwin可以设计三种模型:logical model、physical model、logical/physical model。如果只做文档,可以选择只建立logical model,如果是做项目,需要同时使用logical model和physical model,physical model 是用于生成或者导出脚本的。

1.建立新的数据模型

点击File/New弹出建模窗口如下,可根据具体情况做出相应选择(选的目标数据库最好有驱动):

2.建立各个实体

方法一:点击实体图标,如图:

方法二:右击左边窗口中的entities,然后单击new也可以新建一个实体,

如图:

3.修改实体名称

方法一:单击实体名,按F2键可以对实体名称进行修改;

方法二:右键单击欲进行修改的实体,选择Entity Properties;

方法三:双击实体修改。

4.列的增删:

方法一:右键单击所选实体,选择Attributes,在弹出的Attributes窗口中添加,删除或修改属性;

方法二:单击所选实体,按 tab键也可以进行添加,删除或修改操作。

5.创建约束、存储、触发器

主键:

右击所选实体,然后单击key groups,然后选择实体的主键,如图:

索引:

右击所选实体,选择Indexes…,如图:

存储过程:

单击实体右键Stored Procedures…,如图:

单击New键,在New Stored Procedure界面的Name输入存储过程名,按OK键,在Code处输入代码,按OK键。如图:

触发器:

单击实体右键Triggers…,如图:

6.使用format preferences

如何将图1自动调整成图2效果?

图一

图二

选择Format,单击preferences,如图:

单击Layout Entire Diagram键选择是,如图:

4.2.4正向、反向工程

正向工程

通过正向工程能够快速方便生成DDL数据库定义语言。

选择Tools菜单,单击Forward Engineer,如图:

可以做相应的配置后单击preview,如图:

生成DDL数据库定义语言,保存成后缀为.ers的文件,如图:

反向工程

通过反向工程能把DDL转换成ERwin数据模型。

选择Tools菜单,单击Reverse Engineer...见图:

单击Next,选择Script file,单击Browse..,选择.ers文件,单击Next,如图:

4.2.5导入数据库

将视图切换到physical模型下,连接数据库:单击database\database connection,弹出下面窗口,进行数据库的连接。

链接完成后单击tools\forward engineer\schema generate,将弹出下面的窗口,单击generate,即可将物理模型导入数据库。

4.3 PowerDesigner应用说明

Power Designer 是Sybase公司的CASE工具集,使用它可以方便地对管理信息系统进行分析设计,几乎包括了数据库模型设计的全过程。利用Power Designer可以制作数据流程图、概念数据模型、物理数据模型,还可以为数据仓库制作结构模型,也能对团队设计模型进行控制。他可以与许多流行的数据库设计软件,例如PowerBuilder,Delphi,VB等相配合使缩短开发时间和使系统设计更优化。

power designer是能进行数据库设计的强大的软件,是一款开发人员常用的数据库建模工具。使用它可以分别从概念数据模型(Conceptual Data Model)和物理数据模型(Physical Data Model)两个层次对数据库进行设计。在这里,概念数据模型描述的是独立于数据库管理系统(DBMS)的实体定义和实体关系定义;物理数据模型是在概念数据模型的基础上针对目标数据库管理系统的具体化。

4.3.1配置数据库连接

1.打开powerdesigner,依次点击:database--connect,如图:

2.点击connect,打开对话窗口:

3.然后点击Configuer按钮,弹出数据源配置Configuer Data Connections 对话框:

4.把页签切换到第三个Connetion Profiles页签中,如果连接存在,选中就行,如果不存在,点击add Data Source数据库图标进行新增,弹出Connection Profile Definition对话框如下图;

此对话框中需要输入以下信息

Connection profile name: 输入数据库连接文件名,它会自动加上后缀名.dcp;

Directory:数据库连接文件存放路径;可以任意;

Connetction type: 选择JDBC;

DBMS type : 数据库类型选择Oracle;

Server name: 服务器名称;也相当于对应PL/SQL登陆页面的数据库;

Database name: 数据库名字;

User name: 登陆数据库名字;

Password: 密码

JDBC Driver class: 驱动类;只要下拉框选择就行;

JDBC Driver Jar URL: 访问的服务器路径

JDBC connection files: 驱动包;需要指向ojdbc14.jar或者其他驱动的包的按钮路径;

全部设置如下图:

5.点击Test Connection 按钮进行连接测试;

测试连接是否成功;成功会弹出成功或者失败消息框,测试成功后。点击确定按钮,返回数据源配置Configuer Data Connections对话框,列表中就会多出一个.dcp文件,点击确定即可。

4.3.2导出数据库表

导出数据库表方法如下:

1.启动PowerDesigner

2.菜单:File->Reverse Engineer ->Database 出来New Physical Data Model对话框,DBMS选择ORACLE Version 10g 选项,其他可以选择默认值:

点击“确定”按钮,弹出Database Reverse Engineering Options对话框:

3.然后在下拉框中选择我们之前建立的数据源文件,并再次输入数据库User ID和password:

点击Connection即可连接至数据库,并得取所有的数据库对象,在此我们选择所有的Table。

最后点击OK,大功告成!

4.3.3导入表到数据库

1.用Power Designer创建实例的时候,切记所有的表名、字段、对象名称全部为大写,要不导入数据库会报错,如图:

2.如果Power Designer没有连接数据库,先连接,方法前面已有讲解,如果已经连接了数据库,点击Database,在下拉框中点击Generate Database,如图:

3.点击确定按钮,进入下一页,如图:

4.点击RUN按钮,运行完即可,如图:

数据仓库模型的设计

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

高校图书管理系统数据库物理结构设计

高校图书管理系统数据库物理结构设计 一、设计前要了解的信息(该部分不出现在设计说明书中) 1、数据库的查询事务 (1)按卡号查询读者信息及借书信息(查询读者借书信息时涉及读者、图书与借还关系的连接操作,连接属性:卡号、书号)。 (2)按姓名查询读者信息及借书信息(查询读者借书信息时涉及读者、图书与借还关系的连接操作,连接属性:卡号、书号)。 (3)按书名查询图书信息。 (4)按作者与出版社查询图书信息。 (5)按出版社统计图书信息。 (6)按书号查询图书被借信息(查询图书被借信息时涉及读者、图书与借还关系的连接操作,连接属性:卡号、书号)。 (7)按书名查询图书被借信息(查询图书被借信息时涉及读者、图书与借还关系的连接操作,连接属性:卡号、书号)。 2、数据库的更新事务 (1)办理借书证(读者注册)。 (2)借书(增加借还记录、修改图书的库存数量)。 (3)还书(修改借还记录、修改图书的库存数量)。 3、查询事务的操作频率与性能要求 (1)按卡号查询读者信息及借书信息 操作频率:200次/天 性能要求:3s内完成 (2)按姓名查询读者信息及借书信息 操作频率:80次/天 性能要求:5s内完成 (3)按书名查询图书信息 操作频率:250次/天 性能要求:3s内完成 (4)按作者与出版社查询图书信息 操作频率:250次/天 性能要求:3s内完成 (5)按出版社统计图书信息 操作频率:1次/月 性能要求:10s内完成 (6)按书号查询图书被借信息 操作频率:10次/月

性能要求:6s内完成 (7)按书名查询图书被借信息 操作频率:10次/月 性能要求:6s内完成 二、设计结果 1、数据库名称 Book_Borrow 2、关系表 主键:lbdm 主键:kh 索引:xm(升序) check约束:性别的取值只能为男或女 default约束:性别默认为男

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

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

用PowerDesigner进行数据库物理模型设计

网上书店系统的数据库设计 需求分析名词(实体)动词(关系)用户能购买图书用户、图书购买 用户能评论图书用户、图书评论 能指定图书的类别图书、图书类别隶属 能指定用户的组用户、用户组隶属 用户组、功能权限 能指定用户组能使用 的功能 能指定购买项所属的 购买项、订单隶属 订单 3 Sept. 2008

3 Sept. 2008图书用户 用户组图书类别功能购买评论权限 隶属隶属

一、安装PowerDesigner建模软件 powerDesigner软件是Sysbase公司开发的,用于数据建模的软件。用它可对数据库进行建模。 二、用PowerDesigner为数据库建立概念模型(E-R模型) 三、用PowerDesigner为数据库建立物理模型 3 Sept. 2008

四、创建数据库 ①用powerDesigner创建数据库脚本 ②在企业管理器中创建数据库bookshop ③用数据库脚本创建bookshop库中的表 3 Sept. 2008

五、设计数据库总结 用powerDesigner设计数据库的步骤 步骤一:根据项目的需求分析设计数据库的E-R模型 项目的需求分析→ E-R模型 ?找出需求分析中的名词,这些名词是E-R模型中的实 体和实体中的属性→在E-R图中画实体和添加属性 ?找出需求分析中实体名词间的动词,这些动词是E-R 模型中实体间的关系→在E-R图中添加实体间的关系 3 Sept. 2008

用powerDesigner设计数据库的步骤 步骤二:根据已设计好的数据库的E-R模型生成对应的特定数据库的物理模型:E-R模型→物理模型 ?用tools->check model菜单项检查E-R模型的正确性, 如果有错误和警告应改正 ?用tools->Generate physical Data Model菜单项生成此 E-R模型的物理模型 3 Sept. 2008

数据仓库的数据模型

业务驱动 任何需求均来源于业务,业务决定了需求,需求分析的正确与否是关系到项目成败的关键所在,从任何角度都可以说项目是由业务驱动的所以数据仓库项目也是由业务所驱动的. 但是数据仓库不同于日常的信息系统开发,除了遵循其他系统开发的需求,分析,设计,测试等通常的软件声明周期之外;他还涉及到企业信息数据的集成,大容量数据的阶段处理和分层存储,数据仓库的模式选择等等,因此数据仓库的物理模型异常重要,这也是关系到数据仓库项目成败的关键. 数据仓库的结构总的来说是采用了三级数据模型的方式: 概念模型: 也就是业务模型,由企业决策者,商务领域知识专家和IT专家共同企业级地跨领域业务系统需求分析的结果. 逻辑模型:用来构建数据仓库的数据库逻辑模型。根据分析系统的实际需求决策构建数据库逻辑关系模型,定义数据库物体结构及其关系。他关联着数据仓库的逻辑模型和物理模型这两头. 物理模型:构建数据仓库的物理分布模型,主要包含数据仓库的软硬件配置,资源情况以及数据仓库模式。 如上图所示,在数据仓库项目中,物理模型设计和业务模型设计象两个轮子一样有力的支撑着数据仓库的实施,两者并行不悖,缺一不可.实际上,我有意的扩大了物理模型和业务模型的内涵和外延.在这里物理模型不仅仅是数据的存储,而且也包含了数据仓库项目实施的方法论,资源,以及软硬件选型等等;而业务模型不仅仅是主题模型的确立,也包含了企业的发展战略,行业模本等等. 一个优秀的项目必定会兼顾业务需求和行业的标准两个方面,业务需求即包括用户提出的实际需求,也要客观分析它隐含的更深层次的需求,但是往往用户的需求是不明确的,需要加以提炼甚至在商务知识专家引导下加以引导升华,和用户一起进行需求分析工作;不能满足用户的需求,项目也就失去原本的意义了. 物理模型就像大厦的基础架构,就是通用的业界标准,无论是一座摩天大厦也好,还是茅草房也好,在架构师的眼里,他只是一所建筑,地基->层层建筑->封顶,这样的工序一样也不能少,关系到住户的安全,房屋的建筑质量也必须得以保证,唯一的区别是建筑的材料,地基是采用钢筋水泥还是石头,墙壁采用木质还是钢筋水泥或是砖头;当然材料和建筑细节还是会有区别的,视用户给出的成本而定;还有不可忽视的一点是,数据仓库的数据从几百GB到几十TB不等,即使支撑这些数据的RDBMS无论有多么强大,仍不可避免的要考虑到数据库的物理设计. 接下来,将详细阐述数据仓库概念模型(业务模型),逻辑模型,物理模型的意义. 概念模型设计 进行概念模型设计所要完成的工作是: 界定系统边界 确定主要的主题域及其内容

oracle物理设计原则

数据库物理设计原则 1.1 数据库环境配置原则 1.1.1 操作系统环境: 对于中小型数据库系统,采用linux操作系统比较合适,对于数据库冗余要求负载均衡能力要求较高的系统,可以采用Oracle9i RAC的集群数据库的方法,集群节点数范围在2—64个。对于大型数据库系统,可以采用Sun Solaris SPARC 64位小型机系统或HP 9000 系列小型机系统。RAD5 适合只读操作的数据库,RAD1 适合OLTP数据库 1.1.2 内存要求 对于linux操作系统下的数据库,由于在正常情况下Oracle对SGA的管理能力不超过1.7G。所以总的物理内存在4G以下。SGA的大小为物理内存的50%—75%。对于64位的小型系统,Oracle数据库对SGA的管理超过2G的限制,SGA设计在一个合适的范围内:物理内存的50%—70%,当SGA过大的时候会导致内存分页,影响系统性能。 1.1.3 交换区设计 当物理内存在2G以下的情况下,交换分区swap为物理内存的3倍,当物理内存>2G的情况下,swap大小为物理内存的1—2倍。 1.1.4 其他环境变量参考Oracle相关的安装文档和随机文档。 1.2 数据库设计原则 1.2.1 数据库SID 数据库SID是唯一标志数据库的符号,命名长度不能超过5个字符。对于单节点数据库,以字符开头的5个长度以内字串作为SID的命名。对于集群数据库,当命名SID后,各节点SID自动命名为SIDnn,其中n n为节点号:1,2,…,64。例如rac1、rac2、rac24。 1.2.2 数据库全局名 数据库全局名称: 1.2.3 数据库类型选择

power designer物理数据模型

实验七 PowerDesigner物理数据模型 一、背景知识 1.物理数据模型概念 在设计好数据库的逻辑结构之后,就需要完成其物理设计。物理数据模型(physical data model,PDM)就是以数据库管理系统(DBMS)理论为基础,根据概念模型建立的现实世界模型生成相应的数据库管理系统的SQL脚本语言。利用该SQL脚本在数据库中产生实现世界信息的存储结构(如表、约束等),并保证数据在数据库中的完整性和一致性。图3-1描述了物理数据模型与数据库管理系统的关系。 图3-1 PDM与DBMS的关系 PDM以PowerDesigner为各种数据库提供的数据定义文件作为与语法模板来生成SQL语言脚本。由PDM生成SQL脚本,在通过SQL脚本在数据库中建立相应的数据存储结构,称为正向工程;反之,如果通过数据库中已存在的数据存储结构来导出对应的PDM,则称为逆向工程。 二、实验目的 1.了解和熟悉PowerDesignerPDM及其相关知识。 2.掌握运用PowerDesignerPDM工具建立PDM的方法。 3.掌握对PowerDesignerPDM进行管理的内容和方法。 三、实验内容与步骤 创建物理数据模型过程 用户可以通过四种方式新建PDM: 1.使用设计环境直接建立PDM 2.从现有数据库或数据库SQL脚本逆向工程建立PDM 3.从CMD采用内部模型生成的方法建立PDM 4.根据面向对象模型(OOM)中的类图,采用逆向的内部生成方法建立PDM 在前面的实验中,我们已经了解了利用CDM生成PDM地方法,这样的方法符合常规,即先进行概要设计然后进行详细设计。在本实验中,我们主要练习使用PowerDesigner设计环境直接建立PDM的方法。 1.创建 PDM

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

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

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 部门号部门名 部门负表人 职工编号姓名职位部门

数据库设计示例文档(完整)物理数据库设计

数据库设计示例文档(完整)物理数据库设计D2小组网上培训系统物理数据库设计 陈俊华、董磊、陈俊娜、董昊、海霞、郭云龙 1(针对选定的DBMS,生成基表 由于本系统主要架构在windows操作系统之上,加之本小组成员对SQLServer 比较熟悉,且系统有并发操作的要求,因此决定采用SQLServer2000 DBMS系统。 2(选择合适的文件组织(Heap, Hash, ISAM, B+ Tree, Clustered) 基于在System’s Specification中对系统性能的要求: 1)非峰值时,数据查找、更新、存储的平均时间低于1秒 2)在峰值时,数据查找、更新、存储的平均时间低于5秒 采用SQL Server 2000默认的文件组织结构 3(选择建立适当的索引 基于在System’s Specification中对事务处理的分析: 1)学生情况检索每天50次 2)教师情况检索每天10次 3)课程检索每天100次 4)常见问题检索每天200次 5)资料查询每天200次 6)试题检索每天50次 7)成绩查询每天50次 在SQL Server 2000里,在数据库关系图中为表定义一个主键将自动创建主键索引;由于要频繁查询学生姓名、教师姓名、课程名称、题目、成绩,因此在各表的对应列上创建第二索引。

4(定义全局约束 根据需求分析,本网上培训系统不允许同一名学生在一个学期中选课超过6 门以上。 5(定义视图 用户视图主要是学生视图和教师视图。 6(定义用户访问控制规则 用户在进入系统之前必须提交相应的用户名和口令,系统将根据不同的用户而授予不同的权限。 以下是建表语句: 1)学生表 create table student( StudentID Int(15) not null identity(1,1), StudentName Varchar(20) not null, StudentPassword Varchar(10) not null, StudentStatus Char(1) not null, StudentSex Char(1) not null, EnrollingDate Datetime not null, E-mail Varchar(30), Constraint pk_student primary key clustered(StudentID) ) 索引: create index student_StudentName on student(StudentName) 2)教师表 create table teacher (

概念模型、逻辑模型、物理模型区别(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. 概念数据模型(Conceptual Model):这是面向数据库用户的实现世界的数据模型,主要用来描述世界的概念化结构,它使数据库的设计人员在设计的初始阶段,摆脱计算机系统及DBMS的具体技术问题,集中精力分析数据以及数据之间的联系等,与具体的DBMS无关。概念数据模型必须换成逻辑数据模型,才能在DBMS中实现。 2. 逻辑数据模型(Logical Data Model):这是用户从数据库看到的数据模型,是具体的DBMS 所支持的数据模型,如网状数据模型、层次数据模型等等。此模型既要面向用户,又要面向系统。 3. 物理数据模型(Physical Data Model):这是描述数据在存储介质上的组织结构的数据模型它不但与具体的DBMS有关,而且还和操作系统以及硬件有关。每一种逻辑数据模型在实现时都有其对应的物理数据模型。DBMS为了保证其独立性与可移植性,大部分物理数据模型的实现工作由系统自动完成,而设计者只设计索引、聚集等特殊结构。 数据模型的三要素: 一般而言,数据模型是一组严格定义的概念的集合。这些概念精确地描述了系统的静态特征(数据结构)、动态特征(数据操作)和完整性约束条件,这就是数据模型的三要素。 1. 数据结构 数据结构是所研究的对象类型的集合。这些对象是数据库的组成部分,数据结构指对象和对象间联系的表达和实现,是系统静态特征的描述,包括两个方面: (1)数据本身:类型、内容、性质。例如关系模型中的域、属性、关系等。 (2)数据之间的联系:数据之间是如何相互联系的,例如关系模型中的主码、外码等联系。 2. 数据操作 对数据库中对象的实例允许执行的操作集合,主要指检索和更新(插入、删除、修改)两类操作。数据模型必须定义这些操作的确切含义、操作符号、操作规则(如优先级)以及实现操作的语言。数据操作是对系统动态特征的描述。 3. 完整性约束条件 数据完整性约束是一组完整性规则的集合,规定数据库状态及状态变化所应满足的条件,以保证数据的正确性、有效性和相容性。

数据库物理设计

数据库物理设计 数据库环境 对于制造企业,一般可选用linux,Windows或Unix等操作系统。具体选择哪个操作系统可根据现有的服务器情况做调整。成熟的企业级数据仓库一般选择常见的关系型数据库,同时根据特殊要求,可增加集群数据库、内存关系数据库或本地文件型数据库等。数据存储可采用RAID5、RAID1、RAID5+RAID1的方式。内存配置通常在8G以上,来减少磁盘读取时间。 数据库参数设计 数据库类型:由于数据库目标位企业级数据仓库,数据库类型通常选择data warehouse类型。 连接方式:同时连接类型选择专用方式连接,来满足数据装载时的大量批处理服务。 内存配置:根据服务器实际物理内存的大小,选择70%-80%的内存作为数据库内存大小。 字符集:为了使数据库能够正确支持多国语言,需要将数据库字符集配置为UTF字符集。 其他参数:聚合内存使用,连接数、数据块大小、缓冲区设置等都需要根据实际数据量,使用方式来进行设置。 数据库存储设计 控制文件:控制文件中包含数据库重要信息,需要将控制文件存放在多个磁盘中,来保证数据库可恢复性。控制文

件中参数设置,最大的数据文件数量不能小于数据库参数db_files。 日志文件:数据仓库通常为批处理装载,在装载时会产生大量日志。可选择关闭某些事实表日志,对通常的维表及高频率装载的数据表,可以选择打开日志功能。日志文件的大小由数据库事务处理量决定,在设计过程中,确保每20分钟切换一个日志文件。对于数据仓库系统,日志文件大小通常为几百兆到几千兆。为了确保日志能够镜象作用,每日志组的成员为2个,日志文件组为5—10组。 回滚段配置:Undospace = UR * UPS * db_block_size + 冗余量。UR:表示在undo中保持的最长时间数(秒),由数据库参数UNDO_RETENTION值决定。UPS:表示在undo中,每秒产生的数据库块数量。 临时段表空间配置:数据库临时段表空间根据实际生产环境情况调整其大小,表空间属性为自动扩展。 系统表空间配置:系统表空间大小1G左右,除了存放数据库数据字典的数据外,其他数据不得存储在系统表空间。 表空间大小定义:当表空间大小小于操作系统对最大文件限制时,表空间由一个文件组成。如果表空间大小大于操作系统对最大文件限制时,该表空间由多个数据文件组成,表空间的总大小为估算为:Tablespace + sum (数据段+索引段)*150%。 表空间扩展性设计原则:表空间数据文件采用自动扩展的方式,扩展容量快大小按2的整数倍(1M、2M、4M、8M、16M、32M、64M)进行扩展,创建表空间时尽量采用nologing选项。表空间的最大限制一般采用unlimited,除非确切知道表空间数据文件的最大使用范围。(一般32

数据库物理设计

物理结构设计 数据库物理设计阶段的任务是根据具体计算机系统(DBMS和硬件等)的特点,为给定的数据库模型确定合理的存储结构和存取方法。所谓的“合理”主要有两个含义:一个是要使设计出的物理数据库占用较少的存储空间,另一个对数据库的操作具有尽可能高的速度。 为了设计数据库的物理结构,设计人员必须充分了解所用DBMS的内部特征;充分了解数据系统的实际应用环境,特别是数据应用处理的频率和响应时间的要求;充分了解外存储设备的特性。数据库的物理结构设计大致包括:确定数据的存取方法、确定数据的存储结构。 物理结构设计阶段实现的是数据库系统的内模式,它的质量直接决定了整个系统的性能。因此在确定数据库的存储结构和存取方法之前,对数据库系统所支持的事务要进行仔细分析,获得优化数据库物理设计的参数。 对于数据库查询事务,需要得到如下信息: l 要查询的关系。 l 查询条件(即选择条件)所涉及的属性。 l 连接条件所涉及的属性。 l 查询的投影属性。 对于数据更新事务,需要得到如下信息: l 要更新的关系。 l 每个关系上的更新操作的类型。 l 删除和修改操作所涉及的属性。 l 修改操作要更改的属性值。 上述这些信息是确定关系存取方法的依据。除此之外,还需要知道每个事务在各关系上运行的频率,某些事务可能具有严格的性能要求。例如,某个事务必须在20秒内结束。这种时间约束对于存取方法的选择有重大的影响。需要了解每个事务的时间约束。 值得注意的是,在进行数据库物理结构设计时,通常并不知道所有的事务,上述信息可能不完全。所以,以后可能需要修改根据上述信息设计的物理结构,以适应新事务的要求。 1. 确定关系模型的存取方法 确定数据库的存取方法,就是确定建立哪些存储路径以实现快速存取数据库中的数据。现行的DBMS一般都提供了多种存取方法,如索引法、HASH法等。其中,最常用的是索引法。

物理数据模型

物理数据模型(PDM) 本篇较简单,请读者先阅读上一篇(概念数据模型 (CDM).doc) 物理数据模型与数据库中建立表很像,最终可以生成数据库脚本 工具栏 1.表(Table) 2.存储过程(procedure) 3.视图(view) 4.关联(reference) 5.依赖(dependency) 创建项目工程 1.新建工程,选择“File->New Model”,弹出如图所示的 对话框,选择Model types,在Model name中输入名称,单击“OK”按钮建立模型、如图所示

创建实体 1,在右侧的“图标窗口”中,单击工具箱上的“Entity”工具,在单击窗口的空白处,在单击的位置就数显了一个实体符号。单击“Pointer”工具或单击鼠标右键,可以释放Entity工具,如图

. 2. 双击刚创建的实体集符号,弹出“实体属性”对话框,选择“General”属性页,在“Name”文本框中输入“users”、“Comment”中输入“用户实体”,如图 添加属性

1.在上述对话框中选择Attributes属性页。单击最左边的一个按钮“Insert a Row”,添加新的属性。修改Name 为userid,DataType为Integer,并把P、M上个复选框都打钩(P列表示该属性是否为主标识符,主标识符类似于数据库中的主键; M列表示改属性是否为强制的,打钩表示不能为空) 2,同理为“userlevel”实体添加如下属性,如图所示

定义属性的标准检查约束 1.在左侧的对象浏览器窗口中,选择“username”节点,

数据仓库建模方法

每个行业有自己的模型,但是不同行业的数据模型,在数据建模的方法上,却都有着共通的基本特点。什么是数据模型 数据模型是抽象描述现实世界的一种工具和方法,是通过抽象的实体及实体之间联系的形式,来表示现实世界中事务的相互关系的一种映射。 在这里,数据模型表现的抽象的是实体和实体之间的关系,通过对实体和实体之间关系的定义和描述,来表达实际的业务中具体的业务关系。 数据仓库模型是数据模型中针对特定的数据仓库应用系统的一种特定的数据模型,一般的来说, 我们数据仓库模型分为几下几个层次。 图 2. 数据仓库模型 通过上面的图形,我们能够很容易的看出在整个数据仓库得建模过程中,我们需要经历一般四个过程: ?业务建模,生成业务模型,主要解决业务层面的分解和程序化。 ?领域建模,生成领域模型,主要是对业务模型进行抽象处理,生成领域概念模型。 ?逻辑建模,生成逻辑模型,主要是将领域模型的概念实体以及实体之间的关系进行数据库层次的逻辑化。 ?物理建模,生成物理模型,主要解决,逻辑模型针对不同关系型数据库的物理化以及性能等一些具体的技术问题。 因此,在整个数据仓库的模型的设计和架构中,既涉及到业务知识,也涉及到了具体的技术,我们既需要了解丰富的行业经验, 同时,也需要一定的信息技术来帮助我们实现我们的数据模型,最重要的是,我们还需要一个非常适用的方法论,来指导我们自己针对我们的业务进行抽象,处理,生成各个阶段的模型。 为什么需要数据模型 在数据仓库的建设中,我们一再强调需要数据模型,那么数据模型究竟为什么这么重要呢?首先我们需要了解整个数据仓库的建设的发展史。 数据仓库的发展大致经历了这样的三个过程: ?简单报表阶段:这个阶段,系统的主要目标是解决一些日常的工作中业务人员需要的报表,

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

实验建立数据库概念模型(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 的属性窗口

数据库的物理结构设计

2.6 数据库物理结构设计 ?数据库在物理设备上的存储结构与存取方法称为数 据库的物理结构,它依赖于给定的计算机系统。 ?为一个给定的逻辑数据模型选取一个最适合应用环 境的物理结构的过程,就是数据库的物理设计。 ?充分了解应用环境,详细分析要运行的事务,以获得选择物理数据库设计所需参数 ?充分了解所用RDBMS的内部特征,特别是系统提供的存取方法和存储结构

?关系数据库物理设计的内容 –为关系模式选择存取方法(建立存取路径) –设计关系、索引等数据库文件的物理存储结构 ?物理数据库设计所需参数 -数据库查询事务(查询的关系,查询条件所涉及的属性,连接条件所涉及的属性,查询的投影属性)-数据更新事务(被更新的关系,每个关系上的更新操作条件所涉及的属性,修改操作要改变的属性值)-每个事务在各关系上运行的频率和性能要求

其他需考虑的问题: 目标DBMS支持的特性、功能和选项; 主机计算机系统的特性和能力; 磁盘存储配置; 数据量。

数据库物理设计步骤: 1.数据库逻辑模式调整 2.文件组织与存取设计 3.数据分布设计 4.安全模式设计 5.确定系统配置 6.物理模式评估

1数据库逻辑模式调整 将与平台无关的描述数据库逻辑结构的关系模式及其视图转换为所选定的具体DBMS平台可支持的基本表和视图,并利用DBMS提供的完整性机制设计定义在基本表上的面向应用的业务规则。 (1) 实现目标数据库基本表和视图 遵循目标数据库的语法规则或变通 (2)设计基本表业务规则 利用目标DBMS提供的Check、断言、触发器等完成完整性约束

2文件组织与存取设计 (1)分析事务的数据访问特性 ?使用事务/表交叉引用矩阵,分析系统內重要事务对各基表的访问情况,确定事务访问哪些基本表,对哪些基本表执行了何种操作,并进一步分析各操作涉及到的基本属性表。 将所有事务路径映射到表中; 确定哪些表最常被事务访问; 分析选出的包含了这些表的事务。

数据库设计报告

软件数据库设计报告文档模板 1. 引言 (2) 1.1编写目的 (2) 1.2项目来源 (2) 1.3文档约定 (2) 1.4预期读者和阅读建议 (2) 1.5参考资料 (2) 2. 数据库命名规则 (3) 3. 数据库设计说明 (3) 3.1数据库逻辑设计 (3) 3.2数据库物理设计 (3) 3.3数据库分布 (3) 3.4基表设计 (4) 3.5视图设计 (5) 3.6索引设计 (6) 3.7完整性约束 (7) 3.8授权设计 (7) 3.9触发器设计 (8) 3.10存储过程设计 (8) 3.11数据复制设计 (9) 4. 词汇表 (10) 5. 历史数据处理 (10)

引言 引言是对这份数据库设计说明书的概览,是为了帮助阅读者了解这份文档是如何编写的,并且应该如何阅读、理解和解释这份文档。 1.1 编写目的 说明这份数据库设计说明书是为哪份软件产品编写的,开发这个软件产品意义、作用以及最终要达到的意图。通过这份数据库设计说明书详尽准确地描述了该软件产品的数据库结构。如果这份数据库设计说明书只与整个系统的某一部分有关系,那么只定义数据库设计说明书中说明的那个部分或子系统。 1.2 项目来源 具体说明本软件开发项目的全部风险承担者,以及各自在本阶段所需要承担的主要风险,首要风险承担者包括: ●任务提出者; ●软件开发者; ●产品使用者。 1.3 文档约定 描述编写文档时所采用的各种排版约定。排版约定应该包括: ●命名方法; ●提示方式; ●通配符号: ●等等。 1.4 预期读者和阅读建议 列举本数据库设计说明书所针对的各种不同的预期读者,例如,可能包括: ●开发人员; ●项目经理; ●测试人员; ●文档编写人员。 并且描述了文档中,其余部分的内容及其组织结构,并且针对每一类读者提出最适合的文档阅读建议。 1.5 参考资料 列举编写需求规格说明书时所用到的参考文献及资料,可能包括; ●本项目的合同书; ●上级机关有关本项目的批文;

数据仓库多维数据模型的设计说明

1、数据仓库基本概念 1.1、主题(Subject) 主题就是指我们所要分析的具体方面。例如:某年某月某地区某机型某款App的安装情况。主题有两个元素:一是各个分析角度(维度),如时间位置;二是要分析的具体量度,该量度一般通过数值体现,如App安装量。 1.2、维(Dimension) 维是用于从不同角度描述事物特征的,一般维都会有多层(Level:级别),每个Level 都会包含一些共有的或特有的属性(Attribute),可以用下图来展示下维的结构和组成:以时间维为例,时间维一般会包含年、季、月、日这几个Level,每个Level一般都会有ID、NAME、DESCRIPTION这几个公共属性,这几个公共属性不仅适用于时间维,也同样表现在其它各种不同类型的维。 1.3、分层(Hierarchy) OLAP需要基于有层级的自上而下的钻取,或者自下而上地聚合。所以我们一般会在维的基础上再次进行分层,维、分层、层级的关系如下图:

每一级之间可能是附属关系(如市属于省、省属于国家),也可能是顺序关系(如天周年),如下图所示: 1.4、量度 量度就是我们要分析的具体的技术指标,诸如年销售额之类。它们一般为数值型数据。我们或者将该数据汇总,或者将该数据取次数、独立次数或取最大最小值等,这样的数据称为量度。 1.5、粒度 数据的细分层度,例如按天分按小时分。 1.6、事实表和维表 事实表是用来记录分析的内容的全量信息的,包含了每个事件的具体要素,以及具体发

生的事情。事实表中存储数字型ID以及度量信息。 维表则是对事实表中事件的要素的描述信息,就是你观察该事务的角度,是从哪个角度去观察这个内容的。 事实表和维表通过ID相关联,如图所示: 1.7、星形/雪花形/事实星座 这三者就是数据仓库多维数据模型建模的模式 上图所示就是一个标准的星形模型。 雪花形就是在维度下面又细分出维度,这样切分是为了使表结构更加规范化。雪花模式可以减少冗余,但是减少的那点空间和事实表的容量相比实在是微不足道,而且多个表联结操作会降低性能,所以一般不用雪花模式设计数据仓库。 事实星座模式就是星形模式的集合,包含星形模式,也就包含多个事实表。

数据库逻辑结构图

数据库逻辑结构图 一、实体的关系模型 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)、财务(标志,消费时间,剩余金额,总收入) 消费(消费时间,消费项目,消费金额)

相关主题