数据设计外文翻译

《数据设计外文翻译》由会员分享，可在线阅读，更多相关《数据设计外文翻译（7页珍藏版）》请在毕设资料网上搜索。

1、附录 A Data Design 1. DATA TYPES AND VALUE SETS Anyone who has ever programmed a computer is accustomed to the fact that you usually have to tell the computer whether the information stored in a particular location is an integer, a real number, a character string, a Boolean va1ue, or whatever. Most co

2、mputers have one electronic circuit for adding two integers and another for adding two real numbers, and, of course, addition does not make any sense at all, in general, for character strings. Because the pattern of bits in at storage location can usual1y be interpreted as any of these, the computer

3、 must be told what is intended. This specification is known as the type of the data. Identifying a data object as being of a particular type has the effect of defining an internal representation for the object. It also specifies which operations may be performed on that object and their effects. For

4、 example, the internal representation of an integer in most modem mainframe computers is a string of 32 bits in 2s complement format. The external representation is a character string in which only the digits 0 to 9 and the minus sign may appear. Suitable interpretations of all the standard arithmet

5、ic and logical operations are also implied when a data object is declared to be of type integer.It is also true (but perhaps less obvious) that declaring a data object to be an integer defines a collating system for occurrences of that object. That is, it specifies how the relatively complex operati

6、on, sort, should operate. Specific algorithms for converting between interna1 and external representations are also implied. 2. KEYS All attributes describe some aspect of an entity. Some attributes perform the additional role of distinguishing one particular entity occurrence from all others of the

7、 same type. For example, if care is taken not to assign any employee number to more than one person, then knowing an individuals employee number should be sufficient to locate all of the other attribute values for that individual. An attribute that can be guaranteed to have a unique value for each e

8、ntity is called a key.Sometimes there may be more than one attribute of an entity that uniquely identifies each occurrence. For example, if the personnel records include Social Security Numbers (and if it is felt that the controls on issuing duplicate Social Security Numbers are adequate), then eith

9、er Employee Number or Social Security Number could be used as the key for identifying employees. Keys are fundamental to virtually all methods of Physically managing data in computer systems. When there is more than one possible key, the alternatives are referred to as candidate keys. Normally, one

10、of these will be select as the primary key and used to determine where the record will be stored. Other candidate keys that may be used to facilitate retrieval are called secondary keys. 3. DATABASE SCHEMA This is a description of the data which is stored in the database and specifies what data elem

11、ents are store and what access paths are provided between these elements. The database schema also contains specifications of privacy as well as integrity constraints. It is somewhat similar to the conceptual schema, but is a description of data rather than of reality. Some aspects of reality which

12、are described by data in the database schema. Note, however, that the database schema does not specify how the data is actually stored or how access paths are provided. (Ideally it should not refer to files, records, sets or the like.) It is, therefore, an implementation independent description and

13、for this reason is sometimes referred to as logical schema. That part of the database schema which is of interest to a particular end-user or group of end users is called a database sub-schema. Ideally, a sub-schema should be specified using a notation which is most appropriate for the use to which

14、it is being put. Database sub-schemas have several use : (1) they can be referred to by application programmers to see what access paths are available in that part of the database in which they are interested (2) similarly, they can be referred to by the end-users when they are using a report progra

15、m generator or formulating queries etc. using a query language provided. (3) they can be used to divide the database into units for the specification of privacy constrains. For example, a sub-schema could be defined for which all users have read access but only one specified user has write (update)

16、access. 4. PHYSICAL SCHEMA The physical schema is a description of the physical structure of the database. If, for example, conventional indexed-sequential files are used to store the database, then this will be stated in the physical schema. It will also contain details of record formats, blocking

17、factors etc. The physical schema is constructed as an essential part of the design process. However, it may also be used as an integeral part of he operational database system as discussed below. The physical schema is sometimes called the internal schema. 5. PHYSICAL STORAGE STRUCTURE The structure

18、 in which the database actually resides is termed the physical storage structure. It typically consists of disc files, tapes, mainstore, indices and programs to manipulate these components. 6. BACK-UP AND RECOVERY SYSTEM The back-up and recovery system is the module which rebuilds the database after

19、 corruption due to hardware or software failure. Understanding the Application Tasks One of the often-neglected steps on building software is really understanding the end user s job-the that computer automation is intended to support. Occasionally, this is because the application itself is quite spe

20、cialized； more often, it is because the approach to design tends to be data-oriented. Frequently, these are the major question asked in the analysis: (1) What data should be captured (2) How should the data be processed (3) How should the data be reported These question expand into a series of sub q

21、uestion ,and include issues such as input forms, Codes, screen layouts, computations, postings, corrections, audit trails, retention, storage volumes, processing cycles, report formatting, distribution, and maintenance. there are all vitally important areas. One difficulty, however, is that they all

22、 focus solely on data. People use data, but they do tasks. One might argue that while this may be true of professional workers. Key-entry clerks really only transfer data from an input form to a keyboard； their tasks are very data-oriented. This is a fair portrayal of their jobs today, but is this a

23、 consequence of the real job that need to get done, or is it a symptom of the computer application? Using humans as input devices, particularly for data that is voluminous, consistent in format (as on forms), and in a limited range of variability, is an expensive and antiquated, not to mention dehum

24、anizing, method of capturing data. This may sound like so much philosophy, but it has practical import in the way application design is done. People use data, but they do tasks. And they dont do tasks through o completion one at a time. They do several tasks that are subset of or in intersection wit

25、h each other, and they so them all at once, in parallel. When designers allow this idea to direct the analysis and creation of an Application, rather than focusing on the data orientation that has been historically dominant, the very nature of the effort changes significantly. Why have windowing env

26、ironments been so successful.Because they allow a user to shut down and exit one in order to begin another. The windowing environment comes closer to mapping the way people really think and work than the old one thing at a time approach ever did. This lesson should not be lost. It should be built up

27、on. Understanding the application tasks means going far beyond identifying the data elements, normalizing them, and creating screens, processing programs, and reports. It means really understanding what the users do and what their tasks are, and designing the application to be responsive to those tasks, not just to capture the data, associated with them. In fact, when the orientation is toward the data, the