由异构数据源集成而来的叫数据仓库。（hetrogeneous sources) 也就是从不同数据源来，基于这个数据仓库，那我就能用来分析。
那它必然有几个特点：
1.可以用于报表和分析
2.是一个或多个数据源的集中存储地
3.存储当前和历史数据（不上5年都不好意思叫历史）
这样来看，那我直接在我前端系统的数据库里存储不就好了。
少量的数据是没问题的，但是一旦数据量多起来，动不动要同比，环比。来个3-5年同比的话，分分钟拖垮前端系统啊，那业务还做不做了。我超市买完东西结账，业务员告诉我，不好意思，系统卡住了，等个半小时。我去充个话费，不好意思，系统在跑数据，在等进程。显然，这就要用到数据仓库了。
对于前端操作系统的数据库，因为要处理很多交易，所以并发控制和恢复机制很重要，我要确保数据库的稳健和一致性。我就从这里来数据的，那这数据必须得准确啊，这里可以读取和修改数据。那数据仓库呢，换个词叫OLAP联机在线分析系统，就只需要读取数据就行了，那是不能改的。如果有要求让我们在BW或者HANA这边进行数据的手动更改，那是迫不得已的。OLTP就只有当前数据，OLAP那就历史数据和当前数据。
数据仓库系统的类型：
Data Mart : 那就是数据仓库的一部分，subset的意思
OLAP： 复杂的数据处理（合计，计数）
OLTP： 很多操作（插入，更新，删除）
Aggregations
聚集这个词，很不好解释，但是BW里面又经常用，旧版本的info provider上经常有聚集，那这个词咋理解？
从字面意思来理解，怎么才能聚集，那自然是人多了才能聚集，聚集起来能干啥事呢？
我一个人，那我肯定不能来个总计，我也不会有最大值，最小值，也不用数我多少个。
但是我人一多，我就能来Sum，count，minimum，maximum。我还能average,median,mode。于是，从各个维度来看，比如说从地区这个维度，我就能来sum一下这个地区的销售额了。我还能从年份来maximum。反正就是基于一个事实表，想按啥维度来按自己要求。这不就“聚集”了。
Schema
Schema这个东西就是个小关系数据库，是个架构么，那得有框架，有连接点，而且这个框架里的表啊，列啊，字段啊的，那得有关系。是逻辑关系。就相当于一个大家族，有血缘关系才能组在一起，大家都能扯上点关系。没关系的就别混进来了。数据库是完全关系模型（E-R模型）的。但是数据仓库那就不一样了，就有星型模型，雪花模型，星系模型。这一对比我就晕了。
星型模型
这个看起来很简单，就是一个事实表，里面所有的维度表的主键值那都必须连着一个维度表啊，到维度表这一层就结束了。维度表里都是维度属性。它所囊括的数据就都在这里了。
雪花模型
雪花就是把星星升级一下，分裂维度表。为了达到一个终极目的：减少冗余。
分解大法，在不丢掉任何数据的情况下，把一个大的分裂成两个小的，例如：
分裂前是一个，分裂后是两个。
星系模型
升级成多个事实表和多个维度表，事实表共享，维度表共享。
SQL Concepts
DML
data manipulation language
SELECT
INSERT
UPDATE
DDL
data definition language
CREATE
ALTER
DROP
DCL
data control language
GRANT
REVOKE (withdraw access privileges given with the GRANT command)
SQL operators
Arithmetic /算数运算符： 加减乘除百分号
Relational/Comparison operator比较运算符：大于等于小于
Logical/Boolean Operator： 是否与或运算符
Set Operators ：集合运算符
InnerJoin 内连接
就是说内部找相同的。找到有共同点的，然后把你想要的这家伙所有的东西都拉出来。
前提是，两个表里都有这家伙才行。
NON EQUI Join
跟内连接相反，那就是不等连接：
Outer Join
1. LEFT OUTER JOIN
有个左字，就是所有左表的内容都要，然后左表和右表共有的，也要。
2. RIGHT OUTER JOIN
就是所有共有的内容和右表的内容。
3. FULL OUTER JOIN
所有表的所有数据。没有数据的行，那就是null。
Self Join
当然自己和自己也能Join
先来看看HANA Studio里面怎么用insert /select等。
很简单，找到这个表，右键可以选的。可以查看数据。
insert 也是一样的，直接出来语句，只要写入值就好了。
那接下来有一点：
怎么把列表转换成行表
so easy:
