英语原文共 13 页,剩余内容已隐藏,支付完成后下载完整资料
使用MySQL进行数据库设计
大多数针对信息系统的数据库设计和实现课程的数据库教科书都支持大型数据库系统(Oracle、MS SQL Server、DB/2等)。关于数据库管理最重要的方面:设计和实现;我们不应该忽视MySQL——它是1995年在瑞典开发的、使用最广泛的开源关系数据库管理系统,现在由Oracle公司所有。本文展示了两个数据库设计学习案例。第一个是处理用于将数据模型转换为物理数据库的正向工程技术。第二个案例展示了如何将现有数据库反向工程为数据模型。两个案例都使用了MySQL工作台和MySQL社区服务器。相比之下,Microsoft Access只能将一个物理数据库逆向工程到它的关系图中。 1介绍 数据库设计是数据库开发过程的一部分,涉及对问题定义(规范和需求)的分析,并为构建数据的逻辑结构提供所有必要的发现。问题定义或多或少地正式规定了支持某些组织操作的数据的目的、需求、要求和约束。数据的逻辑结构最初可以用简单的语言表示。例如,它可能由一系列简单语句(主语 谓语 宾语)组成,这些语句可以转换为更具表现力的数据模型。这样的模型接近于人们认为的概念层次或视图(Date, 2004, p. 39),它应该允许精确映射到数据库模式(元数据),通常用数据定义语言(DDL)表示。在关系数据库系统中,这样的DDL由创建数据库及其表、视图、索引等的SQL语句组成。数据模型通常被表示为实体关系图(ERDs),大多数当代的数据库设计工具都能够将图转换为元数据。这样的转换称为正向工程。有些工具还能够进行反向转换——从元数据到ERDs。 本文给出的第一个案例展示了一个完整的ERD结构例子其次是正向工程技术。第二个案例使用一个现有的数据库(元数据)来重新设计ERD(逆向工程)。这两个案例都是使用MySQL工作台实现的(Wikipedia-MySQLW, 2014)。 2学习目标 可以说,教授和学习数据库设计的主要挑战与问题陈述分析和数据建模有关。其余的设计任务更具有可预测性和技术性,因此它们很容易学习,甚至可以自动化。 数据库管理教科书将相当大的篇幅用于数据库设计问题。指导学生完成需求分析、高级(概念)设计和逻辑数据建模的过程。如(Elmasri, 2004年,第52页)所述: 收集并分析了所有的需求之后,下一步就是使用高级概念数据模型为数据库创建一个概念模式。这一步被称为概念设计。概念模式是对用户数据需求的简明描述,包括实体类型、关系和约束的详细描述;这些是用高级数据模型提供的概念表示的。因为这些概念不包括实现细节,所以它们通常更容易理解,并且可以用于与非技术用户进行通信。 理想情况下,数据库设计过程的这个阶段应该由数据库专业人员、主题专家和最终用户组成的团队来执行。即使设计团队拥有非常高水平的多元化专业知识,仍有许多挑战有待解决。尽管没有技术实现细节,但是创建概念模式和高级数据模型可能是数据库设计过程中最困难的部分。本文介绍的两个案例将有助于更好地理解数据库结构的设计过程。 下面所介绍的正向工程案例(案例1)旨在为学生提供一个良好的实践教学集,特别是在将问题定义转换为逻辑数据模型和物理数据库方面提供帮助。 逆向工程案例(案例2)作为通过实体关系图(ERD)记录现有物理数据库的一个例子。 3数据库设计简介 将数据库设计过程解释为逻辑设计而不是物理设计并不少见(2009年,第285页)。物理设计更关心如何将逻辑设计映射到物理数据库。案例1展示了如何使用MySQL工作台实现这样的映射。一些数据库专业人士认为逻辑设计更像是一门艺术而不是一门科学。尽管如此,在构建逻辑数据模型时,有一些通用的指导原则是有用的。 如前所述,逻辑数据模型应该捕获实体类型、属性、关系和约束。根据(Elmasri, at al., 2004, p. 53)“ER模型的基本对象代表了一个实体,它是现实世界中独立存在的“事物”。此时,区分实体类型和实体是很重要的,因为在许多情况下,这两个术语是可以互换使用的。实体类型的概念类似于面向对象设计中使用的类的概念。实体类型是实体的集合(实体实例),就像类是对象的集合一样(类实例)。在一个物理数据库中,实体类型变成了表和实体实例-记录(或表行)。实体类型的典型例子有:人、学生、公司、部门、产品、位置、比赛等。识别实体被认为是开发逻辑数据模型的首要任务。在接下来的内容中,术语“实体”被用于可以明确表示“实体类型”的地方。 实体的描述性属性被称为属性(Elmasri, at al., 2004, p.54)。它们表示实体(在相同的实体类型中)的相关特征,这些实体将持久化在数据存储(数据库)中。每个属性都有自己的类型(它可以承担的值域)。例如,一个人的年龄来自整数集(如果年龄要用整年表示);学生年级是文本 (字符串){ 大一 , 大二, 大三 , 大四 }的一个元素;产品价格是一个非负实数等。理想情况下,逻辑数据模型应该提供实体类型的所有相关属性(已经标识)。高级设计(数据模型)可能不会显示所有必需的属性,但至少应该包括所谓的键。实体类型的键是其属性的子集,唯一地标识其每个实体。一个实体可以有多个键。选择用来正式表示唯一实体实例的键被引用为主键。例如,在大学数据库系统中,学生号码或其他自然唯一标识符(例如:护照号码)用来唯一地识别每个学生。但是,由于隐私和/或安全限制,系统生成的[人工]密钥是唯一映射到自然密钥的。这些键被称为代理键,它们在日常操作中作为主键使用。 逻辑数据模型中最有趣的部分可能是关系。正如在(Elmasri, at al., 2004, p. 61)“实体E1、E2、hellip;En之间的关系类型R 在这些实体之间定义一组关联或关系集。“需要注意的是,虽然关系类型是在实体类型之间定义的,但实际的关系发生在实体实例之间。 实体类型通常被标记为名词,而关系类型具有语言内涵。例如,对于实体类型Student和Registration,我们可以说lt; Student - completed - Registration gt;,其中Student是实体Student的一个实例,Registration是实体Registration的一个实例,关系 completed是一个关系类型。在更详细和技术层面上,这种关系是在实体的键之间实现的。 以下实体学生的实例:
实体注册:
关系完成,简而言之,表示为: 11345 -完成- 234123, 其中11345和234123分别是Student和Registration实体实例的主键。而且,关系完成在这里用键studentID=11345表示,它是注册实例的一个属性。这样的键称为外键。键的这种双重含义是实体之间关系的一种表现。要使一个外键存在于一个实体中,它必须是相关实体中的主键。 实体和关系是问题陈述和需求分析的主要产品。名词是实体很好的候选者,而言语表达则是识别关系。实体的相关(必需)特征作为实体的属性被捕获。更复杂的关系可能会产生额外的实体。对关系施加的重要限制反映了可以参与关系的实体实例的最小或最大数量。这种限制称为基数约束或多重约束。它们包括,但不限于(Connolly, at al., 2005, p. 356-360): bull;一对一(1:1),(0..1: 1)。 bull;一对多(1:1*),(1: 0..*),(0..1:1..*),(0..1:0..*)。 bull;多对多(1..*:1..*),(1..*:0..*),(0..*:0..* ),(*:*)。 例如,关系lt; US_Resident – has – Social_Security_Number gt;是一对一的类型(1:1)。给定的US_Resident有一个social_security_number和给定的social_security_number属于一个us_resident。 关系lt;Student – is – Persongt;是一个特殊的一对一的关系(0..1比1)。一个给定的student是一个person,但一个给定的person不一定是student。实体student可以选择参与:0或1(0..1)。这样的关系也被称为概括。使用面向对象的术语,它是继承的一个例子。对于一个恰巧是student的person来说,后者继承了前者的所有属性。简而言之,这种关系可以被编码为lt;Student(0..1) - is - (1)Persongt;。 关系lt;Faculty – works for – Departmentgt;典型的Many-to - One关系。Faculty(教员)为一个department(部门)工作,而一个department(部门)雇用一个或多个Faculty(教员)。这种关系的一个快捷符号可以是: lt;Faculty (1..*) - works for - (1) Departmentgt; 关系lt;Student - takes - Coursegt;是Many-to-Many类型(0..*: 0 ..*)。一个给定的学生可以选修很多门课程,而一门给定的课程可能很多学生。可能有一个学生还没有注册任何课程,也可能有一个课程没有学生注册。需要注意的是,数据库管理系统不能直接实现多对多关系。它们必须转换为多个更简单的关系,通常是两个或多个一对多关系。例如,lt;Student - takes - Coursegt;关系可以转换为以下一对多/多对一关系: 一对多: lt;Student (1) – completes – (0..*) Registrationgt; 多对一: lt;Registration (0..*) – joins – (1) Classgt; 多对一: lt;Class (0..*) – administers – (1) Coursegt; ERD不仅是一个优秀的设计工具,而且它也是一个方便的文档和参考,特别是数据库应用程序开发人员(SQL和应用程序程序员)。重要的是要注意erd并没有完全捕获逻辑设计。它们在描述实体和关系方面做得很好,但在显示所有必要的约束方面却较弱(Date 2009, p. 286)。在MySQL工作台中开发的数据模型(图表)只能够捕获类型为一对一和一对多的基数约束。有趣的是,试图用MySQL工作台定义多对多关系会自动生成两个一对多的关系。MySQL工作台将ERDs称为EER(增强的实体关系)图。 4案例1:数据建模和正向工程 问题陈述 考虑一个为在线选举系统开发数据库的问题,该系统将用于选举非营利组织的新领导人。一些组织成员担任领导职务(主席、副主席、财务主管、通讯编辑、年会协调员、秘书等)。假定他们已获提名竞选这些职位,并已接受他们的提名,从而成为现有职位的正式候选人。本组织章程规定,每个候选人只能竞选一个职位,每个成员对每个职位只能投一票。该数据库应方便投票过程,并记录分配给候选人的所有选票,但不应告诉哪位成员投票给哪位候选人。典型的投票过程预计包括以下步骤: ·会员使用他/她的用户名和密码登录系统。 ·系统对成员进行身份验证,一旦成功,它将为成员尚未投票的职位提供选票表格。每个表格显示一个职位和这个职位的候选人。 ·在每个表单上,成员选择一个候选人并提交表单。 ·系统存储了选票,包括会员信息、位置和取票时间(表格送达的时间)。另外,系统会记录投票记录,包括投票记录的序列号(唯一的电子签名)和被选中的候选人(她/他的ID)。 重要的是要注意,为了保持投票隐私,必须将包含选定候选人的投票记录与选票(成员 立场)分开。 在现实世界的情况下,上述问题陈述之后通常会有额外的询问、讨论和分析。在这种情况下,假定所有必要的信息都包含在上述语句中。 值得一提的是,参加作者的DBMS课程的学生试图用许多不同的方式解决上述问题。一些学生遵循分析指南并按照建议开发了EER图。一些学生试图开发原型解决方案在Excel中。其他学生甚至直接使用MySQL系统的shell,使用SQL开发了一个物理数据库。提供一个完整的数据库设计和实现过程的详细说明超出了本文的能力范围。然而,一个完整的,一步一步的,指令可以从谷歌驱动器和镜像URL中检索(Letkowski, 2014)。本指令将被维护,以使其与最新的软 剩余内容已隐藏,支付完成后下载完整资料 资料编号:[603199],资料为PDF文档或Word文档,PDF文档可免费转换为Word |
课题毕业论文、文献综述、任务书、外文翻译、程序设计、图纸设计等资料可联系客服协助查找。