几个概念&开篇一张图
-
Database system (DBS)
由一个相互关联的(interrelated)数据集合(collection) 和一组用于访问(access)这些数据的程序组成 -
database
也就是Interrelated data collection, -
DMBS主要目标
:提供一种高效、便利的途径,存取数据库数据。
-
Evaluation Engine
:评估引擎
1.DBS应用(Applications)
企业信息(Enterprise ) | 销售、会计、人力资源、生产制造… |
---|---|
银行金融 | 信用卡、交易、股票、贷款、客户… |
大学 | 学籍信息、课程、人力资源… |
航空 | 预定、时间表… |
电讯Telecommunication | 拨号记录、月度账单… |
… | … |
在早期,很少有人直接与数据库系统交互(Interact),
人们常常,间接地与数据库交互
- 在线书店并浏览书籍或音乐,存储在数据库中。
- 淘宝订单,存储在数据库中。
- 查询银行余额和交易信息,在数据库系统检索。
- …
2.DBS的目标(Purpose)
先来康康 Typical 文件处理系统
:
(70年代,数据库实质上是文件系统)
- 由传统(conventional)操作系统支持。
- 将永久记录(permanent records)存储在不同的文件中。
- 它需要不同的应用程序从相应的文件中提取记录,并向其添加记录。
它有几个主要的弊端disadvantages:
英文 | 中文 |
---|---|
Data redundancy and inconsistency. | 数据的冗余和不一致 |
Difficulty in accessing data. | 数据访问困难 |
Data isolation | 数据孤立 |
Integrity problems | 完整性问题 |
Atomicity problems. | 原子性问题 |
Concurrent-access anomalies | 并发性问题 |
Security problems | 安全问题 |
-
所谓数据孤立:
由于数据分散在不同的文件中,并且文件的格式可能不同,因此编写新的应用程序来检索适当的数据是很困难的。 -
所谓原子性:
当计算机down机时,要将数据库系统恢复到故障前的一致状态。
有些事件(比如转账,出账和到账的一致性),它必须完全发生,否则就根本不发生。在传统的文件处理系统中,很难保证原子性。 -
然而,这些困难,也不是一无是处。
At least,促进(prompt)数据库系统的发展。
3.数据视图(View of data)
-
回顾一下
数据库系统
:
是相互关联的数据
和一组允许用户访问和修改这些数据的程序的 集合。 -
而DBS主要目的,
是为用户提供数据的抽象视图。
也就是说,系统隐藏了数据存储和维护的某些细节。
3.1 数据抽象
首先提问:w&h?(why&how)
why is data abstract needed?
- 为了使系统可用、有效地检索数据。
- 为了提高效率,
- 简化(没有接受过计算机培训的)用户与系统的交互
- 为了用户不可访问某些details,安全性
And How to make it ?
- 设计人员使用复杂的数据结构来表示数据库中的数据。
- 开发人员通过几个抽象层次向用户隐藏复杂性
具体有这3个Levels的Abstractions
物理层 | 最低层次,抽象描述数据实际存储。详细描述复杂的底层数据结构。 |
---|---|
逻辑层 | 高一层次抽象。描述存储的数据,及之存在什么关系。逻辑层用户不需知道可能涉及的物理层结构。这被称为物理数据独立性(physical data independence)。 |
视图层 | 抽象的最高层次,但只描述了整个数据库的一部分。是为了简化用户与DBS的交互。系统可以为同一个数据库提供许多视图。 |
三种抽象的关系可以如图描述
View Level在一些教材中也称外模式
下面用(C++描述)结构体再说明这三级抽象。
struct Address {
char live_addr[100]; //住址
char home_addr[100]; //家乡
int postal_code; //邮编
};
struct student {
char name[20];
bool gender;
Address stu_addr;
};
在物理层,这个结构体数据(记录)可以描述为一个连续存储位置块
而编译器隐藏了这种级别的细节(对programmer隐藏)。
类似地,数据库系统隐藏了许多最低级的存储细节。
在逻辑层,这些记录类型的相互关系也被定义了。
而使用编程语言的程序员,在这个抽象层次上工作。
类似地,数据库管理员通常在这个抽象级别上工作。
最后在视图层,用户看到一组隐藏数据类型细节(逻辑级别的)的应用程序。
此外,视图层提供了一种安全机制,以防止用户访问数据库的某些部分。
3.2 实例和模式(Instances & Schemas)
Instances
:
在特定时刻(at a particular moment) 存储在数据库中的信息集合称为数据库实例
Schemas
:
数据库的总体设计(overall design) 称为数据库模式
- 三个层次的抽象&&三个层次的模式
根据抽象级别 → 模式划分。
物理模式在物理层描述数据库设计,
逻辑模式在逻辑层描述数据库设计。
在视图级还可能有几个模式(有时称为子模式),它们描述数据库的不同视图。 - 物理数据独立性&&物理模式
如果应用程序不依赖于物理模式,就具有物理数据独立性,
因此,如果物理模式发生变化,就不需要重写应用程序。
物理模式隐藏在逻辑模式之下,通常很容易更改,且不影响应用程序。 - 从对应用程序的影响的角度看,
逻辑模式最重要。因为程序员用逻辑模式构造应用程序
3.3 数据模型(Data Models).
数据库结构的底层是数据模型。
是 一组概念工具
:用于描述
- 数据、
- 数据关系(relationships)、
- 数据语义(semantics)
- 约束的一致性(consistency constraints)。
也就提供了:
在物理、逻辑和视图level描述数据库设计的方法。
接着,数据模型可分为四类:
- Relational Model关系模型
- Entity-Relationship Model实体关系模型
- Object-Based Data Model基于对象的数据模型
- Semistructured Data Model半结构化数据模型
- Older models: network model and hierarchical model Older models:
其他模型,网状,层次模型
关系模型使用一组表(表也称为关系)来表示数据以及这些数据间的关系。
绝大多数数据库系统都是基于关系模型的,是应用最广泛的数据模型
实体关系(E-R)模型使用一组称为实体的基本对象以及这些对象之间的关系。。实体-关系模型在数据库设计中被广泛使用
基于对象的数据模型可以看作是使用封装、方法(函数)和对象标识等概念来扩展的E-R模型
对象-关系数据模型结合了面向对象数据模型和关系数据模型的特性。
半结构化数据模型允许指定数据。相同类型的单个数据项可具有不同的属性集。与前面的数据模型相反,(特定类型的每个数据项,都必有相同属性集)。可扩展标记语言(XML)被广泛用于表示半结构化数据
小结:模型的分类
4.DB语言
先上两个定义:
数据定义(definition)语言 (DDL)
来指定(specify)数据库模式.数据操作(manipulation)语言(DML)
来表示(express)数据库查询和更新。
在实践中,二者不是两个独立的语言;
相反,它们只是单一数据库语言的一部分,
4.1 Data-Manipulation Language(DML)
- 允许用户访问或操作, 用合适的Data Model组织的的数据。
- 而访问(access)的类型是:
Modification of information stored in the database | 修改 |
---|---|
Retrieval of information stored in the database | 检索 |
Deletion of information from the database | 删除 |
Insertion of new information into the database | 插入 |
- 基本上有两种类型: (咋又分了两种类型,还不清楚)
Procedural DMLs (过程式,怎么作) | 要求用户指定需要的数据,以及如何获取这些数据 |
---|---|
Declarative DMLs (申明式/非过程式 非过程式,要什么) | 要求用户指定需要的数据,而不指定如何获取这些数据 |
查询(query) 是请求检索信息的语句(Statement)。
DML中涉及 信息检索的(retrieval) 部分称为 查询语言。
术语(term)查询语言 = 数据操作语言(尽管技术上是不正确的)。
- SQL,是使用最广泛的查询语言。
4.2 Data-Definition Language(DDL)
这DDL,不是
deadline
不用慌
DDL is used for~:
- 指定(specify)数据库模式(DB models)
- 指定数据的其他属性/特征(additional properties)
DDL中特殊的 data storage and definition language
is used for~:
- 指定DBS存储结构(storage structure)和访问方法(access methods)
- 这些语句定义了数据库模式的实现细节,
这些细节通常对用户是隐藏的
此外,存入数据库的数据值 必须满足一定的
一致性约束 consistency constraints
。
- 比如:账户余额绝不能是负数
- DDL提供了指定此类约束的工具。
- 数据库系统每次更新数据库时都会检查这些约束。
通常,约束可以是与数据库相关的 任意谓词(arbitrary predicate)
。
然而,测试任意谓词的 代价costly
可能很高。
因此,数据库系统实现的完整性约束(integrity constraints)
可以,用最小的开销进行测试:
Domain Constraints域约束 | … |
---|---|
Referential Integrity参照完整性 | … |
Assertions断言 | … |
Authorization授权 | … |
上表暂不做Statement
5.关系型DB(Relational DB)
关系数据库基于
Relational Model
,
使用一组表table
来表示数据以及这些数据之间的关系。
包括DML和DDL。
5.1 表(Tables)
先看一个table
看图说话:
每个表包含特定类型的记录。
每个表有多个列(Columns),每个列有一个唯一的名称
表的列对应于记录类型的属性(attributes)。
同时这里看到的是Logical Level 的Abstract:
不难看出表也许存储在文件中。
例如,可以使用一个特殊字符 (如逗号) 来分隔记录的不同属性.
所以:
关系模型对数据库开发人员和用户隐藏了底层实现细节。
基于记录的模型:
- 数据库的结构是多种类型的固定格式的记录,定义了固定数量的字段(fields)或属性(attributes)。
- 关系模型是基于记录的模型的一个例子(example)。
5.2 Data-Manipulation Language
这里是两个表: The instructor table、The department table
下面的SQL语句例子,查询的是这两个表
SQL查询语言是非过程性的。
查询接受(takes)多个表(也可能一个)作为输入
并且总是返回一个表
这是一个SQL查询的例子(1个表的输入):
看图说话:
- 查询指定部门名称(History)教员所在的表中的,那些行
- 检索历史记录,显示这些行的name属性值。
这是一个SQL查询的例子(2个表的输入):
看图说话:
…
5.3 Data-Definition Language
SQL提供了丰富的DDL,允许定义表、完整性约束、断言等。
例子:SQL DDL语句定义部门表
And then, a table is generated which is like the The department table above.
5.4 Database Access from Application Programs
应用程序访问数据库
因为:
SQL不支持用户输入、显示输出或网络通信等操作。
有一些计算可以使用通用编程语言进行,但使用SQL则不可能所以:
计算和操作必须用宿主(host)语言编写,如C、c++或Java,
并嵌入访问数据库中的数据的SQL,查询。
应用程序访问数据库,两种方法:
(1)调用API
API(standard) | 它可用于向数据库发送DML和DDL语句并检索结果。 |
---|---|
ODBC | Open Database Connectivity与C语言一起使的标准 |
JDBC | Java Database Connectivity与Java数据库连接的标准 |
(2)扩展宿主语言语法,在宿主语言程序中嵌入DML调用
上篇结束