数据库逻辑结构设计图，设有数据结构dr试画出逻辑结构图
来源：整理 编辑：黑码技术 2024-08-11 22:59:36
本文目录一览
1，设有数据结构dr试画出逻辑结构图
2，什么是数据结构的逻辑结构图呀
数据库的逻辑结构设计就是把概念结构设计阶段设计好的基本 E 一 R 图转换为与选用的 DBMS产品所支持的数据模型相符合的逻辑结构。逻辑结构是独立于任何一种数据模型的，在实际应用中，一般所用的数据库环境已经给定（如SQL Server或Oracle或MySql)。由于目前使用的数据库基本上都是关系数据库，因此首先需要将E-R图转换为关系模型，然后根据具体DBMS的特点和限制转换为特定的DBMS支持下的数据模型，进行优化。
3，怎么使用 powerdesigner 生成 表结构图
画物理结构设计图，根据物理结构设计图生成逻辑结构图，再根据逻辑结构图导出数据库（sql脚本）。有个菜单，反向工程 可以将数据库的表结构视图，触发器等都自动生成到powerdesigner
4，数据库的逻辑结构设计的ER图
E-R图的组件有很多，但概括起来说，可分为以下四种：线段：用于将实体、关系相连接对于双矩形、双菱形、双椭圆、双线段等等一些组件，可以不用去管，通常用以上四种组件就可以表达清楚实体及实体间的关系。从E-R图向关系模式转化 数据库的逻辑设计主要是将概念模型转换成一般的关系模式，也就是将E-R图中的实体、实体的属性和实体之间的联系转化为关系模式。在转化过程中会遇到如下问题：(1)命名问题。命名问题可以采用原名，也可以另行命名，避免重名。(2)非原子属性问题。非原子属性问题可将其进行纵向和横行展开。(3)联系转换问题。联系可用关系表示。 1、标识实体：通常有用户、角色这两个实体。2、标识关系：用户与角色间为多对多的互相拥有关系。3、标识实体、关系的属性:不仅仅是实体有属性，关系同样也有属性，这些属性在实体间建立关系时才会存在。有时属性太多，无法在图上一一列出，可以用表格，在后面的步骤中这个表格同样会用到，如下： 实体 属性 描述 … 用户 性别年龄电话… 男/女多大了联系方式… … 4、确定属性域：属性域就是属性的取值范围。这时，可以用表格将属性的数据类型、数据长度、取值范围及是否可为空、简单/复合、单值/多值、是否为派生属性等域信息定义出来。这个过程，事实上包含了逻辑结构设计中的数据类型、NULL、CHECK、DEFAULT等信息。 实体 属性 描述 数据类型及长度 是否可为空 用户 性别年龄电话… 男/女多大了联系方式… 1字节的短整形或布尔型1字节的短整形20字节的字符型或长整形… NONOYES 5、确定键：键就是可用于标识实体的属性，有：主键、唯一键、外键。 实体 属性 描述 键 用户 用户编号性别年龄电话… 男/女多大了联系方式… 主键 6、实体的特化/泛化：也就是面向对象模型中父类和子类的概念，这是个可选的步骤。举个例子，用户中大部分人都是普通员工，但有一小部分是从事销售的，销售人员有个负责区域的属性，如果将这个属性放在用户实体中，如右图：这时我们会发现，除了销售人员外，其他非销售人员这个属性全都不存在，这就是特化的过程。可以另建一个销售人员的实体来泛化用户实体，如右图：这样就完成了对用户实体的泛化，泛化的过程也就是抽出实体间公共属性的过程，但通常，除非特化的部分太多，才会考虑将一个实体抽象成两个1对1关系的实体，所有这个步骤是可选的。7、检查模型：（1）检查冗余首先检查实体：1对1关系的实体中有没有非外键的重复属性，或者就是同一个实体；其次检查关系：有没有通过其他关系也可以得到的重复属性；当然有时，需要考虑时间维度，因为有些属性是有时效性的，也就是虽然是同一个属性，但不同的时间表示的却是不同的内容，这一点在后面的逻辑结构设计中会提到，这并不是真正的冗余。（2）检查业务检查当前的E-R模型是否满足当前业务的场景。可以从某个实体开始，沿着当前E-R模型的各个节点去模拟业务场景。尤其需要和《需求规格说明书》去做校验。到这里，也就完成了E-R模型建立的全过程，有时，对于比较复杂的E-R模型，一张图可能显得太过局促，可以建立全局、局部E-R模型图，以便于查看和分析。
5，数据库原理与应用的一道ER图以及关系模式设计题 跪求啦
数据库设计通常分为6个阶段1（需求分析：分析用户的需求，包括数据、功能和性能需求；2概念结构设计：主要采用E-R模型进行设计，包括画E-R图；3逻辑结构设计：通过将E-R图转换成表，实现从E-R模型到关系模型的转换；4数据库物理设计：主要是为所设计的数据库选择合适的存储结构和存取路径；5数据库的实施：包括编程、测试和试运行；6数据库运行与维护：系统的运行与数据库的日常维护。）,主要讨论其中的第3个阶段,即逻辑设计。通过一个实际的案例说明在逻辑设计中E-R图向关系模式的转换。
6，数据库的逻辑结构设计的图向关系
模型的转换 E-R图如何转换为关系模型呢？我们先看一个例子。图2.1是学生和班级的E-R图，学生与班级构成多对一的联系。根据实际应用，我们可以做出这个简单例子的关系模式：学生（学号，姓名，班级）班级（编号，名称）“学生.班级”为外键，参照“班级.编号”取值。这个例子我们是凭经验转换的，那么里面有什么规律呢？在2.2节，我们将这些经验总结成一些规则，以供转换使用。 (1)一个实体型转换为一个关系模式一般E-R图中的一个实体转换为一个关系模式，实体的属性就是关系的属性，实体的码就是关系的码。(2)一个1:1联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并。图2.2是一个一对一联系的例子。根据规则（2），有三种转换方式。(i) 联系单独作为一个关系模式此时联系本身的属性，以及与该联系相连的实体的码均作为关系的属性，可以选择与该联系相连的任一实体的码属性作为该关系的码。结果如下：职工（工号，姓名）产品（产品号，产品名）负责（工号，产品号）其中“负责”这个关系的码可以是工号，也可以是产品号。(ii) 与职工端合并职工（工号，姓名，产品号）产品（产品号，产品名）其中“职工.产品号”为外码。(iii) 与产品端合并职工（工号，姓名）产品（产品号，产品名，负责人工号）其中“产品.负责人工号”为外码。(3)一个1:n联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并。(i) 若单独作为一个关系模式此时该单独的关系模式的属性包括其自身的属性，以及与该联系相连的实体的码。该关系的码为n端实体的主属性。顾客（顾客号，姓名）订单（订单号，……）订货（顾客号，订单号）(ii) 与n端合并顾客（顾客号，姓名）订单（订单号，……，顾客号）(4)一个m:n联系可以转换为一个独立的关系模式。该关系的属性包括联系自身的属性，以及与联系相连的实体的属性。各实体的码组成关系码或关系码的一部分。教师（教师号，姓名）学生（学号，姓名）教授（教师号，学号）(5)一个多元联系可以转换为一个独立的关系模式。与该多元联系相连的各实体的码，以及联系本身的属性均转换为关系的属性，各实体的码组成关系的码或关系码的一部分。(6)具有相同码的关系模式可以合并。(7)有些1：n的联系，将属性合并到n端后，该属性也作为主码的一部分这类问题多出现在聚集类的联系中，且部分实体的码只能在某一个整体中作为码，而在全部整体中不能作为码的情况下才出现（其它情况本人还没碰到，呵呵，欢迎指教）。比如上篇文章介绍的管理信息系统中订单与订单细节的联系。关于什么是聚集，2.3节介绍。 这部分本应在概念设计中介绍的，用到了才想起来，这里补充一下。关于现实世界的抽象，一般分为三类：（1） 分类：即对象值与型之间的联系，可以用“is member of”判定。如张英、王平都是学生，他们与“学生”之间构成分类关系。（2） 聚集：定义某一类型的组成成分，是“is part of”的联系。如学生与学号、姓名等属性的联系。（3） 概括：定义类型间的一种子集联系，是“is subset of”的联系。如研究生和本科生都是学生，而且都是集合，因此它们之间是概括的联系。例：猫和动物之间是概括的联系，《Tom and Jerry》中那只名叫Tom的猫与猫之间是分类的联系，Tom的毛色和Tom之间是聚集的联系。订单细节和订单之间，订单细节肯定不是一个订单，因此不是概括或分类。订单细节是订单的一部分，因此是聚集。 有了关系模型，可以进一步优化，方法为：（1） 确定数据依赖。（2） 对数据依赖进行极小化处理，消除冗余联系（参看范式理论）。（3） 确定范式级别，根据应用环境，对某些模式进行合并或分解。以上工作理论性比较强，主要目的是设计一个数据冗余尽量少的关系模式。下面这步则是考虑效率问题了：（4） 对关系模式进行必要的分解。如果一个关系模式的属性特别多，就应该考虑是否可以对这个关系进行垂直分解。如果有些属性是经常访问的，而有些属性是很少访问的，则应该把它们分解为两个关系模式。如果一个关系的数据量特别大，就应该考 虑是否可以进行水平分解。如一个论坛中，如果设计时把会员发的主贴和跟贴设计为一个关系，则在帖子量非常大的情况下，这一步就应该考虑把它们分开了。因为 显示的主贴是经常查询的，而跟贴则是在打开某个主贴的情况下才查询。又如手机号管理软件，可以考虑按省份或其它方式进行水平分解。 这部分主要是考虑使用方便性和效率问题，主要借助视图手段实现，包括：（1） 建立视图，使用更符合用户习惯的别名。（2）对不同级别的用户定义不同的视图，以保证系统的安全性。（3）对复杂的查询操作，可以定义视图，简化用户对系统的使用。物理设计主要工作是选择存取方法（索引），以及确定数据库的存储结构，这里就不说明了。
7，什么是数据库逻辑结构图怎么做的
数据库设计过程包括：nbsp;现实世界→需求分析→概念设计→逻辑设计→物理设计nbsp;概念设计－－利用数据模型进行概念数据库的模式设计。它不依赖任何DBMS（数据库管理系统）常用的数据模型为ERM（实体联系模型），用到的术语有：实体、属性、联系、键。nbsp;逻辑设计－－把概念设计得到的概念数据库模式变为逻辑数据模式，它依赖于DBMS。用到的术语有：函数依赖、范式、关系分解。nbsp;http://blog.csdn.net/ivy_zheng/archive/2007/06/29/1670978.aspx
8，画出数据库内部体系结构三级模式结构
（1）R1=R - S；a b c c b d （2）R2=R U S ；a b c b a f c b d d a f （3）R3=R I S；（4）R4=R × S。a b c b a fa b c d a f b a f b a fb a f d a fc b d b a fc b d d a f数据库的三级模式是数据库在三个级别 (层次)上的抽象，使用户能够逻辑地、抽象地处理数据而不必关心数据在计算机中的物理表示和存储。实际上 ，对于一个数据库系统而言一有物理级数据库是客观存在的，它是进行数据库操作的基础，概念级数据库中不过是物理数据库的一种逻辑的、抽象的描述(即模式)，用户级数据库则是用户与数据库的接口，它是概念级数据库的一个子集(外模式)。
文章TAG：
数据 数据库 逻辑 逻辑结构 数据库逻辑结构设计图
