IBM系统分析——架构设计五视图+数据设计

目  录

一、架构设计五视图

1. 逻辑架构

2. 开发架构

3. 运行架构

4. 物理架构

5. 数据架构

二、数据设计

1. 数据库的逻辑模型

2. 数据库的常用模型

3. 实现从面对对象模型到表的转换

4. 数据库的物理模型

---

一、架构设计五视图

1. 逻辑架构

逻辑架构关注的是功能，包含用户直接可见的功能，还有系统中隐含的功能。或者更加通俗来描述，逻辑架构更偏向我们日常所理解的“分层”，把一个项目分为“表示层、业务逻辑层、数据访问层”这样经典的“三层架构”。

2. 开发架构

开发架构则更关注程序包，不仅仅是我们自己写的程序，还包括应用程序依赖的SDK、第三方类库、中间价等。尤其是像目前主流的Java、.NET等依靠虚拟机的语言和平台，以及主流的基于数据库的应用，都会比较关注。和逻辑架构有紧密的关联。

3. 运行架构

顾名思义，更关注的是应用程序运行中可能出现的一些问题。例如并发带来的问题，比较常见的“线程同步”问题、死锁问题、对象创建和销毁(生命周期管理)问题等等。开发架构，更关注的是飞机起飞之前的一些准备工作，在静止状态下就能规划好做好的，而运行架构，更多考虑的是飞机起飞之后可能发生的一些问题。

4. 物理架构

物理架构，更关注的系统、网络、服务器等基础设施。例如：如何通过服务器部署和配置网络环境，来实现应用程序的“可伸缩性、高可用性”。例子，如何通过设计基础设施的架构，来保障网站能支持同时10W人在线、7*24小时提供服务，当超过10W人或者低于10W人在线时，可以很方便的调整部署架构来支撑。

5. 数据架构

数据架构，更关注的是数据持久化和存储层面的问题，也可能会包括数据的分布、复制、同步等问题。更贴切来讲，如何选择需要的关系型数据库、流行的NOSQL，如何保障数据存储层面的性能、高可用性、灾备等等。很多时候，和物理架构是有紧密联系的，但它更关注数据存储层面的，物理架构更关注整个基础设施部署层面。

二、数据设计

1. 数据库的逻辑模型

逻辑模型就是要将概念模型具体化，就是要实现概念模型所描述的东西，需要哪些具体的功能，处理哪些具体的信息，是对概念模型的进一步细化。

简单概括，就是——“做什么”。

以销售业务为例：“客户”信息基本上要包括：单位名称，联系人，联系电话，地址等属性；“商品”信息基本上要包括：名称，类型，规格，单价等属性；“定单”信息基本上要包括：日期和时间属性。并且“定单”要与“客户”，“业务员”和“商品”明细关联。

系统需要建立几个数据表：业务员信息表，客户信息表，商品信息表，定单表。

系统要包括几个功能：业务员信息维护，客户信息维护，商品信息维护，建立销售定单 。

2. 数据库的常用模型

层次模型、网状模型、关系模型、面向对象数据模型、对象关系数据模型、半结构化模型。

 

3. 实现从面对对象模型到表的转换

方法一：将整个类层次映射成一张表；

方法二：将子类映射成单独的表；

方法三：将每个类映射成单独的表。

4. 数据库的物理模型

物理模型是对真实数据库的描述。例如关系数据库中的一些对象为表、视图、字段、数据类型、长度、主键、外键、索引、约束、是否可为空、默认值。

简单概括，就是——“怎么做”​​​​​​。