Course Notes on Databases and Database Management Systems Databases and Database Management Systems: Summary (original) (raw)
Related papers
Computer Science department 1.7 Database Architecture
We know that a DBMS is a collection of programs that enables users to create and maintain a database. A major purpose of a DBMS is to provide users with an abstract view of the database. This means that the system does not provide all the details of data, rather it hides the details of how data is stored and maintained. However, in order for the system to be usable, data must be retrieved efficiently. This concern leads to the design of complex data structures for the representation of data in the database. Since many database systems end users are not computer trained, the complexities are hidden from them through several levels of abstraction in order to simplify their interaction with the system. Before getting in to the details of database systems architecture, let us discuss two important terms associated with it. View: Normally, a table contains many columns and rows. Sometimes all that data interests the user, and sometimes it does not. There may be a case when only some columns or some rows of a table interest the user. To eliminate data that is not relevant to the current needs, a view is created. A view is a subset of database that an application can process. It may contain parts of one or more tables. Views are sometimes called virtual tables. To the application or the user, views behave in similar fashion as tables; however, they do not have an independent existence. Views allow the user to look at data, but they are not parts of the database. Schema: In any data model, it is important to distinguish between the description of the database and the database itself. The description of a database is called the database schema. The database schema refers to the overall structure of the database tables that store information such as user profile data, metadata or structured information. Hence, the overall logical design of the database is called as the database schema. A schema is a collection of named objects. Schemas provide a logical classification of objects in the database. A schema can contain tables, views, triggers, functions, packages, and other objects. Note that once the schema of the database is created, usually is not changed. If in case it needs to be modified, only the owner of the schema, that is, the DBA, who has access to manipulate the structure of any object in the schema, can modify it. The distinction between the logical and physical representation of data were recognized in 1978 when ANSI/SPARC (American National Standard Institute/ Standards Planning and Requirements Committee) proposed a generalized framework for database systems. According to the ANSI/SPARC DBMS report, a DBMS can be envisioned as a three-layered system: internal, conceptual, and external. 1. Internal (physical) level: this is the lowest level of abstraction and it describes how the data is physically stored and organized on the storage medium, as well as access to the data, such as through data storage in tables and the use of indexes to expedite data access. At this level, complex low-level data structures are described in detail, which deal with actual storage. The internal model separates the physical requirement of the hardware and the operating system from the data model. 2. Conceptual level: Also known as logical or community-user level, conceptual level describes what type of data is actually stored in the data base, and the relationship among the data. At this level, entire database is described in terms of small number of relatively simple structures, such as tables and constraints. Although implementation of the simple structure at the conceptual level may involve complex physical level structures, the user of the conceptual level of abstraction is the DBA, who must decide what information is to be kept in the data base. 3. External level: The external level (or application interface) is the view that the individual user of the database has. This view is often restricted view of the database and the same database may provide a number of different views for different classes of users. This level deals with the methods through which users may access the schema, such as using an input form. In general, the end users and even the application programmers are only interested in the subset of the database. To simplify their interaction with the system, the view level of abstraction is defined. Concisely, this level is concerned with the way in which the data is viewed by individual users.
DATABASE SYSTEM MODELS AND ARCHITECTURES 2.1. INTRODUCTION
Earlier DBMS software package was one integrated system where large centralized mainframe computers were used. The modern DBMS packages are modular in design, with a client/server architecture where hundreds of distributed workstations and personal computers are connected via communications network. There are various types of servers like Web servers, database servers, file servers, application servers and so on. A client module will run on a user workstation or personal computer. Typically, application programs and user interfaces that access the database run in the client module. The client module handles user interaction and provides the user-friendly interfaces such as forms or menu based GUIs. The server module handles data storage, access, search and other functions. The study of data models, schemas and instances is very important to understand database systems. 2.2. DATA MODELS, SCHEMAS, AND INSTANCES 2.2.1 Data Model A data model is a collection of concepts that can be used to describe the structure of the database. It is a type of data abstraction that is used to provide conceptual representation of data. It uses logical concepts that can be easily understood. A data model is a set of concepts that can be used to describe the structure of a database, which includes data types, relationships and data constraints etc. It also includes a set of basic operations for specifying retrievals and updates on the database. Also dynamic aspect or behavior of a database application is included in a data model. Categories of Data Models Data models are categorized based on the types of concepts that they provide to describe the database structure.
I have authored this paper to illustrate the History, Types, and Structure of Database Management Systems and their dependencies. Aiming to give a solid overview of the terms database and DBMS. Also, to help the reader create a global, comprehensive picture of the database and DBMS.We start the paper by listing the history of databases and storing data techniques. Then the terms data and types of data. After that, we start defining database and DBMS and their types. We have an extensive illustration of database objects. We give an overview of SQL, DML, TCL, DQL, and DDL as Structured Query Language. Finally, we ended the paper by talking about database normalization and its levels.
Databases based on relational, object-oriented, and object-relational models represent significant advances in database technologies. In the context of general-purpose database management systems, the fundamentals of database models are examined. A historical perspective on the evolution of major database models is provided. The principal concepts underlying relational, object-oriented, and object-relational database models are presented with examples. Finally, a brief view of database federation issues is introduced and served as the foundation for computerized databases are essential and inseparable components of most of today’s information systems and data base technology.
Encyclopedia of Database Systems, 2009
Chapter 7 has presented models of databases; Chap. 8 discussed means to describe databases, and now we can finally look at actual database implementation problems. In this chapter we will proceed in a top-down fashion. We begin with methods derived from formal models and continue on to systems developed over time and regular use. The discussion in this chapter proceeds in the direction of increased binding, which causes loss of flexibility but increases the performance of systems. Such important implementation issues such as reliability, access protection, integrity, and data representation are not covered in this chapter; they are separately discussed in Chaps. 11, 12, 13, and 14. We concentrate on concepts, and do not present complete system descriptions, although many actual systems will be referenced to allow further study. Appendix B can be consulted for references about the systems named in this chapter. The exact syntax of examples based on these systems has been modified at times in order to provide continuity. The fact that a certain system is cited here as a commendable example does not imply an endorsement of this implementation for a given application but only reflects on the values of the concepts being discussed. 449 Objectives We have implied earlier a number of objectives for a database system design: 1 The ability to refer to data items without having knowledge of record or file structure and as a corollary: 2 The ability to change record or file content and structure without affecting existing database programs We also desire 3 The ability to handle related files within one general framework, so that the data in separate files can remain consistent and so that excessive redundancy in updating and storage can be avoided and 4 A description of the database integrating diverse points of view, so that this description can become a communication medium between data generators and information seekers In order to achieve these lofty goals, we will consider how to implement systems that use schemas to present high-level services while using file-based, record-oriented structures. Sec. 9-1 Issues in Database Implementation 451 9-1 ISSUES IN DATABASE IMPLEMENTATION In this introductory section we will introduce briefly some concepts that recur throughout this chapter. 9-1-1 Functionality and Generality Database-management systems can be built with a wide range of generality. A categorization of these approaches into three levels distinguishes systems which support a single application, several applications of the same type, or multiple types of applications. Some systems have developed through these three levels; others have been designed consciously to attack problems at one specific level. Single-Application Database Systems An organization establishes a database operation using available file system facilities, and designs application programs that interface to the database using a centrally maintained package which implements the required degree of data and structure description. The original airline reservation system at American Airlines, SABRE, many large information systems, such as MEDLARS (a system to query the medical literature), and military command and control systems are examples of this approach. Single-Application-Type Database Systems A group of users working in some type of application area recognizes the commonality of their needs. They or their vendor design a system to match their needs. User differences are incorporated into tables and schemas specific to the user. This step often follows success with a more single-minded system. Examples of this approach are the generalized airline reservation systems (PARS), clinical information systems (TOD, GEMISCH), and bills-of-materials systems (BOMP). Multiple-Application-Type Database Systems A vendor or academic group designs a system with the intent to serve the general database needs in a better fashion. An effort is made to provide a complete set of services. There will, of course, be a tendency to emphasize aspects relating to the experience of the designers, so that in practice a great deal of difference is found among the generalized systems. Another source for generalized systems is a continued evolution from single application or application-type services. An understanding of the history of generalized systems helps to explain features of their design. The development of the CODASYL specification and of the relational model for databases has provided a basis for generalized systems that are relatively independent of past history. Generalized systems developed independently encountered so far in the text are PRTV, RETRIEVE, SOCRATE, and SQL/DS. The IDS and IMS systems owe much to the BOMP applications.
INTRODUCTION AND AN OVERVIEW OF DATABASE MANAGEMENT SYSTEMS
Database management systems are standard tools that enable the storage and retrieval of data within modern information systems. Units introducing database concepts are now an accepted part of most computer science courses. These introductory units tend to concentrate on the use of relational database systems. This advanced module, in contrast, deals with implementation aspects of relational systems as well as to the internal structure and performance issues related to DBMS and tests the candidates‟ knowledge of the current enhancements to relational database systems, object oriented database,datamining, data warehousing etc.. This course examines information about database system architecture, the system catalog, query processing and optimization, transaction processing concepts, concurrency control techniques, database recovery techniques, database security and authorization, object-Oriented and object-relational databases, distributed databases and client server architecture, Data Warehousing and Data Mining, and emerging technologies and applications