数据库设计问题

1. 数据库设计问题

问这种问题通常都不容易说清楚，只能勉强做一下。要更清楚得详谈。
分成：
一级类表：一级类id（主键），类名称 .....(描述，备注等字段)，43条记录
二级类表：二级类id（主键），类名称 .....(描述，备注等字段)，855条记录
属性表：属性id（主键），属性名称 .....(描述，备注等字段)，6000条记录左右，这里我假设你的意思不是6000种属性值呢，而是6000种属性，不同产品规格型号不同。
下面的产品记录若理解为产品，而不是同一产品的不同个体都有一条记录。则
产品类型表：产品类型id（主键），产品名称（同一类型产品名字是一样的），属性1 id，属性1值，属性2 id，属性2值，属性3 id，属性3值 .....(描述，备注等非关键字段)，220万条记录左右。其中属性id都是外键，和属性表关联。这不太符合实际：因为有220万种产品，似乎规模太大了。可能空间很浪费，因为如果某产品有最多100个属性，则其它产品记录中会有大量空属性，如果使用关系和XML混合数据库，可避免该问题，可是在检索中效率如何等方面需要仔细考虑。另外可能还需要考虑诸如生产厂家、销售者等问题，所以问题的规模不见得仅仅是这一点。
若是产品个体的记录，则：
产品类型表还是要的。然后
产品表：产品id（主键），其余诸如出厂日期，描述，备注等非关键字段。

2. 如何合理和有效的进行数据库设计

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

3. 怎么设计这个数据库？

问这种问题通常都不容易说清楚，只能勉强做一下。要更清楚得详谈。
对于第2个问题：
分成：
一级类表：一级类id（主键），类名称 .....(描述，备注等字段)，43条记录
二级类表：二级类id（主键），类名称 .....(描述，备注等字段)，855条记录
属性表：属性id（主键），属性名称 .....(描述，备注等字段)，6000条记录左右，这里我假设你的意思不是6000种属性值呢，而是6000种属性，不同产品规格型号不同。
下面的产品记录若理解为产品，而不是同一产品的不同个体都有一条记录。则
产品类型表：产品类型id（主键），产品名称（同一类型产品名字是一样的），属性1 id，属性1值，属性2 id，属性2值，属性3 id，属性3值 .....(描述，备注等非关键字段)，220万条记录左右。其中属性id都是外键，和属性表关联。这不太符合实际：因为有220万种产品，似乎规模太大了。可能空间很浪费，因为如果某产品有最多100个属性，则其它产品记录中会有大量空属性，如果使用关系和XML混合数据库，可避免该问题，可是在检索中效率如何等方面需要仔细考虑。另外可能还需要考虑诸如生产厂家、销售者等问题，所以问题的规模不见得仅仅是这一点。
若是产品个体的记录，则：
产品类型表还是要的。然后
产品表：产品id（主键），其余诸如出厂日期，描述，备注等非关键字段。 
对于第1个问题：
则是数据库优化问题，要根据数据库访问特点，包括提高硬件性能（更好的机器、服务器群集）、加适当索引、采用适当的并发机制等方式来解决问题。而且最好有一个具体需求，然后尽快测试系统原型是否满足要求，不满足就设法改进直到满足要求为止。

4. 数据库应该怎么设计

你可以使用信息管理平台将案例信息都录进去，集中管理起来，后面查阅就方便了。我这里以华创信息管理平台为例，说明一下这类平台具有的功能，你看是否适合你：
1、面向非专业人员，无需编程，能让用户自由建表、自定义数据格式，能管理各种数据。无论您想管理什么，建表即可。比如案例资料表，设置以下字段：项目名称、设计要求、作者、开始日期、完成日期...等，用于记录常规信息；再设置几个附件型字段，用于上传word、excel、图片等文档。
2、建表后再设置登录帐号及权限，大家就可录入数据、共享数据了，至于操作界面、数据存储等细节由平台自动完成。
3、支持多用户同时访问，具有完善的权限，各类人员的增删改及查看权均可详细控制。
4、不仅支持电脑访问，而且支持手机、iPad直接访问，无论何时何地都能录数据、查数据。
5、具有自动提醒功能，能自动发送email通知、手机短信、系统内部短信，可用于生日提醒、各种到期提醒等。
6、支持excel数据的导入导出，现有的案例资料无需再次输入，可直接导入到本系统中；系统中的数据也可再次导出成 Excel、Word文档。
 
该平台既可下载试用，也可直接在线试用。你可以先弄最简单的、最紧迫的几个表，避免一上来就弄得太复杂，熟练之后，再逐步扩展至其他管理。

5. 数据库的设计？

总共有六个：
1.　需求分析：分析用户的需求，如数据、功能和性能需求等；
2.　概念结构设计：主要采用E-R模型进行设计，包括画E-R图；
3.　逻辑结构设计：通过将E-R图转换成表，实现从E-R模型到关系模型的转换；
4.　数据库物理设计：确定数据的存储结构、存取路径、存放位置。；
5.　数据库的实施：编程、测试和试运行；
6.　数据库运行与维护：系统的运行与数据库的日常维护。

6. 数据库设计的问题

线，我就不给你画了，你看看我这个图你能看懂不


其他属性那些都是选填字段，id类的都是必填字段，这些表靠着这些id有千丝万缕的关联，你先理解下，不懂再问。如果一会答案被推荐了，请私信联系。这些东西不是一句两句话就能给你讲明白的。

7. 如何设计合理高效的数据库

一、 引言数据库对于企业信息化的重要性是不言而喻的。数据库存储着现代企业最重要的数据，包括生产、经营、管理等各类数据，这些数据作为企业的核心信息，通过各类信息系统，为用户提供及时准确的信息，帮助用户分析，为用户提供决策依据。为提高企业的工作效率，提升企业形象，具有传统模式无法比拟的优势。其中构建合理高效的数据库，是数据库建设关键之一。如何构建合理高效的数据库是企业信息化过程要解决的问题。下面就数据库的构建谈谈自己的一些经验，希望能对大家有所帮助。 二、 设计数据库之前
数据库并不是凭空想象出来的，而是根据业务部门的需要设计符合业务需求的数据库。因此在形成数据库之前需要充分了解业务需求。 1. 充分理解业务需求。需求分析是整个设计过程的基础，是最困难、最耗费时间的一步。在这期间通过与业务部门交流，了解用户的想法以及工作流程，通过双方多次交流，会形成初步的数据模型，当然这时的数据模型不会是最终的模型，还需要和用户进行交流，并且在以后的信息系统开发过程中还会反复修改。 2. 重视输入输出。在定义数据库表和字段需求（输入）时，首先应了解数据产生源和数据流程，也就是必需要知道每个数据在那儿产生，数据在那儿表现，以什么样的形式表现等等，然后根据用户提供的报表或者设计出的报表、查询和视图（输出）以决定为了支持这些输出哪些是必要的表和字段。 3. 创建数据字典和ER 图表。ER 图表和数据字典可以让任何了解数据库的人都明确如何从数据库中获得数据。ER图对表明表之间关系很有用，而数据字典则说明了每个字段的用途以及任何可能存在的别名。对SQL 表达式的文档化来说这是完全必要的。 需要注意的是，在需求分析调研过程中，并不是一帆风顺的，因为业务人员对于业务的理解不同，以及对于信息知识的缺乏，会影响需求分析的质量，为了提高质量，各方要用更多的时间交流与相互理解，业务部门需要精通业务的人员自始至终全力配合，而开发人员则尽量使用用户理解的业务术语交流，这样会避免出现理解不同而产生的歧义。 三、 设计合理的表结构
通常合理的表结构会减少数据冗余，提高数据库的性能。设计合理的表结构要遵循以下两点。 1. 标准化和规范化 数据的标准化有助于消除数据库中的数据冗余。标准化有好几种形式，但3NF(第三范式)通常被认为在性能、扩展性和数据完整性方面达到了最好平衡。简单来说，遵守3NF标准的数据库的表设计原则是：某个表只包括其本身基本的属性，当不是它们本身所具有的属性时需进行分解。表之间的关系通过外键相连接。它具有以下特点：有一组表专门存放通过键连接起来的关联数据。 例如：某个存放单井信息及其有关油井生产日报信息的3NF数据库就有两个表：单井基础信息和油井日报信息。日报信息不包含单井的任何信息，但表内会存放一个键值，该键指向单井基础信息里包含该油井信息的那一行。 不过也有例外，有时为了效率的缘故，对表不进行标准化也是必要的。 2. 考虑各种变化 在设计数据库的时候考虑到哪些数据字段将来可能会发生变更。使数据库更具扩展性，从而减少将来数据变更所带来的损失。 例如，日期类型字段，有时我们会考虑使用字符类型代替日期类型，因为在处理日期字段上容易产生数据错误，所以我们就使用字符类型。这样的例子还很多，在做前期设计时都要考虑的。 表结构的设计不是一次就能成功的，在信息系统开发过程中会存在数据读取、录入或统计困难，为了解决这些问题会修改表结构，或增加一些字段，或修改一些字段的属性。这个过程不断重复，因此不要想一次能成功。建议使用专门设计工具来做这些工作，笔者经常使用：SYBASE PowerDesigner ，当然还有其它的工具：ORACLE Designer 2000 ，ROSE等工具。这样会使你的工作事半功倍。 四、 选择合理的索引
索引是从数据库中获取数据的最高效方式之一。95%的数据库性能问题都可以采用索引技术得到解决。 1. 逻辑主键使用唯一的成组索引，对系统键（作为存储过程）采用唯一的非成组索引，对任何外键列采用非成组索引。考虑数据库的空间有多大，表如何进行访问，还有这些访问是否主要用作读写。 2. 大多数数据库都索引自动创建的主键字段，但是可别忘了索引外键，它们也是经常使用的键，比如运行查询显示主表和所有关联表的某条记录就用得上。 3. 不要索引大型字段（有很多字符），这样作会让索引占用太多的存储空间。如MEMO(备注)、TEXT(文本)等字段。 4. 不要索引常用的小型表 不要为小型数据表设置任何键，假如它们经常有插入和删除操作就更别这样作了。对这些插入和删除操作的索引维护可能比扫描表空间消耗更多的时间。如代码表，或系统参数表。 五、 保证数据完整性
数据的完整性非常重要，这关系到数据的准确性，不准确的数据是毫无价值的，因此保证数据的完整性非常重要。 1. 完整性实现机制：实体完整性：主键参照完整性： 父表中删除数据：级联删除；受限删除；置空值父表中插入数据：受限插入；递归插入 父表中更新数据：级联更新；受限更新；置空值 DBMS对参照完整性可以有两种方法实现：外键实现机制（约束规则）和触发器实现机制用户定义完整性：NOT NULL；CHECK；触发器 以上完整性机制需要熟悉和掌握，它对于数据的完整性非常重要。 2. 用约束而非业务规则强制数据完整性 采用数据库系统实现数据的完整性。这不但包括通过标准化实现的完整性而且还包括数据的功能性。在写数据的时候还可以增加触发器来保证数据的正确性。不要依赖于业务层保证数据完整性；它不能保证表之间（外键）的完整性所以不能强加于其他完整性规则之上。 3. 强制指示完整性 在有害数据进入数据库之前将其剔除。激活数据库系统的指示完整性特性。这样可以保持数据的清洁而能迫使开发人员投入更多的时间处理错误条件。 4. 使用查找控制数据完整性 控制数据完整性的最佳方式就是限制用户的录入。只要有可能都应该提供给用户一个清晰的价值列表供其选择。这样将减少键入代码的错误和误解同时提供数据的一致性。某些公共数据特别适合查找：性别代码、单位代码等。 5. 采用视图 视图是一个虚拟表，其内容由SQL语句定义，视图不仅可以简化用户对数据的理解，也可以简化他们的操作。那些被经常使用的查询可以被定义为视图，从而使得用户不必为以后的操作每次指定全部的条件。另外通过视图用户只能查询和修改他们所能见到的数据。数据库中的其它数据则既看不见也取不到。数据库授权命令可以使每个用户对数据库的检索限制到特定的数据库对象上，增强数据的安全性。 六、 结束语
数据库的高效运行不仅需要技术上的支持，也需要硬件平台和网络的支持以及数据库管理员的有效管理，本文只是从技术的角度说明如何提高数据库的效率，但在实际应用过程中其它方面的支持也是不可缺少的，尤其是数据库管理，数据库建设是“三分技术，七分管理，十二分基础数据”，因此对于数据库管理一定要重视，在管理到位的情况下技术才能发挥应有的作用。

8. 数据库设计的定义