September 21, 2012

R Language & esProc to Implement SQL Join and Distinct etc. Functions


Every SQL users know that one has to finish composing all SQL codes and then run them all at one time, resulting in a poor ability for interactctive data analytics. However, the simple and easy-to-understand query syntax of SQL is always welcomed by programmers. Apowerful computation and analysis tools, R language and esProc are surely need to offer the similar query syntax. In the last SQL basic functions article, we have discuss implement basic SQL functions like retrieve data of the entire table, where, order, group & sum. Let’s talk more today.



The example data is from 2 tables of the classical Northwind database:
Orders table with the main fields: OrderID, EmployeeID, OrderDate, Freight, CustomerID
Customer table with the main fields: CustomerID, CompanyName

Join:  Perform left join on Orders table and Customers table by CustomerID.
SQL Solution:
Select * from Orders left join Customers on Orders.CustomerID =Customers.CustomerID
esProc solution:
=join@1(A1:CustomerID:Orders, B1:CustomerID:Customers)
R solution:
merge(A1,B1,by.x="CustomerID",by.y="CustomerID",all.x=TRUE)
Comments: The join of SQL equals to join of esProc or the merge of R. Similarly, the left join of SQL equals to join@1 of esProc, or merge(...all.x=TRUE) of R. Obviously, esProc is more alike SQL in the respects of both the syntax conventions and the literal meanings. 

Distinct: Remove the duplicate CustomerID
SQL solution: select distinct CustomerID from Orders
R solution: unique(B2$CustomerID)
esProc solution: =B2.id(CustomerID)
Comments: The keywords of the two solutions respectively differ to that of SQL. However, their usages are basically the same to that of SQL. In which, R is the typical function style, and esProc is the typical object style.

Like: Search for the record with Island in ShipName
SQL solution: select * from Orders where ShipName like '%Island%'
R solution: subset(A1,grepl("Island",ShipName,ignore.case = TRUE))
esProc solution: =A1.select(like@c(ShipName ,"*Island*"))
Comments: R supports several means to match, including the regular expressions, and is more powerful than esProc in this respect. The usages of esProc are more close to that of SQL, and fit for those who are familiar with SQL.

When come to complex data calculation, SQL is replaceable in some aspects actually. Just as you see from above comparison, esProc has a coding style more close to that of SQL. 

R is more resourceful in details, ideal for the programmers and mathematicians. In addition, supporting the regular expressions and other functions makes R more open as a preferred analysis tool for programmers.  

September 12, 2012

Implement SQL Basic Functions through R Language & esProc


It is known to us that SQL users have to finish composing all codes and then run them all at one time, resulting in a poor ability for interactctive data analytics. However, the simple and easy-to-understand query syntax of SQL is always welcomed by programmers. As powerful computation and analysis tools, R language and esProc are surely need to offer the similar query syntax. In this article, let's discuss how to implement the basic functions of SQL through R language and esProc with some examples.

The example data is from 2 tables of the classical Northwind database:
Orders table with the main fields: OrderID, EmployeeID, OrderDate, Freight, CustomerID
Customer table with the main fields: CustomerID, CompanyName




Retrieve data of the entire table

SQL solution: select * from Orders
R solution: A1<-sqlQuery(conn,'select * from Orders')
esProc solution: $select * from Orders
Comments: The word count of esProc and SQL codes only differs by one word. The R language has a strong flavor of programming. 

Where: Search for the order which has a freightage higher than 100 and is placed before the year of 1998

SQL solution: SELECT * FROM Orders WHERE Freight > 100 AND OrderDate < '1998-01-01'
R solution: subset(A1,Freight > 100 & OrderDate < as.POSIXlt('1998-01-01'))
esProc solution: =A1.select(Freight > 100 && OrderDate < date("1998-01-01"))
Comments: Both SQL and R solutions are close to SQL to some extent. R is of the typical function style, and esProc is of the typical object style. The programmers prefer the former, while the business experts or analysts prefer the latter esProc, for esProc is easier for them to understand.

Order: Sort by employees correctly, and then sort by freightage in reverse order

SQL solution: SELECT * FROM Orders ORDER BY EmployeeID ,Freight DESC
R solution: A1[order(A1$ EmployeeID,-A1$Freight),]
esProc solution: =A1.sort(EmployeeID,Freight:-1)
Comments:  
The R solution is to retrieve 2 vectors from A1 at first, pass them to the function order to group them together for sorting, and then export the serial numbers. At last, data will be rearranged according to the serial number. The computation process of R language is rather winding, not as straightforward as SQL. It is because that R is good at handling vector, the access to structured data will take column as the basic unit, and the parameter usually takes up a whole column. By comparison, SQL takes the record (column) as the basic unit, with parameter as the column name.
esProc solution resembles that of SQL because esProc takes the record (row) as the basic unit .

Group & Sum: Summarize by employee, sum up the freightage, and count the orders:

SQL solution: SELECT EmployeeID, COUNT(OrderID), SUM(Freight) FROM Orders GROUP BY EmployeeID
esProc solution: =A1.group(EmployeeID; EmployeeID, ~.count(), ~.sum(Freight))
R solution:
A4<-aggregate(A1$Freight,list(A1$EmployeeID),sum)  
A4$count<-tapply(A1$Freight,A1$EmployeeID,length)
Comments: In this case, it is obvious that R and SQL differ greatly. The algorithms available in R may be clearer for mathematicians, and means more learning efforts for users accustomed to SQL.

SQL: http://www.sql.org/
R: http://en.wikipedia.org/wiki/R_%28programming_language%29
esProc: http://www.raqsoft.com/products

From the above functions, when come to SQL data computing and complex data calculation, SQL is replaceable in some aspects actually. We can see from the above comparison, esProc has a coding style more close to that of SQL since esProc supports the data structure of “Record” by the infrastructure, making it more suitable for users that are familiar with SQL. In addition, compared with R language, esProc provides the representation style of “object + functions” that is much easier for business experts to accept for financial data analytics, marketing and sales data analysis.

R is more resourceful in details, ideal for the programmers and mathematicians. In addition, supporting the regular expressions and other functions makes R more open as a preferred analytics tool for programmers.

September 6, 2012

Interactive Analytics and OLAP - Part III


In the part ii of interactive analytics and OLAP, we leave a question: can the narrowed OLAP be used to complete the computation process as follows (marketing and sales data analysis)?

 The first n customers whose purchases from the company account for half of the sales volume of the company of the current year;
 The stocks which go up to the limit for three consecutive days within one month;
 Commodities in the supermarket which are sold out at 5 P.M for three times within one month;
 Commodities whose sales volumes in this month have decreased by more than 20% over those of the preceding month;
       … 
       Of course NOT!
Currently OLAP system has two key disadvantages:
The multi-dimensional cube is prepared in advance by the application system and user does not have the capability to temporarily design or reconstruct the cube, so once there is new analysis demand, it is necessary to re-create the analytics cube.
The analysis actions could be implemented by cube are rather monotonous. The defined actions are quite few, such as the drilling, aggregating, slicing, and pivoting. The complicated analysis behavior requiring multi-steps is hard to implement.
Although the current OLAP tools are splendid regarding its look and feel, few on-line analysis capabilities powerful enough are provided actually.

       Then, what kind of OLAP do we need? What kind of OLAP tools we need?
       It is very simple, and we need a kind of on-line analytical system that can support evaluation process, which SQL data computing or excel computation can handle.

       Technically speaking, steps for evaluation process can be regarded as computation regarding data (query can be understood to be filter computation). This kind of computation can be freely defined by user and user can occasionally decide the next computation action according to the existing intermediate result, without having to model beforehand. Additionally, as data source is generally database system, it is necessary to require this kind of computation to be able to very well support mass structured data (tools like esProcinstead of simple numeric computation. And evaluation process is what business need especially in marketing and sales data analysis.

       Then, can SQL (or MDX) play this role?
       SQL is indeed invented for this aim and it owns complete computation capability and it adopts a writing style similar to natural language.
But, as SQL computation system is too basic, it is very difficult and over-elaborate to achieve complex computation by a SQL data computing, such as problems listed in the preceding paragraphs. It is even not so easy for programmers who have received professional training, so ordinary users can only use SQL to implement some of the simplest queries and aggregate computation (based on the filter and summarization of a single table). This result leads to the fact that the application of SQL has already deviated far away from its original intention of invention, almost becoming the expertise for programmers.
We should follow the working thought of SQL to carefully study the specific disadvantage of SQL and find the way to overcome it in an effort to develop a new generation of computation system, thereby implementing the evaluation process, namely, the real OLAP, instant data analytics.
 Sponsored by Raqsoft.
Related Articles:

September 3, 2012

Interactive Analytics and OLAP - Part II


After the first stage of real application process of the OLAP in interactive analytics and OLAP - Part I, we will start OLAP application of stage 2. 
Interactive Analytics & OLAP

Those guesses in part i of interactive data analytics are just the basis for forecast. After operating for a period of time, a constructed business system can also accumulate large quantities of data (so called complex data calculation), and these guesses have most probably been evaluated by these accumulated data, when evaluated to be true, they can be used in forecast; when evaluated to be false they will be re-guessed.


 It needs to be noted that these guesses are made by users themselves instead of the computer system! Instant data analytics is started by human being in OLAP. What a computer should do is to help a user to evaluate according to the existing data, the guess to be true or false, namely, on-line data query (including certain aggregation computation). This is just the application process of OLAP. The reason why on-line analysis is needed is that many query computations are temporarily required after a user has seen a certain intermediate result. In the whole process, model in advance is impossible and unnecessary (Raqsoft esProc is born to deal with these issues).

 We call the above process evaluation process, whose purpose is to find from historical data some laws or evidences for conclusions, and the means adopted is to conduct interactive query computation on historical data. And this process can be a complex data calculation.

       The following are a few examples actually requiring computations (or queries):
       The first n customers whose purchases from the company account for half of the sales volume of the company of the current year;
       The stocks which go up to the limit for three consecutive days within one month;
       Commodities in the supermarket which are sold out at 5 P.M for three times within one month;
       Commodities whose sales volumes in this month have decreased by more than 20% over those of the preceding month;
       …

Evidently, this type of computation demand is ubiquitous in business analysis process and all can be computed out from historical database.

Then, can the narrowed OLAP be used to complete the above-mentioned data computation process?
In the third part of Interactive Analytics and OLAP, i will answer the question above.
To be continued... 

Related Articles:

Interactive Analytics and OLAP - Part I