9-7本科毕业设计外文翻译(附外文原文)封面

9-7本科毕业设计外文翻译(附外文原文)封面内容摘要：

tore data are automatically generated ``beneath the covers39。 39。 . More sophisticated mappings are also provided, for example, where rows of multiple tables are bined in a Java class. As interest in JDBC has grown, more developers have been working on JDBCbased tools to make building programs easier, as well. Programmers have also been writing applications that make accessing a database easier for the end user. For example, an application might present a menu of database tasks from which to choose. After a task is selected, the application presents prompts and blanks for filling in information needed to carry out the selected task. With the requested input typed in, the application then automatically invokes the necessary SQL mands. With the help of such an application, users can perform database tasks even when they have little or no knowledge of SQL syntax. JDBC versus ODBC and other APIs At this point, Microsoft39。 s ODBC (Open DataBase Connectivity) API is probably the most widely used programming interface for accessing relational databases. It offers the ability to connect to almost all databases on almost all platforms. So why not just use ODBC from Java? The answer is that you can use ODBC from Java, but this is best done with the help of JDBC in the form of the JDBCODBC Bridge. The question now bees, ``Why do you need JDBC?39。 39。 There are several answers to this question:  ODBC is not appropriate for direct use from Java because it uses a C interface. Calls from Java to native C code have a number of drawbacks in the security, implementation, robustness, and automatic portability of applications.  A literal translation of the ODBC C API into a Java API would not be desirable. For example, Java has no pointers, and ODBC makes copious use of them, including the notoriously errorprone generic pointer ``void *39。 39。 . You can think of JDBC as ODBC translated into an objectoriented interface that is natural for Java programmers.  ODBC is hard to learn. It mixes simple and advanced features together, and it has plex options even for simple queries. JDBC, on the other hand, was designed to keep simple things simple while allowing more advanced capabilities where required.  A Java API like JDBC is needed in order to enable a ``pure Java39。 39。 solution. When ODBC is used, the ODBC driver manager and drivers must be manually installed on every client machine. When the JDBC driver is written pletely in Java, however, JDBC code is automatically installable, portable, and secure on all Java platforms from work puters to mainframes. In summary, the JDBC API is a natural Java interface to the basic SQL abstractions and concepts. It builds on ODBC rather than starting from scratch, so programmers familiar with ODBC will find it very easy to learn JDBC. JDBC retains the basic design features of ODBC。 in fact, both interfaces are based on the X/Open SQL CLI (Call Level Interface). The big difference is that JDBC builds on and reinforces the style and virtues of Java, and, of course, it is easy to use. More recently, Microsoft has introduced new APIs beyond ODBC: RDO, ADO, DAO, and OLE DB. These designs move in the same direction as JDBC in many ways, for example, in being objectoriented interfaces to databases based on classes that can be implemented on ODBC. However, we did not see functionality in any of these interfaces pelling enough to make them an alternative basis to ODBC, especially with the ODBC driver market wellestablished. Mostly they represent a thin veneer on ODBC. This is not to say that JDBC does not need to evolve from the initial release described in this book。 we discuss a few directions in ``The Future of JDBC39。 39。 in Appendix B. However, we feel that most new functionality belongs in higherlevel APIs such as the object/relational mappings and embedded SQL we mentioned earlier in ``JDBC Is a Lowlevel API and a Base for Higherlevel APIs.39。 39。 Twotier and Threetier Models The JDBC API supports both twotier and threetier models for database access. In the twotier model, a Java applet or application talks directly to the database. This requires a JDBC driver that can municate with the particular database management system being accessed. A user39。 s SQL statements are delivered to the database, and the results of those statements are sent back to the user. The database may be located on another machine to which the user is connected via a work. This is referred to as a client/server configuration, with the user39。 s machine as the client, and the machine housing the database as the server. The work can be an intra, which, for example, connects employees within a corporation, or it can be the Inter. In the threetier model, mands are sent to a ``middle tier39。 39。 of services, which then send SQL statements to the database. The database processes the SQL statements and sends the results back to the middle tier, which then sends them to the user. MIS directors find the threetier model very attractive because the middle tier makes it possible to maintain control over access and the kinds of updates that can be made to corporate data. Another advantage is that when there is a middle tier, the user can employ an easytouse higherlevel API which is translated by the middle tier into the appropriate lowlevel calls. Finally, in many cases the threetier architecture can provide performance advantages. Until now the middle tier has typically been written in languages such as C or C++, which offer fast performance. However, with the introduction of optimizing pilers that translate Java bytecode into efficient machinespecific code, it is being practical to implement the middle tier in Java. This is a big plus, making it possible to take advantage of Java39。 s robustness, multithreading, and security featur。