PURPOSE
---------
STAR JOIN에 대해서 이해한다.

EXPLANATION
-----------

- 개요

star query는 oracle 7 server의 datawarehouse에서 폭넓게 사용되는 feature라
할 수 있다.
이 문헌에서는 star schema와 query를 정의하고 이들의 최적의 process와
Oracle7 이 어떻게 이 query를 address하는지를 check하도록 한다.

(1) star schema 란 무엇?

"star schema" 는 많은 datawarehouse 응용 program 을 위해 data 가 표현되는
방법이라 할 수 있다.

star schema는 1개의 큰 table (FACT table 이라 함.) 과 여러개의 작은 table
(DIMENSION table) 로 이루어져 있다.

예를 들어, 소매 상의 환경에서 star schema 가 다음과 같은 table 과 attribute로
구성될 수 있다.
:

SALES
CUSTOMER_KEY (references CUSTOMERS.CUSTOMER_KEY)
SKU_KEY (references SKU.SKU_KEY)
SUPPLIER_KEY (references SUPPLIERS.SUPPLIER_KEY)
STORE_KEY (references STORES.STORE_KEY)
DATE
QUANTITY
TOTAL_PRICE

multi-column B-tree index on (CUSTOMER_KEY, PART_KEY, SUPPLIER_KEY,
STORE_KEY)

CUSTOMERS
CUSTOMER_KEY
NAME
ADDRESS

SKUS
SKU_KEY
NAME
COST

SUPPLIERS
SUPPLIER_KEY
NAME
ADDRESS

STORES
STORE_KEY
ADDRESS


이 때 SALES 테이블은 각각의 구매건에 대한 data 를 포함하고 있기 때문에
(구매일, total 가격) 매우 큰 table 이고 하루에 몇 십만 건의 transaction 이
발생할 수 있다.

반면에 CUSTOMER, SKUS, SUPPLIERS, STORES 테이블은 SALES table 과 매우 적은
관계를 가지고 있다.

이 경우 SALES 가 FACT table 이고 나머지가 DIMENSION table 이다.
이 DIMENSION table은 서로의 관계가 적다. 그대신 FACT table 과 primary key/foreign key 도
관계를 맺고 있다 이를 star schema 라 한다.

(2) star query 가 무엇?

"star query" 는 star schema 를 query 하는 전형적인 방법으로
각 DIMENSION tabledl FACT table 과 primary key/foreign key로 join 되는
것이다.
그러므로 이 예제에서는 CUSTOMERS, SKUS, SUPPLIERS,STORES 가 SALES가 다음
처럼 join 된다. 아래는 SKU 의 total sales 를 계산하는 경우이다.

select
SUPPLIER.NAME,
STORE.NAME,
sum(TOTAL_SALES)
from
SALES,
CUSTOMERS,
SKUS,
SUPPLIERS,
STORES
where
SALES.CUSTOMER_KEY = CUSTOMERS.CUSTOMER_KEY and
SALES.SKU_KEY = SKUS.SKU_KEY and
SALES.SUPPLIER_KEY = CUSTOMERS.SUPPLIER_KEY and
SALES.STORE_KEY = STORES.STORE_KEY and
SALES.DATE between '01-AUG-94' and '01-SEP-94' and
CUSTOMERS.NAME in ('Customer A', 'Customer B') and
SKUS.NAME = 'SKU #1';
group by SUPPLIER.NAME, STORE.NAME;

이 query는 "query graph"로 표현될수 있다.
query graph 에서 , 노드는 table 을 표현하고, branch 는 join predicate 를
나타낸다.


CUSTOMERS SKUS
\ /
\ /
SALES
/ \
/ \
SUPPLIERS STORES

Query graph for a star query

이 처럼 표현되는 것을 "star query." 라 하며, 모든 star queries 는
1개의 커다란 table 과 여러개의 작은 table 이라는 특성을 공유한다.


(3) 최적의 star query 실행.

Star querie를 효율적으로 실행하는 부분은 오래전부터 관계형 데이타베이스에서
문제로 지적이 되어왔다.

위예제에서, execution plan 은 SALES 와 CUSTOMERS table 이 join 되고,
그 다음 SKUS table 이 join 되며, SUPPLIERS ,STORES table이 순차적으로
join 된다.


OPERATION OPTIONS OBJECT_NAME
========= ======= ===========
NESTED LOOP
NESTED LOOP
NESTED LOOP
NESTED LOOP
TABLE ACCESS FULL SCAN CUSTOMERS
TABLE ACCESS BY ROWID SALES
INDEX RANGE SCAN SALES_INDEX
TABLE ACCESS FULL SCAN SKUS
TABLE ACCESS FULL SCAN SUPPLIERS
TABLE ACCESS FULL SCAN STORES
<효율적이지 못한 star query 의 execution>


이 execution plan 은 효율적이지 못하다. 왜냐하면 SALES 라는 거대한 table
이 4개의 join 에 참여하기 때문이다.
또 bitmap 드의 technique 도 performance 에 별 영향을 주지 못한다.

효율적인 수행은 비용이 많이드는 SALES table 의 join 을 다른 table 이 모두
join 될때까지 미루는 것이다.
즉 SALES table 의 join 은 1번만 되도록 한다.
이 join 은 10-100 의 효과를 얻을수 있다.

OPERATION OPTIONS OBJECT_NAME
========= ======= ===========
NESTED LOOP
NESTED LOOP
NESTED LOOP
NESTED LOOP
TABLE ACCESS FULL SCAN CUSTOMERS
TABLE ACCESS FULL SCAN SKUS
TABLE ACCESS FULL SCAN SUPPLIERS
TABLE ACCESS FULL SCAN STORES
TABLE ACCESS BY ROWID SALES
INDEX RANGE SCAN SALES_INDEX

<효율적인 plan>



Star querie 는 많이 사용되지 아니하고, 큰 table을 뺀 나머지 table
(CUSTOMERS, SKUS,SUPPLIERS, and STORES) 들이 cartesian product 에 들어가야
하므로 optimal한 전략을 세우기가 쉽지 않다.
왜냐면 그들 table 간에는 join predicate 가 없음에도 불구하고 join 을 해야하
기 때문이다.
일반적으로 cartesian-product join 은 매우 비용이 많이드는 작업으로 피해야
하는 작업이나, star query 에서는 FACT table 을 계속 반복적으로 query 하는
것보다 DIMENSION table 끼리 cartesian-product join 을 하는 것이 훨씬
효율적이다.


(4) 복잡한 star queries

어떤 business 에서는 단순한 star query schema 로 풀리지 않는 경우도 있다.
이런 경우는 많은 DIMENSION 이 있고, 추가적으로 foreign key/primary key
관계가 있다.
이들 구조는 "snowflake" 구조라 하며 ,star 구조의 복잡한 형태라 할수있다.

위의 예제에서 , 소매상은 SKU 를 누가 공급하고, 그 공급자는 어떤 창고를 이용
하는지에 대해 알고자 한다고 가정하자.또 SKU 의 생산자등의 정보와 같은 다양한
정보를 얻고자 한다면 이는 아주 복잡한 구조를 띄며 start schema 는 다음과
같은 구조를 이룬다 .

DIMENSION DIMENSION
| |
| |
DIMENSION--DIMENSION DIMENSION--DIMENSION
\ /
\ /
FACT
/ \
/ \
DIMENSION--DIMENSION DIMENSION--DIMENSION
| |
| |
DIMENSION DIMENSION

Complex star query

이처럼 복잡한 구조로 바뀌었음에도 기본적인 start squery 방법은 동일하며,
FACT table 과 join 되기 전에 DIMENSION table 끼리 먼저 JOIN 되어야 한다.




어떤 경우의 star schema 에서는 DIMENSION table이 너무 많커나, 커서 기존의
start query 가 유효하지 않을 수 있다.

이런 경우 FACT table 을 맨 나중에 join 하는 것보다, 먼저 FACT 와 DIMENSION
을 join 하는 것이 효율적인 경우가 있다.

또는 모든 DIMENSION table 을 join 하고 다른 방법으로 (sort merge 또는 hash jojn)
으로 FACT table 과 join 하는 것이다.

이러한 이유로 ,효과적인 query optimizer 는 기본적인 start query
processing 이 적용되어야 할지, 다른 logic 의 start query procession 이
적용되어야 할지 구별이 가능해야 한다.





Star querie는 오라클의 cost-based optimizer 에 의해 운영되는 것인데 , 이
optimizer 는 start query 등의 datawarehousing quert 에 적합하다 .

star query 에 대한 최적의 정책은 cartesian product join 이다 .
Cartesian product join는 비용이 많이 들어 OLTP 에서는 거의 사용되지 않고있다.
이러한 이유들로 rule-based optimizer 는 시스템적으로 cartesian product을
사용하지 않는다. 그러므로 rule-based optimezer 는 star query 를 위한 효율적인
execution plan 을 만들수 없다. 반면 cost based optimizer 는 cartesian
join 의 이용이 가능하며 효율적인 plan 을 만든다.


Oracle 7 server 의 7.1 과 7.2 의 cost-based optimizer 는 5 개 이하의 table
로 구성된 star query 에 대한 execution plan 을 만드는 것이 가능하며, 그 이상의
start query 에 대해서는 optimizer hint 가 사용되어져야 한다.

7.3 에서는 cost-based query optimizer의 성능은 더욱 좋아져서 다음 2 가지
경우에 대해 지능적으로 check 가 가능하다. :

- 1table 이 눈에 띄게 다른 table 보다 큰가 ?
- 큰 table 이 concatenated index 를 가지는가 ?

query 가 위의 2 조건을 만족하면,cost based optimizer 는 conventional
star query 에 무게를 주어 접근한다.

V7.3 의 const-based optimizer 는 table 갯수에 상관없이 또 schema 의 복잡성에 상관없이
optimal , 또는 그에 가까운 결과를 준다.

또한 V7.3 부터 제공하는 STAR 라는 hint 를 사용하면 cost-based optimizer 는 주어진
query에 대해 오직 star query 만을 고려해 접근한다.



star schema 는 datacube 를 실행하는 한 방안인데 ,이 datacube 라 함은
OLAP 에서 multidimensuonal analysis 를 위한 OLAP tool 에서 사용되어진다.


FACT table 이 datacube 의 contain 을 나타내며, 각 DIMENSION table 은
datacube 의 1 dimension 을 나타낸다.

위의 예제에서 datacube 의 dimension 은 CUSTOMERS ,SKUS, SUPPLIERS, STORES
이고 datacube 의 contents 는 FACTS table에 저장되어진다.

이 경우 star schema 는 CUSTOMERS, SKUS, SUPPLIERS, STORES 로 조합된 모든 경우에 대해
total sales 를 가진다.

비록 star query 가 OLAP 에서 여러 경우에 대응해서 결과를 주지 못한다 하더라도,
커다란 datacube 에서 작은 slice 는 효율적으로 제시한다.

<결론>

V7.3 에서 cost-based 의 효율 증대로 star query 를 완벽하게 제공한다 할수있다.
또한 parallel query processing 과 bitmap index 와 더불어 data warehouse
용의 server 역할을 충실히 한다 할수있겠다.