表太多的库，一般情况下没什么大的问题，也不是很有必要划分为多个库。除非这个库里面，许多表是平时基本上不使用的，少数表是需要反复频繁使用的，那么有必要把频繁使用的表移到一个库里面。因为 *** 作系统一般对目录下的文件是不排序的，数据库请求 *** 作系统打开某文件的时候， *** 作系统实际上是顺序搜索目录表（FDT），这样当目录下的文件数太多的时候，效率会很差。经过我自己的实验，在WINDOWS下当文件个数达到5000左右的时候我无法忍受，在FREEBSD下也差不多。
字段数较多的表，在数据库理论里面称为宽表。它是有的情况下必须要有的，比如我什么零件库，零件的参数就有上千个，是正常的。一般我们不需要把宽表划分为几个表，因为程序会变得复杂，而每次查询都需要关联多表，更新更是麻烦。
但是在某些情况下，把宽表进行划分是有效的。比如一部分字段是比较固定的，而另外一些字段是需要反复更新的。把需要反复更新的字段单独分为一个表，能提高更新的效率，也能减少更新期间系统故障时带来的风险。
对宽表的划分，应该照顾逻辑属性。比如对论坛的表进行划分，可以把论坛ID、标题等固定属性分为一个表，而把论坛状态、最后回复者、帖子数等状态属性分为一个表。
对于基本上不需要修改的表，无论字段有好多，也无论文件有多大，都没有必要划分为多个表。
通常情况下，可以从两个方面来判断数据库设计的是否规范:1)一是看看是否拥有大量的窄表
窄表往往对于OLTP比较合适，符合范式设计原则
2)宽表的数量是否足够的少。
所谓的宽表就是字段比较多的表，包含的维度层次比较多，造成冗余也比较多，毁范式设计，但是利于取数统计
若符合这两个条件，我们可以说数据库设计的比较好.
当然这是两个泛泛而谈的指标。为了达到数据库设计规范化的要求，一般来说，需要符合以下五个要求。
要求一：表中应该避免可为空的列。
虽然表中允许空列，但是，空字段是一种比较特殊的数据类型。数据库在处理的时候，需要进行特殊的处理。如此的话，就会增加数据库处理记录的复杂性。当表中有比较多的空字段时，在同等条件下，数据库处理的性能会降低许多。
所以，虽然在数据库表设计的时候，允许表中具有空字段，但是，我们应该尽量避免。若确实需要的话，我们可以通过一些折中的方式，来处理这些空字段，让其对数据库性能的影响降低到最少。
要求二：表不应该有重复的值或者列。
如现在有一个进销存管理系统，这个系统中有一张产品基本信息表中。这个产品开发有时候可以是一个人完成，而有时候又需要多个人合作才能够完成。所以，在产品基本信息表产品开发者这个字段中，有时候可能需要填入多个开发者的名字。
如进销存管理中，还需要对客户的联系人进行管理。有时候，企业可能只知道客户一个采购员的姓名。但是在必要的情况下，企业需要对客户的采购代表、仓库人员、财务人员共同进行管理。因为在订单上，可能需要填入采购代表的名字可是在出货单上，则需要填入仓库管理人员的名字等等。
为了解决这个问题，有多种实现方式。但是，若设计不合理的话在，则会导致重复的值或者列。如我们也可以这么设计，把客户信息、联系人都放入同一张表中。为了解决多个联系人的问题，可以设置第一联系人、第一联系人电话、第二联系人、第二联系人电话等等。若还有第三联系人、第四联系人等等，则往往还需要加入更多的字段。
所以，我们在数据库设计的时候要尽量避免这种重复的值或者列的产生。笔者建议，若数据库管理员遇到这种情况，可以改变一下策略。如把客户联系人另外设置一张表。然后通过客户ID把供应商信息表跟客户联系人信息表连接起来。也就是说，尽量将重复的值放置到一张独立的表中进行管理。然后通过视图或者其他手段把这些独立的表联系起来。
要求三：表中记录应该有一个唯一的标识符。
在数据库表设计的时候，数据库管理员应该养成一个好习惯，用一个ID号来唯一的标识行记录，而不要通过名字、编号等字段来对纪录进行区分。每个表都应该有一个ID列，任何两个记录都不可以共享同一个ID值。另外，这个ID值最好有数据库来进行自动管理，而不要把这个任务给前台应用程序。否则的话，很容易产生ID值不统一的情况。
另外，在数据库设计的时候，最好还能够加入行号。如在销售订单管理中，ID号是用户不能够维护的。但是，行号用户就可以维护。如在销售订单的行中，用户可以通过调整行号的大小来对订单行进行排序。通常情况下，ID列是以1为单位递进的。但是，行号就要以10为单位累进。如此，正常情况下，行号就以10、20、30依次扩展下去。若此时用户需要把行号为30的纪录调到第一行显示。此时，用户在不能够更改ID列的情况下，可以更改行号来实现。如可以把行号改为1，在排序时就可以按行号来进行排序。如此的话，原来行号为30的纪录现在行号变为了1，就可以在第一行中显示。这是在实际应用程序设计中对ID列的一个有效补充。这个内容在教科书上是没有的。需要在实际应用程序设计中，才会掌握到这个技巧。
要求四：数据库对象要有统一的前缀名。
一个比较复杂的应用系统，其对应的数据库表往往以千计。若让数据库管理员看到对象名就了解这个数据库对象所起的作用，恐怕会比较困难。而且在数据库对象引用的时候，数据库管理员也会为不能迅速找到所需要的数据库对象而头疼。
其次，表、视图、函数等最好也有统一的前缀。如视图可以用V为前缀，而函数则可以利用F为前缀。如此数据库管理员无论是在日常管理还是对象引用的时候，都能够在最短的时间内找到自己所需要的对象。
要求五：尽量只存储单一实体类型的数据。
这里将的实体类型跟数据类型不是一回事，要注意区分。这里讲的实体类型是指所需要描述对象的本身。笔者举一个例子，估计大家就可以明白其中的内容了。如现在有一个图书馆里系统，有图书基本信息、作者信息两个实体对象。若用户要把这两个实体对象信息放在同一张表中也是可以的。如可以把表设计成图书名字、图书作者等等。可是如此设计的话，会给后续的维护带来不少的麻烦。
如当后续有图书出版时，则需要为每次出版的图书增加作者信息，这无疑会增加额外的存储空间，也会增加记录的长度。而且若作者的情况有所改变，如住址改变了以后，则还需要去更改每本书的记录。同时，若这个作者的图书从数据库中全部删除之后，这个作者的信息也就荡然无存了。很明显，这不符合数据库设计规范化的需求。
遇到这种情况时，笔者建议可以把上面这张表分解成三种独立的表，分别为图书基本信息表、作者基本信息表、图书与作者对应表等等。如此设计以后，以上遇到的所有问题就都引刃而解了。
以上五条是在数据库设计时达到规范化水平的基本要求。除了这些另外还有很多细节方面的要求，如数据类型、存储过程等等。
（1）为什么要分层
作为一名数据的规划者，我们肯定希望自己的数据能够有秩序地流转，数据的整个生命周期能够清晰明确被设计者和使用者感知到。直观来讲就是如图这般层次清晰、依赖关系直观。
但是，大多数情况下，我们完成的数据体系却是依赖复杂、层级混乱的。如下图，在不知不觉的情况下，我们可能会做出一套表依赖结构混乱，甚至出现循环依赖的数据体系。
因此，我们需要一套行之有效的数据组织和管理方法来让我们的数据体系更有序，这就是谈到的数据分层。数据分层并不能解决所有的数据问题，但是，数据分层却可以给我们带来如下的好处：
1）清晰数据结构： 每一个数据分层都有它的作用域和职责，在使用表的时候能更方便地定位和理解；
2）减少重复开发： 规范数据分层，开发一些通用的中间层数据，能够减少极大的重复计算；
3）统一数据口径： 通过数据分层，提供统一的数据出口，统一对外输出的数据口径；
4 ）复杂问题简单化： 将一个复杂的任务分解成多个步骤来完成，每一层解决特定的问题。
为了满足前面提到好处，通常将数据模型分为三层：数据运营层（ ODS ）、数据仓库层（DW）和数据应用层（APP）。简单来讲，我们可以理解为：ODS层存放的是接入的原始数据，DW层是存放我们要重点设计的数据仓库中间层数据，APP是面向业务定制的应用数据。下面详细介绍这三层的设计。
（2）数据模型的分层
1）源数据层（ODS）
此层数据无任何更改，直接沿用外围系统数据结构和数据，不对外开放；为临时存储层，是接口数据的临时存储区域，为后一步的数据处理做准备。
2）数据仓库层（DW）
也称为细节层，DW 层的数据应该是一致的、准确的、干净的数据，即对源系统数据进行了清洗（去除了杂质）后的数据。
此层可以细分为三层：
明细层DWD（Data Warehouse Detail） ：存储明细数据，此数据是最细粒度的事实数据。该层一般保持和ODS层一样的数据粒度，并且提供一定的数据质量保证。同时，为了提高数据明细层的易用性，该层会采用一些维度退化手法，将维度退化至事实表中，减少事实表和维表的关联。
中间层DWM（Data WareHouse Middle） ：存储中间数据，为数据统计需要创建的中间表数据，此数据一般是对多个维度的聚合数据，此层数据通常来源于DWD层的数据。
业务层DWS（Data WareHouse Service） ：存储宽表数据，此层数据是针对某个业务领域的聚合数据，业务层的数据通常来源与此层，为什么叫宽表，主要是为了业务层的需要在这一层将业务相关的所有数据统一汇集起来进行存储，方便业务层获取。此层数据通常来源与DWD和DWM层的数据。
在实际计算中，如果直接从DWD或者ODS计算出宽表的统计指标，会存在计算量太大并且维度太少的问题，因此一般的做法是，在DWM层先计算出多个小的中间表，然后再拼接成一张DWS的宽表。由于宽和窄的界限不易界定，也可以去掉DWM这一层，只留DWS层，将所有的数据在放在DWS亦可。
3）数据应用层（DA 或 APP）
前端应用直接读取的数据源；根据报表、专题分析的需求而计算生成的数据。
4）维表层（Dimension）
最后补充一个维表层，维表层主要包含两部分数据：
A）高基数维度数据：一般是用户资料表、商品资料表类似的资料表。数据量可能是千万级或者上亿级别。
B）低基数维度数据：一般是配置表，比如枚举值对应的中文含义，或者日期维表。数据量可能是个位数或者几千几万。
（3）问题扩展
数据仓库系统架构
上图系统各部分的执行流程是：
1）确定分析所依赖的源数据。
2）通过ETL将源数据采集到数据仓库。
3）数据按照数据仓库提供的主题结构进行存储。
4）根据各部门的业务分析要求创建数据集市（数据仓库的子集）。
5）决策分析、报表等应用系统从数据仓库查询数据、分析数据。
6）用户通过应用系统查询分析结果、报表。
（4）结合项目中使用
电商网站的数据体系设计，这里针对用户访问日志这一部分数据进行举例说明:
在ODS层中，由于各端的开发团队不同或者各种其它问题，用户的访问日志被分成了好几张表上报到了我们的ODS层。
为了方便大家的使用，我们在DWD层做了一张用户访问行为天表，在这里，我们将PC网页、H5、小程序和原生APP访问日志汇聚到一张表里面，统一字段名，提升数据质量，这样就有了一张可供大家方便使用的明细表了。
在DWM层，我们会从DWD层中选取业务关注的核心维度来做聚合 *** 作，比如只保留人、商品、设备和页面区域维度。类似的，我们这样做很多个DWM的中间表。
然后在DWS层，我们将一个人在整个网站中的行为数据放到一张表中，这就是我们的宽表了，有了这张表，就可以快速满足大部分的通用型业务需求了。
最后，在APP应用层，根据需求从DWS层的一张或者多张表取出数据拼接成一张应用表即可。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）