持续创作，加速成长！这是我参与「掘金日新计划 · 6 月更文挑战」的第2天，点击查看活动详情
数据库设计法律
本来应该是“数据库设计规范”。我是故意的。因为这些就是法律： 1、禁止物理删除。 2、禁止使用保留字。 3、禁止无主键。 4、禁止单表索引超过5个。 5、禁止违反命名规则随意建表。 6、禁止无注释代码。 7、禁止使用物理外键，在应用层解决外键关联需求。 8、单表数量控制在1000万以内。如预计有超出，建议提前分库分表。 9、禁止对象类型字段（如BLOB、TEXT等）与其他字段在同一个表中混用。 10、原则上禁止一切流程外的操作，尤其是没有记录的update！！！ 上述所有操作，都是有血泪史的。每一条经验的背后，都是血淋淋的教训，都是失误后一双双通宵敖红的眼睛。
维度建模简介
维度建模是 展现分析数据的首选技术，这一观点之所以被广泛接受，主要基于以下两个需要同时满足 的需求： •以商业用户可理解的方式发布数据。 •提供高效的查询性能。 维度建模并不是一种新技术，早期主要用于简化数据库。50多年来，经过大量案例的 考验，IT组织、行业顾问和商业用户自然而然地被这种以单一维度结构满足人们基本需求 的简单性所吸引。简单性至关重要，因为它能够确保用户方便地理解数据，以及确保软件 能够快速、有效地发现及发布结果。
举个栗子：销售额或利润，这一结果是满足特定产品、市场和时间的结果。将某些事情以具体、有形的方式抽象 成数据集展示出来的能力是解决可理解能力的法宝。如果上述场景表现太简单，这正是我 们的所需！从简单的数据模型开始是保持设计简单性的基础。如果从复杂的数据模型起步, 那么最终会导致模型过度复杂，从而导致査询性能低下，最终使商业用户反感。爱因斯坦 曾经说过“凡事应该尽简单，直到不能再简单为止。”
星型模型
在关系数据库管理系统中实现的维度模型称为星型模式，因为其结构类似星型结构。 在多维数据库环境中实现的维度模型通常称为联机分析处理(OnLine Analytical Processing, OLAP)多维数据库，如图
事实表
“事实”这一术语表示某个业务度量。从市场角度观察，记录销售的产品的数量单位，以及每种产品在每个销售事务中涉及的销售额。当产品被扫描时可以获取这些度量,
物理世界的每一个度量事件与对应的事实表行具有一对一的关系，这一思想是维度建 模的基本原则。其他工作都是以此为基础建立的。
星型模式中维度与事实的连接
在对维度表与事实表有了简单了解后，可以开始将维度模型中的基本元素一起加以考虑了，如图所示。维度模型表示每个业务过程包含事实表，事实表存储事件的数值化度量，围绕爭实表的是多个维度表，维度表包含事件发生时实际存在的文本环境。这种类似星状的结构通常称为星型连接，这一个术语的采用可以追溯到关系数据库系统产生的初期。
最后来一段SQL
`SELECT
store.district_name,
product.brand,
sum （sales_facts . sales_dollars） AS ''Sales Dollars"
FROM
store,
product,
date,
sales_facts
WHERE
date . month_name='* January'* AND
date.year=2013 AND
store.store_key = sales_facts.store_key AND product.product_key = sales_facts.product_key AND date.date_key = sales_facts.date_key
GROUP BY
store , district_name,
product.brand`
逐行仔细研究这段代码可以看出，紧接SELECT语句后的两行来源于报表需要的维度 属性，其后是来自于事实表的聚集矩阵。FROM子句说明査询涉及的所有表，WHERE子 句的前两行定义了报表的过滤器，然后描述维度与事实表之间需要做的连接操作。最后，GROUP BY子句建立报表内的聚集。
