Tekla截面库lis文件生成器

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

概念数据模型设计与逻辑数据模型设计、物理数据模型设计是数据库及数据仓库模型设计的三个主要步骤。 在数据仓库领域有一个概念叫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 （例如：系部代码----由学号或者系名或者系宿舍楼推出） 更改后：

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

数据库设计实例需求分 析概念结构逻辑结构 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端对应的关 系模式合并。

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

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