SQL Unit - 1
SQL Unit - 1
Unit – 4
Database Design
1. 3 Define Objectives :
Thus, the scope and boundaries become the factors that force the
design into a specific mold, and the designer’s job is to design the best
system possible within those constraints.
Database Life Cycle (DBLC)
2. Database Design:
Database Life Cycle (DBLC)
2. Database Design:
The second phase focuses on the design of the database model that
will support company operations and objectives. This is arguably the
most critical DBLC phase: making sure that the final product meets
user and system requirements.
At this point, there are two views of the data within the system: the
business view of data as a source of information and the designer’s
view of the data structure, its access, and the activities required to
transform the data into information. Consider the following Figure to
contrasts those views.
Database Life Cycle (DBLC)
2. Database Design:
Database Life Cycle (DBLC)
2. Database Design:
Database Life Cycle (DBLC)
2. Database Design:
Database Life Cycle (DBLC)
2. Database Design:
Database Life Cycle (DBLC)
2. Database Design:
1. Cost:
2. DBMS features and tools:
3. Underlying model:
4. Portability:
5. DBMS hardware requirements:
Database Life Cycle (DBLC)
2. Database Design:
III. Logical Design:
Database Life Cycle (DBLC)
Database Life Cycle (DBLC)
Given a query, there are generally a variety of methods for computing
the answer. For example, we have seen that, in SQL, a query could be
expressed in several different ways. Each SQL query can itself be
translated into a relational-algebra expression in one of several ways.
Furthermore, the relational-algebra representation of a query specifies
only partially how to evaluate a query; there are usually several ways
to evaluate relational-algebra expressions. As an illustration, consider
the query:
select balance from account where balance < 2500
The response time for a query-evaluation plan (that is, the clock time
required to execute the plan), assuming no other activity is going on
the computer, would account for all these costs, and could be used as a
good measure of the cost of the plan.
Basic Algorithms :
A1. Linear search
In a linear search, the system scans each file block and tests all records
to see whether they satisfy the selection condition. Selections on key
attributes have an average cost of br/2, but still have a worst-case cost
of br.
We can sort a relation by building an index on the sort key, and then
using that index to read the relation in sorted order. However, such a
process orders the relation only logically, through an index, rather than
physically.
Hence, the reading of tuples in the sorted order may lead to a disk
access for each record, which can be very expensive, since the number
of records can be much larger than the number of blocks. For this
reason, it may be desirable to order the records physically.
1. In the first stage, a number of sorted runs are created; each run is
sorted, but contains only some of the records of the relation.
i = 0;
repeat
read M blocks of the relation, or the rest of the
` relation, whichever is smaller;
sort the in-memory part of the relation;
write the sorted data to run file Ri;
i = i + 1;
until the end of the relation
Query Processing
Sorting:
2. In the second stage, the runs are merged. Suppose, for now, that the
total number of runs, N, is less than M,
read one block of each of the N files Ri into a buffer page in memory;
repeat
choose the first tuple (in sort order) among all buffer pages;
write the tuple to the output, and delete it from the buffer
page;
if the buffer page of any run Ri is empty and not end-of-
file(Ri)
then read the next block of Ri into the buffer page;
until all buffer pages are empty
In our example, the inputs to the join are the customer relation and the
temporary relation created by the selection on account. The join can now be
evaluated, creating another temporary relation. By repeating the process, we
will eventually evaluate the operation at the root of the tree, giving the final
result of the expression. In our example, we get the final result by executing
the projection operation at the root of the tree, using as input the temporary
relation created by the join.