Model工具

Sybase PowerDesigner - 一个高端数据建模工具。你可以下载一个45天试用版。

  • ERWin - 一个高端数据建模工具。可下载试用版。
  • Rational Rose Enterprise - 一个高端UML工具,恰如其分的数据库建模支持。可下载试用版。
  • Visio Professional - 一个价格低廉的绘图工具,可用来生成数据模型、UML图等。企业版还支持针对各种数据库的双向工程能力。你可以订购60天试用版的CD。
  • Dezign - 一个价格极其低廉的ERD建模工具。你可以下载一个有限制的试用版本。
  • ERD Tool List - 一个关于各种数据库和UML建模工具的链接和资源的清单。

附:

PowerDesigner12.0下载地址:

http://download.sybase.com/eval/PowerDesigner/powerdesigner12_eval.exe

破解补丁http://www.cnblogs.com/Files/polugen/PD12.rar

CDM是大多数开发者使用PD时最先创建的模型,也是整个数据库设计最高层的抽象。CDM是建立在传统的ER图模型理论之上的,ER图中有三大主要元素:实体型,属性和联系。其中实体型对应到CDM中的Entity,属性对应到CDM中每个Entity的Attribute,在概念上基本上是一一对应的。但在联系上,CDM有了比较大的扩展,除了保留ER图原有的RelationShip概念之外,还增加了Association,Inheritance两种实体关系,下面就让我们分别看看这些关系的用法和之间的区别(下图中被标红的工具栏按钮就是用来向实体中添加这些关系的)。   另外,在介绍所有这些CDM中的元素之前,笔者先给出一个很简单的CDM图,是对我们最最熟悉的学校场景的一个建模,下文中提到的所有概念在图中都有体现,大家在看下文的时候可以对照着来看:
一. RelationShip(联系)   先给出PD手册里对联系的定义:“A relationship is a link between entities. For example, in a CDM that manages human resources, the relationship Member links the entities Employee and Team, because employees can be members of teams. This relationship expresses that each employee works in a team and that each team has employees.” 可见,也许联系的概念真的太简单了吧,所以反而不那么好表述,所以PD的文档里也是用一个例子来说明出现了什么样的情况我们就认为两个实体间是有联系的。   当我们提起实体间联系的时候,最先想到的恐怕是one to one,one to many 和many to many这三种联系类型,这些联系类型也是大家最熟悉的。笔者对ER图原本的概念并不精通,但在CDM中,联系还有另外三个可以设置的属性:mandatory(强制性联系), dependent(依赖性联系/标定关联) 和dominant(统制联系)。这些属性对后面PDM的生成都有比较大的影响,需要我们一一有所了解。它们都是在联系的属性控制面板中设定的,见下图: 1.mandatory   联系是否具有强制性,指的是实体间是不是一定会出现这种联系;或者换句话说,当我们在谈及一个联系的应用场景的时候,联系对应的那两个实体型的实体实例的个数可不可能为零。也许这样的解释还是有点抽象,让我们举两个联系的例子,一个是对两边的实体都有强制性的,另一个则不然。 (1)教师--学生 联系   这个联系首先是一个多对多联系,因为每个老师可以教多个学生,每个学生也都有多个老师来负责他们的学业。同时,这个联系对教师和学生都是强制性的,也就是说,不存在任何一个老师,他不负责任何一个学生的教学;也不存在任何一个学生,他没有任何一个任课老师。 (2)学生--俱乐部 联系   这个联系也是一个多对多关系,但它对学生这个实体型而言就不是强制的(Optional,可选的)。每个俱乐部都有至少一个学生参加,但并不是每个学生都要去参加俱乐部的活动。完全可以有一些学生,他们什么俱乐部都没参加。 上面的例子主要是从概念的角度来区分了mandatory和optional的区别。实际上如果把这个模型对应到我们最后生成的表,如果A-B间的联系对A是mandatory的话,那么如果在A里面如果包含B的外键,这个外键不能为空值,反之可以为空值。后面我们谈到PDM和实际数据库的时候,大家会看到这一点。 2.dependent   每一个Entity型都有自己的Identifier,如果两个Entity型之间发生关联时,其中一个Entity型的Identifier进入另一个Entity型并与该 Entity型中的Identifier共同组成其Identifier时,这种关联称为标定关联,也叫依赖性关联(dependent relationship)。一个Entity型的Identifier进入另一个Entity型后充当其非Identifier时,这种关联称为非标定关联,也叫非依赖关联。   概念的定义说起来还是有些拗口,说白了其实就是主-从表关系,从表要依赖于主表。比如在我们系统里要记录教师休假的情况,有一个实体型Holiday,其属性包括休假的开始时间和天数,每次有教师休假的时候,都要在这个表留下记录。从我们的场景描述中可以看到,实体型假期必须依附于实体型教师,即对于每一个假期实例,必须指向某一个教师实例。   对于依赖型联系,必须注意它不可能是一个多对多联系,在这个联系中,必须有一个作为主体的实体型。一个dependent联系的从实体可以没有自己的identifier. 3.dominant   这个联系属性是最为简单的,它仅作用于一对一联系,并指明这种联系中的主从表关系。在A,B两个实体型的联系中,如果A-->B被指定为dominant,那么A为这个一对一联系的主表,B为从表,并且在以后生成的PDM中会产生一个引用(如果不指定dominant属性的话会产生两个引用)。比如老师和班级之间的联系,因为每个班级都有一个老师做班主任,每个老师也最多只能做一个班级的班主任,所以是一个一对一关系。同时,我们可以将老师作为主表,用老师的工号来唯一确定一个班主任联系。
二.Association(关联)   先来看一下PD给association的定义:“An association is a connection between entities. In the Merise modeling methodology an association is used to connect several entities that each represents clearly defined objects, but are linked by an event, which may not be so clearly represented by another entity.”。   在上一小段提到的那些RelationShip,在很多情况下(特别是多对多关系中),我们会把联系专门提出来,作为一个实体型放在两个需要被关联的实体型中间(在PD中,选中任何一个联系,在右键的弹出菜单中选择“Change to Entity”命令即可完成联系转实体的操作)。但有的时候,把若干个实体型之间的联系抽象为一个实体型可能不太合适,这个时候你可以选择为这些实体型建立一个association,那么在生成PDM的时候,所有这些相关实体型的identifier都会被加入到association对应生成的表模型中。所以,说白了,其实association就是实体型的一种特例,用来在建模的时候更确切的表达实体间的关联信息。在PD的文档中举了一个录音带、顾客、商店三个实体型在租借录音带这个场景上发生关联,然后把租借定义为上述三个实体型之间的association的例子,非常确切。在我们的学校模型里,我定义了家访做为老师和学生实体型中间的一个association,在接下来产生的PDM中大家就可能看到这种定义所产生的效果。
三.Inheritance(继承)   这种关系在概念层面是最容易理解的了,本文就不赘述了。
前面已经介绍了CDM中关于实体间关系的主要内容,接下来我们就来看看根据这个CDM所生成的PDM是一个什么样子: 上图中所有标红的部分是我们最应该关注的内容,因为他们都是由于我们对实体型间的关系的定义而产生的,下面给出一些简单的说明。 1. “师生关系”和“学生俱乐部”这两个表是由于我们的多对多关系而产生的。 2. “假期”表的“工号”字段是由于我们将教师-假期关系指定为dependent而产生的。 3. “班级”表的“工号”字段是由于我们将教师-班级关系制定为dominant而产生的。 4. “家访”表中的“工号”和“学号”字段是由于家访是教师和学生实体型的association而产生的。 另外,记得我们在提到dominant属性的时候说过,一个没指定dominant方向的一对一联系将产生两个引用,下面我们就把原本的CDM中的教师-班级关系进行一个小小的修改,去掉这个relationship的dominant定义,那么最终产生的PDM中教师表和班级表将互相包含对方的主键(由于我们的班级表没有自己的主键,所以只能在班级表中看到多出来的列),截图如下: 对照这个PDM截图和上一个PDM截图之间的区别,大家可以很容易得看出dominant属性对一个一对一关系的作用。
  好了,说到这里,本文就暂时告一段落了。文中提到的,都是经常使用PD的同志和笔者一样每天都会碰到的一些概念。只有我们把这些概念弄得很清楚,对PD的使用才能事半功倍。笔者也在网上找过关于PD的资料,发现有价值的资源很少。如果哪位老兄有比较好的资源或者书,还请推荐一二。 应一位朋友的要求,将本文中用到的CDM文件放在这里:school.rar

时间: 2024-07-30 13:31:03

Model工具的相关文章

地理信息系统 - ArcGIS - 高/低聚类分析工具(High/Low Clustering ---Getis-Ord General G)

前段时间在学习空间统计相关的知识,于是把ArcGIS里Spatial Statistics工具箱里的工具好好研究了一遍,同时也整理了一些笔记上传分享.这一篇先聊一些基础概念,工具介绍篇随后上传. 空间统计研究起步于上个世纪70年代,空间统计其核心就是认识与地理位置相关的数据间的空间依赖.空间关联等关系,通过空间位置建立数据间的统 计关系.空间统计学依赖于tablor地理学第一定律,即空间上越临近的事物拥有越强的相似程度:和空间异质性,即空间位置差异造成的行为不确定现象.例 如要度量犯罪率与教育程

技术经验集

JAVA EE架构师 需要具备的知识 1.构架师胚胎(程序员) 学习的知识是语言基础.设计基础.通信基础等,应该在大学完成,内容包括java.c.c++.uml.RUP.XML.socket通信(通信协议)--学习搭建应用系统所必须的原材料. 2.构架师萌芽(高级程序员) 学习分布式系统.组建等内容,可以在大学或第一年工作时间接触,包括分布式系统原理.ejb.corba.com/com+.webservice(研究生可以研究网络计算机.高性能并发处理等内容) 3.构架师幼苗(设计师) 应该在掌握

OC实用转换model的工具

说明 这是本人写的一个专门用来将json数据直接转换生成Model文件的工具,目的是为了让你从写Model文件的繁琐过程中解脱出来,提升效率以及减少出错的几率,工具的特点如下: 1. 用组合设计模式处理树形数据结构(非线性数据结构) 2. 在调试台中处理生成Model文件 3. 一次生成所有的Model文件,自动过滤Null值,后续维护Model提供UndefinedKey提示(以下为演示中一次生成的所有Model文件) *4. 设计原理基于非线性数据结构,需要对树形结构有所了解才能理解源码的实

基于OCILIB的oracle数据库操作总结及自动生成Model和Dao的工具

基于OCILIB的oracle数据库操作总结 1.       类图 2.       基类BaseOCIDao的设计与实现 BaseOCIDao.h头文件 #pragma once /* --------------------------------------------------------------------------------------------- * * INCLUDES * ----------------------------------------------

提高生产性工具 - Model代码生成器(NET / JAVA) (一)

原来在上一家公司,整整一年都在做工具,提高生产性,那个项目特别巨大,所以总共为老东家节约了500K左右的美金. (除了表扬之外,我个人什么好处都没有,领导们都升官发财了,郁闷) 到了新公司,也准备开发一些提高生产性的工具.最近在看NET MVC和Spring MVC的资料.所以想开发一个Model代码生成工具. 公司不能上Git,代码也刚开始写,所以暂时不拿出来了.逻辑很简单,博客园高手如云,看一下就知道我怎么写的了. 功能现在还很简单,以后完善. 软件的界面大概是这个样子的,验证这块只是开了个

第三篇:Entity Framework CodeFirst & Model 映射 续篇 EntityFramework Power Tools 工具使用

上一篇 第二篇:Entity Framework CodeFirst & Model 映射 主要介绍以Fluent API来实作EntityFramework CodeFirst,得到了大家一些支持,其中就有一位同学就提出.熟悉了EntityFramework CodeFirst 原理,就可以用微软的工具来生产代码.是的,今天就来讲一下,由微软EntityFramework小组开发的为EntityFramework CodeFirst Visual Studio小插件 “Entity Frame

Swift - 从字典(或者Alamofire)直接创建Model文件的工具

效果 1. 常规生成model的方式 2. 通过debug创建model的方式 特性 1. 可以处理JSON格式的字典数据 2. 可以处理本地的json数据 3. 可以处理Alamofire生成的json格式返回数据 4. 生成的Models继承自NSObject,所有方法均系系统方法,没有任何接口污染,后续升级不存在版本兼容问题(以下是一个生成的Model的示例) // // AlamofireModel.swift // // http://www.cnblogs.com/YouXianMi

自动生成mybatis的model,mapper,xml工具的使用

首先把这三个文件放到一个目录里,我是放到了C盘下的wangbo目录下: 接下来就是设置config.xml文件了,config.xml: 1 <?xml version="1.0" encoding="UTF-8"?> 2 <!DOCTYPE generatorConfiguration 3 PUBLIC "-//mybatis.org//DTD MyBatis Generator Configuration 1.0//EN"

【原创】文本工具的使用--根据数据库字段快速生成该表对应的Model类属性

在实际项目开发过程中,我们会经常碰到这样的问题:数据库表的字段按下划线命名方式都设计好了,接下来是要创建该表对应的Model类.如果我们按照数据库表中的字段,再手动敲一遍,生成对应Model类的属性.在字段少的情况下,手动创建Model类似乎没啥的.要是字段比较多,那就有点费时了.那如何快速生成数据库表字段对应的Model类呢?以下是本人的解决方案: 1.将建表语句复制到文本编辑器,如notepad++,editplus,vim等. 2.剔除其他字符串,提取字段 点击全部替换 3.下划线法转驼峰