Relational query languages provide a highlevel "declarative" interface to access data storedin relational databases. Over time, SQL [1,4] has emergedas the standard for relational query languages. Two keyelements of the component of the evaluation of a systemfor querying SQL databases are the query optimizer andexecution engine queries. The query execution engineimplements a set of physical operators. An operator takesas input one or more data streams and producesan output data stream. Examples of operators are physical(external) sorting, sequential analysis, index analysis,nested loop join and sort-merge join. We refer to operatorssuch as physical operators since they are notnecessarily related one by one with the relational operators.The easiest way to think of physical operators is like piecesof code that are used as building blocks to enable theexecution of SQL queries. An abstract representation of such a performance is a physical operator tree, as shown inFigure 2. The edges in an operator tree represent theflow of data between the physical operators.We use the terms physical operator tree and executionplan (or simply plan) interchangeably. The executionengine is responsible for implementing the plan resultinggenerate responses to the request. Therefore, theCapabilities of the query execution engine to determinethe structure of the operator trees that arepracticable. We refer the reader to  for an overview of the technical evaluation of the query. The queryoptimizer is responsible for producing the input for theexecution engine. It takes a parsed representation of anSQL query as input and is responsible forproducing an efficient execution plan for the given SQLquery in the space of possible execution plans. The task of an optimizer is nontrivial since for a given SQL query,there may be many operator trees possible:• The algebraic representation of the data query can betransformed into many other logically equivalent algebraicrepresentations: for example,Join (Join (P, Q), R) = Join (Join (Q, R), P)• For a given algebra representation, there can be manyoperator trees that the operator algebraic expression toperform, for example, in general, there areseveral algorithms supported them in a system database. Inaddition, the current or the response time for theimplementation of these plans is verydifferent. Therefore, a choice of execution by theoptimization program is crucial. For instance, queryoptimizations are regarded as difficult search. To solve thisproblem, we need:• A space of plans (search space).• A cost estimation technique so that a cost may beassigned to each plan in the search space. Intuitively, this isan estimation of the resources needed for the execution of the plan.• An enumeration algorithm that can search through theexecution space A desirable optimizer is one wherethe search space includes plans to lower costs, the costingtechnique is correct and the enumeration algorithm eff-icient. Each of these tasks is nontrivial and that iswhy building a good optimizer is a huge undertaking.
Query AnalyzerQuery OptimizerCode Generator/InterpreterQuery Processor
Figure 3: Query traverses through DBMS
Index Nested Loop(P,z=R,z)Merge_Join(Pz=Qz)Index Scan RMerge_Join(Pz=Qz)Merge_Join(Pz=Qz)Table Scan
Figure 2: Physical Operator Tree
(IJCSIS) International Journal of Computer Science and Information Security,Vol. 9, No. 10, October 2011103http://sites.google.com/site/ijcsis/ISSN 1947-5500