银行数据库设计ppt课件.ppt

上传人(卖家):三亚风情 文档编号:2219316 上传时间:2022-03-22 格式:PPT 页数:54 大小:2.16MB
下载 相关 举报
银行数据库设计ppt课件.ppt_第1页
第1页 / 共54页
银行数据库设计ppt课件.ppt_第2页
第2页 / 共54页
银行数据库设计ppt课件.ppt_第3页
第3页 / 共54页
银行数据库设计ppt课件.ppt_第4页
第4页 / 共54页
银行数据库设计ppt课件.ppt_第5页
第5页 / 共54页
点击查看更多>>
资源描述

1、7.1-53n初始的用户需求规格说明可以基于数据库用户的交流以及设计者自己对银行业务的分析。这个设计阶段中的需求描述是制定数据库的概念结构的基础。以下是银行企业的主要特征:l1.银行有多个支行。每个支行位于某个城市,由唯一的名字标识。银行监控每个支行的资产l2.银行客户通过其customer_id值标识,银行存储了每位客户的姓名及其居住的城市和街道。客户可以有账户,并且可以贷款。一个客户可能和某个银行员工发生联系,该员工作为此客户的贷款负责人或私人助理l3.银行员工功过其employee_id值来标识。银行的管理机构存储每个员工的姓名、电话号码、亲属姓名及其经理的employee_id号码。银

2、行还需要知道员工开始工作的日期,由此日期可以推知员工的雇佣期l4.银行提供两类账户支票账户和储蓄存款账户。账户可以由两个或两个以上客户共有,一个客户也可以有两个或两个以上的账户。每个账户被赋予唯一的账户号。银行记录每个账户的余额以及每个账户拥有者访问该账户的最近日期。另外,每个储蓄存款账户有其利率,而每个支票账户有其透支额l5.每笔贷款由某个支行发放,能被一个或多个客户所共有。一笔贷款用一个唯一的贷款号标识。银行需要知道每笔贷款所贷金额以及逐次还款情况。虽然贷款的还款号并不能唯一地标识银行所有贷款中的某个特定的还款,但可以唯一地标识对某贷款的所还款项。对每次的还款需要记载其日期和金额n真实的银

3、行中,还应像记载对贷款的所还款项那样来记载每个储蓄存款账户或支票账户中取出或存入的金额。由于这些记载的建模过程类似,并且为了保持示例的简洁性,在我们的模型中不考虑对存款和取款的记录。7.2-53n数据库建模如下:l一组实体的集合l一组实体集间联系的集合n实体:是现实世界中可区别于其他对象的“事物”或“对象”。l例如:企业中的每个人都是一个实体,一个人的person_id性质可以唯一地标识这个人;贷款也可以被看作实体,通过贷款号唯一地标识某个贷款实体。n每个实体有一组性质(或属性)l例如:people have names and addressesn实体集:是相同类型即具有相同性质(或属性)的

4、实体集合。l例如:某个银行的所有客户的集合可被定义为实体集customer。类似地,实体集loan表示某个银行所发放的所有贷款的集合。l实体集不必互不相交。例如,可以定义银行所有员工的实体集employee和所有客户的实体集customer。而一个person实体可以是employee实体,可以是customer实体,可以既是employee实体又是customer实体,也可以都不是。7.3-53customer_id customer_ customer_ customer_ loan_ amount name street city number7.4-53n联系:是指多个实体间的相互关联

5、。例如:可以定义客户Hayes和贷款号L-15相关联的联系HayesloanL-15customer entityrelationship setloan entityn联系集联系集是n (n 2) 个实体集上的数学关系,其元素如下:(e1, e2, en) | e1 E1, e2 E2, , en En这里 (e1, e2, , en) 是一个联系。l例如: (Hayes, L-15) borrower7.5-537.6-53n一个联系集也可以具有描述性属性。n实体集customer和account之间的联系集depositor。我们可以将属性access_date与该联系关联起来,以表示客

6、户访问一个账户的最近日期。7.7-53n一个实体集可能有多个属性,每个实体可以用一组(属性,数据值)对来表示。n域域 每个属性都有一个可取值的集合 n属性类型:l简单 属性和复合属性l单值 属性和多值 属性4例如:多值属性: phone_numbersl派生 属性4可以从别的相关属性或实体派生出来4例如: age, 派生于 date_of_birth例如: customer = (customer_id, customer_name, customer_street, customer_city )loan = (loan_number, amount )7.8-537.9-53n指明一个实体

7、通过一个联系集能同时与多少个实体相关联。n映射基数在描述二元联系集时非常有用。n对于实体集A和B之间的二元联系集R来说,映射的基数必然是以下情况之一:lOne to onelOne to manylMany to onelMany to many 7.10-53One to oneOne to many注:A和B中的某些实体可能没有与另一个实体集中的任何实体相 关联。7.11-53Many to oneMany to many注:某个联系集的映射基数是依赖于该联系集所建模的对象在现 实世界中的实际情况。7.12-53n超码超码:是一个或多个属性的集合,这些属性的组合可以使我们在一个实体集中唯一

8、地标识一个实体。n我们通常只对这样的一些超码感兴趣,它们的任意子集都不能成为超码,这样的最小子集称为候选码。lCustomer_id is candidate key of customerlaccount_number is candidate key of accountn尽管可能存在多个候选码,只选择其中之一作为主码。n码(主码、候选码或超码)是实体集的性质,而不是单个实体的性质。实体集中的任意两个实体都不允许同时在码属性上具有相同的值。码的制定代表了被建模的现实企业中的约束。n主码的选择应该是那些从不或极少变化的属性。l例如:一个人的地址不应作为主码的一部分;(美)社会保障号可以作为主

9、码。7.13-53n所有参与的实体集的主码的组合构成一个联系集的超码。l(customer_id, account_number) is the super key of depositorl注:给定的联系集中的一个联系实例必须是由其参与实体能唯一标识的,而不必使用描述属性。 4假设我们要记录一个客户访问一个账户的所有日期。单值的属性access_date只能保存一个访问日期。我们不能通过同一用户和帐号之间联系的多个实例来表示多个访问日期,因为这些联系实例无法仅使用参与的实体来唯一的标识。正确的处理方法是创建一个多值的属性access_date,它可以保存所有的访问日期。n联系集的主码结构依赖

10、于联系集的映射基数。l例如,实体集customer和account,以及具有属性access_date的联系集depositor。4如果联系集是多对多的,那么depositor的主码由customer和account的主码共同组成。4如果一个客户只能有一个帐号,即depositor联系是从customer到account多对一的,则depositor的主码就是customer的主码。4如果联系是从account到customer多对一的,则每个帐号最多只能属于一个客户,所以depositor的主码就是account的主码。4一对一的联系中,可以使用两个主码中的任意一个来作为联系的主码。7.14

11、-53n矩形表示实体集;双矩形表示弱实体集n菱形表示联系集n线段将属性连接到实体集或将实体集连接到联系集n椭圆表示属性l双椭圆表示多值属性l虚椭圆表示派生属性n双线表示一个实体集全部参与到联系集中n下划线表示主码属性7.15-537.16-537.17-53n参与一个联系集的实体集可以相同n标签 “manager” 和 “worker” 称为角色; 表示实体在联系中的作用n角色在E-R图中用连接菱形和矩形的线段上的标签指明n角色标签是可选的,用于解释联系的语义7.18-53nOne-to-many 联系borrower : a loan is associated with at most o

12、ne customer via borrower, a customer is associated with several (including 0) loans via borrower7.19-53nMany-to-one 联系borrower :a loan is associated with several (including 0) customers via borrower, a customer is associated with at most one loan via borrower7.20-53nA customer is associated with sev

13、eral (possibly 0) loans via borrowernA loan is associated with several (possibly 0) customers via borrower7.21-53n全部参与 (双线): every entity in the entity set participates in at least one relationship in the relationship setl例如: participation of loan in borrower is total4 every loan must have a custome

14、r associated to it via borrowern部分参与: some entities may not participate in any relationship in the relationship setl例如: participation of customer in borrower is partial7.22-537.23-53实体集和联系集的概念并不精确,而且定义一组实体及它们的实体集和联系集的概念并不精确,而且定义一组实体及它们的相互联系可能有多种不同的方式。相互联系可能有多种不同的方式。n用实体集还是用属性用实体集还是用属性n用实体集还是用联系集用实体集

15、还是用联系集n用二元联系集与用二元联系集与n元联系集元联系集n联系属性的布局联系属性的布局7.24-53n具有属性employee_id、employee_name和telephone_number的实体集employee。l如果电话可以作为一个单独的实体,它具有属性telephone_number和location4实体集employee,具有属性employee_id和employee_name。4实体集telephone,具有属性telephone_number和location。4联系集emp_telephone,表示员工及电话间的联系。l两种定义主要差别4将电话处理成为一个telep

16、hone_number属性暗示对每个员工,正好有一个电话号码与之相联系;而将电话看成一个telephone实体,就允许每个员工可以有多个电话号码与之相联系。也就是说,将电话作为一个实体来建模可以保存关于电话的额外信息,如它的位置,或类型(移动的,视频的或普通的旧电话),或哪些人共用。因此把电话视为一个实体比把它视为一个属性的方式更具有通用性;而且当这种通用性很重要的时候,这种定义方式就更为适合。7.25-53n什么作为属性?什么作为实体集?l区分它们主要依赖于被建模的实际企业的结构,以及被讨论的属性的相关语义。l常见错误4用一个实体集的主码作为另一个实体集属性,而不是使用联系。 例如,即使每笔

17、贷款只有一个客户,将cumstomer_id作为loan的属性也是不正确的。用borrower联系代表贷款和客户之间的关联才是正确的方法,这样可以明确地表示出两者之间的关系,而不是将这种关系隐含在属性中。4将相关实体集的主码属性作为联系集的属性。 例如,loan_number和customer_id不应该在borrower联系中作为属性出现。这样做是不对的,因为在联系集的表示中已经隐含了这些主码属性。7.26-53n银行贷款的建模l一种方法假设银行贷款通过一个实体来建模。l另一种方法,不将贷款做为一个实体,而将其作为客户和银行支行之间的一个联系,这一联系具有描述属性loan_number和am

18、ount。每笔贷款都是用客户和银行支行间的一个联系来表示。4如果每笔贷款正好为一个客户所有,并且正好同一个支行相联系,那么我们可以发现用联系来表示贷款是能满足设计要求的。4但是,采用这样的设计,不能很方便地表示几个客户共有一笔贷款的情况。为此,必须为共有贷款的每个持有人分别定义一个联系,并不得不在每个这样的联系中复制描述性属性loan_number和amount的值。当然,每个这样的联系必须有相同的loan_number和amount值。 数据复制的问题n在确定用实体集还是联系集时可采用的一个原则是,当描述发生在实体间的行为时采用联系集。7.27-53n数据库中的联系通常都是用二元的。一些看来

19、非二元的联系实际上可以用多个二元关系更好地表示。l例如,我们可以创建一个三元联系parent,将一个孩子与其父母相关联。这一联系也可以用两个二元联系分别来表示,即mother和father,分别与他们的孩子相关联。使用mother和father两个联系使我们可以记录孩子的母亲,即使我们不知道父亲的身份;而对于这种情况三元联系parent中必须有一个Null值。所以在这个例子中用二元联系更好。n上面的方法并不总是令人满意的。l考虑联系集works_on,它与employee、branch和job有关。4不能直接将works_on分离为employee和branch之间的联系与employee和j

20、ob之间的联系这两个二元联系。4否则,我们可以记录Jones既是经理又是审计员,且Jones既在Perryridge又在Downtown工作;然而我们无法记录Jones是在Perryridge工作的经理和在Downtown工作的审计员,而不是在Perryridge工作的审计员或在Downtown工作的经理。7.28-53n一个联系的映射基数比率会影响联系属性的布局。l一对一或一对多联系集的属性可以放到一个参与该联系的实体集中,而不是放到联系集中。4例如,指定depositor是一个一对多的联系集,也就是一个客户可以有多个账户,但每个账户只能属于一个客户。在这种情况下,指明客户最后一次访问账户的

21、日期的属性access_date可以放在account实体集中。既然每个account实体最多和一个customer实例参与到联系中,因而将属性access_date放在account实体集中和将属性access_date放在depositor联系集中具有相同的含义。l一对多联系集的属性仅仅可以重放置到参与联系的“多”的那一边的实体集中。l一对一的联系集,联系的属性可以放到任一参与联系的实体中。7.29-53n设计时将描述属性作为联系集的属性还是实体集的属性这一决定应该反映出被建模企业的本来特点。l设计者可以选择保留access_date作为depositor的属性,以显式地表明访问发生在实体

22、集customer和实体集account的交互点上。l属性位置的选择在多对多联系集中体现得更清楚。4假设depositor为一个多对多的联系集,表明一个客户可有一个或多个账户,而一个帐户可以为一个或多个客户所拥有。 要表达某个客户最近一次访问某个账户的日期,access_date则必须作为联系集depositor的属性,而不是任何一个参与此联系集的实体集的属性。如果将access_date作为account的属性,对一个共有的账户,就不能确定是哪个客户进行了最近一次访问。l当一个属性是由参与的实体集联合确定而不是由单独的某个实体集确定时,该属性就必须放到多对多联系集中。7.30-53n一个实体

23、集可能没有足够的属性以形成主码,这样的实体集就称作弱实体集。与此相对,有主码的实体集称作强实体集。l实体集payment:该实体集具有属性payment_number、payment_date和payment_amount。还款号通常是从1开始的连续数字,分别针对每一笔贷款生成。虽然各个payment实体互不相同,但不同贷款的还款却可能具有相同的还款号。因此,实体集payment没有主码,是一个弱实体集。n弱实体集必须与另一个称为标识实体集或属主实体集的实体集关联才有意义。l每个弱实体集必须和一个标识实体关联,也就是说,弱实体集就称为存在依赖于标识实体集。我们称标识实体集拥有它所标识的弱实体集

24、。l将弱实体集与其标识实体集相关联的联系称为标识性联系。标识性联系是从弱实体集到标识实体集的多对一联系。lpayment的标识实体集是loan,将payment实体和它们对应的loan实体关联在一起的loan_payment是标识性联系。n虽然弱实体集没有主码,仍需要某种方法来区分那些依赖于某个强实体集的弱实体集中的实体。弱实体集的分辨符是使得我们能进行这种区分的属性集合。l弱实体集payment的分辨符是属性payment_number,因为对每笔贷款来说,还款号唯一标识了偿还该贷款的一笔款项。弱实体集的主码由标识实体集的主码和弱实体集的分辨符共同组成。例如弱实体集payment的主码是lo

25、an_number, payment_number,其中loan_number是标识实体集loan的主码,而payment_number区分同一个贷款的不同payment实体。7.31-537.32-53n特殊化从单一的实体集出发,通过创建不同的低层实体集来强调同一实体集中不同实体间的差异。l低层实体集可以有特殊的属性或参与到特殊的联系中,这些属性或联系并非适用于高层实体集中的所有实体。l设计者采用特殊化的原因正是为了表达这样的与众不同的特征。l如果customer和employee既没有特有的属性(即与person实体所拥有的那些属性不同的属性),又没有参与特殊的联系(即person实体没有

26、参与的联系),就没有必要对person实体集进行特殊化。n一般化的进行基于这样的认识:一些实体集具有共同的特征(即可以用相同的属性对它们进行描述,且它们都参与到相同的联系集中)。一般化是在这些实体集的共同性的基础上将它们综合成了一个高层实体集。l一般化用于强调低层实体集间的相似性并隐藏它们的差异;同时由于去除了共同属性的重复出现,可以达到简洁的表示效果。.7.33-537.34-53n 考虑employee、branch和job之间的三元联系works_on。n 假设想记录一位员工在某一部门作为经理的工作情况。n 存在的问题:冗余信息。n联系集works_on和manages可以合并到一个联系

27、集中。然而,我们不应该将它们合并到一起,因为一些employee、branch、job组合可能没有经理7.35-53n 聚集是一种抽象,通过这种抽象,联系被当作高层实体来看待。n将联系集works_on看成一个称作works_on的高层实体集,并且可以像对待别的实体集那样对待这样的实体集,从而可以在works_on和manager之间创建一个二元联系manages来表示谁管理什么任务。7.36-53n初始的用户需求规格说明可以基于数据库用户的交流以及设计者自己对银行业务的分析。这个设计阶段中的需求描述是制定数据库的概念结构的基础。以下是银行企业的主要特征:l1.银行有多个支行。每个支行位于某个

28、城市,由唯一的名字标识。银行监控每个支行的资产l2.银行客户通过其customer_id值标识,银行存储了每位客户的姓名及其居住的城市和街道。客户可以有账户,并且可以贷款。一个客户可能和某个银行员工发生联系,该员工作为此客户的贷款负责人或私人助理l3.银行员工功过其employee_id值来标识。银行的管理机构存储每个员工的姓名、电话号码、亲属姓名及其经理的employee_id号码。银行还需要知道员工开始工作的日期,由此日期可以推知员工的雇佣期l4.银行提供两类账户支票账户和储蓄存款账户。账户可以由两个或两个以上客户共有,一个客户也可以有两个或两个以上的账户。每个账户被赋予唯一的账户号。银行

29、记录每个账户的余额以及每个账户拥有者访问该账户的最近日期。另外,每个储蓄存款账户有其利率,而每个支票账户有其透支额l5.每笔贷款由某个支行发放,能被一个或多个客户所共有。一笔贷款用一个唯一的贷款号标识。银行需要知道每笔贷款所贷金额以及逐次还款情况。虽然贷款的还款号并不能唯一地标识银行所有贷款中的某个特定的还款,但可以唯一地标识对某贷款的所还款项。对每次的还款需要记载其日期和金额n真实的银行中,还应像记载对贷款的所还款项那样来记载每个储蓄存款账户或支票账户中取出或存入的金额。由于这些记载的建模过程类似,并且为了保持示例的简洁性,在我们的模型中不考虑对存款和取款的记录。7.37-53n实体集bra

30、nch,具有属性branch_name、branch_city和assets;n实体集customer,具有属性customer_id、customer_name、customer_street和customer_city;此外还可以考虑加上属性banker_name;n实体集employee,具有属性employee_id、employee_name、telephone_number、salary和manager;此外还包括多值属性dependent_name,属性start_date及其派生属性employment_length;n两个账户实体集savings_account和checki

31、ng_account,它们共同的属性是account_number和balance;此外,savings_account还具有属性interest_rate,checking_account还具有属性overdraft_amount;n实体集loan,具有属性loan_number、amount和originating_branch;n弱实体集loan_payment,具有属性payment_number、payment_date和payment_amount。7.38-53n定义如下联系集,在此过程中要对前面关于实体集属性的决策进一步精化lborrower,是customer和loan间的一

32、个多对多联系集;lloan_branch,指明产生贷款的银行支行的多对一联系集。注意这个联系代替了loan实体集的originating_branch属性;lloan_payment,从loan到payment的一对多联系集,表明一笔款项是为某笔贷款而付的;ldepositor,具有联系属性access_date,是customer和account间的多对多联系集,表明某个客户拥有某个账户;lcust_banker,具有联系属性type的一个多对一联系集,表明一个客户可以从一个银行员工处获得建议,而一个银行员工可以为一个或多个客户提供建议。注意这个联系集代替了customer实体集的banke

33、r_name属性;lworks_for,具有manager角色和具有worker角色的employee实体之间的联系集;其映射基数表明了一个员工仅为一个经理工作,而一个经理监督一个或多个员工。注意我们用这一联系集代替了employee实体集的manager属性。7.39-537.40-53n符合E-R数据库模式的数据库可以表示为一些关系模式的集合。数据库的每个实体集和联系集都有唯一的关系模式与之对应,关系模式名即为相应的实体集或联系集的名称。nE-R模型和关系数据库模型都是现实世界抽象的逻辑表示。由于两种模型都采用类似的设计原则,我们可以将E-R设计转换为关系设计。7.41-53n强实体集:l

34、模式具有与该强实体集相同的属性。n弱实体集:l模式具有的属性为:标识实体集的主码+该弱实体集属性4payment = (loan_number,4 payment_number, payment_date, payment_amount)7.42-53n对于多对多的二元联系,主码应该是参与实体集的主码属性的并集。n对于一对一的二元联系集,任何一个参与实体集的主码都可以作为联系的主码。可以任意选择一个与该联系集相关联的实体集,将它的主码属性作为联系的主码。n对于多对一的二元联系集,主码应该是联系集中“多”那一边的实体集的主码。n对于n元联系集,如果连接到它的边中没有箭头,则主码是所有参与实体集的

35、主码属性的并集。n对于n元联系集,如果连接到它的一条边中有一个箭头,则除去“箭头”那一边的实体集的主码属性,其他参与实体集的主码属性的并集为联系的主码。n注:还要在该模式R上建立外码约束。7.43-53n对于多对一或一对多的联系集,如果多的一方是全部参与的,则可以通过在多的一方添加额外的属性(一的一方的主码)来表示。n例如:不需要为account和branch创建联系集account-branch,而可以通过在account中添加branch_name来表示二者联系。7.44-53n一对一的联系集,任意一方都可作为多的一方处理。l即,额外的属性可以添加到任何一个实体n如果多的一方部分参与联系,

36、可能导致空值。laccount = (account_number, balance, branch_name)lbranch = (branch_name, branch_city, assets)n弱实体集与其标识实体集的联系集转换的模式是冗余的。l例如:payment和loan的联系集loan_payment7.45-53n通过为每个子属性创建一个单独的属性来处理复合属性,并不是为复合属性自身创建单独的一个属性。l例如:address是实体集customer的一个复合属性,并且address由street和city组成。从customer产生的模式将包括属性address_street和

37、address_city,而不是为address建立单独的属性或模式。n多值属性较为复杂,必须为其创建新的关系模式。l对一个多值属性M,为其创建关系模式R,该模式具有对应M的属性A,以及对应属性M所在的实体集或联系集的主码的那些属性。4例如实体集employee,该实体集具有一个多值属性dependent_name。employee的主码是employee_id。我们为该属性创建一个关系模式: dependent_name(employee_id, d_name)4一个雇员的每个亲属都可以表示为该模式上的关系中的唯一一个元组。这样,假设有一个employee_id为12-234的雇员,他的亲属

38、有John何Mary,就对应着关系dependent_name中的两个元组: (123-45-6789 , Jack) and (123-45-6789 , Jane)l这种关系模式的主码由模式中的所有属性构成;另外,需要在该关系模式上建立外码约束7.46-53n方法 1: l为高层实体集创建模式 l为每个低层实体集创建模式,属性包括高层属性的主码和其局部属性集 schema attributes person name, street, city customer name, credit_rating employee name, salaryl缺陷:获取雇员信息需要访问两个关系(连接)7

39、.47-53n方法2: l为每个实体集创建模式,包括其局部属性和继承属性schema attributespersonname, street, citycustomername, street, city, credit_ratingemployee name, street, city, salaryl如果是全部特殊化,person模式不再需要存储信息l缺陷:如果一个人既是客户又是雇员,street和city的数据产生冗余7.48-53n创建如下模式:l被聚集联系的主码l被聚集实体集的主码l描述性属性7.49-53n例如:为联系集works_on和实体集manager的聚集创建如下模式 m

40、anages (employee_id, branch_name, title, manager_name)n模式 works_on 是冗余的,如果允许manages中属性manager_name为空值的话7.50-53nbranch = (branch_name, branch_city, assets)ncustomer = (customer_id, customer_name, customer_street, customer_city)nloan = (loan_number, amount)naccount = (account_number, balance)nemployee

41、 = (employee_id. employee_name, telephone_number, start_date)ndependent_name = (employee_id, dname)naccount_branch = (account_number, branch_name)nloan_branch = (loan_number, branch_name)nborrower = (customer_id, loan_number)ndepositor = (customer_id, account_number)ncust_banker = (customer_id, empl

42、oyee_id, type)nworks_for = (worker_employee_id, manager_employee_id)npayment = (loan_number, payment_number, payment_date, payment_amount)nsavings_account = (account_number, interest_rate)nchecking_account = (account_number, overdraft_amount)7.51-53n一个模式总可以分解为满足3NF的一组子模式,它们满足:l该分解是无损的l该分解保持依赖n一个模式总可以分解为满足BCNF的一组子模式,它们满足:l该分解是无损的l该分解可能不保持依赖.精品课件精品课件!精品课件精品课件!7.54-53n关系数据库的设计目标:lBCNF.l无损联接.l保持依赖.n如果无法达到上述目标,可采用下面某个目标:l可能不保持依赖BCNF l可能存在冗余3NF

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 办公、行业 > 各类PPT课件(模板)
版权提示 | 免责声明

1,本文(银行数据库设计ppt课件.ppt)为本站会员(三亚风情)主动上传,163文库仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。
2,用户下载本文档,所消耗的文币(积分)将全额增加到上传者的账号。
3, 若此文所含内容侵犯了您的版权或隐私,请立即通知163文库(发送邮件至3464097650@qq.com或直接QQ联系客服),我们立即给予删除!


侵权处理QQ:3464097650--上传资料QQ:3464097650

【声明】本站为“文档C2C交易模式”,即用户上传的文档直接卖给(下载)用户,本站只是网络空间服务平台,本站所有原创文档下载所得归上传人所有,如您发现上传作品侵犯了您的版权,请立刻联系我们并提供证据,我们将在3个工作日内予以改正。


163文库-Www.163Wenku.Com |网站地图|