企业资产管理系统-论文-学位论文.doc

大连交通大学信息工程学院
毕业设计(论文)任务书

题 目 企业资产管理系统

任务及要求：　
1.设计（研究）内容和要求　
任务：
1、 调查企业资源当前技术的发展近况，完成实习报告，字数不少于3000，第三周交给指导老师。
2、 结合自己实习情况安排进度，填写进度计划表，第二周完成后交给指导老师签字，并严格执行。
3、 按照软件工程思想，独立完成系统的设计和程序开发，完成代码估计2000行左右。
4、 用Java技术实现各类信息的管理和查询。
5、 程序简洁，算法可行，运行情况良好。

要求：
1、 每周和指导老师至少见面沟通一次，回报课题进展情况，接受老师询问。
2、 接到任务书后，查阅与题目及专业相关的外文资料进行翻译，要求不少于10000个外文字符，译出汉字不得少于3000，于第四周交给指导老师审阅。
3、 毕业设计第13周完成毕业论文的装订，并由指导老师评阅。论文要求12000字以上，包括综述、系统总体设计、系统实现、性能分析、结论等。
4、 教学第13周通过中软及教研室组织进行软件验收，验收时要提供软件使用说明书。
5、 于第13周提出毕业答辩申请并签字。
6、 第14 周答辩，要求制作PPT
2.原始依据
通过大学几年的学习，已经学习了诸如C++、JavaBean、数据结构、java、oracle等多门程序设计语言和网络等基础知识和专业知识，学生有能力而且可以独立完成小中型项目的设计与开发。学校现有设备和环境可以提供给学生实习和上机，而且具有专业老师可以指导学生。

3.参考文献
[1] 扬明.李勇平.北大青鸟 ACCP3.0.北京:北京大学出版社.2003
[2] [美]Craig Larman 著 译者:李洋 郑龑.UML和模式应用(原书第3版) .北京:人民邮电出版社.2004.9
[3] Dan Pilone.Neil Pitman.UML2.0技术手册（影印版）.南京:东南大学出版社. 2004.7
[4] 黄梯云.管理信息系统（3版）[M]．北京:高等教育出版社.2009
[5] 吕杨波.ASP从入门到精通[M].北京:清华大学出版社.2008
[6] 薛小龙.ASP模块开发大全[M].北京:电子工业出版社.2008
[7] B1Idley P J.The Future of the Multinational Enterprise [M].London: Macmillan.2007
[8] Dunning J H. International Production And The Multinational Enterprise [M]. London: George Allen And Unwin.2008
[9] 何丽红.基于ASP的网上购物系统[J].中国高新技术企业.2009（2）
[10] 刘瑞新.Delphi数据库开发毕业设计指导及实例.[M]—北京：机械工业出版社.2005.3

　指导教师签字：
教研室主任签字：
　　　　　　　　　　　　　　　　　　　　　　　　 年 月 日
大连交通大学信息工程学院
毕业设计(论文)进度计划与考核表
学生姓名
宫立婷
专业班级

计算机科学与技术08-1班
指导教师
刘品
于林林
本课题其他人员
无
题　目
企业资产管理系统
日　期
计划完成内容
完成情况
指导老师检查签字
第1周
查找资料、完成任务书、提交进度表

第2周
补充相应资料、完成调研报告、完成英文翻译

第3周
系统需求分析阶段

第4周
系统概要设计阶段

第5周
系统详细设计阶段

第6周
编码实施、完成论文初稿

第7周
完成系统编码实施、系统编码调试

第8周
代码测试、提交论文初稿

第9周
完成系统编码调试、完善毕业论文

第10周
完成撰写毕业设计论文编写及代码测试

第11周
完成论文终稿

第12周
提交毕业论文终稿及代码

第13周
提交毕业论文成果资料

第14周
毕业论文答辩

指导教师签字：　　　　　　　　　　　 年 月 日

注：“计划完成内容”由学生本人认真填写，其它由指导教师考核时填写。

大连交通大学信息工程学院
毕业设计(论文)外文翻译

学生姓名 宫立婷 专业班级 计算机08-1班
指导教师 刘品 于林林 职 称 高工 讲师
所在单位 信息科学系计算机教研室
教研室主任 宋丽芳

完成日期 2012 年 4 月 13 日

Database Management System

You know that a data is a collection of logically related data elements that may be structured in various ways to meet the multiple processing and retrieval needs of organizations and individuals. There’s nothing new about data base-early ones were chiseled in stone, penned on scrolls, and written on index cards. But now database are commonly recorded on magnetically media, and computer programs are required to perform the necessary storage and retrieval operations.
The system software package that handles the difficult tasks associated with created, accessing, and maintaining database records is in a DBMS package establish an interface between the database itself and the users of the database. (These users may be applications programmers, managers and others with information needs, and various OS programmers.)
A DBMS can organize, process, and present selected data elements from the database. This capability enables decision makers to search. Probe, and query data contents in order to extract answers to nonrecurring and unplanned questions that aren’t available in regular reports. These questions might initially be vague and/or poorly defined, but people can “browse” through the database until they have the needed information. In short, the DBMS will “manage” the stored data items and assemble the needed items from the common database in response to the queries of those who aren’t programmers. In a file-oriented system, users needing special information may communicate their needs to a programmers, who, when time permits, will information. The availability of a DBMS, however, offers users a much faster alternative communications patch (see figure).
Special, direct, and other file processing approaches ate used to organize and structure data in single files. But a DBMS is able to integrate data elements from several files to answer specific user inquiries fir information. This means that the DBMS is able to structure and tie together the logically related data from several large files.
Logical structures. Identifying these logical relationships is a job of the data administrator. A data definition language is used for this purpose. The DBMS may then
Employ one of the following logical structuring techniques during storage access, and retrieval operation: list structures, hierarchical (tree) structures, and network structures, relational structures.
1. List structures. In this logical approach, records are linked together by the use of pointers. A pointer is a data item in one record that identifies the storage location of another logically related record. Records in a customer master file, for example, will contain the name and address of each customer, and an account number identifies each record in this file. During an accounting period, a customer may maintain an invoice file to reflect these transactions. A list structure could be used in this situation to show the unpaid invoices at any given time. Each in the customer file would point to the record location of the first invoice for that customer in the invoice file. This invoice record, in turn would be linked to later invoice for the customer. The last invoice in the chain would be identified by the use of a special character as a pointer.
2. Hierarchical structures. In this logical approach, data units are structured in multiple levels that graphically resemble an “upside down” tree with the root at the top and the branches formed below, there’s a superior-subordinate relationship in a hierarchical structure. Below the single-root data component are subordinate elements (or one) has only a single owner. Thus, as we see in figure, a customer owns an invoice, and the invoice has subordinate items. The branches in a tree structure are not connected.
3. Network structures. Unlike the tree approach, which dose not permit the connection of branches, the network structure permits the connection of the nodes in a multidirectional manner. Thus, each node may have several owners and may, in turn, own any number of other data units. Data, management software permits the extraction of the needed information from such a structure by beginning with any record in a file.
4. Relational structures. A relational structure is made up of many tables. The data are stored in the form of “relations” in these tables. For example, relation tables could be established to link a college course with the instructor of the course, and with the location of the in order to find the name of the instructor and the location of the English class, the course/instructor relation is searched to get the name, and the course/location relation is searched to get the class location. Many other relations are of course, possible. This is a relatively new database structuring approach that’s expected to be widely implemented in the future.
5. Physical structure. People visualize or structure data in logical ways for there
Own purposes. Thus, records R1 and R2 may always be logically linked and processed in sequence in one particular application. However, in a computer system it’s quite possible that these records that are logically contiguous in one application are not physically stored together. Rather, the physical structure of the I/O and storage devices techniques used, but also on the different logical relationships that users may assign to the data found on R1 and R2. For example, R1 and R2 may be records of credit customers who have shipments send to the same block in the same city every two weeks. From the shipping department manager’s perspective, then, R1 and R2 are sequential entries on a geographically organized shipping report. But may be identified, and their accounts may be processed, according to their account numbers which are widely separated. In short, then the physical location of the stored records in many computer-based information systems is invisible to users.
During the past five years, Microsoft has promoted Data Access Objects (DAO), and then Remote Data Objects (RDO), and now ActiveX Data Objects (ADO) as the primary data access technology for Visual Basic developers. It seems that Microsoft has been pushing a different data access technology with each successive version of Microsoft Visual Studio. Today, new versions of ADO are available on Microsoft's Web site and ship with other products and technologies, such as Microsoft Windows 2000, Microsoft Windows NT 4 Service Packs, Microsoft Internet Explorer versions 3 and later, Microsoft SQL Server 6.5 Service Pack 5 and SQL Server 7, Microsoft Office 2000, and even Microsoft Expedia Streets & Trips 2000.
One of the goals of ADO is to simplify data access. ADO is built upon some fairly complex technologies—OLE DB and ODBC (open database connectivity)—and is designed to allow you to programmatically access and modify data stored in a wide variety of databases. This broad reach is a departure from previous data access technologies. For the sake of comparison, let's take a quick glance at ADO's predecessors: DAO and RDO.
Data Access Objects
DAO was originally designed to interact with Microsoft Access databases. Although you can use DAO to access SQL Server and Oracle databases, many developers complain about DAO's performance with these large database systems. Others complain that DAO doesn't permit programmers to access some of the richer, more powerful features of SQL Server and Oracle, such as output and return parameters on stored procedures.
One of my coworkers likes to say that using DAO to work with an Oracle database is like performing brain surgery on you…without anesthetics…while wearing oven mitts. Extreme? Yes—but he does have a point. DAO is tuned to work with desktop databases, not client/server databases. Frustrated by DAO's performance and access limitations, developers who wanted to work with SQL Server and Oracle databases generally sought other options.
Remote Data Objects
Microsoft provided another option in RDO, which originally released with Visual Basic 4 Enterprise Edition. RDO's object model closely resembles the hierarchy of structures in the ODBC API. Programmers found that RDO provided much faster access to client/server database systems, such as SQL Server and Oracle, than DAO did. Although those familiar with the ODBC API quickly learned how to work with the RDO object model, developers lacking experience with that API, such as those who had been using DAO, found the RDO technology difficult to use.
The object model itself wasn't the problem for most programmers learning RDO: the nuances inherited from the ODBC API posed the greatest obstacles. Suddenly, programmers had to bone up on cursors and bookmarks. They had to learn many of the ins and outs of specific database systems. Does the error message "The connection is busy with results from another hstmt" ring any bells out there? If you try to do the impossible on an ODBC connection to your database, RDO won't save you. Instead, you'll get that error. DAO hid the problem from you by automatically creating another connection to your database to perform the action you requested.
Another challenge that RDO posed for programmers accustomed to writing DAO code was that RDO lacked many of DAO's features, such as sorting, searching, and filtering. Other DAO functionality unavailable in the RDO world includes data definition language (DDL) interfaces to ODBC API functions such as Create Table and Create Field.
Best of Both Worlds: ActiveX Data Objects
Programmers clamored for a data access technology that combined the simplicity and relative ease of use of DAO with the speed, power, and control of RDO. Initially introduced as part of the Microsoft Internet Information Server 3 package, ADO was intended to be all things to all people. Of course, such lofty goals are rarely fulfilled.
While the initial release of ADO lacked many of Rod’s features, I believe that ADO 2.0 offered comparable functionality. Certain RDO features, such as mixed cursors, have yet to be implemented in ADO, but these features are few and far between. In fact, I'm at a loss to name a single significant feature available in RDO that was not available in ADO 2.0 in one form or another. (I'm sure someone will tell me otherwise; a great way to find such features is to make a statement like that in a book like this.)
With the release of version 2.1, ADO and its supporting libraries began offering nearly all features available in DAO. DDL libraries were added to ADO in version 2.1 to provide functionality similar to functions available with DAO, such as Create Table, Create Field, and Create Index. Microsoft Jet and Replication Objects (JRO) in ADO 2.1 offers much of the Jet-specific functionality available via the DB Engine object in DAO. ADO 2.1 also added functionality to simplify the retrieval of newly generated identity values. ADO 2.5 adds no new functionality to more closely match the capabilities of DAO and RDO, because perhaps the only place where ADO lags behind DAO is in its searching and filtering capabilities.
So ADO has most of the functionality of RDO and DAO as well as many helpful features not available in previous data access technologies.
Database Management
There are problems with traditional data management. A more subtle problem is data dependency. When a problem’s logic is tied to it’s physical data structure, changing that structure will almost certainly require changing the program. As a result, programs using traditional access methods can be difficult to maintain. The solution to both problems id often organizing the data as a single, integrated database. The task of controlling access to all the data can then be concentrated in a centralized database management system.
How dose the use of a centralized database solve the data redundancy problem? All data are collected and stored in a single place; consequently, there is one and only one copy of any given data element. When the value of an element (an address, for example) changes, the single database copy is corrected. Any program requiring access to this data element gets the same value, because there is only one value.
How dose a database help to solve the data dependency problem? Since the responsibility for accessing the physical data rests with the database management system, the programmer can ignore the physical data structure. As a result, programs tend to be much less dependent upon their data, and are generally much easier to maintain. Expect the trend toward database management to continue.

数据库管理系统

众所周知，数据库是逻辑上相关的数据源集合。这些数据源可以按照不同的结构组织起来，以满足单位和个人的多方面的要求。数据库本身并没有什么新东西——早期的数据库凿在石头上，记在名册上，以及写在索引卡中。而现在普遍记录在可磁化的介质上，并