数据库真题整理

文章目录

真题(前面的为真题,后面的为期末题)

1,大数据和BI数据分析有什么不同,根据应用大数据的场景、来源和技术架构分析一下。

BI(Business Intelligence),中文翻译是商务智能,是一套完整的解决方案,用来将组织中现有的数据进行有效的整合,快速准确的提供报表并提出决策依据,帮助组织做出明智的业务经营决策。

**大数据(Big Data)**是从收集的海量数据中,通过算法将这些来自不同渠道、格式的数据进行直接分析,从中寻找到数据之间的相关性。简单而言,大数据更偏重于发现,以及猜测并印证的循环逼近过程。

第一、从数据来源角度

大数据应用的数据来源,不仅仅包括非结构化的数据,还有各种系统数据,数据库数据。其中非结构化数据主要是集中在互联网以及一些社交网站上的数据以及一些机器设备的数据,这些都构成了大数据应用的数据来源。对于大数据的分析工具来说,现阶段也是对于非结构化的数据分析的比较多。

BI系统则是在数据集成方面的技术越来越成熟,对于数据的提取,一个各种数据挖掘的要求来说,数据集成平台会帮助企业实现数据的流通和交互使用,在企业内部实施BI应用就是为了可以更好的对数据进行分享和使用。

第二、应用场景

BI与大数据区别在于前者更倾向于决策,对事实描述更多是基于群体共性,帮助决策者掌握宏观统计趋势,适合经营运营指标支撑类问题,大数据则内涵更广,倾向于刻画个体,更多的在于个性化的决策。

大数据 技术架构:

大规模并行处理数据库、数据挖掘、分布式文件系统、分布式数据库,云计算平台。

2,数据库有哪些范式,他们的定义是什么?什么时候可以不遵守范式?

设计关系型数据库的时候,需要遵守不同的规范要求,这些不同的规范要求称之为不同的范式。

1NF:每个分量必须是不可分的数据项。

2NF: 若R∈1NF,且每一个非主属性完全依赖于码,则R∈2NF

3NF:若R∈2NF,且每一个非主属性不传递依赖于码。

BCNF:所有主属性对每个不包含它的码,也是完全函数依赖。

反范式化设计:没有冗余的数据库设计可以做到。但是,没有冗余的数据未必是最好的数据库,有时为了提高运行效率就必须降低范式标准,适当保留冗余数据,具体做法是:再概念数据模型设计时遵守第三范式,降低范式标准放到物理模式设计时考虑。降低范式就是增加字段,允许冗余,达到空间换时间的目的。

ADD:

范式化

  • 优点
    • 减少数据冗余
    • 数据表更新快,体积小
  • 缺点
    • 对于查询需要多个表进行关联,导致性能降低
    • 更难以进行索引优化

反范式

  • 优点
    • 可以减少表的关联
    • 更好的进行索引优化
  • 缺点
    • 存在数据冗余及数据维护异常
    • 对数据的修改需要更多的成本

3,什么是事务和程序?他们之间有什么区别?

事务:事务是数据库提供的一种手段,通过这一手段,应用程序将一系列数据库操作组合在一起作为一个整体以便数据库系统提供一组保证,也就是事务的ACID性。

程序:由序列组成,告诉计算机如何完成一个具体的任务,一般来讲一个程序中可以包含多个事务。

4,事务的四个特性

原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持续性(Durability)

  • A:事务的更新操作必须作为一个整体,要么全部成功,要么全部失败。
  • C:事务的执行结果必须使DB从一个一致状态变到另外一个一致状态。(DB只包含成功事务的提交结果)
  • I:一个 事务的执行不能被其他事务干扰
  • D:一旦事务被提交,那么它对数据所作的修改将是持久性的,无论发生何种机器和系统故障。

5,登记日志的原则是什么?为什么?

原则:

  1. 登记的次序严格按照并发事务的执行时间次序。
  2. 必须先写日志文件,后些数据库。

原因:数据的修改写到数据库中和对应的日志,写到日志文件中是两个不同的操作。故障可能在这两个操作之间发生。如果先写了数据库修改,没有对应的日志记录,那么以后就无法恢复这个修改。若先些日志,没有修改数据库,则按照日志文件恢复时只是多执行了了次不必要的UNDO操作,不会影响数据库的正确性。

6,为什么事务的非正常结束会影响DB的正确性。

事务的执行结果必须从一个一致状态变到另外一个一致状态。若DBMS运行发生故障,有些事务尚未完成就被中断,这些未完成的事务对DB的修改有一部分已经写入了物理数据库,这是数据库就有可能处于不正确状态。(可以举个栗子,银行转账的例子)

7,针对不同的故障,试给出恢复策略和方法。

  • 事务故障(事务在运行至正常终止点前被终止)
    1. 反向扫描文件日志,查找该事务的更新操作。
    2. 对该事务的更新执行逆操作。直至读到此事务的开始标记。
  • 系统故障(未完成事务对data的更新可能已经写入数据库,或已经提交的事务对数据库的更新还留在缓存未写入数据库)
    1. 正向扫描日志,找出故障发生前已经提交的事务放入REDO队列,未完成的事务放进UNDO队列。
    2. 对REDO队列中的事务进行重做。
    3. 对UNDO队列的事务进行撤销
  • 介质故障(磁盘上的物理数据和日志文件都被破坏)
    1. 装入最新的数据
  • 2
    点赞
  • 36
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
以下是一道数据库系统工程师的: 1.假设你在为一个在线商店设计一个数据库,该商店需要存储以下信息: - 每个客户的姓名、地址、电子邮件和电话号码 - 产品的名称、描述、价格和库存量 - 订单中每个产品的数量和总价值 - 每个订单的日期和状态(已发货、已取消等) 请提供一个包含必要数据表和它们之间关系的数据库模型,并解释你的设计思路。 答案: 基于上述需求,我们可以设计以下四个数据表: - Customers:存储每个客户的姓名、地址、电子邮件和电话号码。 - Products:存储产品的名称、描述、价格和库存量。 - Orders:存储每个订单的日期和状态(已发货、已取消等)。 - OrderDetails:存储订单中每个产品的数量和总价值。 这些表之间的关系如下: - Customers 和 Orders:一对多关系,一个客户可以有多个订单,但一个订单只属于一个客户。 - Orders 和 OrderDetails:一对多关系,一个订单可以有多个订单详情,但一个订单详情只属于一个订单。 - Products 和 OrderDetails:一对多关系,一个产品可以在多个订单详情中出现,但一个订单详情只对应一个产品。 其中,每个表都需要一个主键来唯一标识每个记录。在此设计中,我们可以使用以下主键: - Customers:CustomerId - Products:ProductId - Orders:OrderId - OrderDetails:OrderDetailId 此外,我们还需要在一些表中添加外键来建立它们之间的关系。具体来说: - Orders 表的外键:CustomerId,指向 Customers 表的主键 CustomerId。 - OrderDetails 表的外键:OrderId,指向 Orders 表的主键 OrderId 和 ProductId,指向 Products 表的主键 ProductId。 这样设计的数据库模型可以很好地满足上述需求,并且具有良好的扩展性和数据完整性。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值