概念建模,概念建模数据视图
数据建模的如何进行
概念建模
数据建模大致分为三个阶段，概念建模阶段，逻辑建模阶段和物理建模阶段。其中概念建模和逻辑建模阶段与数据库厂商毫无关系，换言之，与MySQL，SQL Server，Oracle没有关系。物理建模阶段和数据库厂商存在很大的联系，因为不同厂商对同一功能的支持方式不同，如高可用性，读写分离，甚至是索引，分区等。
概念建模阶段
实际工作中，在概念建模阶段，主要做三件事：
1. 客户交流
2. 理解需求
3. 形成实体
这也是一个迭代，如果先有需求，尽量去理解需求，明白当前项目或者软件需要完成什么，不明白或者不确定的地方和客户及时交流，和客户double confirm过的需求，落实到实体（Package）；但是好多时候我们需要通过先和客户交流，进而将交流结果落实到需求，之后进一步具体到实体；本文可能会涉及到一些来自于EA（Enterprise Architect 7.1）建模术语，（EA中将每个实体视为一个Package）。这里并不对各种建模工具进行比较，如Visio，EA，PowerDesigner， ERWin等；其实作为员工的我们选择性很少，公司有哪个产品的Licence，我们就用哪个吧。
举例说明：在一个B2C电子商务网站中，这样的需求再普通不过了：客户可以在该网站上自由进行购物！我们就以这个简单例子，对其进行细分，来讲解整个数据建模的过程，通过上面这句话，我们可以得出三个实体：客户，网站，商品；就像Scrum（敏捷开发框架的一种）中倡导的一样每个Sprint，都要产出确确实实的东西，OK，概念建模阶段，我们就要产出实体。客户和商品（我们将网站这个实体扔掉，不需要它。）
在创建这两个实体（Package）的时候，我们记得要讲对需求的理解，以及业务规则，作为Notes添加到Package中，这些信息将来会成为数据字典中非常重要的一部分，也就是所谓的元数据。BTW，EA或者其他建模工具应该都可以自动生成数据字典，只不过最终生成的格式可能不太一样。如在Customer这个Package的Notes上，我们可以这样写，用户都要通过填写个人基本信息以及一个邮箱来注册账户，之后使用这个邮箱作为登录帐号登录系统进行交易。
在概念建模阶段，我们只需要关注实体即可，不用关注任何实现细节。很多人都希望在这个阶段把具体表结构，索引，约束，甚至是存储过程都想好，没必要！！因为这些东西使我们在物理建模阶段需要考虑的东西，这个时候考虑还为时尚早。可能有的人在这个阶段担心会不会丢掉或者漏掉一些实体?也不用担心，2013年好多公司都在采用Scrum的开发模式，只要你当前抽象出来的实体满足当前的User Story，或者当前的User Story里面的实体，你都抽象出来了，就可以了！如果你再说，我们User Story太大，实体太多，不容易抽象，那就真没办法了，建议你们的团队重新开Sprint 计划会议。
逻辑建模
逻辑建模阶段
对实体进行细化，细化成具体的表，同时丰富表结构。这个阶段的产物是，可以在数据库中生成的具体表及其他数据库对象（包括，主键，外键，属性列，索引，约束甚至是视图以及存储过程）。我在实际项目中，除了主外键之外，其他的数据库对象我都实在物理建模阶段建立，因为其他数据库对象更贴近于开发，需要结合开发一起进行。如约束，我们可以在web page上做JavaScript约束，也可以在业务逻辑层做，也可以在数据库中做，在哪里做，要结合实际需求，性能以及安全性而定。
针对Customer这个实体以及我们对需求的理解，我们可以得出以下几个表的结构，用户基本信息表（User），登录账户表（Account），评论表（Commnets,用户可能会对产品进行评价），当然这个案例中我们还会有更多的表，如用户需要自己上传头像（图片），我们要有Picture表。
针对产品实体，我们需要构建产品基本信息表（Product），通常情况下，我们产品会有自己的产品大类（ProductCategory）甚至产品小类（ProductSubCategory），某些产品会因为节假日等原因进行打折，因为为了得到更好的Performance我们会创建相应ProductDiscount表，一个产品会有多张图片，因此产品图片表（ProductPicture）以及产品图片关系表（ProductPictureRelationship），（当然我们也可以只设计一张Picture表，用来存放所有图片，用户，产品以及其他）有人说产品和图片是一对多的关系，不需要创建一个关系表啊?是的，我认为只要不是一对一的关系，我都希望创建一个关系表来关联两个实体。这样带来的好处，一是可读性更好，实现了实体和表一一对应的关系，二是易于维护，我们只需要维护一个关系表即可，只有两列（ProductID和PictureID），而不是去维护一个Picture表。
客户进行交易，即要和商品发生关系，我们需要Transaction表，一个客户会买一个或者多个商品，因为一笔Transaction会涉及一个或多个Products，因此一个Transaction和ProductDiscount之间的关系（ProductDiscount和Product是一一对应的关系）需要创建，我们称其为Item表，里面保存TransactionID以及这笔涉及到的ProductDiscountID（s），这里插一句，好多系统都需要有审计功能，如某个产品历年来的打折情况以及与之对应的销售情况，我们这里暂不考虑审计方面的东西。
就这样，我们根据需求我们确定下来具体需要哪些表，进一步丰富每一个表属性（Column），当然这里面会涉及主键的选取，或者是使用代理键（Surrogate Key），外键的关联，约束的设置等细节，这里笔者认为只要能把每个实体属性（Column）落实下来就是很不错了，因为随着项目的开展，很多表的Column都会有相应的改动。至于其他细节，不同数据库厂商，具体实现细节不尽相同。关于主键的选取多说一句，有的人喜欢所有的表都用自增长ID作为主键，而有的人希望找到唯一能标识当前记录的一个属性或者多个属性作为主键；自增长ID作为代理主键，对于将来以多个类似当前Transaction System作为数据源，构建数据仓库的时候，这些自增长ID主键会是一个麻烦（多个系统中，相同表存在大量主键重复）；使用一个属性或多个属性作为作为主键，不管主键是可编辑的，读写效率是我们必须考虑得。所以并没有一个放之四海而皆准的原则，笔者只是给大家推荐一些考虑的因素。
物理建模
物理建模阶段
EA可以将在逻辑建模阶段创建的各种数据库对象生成为相应的SQL代码，运行来创建相应具体数据库对象（大多数建模工具都可以自动生成DDL SQL代码）。但是这个阶段我们不仅仅创建数据库对象，针对业务需求，我们也可能做如数据拆分（水平或垂直拆分），如B2B网站，我们可以将商家和一般用户放在同一张表中，但是针对PERFORMANCE考虑，我们可以将其分为两张表；随业务量的上升，Transaction表越来越大，整个系统越来越慢，这个时候我们可以考虑数据拆分，甚至是读写分离（即实现MASTER-SLAVE模式，MYSQL/SQLSERVER可以使用Replication，当然不同存储引擎采用不同的方案），这个阶段也会涉及到集群的事情，如果你是架构师或者数据建模师，这个时候你可以跟DBA说，Alright,I am done with it,now is your show time.
相信大家都知道范式，更有好多人把3NF奉为经典，3NF确实很好，但是3NF是几十年前提出来的，那个时候的数据量以及访问频率和2012年完全不是一个数量级的；因此我们绝对不能一味地遵守3NF；在整个数据建模过程中，在保证数据结构清晰的前提下，尽量提高性能才是我们关注的要点，因此笔者大力倡导数据适当冗余!
上面笔者是结合一些实际例子表达自己对数据建模的观点，希望对读着有用。在数据建模过程中，不要希望一步到位将数据库设计完整，笔者不管是针对data warehouse还是Transactional Database设计，从来没有过一次成功的经历。随着项目的进行，客户和开发团队对业务知识与日增长，因此原来的设计也在不断完善中。毕竟，数据建模或者设计数据库不是我们的最终目的，我们需要的是一个健壮，性能优越，易扩展，易使用的软件!
概念模型的模型设计
概念模型设计
概念模型不依赖于具体的计算机系统，他是纯粹反映信息需求的概念结构。
建模是在需求分析结果的基础上展开，常常要对数据进行抽象处理。常用的数据抽象方法是‘聚集’和‘概括’。
E-R方法是设计概念模型时常用的方法。用设计好的ER图再附以相应的说明书可作为阶段成果
概念模型设计可分三步完成： ① 确定局部概念模型的范围
② 定义实体
③ 定义联系
④ 确定属性
⑤ 逐一画出所有的局部ER图，并附以相应的说明文件 建立全局E-R图的步骤如下：
① 确定公共实体类型
② 合并局部E-R图
③ 消除不一致因素
④ 优化全局E-R图
⑤ 画出全局E-R图，并附以相应的说明文件。 概念模型的评审分两部分进行：
第一部分是用户评审。
第二部分是开发人员评审。
概念模型是什么？
也称信息模型，它是按用户的观点来对数据和信息建模。概念模型是现实世界到机器世界的一个中间层次。表示概念模型最常用的是实体-关系图。概念模型是对真实世界中问题域内的事物的描述，不是对软件设计的描述。概念的描述包括：记号、内涵、外延，其中记号和内涵（视图）是其最具实际意义的。概念模型用于信息世界的建模，它是世界到信息世界的第一层抽象，它数据库设计的有力工具，也是数据库开发人员与用户之间进行交流的语言。因此概念模型既要有较强的表达能力，应该简单、清晰、易于理解。目前最常用的是实体-联系模型。在管理信息系统中，概念模型：是设计者对现实世界的认识结果的体现，是对软件系统的整体概括描述。让读者更易理解，读时有个参考的东西。概念模型设计的常用方法是实体关系方法（E-R方法）。用实体关系方法对具体数据进行抽象加工，将实体集合抽象成实体类型，用实体间的关系反映现实世界事物间的内在关系。首先可以进行局部E-R模型，然后把各局部E-R模型综合成一个全局的E-R模型，最后对全局E-R模型进行优化，最后得到的。在数据仓库中的含义总的来说，数据仓库的结构采用了三级数据模型的方式，即概念模型、逻辑模型、物理模型。概念模型:也就是业务模型,由企业决策者,商务领域知识专家和IT专家共同研究和分析企业级的跨领域业务系统需求分析的结果。在数据仓库项目中,物理模型设计和业务模型设计象两个轮子一样有力地支撑着数据仓库的实施,两者并行不悖,缺一不可。实际上,这有意地扩大了物理模型和业务模型的内涵和外延，因为，在这里物理模型不仅仅是数据的存储,而且也包含了数据仓库项目实施的方法论、资源以及软硬件选型，而业务模型不仅仅是主题模型的确立,也包含了企业的发展战略,行业模本等等更多的内容。一个优秀的项目必定会兼顾业务需求和行业标准两个方面,业务需求既包括用户提出的实际需求,也要客观分析它隐含的更深层次的需求,但是往往用户的需求是不明确的,需要加以提炼甚至在商务知识专家引导下加以升华,和用户一起进行需求分析工作。如果不能满足用户的需求,项目也就失去了原本的意义。关于概念模型概念模型设计是在原有的业务数据库的基础上建立了一个较为稳固的概念模型。因为数据仓库是对原有数据库系统中的数据进行集成和重组而形成的数据集合，所以数据仓库的概念模型设计，首先要对原有数据库系统加以分析理解，看在原有的数据库系统中有什么、怎样组织的和如何分布的等，然后再来考虑应当如何建立数据仓库系统的概念模型。一方面，通过原有数据库的设计文档以及在数据字典中的数据库关系模式，我们可以对企业现有的数据库中的内容有一个完整而清晰的认识;另一方面，数据仓库的概念模型是面向企业全局建立的，它为集成来自各个面向应用的数据库的数据提供了统一的概念视图。它的工作主要是界定系统的边界和确定主要的主题域。界定系统边界将决策者的数据分析的需求用系统边界的定义形式反映出来。确定主题域是对每个主题域的内容进行较明确的数据仓库建模技术在行业中的应用描述，其内容包括:主题域的公共码键、主题域之间的联系以及充分代表主题的属性组。
简单说一下ansys 概念建模与3D建模区别
我说下我的理解：
ansys
wb里面概念建模就是创建线体和面体，线体无直径参数就相于一个理想条件，对应的是梁单元，面体无厚度，相当于是一个无厚度的壳。对应壳单元。
以上2中在现实中是不存在的只能在理论中存在，所以说是概念建模，用来模拟各个特定力学状态下的理想模型
而3D建模就是有具体长宽高的概念可以赋予密度，现实中可以真实存在的物理模型，
数据库建模，概念模型、逻辑模型、物理模型的区别和转化
关于数据库理论中概念模型、逻辑模型、物理模型之间的区别。随机复习上网并复习，并在此记录一下，数据库建模是对现实世界进行分析、抽象、并从中找出内在联系，进而确定数据库的结构。
1、概念模型：就是从现实世界到信息世界的第一层抽象，确定领域实体属性关系等，使用E-R图表示，E-R图主要是由实体、属性和联系三个要素构成的。
2、逻辑模型：是将概念模型转化为具体的数据模型的过程，即按照概念结构设计阶段建立的基本E-R图，按选定的管理系统软件支持的数据模型（层次、网状、关系、面向对象），转换成相应的逻辑模型。这种转换要符合关系数据模型的原则。目前最流行就是关系模型（也就是对应的关系数据库）
E-R图向关系模型的转换是要解决如何将实体和实体间的联系转换为关系，并确定这些关系的属性和码。这种转换一般按下面的原则进行：
（1）一个实体转换为一个关系，实体的属性就是关系的属性，实体的码就是关系的码。
（2）一个联系也转换为一个关系，联系的属性及联系所连接的实体的码都转换为关系的属性，但是关系的码会根据联系的类型变化，如果是：
1：1联系，两端实体的码都成为关系的候选码。
1：n联系，n端实体的码成为关系的码。
m：n联系，两端实体码的组合成为关系的码。
3、物理模型就是根据逻辑模型对应到具体的数据模型的机器实现。物理模型是对真实数据库的描述。如关系数据库中的一些对象为表、视图、字段、数据类型、长度、主键、外键、索引、约束、是否可为空、默认值。
---------------------------------------------------------------------
概念设计就是设计E-R图啊，物理（逻辑）设计就是把你的E-R图中的实体，属性转换成关系模式
1.概念设计；对用户要求描述的现实世界(可能是一个工厂、一个商场或者一个学校等)，通过对其中住处的分类、聚集和概括，建立抽象的概念数据模型。这个概念模型应反映现实世界各部门的信息结构、信息流动情况、信息间的互相制约关系以及各部门对信息储存、查询和加工的要求等。所建立的模型应避开数据库在计算机上的具体实现细节，用一种抽象的形式表示出来。以扩充的实体—（E-R模型）联系模型方法为例，第一步先明确现实世界各部门所含的各种实体及其属性、实体间的联系以及对信息的制约条件等，从而给出各部门内所用信息的局部描述(在数据库中称为用户的局部视图)。第二步再将前面得到的多个用户的局部视图集成为一个全局视图，即用户要描述的现实世界的概念数据模型。
2.逻辑设计；主要工作是将现实世界的概念数据模型设计成数据库的一种逻辑模式，即适应于某种特定数据库管理系统所支持的逻辑数据模式。与此同时，可能还需为各种数据处理应用领域产生相应的逻辑子模式。这一步设计的结果就是所谓“逻辑数据库”。
3.物理设计；根据特定数据库管理系统所提供的多种存储结构和存取方法等依赖于具体计算机结构的各项物理设计措施，对具体的应用任务选定最合适的物理存储结构(包括文件类型、索引结构和数据的存放次序与位逻辑等)、存取方法和存取路径等。这一步设计的结果就是所谓“物理数据库”。
4.三者关系：由上到下，先要概念设计，接着逻辑设计，再是物理设计，一级一级设计。