Network Working Group D. Mitton Request for Comments: 2882 Nortel Networks Category: Informational July 2000 Network Access Servers Requirements:
Extended RADIUS Practices
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract
This document describes current practices implemented in NAS products that go beyond the scope of the RADIUS RFCs 2138, 2139 [1,2]. The
purpose of this effort is to give examples that show the need for
addressing and standardizing these types of ad-hoc functions. Since
many of these features require a matching server support component,
the ability to deploy and manage interoperable NAS and AAA server
products is severely hindered.
These practices are documented here to show functions that are
obviously desired in developing future AAA protocols for NAS
deployment.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Disclaimers . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Presentation . . . . . . . . . . . . . . . . . . . . . . 3
2. Attribute Usage . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Attribute Conflicts . . . . . . . . . . . . . . . . . . . 4
2.2. Attribute Value Conflicts . . . . . . . . . . . . . . . . 4
2.2.1 Vendor Specific Enumerations Proposal . . . . . . . . . . 4
2.3 Vendor Specific Attribute Usage . . . . . . . . . . . . . 5
2.3.1 VSAs in use by clients: . . . . . . . . . . . . . . . . . 5
2.3.2 Clients that support multiple Vendors: . . . . . . . . . 5
3. Attribute Data Types . . . . . . . . . . . . . . . . . . . 6
4. New Messages . . . . . . . . . . . . . . . . . . . . . . . 7
5. Additional Functions . . . . . . . . . . . . . . . . . . . 7
5.1 Password Change . . . . . . . . . . . . . . . . . . . . . 8 Mitton Informational [Page 1]
5.2 Authentication Modes . . . . . . . . . . . . . . . . . . . 8
5.3 Menus . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.4 Pseudo Users . . . . . . . . . . . . . . . . . . . . . . . 9
6. Resource Management . . . . . . . . . . . . . . . . . . . . 9
6.1 Managed Resources . . . . . . . . . . . . . . . . . . . . . 9
6.2 Resource Management Messages . . . . . . . . . . . . . . . 10
6.3 Concurrent Logins . . . . . . . . . . . . . . . . . . . . . 10
6.4 Authorization Changes . . . . . . . . . . . . . . . . . . . 11
7. Policy Services . . . . . . . . . . . . . . . . . . . . . . 11
8. Accounting Extensions . . . . . . . . . . . . . . . . . . . 12
8.1 Auditing/Activity . . . . . . . . . . . . . . . . . . . . . 12
9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . 12
10. Security Considerations . . . . . . . . . . . . . . . . . . 13
11. Implementation Documents . . . . . . . . . . . . . . . . . 13
11.1. Clients . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.2. Servers . . . . . . . . . . . . . . . . . . . . . . . . . 14
12. References . . . . . . . . . . . . . . . . . . . . . . . . 14
13. Author’s Address . . . . . . . . . . . . . . . . . . . . . 15
14. Full Copyright Statement . . . . . . . . . . . . . . . . . 16
1. Introduction
The RADIUS Working Group was formed in 1995 to document the protocol of the same name, and was chartered to stay within a set of bounds
for dial-in terminal servers. Unfortunately the real world of
Network Access Servers (NASes) hasn’t stayed that small and simple,
and continues to evolve at an amazing rate.
This document shows some of the current implementations on the market have already outstripped the capabilities of the RADIUS protocol. A quite a few features have been developed completely outside the
protocol. These features use the RADIUS protocol structure and
format, but employ operations and semantics well beyond the RFC
documents.
I learn of the details of these functions from reading industry
manuals and often have to respond to them in competive bid
specifications. As they become deployed in the field, they gather
the force of de-facto standards.
Because they have been done outside scope of the RFCs, they are
vendor specific, and introduce significant problems in offering an
interoperable product.
Mitton Informational [Page 2]
1.1. Disclaimers
The data and numbers in this document have been gleaned from public
sources and vendor documents along the way. Actual implementation of many these features and variation from the documentation has not been confirmed.
This document is a snapshot of known practices at the time of
writing. It is not intended to standardize these practices here, or keep this document current, beyond initial publication. While some
detailed information is given, it is not the purpose of this document to directly or sufficiently describe the functions mentioned to the
level of a complete functional specification.
The author has not transcribed copyrighted material, and is not aware of whether any of these practices have of intellectual property
restrictions.
Any numeric assignments or functional operations are subject to
change by vendors without notice. I would appreciate any direct
input, preferably first hand, from implementors.
1.2. Presentation
Without any easy organization for the material, information is
arranged in a simple taxonomy from bottom-up complexity:
- Attribute Usage
- Attribute Data Types
- Message Codes
- New Operations
2. Attribute Usage
The RADIUS RFCs define attribute type ranges and specific attribute
definitions.
- There are about 70 defined RADIUS attributes:
- Values 192-223 are reserved for experimental use
- Values 224-240 are reserved for implementation-specific use
- Values 241-255 are reserved and should not be used.
Mitton Informational [Page 3]
Attribute 26 was defined to be the Vendor Specific Attribute (VSA)
with further internal structure to allow vendor expansion.
2.1. Attribute conflicts
In practice attributes 92-255 are in use by a vendor. And another
vendor also use attributes in the 90-104 range and conflicts with
this usage.
To deal with these issues, server vendors have added vendor specific parameters to their client database files. The administrator has to indicate the vendor type of NAS along with the client IP address and secret, so that the server can disambiguate the attribute usage.
One server has a single large vendors file to describe the mapping
all attributes to an internal format that retains the vendor id.
Another server implementation uses multiple dictionaries, each
indexed to a NAS and Vendor Model definition list.
2.2. Attribute Value Conflicts
Adding additional attributes may be more trouble than necessary for
simple features. Often existing RADIUS attributes could be extended with additional values (particularly attributes that are enumerated
choices). But in doing such there is no way to guarantee not
conflicting with other vendor’s extensions.
2.2.1. Vendor Specific Enumerations proposal
One proposed solution to this problem was Vendor Specific
Enumerations (VSEs). That is to imbed the vendor’s management ID in the numeric value (ala VSAs) which would to divide up the attribute
value space. This technique has not seen any acceptance by the
working group or other vendors, however, the vendor did accomplish
the goal of not conflicting with working group additions or other
vendor values.
Example dictionary of VSE values:
VALUE Service-Type VSE-Authorize-Only 0x06300001
VALUE Acct-Status-Type VSE-User-Reject 0x06300001
VALUE Acct-Status-Type VSE-Call-Reject 0x06300002
VALUE Acct-Status-Type VSE-IPCP-Start 0x06300003
VALUE Acct-Status-Type VSE-IPXCP-Start 0x06300004
VALUE Acct-Status-Type VSE-ATCP-Start 0x06300005
VALUE Acct-Status-Type VSE-Accounting-Restart 0x06300006
VALUE Acct-Status-Type VSE-Accounting-Shutoff 0x06300007
Mitton Informational [Page 4]
VALUE Acct-Status-Type VSE-Tunnel-Start 0x06300008
VALUE Acct-Status-Type VSE-Tunnel-Stop 0x06300009
VALUE Acct-Status-Type VSE-Tunnel-Reject 0x0630000a
VALUE Acct-Status-Type VSE-Tunnel-Link-Start 0x0630000b
VALUE Acct-Status-Type VSE-Tunnel-Link-Stop 0x0630000c
VALUE Acct-Status-Type VSE-MP-Start 0x0630000d
VALUE Acct-Status-Type VSE-MP-Stop 0x0630000e
VALUE Acct-Status-Type VSE-Line-Seizure 0x0630000f
VALUE Acct-Status-Type VSE-Rlogin-Start 0x06300010
VALUE Acct-Status-Type VSE-Rlogin-Stop 0x06300011
2.3. Vendor Specific Attribute Usage
Because attribute 26 Vendor Specific Attributes (VSAs) came late in
the RADIUS working group development, there were some server
implementations that were late to support them. Today, there are
several leading implementations of clients that make extensive use of VSAs. What’s unfortunate is that there is also several different
formats of VSAs implemented. This is because the RFC suggested
format does not support more than 256 attributes.
2.3.1. VSAs in use by some clients:
At the time this document was written, the following had be observed: - Microsoft: several for MS-CHAP authentication support [9]
- ACC: 42 [10]
- Nortel(Bay): about 60 VSAs and 16 VSEs
- Nortel(Aptis): about 60 VSA: 20 1-byte, ?130 4-byte header.
Aptis VSAs have shifted from a regular format to a 4-byte header format, due to the large number of attributes implemented.
- 3Com (USR): about 130
USR VSAs are different than the format suggested in RFC 2138.
They have a 4 byte type field and have no internal length.
Some vendors that did not initially use VSAs, have shifted in later
releases VSA usage as a configuration option.
2.3.2. Clients that support Multiple Vendor Attributes
Now that MS-CHAP RADIUS attributes have been published in RFC 2548
[9] as Microsoft VSA attributes, it will become typical that for NAS clients that support MS-CHAP authentication to process several
Mitton Informational [Page 5]
different vendor VSA types. This has implications for RADIUS servers that filter or "prune" return attributes based on the vendor
make/model of the NAS client.
One NAS implementation can receive up to three different vendor
specific attribute sets, but will only send attributes according to
the "mode" that has been configured by the operator. This allows it
to fit into environments where the customer has become dependent on a particular set of RADIUS attributes, and allows the NAS to "drop-in" without server attribute changes.
There is another NAS that supports 3 vendor attributes sets
concurrently. That is, it will normally use a combination of
different vendor VSAs in return profiles from the server. This was
done to support a superset of competing vendor’s extensions, as well as it’s own, and include an extensions from a sister product.
3. Attribute Data Types
The base RFCs define only has 4 basic data types:
- integer, 32 bit unsigned
- string, 1-253 bytes, counted.
- ipaddr, 32 bit IPv4
- date, 32 bit Unix format.
Since then, various variations have been added:
The tunnel authentication document [6] adds an optional compound
"tag" byte to tunnel attributes. These are a single byte prepended
to the data field in order to support sets of attributes to be
returned. The byte value must be in the range 01-3F hex or it is
considered to be data.
Note that there is no native support for IPv6 addresses. In fact IPv6 support is missing in some fixed message components too.
There have been special attribute types created within servers. For packet filters, the format called "abinary" was created. The user
enters an ASCII string filter description in the user profile, but
the server parses it into a binary string before passing it to the
NAS. This lowers the complexity of the NAS parser. Also a
"phonestring" server data type allows additional data type checking
at the entry application.
Mitton Informational [Page 6]
4. New Messages
A number of new message types have been introduced by various parties over time. The base specification has 6, vendors have added 26.
These fall into a number of categories which are described in the
next section below. Some of these messages are actually used between the RADIUS server and some other resource server, using a RADIUS-like protocol to implement new functions.
6 Accounting Status
(now Interim Accounting [5])
7 Password Request
8 Password Ack
9 Password Reject
10 Accounting Message
21 Resource Free Request
22 Resource Free Response
23 Resource Query Request
24 Resource Query Response
25 Alternate Resource Reclaim Request
26 NAS Reboot Request
27 NAS Reboot Response
29 Next Passcode
30 New Pin
31 Terminate Session
32 Password Expired
33 Event Request
34 Event Response
40 Disconnect Request
41 Disconnect Ack
42 Disconnect Nak
43 Change Filters Request
44 Change Filters Ack
45 Change Filters Nak
50 IP Address Allocate
51 IP Address Release
5. Additional Functions
These are operations performed using RADIUS extensions and additional messages types.
Mitton Informational [Page 7]
5.1. Password Change
Remotely requested password change operations were described and
proposed, but rejected by the working group. None the less, the
feature is still deployed in a number of products.
Message types:
- Password Request
- Password Ack or Reject
5.2. Authentication Modes
Additional message types have been added to negotiate passcode
changes for token card servers.
- Next Passcode
- New PIN
- Password Expired
They allow the NAS or RADIUS server negotiate passcode changes with
an external security server.
5.3. Menus
At least two vendors have built menuing interaction systems for use
with terminal dial-ins.
One implementation uses the Reply-Message string as the menu text to be displayed, and the State attribute to keep track of the place in
the menu. The menu is displayed using the Access-Challenge message. The response is encoded in the User-Password field like an ordinary
challenge sequence would.
Some RADIUS clients have problems with this because they cannot
handle long or multiple Reply-Message attributes that may have
embedded carriage returns and line-feeds. The new Echo attribute
should also control echo behavior on the menu response. Use of the State attribute to keep track of a Challenge sequence is also
standard behavior.
Another implementation uses two vendor attributes (VSA-Menu-Item, and VSA-Menu-Selector as well as VSA-Third-Prompt) to convey this
information. This implementation is vendor specific.
Mitton Informational [Page 8]
5.4. Pseudo Users
One client implementation takes advantage of your vanilla RADIUS
server’s ability to be used as a remote database server. By using
some well-known, implementation specific, strings for Username and
Password attributes, the NAS can request information from the server, such as: Static IP routes, Static IPX routes, or the Message of the Day.
These are called pseudo-user requests, because they use a user entry with this manufactured name, for purposes other than authentication. Another client also uses a pseudo-user technique for resolving
unknown Filter-ID(11) values. An Access-Request message is sent to
the RADIUS server with the Filter-ID as the Username value, the
password is a known string, and the Service-Type is VSE-
Authorization-Only. The response must also be of the same Service-
Type, or the response will be ignored. The responding profile should contain the IP-Filter VSA attributes that will define the desired
filter.
It should be noticed that pseudo-user profiles could be a security
problem if a specific or operationally invalid Service-Type is not
attached to the profile. The client should test for this returned
value, to prevent normal dial-in users from gaining access via this
profile.
6. Resource Management
Authorized sessions may need to be allocated additional dynamic
resources in order to perform their services. The most typical is IP addresses. The allocation may want to be delayed until needed or
coordinated on a scale independent of the RADIUS server. Additional messages may be used to allocate and free these resources. The
RADIUS server may proxy these requests to another server.
Examples: Certain servers can allocate addresses local to the NAS or use an outboard address server. Other servers have an internal
address pool capability, which will fill in the Framed-IP-Address
attribute with an assigned value based on pool selected.
6.1. Managed Resources:
Resources managed include: IP Addresses, Concurrent Logins, Dial-in
Port allocation policies, Tunnel limits and load distribution.
Mitton Informational [Page 9]
There are several different types of implementation techniques:
- Explicit request/free resource requests
- Monitor usage with deamons watching the state
- Explicit messages to a state deamon
- Monitor Accounting messages for state changes
6.2. Resource Management Messages
Messages used for resource management
- IP Address Allocate
- IP Address Release
- Resource Request
- Resource Response
- Resource Free Request
- Resource Free Response
- Resource Reclaim Request
- NAS Reboot Request/Response
These messages are used to allocate and free resources for a NAS from a centralized server. These mechanisms allows the service provider
better administrative control than some automated LAN services, which don’t have policy inputs or controls.
6.3. Concurrent Logins
The RADIUS protocol was designed to allow stateless servers. That
is, servers that don’t know the status of the active sessions.
However, it is very important for many service providers to keep
track of how many sessions a given user may have open, and
accordingly disallow access.
There are several different techniques used to implement login limits on a RADIUS environment. Some vendors have build NAS monitoring
tools either into their RADIUS servers, either directly or as
auxiliary deamons, that can check the session status of the
controlled NASes by SNMP or proprietary methods.
Other vendors monitor the RADIUS accesses and accounting messages and derive state information from the requests. This monitoring is not
as reliable as directly auditing the NAS, but it is also less vendor specific, and can work with any RADIUS NAS, provided it sends both
streams to the same server.
Some of the approaches used:
Mitton Informational [Page 10]
- SNMP commands
- Telnet monitor deamon
- Accounting monitor
6.4. Authorization Changes:
To implement an active changes to a running session, such as filter
changes or timeout and disconnect, at least one vendor has added a
RADIUS "server" to his NAS. This server accepts messages sent from an application in the network, and upon matching some session
information, will perform such operations.
Messages sent from Server to NAS
- Change Filter Request
- Change Filter Ack / Nak
- Disconnect Request
- Disconnect Response
Filters are used to limit the access the user has to the network by
restricting the systems and protocols he can send packets to. Upon
fulfilling some registration with an authorization server, the
service provider may wish to remove those restrictions, or disconnect the user.
7. Policy Services
Some vendors have implemented policy servers using RADIUS as the
control protocol. Two prominent Policy Managers act as RADIUS proxy filters and use RADIUS messages to deny access to new sessions that
exceed active policy limits.
One implementation behaves like a RADIUS proxy server, but with a
policy process governing it’s forward decisions. Typically a pre-
authentication message (like the new RADIUS draft Service-Type =
CallCheck) is emitted by the NAS upon call arrival. This message will contain only the Dialed-Number information in the Username field.
The server receives the Access-Request messages and processes them
against it’s knowledge of the network state and the provisioned
policies.
An Access-Accept will be returned to the system to accept the call,
and many also contain dynamic policy information and Virtual POP
specific default parameters. When the real PPP authentication is
engaged, the proxy will forwards the Access-Request to a RADIUS
server, if this session was approved at pre-auth. It can also
process Access-Requests that were not preceded by a pre-auth
exchange, and use the Username field for information about the
Mitton Informational [Page 11]
desired realm, in it’s policy evaluation.
The other implementation performs a similar operations. It uses VSAs in the Access-Request to distinguish pre-authentication message
types.
8. Accounting Extensions
Traditional Accounting only records session starts and stops which is pretty boring. Additional session information reporting can be added easily which gives a better picture of operation in use as they
happen. Some event types are listed below.
8.1. Auditing/Activity
- Call or Modem Starts, Stops
- Tunnel Starts, Stops
- Tunnel Link Starts & Stops
- Admin changes
These events if monitored by a stateful server can be used to gather information about the usage of the network on a user/session basis.
Information about when a particular user entered the network is more relevant to network service management than attempting track
backwards from low level IP address flows. Useful information about port usage across a range of NASes allows service provider to quickly find problem areas or users.
Information about call failures, successes, and quality are also
deemed important many service providers.
Extending RADIUS accounting is easy, it’s surprising that more
implementations have not been made in this area.
9. Conclusions
In real life RADIUS Servers are becoming rather complex software
implementations. They are often brokering authentication and
authorization to other authorities or repositories. Variants of
RADIUS protocol is often used as glue protocol for these type of
solutions.
Some of the solutions are kludges that could be cleaned up by better underlying services.
What this means to the implementor is that RADIUS as the RFCs
describe it is becoming less relevant. Many additional features
require matching client and server processing message processing. Mitton Informational [Page 12]
Without standardization of these functions we don’t have much
interoperability in the field and much effort is spent in reverse
engineering and reaction to unknown areas.
This memo is not a complete survey by any means. It is a
representative summary of practices that I am aware of at the time of writing. I still appreciate input from vendors or users on practices and details known, and particularly any reference material you can
pass me.
10. Security Considerations
This document documents known practices, and does not propose any
particular new protocols. Extensions to RADIUS protocols create new
security implications because of their functions go beyond those
considered in the RFCs. Some of these include:
- The ability to change passwords via a RADIUS exchange was
deliberately left out of the protocol by the working group,
because of security concerns.
- The Pseudo-User profiles and the Call-Check operation may allow
unintended access if static and well-know account names and
passwords are allowed to be used by regular interactive accounts. - Resource Management operations must be protected from denial of
service attacks.
- Client side authorization change exchanges need to be secured from attacks that could disconnect or restrict user services.
11. Implementation Documents
Information about the following implementations can be obtained from the respective owners. Most listed are available from the
manufacturer’s web site.
11.1. Clients:
- 3Com(USR) Total Control Hub
- Ericsson(ACC) Tigris
draft-ilgun-radius-accvsa-01.txt, Dec 1998
- Lucent(Ascend) MAX TNT
- Lucent(Livingston) Portmaster
- Nortel(Aptis) CVX 1800
- Nortel(Bay Networks) Versalar 5399/8000 Remote Access Controller
- Intel(Shiva)
Mitton Informational [Page 13]
11.2. Servers:
- Ericsson(ACC) Virtual Port Server Manager
- Funk Steel-Belted RADIUS
- Intel(Shiva) Access Manager
- Lucent(Ascend) Access Control
- Lucent(Ascend) NavisAccess
- Lucent(Ascend) Modified Livingston 1.16
- Lucent(Livingston) V2.01
- Lucent(Livingston) ABM
- Lucent Port Authority
- MERIT AAA Servers
- Nortel(Bay Networks) BaySecure Access Control
- Nortel Preside Radius
- Nortel CVX Policy Manager
12. References
[1] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2138, April
1997.
[2] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997.
[3] Rigney, C., Willens, S., Ruebens, A. and W. Simpson, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865, June
2000.
[4] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[5] Rigney, C., Willats, W. and P. Calhoun, "RADIUS Extensions", RFC 2869, June 2000.
[6] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and
I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, June 2000.
[7] Zorn, G., Aboba, B. and D. Mitton, "RADIUS Accounting
Modifications for Tunnel Protocol Support", RFC 2867, June 2000.
[8] Aboba, B. and G. Zorn, "Implementation of L2TP Compulsory
Tunneling via RADIUS", RFC 2809, April 2000.
[9] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC
2548, March 1999.
[10] Ilgun, K., "RADIUS Vendor Specific Attributes for ACC/Ericsson
Datacom Access", Work in Progress.
Mitton Informational [Page 14]
13. Author’s Address
David Mitton
Nortel Networks
880 Technology Park Drive
Billerica, MA 01821
Phone: 978-288-4570
EMail: dmitton@https://www.doczj.com/doc/2c11283478.html,
Mitton Informational [Page 15]
14. Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Mitton Informational [Page 16]
图书馆管理系统可行性分析报告 1、引言 为了方便管理者与读者特提出开发此系统。 1.1 编写目的 从现在应用的技术方面、管理者和用户的操作方式方面研究图书馆管理管理系统的可行性和必要性。图书馆管理系统的实施，将很大程度上提高了图书馆信息资源的利用率，也使得读者能够更加方便的对图书进行个性化的管理。 1.2 项目背景 软件名称：图书馆管理系统 项目任务提出者：某图书馆馆长 开发者：计算机055 班（薛剑锋组）用户：图书馆工作人员及读者 1.3 参考资料 《实用软件工程》郑人杰清华大学出版社 《C＃HOW TO PROGRA》M H.M.Deitel P.J.Deitel 清华大学出版社 《数据库原理及其应用教程》黄德才科学出版社 2、可行性研究的前提 2.1 要求 功能：能够准确快速的记录图书的状态，实时了解图书是否被借、是否归还、是否借出超期等信息; 读者和管理人员可进行一些需要的操作. 性能：功能齐全，数据共享，操作简便，可靠性好，稳定快速，用户界面友好 输入/ 输出：英文和汉字输入、输出 安全与保密要求：不能轻易被破坏，不能让管理人员以外的人删改图书信息，不能让读者的私人信息外泄，不能让一些意外事故损害数据库信息。 完成期限：2008.5.29 2.2 目标 本系统要达到的目标有以下几点： 1> 能够存储一定数量的图书信息, 并方便有效的进行相应的书籍数据操作和管理，这主 要包括： 图书信息的录入、删除及修改。 图书信息的关键字检索查询。 图书的出借、返还和资料统计。 2> 能够对一定数量的读者进行相应的信息存储与管理，这其中包括： 读者信息的登记、删除及修改。 读者资料的统计与查询。 3> 能够提供一定的安全机制，提供数据信息授权访问，防止随意删改，同时提供信息备份 的服务。
板式换热机组技术规范书 一、概述 为满足中丝辽宁液体化学品物流项目办公楼辐射采暖需要，配套全自动板式快速换热定压机组。 二、现场条件 当地气象资料据1973年～1982年的营口鲅鱼圈韭菜坨子气象站(N40?18'，E122?05')气象观测资料统计，特征值如下: 1、气温 年平均气温 9.8 ℃ 极端最高气温 34.4 ℃ (1978年8月5日) 极端最低气温 -22.4℃ (1976年2月5日) 2、降水 年平均降水量549.9 mm 一日最大降水量204.7 mm (1975年7月31日) 3、雾况 年平均雾日为4.4 d。 4、风 仙人岛海区强风向是WNW、S，最大风速29.0m/s ;次强风向是N、NE ,其最大风速26.0m/s ;常风向为SSE ,频率17.28% ,次常风向为S ,频率13.94%。六级以上风频率16.62%。 5、地震烈度： 7度。 三、技术文件内容 1、供货范围及性能参数 1．1供货范围 供货范围表
1．3 性能参数 1)1台板式换热器（传热板片由进口304不锈钢板组成，使用进口三元乙丙烯橡胶 密封,板片厚度0.5mm）； 2)板换负荷为215KW，T1＝95/70℃，P1＝1.0MPa，一次侧流量7.4m3/h，T2＝45/35℃， P2＝1.0MPa，二次侧流量18.4m3/h； 3)两台循环水泵，一用一备，流量20m3/h，扬程 22m；厂家自带控制设备1套； 4)两台定压补水水泵，一用一备，流量1m3/h，扬程 15m；厂家自带控制设备1套； 5)定压值0.14MPa，低限压0.12MPa，高限压力0.36MPa； 6)DN40对夹式蝶阀 D373-16C 2个，DN65对夹式蝶阀 D373-16C 5个，DN50 橡胶 软接头 PN=1.6MPa 4个，DN32电动调节阀 PN=1.6MPa 1个，压力表组 PN=1.6 7套（铜制），双金属温度计 0~200℃ 5块。 7)定压罐 1个； 8)DN25 安全阀 PN=0.6MPa 2、执行的规范及技术规定 货物应符合设计要求及国家规范、图集要求包括但不限于下述项目： 《建筑给水排水及采暖工程施工质量验收规范》GB50242-2002 《低压成套开关设备和控制设备空壳体的一般要求》GB/T20641-2006 《低压成套开关设备和控制设备第1部分：型式试验和部分型式试验成套设备》GB7251.1-2005 《低压成套开关设备和控制设备智能型成套设备通用技术要求》GB/T7251.8-2005 《低压开关设备和控制设备》 GB14048.1～.16系列标准。 《低压固定封闭式成套开关设备》JB/T 5877-2002 《低压系统内设备的绝缘配合第1部分：原理、要求和试验》GB/T16935.1-2008 《低压系统内设备的绝缘配合第5部分：不超过2mm的电气间隙和爬电距离的确定方法》GB/T16935.5-2008 《低压成套开关设备和电控设备基本试验方法》GB/T 10233-2005 《压力容器安全技术监察规程》质技监局锅发[1999]154号 《钢制压力容器》GB150-1998 《钢制压力容器封头》JB/T4746-2002 《补强圈钢制压力容器用封头》JB/T4736-2002 《平面、突面板式平焊钢制管法兰》GB/T9119-2000 《凸面板式平焊钢制管法兰》 JB/T81-1994 《承压设备无损检测第1部分通用要求》JB/T 4730.1-2005 《分（集）水器分汽缸》05K232 《民用建筑电气设计规范》JGJ16-2008 《公共建筑节能设计标准》GB50189-2005
一、 数据库设计 1．系统功能 图11.1图书借阅系统功能模块图 2. 数据需求 本系统的实体为“图书的进货”和“图书的销售”，它们之间通过“图书表”联系起来。具体的关系模式为： 出版社（出版社ID 、出版社） 图书（图书编号、分类、书名、作者、出版社．．．ID ．． 、单价、库存数量） 进货单（进货单ID （自动编号）、图书编号．．．．、进货日期（默认值为当前日期）、折扣、数量、金额（单价*数量*折扣）） 销售单（销售单ID （自动编号）、图书编号．．．．、销售日期（默认值为当前日期）、数量、折扣、金额（单价*数量*折扣）） 二、数据库和表设计 首先创建一个空数据库，然后根据需要创建数据库中的对象。 1. 创建空数据库 （1）在Access 窗口中单击“文件”|“新建”命令，打开“新建文件”任务窗格，选择“空数据库”。 （2）在“文件新建数据库”窗口的“文件名”文本框中输入数据库的名称“出版社”，选择数据库文件的保存位置，单击“创建”按钮。 2. 创建表 创建表需要先创建表的结构。根据本系统的逻辑结构设计，需要创建4张表：“出版社表”、“进货单”和“图书表”、“销售单”各表的结构如表11-1~11-4所示。 表11-1“进货单”表结构
表11-2“销售单”表结构 表11-3“图书表”表结构 表11-4“出版社表”表结构 3. 创建表之间的关系 表与表之间是通过相关字段进行连接来建立关系的，本系统中“出版社”表与“图书”表之间通过“出版ID ”字段建立了一对多的关系，“图书”表与“进货单”表通过“图书编号”字段建立了一对多的关系，“图书”表与“销售单”表通过“图书编号”字段建立一对多的关系。如图11.3所示。因为图书借阅系统表中的数据变动比较频繁，而且每张表的数据变动可能会影响到其它表中数据的正确性，因此创建表之间的关系时均要实施参照完整性、设置级联更新和级联删除。 图11.2创建表之间的关系 4. 录入数据 表中的数据可以在创建表和关系后录入，也可以在创建表时录入，但后者不能保证数据的参照完整性。录入数据后3张表的记录如图11.4~11.6所示。 图11.3“进货单”表的记录 图11.7“销售单”表的记录
某制造企业销售管理系统数据库设计 一、需求分析 （一）业务流程： 1、销售部统计商品信息，向客户发布商品信息。 2、客户根据销售部发布的商品信息，向销售部发送订单。 3、销售部将订单发送给主管部门审核。 4、主管部门对订单进行核对： （1）如果不批准订单，主管部门向客户发布不批准的信息； （2）如果批准，主管部门向客户发布批准的信息；销售部获取批准的订单，核对客户信息，登记新客户的基本资料或修改原有客户的基本资料，同时及时发布商品修改后的信息；生产部门接受订单，生产客户所需的商品，生产完成后，将发货单与商品一同发出。 5、客户确认发货单。 （二）数据流程图 员客客 填写上报核对确认 P3发货P2订单基本信息处理订单P1基本处理处理信息 客户信息员工信息 销售管理系统第一层数据流程图
第二层数据流程图： 核对员工客户上报填写 客P1.1员P1.2 户信息工信息 客户信息员工信息 P1 基本信息 客主管部 订单数审P2.P2.P2.理订核订预订订下
发货确认预订单商品信息订单 信贷状况客户 P2订单处理 （三）数据字典 1、订单号数据项可以描述如下 : 数据项 : 订单号 含义说明 : 唯一标识每张订单 别名 : 订单编号 类型 : 字符型 长度 : 4 取值范围 : 0000至 9999 取值含义 : 前 2 位标别所在地区，后 2 位按顺序编号 与其他数据项的逻辑关系 :唯一识别订单 2、商品信息是该系统中的一个重要数据结构，它可以描述如下 : 数据结构 : 商品信息 含义说明 : 是销售管理系统的重要数据结构，定义了销售商品的具体信息组成 : 产品号，产品名，单价，重量 3、数据流“订单数据可描述如下 : 数据流 : 订单数据 说明 : 客户选购商品所下的初始订单 数据流来源 : 客户 数据流去向 : 接受订单 组成 : 客户基本信息＋商品编号＋数量等 平均流量 : 5张／天 高峰期流量 : 100张／天 4、数据存储“订单可描述如下 : 数据存储 : 订单表 说明 : 记录每张订单的具体情况 流入数据流 : 订单处理 流出数据流 : …… 订单号，客户编号，产品，数量，单价等 : 组成 数据量 : 每年2000张 存取方式 : 随机存取 5、处理过程“接收订单尠可描述如下 : 处理过程 : 接收订单 说明 : 核准客户所下订单 输入 : 订单数据，商品信息，主管审批 输出 : 核对订单至主管部门，是否确认信息给客户 处理 : 接收到客户订购产品的初始订单后，根据商品信息以及客户以往
目录 1. 总述 1.1 项目介绍 1.2 供货范围 1.3 提交的资料 1.4 规范和标准 1.5 设计条件和设计要求 1.6 供货商的服务 1.7 经验和资格 2. 设备、材料 2.1 热交换器 2.2 水泵、电机 2.3 配件 2.4自动控制及测量设备 2.5保温 2.6 防腐保温 3. 压力试验 4. 包装、运输 附录1. 换热机组性能表
1. 总述 1.1 项目介绍 本文所指的板式换热机组将用于中海连湖花园供热工程中。 输送介质为水，一级网的工作温度：120/60℃，工作压力1.6MPa。二级网的工作温度：散热器采暖70/50℃，工作压力1.0MPa。 为了节省热力站维修和更换部件的费用，要求所供的板式换热机组应无故障运行至少3年。 1.2 供货范围 详见货物需求表。 供货商要保证换热机组的设计符合系统的要求，每个换热机组包括： ——泵组(含电机) ——板式换热器 ——必要的关断阀、过滤器、安全阀、调节阀、热量计 ——必要的连接管线 ——自动控制及测量设备 ——上述设备要求有一个共同的底座 ——试验的数据资料 ——设备装卸所需的专用工具 配套的板式换热器的单板换热面积由供货商确定，换热器的 板片数不得大于150片。为了备品备件的互换性，要求供货商所提供的单板换热器面积的规格不得超过三种。 供货范围应包括随机和两年运行所需的备件和易损件，其价格应包括在总投标标价中。 选用垫片为免粘式结构的板式换热器。 1.3 提交的资料
供货商需提交下述文件和图纸 ——技术文件和图纸清单 ——总装图纸 ——特殊工具清单 ——协作制造厂商清单 ——板式换热器的性能测试报告 ——水泵、电机的性能测试报告 ——换热机组的技术要求说明书及技术数据 ——设计选型计算结果 ——有关热交换器、泵、阀的选型计算的说明 ——热交换机组流程图 ——换热机组及配件的外形图 ——机组启动、运行说明 ——机组部件的维修说明 1.4规范和标准: 所供设备和材料的设计、制造、检查、试验等应满足下列规范和标准中的有关说明: CJ/T191 《板式换热机组》 GB 中国标准 IS0 国际标准组织 JIS 日本工业标准 ASME 美国机械工程师协会 IEC 国际电气技术委员会 IEEE 美国电气和电子工程协会 ISA 美国仪器、仪表协会 其它国际公认的与上述标准相当或更好的标准也可以接受。
图书馆管理系统数据库分析与设计 一、需求分析 用户的需求具体体现在各种信息的提供，保存，更新和查询，这就要求数据库结构能够充分满足各种信息的输入和输出。 在调查有关图书馆管理信息需求的基础上，我们主要考虑以下几方面的需求： 1 图书馆读者需求 2 图书馆管理人员需求 3 数据的可靠性和数据的输入，查询的方便快捷性 对图书馆管理信息系统分析后，我们将系统分为几个模块：借阅管理模块，读者信息管理模块，图书信息管理模块，系统管理模块。其主要功能如下： 1 借阅管理模块主要功能如下： ⑴为读者办理，修改，注销借书证，输入读者借书证基本信息等，定制读者的借阅权限 ⑵通过借书证查询图书信息，借出图书信息，借阅图书 ? 借出的图书不能在当天归还。 ? 每次借阅后读者最多可以续借一册图书一次。 ⑶读者还书程序及管理人员的处理程序： ? 对于超期的图书，图书管理系统将自动向读者电子邮箱中发一封电子邮件催还图 书。 ? 在本馆所借的文献资料，均应在规定的期限内按时归还。逾期不还者，将分别按 以下规定处理： 中文图书借阅：每册每天罚款0.2元。 新书借阅和外文图书借阅：每册每天罚款0.5元。 ? 在超期图书归还并缴清罚款之前，读者不可借阅图书；超期图书也不能续借。 2读者信息管理模块主要功能如下： ⑴读者基本信息的输入，如：编号，姓名、性别、类型（学生、教师等）、单位、电子信箱等 ⑵读者信息的修改，注销等功能 ⑶添加新的读者及其信息等 3图书信息管理模块主要功能如下： ⑴制作书籍的各种信息管理，如：所属藏馆，新旧书，中外文分类，名称、作者、ISBN号、出版地、出版社、出版时间、字数、单价、内容简介、所属分类号等 ⑵书籍信息的修改，新图书的入库管理和废弃图书信息的注销等 4系统管理模块主要功能如下： ⑴用户登陆 ⑵修改密码 ⑶添加，注销用户 二、E-R图 根据以上分析，我们先得出局部E-R图，然后得出整体E-R图： 1 借书系统E-R图
目次前言II 1 范围1 2 规范性引用文件1 3 定义2 4 型号编制2 5 基本参数3 6 一般规定3 7 板式换热器4 8 水泵4 9 变频器5 10 阀门及管路附件6 11 防腐与保温6 12 控制和测量设备6 13 材料及连接8 14 整机技术要求9 15 试验方法9 16 检验规则10 17 标志、包装、运输和贮存11 附录 A （规范性附录）板式换热机组工艺控制系统流程图13 附录 B （规范性附录）板式换热机组安装使用条件15 前言 本标准为首次制订的行业标准。 本标准主要对板式换热机组的整机提出需要控制的技术参数和质量指标，关于板式换热器的标准，应按照GB/T 16409《板式换热器》执行，本标准不再做特别规定。 按照本标准生产制造的板式换热机组符合《城市热力网设计规范》对热力站的规定。 本标准由建设部标准定额研究所提出。 本标准由建设部城镇建设标准技术归口单位城市建设研究院归口。 本标准起草单位：中国市政工程华北设计研究院 城市建设研究院 九圆热交换设备制造有限公司 兰州兰石鲁尔热力工程有限公司 APV中国有限公司 天津市换热装备总厂 清华同方人环工程公司 北京硕人时代科技有限公司 沈阳太宇机电设备有限公司 丹佛斯公司 本标准主要起草人：廖荣平、王淮、杨健、信岩、刘涤杰、王志峰、 王立新、王兵、俞华伟、史登峰、吴军、李滨涛。 1范围 本标准规定了板式换热机组（以下简称机组）的型号编制、基本参数、技术要求、试验方法．
和检验规则、标志、包装、运输和贮存要求。 本标准适用于供热、空调及生活热水等换热系统中使用的板式换热机组。 2规范性引用文件 下列文件中的条款通过本标准的引用而成为本标准的条款。凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本标准，然而，鼓励根据本标准达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本标准。GB/T 700 碳素结构钢 GB/T 707 热轧槽钢尺寸、外形、重量及允许偏差 GB/T 2887 电子计算机场地通用规范 GB 3096 城市区域环境噪声标准 GB/T 4942.2 低压电器外壳防护等级 GB/T 5117 碳钢焊条 GB/T 5657 离心泵技术条件 GB 7251.1 低压成套开关设备和控制设备第一部分：型式试验和部分型式试验成套设备 GB/T 8163 输送流体用无缝钢管 GB/T 9112 钢制管法兰类型与参数 GB/T 9787 热轧等边角钢尺寸、外形、重量及允许偏差 GB/T 12233 通用阀门铁制截止阀与升降式止回阀 GB/T 12237 通用阀门法兰和对焊连接钢制球阀 GB/T 12238 通用阀门法兰和对夹连接蝶阀 GB/T 12243 弹簧直接荷载式安全阀 GB 12459 钢制对焊无缝管件 GB/T 12668.2 调速电气传动系统第二部分一般要求低压交流变频电气传动系统额定值的规 定 GB 12706.1 额定电压35kV及以下铜芯、铝芯塑料绝缘电力电缆第1部分：一般规定 GB 12706.2 额定电压35kV及以下铜芯、铝芯塑料绝缘电力电缆第2部分：聚氯乙烯绝缘电力电缆 GB 12706.3 额定电压35kV及以下铜芯、铝芯塑料绝缘电力电缆第3部分：交联聚乙烯电力电缆 GB/T 12712 蒸汽供热系统凝结水回收及蒸汽疏水阀技术管理要求 GB/T 13384 机电产品包装通用技术条件 GB/T 16409 板式换热器 GB 50015 建筑给水排水设计规范 GB 50054 低压配电设计规范 GB 50174 电子计算机机房设计规范 GB 50236 现场设备、工业管道焊接工程施工及验收规范 JB/T 87 管路法兰用石棉橡胶垫片 JB/T 8680.2 三相异步电动机技术条件第2部分Y2-E系列(IP54)三相异步电动机(机座号80～280) JB/T 53058 管道式离心泵产品质量分等 CJJ 34 城市热力网设计规范 CJ 128 热量表 涂装前钢材表面处理规范SY/T 0407 3定义
商品销售系统数据库设计 1.数据库基本信息 1.1.数据库名称 ●DatebaseName: goodssaledb ●主逻辑名: goodssaledb ●日志逻辑名: goodssaledblog 1.2.数据库文件名 ●goodssaledb.mdf ●goodssaledb.ldf 1.3.用户名/密码 ●DBusername:sa ●DBpassword: 123 1.4.数据库管理系统(DBMS) ●Microsoft SQL Server 2008 1.5.设计工具 ●PowerDesign 1.6.编程工具 ●JDBC访问数据库
1.7.数据库命名规则 ●数据表：以“t_”开头，后接表名 ●视图名：以“v_”开头，后接视图名 ●存储过程名：以“p_”开头，后接过程名 ●索引名：以“i_”开头，后接索引名 ●所有字段名都用大写表示 2.数据库表结构 序号分类名称表名备注1 用户管理用户表t_user_info 2 商品销售管 理商品信息表t_goods_info 3 购物车表t_shoppingcar
2.1.用户信息表表名：t_user_info 字段名描述名类型是否 为空 缺省值 约束 条件 说明 USERNAME 用户名nvarchar(50) N P 唯一，不允许重名USERPWD 密码nvarchar(16) N 明文存储USERTYPE 用户类型int N 1 0:超级用户 1:普通用户 2:管理员用户STATUS 状态int N 0 -1:锁定 0:未登录(正常) 1:已登录 2:禁用 备注：当前用户输错3次密码时，即被锁定（-1），当下次正确登录时，则解锁。 2.2.商品信息表 表名：t_goods_info 字段名描述名类型是否 为空 缺省值 约束 条件 说明 GOODSNO 商品编号nvarchar(32) N P 唯一，不允许重名GOODSNAME 商品名称nvarchar(100) N GOODSNUM 商品数量int N 0 GOODSPRICE 商品价格numeric(8,2) N 0 备注：此表为商品的库存表 2.3.购物车表 表名：t_shoppingcar 字段名描述名类型是否缺省值约束说明
图书管理系统数据库设计 一、系统概述 1、系统简介图书管理是每个图书馆都需要进行的工作。一个设计良好的图书管理系统数据库能够给图书管理带来很大的便利。 2、需求分析 图书管理系统的需求定义为： 1.学生可以直接通过借阅终端来查阅书籍信息，同时也可以查阅自己的借阅信息。 2.当学生需要借阅书籍时，通过账号密码登陆借阅系统，借阅系统处理学生的借阅，同时修改图书馆保存的图书信息，修改被借阅的书籍是否还有剩余，同时更新学生个人的借阅信息。 3.学生借阅图书之前需要将自己的个人信息注册，登陆时对照学生信息。 4.学生直接归还图书，根据图书编码修改借阅信息 5.管理员登陆管理系统后，可以修改图书信息，增加或者删除图书信息 6.管理员可以注销学生信息。 通过需求定义，画出图书管理系统的数据流图：
数据流图 二、系统功能设计 画出系统功能模块图并用文字对各功能模块进行详细介绍系统功能模块图： 三、数据库设计方案图表 1、系统E-R模型 总体E-R图： 精细化的局部E-R图： 学生借阅-归还E-R图： 管理员E-R图： 2、设计表 给出设计的表名、结构以及表上设计的完整性约束。student :
book: book_so比 borrow:存储学生的借书信息
return_table: 存储学生的归还信息 存储学生的罚单信息 man ager:
3、设计索引 给出在各表上建立的索引以及使用的语句。student ： 1. 为stu_id 创建索引，升序排序sql:create index index_id on student(stu_id asc); 2. 为stu_name 创建索引，并且降序排序sql:alter table student add index index_name(stu_name, desc); 插入索引操作和结果如下所示： mysql> create index index_id on student(stu_id asc); Query OK, 0 rows affected Records: 0 Duplicates: 0 Warnings: 0 mysql> alter table student add index index_name(stu_name desc); Query OK, 0 rows affected Records: 0 Duplicates: 0 Warnings: 0 mysql> book: 1. 为book_id 创建索引，升序排列sql:create index index_bid on book(book_id); 2. 为book_record 创建索引，以便方便查询图书的登记日期信息，升序：sql:create index index_brecord on book(book_record); 插入索引的操作和结果如下所示： mysql> create index index_bid on book(book_id);
数据库系统及应用集中上机设计 报告 《图书管理系统》 题目：图书管理系统 班级：0120903 姓名：胡书冲苏松林 学号：2009210383 2009210384 指导老师：邹洋 时间：第5~14周
图书管理系统 目录 一．设计题目............................................................................................................................. 二．需求分析............................................................................................................................. 2.1 人工图书管理中的几个突出问题..................................................................................... 2.2 图书管理系统设计分析..................................................................................................... 三．开发环境，设计工具......................................................................................................... 四．详细设计............................................................................................................................. 4.1 设计思想............................................................................................................................ 4.2 总体设计............................................................................................................................. 4.3 模块设计............................................................................................................................. 4.3.1登录模块......................................................................................................................... 4.3.2图书管理模块................................................................................................................. 4.3.3用户管理模块................................................................................................................. 4.3.4借阅管理模块................................................................................................................... 4.3.5管理员............................................................................................................................... 五．关键技术和体会................................................................................................................. 5.1 关键技术............................................................................................................................. 5.1.1图书查询功能的实现....................................................................................................... 5.1.2.......................................................................................................................................... 5.2 心得体会.............................................................................................................................. 一．设计题目：图书管理系统 图书管理系统主要为用户提供方便、快捷的图书查询、浏览，个人信息管理，以及图书借阅归还等功能；同时也为管理员提供了高效的对电子书籍，用户等各种信息的管理平台。对于本系统，我们需要实现以下一些基本功能特点： 1. 界面友好、操作简单：系统的界面设计简洁明了，采用菜单选项，弹出式窗口等可视化手段，每一过程有相应的功能提示。 2. 丰富的查询功能：系统的查询功能要方便灵活，如图书可以按书籍名称、出版社、作者等多种关键字查询。 3. 用户管理：具备用户的注册、删除、修改及用户权限。 4. 栏目管理：创建、修改、删除栏目。 5. 全面的信息管理：各个栏目中的信息发布、信息修改、信息删除等。提供相关图书、读者、借书信息报表，同时可实现汇总和对数据项的组合输出功能。 6. 权限管理：对用户和操作实行权限分配，根据所具有的权限访问相应信息，进行相关操作，保证管理系统的安全性。
数据库原理与应用 课程设计(论文) 电脑销售管理系统 院（系）名称 电子与信息工程学院 专业班级软件工程 学号8 学生姓名 指导教师 起止时间：—课程设计（论文）任务及评语 院（系）：电子与信息工程学院教研室：软件工程学号学生姓名专业班级
摘要 电脑管理是通过采购、仓储、综合、出库、配送等活动，解决物资供需之间存在的时间、空间、数量、品种、价格等方面的矛盾，以此衔接社会生产的各环节，从而确保生产的顺利进行。随着社会经济的发展，当企业的物流业务发展到一定规模之后，执行效率就成为物流发展的瓶颈。计算机信息管理技术的迅速发展恰恰解决了这个问题，它使计算机技术与现代管理技术相互配合，来更加准确、高速地完成工业企业日常的电脑销售管理工作，使企业能够以最少的人员来完成更多的工作。 系统的开发主要包括后台数据库的建立和维护以及前端应用程序的开发两个方面。本系统使用SQL Server 2008建立数据库后台，使用C#进行前台界面和处理程序的开发，前者建立成数据一致性和完整性强、数据安全性好的数据库,而后者具有应用程序功能完备，易使用等特点。 关键词：电脑；销售管理系统；C#
目录 第1章绪论 (1) 研究背景 ..................................... 错误!未定义书签。 开发意义 ..................................... 错误!未定义书签。第2章系统需求分析 (3) 开发环境和软件 ............................... 错误!未定义书签。 Microsoft Visual Studio ..................... 错误!未定义书签。 SQL Server数据库............................ 错误!未定义书签。 系统功能分析 ................................. 错误!未定义书签。第3章系统设计. (7) 系统功能结构设计 (7) 数据库概念结构设计 (7) 数据库逻辑结构设计 (8) 数据库实现 (8) 数据库关系图 (8) SQL语句实现 (9) 第4章系统实现 (12) 用户登录界面 (12) 主要功能界面 (12) 主界面 (12) 电脑信息界面 (13) 商品管理界面 (16) 店面信息查询界面 (16) 其他界面 (17) 第5章课设总结 (18) 参考文献 (19)
板式换热机组在中央空调系统中主要是蒸发和冷凝的作用，制冷剂经过压缩机压缩成高温高压气体后与冷却水进行热交换，形成低温高压的液体，经过减压形成低温低压的液体，然后经过蒸发器与冷冻水进行热交换吸收冷冻水的热量蒸发成为热蒸汽，再进入压缩机中进行循环，降温后的冷冻水被送到用户端。 艾瑞德板式换热器（江阴）有限公司作为专业的可拆式板式换热器生产商和制造商，专注于可拆式板式换热器的研发与生产。ARD艾瑞德专业生产可拆式板式换热器（PHE）、换热器密封垫（PHEGASKET）、换热器板片(PHEPLATE)并提供板式换热器维护服务（PHEMAINTENANCE）的专业换热器厂家。 ARD艾瑞德拥有卓越的设计和生产技术以及全面的换热器专业知识，一直以来ARD致力于为全球50多个国家和地区的石油、化工、工业、食品饮料、电力、冶金、造船业、暖通空调等行业的客户提供高品质的板式换热器，良好地运行于各行业，ARD已发展成为可拆式板式换热器领域卓越的厂家。 ARD艾瑞德同时也是板式换热器配件（换热器板片和换热器密封垫）领域专业的供应商和维护商。能够提供世界知名品牌（包括：阿法拉伐/AlfaLaval、斯必克/SPX、安培威/APV、基伊埃/GEA、传特/TRANTER、舒瑞普/SWEP、桑德斯/SONDEX、艾普尔.斯密特/API.Schmidt、风凯/FUNKE、萨莫威孚/Thermowave、维卡勃Vicarb、东和恩泰/DONGHWA、艾克森ACCESSEN、MULLER、FISCHER、REHEAT等）的所有型号将近2000种的板式换热器板片和垫片，ARD艾瑞德实现了与各品牌板式换热器配件的完全替代。全球几十个国家的板式换热器客户正在使用ARD 提供的换热器配件或接受ARD的维护服务（包括定期清洗、维修及更换配件等维护服务）。 无论您身在何处，无论您有什么特殊要求，ARD都能为您提供板式换热器领域的系统解决方案。
汽水换热机组-水水换热机组，板式汽水换热机组，水水板式换热机组，山东国信专业生产汽水换热机组，水水换热机组。 山东国信工业设备有限公司所主营产品： 1.换热设备：包括换热器，板式换热器，管壳式换热器，容积式换热器，螺旋板换热器，双纹管式换热器,U型管式换热器，双纹管湍流换热器，双纹管湍流容积式换热器，浮动盘管容积式换热器，浮动盘管换热器，BRB系列不等截面板式换热器，高温汽(水)-水板式换热器，板式闭式循环水冷却器，QSS节能型组合式汽-水-水换热器，换热机组，采暖换热机组，汽水换热机组，管壳式换热机组，高效智能板式换热机组，智能双螺纹管换热机组，换热机组成套设备，热交换机组，等； 2.2.水处理设备：包括：全自动软水器，电子水处理器，水箱自洁消毒器，全程综合水处理器，旋流除砂器，反冲式除污器，全自动压差过滤器，变频电子除垢仪，旁流水处理器，高效永磁除垢器，铜银离子发生器,全自动软水器,臭氧发生器,二氧化氯发生器,成套加装置,全自动压差过滤器,快速反冲洗过滤器,Y型、T型过滤器,重点技术一曝气生物滤池( BAF),重点技术一膜生物反应器(MBR)等； 3.3.给水设备包括：消防给水设备，消防稳压给水设备； 4.4.供水设备：包括变频供水设备，气压供水设备，无负压供水设备,无塔供水设备，无负压变频供水设备，变频恒压供水设备，囊式落地膨胀水箱，等； 5.5.压力容器类：包括分气缸，分集水器，储气罐油罐，稳压膨胀罐等山东济南生产厂家！ 6.板式换热机组简介 高效智能板式换热机组是集热交换系统和热t控制、热1二调节、热计量等系统一体的全自动智能化的高效节能产品。它根据工况需求、随气象条件的变化，由中央控制器实现对一二次热网的智能控制，最终实现供热量与实际热负荷的平衡。它是集城镇集中供热(采暧、空调、生活用热水)最理想的热交换设备。该机组是由板式换热器，循环泵．补水泵，除污器，管道，阀门，仪表，变频控制系统等组成。根据用户需要可加配电子除垢仪和全自动编程系统。本机组具有传热效率高．阻力小，结构紧凑，运行可靠，操作简便直观等优点，是首选的高效节能产品。 三、板式换热机组特点 采用工控计算或智能化温度调节器使供水温度智能控制．即供水温度按程序设定可随室
软件工程（课程设计）题目：图书管理系统-数据库设计 学院工商学院 学科门类工科 专业软件工程 学号2012484156 姓名文鹏 指导教师王思乐 2014年12月7日
河北大学学年论文（课程设计）任务书 （指导教师用表） 指导教师签字:
河北大学学年论文（课程设计）成绩评定表 学院：工商学院
数据库设计说明书大纲 1 引言 随着计算机技术的不断应用和提高，计算机已经深入到当今每个学生学习生活的各个角落。而对于学校的图书馆仍采用管理员管理书籍基本信息、书籍借还信息的形式，不仅效率低，而且手续繁琐。为了满足其学生自行对图书馆书籍，借还书等进行高效的查询使用，在学生具备一定的计算机操作能力的前提下，此图书管理系统软件力求提高其图书馆使用效率。 1.1 编写目的 本文档的编写是为了熟悉SQL Server数据库的数据库管理（数据库的创建、备份与恢复、函数与存储过程的应用、数据导入导出、作业的调度等）、表的设计（表的创建、修改、删除，字段的默认值、约束及关系等）、数据的查询处理（insert、update、delete、select语句的应用）等技术；完善图书管理系统软件的开发途径和应用方法。以求在最短的时间高效的开发图书管理系统。 预期读者是“软件工程”教师，及从事“图书管理系统”开发的相关人。 1.2 背景 待开发的数据库的名称：Library Management System(LMS) 使用此数据库的软件系统的名称：图书管理系统。 随着图书馆图书种类、数量的不断扩大，图书检索速度慢、统计工作量大，难以满足图书馆现代化管理的要求。因此，建立一套图书馆管理软件，科学的对图书馆数据进行管理，方便图书的检索和读者借阅工作。 本项目的提出者及开发者是软件工程专业图书管理系统开发小组（高彦昭、甄朝霞、李茹枫、孙华芬、陆叶倩、秦薇），用户是学校图书馆。 图书管理系统软件LMS V1.0是一套功能比较完善的数据管理软件，具有数据操作方便高效迅速等优点。该软件采用功能强大的数据库软件开发工具进行开发，具有很好的可移植性，可在应用范围较广的DOS、WINDOWS系列等操作系统上使用。除此以外，LMS V1.0可通过访问权限控制以及数据备份功能，确保数据的安全性。
销售管理系统数据库设 计 文件管理序列号：[K8UY-K9IO69-O6M243-OL889-F88688]
某制造企业销售管理系统数据库设计 一、需求分析 （一）业务流程： 1、销售部统计商品信息，向客户发布商品信息。 2、客户根据销售部发布的商品信息，向销售部发送订单。 3、销售部将订单发送给主管部门审核。 4、主管部门对订单进行核对： （1）如果不批准订单，主管部门向客户发布不批准的信息； （2）如果批准，主管部门向客户发布批准的信息；销售部获取批准的订单，核对客户信息，登记新客户的基本资料或修改原有客户的基本资料，同时及时发布商品修改后的信息；生产部门接受订单，生产客户所需的商品，生产完成后，将发货单与商品一同发出。 5、客户确认发货单。 （二）数据流程图
填写上报 客户信息员工信息 P1 基本信息 1、订单号数据项可以描述如下 : 数据项 : 订单号 含义说明 : 唯一标识每张订单 别名 : 订单编号 类型 : 字符型 长度 : 4 取值范围 : 0000至 9999 取值含义 : 前 2 位标别所在地区，后 2 位按顺序编号 与其他数据项的逻辑关系 :唯一识别订单 2、商品信息是该系统中的一个重要数据结构，它可以描述如下 :数据结构 : 商品信息
含义说明 : 是销售管理系统的重要数据结构，定义了销售商品的具体信息 组成 : 产品号，产品名，单价，重量? 3、数据流“订单数据 " 可描述如下 : 数据流 : 订单数据 说明 : 客户选购商品所下的初始订单 数据流来源 : 客户 数据流去向 : 接受订单 组成 : 客户基本信息＋商品编号＋数量等 平均流量 : 5张／天 高峰期流量 : 100张／天 4、数据存储“订单 " 可描述如下 : 数据存储 : 订单表 说明 : 记录每张订单的具体情况 流入数据流 : 订单处理 流出数据流 : …… 组成 : 订单号，客户编号，产品，数量，单价等 数据量 : 每年2000张 存取方式 : 随机存取 5、处理过程“接收订单 "可描述如下 : 处理过程 : 接收订单 说明 : 核准客户所下订单
图书管理系统数据库设计-M Y S Q L实现 公司内部编号：（GOOD-TMMT-MMUT-UUPTY-UUYY-DTTI-
图书管理系统数据库设计 一、系统概述 1、系统简介 图书管理是每个图书馆都需要进行的工作。一个设计良好的图书管理系统数据库能够给图书管理带来很大的便利。 2、需求分析 图书管理系统的需求定义为： 1.学生可以直接通过借阅终端来查阅书籍信息，同时也可以查阅自己的借阅信息。 2.当学生需要借阅书籍时，通过账号密码登陆借阅系统，借阅系统处理学生的借阅，同时修改图书馆保存的图书信息，修改被借阅的书籍是否还有剩余，同时更新学生个人的借阅信息。 3.学生借阅图书之前需要将自己的个人信息注册，登陆时对照学生信息。 4.学生直接归还图书，根据图书编码修改借阅信息 5.管理员登陆管理系统后，可以修改图书信息，增加或者删除图书信息 6.管理员可以注销学生信息。 通过需求定义，画出图书管理系统的数据流图：
数据流图 二、系统功能设计 画出系统功能模块图并用文字对各功能模块进行详细介绍。系统功能模块图： 三、数据库设计方案图表 1、系统E-R模型 总体E-R图： 精细化的局部E-R图： 学生借阅-归还E-R图： 管理员E-R图： 2、设计表 给出设计的表名、结构以及表上设计的完整性约束。student：
book: book_sort: borrow:存储学生的借书信息 return_table:存储学生的归还信息 ticket:存储学生的罚单信息 manager:
3、设计索引 给出在各表上建立的索引以及使用的语句。 student： 1.为stu_id创建索引，升序排序 sql:create index index_id on student(stu_id asc); 2.为stu_name创建索引，并且降序排序 sql:alter table student add index index_name(stu_name, desc); 插入索引操作和结果如下所示： mysql> create index index_id on student(stu_id asc); Query OK, 0 rows affected Records: 0 Duplicates: 0 Warnings: 0 mysql> alter table student add index index_name(stu_name desc); Query OK, 0 rows affected Records: 0 Duplicates: 0 Warnings: 0 mysql> book: 1.为book_id创建索引，升序排列 sql:create index index_bid on book(book_id); 2.为book_record创建索引，以便方便查询图书的登记日期信息，升序：