关系型数据库管理系统（精选12篇）
关系型数据库管理系统 篇1
摘要：实现基于关系数据库的信息 (关键字) 检索, 将使用户不需要任何SQ L语言和底层数据库模式的知识, 就像使用搜索引擎一样来获取数据库中的相关数据。关系数据库的关键字检索技术已经成为目前数据库领域中的一个研究重点。
关键词：关系数据库,关键词查询,数据库模式
1 系统总体设计
面向关系数据库的关键字查询系统主要有五部分组成, 首先要分析输入的关键字, 有几个关键字组成;然后调用全文索引, 查看这些关键字所属, 是表名、属性名还是属性值;接下来查询数据库的模式图, 从而得到几种可能的元组连接树;最后将相应元组连接树转化成SQ L语句查询关系数据库, 生成查询结果, 以二维表格形式显示。由上述内容可得系统流程图如图1所示。
2 数据库设计
本系统为面向关系数据库的关键字图图11系系统统流流程程图图查询系统, 在实验中本文选取了IM D B数据集, 为了进行实验, 将数据集整理为以下七个表数据结构。
实验数据集 (电影信息数据库) :A ctor (演员表) 、C onsum e (设计师) 、D irector (导演信息) 、B usiness (投资) 、Editor (编辑) 、C olor (颜色信息) 、Keyw ord (关键词) 。
本数据库抽象的数据库关系E-R图如图2所示。
图2为数据库关系的E-R图。在图中, 黄色钥匙为每个表的主键, 黑线部分为表之间外键关系, 设定除business表外每个表都有一个外键m vnam e, 而在抽象出的关系图中, 以m vnam e和episode为数据库每个表之间最重要的联系, 即表之间关系以m vnam e和episode属性为联系。
3 数据库索引设计
在关系型数据库中, 例如O racle、D B 2、SQ L Server和M yS Q L等都提供了对关键字查询的扩展, 可以为数据库的表属性建立全文索引, 这为实现关系数据库的关键字查询提供了基础。已有多个关系数据库的关键字查询系统被开发出来, B A N KS、D ISC O V ER、IR-style、SEKKER等等。然而在已有的系统中, 多数系统仅仅支持数据库中文本属性的查询, 却忽略了对数据库中元数据的处理。如果用户给定的查询关键字是数据库中的元数据, 则有些系统就不能够满足用户的查询需求, 或者查询结果不够精确, 返回大量与查询不相关的结果。SEKKER虽然提出了支持数字属性和元数据的查询, 但是却在查询语言上做了限定, 只能通过给定的查询语言格式进行查询, 所以系统的灵活性不高。
关键字“{C olor”“D irector”}的索引结构如表1所示。
4 数据库模式图的构建
在关系数据库中, 关键字是通过主外键进行连接的, 因此关系数据库采用的数据模型, 即为基于模式图建模。模式图的节点对应数据库中的关系, 边表示关系间的主外键约束。
模式图 (Schem a G raph, G S) 是将关系数据库的模式信息定义为模式图G S (V, E) , 其中V表示模式图中的节点, 与数据库中的关系一一对应, E表示模式图中的边, 将具有主外码约束相对应的关系连接起来, 关系Ri和关系Rj中的主外键关系对应模式图一条边Ri→Rj。
本文数据库对应的数据库模式图如图3所示。
5 关键字检索设计
关键字检索技术主要是, 通过分析用户输入的关键字所属类型来确定元组连接树, 从而转换成相应的SQ L语句来查询关系数据库。如果用户输入的关键字都是表名, 则将几个表自然连接后输出即可;若用户输入的关键字有表名、属性名, 那么将属性列加到表中输出就是用户所检索的内容;若用户输入的关键字中有属性值, 则将属性值对应属性与表或属性列连接, 根据属性值对应元组来显示查询结果。由此可见, 对于相同的关键字, 如果它不止一种所属值, 那么它就会对应不同的SQ L语句。
6 结果生成设计
在本文中, 将查询结果定义为元组连接树。给定一个数据库模式图G S, 一个元组连接树T是一棵元组树。其中, T中的每一条边 (ti, tj) (ti∈Ri, tj∈Rj) 满足以下两个要求: (1) (Ri, Rj) ∈G S, (2) ti∞tj∈Ri∞Rj。同时这些元组连接树满足以下条件: (1) 完整性:用户提交的所有关键字均出现在元组连接树上; (2) 最小性:从元组连接树中移除任何元组后的元组连接树都不具有完整性。
元组连接树生成规则伪代码如下:
7 结束语
本文将生成的关系图转换为SQ L查询, 通过执行相应的查询, 进而得到每个关系路径对应的查询结果。因为关系图是按照关联度进行返回的, 但是这样关联度仅仅的将关键字映射在关系的层面上, 为了使查询结果更加明确, 本文将结果进行细化, 将关键字映射到关系层面。为了避免大量冗余结果的产生, 为了更精确的满足用户的查询需求, 将与关键字关系有关系的结果返回给用户即可。
参考文献
[1]林子雨, 杨冬青, 王腾蛟, 张东站.基于关系数据库的关键词查询[J].软件学报, 2010 (10) .
[2]林子雨, 邹权, 赖永炫, 林琛.关系数据库中的关键词查询结果动态优化[J].软件学报, 2014 (03) .
[3]李慧颖, 瞿裕忠.基于关键词的R D F数据查询方法[J].东南大学学报 (自然科学版) , 2010 (02) .
关系型数据库管理系统 篇2
客户关系管理系统
（1）E-R图向关系模型的转换
将总体概念结构E-R图转化成关系模型。
客户（姓名，性别，账号，联系电话，所在单位名称）主键：姓名
订单（订单名称，订单客户姓名，订单客户联系方式，预订交货日期）主键：订单名称
服务台（用户名，联系方式，产品名称，ID）主键：用户意见
综合管理台(产品销售排名，产品发货量，收发货地点统计，业务员排名，客户文化统计，客户地域人数，客户年龄统计，与目标数的差距比，经销商姓名，市场情况，产品市场占有率，产品销售排名)主键：客户地域人数统计 副键：产品发货量
关系型数据库管理系统 篇3
摘要：随着经济全球化和竞争的加剧，企业关系作为一种关键资源变得日益复杂，成功的企业关系管理对企业的组织结构和信息结构提出了更高的要求。文章在以狭义企业关系为研究对象，分析了企业关系管理的核心思想及其内涵，构建了企业关系管理的体系结构。将数据挖掘相关技术引入企业关系管理系统，分析了数据挖掘在企业关系管理中应用的几个方面及其应用过程。
关键词：企业关系；数据挖掘；数据仓库；系统
一、引言
信息技术条件下，成功的企业关系管理需要一个合理的组织框架，更需要一个合理的信息结构。数据挖掘作为一种先进的数据分析方法，已经在客户关系管理中得到了广泛的应用。以此为鉴，我们认为数据挖掘也是实现企业关系数据深入分析的有效工具。
二、企业关系管理
1企业关系管理定义。企业关系始于20世纪60年代社会心理学和行为理论研究，由营销学家Levy＆Kofler首次提出，随后随关系营销学的发展而发展。Hakansson提出企业关系就是相互作用的双方于不同水平的投资、组织学习、相互适应、信任与承诺，并初次建立了企业关系的相互作用模型。Anderson＆Nams强调了企业关系概念的互惠性质，认为企业关系是两个组织之间为减少总成本或增加价值收益而形成的广泛的社会、经济、服务及技术联系。Morgan＆Hunt认为企业关系就是企业关系双方基于社会心理的相互作用过程。并研究了企业关系的结构和机理。陈晓峰将企业关系定义为供应商、客户，员工、政府、媒体及其他等众多联系的集合。钱言将企业关系定义为具有主观能动性的企业在行动过程中相互之间产生的一种联系，研究对象仅限于企业与企业之间。从以上观点，我们可以归结为广义和狭义两类定义。广义的企业关系指所有与企业发生直接相互作用的组织和个体。狭义的企业关系单指两个或多个企业组织之间出现的、相对持久的资源交易、资源流动和资源联系。
笔者认为广义的企业关系中个体与组织两类关系对象在关系接触方式、关系价值贡献率、关系稳定性以及控制模式等方面均存在显著差异。同样的道理。政府机构、媒体和社区等组织形式的关系对象与企业组织在结构体制和运作模式上与企业也无可比性。因此，我们在对企业关系管理研究时。不可将其一概而论。基于以上表述，本文的研究选取了狭义的企业关系为研究对象，即企业关系管理就是指对企业自身与其他企业之间的相互作用进行管理和控制过程。
2企业关系管理内涵。对企业关系管理内涵可作如下归纳：
(1)合理选取关系对象。依照系统论的观点。结构决定功能，那么企业关系的结构组成就是分析企业关系特有功能和价值的基础。关系对位才能创造价值，企业需要结合自身经营战略目标决定与哪些企业形成特定的关系类型，并建立紧密或松散的关系来完成自身目标。因此，企业关系管理的首要步骤就是选取与之相称的关系对象。如果选择的关系对象志不同，道不合，趣不投，关系就不可能长期维持。如果路径选择不同。关系双方则不能形成战略的协同和资源的互补，达不到降低成本，提高收益率的目的：而双方价值观、行为方式与管理风格等文化方面的差异也同样如此。
(2)最大化关系价值。以价值为本的管理模式使得关系价值成为企业关系管理的核心和实施企业关系管理策略的主要依据。企业关系管理的过程就是企业寻求关系价值最大化的过程。其中，关系变量是衡量企业关系价值大小的最主要指标。Wilson基于广泛的B—to—B文献提出了以下数影响企业关系演化中关系价值的关系变量：承诺、信任、合作、共同，分享目标、相互依赖，权力的不平衡、绩效满意度、不同水平的变化、相互适应性、沉没成本、共享技术、组织上的关系和社会性关系等等。企业就是通过对关系双方此类变量信息的获取来评估企业关系绩效、关系收益、关系地位和相互适应性、转换成本等来感知关系价值，从而不断的修正初始的关系状态，以求各自的关系价值最大化。
(3)关系风险防范。处于开放系统中的企业关系本身存在许多不确定性因素，并由此导致企业关系风险，进而致使企业关系非意愿瓦解。企业关系风险主要表现为机会主义行为，即基于追求自我利益最大化而采取的欺骗行为。在企业关系中，机会主义行为主要表现为隐瞒和歪曲信息、躲避或违反关系契约而不完全履行关系承诺或关系义务、窃取关系企业的技术、挖走关系企业的关键人才等。
因此，有效的关系管理要求企业要与关系对象保持良好的沟通，深入分析和准确掌握对方的关系需求，全面、及时跟踪把握企业关系发展状态。形成企业关系双方的良性互动，降低了机会主义发生可能性。
3企业关系管理的体系结构。从体系结构上来看，企业关系管理架构由三个关键的部分组成如图1所示。
(1)关系接触层：企业关系的参与者可能是某一部门或者是多个部门，或者是在多个部门间转换。企业通过关系接触层的关系中心与关系对象进行各种方式的沟通和联系，并对各个部门的接触信息进行集中和处理。
(2)分析层：分析层是将关系接触中心和关系管理决策所产生的信息通过共享数据仓库连接起来。如果一个企业的信息来源相互独立，那么这些信息会有重复、互相冲突并且会过时，这对企业的整体运作效率将产生负面影响。基于统一的企业关系数据和融入所有企业业务应用系统的分析环境，就可以对其进行加工处理，提供即时分析，然后将分析结果反馈给决策层和整个企业内部。这样便增加了信息分析的价值，为企业的战略决策提供支持，企业决策者会权衡这些信息做出更全面及时的商业决策。
(3)决策层：决策层功能是对上面两部分的应用所产生的信息进行加工处理，产生商业智能。为企业的关系管理决策提供支持。并且关系决策层往往要再将关系活动分派到关系接触层的相关执行部门。
三、数据挖掘及其主要技术方法
数据挖掘是指从大量的、不完全的、有噪声的、模糊的、随机的实际应用数据中，提取隐含在其中的、人们事先不知道的、但又是潜在有用的信息和知识的过程。它通过选择数据，对数据进行检测，建立挖掘分析模型。挖掘出深层次的信息和知识，用于信息管理、过程控制、科学研究、决策支持等方面。
按照所挖掘的数据模式的不同，可以将数据挖掘的技术方法划分为以下四种!
1偏差分析。偏差分析用来发现数据集中与正常情况不同的异常和变化，并进一步分析种变化的原因。当某个别数据对象不符合大多数数据对象所构成的规律时就会形成孤立点。孤立点可能是事物偶然异常或分析操作失误等造成的，常常被视为噪声被剔除。但是也可能蕴含着重要的信息，比如，企业关系交易中的信用欺诈行为。诸如此类的小概率发生事件往往比经常发生的事件更有挖掘价值。
2预测。预测是指利用从历史数据集中自动推导出的对给定数据的推广描述，预测未知的数据值或变化趋势。
例如根据关系投资、关系企业规模和关系承诺等来预测关系价值。
3序列模式分析。序列模式分析把数据之间的关联性与时间性联系起来，不仅要确定事件是否发生，而且需要确定事件发生的时间。序列模式分析非常适于寻找事物的发生趋势或重复性模式。例如，对某关系在不同时段的关系互动状态行为进行分析，发现和探测稳定关系集。
4聚类分析。聚类分析是根据事物本身潜在的特性研究对象分类的方法。通过聚类把一个数据集中的个体或对象按照相似性归约成若干类别。其原则是使同一类别中的对象之间具有尽可能大的相似性。而不同类别中的对象之间具有尽可能大的差异性。如按照关系稳定性或关系价值大小对关系对象聚类。
5演变分析：演变分析描述的是随时间变化的行为的规律或趋势，并建立与时间的关系模型。例如。对随时间变化的关系的稳定性分析。
四、企业关系管理中数据挖掘的运用
1企业关系管理的数据仓库。企业关系管理中数据仓库的数据分为源数据、关系型数据和多维数据三类。将所有分散在不同部门、不同业务系统的数据按统一的标准进行提取后形成的数据我们称之为源数据。源数据是数据仓库开发的基础数据。关系型数据是在源数据的基础上，按照不同的业务需求整合形成的数据。关系型数据经过了对源数据的清洗和整理，能够保证数据的标准化，可以支持绝大部分对关系型数据库的分析和查询应用。且是建立多维数据的基础。多维数据是建立在关系型数据的基础上，针对不同的业务需求、从不同的视角产生的，能够提供满足业务需要的数据。
2企业关系管理中数据挖掘应用的几个方面。
(1)关系细分。基于数据挖掘技术的聚类功能可按照不同的标准，比如：企业关系对象的类型、企业规模、关系价值、关系稳定性和满意程度等来划分不同的关系对象群体。以实现对企业关系针对性的差异化关系管理策略，实现关系价值最大化。
(2)关系价值评估。企业若不评价估计企业关系的价值，就很难做出适时的关系管理策略。由于企业关系价值评价指标具有较强模糊性，常常采用数据挖掘的模型综合评价方法来评估关系价值的高低。数据挖掘技术还可以分析和预测不同情况下关系价值的变化，帮助企业制定合适的关系策略。
(3)关系质量、关系满意度评价。关系质量和关系满意度是关系主体根据一定的标准对关系满足各自需求程度的共同认知评价。不断的追求高关系质量和关系满意度是提高关系稳定性和获取最大关系价值的重要手段。已有大量文献表明，数据挖掘的统计回归分析方法是挖掘关系质量影响因素及分析它们之间相互关系的有力工具。
(4)企业关系方信用评估与机会主义风险识别和防范。数据挖掘技术可以为关系风险管理提供一个客观、准确的评估和控制机制。以数据统计分析为基础的数据挖掘技术，通过收集和分析关系对象的行为、信用和背景纪录，从大量历史数据中分析出具体企业关系的机会主义行为倾向及信用等级。另外，还可以通过孤立点分析还可以发现关系对象的一些异常行为，有效防范风险。
(5)企业关系状态预测。把握企业关系动态特征是关系管理的关键。数据挖掘技术通过对实时关系动态数据的采集和整理，将多源数据进行融合、分析和挖掘，提取企业关系状态特征，同时结合历史数据和未来预测数据对关系的发展演化过程进行仿真预测。
3企业关系管理的数据挖掘过程。根据上文对企业关系管理体系结构的描述，建立基于数据挖掘技术的企业关系管理系统模型如图2，它的工作流程主要包括以下三个阶段：
(1)数据准备阶段。它主要包括目标定义和数据预处理两个阶段。目标定义是了解企业经营要达到的目标，在此基础上进行企业关系的数据收集。数据收集主要在关系接触层，包括呼会面、电子邮件、电话、传真等方式。最初搜集的数据是源数据。比较分散且有大量冗余：要再按照不同业务需求过滤和筛选，保留其中的关系型数据：再对关系型数据分析、处理和集成转换，降低数据维数，形成适合数据挖掘的数据集合，最后再将此数据集合装入数据仓库。数据仓库的数据来源还可以是其他系统，如ERP、CPM、SCM系统中的现存数据。
(2)数据挖掘阶段。该阶段对应关系管理体系的分析层次，是整个基于数据挖掘技术的关系管理系统的核心。针对前一阶段处理、整合形成的数据集合。在模型库和知识库的帮助下，根据不同的业务需要，选择适合的数据挖掘模型、挖掘技术及工具，对数据仓库中的数据进行挖掘。并借助有关联系分析处理得到隐藏的企业关系知识及模式，并将分析出来的有用模式保存到模型库和知识库中。
(3)数据挖掘结果应用阶段。该阶段对应关系管理的决策层，数据挖掘和知识发现的最终目的就是辅助决策者做出决策。决策者可以根据数据挖掘的解释结果，结合实际情况，调整关系管理策略。以便企业更好地进行关系管理工作。并且，企业关系管理实践同时检验数据挖掘知识和模型使用效果，若效果不好则需要重新修改原有的模型，甚至是原有的目标重新定义。
五、结论
关系型数据库管理系统 篇4
数据同步就是借助数据复制技术将一组数据从一个数据源拷贝到不同物理地点的另一个数据源。中国石油集团搭建数据同步系统主要用于解决以下两个问题:
(1) 实现中国石油集团各机构业务系统之间数据的交换与共享, 这些系统由于开发时间与环境不一致, 因此, 所采用的数据库工具与所设计的数据库表一般差异较大。
(2) 中国石油集团各机构业务系统在更新换代过程中, 为了让用户拥有一段时间的适应期, 出现的新旧系统同时运行的过渡阶段, 这种情况下, 新旧系统的数据库可能出现重构, 并且旧系统中发生的数据变化需要实用同步更新到新系统中。
2数据同步问题分析
在搭建中国石油集团的数据同步系统过程中, 相关的调查现状如下:
(1) 从整体上看, 作为待同步数据的多个业务系统由于分别由各个机构在不同时期独立开发, 缺少关联, 因此, 所采用的数据库系统和数据表结构差异很大。
从数据库系统上分析, 位于地方县市的部门开发的系统多采用MYSQL数据库或者SQLSERVER数据库, 极少数采用了ACCESS数据库;位于省级部门开发的系统多采用ORACLE数据库或者DB2数据库。
从数据表结构分析, 基本上待同步的两个数据表之间不存在一致性, 并且出现很多数据字段同名不同义或者同义不同名的现象。
(2) 从业务逻辑上看, 数据同步过程中, 数据传播方向分为两类:一类是数据在同级系统间进行复制, 这类业务虽然要求数据复制周期较短, 但是允许存在时间延迟。一类是数据由下级系统向上级系统进行复制, 这类业务主要用于分析, 可接受的数据复制周期较长。
所以, 系统并不像金融系统那样需要实时保证数据的紧密一致性。为了提高系统的可用性, 在实际应用中, 各节点之间的数据采用异步复制。
可见, 数据同步的难点主要在于对数据异构性的处理和对数据复制时效性的控制。
3数据同步方案设计
完成一次数据同步任务的过程由数据捕获, 数据转换和数据传输三个标准步骤来执行。
图1展现了数据同步的标准数据复制流程。
经过调研, 在现有技术中, 本文发现利用这三个标准步骤来执行同步的方案仅限于数据库表字段之间彼此一对一的复制, 不能支持涉及跨库跨表的多字段映射关系的复制需求, 其问题就在于数据转换模块只能处理两表之间互相关联的两个数据字段之间的一对一类型转换关系, 而难以处理多表之间互相关联的多个数据字段之间的复杂转换关系。
而在中国石油集团的同步应用场景中, 为了在不改动当前各类应用系统的数据资源结构的基础上实现分布式数据库系统的数据同步目标, 就必然涉及在同步过程中需要完成对数据字段之间复杂转换关系的处理, 这就意味着数据转换模块必须能够承担足够复杂的数据分析处理任务。
为此, 本文在三个标准步骤的基础上特别设计了一个智能数据转换中心, 并基于该数据转换中心, 将同步的源数据库和目标数据库区分为同步源区和同步目标区, 每个同步源区和同步目标区都可以拥有不止一个数据库, 它们之间的复杂数据转换关系依靠智能数据转换中心进行处理以便满足中国石油集团的数据同步应用场景。
3.1数据捕获
本文通过对目前常用的七种数据捕获技术的优缺点进行对比分析发现, 控制表法能够获取各种方式操纵数据库所引起的变化数据, 具有普遍适用性, 且不需要修改表结构, 不会影响原业务系统的性能, 在时效性上十分灵活, 其设计思想最适用于中国石油集团各机构业务系统的数据同步应用场景。
但是, 控制表法要为每个进行同步的源表T创建一个控制表C, 这对拥有大量需要同步的源数据表的同步应用来说是十分占用数据库空间的。因此, 本文在控制表法设计思想的基础上, 做了一种改进的用于异构数据库同步的变化数据捕获方法——同步变化表法。
该方法在每个要同步的源数据库中只创建一个同步变化表, 同步变化表里面包含发生变化的源数据表的表名, 数据项所在源数据表的主键值, 数据变化的类型 (插入、删除、更新) , 数据变化时间和数据同步的状态 (已同步、未同步) 。当源数据表中的数据发生变化的时候, 通过在其上建立的删除、增加和修改触发器向同步变化表里面添加相应的记录信息。这些记录信息被用于在同步过程中查找变化数据的完整信息, 并且在数据被同步成功后删除, 有效的减少了数据库空间的占有量。
3.2数据转换
为解决中国石油集团异构数据之间复杂的转换关系, 本文设计了一个智能数据转换中心, 该转换中心利用数据整合、数据计算和一个可以自由灵活扩充的计算公式库用于处理对应复杂数据关系的转换。
智能数据转换中心会将提取的变化数据按照系统规则整合为约定格式的XML文档, 该XML文档详细描述了每个数据的来源数据库、数据表名称、数据字段与数据类型。之后由数据计算中心按照配置的数据转换关系从XML文档中提取相关数据并调用计算公式库中的算子进行分析得到目标数据表要求的数据格式, 并将这些数据转换为对应目标数据库的SQL脚本进行输出, 从而完成复杂数据关系的转换。
3.3数据传输
为保证传输周期的灵活性, 本文采用定时器技术以自由指定周期的轮询方式进行数据传输。图2展现了本文设计的数据传输模块的处理流程。
4数据同步方案实现
4.1同步实例
以中国石油集团某机构下级业务系统向上级系统汇总油井数据同步应用为例。
在这一同步应用场景中, 一个地区存在多个并行的下级业务系统负责管理其所分配的若干口油井。上级业务系统每天会获取一次这些下级业务系统的当日采油量数据进行汇总, 从而得到某一地区每日采油量数据。
4.2系统实现
很显然, 在汇总采油量数据的同步应用中, 是一个多对一的复杂数据转换关系。同步源区包含多个下级业务系统对应的源数据库, 同步目标区只包含一个上级业务系统对应的目标数据库, 在同步过程中, 对应一个地区的采油量数据需要对地区包含的每一个下级业务系统对应数据库中的每日油井信息表数据做汇总计算得到, 为此, 按照本文所设计的同步方案, 同步系统实现如下:
(1) 需要在下级业务系统数据库中增加同步变化表如表1。
(2) 为每日油井信息表daily Oil添加增删改触发器, 用于捕获每日变化数据到同步变化表中。
(3) 在智能数据转换中心中将这一种复杂数据转换关系配置在映射文件中如下:
可见, 在数据转换关系映射文件中记录了上级业务系统每日采油量信息表Area Oil所需要的数据对应的每个地区的源数据库链接地址, 数据转换的计算方式, 各个字段与源数据表字段的关联关系, 源数据表名称和轮询周期。在执行过程中, 智能数据转换中心将根据这些信息定时提取源变化数据集合做相应计算完成复杂数据转换。最后, 本文采用JAVA语言对系统做了实现。
5结语
本文设计的多级异构数据库智能同步分析系统可以在不改变原有系统业务逻辑和数据资源结构的基础上来完成不同异构数据的同步处理任务, 有效满足了中国石油集团的分布式系统数据同步应用场景。该系统采用类似插件开发的问题解决思路, 具备很广的通用性, 可普遍适用于不需要保持数据副本紧密一致性的各类数据同步应用场景。
参考文献
[1]杨淼淇, 叶国权, 孙纳新.异构数据库的变化捕捉和动态同步策略的研究与比较[J].办公自动化:综合月刊, 2010 (03) :35-37.
[2]杨鹏, 杨海涛, 王正华.异构数据库变化捕捉及同步策略[J].计算机工程, 2008 (16) :53-55.
客户关系管理与数据挖掘 篇5
1.客户关系管理的定义
客户关系管理首先是一种管理理念，其核心思想是将企业的客户作为重要的资源，通过完善的客户服务和深入的客户分析来满足客户的需求，保证实现客户的终生价值。
CRM又是一种旨在改善企业与客户之间关系的新型管理机制，它实现于企业的市场营销、销售、服务与技术支持等与客户相关的领域。通过向企业的销售、市场和客户服务的专业人员提供全面、个性化的客户资料，并强化跟踪服务、信息分析的能力，使他们能够维护一系列与客户和生意伙伴之间卓有成效的“一对一关系” 从而使企业得以提供更快捷和周到的优质服务.提高客户的满意度。
CRM也是一种管理软件和技术。它将最佳的商业实践与数据挖掘、数据仓库、一对一营销、销售自动化以及其他信息技术紧密结合在一起，为企业的销售、客户服务和决策支持等领域提供了一个业务自动化的解决方案，使企业有了一个基于电子商务的面对客户的前沿，从而顺利实现由传统企业模式到以电子商务为基础的现代企业模式的转化。
2.客户关系管理的研究和应用现状
CRM起源于20世纪80年代初提出的接触管理，即专门收集整理客户与公司联系的所有信息。到20世纪90年代初期则演变成为包括服务中心与支持资料分析的客户服务。经历720余年不断演变发展，CRM逐渐形成了一整套管理理论体系和应用技术体系。
从全球的范围看，市场对CRM的需求已经比ERP高，CRM销售量每年的增长率超过了30%，而ERP只有10%。的销售额达到了 140亿美元之多，企业信息化的重点从后台系统转向了前台。在国内，多数企业将大部分力气投入到企业内部信息系统得建设上，这意味着CRM在我国的应用还不成熟。
CRM应用最广泛的领域是与科技和计算机相关的领域，这一领域中的企业由于信息化程度高和自身的优势，能够通过CRM系统建立起与客户之间的有效价值链，从而铲射功能更大的效益，
而在我国生产总值中占据重要地位的传统企业在CRM的市场中所占比例较小。加入WTO后企业面临着更为严峻的国际竞争，因此企业迫切需要寻找类似CRM的新思路、新理念来增强企业的竞争力。现在市场中CRM供应商较多国际的有Siebel、 Oracol、Borland、sybase，国内的用友、中圣、金蝶创智等。[next]
二、数据挖掘是CRM成功的保障
大量数据的产生和收集导致了信息的爆炸，但信息仅仅停留在这个阶段，未对这些信息进行适时和深层次的分析，致使企业对客户知识的缺乏。数据挖掘可以从繁杂的数据中找出真正有价值的信息知识，提高企业对客户了解程度，时时快捷的发现并满足客户的需求，从而提高企业的竞争力。
1.数据挖掘使市场信息触手可及
数据库及数据挖掘技术可以扩展企业核心业务过程的信息后勤基础，通过数据挖掘来保证对数据的访问及分析，从而提高业务过程的有效性。当企业通过数据仓库直接向其顾客索取某些信息密集型顾客支持过程的资源时，支持成本会不断地下降，企业的管理成本也就随之降低。
利用信息技术和数据资源，不断地增强对客户的了解程度，使客户感觉好像与企业有一种独一无二的个人关系，具有有效的信息文换和访问能力，与客户打交道变得更容易一些。数据挖掘技术基于事实，利用数据仓库中产品、价格、投资、分配等方面，从浩瀚的信息海洋中提炼出有价值的信息，发现隐含在这些信息中的对等的、不明显的、不可预知的模式、趋势和关系，为企业提供决策的依据。
2.数据挖掘将数据加工成信息和知识
在CRM 中，数据仓库将海量复杂的客户行为数据集中起来建立一个整合的、结构化的数据模型，在此基础上对数据进行标准化、抽象化、规范化分类、分析，为企业管理层提供及时的决策信息，为企业业务部门提供有效的反馈数据。数据挖掘对客户资料进行分析，是挖掘客户潜力的基石。
关系型数据库管理系统 篇6
一、数据仓库是企业CRM的核心
面对日益激烈的市场竞争，客户越来越成为企业最重要的资源，企业要理解客户、影响客户就必须通过不断地获得与客户相关的信息，了解客户，进而为客户提供个性化服务，从而提高客户的满意度和持久度，为企业创造利润。然而在企业中客户数据可能存在于订单处理、客户支持、营销、销售、查询系统等各个环节或部门，产生这些数据的系统是专门为特定的业务设计的，并拥有关于客户的部分信息，因此企业要想成功实施CRM首先必须把这些分散的客户信息集成起来，这涉及到CRM如何与企业现有的系统进行连接，目前一种普遍的做法是将CRM与数据仓库相结合，建立时需要考虑以下几方面的因素：
1、CRM中数据仓库的是客户数据的集成。CRM数据仓库的建立需要把企业内外的客户数据集成起来。从这些不同信息源中对个别顾客进行分析、识别，并寻求这些顾客间的相互关系，如有一些顾客可能有亲属关系。就客户数据集成来讲，主要包括两个方面：其一，企业需具有对顾客进行匹配和合并的能力。其二，记录的匹配和合并的完整性和准确性是很重要的。此外，如果把本不应合并的记录合并了，这时对客户的看法也是歪曲的。这些不完整、不准确和不可靠的匹配都会导致不准确的分析结果和决策，导致企业费用的增加和利润的减少。因此，对于CRM客户匹配和建立完整准确的数据仓库来讲，姓名和地址这两个信息片断是很重要的，没有姓名和地址所进行的客户匹配是不充分的。
2、保持已有客户和添加新客户与别的类型的数据仓库有着诸多不同，CRM数据仓库的维护更具有挑战性。CRM中的数据仓库是逐渐更新的，而不是一次性完全更新的。这主要基于两个方面的原因：数据仓库所利用的信息源中的历史数据经过一段时间后可能被擦掉；在每次更新时，都重新进行客户记录匹配和重新建立数据仓库的做法工作量太大，不可行。比较合理的做法是，在保留已有数据的基础上，每次更新时都加入新的数据。首先识别新数据是关于新客户还是关于数据仓库中已有客户，如果是新的客户数据，就要给这个客户一个独立的标识，在数据仓库中插入一行，如果是关于已有客户的数据，就要对这些客户记录的相关信息片断进行更新。把客户数据仓库的更新与销售数据仓库的更新做一个比较。每个既定的时间点，新的销售数据被加入到销售数据库中。在此过程中，不需要把新数据与已有数据进行匹配，不会对已有的数据进行修改。这种更新是全新数据的载入，比上面所讨论的客户数据的更新要简单。
3、建设和维护企业CRM数据仓库的工具选择。建设和维护企业CRM数据仓库有两种类型的工具。其一是转换工具，其二是清理工具。前者满足了一般数据仓库的建设和维护需求，通常熟悉的数据仓库工具属于这个行列，它的主要功能是数据抽取、转移和数据载入。但它没有姓名和地址清理、模糊匹配和合并的功能，与已有的数据库的同步化能力比较弱，客户合并的能力也很弱。其主要目标是为OLAP服务，而不是详细的客户水平的数据。后者则可以满足一些特别的需求，但没有提供通常的建设和维护数据仓库的功能，即没有提供抽取、数据载入和更新、元数据管理的功能，其核心工作是清理和匹配。尽管转换工具和清理工具的功能在某些环节上有着交叉，但它们大部分功能是互补的。因此在建设CRM数据仓库的时候，对这两种工具都是需要的，以实现数据和元数据层次的集成，而这种集成常常很费时间，成本也较高。
二、数据仓库企业CRM系统的构建
数据仓库是CRM的灵魂，在CRM中充分发挥数据仓库的作用是CRM系统成败的关键之一，企业利用数据仓库和数据挖掘技术加强客户关系管理势在必行。通过企业CRM数据仓库的建立，实现全部客户数据的集中存储和管理，使不同部门接触客户后的经验能立即与其它部门分享，从而支持整个企业的相关数据分析，提供面向整个企业的决策功能。同时随着信息技术的不断发展，各企业通过建立多种与客户交流的渠道，将面对面、电话接洽、E-mail、Fax或信函以及Web访问协调为一体，以提供更快速和周到的优质服务吸引和保持更多的客户。
以数据仓库为基础的企业CRM系统构架如图所示：
从图中可以看出以数据仓库为基础的企业CRM系统包括三个层次：
1、信息采集系统。数据仓库是企业CRM的基础，可以满足系统对各方面数据的要求，包括客户基本信息、产品、交易信息、反馈信息等等。这些数据可以分为两部分：一是前台数据即来自企业外部的数据，包括客户基本信息（如客户姓名、年龄、性别、地址、联系电话等）、客户行为信息（如客户订货情况）等等，这些信息是海量的，而且是分散的，企业可以通过多种渠道（展销会、Web、电子邮件等）完成CRM数据收集。另一部分数据是来自于企业内部日常运作过程中所产生的信息流，称为后台数据，包括企业产品信息、服务信息、资产数量及其分布情况等等。它们可能分布在不同的硬件、数据库、网络环境中，为不同的业务部门服务。从结构上看，它们是相对独立的，这部分数据一般通过企业内部网络链实行信息的共享与集中。因此，与前台海量数据相比是比较集中的，也比较容易获得。通过信息采集系统企业前台与后台数据被抽取到CRM数据仓库中，利用数据仓库的星状资料模式（Star Schema）的思想，建立数据仓库模型，把数据集成一个统一的整体，得到提供面向全局的数据视图，再以此为基础进行抽取、集成与转换，并以客户信息数据仓库的形式存储。
2、客户服务支持系统。企业建立CRM系统的目标之一是要留住客户，在很多情况下，客户的保持和提高客户利润贡献度依赖于提供优质的服务。因此，客户服务和支持对企业来说是极为重要的。客户服务支持为客户提供了客户服务热线、服务网站等功能。它是企业提高客户满意度、忠诚度从而达到留住老客户、发展新客户的一个重要手段。从数据流向来看，此时的数据应该是双向的。从功能上来看，客户服务支持系统一般包括了客户账号管理、服务合约管理、服务请求管理、联系活动管理以及客户普查等功能。通过这些功能，服务人员能快速地查询客户的服务合约确定客户的服务级别，并创建、分配客户的服务请求。服务人员还可以随时查询与客户的联系记录以及服务请求的执行情况。此过程也将充分利用CRM数据仓库的信息，如客户呼叫中心在为客户提供服务时需要实时查询客户基本信息（信用情况、账户情况等）。客户服务系统为客户的服务过程包括用户的反馈信息也将被CRM数据仓库所记录，以作为今后提高服务响应速度、改善客户服务，提高客户满意度，对服务人员进行考核的依据。
3、信息分析系统。如果对于企业CRM系统而言信息采集是一个起点，那么对所获得的信息进行分析则是支持企业决策的依据。企业CRM系统除了将各个渠道得来的数据，整理成全面、完善的CRM数据仓库之外，还应具备对信息进行分析的能力。在这里的信息分析有两个方面的含义，一是对客户行为的分析，目的是发现客户的偏好，预测客户的个性化需求，以便于企业设计符合客户需求的产品或服务，协助企业制定针对性的营销策略；另一个是对客户反馈信息的分析，目的是通过对“过程”、“客户状态”、“客户满意度”和“客户成本”的评估、检测和分析，帮助企业及时、准确、全面地掌握自己的客户服务水平、销售服务机会等情况。
事实上企业在日常的营运过程中储存了大量详细的客户轮廓的信息和客户交易厅行为的历史数据，这些数据经过抽取、转换和装载过程，形成数据仓库，通过对这些数据的分析来发现隐藏在数据后面的真实情况，并将客户行为数据与其他相关的客户数据集中起来，对客户进行统一的规划，能帮助企业以科学的手段快速地分析、模拟和预测客户的个性化需求，进而设计符合客户需求的产品或服务，为市场分析提供依据。此外，借助于数据仓库的数据清洁与集中过程，将客户对市场反馈信息自动输入到数据仓库中，建立在数据仓库基础上的数据挖掘和多维数据分析，则能够提供强大的市场分析功能。数据仓库为企业提供了综合运行不同平台上的业务数据，能进行不同产品或服务的盈利性分析和风险性分析，以最大限度地增加企业利润和利润占有率。
多级安全关系数据库管理系统 篇7
关键词：多级安全,数据库,管理
0.引言
国内外对于多级安全数据库管理系统研究领域已经开展了很多研究,而且设计了许多的多级安全数据库体系架构。这些体系架构主要分成TCB子集结构(TCB Subset DBMS)、可信主体结构(Trusted Subject DBMS)和外部封装体系结构等三类。
1. 访问控制模型概述
安全模型是概念模型的一种,其具有独立于软件实现以及高层抽象等特点,亦称作策略表达模型。在各种安全系统中(数据库系统也包括在内),安全模型能够有效的将该系统的安全策略和安全需求精确地描述出来。自上世纪70年代起,很多安全模型相继出现,而最重要的安全策略则是实施访问控制。仅有被授权的用户、程序或进程才能对系统资源进行访问,即访问控制,其对系统谁能访问,系统的哪些资源能够被访问,怎样对这些资源加以使用等做出决定。对于未经允许的用户采取适当的访问控制可防止数据被他们无意或有意获取。
安全模式以不同的访问控制策略类型为依据,可分成强制访问控制(MAC,Mandatory Access Control)以及自主访问控制(DAC,Discretionary Access Control)两种类型。
对于用户或用户组,即系统中的主体以自身的身份以及安全策略为依据,允许访问系统中的信息对象的模式,例如通过读、写等手段对用户访问信息对象进行控制,这就是DAC即自主访问控制的基本思想。对象由单个用户生成,单个用户拥有对象;对象的拥有者可完全支配对象,对其它用户能否访问该对象做出决定。DAC这种访问控制策略允许主体施加特定限制给访问控制。主体被允许设置访问控制权限给访问资源的用户,系统在用户访问资源时会对用户访问该资源的权限进行检查,用户能够访问资源的前提是通过验证,反之该用户则无权对系统继续访问。访问矩阵是自主型安全模型的典型代表。在数据库管理系统以及操作系统中该模型均可使用,访问矩阵的基本思想是,在全局矩阵A中存储全部的访问控制信息,主体表示为A中的行,客体表示为A中的列,A中的每一个元素代表i(主体)有权访问j(客体)。如:在某系统中,有User1、User2以及User3三个主体,有O bject1、O bject2、O bject3以及O bject4四个客体。
简单易行、直观明了是该方法的优点,不过每有一个主体或客体增加,都要将其与其它全部客体或主体比较,所以更新等操作相当麻烦,需要付出很高的代价。怎样对特洛伊木马的攻击进行有效抵御是DAC普遍难以解决的问题。在拥有对象者不知情的情况下,为了将访问控制机制绕过,破坏、篡改或者修改系统信息,木马能够以属主的身份授权攻击者,或者以某种方式表示信息,使攻击者能够访问信息。利用无法逃避的访问控制,强制访问控制能够对各种攻击,包括直接的和间接的加以防止。系统在强制访问控制下会指派不同的安全属性给主体和客体,在没有改变系统安全策略的情况下无法轻易改变这些安全属性。系统对主体和客体的安全属性是否匹配进行检查,以此对允许继续访问与否进行判断。包括用户自己的数据资源在内的所有数据资源用户都无权赋予其它用户访问权限,所以数据的访问控制不能简单指派,这是强制访问控制与自主访问控制的不同之处。BIBA模型以及BLP模型等是强制访问控制模型的典型代表。
如果系统对安全性的要求不高,其安全性需要自主访问控制即可满足。而在一些有较高安全性要求的系统中,如国防、军事等的应用中,强制访问控制必须实现。不过如果系统中只有强制访问控制,则会出现无法正常使用很多资源的现象。所以,以MAC为主,辅以DAC的访问控制策略适合在有较高安全性要求的系统中使用。
2. 完整性锁体系结构
完整性锁体系结构(Integrity Lock Architecture)是一个可信主体DBMS体系结构的重要的变种。
在锁体系统的构成中有三个重要的组成部分,一部分为不可信前端进程,另一部分可信的筛选器进程,最后一部分为不可信的数据管理器进程。
不可信前端进程和用户进行交流,任务是进行查询语法分析,并返回给用户处理器所查询结果。可信的筛选器进程就是把数据数据库对象及其安全标签进行加密与解密。可信前端把每个元组进行校验和后必须将有关这些操作都完成,有效提高了TCB的复杂性。除此之外,验证校验和通过修改后产生后察修改,但无法有效修改以及删除组织数据。
3. 改进的MLS/DBMS体系结构
本文前文讨论了安全管理体系常见的系统结构。在本部分的讨论过程中,提出以本人工作经验为基础的MLS-DBMS体系结构,对此结构进行系统的分析以及其对数据库管理系统的作用机理,并集合代码对其安全内核以及相关安全模块进行分析。
本文可信的操作系统使用的是Seclinux,如图1展示体系结构。
本系统构成由四个安全等级组成,分别为:系统公开级别(Unclassified),系统秘密级别(Confidential),系统机密级别(Secret)、系统绝密级别(Top Secret)等四个等级。具有安全内核的安全数据库管理系统SECBase,各个安全等级的DBMS实例,可信操作系统Seclinux,以及各级数据片段是这个体系结构主要包括的四个部分。这个体系结构中,用户端被SECBase安装了相关安全机制,它可以对来自不同安全等级用户端的操作进程对DBMS来讲是否可信进行了保证。
在上述的四个安全级别中每个安全能级均存在级DBMS分支,并且利用每一级数据库的不同而创造具体实例。其中包括本级层次的数据以及通过本级别数据调配的子集单级数据库,系统受到了由单级DBMS传输而产生的用户请求后,由能够确保DBMS和数据的完整性,将采用可信操作系统Sec Linux对各级数据文件进行访问,这样不仅充分使可信操作系统的安全功能被充分利用,同时还利用可信操作系统达到MAC。
多级安全数据库根据其安全级别被分解为多个分别存储的单级数据库,每个单级数据库对应一个安全级别,数据库的数据被分别存储在各级数据磁盘中,根据安全级别进行成严格的区域分割,而且可以利用相应的访问控制规则对各个区域之间的访问进行控制。自主访问控制模块(DACM)、强制访问控制模块(MACM)、推理控制模块(ICM)、安全约束处理模块(SCM)和审计模块(AM)就是SECBase安全内核主要的模块。只要用户登陆成功,就可以提出访问请求。
4. SECBase安全内核相关模块
4.1 自主访问控制模块
自主访问控制做表一级的权限检查。用户的访问请求经分析解释以后传递给自主访问控制模块,自主访问控制模块检查该用户是否对该表进行诸如插入之类操作的权限。当自主访问通过控制检查,强制访问控制模块就会接收到用户的访问请求,否则就拒绝用户的访问请求。在DBMS启动时自动加载了用户权限,一个用户对一个表具有的权限都被这个表中每条元组进行一一记载。
系统管理员(DBA)进行负责自主访问控制,利用GR AN T和R EVO KE连个操作对用户进行授权和撤销权限。
4.2 强制访问控制模块
强制访问控制是通过用户无法回避的存取限制来防止各种直接和间接的攻击。通过了自主访问控制检查的用户请求被送到强制访问控制模块进行强制访问控制检查。当通过了强制访问控制检查,推理控制模块也接受了用户的强求,否则就拒绝请求。半元组级标记在SECBase中达到,对实体多实例和元组多实例也支持。普通用户对不大于自身安全等级的数据实体进行创建。
4.3 安全约束处理模块
根据递给推理控制模块接受了释放的安全约束并进行处理,其他类型的安全约束采取来计算密级模板。安全约束定义我们可以从下面得出:
struct Security_Constraints{int N um//约束编号Label Typeleft//“”的左边的变量Label Typeright//密级常量或变量charselection_control//选择条件,就是这个安全约束采用的范围}。
本文建立的是一个以安全约束图为基本安全框架的密级分配算法并且以基础构建的安全算法为基本对安全约束图进行二次约定。进而通过二者的相互制约达到安全系统相互牵制的作用。建立安全约束图仅仅是为了保证约束的执行顺序能够安全合理,所以建图时对于选择条件可以不用考虑。
参考文献
[1]Bell D.E.,LaPadula.L.J.Secure Computer Systems:Mathematical Foundations.ESD-TR-73-278,Vol.I,AD 770 768,Electronic Systems Division,Air Force Systems Command,HanscomAir Force Base,Bedford,MA,USA,Nov 1973.
[2]Bell D.E.,LaPadula.L.J.Secure Computer Systems:AMathematical Model.ESD-TR-73-278,Vol.II,AD 771 543,Electronic Systems Division,Air Force Systems Command,HanscomAir Force Base,Bedford,MA,USA,Nov 1973.[14]Landwehr,Carl E.,Connie L.Heitmeyer,and John McLean,A Security Model forMilitary Message Systems,ACM Trans.Computer Systems,Vol.2,No.3,Aug.1984,pp.198-222.
[3]Graubart,Richard D.and John P.L.Woodward,“APreliminary Naval Surveillance DBMS Security Model,”Proc.IEEESymp.Security and Privacy,Oakland,Calif.,Apr.1982,pp.21-37.
[4]Denning D.E.,Lunt T.F.and R.R.Schell et al.A multilevelrelational data model.Proceedings of 1987 IEEE Symp.Securityand Privacy.Oakland,CA.IEEE Computer Society Press.Apr.1987.
[5]Denning D.E.,Lunt T.F.,R.R.Schell et al.The SeaViewsecurity model.Proceedings of 1988 IEEE Symp.Security andPrivacy.Oakland,CA.IEEE Computer Society Press.Apr.1988.
[6]Thuraisingham B M.A nonmonotonic typed multilevellogic for multilevel secure database&knowledge-base managementsystems.Proceedings of the 4th IEEE Workshop on ComputerSecurity Foundations,1991.pp.127-138.
关系型数据库管理系统 篇8
数据库技术诞生于20世纪60年代末, 从诞生至今已经发展到了第三代数据库。第一代数据库为层次与网状数据库系统, 第二代为关系型数据库, 如今发展到以面向对象数据模型为主要特征的第三代数据库系统。从层次型与网状型数据库跨越到关系型数据库要归因于20世纪70年代美国E.F.Codd提出的关系型数据库的数学模型。此后, 关系型数据库得到了长足的发展, 目前已经成为主流数据库类型。目前虽然面向对象的数据库、分布式数据库和多媒体数据库等新型数据库获得了长足发展, 但是还没有从根本上摆脱对关系型数据库的核心技术。因此, 目前的商用数据库仍然选择了关系型数据库。
ERP, 即企业资源计划 (Enterprise Resource Planning) , 是建立在信息技术基础上的系统化的进行企业管理、决策的平台。ERP的发展历经了MIS (Management Information System) 阶段、MRP (Material Require Planning) 阶段、MRP I (Manufacture Resource Planning) 阶段而进入了ERP阶段。ERP系统应具备的标准功能包括超越MRP II范围的集成功能、支持混合方式的制造环境、支持能动的监控能力并提高业务绩效、支持开放的客户机/服务器 (C/S) 计算环境。ERP系统的管理对象是企业内的人力资源和资产, 包括固定资产和存货, 以及在这个基础上运作的企业流程。
二、企业建立小型数据库的必要性与可行性
1、必要性
企业在运作过程中产生了大量的信息, 这些信息需要加工、整理、储存、共享, 使信息的需求者能在需要的时候方便地得到相关信息。对于已经实施了ERP项目的企业, 诸如财务、库存、生产、质量等关键数据都已经全部或部分整合在ERP中。但是对于这些企业基础数据以外的一些信息, 由于其本身所具有的零散性、随意性、临时性等特点而无法集成到ERP系统中去。但是这些信息却是企业各部门运作当中所不可或缺的。对于其中一部分的内容, 只是日常工作中临时需要, 而无保存价值, 这部分的信息没有进一步加工、保存的必要。这类信息大致包括口头通知、简单直接的操作指令、对工作状态的查询申请等。而对于其他的内容, 则由于其相对重要, 且可能被反复利用, 需要储存以备将来查询, 则有必要妥善保管、仔细维护。这类信息包括各种统计结果、调查分析报告等。此外, 对于部分已经集成到ERP系统中去的信息, 由于以下一些原因而有必要再建立独立的辅助信息系统单独管理这些信息, 形成对ERP系统的备份:
(1) 用户操作不便。ERP系统中的数据和格式都有规定形式, 统一的用户界面, 这样的界面通常是为企业运作所必须。但是往往在某些场合需要对信息进行快速查询, 显示用户需要的信息, 但是这样的要求往往并不容易得到满足。一方面ERP系统的用户界面灵活性有一定的制约, 不可能任意满足客户的需求。另一方面开发不同的用户界面要求ERP系统的维护商付出额外的努力, 这往往是需要经费支持的。
(2) 对正式数据要求的严谨性使得用户为了满足系统的流程需要而操作产生很多无效的记录或无法录入的记录。例如, 没有库存的产品在ERP系统中是无法交货的, 但如果因为情况特殊入库的产品无法录入系统, 则ERP系统将由于没有相应的产品库存而拒绝发货。但实际情况并非如此, 可能产品因为顾客急需而提前发出, 这样就需要有独立的系统记录这种特殊的物料移动。此外, 当系统中的数据失真需要调整时将产生很多的虚假记录, 这些记录是为了记录调整而产生的。过多的类似记录将为以后追溯历史记录造成很大的困惑。如果有辅助的系统记录真实的历史记录, 则可以帮助用户方便地进行记录查询。
2、可行性
数据库是按照数据结构来组织、存储和管理数据的仓库, 分为物理数据层、概念数据层和逻辑数据层。数据库可实现数据共享, 减少数据的冗余度, 可对数据集中控制, 使数据得以保持一致性、独立性和可维护性, 增强了数据的安全性和可靠性。数据库一般分为层次型数据库、网络型数据库和关系型数据库, 当前的主流数据库是关系型数据库。
对于企业运作所产生的数据来说, 这些数据结构相对简单, 对操作、查询的要求不高, 这使利用关系型数据库管理这些数据成为了可能。目前市场上有很多商用小型关系型数据库可供开发利用, 如DBASE系列, Fox Base, Fox Pro, Inter Base, MSAcess, SQL Server, Oracle, DB2等, 也有一些开放源代码的可供利用, 典型的如My SQL。小型关系型数据库相对简单, 编程容易, 即使是业余爱好者也可以开发出简单的事务系统。此外, 面向用户的可视化界面使开发出的数据库具有良好的操作性能, 能够为广大用户所接受。
三、开发实例
为了满足企业对数据管理的需要, 笔者以ACCESS为开发平台为企业开发出简单的事务管理系统做为ERP系统的补充。ACCESS的特点是简单、方便, 多数公司内都使用Office办公软件, 可得性强, 部署方便。但ACCESS也有很多缺点, 如不能编译成可执行文件、安全性不高、多用户条件下操作性差、数据库容量有一定限制等问题, 但对于我们所需要的辅助性的简单事务系统来说是足够满足用户需求的。
确定了数据库软件后, 首先要做的就是对用户的需求进行调查, 在此基础上确立数据库的基本功能。为了简便起见, 笔者首先选取一个部门作为数据库开发的起点。部门级的数据相对简单、功能类似, 用户要求一致性强。经过访问, 我们发现, 在公司各个部门中, 以仓库的信息最为庞杂, 经常需要进行大量的查询, 是各个部门所需信息的提供者, 对信息管理的要求也最为迫切。对于仓库, 他们需要对物料的出入库进行记录, 需要显示库存情况, 需要对物料的基本信息随时查询, 需要对历史记录调阅, 需要对发货情况进行跟踪等。仓库所要处理的事务涉及原材料、产成品、废弃物、样品的收发货、库存的管理, 以及其他部门内部的事务管理。
在了解了用户的基本需求后, 就要对系统涉及到的数据结构进行分析。这一步涉及到数据库的基础数据结构, 是数据库设计的核心, 因此需要特别谨慎。该企业的物料数据结构极为复杂, 整个数据分成四个层次:第一层是通用代码, 其作用是唯一确定了某物料, 具有与某种物料一一对应的关系;第二层是半成品代码, 代表着某种产品未包装的状态;第三层是产成品代码, 对应着包装好的产成品;第四层是销售服务代码, 对应的是不同包装不同产品名称的某种产成品。根据分析, 我们认为, 半成品的代码只是在生产过程中使用, 销售服务代码也只是客户服务所需, 都不是仓库所期望处理的数据。所以数据库所要处理的数据就只有通用代码和产成品代码了。鉴于产成品代码与通用代码之间存在着映射关系, 所以决定以通用代码作为数据存储的基础结构, 产成品代码通过不同的包装类型与通用代码的结合来体现。对于其他种类的物料, 同样可以套用类似的数据结构。但为了区分不同类型的物料, 在编码结构上考虑使用可明显区分不同类型数据的编码方法。
数据结构确定之后, 就是根据用户的要求来设计用户界面, 具体实现数据录入、数据查询、数据打印、数据分析等功能。在这一设计过程中, 以下一些要点必须得到注意:
(1) 良好的用户界面是用户乐于接受该事务系统的前提。良好的用户界面使得用户可以方便地操作, 毋须数据库的知识就可以使用。用户可以在统一的界面上操作, 排除了非法操作的可能。
(2) 对于各项操作、查询等要根据用户的需要安排合适的规格。恰当的数据显示规格将方便用户的使用, 节省用户的时间。
(3) 从简化操作步骤出发, 在操作界面的安排上尽量方便用户的使用, 以自动的方式响应用户的需求。
在数据库的设计基本成型后, 需要用户将基础数据录入系统。这是一个比较辛苦的阶段, 毕竟不是所有的数据都可以方便地一次性上传至系统, 有些数据需要用户手工输入, 工作量比较大。造成这一局面的原因是有些数据没有汇总归档, 处理方式随意不够规范, 致使数据无法得到数据库的处理。
数据录入系统后, 用户就可以对系统进行测试。在测试中发现问题后应对系统中的错误及时更正。这是系统开发的最后阶段。测试结束后该事务管理系统就可以正式交付用户使用。
四、结论
经过用户一段时间的使用, 用户对这套事务管理系统基本满意。用户对其评价是方便、可靠、易用, 对日常工作有很大帮助和支持。用户拥有了统一的操作平台, 改变了过去信息各人随意处理、分别保管、查询不易的局面。而且对于部门级的用户来说, 该事务管理系统基本开发成功。该套系统的开发成功为以后将其推广到其他部门去提供了经验, 也打下了基础。
在数据库开发过程中同样遇到了很多困难。例如, 用户需求的多变性使得数据库的开发经历了反复修改, 增加了开发的工作量。用户新增加的对数据的需求与调查过程中得到的信息不一致, 致使数据结构无法统一, 只能另外安排, 造成了数据的通用性差, 影响了数据库的使用效率。因此, 如果能在系统规划阶段就尽量全面地考虑到将来的使用情况, 尽量为所有可能的操作预留接口, 使系统具有良好的可扩展性能, 是系统设计时必须予以考虑的。此外, 对于类似于EHS部门这样的与企业生产资源关联度不大的部门, 可以考虑为其单独开发一个适合于本部门使用的管理系统。其他部门可以通过共享的方式访问该系统, 但没有操作权限。最后, 数据库开发还应注意的一个问题是哪些已经在ERP系统中存在的数据是需要数据库来管理的。因为企业运行的核心数据已经在ERP系统中运行, 所以哪些数据需要额外的记录就必须慎重考虑。一般认为, 只有那些比较重要且需要重点管理的数据才有价值为ERP系统已经存在的数据进行备份。否则将造成用户负担过重, 重复劳动过多。
关系型数据库管理系统 篇9
关键词：学员信息管理,关系数据库模型,数据库模式,数据库模式规范化
0 引言
学员信息管理系统能极大地方便学员管理工作者，将其从繁重、复杂的学员管理工作中解脱出来，以科学、严谨、程序化的制度来规范学校学员管理过程，并以其强大的数据处理及统计分析功能适应学校灵活多变的业务需要及发展趋势，逐步成为学校学员信息管理的主要平台和重要手段[1]。昆明消防指挥学校是消防部队干部成长的两所军校之一，是一所具有光荣传统的消防指挥学校，办学至今已为全国消防部队培养输送了一万多名优秀基层指挥员，为我国消防事业发展做出了重要贡献。随着学校办学规模的扩大，学员数量的增多，学员的信息管理工作难度加大。但是学校还依靠传统纸质档案的方式管理学员信息，该方式存在信息查询手续不便于操作、查询工作过程繁琐、信息不便于长期保存、信息统计不准确等问题，所以急需开发出代替统质档案的学员电子档案。
数据库系统是学员综合信息管理系统的根本所在，是实现学员信息管理最重要的技术环节。本文依托关系数据库理论，从应用需求抽象、数据库表设计、数据库表关系建立、数据库模式优化几个方面建立学员综合信息管理系统数据库模型，为下一步编写前后台代码，实现整个学员综合信息管理做好准备工作。
1 关系数据库简述
数据库技术发展至今已有40多年的历史，它作为数据管理的有效手段，大大促进了计算机应用技术的发展。从早期的文件系统到层次数据库和网状数据库，从关系数据库到面向对象数据库，以及面向不同应用的时态数据库、演绎数据库等等，均向人们展示了数据库技术的广阔应用前景[2]。
关系数据库(Relational Database)，顾名思义是建立在关系数据库模型基础上的数据库，借助于集合代数、离散数学等概念和方法来处理数据库中的数据。关系数据库是一个被组织成一组拥有正规描述的表格，该形式表格作用的实质是装载着数据项的特殊收集体。这些表格中的数据以许多不同的方式被存取或重新召集而不需要重新组织数据库表格[3]。除了相对容易创建和存取之外，关系数据库具有容易扩充的优势。在最初数据库创造之后，一个新的数据种类能被添加而不需要修改所有的现有应用软件。目前主流的关系数据库有Oracle、SQL、Aceess、DB2、My SQL、SQL Server、Sybase等等[4]。根据本校办学规模和处理信息量，采用ACEESS作为本系统数据库的管理工具。
2 数据库模型建立
2.1 应用需求抽象
根据学员信息管理的具体任务，按照管理功能进行业务划分和模块化设计。按照简单性、独立性及完整性原则，学员信息管理系统后台可以分为以下几个子系统:即学员档案管理子系统、课程管理子系统、成绩管理子系统、中队管理子系统、管理统计子系统、系统管理子系统、系统维护子系统。系统功能模型如图1所示。
(1)学员档案管理子系统
学员档案管理主要有学员管理、批量学员添加、按中队批量学员添加等功能。
(2)课程管理子系统
课程管理子系统主要有课程管理、批量课程添加、任课管理、任课添加等功能。
(3)成绩管理子系统
成绩管理子系统完成成绩管理、批量成绩添加、按中队成绩添加功能。
(4)中队管理子系统
中队管理子系统完成中队管理、中队批量添加两个子模块功能。
(5)管理统计子系统
管理统计子系统显示学校基本信息，包括年级数、中队数、学员数、教师数、课程数、用户浏览统计等相关信息，还可完成学员统计、排名统计功能。
(6)系统管理子系统
系统管理子系统包括修改管理员密码、帐号管理、干部管理、年级管理、学期管理功能。
(7)系统维护子系统
系统维护子系统主要完成系统的相关设置功能，包括站点名称，站点LOGO设置，网站主体表格属性设置，年级变迁(这里主要是对年级进行批量升级操作，也可以在中队管理下单个进行升级)。
2.2 数据库表设计
根据应用需求抽象可以对数据库表进行设计，下面对主要数据库表的结构进行介绍。
(1)存储学员的基本信息，学员基本信息是学员综合管理的基础。student(sid:自动编号:学员ID;suser:文本:学号、登陆账号，不可更改;password:文本:密码;sname:文本:姓名;sex:文本:性别:男，女，保密;cla_id数字:班级id;states:文本:状态:在读，离校，退学，毕业;scome:日期/时间:入学;sout:日期/时间:离校;scancel:日期/时间:退学;sadddtime:日期/时间:登记;slastdate:日期/时间:出生年月;political:文本:政治面貌;education:文本:文化程度;ruwu:日期/时间:入伍时间;yuanbubie:文本:原部别;address:文本:家庭住址;ligong:文本:立功受奖;interests:文本:兴趣爱好;province:数字:总队)。
(2)课程表，存储课程名称和编号。Subject(sid:自动编号:课程ID;sname:文本:课程名称)。
(3)学期表，存储学期信息。term(tid:自动编号:学期;tname:文本:学期名;tnow:数字:1当前学期;tstart:日期/时间:学期开始年月;tend:日期/时间:学期结束年月)。
(4)教师信息表，存储教师信息。teacher(tid:自动编号:教师;tuser:文本:帐号，不可更改;password:文本:密码;tname:文本:姓名;telephone:文本:电话;temail:文本:邮箱;sex:文本:性别:男，女，保密;statestime:日期/时间:现等(职)级时间;states:文本:现专业技术等级或职务post:文本:职称;tcome:日期/时间:入职时间;tgo:日期/时间:离职时间;education:文本:学历;university:文本:最高学历毕业院校;chushi:数字:所在处室ID;political:文本:政治面貌;birthday:日期/时间:出生年月;classID:数字:所在中队ID)。
(5)任课信息表，存储教室任课信息。tea_sub(tsid:自动编号:任课表;ts_tea_user:文本:教师ID;ts_sub_id:数字:课程;ts_ter_id:数字:学期;ts_cla_id:数字:中队)。
2.3 数据库表关系建立
关系数据库模式的建立，离不开数据表之间关系的建立，只有建立表之间的关系，整个数据库才能形成一个系统，提供强大的信息存储、查询、和处理功能[5]。对比应用需求说明和现实学校各部门的业务流程，设计数据库表之间的关系如图1所示。
(1)学员和评语之间存在一对多的对应关系，即一个学员可以有多条来自不同老师的评语;学员和家长存在一对多的对应关系，即一个学员可以对应一个家长，方便家长对学员相关信息进行查询。学员和平时成绩存在一对多的对应关系，即一个学员可以有多种平时成绩;同时，学员还和中队有多对一对应关系，即一个中队可以有多个学员。
(2)中队和成绩有一对多的对应关系，即一个中队可以有多条成绩;中队和年级有一对一的对应关系，即一个中队属于一个年级。中队和大队有一对一的对应关系，即一个中队属于一个大队，中队和任课信息有一对多的对应关系即一个中队有多条任课关系与之对应。大队和中队有一对多的对应关系，即一个大队对应多个中队。
(3)任课信息表中的教师ID和教师信息表中ID存在一一对应关系。教师表中ID和任课教师信息表中的ID存在一对多的关系。即一个教师可以有多个任课关系。任课教师表中的课程ID和课程表中的课程ID存在一一对应关系。任课信息表中的学期和学期ID存在一一对应关系。即一个任课信息对应一个学期。成绩表中的课程ID和课程信息表中的ID存在一一对应关系，成绩表中的学期ID和学期表中的学期ID存在一一对应关系。
2.4 数据库模式设计
2.4.1 关系数据库设计中存在问题
(1)数据冗余:在一个数据集合中重复的数据称为数据冗余。例如在设计时没有把教师信息表Teacher和任课信息表tea_sub分开，那么每存储一条任课信息tea_sub(tsid、ts_tea_user、ts_sub_id、ts_ter_id、ts_cla_id)教师表中的其他信息也要重复存储[4]。
(2)更新异常:更新异常分为插入异常和删除异常。
插入异常:比如学员信息表student，如果不知道学号，那么插入再多的其他信息都是没有意义的。例如一个刚入职的教师理所当然要在任课信息表中有其相关数据，但此时他还没有任课，即他对应的元组
删除异常:例如在没分解的教师信息表中的任课信息中，相应的任课关系解除。那么删除整条记录，该教师的其他信息也被删除，在查询的时候无法查阅该教师相关信息，这也与实际需求相悖，将这种现象称为删除异常。
数据库的性能优化包括硬件优化，查询优化和设计优化三个方面。本文着重介绍设计优化即模式优化，模式优化重点解决数据冗余和更新异常问题。
2.4.2 数据库模式的规范化
在对数据库进行模式设计时，对关系的分解并不是盲目的，分解的目的在于减少关系模式的规模，避免不必要的存储及操作的冗余和数据更新异常。为了清除异常，需要对关系模式进行合理地分解。为此，人们设计数据库设计的规范化理论，以便能够设计出异常尽可能少的数据库模式[4]。
据参考文献[4]所述，数据库模式分为6级，具体的定义见参考书目。分别是1NF:是关系数据库对模式的基本要求，即要求属性的值必须是原子属性不可再分。2NF:消除了数据库模式中非主属性对码的部分依赖。3NF:消除了数据库模式中非主属性对码的传递依赖。BCNF:消除了数据库模式中一切属性对码的传递依赖。4NF:消除了数据库模式中非平凡的和非码所隐患的多值依赖。5NF:消除了数据库模式中非平凡的和非码所隐患的连接依赖[4]。范式的级别由小到大分别是有1NF到5NF。范式的级别越低，冗余与更新异常就越容易产生[6]。
(1)满足1NF的学员信息表分解，在学员信息表中每一个属性都该是原子属性，故对部职别进行分解。由消防部队的编制特点，每个省、自治区、直辖市均有相应的消防总队;每个地级市、自治州、区都有相应的消防支队。学校学员来自五湖四海，故对学员信息表中的部职别属性进行分解。由于有的学员来自总队和支队机关，故把部职别分为总队和部职别两个属性，即
由图2可见模式分解后存储空间得到了大幅度优化，如果下一步根据应用需求再将原部别优化到支队一级，存储空间还将得到进一步优化，数据库性能将显著提升。
(2)满足BCNF的教师信息表分解，在2.4.1节数据库设计存在问题中提到数据冗余和删除异常，在没分解的教师信息表的任课信息中，相应的任课关系解除。那么删除整条记录，该教师的其他信息也被删除，在查询的时候无法查阅该教师相关信息，这也与实际需求相悖。要解决删除异常，即把教师信息表Teacher分解为教师基本信息表teacher和任课教师信息表tea_sub(tsid、ts_tea_user、ts_sub_id、ts_ter_id、ts_cla_id)。这样的分解既解决了数据冗余的问题，也解决了删除异常的问题。分解后Teacher和tea_sub关系模式都是1NF，且在其中不存在这样的属性A,A传递依赖与Teacher和tea_sub的码、由于关系模式Teacher={R1,R2…，Rn}和tea_sub={R1,R2…，Rn}中Ri(i=1,2，…，n)为BC范式，则关系模式Teacher和tea_sub也满足BCNF。
数据库的规范化设计还有很多，根据系统应用需求的变更和数据规模的递增，需要设计相应的数据模式来优化昆明消防指挥学校学员综合信息管理系统的数据库性能，使之满足应用需求，更好地为学校教师、学员和管理人员提供便捷的信息化服务。
3 结束语
本文介绍了昆明消防指挥学校学员综合信息管理系统的项目开发背景，以关系数据库为系统数据库设计的切入点，从应用模型抽象、数据库表设计、数据库表之间关系设计、以及数据模式设计几个方面详细分析和设计了军校学员综合信息管理系统的数据库。在应用过程中，系统响应迅速，数据存储、编辑、更新、查询正确，未发现明显的存储和更新异常。并对数据库设计模式进行了优化，进一步减少了数据冗余，使整个系统的性能得到进一步的提升。但是，数据库中还存在一定的数据冗余，数据库模式规范化还需进一步优化。在下一步的工作中还将继续对关系数据库理论进行深入研究，力争能使本系统的数据库模式性能明显提升，满足更高级别的范式规范，为全校师生、管理人员提供方便快捷的学员综合信息查询管理平台。
参考文献
[1]张辉.军校信息化教学管理探讨[J].中国管理信息化,2010,13(5):116-118.
[2]萨师煊,王珊.数据库系统概论[M].北京:高等教育出版社,2002.
[3]张华林.道路网络的关系数据库模型探讨[C].第六界中国智能交通年会暨第七界国际节能与新能源汽车创新发展论坛优秀论文集(智能交通),2008.
[4]刘惟一,田雯.数据模型[M].北京:科学出版社,2002.
[5]刘英,冯云.数据库系统性能调优的研究与实践[J].甘肃科技,2008,7(24):22-24.
关系型数据库管理系统 篇10
近年来, 学校的学员数量越来越多, 办学规模越来越大, 在很大程度上增加了学员信息管理的难度, 传统的学员信息管理方法有很多的缺陷, 已经不能适应时代的发展, 只有程序化的严谨的科学的管理信息系统才能满足时代的需要。所谓关系数据库, 就是以关系数据库模型为基础建立数据库, 通过离散数学和集合代数来处理数据库中的数据。如何优化学员信息管理系统的关系数据库模型一直是重点研究的课题。
2 基于学员信息管理系统的关系数据库模型的建立
2.1 运用需求抽象
结合学员信息的主要任务和管理功能进行设计, 主要包括模块化设计和业务划分, 按照完整性、独立性、简单性原则, 把学员信息系统划分成七个子系统, 分别是系统维护子系统、系统管理子系统、管理统计子系统、中队管理子系统、成绩管理子系统、课程管理子系统、学员档案管理子系统。图1为系统功能模型。系统维护子系统用于设置站点LOGO、站点名称以及网络主体表格属性, 并且能够对年级变迁进行升级操作。系统管理子系统主要用于账号管理、年级管理、干部管理、学期管理以及管理员密码的修改。管理统计子系统用于基本信息的显示, 包括中对数、课程数、教师数、年级数、学员数、用户浏览数, 而且还可以起到排名统计和学员统计的作用。中队管理子系统有两个子模块功能, 分别是中队批量添加和中队管理。成绩管理子系统主要用来添加批量成绩和管理成绩。课程管理子系统的功能是任课添加、任课管理、批量课程管理、课程管理。学员档案管理子系统的主要功能是批量添加学员、管理学员。
2.2 建立数据表关系
要想建立关系数据库模式, 首先要建立数据表之间的关系, 只有这样才能形成一个数据库系统, 起到信息查询、信息存储、信息处理的作用。
学员和评语之间属于一对多的关系, 也就是说一个学员可以有很多不同的评语。学员和成绩之间属于一对多的关系, 也就是说一个学员具有很多不同科目的成绩。学员和家长之间属于一对一的关系, 也就是说一个学员只能对应一个家长, 便于家长查询学员的信息。学员和中队之间属于多对一的关系, 也就是说一个学员只能参加一个中队, 但是一个中队能够拥有很多学员。
中队和成绩之间属于一对多的关系, 也就是说一个中队能够有很多不同的成绩。中队和大队之间属于一对一的关系, 也就是说一个中队只能属于一个大队。中队和年级之间属于一对一的关系, 也就是说一个中队只能属于一个年级。大队和中队属于一对多的关系, 也就是说一个中队只能属于一个大队, 但是一个大队能够拥有很多个中队。中队和任课信息属于一对一的关系, 也就是说一个中队能够拥有很多任课关系。
在任课信息表中, 教师表里面的教师的ID与任课教师表里面的ID属于一对多的关系, 也就是说一个教师能够有很多任课关系。任课信息表里的学期与学期ID之间属于一对一的关系, 也就是说一个学期对应一个任课信息。任课教师表中的课程的ID与课程表中的课程ID属于一对一的关系。学期表里的学期ID与成绩表中的学期ID属于一一对应的关系。课程信息表里的ID与成绩表中的课程ID属于一一对应的关系。
2.3 设计数据库模式
2.3.1 设计关系数据库出现的问题
设计关系数据库出现的问题主要有数据冗余和更新异常。数据冗余指的是集合数据中出现重复的数据, 这些重复的数据就是数据冗余。比如在做设计时没有与分开任课信息表和教师信息表, 结果导致输入一条任课信息, 这些信息就会重复存储到教师信息表中去。更新异常主要包括删除异常和插入异常。
没有分解的教师信息表中删除任课信息, 那么就解除了相应的任课关系, 在整条记录删除后, 也就删除了这个教师的所有信息, 导致查询不到这个教师的信息, 这种情况并不符合实际需求, 这种现象就是所谓的删除异常。
在学员信息表中, 假如不知道学生的学号, 就算输入再多的信息都是毫无意义的。假如一个教师刚刚入职, 那么任课信息表中就不会有任何相关数据, 而他又没有正式开始任课, 所以不能在数据库中添加他的相关信息, 不能够在任课信息表中注册教师的任课信息, 这种情况并不符合实际需求, 这是属于不合理的操作, 这种现象就是所谓的插入异常。删除异常和插入异常在很大程度上降低了数据库的性能。
2.3.2 规范化数据库模式
在设计数据库模式时, 不能盲目分解关系, 因为关系分解的目的是把关系模式的规模减少, 减少数据更新异常和数据冗余的可能性。因此, 为了更好的清除出现的异常, 一定要科学合理的分解关系模式。为了合理的分解关系模式。人们想出了规范化的理论, 通过这些理论设计出的数据库模式没有很大的异常情况。
相关资料显示, 数据库模式可以分成六级。1NF指的是关系数据库对于模式的具体要求, 也就是说属性的值一定是原子属性并且不可再分。2NF指的是把数据库中的非主属性对于码的依赖性消除了。BCNF指的是把数据库中全部属性对于码的传递依赖性消除了。4NF指的是把数据库中的非码和非平凡的多值依赖消除了。5NF指的是把数据库模式的非码和非平凡的连接依赖性消除了。范式的级别最大的是5NF, 范式的级别最小的是1NF, 而且范式的级别越高, 更新异常和数据冗余的情况就越少, 范式的级别越低, 更新异常和数据冗余的情况就越多。
在上文提到的删除异常, 也就是在没有分解的教师信息表中删除任课信息, 那么就解除了相应的任课关系, 在整条记录删除后, 也就删除了这个教师的所有信息, 导致查询不到这个教师的信息。删除异常的解决, 需要将教师信息表分解成为任课教师信息表和教师基本信息表。这种分解方式, 不仅把数据冗余的情况解决了, 而且还把删除异常的情况也解决了。分解之后的任课教师信息表和教师基本信息表的关系关系模式都是最低范式, 也就是1NF。
规范化的数据库设计还有很多种方法, 但是需要结合数据规模的递增和系统应用需求的更新来设计, 才能更好的优化数据库性能, 使学员信息管理系统能够符合需求, 更好的为学员、教师以及管理人员服务。
3 结束语
在设计关系数据库时出现的主要问题是数据冗余和更新异常, 数据冗余指的是集合数据中出现重复的数据, 这些重复的数据就是数据冗余。更新异常主要包括删除异常和插入异常。这些问题在一定程度上降低学员综合信息管理系统的性能。所以在设计数据库模式时, 不能盲目分解关系, 因为关系分解的目的是把关系模式的规模减少, 减少数据更新异常和数据冗余的可能性。因此, 为了更好的清除出现的异常, 一定要科学合理的分解关系模式。为了合理的分解关系模式。人们想出了规范化的理论, 通过这些理论设计出的数据库模式没有很大的异常情况。学员综合信息管理系统的优化并不是简单的事情, 需要相关工作人员的共同努力, 在不断的实践中总结经验, 积累经验, 在此基础上寻求创新, 进一步优化数据库模式, 更好的为学员、教师以及管理人员服务。
摘要：学校管理中最重要的内容是学员信息的管理, 作为学校的核心内容, 学员信息管理能够反应学校的教学水平和教学质量。学员信息管理系统能够将传统复杂的繁重的学员管理工作有效改善, 通过程序化的严谨的科学的制度来管理学员信息, 提高了学员信息管理的水平。如何完美设计学员信息管理系统的关系数据库模型一直是教育界重点关注的话题。本文简要分析了数据表关系的建立和数据库模式的设计, 旨在为学员信息管理系统的关系数据库模型的完善提供参考依据。
关键词：学员信息管理系统,关系数据库模型
参考文献
[1]李武, 刘清梅.基于B/S模式的大学生就业指导信息系统设计[J].科技信息 (科学教研) , 2013, 5 (04) :957-958
[2]薛振清, 陈守森.基于B/S构架的校园综合信息与内容管理系统[J].人力资源管理, 2012, 4 (04) :366-367.
关系型数据库管理系统 篇11
[关键词] 数据挖掘 客户關系管理 数据库
客户关系管理系统中的商业数据，不但来源于企业的内部，更多的来自于企业的外部。这些数据与企业的客户关系密切，可以帮助企业更加清晰地分辨潜在客户、进行更有效的交叉销售，更容易地扩展客户关系。但关于企业客户数据的质量，就象齿轮中的沙子，它不会完全阻挡前进的步伐，但会让企业越走越慢，不断消耗掉企业努力的成果。所以，企业的客户关系管理系统能否有效运行、实现预期目标，很大程度上取决于企业是否进行了有效的数据挖掘，从而获得了可靠、有意义的商业数据。
一、数据挖掘的内涵
数据挖掘（Data Mining），又称数据库中的知识发现（Knowledge Discovery in Database，KDD)，是指从大型数据库或数据仓库中提取隐含的、未知的、非平凡的及有潜在应用价值的信息或模式的过程。数据挖掘是数据库研究中的一个很有应用价值的新领域，融合了数据(仓)库、人工智能、机器学习、统计学等多个领域的理论和技术。
从客户关系管理（Customer Relationship Management,CRM)系统所搜集的数据，是最能帮助企业了解客户的。数据挖掘技术正是为完成这一使命而诞生的。它能够根据现有数据对将来的发展趋势和行为进行预测，从而很好地支持人们的决策。同时，数据挖掘工具还能够解决一些很消耗人工时间的传统问题，因为它们能够快速地浏览整个数据库，找出一些专家们不易察觉的极有用的信息。因此可以说，客户关系管理的成功主要在于它成功进行了数据挖掘、数据仓库等技术的有效运用。
二、数据挖掘在企业客户关系管理中的作用与功能
数据挖掘技术是客户关系管理深层次应用的核心技术，在客户关系管理中具有非常重要的商业价值。其作用与功能主要体现在:
1.数据挖掘有助于提高企业决策质量。对客户数据所做的挖掘与分析，其目的不单单是为了研究的需要，站在企业层面上，更是为获得并加工有利于商业运作、提高竞争力的信息，为商业决策提供真正有价值的参考和依据，进而获得利润的过程。
2.数据挖掘有助于企业对客户生命周期进行分阶段的管理。它能够帮助企业明确：处于不同生命周期阶段的客户需求和特点。使企业能够为客户提供更有针对性的服务，包括更好地服务新客户、让已有客户获取更多服务并创造更多利润、进一步保持和提升客户价值等。
3.数据挖掘有助于企业预测业务发展的趋势。数据挖掘是从大量数据中，抽取出潜在的、有价值知识、模型或规则的过程。对于企业而言，通过数据挖掘可以揭示已知事实与未知的结果间的关系，实现有效的预测，并帮助企业分析完成任务所需的关键因素，实现增加收入、降低成本、使企业处于更有利竞争地位的目的。
4.数据挖掘有助于企业对客户进行有效的市场细分。数据挖掘可以把大量的客户分成不同的类别，并确保在每个类别中的客户都拥有相似的属性,而不同类别中的客户属性不同,从而实现市场细分有效。企业进而可以为这几类不同的客户,提供不同的、特定的服务,以提高服务的针对性和客户的满意度。通过数据挖掘对客户进行细致而切实可行的分类,对企业的经营决策有大有益处。
三、在客户关系管理中应用数据挖掘技术的策略要求
1.需确立合理的数据挖掘目标。为保证数据挖掘能够正常、有效地开展和进行，其实施过程中必须有明确的远景规划和近期实现目标。管理者制定规划和目标时，既要考虑企业内部的现状和实际技术水平，同时也要看到外部市场对企业的要求与挑战。企业必须将已经形成并得到企业内部认同的、明确的数据挖掘项目远景规划和近期实现目标落实成文字，明确任务目标、进度和预期作用等内容。
2.需寻求高层管理者的理解与支持。高层管理者对客户关系管理中数据挖掘的支持、理解和承诺，是数据挖掘成功的关键因素之一。缺乏管理者支持与承诺，会对数据挖掘的实施带来很大的负面影响，甚至可以使项目在启动时就已经举步维艰。要得到管理者的支持与承诺，既可要求管理者对项目有相当的参与程度，进而能够对项目实施有一定理解；也可将实施过程中所影响到的部门的高层领导，设为数据挖掘项目的发起人或发起的主要参与者。
3.需全面掌握客户的数据。在接通客户关系管理系统并将原始数据导入新系统之前，数据挖掘人员要全面考察数据来源，获取数据的内容、质量和可靠性等情况信息。当采用适当的数据挖掘工具，执行这些枯燥而易出错的程序时，可使数据挖掘工作所花费的时间减少到相当于初次手工作业所需时间的10%左右，并可及早发现和纠正数据问题，大大降低成本和失败的风险。
4.要建立数据标准。进行数据挖掘和分析时，需将客户姓名、联系地址、识别方法和产品信息等客户数据标准化，以确保一致性并将记录与统计逻辑相匹配，从而减少查看客户全景视图的数据重复。同时，要建立保证数据质量的相关流程和程序，以确保数据的适用性和质量。
5.要明确相关的奖惩制度。数据挖掘实施过程中也会发生人员流动、工作人员的效率不高、情绪不积极等情况。针对上述情况，要求在建立实施小组和人员定位时，一定要在企业内部达成共识，防止在实施其间对人员的随意抽调。同时，还必须对实施小组成员的职责分工有明确定义，将每项任务落实到人，明确对个人的考核目标，对优秀人员予以奖励，不能完成任务的予以处罚。
参考文献:
[1]李琪:《客户关系管理》,重庆大学出版社,2004
[2]王广宇:《客户关系管理方法论》,清华大学出版社,2004
[3]MBA职业经理人论坛网
关系型数据库管理系统 篇12
传统主动数据库的主动性主要是通过规则机制实现的,常采用事件驱动的ECA规则模型,即事件一条件一动作(Event—Condition—Action)规则。事件驱动的“事件一条件一动作”的一般形式为:
WHEN<事件表达式>
IF<条件1>THEN
<动作1>
WHERE<约束1>
END IF
由上面的规则定义可知,传统的ECA模型往往只关注在数据库管理系统的本身,而不具有与系统进行交互的能力,因此,我们在设计与实现一个嵌入式关系数据库管理系统(EDBMS, Embedded Database Manage System)的基础上,对其中的主动模块进行了分析与实现。
1 嵌入式关系数据库管理系统与主动模块的体系结构
图1为自主设计的嵌入式关系数据库管理系统原型的体系结构图。
内核部分为整个嵌入式关系数据库管理系统的核心,它负责进行语法分析、查询执行、缓冲区管理、日志管理等等。从图1中可看出,系统的层次清晰,层与层之间的接口简单,这使系统各层次能相对独立的开发,增加了系统的可移植性、可伸缩性。API是系统提供给用户使用嵌入式数据库管理系统的一组接口函数。用户将通过这一组函数进行查询、更新与同步等操作,或者进行基于该DBMS的开发。配置管理模块负责对整个嵌入式关系数据库管理系统进行配置,同步模块则负责移动设备与其他移动设备或中心数据库的同步,包括建立连接、传送数据、接受广播数据等功能。
在传统的数据库管理系统体系结构不同,在本体系结构中,将主动模块放置于内核中实现。这是基于以下的考虑:(一)、相对于运行于pc机上的传统数据库,运行于移动设备上的嵌入式关系库管理系统对电力,内存,网络连接状况的变化更为敏感;(二)、 对于ECA规则的每个部分——事件、条件及动作,嵌入式关系数据库管理系统都需要进行扩充,以表达更为复杂的规则,适应移动设备的实际应用环境;(三)、由于移动设备的资源相对贫乏,因此执行的效率是一个关键的问题,将主动模块放置于内核中实现,能够尽量的提高系统的效率。(四)、能更好的提高主动模块与内核其他模块的藕合度,从而使得其他模块能更好更方便的增加主动功能。
2 嵌入式关系数据库管理系统中主动模块的描述与实现
由上面的讨论可知,嵌入式关系数据库管理系统中的主动模块,不仅要包括传统主动模块中的各种主动功能,还要定义系统环境发生变化时的各种事件,即ECA的每个部分都需要进行扩充。扩充后的ECA各个部分的BNF范式如下:
由上面对ECA规则的BNF描述可知,由于引入了
主动模块的运行过程如下:
(1)在数据库管理系统启动时,主动模块载入内核;
(2)主动模块进行监测,并建立与系统的通信管道;
(3)当有事件触发时,判断事件的种类;
(4)如果为,
(5)查找此事件相对应的判断条件
(6)如果相关上下文信息使得判断条件为假,则转(2);
(7)根据限制条件
(8)转(2)。
3 实验与分析
为了对实施了主动模块的嵌入式关系数据库管理系统的效率进行分析,我们进行了实验。实验环境采用ARM 9芯片的开发板,芯片频率为200 MHz,RAM为64 M,嵌入式数据库管理系统与其中的主动模块均采用C语言实现。
主动模块的执行需要占用一定的资源,为了验证主动模块执行的效率,实验一将没有实现主动模块的EDBMS,主动模块置于内核外的EDBMS及采用本文体系结构的EDBMS三种EDBMS的效率进行了比较,主动模块中定义了不同数目的主动规则(均为不涉及到系统的主动规则),对于每个EDBMS都递交相同数目的SQL查询,其执行时间如图2所示。由图2可以看出,由于需要解析并执行主动规则,因此实现了主动规则的EDBMS在执行时间需要较长,且随着主动规则数目的增加,执行时间也相应延长,但将主动模块置于内核部分的EDBMS执行时间要显著少于将主动模块置于内核外的EDBMS。
本文所提出的创新点不仅是在于将主动模块置于内核部分实现,以提高效率,而且也对ECA规则进行了扩充,使得数据库管理系统能更好的适应系统环境,从而提高整体的效率。实验二在EDBMS中定义了若干条根据系统状况来进行查询优化的主动规则,并递交不同数目的SQL查询,其执行结果图3所示。由图3可以看出,虽然主动规则的执行会占用一些资源,但由于能根据系统状况来动态配置查询优化的方式,因此实现了主动模块的EDBMS执行效率有时甚至优于没有实现主动模块的EDMS。
4 总 结
针对传统主动数据库在移动计算环境下应用受限的情况,本文提出了一种高效且易于实现的嵌入式数据库中主动模块的实现方案。理论分析和实验验证均表明,此实现方案不仅能够定义与处理复杂的主动规则,而且在效率上进行了一定优化。在下一步的工作中,还将对主动规则执行优化,主动规则的进一步扩充等问题进行研究。
参考文献
[1]Baralis E,Ceri S,et a1.Gompile-time and runtime analysis of active behaviors.IEEE Trans.Knowledge and Data Engineering,1998;10(3):353—370
[2]Comai S,Tanca L.Termination and confluence by rule prioritization.IEEE Trans Knowledge and Data Engineering,2003;15(2):257—270
[3]翟玉人,高朝瑞,高晶.数据库主动功能扩展技术研究与实现.计算机工程与应用,2006;42(11):179—182
【关系型数据库管理系统】推荐阅读：
关系数据05-25
关系数据库模式05-09
关系数据库中的规范化08-07
基于关系数据库的地籍空间数据存储结构07-18
大数据时代的国际关系研究论文08-12
关系管理05-16
系统学科关系07-16
宾客关系管理07-11
人才关系管理07-30
品牌关系管理论文05-13