一、软件体系结构与设计过程
软件体系结构（软件架构）：{构建，连接件，约束}。
构件：组成系统的具有一定独立功能的不同粒度的程序模块等。
连接件：将不同的构件连接起来，表示构件间的相互作用，如信号量的传递、功能和方法的调用。
约束：对象连接时的规则。
软件设计过程：
概要设计：
完成软件的总体结构设计。
对每个功能模块进行功能描述、全局数据定义和外部文件定义。
做到低耦合，高内聚，降低模块接口的复杂性。
可采用层次结构图表示软件总体结构，体现自顶向下、逐步求精的设计思想。
应提供概要设计说明书等
详细设计：
细化概要设计产生的功能模块，形成可编程的程序模块。
用某种过程设计语言设计程序模块的内部细节。
还要制定模块测试方案。
可采用结构化设计方法（面向数据流的设计方法）、面向对象设计方法或面向数据设计方法。
总体设计：
对软件需求进行分解，划分成若干个子系统，定义各个子系统应事先的功能和相互间的交互关系和通信机制。
将每个子系统进一步划分为功能模块，定义各功能模块的数据结构、相互间交互关系。
二、DBAS总体设计
内容：DBAS体系结构设计、DBAS软件总体设计、软硬件选型与配置设计、业务规则初步设计。
体系结构设计：
将系统从功能、层次/结构、地理分布等角度进行分解，划分为多个子系统，定义各子系统应事先的功能。
设计系统的全局控制，明确各子系统间的交互和接口关系。
客户/服务器体系结构：（两层C/S结构）
数据管理功能在客户端上，数据处理功能在数据库服务器上。
数据库服务器可以为多个客户端应用一共共享的数据管理功能。
客户端应用可以通过网络访问多个不同数据源。
客户端除了完成人机交互功能外，还需要完成面向应用的数据处理功能，属于“胖客户端”。
浏览器/服务器结构：（三层B/S结构）
表示层位于客户端，有Web浏览器实现。
客户端：根据现实逻辑完成具体的数据表示和人机交互功能，属于“瘦客户端”。
功能层：位于Web应用服务器，实现面向具体应用领域的业务规则，接收用户请求，向数据库服务器提出数据操作请求，接收数据访问结果，通过客户端将结果返回给用户。
数据层：位于数据库服务器，通过DBMS完成具体的数据存储和数据存取等数据管理功能。接收来自应用服务器提出的数据操作请求，将数据访问结果返回给应用服务器。
二者特点：使用Internet、维护工作量方便B/S优于C/S，在运行速度、数据安全、人机交互方面，B/S不如C/S。
DBAS软件总体设计：将DBAS软件系统分解为一系列子系统，为各子系统分配相应功能，定义子系统间的协调相互机制。
软硬件选型和配置设计
业务规则初步设计：用业务流程图表示出来。
三、DBAS功能概要设计
表示层：负责所有与用户交互的功能。
业务逻辑层：根据业务逻辑将表示层获取的数据进行组织后传递给数据访问层。
数据访问层：与DBMS系统进行交互，提取或存入应用系统所需的数据。
数据持久层：数据组织和存储。
表示层概要设计：主要任务是人能及界面设计。
业务逻辑层概要设计：高内聚，低耦合。构件间接口明确。如果构件过于复杂，可进一步细分。
数据访问层概要设计：主要任务是针对DBAS的数据处理需求设计用于操作数据库的各类事务。
事务的特性：原子性、一致性（保证事务的操作状态是正确的）、隔离性（互不打扰）、持续性（影响是永久的，对于撤销的事务影响可以消除）。
四、DBAS功能详细设计：
表示层详细设计：初步设计、用户界面细节设计、原型设计与改进。
业务逻辑层详细设计：
根据概要设计中定义的个程序模块功能和输入输出数据需求，设计各模块的内部处理流程和算法、数据结构、对外接口，是对概要设计的细化。
可以通过UML类图、活动图、协作图来描述DBAS对用户业务的详细实现逻辑。
五、应用系统安全架构设计
数据安全设计：
安全性保护、完整性保护、并发控制、数据库的备份与恢复、数据加密传输。
安全性保护：
用户身份鉴别：windows集成，用户名和密码。
权限控制、视图机制：建立用户时设好权限等级。
视图机制：即使数据存在，但用户看不到它们。
完整性保护：
指正确性、一致性、相容性。
防止假如不合语义的数据。
方法：设置完整性检查，即对数据库中的数据设置一些约束条件。
作用对象：分为列、元组、关系三种级别，列：值的类型、范围、精度、排序，元组：各个属性间的约束（主键约束，外键约束）。
完整性约束条件的设置由用户通过完整性约束语句给出，完整性检查由数据库管理系统完成。
数据库并发控制：
数据库管理系统可以同时接纳多个失误，事务可以在时间上重叠执行，称为并发访问。
封锁技术：一段时间内进制某用户对数据对象做某些操作以避免产生数据不一致的问题。
排它锁x和共享锁s。
避免死锁：
同一顺序访问资源。
避免事务中的用户交互，由于用户相应不及时而造成事务长时间挂起就会产生死锁。
采用小事务模式，尽量缩短事务长度。
使用记录级别的锁（行锁），少用表级别的锁。
使用绑定连接。
不一致现象：
解决方法：基于封锁方法、基于撤回方法
事务：
一条或多条SQL语句的一次执行。
可串行性：一个调度对数据库的状态的影响都和某个串行调度相同
冲突：
什么是锁：
排它锁X：只有一个一个事务能读，写，其他事务不能读、写。
共享锁S：所有事务都可以读，但任何事务不能写。
更新锁U
增量所I
相容性（矩阵）：
有S锁，其他能申请S，不能申请X
有X锁，其他不能申请S和X
饿死：
数据项A现在有共享型锁，T1对数据项A申请排它锁，此时需要等待A上锁的释放，但是此时T2向A申请了共享型锁，因为是相容的，所以当A上刚开始的共享型锁释放后，T1还需等待T2，而此时，T3又向A申请了共享型锁……那么T1的加锁申请一直不能的得到满足，称饿死。
如何避免饿死？
假如T对Q申请的M型锁
1.不存在对Q持有与M不相容的锁
2.不存在等待Q加锁且先于T申请加锁的事务
这样，一个加锁申请就不会被其后申请加锁的事务所阻塞。
封锁协议（加/解锁时机）：
隔离性级别：
两段封锁协议：
对于每一个事务，在有加锁的地方前不能解锁，在有解锁的地方前加锁。
可保证冲突的可串行化。
可能产生死锁。
