系统逻辑模型是一种

问题一：什么是系统的逻辑模型?什么是系统的物理模型 以实物或画图形贺渣式直观的表达认识对象的特征

在数据仓库项目中，物理模型设计和业务模型设计象两个轮子一样有力地支撑着数据仓库的实施，两者并行不悖，缺一不可。实际上，这有意地扩大了物理模型和业务模型的内涵和外延，因为，在这里物理模型不仅仅是数据的存储，而且也包含了数据仓库项目实施的宏腔方法论、资源以及软硬件选型，而业务模型不仅仅是主题模型的确立，也包含了企业的发展战略，行业模本等等更多的内容。

物理模型就像大厦的基础架构，就是通用的业界标准，无论是一座摩天大厦也好，还是茅草房也好，在架构师的眼里，他只是一所建筑，地基―层层建筑―封顶，这样的工序一样也不能少，关系到住户的安全，房屋的建筑质量也必须得以保证，唯一的区别是建筑的材料，地基是采用钢筋水泥还是石头，墙壁采用木质还是钢筋水泥或是砖头；当然材料和建筑细节还是会有区别的，视用户给出的成本而定；还有不可忽视的一点是，数据仓库的数据从几百GB到几十TB不等，面对如此大的数据管理，无论支撑这些数据的RDBMS（关系数据库）多么强大，仍不可避免地要考虑数据库的物理设计。

设计依据

物理模型设计所做的工作是根据信息系统的容量，复杂度，项目资源以及数据仓库项目自身（当然，也可以是非数据仓库项目）的软件生命周期确定数据仓库系统的软硬件配置，数据仓库分层设计模式，数据的存储结构，确定索引策蔽拍衫略，确定数据存放位置，确定存储分配等等。这部分应该是由项目经理和数据仓库架构师共同实施的。

数仓模型

编辑

确定数据仓库实现的物理模型，必须做到以下几方面:

确定资源

◆确定项目资源

根据预算和业务需求，并参考以往的数据仓库项目经验，对该项目的成本周期和资源进行估算。

关于项目周期的估算，主要基于ETL函数功能点以及加权后的复杂度进行估算，通过以往项目经验和专家评估,然后再根据软件生命周期的划分，可以有效的得知项目的整体周期。

关于人员的估算，主要取决于人员的工作经验，素养，对新技术的掌握能力，还要考虑到人员流动等方面的人员备份。

确定配置

◆确定软硬件配置

数据仓库项目与其他业务系统不同，尤其需要对数据容量进行估算，这是因为数据仓库是历史的稳定的基于主题的集成的等等特性所决定的，它是对以往历史数据的集成，如果项目初期不加以考虑，很快就会造成灾难性的后果。

所以，首先要得到数据仓库的预计容量，也要考量具体的关系数据库的性能，既要考虑实际的预算，也要视实际的需求而定。在发挥软件作用的同时，兼顾扩展性。

存储设计

◆数据仓库存储设计

数据仓库一般采用分层设计，即ODS层，数据仓库层，数据仓库聚合层数据集市等等；数据仓库的分层是灵活的，没有固定的模式，一切视实际情况而定。

物理学是研究物质运动规律的学科，而实际的物理现象和物理规律一般都是十分复杂的，涉及到许多因素。舍弃次要因素，抓住主要因素，从而突出客观事物的本质特征，这就叫构建物理模型。构建物理模型是一种研究问题的科学的思维方法。

中学分类

编辑

中学物理模型一般可分三类：物质模型、状态模型、过程模型。

物质模型

物质可分为实体物质和场物质。

实体物质模型有力学中的质点、轻质d簧、d性小球等；电磁学中的点电荷、平行板电容器、密绕螺线管等；气体性质中的理想气体；光学中的薄透镜、均匀介质等。

场物质模型有如匀强电场、匀强磁场等都是空间场物质的模型。

状态模型

研究流体力学时，流体的稳恒流动（状态）；研究理想气体时，气体的平衡态；研究原子物理时，原子所处的基态和激发态等都属于状态模型。

过程模型

在研究质点运动时，如匀速直线运动、匀变速直线运动、匀速圆周运动......>>

问题二：结构化分析方法中采用以下哪一项来建立系统的逻辑模型 结构化分析方法(Structured Method)是强调开发方法的结构合理性以及所开发软件的结构合理性的软件开发方法。结构是指系统内各个组成要素之间的相互联系、相互作用的框架。结构化开发方法提出了一组提高软件结构合理性的准则，如分解与抽象、模块独立性、信息隐蔽等。针对软件生存周期各个不同的阶段，它有结构化分析(SA)、结构化设计(SD)和结构化程序设计(SP)等方法。

结构化分析方法给出一组帮助系统分析人员产生功能规约的原理与技术。它一般利用图形表达用户需求，使用的手段主要有数据流图、数据字典、结构化语言、判定表以及判定树等。

结构化分析的步骤如下：

①分析当前的情况，做出反映当前物理模型的DFD；

②推导出等价的逻辑模型的DFD；

③设计新的逻辑系统，生成数据字典和基元描述；

④建立人机接口，提出可供选择的目标系统物理模型的DFD；

⑤确定各种方案的成本和风险等级，据此对各种方案进行分析；

⑥选择一种方案；

⑦建立完整的需求规约。

结构化设计方法给出一组帮助设计人员在模块层次上区分设计质量的原理与技术。它通常与结构化分析方法衔接起来使用，以数据流图为基础得到软件的模块结构。SD方法尤其适用于变换型结构和事务型结构的目标系统。在设计过程中，它从整个程序的结构出发，利用模块结构图表述程序模块之间的关系。结构化设计的步骤如下：

①评审和细化数据流图；

②确定数据流图的类型；

③把数据流图映射到软件模块结构，设计出模块结构的上层；

④基于数据流图逐步分解高层模块，设计中下层模块；

⑤对模块结构进行优化，得到更为合理的软件结构；

⑥描述模块接口。

结构化程序设计原则和方法

在结构化程序设计的具体实施中，要注意把握以下原则和方法：

1．使用程序设计语言中的顺序、选择、循环等有限的控制结构表示程序的控制逻辑；

2．选用的控制结构只允许有一个入口和一个出口；

3．程序语句组成容易识别的语句序列块，每块只允许有一个入口和一个出口；

4．复杂结构的程序设计时，仅用嵌套的基本控制结构进行组合嵌套来实现；

5．严格控制GOTO语句的使用。其意思是指：

（1）用一个非结构化的语言去实现一个结构化的构造，既虽然有些高级语言有GOTO语句，但编程时不使用；

（2）若不使用GOTO语句会使功能模糊时，慎重地使用GOTO语句；

（3）在某种可以改善而不是损害程序可读性的情况下，慎重地使用GOTO语句。

问题三：什么是会计信息系统分析中用来表达新系统的逻辑模型 对新系统的逻辑模型的分析

新系统的开发对A银行而言虽然是一个巨大的变化，即由手工处理到现代化管理信息系统的转变，无论在实际运营中，还是在员工和银行的经营理念中，都是一个具有深远意义的飞跃。但究根问底，新系统的逻辑模型仍是以原有的银行传统逻辑模型为基础，这是由银行的功能和其比较固定的业务流程决定的，并不会因系统物理形态的变化而发生根本上的变化。下面对新系统的逻辑模型用数据流程图(dataflowdiagram)、数据字典(datadictionary)等工具加以描述

问题四：帮帮，1.信息系统的逻辑模型要解决系统“干什么” 任务是：在充分认识原信息系统的基础上，通过问题识别、可行性分析、详细调查、系统化分析，最终完成新系统的逻辑方案设计，或称逻辑模型设计。逻辑方案不同于物理方案，前者解决“做什么”的问题，是系统分析的任务；后者解决“怎么做”的问题

问题五：目前普遍使用的逻辑数据模型是哪一种 目前普遍使用的逻辑数据模型是关系模型数据库系统

还有非关系模型

最新的为第三代数据模型

第三代数据库系统都应具有以下三个基本特点：

1. 必须保持或继承第二代数据库系统的技术

2. 应支持数据管理、对象管理和知识管理

3. 应该对其他系统开放

问题六：信息系统的逻辑模型用到哪些图表,它们之间有什么关系? 信息系统的逻辑模型用到的图表有：业务流程图、数据流程图、组织机构图（层次方框图）、Varner图（描述数据结构图层的图）IPO图（输入处理输出图）、PAD图（问题分析图）、表格分配图、不能用计算机处理的是源终点。

数据流图反映信息在系统中流动和处理情况。组织结构图是组织结构的直观反映，也是对该组织功能的一种侧面诠释。各个图表在信息处理方案的不同阶段呈现数据流程图是在业务流程图的基础上建立起来的以更合适的确立系统的逻辑结构和数据分布。

问题七：什么是新系统逻辑模型 一般

业务和系统开发领域绝对不能容许设计上的重大失误。可是，很多开发人员却因为不了解设计步骤而恰恰轻视乃至完全忽略了整个设计过程。而实际上，我们中的大多数人也戚陵确实缺乏必要的有关技能和知识，结果令我们往往“旁路”了项目开发中最重要的阶段。说真的，有本事敢直接绕过设计阶段的人还没诞生呢。如果我们不花点时间创建一个逻辑模型，那么要实现一套高效和优秀的设计是完全不可能的。略过设计步骤会产生大量的错误，而这些错误又会令我们耗费大量的时间在发现它们的时候反复调试和纠正。下面我就大致讨论下设计的逻辑和物理模型，然后引领读者经过逻辑模型的创建全过程。本文是有关主题系列的开篇，在后续的第2部分里，我会根据已经发现的缺陷修改我们的原始设计。数据库的设计方法在对数据库项目的需求着手评估和分析周，接下来的一步就是设计出一套方案帮助你达到项目的要求和目标。在开发领域这一步骤被称做数据库设计方法。它是一种结构化的措施，支持设计流程同时还包括了诸如公司业务流程、规定和文档等一系列工具。步步进阶的整套流程帮助开发人员计划、管理和控制设计及其实现从而高效地完成任务。这意味着，你拥有一整套方法，也就是按照特定顺序安排的项目列表，这些方法指引你经过数据模型创建的全过程。请不要错误地把这个过程理解为平常的过程，实际上它是完全必要的阶段。你应该从完全理解数据和用户需求这一目的出发研究该过程。每一个项目无论其规模大小都能从以下三种模型中获益：概念：明确和说明创建数据全局视图的主要对象，同时辅以一定的轻微细节。许多企业都局限于特定的数据库管理系统（DBMS），所以这一步可以忽略或者放到逻辑模型一组。逻辑：构高则戚造采用特定数据的模型，但还不用考虑最终保存数据以及运营应用程序的具体数据库系统。由于SQL Server是一种关系型数据库管理系统（RDBMS），所以我们要依赖于实体关系模型（ER：Entity-Relationship）。在这一阶段你必须明确实体、关系、属性并对你的数据实行规格化。逻辑模型建立在数据集合的基础之上。为了更深入地了解ER模型，不不妨访问下ITS数据库服务网站或者参考Mapping an ER Model to the Relational Model Web site（是一个.PDF文件）。物理：根据所采用的具体RDBMS设计实现逻辑模型的具体模型。在这一阶段，你需要说明数据表、索引等数据库对象，而物理模型就是根据数据表建立的。建立逻辑模型的真实用意无非是为了确认应用程序能满足最终的需求（包括输入和输出两方面）。换句话说，逻辑模型必须能产生所有已知的报告、查询等结果。此外，用户还应该能够以合理的方式输入和 *** 作数据。一旦逻辑模型到位，你就应开始把你所了解的情况应用到项目的物理需求方面——比如说——物理模型。图A就描述了逻辑和物理模型在这一阶段的差别。图A　逻辑和物理数据模型逻辑模型的实现目前阶段的所谓“实现”其实就是完成逻辑模型的组件。在明确了实体、关系和属性的情况下，你应该揭示出那些在工作环境下可能会产生问题的缺陷：缺少的实体表示同一概念实体的多个实体需要额外实体来解决问题的多对多关系Aggregator：一家俱乐部，其成员可以享受打折服务。Corporate：代表其盯芹职员下定单的公司。它们不能享受的打折优不过需要获得旅行社的全方位服务支持。比如说，旅行社必须帮助它们解决一些诸如取消计划、飞机票订位过多等方面的问题。企业客户总是一样的而旅行者只能是其职员。Retail：不能享受任何折扣优惠的单独客户。这时，你应该准备定义应用程序的主要对象或者实体。为了针对客户类型应用以上的业务规则，你可能会把每一种客户类型当作单独的实体，如表A所示。数据类型和其他信息都是针对SQL Server考虑的。表A　定义应用实体看图B，你可以简化当前的模型：客户订单。某种特定类型的客户。图B不同实体之间的关系正如我们在上面所提到的那样，业务规则要求我们对客户实现区别对待。结果，客户不能总是具有同样的属性。我们的第1个解决方案是创建一个数据表，其中包含了各类客户的特定属性。这一原始设计带来了下列问题：所有的客户数据表都采用系统生成的主键，大致以种子值1开始递增。那就是说，你完全会遭遇重复的ClientID值。结果我们就无法恰当地把每一定单关联到特定的客户，因为每一客户表都包含了重复的值。因为每一客户表重复公共字段（如ClientID、ClientName、Address和Telephone）而产生了一些冗余的属性。客户会有更多的地址吗？也许他们会具有一个当地地址和一个付费的单位地址。客户只有一个电话号码？也许你应该列出多个电话号码乃至传真号码。有必要根据客户的类型来标识定单吗？显然你不能。找出和解决设计问题你首先采取的行动可能和我们用的不同，但那还不是关键的问题。最重要的是你可能没有认识的到设计中隐藏的问题。在后续的文章里我会采用已知的、业已得到证明的方法来寻找和解决设计问题，免得它们在今后的工作中引出不少漏子。

---