逻辑数据模型举例(一)
概念数据模型设计与逻辑数据模型设计
概念数据模型设计与逻辑数据模型设计、物理数据模型设计是数据库及数据仓库模型设计的三个主要步骤。
在数据仓库领域有一个概念叫conceptual data model，中文一般翻译为“概念数据模型”。
概念数据模型是最终用户对数据存储的看法，反映了最终用户综合性的信息需求，它以数据类的方式描述企业级的数据需求，数据类代表了在业务环境中自然聚集成的几个主要类别数据。
概念数据模型的内容包括重要的实体及实体之间的关系。在概念数据模型中不包括实体的属性，也不用定义实体的主键。这是概念数据模型和逻辑数据模型的主要区别。
概念数据模型的目标是统一业务概念，作为业务人员和技术人员之间沟通的桥梁，确定不同实体之间的最高层次的关系。
在有些数据模型的设计过程中，概念数据模型是和逻辑数据模型合在一起进行设计的。
在数据仓库领域有一个概念叫logical data model，中文一般翻译为“逻辑数据模型”。
逻辑数据模型反映的是系统分析设计人员对数据存储的观点，是对概念数据模型进一步的分解和细化。逻辑数据模型是根据业务规则确定的，关于业务对象、业务对象的数据项及业务对象之间关系的基本蓝图。
逻辑数据模型的内容包括所有的实体和关系，确定每个实体的属性，定义每个实体的主键，指定实体的外键，需要进行范式化处理。【逻辑数据模型举例】
逻辑数据模型的目标是尽可能详细的描述数据，但并不考虑数据在物理上如何来实现。
逻辑数据建模不仅会影响数据库设计的方向，还间接影响最终数据库的性能和管理。如果在实现逻辑数据模型时投入得足够多，那么在物理数据模型设计时就可以有许多可供选择的方法。
在数据仓库领域有一个概念叫physical data model，中文一般翻译为“物理数据模型”。【逻辑数据模型举例】
物理数据模型是在逻辑数据模型的基础上，考虑各种具体的技术实现因素，进行数据库体系结构设计，真正实现数据在数据库中的存放。【逻辑数据模型举例】
物理数据模型的内容包括确定所有的表和列，定义外键用于确定表之间的关系，基于用户的需求可能进行发范式化等内容。在物理实现上的考虑，可能会导致物理数据模型和逻辑数据模型有较大的不同。
物理数据模型的目标是指定如何用数据库模式来实现逻辑数据模型，以及真正的保存数据
逻辑数据模型举例(二)
逻辑数据模型的评判标准与设计关键
摘 要： 商业银行的数据是商业银行宝贵的财富，这些未经加工的数据并不能满足商业银行的需要。因此，通过数据仓库技术对商业银行的数据进行有效的整合是一项重大的系统工程。利用数据仓库技术成功整合商业银行数据成功的关键是要做好基础数据的准备工作。基础数据的质量好坏直接决定了数据仓库系统工程的成败。 【关键词】逻辑数据模型 评判标准 设计关键
2003年中国建设银行制定了《中国建设银行科技应用总体规划》，确定了项目群实施规划、数据仓库和管理信息系统实施规划。规划中明确了建设银行的目标应用体系架构、技术架构以及项目实施路径等，规划出未来5-10年建设银行信息化发展战略。规划旨在为建设银行业务新一轮改革发展提供有力支撑，不断提高建设银行的盈利能力。为实现这一战略目标，建设银行以数据集中为前提，通过数据仓库为基础，通过信息管理平台持续开发客户分析管理、资产负债管理等应用，使建设银行信息化水平和内部管理水平走上新台阶。其中数据集中和数据仓库的建设是关键步骤。
1 Teradata FSLDM客户化
Teradata FSLDM是预先构建的逻辑数据模型，利用它可以直接开始数据仓库模型设计。它是一个纯粹的逻辑数据模型，可以运行在任何数据库和平台上，与Teradata数据库无关。客户化方法论可以概括为自底向上、从顶至下以及自底向上和从顶至下的联合使用。下面我们简要对这几种方法进行一下对比和分析，主要从策略、过程等方面的特点来决定到底采用何种方法进行开发。
首先，自底向上法是指先从较下层设计开始，也就是说去解决问题的各个不同的小部分，然后把这些部分组合成为完整的应用。这种设计方法主要是要根据系统功能要求，从具体的逻辑部件或者相似系统开始，凭借设计者熟练的技巧和丰富的经验，通过对其进行相互连接、修改和扩大，构成所要求的系统并保证系统功能的实现。从设计成本和开发周期来讲，自底向上法一般优于自顶向下法，但是由于其设计是从最底层开始的，所以也存在难以保证总体设计的最佳性的问题，一般适用于探索性的开发项目。在银行建设数据仓库，自底向上策略一般是从某个数据仓库原型开始，选择一些特定的为企业管理人员所熟知的管理问题作为数据仓库建设目标。该策略的主要优点在于能够以较小的投入在短时间内取得局部成果。
结合银行业务特点，一般来讲，按照数据仓库的思路建设信息决策系统已经有一定的先例和成功经验可以借鉴，不应该算作探索性尝试，而是目标明确、长期规划的建设过程，所以应该采用从顶至下的方法进行。也就是说，在开发前就已经具备数据仓库的系统定位、实现目标、应用范围等内容，这种策略对开发人员的开发经验要求和管理层、建设者的预期目标明确程度都有非常高的要求。
2 具体实施策略
在某银行Teradata FS-LDM客户化的具体实施过程中，采取的是分重点设计主题、自主设计主题、简化设计主题等不同类别，根据每种类别的特点和目标来分别制定有针对性实施策略的原则。实施后，产生的实体主题分布情况如下图所示：
下面从几个主题区域的具体情况来分别看一下。
团体域：团体域的逻辑数据模型截图如下图所示，它在分类、主要实体和与其它主题的关系方面继承了FS-LDM，在外部组织的非排它分类、贷款项目信息、重要相关人信息、团体地址信息等方面客户化程度较高。对于客户单一视图来讲，实施后可能存在的问题是由于来自各源业务系统的内部机构信息（一般是机构编码等）不一致，就需要数据仓库同时保留多套内部机构信息或需要手工建立映射关系。当然，这种情况能够最大限度地保留源业务系统信息，满足当前应用对机构信息的需求，但也存在可能造成系统资源开销较大、对各原系统数据缺乏统一机构分析视角等问题。
协议域：协议域的逻辑数据模型截图如下图所示，它在大型分类（如行业、业务种类等）、主要实体和与其它主题的关系方面继承了FS-LDM，在各个详细子类、对帐单地址、协议和业务种类等方面客户化程度较高。这一主题区域包含了协议的金额、状态历史，协议的周期性资金变动计划，以及协议与协议之间的关系历史等在内的所有与协议相关的变动历史信息。
资产域：资产域的逻辑数据模型截图如下图所示，它在资产及其分组、资产价值历史等主要实体以及与其它主题的关系方面继承了FS-LDM，在资产分类（以建设银行为准）、资产详细信息以及处置情况等方面客户化程度较高。需要说明的是，这里的资产概念分为实物资产、金融资产、无形资产三类，所有与之相关的信息都存放在此，且既包括银行资产，也包括客户资产（大多数情况是客户在办理贷款申请时提交的担保及抵质押物信息），同时既可以描述一个团体的所有资产，也可以描述一个资产被多个团体拥有的情况，也就是说，一个团队可以与多项资产有关，一个资产也可以与多个团体有关。
财务域：财务域的逻辑数据模型截图如下图所示，它在分类总账科目、财务细目、主要实体科目和上述科目的子类、历史以及与其它主题的关系方面继承了FS-LDM，同时将财务预算、统计项目保留为今后可扩充的部分。目前的特点是对于银行内部账组织模式进行了抽象描述，能够适应不同科目组织体系，但仅就总帐科目余额进行了客户化。
作者单位
海南师范大学桂林洋校区信息科学技术学院 海南省海口市 571127
http://m.zhuodaoren.com/tuijian331946/
推荐访问:套套逻辑举例 逻辑回归模型
