数据库的行和列之间的转化


最常见的   行  转   列,主要原理是利用decode函数、聚集函数(sum),结合group by分组实现的:

                  select  t.user_name, 
                          sum(decode(t.course, '语文', score,null)) as CHINESE, 
                          sum(decode(t.course, '数学', score,null)) as MATH, 
                          sum(decode(t.course, '英语', score,null)) as ENGLISH 
                  from test_tb_grade  t 
                  group by t.user_name 
                  order by t.user_name
                    >>>>>>>>>>>>>>>>


最常见的     列  转    行,主要原理是利用SQL里面的union/union all:

            select user_name, '语文' COURSE , CN_SCORE as SCORE from test_tb_grade2  
            union select user_name, '数学' COURSE, MATH_SCORE as SCORE from test_tb_grade2  
            union select user_name, '英语' COURSE, EN_SCORE as SCORE from test_tb_grade2  
            order by user_name,COURSE  

            >>>>>>>>>>>>>>>>>>>>>>>


                  


  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
解放军信息工程大学 数据库课程设计报告 题 目: 网上购物系统 "系部名称 ": "理学院 " "专业名称 ": "信息工程 " "班 级 ": "123 " "学号 ": "12345678 " "学生姓名 ": "留不得 " "指导教师 ": "说不得 " "时间 ": "2012学年 " 一、课程设计目的 通过数据库设计报告来巩固自己所学的数据库的课程,同时把自己在课上学到的 东西应用到实际中去。如今网购已经成为了潮流,通过这次设计可以了解网购的过 程,以及在网购中的一些问题。通过这种设计方便用户根据自己的喜好,浏览自己 喜欢的东西。若要想购买商品,就必须通过注册成为会员才能进行购买,登陆后就 可以购物了。商店的各种商品都进行了详细地分类,可以轻松地找到想要的商品, 同时查找系统能很容易地找到相关的商品。同时买到自己喜欢的东西后就可以去结 算,通过下订单你可以填写自己的相关信息,而完成购物的流程。 课程设计内容 (一)系统需求分析 1、功能需求 通过实际调查,要求本系统具有以下功能: 系统具有良好的人机界面。 如果系统的使用对象较多,则要求有较好的权限管理。 全面展示网上商品的交易信息。 商品分类显示,方便顾客了解本网站上的所有商品 查看网上各个商品的交易信息。 系统最大限度地实现易维护性和易操作性。 系统运行稳定、安全可靠。 支持商品检索显示,可以通过查找商品的模糊信息查找所需商品。 2、数据流图 a、业务流程图 b、中层数据流图 c、会员查看信息流程图 d、销售商维护商品信息流程图 e、会员购买商品数据流程图 f、邮寄商品数据流图 g、会员信息数据管理信息流图 3、数据字典 数据字典是我在数据流程图中选取的一些中层数据流,我把我所抽去的数据列出以下 表来。 (1)数据项: "数据项名 "数据类型 "长度 "别名 "取值范 " " " " " " "围 " " "会员编号 "字符型 "15 "会员的编号 " " " "姓名 "文本型 "20 "会员的姓名 " " " "密码 "文本型 "20 "会员的密码 " " " "电话 "字符型 "12 "会员的电话 " " " "地址 "文本型 "50 "会员的地址 " " " "商品编号 "字符型 "15 "商品的编号 " " " "类型 "文本型 "10 "商品的类型 " " " "名称 "文本型 "20 "商品的名称 " " " "价格 "整型 "6 "商品的价格 " " " "简介 "文本型 "500 "商品的简介 " " " "图片 "图片型 " "商品的图片 " " " "购物车编号 "字符型 "10 "购物车的编号 " " " "商品数量 "整型 "10 "购买商品的数量 " " " "订单编号 "字符型 "15 "购物时生成的订单" " " "订单日期 "时间型 "10 "购买商品的时间 " " " (2)数据结构: 根据对系统需求的分析,结合对E-R图的分析和转化,在系统中的数据结构如下表 "数据结构名 "含义说明 "组成 " "会员 "记录会员的基本信息 "会员编号、姓名、密码、电话、地址 " "商品 "记录销售商提供的商品信 " 商品编号、类型、名称、价格、简介、图片 " " "息 " " "订购 "记录会员的购物信息 " 会员编号、商品编号、订单编号、订单日期 " "购物车 "存储会员需要购买的商品 " 会员编号、商品编号、购物车编号、商品数量 " (二)、概念设计 E-R图 每个实体定义的属性如下: 会员:{会员编号,姓名,密码,电话,地址} 商品:{商品编号,类型,名称,价格,简介,图片} 订购:{订单编号,订单日期} 购物车:{购物车编号,商品数量} 、数据逻辑结构设计 将E- R图转换为关系模型,即将实体、实体的属性和实体之间的联系转化为关系模式,。 关系模式设计: 会员表: "数据项名 "数据类型 "长度 "别名 "是否为空 "主外键 " "会员编号 "字符型 "15 "会员编号 "否 "主键 " "姓名 "文本型 "20 "姓名 "否 " " "密码 "文本型 "20 "密码 "否 " " "电话 "字符型 "12 "电话 "否 " " "地址 "文本型 "50 "地址 "否 " " 商品表: "数据项名 "数据类型 "长度 "别名 "是否为空 "主外键 " "商品编号 "字符型 "15 "商品编号 "否 "主键 " "类型 "字符型 "15 "类型 "否 " " "名称 "字符型 "20 "名称 "否 " " "价格 "整型 "10 "价格 "否 " " "简介 "文本型 "500 "简介 " " " "图片 "image型 "100 "图片 " " " 订购表: "数据项名 "数据类型 "长度 "别名 "是否为空 "主外键 " "会员编号
去年十月,TiDB 1.0 版本发布,在接下来的六个月中,开发团队一方面在维护 1.0 版本的稳定性并且增加必要的新特性,另一方面马不停蹄的开发 2.0 版本。经过 6 个 RC 版本,TiDB 2.0 GA 版本于 4 月 27 日正式发布。 2.0 版本规划 根据现有用户的情况、技术发展趋势以及社区的声音,TiDB 2.0 版本主要聚焦在以下几点: 保证 TiDB 的稳定性以及正确性。这两点是一个数据库软件的基础功能,作为业务的基石,任何一点抖动或者错误都可能对业务造成巨大的影响。目前已经有大量的用户在线上使用 TiDB,这些用户的数据量在不断增加、业务也在不断演进。 提升 TiDB 在大数据量下的查询性能。TiDB 目前很多客户都有少则上百 GB,多则上百 TB 的数据,一方面数据会持续增加,另一方面也希望能对这些数据做实时的查询。所以如果能提升大数据量下的查询性能,对用户会很有帮助。 优化 TiDB 的易用性和可维护性。TiDB 整套系统的复杂性比较高,运维及使用的难度要大于单机数据库,所以希望能提供尽可能方便的方案帮助用户使用 TiDB。比如尽可能简化部署、升级、扩容方式,尽可能容易的定位系统中出现的异常状态。 围绕上面三点原则,TiDB 做了大量的改进,一些是对外可见,如 OLAP 性能的显著提升、监控项的大量增加以及运维工具的各项优化,还有更多的改进是隐藏在数据库背后,默默的提升整个数据库的稳定性以及正确性。 正确性和稳定性 在 1.0 版本发布之后,TiDB 开始构建和完善自动化测试平台 Schrodinger,彻底告别了之前靠手工部署集群测试的方式。同时也新增了非常多的测试用例,做到测试从最底层 RocksDB,到 Raft,再到 Transaction,然后是 SQL 都能覆盖。 在 Chaos 测试上面,TiDB 引入了更多的错误注入工具,例如使用 systemtap 对 I/O 进行 delay 等,也在代码特定的业务的逻辑进行错误注入测试,充分保证 TiDB 在异常条件下面也能稳定运行。 TiDB 的开发团队之前做了很多 TLA+ 的论证工作,也有一些简单的测试,1.0 之后开始使用 TLA+ 系统进行论证,保证所做的实现在设计上面都是正确的。 在存储引擎方面,为了提升大规模集群的稳定性和性能,TiDB 优化了 Raft 的流程,引入 Region Merge、Raft Learner 等新特性;优化热点调度机制,统计更多的信息,并根据这些信息做更合理的调度;优化 RocksDB 的性能,使用 DeleteFilesInRanges 等特性,提升空间回收效率,降低磁盘负载,以及更加平滑地使用磁盘资源等等。 OLAP 性能优化 TiDB 2.0 版本重构了 SQL 优化器和执行引擎,希望能尽可能快的选择最优查询计划并且尽可能高效地执行查询计划。 1.0 版本已经从基于规则的查询优化器转向基于代价的查询优化器,但是还不够完善,在 2.0 版本中,一方面优化统计信息的精确度以及更新及时程度,另一方面提升 SQL 优化器的能力,对查询代价的估算更加精准、对复杂过滤条件的分析更加细致、对关联子查询的处理更加优雅、对物理算子的选择更加灵活准确。 在这一版本中,SQL 执行引擎引入新的内部数据表示方式 --- `Chunk`,一个结构中保存一批数据而不仅是一行数据,同一列的数据在内存中连续存放,使得内存使用更紧凑,这样带来了几点好处:1. 显著减小了内存消耗; 2. 批量分配内存,减小了 GC 开销;3. 算子之间可以对数据进行批量传递,减小调用开销;4. 在某些场景下,可以进行向量计算以及减小 CPU 的 Cache Miss 的情况。 完成上述两项改动之后,TiDB 在 OLAP 场景下的性能有了大幅的质的提升,从 TPC-H 的对比结果来看,所有的 Query 在 2.0 中都运行得更快,一些 Query 大多数都有几倍甚至数量级的提升,特别是一些 1.0 中跑不出结果的 Query 在 2.0 中都能顺利执行。 易用性和可运维性 为了更容易被安装和使用,TiDB 2.0 在监控、运维、工具方面也做了诸多优化。 在监控方面,增加了过百个监控项,同时通过 HTTP 接口、SQL 语句等方式暴露出一些运行时信息,用于系统调优或者是定位系统中存在的问题。 在运维方面,运维工具做了优化,简化操作流程,降低操作复杂度及操作过程对于线上的影响。同时功能也更加丰富,支持自动部署 Binlog 组件、支持启用 TLS。 2.0 详细更新列表 TiDB: 1.SQL 优化器 精简统计信息数据结构,减小内存占用 加快进程启动时加载统计信息速度 支持统计信息动态更新 [experimental] 优化代价模型,对代价估算更精准 使用 `Count-Min Sketch` 更精确地估算点查的代价 支持分析更复杂的条件,尽可能充分的使用索引 支持通过 `STRAIGHT_JOIN` 语法手动指定 Join 顺序 `GROUP BY`子句为空时使用 Stream Aggregation 算子,提升性能 支持使用索引计算 `Max/Min` 函数 优化关联子查询处理算法,支持将更多类型的关联子查询解关联并转化成 `Left Outer Join` 扩大 `IndexLookupJoin` 的使用范围,索引前缀匹配的场景也可以使用该算法 2.SQL 执行引擎 使用 Chunk 结构重构所有执行器算子,提升分析型语句执行性能,减少内存占用,显著提升 TPC-H 结果 支持 Streaming Aggregation 算子下推 优化 `Insert Into Ignore` 语句性能,提升 10 倍以上 优化 `Insert On Duplicate Key Update` 语句性能,提升 10 倍以上 下推更多的数据类型和函数到 TiKV 计算 优化 `Load Data` 性能,提升 10 倍以上 支持对物理算子内存使用进行统计,通过配置文件以及系统变量指定超过阈值后的处理行为 支持限制单条 SQL 语句使用内存的大小,减少程序 OOM 风险 支持在 CRUD 操作中使用隐式的行 ID 提升点查性能 3.Server 支持 Proxy Protocol 添加大量监控项, 优化日志 支持配置文件的合法性检测 支持 HTTP API 获取 TiDB 参数信息 使用 Batch 方式 Resolve Lock,提升垃圾回收速度 支持多线程垃圾回收 支持 TLS 4.兼容性 支持更多 MySQL 语法 支持配置文件修改 `lower_case_table_names` 系统变量,用于支持 OGG 数据同步工具 提升对 Navicat 的兼容性 在 `Information_Schema` 中支持显示建表时间 修复部分函数/表达式返回类型和 MySQL 不同的问题 提升对 JDBC 兼容性 支持更多的 `SQL_MODE` 5.DDL 优化 `Add Index` 的执行速度,部分场景下速度大幅度提升 `Add Index` 操作变更为低优先级,降低对线上业务影响 `Admin Show DDL Jobs` 输出更详细的 DDL 任务状态信息 支持 `Admin Show DDL Job Queries JobID` 查询当前正在运行的 DDL 任务的原始语句 支持 `Admin Recover Index` 命令,用于灾难恢复情况下修复索引数据 支持通过 `Alter` 语句修改 Table Options PD: 1.增加 `Region Merge` 支持,合并数据删除后产生的空 Region [experimental] 2.增加 `Raft Learner` 支持 [experimental] 3.调度器优化 调度器适应不同的 Region size 提升 TiKV 宕机时数据恢复的优先级和恢复速度 提升下线 TiKV 节点搬迁数据的速度 优化 TiKV 节点空间不足时的调度策略,尽可能防止空间不足时磁盘被写满 提升 balance-leader scheduler 的调度效率 减少 balance-region scheduler 调度开销 优化 hot-region scheduler 的执行效率 4.运维接口及配置 增加 TLS 支持 支持设置 PD leader 优先级 支持基于 label 配置属性 支持配置特定 label 的节点不调度 Region leader 支持手动 Split Region,可用于处理单 Region 热点的问题 支持打散指定 Region,用于某些情况下手动调整热点 Region 分布 增加配置参数检查规则,完善配置项的合法性较验 5.调试接口 增加 `Drop Region` 调试接口 增加枚举各个 PD health 状态的接口 6.统计相关 添加异常 Region 的统计 添加 Region 隔离级别的统计 添加调度相关 metrics 7.性能优化 PD leader 尽量与 etcd leader 保持同步,提升写入性能 优化 Region heartbeat 性能,现可支持超过 100 万 Region TiKV: 1.功能 保护关键配置,防止错误修改 支持 `Region Merge` [experimental] 添加 `Raw DeleteRange` API 添加 `GetMetric` API 添加 `Raw Batch Put`,`Raw Batch Get`,`Raw Batch Delete` 和 `Raw Batch Scan` 给 Raw KV API 增加 Column Family 参数,能对特定 Column Family 进行操作 Coprocessor 支持 streaming 模式,支持 streaming 聚合 支持配置 Coprocessor 请求的超时时间 心跳包携带时间戳 支持在线修改 RocksDB 的一些参数,包括 `block-cache-size` 大小等 支持配置 Coprocessor 遇到某些错误时的行为 支持以导数据模式启动,减少导数据过程中的写放大 支持手动对 region 进行对半 split 完善数据修复工具 tikv-ctl Coprocessor 返回更多的统计信息,以便指导 TiDB 的行为 支持 ImportSST API,可以用于 SST 文件导入 [experimental] 新增 TiKV Importer 二进制,与 TiDB Lightning 集成用于快速导入数据 [experimental] 2.性能 使用 ReadPool 优化读性能,`raw_get/get/batch_get` 提升 30% 提升 metrics 的性能 Raft snapshot 处理完之后立即通知 PD,加快调度速度 解决 RocksDB 刷盘导致性能抖动问题 提升在数据删除之后的空间回收 加速启动过程中的垃圾清理过程 使用 `DeleteFilesInRanges` 减少副本迁移时 I/O 开销 3.稳定性 解决在 PD leader 发送切换的情况下 gRPC call 不返回问题 解决由于 snapshot 导致下线节点慢的问题 限制搬移副本临时占用的空间大小 如果有 Region 长时间没有 Leader,进行上报 根据 compaction 事件及时更新统计的 Region size 限制单次 scan lock 请求的扫描的数据量,防止超时 限制接收 snapshot 过程中的内存占用,防止 OOM 提升 CI test 的速度 解决由于 snapshot 太多导致的 OOM 问题 配置 gRPC 的 `keepalive` 参数 修复 Region 增多容易 OOM 的问题 此外,同时发布的还有 TiSpark 1.0 GA 版本。TiSpark 1.0 版本组件提供了针对 TiDB 上的数据使用 Apache Spark 进行分布式计算的能力。更新包括: 1.提供了针对 TiKV 读取的 gRPC 通信框架 2.提供了对 TiKV 组件数据的和通信协议部分的编码解码 3.提供了计算下推功能,包含 聚合下推 谓词下推 TopN 下推 Limit 下推 4.提供了索引相关支持 谓词转化聚簇索引范围 谓词转化次级索引 Index Only 查询优化 运行时索引退化扫表优化 5.提供了基于代价优化 统计信息支持 索引选择 广播表代价估算 6.多种 Spark Interface 的支持 Spark Shell 支持 ThriftServer/JDBC 支持 Spark-SQL 交互支持 PySpark Shell 支持 SparkR 支持 相关链接 TiDB 的详细介绍:点击查看 TiDB 的下载地址:点击下载
考勤管理系统分析和设计 实验报告 专业:07软件工程 姓名: 学号: 综合教务系统分析和设计   系统的分析和设计过程主要包括:需求分析;概念结构设计;逻辑结构设计;物理 结构设计,建立合适的索引,提高查询速度;应用系统的模块设计;应用系统的用户界面 设计。数据库系统的实施和维护. 一) 数据库需求分析 1.数据库需求分析 根据数据流程,可以列出以下管理系统所需的数据项和数据结构. 出勤记录:记录号、员工、出入情况和出入时间. 月度考勤统计:记录号、员工、年月、累计正常工作时间、累计请假时间、累计加班 时间、累加出差时间、迟到次数、早退次数和矿工次数。 请假记录:记录号、员工、假期起始时间/结束时间和请假缘由. 加班记录:记录号、员工、加班时间长度和日期。 出差记录:记录号、员工、出差起始时间/结束时间和具体描述。 人员信息:员工号、密码、权限、部门和当前状态等。 部门设置:部门编号、名称等。 2。系统功能分析 上班时间的设定.上下班时间相对固定,可保存在客户端的设置文件中。 员工出入单位的情况记录。出入情况由考勤机来记录,但是需要设置人工添加的功能 ,已被特殊情况的处理。 请假、加班和出差情况的记录。 每个月底进行整个月出勤  3. 开发工具:   该综合教务系统的数据库采用Microsoft的Office Access 2003建表,前台应用程序采用Visual C++ 6.0来编写,提供Web界面方便学生从网上使用。  二) 数据库的概念设计   1.系统的概念模型:   选课系统概念模型的ER图   上图是选课系统的概念模型的ER图,该系统涉及的实体集有:   员工实体集:具有属性员工号、员工密码、权限、姓名、所在部门。   出差记录实体集:具有属性记录编号、起始时间、结束时间、具体描述。   出勤记录实体集:具有属性记录编号、出入时间、出入状态.   月度考勤统计实体集:具有属性记录编号、年月、累计工作时间、累计请假时间、 累计加班时间、累积出差时间、迟到次数、早退次数、旷工次数。    请假记录实体集:具体属性记录编号、起始时间、结束时间、原由. 加班记录实体集:具体属性记录编号、加班时间、日期。 一个出差记录可以有多个员工,一个员工只能有一个出差记录,所以员工和出差记录之 间的联系为N:1的联系,员工与其他实体集之间都是N:1的联系.    2 将E—R模型转换为关系模式  (1) 员工实体集可以转换为关系:   员工(员工号,员工密码,权限,姓名,所在部门)  (2) 出差记录实体集可以转换为关系   出差记录(记录编号,起始时间,结束时间,具体描述)  (3) 出勤记录实体可以转换为关系   出勤记录(记录编号,出入时间,出入状态)   (4) 月度考勤统计实体集可以转换为关系 月度考勤统计(记录编号,年月,累计工作时间,累计请假时间,累计加班时间, 累积出差时间,迟到次数,早退次数,旷工次数)  (5) 请假记录实体集可以转换为关系:   请假记录实体集(记录编号,起始时间,结束时间,原由)   (6) 加班记录实体集可以转化为关系:   加班记录实体集(记录编号,加班时间,日期)     3。 数据库表结构设计:    把关系模型转化为表结构: 1) 出勤记录表 出勤记录表用来记录职工的出勤情况,包括记录编号、员工编号、出入情况和出入时 间,如表所示    出勤记录表(ATTENDENCE) "字段名称 "数据类型 "说明 " "ID "数字 "记录编号 " "PERSON "文本 "员工号 " "IN_OUT "文本 "出入情况 " "IO_TIME "日期/时间 "出入时间 " 2) 月度考勤统计表 月度考勤统计表用来记录职工的考勤情况,包括记录编号、员工编号、年月、累计正 常工作时间、累计请假时间、累计加班时间、累计出差时间、迟到次数、早退次数和 旷工次数,如表所示 月度考勤统计表(ATTENDENCE) "字段名称 "数据类型 "说明 " "ID "数字 "记录编号 " "YEAR_MONTH "文本 "统计月份 " "PERSON "文本 "员工号 " "WORK_HOUR "数字 "累计工作时间 " "OVER__HOUR "数字 "累计加班时间 " "LEAVE_HDAY "数字 "累计请假时间(半天" " " ") " "ERRAND_HDAY "数字 "累计出差时间(半天" " " ") " "LATE_TIMES "数字 "迟到次数 " "EARLY_TIMES "数字 "早退次数 " "ABSENT_TIMES "数字 "旷工次数 " 3) 请假记录表 请假记录表用来记录职工的请假情况,包括记录编号、员工编号、假期起始时间、结 束时间和请假缘由,如图所示 请假记录表(LEAVE) "
信息安全的核心就是数据库的安全,也就是说数据库加密是信息安全的核心问题。数据库数据的安全问题越来越受到重视,数据库加密技术的应用极大的解决了数据库中数据的安全问题,但实现方法各有侧重。 随着电子商务逐渐越来越多的应用,数据的安全问题越来越受到重视。一是企业本身需要对自己的关键数据进行有效的保护;二是企业从应用服务提供商(Application Service Provider,ASP)处获得应用支持和服务,在这种情况下,企业的业务数据存放在ASP处,其安全性无法得到有效的保障。因为传统的数据库保护方式是通过设定口令字和访问权限等方法实现的,数据库管理员可以不加限制地访问和更改数据库中的所有数据。解决这一问题的关键是要对数据本身加密,即使数据不幸泄露或丢失,也难以被人破译,关于这一点现基本数据库产品都支持对数据库中的所有数据加密存储。 对数据进行加密,主要有三种方式:系统中加密、客户端(DBMS外层)加密、服务器端(DBMS内核层)加密。客户端加密的好处是不会加重数据库服务器的负载,并且可实现网上的传输加密,这种加密方式通常利用数据库外层工具实现。而服务器端的加密需要对数据库管理系统本身进行操作,属核心层加密,如果没有数据库开发商的配合,其实现难度相对较大。此外,对那些希望通过ASP获得服务的企业来说,只有在客户端实现加解密,才能保证其数据的安全可靠。 1. 常用数据库加密技术 信息安全主要指三个方面。一是数据安全,二是系统安全,三是电子商务的安全。核心是数据库的安全,将数据库的数据加密就抓住了信息安全的核心问题。 对数据库中数据加密是为增强普通关系数据库管理系统的安全性,提供一个安全适用的数据库加密平台,对数据库存储的内容实施有效保护。它通过数据库存储加密等安全方法实现了数据库数据存储保密和完整性要求,使得数据库以密文方式存储并在密态方式下工作,确保了数据安全。 1.1 数据库加密技术的功能和特性 经过近几年的研究,我国数据库加密技术已经比较成熟。 一般而言,一个行之有效的数据库加密技术主要有以下6个方面的功能和特性。 (1)身份认证: 用户除提供用户名、口令外,还必须按照系统安全要求提供其它相关安全凭证。如使用终端密钥。 (2) 通信加密与完整性保护: 有关数据库的访问在网络传输中都被加密,通信一次一密的意义在于防重放、防篡改。 (3) 数据库数据存储加密与完整性保护: 数据库系统采用数据项级存储加密,即数据库中不同的记录、每条记录的不同字段都采用不同的密钥加密,辅以校验措施来保证数据库数据存储的保密性和完整性,防止数据的非授权访问和修改。 (4) 数据库加密设置: 系统中可以选择需要加密的数据库列,以便于用户选择那些敏感信息进行加密而不是全部数据都加密。只对用户的敏感数据加密可以提高数据库访问速度。这样有利于用户在效率与安全性之间进行自主选择。 (5)多级密钥管理模式: 主密钥和主密钥变量保存在安全区域,二级密钥受主密钥变量加密保护,数据加密的密钥存储或传输时利用二级密钥加密保护,使用时受主密钥保护。 (6) 安全备份: 系统提供数据库明文备份功能和密钥备份功能。 1.2 对数据库加密系统基本要求 (1) 字段加密; (2) 密钥动态管理; (3) 合理处理数据; (4) 不影响合法用户的操作; (5) 防止非法拷贝; 1.3 数据加密的算法 加密算法是一些公式和法则,它规定了明文和密文之间的变换方法。密钥是控制加密算法和解密算法的关键信息,它的产生、传输、存储等工作是十分重要的。 数据加密的基本过程包括对明文(即可读信息)进行翻译,译成密文或密码的代码形式。该过程的逆过程为解密,即将该编码信息转化为其原来的形式的过程。 DES算法, DES(Data Encryption Standard)是由IBM公司在1970年以后发展起来的,于1976年11月被美国政府采用,DES随后被美国国家标准局和美国国家标准协会(American National Standard Institute,ANSI)承认, DES算法把64位的明文输入块变为64位的密文输出块,它所使用的密钥也是64位,DES算法中只用到64位密钥中的其中56位。 三重DES, DES的密码学缺点是密钥长度相对比较短,因此,人们又想出了一个解决其长度的方法,即采用三重DES,三重DES是DES的一种变形。这种方法使用两个独立的56位密钥对交换的信息(如EDI数据)进行3次加密,从而使其有效密钥长度达到112位或168位, 对安全性有特殊要求时则要采用它。 RSA算法它是第一个既能用于数据加密也能用于数字签名的算法。它易于理解和操作,也很流行。算法的名字就是发明者的名字:Ron Rivest, AdiShamir 和Leonard Adleman, 但RSA的安全性一直未能得到理论上的证明, RSA的安全性依赖于大数的因子分解,但并没有从理论上证明破译RSA的难度与大数分解难度等价。即RSA的重大缺陷是无法从理论上把握它的保密性能如何,而且密码学界多数人士倾向于因子分解不是NPC问题, RSA算法是第一个能同时用于加密和数字签名的算法,也易于理解和操作。RSA是被研究得最广泛的公钥算法,从提出到现在已近二十年,经历了各种攻击的考验,逐渐为人们接受,普遍认为是目前最优秀的公钥方案之一。 AES是美国高级加密标准算法,将在未来几十年里代替DES在各个领域中得到广泛应用,尽管人们对AES还有不同的看法,但总体来说,AES作为新一代的数据加密标准汇聚了强安全性、高性能、高效率、易用和灵活等优点。AES设计有三个密钥长度:128,192,256位,相对而言,AES的128密钥比DES的56密钥强1021倍。AES算法主要包括三个方面:轮变化、圈数和密钥扩展。在理论上,此加密方法需要国家军事量级的破解设备运算10年以上时间才可能破译。 1.4 数据库数据加密的实现 使用数据库安全保密中间件对数据库进行加密是最简便直接的方法。主要是通过系统中加密、DBMS内核层(服务器端)加密和DBMS外层(客户端)加密。 在系统中加密,在系统中无法辨认数据库文件中的数据关系,将数据先在内存中进行加密,然后文件系统把每次加密后的内存数据写入到数据库文件中去,读入时再逆方面进行解密就,这种加密方法相对简单,只要妥善管理密钥就可以了。缺点对数据库的读写都比较麻烦,每次都要进行加解密的工作,对程序的编写和读写数据库的速度都会有影响。 在DBMS内核层实现加密需要对数据库管理系统本身进行操作。这种加密是指数据在物理存取之前完成加解密工作。这种加密方式的优点是加密功能强,并且加密功能几乎不会影响DBMS的功能,可以实现加密功能与数据库管理系统之间的无缝耦合。其缺点是加密运算在服务器端进行,加重了服务器的负载,而且DBMS和加密器之间的接口需要DBMS开发商的支持。 在DBMS外层实现加密的好处是不会加重数据库服务器的负载,并且可实现网上的传输,加密比较实际的做法是将数据库加密系统做成DBMS的一个外层工具,根据加密要求自动完成对数据库数据的加解密处理。 采用这种加密方式进行加密,加解密运算可在客户端进行,它的优点是不会加重数据库服务器的负载并且可以实现网上传输的加密,缺点是加密功能会受到一些限制,与数据库管理系统之间的耦合性稍差。 数据库加密系统分成两个功能独立的主要部件:一个是加密字典管理程序,另一个是数据库加解密引擎。数据库加密系统将用户对数据库信息具体的加密要求以及基础信息保存在加密字典中,通过调用数据加解密引擎实现对数据库表的加密、解密及数据转换等功能。数据库信息的加解密处理是在后台完成的,对数据库服务器是透明的。 按以上方式实现的数据库加密系统具有很多优点:首先,系统对数据库的最终用户是完全透明的,管理员可以根据需要进行明文和密文的转换工作;其次,加密系统完全独立于数据库应用系统,无须改动数据库应用系统就能实现数据加密功能;第三,加解密处理在客户端进行,不会影响数据库服务器的效率。 数据库加解密引擎是数据库加密系统的核心部件,它位于应用程序与数据库服务器之间,负责在后台完成数据库信息的加解密处理,对应用开发人员和操作人员来说是透明的。数据加解密引擎没有操作界面,在需要时由操作系统自动加载并驻留在内存中,通过内部接口与加密字典管理程序和用户应用程序通讯。数据库加解密引擎由三大模块组成:加解密处理模块、用户接口模块和数据库接口模块。 2. 结束语 上面的论述还远远没达到数据库安全需要,比如现在的数据库基本都基于网络架构,网际的安全传输等,也是要重点考虑的方面。一个好的安全系统必须综合考虑核运用这些技术,以保证数据的安全,通过以上论述希望对大家有所帮助,同时也和大家一起讨论一起学习,共同进步。

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值