《数据库课程设计手机话费管理系统报告.docx》由会员分享，可在线阅读，更多相关《数据库课程设计手机话费管理系统报告.docx（36页珍藏版）》请在三一办公上搜索。
1、摘要随着移动通信行业在中国的崛起，手机正像当年街上来来往往的自行车一样，飞到寻常百姓家，装进每个人的口袋。这种可随身携带的通讯工具，以其便捷的通讯方式，丰富的通讯功能，相对低廉的价格，正在向传统的通讯工具发出挑战。然而，也正是由于移动通讯工具的诸多优点，使得手机的持有数量极具增长，这就给传统的人工办理缴费和查询带来了巨大的压力。基于此，我们开发设计了此话费管理系统，利用数据库强大的功能，实施网上缴费和查询，来解决这个问题。在计算机高度普及的今天，人们的日常琐事也越来越依赖于网络。这也为我们这个数据库设计提供了一个契机。用数据库来储存繁琐的话费信息，这样既方便工作人员管理，又便于用户操作。既节省
2、了存储空间，又节省了操作时间。数据库为话费管理提供了一个平台，它将话费的相关信息存储起来，并提供查询、修改等操作功能，使话费管理变得简单易行。同时，数据库还可以用其他语言工具设计可视的操作界面，提高对话费信息的操作效率。本系统主要完成缴费操作，余额查询，消费记录，用户管理等功能。操作简单易行，能基本满足话费管理的相关功能。本设计主要介绍了手机话费管理系统，它包括需求分析、概念结构设计和逻辑结构设计三个主要部分，主要实现对手机话费信息的规范化、系统化的管理。在需求分析中，主要内容为数据项、数据结构、数据流、数据存储及数据流图；在概念结构设计中，构造出E-R图、总体概念模型和CDM图；在逻辑结构设
3、计中主要工作就是将E-R图转换成关系模式，并构造具体的PDM图。关键字 数据库，数据库设计，话费管理- 34 -目录摘要I1系统总体介绍及组内分工11.1系统功能分析11.2 系统功能模块设计11.3 组内分工12 数据库设计22.1需求分析32.1.1需求分析设计思想32.1.2数据字典32.1.3数据流图92.2概念结构设计112.1.1概念结构设计思想112.1.2概念结构设计方法112.1.3 CDM模型的生成过程142.3逻辑结构设计202.3.1逻辑结构设计的思想202.3.2 E-R图向关系模型的转换202.3.3 PDM模型的生成过程222.3.4 SQL脚本23结论31致谢3
4、2参考文献331系统总体介绍及组内分工1.1系统功能分析现代社会, 随着科技的迅猛发展和人们生活水平的日益提高, 手机已成为一个大众化, 且普及率相当高的通讯工具. 正是由于手机的大量普及, 手机网络的服务已成为客户看重的一点.。对于目前大多数手机用户来说，手机话费充值的方法都过于单调。除了移动公司所发行的动感地带系列手机卡可以通过直接缴费的方式进行充值外，其他方式的手机卡均只能通过手机充值卡进行充值。本系统可以使手机缴费更加方便快捷，用户可以使用银行卡进行缴费，从而实现对用户的手机话费管理。1.2 系统功能模块设计手机话费管理系统主要完成的功能有：话费信息的管理负责话费充值更新和余额信息存储
5、；用户信息的管理负责用户的个人信息存储；手机业务信息的管理负责手机所办理的业务的信息存储；手机账目信息的管理负责手机消费账目的存储。手机话费管理系统主要功能模块图如图1.1系统功能模块图。 图1.1 系统功能模块图1.3 组内分工组内分工如下表1.1 组内分工所示。表1.1 组内分工姓名主要分工成绩组长概念结构设计，局部及全局E-R图的设计、绘制CDM图并由此生成PDM图以及生成SQL脚本、相关截图、报告的排版以及致谢的撰写。组员系统总体功能模块、需求分析的撰写，设计数据字典和数据流图、结论和摘要的撰写。逻辑结构设计，E-R图向关系模型的转换，查找资料和打印报告。2 数据库设计2.1需求分析2
6、.1.1需求分析设计思想在手机话费管理系统中，主要有手机用户和工作人员两个操作实体，对于普通的手机用户来说，该系统仅允许他们作一个操作：即可以使用该系统通过手机号与密码发出查询请求, 查询该手机所剩余的话费。工作人员必须通过账号与相对应的密码登陆系统才能有权限完成以下的各种功能。工作人员的登陆可以统计并查看所有的手机用户信息。手机话费管理系统中实体的联系如下：一个用户可以注册多个手机号码，一个手机号码只能被一个用户注册。用户和号码之间是一对多的联系。一个用户可以拥有多张银行卡，一张银行卡只能属于一个用户，用户和银行卡之间是一对多的联系。一张银行卡可以为多个号码缴费，一个号码可以由多张银行卡缴费
7、，银行卡和号码之间是多对多联系。一个号码可以办理多个业务，一个业务可以被多个号码办理，号码和业务之间是多对多的联系。一个帐目包含多种业务，一种业务只能产生一种业务，帐目和业务之间是一对多的联系。2.1.2数据字典数据项用户信息数据项名：身份证号码含义说明：用户的唯一标识别名：ID_no类型：字符型长度：18数据项名：用户姓名含义说明：手机用户的姓名别名：user_name类型：字符型长度：8数据项名：用户密码含义说明：用户查询信息时的密码别名：user_password类型：字符型长度：10数据项名：用户性别含义说明：手机用户的性别别名：user_sex类型：字符型长度：2取值范围：男女数据项
8、名：用户地址含义说明：用户的家庭住址别名：user_addr类型：字符型长度：20数据项名：用户状态含义说明：手机号码的开/停状态别名：user_state类型：字符型长度：2取值范围：开/停工作人员信息数据项名名：工作人员编号含义说明：工作人员唯一标识别名：staff_id类型：字符型长度：10数据项名：工作人员姓名含义说明：工作人员的姓名别名：staff_name类型：字符型长度：10数据项名：工作人员口令含义说明：操作记录工作人员的登录密码别名：staff_password类型：字符型长度：10数据项名：工作人员性别含义说明：工作人员的性别别名：staff_sex类型：字符型长度：2取值
9、范围：男女银行卡信息数据项名：银行卡号含义说明：银行卡的唯一标识别名：bank_card类型：字符型长度：18数据项名：余额含义说明：银行卡的余额别名：bank_balance类型：money型长度：8手机信息数据项名：手机号码含义说明：用户注册的手机号码别名：phone_no类型：字符型长度：12业务信息数据项名：业务名称含义说明：手机所能办理业务的名称别名：YEWU_name类型：字符型长度：8数据项名：业务金额含义说明：业务对于的金额别名：YEWU_sum类型：money型长度：8数据项：业务编号含义说明：业务的唯一标示别名：YEWU_no类型：字符型长度：6账目信息数据项：消费月份含义
10、说明：手机消费的具体月份别名：consume_month类型：字符型长度：4数据项名：账目编号含义说明：账目的唯一标示别名：account_no类型：字符型长度：10数据项名：业务费含义说明：用户注册手机号码的时间别名：YEWU_fee类型：money型长度：8话费信息数据项名：话费编号含义说明：话费的唯一标示别名：cost_no类型：字符型长度：10数据项：话费余额含义说明：手机当前剩余的话费别名：balance类型：money型长度：8数据项名：手机号码含义说明：用户注册的手机的号码别名：phone_no类型：字符型长度：12注册信息数据项名：注册时间含义说明：用户注册手机号码的时间别名：
11、register_time类型：日期型数据项名：手机号码含义说明：用户注册的手机的号码别名：phone_no类型：字符型长度：12办理信息数据项名：办理时间含义说明：手机号码办理业务的时间别名：BANLI_time类型：日期型缴费信息数据项名：缴费金额含义说明：银行卡缴费时的金额别名：pay_sum类型：money型长度：8数据项名：缴费时间含义说明：卡缴费的时间别名：pay_time类型：日期型数据结构数据结构反映了数据之间的组合关系。 一个数据结构可以由若干个数据项组成，也可以由若干个数据结构组成，或由若干个数据项和数据结构混合组成。对数据结构的描述，数据结构描述数据结构名，含义说明，组成
12、:数据项或数据结构。工作人员信息结构=工作人员，此结构描述工作人员的具体信息，组成：工作人员编号，工作人员姓名，工作人员口令，工作人员性别用户银行卡结构=银行卡，此结构描述充值时银行卡的具体信息，组成：银行卡号，余额话费结构=话费，此结构描述当前剩余话费的具体信息，组成：手机号码，话费余额手机用户个人信息结构=用户，此结构描述用户的具体信息，组成：身份证号码，用户姓名，用户性别，用户地址，用户密码，用户年龄业务结构业务，此结果描述用户所能办理业务的具体信息，组成：业务编号，业务名称，业务金额帐目结构帐目，此结果描述用户办理的业务消费的具体信息，组成：帐目编号，消费月份，业务费数据流用户注册号码
13、=注册号码，用户到工作人员处注册手机号码，此数据来源于用户，流向用户个人信息存储，组成：用户，工作人员工作人员注册用户=注册用户，用户注册号码时工作人员添加新用户的注册信息，此数据来源于工作人员，流向用户个人信息存储，组成：工作人员，用户产生个人信息=个人信息，用户注册经工作人员确认的号码后产生的用户个人信息，此数据来源于用户，流向用户信息存储，组成：工作人员，用户用户信息提供用户信息，工作人员修改用户信息时的信息来源，此信息来源于用户个人信息存储，流向工作人员，组成：工作人员工作人员修改信息=修改后的信息，工作人员修改后的个人信息，此信息来源于工作人员，流向用户信息存储，组成：工作人员查询剩
14、余话费=提供话费信息，用户查询剩余话费时的信息来源，此数据来源于话费，流向用户，组成：用户，话费提供个人信息=提供个人信息，充值时用户信息和银行卡信息进行综合，此数据来源于用户个人信息存储，流向话费信息存储，组成：用户产生银行卡余额=银行卡余额，综合用户信息与银行卡信息后产生银行卡余额进行缴费，此数据来源于用户和银行卡，流向话费信息存储，组成：用户，银行卡产生缴费金额=缴费金额，银行卡剩余金额中支出部分金额缴纳话费，此数据来源于用户和银行卡，流向话费信息存储，组成：用户，银行卡用户办理业务=业务办理，用户办理手机业务，此数据来源于用户，流向个人业务信息存储，组成用户，业务具体业务=具体业务，用
15、户可办理的所有业务，此数据来源于业务，流向个人业务信息存储，组成业务办理的业务=办理的业务，用户确认办理的业务，此数据来源于业务和用户，流向个人业务信息存储，组成：业务，用户产生的帐目=帐目，用户办理的所有业务的消费帐目，此数据来源于业务信息存储，流向帐目信息存储，组成：业务，用户产生帐目信息=帐目信息，用户办理的所有业务产生的帐目信息，此数据来源于帐目信息存储，流向帐目，组成帐目用户查询剩余话费=提供账目信息，用户查询账目信息时提供账目信息，此数据来源于话费信息存储，流向用户，组成:用户, 话费工作人员查询业务=提供业务信息，工作人员查询所有业务时提供业务信息，此数据来源于业务，流向工作人员
16、，组成：业务，工作人员工作人员查询帐目=提供帐目信息，工作人员查询所有用户的帐目信息时提供帐目信息，此数据来源于帐目，流向工作人员，组成：帐目，工作人员工作人员查询个人业务=提供个人业务信息，工作人员查询用户个人业务时提供个人业务信息，此数据来源于个人信息存储，流向工作人员，组成：工作人员数据存储用户个人的信息=用户个人信息存储，用于存储手机用户的个人资料及话费信息等，信息来源工作人员，去向用户，组成：用户，工作人员手机的话费信息=话费信息存储，用于存储手机的话费记录，信息来源用户和银行卡，去向话费，组成：用户，银行卡，话费业务信息=个人业务信息存储，用于存储提供的所有业务，信息来源业务，去向
17、帐目，组成：用户，业务帐目信息=帐目信息存储，用于存储用户所办业务的具体帐目信息，信息来源业务信息存储，去向帐目，组成：业务，用户处理过程用户对号码注册=注册，用户对手机号码进行注册，输入：注册号码，注册用户，输出：个人信息，处理：用户进行号码注册，工作人员确认注册后，产生用户个人信息用户缴纳话费=缴费，用户使用银行卡为手机缴费。输入：提供个人信息，银行卡余额，缴费金额，输出：当前话费信息，处理：，首先综合用户与银行卡信息，然后从银行卡中扣除缴费金额，更新话费信息帐目产生生成帐目，用户办理的所有业务具体消费帐目，输入：办理的业务，输出：帐目信息，处理：统计用户办理业务后，产生具体的帐目信息2.
18、1.3数据流图数据流图如下图2.1所示。图2.1数据流图分析数据流图：基本符号：圆框，表示加工；学生表示数据的源点；：方框，表示数据的源点或数据的终点；：箭头，表示被加工数据的路径和流向，即数据流；：双杠，表示数据存储，可以是一个纪录或一个数据文件，可用名词或名词性短语命名；具体功能分析数据源点和数据终点数据源点和数据终点用方框表示，它是系统之外的实体，可以是人、事、物、部门或其他系统，如图2.1中的工作人员和用户。加工（数据处理变换）加工用圆框表示，是对数据进行处理的逻辑单元，它接受若干输入数据流，通过加工内部产生规定的输出数据流。如图2.1中查询手机用户基本信息。数据流数据流用带数据流标识
19、的箭头表示，表示系统处理的数据对象和数据流动的方向。数据流的方向可以是：从一个加工流向另一个加工、从加工流向数据存储或数据存储流向加工、从源点流向加工或从加工流向终点，如图2.1中箭头所表示就是流向。2.2概念结构设计2.1.1概念结构设计思想概念结构设计是将需求分析阶段所得到的用户需求抽象为信息结构，能够真实、充分的反映现实世界，包括事物与事物之间的联系，能满足用户对数据的处理需求，易于理解，易于更改，易于向关系、网状、层次等各种数据模型转换。概念结构是各种数据模型的共同基础，它比数据模型更独立于机器、更抽象，是用来描述某个特定组所关心的信息结构，从而更加稳定。2.1.2概念结构设计方法概念
20、桔构设计通常有四种方法，自顶向下、自底向上、逐步扩张、混合策略等四种方法。通常采用自底向上的方法，自顶向下地进行需求分析，然后再自底向上地设计概念结构。自底向上的设计概念结构的方法通常分为两步：第一步是抽象数据并设计局部视图，第二部是集成局部视图，得到全局的概念结构。基于这些，本次课程设计采用自底向上的方法进行概念结构设计。根据需求分析阶段的需求分析设计思想、数据字典以及数据流图所提供的信息，采取分类、聚集的抽象方法，对需求分析的结果进行细化、补充和修改。形成实体、实体的属性，标示实体的码，确定实体之间的联系类型（1：1，1：n，m：n），设计分ER图，然后将所有的分ER图综合成一个系统的总E
21、R图。最后根据总的ER图，利用利用PowerDesigner设计出概念模型。根据需求分析阶段所提供的系统信息，确定系统中的实体、属性以及实体之间的联系。确定实体和属性的两条准则：1.作为“属性”不能再具有需要描述的性质。“属性”必须是不可分割的数据项，不能包含其他属性。2.“属性”不能与其他实体具有联系，即ER图中所有表示的联系是实体之间的联系。设计局部ER图用户实体信息，如图2.2所示。图2.2用户实体信息用户实体定义。用户：身份证号码，用户姓名，用户密码，用户性别，用户地址，用户状态工作人员实体信息，如图2.3所示。图2.3工作人员实体信息工作人员实体定义。工作人员：工作人员编号，工作人员
22、姓名，工作人员性别，工作人员口令银行卡实体信息，如图2.4所示。图2.4银行卡实体信息银行卡实体定义。银行卡：银行卡号，余额话费实体信息，如图2.5所示。图2.5话费实体信息话费实体定义。话费话费编号，手机号码，话费余额业务实体信息，如图2.6所示。图2.6业务实体信息业务实体定义。业务业务编号，业务名称，业务金额账目实体信息，如图2.7所示。图2.7账目实体信息账目实体定义。账目账目编号，消费月份，业务费手机信息实体，如图2.8所示。图2.8手机实体信息手机实体定义。手机手机号码银行卡实体和话费实体之间的联系，如图2.9所示。图2.9银行卡实体和话费实体之间的缴费联系用户的一张银行卡可以为自
23、己的多部手机缴费，一部手机的缴费可以通过用户的多张不同的银行卡进行。银行卡实体和话费实体之间通过缴费构成多对多的联系。手机实体和业务实体之间的联系，如图2.10所示。图2.10手机实体和业务实体之间的办理联系一个手机号码可以办理多个业务，一个业务可以被多个手机号码办理。手机实体和业务实体通过办理构成多对多联系。工作人员实体和用户实体之间的联系，如图2.11所示。图2.11工作人员实体和用户实体之间的注册联系一个工作人员可以为用户注册多个手机号码，一个用户的手机号码可以由多个工作人注册。工作人员实体和用户实体之间通过注册构成多对多的联系。集成局部ER图生成全局ER图根据局部ER图，实体的属性，实
24、体的码，实体之间的联系，设计出的手机话费管理系统E-R图，如下图2.12所示。图2.12全局ER图2.1.3 CDM模型的生成过程安装完PowerDesigner后，依次选择【开始】【程序】【Sybase】 【PowerDesigner 9 】【PowerDesigner】选项，弹出【PowerDesigner】对话框，进入PowerDesigner运行界面，如下图2.13所示。 图2.13 PowerDesigner运行界面然后在【PowerDesigner】中新建一个CDM模型：选择【File】【New】命令。弹出的子菜单中选择 Conceptual Data Model,单击【OK】按钮
25、，如图2.14所示。图2.14 选择界面出现CDM工作区，如图2.15所示。图2.15 CDM工作区创建实体：单击Palette面板中的【Entity】工具，如图2.16所示。在模型区域单域单击鼠标左键，在鼠标单击的位置出理Entity的图符即创建一个实体，如图2.17所示。实体图标：绘制实体实体到联合连接图标：绘制实体到联合的联系联合图标：绘制带有属性的联系实体到实体连接图标：绘制实体到实体的联系图2.16 CDM中的工作板图2.17 创建实体双击CDM工作区中的实体图形，出现定义实体特征的窗口【Entity Properties】，如图2.18所示。图2.18 定义实体特征窗口绘制实体：输
26、入Name、Code内容。这里Name表示实体的描述名称，一般最好用中文描述（如：用户）， Code表示实体的代码名称，最好用简化的英文描述（如：user）。单击“确定”按钮，当前CDM工作区就定义了一个实体。定义实体属性实体属性是附加到实体上的数据项。在DataArchitect环境下，定义一个实体属性需在图2.18所示的窗口上选择“Attributes”选项卡，出现定义实体属性的窗口，如图2.19所示。图2.19 定义实体属性窗口在图2.19窗口中必须完成如下工作：确定实体属性的Name和Code。Name是对属性含义的具体描述，一般最好用中文描述，Code是属性的代码，与今后程序设计时有
27、很大关系，所以定义时应特别谨慎。确定实体属性的数据类型（Data Type列）。确定一个属性是否为这个实体的标识符或标识符的一部分（Primary复选框），实体的标识符可以由一个或多个属性组成，它惟一标识实体中的一个实例，即它代表了关系中的主键，在实体图形符号中，标识符（主键）属性带有下划线。标识一个实体的属性是否为强制的（Mandatory复选框），强制特性表示属性是否需要一个值，如果属性是强制的，那么该属性在数据库表中的对应列上不允许空值，一般主键是不允许为空的。标识一个实体属性是否在模型中显示（Display复选框）。需要指出的是，在图2.18的窗口上必须输入Name、Code和Data
28、 Type列的内容。输入完成后，单击“确定”按钮，此时完成了一个实体属性的定义。绘制联系在DataArchitect环境下绘制联系分两种情况：绘制不带属性的联系不带属性的联系通常是用实体之间的一条线，即使用“实体到实体连接图标”来绘制。其操作过程是：选中工具板上“实体到实体连接图标”，在CDM工作区中，将鼠标的十字箭头定位到一个实体，按住左键拖拉到另一个实体中，松开鼠标，此时在两个实体之间出现一条线，表明两个实体间已建立了一个联系，然而联系的类型可能需要重新确定，因为联系的默认类型可能不符合要求。定义联系的类型以及联系的特性，可以双击代表联系的线，出现定义“无属性”联系窗口，如图2.20所示，
29、此时可以修改相应的内容。图2.20 定义无属性的联系窗口在图2.20的窗口中必须完成如下工作： 确定联系的名称（Name），通常系统提供默认值。 确定代码（Code），通常与Name相同。 确定角色（Role），这里角色是个动词，它描述了实体间的联系。通常要为联系的两个方向定义角色。 确定基数（Cardinality），它反映了两个实体间的联系类型，基数包括一对一、一对多、多对一及多对多四种联系类型，它是有方向的。通常联系的两个方向上都应该定义基数。 确定依赖（Dependent），依赖表示一个实体是否依赖于另一个实体。 确定强制（Mandatory），这里强制表示实体间的联系是否可选。如果在
30、依赖基础上又选择了强制，那么，在生成物理模型时，一端表的主键将在另一端表中出现，而且仍然是主键。通常应该从两个方向上定义强制。在模型中用穿过联系的一条短直线表示强制，用联系上的一个小圆圈表示可选。如果定义联系时选择不同，那么在模型中表示联系的线上是有区别的，请在实践过程中留意。绘制带有属性的联系带有属性的联系通常分两步，首先要使用“联合图标”建立一个“联合”，然后再使用“实体到联合连接图标”完成。 建立“联合”过程首先选中工具板上“联合图标”，在CDM工作区中单击任意处，产生“联合”；用鼠标双击“联合”图形，出现定义“带属性”联系即联合特性的窗口，如图2.21所示。图2.21联合特性的窗口在“
31、General”选项卡中，输入Name（即联系名，最好输入汉字名字）、Code（最好输入英文名）。在“Attributes”选项卡中，输入联系的属性。单击“确定”按钮，在CDM工作区中产生一个“联合”（即带有属性的联系）。 建立实体到联合的连接“联合”建立好后，需要将该“联合”与相关实体连接，使用“实体到联合连接图标”来完成。其操作过程是：选中工具板上“实体到联合连接图标”，在CDM工作区中，将鼠标的十字箭头定位到一个“实体”，按住左键拖拉到“联合”中，松开鼠标，此时在该实体与联合之间出现一条“联合连接”线（也可以绘制另一个实体到联合的连接），这条线表明实体与联合之间建立了一种关联，然而这种关
32、联的类型需要重新确定，双击“联合连接”线，出现定义“联合连接”线特性的窗口，如图2.22所示。图2.22 定义“联合连接”特性的窗口在图2.22的窗口中，需要在从下拉列表中选择“Cardinality”的值（即实体到联合的连接类型，有“0，n”、“0，1”、“1，1”、“1，n”四种类型可选择），单击“确定”按钮，完成设置。参照上面的使用部骤依次建立各个实体并修改实体的属性；再依次建立实体间的联系并修改其属性，最后生成CDM模型，如图2.23所示。图2.23 CDM模型2.3逻辑结构设计概念结构是独立于任何一种数据模型的信息结构。逻辑结构设计的任务就是把概念结构设计阶段设计好的基本E-R图转化
33、为与选用DBMS产品所支持数据模型相符合的逻辑结构。2.3.1逻辑结构设计的思想针对手机话费管理系统 ，逻辑结构设计采用关系模型转换概念结构，将E-R图依照规则转换为关系模型，为了进一步提高数据库应用系统的性能，再将转换后的关系模型进行优化，确定是否要对某些模式进行合并或分解，为物理设计提供最优的处理。 2.3.2 E-R图向关系模型的转换关系模型的逻辑结构是一组关系模式的集合。E-R图则是由实体，实体的属性和实体间的联系三个要素组成。所以将E-R图转换为关系模型实际上就是要将实体，实体的属性和实体间的联系转换为关系模式。转换原则如下：实体类型的转换:将每个实体类型转换成一个关系模式，实体的属
34、性及为关系模式的属性，实体标识符及为关系模式的键。联系类型的转换，根据不同的情况做不同的处理。 若实体间的联系是1:1的，可以在两个实体类型转换成的两个关系模式中的任意一个关系模式的属性中加入另一各关系模式的键和联系类型的属性。 若实体间的联系1:N的，则在N端实体类型转换成的关系模式中加入1端实体类型转换成的关系模式的键和联系类型的属性。 若实体间的联系是M:N的，则将联系类型也转换成关系模式，其属性为两端实体类型的键加上关系类型的属性，而键为两端实体间的组合。3个或3个以上实体间的一个多元联系可以转换为一个关系模式。与该多元联系相连的各实体的码以及联系本身的属性均转换为关系的属性，各实体的
35、码组成关系的码或关系码的一部分。具有相同码的关系模式可合并。 依照该规则将企业人事管理系统的E-R图转换为关系模型如下 将每一个实体转换成一个关系（关系就是给出关系名，写出属性，并标明该关系的主键） 工作人员的基本信息（工作人员编号，工作人员姓名，工作人员性别，工作人员口令）此为工作人员实体对应的关系模式，主码为工作人员的编号。 用户的基本信息（身份证号码，用户姓名，用户密码，用户性别，用户地址，用户状态）此为用户实体对应的关系模式，主码为用户的身份证号码。 银行卡信息（银行卡号，余额）此为银行卡实体对应的关系模式，主码为银行卡号。 话费信息（手机号码，话费余额）此为话费实体对应的关系模式，主
36、码为手机号码。 业务信息（业务编号，账目编号，业务名称，业务金额）此为业务实体对应的关系模式，主码为业务编号，业务消费产生账目，为n：1的“消费”联系，所以账目编号为业务信息的外码。账目信息（账目编号，消费月份，业务费）此为账目实体对应的关系模式，账目编号为主码。缴费（缴费编号，手机号码，缴费金额，缴费时间）此为联系“缴费”所对应的关系模式，银行卡缴费话费的n:m“缴费”联系，所以银行卡号和手机号码联合做“缴费”的主码。办理（业务编号，手机号码，办理时间）此为联系“办理”所对应的关系模式，手机办理业务的n:m“办理”联系，所以手机号码和业务编号联合做“办理”的主码。注册（工作人员编号，身份证号
37、码，注册时间，手机号码）此为联系“注册”所对应的关系模式，工作人员为用户注册的n:m“注册”联系，所以工作人员的编号和用户的身份证号码联合做“注册”的主码。手机信息(手机号码，身份证号码)此为手机实体的关系模式，手机号码为主码，手机号码为用户的n：1的“属于”关系，所以用户的身份证号码传递过去做手机的外码。由E-R图可知，手机话费管理系统有七个实体和三带属性个联系。可转换为10个关系模型。由关系依赖知，在工作人员的基本信息、用户的基本的信息、银行卡信息、话费信息、账目信息、业务信息、手机信息、缴费、办理、注册中，这十个关系模式中其属性都是不能再分的，为一阶范式。并且都是由主码唯一决定关系中的其
38、他属性，不存在部分函数依赖和传递函数依赖，所以这是十个关系都是3NF。皆为最优，关系模型的优化结束。2.3.3 PDM模型的生成过程 选择生成CDM模型中的【Tools】 【Generate Physical Data Model.】得到PDM对话框生成图，首先选择要转换的DBMS,这里选择“ORACLE Version 9i”，然后确定名称(name)和代码(code)如图2.24所示。图2.24 PDM对话框生成图 点击确定，最后形成PDM，如图2.25所示。图2.25 PDM模型2.3.4 SQL脚本/*=*/* Database name: ConceptualDataModel_5
39、*/* DBMS name: ORACLE Version 9i */* Created on: 2008-11-29 21:32:38 */*=*/alter table BANLI drop constraint FK_BANLI_BANLI_业务/alter table BANLI drop constraint FK_BANLI_BANLI2_手机/alter table bank_card drop constraint FK_BANK_CAR_USE_USER/alter table pay drop constraint FK_PAY_PAY_BANK_CAR/alter tab
40、le pay drop constraint FK_PAY_PAY2_PHONE_CO/alter table register drop constraint FK_REGISTER_REGISTER_STAFF/alter table register drop constraint FK_REGISTER_REGISTER2_USER/alter table 手机 drop constraint FK_手机_BELONG_USER/alter table 业务 drop constraint FK_业务_CONSUME_ACCOUNT/drop index BANLI2_FK/drop
41、index BANLI_FK/drop index use_FK/drop index pay2_FK/drop index pay_FK/drop index register2_FK/drop index register_FK/drop index belong_FK/drop index consume_FK/drop table BANLI cascade constraints/drop table account cascade constraints/drop table bank_card cascade constraints/drop table pay cascade
42、constraints/drop table phone_cost cascade constraints/drop table register cascade constraints/drop table staff cascade constraints/drop table user cascade constraints/drop table 手机 cascade constraints/drop table 业务 cascade constraints/*=*/* Table: BANLI */*=*/create table BANLI ( YEWU_no CHAR(6) not null, 手机号码 CHAR(10) not null, BANLI_time DATE, constraint PK_BANLI primary key (YEWU_no, 手机号码)/*=*/* Index: BANLI_FK */*=*/create index BANLI_FK on BANLI ( YEWU_no ASC)/*=*/* Index: BANLI2_FK
