毕业论文指导资料.docx
- 文档编号:12711920
- 上传时间:2023-04-21
- 格式:DOCX
- 页数:27
- 大小:53.96KB
毕业论文指导资料.docx
《毕业论文指导资料.docx》由会员分享,可在线阅读,更多相关《毕业论文指导资料.docx(27页珍藏版)》请在冰豆网上搜索。
毕业论文指导资料
毕业论文指导资料
目录
一、本科学生毕业论文的目的和内容
二、管理信息系统开发的主要步骤
三、开发工具和注意事项
四、毕业论文指导资料
五、毕业论文撰写格式
一、本科学生毕业论文的目的和内容
本科学生在毕业之前必须做毕业论文,其目的是通过毕业论文,让学生独立开发一个具体的计算机应用项目,系统地进行分析总结和运用学过的书本知识,以巩固本科阶段所学的专业理论知识,并给予一个理论联系实际的机会。
为了便于实施和管理,规定网络学院计算机相关专业本科学生毕业论文主要以开发一个管理信息系统为毕业实践的课题,每个毕业生通过独立开发一个具体的管理信息系统,掌握开发一个比整完整的管理信息系统的主要步骤,并从中获得一定的实际经验。
二、管理信息系统开发的主要步骤
管理信息系统开发的主要步骤及各步骤的基本内容如下:
1、 系统分析
主要工作内容有以下几项:
确定系统目标
系统可行性分析
2、 系统调查
系统的组织结构、职能结构和业务流程分析。
其中系统的组织结构图应画成树状结构。
系统业务流程分析、业务流程图
3、 数据流程分析
数据流程图(系统关联图、顶层图、一层数据流图、二层数据流图)
数据词典
代码设计
4、 管理信息系统的功能设计
系统的功能结构图,每个功能模块的主要工作内容、输入输出要求等。
系统控制结构图
5、 数据库设计
概念模型设计:
实体、实体间的联系、E-R图
关系模式设计:
E—R图->关系模式的转换规则
关系模式
数据库表设计:
数据库表结构
6、 系统物理配置方案
7、 人机界面设计
8、 模块处理概述
9、 系统测试和调试:
测试计划、测试用例、测试结果
三、开发工具和注意事项
1、开发工具
开发工具可由学生任选。
如Delphi、FoxPro、VB、Access等,这些工具的使用全由学生自学。
2、注意事项
(1)项目开发步骤的完整性(系统需求分析、概念设计、物理设计、系统环境和配置、系统实施以及系统测试和调试等)
(2)每个开发步骤所得结果的正确性(业务流程图、数据流程图、数据词典、HIPO图、E-R图、关系模式、人机界面设计及模块处理等的详细分析和说明)
(3)论文整体结构的完整性(前言、各个具体步骤的叙述和分析、结语、参考文献和有关附录)
(4)提供软件系统的可执行盘片及操作说明书
(5)参考资料(列出必要的参考资料)
四、毕业论文指导资料
1、可行性分析
技术可行性、经济可行性、营运可行性
2、 数据流程图
数据流程图是结构化系统分析的工具。
它既可以表达数据在系统内部的逻辑流向及存储,又可以表达系统的逻辑功能和数据的逻辑变换。
数据流程图既能表达现行人工系统的数据流程和逻辑处理功能,也能表达自动化系统的数据流程和逻辑处理功能。
数据流程有四种基本符号:
外部项、数据流、处理逻辑(加工)、数据元素和数据存储。
(1)外部项
外部项又称外部实体,是指不受系统控制,在系统之外的事物或人。
它表达该系统的数据的外部来源或去处。
它也可以是另外一个数据处理系统,它向该系统提供数据或接收来自该系统向它发出的数据。
(2) 数据流
数据流用箭头表示数据流动的方向,并给予命名。
一般采用单箭头,偶尔使用双箭头。
数据流可以由某一个外部项产生,也可以由某一个处理逻辑产生,还可以来自某一个数据存储。
一般来说,对每一个数据流可以在数据流箭头的上方加以简单的描述;对一些含义比较明显的数据流,就不一定作描述。
也可以在数据流上写记号,然后另外给出记号的意义。
(3)处理逻辑(加工)
处理逻辑对数据的变换方式有两种:
A、变换数据的结构
B、在原有数据内容基础上产生新的数据内容
可以用一个长方形框表示处理逻辑。
由三部分组成:
标识部分、功能描述部分和功能执行部分。
标识部分用于惟一地标识一个处理逻辑,以区别于其它逻辑。
一般用数字编号表示主处理逻辑,编号下再接子编号,表示某个处理逻辑被进一步分解后某个处理逻辑下的某个子处理逻辑等。
功能描述部分是处理逻辑必不可少的部分。
用一句非常简单的话,直接表示这个处理逻辑要做的事,即它的逻辑功能。
在逻辑的功能描述部分中没有主语,只有动词和宾语组成。
执行这项功能的主体可能是某一个部门,也可以是某一个人或计算机程序,它们被看作处理逻辑的执行者,书写在长方框的底部。
功能执行部分同标识部分一样,不是必须的,只是作参考用,通常是不写出的。
(4)数据元素
数据元素是数据的最小组成单位,是不可分的数据单位。
数据元素是数据流或数据存储中的基本成分。
(5)数据存储(文件)
数据存储用长方条表记,在长方条内部写上该数据存储的名称。
用作标识的编号一般用英文字母D和数字组成。
同外部项一样,允许在一张数据流程式图上重复出现相同的数据存储,以避免数据流线的交叉,这时应在重复的数据存储符号的左侧再加一条竖线。
一个处理逻辑可能要从数据存储中读出某些数据,或者可能把一些数据存入到某个数据存储中,甚至修改数据存储中的某些数据,那么就得用数据流将处理逻辑和数据存储联结起来。
3.数据流程图的分解
编制复杂的数据流程图,采用自顶向下扩展逐层分解。
首先是系统关联图,给出外部实体与即将开发的管理信息系统之间的数据流(从外部实体进入系统,或从系统输出给外部实体)。
关联图回答系统从外部世界得到什么,系统将给外部世界又是什么。
从关联图分解得到顶层图,又从顶层图分解得到一层数据流程图,再分解出二层数据流程图。
在分解过程中,随着更具体和更详细,新的数据流和数据存储被引入,但在关联图中提及的那些数据流是不能再增加,也不允许被减少的。
在上述分解过程中,上层的一个处理逻辑可能被分解成多个更具体的处理逻辑,新的数据存储和数据流被引入。
如此逐一分解扩展,直至不需要再分解为止。
4、数据词典
数据词典,既用于描述数据流和数据存储的详细逻辑内容,也可用于描述外部项和处理逻辑的某些数据特性。
数据词典把数据的最小组成单位看作数据元素,若干个数据元素组成数据结构。
它通过对数据元素和数据结构的定义,来描述数据流和数据存储的逻辑内容。
数据元素
数据元素是数据的最小组成单位,也就是不可分的数据单位。
在数据词典中,对数据元素的定义包括以下五项内容:
(1) 数据元素的名称
(2) 在其他场合下的别名
(3) 取值的范围和取值的含义
(4) 数据元素的长度
(5) 在何处出现
数据结构
在数据词典中,数据结构是用来对数据之间的组合关系进行定义的,它完全是一种逻辑的描述。
一个数据结构可以由若干个数据元素组成,也可以由若干个数据结构组成,还可以由若干个数据元素和数据结构混合组成。
在数据结构中,对数据结构的定义包括以下几项内容:
(1)数据结构的名称
(2)数据结构的组成
数据流
数据流是数据结构在系统内传输的路径。
在数据词典中对数据流的定义要包括以下五项内容:
a) 数据流的来源
b) 数据流的去向
c) 数据流的组成
d) 数据流的流通量
e) 高峰时期的流通量
数据存储
数据存储也是数据流的来源或去向之一。
在数据词典中,对数据存储定义的内容简单地给予以下描述:
(1)数据存储的名称及其编号
(2)流入/流出的数据流
(3)数据存储的组成:
数据结构
处理逻辑
处理逻辑的表达工具有判断树、判定表、结构化语言等。
在数据词典中,对处理逻辑的定义有以下的内容:
(1)处理逻辑在数据流程图内的名称和编号。
处理逻辑的名称应该反映它的逻辑功能
(2)对处理逻辑简单的描述
(3)处理逻辑的输入和输出
(4)对处理逻辑的主要功能描述,可用结构化语言简单地概括其逻辑功能
处理逻辑在数据词典中的表达应该按“输入-处理-输出”的顺序排列。
外部项
外部项的数量反映了系统的独立性程度,以及人机界面设计的合理性。
外部项的个数应尽可能少。
外部项在数据词典中的定义包括以下两项内容:
(1) 外部项的名称
(2) 有关的数据流
5、关系数据库建模
逻辑数据库的设计过程分成两个阶段。
概念模式设计
对给定的现实世界状态的第一层抽象(与计算机无关)。
逻辑数据结构设计
这是概念模式的表示,可以把它映照成一种实际的处理(与计算机、数据模型都有关)。
第一阶段同应用领域的信息需求分析有关,用来提供非形式的需求规格说明,由此构造一个高级的数据模型。
数据库设计应先进行概念模型的设计,然后是对关系数据库的建模。
采用称之为实体联系模型的非形式模型。
它提供一种表示实体及其相互联系的自然方法。
先在第一阶段的设计策略上使用实体联系模型,然后讨论从实体-联系模型向关系模型的转换。
实体-联系的建模
实体-联系模型中的信息由下列三种基本概念级成:
实体正要被建模的对象
联系实体之间的联系
属性实体和联系的特征
模式化的实体-联系模型
模式化的实体-联系模型用图表方法表示数据的自然结构。
在图表中,用长方框表示实体集,菱形框表示联系。
联系由弧边把参加的实体连接起来,联系的对应元个数可在弧边上标出。
在完整的E-R模型中,还对每个实体和联系的属性另外列出。
键
关系R的键K是有如下性质的属性的一个子集:
(1)惟一的标识性,在R上,K的值惟一地标识一个元组
(2)无冗余性,在不破坏性质
(1)的情况下,K中没有属性可以被删除
在同一个关系中每一个元组都是不相同的,故键总是存在的。
一个关系可以有多个候选键。
在这种情况下,必须从中选出一个作为基本的键。
组成基本键的属性称为主属性。
在任何元组中,主属性的值不可以是空的。
在关系模式中,用下划线标出主属性。
联系
在现实世界中,实体集或“型”之间会出现:
1:
1,1:
N,N:
M等复杂的联系。
例如:
在同类型的实体集之间或者两个以上实体集之间可以有联系。
不同实体集之间的联系:
不同实体集之间的联系的实例举不胜举,如学生与课程之间的选修联系,产品与仓库之间的存放联系等
同一实体集的实体间联系:
同一实体集的实体间联系指在相同实体集中不同实体之间的联系。
1:
1的同一实体联系
实体集个人实体可以与另一个成员建立婚姻关系,在一夫一妻制下是1:
1的同一实体联系。
在这个联系中,个人之间的这个联系常用婚姻状况的属性来简单表示。
1:
N的同一实体联系
实体集雇员可以领导其他雇员,若一个雇员领导多个雇员,领导联系是一个1:
N联系。
N:
M的同一实体联系
实体集部件可以由其他一些部件组合而成,这种情况可以由一个N:
M的同一实体联系表示。
子类型
实体集E1的每一个实例也是实体集E2的实例,那么E1是E2的子类型。
如果实体集E的每一个出现也是实体集E1、E2、…、En中的仅有一次出现,那么E是E1、E2、…、En的一个超类型。
子类型的例子是,在学院数据库中也许规定系主任是一位教授更合适。
教授是教师的特别范畴。
同样,实体集教师和学生具有一些共同的性质,其实都可以把他们看作实体集人的不同范畴。
实体集教师和学生都是实体集人的子类型,而实体集教授是教师实体集的子类型。
另一方面,如果在数据库内实体集人的每一个实例是实体学生的一个实例或者是实体集教师的一个实例。
那么,人是学生和教师的超类型。
子类型同其超类之间的联系由一种特别的1:
1联系IS-A来表示。
子类型不要求全部的,只需要部分共享超类型属性和联系。
另一方面,子类型可以有附加的,只有它才有的属性和联系。
例如,只有教授才能担任系主任等。
由此,这个联系应该在实体集教授、系之间定义。
教授共享教师的全部属性,但是可以有仅同教授相关的附加属性。
例如系主任职务。
对于需要不同用记视图的应用中,特别要用到子类型。
这在一般性和类型的层次性中是一项关键技术。
三个实体集的实体间联系
联系可以由两个或两个以上的实体集组成。
例如:
对关于公司、产品和销售国家等的信息,它们之间是三个实体间存一个销售关系,且是多对多的。
对于给定的一对(公司,产品)可销售多个国家;
对于给定的一对(公司,国家),会销售多种产品,由该公司出口到该国。
通常是在不能够对有关的多个实体集使用多个二元联系时才引入三元联系。
例如,如果某公司制造多个产品,而且把全部产品出口到许多不同的国家,那么可以用公司与产品之间的制造联系,以及公司与国家的出口关系代替。
一个E-R图的实例
某学院有基本实体集:
系、教师、学生和课程。
它们各有属性:
系:
系编号,系名,位置
课程:
课程号,课程名称,开课学期
学生:
学生学号,学生姓名,性别,地址
教师:
教师编号,教师姓名,办公室
实体间有联系:
每个系有一位系主任,有多位教师;一个教师仅在一个系任职;每个系开设多门不同课程;每门课程各由一位教师授课;一个学生可以在不同的系选修多门课程。
存在联系有:
1对1:
系与系主任(系主任是教师)
1对多:
系与教师、系与课程,教师与课程
多对多:
学生与课程
因此有E-R图
E-R模型转换成关系模式的基本规则
实体集的转换
每个实体集用一个关系表示,实体集的属性被转换成关系的属性。
实体集的主键在满足惟一标识和无冗余等性质的条件下,将作为对应关系的主键。
在实体关系中,由于它与其它实体集存在联系,可能还要增加一些属性。
二元联系的转换
对联系的转换技术主要同联系的性质,以及参加联系的实体集成员类有关。
相应的法则如下:
A.强制类型类
倘若实体集E2与实体集E1的联系N:
1,E2的关系模式应包含E1的主属性。
例如,倘若规定每门课程由本系授课,在实体集课程与系之间的提供联系中,课程是联系提供的强制成员。
因此课程的关系模式中应包含实体集系的主属性:
课程(课程号,系编号#,教师编号#,课程名称,开课学期)
其中“系编号”是由提供关系引入的键,称为外键(用#表示),表示系与课程之间的提供联系。
而教师编号又是反映课程与教师之间授课联系,表示该课程是某位教师讲授的。
B.可选成员类
倘若实体集E2是它同实体集E1的N:
1联系中的一个可选成员,那么,这个联系往往由包括E1和E2主属性以及该联系中每个属性的各个关系模式表示。
例如,图书馆的书,也许被借出或者未被借出(假定仅将当前借出的记录在数据库内)。
读者和书之间的联系借阅联系是1:
N的。
若用下列关系模式表示这个E-R模型
读者(证号,姓名,地址)
书(ISBN,证号#,借阅日期,应还日期)
在关系书中引入外键证号,记下当前借出具体一本书的借书人的借书证号码。
然而,在关系书本中许多元组的属性证号的值是空的,表示对应的书处于未出借状态。
这里的空值指某本书实体当前未参加借阅联系。
不仅仅联系的可选型会引起空值,由于实体集的某个实例的具体属性未定义,也会引起空值。
在上例子中,可以引入另一个表示联系出借的关系,来避免空值:
读者(证号,姓名,地址)
书(ISBN,书名,出版社)
借阅(ISBN#,证号#,出借日期,应还日期)
这样,只有当前被借出的书才出现在关系借阅中。
如果一个联系有某种属性,那么,将可选联系用另一个关系来表达是有意义的。
例如,在上例增加了出借日期和应还日期等与联系借阅结合。
在联系中,实体集的联系型也许是“几乎强制”的,这就是说,绝大多数的元组都参加联系。
在这种情况下,容许少量空值比引入另一个关系更好。
C.N:
M二元联系
N:
M联系一般由另一个关系模式表示。
这个关系模式由每个参加的实体集的主属性以及这个联系的全部属性一起组成。
这种变换应用于参加实体集的各种成员类。
例如实体集学生和课程之间的联系选课可以由下列模式表示:
选课(学号#,课程号#,选课日期,实践成绩,考试成绩)
学院数据库的关系模式
应用上述基本转换规则,若实体集E2与实体集E1的联系1:
1,应根据需要把E2的主属性放入关系模式E1中,或反之。
若实体集E2与实体集E1的联系N:
1,E2的关系模式应包含E1的主属性。
N:
M联系一般由另一个关系模式表示,这个关系模式由每个参加的实体集的主属性以及这个联系的所有属性一起组成。
得到以下学院落数据库关系模式:
系(系编号,系名,教师编号#,位置)
课程(课程号,系编号#,教师编号#,课程名称,开课学期)
学生(学号,姓名,性别,地址)
教师(教师编号,教师姓名,系编号#,办公室号)
选修(学号#,课程号#,选课日期,实践成绩,考试成绩)
在以上模式中,关系系的外键教师编号表示联系领导,以说明这个联系的成员是对系强制的。
关系课程中的外键教师编号和系编号分别表示联系授课和提供。
课程实体集是每一个这些联系的强制成员。
关系教师内的外键系编号表示系与教师之间的联系属于。
教师是它们的强制成员。
最后,由M:
N联系引出关系选修。
E-R模型转换成关系模式方法的进一步讨论
同一实体集联系的转换
同一实体集联系的转换在很大程度上根据二元联系的类型。
A.1:
1同一实体集联系
1:
1同一实体集联系的常用例子是在实体集人的实例之间的婚姻联系。
显然,这是一种可选的联系,因为会有一些人不参加这个联系。
因此可用另一个关系模式表示这个联系:
个人(身份号,名,地址)
婚姻状况(丈夫身份号#,妻子身份号#,结婚日期)。
必须在婚姻关系上用区分丈夫和妻子的身份号码来解决属性名冲突问题。
假定每个人只允许有一个配偶,于是丈夫身份号或者妻子身份号都可用作关系婚姻的主键。
倘若希望存储婚姻的资料,联系便是N:
M的,而且丈夫身份号和妻子身份号一起组成键属性。
若考虑有复婚的情况,则主键还要包含结婚日期。
B.1:
N同一实体集联系
1:
N同一实体集联想系的例子是雇员和上司的实体联系。
倘若每一个雇员都有一个上司,那么就要有一个强制联系。
它可以通过上司的键置于雇员的关系模式上来表示。
如:
雇员(雇员身份号,上司身份号#,雇员名)
倘若仅有一些雇员被领导,那么要用另一个关系表示这个联系,见如下的关系模式:
雇员(雇员身份号,雇员名)
领导(雇员身份号,上司身份号#)
C.N:
M同一实体集联系
N:
M同一实体集联系的例子是,一个部件是其它部件的组成零件,这个联系可以翻译成如下的关系模式:
部件(部件号,部件名,规格说明)
组成(主部件号#,分部件号#,数量)
部件关系模式对于组成联系有另一个关系。
按这个方法,它要有参加实体的键属隆。
然而,对于同一实体集的联系来说,这些键属性取自同一实体集,而且必须区分它们,以上说明组成一个大部件的每一种小部件有一定的个数。
子类型转换
子类型的关系只包含超类型的键同该子类型指定的增加属性。
例如,假设把实体集教师的子类型教授引入学院模式。
然后,这个关系模式将对教授有另一个关系,它的形式是:
教授(教师编号#,系主任头衔)
在这个关系中,键属性教师编号是外键,它取自关系教师。
这个外键表示子类型和其超类之间的是其中之一联系。
通过这个外键,可以访问教授同其他教师共有的附加属性。
层次类型的转换得到一个代表根实体集和每个子类型的另外关系,每个关系的键是根实体关系的键,它还可以包括对所有子类型所拥有的属性。
每个子类型的关系,包含同这个键一起的隶属该子类型的属性。
于是,层次类型涉及实体集人同子类型学生和教师,以及教师的子类型的实体集教授,可由下列形式的关系模式表示:
个人(身份号,所有个人公共属性)
学生(身份号#,所有学生公共属性)
教师(身份号#,所有教师公共属性)
教授(身份号#,所有教师公共属性)
身份号惟一地标识实体集人一个实例。
关系人将对每个学生、教师和教授都有一个元组。
关系教师对每一个教授有一个元组。
三个实体集联系的转换
一个三个实体集联系被转换成另一个关系模式,其中包括有三个参加联系的实体集的键,以及这个联系的属性。
例如公司、产品、国家三者之间存在销售联系。
在联系销售中,可能要附加每年由公司销售到有关国家的产品数量。
联系销售的键由这个联系的对应性确定。
倘若是N:
M:
P的,那么全部三个外键作成销售的键。
倘若每个公司把它的每个产品仅出口一个国家,那么,显然仅需把公司和产品两个外键作成销售的键。
考虑这样一种情况,一些学员在导师指导下做不同的课题。
设没有一个导师能够指导一个做多项课题的学员;又没有一个学员能够在多个导师指导下做一个项目。
可以用一个包括学员、导师和课题三个实体集联系来表示指导联系。
该联系是1:
1:
N的,可用以下四个关系模式表示。
学员(学员号、……)
导师(导师号、……)
课题(课题号、……)
指导(导师号#、学员号#、课题号#、……)
作为1:
1:
1三个实体集联系的一个例子,实体集教师、教科书和课程之间的联系。
教师给一门课程选用一本教科书,对同一门课程不同的教师选用不同的教科书,没有一个教师对不同的课程选用同一本教科书。
但是,对不同的课程,不同的教师可以选用相同的教科书。
联系使用是1:
1:
1的,使用关系模式有三个候选键,从三中候选键中任意选出二个都可作为采用关系的键。
教师(员工号、……)
教科书(书号、……)
课程(课程号、……)
采用(员工号#、书号#、课程号#、……)
关系模式的规范化
使用前述方法设计的关系模式仍然会产生异常或者不协调性。
必须在实现之前解决这个问题。
这个求精过程称为规范化。
规范化理论建立在范式概念上。
按前述方法设计的关系模式,最低限度是第一范式INF。
第一范式的每个属性是一个原子,是不可分解的数据项。
这个性质是在原来的关系定义中规定的。
从原始的需求分析出发推出合适的实体,属性和关系将会对所得关系模式上的规范水平有根本的影响。
关系模式中的任何异常或者不协调性很大程度是由于实体-联系模型的不合适或者不正确引起的。
函数依赖
对于给定的关系R,R的属性B函数依赖R的属性A(记作A->B),当且仅当对于R的两个元组,如果它们的A值相等,则它们的B值相等。
在任何实例上,每个A的值仅惟一地有一个B的值与之对应。
实际上,属性A和B是可以组合的。
考虑以下设计欠佳的关系模式:
报告(学号,课程号,课程,教师名,教室号,成绩)
元组表示学生S取得C号课程的分数M,课程名称是T,该课程由教师L在R号教室上课。
假定每门课程只有一个教师,每个教师有一个教室。
这个关系存在的一些函数依赖如下:
学号,课程号->成绩
即一对(学号,课程号)值,正好存在成绩的一个值。
课程号->课程课程号->教师名课程号->教室
对于课程号的一个值,正好存在课程、教师名、教室的一个值。
教师名->教室号
每个教师正好有一个对应的教室号值。
属性成绩被称为完全函数依赖于键,这是由于它依赖于组合对的键属性学号和课程号,但不依赖于其中的任何一个。
如果关系R的属性B函数依赖于A,而不函数依赖于A的任何一个真子集,那么,属性B完全函数依赖于属性B。
属性课程、教师名、教室号被称为部分函数依赖于健,这是由于它们仅依赖于课程号,而不依赖于学号。
属性教室号被称为传递依赖于课程号,这是由于它依赖于教师名,而教师名又依赖于课程号。
关系模式中的这种函数依赖的部分性和传递性在处理数据库时会引起一系列的问题。
因此,在实现之前,必须把它们清除掉。
第二范式
数据库被称为第二范式(2NF),如果它是第一范式(1NF),而且每一个非主属性完全函数依赖于键。
前述定义的报告不是2NF,在数据处理时会引起一系列问题,这是因为:
(1)倘若希望在数据库中插入新课程的细节,在至少有一个学生注册之前才能够执行(不可以在主属性学号上有空值)。
类似地,如果希望插入一个新教师的细节及其教室号码,在他被安排上课而且至少有一个学生在这个课程注了册后,才能执行。
(2)倘若想把课程361的名称由《数据库技术》改成《数据库系统》,那么,必须查找有课程号的这个值的每一个元组,而且全部更新它们,其实,有多少学生选修这门课程,就会有多少个元组。
(3)倘若选修课程361的每个学生放弃该课程,除了删除相应
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 毕业论文 指导 资料