基础水文数据库表结构设计思路ppt课件
合集下载
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
典型暴雨洪水在摘录表中电站下游流量水位关系曲线频率曲线查算表存入关系线表水库库区陆面蒸发和水面蒸发存入区水量表水库库区渗漏资料存入区水量表水库水位容积水位面积关系曲线存入关系线表点用水资料存入站点水量表面用水资料存入区水量表出力历时曲线或出力保证率曲线存入关系线表装机发电量关系曲线存入关系线表水库防洪调节计算见上文的区域水量平衡计算与水量还原兴利库容调节水量与设计保证率关系存入关系线表调节库容保证率曲线存入关系线表水库调度图存入关系线表灌溉需水过程线存入关系线表以上示例应该能说明一个问题本标准不仅是一个表结构方案也是一个流域数字化方案的雏形配以相应的应用软件可用于大流域水文业务的数字化虽然表示方法单一功能尚不完整不能构成一个完整的数字流域系统但一个数字流域系统除了要有完整的基础水文数据外至少还应该存储完整的计算参数应该实现区站拓扑的数字化和方法组合的数字化本标准的数据库只差方法组合的数字化方案
五、表构造3.0的设计思绪猜测
1．根据年鉴表，忽略特例，用关系模型设计基表 2．表构造3.0ORACLE物理设计 表示日值的四种构造：31×12 12×31 1×366 366×1 结论：12×31更快 3．物理设计结论被逻辑的表构造广泛采用。即以物理设计反
过来指点逻辑设计。
第二章 存储内容
1.采用了一切添加数据的建议； 2.存储体定义完好，形状、参数、公式均有存 储体； 3.资料审查根据齐全。
二、函数依赖的判别准那 么
1．函数依赖是语义上的 如码决议名，码定那么名定，码同那么名同，虽有码 异名同情况，但那是随机的多对一，并非确定性的多对一， 在关系模型中不属多对一，仍属一对一，即数学上的单值， 而不是单调。恒等的数学上的列间显函数关系也属函数依 赖，如2X1+X2函数依赖于X1和X2。
三、0NF 一切同质数据成列
同质成列是运用关系实际的根本前提，是关系模型的一 条潜规那么。根据如下：
1．属性集概念指同质成列。 2．各范式中的一个关系方式指的是一切关系实例的集 合，其属性集当指一切同质数据。 3．函数依赖概念针对一切的关系实例，各范式中的属 性集概念当与之对应。
4．关系模型的完好性指的是一致性，也可以说是横向的 完好性，纵向的完好性当在根本假定中包含。
2．任何有用的例外必需参与列间的函数依赖判别 一码对两名的情况即使只出现一次，那么码不能决议名。 函数依赖是一切关系实例都要满足的约束条件，有一个实例不 满足也不属函数依赖，冗余也是如此。这要求数据库设计照顾 特例。水文上的函数依赖指任何时间任何地点都满足确实定性 的决议关系。某些情况下，错误的数据也要参与函数依赖判别。 表构造3.0设计似乎忽略了这一点。 3．函数依赖是对应数据之间的，不是插补后的等价数据 之间的。 数据库逻辑设计是离散的，水文业务运用却是延续的。不 插补绳套数据，关系线表的自变量值与因变量值一对一。插补 后的等价绳套数据却可以一对多或多对一。
5．集合运算是关系数据库的强项，属性集不完好能够导 致没有集合，而没有集合那么范式没有意义。
6．任何教科书上的举例都没有分割属性集。 7．现有RDBMS都不支持较多的列。 8．UNION合并得到的集合的运算才干受DBMS限制。
0NF要求进展表合并和列合并。 列合并要留意坚持原有的函数依赖，列的合并经常需求新增 一个决议要素列，如沙重百分数列合并产生上限粒径列，保证率 水位列合并产生保证率列，不同时段长的极值合并产生时段长列。 本规范实现的列合并如下： 1.同质数据防止一地一列。 2.同质数据防止一时一列。防止每年一列、每月一列、每旬 一列、每日一列、每时段一列。 3.各地采用的分级有所不同，分级量如沙重百分数、保证率 水位等合并为一列。
四、不作物理设计
逻辑设计的目的是消除异常，减少冗余，关系模型公用于逻辑设计。逻辑设计的条件和结论均 是稳定的。
物理设计的目的是按各用户的偏好提升性能，各用户的偏好有冲突时进展性能平衡。物理设计无 实际支持。
关系模型的逻辑设计可以直接当成物理设计。并不阐明其设计成果就是物理的表构造，性能不佳 并非关系模型之过。不可把性能和关系模型搅和在一同，不能用物理设计来指点逻辑设计，不要在 逻辑设计中掺杂物理设计。逻辑设计与RDBMS无关，不能拿RDBMS来衡量本规范。一些文章中关 于性能与构造关系的论述均是物理设计阶段的结论。
2．年鉴降水量摘录表中的跨日数据难以查询 起时辰 止时辰 降水量 1988-8-8 8:00 止时分空 空 1988-8-10起时分空 8:00 20.0 把空时间变成非空时间后入库，即作为两条记录入库，在查 询条件中输入时间，假设只查到后一条记录，那么查询结果显 然是错误的。发生这种错误的缘由是用两条记录表示一个不可 分的量。数据完好性包括存储数据完好性和查询结果的完好性， 任何查询结果序列都应是完好的，要保证部分查询结果的完好 性，不能对查询语句的编写者提要求，只能经过完善逻辑设计 处理。
面向对象的精华在于笼统，OO笼统要求的方式笼统， 指的是同质数据以同名变量表示，且只用一个类属性表示， 而字段标识也是变量。含义相近量纲一样为同质，水文上除 了时间地点等定位属性不同外其他属性均同的数据为同质数 据，假好像质数据要分为不同的类，如何设计出更高层次的 类？如何进展耐久化？耐久化要求表字段与类属性构造相近， 所以，对象关系数据库的根本要求就是，同质数据只能组织 成一列，同一字组只能组织成一行。这两条原那么可以方便 编程。同质数据合并可降低查询定位门槛，如洪水水文要素 摘录表和洪水水位摘录表合并，不用知道某一个站是水文站 还是水位站，就可以查询。
三、为 谁 设 计
关系模型针对的是一切的数据运用者和支配者，物理设计也针 对一切的数据运用者和支配者，但袒护关键运用。以全部数据为本 照顾特例是数据库正向工程的根本设计原那么。数据库逆向工程那 么未必如此。逻辑设计的对象自然是：
1．一切的维护管理人员 2．一切直接运用数据者 3．一切的基于数据库的软件开发人员 总之是一切和数据打交道的人，不是多数人，更不是个他人。 换句话说，是为了满足一切的需求。留意，一些运用软件催生的数 据库表构造不太合理，类似于输出表的构造，通常是由于他们只思 索了一种运用。
法步外计置算为和开站发间大、流区域内运、用区系际统组奠合定了根
3．更完备的计算支持
底计。算区。站拓扑可以可视化，能够导致高 级业务分析软件产生新的操控界面。
4．规范化(含数字化)程度更高
5．更有利于编程
二、技术背景
今天的世界已进入软件主导的计算机时代。表构造3.0是硬件主导时 代的产物。
1.数据构造化。xDB构造化魅力不减，XML构造化引领时髦。 2.ORDBMS渐成主流 3.数据、呈现与软件三者分别 4.面向对象的程序设计取代构造化程序设计，成为程序设计的主流 5．水文数据库逆向工程进展不顺利 未来将是数据主导的时代，只需把数据理顺，把业务逻辑归纳出来， 就能够完成了系统的开发。这意味着，更多的数据，更严密的数据构造， 更直接的更新(实时更新与实时呈现)，更间接的数据表示，更少的软件 (大部分程序变成了数据，剩下的部分集成度很高)。
为方便字符串的定位截取，注解符号全部变为1位字符。 本规范只是提出了一个根本类，该类的用途仅限于完善逻 辑设计和统计数据量，未思索承继或扩展，离一套完善的类属 体系还非常遥远，本规范的数据库依然只是一个关系数据库， 谈不上对象关系数据库，由于库内字段齐全，且各字段都方便 OO援用，表字段就是最根本的类属性，可以此为根底，采用从 表到类的映射，将一个基表映射为一个耐久化类，将表字段的 各种组合映射到各非耐久化类，设计出对象关系数据库。
4 水文调查 资料
5区站 拓扑
1 地表水整编
数
据
2 泥沙整编 成果
3 工程推流 数据
存储内容构成图
第三章 规范化
规范化的起点是水文运用中一切有用的关系方式。我们 从相关业务规范出发，规范中的每一个表都当成一个关系， 在业务规范的字里行间和图片中，我们还可以找到一些没有 成表的关系。这些成表或未成表的关系就是我们要规范的一 切对象，当然也包括征求意见得来的关系和表构造3.0中独 有的关系，以及高级业务计算所需求的一些关系。总之是编 写组人员想到看到听说的全部数据。旧规范特有的部分数据 能够被忽略。
实现表内维护和表间维护的技术通常是不同的，对于规 范化的基表和完善的系统而言，表间维护经常不需求用户参 与，表内维护那么需求用户参与，故表间冗余不会引发维护 异常，而表内冗余那么会引发维护异常，所以，规范化的重 点应在表内，应努力于消除表内冗余，但依然保管必要的表 间冗余，即允许冗余的列在另一个表中出现，而不允许在本 表中出现，这样可以降低查询门槛，支持快捷的查询。
4．月年平均泥沙颗粒级配表 <月年平均悬移质输沙率颗粒级配表>、<月年平均推移质颗粒 级配表>和床沙的有关表格。
5．月年泥沙特征粒径表 <月年平均悬移质输沙率颗粒级配表>、<月年平均推移质颗粒 级配表>和床沙的有关表格。
基础水文数据库表结构
设 计思路
主要内容：
一概述 二 存储内容 三 规范化 四 业务逻辑的表示 五 高级运用的概念性数据组织方案
第一章 概述
水利软件系统的开展趋势是外置数据的
一、本规范表构数越造量来和越的种少特类。越本点来规越范多外，置程了序更中多的的硬数编据码，
包括形状量、参数和方法，并为运用提
DBMS提供了性能优化工具。可作存储优化，查询优化，未来的DBMS能 够实现透明的预先衔接。这些都是不牺牲范式等级和构造提升性能的途径。
DBMS提供了数据分布工具，经过数据的合理分布，也能改善性能。 牺牲范式等级和构造提升性能是挖肉补疮或因陋就简的做法，本规范数 据库对性能的要求不高，逆规范化得不偿失。 不作物理设计自然也就不思索性能，2000问题就是节约两个字节呵斥的。 表构造3.0的ORACLE物理设计很充分，既节省存储空间，又提高查询速度， 没有运用时间换空间或空间换时间战略，其物理设计是很高明的，却得出了不 合理的逻辑设计结论。 所以，不用作物理设计，直接将本规范表构造当成物理的表构造即可。
1．洪水水文要素摘录表 <洪水水位摘录表> 、 <洪水水文要素摘录表>和<洪水含沙 量摘录表>。
2．日旬月年输沙率表 <逐日平均悬移质输沙率表> 、 <悬移质输沙率月年统计表>、 <逐日平均推移质输沙率表>，年表另加<实测推移质成果表>的表 头部分。
3．旬月年流量表 <逐日平均流量表>和<流量月年统计表>
物理设计是针对特定的DBMS的。普通情况下，表中行多那么查询慢，表中行少那么查询快。也 可以做一个RDBMS，把用在行上的技术与用在列上的技术对调，用之那么会得出相反的结论。
物理的表构造有一定程度的恣意性，不宜作为行业规范。表构造3.0的 12×31阵可以了解为一种物理构造，它没有思索到，矩阵的转置查询既不方 便，而且速度很慢。
本规范中，部分旬表是冗余表，时段极值列多为表间冗 余列。
一、面向对象初步
关系模型处理维护异常，而查询异常和记录难以定位的 问题无法用关系模型处理。我们发现了两种查询异常：
1．年鉴日降水量表中的合并量不加转换直接入库后查询 异常
合并量无注解码，部分查询查出的结果能够是错误的。 数据准确性包括存储数据准确性和查询结果的准确性，不仅 要保证整体查询准确性，也要保证部分查询的准确性。发生 这种景象的缘由是该降水量的注解码与其他记录有关，即用 多条记录表示一个值。
我们把12×31的构造极端化，变成1×5000000，每一 个数值一个字段，或变成5000000个表，〔其荒唐不在于列 多，逻辑设计并不限制列数，虽然物理设计限制它〕，查询 时如何准确地定位数据呢？无法定位比查询异常更糟糕。怎 样利用关系数据库的集合运算才干？要在查询时准确地定位 数据，12×31的构造曾经很难，何况1×5000000。
4.分钟、小时、日<时段最大降水量表>和<时段最大洪量 表>各种时段长的极值合并为一列。
5.<时段最大降水量表>和<时段最大洪量表>各种时段长的 极值合并为一列。
6.<实测潮流量成果表>中潮流速代表垂线有多条，合并各 代表垂线流速为一列。
表合并要留意坚持原有的函数依赖，表的合并经常需求新增 一个表示类型的决议要素列，如泥沙类型字段是沙表合并的产物。 本规范实现的表合并如下：
这两个例子阐明，记录的牵连导致查询异常，在水文 数据中存在一种不可分为多条记录的组合。这种组合我们称 为字组，字组是最底层的自描画通用类，也是一个统计单位。 为理处理查询异常问题，本规范按字组不可分的原那么做了 一些规定。封装要求不存在额外的关系，字组不可分实践上 就是对象封装和信息隐藏的详细化。字组完好性使得对象容 易组织和处置。
与表构造3.0相比，具有以供下完善特的点数：据构造支持，善加利用可减
1．存储内容更丰富
少程序中的硬编码。本规范消除了各种 维几护乎异支常持，一便切于的实推时流数计据算更，新添与加实时整
ቤተ መጻሕፍቲ ባይዱ
编了。一本些规更范切也合处业理务了逻查辑询、异更常贴和近数据难
2．数据的构造化程度更高 以实定践位业问务题流。程区的站数拓据扑，外以置支和持初多步的方
五、表构造3.0的设计思绪猜测
1．根据年鉴表，忽略特例，用关系模型设计基表 2．表构造3.0ORACLE物理设计 表示日值的四种构造：31×12 12×31 1×366 366×1 结论：12×31更快 3．物理设计结论被逻辑的表构造广泛采用。即以物理设计反
过来指点逻辑设计。
第二章 存储内容
1.采用了一切添加数据的建议； 2.存储体定义完好，形状、参数、公式均有存 储体； 3.资料审查根据齐全。
二、函数依赖的判别准那 么
1．函数依赖是语义上的 如码决议名，码定那么名定，码同那么名同，虽有码 异名同情况，但那是随机的多对一，并非确定性的多对一， 在关系模型中不属多对一，仍属一对一，即数学上的单值， 而不是单调。恒等的数学上的列间显函数关系也属函数依 赖，如2X1+X2函数依赖于X1和X2。
三、0NF 一切同质数据成列
同质成列是运用关系实际的根本前提，是关系模型的一 条潜规那么。根据如下：
1．属性集概念指同质成列。 2．各范式中的一个关系方式指的是一切关系实例的集 合，其属性集当指一切同质数据。 3．函数依赖概念针对一切的关系实例，各范式中的属 性集概念当与之对应。
4．关系模型的完好性指的是一致性，也可以说是横向的 完好性，纵向的完好性当在根本假定中包含。
2．任何有用的例外必需参与列间的函数依赖判别 一码对两名的情况即使只出现一次，那么码不能决议名。 函数依赖是一切关系实例都要满足的约束条件，有一个实例不 满足也不属函数依赖，冗余也是如此。这要求数据库设计照顾 特例。水文上的函数依赖指任何时间任何地点都满足确实定性 的决议关系。某些情况下，错误的数据也要参与函数依赖判别。 表构造3.0设计似乎忽略了这一点。 3．函数依赖是对应数据之间的，不是插补后的等价数据 之间的。 数据库逻辑设计是离散的，水文业务运用却是延续的。不 插补绳套数据，关系线表的自变量值与因变量值一对一。插补 后的等价绳套数据却可以一对多或多对一。
5．集合运算是关系数据库的强项，属性集不完好能够导 致没有集合，而没有集合那么范式没有意义。
6．任何教科书上的举例都没有分割属性集。 7．现有RDBMS都不支持较多的列。 8．UNION合并得到的集合的运算才干受DBMS限制。
0NF要求进展表合并和列合并。 列合并要留意坚持原有的函数依赖，列的合并经常需求新增 一个决议要素列，如沙重百分数列合并产生上限粒径列，保证率 水位列合并产生保证率列，不同时段长的极值合并产生时段长列。 本规范实现的列合并如下： 1.同质数据防止一地一列。 2.同质数据防止一时一列。防止每年一列、每月一列、每旬 一列、每日一列、每时段一列。 3.各地采用的分级有所不同，分级量如沙重百分数、保证率 水位等合并为一列。
四、不作物理设计
逻辑设计的目的是消除异常，减少冗余，关系模型公用于逻辑设计。逻辑设计的条件和结论均 是稳定的。
物理设计的目的是按各用户的偏好提升性能，各用户的偏好有冲突时进展性能平衡。物理设计无 实际支持。
关系模型的逻辑设计可以直接当成物理设计。并不阐明其设计成果就是物理的表构造，性能不佳 并非关系模型之过。不可把性能和关系模型搅和在一同，不能用物理设计来指点逻辑设计，不要在 逻辑设计中掺杂物理设计。逻辑设计与RDBMS无关，不能拿RDBMS来衡量本规范。一些文章中关 于性能与构造关系的论述均是物理设计阶段的结论。
2．年鉴降水量摘录表中的跨日数据难以查询 起时辰 止时辰 降水量 1988-8-8 8:00 止时分空 空 1988-8-10起时分空 8:00 20.0 把空时间变成非空时间后入库，即作为两条记录入库，在查 询条件中输入时间，假设只查到后一条记录，那么查询结果显 然是错误的。发生这种错误的缘由是用两条记录表示一个不可 分的量。数据完好性包括存储数据完好性和查询结果的完好性， 任何查询结果序列都应是完好的，要保证部分查询结果的完好 性，不能对查询语句的编写者提要求，只能经过完善逻辑设计 处理。
面向对象的精华在于笼统，OO笼统要求的方式笼统， 指的是同质数据以同名变量表示，且只用一个类属性表示， 而字段标识也是变量。含义相近量纲一样为同质，水文上除 了时间地点等定位属性不同外其他属性均同的数据为同质数 据，假好像质数据要分为不同的类，如何设计出更高层次的 类？如何进展耐久化？耐久化要求表字段与类属性构造相近， 所以，对象关系数据库的根本要求就是，同质数据只能组织 成一列，同一字组只能组织成一行。这两条原那么可以方便 编程。同质数据合并可降低查询定位门槛，如洪水水文要素 摘录表和洪水水位摘录表合并，不用知道某一个站是水文站 还是水位站，就可以查询。
三、为 谁 设 计
关系模型针对的是一切的数据运用者和支配者，物理设计也针 对一切的数据运用者和支配者，但袒护关键运用。以全部数据为本 照顾特例是数据库正向工程的根本设计原那么。数据库逆向工程那 么未必如此。逻辑设计的对象自然是：
1．一切的维护管理人员 2．一切直接运用数据者 3．一切的基于数据库的软件开发人员 总之是一切和数据打交道的人，不是多数人，更不是个他人。 换句话说，是为了满足一切的需求。留意，一些运用软件催生的数 据库表构造不太合理，类似于输出表的构造，通常是由于他们只思 索了一种运用。
法步外计置算为和开站发间大、流区域内运、用区系际统组奠合定了根
3．更完备的计算支持
底计。算区。站拓扑可以可视化，能够导致高 级业务分析软件产生新的操控界面。
4．规范化(含数字化)程度更高
5．更有利于编程
二、技术背景
今天的世界已进入软件主导的计算机时代。表构造3.0是硬件主导时 代的产物。
1.数据构造化。xDB构造化魅力不减，XML构造化引领时髦。 2.ORDBMS渐成主流 3.数据、呈现与软件三者分别 4.面向对象的程序设计取代构造化程序设计，成为程序设计的主流 5．水文数据库逆向工程进展不顺利 未来将是数据主导的时代，只需把数据理顺，把业务逻辑归纳出来， 就能够完成了系统的开发。这意味着，更多的数据，更严密的数据构造， 更直接的更新(实时更新与实时呈现)，更间接的数据表示，更少的软件 (大部分程序变成了数据，剩下的部分集成度很高)。
为方便字符串的定位截取，注解符号全部变为1位字符。 本规范只是提出了一个根本类，该类的用途仅限于完善逻 辑设计和统计数据量，未思索承继或扩展，离一套完善的类属 体系还非常遥远，本规范的数据库依然只是一个关系数据库， 谈不上对象关系数据库，由于库内字段齐全，且各字段都方便 OO援用，表字段就是最根本的类属性，可以此为根底，采用从 表到类的映射，将一个基表映射为一个耐久化类，将表字段的 各种组合映射到各非耐久化类，设计出对象关系数据库。
4 水文调查 资料
5区站 拓扑
1 地表水整编
数
据
2 泥沙整编 成果
3 工程推流 数据
存储内容构成图
第三章 规范化
规范化的起点是水文运用中一切有用的关系方式。我们 从相关业务规范出发，规范中的每一个表都当成一个关系， 在业务规范的字里行间和图片中，我们还可以找到一些没有 成表的关系。这些成表或未成表的关系就是我们要规范的一 切对象，当然也包括征求意见得来的关系和表构造3.0中独 有的关系，以及高级业务计算所需求的一些关系。总之是编 写组人员想到看到听说的全部数据。旧规范特有的部分数据 能够被忽略。
实现表内维护和表间维护的技术通常是不同的，对于规 范化的基表和完善的系统而言，表间维护经常不需求用户参 与，表内维护那么需求用户参与，故表间冗余不会引发维护 异常，而表内冗余那么会引发维护异常，所以，规范化的重 点应在表内，应努力于消除表内冗余，但依然保管必要的表 间冗余，即允许冗余的列在另一个表中出现，而不允许在本 表中出现，这样可以降低查询门槛，支持快捷的查询。
4．月年平均泥沙颗粒级配表 <月年平均悬移质输沙率颗粒级配表>、<月年平均推移质颗粒 级配表>和床沙的有关表格。
5．月年泥沙特征粒径表 <月年平均悬移质输沙率颗粒级配表>、<月年平均推移质颗粒 级配表>和床沙的有关表格。
基础水文数据库表结构
设 计思路
主要内容：
一概述 二 存储内容 三 规范化 四 业务逻辑的表示 五 高级运用的概念性数据组织方案
第一章 概述
水利软件系统的开展趋势是外置数据的
一、本规范表构数越造量来和越的种少特类。越本点来规越范多外，置程了序更中多的的硬数编据码，
包括形状量、参数和方法，并为运用提
DBMS提供了性能优化工具。可作存储优化，查询优化，未来的DBMS能 够实现透明的预先衔接。这些都是不牺牲范式等级和构造提升性能的途径。
DBMS提供了数据分布工具，经过数据的合理分布，也能改善性能。 牺牲范式等级和构造提升性能是挖肉补疮或因陋就简的做法，本规范数 据库对性能的要求不高，逆规范化得不偿失。 不作物理设计自然也就不思索性能，2000问题就是节约两个字节呵斥的。 表构造3.0的ORACLE物理设计很充分，既节省存储空间，又提高查询速度， 没有运用时间换空间或空间换时间战略，其物理设计是很高明的，却得出了不 合理的逻辑设计结论。 所以，不用作物理设计，直接将本规范表构造当成物理的表构造即可。
1．洪水水文要素摘录表 <洪水水位摘录表> 、 <洪水水文要素摘录表>和<洪水含沙 量摘录表>。
2．日旬月年输沙率表 <逐日平均悬移质输沙率表> 、 <悬移质输沙率月年统计表>、 <逐日平均推移质输沙率表>，年表另加<实测推移质成果表>的表 头部分。
3．旬月年流量表 <逐日平均流量表>和<流量月年统计表>
物理设计是针对特定的DBMS的。普通情况下，表中行多那么查询慢，表中行少那么查询快。也 可以做一个RDBMS，把用在行上的技术与用在列上的技术对调，用之那么会得出相反的结论。
物理的表构造有一定程度的恣意性，不宜作为行业规范。表构造3.0的 12×31阵可以了解为一种物理构造，它没有思索到，矩阵的转置查询既不方 便，而且速度很慢。
本规范中，部分旬表是冗余表，时段极值列多为表间冗 余列。
一、面向对象初步
关系模型处理维护异常，而查询异常和记录难以定位的 问题无法用关系模型处理。我们发现了两种查询异常：
1．年鉴日降水量表中的合并量不加转换直接入库后查询 异常
合并量无注解码，部分查询查出的结果能够是错误的。 数据准确性包括存储数据准确性和查询结果的准确性，不仅 要保证整体查询准确性，也要保证部分查询的准确性。发生 这种景象的缘由是该降水量的注解码与其他记录有关，即用 多条记录表示一个值。
我们把12×31的构造极端化，变成1×5000000，每一 个数值一个字段，或变成5000000个表，〔其荒唐不在于列 多，逻辑设计并不限制列数，虽然物理设计限制它〕，查询 时如何准确地定位数据呢？无法定位比查询异常更糟糕。怎 样利用关系数据库的集合运算才干？要在查询时准确地定位 数据，12×31的构造曾经很难，何况1×5000000。
4.分钟、小时、日<时段最大降水量表>和<时段最大洪量 表>各种时段长的极值合并为一列。
5.<时段最大降水量表>和<时段最大洪量表>各种时段长的 极值合并为一列。
6.<实测潮流量成果表>中潮流速代表垂线有多条，合并各 代表垂线流速为一列。
表合并要留意坚持原有的函数依赖，表的合并经常需求新增 一个表示类型的决议要素列，如泥沙类型字段是沙表合并的产物。 本规范实现的表合并如下：
这两个例子阐明，记录的牵连导致查询异常，在水文 数据中存在一种不可分为多条记录的组合。这种组合我们称 为字组，字组是最底层的自描画通用类，也是一个统计单位。 为理处理查询异常问题，本规范按字组不可分的原那么做了 一些规定。封装要求不存在额外的关系，字组不可分实践上 就是对象封装和信息隐藏的详细化。字组完好性使得对象容 易组织和处置。
与表构造3.0相比，具有以供下完善特的点数：据构造支持，善加利用可减
1．存储内容更丰富
少程序中的硬编码。本规范消除了各种 维几护乎异支常持，一便切于的实推时流数计据算更，新添与加实时整
ቤተ መጻሕፍቲ ባይዱ
编了。一本些规更范切也合处业理务了逻查辑询、异更常贴和近数据难
2．数据的构造化程度更高 以实定践位业问务题流。程区的站数拓据扑，外以置支和持初多步的方