Computer Application In Management

ASSSIGNMENT

Sidharth Gupta 50-TBS-13

Concept of Database
1. Databases and Database Systems
1.1 What Is a Database?

A database can be summarily described as a repository for data. This makes clear that building databases is really a continuation of a human activity that has existed since writing began; it can be applied to the result of any bookkeeping or recording activity that occurred long before the advent of the computer era. However, this description is too vague for some of our purposes, and we rene it as we go along. The creation of a database is required by the operation of an enterprise. We use the term enterprise to designate a variety of endeavors that range from an airline, a bank, or a manufacturing company to a stamp collection or keeping track of people to whom you want to write New Year cards. Throughout this book we use a running example that deals with the database of a small college. The college keeps track of its students, its instructors, the courses taught by the college, grades received by students, and the assignment of advisors to students, as well as other aspects of the activity of the institution that we discuss later. These data items constitute the operational data that is, the data that the college needs to function. Operational data are built from various input data (application forms for students, registration forms, grade lists, schedules) and is used for generating output data (transcripts, registration records, administrative reports, etc.) Note that no computer is necessary for using such a database; a college of the 1930s would have kept the same database in paper form. However, the existence of computers to store and manipulate the data does change user expectations: we expect to store more data and make more sophisticated use of these data.

1.2 Database Management Systems

A database management system (DBMS) is an aggregate of data, hardware, software, and users that helps an enterprise manage its operational data. The main function of a DBMS is to provide ecient and reliable methods of data retrieval of many users. If our college

has 10,000 students each year and each student can have approximately 10 grade records per year, then over 10 years, the college will accumulate 1,000,000 grade records. It is not easy to extract records satisfying certain criteria from such a set, and by current standards, this set of records is quite small! Given the current concern for grade ination, a typical question that we may try to answer is determining the evolution of the grade averages in introductory programming courses over a 10-year period. Therefore, it is clear that ecient data retrieval is an essential function of database systems. Most DBMSs deal with several users who try simultaneously to access several data items and, frequently, the same data item. For instance, suppose that we wish to introduce an automatic registration system for students. Students may register by using terminals or workstations. Of course, we assume that the database contains information that describes the capacity of the courses and the number of seats currently available. Suppose that several students wish to register for cs210 in the spring semester of 2003. Unfortunately, the capacity of the course is limited, and not all demands can be satised. If, say, only one seat remains available in that class, the database must handle these competing demands and allow only one registration to go through.

2. Architecture of Database Systems

The architecture of a DBMS can be examined from several angles: the functional architecture that identies the main components of a DBMS, the application architecture that focuses on application uses of DBMSs, and the logical architecture that describes various levels of data abstractions. Functionally, a DBMS contains several main components shown in Figure 1.1: the memory manager; the query processor; the transaction manager. The query processor converts a user query into instructions the DBMS can process eciently, taking into account the current structure of the database (also referred as metadata which means data about data). The memory manager obtains data from the database that satises queries compiled by the query processor and manages the structures that contain data, according to the DDL directives. Finally, the transaction manager ensures that the execution of possibly many transactions on the DBMS satises the ACID properties mentioned above and, also, provides facilities for recovery from system and media failures. The standard application architecture of DBMSs is based on a client/server model. The client, which can be a user or an application, generates a query that is conveyed to the server. The server processes the query (a process that includes parsing, generation of optimized execution code, and execution) and returns an answer to the client. This

architecture is known as two-tier architecture. In general, the number of clients may vary over time. In large organizations, it is often necessary to create more layers of processing, with, say, a layer of software to concentrate the data activities of a branch oce and organize the communication between the branch and the main data repository. This leads to what is called a multi-tier architecture. In this setting data are scattered among various data sources that could be DBMSs, le systems, etc. These constitute the lowest tier of the architecture, that is, the tier that is closest to the data. The highest tier consists of users that act through user interfaces and applications to obtain answers to queries. The intermediate tiers constitute the middleware, and their role is, in general, to serve as mediators between the highest and the lowest tiers. Middleware may be consist of web servers, data warehouses, and may be considerably complex. Multi-tier architecture is virtually a requirement for world wide web applications. The logical architecture, also known as the ANSI/SPARC architecture, was elaborated at the beginning of the 1970s. It distinguishes three layers of data abstraction: 1. The physical layer contains specic and detailed information that describes how data are stored: addresses of various data components, lengths in bytes, etc. DBMSs aim to achieve data independence, which means that the database organization at the physical level should be indierent to application programs 2. The logical layer describes data in a manner that is similar to, say, denitions of structures in C. This layer has a conceptual character; it shields the user fromthe tedium of details contained by the physical layer, but is essential in formulating queries for the DMBS. 3. The user layer contains each users perspective of the content of the database.

Relational database model

1. Introduction
The relational model for database management is a database model based on first-order predicate logic, first formulated and proposed in 1969 by E.F. Codd. The relational model is the mainstay of contemporary databases. The relational model consists of: 1. A class of data structures referred to as tables. 2. A collection of methods for building new tables starting from an initial collection of tables; we refer to these methods as relational algebra operations. 3. A collection of constraints imposed on the data contained in tables.

Its central idea is to describe a database as a collection of predicates over a finite set of predicate variables, describing constraints on the possible values and combinations of values. The content of the database at any given time is a finite (logical) model of the database, i.e. a set of relations, one per predicate variable, such that all predicates are satisfied. A request for information from the database (a database query) is also a predicate. The relational model was the first database model to be described in formal mathematical terms. Hierarchical and network databases existed before relational databases, but their specifications were relatively informal. After the relational model was defined, there were many attempts to compare and contrast the different models, and this led to the emergence of more rigorous descriptions of the earlier models; though the procedural nature of the data manipulation interfaces for hierarchical and network databases limited the scope for formalization.

2. The Model
The fundamental assumption of the relational model is that all data is represented as mathematical n-ary relations, an n-ary relation being a subset of the Cartesian product of n domains. In the mathematical model, reasoning about such data is done in two-valued predicate logic, meaning there are two possible evaluations for each proposition: either true or false (and in particular no third value such as unknown, or not applicable, either of

which are often associated with the concept of NULL). Data are operated upon by means of a relational calculus or relational algebra, these being equivalent in expressive power. The relational model of data permits the database designer to create a consistent, logical representation of information. Consistency is achieved by including declared constraints in the database design, which is usually referred to as the logical schemes. The theory includes a process of database normalization whereby a design with certain desirable properties can be selected from a set of logically equivalent alternatives. The basic relational building block is the domain or data type, usually abbreviated nowadays to type. A tuple is an ordered set of attribute values. An attribute is an ordered pair of attribute name and type name. An attribute value is a specific valid value for the type of the attribute. This can be either a scalar value or a more complex type. A relation consists of a heading and a body. A heading is a set of attributes. A body (of an n-ary relation) is a set of n-tuples. The heading of the relation is also the heading of each of its tuples. A TABLE is an accepted visual representation of a relation; a tuple is similar to the concept of row, but note that in the database language SQL the columns and the rows of a table are ordered

3. Application To Database
A data type as used in a typical relational database might be the set of integers, the set of character strings, the set of dates, or the two boolean values true and false, and so on. The corresponding type names for these types might be the strings "int", "char", "date", "boolean", etc. It is important to understand, though, that relational theory does not dictate what types are to be supported; indeed, nowadays provisions are expected to be available for user-defined types in addition to the built-in ones provided by the system. Attribute is the term used in the theory for what is commonly referred to as a column. Similarly, table is commonly used in place of the theoretical term relation (though in SQL the term is by no means synonymous with relation). A table data structure is specified as a list of column definitions, each of which specifies a unique column name and the type of

the values that are permitted for that column. An attribute value is the entry in a specific column and row, such as "John Doe" or "35". A tuple is basically the same thing as a row, except in an SQL DBMS, where the column values in a row are ordered. (Tuples are not ordered; instead, each attribute value is identified solely by the attribute name and never by its ordinal position within the tuple.) An attribute name might be "name" or "age". A relation is a table structure definition (a set of column definitions) along with the data appearing in that structure. The structure definition is the heading and the data appearing in it is the body, a set of rows. A database relvar (relation variable) is commonly known as a base table. The heading of its assigned value at any time is as specified in the table declaration and its body is that most recently assigned to it by invoking some update operator (typically, INSERT, UPDATE, or DELETE). The heading and body of the table resulting from evaluation of some query are determined by the definitions of the operators used in the expression of that query.

Entity
An entity is a thing or object of importance about which data must be captured. All things aren't entitiesonly those about which information should be captured. Information about an entity is captured in the form of attributes and/or relationships. If something is a candidate for being an entity and it has no attributes or relationships, it isn't an entity. Database entities appear in a data model as a box with a title. The title is the name of the entity.

An entity in a data model Some examples of database tables are :1. 2. 3. 4. 5. a customer table an appointments table an exam sessions table a teachers' names table a concert venue table

Now, each of these tables are about an object, thing, or person which represent entities. Some other examples of entities are customer, videos, appointments, patients, books, exam sessions, products, teachers etc.