基础水文数据库表结构设计思路

null基 础 水 文 数 据 库 表 结 构基 础 水 文 数 据 库 表 结 构设 计 思 路 二○○六年七月彭开泉13317122837 pengkaiquan@tom.com主要内容： 主要内容： 二 存储内容 三 规范化 一 概 述四 业务逻辑的表示 五 高级应用的概念性数据组织 方案 气瓶 现场处置方案 .pdf气瓶 现场处置方案 .doc见习基地管理方案.doc关于群访事件的化解方案建筑工地扬尘治理专项方案下载 第一章 概述 第一章 概述 一、本标准表结构的特点2．数据的结构化程度更高 5．更有利于编程4．规范化(含数字化)程度更高3．更完备的计算支持 与表结构3.0相比，具有以下特点： 1．存储内容更丰富几乎支持所有的推流计算，增加了一些更切合业务逻辑、更贴近实际业务流程的数据，以支持多步计算和站间、区内、区际组合计算。 水利软件系统的发展趋势是外置数据的数量和种类越来越多，程序中的硬编码越来越少。本标准外置了更多的数据，包括状态量、参数和方法，并为应用提供完善的数据结构支持，善加利用可减少程序中的硬编码。本标准消除了各种维护异常，便于实时数据更新与实时整编。本标准也解决了查询异常和数据难以定位问题。区站拓扑外置和初步的方法外置为开发大流域应用系统奠定了基础。区站拓扑可以可视化，可能导致高级业务分析软件产生新的操控界面。 null 二、技术背景 今天的世界已进入软件主导的计算机时代。表结构3.0是硬件主导时代的产物。 1.数据结构化。xDB结构化魅力不减，XML结构化引领时尚。 2.ORDBMS渐成主流 3.数据、呈现与软件三者分离 4.面向对象的程序 设计 领导形象设计圆作业设计ao工艺污水处理厂设计附属工程施工组织设计清扫机器人结构设计 取代结构化程序设计，成为程序设计的主流 5．水文数据库逆向工程进展不顺利 未来将是数据主导的时代，只要把数据理顺，把业务逻辑归纳出来，就可能完成了系统的开发。这意味着，更多的数据，更紧密的数据结构，更直接的更新(实时更新与实时呈现)，更间接的数据表示，更少的软件(大部分程序变成了数据，剩下的部分集成度很高)。 null 三、为 谁 设 计 关系模型针对的是所有的数据使用者和操纵者，物理设计也针对所有的数据使用者和操纵者，但袒护关键应用。以全部数据为本照顾特例是数据库正向工程的基本设计原则。数据库逆向工程则未必如此。逻辑设计的对象自然是： 1．所有的维护管理人员 2．所有直接使用数据者 3．所有的基于数据库的软件开发人员 总之是所有和数据打交道的人，不是多数人，更不是个别人。换句话说，是为了满足所有的需求。注意，一些应用软件催生的数据库表结构不太合理，类似于输出表的结构，通常是因为他们只考虑了一种应用。null 四、不作物理设计 逻辑设计的目的是消除异常，减少冗余，关系模型专用于逻辑设计。逻辑设计的条件和结论均是稳定的。 物理设计的目的是按各用户的偏好提升性能，各用户的偏好有冲突时进行性能平衡。物理设计无理论支持。 关系模型的逻辑设计可以直接当成物理设计。并不表明其设计成果就是物理的表结构，性能不佳并非关系模型之过。不可把性能和关系模型搅和在一起，不能用物理设计来指导逻辑设计，不要在逻辑设计中掺杂物理设计。逻辑设计与RDBMS无关，不能拿RDBMS来衡量本标准。一些文章中关于性能与结构关系的论述均是物理设计阶段的结论。 物理设计是针对特定的DBMS的。一般情况下，表中行多则查询慢，表中行少则查询快。也可以做一个RDBMS，把用在行上的技术与用在列上的技术对调，用之则会得出相反的结论。 null 物理的表结构有一定程度的任意性，不宜作为行业标准。表结构3.0的12×31阵可以理解为一种物理结构，它没有考虑到，矩阵的转置查询既不方便，而且速度很慢。 DBMS提供了性能优化工具。可作存储优化，查询优化，未来的DBMS可能实现透明的预先连接。这些都是不牺牲范式等级和结构提升性能的途径。 DBMS提供了数据分布工具，通过数据的合理分布，也能改善性能。 牺牲范式等级和结构提升性能是挖肉补疮或因陋就简的做法，本标准数据库对性能的要求不高，逆规范化得不偿失。 不作物理设计自然也就不考虑性能，2000问题就是节约两个字节造成的。表结构3.0的ORACLE物理设计很充分，既节省存储空间，又提高查询速度，没有使用时间换空间或空间换时间策略，其物理设计是很高明的，却得出了不合理的逻辑设计结论。 所以，不必作物理设计，直接将本标准表结构当成物理的表结构即可。null 五、表结构3.0的设计思路猜测 1．根据年鉴表，忽略特例，用关系模型设计基表 2．表结构3.0ORACLE物理设计 表示日值的四种结构：31×12 12×31 1×366 366×1 结论：12×31更快 3．物理设计结论被逻辑的表结构广泛采用。即以物理设计反过来指导逻辑设计。第二章 存储内容 第二章 存储内容 1.采纳了所有增加数据的建议； 2.存储体定义完整，状态、参数、公式均有存储体； 3.资料审查依据齐全。 null存储内容构成图第三章 规范化第三章 规范化 规范化的起点是水文应用中所有有用的关系模式。我们从相关业务规范出发，规范中的每一个表都当成一个关系，在业务规范的字里行间和图片中，我们还可以找到一些没有成表的关系。这些成表或未成表的关系就是我们要规范的所有对象，当然也包括征求意见得来的关系和表结构3.0中独有的关系，以及高级业务计算所需要的一些关系。总之是编写组人员想到看到听说的全部数据。旧规范特有的部分数据可能被忽略。 null 实现表内维护和表间维护的技术通常是不同的，对于规范化的基表和完善的系统而言，表间维护常常不需要用户参与，表内维护则需要用户参与，故表间冗余不会引发维护异常，而表内冗余则会引发维护异常，所以，规范化的重点应在表内，应致力于消除表内冗余，但仍然保留必要的表间冗余，即允许冗余的列在另一个表中出现，而不允许在本表中出现，这样可以降低查询门槛，支持快捷的查询。 本标准中，部分旬表是冗余表，时段极值列多为表间冗余列。null 关系模型解决维护异常，而查询异常和记录难以定位的问题无法用关系模型解决。我们发现了两种查询异常： 1．年鉴日降水量表中的合并量不加转换直接入库后查询异常 合并量无注解码，局部查询查出的结果可能是错误的。数据准确性包括存储数据准确性和查询结果的准确性，不仅要保证整体查询准确性，也要保证局部查询的准确性。发生这种现象的原因是该降水量的注解码与其他记录有关，即用多条记录表示一个值。 一、面向对象初步null 2．年鉴降水量摘录表中的跨日数据难以查询 起时刻 止时刻 降水量 1988-8-8 8:00 止时分空 空 1988-8-10起时分空 8:00 20.0 把空时间变成非空时间后入库，即作为两条记录入库，在查询条件中输入时间，如果只查到后一条记录，则查询结果显然是错误的。发生这种错误的原因是用两条记录表示一个不可分的量。数据完整性包括存储数据完整性和查询结果的完整性，任何查询结果序列都应是完整的，要保证局部查询结果的完整性，不能对查询语句的编写者提要求，只能通过完善逻辑设计解决。 null 这两个例子表明，记录的牵连导致查询异常，在水文数据中存在一种不可分为多条记录的组合。这种组合我们称为字组，字组是最底层的自描述通用类，也是一个统计单位。为了解决查询异常问题，本标准按字组不可分的原则做了一些规定。封装要求不存在额外的关系，字组不可分实际上就是对象封装和信息隐藏的具体化。字组完整性使得对象容易组织和处理。null 我们把12×31的结构极端化，变成1×5000000，每一个数值一个字段，或变成5000000个表，（其荒唐不在于列多，逻辑设计并不限制列数，虽然物理设计限制它），查询时如何精确地定位数据呢？无法定位比查询异常更糟糕。怎样利用关系数据库的集合运算能力？要在查询时精确地定位数据，12×31的结构已经很难，何况1×5000000。null 面向对象的精髓在于抽象，OO抽象要求的形式抽象，指的是同质数据以同名变量表示，且只用一个类属性表示，而字段标识也是变量。含义相近量纲相同为同质，水文上除了时间地点等定位属性不同外其他属性均同的数据为同质数据，如果同质数据要分为不同的类，如何设计出更高层次的类？如何进行持久化？持久化要求表字段与类属性结构相近，所以，对象关系数据库的基本要求就是，同质数据只能组织成一列，同一字组只能组织成一行。这两条原则可以方便编程。同质数据合并可降低查询定位门槛，如洪水水文要素摘录表和洪水水位摘录表合并，不必知道某一个站是水文站还是水位站，就可以查询。null 为方便字符串的定位截取，注解符号全部变为1位字符。 本标准只是提出了一个基本类，该类的用途仅限于完善逻辑设计和统计数据量，未考虑继承或扩展，离一套完善的类属体系还非常遥远，本标准的数据库仍然只是一个关系数据库，谈不上对象关系数据库，由于库内字段齐全，且各字段都方便OO引用，表字段就是最基本的类属性，可以此为基础，采用从表到类的映射，将一个基表映射为一个持久化类，将表字段的各种组合映射到各非持久化类，设计出对象关系数据库。null 1．函数依赖是语义上的 如码决定名，码定则名定，码同则名同，虽有码异名同情况，但那是随机的多对一，并非确定性的多对一，在关系模型中不属多对一，仍属一对一，即数学上的单值，而不是单调。恒等的数学上的列间显函数关系也属函数依赖，如2X1+X2函数依赖于X1和X2。 二、函数依赖的判别准则null 2．任何有用的例外必须参与列间的函数依赖判断 一码对两名的情况即使只出现一次，则码不能决定名。函数依赖是所有关系实例都要满足的约束条件，有一个实例不满足也不属函数依赖，冗余也是如此。这要求数据库设计照顾特例。水文上的函数依赖指任何时间任何地点都满足的确定性的决定关系。某些情况下，错误的数据也要参与函数依赖判断。 表结构3.0设计似乎忽略了这一点。 3．函数依赖是对应数据之间的，不是插补后的等价数据之间的。 数据库逻辑设计是离散的，水文业务应用却是连续的。不插补绳套数据，关系线表的自变量值与因变量值一对一。插补后的等价绳套数据却可以一对多或多对一。null 同质成列是运用关系理论的基本前提，是关系模型的一条潜规则。依据如下： 1．属性集概念指同质成列。 2．各范式中的一个关系模式指的是所有关系实例的集合，其属性集当指所有同质数据。 3．函数依赖概念针对所有的关系实例，各范式中的属性集概念当与之对应。 三、0NF 所有同质数据成列null 4．关系模型的完整性指的是一致性，也可以说是横向的完整性，纵向的完整性当在基本假定中包含。 5．集合运算是关系数据库的强项，属性集不完整可能导致没有集合，而没有集合则范式没有意义。 6．任何教科 书 关于书的成语关于读书的排比句社区图书漂流公约怎么写关于读书的小报汉书pdf 上的举例都没有分割属性集。 7．现有RDBMS都不支持较多的列。 8．UNION合并得到的集合的运算能力受DBMS限制。null 0NF要求进行表合并和列合并。 列合并要注意保持原有的函数依赖，列的合并常常需要新增一个决定因素列，如沙重百分数列合并产生上限粒径列，保证率水位列合并产生保证率列，不同时段长的极值合并产生时段长列。本标准实现的列合并如下： 1.同质数据避免一地一列。 2.同质数据避免一时一列。避免每年一列、每月一列、每旬一列、每日一列、每时段一列。 3.各地采用的分级有所不同，分级量如沙重百分数、保证率水位等合并为一列。 null 4.分钟、小时、日《时段最大降水量表》和《时段最大洪量表》各种时段长的极值合并为一列。 5.《时段最大降水量表》和《时段最大洪量表》各种时段长的极值合并为一列。 6.《实测潮流量成果表》中潮流速代表垂线有多条，合并各代表垂线流速为一列。null 表合并要注意保持原有的函数依赖，表的合并常常需要新增一个表示类型的决定因素列，如泥沙类型字段是沙表合并的产物。本标准实现的表合并如下： 1．洪水水文要素摘录表 《洪水水位摘录表》 、 《洪水水文要素摘录表》和《洪水含沙量摘录表》。 2．日旬月年输沙率表 《逐日平均悬移质输沙率表》 、 《悬移质输沙率月年统计表》、《逐日平均推移质输沙率表》，年表另加《实测推移质成果表》的表头部分。 3．旬月年流量表 《逐日平均流量表》和《流量月年统计表》 null 4．月年平均泥沙颗粒级配表 《月年平均悬移质输沙率颗粒级配表》、《月年平均推移质颗粒级配表》和床沙的有关表格。 5．月年泥沙特征粒径表 《月年平均悬移质输沙率颗粒级配表》、《月年平均推移质颗粒级配表》和床沙的有关表格。 6．实测输沙率成果表 《实测悬移质输沙率成果表》、《实测推移质输沙率成果表》、《实测推移质成果表》。null 7．实测泥沙颗粒级配表 《实测悬移质断面平均与相应单位水样颗粒级配成果表》、《实测悬移质断面平均颗粒级配成果表》、《实测悬移质单样颗粒级配成果表》、《实测推移质成果表》、《床沙断面颗粒级配实测成果表》和《床沙垂线颗粒级配实测成果表》。 8．实测泥沙特征粒径表 《实测悬移质断面平均与相应单位水样颗粒级配成果表》、《实测悬移质断面平均颗粒级配成果表》、《实测悬移质单样颗粒级配成果表》《实测推移质成果表》、《床沙断面颗粒级配实测成果表》和《床沙垂线颗粒级配实测成果表》null 9．堰闸逐年特性表 《堰闸流量率定成果表》和《堰闸实测潮量成果统计表》的表头部分 10. 旬月年水温表 《逐日水温表》和《水温月年统计表》 11．年冰情表 《冰情统计表》和《冰情及冰厚要素摘录表》 12．水文水位站沿革表 《水文水位站沿革表》、《水文水位站断面及设施说明表》和《水文水位站基本水尺水位观测设备沿革表》 13．《站点水量表》和《区水量表》 整编规范中的各实测调查水量表与水文调查规范中的各种实测调查水量同质合并。null 值不必再分指的是不继续分什么都容易做，值无二义也包括组成值的元素如注解符号无二义。1NF的目的是非结构化数据的数字化，在水文应用领域，主要包括属性数据数字化，方法数据数字化，空间拓扑数字化。下面几条是对不必再分的理解。 1．站码不再分仍然可以做各种维护和查询计算。 四、1NF 值不必再分，值无二义null 2．时间分与不分都便于计算，分不分都满足1范式，时间分开是为了区分空值。 3．文字按属性再分，只含一种属性时再分无意义。 4．注解码再分并不是近几年的需求，权宜之计是不再分。 5．附注本可按时间再分，在注解码中也已准确表示，实现难度较大而收效不大。null具体措施： 1．数字与字串分离，主要是数字与注解码分离为两个字段。 2．要参与计算的数据以数值型存储。 3．统一计量单位，使数字与计量单位分离。 4．年鉴表头中的名值对数据分离。 5．从图片中提取数据单独存储，B型数据允许冗余存储。 6．从文章中提取数据。null 7．规定特殊数据的取值，做到一义一码，一码一义，以避免不同的人有不同的理解和处理。 8．注解符号一符号一义，以确保注解码无二义。 9．两个大断面表陡坎处的垂线号加后缀“A”或“B”区分垂线顺序。 10．《实测流量成果表》的水浸冰与水分开，另加三个字段。 11．对“其他”的规定很灵活，可以直接列出，避免因提供的枚举不足而产生二义值。 null 避免主键所有列到从列多值对同一值。即从列中的值不重复。 1．摘录日旬月年值分表存储。报表按站码时间分解，以保持函数依赖，减少异常。由此得到十大表类中的5类。其余表也根据主键和用途用法的不同进行分类。 2．年鉴表头各数据入年表类或基本信息表类，水闸数据入《水闸特性表》，泵站数据入《水电站泵站特性表》，这些表头数据不可入日旬月表类，作为主列的蒸发器型式除外。 五、2NF 消除从列对主键的部分函数依赖null 3．如果不统一计量单位，计量单位入《计量单位采用情况表》，日旬月表类不设计量单位字段。 4．平均颗粒级配与泥沙特征粒径分表。 5．从《实测潮流量成果表》中分出《实测代表垂线潮流速表》。 6．关系线分为两个表，一表存线，另一表存点。null 从列对从列不整列冗余。 1．去掉潮表中的农历，增设《公农历日期对照表》。 2．关系线表中存储绳套，消除了自变量值与因变量值之间的函数依赖。 3．率定表类中一些值之间,虽存在水文学意义上的计算关系,如水位差=闸上水位-闸下水位,实测流量=断面过水面积*断面平均流速,但这些数据要用于核查,可能存在错误,这些错误对资料审查是有用处的,且整编规范规定,率定需要时才填,意味着上述等式中的三个量可以不全部填,所以,上述两个等式都不是恒等式,各字段之间不存在函数依赖。 六、3NF 消除从列间的函数依赖null 4．含有公式编号字段的率定表，从列之间一般会有一个完整的列间计算关系，表示运用某公式采用某参数根据某输入得到某输出，此种计算关系是要接受审查的计算关系，未来要进一步接受审查的关系都没有函数依赖，因为其中的数据错误是有用的。 5．实测调查类表存储的也是要进一步接受审查的点据，其中的一些列间水文学计算关系也不属函数依赖。 6．其他表类已通过数据审查，而且不会有进一步的计算关系审查，其中的数据错误再无利用价值，列间的函数依赖关系判断不应考虑有错误数据存在的情况。null 主列对主列不整列冗余。 主列通常是区，站，垂线号，时间，测次等。 时间与空间之间无函数依赖。 地理从属关系之间有函数依赖，区依赖于站，两者不可作为同一个表的主键。 垂线号是在站内的编号，与站之间无函数依赖关系。 测次是年内编号，与时间之间无函数依赖关系。七、BCNF 消除主列间的函数依赖null 两对列间一对多可能会导致一对列间多对多，形成多值依赖，必须分表，以消除列间非函数依赖的多值对多值，在按0NF合并后的年鉴表中位于不同块的数据原则上都可以分解。按0NF合并后的年鉴表如无多对多，则尽可能不分解，如有多对多，则保留原主键分表。八、4NF 消除列间多对多null 1．按主要测验整编项目分表。 2．按工程特性分表。无工程控制与有工程控制分开，水闸与泵站分开。 3．整体工程与分部工程分表。水库与溢洪道分开，水库与水闸水洞分开。 4．不同种类的分部工程分表。溢洪道与输水洞分开。null 在4NF水平及更低水平，分表时尽可能保持年鉴和其他规范上原有的一对一关系，经多年多方使用的年鉴已将绝大多数有关系的数据列入同一个表并对应起来，关系分解自然是无损的，且能保持主列到从列的函数依赖。 到4NF之后，对基表作有意义的再分解已经很难，我们只能考虑基表之间的连接是否有信息损失。九、5NF保持表间无损连接性null 对于日旬月年表的跨表类同项目连接，除了日降水量表规定不存储0降水可能导致因连接而丢失信息外，其余各种主键连接都不可能有信息损失。实际查询中，连接日降水量表可采用左右连接避免信息损失。 摘录表类和实测调查表类的时间对应性不好，离散序列null连接没有意义，而连续序列的插值连接又不被支持，不必考虑消除基表间的连接依赖问题。 其余的表均按一个表一类实体组织，这些非同类实体之间一般没有连接要求。 因站码唯一且非空，站码表与各时间序列表的连接是无损的。第四章 业务逻辑的表示第四章 业务逻辑的表示 1．表结构3.0的测站 指的是行政站的一个物理断面或一类与断面无关的测验项目，该物理断面不带任何与断面无关的测验项目，与断面无关的测验项目另外编码，其实就是把一个行政站的每一个测验项目当成一个测站。 简言之，一台固定测验设备的一个安装地点（无明显的位置改变）一个站。 一、测站和站点概念null 2．现行测站编码办法的测站 指的是行政站的一个逻辑断面及其与断面无关的测验项目，无断面时指的是一个行政站，断面迁移前后的断面序列是一个逻辑断面，用同一个站码标识。其实就是信息化的水情站。 简言之，一套固定测验设备一个站，多余的设备继续成套为另一个站。直至所有的在役设备都编入站。null 3．本标准的测站概念演变 本标准在征求意见稿阶段，采用的是行政站概念，以站码＋断面号定位站内各种数据，对于与断面无关的数据，不列断面号，对于水闸，以闸组号代替断面号，对于泵站，以机组号代替断面号，对于蒸发站，以蒸发器型式替代断面号。用户可以直接按行政站组织数据。正式标准去掉了水位水文站的断面号字段，仍然保留了闸组号和机组号。null 4．本标准的测站概念 由于本标准编制时，尚无测站编码标准，因而本标准的测站和站点概念是模糊的，可以理解为一个现行测站编码办法的测站，如果不打算存储一个水位水文行政站的第二个逻辑断面的数据，也可以理解为一个行政站。null 5．本标准的站点概念 为本标准测站概念+非行政的调查点、计算点，有特别的计算要求时，站点概念可包括多点合成，也可包括区或调查区。null 1．三维流向二、水量和流量的流向降水蒸散发排 开采或出露引渗灌泻流回流null 一个行政站的流向可能是三维的，即有泻流、回流、引、排、开采、渗灌六种基本流向，要支持复杂的水量平衡和水量还原计算，必须准确标识水量或流量数据的三维流向。广义的基本流向还包括降水和蒸散发。 表结构3.0的测站指的是物理断面(如果有断面)，其流向是垂直于断面的流向，只需要采用一维表示，因而是一维流向。null 2．相对于区边界的流向 水量类别字段表示各种三维流向，不仅仅是基本流向，还包括整个时段的流向总结。水量类别字段表示的三维流向与分区无关，而水量平衡和水量还原计算属区域计算，区域计算要求明确表示水是区的输入还是输出。《调查区与站点关系表》中的站点类别字段表示进区流向和出区流向，其前7种站点类别表示空中、地表、地下水之间的层间水量交换补给方向，接着的6种站点类别表示地表水区外区内水量交换补给方向。null 3．总结的流向与通常的流向 《调查区与站点关系表》中的站点类别字段表示整个生命期的流向总结，偶尔有反流向也叫进出水点。水量类别字段表示整个当前时段的流向总结，时段内有引有排通常为引水时也取引排，时段长为0则表示瞬时流向。两者都是总结的流向，并不是通常的流向，本标准中时段量的流向都是总结的流向，注意，流向符号是针对通常的流向的，不能说瞬时量的流向就是通常的流向。null 4．一维流向换算为三维流向 电算整编数据的流向多采用一维表示，入库时不必转换为三维流向，但必须以正负号标识其一维流向，在水量平衡与还原应用中常常需要换算为三维流向，如何换算为三维流向呢？ 通常的流向指从高处到低处的流向。应从《调查区与站点关系表》中站点类别字段界定的两个方向中，选择从高处到低处的三维流向为正水量或正流量方向，另一个方向则是负水量或负流量方向。如果求的是水量，还应根据站点类别字段与水量类别字段的对应关系，确定其水量类别。null 1．站内拓扑 区站拓扑表示业务分析人员的地理知识，用于对站内计算、站间计算、区内计算和区际计算提供强大的数据支持，表结构3.0只支持单断面计算。 水闸断面按照分流水体和规格分闸组，表示水闸断面的剖分关系和水流分支汇合关系。以支持更精细的单站计算。三、区站拓扑null 泵站断面按照分流水体和规格分机组，表示泵站断面的剖分关系和水流分支汇合关系。以支持更精细的单站计算。 支持自然断面、水闸断面、泵站断面三者地理上同位置集成。进一步支持更复杂的单站计算。 流向的表示与水网的表示一致，可互相换算。null 2．站间拓扑 《测站断面关系表》表示与水体无关的断面连接关系。以多条记录表示站间连接的一对多。 《调查站点表》的上下界站码表示断面连接关系。以单条记录表示站间连接的一对多。 《调查站点表》表示复杂的地表水网、站网、控水点的断面关系，该表中的无站点水体被忽略，如果所有的水体都有站，则能表示一个完整的水网。null 通过断面与水体的衔接，间接地使闸组、机组与自流水体、湖、库衔接起来，形成一个带分部工程的水网，并把水网中的各信息点结合起来。以用于站间计算、多站计算和分区计算，也可用于多库、多湖和平原水网联合调洪演算与调节计算。 要注意的是，信息隐藏作用使得无站点水体被忽略，要实现水网站网的完全外置，可能需要为应用系统在无站点水体上添加虚拟的站点，才能构成一个没有断线的完全支持水平衡计算的外置水网和站网。 以控水目的、控水工程类型字段结合站点码表示工程与断面的关系，把工程纳入水网。null 3．区站拓扑 《调查区表》的区名字段和直接上级区名字段表示区际从属关系树。 《调查区与站点关系表》表示区站关系，可纳入所有的站点和分区，可表一区多站、一站多区、多站多区。 《调查区与站点关系表》中同一个地表水站点同时属于不同的区，且地理包含关系为边界点时，说明这几个区通过该站相连，以反映区际连接关系。null 要存储全部数据和关系，仅仅表示逻辑上的二维表是不够的，还要能用二维表表示其他数据结构(指存储内容的逻辑数据结构，也可以认为是数据在应用程序内存中的结构)，二维表几乎可以表示所有类型的逻辑数据结构。 四、用二维表表示逻辑数据结构null 1．表示非结构化数据 《图片表》存储非结构化数据。 2．表示可还原的二维表 《时间残缺数据表》是一个可还原的二维表。 可用SQL还原的二维表还有《数据订正情况表》。 3．表示树层次 《数据库字段属性表》表示表和字段两级树。 关系线双表的关系图名、线参数表达式和线上采样点编号表示图线点三级树。 《调查区表》的区名和直接上级区名构成分区树，查询时采用自连接得到树，自连一次得到两级树，自连两次得到三级树，自连n次得到n+1级树。《调查区与站点关系表》的站点码和区名将此分区树扩展到站点一级。null 4．表示网 《测站断面关系表》表示与水体无关且不带工程的站网。 《调查站点表》的上下界站码表示断面连接关系。以单条记录表示站间连接的一对多。 《调查站点表》表示带工程含水体和信息点的地表水网，配合其他表，实际上表示的是水网、站网、断面网、机组网、闸组网的混合体。第五章 高级应用的概念性数据组织方案第五章 高级应用的概念性数据组织方案 《数据库表属性表》和《数据库字段属性表》取代系统表提供存储体定义。支持对所有存储体的浏览。 《测站资料 登记表 调解登记表下载应聘登记表下载调解登记表下载调解登记表下载调解登记表下载 》标识资料序列的站年级完整性。 附注表描述年以下时段的完整性。 注解码标识记录的完整性。 残缺时间数据可分离到残缺时间数据表中，也可不分离出去，而按4.4.4的要求表示。 附注与注解描述数据的准确性。 站史存储在各沿革表中。一、数据库浏览、资料审查与数据挑选null 《图片表》的MIME类型关联各种播放工具。 《图片表》存储各种格式的多媒体，包括矢量图。 《图片表》的图标题取站点名，图字段以ORACLE Spatial几何类型存储站点的集水区矢量图。 《图片表》的图标题取区名，图字段以ORACLE Spatial几何类型存储区边界矢量图。 《图片表》的图标题取河名，图字段以ORACLE Spatial几何类型存储河段矢量图。二、图文与多媒体数据组织null 《图片表》的图字段以XML类型存储结构图 《图片表》的图字段以XML类型存储流程图 《图片表》的MIME类型取SMIL时，图字段存储多条多媒体记录集成而成的多媒体演示。 区站拓扑表示示意性分布图，反映水文业务的信息流和地理概念。 关系线表存储方法型矢量图（关系图）。 时间上不连续及注解码的缺对应统计图的断线。null B型字段准确的说应称为其他型，用于非结构化数据的全面集成，担子可能太重，某些DBMS可能难以胜任，需要有针对性地进行物理设计。 某些DBMS可能无法做到以一个字段存储各种格式的多媒体和图文内容。某些格式可能需要转换为其他格式后入库，也可能需要定义多个图字段，分别存储不同格式的多媒体数据。注意，本标准对V型字段的一个逻辑标识对应多个物理标识作了规定。但对B型字段未作类似的规定。 有流式播放要求时，需要边下载边播放，图片表可能应分解为若干个文件放到流服务器上。导致图片表物理上不在数据库中。 null 《水文 调查报告 行政管理关于调查报告关于XX公司的财务调查报告关于学校食堂的调查报告关于大米市场调查报告关于水资源调查报告 表》的调查报告内容字段可以引用《图片表》的记录。 《图片表》的图字段可以存储样式化信息。图标题必须带后缀.xsl或.css。 《水文调查报告表》的调查报告格式字段可以引用《图片表》中样式化信息的图标题。 《实测大断面成果表》和《痕迹表》存储各种断面的形状和位置。null 《关系线说明表》用于索引各种定线点据，确定定线参数，统计定线精度。通过《数据库字段属性表》可确定点据在库中的存储位置，进而生成查询点据的语句。 《关系线表》存储关系线的结点。 《关系线说明表》与《关系线表》通过站码、关系线类别和线号的等连接，找到点据，建立点据与回归线或回归面之间的对应关系。三、整编定线null 查线计算根据关系线表备注字段的查线方法进行，如备注字段无说明，则按直线插值法查线。查线计算还要考虑整个关系图是曲面、线簇还是单一线，根据线参数表达式可以作出该判断。 拟合或定线计算根据《关系线说明表》定线点据、定线参数和定线方法进行，要完成一个完整的定线过程，还必须借助其他程序或工具。null 1．水文学方法推流的优缺点(个人观点) 是规范的单站推流方法。整编规范上列出的推流方法都是水文学方法。 不使用工程运用信息。 常使用除水位外的其他流量测验物理量(如断面过水面积)。 统计学规律符合较好。 违背水力学规律的数据远远超出1/20000。 推流公式因人而异、因站而异、因时而异甚至同一站各测次不同。四、单站工程推流null 推流结果数据质量参差不齐。 难以用于测验前推流。 因公式选择的灵活性太大，公式的选定人多手杂，选定的公式可能同一站各年不同甚至各测次不同，且推流计算常常需要流量测验的各种物理量，因而常常只能作为一种事后的计算或订正手段，而一些应用如实时洪水预报调度需要在测验前事先推流。null 2．水力学方法推流的优缺点 使用工程运用信息。 不使用除水位外的其他流量测验物理量。 符合水力学规律。 同一套方法可用于所有的工程的所有的测次。 推流结果数据质量一致。 可用于事先和事后的推流计算。null 3．数据组织方案 溢洪道、深孔、阀门、排灌闸水力学推流参数参数存入《水闸特性表》 溢洪道、深孔、阀门、排灌闸运用信息及工况存入《水闸流量率定成果表》 泵站水力学推流参数存入《水电站泵站特性表》 各泵型的流量查算表存入关系线表，站码字段填泵型。null 泵站运用信息及工况存入《水电站泵站流量率定成果表》 水文学方法推流参数存入各《流量率定成果表》 为提高公式表示方法结构化程度，建议以MathXL格式存储未统一编号的水文学方法推流公式，公式中各因子的元素名直接采用对应的字段标识。null 站点水量表和区水量表中对正负号的规定方便水量平衡计算，一般可以直接使用加法。 区站拓扑存储湖库河网中各水体连接关系和三维流向。 单站工程推流数据组织方法见上文。 《水闸特性表》反映水闸改造史。 《水电站泵站特性表》反映水电站泵站改造史。 调洪演算公式和参数存入关系线表五、区域水量平衡计算与水量还原 (到任意年份)null 调节计算和补偿调节计算公式和参数存入关系线表 水量还原公式和方法存入关系线表 已还原成果存入《区水量表》 场次定义存入《站点水量表》。以支持场次水量平衡计算与水量还原。 时段类别字段列出了各种时间上的分期。以支持分期水量平衡计算与水量还原。null 预报方案的相关图存入关系线表，可存多站相关图。 预报方案的公式和预报模型化算为等价的关系线存入关系线表，多元相关应转化为等价的多个二元或三元相关。 预报方案的单位线存入关系线表。 稳定基流存入关系线表。 单站工程推流数据组织方法见前文。六、洪水预报调度及其方案编制null 单元划分及站点上下界关系存入《调查站点表》、《调查区表》和《调查区与站点关系表》，这三个表也表示了多站水量平衡关系，预报程序可据此确定调洪演算的试算和迭代步骤。 流向数据的组织见前文。 降水数据存入《调查降水量表》。 水位流量数据存入《洪水水文要素摘录表》。null 场次定义存入《站点水量表》，以支持场次洪水预报。在调查报告编号字段列带区名的场次编号。各站的起涨落平时点虽可能不同，但却有统一的场次编号。 时段类别字段列出了各种时间上的分期。以支持分期连续洪水预报。 各种调度预案以XML格式存入《图片表》的图字段。 设计洪水存入《洪枯水调查考证成果表》，在水情描述字段注明“设计洪水重现期x年”。null 在《调查站点表》中，水电站控水目的含“发电”，控水工程类型为“泵”。 库区基本资料存入《调查区表》。 库区与各站点的水量交换关系存入《调查区与站点关系表》 设计的特征水位和特征库容存入《水库基本工程指标表》 溢洪道水闸及输水工程设计指标存入分部工程基本情况表6.1.10 和表6.1.11。 七、水能设计null 水工建筑设计成果在图片表中。 设计暴雨存入《调查降水量表》，在雨情描述字段注明“设计暴雨”。设计面暴雨的站点名取区名，站点码取区码。 设计洪水存入《洪枯水调查考证成果表》，在水情描述字段注明“设计洪水重现期x年”。 径流资料在日表旬表月表年表中。 典型暴雨洪水在摘录表中 电站下游流量水位关系曲线 频率曲线查算表存入关系线表null水库库区陆面蒸发和水面蒸发存入《区水量表》 水库库区渗漏资料存入《区水量表》 水库水位容积、水位面积关系曲线存入关系线表 点用水资料存入《站点水量表》 面用水资料存入《区水量表》 出力历时曲线或出力保证率曲线存入关系线表 装机发电量关系曲线存入关系线表null水库防洪调节计算见上文的区域水量平衡计算与水量还原 兴利库容调节水量与设计保证率关系存入关系线表 调节库容保证率曲线存入关系线表 水库调度图存入关系线表 灌溉需水过程线存入关系线表null 以上示例，应该能说明一个问题，本标准不仅是一个表结构方案，也是一个流域数字化方案的雏形，配以相应的应用软件，可用于大流域水文业务的数字化，虽然表示方法单一，功能尚不完整，不能构成一个完整的数字流域系统，但一个数字流域系统除了要有完整的基础水文数据外，至少还应该存储完整的计算参数，应该实现区站拓扑的数字化和方法组合的数字化，本标准的数据库只差方法组合的数字化方案。null