The document provides an overview of advanced modeling techniques in SQLScript, including data type extensions that allow defining table types, functional extensions that allow defining functions, and procedural extensions that provide imperative constructs. It describes SQLScript's capabilities like pushing data intensive logic into the database, encouraging set-oriented programming. Key concepts covered include table types, procedures, calculation views, relational operators, and functional logic constructs like IF/ELSE statements.
1 of 44
Download to read offline
More Related Content
ADVANCED MODELLING.pptx
1. ADVANCED MODELLING
Modeling Overview
Calculation View: Overview & Types
SQL Script: Motivation
SQL Script: Overview
SQL Script Processing
Data Type Extensions
Scalar Data type
Table type
Functional Extension
Concept
Procedure
Procedure Calls
Implementing Functional logic
Operators
SQL Script/Built in Function
Debugging and troubleshooting SQL Script
Restrictions for SQL Statement
5. SELECT
The FOR UPDATE clause locks the selected rows so that other
users cannot lock or update the rows until the end of this
transaction. The TIME TRAVEL clause is used for statement level
time travel to go back to the snapshot specified by commit_id or
timestamp.
7. SQL SCRIPT Motivation
SQLScript is a collection of extensions to Structured Query Language or SQL.
The main motivation for SQLScript is to embed data intensive application logic
into the database, in contrast to a traditional approach where the application logic
is normally executed in an application server.
The various extensions to SQL provided by SQLScript:
Data Extensions allow the definition of table types without corresponding tables.
Functional Extensions allow definitions of functions which can be used to
express and encapsulate complex data flows.
Procedural Extensions provide imperative constructs executed in the context of
the database process.
SQLScript
Allows developer to push data intensive logic into the database;
Encourages developer to implement algorithms using a set-oriented paradigm
instead of one tuple at a time paradigm; and allows usage of imperative as well as
declarative statements.
10. DATA TYPE EXTENSIONS
SQLScripts data type extension allows the definition of table types. These table
types are used to define parameters for a procedure that represent tabular results.
You can create a table type by using the CREATE TYPE and delete a table type
by using DROP TYPE.
SQLScripts allow the definition of table types. These table types are used to
define parameters for a procedure that represent tabular results.
15. PROCEDURES
Create a procedure using the New SQL Procedure wizard. You can start the
New SQL Procedure wizard from the context menu of the package. Right-
click the package and choose New > Procedure, and the New SQL
Procedure wizard appears.
In the New SQL Procedure wizard, provide creation parameters. Next, set the
value of the attribute Run With to select the security mode.
Default schema is used for object name qualification.
21. ADVANCED MODELLING
Calculation engine is the execution engine for SQLScript. SQLScript
statements are parsed into calculation model as much as possible. The
calculation engine instantiates a calculation model at the time of query
execution.
Nodes for set operations include projection, aggregation, join, union, minus,
and intersection.
The SQL nodes that execute an SQL statement are an attribute of the node.
Nodes of type R-operation are used for statistical calculations. The
calculation performed by such a node is described using the R language for
statistical computing.
25. CALCULATION VIEW
Data source access functions bind the column table or column view of a data
source to a table variable. This enables reference by other built-in functions or
statements in a SQLScript procedure. Attributes cannot be renamed using data
access operator.
The CE_COLUMN_TABLE operator provides access to an existing column
table. It takes the name of the table and returns its content bound to a variable.
Optionally, you can also provide a list of attribute names to restrict the output to
the given attributes.
Many of the Calculation Engine operators provide a projection list for restricting
the attributes returned in the output. In the case of relational operators, the
attributes may be renamed in the projection list. The functions that provide data
source access do not rename the attributes but provide a simple projection
26. CALCULATION VIEW
The CE_JOIN_VIEW operator returns results for an existing attribute view. It takes
the name of the attribute view and an optional list of attributes as parameters of such
views/models.
27. CALCULATION VIEW
The CE_OLAP_VIEW operator returns results for an Analytic View. It takes
the name of the Analytic View and an optional list of key figures and
dimensions as parameters.
The Analytic View is grouped by the given dimensions. The key figures are
aggregated using the default aggregation of the Analytic View.
30. RELATIONAL OPERATORS
Relational operator provides the functionality which are directly executed in the
Calculation Engine. This allows exploitation of the specific semantics of the
Calculation Engine and to tune the code of a procedure if required.
The CE_JOIN operator calculates a natural or inner join of the given pair of
tables on a list of join attributes. For each pair of join attributes, only one
attribute will be in the result. Optionally, you can also give a projection list of
attribute names to restrict the output to the given attributes. If you provide a
projection list, it must include the join attributes.
Finally, the plan operator requires each pair of join attributes to have identical
attribute names. However, if any join attributes have different names, one of
them must be renamed prior to the join.
32. RELATIONAL OPERATORS
The CE_PROJECTION operator restricts the columns of the table variable to
those mentioned in the projection list. Optionally, it renames columns, computes
expressions, or applies a filter.
The Calculation Engine plan operator, CE_PROJECTION, takes three parameters
as input:
A variable of type table which is subject to the projection. For example, CE_JOIN,
CE_PROJECTION cannot handle tables directly as input.
A list of attributes which should be in the resulting table. The list must at least
have one element. The attributes can be renamed using the SQL keyword AS and
expressions can be evaluated using the CE_CALC function.
An optional filter where Boolean expressions are allowed as defined for the
CE_CALC operator.
In this operator, the projection in 2nd parameter is applied first including column
renaming and computation of expressions. As last step, the filter is applied.
34. RELATIONAL OPERATORS
CE_CALC operator is used inside other operators. It evaluates an expression
and is usually bound to a new column. The CE_CALC operator evaluates
expressions in the CE_PROJECTION function. The CE_CALC function
takes two arguments:
The expression enclosed in single quotes.
The result type of the expression as an SQL type.
The CE_CALC operator also helps computing row numbers.
36. RELATIONAL OPERATORS
The CE_AGGREGATION operator groups the input and computes
aggregates for each group.
The aggregation operator takes three input parameters:
A variable of type table containing the data that should be aggregated.
CE_AGGREGATION cannot handle tables directly as input.
A list of aggregates. For example, [SUM (A), MAX (B)] specifies that
in the result, column A has to be aggregated using the SQL aggregate
SUM, and for column B, the maximum value should be given.
An optional list of group-by attributes. For example, [C] specifies that
the output should be grouped by column; that means, the resulting
schema has a column named C in which every attribute value from the
input table appears exactly once. If this list is absent, the entire input table
should be treated as a single group and the aggregate function is applied
to all tuples.
The final parameter is optional. Note that CE_AGGREGATION implicitly
defines a projection. All columns that are not in the list of aggregates or in
the group-by list are not part of the result.
38. RELATIONAL OPERATORS
The CE_UNION_ALL function is semantically equivalent to SQL
UNION ALL statement. It computes the union of two tables, which
need to have identical columns. The CE_UNION_ALL function
preserves duplicates; that means that the result is a table, which
contains all the rows from both input tables.
40. FUNCTIONAL LOGIC
The IF statement consists of a Boolean expression. If this expression
evaluates to true, then the statements in the mandatory block are
executed. The IF statement ends with END IF, and the remaining
parts are optional.
However, if the Boolean expression does not evaluate to true, then
the ELSE branch is evaluated. In most cases, this branch starts with
ELSE. The statements are executed without further checks. After an
ELSE branch, no further ELSE branch or ELSEIF branch is allowed.
Alternatively, when ELSEIF is used instead of ELSE, another Boolean
expression is evaluated. If it evaluates to true, the statements are
executed. In this manner, an arbitrary number of ELSEIF clauses can
be added. This statement can be used to simulate the switch-case
statement known from many programming languages.
42. FUNCTIONAL LOGIC
The WHILE loop executes the statements in the body of the loop
only when the Boolean expression at the beginning of the loop
evaluates to true.
The FOR loop iterates a range of numeric values and binds the
current value to a variable in ascending order. The numeric values
are denoted by start and end in the syntax. Iteration starts with
value start and is incremented by one until the loop-var is larger
than end. Hence, if start is larger than end, the body loop will not be
evaluated. For each enumerated value of the loop variable, the
statements in the body of the loop are evaluated. The optional
keyword REVERSE specifies to iterate the range in descending
order.
44. EXECUTE SQL
The EXEC statement executes SQL statements passed in a string
argument. This statement allows for constructing an SQL statement
at execution time of a procedure. Thus, on the one hand, dynamic
SQL allows using variables where they might not be supported in
SQLScript. It provides more flexibility in creating SQL statements.
On the other hand, dynamic SQL comes with an additional cost at
runtime.
In Dynamic SQL, the opportunities for optimizations are limited.
The statement is potentially recompiled every time the statement is
executed. You cannot use SQLScript variables in the SQL statement;
however, it is possible while constructing the SQL statement string.
You cannot bind the result of a dynamic SQL statement to an
SQLScript variable. You must be very careful to avoid SQL injection
bugs that might harm the integrity or security of the database.