数据库设计问题

2024-05-06 01:10

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. 数据库设计的问题

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


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

3. 数据库设计需要注意的问题

问题有点大,提个思路吧:

1 所用的数据库类型?Oracle 、Mysql、DB2 还是其它?

2 面向的应用?是OLTP 还是 DSS/OLAP?
3 系统的存储结构如何?指系统的文件系统类型、磁盘实现、是否支持冗余、是否支持缓存写入等,会影响到数据库的压缩、日志、统计等属性设置。
4 是新项目的数据库,还是属于迁移的?即对数据的设计和修改的范围和限制。
5 数据库级别的考虑?空间、日志、字符集、是否闪回、数据块大小等。
6 表级别的考虑?数据类型、分区、主键、唯一键、索引、聚集索引、外键、全文查询、数据块大小、压缩、日志等。
7 视图、存储过程、触发器等设计,用于保证事务、便于程序访问的相关设计;
按以上具体参阅资料考虑各部分的设计和注意事项吧。

数据库设计需要注意的问题

4. 在数据库设计过程中要注意哪些问题?

DB2数据库的性能与稳定性直接跟数据库对象的多少、大小有关。如果对象很少,不复杂,那么就算不怎么规划,也能够达到比较高的性能。如果对象数据比较多、比较大的话,那么就需要在数据库设计之前好好的规划,否则会在很大程度上影响数据库的性能与稳定性。

  一、选择合适的语言与数据库字符集。

  在企业中部署数据库的时候,首先需要在操作系统上安装数据库。而在安装数据库的时候,需要选择安装的语言环境。即是以中文状态下安装数据库还是以英文状态安装数据库。如在启动安装程序的时,可以利用/i language选项来指定安装过程中所采用的语言。到目前为止,DB2数据库已经支持很多种语言。那么数据库在安装过程中,该采用什么语言呢?笔者建议,只要数据库管理员有一点英语基础,最好能够采用英文语言环境来进行安装。虽然说现在DB2数据库的中文语言环境已经设计的比较完善,但是笔者仍然担心其有一些不知名的漏洞。为此笔者在安装DB2数据库的时候,基本上都采用的是英文语言环境来进行安装。即将语言设置为“EN”,表示英文。提高DB2数据备份与恢复的效率。

  另外如果DB2 数据库中要保存英文以外的数据,或者说用户会使用不同的字符集访问数据库时,还需要在数据库安装过程中选择特定的数据库字符集。DB2数据库中的所有字符数据,包括数据字典中的数据,都是存储在数据库字符集中的。如果用户使用不同的字符集访问数据库时,数据库管理员就需要选择包含所有这些用户的字符集的超集。只有如此,才能够确保系统能够很方便的使用替代字符完成字符的转换,从而提高数据库的性能。如果用户选择的字符集不对,有可能会出现一些莫名其妙的问题。如一次用户在安装数据库过程中,没有选择合适的字符集。虽然在使用的过程中,其存储中文字符没有问题。但是当对数据库采取还原操作时,却发现还原后的数据库中有些原来是中文字符的地方,尽然出现了乱码。这主要就是没有选择合适的字符集惹的祸。有时候如果字符集选择不当的话,从外部数据源(如Excel表格)导入数据的时候,中文数据也会无法顺利导入。所以,数据库管理员在安装数据库的时候,需要根据实际企业,来选择合适的字符集。

  二、评估数据库对象的大小、数量。

  DB2数据库的性能与稳定性直接跟数据库对象的多少、大小有关。如果对象很少,不复杂,那么就算不怎么规划,也能够达到比较高的性能。如果对象数据比较多、比较大的话,那么就需要在数据库设计之前好好的规划,否则会在很大程度上影响数据库的性能与稳定性。其实DB2 数据库就好像一个仓库,数据库中的对象(如索引、数据表、表空间)等等就好像仓库中的货物。如果货物比较少,那么随便放放,仓库都显得很空旷。货物寻找起来也会很方便。但是如果货物数量比较多、比较大,就必须要对其存储空间进行合理规划。只有如此才能够让仓库的空间利用率达到最佳状态。并且货物的存放有序,在查找起来也特别的方便。笔者这里就以仓库管理为例,说话该如何做好数据库对象大小、数量等方便的评估,以及他们对于数据库性能与稳定性的影响。

  1、根据对象大小来规划存储空间。在仓库货物的摆放上,要根据货物的大小来规划存储空间。或者说要首先防止大的货物。只有如此空间的利用率才会最高。其实在规划DB2对象的时候,也是如此。如某些表可能会包含的记录比较多,属于大表。此时数据库管理员就需要考虑,是否将其放置在一个独立的表空间或者硬盘空间上,以提高数据操作的性能。大表所对应的索引往往也是比较大的。为此在硬件条件允许的情况下,将索引表与数据表分别存放在不同的硬盘上,可以提高数据库的性能。而对于一些比较小的对象(如数据表),可以将它们存放在一个表空间中。其实这个表空间就好像仓库中的一个个纸盒子。将小的对象放入到这个“纸盒子”中,不但不占空间,而且也容易管理。

  2、根据对象的使用频率来规划存放空间。在仓库中摆放物品的时候,往往会把近期就要用到的货物或者频繁需要用到的东西放在仓库门口或者容易拿到的地方。如此在拿这些货物时就会比较便捷,也不会对其他货物产生影响。对于DB2数据库中的对象来说,也是这么一回事。可以将那些访问量比较大的对象,如索引、数据表,存放在性能比较好的硬盘上或者单独的硬盘中。此时访问这些数据,就不会与其它对象产生I/O冲突,操作起来速度就会比较快。而将不怎么用到的对象,存放在一起。由于他们不怎么被用到,所以即使存放在性能比较低的硬盘上,其对数据库性能产生的负面影响也是非常有限的。 在DB2数据库里面如何更新执行计划

  3、根据类别来存放数据库对象。在仓库中存放货物的时候,还会对其进行分类。然后根据类别来进行存放。这有利于货物的管理与检索。其实在数据库对象存储空间设计时,也需要考虑这个因素。如现在应用软件在设计的时候,很多都是根据模块来设计。那么在数据库对象设计时,也需要根据这个模块来设计存储的空间。如将同一个模块的数据库对象存放在同一个表空间内。不过这可能会跟上面的两个建立相违背。此时最好是在对象的命名上做文章。如可以根据模块的不同,分别给数据库对象取一个相同的前缀或者后缀。如即使同一块模块要用到多个表空间,此时就可以给表空间一个相同的前缀。如此在管理数据库对象的时候,根据表空间的前缀就可以判断其所属的模块了。如果再加上一个后缀来表示其数据库对象的分类,那么就更合理了。为此在管理数据库对象的时候,要执行分类管理。不仅要从技术上对其进行分类,如分为索引、数据表、关键字等等。还需要从功能上进行分类,如按应用程序的模块来进行分类等等。

  三、设计好数据库备份与还原的方案。

  在数据库交付生产使用之后,往往需要进行大量的测试。但是在测试过程中往往又会产生很多的垃圾数据。可是交给企业应用的,肯定是一个干净的数据库系统。为此在数据库设计的时候,就需要想好如果减少测试过程中的垃圾数据。或者采取什么样的方式来实现在交互时自动清除垃圾数据的机制。

  一般来说,想要一个数据库备份与还原的方案,减少数据库测试所产生的垃圾数据。如现在在给企业部署数据库的时候,往往是先安装一个干净的数据库系统。当然字符集这些需要预先设置好。然后再利用数据库还原功能将预先定义好的数据库模型还原出来。

  另外有些时候需要两个方案互为补充。如在数据库初始化的过程中,采用数据库还原的方式来创建数据库对象。但是在应用软件升级的时候,由于此时已经有了用户的数据,为此不能够在使用数据库还原的方法。而是通过应用程序来执行某些SQL代码,来调整或者增加部分数据库对象。无论采用哪一种方式,需要遵循的一个原则就是在给企业创建数据库对象时要最大限度的减少测试。而要做到这一点,就是需要先在测试服务器上创建对象并测试对象可用。然后直接将相关的SQL代码在投入使用的数据库服务器上执行。

5. 为什么需要设计数据库

数据库设计能够:
1、节省数据的存储空间     
2、能够保证数据的完整性
3、方便进行数据库应用系统的开发
 
糟糕的数据库设计:
1、数据冗余、存储空间浪费  
2、内存空间浪费 
3、数据更新和插入的异常

为什么需要设计数据库

6. 数据库设计难题

这里首先应该把业务逻辑理清楚,然后才考虑数据库的冗余问题。
1。 首先是两表之间的关联,按照你的描述是销售订单表的单号+款号与时间进度表的某个主键关联。
2。 然后是时间进度表的信息含义代表什么?也就意味着时间进度表中的值在什么时候更新?
我的建议是:在数据库中只保留两表关联的关系,不要考虑这种更新的逻辑,而是在程序代码中处理表间的联动,即时间进度表的添加、更新、删除。当销售订单表更新的时候,先删除所有时间进度表中的信息,然后重写入其中。

7. 为什么需要设计数据库

数据库设计能够:
1、节省数据的存储空间
2、能够保证数据的完整性
3、方便进行数据库应用系统的开发
糟糕的数据库设计:
1、数据冗余、存储空间浪费
2、内存空间浪费
3、数据更新和插入的异常

为什么需要设计数据库

8. 怎么设计这个数据库?

问这种问题通常都不容易说清楚,只能勉强做一下。要更清楚得详谈。
对于第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个问题:
则是数据库优化问题,要根据数据库访问特点,包括提高硬件性能(更好的机器、服务器群集)、加适当索引、采用适当的并发机制等方式来解决问题。而且最好有一个具体需求,然后尽快测试系统原型是否满足要求,不满足就设法改进直到满足要求为止。