Ms Access and Dtbse Fundamentals
Ms Access and Dtbse Fundamentals
Index
Introduction
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.
• Database File
This is your main file that encompasses the entire database and that is saved to your hard-drive or floppy
disk.
Example StudentDatabase.mdb
Database File
• Table
A table is a collection of data about a specific topic. There can be multiple tables in a database. Table
Example #1) Students
Example #2) Teachers
• Field Field
Fields are the different categories within a Table. Tables usually contain multiple fields.
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).
• Primary Key
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
Defining Relationships
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.
In the database window view, at the top, click on Tools ---> Relationships
Select the Tables you want to link together, by clicking on them and selecting the Add Button
Drag the primary key of the Parent table (Teacher in this case), and drop it into the same field in the Child
table (Student in this case)
Select Enforce Referential Integrity
When the Cascade Update Related Fields check box is set, changing a primary key value in the primary
table automatically updates the matching value in all related records.
When the Cascade Delete Related Records check box is set, deleting a record in the primary table deletes
any related records in the related table
Click Create and Save the Relationship
Creating a Form
• 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
Click Next
Select the style you desire. Click Next
Give you form a name, and select Open the Form and enter information
Select Finish
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
Creating a Report
• 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.
Click Next
Select if you would like to group your files. Keep repeating this step for as many groupings as you would like.
Click Next
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
Select Finish
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.
Characteristics of DBMS
Characteristics of DBMS
• 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.
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.
• Controlling Redundancy
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.
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.
An entity represents a real-world object or concept, such as an employee or a project, that is described in
the database.
An attribute represents some property of interest that further describes an entity, such as the employee’s
name or salary.
A relationship among two or more entities represents an interaction among the entities; for example, a
works-on relationship between an employee and a project
DBMS Architecture
• The three-schema architecture, which was proposed to help achieve and visualize these
characteristics.
Levels of DBMS
Levels of DBMS
Levels of DBMS
Data Independence
• 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.