数据库设计——概念结构设计概念模型由于计算机不可能直接处理现实世界中的具体事物,所以人们必须事先把具体事物转换成计算机能够处理的数据,也就是数字化。概念模型是现实世界到机器世界的一个中间层次。现实世界的事物反映到人的脑子中来,人们把这些事物抽象为一种既不依赖于具体的计算机系统又不为某一DBMS支持的概念模型,然后再把概念模型转换为计算机上某一DBMS支持的数据模型.实体:客观存在并相互区别的事物及其事物之间的联系。例如,一个学生、一门课程、学生的一次选课等都是实体。主要概念码:唯一标识实体的属性集。例如,学号是学生实体的码。属性:实体所具有的某一特性。例如,学生的学号(20052268)、姓名(张山)、性别(男)、出生年份(1976)、系(计算机系)、入学时间等(1994)。域:属性的取值范围。例如,年龄的域为大于15小于35的整数性别的域为(男,女)。实体型:用实体名及其属性名集合来抽象和刻画同类实体,称为实体型。例如,学生(学号,姓名,性别,出生年份,系,入学时间)就是一个实体型。实体集:同型实体的集合称为实体集。例如,全体学生就是一个实体集。联系:实体与实体之间以及实体与组成它的各属性间的关系。联系有三种情况:一对一联系(班长与班级),一对多联系(班主任与班级),多对多联系(教师与课程);实体与组成它的各属性间:职工。实体—联系方法(E-R图)实体型:用矩形表示,矩形框内写明实体名。属性:用椭圆形表示,并用无向边将其与相应的实体连接起来。联系:用菱形表示,菱形框内写明联系名,并用无向边分别与有关实体连接起来,同时在无向边旁标上联系的类型(1:1,1:n或m:n)。表示方法一个班级的概念模型的E-R图。班号班级名称班级人数班级学号组成姓名性别年龄籍贯人数学生1n请同学们自己分别举出3种联系的E-R模型目前最常用的数据模型有层次模型、网状模型和关系模型。其中层次模型和网状模型统称为非关系模型。三种主要的数据模型1.层次数据模型最早出现的数据模型用树形结构表示各类实体以及实体间的联系典型代表是IBM公司的IMS(InformationManagementSystems)数据库管理系统在数据库中,对满足以下两个条件的数据模型称为层次模型。(1)有且仅有一个节点无双亲,这个节点称为“根节点”。(2)其他节点有且仅有一个双亲。若用图来表示,层次模型是一棵倒立的树。系教研室教师学生2.网状数据模型典型代表是DBTG系统,也称CODASYL系统,它是20世纪70年代数据系统语言研究会CODASYL(ConferenceOnDataSystemsLanguage)下属的数据库任务组(DataBaseTaskGroup,简称DBTG)提出的一个系统方案。在数据库中,对满足以下两个条件的数据模型称为网状模型:(1)允许一个以上的节点无双亲。(2)一个节点可以有多于一个的双亲。若用图表示,网状模型是一个网络系教研室教师学生住处自然界中实体型间的联系更多的是非层次关系,用层次模型表示非树形结构是很不直接的,网状模型则可以克服这一弊病3.关系模型1970年IBM公司SanJose研究室的研究院E.F.Codd首次提出了数据库系统的关系模型,开创了数据库关系方法和关系数据理论研究,为数据库技术奠定了理论基础。1981年E.F.Codd获得了ACM图灵奖关系模型是建立在严格的数学概念的基础上。对于用户,关系模型中数据的逻辑结构是一张二维表。自顶向下首先定义全局概念结构的框架,然后逐步细化方法与步骤自底向上首先定义各局部应用的概念结构,然后将它们集成起来,得到全局概念结构逐步扩张首先定义最重要的核心概念结构,然后向外扩充,以滚雪球的方式逐步生成其他概念结构,直至总体概念结构常用策略(P211图7.8)自顶向下地进行需求分析自底向上地设计概念结构自底向上设计概念结构的步骤(P211图7.9)第1步:抽象数据并设计局部视图第2步:集成局部视图,得到全局概念结构设计分E-R图的步骤:⒈选择局部应用⒉逐一设计分E-R图局部视图设计两种方式:一次集成(P219图7.25(a))逐步累积式(P219图7.25(b))步骤:合并修改与重构视图的集成判断作为属性还是作为实体的两个准则(1)作为属性,不能在具有描述的性质。“属性”必须是不可分的数据项,不能包含其他的数据项。(2)“属性”不能与其他实体具有联系,即E-R图中所表示的联系是实体之间的联系。凡满足上述两条准则的事物,一般均可作为属性对待。销售管理子系统整个系统功能围绕了“订单”和“应收帐款”的处理。数据结构中订单、顾客、顾客应收帐目用的最多,是许多子功能、数据流共享的数据,因此先设计该分E-R图的草图。销售管理子系统参照第二层数据流图和数据字典中的详尽描述,遵循前面给出的两个准则,进行了如下调整:销售管理子系统(1)每张订单由订单号、若干头信息和订单细节组成。订单细节又有订货的零件号、数量等来描述。按照准则(2),订单细节就不能作为订单的属性处理而应该上升为实体。一张订单可以定若干产品,所以订单与订单细节两个实体之间是1:n的联系。订单组成订单细节n1销售管理子系统(2)原订单和产品的联系实际上是订单细节和产品的联系。每条订货细节对应一个产品描述,订单处理时从中获得当前的单价、产品重量等信息。订单组成订单细节n1销售管理子系统(3)“发票主清单”是一个数据存储,是否应作为实体假如分E-R图呢?这里的数据存储对应手工凭证,发票上的信息在开具发票的同时已及时存入应收账款中了。销售管理子系统(4)工厂对大宗货物给予优惠。每种产品都规定了不同订货数量的折扣,应增加一个“折扣规则”实体存放这些信息,而不应把它们放在产品描述实体中。销售管理子系统最后得到分E-R图如图所示:顾客应收账款支付订货订单组成订单细节产品描述参照2参照1折扣规则n1n1n1n1n1销售管理子系统每个实体定义的属性如下:顾客:{顾客号,顾客名,地址,电话,信贷状况,账目余额}订单:{订单号,顾客号,订货项数,订货日期,交货日期,工种号,生产地点}订单细则:{订单号,细则号,零件号,订货数,金额}销售管理子系统应收账款:{顾客号,订单号,发票号,应收金额,支付日期,支付金额,当前余额,货款限额}产品描述:{产品号,产品名,单价,重量}折扣规则:{产品号,订货量,折扣}