第6章商务智能基础数据库与信息管理.pptVIP

第六章 商务智能基础：数据库与信息管理 开篇案例：惠普能否从企业数据仓库中挖掘成功 HP的CIO：Randy Mott （兰迪 莫特） 惠普有大量的数据，存放在多个应用程序和数据库中，分布于全球各地的不同部门和不同领域。然而，众多的系统和应用程序却无法提供所需要的完整且前后一致的信息。 惠普的CIO决定： 建立数据仓库，即在全公司建立一个可共享的信息库，用于提供统一而且准确的商业信息。该数据仓库取代了17种不同的数据库技术，通过连接目前正在使用的1.4万个数据库，使不同地区和部门的员工都可以在第一时间获取所需数据。 HP最终将这一数据仓库系统发展为独立产品：Neoview，并销售给其他企业 6.1 传统文件环境下的数据整理 6.1.1 文件组织术语和概念 字段 记录 某个数据库中的一份表文件，该文件存储了选修《管理信息系统》课程的10级物流专业的同学名单。每列是一个字段，每行为一个记录。 从数据库原理的角度来看，表中反映了“学生”这一类实体集（Entity Set），表中的每一行是该类型中的一个具体的实体，每个实体都具有学号、姓名、专业名称等属性 6.1.2 传统文件环境的问题 数据冗余与混乱 程序--数据依赖 欠缺弹性 安全性低 缺乏数据共享 与实用性 同样的这样一张表，如果在学校的学生处、教务处分别存储一份，可能会立即产生各种问题。 6.2 使用数据库管理数据 6.2.1 数据库管理系统 有了DBMS，用户和程序员不需要直接和数据库打交道，只需要通过各种应用程序去调用数据库即可。这极大地简化了工作量。 例如：在网上发布一条微博，用户完全不必关心这条微博存储在哪台网站服务器上的哪个存储区域，以何种格式存储……这一切均由DBMS完成。 1、DBMS如何解决传统文件环境带来的问题 2、关系型数据库管理系统 层次型DBMS 网型 DBMS 关系型DBMS，它是严格的、标准的二维表格 关键字（Primary Key） 外关键字（Foreign Key） 3、关系型DBMS操作 4、面向对象数据库管理系统 选择 投影 联接 6.2.2 DBMS的优势 Visual Foxpro中的数据定义 Access中的数据定义 SQL Server中的数据定义 SQL语言是几乎所有关系型数据库的通用语言，要深入掌握SQL语言并不容易，为此，许多DBMS允许用户以可视化方式创建查询，然后为用户自动生成对应的SQL语言并执行。如图是在Access中完成一次交叉表查询，生成的SQL语句从功能上看属于数据操纵语言。 例如，有某个关系如下 学生（学号、姓名、性别、年龄、籍贯、入学分） 在该关系中，不同记录之间，只有学号是不能重复的，而其他的都存在出现重复项的可能，因此学号就是该关系的关键字。 又如学生的选课关系： 学号 课程号 成绩 1001 A1 89 1002 A1 78 1001 A2 89 1002 A2 78 学号、课程号、成绩三项都有可能重复，因此其中的单独某项不能作为关键字，只能取属性的集合作为关键字。 经过简单分析可以得出，只有学号+课程号的组合不可能出现重复项，即该关系的关键字是（学号、课程号） 6.2.3 设计数据库 规范化和实体联系图 编号 姓名 电话 市话 手机 在Word和Excel中均允许制作如上的表头，但在数据库中是不允许的 关系数据库规定：每个属性是不可再分的。若违反这一规定，则称其为不满足第一范式（1NF）。 达到第一范式是关系数据库的最基本要求。 再看右表： 学号 姓名 籍贯 课程号 成绩 1001 张三 合肥 A1 87 1002 李四 芜湖 A1 92 1001 张三 合肥 A2 85 1002 李四 芜湖 A2 76 显然该关系满足第一范式 如前所述，该关系的关键字是（学号、课程号） 但是：学生的姓名和籍贯被重复存储了，这是不必要的，究其原因在于：学号本身就可以直接决定姓名和籍贯，无须借助于课程号来实现。这就迫使我们要对该关系做出分解，即： 关系1：学生（学号、姓名、籍贯） 关系2：选课（学号、课程号、成绩） 分解后可知：上述情况消失了。（虽然学号仍被重复存储了，但这是为了更好地使用数据库而做出的一种妥协） 如果某个关系存在这种情况： 关系的关键字是属性的组合，但是其中某个属性又可以独立地决定其他属性，则称该关系不满足于第二范式。 换言之：若某关系的关键字是单个属性，则该关系必然满足第二范式。 学号 姓名 系别 系主任 1001 赵大 英语 老张 1002 钱二 英语 老张 1003 孙三 贸易 老李 1004 李四 贸易 老李 经分析可知：左表中的关键字是学号，由于是单属性，因此其必然满足第二范式。 但是：“系主任”仍然出现了重复存储的现象。 此外，若英语系的学生全部毕业，数据删除，同时也就抹去了“