网络数据库原理及应用 主讲：刁仁宏.

Presentation on theme: "网络数据库原理及应用 主讲：刁仁宏."— Presentation transcript:

1 网络数据库原理及应用 主讲：刁仁宏

2 联系方式 [声明:以上信息不得再向我询问] Tel:028- 13438142532
群号码: 课件密码:123456 [声明:以上信息不得再向我询问] 2005年9月 第2页

3 教学目的 了解数据库技术的发展方向。 深入理解数据库系统的基本概念。
掌握数据库设计的一般方法，能够使用MS SQL Server进行数据库设计。 初步具备进行数据库应用系统设计开发的能力。 2005年9月 第3页

4 教学计划 第1章 数据库理论基础 2学时 第2章 SQL Server 2000安装和常用工具 2学时
第1章 数据库理论基础              2学时 第2章 SQL Server 2000安装和常用工具 2学时 第3章 Transact-SQL语言基础   2学时 第4章 数据库基本对象操作和管理   2学时 第5章 数据的查询和修改    2学时 第6章 实施数据完整性        2学时 第7章 数据库高级对象操作和管理 2学时 第8章 数据库系统的安全性管理 2学时 第9章 应用系统实例 学时 上机实习(时间具体通知) 学时 2005年9月 第4页

5 第1章 数据库理论基础 教学内容： 数据库发展简史 数据库、数据库管理系统、数据库系统 数据库系统的结构 数据库设计过程数据库设计过程
关系数据库设计的规范化和非规范化 数据库应用结构 2005年9月 第5页

6 1.1 数据库发展简史 数据库系统的萌芽出现于60年代。当时计算机开始广泛地应用于数据管理，对数据的共享提出了越来越高的要求。传统的文件系统已经不能满足人们的需求了，能够统一管理和共享数据的数据库管理系统（DBMS）应运而生。 按照数据模型的特点将传统数据库系统分成网状数据库、层次数据库和关系数据库三类。 网状DBMS（1961年、通用电气公司、集成数据管理系统（IDMS）） 层次型DBMS ，IBM公司在1968年开发的IMS（Information Management System） 2005年9月 第6页

7 1.1.2 关系数据库的由来 网状数据库和层次数据库已经很好地解决了数据的集中和共享问题，但数据的独立性和抽象有很大缺陷。用户在对这两种数据库进行存取数据时，仍然需要明确数据的存储结构，指出存取路径。关系数据库能较好地解决了这些问题。 1969年E.F. Codd发明了关系数据库。 1976年霍尼韦尔（Honeywell）公司开发了第一个商用关系数据库系统——Multics Relational Data Store。 2005年9月 第7页

8 1.1.3 结构化查询语言 Structured Query Language，结构化查询语言 。SQL语言的功能包括查询、操纵、定义和控制，是一个综合的、通用的关系数据库语言，同时又是一种高度非过程化的语言，只要求用户指出做什么而不需要指出怎么做。 SQL-89标准 SQL-92标准 SQL3标准 2005年9月 第8页

9 1.1.4 面向对象数据库 主要设计思想是企图用新型数据库系统来取代现有的数据库系统。 一般把数据库系统分为三代：
支持层次模型和网状模型的第一代数据库系统。 支持关系模型的第二代数据库系统。 支持面向对象的数据模型的第三代数据库系统。 2005年9月 第9页

10 1.2 数据库管理系统和数据库系统 1.2.1 文件管理系统 图1-1 文件管理系统示例 玩具基本信息管理 应用程序App1 购物者购买玩具管理 应用程序App2 玩具信息文件File1 购物者信息文件File2 订单信息文件File3 购物者购买玩具，先查找文件File2，判断此用户是否合法；如果合法则访问File1，判断有无此玩具；如果也有， 则将订单信息写到文件File3中 2005年9月 第10页

11 1.2.2 数据库管理系统(DBMS) 数据库(DB) 数据库是存放数据的“仓库”,是相关数据(计算机中表达信息的符号)的集合
数据库是以一定的数据结构形式存储在一起的相互有关的具有冗余数据少、共享性、独立性、完整性等特点的数据集合 粮库 Database Table 粮仓 2005年9月 第11页

12 1.2.2 数据库管理系统(DBMS) 用户与操作系统之间的一组数据管理软件，它们能组织、存储、维护、获取数据等。 应用程序App1
图1-2 数据库管理系统示例 玩具基本信息管理 应用程序App1 购物者购买玩具管理 应用程序App2 数据库管理系统 数据库 用户与操作系统之间的一组数据管理软件，它们能组织、存储、维护、获取数据等。 2005年9月 第12页

13 1.2.2 数据库管理系统(DBMS) 一个数据库管理系统应该具备如下功能：
数据定义功能：定义数据的结构、数据与数据之间的关联关系、数据的完整性约束等； 数据操纵功能：实现对数据库中数据的操纵，包括插入、删除和修改数据； 数据查询功能：实现灵活的数据查询功能，使用户可以方便地使用数据库中的数据； 数据控制功能：实现对数据库数据的安全性控制、完整性控制等各方面的控制功能； 数据管理功能：实现数据库的备份和恢复； 数据通信功能：在分布式数据库或提供网络操作功能的数据库中还必须提供数据的通信功能。 还有性能优化、并发控制等 2005年9月 第13页

14 1.2.3 数据库系统（DBS） 由数据库（DB）、数据库管理系统（DBMS）、应用系统（Application）、数据管理员（DBA）和用户（USER）组成 DB：是集成的、结构化的Data的集合，是DBMS的管理对象 DBMS：是DBS的核心软件，负责对DB的使用、控制和管理 USER：管理和使用DB的人员 DBA：设计、管理和使用DB的人员 Application：是应用DB中的Data的一些软件 2005年9月 第14页

15 1.2.3 数据库系统（DBS） 数据库 数据库管理系统 (Database) （DBMS） 数据库管理员（DBA）
用户（user） 数据库 (Database) 数据库管理系统 （DBMS） 应用程序 Application 数据库管理员（DBA） 用户（user） 图1-3 数据库系统组成 2005年9月 第15页

16 1.2.3 数据库系统（DBS） 硬件 应用系统 DBMS，编译系统 操作系统 数据库系统软硬件层次 .net，VB，VC DELPHI
应用开发工具软件 应用系统 .net，VB，VC DELPHI SQL Server， Oracle，Db2 数据库系统软硬件层次 2005年9月 第16页

17 1.3 数据库系统的结构 三级模式结构 内模式（存储模式）是最接近物理存储的，也就是数据的物理存储方式；
描述数据库的物理存储结构 由DBMS提供的工具或语言完成 模式（逻辑模式、概念模式）是介于内模式和外模式之间的中间层次。描述的是数据的全局逻辑结构 . 现实世界中数据库用户的数据抽象 描述整个数据库的结构 着重描述实体、属性、关系和约束 外模式（子模式、用户模式）是最接近用户的，也就是用户所看到的数据视图；描述的是数据的局部逻辑结构 。 描述特定用户组感兴趣的那部分的数据库 2005年9月 第17页

18 1.3 数据库系统的结构 模式 内模式 外模式1 数据库DB 应用A 数据库系统的三级模式结构 外模式2 外模式N 外模式 应用B 应用C
（公共用户视图） 数据库系统的三级模式结构 外模式2 外模式N （存储视图） （单个用户视图） 外模式 应用B 应用C 应用M 应用N 2005年9月 第18页

19 1.3 数据库系统的结构 三级模式结构的优点 保证数据的独立性 简化了用户接口 有利于数据共享 利于数据的安全保密 2005年9月 第19页

20 1.3.2 数据库的二级模式映像功能 数据库管理系统在三个模式之间提供了两层映像： 外模式/模式映像 模式/内模式映像
定义了该外模式与模式之间的对应关系。通常包含在各自的外模式描述中。 模式/内模式映像 数据库的逻辑结构与存储结构之间的对应关系，该映像通常包含在模式描述中 。 2005年9月 第20页

21 1.4 数据库设计过程 现实世界 认识抽象 转换 计算机支持的数据模型 E-R图 信息世界 图1－6 数据库的设计过程
2005年9月 第21页

22 1.4.1 数据和数据模型 数据是信息存在的一种形式，只有通过解释或处理才能成为有用的信息 . 数据的静态特征 数据的动态特征
包括数据的基本结构、数据间的关系和对数据取值范围的约束。 数据的动态特征 对数据可以进行的操作以及操作规则。对数据库数据的操作主要有查询数据和更改数据 2005年9月 第22页

23 1.4.1 数据和数据模型 模型是现实世界特征的模拟和抽象。 数据模型（Data Model）也是一种模型，它是对现实世界数据特征的抽象。
概念层数据模型。信息世界的概念。 也称为概念模型或信息模型，它是从数据的应用语义视角来抽取模型并按用户的观点来对数据和信息进行建模。这类模型主要用在数据库的设计阶段，它与具体的数据库管理系统无关。 组织层数据模型。计算机世界的概念。是数据库系统的核心和基础。 层次模型（用树型结构组织数据）。 网状模型（用图形结构组织数据）。 关系模型（用简单二维表结构组织数据）。 对象关系模型（用复杂的表格以及其他结构组织数据）。 2005年9月 第23页

24 现实世界中的客观事物的抽象过程 现实世界 概念模型 DBMS支持的数据模型 信息世界 计算机世界 认识抽象 转换

25 1.4.1 数据和数据模型 数据模型包括： 数据结构。对系统静态特性的描述。 数据操作。操作及有关的操作规则。 数据完整性约束。
一类是与数据类型、内容、性质有关的对象，比如关系模型中的域、属性和关系等； 另一类是与数据之间关系有关的对象，它从数据组织层表达数据记录与字段的结构。 数据操作。操作及有关的操作规则。 数据检索：在数据集合中提取用户感兴趣的内容，不改变数据结构与数据值。 数据更新：包括插入、删除和修改数据，此类操作改变数据的值。 数据完整性约束。 是一组完整性规则的集合。 2005年9月 第25页

26 1.4.2 概念层数据模型 常用的概念模型是实体——关系（Entity-Relationship，简称E-R）模型。
用于信息世界的建模 ，是面向用户、面向现实世界的数据模型，它与具体的DBMS无关。 常用的概念模型是实体——关系（Entity-Relationship，简称E-R）模型。 主要涉及三个概念：实体、属性和关系。 2005年9月 第26页

27 1.4.2 概念层数据模型 1.实体（Entity） 实体是具有相同性质并且彼此之间可以相互区分的现实世界对象的集合。
在关系数据库中，一般一个实体被映射成一个关系表，表中的一行对应一个可区分的现实世界对象（这些对象组成了实体），称为实体实例（entity instance）。 在E-R图中用矩形框表示具体的实体，把实体名写在框内。 2005年9月 第27页

28 1.4.2 概念层数据模型 2．属性（Attribute） 实体所具有的特征称为它的属性。是描述实体或者关系（在下面说明）的性质的数据项。
每个实体都有一个标识符（或叫实体的键），标识符是实体中的一个属性或者几个属性的组合，每个实体实例在标识符上具有不同的值。 在E-R图中用椭圆表示属性，椭圆内写上属性名。 2005年9月 第28页

29 1.4.2 概念层数据模型 3．关系（Relationship ） 实体内部的关系 不同实体之间的关系
组成实体的各属性之间的关系 。如“职工”实体中，假设有“职工号”和“部门经理号” 。 不同实体之间的关系 例。“玩具”实体（设有属性：ID号、名称、价格、重量、商标ID）和“商标”实体（设有属性：商标ID、商标名称、商标说明）之间的“商标ID” 关系用菱形框表示，框内写上关系名，并用连线将有关的实体连接起来。 2005年9月 第29页

30 1.4.2 概念层数据模型 关系有三种类型: 一对一（1:1） 一对多（1:n） 多对多（m:n） 1 n m 管理 玩 具 部 门 有
玩 具 部 门 有 购买 （a） （b） （c） 经 理 商 标 购物者 2005年9月 第30页

31 1.4.2 概念层数据模型 p n m 顾 客 玩 具 购买 图1－9 多个实体之间的关系示例 销售人员 2005年9月 第31页

32 1.4.2 概念层数据模型 用矩形表示实体，矩形框内写上实体名。 实体的属性用椭圆表示，椭圆内写上属性名，并用无向边与其实体相连。 学生
学号 姓名 性别 系 入学时间 2005年9月 第32页

33 1.4.2 概念层数据模型 关系（实体间的联系） 教学 教师 学生 1 N 用菱形表示,关系以适当的含义命名，名字写在菱形框中;
用无向连线将参加相应联系的实体矩形框分别与菱形相连; 并在连线上标明联系的类型，即1:1,1:N或N:M 如联系具有属性，也要用无向边与该联系连接起来 学号 姓名 工号 姓名 教学 教师 学生 1 N 2005年9月 第33页

34 1.4.2 概念层数据模型 E-R图的画法 确定系统中的实体 确定每个实体的属性 确定实体间的关系 2005年9月 第34页

35 E-R图的画法 确定每个实体的属性 学号 系 姓名 课程名称 课程号 学生 课程 性别 入学时间 2005年9月 第35页

36 E-R图的画法 确定实体间的关系 学习 M N 学生 课程 成绩 2005年9月 第36页

37 E-R图的画法 课程名称 学号 系 姓名 课程号 M 学习 N 学生 课程 性别 入学时间 成绩 2005年9月 第37页

38 练习 用E-R图描述图书信息管理的数据模型
每个借书人有姓名、借书证号和单位属性，每个借书人可以借5本书，每本图书有总编号、分类号、书号、作者、定价和位置属性，同一本书可以相继被几个人借阅。 2005年9月 第38页

39 总编号 分类号 书号 作者 定价 位置 图书 借书人 姓名 结书证号 单位 借书 时间
m n 时间

40 1.4.3 组织层数据模型 1.层次模型 用树结构表示实体之间联系的模型叫层次模型。
树由节点和连线组成，节点代表实体型，连线表示两实体型间的一对多联系。 树有以下特性： 每棵树有且仅有一个节点无父节点，此节点称为树的根（Root）。 树中的其它节点都有且仅有一个父节点 2005年9月 第40页

41 1.4.3 组织层数据模型 层次模型示意图 2005年9月 第41页

42 科室 医生 病房 病人 1.4.3 组织层数据模型 2.网状模型 是一个满足下列条件的有向图 可以有一个以上的节点无父节点。
至少有一个节点有多于一个的父节点（排除树结构）。 科室 医生 病房 病人 2005年9月 第42页

43 1.4.3 组织层数据模型 3.对象关系模型（用复杂的表格以及其他结构组织数据） 引入对象的观念。如：
InterSystems 公司的Caché数据库 SQL Server的table 数据类型 Oracle的大型对象数据类型 2005年9月 第43页

44 1.4.3 组织层数据模型 4. 关系模型 表示实体以及实体之间关系的模型称为关系数据模型 用二维表来表示实体及其相互联系 字段 记录
2005年9月 第44页

45 1.4.3 组织层数据模型 关系模型中的基本术语 关系(表) 元组(行) 属性(列)
关系就是二维表 ，每一列不可再分 ，属性不能重名 ，可交换列的前后顺序 。 元组(行) 表中的每一行数据称作是一个元组 属性(列) 表中的每一列是一个属性值集，列可以命名，称为属性名 。 2005年9月 第45页

46 1.4.3 组织层数据模型 关系模型中的基本术语 主键（PK） 外键（FK） 域 用于惟一的确定表中的一个元组。
当一个表的主键在另一个表中作为一个属性存在时，它就在另外一个表中被称作是外键，外键是可以重复的。 域 属性的取值范围就称为域。 2005年9月 第46页

47 1.4.3 组织层数据模型 关系模型的数据操作 关系模型的操作对象是集合，而不是行，也就是操作的对象以及操作的结果都是完整的表（行的集合，而不只是单行，当然，只包含一行数据的表是合法的，空表或不包含任何数据行的表也是合法的）。 查询、插入、删除和修改四种操作。 2005年9月 第47页

48 1.4.3 组织层数据模型 关系模型的数据完整性约束 实体完整性 引用完整性 域完整性 用户自定义完整性 2005年9月 第48页

49 1.4.3 组织层数据模型 (1) 实体完整性 指的是关系数据库中所有的表都必须有主键，而且表中不允许存在如下的记录。
无主键值的记录 主键值相同的记录 关系模型中使用主键作为记录的惟一标识 。在关系数据库中主属性不能取空值。 关系数据库中的空值是特殊的标量常数，它既不是“0”，也不是没有值，它代表未定义的或者有意义但目前还处于未知状态的值。数据库中的空值用“NULL”表示。 2005年9月 第49页

50 1.4.3 组织层数据模型 (2)引用完整性（参照完整性 ）
引用完整性一般是指多个实体或关系表之间的关联关系。 一个表中某列的取值受另一个表的某列的取值范围约束的特点就称为引用完整性。 在关系数据库中用外键（Fk)来实现引用完整性。 例1-1 “玩具”表和“种类”表所包含的属性如下，其中主键用下划线标识。 玩具(玩具ID，名称，种类ID，价格，重量，产地) 种类(种类ID，种类，描述) 2005年9月 第50页

51 1.4.3 组织层数据模型 (3)域完整性 (4)用户自定义完整性
域完整性或语义完整性。确保了只有在某一合法范围内的值才能存储到一列中。可以通过限制数据类型、值的范围和数据格式来实施域完整性。 (4)用户自定义完整性 是针对某一具体应用领域定义的数据约束条件，它反映某一具体应用所涉及的数据必须要满足应用语义的要求。 2005年9月 第51页

52 1.4.4 E-R模型转化为关系模型 三个世界术语对应 现实世界 信息世界 计算机世界 事物总体 实体集 表 事物的个体 实体 记录 特征
属性 字段 事物之间的联系 E-R模型 数据模型 2005年9月 第52页

53 1.4.4 E-R模型转化为关系模型 将实体转换表 注意表的命名规范 信息世界 机器世界 实体 表 属性 表的列（字段）
信息世界 机器世界 实体 表 属性 表的列（字段） 实例 表的行（记录） 码 表的某列（键） 注意表的命名规范 2005年9月 第53页

54 1.4.4 E-R模型转化为关系模型 将关系映射成一个表
一个1：1关系可以转换为一个独立的关系表，也可以与任意一端所对应的关表合并。例1-2。 一个1：n关系可以转换为一个独立的表，也可以与n端所对应的表合并。例1-3 。 一个m：n关系转换为一个表。与该关系相连的各实体的关键字以及关系本身的属性均转换为该表的属性，新表的关键字包含各实体的关键字，同时新表中各实体的关键字为引用各自实体的外关键字。例1-4 。 3个或3个以上实体间的一个多元关系可以转换为一个表。与该多元关系相连的各实体的关键字以及关系本身的属性均转换为此表的属性，而此表的关键字包含各实体的关键字，同时新表中的各实体的关键字为引用各自实体的外关键字。 具有相同码的表可以合并。 2005年9月 第54页

55 E-R模型转换关系模型示例1-2 部门表(部门号(PK)，部门名，经理号(FK))。 经理表(经理号(PK) ，经理名，电话)。
管理 部 门 经 理 经理ID 姓名 部门ID 部门名 部门表(部门号(PK) ，部门名) 。 经理表(经理号(PK) ，部门号(FK)，经理名，电话) 。 部门表(部门号(PK) ，部门名) 。 经理表(经理号(PK) ，经理名，电话)。 部门－经理表(经理号(FK) ，部门号(FK))。 2005年9月 第55页

56 E-R模型转换关系模型示例1-3 商标表(商标ID (PK) ，商标名) 。 玩具表(玩具ID (PK) ，玩具名，商标ID (FK) )。
n 1 玩 具 有 商 标 玩具ID 玩具名 单价 商标ID 商标名 商标表(商标ID (PK) ，商标名) 。 玩具表(玩具ID (PK) ，玩具名，商标ID (FK) )。 商标表(商标ID (PK) ，商标名) 。 玩具表(玩具ID (PK) ，玩具名，单价，产地 ) 。 商标－玩具表（商标ID (FK) ，玩具ID (FK) ） 2005年9月 第56页

57 E-R模型转换关系模型示例1-4 购物者表（购物者ID（PK），购物者名，性别，地址）。 玩具表(玩具ID （PK），玩具名，单价，产地)。
购物者－玩具表（购物者ID，玩具ID，数量）其中（购物者ID，玩具ID）为组合主键，同时也为引用购物者表和玩具表的外键 。 n m 玩 具 购买 购物者 购物者名 玩具ID 玩具名 单价 购物者ID 数量 2005年9月 第57页

58 1.5关系数据库设计的规范化和非规范化 如果修改一个学生的地址,就需要修改和那个学生相关的多行内容，否则将引起数据的不一致。
表1-4 带数据示例的表 学号 姓名 …… 学期 数学 英语 张三 1 40 65 2 56 48 李四 93 84 85 90 如果修改一个学生的地址,就需要修改和那个学生相关的多行内容，否则将引起数据的不一致。 更新异常—— 插入、修改、删除数据可能导致不一致性。 不一致性—— 数据重复时，更容易引发错误。 无谓地占用额外的磁盘空间。 2005年9月 第58页

59 1.5关系数据库设计的规范化和非规范化 要设计出一个好的数据库，应该遵循下列规则： 每张表中都应有一个标识列。
每张表中只能存放一种实体的数据。 应避免接收带有NULL值的列。 应避免值或列的重复。 2005年9月 第59页

60 1.5.1 规范化设计 规范化将导致满足某些特定规则并代表某些范式的表的形成。 范式用于确保数据库中不存在各种类型的异常和不一致。
表结构总是属于某个特定的范式。 各范式之间的关系 非规范化关系 1NF 2NF 3NF BCNF …… 2005年9月 第60页

61 1．第一范式（1NF） 当表中的每个单元含且仅含一个值时，这个表叫做第一范式（1 NF）。 Ecode Dept ProjCode
Hours E101 Systems P27 P51 P20 90 101 60 E305 Sales P22 109 98 E508 Admin NULL 72 当表中的每个单元含且仅含一个值时，这个表叫做第一范式（1 NF）。 Ecode Dept ProjCode Hours E101 Systems P27 90 P51 101 P20 60 E305 Sales 109 P22 98 E508 Admin NULL 2005年9月 第61页

62 1.5.1 规范化设计 函数依赖 给定一个关系（你可以称其为表，也可以称其为关系）R，如果R中A的每个值都与B的某个确定值相对应，则属性A函数依赖于B。换句话说，当且仅当对于B的每个值都能够在A中找到一个确定的值时，属性A函数依赖于B。属性 B称为决定因子。 Code Name City E1 Mac Delhi E2 Sandra CA E3 Henry Paris 2005年9月 第62页

63 2．第二范式（2NF） 当一个表是1 NF 且一行中的每个属性都依赖于整个关键字（不仅仅是关键字的一部分）时，该表就可以称作第二范式。
Ecode ProjCode Dept Hours E101 P27 Systems 90 E305 Finance 10 E508 P51 Admin NULL 101 P20 60 72 2005年9月 第63页

64 2．第二范式（2NF） EmployeeDept Project ECode Dept ProjCode Hours E101
Systems P27 90 E30 Sales P51 101 E50 Admin P20 60 E305 10 E508 NULL 72 2005年9月 第64页

65 3．第三范式（3NF） 当一个关系是2 NF，且其中的每个非关键字属性仅函数依赖于主关键字时，这样的关系称为3 NF。 Ecode Dept
DeptHead E101 Systems E901 E305 Finance E906 E402 Sales E508 Admin E908 E607 E909 E608 2005年9月 第65页

66 3．第三范式（3NF） 表1-11（a） Employee 表1-11（b）Department ECode Dept DeptHead
Systems E901 E305 Finance Sales E906 E402 Admin E908 E508 E909 E607 E608 2005年9月 第66页

67 1.5.2非规范化设计 规范化的最终产物是一系列相关的表，这些表构成了数据库。但有的时候，为了得到简单的输出，你得连接多个表。这影响了查询的性能。在这种情况下，更明智的做法是引入一定程度的冗余，包括引入额外的列或额外的表。为了提高性能，在表中故意引入冗余的做法称为非规范化 在下列情况下可以考虑进行非规范化处理： 大量频繁的查询过程所涉及的表都需要进行连接。 主要的应用程序在执行时要将表连接起来进行查询。 对数据的计算需要临时表或进行复杂的查询。 2005年9月 第67页

68 1.6 数据库应用结构 1.6.1 客户机/服务器结构 2005年9月 第68页

69 1.6.1 客户机/服务器结构 Client/Server体系结构 由多个用户共享的信息和功能，称为服务器。 每个用户所专有，称为客户。
执行后台服务，如管理共享外设、控制对共享数据库的操纵、接受并应答客户机的请求等。 每个用户所专有，称为客户。 负责执行前台功能，如管理用户接口、数据处理和报告请求等。 优点 将一个应用系统分成两大部分，由多台计算机分别执行，使它们有机的结合在一起，协同完成整个系统的应用，从而达到系统中软、硬件资源最大限度的利用。 2005年9月 第69页

70 1.6.2互联网应用结构 2005年9月 第70页

71 1.7 小结 数据库发展简史 数据库管理系统和数据库系统 数据库系统的结构 数据库设计过程 关系数据库设计的规范化和非规范化 数据库应用结构
文件管理系统 数据库管理系统 数据库系统 数据库系统的结构 三级模式结构 数据库的二级模式映像功能 数据库设计过程 数据和数据模型 概念层数据模型 组织层数据模型 E-R模型转化为关系模型 关系数据库设计的规范化和非规范化 数据库应用结构 2005年9月 第71页

72 思考题 设计并规范一些表，来记录和完成一下功能：
现在有一家网上玩具商店，通过网络销售玩具，购物者通过注册自己的信息成为合法用户，才能购买玩具。 商店有各种不同厂商，适合不同年龄层次人的玩具。 购物者购买玩具可以给自己或送给别人（暂且都叫接受者）投递时需要填写接受者的详细信息。 购买完成后，玩具经过包装通过各种不同的投递方式出货。 要求详细记录每个购物者的每笔交易和发生的费用，包括玩具的价格，包装的价格，投递的价格等等。 2005年9月 第72页