数据库设计多对多关系的几种形态

本文分享了数据库设计中的十四项实用技巧,包括处理实体间关系、理解范式标准、防止冗余及提升运行效率等,帮助读者设计高效且合理的数据库。

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

本文来自优快云博客,转载请标明出处:http://blog.youkuaiyun.com/shuilv2000/archive/2009/04/22/4100727.aspx

<think>我们正在讨论非关系数据库(NoSQL)中的跨形态数据检索,并与关系数据库(RDBMS)进行比较。跨形态数据检索指的是能够同时处理多种类型的数据(如结构化、半结构化、非结构化)并进行检索的能力。 根据引用[1]和[2],关系数据库擅长存储结构化数据,支持复杂的SQL查询和事务处理,但在处理半结构化或非结构化数据时可能不够灵活。而非关系数据库则提供了多种数据模型(如文档、键值、图、列存储等)来适应不同类型的数据。 下面我们将从以下几个方面展开: 1. 非关系数据库实现跨形态数据检索的方法 2. 关系数据库在跨形态数据检索中的做法 3. 两者在便利性上的比较 一、非关系数据库实现跨形态数据检索的方法 非关系数据库有多种类型,每种类型针对不同形态的数据有不同的检索方式。 1. 文档数据库(如MongoDB): - 存储:文档数据库可以存储半结构化的数据(如JSON、XML),每个文档可以有不同的结构。 - 检索:支持丰富的查询语言(如MongoDB的查询语法),可以对嵌套字段、数组进行查询,还支持全文索引(对文本内容进行检索)和地理空间索引等。 - 跨形态数据:由于文档数据库的灵活性,可以同时存储结构化数据和半结构化数据,并利用其查询能力进行检索。例如,一个文档可以包含文本字段(非结构化)、元数据(结构化)和标签数组(半结构化)。 2. 图数据库(如Neo4j): - 存储:图数据库专注于存储实体(节点)和关系(边),适合高度关联的数据。 - 检索:通过图遍历进行检索,可以高效地查询关系。图数据库通常有自己的查询语言(如Cypher),支持模式匹配、路径查询等。 - 跨形态数据:图数据库本身存储的是结构化的节点和关系,但可以通过属性存储非结构化数据的引用(如外部存储的PDF文件路径),然后结合外部系统实现全文检索(如通过集成Elasticsearch)。 3. 列存储数据库(如Cassandra): - 存储:按列存储数据,适合大规模数据的高效读写。 - 检索:支持基于主键的快速查询,但复杂查询能力有限。 - 跨形态数据:通常用于结构化数据,对于非结构化数据,需要设计合适的列族结构,或者结合其他系统。 4. 键值数据库(如Redis): - 存储:简单的键值对,值可以是字符串、列、集合等。 - 检索:通过键快速检索值,值的内容可以是任意形态,但数据库本身不提供对值内容的复杂检索(如全文搜索)。 - 跨形态数据:通常需要应用层解析值的内容,或者结合其他工具(如Redis的模块RediSearch)进行全文检索。 5. 多模型数据库(如ArangoDB): - 存储:支持多种数据模型(文档、图、键值)在一个数据库中。 - 检索:提供统一的查询语言(如AQL),可以同时查询不同形态的数据。 - 跨形态数据:这是非关系数据库中处理跨形态数据检索的先进方式,允许在一个查询中结合文档查询和图遍历。 二、关系数据库在跨形态数据检索中的做法 关系数据库通常要求数据有固定的模式(结构)。为了处理跨形态数据,传统做法包括: 1. 结构化数据:直接存储中,利用SQL进行复杂查询。 2. 半结构化数据:使用JSON/XML数据类型(如PostgreSQL的JSONB,MySQL的JSON类型),并利用相应的函数和索引进行查询。 3. 非结构化数据:通常存储在外部文件系统,数据库中只存储路径或元数据,或者使用BLOB类型存储(但不推荐大文件)。对于文本内容,可以使用全文检索功能(如MySQL的全文索引,PostgreSQL的tsvector)。 然而,关系数据库在处理非结构化和半结构化数据时,其灵活性和性能可能不如非关系数据库。例如,当数据模式经常变化时,修改结构可能很麻烦。 三、便利性比较 1. 灵活性: - NoSQL:无需预定义模式,可以动态添加字段,适合多变的数据形态。在同一个集合(或)中可以存储不同结构的数据。 - RDBMS:需要预先定义模式,修改模式可能涉及复杂的迁移操作。虽然现在支持JSON类型,但查询和索引仍然需要额外配置。 2. 查询能力: - NoSQL:不同类型的NoSQL数据库查询能力差异很大。文档数据库(如MongoDB)和图数据库(如Neo4j)在各自的领域有强大的查询能力,但跨模型查询可能需要多模型数据库。 - RDBMS:SQL是强大的标准化查询语言,支持复杂的连接和聚合操作。对于半结构化数据(如JSON),现代关系数据库也提供了查询功能,但不如专门的文档数据库自然。 3. 扩展性: - NoSQL:通常设计为分布式,易于水平扩展,适合大数据量和高并发。 - RDBMS:垂直扩展较为容易,水平扩展(分片)比较复杂。 4. 事务和一致性: - RDBMS:支持ACID事务,保证数据一致性。 - NoSQL:通常遵循BASE原则(基本可用、软状态、最终一致),牺牲一致性以获得可用性和分区容忍性。但也有一些NoSQL数据库支持事务(如MongoDB的多文档事务,但使用起来比关系数据库复杂)。 5. 跨形态数据检索的便利性: - 非关系数据库:在存储和检索多种形态数据时,通常更灵活和高效。例如,文档数据库可以自然地存储和检索JSON文档,图数据库可以高效处理关联关系。 - 关系数据库:对于以结构化数据为主,同时包含少量半结构化数据的场景,利用JSON类型可以满足需求。但如果非结构化数据占比较大,可能需要结合外部系统(如Elasticsearch进行全文检索),这样会增加系统复杂度。 总结: 非关系数据库在跨形态数据检索方面具有天然的灵活性,尤其是文档数据库和图数据库。而关系数据库在结构化数据的复杂查询和事务处理上具有优势,虽然现代关系数据库增加了对半结构化数据的支持,但在处理大规模非结构化数据时仍需要借助外部系统。 因此,选择哪种数据库取决于具体应用场景: - 如果应用以结构化数据为主,且需要强事务和复杂查询,关系数据库更合适。 - 如果应用需要处理多种形态的数据(尤其是半结构化和非结构化),且对水平扩展和灵活性要求高,非关系数据库更合适。 在实际应用中,也常常采用混合架构(多模数据库),或者将关系数据库和非关系数据库结合使用,以发挥各自的优势。 §§相关问题§§ 1. 如何选择关系数据库和非关系数据库用于混合数据存储? 2. 在非关系数据库中,如何实现高效的全文检索? 3. 现代关系数据库对JSON数据的支持程度如何? 4. 图数据库在处理关联数据时有哪些优势?</think>### 非关系数据库中的跨形态数据检索方法及与关系数据库比较 #### 一、非关系数据库实现跨形态数据检索的方法 1. **多模型数据库(Multi-model Databases)** - **原理**:在单一引擎中支持文档、图、键值、列存储等多种数据模型 - **实现方式**: ```cypher // ArangoDB示例:同时查询文档和图数据 FOR doc IN documents FILTER doc.type == "PDF" FOR v, e IN 1..2 OUTBOUND doc related_docs RETURN {document: doc, connections: e} ``` - **优势**:统一查询语言(如AQL)处理JSON文档、图关系等异构数据[^2] 2. **混合存储架构** - **核心组件**: - 文档库(MongoDB)存储半结构化数据 - 图数据库(Neo4j)处理关联关系 - 搜索引擎(Elasticsearch)实现全文检索 - **数据流**: ```mermaid graph LR A[PDF文件] --> B[文本提取] --> C[Elasticsearch] D[CSV数据] --> E[MongoDB] F[设备元数据] --> G[Neo4j] C & E & G --> H[统一查询层] ``` 3. **非结构化数据处理技术** - **文本检索**:倒排索引(Elasticsearch)、N-Gram分词 - **图像检索**: - 特征向量存储:$v_{\text{img}} = [0.12, -0.05, ..., 0.78]^T$ - 相似度计算:$\text{sim}(q,v) = \frac{q \cdot v}{\|q\| \|v\|}$ - **跨模态对齐**:CLIP等模型建立文本-图像联合嵌入空间 #### 二、关系数据库的跨形态检索实现 1. **结构化数据主导模式** ```sql -- PostgreSQL JSONB查询示例 SELECT metadata->>'author', pdf_content FROM documents WHERE metadata @> '{"type": "PDF"}'; ``` - **局限**:BLOB字段无法直接索引内容,需借助外部扩展[^1] 2. **混合解决方案** | 组件 | 职责 | |---------------------|--------------------------| | 关系数据库 | 存储结构化元数据 | | 文件系统/对象存储 | 存放大文件(PDF/图片) | | 搜索引擎 | 提供全文检索能力 | #### 三、关键能力对比 $$ \begin{array}{|c|c|c|c|} \hline \text{特性} & \text{关系数据库} & \text{多模型NoSQL} & \text{混合架构} \\ \hline \text{模式灵活性} & \text{刚性} & \text{动态} & \text{可变} \\ \text{关联查询能力} & \text{强} & \text{中等} & \text{强} \\ \text{全文检索效率} & \text{需插件} & \text{原生支持} & \text{最优} \\ \text{事务一致性} & \text{ACID} & \text{BASE} & \text{最终一致} \\ \text{扩展成本} & \text{高} & \text{低} & \text{中} \\ \hline \end{array} $$ #### 四、典型场景解决方案 1. **工业质检系统**(参考引用[2]) - **结构化数据**:MySQL存设备参数(型号、阈值) - **非结构化数据**:MinIO存储缺陷图片,Elasticsearch索引视觉特征 - **关联分析**:Neo4j建立「设备-缺陷类型-工艺参数」关系网 2. **跨文档知识图谱** ```cypher // Neo4j+全文检索集成 CALL apoc.es.query('pdf-index', 'content:焊接缺陷') YIELD node MATCH (node)-[:CONTAINS_TERM]->(t:Term) RETURN t.name, COUNT(*) AS frequency ``` #### 五、选型建议 1. **优先选NoSQL当**: - 数据形态≥3种(文本+图像+时序) - 需实时关联非结构化数据(如根据CT扫描图检索病例文本) - 模式频繁变更(工业物联网传感器扩展) 2. **优先选关系型当**: - 强事务需求(金融交易系统) - 固定模式结构化数据(ERP核心) - 已有SQL技能栈且数据形态单一 > **创新方向**:向量数据库(如Milvus)实现跨模态语义检索,支持“以图搜文”、“以文查”等场景,其相似度计算可示为: > $$ \text{rank}(q,D) = \arg\max_{d \in D} \left( f_{\text{enc}}(q)^T f_{\text{enc}}(d) \right) $$ > 其中$f_{\text{enc}}$为跨模态编码器[^2]
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值