通常情况下，可以从两个方面来判断数据库设计的是否规范：
1）看是否拥有大量的窄表
2）看宽表的数量是否足够的少
所谓的宽表就是字段比较多的表，包含的维度层次比较多，造成冗余也比较多，毁范式设计，但是有利于取数。
当然，数据库表设计最好遵循以下五个要求：
1）表中应该避免可为空的列。 虽然表中允许空表，但是，空字段是一种比较特殊的数据类型。数据库在处理的时候需要进行特殊的处理。这样就会增加数据库处理记录的复杂性，当表中有比较多的空字段时，在同等条件下，数据库处理的性能会降低许多。所以，虽然在数据库表设计的时候，允许表中有空字段，但是我们应该尽量避免。若需要的话，我们可以通过一些折中的方式来处理这些空字段，让其对数据库性能的影响降到最低。
2）表中不该有重复的值或者列。如进销存系统中，需要对客户的联系人进行管理。有时候企业可能只知道客户一个采购员的名字，但是在必要的情况下，企业需要对客户的采购代表、仓管员、财务员共同进行管理。因为在订单上，可能需要填入采购员的名字，可是在出货单上，则需要填入仓管员的名字等等。为了解决这个问题，有很多种方式，但是若设计不合理的话，则会导致很多重复的列或者值，如果我们这么设计，把客户的信息、联系人都放入一张表中。为了解决多个联系人的问题，可以设置第一联系人及电话、第二联系人及电话、第三联系人及电话等等。则可能还需要更多字段。所以我们在设计数据库的时候尽量避免重复的值或者列的产生。建议把客户联系人另外设置一张表。然后通过客户ID把供应商信息表和客户联系人信息表连接起来。也就是说尽量将重复的值放置到一张独立的表中进行管理。然后通过视图或者其他手段把这些独立的表联系起来。
3）表中记录应该有一个唯一的标识符。在数据库设计的时候，应该用一个ID号来唯一的标识记录，而不要通过名字、编号等字段来对记录进行区分，每个表应该有一个ID列，任何两个记录都不可以共享同一个ID值，另外这个ID值最好有数据库进行统一自动管理，而不要把这个任务给前台应用程序。否则的话，很容易产生ID值不统一的情况。另外，在设计数据库的时候，最好加入行号。例如在销售订单管理中，ID号是用户不能够维护的，但是，行号用户就可以维护。在销售订单的行号中，用户可以通过调整行号的大小来对订单进行排序。通常情况下，ID列是以1为单位递进的。但是行号就要以10为单位累进，如此，在正常情况下，行号是以10,20,30依次扩展下去。若此时用户需要把行号为30 的调整到第一行显示，此时用户在不改ID列的情况下，可以更改行号来实现。如把行号改为1，就可以在排序时按行号来排序。
4）数据库对象要有统一的前缀名。一个比较复杂的应用系统，其对应的数据库表可能上千个的，若要让数据库管理员看到表名就知道这个数据库表所起的作用，恐怕会比较困难，而且在数据库对象引用的时候，数据库管理员也会为不能快速找到所需的数据库对象而头疼。其次表、视图、函数等最好也有统一的前缀。如表可以用T，视图可以用V，函数用F。
5）尽量只存储单一实体类型的数据。这里说的实体类型跟数据类型不是一回事，要注意区分，这里的实体类型是所需要描述对象的本身。举个例子，例如有一个图书管理系统，有图书基本信息、作者信息两个实体对象，若要把这两个实体对象信息放在同一张表中也是可以的，可以把表设计成图书名字、图书作者等，可是如此的话，会给后续的维护带来不少的麻烦。当后续有图书出版时，则需要为每次的图书增加作者信息，这无疑会增加额外的存储空间，也会增加记录的长度，而且若作者的情况有所改变，如地址变了，则还需要去更改每一本书的记录。同时，若这个作者的图书从数据库删除了，这个作者的信息也没有了，很明显，这不符合数据库设计规范的需求。遇到这种情况，建议把上面的这张表拆分成3个表，分别为图书基本信息表、作者基本信息表、图书与作者对应表等。