2017年1月-关于数据库表设计、查询、统计的想法。

       我最近的一项工作内容，就是项目软件产品的的行业需求分析，一般来说政府行业软件是和行业特征、行业法规，行业政府的办公需求，服务公众的方式、理念密切相关的。它的重心是业务逻辑的实现和数据库的规划（至少现阶段的我的认识是这样的），问题来了，我如何才能依托对业务的深入理解，设计出高效、不冗余、有价值的关系型数据库的逻辑层的设计（一般数据库包括物理层、逻辑层、视图层）。这些需要用到范式的知识吗？需要怎么系统的看待这个问题和解决这个问题，输出我想要的 数据库表设计、视图上的查询列表内容、统计的数据（这个3个方面应该是传统软件经常关心的部分吧），我想首先要有理论支撑吧。

      我开始了《数据库系统概念》中文第六版的学习。本人一直都没有开始认真的学习这个领域，现在开始尝试。希望能共勉和得到指导。

      关系型数据库的设计窍门与经验，尤其是自己关注的要点，有一些限于描述的复杂性，无法通过 百度搜索轻松定位找到答案，也许知乎会有解释，但是我相信只有通过自己的探索、猜想、阅读名著，才会深入骨髓和大脑，无论你关注的什么行业的数据库设计，一定有比较好通用的设计方法和设计理念。

    首先是概念层面的建模，难道E-R关系模型，是必须经历的步骤？，为什么我设计的时候，并没有这样去考虑，而是站在业务的层面区划分。

   假设以旅馆行业为例子，主要有几个方面的数据需要组织和管理，比如： 旅馆基本信息、从业人员信息、旅馆住宿信息，三个方面。

   站在抽象概况细分的角度，我会再归纳为：

企业基础信息：包括企业统一信用代码、企业名称、企业地址、 法人代表等。  

旅馆企业行业信息：包括房间数量、旅馆等级、前台服务员人数等。

企业从业人员信息：姓名、年龄、性别、民族等。

旅馆住宿信息：入住时间、入住房号、退房时间、支付方式等。

第四个和前三个有点区别，前三个都和具体的一个事物有关，而第四个是反映的关系、联系。

逻辑结构设计是将概念模型转换成逻辑模型的过程，也就是将E-R图中的实体、关系、属性转化为DBMS所支持的数据结构的过程，关系型数据库的数据结构为：表。

对于世界上的事物，可以用 实体表ENTITY、关系表RELATION、事实表FACT、报表REPORT等，他们研究的事物有什么不一样呢？

实体表可以认为是对某个事物的属性和属性值的集合。

关系表可以认为是某个事物与某另一个事物的数据关系。

事实表呢？

报表呢？

维度表呢？旅馆名称与统一信用代码的对应表。

http://blog.csdn.net/seusoftware/article/details/5524414