• 关于

    范式

    的搜索结果

回答

第一范式:列不可再分 第二范式:行可以唯一区分,主键约束 第三范式:表的非主属性不能依赖与其他表的非主属性 外键约束 且三大范式是一级一级依赖的,第二范式建立在第一范式上,第三范式建立第一第二范式上
茶什i 2019-12-02 03:14:30 0 浏览量 回答数 0

回答

第一范式:每个列都不可以再拆分。 第二范式:在第一范式的基础上,非主键列完全依赖于主键,而不能是依赖于主键的一部分。 第三范式:在第二范式的基础上,非主键列只依赖于主键,不依赖于其他非主键。 在设计数据库结构的时候,要尽量遵守三范式,如果不遵守,必须有足够的理由。比如性能。事实上我们经常会为了性能而妥协数据库的设计。
剑曼红尘 2020-03-31 10:25:47 0 浏览量 回答数 0

问题

这个数据库设计满足第三范式么?

这个数据库设计满足第三范式么?我是参照第三范式设计的机票管理系统...
a123456678 2019-12-01 20:16:52 616 浏览量 回答数 1

回答

一般的数据表设计至少要满足一范式,基于减少冗余节省存储空间的目的,应尽量设计满足三范式的数据表。但是有时候可能为了业务需求也需要保留冗余即存留传递依赖的字段。所以企业级数据库设计时,至少要满足二范式。
51干警网 2019-12-02 01:34:33 0 浏览量 回答数 0

回答

第一范式()无重复的列 第二范式(2NF)属性完全依赖于主键 [消除部分子函数依赖] 第三范式(3NF)属性不依赖于其它非主属性 [消除传递依赖]
游客6nvww5bb5kd2w 2020-02-14 19:58:32 0 浏览量 回答数 0

回答

根据第三范式定义每个非关键字列都独立于其他非关键字列,并依赖于关键字,第三范式指数据库中不能存在传递函数依赖关系。航班表,机票表,客户表中的非关键字和其他非关键字都依赖于主键,而且非互相依赖(也就是说知道其中一个非关键字,并没有一个函数能求出另一个非关键字),所以是符合第三范式的。
a123456678 2019-12-02 03:03:20 0 浏览量 回答数 0

问题

数据的三范式

数据的三范式...
游客6nvww5bb5kd2w 2020-02-14 19:58:18 0 浏览量 回答数 1

回答

首先应尽量满足三范式的要求,在一定程度上打破三范式的要求以提高数据库的性能。例如,我们创建某些表的时候,不仅会插入外键,还会插入相关的属性,这违反了第三范式,但这样做的好处,就是我们在业务查询的时候会减少很多关联查询,从而提高查询效率。
茶什i 2019-12-02 03:14:32 0 浏览量 回答数 0

问题

数据库三范式是什么?

数据库三范式是什么?...
茶什i 2019-12-01 21:57:15 5 浏览量 回答数 1

问题

[@倚贤][¥20]数据库范式

数据库范式...
jack胡 2019-12-01 19:28:15 401 浏览量 回答数 1

问题

数据库三大范式是什么?

数据库三大范式是什么?...
剑曼红尘 2020-03-31 10:25:37 0 浏览量 回答数 1

问题

如何通俗地理解三个范式?

如何通俗地理解三个范式?...
珍宝珠 2019-12-01 21:59:06 32 浏览量 回答数 1

回答

第一范式:1NF是对属性的原子性约束,要求属性具有原子性,不可再分解; 第二范式:2NF是对记录的惟一性约束,要求记录有惟一标识,即实体的惟一性; 第三范式:3NF是对字段冗余性的约束,即任何字段不能由其他字段派生出来,它要求字段没有冗余。
珍宝珠 2019-12-02 03:16:29 0 浏览量 回答数 0

问题

企业级应用的数据库,应该满足几范式?

企业级应用的数据库,应该满足几范式?...
51干警网 2019-12-01 19:41:07 1324 浏览量 回答数 1

回答

首先,json的范式是:参考:http://json.org/从上图可以看出,key的类型,只能是string,至于value值,有string,array,object等(详情可以从上面的链接查看)。至于string类型,标准的格式是:string形式: "" 或者 " chars "(这个在链接页面也有。)标准的字符串,是由双引号括起来的。 知道了json的范式,你的问题也很清晰了。无论你的key是什么类型,都会被解析器认为是string类型,因为这是范式要求。所以不是多了一对引号,只是因为你本来的key值,解析出来的结果有字符串而已。
蛮大人123 2019-12-02 01:55:20 0 浏览量 回答数 0

问题

Kotlin 是什么?

Kotlin的发展历程有人知道吗? Kotlin有哪些特性? 编程范式是什么? 编程范式有哪些类型?...
问问小秘 2020-04-30 16:30:43 1 浏览量 回答数 1

回答

数据库范式,简言之就是,数据库设计对数据的存储性能,还有开发人员对数据的操作都有莫大的关系。所以建立科学的,规范的的数据库是需要满足一些。规范的来优化数据数据存储方式。在关系型数据库中这些规范就可以称为范式
1565966273186108 2019-12-02 01:50:32 0 浏览量 回答数 0

回答

通常先考虑性能,如果冗余一个字段能够减少很多关联查询,那么通常会选择冗余,而不是去追求第三范式。例如文章详情页通常会有评论数,这个评论数通常会冗余在文章表中,而不是每次去评论表中统计。但是反范式也有缺点:维护的字段多了,数据可能不一致,存储空间也大了等等。这就要看是否能灵活运用了
我的中国 2019-12-02 01:34:01 0 浏览量 回答数 0

问题

弱监督机器学习范式

东南大学计算机科学与工程学院张敏灵在CCAI 2017中国人工智能大会上做了主题为《弱监督机器学习范式》的分享,就大数据分析,传统的监督学习,MLL的挑战做了深入的分析。 https://yq....
福利达人 2019-12-01 20:57:22 371 浏览量 回答数 0

问题

mysql建表的规范和实际应用中的冲突问题。

今天研究shopnc的数据表结构,发现很多表不按照三范式来建表,很多表都是相关字段重复。优点是很多时候不用关联表进行查询了。缺点是不按照三范式规范,而且如果中途改一个表的字段后,相应的表也应该进行修改,但到那个时候已然发现不好改了,因为可能...
我的中国 2019-12-01 19:40:36 1120 浏览量 回答数 1

回答

数据库设计中的第一范式:如果一个关系模式R的所有属性都是不可分的基本数据项,则R∈1NF。你这个模型中数据跟当前时间存在关联,显然不符合第一范式,不建议存在数据库里面.建议写到 Memcache 里面,然后使用 Cron job 来更新数值.如果一定要用数据库来实现,也可以不用循环来求平均值的.取出来的就是 2013-12-02 02:00:00 过去 24 小时的平均值.
蛮大人123 2019-12-02 01:45:22 0 浏览量 回答数 0

问题

魔乐MLDN李兴华主讲Oracle视频教程

百度网盘:http://pan.baidu.com/s/1c08H79Y 文件大小:3.04G 提取密码:m46x 解压密码:www.he11oworld.com 1-Oracl...
webssss 2019-12-01 20:58:21 13867 浏览量 回答数 5

问题

云栖商学院-打造“技术+管理”新范式

阿里云大学正雄在2017杭州云栖大会中做了题为《云栖商学院-打造“技术+管理”新范式》的分享,就技术驱动商业的发展,商学院的挑战和机遇,云栖商学院技术+管理双轮驱动做了深入的分析。 https...
福利达人 2019-12-01 21:13:40 462 浏览量 回答数 0

问题

关于数据表反三范式的一点疑问?

一个简单的问题:文章分类表:article_type(id, name, pid, num)这个num是该分类下的文章数量,我之前一直就是这样的,在新增文章或者删除文章时都会更新对应分类的num字段。但是现在我觉的这好像没有必要,因为每个文...
a123456678 2019-12-01 20:15:37 960 浏览量 回答数 2

回答

反范式化,将关联的文档放在主文档的内部
西秦说云 2019-12-02 01:41:11 0 浏览量 回答数 0

回答

自己先用 第三范式 分解 再跟据需求 合理地冗余一些字段。
杨冬芳 2019-12-02 02:37:18 0 浏览量 回答数 0

问题

阿里云移动云Apsara Mobile重磅发布 推出Cloud Native App全新研发范式

10月13日,阿里巴巴在2017杭州·云栖大会上重磅发布了阿里云移动云ApsaraMobile。阿里云移动云是一套帮助开发者构建工程化、系统化、智能化的移动研发体系能力的云计算服务,功能覆盖移动研发的全生命周期。同时ÿ...
mqc 2019-12-01 21:33:13 1382 浏览量 回答数 1

回答

1. 原始单据与实体之间的关系 可以是一对一、一对多、多对多的关系。在一般情况下,它们是一对一的关系:即一张原始单据对应且只对应一个实体。在特殊情况下,它们可能是一对多或多对一的关系,即一张原始单证对应多个实体,或多张原始单证对应一个实体。 这里的实体可以理解为基本表。明确这种对应关系后,对我们设计录入界面大有好处。 〖例1〗:一份员工履历资料,在人力资源信息系统中,就对应三个基本表:员工基本情况表、社会关系表、工作简历表。这就是“一张原始单证对应多个实体”的典型例子。 2. 主键与外键 一般而言,一个实体不能既无主键又无外键。在E—R 图中, 处于叶子部位的实体, 可以定义主键,也可以不定义主键(因为它无子孙), 但必须要有外键(因为它有父亲)。 主键与外键的设计,在全局数据库的设计中,占有重要地位。当全局数据库的设计完成以后,有个美国数据库设计专家说:“键,到处都是键,除了键之外,什么也没有”,这就是他的数据库设计经验之谈,也反映了他对信息系统核心(数据模型)的高度抽象思想。 因为:主键是实体的高度抽象,主键与外键的配对,表示实体之间的连接。 3. 基本表的性质 基本表与中间表、临时表不同,因为它具有如下四个特性: 原子性。基本表中的字段是不可再分解的。原始性。基本表中的记录是原始数据(基础数据)的记录。演绎性。由基本表与代码表中的数据,可以派生出所有的输出数据。稳定性。基本表的结构是相对稳定的,表中的记录是要长期保存的。理解基本表的性质后,在设计数据库时,就能将基本表与中间表、临时表区分开来。 4. 范式标准 基本表及其字段之间的关系, 应尽量满足第三范式。但是,满足第三范式的数据库设计,往往不是最好的设计。为了提高数据库的运行效率,常常需要降低范式标准:适当增加冗余,达到以空间换时间的目的。〖例2〗:有一张存放商品的基本表,如表1所示。“金额”这个字段的存在,表明该表的设计不满足第三范式,因为“金额”可以由“单价”乘以“数量”得到,说明“金额”是冗余字段。但是,增加“金额”这个冗余字段,可以提高查询统计的速度,这就是以空间换时间的作法。在Rose 2002中,规定列有两种类型:数据列和计算列。“金额”这样的列被称为“计算列”,而“单价”和“数量”这样的列被称为“数据列”。640?wx_fmt=png 表1 商品表的表结构 5. 通俗地理解三个范式 通俗地理解三个范式,对于数据库设计大有好处。在数据库设计中,为了更好地应用三个范式,就必须通俗地理解三个范式(通俗地理解是够用的理解,并不是最科学最准确的理解): 第一范式:1NF是对属性的原子性约束,要求属性具有原子性,不可再分解 第二范式:2NF是对记录的惟一性约束,要求记录有惟一标识,即实体的惟一性; 第三范式:3NF是对字段冗余性的约束,即任何字段不能由其他字段派生出来,它要求字段没有冗余。 没有冗余的数据库设计可以做到。但是,没有冗余的数据库未必是最好的数据库,有时为了提高运行效率,就必须降低范式标准,适当保留冗余数据。具体做法是:在概念数据模型设计时遵守第三范式,降低范式标准的工作放到物理数据模型设计时考虑。降低范式就是增加字段,允许冗余。 6. 要善于识别与正确处理多对多的关系 若两个实体之间存在多对多的关系,则应消除这种关系。消除的办法是,在两者之间增加第三个实体。这样,原来一个多对多的关系,现在变为两个一对多的关系。要将原来两个实体的属性合理地分配到三个实体中去。 这里的第三个实体,实质上是一个较复杂的关系,它对应一张基本表。一般来讲,数据库设计工具不能识别多对多的关系,但能处理多对多的关系。 〖例3〗:在“图书馆信息系统”中,“图书”是一个实体,“读者”也是一个实体。这两个实体之间的关系,是一个典型的多对多关系:一本图书在不同时间可以被多个读者借阅,一个读者又可以借多本图书。为此,要在二者之间增加第三个实体,该实体取名为“借还书”,它的属性为:借还时间、借还标志(0表示借书,1表示还书),另外,它还应该有两个外键(“图书”的主键,“读者”的主键),使它能与“图书”和“读者”连接。 7. 主键PK的取值方法 PK是供程序员使用的表间连接工具,可以是一无物理意义的数字串, 由程序自动加1来实现。也可以是有物理意义的字段名或字段名的组合。不过前者比后者好。当PK是字段名的组合时,建议字段的个数不要太多,多了不但索引占用空间大,而且速度也慢。 8. 正确认识数据冗余 主键与外键在多表中的重复出现, 不属于数据冗余,这个概念必须清楚,事实上有许多人还不清楚。非键字段的重复出现, 才是数据冗余!而且是一种低级冗余,即重复性的冗余。高级冗余不是字段的重复出现,而是字段的派生出现。〖例4〗:商品中的“单价、数量、金额”三个字段,“金额”就是由“单价”乘以“数量”派生出来的,它就是冗余,而且是一种高级冗余。冗余的目的是为了提高处理速度。 只有低级冗余才会增加数据的不一致性,因为同一数据,可能从不同时间、地点、角色上多次录入。因此,我们提倡高级冗余(派生性冗余),反对低级冗余(重复性冗余)。 9. E--R图没有标准答案 信息系统的E--R图没有标准答案,因为它的设计与画法不是惟一的,只要它覆盖了系统需求的业务范围和功能内容,就是可行的。反之要修改E--R图。尽管它没有惟一的标准答案,并不意味着可以随意设计。好的E—R图的标准是:结构清晰、关联简洁、实体个数适中、属性分配合理、没有低级冗余。 10. 视图技术在数据库设计中很有用 与基本表、代码表、中间表不同,视图是一种虚表,它依赖数据源的实表而存在。视图是供程序员使用数据库的一个窗口,是基表数据综合的一种形式, 是数据处理的一种方法,是用户数据保密的一种手段。 为了进行复杂处理、提高运算速度和节省存储空间, 视图的定义深度一般不得超过三层。若三层视图仍不够用, 则应在视图上定义临时表, 在临时表上再定义视图。这样反复交迭定义, 视图的深度就不受限制了。 对于某些与国家政治、经济、技术、军事和安全利益有关的信息系统,视图的作用更加重要。这些系统的基本表完成物理设计之后,立即在基本表上建立第一层视图,这层视图的个数和结构,与基本表的个数和结构是完全相同。并且规定,所有的程序员,一律只准在视图上操作。 只有数据库管理员,带着多个人员共同掌握的“安全钥匙”,才能直接在基本表上操作。请读者想想:这是为什么? 11. 中间表、报表和临时表 中间表是存放统计数据的表,它是为数据仓库、输出报表或查询结果而设计的,有时它没有主键与外键(数据仓库除外)。临时表是程序员个人设计的,存放临时记录,为个人所用。基表和中间表由DBA维护,临时表由程序员自己用程序自动维护。 12. 完整性约束表现在三个方面 域的完整性:用Check来实现约束,在数据库设计工具中,对字段的取值范围进行定义时,有一个Check按钮,通过它定义字段的值城。 参照完整性:用PK、FK、表级触发器来实现。用户定义完整性:它是一些业务规则,用存储过程和触发器来实现。 13. 防止数据库设计打补丁的方法是“三少原则” 1、一个数据库中表的个数越少越好。只有表的个数少了,才能说明系统的E--R图少而精,去掉了重复的多余的实体,形成了对客观世界的高度抽象,进行了系统的数据集成,防止了打补丁式的设计; 2、一个表中组合主键的字段个数越少越好。因为主键的作用,一是建主键索引,二是做为子表的外键,所以组合主键的字段个数少了,不仅节省了运行时间,而且节省了索引存储空间; 3、一个表中的字段个数越少越好。只有字段的个数少了,才能说明在系统中不存在数据重复,且很少有数据冗余,更重要的是督促读者学会“列变行”,这样就防止了将子表中的字段拉入到主表中去,在主表中留下许多空余的字段。所谓“列变行”,就是将主表中的一部分内容拉出去,另外单独建一个子表。这个方法很简单,有的人就是不习惯、不采纳、不执行。 数据库设计的实用原则是:在数据冗余和处理速度之间找到合适的平衡点。“三少”是一个整体概念,综合观点,不能孤立某一个原则。该原则是相对的,不是绝对的。“三多”原则肯定是错误的。试想:若覆盖系统同样的功能,一百个实体(共一千个属性) 的E--R图,肯定比二百个实体(共二千个属性)的E--R图,要好得多。 提倡“三少”原则,是叫读者学会利用数据库设计技术进行系统的数据集成。数据集成的步骤是将文件系统集成为应用数据库,将应用数据库集成为主题数据库,将主题数据库集成为全局综合数据库。 集成的程度越高,数据共享性就越强,信息孤岛现象就越少,整个企业信息系统的全局E—R图中实体的个数、主键的个数、属性的个数就会越少。提倡“三少”原则的目的,是防止读者利用打补丁技术,不断地对数据库进行增删改,使企业数据库变成了随意设计数据库表的“垃圾堆”,或数据库表的“大杂院”,最后造成数据库中的基本表、代码表、中间表、临时表杂乱无章,不计其数,导致企事业单位的信息系统无法维护而瘫痪。 “三多”原则任何人都可以做到,该原则是“打补丁方法”设计数据库的歪理学说。“三少”原则是少而精的原则,它要求有较高的数据库设计技巧与艺术,不是任何人都能做到的,因为该原则是杜绝用“打补丁方法”设计数据库的理论依据。 14. 提高数据库运行效率的办法 在给定的系统硬件和系统软件条件下,提高数据库系统的运行效率的办法是:在数据库物理设计时,降低范式,增加冗余, 少用触发器, 多用存储过程。 当计算非常复杂、而且记录条数非常巨大时(例如一千万条),复杂计算要先在数据库外面,以文件系统方式用C++语言计算处理完成之后,最后才入库追加到表中去。这是电信计费系统设计的经验。 发现某个表的记录太多,例如超过一千万条,则要对该表进行水平分割。水平分割的做法是,以该表主键PK的某个值为界线,将该表的记录水平分割为两个表。若发现某个表的字段太多,例如超过八十个,则垂直分割该表,将原来的一个表分解为两个表。 对数据库管理系统DBMS进行系统优化,即优化各种系统参数,如缓冲区个数。在使用面向数据的SQL语言进行程序设计时,尽量采取优化算法。 总之,要提高数据库的运行效率,必须从数据库系统级优化、数据库设计级优化、程序实现级优化,这三个层次上同时下功夫。
茶什i 2019-12-27 15:54:46 0 浏览量 回答数 0

回答

我试图在这里尝试用外行术语解释标准化。首先,它适用于关系数据库(Oracle,Access,MySQL),因此不仅适用于MySQL。 规范化是要确保每个表都只有最小的字段并摆脱依赖关系。假设您有一个员工记录,而每个员工都属于一个部门。如果将部门与员工的其他数据一起存储为字段,则会遇到问题-如果删除部门,会发生什么?您必须更新所有部门字段,并且有机会出错。如果某些员工没有部门(也许是新分配的)怎么办?现在将有空值。 因此,简而言之,标准化是要避免字段为空,并确保表中的所有字段仅属于所描述数据的一个域。例如,在雇员表中,这些字段可以是ID,姓名,社会保险号,但是这三个字段与部门无关。仅员工ID描述该员工所属的部门。因此,这意味着员工所在的部门应该在另一个表中。 这是一个简单的规范化过程。 EMPLOYEE ( < employee_id >, name, social_security, department_name) 如所解释的,这没有被标准化。规范化的形式可能看起来像 EMPLOYEE ( < employee_id >, name, social_security) 在这里,Employee表仅负责一组数据。那么,我们在哪里存储员工所属的部门?在另一张桌子 EMPLOYEE_DEPARTMENT ( < employee_id >, department_name ) 这不是最佳的。如果部门名称更改怎么办?(美国政府一直在发生这种情况)。因此最好这样做 EMPLOYEE_DEPARTMENT ( < employee_id >, department_id ) DEPARTMENT ( < department_id >, department_name ) 有第一范式,第二范式和第三范式。但是,除非您正在学习数据库课程,否则我通常只会采用我能理解的最规范的形式。 希望这可以帮助。来源:stack overflow
保持可爱mmm 2020-05-11 12:00:20 0 浏览量 回答数 0

回答

列数多,也就是一般说的胖表,大于50列才能说是胖吧,窄表更好些,当然也不是绝对的。数据库设计还是从属于业务,能在基本遵从二范式就好,有时候为了性能必要的数据冗余还是要的
落地花开啦 2019-12-02 01:44:32 0 浏览量 回答数 0
阿里云企业服务平台 陈四清的老板信息查询 上海奇点人才服务相关的云产品 爱迪商标注册信息 安徽华轩堂药业的公司信息查询 小程序定制 上海微企信息技术相关的云产品 国内短信套餐包 ECS云服务器安全配置相关的云产品 天籁阁商标注册信息 开发者问答 阿里云建站 自然场景识别相关的云产品 万网 小程序开发制作 视频内容分析 视频集锦 代理记账服务 北京芙蓉天下的公司信息查询