數(shù)據(jù)庫(kù)外文翻譯7-數(shù)據(jù)庫(kù)-在線瀏覽
2025-03-24 11:55本頁(yè)面
【正文】 grown in orders of magnitudes. For decades it has been unlikely that a plex information system can be built effectively without a proper database supported by a DBMS. The utilization of databases is now spread to such a wide degree that virtually every technology and product relies on databases and DBMSs for its development and mercialization, or even may have such embedded in it. Also, anizations and panies, from small to large, heavily depend on databases for their operations. No widely accepted exact definition exists for DBMS. However, a system needs to provide considerable functionality to qualify as a DBMS. Accordingly its supported data collection needs to meet respective usability requirements (broadly defined by the requirements below) to qualify as a database. Thus, a database and its supporting DBMS are defined here by a set of general requirements listed below. Virtually all existing mature DBMS products meet these requirements to a great extent, while less mature either meet them or converge to meet them. Evolution of database and DBMS technology The introduction of the term database coincided with the availability of directaccess storage (disks and drums) from the mid1960s onwards. The term represented a contrast with the tapebased systems of the past, allowing shared interactive use rather than daily batch processing. In the earliest database systems, efficiency was perhaps the primary concern, but it was already recognized that there were other important objectives. One of the key aims was to make the data independent of the logic of application programs, so that the same data could be made available to different applications. The first generation of database systems were navigational,[2] applications typically accessed data by following pointers from one record to another. The two main data models at this time were the hierarchical model, epitomized by IBM39。ledgerbook39。s requirements. Though attractive in many cases, a generalpurpose DBMS is not always the optimal solution: When certain applications are pervasive with many operating instances, each with many users, a generalpurpose DBMS may introduce unnecessary overhead and too large footprint (too large amount of unnecessary, unutilized software code). Such applications usually justify dedicated development. Typical examples are systems, though they need to possess certain DBMS properties: systems are built in a way that optimizes messages handling and managing, and do not need significant portions of a generalpurpose DBMS 3 functionality. Database machines and appliances In the 1970s and 1980s attempts were made to build database systems with integrated hardware and software. The underlying philosophy was that such integration would provide higher performance at lower cost. Examples were IBM System/38, the early offering of Teradata, and the Britton Lee, Inc. database machine. Another approach to hardware support for database management was ICL39。 see below) may be viewed, to some extent, as an extension of Data modeling. It is used to 4 conveniently answer requirements of different endusers from a same database, as well as for other benefits. For example, a financial department of a pany needs the payment details of all employees as part of the pany39。s database, that both include the employees39。 performance requirements, possibly conflicting, in attempt to optimize the overall database usage by all its enduses according to the database goals and priorities. All the three levels are maintained and updated according to changing needs by database administrators who often also participate in the database design. The above threelevel database architecture also relates to and being motivat
黨政相關(guān)相關(guān)推薦
鄂ICP備17016276號(hào)-1