Access is a database program that enables one can store information such as a client list, products, invoices, inventory, events, and other collections of data. In addition to entering the data in a database table, you have several tools for working with the data. Forms for simpler data entry can be created. You can create a query to display a set of record. All these elements are Access objects and are stored together in the database.
Microsoft Access is a powerful program to create and manage your databases. In Access terms, a database is a collection of all the tables, queries, forms, data access pages, reports, macros, and modules that compose a complete system. Relational refers to the fact that the tables that comprise the database relate to one another.
Hierarchy that Microsoft Access uses in breaking down a database
This is your main file that encompasses the entire database and that is saved to your hard-drive or floppy disk. Example StudentDatabase.mdb
A table is a collection of data about a specific topic. There can be multiple tables in a database. Example #1) Students Example #2) Teachers
Fields are the different categories within a Table. Tables usually contain multiple fields. Example #1) Student LastName Example #2) Student FirstName
Datatypes are the properties of each field. A field only has 1 datatype.
After starting Access, create a new database or open an existing database. A database is stored as a file on your computer or on a network computer. To work with the objects in a database, one must open the database file. To open an existing database , follow these steps:
When Microsoft Access first starts up, a dialog box is automatically displayed with options to create a new database or open an existing one. If this dialog box is displayed, click Access Database Wizards, pages, and projects and then click OK.
On the Databases tab, double-click the icon for the kind of database you want to create.
A table is a collection of data about a specific topic, such as students or contacts. Using a separate table for each topic means that you store that data only once, which makes your database more efficient, and reduces data-entry errors. Tables organize data into columns (called fields) and rows (called records).
One or more fields (columns) whose value or values uniquely identify each record in a table. A primary key does not allow Null values and must always have a unique value. A primary key is used to relate a table to foreign keys in other tables. For Example., make the Soc Sec # field the primary key, meaning that every student has a social security number and no 2 are the same. To do this, simply select the Soc Sec # field and select the primary key button
After setting up multiple tables in your Microsoft Access database, we need a way of telling Access how to bring that information back together again. The first step in this process is to define relationships between your tables. After this, one can create queries, forms, and reports to display information from several tables at once. A relationship works by matching data in key fields - usually a field with the same name in both tables. In most cases, these matching fields are the primary key from one table, which provides a unique identifier for each record, and a foreign key in the other table. For example, teachers can be associated with the students they're responsible for by creating a relationship between the teacher's table and the student's table using the Teacher ID fields.
It is a good idea to create a form using the wizard, unless you are an advanced user and know what you are doing. Microsoft Access does a very good job of creating a form using the wizard. The following steps are needed to create a basic form:
Switch to the Database Window. You can do this by pressing F11 on the keyboard.
Click on the Forms button under Objects on the left side of screen
Double click on Create Form Using Wizard
On the next screen select the fields you want to view on your form.Click Next
Select the layout you wish
Select the style you desire. Click Next
Give you form a name, and select Open the Form and enter information
You should see your form. To adjust the design of your form, simply hit the design button (same as with the tables), and adjust your form accordingly
A report is an effective way to present your data in a printed format. Because you have control over the size and appearance of everything on a report, you can display the information the way you want to see it. If forms are for input, then reports are for output. Anything you plan to print deserves a report, whether it is a list of names and addresses, a financial summary for a period, or a set of mailing labels. Again the Access Wizards walk you through the process of defining reports.
Switch to the Database Window. You can do this by pressing F11 on the keyboard.
Click on the Reports button under Objects on the left side of screen
Double click on Create Report Using Wizard
On the next screen select the fields you want to view on your form. Most of the time you would select all of them.
Select if you would like to group your files. Keep repeating this step for as many groupings as you would like.
Select the layout and the paper orientation you desire. Click Next
Select the style you desire..Click Next
Give you report a name, and select Preview the Report
A number of characteristics distinguish the database approach from the traditional approach of programming with files. In traditional file processing, each user defines and implements the files needed for a specific application as part of programming the application. For example, one user, the grade reporting office, may keep a file on students and their grades. Programs to print a student’s transcript and to enter new grades into the file are implemented. A second user, the accounting office, may keep track of students’ fees and their payments. Although both users are interested in data about students, each user maintains separate files—and programs to manipulate these files—because each requires some data not available from the other user’s files. This redundancy in defining and storing data results in wasted storage space and in redundant efforts to maintain common data up-to-date. In the database approach, a single repository of data is maintained that is defined once and then is accessed by various users. The main characteristics of the database approach versus the file-processing approach are the following.
A fundamental characteristic of the database approach is that the database system contains not only the database itself but also a complete definition or description of the database structure and constraints. This definition is stored in the system catalog, which contains information such as the structure of each file, the type and storage format of each data item, and various constraints on the data. The information stored in the catalog is called meta-data, and it describes the structure of the primary database. The catalog is used by the DBMS software and also by database users who need information about the database structure. A general purpose DBMS software package is not written for a specific database application, and hence it must refer to the catalog to know the structure of the files in a specific database, such as the type and format of data it will access. The DBMS software must work equally well with any number of database applications—for example, a university database, a banking database, or a company database—as long as the database definition is stored in the catalog.
Insulation between Programs & Data and Data Abstraction
In traditional file processing, the structure of data files is embedded in the access programs, so any changes to the structure of a file may require changing all programs that access this file. By contrast, DBMS access programs do not require such changes in most cases. The structure of data files is stored in the DBMS catalog separately from the access programs. We call this property program-data independence. In object-oriented and object-relational databases, users can define operations on data as part of the database definitions. An operation (also called a function) is specified in two parts. The interface (or signature) of an operation includes the operation name and the data types of its arguments. The implementation (or method) of the operation is specified separately and can be changed without affecting the interface. User application programs can operate on the data by invoking these operations through their names and arguments, regardless of how the operations are implemented. This may be termed program-operation independence. The characteristic that allows program-data independence and program-operation independence is called data abstraction.
A database typically has many users, each of whom may require a different perspective or view of the database. A view may be a subset of the database or it may contain virtual data that is derived from the database files but is not explicitly stored. Some users may not need to be aware of whether the data they refer to is stored or derived. A multi-user DBMS whose users have a variety of applications must provide facilities for defining multiple views.
Sharing of Data and Multi user Transaction Processing
A multi user DBMS, as its name implies, must allow multiple users to access the database at the same time. This is essential if data for multiple applications is to be integrated and maintained in a single database. The DBMS must include concurrency control software to ensure that several users trying to update the same data do so in a controlled manner so that the result of the updates is correct. For example, when several reservation clerks try to assign a seat on an airline flight, the DBMS should ensure that each seat can be accessed by only one clerk at a time for assignment to a passenger. These types of applications are generally called on-line transaction processing (OLTP) applications.
End users are the people whose jobs require access to the database for querying, updating, and generating reports; the database primarily exists for their use. There are several categories of end users:
Casual end users - occasionally access the database, but they may need different information each time. They use a sophisticated database query language to specify their requests and are typically middle- or high-level managers or other occasional browsers.
Naive or parametric end users make up a sizable portion of database end users. Their main job function revolves around constantly querying and updating the database, using standard types of queries and updates—called canned transactions—that have been carefully programmed and tested. The tasks that such users perform are varied:
Bank tellers check account balances and post withdrawals and deposits.
Reservation clerks for airlines, hotels, and car rental companies check availability for a given request and make reservations.
Sophisticated end users - include engineers, scientists, business analysts, and others who thoroughly familiarize themselves with the facilities of the DBMS so as to implement their applications to meet their complex requirements.
Stand-alone users - maintain personal databases by using ready-made program packages that provide easy-to-use menu- or graphics-based interfaces. An example is the user of a tax package that stores a variety of personal financial data for tax purposes.
In traditional software development utilizing file processing, every user group maintains its own files for handling its data-processing applications. For example, consider the UNIVERSITY database; here, two groups of users might be the course registration personnel and the accounting office. In the traditional approach, each group independently keeps files on students. The accounting office also keeps data on registration and related billing information, whereas the registration office keeps track of student courses and grades. Much of the data is stored twice: once in the files of each user group. Additional user groups may further duplicate some or all of the same data in their own files. This redundancy in storing the same data multiple times leads to several problems. First, there is the need to perform a single logical update—such as entering data on a new student—multiple times: once for each file where student data is recorded. This leads to duplication of effort. Second, storage space is wasted when the same data is stored repeatedly, and this problem may be serious for large databases. Third, files that represent the same data may become inconsistent. This may happen because an update is applied to some of the files but not to others.
Restricting Unauthorized Access-
When multiple users share a database, it is likely that some users will not be authorized to access all information in the database. For example, financial data is often considered confidential, and hence only authorized persons are allowed to access such data. In addition, some users may be permitted only to retrieve data, whereas others are allowed both to retrieve and to update. Hence, the type of access operation—retrieval or update—must also be controlled. Typically, users or user groups are given account numbers protected by passwords, which they can use to gain access to the database. A DBMS should provide a security and authorization subsystem, which the DBA uses to create accounts and to specify account restrictions. The DBMS should then enforce these restrictions automatically. Notice that we can apply similar controls to the DBMS software.
One fundamental characteristic of the database approach is that it provides some level of data abstraction by hiding details of data storage that are not needed by most database users. A data model is a collection of concepts that can be used to describe the structure of a database and provides the necessary means to achieve this abstraction. By structure of a database we mean the data types, relationships, and constraints that should hold on the data. Most data models also include a set of basic operations for specifying retrievals and updates on the database. In addition to the basic operations provided by the data model, it is becoming more common to include concepts in the data model to specify the dynamic aspect or behavior of a database application. This allows the database designer to specify a set of valid user-defined operations that are allowed on the database objects.
Many data models have been proposed, and we can categorize them according to the types of concepts they use to describe the database structure.
High-level or conceptual data models- provide concepts that are close to the way many users perceive data.
Low-level or physical data models- provide concepts that describe the details of how data is stored in the computer.
Concepts provided by low-level data models are generally meant for computer specialists, not for typical end users. Between these two extremes is a class of representational (or implementation) data models, which provide concepts that may be understood by end users but that are not too far removed from the way data is organized within the computer. Representational data models hide some details of data storage but can be implemented on a computer system in a direct way.
The collection of files permanently stored on secondary storage devices is known as the physical database. The physical or internal level is the one closest to physical storage, and it provides a low-level description of the physical database, and an interface between the operating system's file system and the record structures used in higher levels of abstraction. It is at this level that record types and methods of storage are defined, as well as how stored fields are represented, what physical sequence the stored records are in, and what other physical structures exist.
The conceptual level presents a logical view of the entire database as a unified whole, which allows you to bring all the data in the database together and see it in a consistent manner. The first stage in the design of a database is to define the conceptual view, and a DBMS provides a data definition language for this purpose. It is the conceptual level that allows a DBMS to provide data independence. The data definition language used to create the conceptual level must not specify any physical storage considerations that should be handled by the physical level. It should not provide any storage or access details, but should define the information content only.
The external or view level provides a window on the conceptual view which allows the user to see only the data of interest to them. The user can be either an application program or an end user. Any number of external schema can be defined and they can overlap each other. Because they have responsibilities for the design and maintenance for the design and maintenance of the database, they at times need to be able to see the entire database. The external and the conceptual view are functionally equivalent for these two users.
The three-schema architecture can be used to explain the concept of data independence, which can be defined as the capacity to change the schema at one level of a database system without having to change the schema at the next higher level. 2 types of data independence:
Logical data independence is the capacity to change the conceptual schema without having to change external schemas or application programs. We may change the conceptual schema to expand the database, or to reduce the database. In the latter case, external schemas that refer only to the remaining data should not be affected. Only the view definition and the mappings need be changed in a DBMS that supports logical data independence. Application programs that reference the external schema constructs must work as before, after the conceptual schema undergoes a logical reorganization. Changes to constraints can be applied also to the conceptual schema without affecting the external schemas or application programs.
Physical data independence is the capacity to change the internal schema without having to change the conceptual (or external) schemas. Changes to the internal schema may be needed because some physical files had to be reorganized—for example, by creating additional access structures—to improve the performance of retrieval or update. If the same data as before remains in the database, we should not have to change the conceptual schema. For example, providing an access path to improve retrieval of SECTION records by Semester and Year should not require a query such as "list all sections offered in fall 1998" to be changed, although the query would be executed more efficiently by the DBMS by utilizing the new access path.