这门学问的特点和定位^§1.0.1#

• 理论型？
  • 关系数据库理论　—　实际上是数学
  • 效率问题　—　很多理论空间：hash、map……
  • 数据挖掘
  • ……
• 应用型？
  • 搜索引擎 — Google、Baidu、几乎所有网站
  • 管理信息系统 — MIS、ERP……
  • 所有涉及到数据管理的领域的重要平台
    • 遗憾的是，少见能够把数据库结构设计做得很漂亮的人

各位在这门学问中的定位^§1.0.2#

• 毕业需要
  • no pass no degree ?
• 工作需要
  • 广泛的应用范围，导致了它广泛的实用价值
  • 可操作性强

一点建议^§1.0.3#

• 认清自己的目标
  • 兴趣是最好的老师
  • 如果没有兴趣……
• 方法建议
  • 基本概念要理解而不是记忆
    • 要知所以其然而不是仅仅知其然 → 举一反三
  • 练习: 自己动手才有效果
    • 实践、实践、实践
    • 重复一遍对大家有好处：实践、实践、实践

NECESSITY is the mother of INVENTION^§1.9.0#

• 需求：数据管理和处理任务
  • 数据管理
    • 对数据进行分类、组织、编码、存储、检索
  • 数据处理
    • 对数据进行收集、存储、加工、传播
• 两次数据危机
  • 20世纪60年代
    • 美国陆地卫星，阿波罗计划等催生了数据库系统。
  • 80-90年代
    • 人类基因组计划，web数据大量增加等促成了数据挖掘技术的产生。

几个具有代表意义的事件^{* §1.9.0}#

Ted Codd
Turing Award 1981

• 1969 IBM IMS 层次数据库
• 60年代末到70年代初的CODASYL下的DBTG 网状数据库模型
• 1970 E.F.Codd. “大型共享数据库数据的关系模型” 关系数据库模型
• 80年代中期以后，对象－关系模型

20世纪50年代和60年代初^{* §1.9}#

• 数据处理使用磁带进行存储
  • 磁带仅提供顺序存取(sequential access)
• 打孔卡带

20世纪60年代末和70年代^{* §1.9}#

• 硬盘：允许直接访问（direct access）数据
• 网状和层次数据模型
• Ted Codd 提出了关系（relational）数据模型
  • 凭借这项工作获得ACM图灵奖
  • IBM 研究院启动 System R 原型
  • 加州大学伯克利分校开始Ingres prototype
• 高性能事务处理

20世纪80～90年代^{* §1.9}#

• 80年代
  • 关系原型演变为商业系统
    • SQL成为行业标准
  • 并行和分布式数据库系统
    • Wisconsin, IBM, Teradata
  • 面向对象的数据库系统
• 90年代
  • 大型决策支持(decision support)和数据挖掘(data-mining)应用程序
  • 数据仓库：大型TB级数据
  • 网络/电子商务登场

21世纪00～10年代^{* §1.9}#

• 00年代
  • Big data storage systems
    • Google BigTable, Yahoo PNuts, Amazon
    • “NoSQL” systems.
  • Big data analysis: beyond SQL
    • Map reduce and friends
• 10年代
  • SQL 前端到 Map Reduce
  • 大规模并行数据库系统
  • 多核主内存数据库

应用行业^§1.1#

• 企业信息管理
  • 销售：客户、产品、采购
  • 会计：付款、收款、资产
  • 人力资源：有关员工、工资、工资税的信息
• 制造业:生产、库存、订单、供应链管理
• 银行和金融业
  • 客户信息、账户、贷款和银行交易。
  • 信用卡交易
  • 金融：金融工具(如股票、债券)销售和购买; 实时市场数据存储
• 大学: 注册, 成绩管理
• 航空业：预订、时刻表
• 电信业：记录通话，短信和数据使用，生成月度账单，维护预付费电话卡的余额
• 在线服务
  • 在线零售商：订单跟踪，个性化推荐
  • 在线广告
• 文档数据库
• 导航系统
  • 不同景点的位置及道路，火车系统，公共汽车路线……

应用方式^§1.1#

实际应用中最常见的数据库使用方式有两种

• 联机事务处理 / OnLine Transaction Processing
  • 并发量大、请求频次高
  • 单次请求数据量小、响应时间短
  • 一般是日常业务，如：收银
• 联机数据分析 / OnLine Analytics Processing
  OnLine Data Analytics
  • 并发量小、请求频次低
  • 单次请求数据量大、响应时间长
  • 一般是汇总分析，如：年终汇总、决策支持、数据挖掘

数据管理-人工阶段^§1.2#

[ 环境条件 ] |---|---| |时间|20世纪50年代中期前| |硬件|外存：卡片、纸带、磁带| |软件|汇编语言| |处理方式|数据批处理|

• 数据不进行保存
  计算时输入，用完撤走
• 没有专门的数据管理软件
  程序自己管理存储结构、存取方法、输入方式……
• 数据不共享
  程序之间无统一定义
• 数据不独立
  数据存储或逻辑结构变化将导致程序变化

数据管理-文件系统阶段^§1.2#

[ 环境条件 ] |—|--------| |时间|20世纪50年代末到60年代中期| |硬件|磁盘．磁鼓等直接存取的外存设备| |软件|操作系统、高级语言、OS中的文件系统是专门用于数据管理的软件（DOS）| |处理方式|文件批处理、联机实时处理|

• 数据可长期保存
  文件系统管理数据
• 数据共享性差，冗余大
  不同应用，对文件数据结构定义不同
• 数据存储结构独立性得到实现
  程序不需关心具体物理设备差异
• 数据逻辑结构独立性差
  逻辑结构变化将导致程序变化

文件系统在数据管理上的问题^§1.2#

• 数据冗余(redundancy)和不一致(inconsistency)
  • 多种文件格式、不同文件中的信息重复
• 访问数据困难
  • 需要编写新程序来执行每个新任务
• 数据孤立(isolation) — 多个文件和多种格式
• 完整性(Integrity)问题
  • 完整性约束（例如，帐户余额> 0）在程序代码中变得“埋没”，而不是明确说明
  • 难以添加新约束或更改现有约束
• 更新的原子性(Atomicity)
  • 故障可能会使数据库处于与执行部分更新不一致的状态
  • 示例：资金从一个账户转移到另一个账户应该完成或根本没有发生
• 多个用户并发访问
  • 性能所需的并发访问
  • 不受控制的并发访问可能导致不一致
    • 示例：两个人读取余额（假设100）并通过同时取款（假设每个50）
• 安全问题
  • 很难为用户提供对某些（但不是全部）数据的访问权限

数据管理-数据库系统阶段^§1.2#

[ 环境条件 ] |---|---| |时间|20世纪60年代后期| |硬件|大容量的磁盘（硬件价格下降）| |软件|软件开发成本提高（冗余的工作显得昂贵）| |处理方式|联机实时处理|

• 数据结构化
• 共享性高，冗余小，易扩充
• 数据独立性高
• 由DBMS统一管理控制

View of Data -概念,逻辑,符号系统^§1.3.0#

• 概念决定论
  • “所有答案都在定义中”
  • 概念是基石，不同的概念导致不同的理论，所以概念很重要！
  • “符号”“符号系统”“归纳化→概念化→抽象化”
• 逻辑
  • 本能？理智？感性？希尔伯特vs哥德尔定理
  • 对角线原理、皇帝新脑、人工智能、逻辑……（命题：悖论问题）

定义数据库系统 – data,DB,DBMS,DBS^§1.3.0#

• 数据（Data）
  • 数据：描述事物的符号记录
  • 语义（semantic）：数据的含义（实际的价值和意义）
    • 价值→价值判断(立场)
• 数据库（Database, DB）
  • 数据集合：长期储存、有组织、可共享
  • 小冗余、高独立性、易扩展
• 数据库管理系统（DBMS）
  • 数据组织、存储、管理
  • 数据定义(DDL), 数据操纵(Data Manipulation Language)
  • DB的事务和运行管理：安全性、完整性
  • DB的建立和维护（一些实用程序）
• 数据库系统（DBS）
  • 硬件→OS→DBMS→应用程序

模型、数据模型^§1.3.1.0#

• 模型(Model):
  现实世界特征的模拟和抽象
  • 模型就是世界观 → 建模过程就是形成世界观的过程
• 数据模型(Data Model):
  现实世界数据特征的模拟和抽象
  • 数据模型就是计算机系统的世界观
  • 逻辑模型：按计算机系统的观点对数据的建模，主用于DBMS的实现，如：层次、网状、关系等。
  • 物理模型：对数据最底层的抽象，描述数据在系统内部的表示方式和存取方法。

关系模型-直观感受^§1.3.2#

所有数据存放在多个 表（table）中，如：

[instructor]

[department]

层次模型(Hierarchical Model)^{* §1.3.2.0}#

网状模型(Network Model)^{* §1.3.2.0}#

网状模型-优缺点^{* §1.3.2.0}#

• 更真实的模拟
• 良好的性能
• 结构复杂
• DDL,DML语言复杂
  

数据抽象层次Data Abstraction Level^§1.3.3#

• 物理层 Physical level
  • 最低层次抽象，描述数据在“物理设备”中的存储结构
  • 又名：内模式(Internal schema),存储模式(Storage schema)
• 逻辑层 Logical level
  • 中层抽象，描述在“逻辑设备(数据库)”中的存储结构
  • 又名：模式(Schema),概念模式(Concept schema)

  1
  type instructor = record
  2
    ID : string;
  3
    name : string;
  4
    dept_name : string;
  5
    salary : integer;
  6
  end;

• 视图层 View level
  • 提供给应用的抽象描述，模式的子集，有重命名能力（昵称）
  • 又名：外模式(External schema),子模式(Subschema)
• 数据库系统(DBS)的三个抽象层
  • DBS的物理设备是文件，一个DB只能有一种内模式（存储方式）
  • DBS的逻辑设备就是DB，一个DB只能有一种模式（逻辑结构）
  • 一个DB可以有多个外模式（视图）供程序使用

数据定义语言/Data Definition Language(DDL)^§1.4.1#

• 用于定义数据库模式(database schema)

  1
  create table instructor (
  2
    ID      char(5),
  3
    name    varchar(20),
  4
    dept_name  varchar(20),
  5
    salary    numeric(8,2)
  6
  );

• DDL定义的模式存储在 数据字典(data dictionary)中
• 数据字典包含“元数据(metadata)” - 描述数据的数据
  • 数据库模式(Database Schema)
  • 完整性约束(Integrity constraints)
    • 域约束(domain constraints) - 类似数据类型，如：整数、字符串…
    • 引用完整性(referential integrity) - 不能引用不存在的东西
  • 授权(Authorization) - Who can do what on what

数据操纵语言Data Manipulation Language(DML)^§1.4.3#

• 访问和修改数据库中的数据的语言
  • Query, Insert, Delete, Update
  • 涉及到信息检索的部分称作查询语言(query language)
• DML有两种类型
  • 过程化的/Procedural
    需用户指定获取什么数据，以及如何获取
  • 声明式的/Declarative(非过程化的/nonprocedural)
    只需指定获取什么数据，不必指明如何获取
• SQL 是最常用的DML

应用程序访问数据库^§1.4.5#

• 应用程序需要
  • 将DDL、DML发送到数据库系统（Database System）
  • 应用程序需要获得DBS的执行结果
• DBS提供API给应用程序调用
  • ODBC: C,C++,其它一些应用的DB API
  • JDBC: java

数据库结构#

• Centralized databases
  • One to a few cores, shared memory
• Client-server
  • One server machine executes work on behalf of multiple client machines.
• Parallel databases
  • Many core shared memory
  • Shared disk
  • Shared nothing
• Distributed databases
  • Geographical distribution
  • Schema/data heterogeneity

数据库应用的结构#

Database applications are usually partitioned into two or three parts

• Two-tier architecture
  the application invokes database system functionality directly

• Three-tier architecture the client acts as a front end and does not contain any direct database calls
  • The client communicates with an server, usually through a forms interface
  • The server in turn communicates with a database system to access data