数据库表设计有哪些规则，数据库建表的规则怎么才能建一个好的数据库

来源：整理时间：2024-05-16 05:35:07 编辑：黑码技术手机版

1，数据库建表的规则怎么才能建一个好的数据库

建议你参考下数据库设计范式（共六个），通常数据库设计满足第三范式就可以了。

朋友,我来告诉你答案!你是用什么建数据啊？？

你要看自己的需求要多详细一般达到三范式就行但是这个也不是固定的主要还是满足需求方便表的个数和字段放在哪个表中这都需要好好考虑愿意的话就把例子说一下大概给你想想

数据库建表的规则怎么才能建一个好的数据库

2，数据库的编制遵守哪些规则

最重要的,也是最基本的 --- 数据库的设计要满足三个范式要求.还有个三少原则:--表尽量少--表中列尽量少--表的主键列尽量少

建议把地区单独作为一张表：地区表（一般就是id主键、地区名）；小吃单独一张表：小吃表，存放小吃的各种属性（名称、口味等等属性）小吃关联地区：需要考虑的是有些地方可能都有相同的小吃那么，可能需要建立一张中间关系表：地区_小吃表（存放地区id、小吃id）即可。这样可以通过地区id查询出该地区的所有小吃；反之，可以通过小吃id查询出哪些地区有这些小吃。避免了，直接在小吃表关联地区，造成数据重复。如果没有其他操作的话，这三张表就可满足了。希望能帮助你！

数据库的编制遵守哪些规则

3，foxpro 数据库设计原则有哪几要

要应试的话，以下废话...... 每个具体项目，有不同的具体要求，于是有不同的数据库设计，做真实工程的话，先要同使用方细致地沟通，尽量让双方达成项目功能和性能的共识，这一点非常重要，因为懂业务的人不一定懂编程，懂编程的人不一定懂业务，通常设计数据库主要考虑：1. 必须兼顾用户使用以及程序设计的高效性，优先考虑频率高的表分配和字段分配，合理配置关键字段，合理使用备注型字段，合理使用索引，该复杂的复杂，该简单的简单。2. 必须考虑可扩展性，不要在项目完成时因为客户的补充要求，使数据库出现一堆鸡勒字段。3. 必须考虑数据完整性，注意结合程序，避免因忽然停电，网络故障导致的数据缺失。4. 必须考虑数据的可靠性，注意结合程序，保证录入、查询、汇总结果的真确性。基于数据库的应用程序，数据库的设计直接影响着所有的后续开发，数据库的设计的关键是必须要【细心周到】。又谬论了一回......仍希望你懂我......

foxpro 数据库设计原则有哪几要

4，Sqlserver数据库设计原则

由于字数太多，只能分开来写了，望见谅！如果希望设计出比较好的数据库，有一些专门的规则，称为数据库的设计范式。遵循这些规则，你将设计出良好的数据库。下面将逐一对其进行说明： 1.第一范式：它的目标是确保每一列的原子性，如果每列（或属性）都是不可再分的最小数据单元，则满足第一范式。 2.第二范式：第二范式则是在第一范式的基础上，更近一层，目标是确保表中的每一列都和主键相关。如果一个关系满足第一范式，并且除了主键意外的其他列，都依赖与该主键，则满足第二范式。例如：订单表（订单编号，产品编号，订购日期，价格，。。。）;该表主要用来表述订单，所以将订单设为主键，而“订购日期”，“价格”这两列与“订单编号”主键相关。但是“产品编号”并不依赖于“订单编号”，该列应当删除，放入产品表中。这样，该表就之描述一件事情：订单信息了。

1、确定b表结构支持a的数据 2、使用sql server 数据段导入功能请参考 http://www.itmop.com/network/sql/mssql/0717454.html

5，请大伙给我解释一下数据库设计的基本原则

这个很抽象！

如果完全按照3个范式，不但对数据库服务器是一个考验，对统计数据也是一种考验哈当你的数据是千万级的时候就会知道其实是个噩梦

数据库设计的三范式所谓范式，是关系型数据库关系模式规范化的标准，从规范化的宽松到严格，分别为不同的范式，通常使用的有第一范式、第二范式、第三范式及BC范式等。范式是建立在函数依赖基础上的。函数依赖定义：设有关系模式R(U)，X和Y是属性集U的子集，函数依赖是形为X→Y的一个命题，对任意R中两个元组t和s，都有t[X]=s[X]蕴涵t[Y]=s[Y]，那么FD X→Y在关系模式R(U)中成立。X→Y读作X函数决定Y，或Y函数依赖于X。通俗的讲，如果一个表中某一个字段Y的值是由另外一个字段或一组字段X的值来确定的，就称为Y函数依赖于X。函数依赖应该是通过理解数据项和企业的规则来决定的，根据表的内容得出的函数依赖可能是不正确的。第一范式（1NF）定义：如果关系模式R的每个关系r的属性都是不可分的数据项，那么就称R是第一范式的模式。　　简单的说，每一个属性都是原子项，不可分割。1NF是关系模式应具备的最起码的条件，如果数据库设计不能满足第一范式，就不称为关系型数据库。关系数据库设计研究的关系规范化是在1NF之上进行的。第二范式（2NF）定义：如果关系模式R是1NF，且每个非主属性完全函数依赖于候选键，那么就称R是第二范式。简单的说，第二范式要满足以下的条件：首先要满足第一范式，其次每个非主属性要完全函数依赖与候选键，或者是主键。也就是说，每个非主属性是由整个主键函数决定的，而不能由主键的一部分来决定。举个例子：　　有股票日行情表的主键是股票代码和交易日期组成。非主属性中有收盘价和成交量等，都是由主键，即股票代码和交易日期函数决定的，单独的股票代码或者交易日期都不能函数决定这些非主属性。如果这个表中有非主属性股票简称，则股票简称是可以由股票代码来函数决定的，这样股票简称这个非主属性就不是完全函数依赖于候选键，这样的设计就不满足第二范式。第三范式（3NF）定义：如果关系模式R是2NF，且关系模式R（U，F）中的所有非主属性对任何候选关键字都不存在传递依赖，则称关系R是属于第三范式。简单的说，第三范式要满足以下的条件：首先要满足第二范式，其次非主属性之间不存在函数依赖。由于满足了第二范式，表示每个非主属性都函数依赖于主键。如果非主属性之间存在了函数依赖，就会存在传递依赖，这样就不满足第三范式。举个例子：在股票基本情况表中，主键是股票代码，有非主属性所属一级行业和所属二级行业。根据业务规则，所属二级行业能够函数决定所属一级行业，这就表示存在这样一种关系：股票代码函数决定所属二级行业，所属二级行业函数决定所属一级行业，这就形成了传递依赖，这样的设计就不符合第三范式。不过在实际运用中，为查询和使用的方便，有时也会违反第三范式。如上例，如果没有所属一级行业的属性，需要查询所属一级行业的相关股票，需要查询时使用函数来从二级行业中函数生成所属一级行业，使用性能上会受影响。所以通常会加上所属一级行业的属性。BC范式（BCNF）BC范式是第三范式的增强版，不过也有人说是直接从1NF发展过来的，即每个属性，包括主属性或非主属性，都完全依赖于候选键，并且不存在传递依赖情况。

设计数据库不应该有这些： 1数据冗余 2不一致性 3插入异常 4删除异常这图就出现了问题如人工智能的学分不一致有两个文化学这就出现了以上的问题所以要杜绝我们可以这样分为两个表如下：右边的表只要把人工智能的删除一个就好了（画错了不好意思）在就是函数的一些关系如函数依赖： v函数依赖设R(U)是一个属性集U上的关系，X和Y是U的子集。如果属性集合X中每个属性的值构成的集合唯一地决定了属性集合Y中每个属性的值构成的集合，则属性集合Y函数依赖于属性集合X，计为：X→Y 如下表所示，知道了“课程名”的值，即可知道“授课学时”的值。称“授课学时”函数依赖于“课程名”，或“课程名”可以决定“授课学时”，记作课程名→授课学时。还有这个 v部分函数依赖：如果非主属性B函数依赖于构成某个候选关键字的一组主属性A的某一个真子集，则称B部分函数依赖于A。 v如“学分”函数依赖于主关键字{学号、课程}。但决定“学分”的只是“课程”，与“学号”无关，则称“学分”部分函数依赖于{学号、课程} 。传递关系： v传递函数依赖的关系：在R (U)中，如存在X，Y，Z包含于U ，且满足：X—>Y ，Y—>Z，则称Z传递函数依赖于X。 v学生住宿的楼号依赖于学号，学生应交的住宿费是由楼号决定的，即“收费”依赖于“楼号”，“楼号”依赖于“学号”，则“收费”传递函数依赖于“学号”。接下来的就是要符合范式：第一范式：任何符合关系定义的表即满足第一范式。 IDNameSexAgeMaleFemale101张三Y 20102李四 Y21v第二范式 ?