"Model-First 数据库创建步骤"

版权申诉
0 下载量 82 浏览量 更新于2024-02-25 收藏 2.72MB DOC 举报
# 采用 Model-First 方式创建数据库 在数据库设计和开发过程中,采用Model-First 方式创建数据库是一种常见的方法。它允许开发人员首先创建数据库模型,然后根据模型自动生成数据库结构,这样可以更加高效地进行数据库设计和开发。 对于使用Model-First 方式创建数据库的开发人员来说,最常见的工具就是 Vistual Studio 2010 Beta2。在开始创建数据库之前,首先要创建一个解决方案。打开Vistual Studio 2010 Beta2,并点击“new project”,选择需要的项目类型,然后创建解决方案。创建解决方案的过程很简单,只要按照提示操作即可。 在解决方案创建完成之后,接下来就是创建数据库模型。在Vistual Studio 2010 Beta2中,可以使用Entity Framework来创建数据库模型。Entity Framework是一个强大的数据库访问技术,可以帮助开发人员更加便捷地进行数据库编程。要使用Entity Framework创建数据库模型,首先需要在解决方案中添加一个新的ADO.NET Entity Data Model。只需要右键点击解决方案中的项目,选择“Add”->“New Item”,然后选择“ADO.NET Entity Data Model”,命名并创建即可。 创建数据库模型之后,就可以开始进行数据库设计。在Entity Framework中,可以使用实体模型设计器来进行数据库表的设计,包括表的字段、主键、外键等等。在实体模型设计器中,只需要拖拽实体对象和字段对象,设置它们之间的关系,即可完成数据库模型的设计。 设计完成数据库模型之后,就可以利用Entity Framework来自动生成数据库结构。只需要在Vistual Studio 2010 Beta2中点击“Generate Database from Model”按钮,选择数据库连接和生成选项,即可自动创建数据库结构。在自动生成数据库结构的过程中,Entity Framework会根据数据库模型自动创建相应的表、字段、主键和外键,从而可以省去手动编写SQL语句的繁琐过程。 总之,采用Model-First 方式创建数据库是一种高效的数据库设计和开发方法。通过Vistual Studio 2010 Beta2和Entity Framework,开发人员可以首先创建数据库模型,然后根据模型自动生成数据库结构,从而使数据库设计和开发过程更加简单、快速和可靠。同时,采用Model-First 方式创建数据库也能够更好地适应需求变化,因为只需要修改数据库模型,就可以自动生成新的数据库结构,而无需修改复杂的SQL语句。因此,对于需要快速迭代和灵活应对需求变化的项目来说,采用Model-First 方式创建数据库是一种非常值得推荐的做法。
2023-01-08 上传
数据库模型设计连载(1~6) 最近一直有个愿望:希望把自己所从事的数据库模型设计方面的工作经验和想法付诸文 字,算是对此前工作的一个总结,今天终于开始了万里长征的第一步。 在正式开始之前,我先向大家介绍两本书——《数据模型资源手册卷一》、《数据模型资源 手册卷二》,国内有机械工业出版社出版的中文译本,很多同行可能都已看过,我本人也 看过。 看过之后深受启发,同时也感到两点美中不足: 1、这两部书的成书时间较早,且原作内容是基于美国企业的业务需求而建,有些最新 的行业信息及"中国特色"的东西没有收录。 2、书中原作者所使用的设计符号是作者专用的,而对于目前国内数据库模型设 计的专业人员来说,ER图或者PowerDesigner中的CDM、PDM图更容易理解和沟通。 所以,在今后一段时间,我希望每天能抽出2个小时,结合上面提到的两部书的 内容、PowerDesigner的PDM模型以及本人相关工作经验,在这里做一个数据库模型设计 的连载。本连载计划用120天的时间撰写完毕。 这么做的目的,一方面是将头脑里的无形信息落实到文字上、有效避免遗忘, 另一方面更加希望抛砖引玉,在与同行们沟通交流之后对我自己也是个促进和提高,对 其他同行也起到各借鉴的作用。望广大同行们不吝赐教,大家一起来推动数据库模型设 计的资源共享计划。 什么是模式? 连载之1 原创:胖子刘(转载请注明出处及作者,谢谢。) 什么是模式?简单说来,模式类似于定式,就是遇到反复出现的同一问题时所固定使 用的解决方案。下围棋的朋友可能对"定式"这个词比较熟悉,定式包含着下棋时做遇到 的各种情况下的下法、急所、手筋及死活等基本原理,例如星定式、小目定式、边定式 等等,定式懂的越多,围棋下的越好。 那么是不是数据库设计模式懂得越多,设计工作越完美呢?理论上是这样,但是在我 这里,各位朋友所能看到的数据库设计模式只有四种。 为什么只有四种而不是更多? 不时有那句话吗:"浓缩的都是精华"! 在后面的文章中,您会陆续看到浩浩荡荡的设计实例连篇累牍,却都是利用这四种基 本模式设计出来的。《易传·系辞》曰:"易有太极,是生两仪,两仪生四象,四象生八卦 。"老子在《道德经》中也说:"道生一,一生二,二生三,三生万物。" 设计模式不必多,只要掌握其中关键的几个,再结合实际的业务需求,一个完整的数 据库模型就可以推导出来。 下面让我们来逐一介绍这四种主要设计模式—— (一)主扩展模式 连载之2 原创:胖子刘(转载请注明出处及作者,谢谢。) (一)主扩展模式 主扩展模式,通常用来将几个相似的对象的共有属性抽取出来,形成一个"公共属性 表";其余属性则分别形成"专有属性表",且"公共属性表"与"专有属性表"都是"一对一 "的关系。 "专有属性表"可以看作是对"公共属性表"的扩展,两者合在一起就是对一个特定对象 的完整描述,故此得名"主扩展模式"。 举例如下(注:这个例子已经作了相当程度的简化,仅仅是用来帮助大家理解"主扩 展模式"这个概念来使用的,请大家注意)。 假设某公司包括如下6种类型的工作人员:采购员、营销员、库房管理员、收银员、 财务人员和咨询专家,采用主扩展模式进行设计,如下图所示。 无论哪种类型的工作人员,都要访问公司的办公软件,所以都有"登陆代码"和"登录 密码";并且作为一般属性,"姓名"、"性别"、"身份证号"、"入职时间"、"离职时间"等 属性,都与个人所从事的工作岗位无关,所以可以抽取出来作为公共属性,创建"公司员 工"表。 很显然,公司委派员工采购哪些商品是"采购员"的专有属性,这是由公司的实际业务 特点决定的。换句话说,公司不可能把采购任务放到"营销员"身上,也不可能放到"库房 管理员"身上,"采购商品"属性就是"采购员"的专用属性。 "采购员"表的主键与"公司员工"表的主键是相同的,包括字段名称和字段的实际取值 ;"采购员"表的主键同时是"公司员工"表主键的外键。在PDM图里可以看到"采购员"表中 的"员工ID"字段后面有一个"<pk,fk>"标记,这个标记就说明"员工ID"字段既是"采购员 "表的主键,同时也是该表的外键。 "公司员工"表是主表,"采购员"表是扩展表,二者是"一对一"的关系,两个表的字段 合起来就是对"采购员"这个对象的完整说明。同理,"公司员工"表和其他5个表之间也都 分别构成了"一对一"的关系。 对于主表来说,从表既可以没有记录,也可以有唯一一条记录来对主表进行扩展说明 ,这就是"主扩展模式"。 (二)主从模式 连载之3 原创:胖子刘(转载请注明出处及作者,谢谢。) (二)主从模式 主从模式,是数据库设计模式中最常见、也是大家日常设计工作中用的最多的一种模 式,它描述了两个表之间的主从关系,是典型的"一对多"关系。 举例如下(注:这个例子已经作了相当
2023-01-08 上传
为什么需要设计数据库 这里我们思考两个问题: 修建茅屋需要设计吗?修建大厦需要设计吗? 结论是:当数据库比较复杂(如数据量大,表较多,业务关系复杂)时,我们需要先 设计数据库; 因为,良好的数据库设计能够: q 节省数据的存储空间 q 能够保证数据的完整性 q 方便进行数据库应用系统的开发 糟糕的数据库设计: q 数据冗余、存储空间浪费 q 内存空间浪费 q 数据更新和插入的异常 软件项目开发周期 我们再来看看软件项目的开发周期: 需求分析阶段:分析客户的业务和数据处理需求; 概要设计阶段:设计数据库的E-R模型图,确认需求信息的正确和完整; 详细设计阶段:将E- R图转换为多张表,进行逻辑设计,并应用数据库设计的三大范式进行审核; 代码编写阶段:选择具体数据库进行物理实现,并编写代码实现前端应用; 软件测试阶段:…… 安装部署:…… 设计数据库 在需求分析阶段,设计数据库的一般步骤为: – 收集信息 – 标识对象 – 标识每个对象的属性 – 标识对象之间的关系 在概要设计阶段和详细设计阶段,设计数据库的步骤为: – 绘制E-R图 – 将E-R图转换为表格 – 应用三大范式规范化表格 下面我们以一个BBS简易论坛的数据库设计为例来看看设计数据库的步骤: 收集信息: 与该系统有关人员进行交流、坐谈,充分理解数据库需要完成的任务 BBS论坛的基本功能: l 用户注册和登录,后台数据库需要存放用户的注册信息和在线状态信息; l 用户发贴,后台数据库需要存放贴子相关信息,如贴子内容、标题等; l 论坛版块管理:后台数据库需要存放各个版块信息,如版主、版块名称、贴子数等; 标识对象(实体-Entity) 标识数据库要管理的关键对象或实体 实体一般是名词: l 用户:论坛普通用户、各版块的版主。 l 用户发的主贴 l 用户发的跟贴(回贴) l 版块:论坛的各个版块信息 标识每个实体的属性(Attribute) 标识对象之间的关系(Relationship) l 跟贴和主贴有主从关系:我们需要在跟贴对象中表明它是谁的跟贴; l 版块和用户有关系:从用户对象中可以根据版块对象查出对应的版主用户的情况; l 主贴和版块有主从关系:需要表明发贴是属于哪个版块的; l 跟贴和版块有主从关系:需要表明跟贴是属于哪个版块的; 绘制E-R图 将E-R图转化为表格 将各实体转换为对应的表,将各属性转换为各表对应的列 标识每个表的主键列,需要注意的是:没有主键的表添加ID编号列,它没有实际含 义,用于做主键或外键,例如用户表中的"UID"列,版块表中添加"SID"列,发 贴表和跟贴表中的"TID"列 在表之间建立主外键,体现实体之间的映射关系 这里我们绘制ER图可以使用微软的Word或VISIO以及Sybase公司的PowerDesigner,它 主要用于和客户沟通交流意见,并反复修改,直到客户确认。客户确认后,再将E- R图转换为表。上面我们已经做好了这个工作。那接下来就是最后一步:应用三大范式对 设计的多张表进行审核并规范化表的结构。 数据规范化 仅有好的RDBMS并不足以避免数据冗余,必须在数据库的设计中创建好的表结构。表设 计后,很可能结构不合理,出现数据重复保存,简称数据的冗余,这对数据的增删 改查带来很多后患,所以我们需要审核是否合理,就像施工图设计后,还需要其他 机构进行审核图纸是否设计合理一样。 如何审核呢?需要一些有关数据库设计的理论指导规则,这些规则业界简称数据库的 范式。Dr E.F.codd 最初定义了规范化的三个级别,范式是具有最小冗余的表结构。这些范式是: – 第一范式(1st NF -First Normal Fromate) – 第二范式(2nd NF-Second Normal Fromate) – 第三范式(3rd NF- Third Normal Fromate) 如果每列都是不可再分的最小数据单元(也称为最小的原子单元),则满足第一范式 (1NF)。第一范式的目标是确保每列的原子性。 如果一个关系满足1NF,并且除了主键以外的其他列,都依赖于该主键,则满足第二范 式(2NF)。第二范式要求每个表只描述一件事情,确保表中的每列,都和主键相 关。 如果一个关系满足2NF,并且除了主键以外的其他列都不传递依赖于主键列,则满足第 三范式(3NF)。第三范式确保每列都和主键列直接相关,而不是间接相关。 下面我们来看个形象的例子吧!假设某建筑公司要设计一个数据库。公司的业务规则 概括说明如下: 公司承担多个工程项目,每一项工程有:工程号、工程名称、施工人员等 公司有多名职工,每一名职工有:职工号、姓名、性别、职务(工程师、技术员)等 公司按照工时和小时工资率支付工资,小时工资率由职工的职务决定(例如,技术员 的小时工资率与工程师不