数据库进阶：ERP管理软件数据库系统的几种设计方法

自增长primary key

采用自增长primary key主要是性能 早期的数据库系统 经常采用某种编号 比如身份z号码 公司编号等等作为数据库表的primary key 然而 很快 大家就发现其中的不利之处

比如早期的医院管理系统 用身份z号码作为病人表的primary key 然而 第一 不是每个人都有身份z;第二 对于国外来的病人 不同国家的病人的证件号码并不见得没有重复 因此 用身份z号码作为病人表的primary key是一个非常糟糕的设计 考虑到没有医生或者护士会刻意去记这些号码 使用自增长primary key是更好的设计

公司编号采用某种特定的编码方法 这也是早期的数据库系统常见的做法 它的缺点也显而易见 很容易出现像千年虫的软件问题 因为当初设计数据库表的时候设计的位数太短 导致系统使用几年后不能满足要求 只有修改程序才能继续使用 问题在于 任何人设计系统的时候 在预计某某编号多少位可以够用的时候 都存在预计不准的风险 而采用自增长primary key 则不存在这种问题 同样的道理 没有人可以去记这些号码

使用自增长primary key另外一个原因是性能问题 略有编程常识的人都知道 数字大小比较比字符串大小比较要快得多 使用自增长primary key可以大大地提高数据查找速度

避免用复合主键 (pound primary key)

这主要还是因为性能问题 数据检索是要用到大量的 primary key 值比较 只比较一个字段比比较多个字段快很多 使用单个primary key 从编程的角度也很有好处 sql 语句中 where 条件可以写更少的代码 这意味着出错的机会大大减少

双主键

双主键是指数据库表有两个字段 这两个字段独立成为主键 但又同时存在 数据库系统的双主键最早用在用户管理模块 最早的来源可能是参照 *** 作系统的用户管理模块

*** 作系统的用户管理有两个独立的主键 *** 作系统自己自动生成的随机 ID (Linux windows 的 SID) login id 这两个 ID 都必须是唯一的 不同的是 删除用户 test 然后增加一个用户 test SID 不同 login id 相同 采用双主键主要目的是为了防止删除后增加同样的 login id 造成的混乱 比如销售经理 hellen 本机共享文件给总经理 peter 一年后总经理离开公司 进来一个普通员工 peter 两个peter 用同样的 login id 如果只用 login id 作 *** 作系统的用户管理主键 则存在漏洞 普通员工 peter 可以访问原来只有总经理才能看的文件 *** 作系统自己自动生成的随机 ID 一般情况下面用户是看不到的

双主键现在已经广泛用在各种数据库系统中 不限于用户管理系统

以固定的数据库 表应付变化的客户需求

这主要基于以下几个因素的考虑

大型EPR系统的正常使用 维护需要软件厂商及其众多的合作伙伴共同给客户提供技术服务 包括大量的二次开发

如果用户在软件正常使用过程中需要增加新的表或者数据库 将给软件厂商及其众多的合作伙伴带来难题

软件升级的需要

没有一个软件能够让客户使用几十上百年不用升级的 软件升级往往涉及数据库表结构的改变 软件厂商会做额外的程序将早期版本软件的数据库数据升级到新的版本 但是对于用户使用过程中生成的表进行处理就比较为难

软件开发的需要

使用固定的数据库库表从开发 二次开发来说 更加容易 对于用户使用过程中生成的表 每次查找数据时都要先查表名 再找数据 比较麻烦

举例来说 早期的用友财务软件用Access作数据库 每年建立一个新的数据库 很快 用户和用友公司都发现 跨年度数据分析很难做 因此这是一个不好的设计 在 ERP 中 很少有不同的年度数据单独分开 一般来说 所有年份的数据都在同一个表中 对于跨国公司甚至整个集团公司都用同一个 ERP 系统的时候 所有公司的数据都在一起 这样的好处是数据分析比较容易做

现在大多数数据库系统都能做到在常数时间内返回一定量的数据 比如 Oracle 数据库中 根据 primary key 在 万条数据中取 条数据 与在 亿条数据中取 条数据 时间相差并不多

避免一次取数据库大量数据 取大量数据一定要用分页

这基本上是现在很多数据库系统设计的基本守则 ERP 系统中超过 万条数据的表很多 对于很多表中的任何一个 一次取所有的会导致数据库服务器长时间处于停滞状态 并且影响其它在线用户的系统响应速度

一般来说 日常 *** 作 在分页显示的情况下面 每次取得数据在 之间 系统响应速度足够快 客户端基本没有特别长的停顿 这是比较理想的设计 这也是大型数据库系统往往用 ODBC ADO 等等通用的数据库联接组件而不用特定的速度较快的专用数据库联接组件的原因 因为系统瓶颈在于数据库( Database) 方面(数据量大) 而不在于客户端(客户端每次只取少量数据)

在 B/S 数据库系统中 分页非常普遍 早期的数据库系统经常有客户端程序中一次性取大量数据做缓冲 现在已经不是特别需要了 主要原因有

数据库本身的缓冲技术大大提高

大部分数据库都会自动将常用的数据自动放在内存中缓冲 以提高性能

数据库联接组件的缓冲技术也在提高

包括 ADO 在内的一些数据库联接组件都会自动对数据结果集(result set)进行缓冲 并且效果不错 比较新颖的数据库联接组件 比如 Hibernate 也加入了一些数据结果集缓冲功能

当然 也有一些数据库联接组件没有对数据结果集进行缓冲 比如 JDBC Driver 不过几年之内情况应该有所改观 也有些不太成功的数据缓冲 比如 EJB 中的实体Bean 性能就不尽如人意 实体Bean数据也是放在内存中 可能是因为占用内存过多的缘故

lishixinzhi/Article/program/SQL/201311/16157

（一）系统数据库类型

数据库是整个农用地分等信息系统的基础，是系统开发设计要考虑的重中之重。在数据形式上，系统数据库包括两大块：一是空间数据库，二是属性数据库。目前的空间数据技术已从以MapInfo为代表的混合型数据库（空间数据库＋关系型数据库）发展到以ArcInfo的Coverage为代表的拓展型数据库。鉴于农用地分等属性数据量庞大，为减少数据冗余，提高数据检索的速度，本研究采用空间数据和属性数据分开管理的模式，依据关键字段进行绑定，进行科学索引，从而实现空间数据和属性动态链接和高效整合。

1空间数据库

江苏省农用地分等信息系统空间数据库内容包括以下方面：

（1）土地利用现状图层：全省13个省辖市以1996年土地利用现状图为基础，经变更调绘形成以2000年为基准年的土地利用现状图，以现行的土地分类标准按八大类分类进行信息提取并分层存储，系统分别存储为耕地、林地、水域、未利用地、建设用地等图层。

（2）全省土壤类型图层：以土属为分类单位，比例尺为1:20万。

（3)1996年和2000年全省行政区划图层：在行政区划中精确到乡镇级别，分别提取存储了市名图层、县（区）名图层、乡（镇）名图层、全省行政界线图层、市级行政界线图层、县（区）级行政界线图层、乡（镇）级行政界线图层。

（4）评价单元图层：通过GIS空间叠加功能，利用土地利用现状图、行政区划图和土壤类型图叠加产生的评价单元图层，建立分等评价单元数据库。

2属性数据库

江苏省农用地分等信息系统属性数据库内容包括以下方面：

（1）土壤属性数据：以全国第二次土壤普查为基础，结合全省土壤监测样点数据，建立土壤质量状况数据库，最小单位为土种，包括pH值、有机质含量、表层土壤质地、耕层厚度、障碍层深度、水土侵蚀程度、盐渍化程度数据。

（2）农田水利环境数据：建立了1996～2000年间各乡镇农田水利环境基础数据库，包括灌溉保证率、排水条件数据。

（3）土地利用现状数据：建立了全省13个省辖市的以1996年土地利用现状图为基础，经变更调绘形成的以2000年为基准年的土地利用现状数据库，区分耕地中的详细用地类型差异，标示水田、旱地、荒草地等纳入本次评价范围的用地内容。

（4）全省地形地貌数据库。

（5）农业区划数据：输入了江苏省农业区划数据，把江苏全省划分为6大区划，以乡镇为最小级别，建立全省乡镇的区划归属数据库。

（6）农业耕作制度数据：建立了全省各市、县、乡镇的农业耕作制度数据库，包括指定作物水稻和小麦的播种空间分布状况数据库。

（7）光温生产潜力数据：建立了全省各市、县指定作物水稻和小麦的光温生产潜力和气候生产潜力数据库。

（8）农业投入－产出数据：全省13个省辖市以乡镇为单位，建立了1996～2000年农业生产投入－产出数据库。

（9）作物产量数据：全省13个省辖市以乡镇为单位，建立了1996～2000年的指定作物水稻和小麦的产量数据库。

（10）土地利用详查分类面积数据：全省13个省辖市以乡镇为单位，建立了2000年土地利用详查分类面积数据库。

从数据格式上分，数据库又可分为：①图件数据库：指空间数据以及绑定在空间数据上的相关属性数据，本次江苏省农用地分等建立了以分等单元为记录的属性数据库，并通过关键字段与空间数据关联；②分类统计数据库：包括全省13个省辖市以乡镇为单位的1996～2000年指定作物产量统计数据和全省13个省辖市以乡镇为单位的2000年土地利用详查分类面积统计数据。

（二）系统数据库管理模式

为减少数据存储冗余，同时提高索引速度，江苏省农用地分等信息系统数据文件采用普遍的目录树形式进行管理，按省－市－县行政体系分别存储相关数据。全省建立13个省辖市分目录，分目录下按照各自所含的县（区）建立子目录。根据目前行政管理体系现状，基础资料大多来源于县级行政单位，因此采用县（区）为基本行政单位较为合理，在保证资料来源的同时，也利于资料的分类归档存储。其相对应的空间图件数据也按精度要求分割到县级行政单位，既能减少系统调用数据的吞吐量，同时也满足了系统的精度需求。空间数据、属性数据、文本数据按照各自所属的行政级别归类存储，同时设立数据文件管理器进行目录文件的索引管理，见图3-86。

图3-86 江苏省农用地分等信息系统数据文件管理模式图

（三）系统数据库结构

数据库的结构设计决定了数据之间的调用及接口关系，清晰的逻辑调用关系和统一的数据接口格式有利于数据的组织、管理、调用。

1空间数据库

江苏省农用地分等信息系统空间数据库以矢量图件的形式存在，以分图层的方式管理，包括了全省行政界线、土壤类型、按八大类分别提取的土地利用现状、分等单元等图层。其中，分等单元图层作为农用地分等的基础，考虑到图层本身信息量大，可能影响到系统运行效率，因此所在图层的属性表中只保留了ID字段，通过ID字段与外部属性库绑定，实现分等单元与外部属性库一一对应关系。ID字段是本图层的特征代码，表征了单元的唯一性，能体现出单元的图上位置和行政归属。《农用地分等定级规程》（国土资源大调查专用）和《中华人民共和国行政区划代码》（GB/T 2260-1999）为本研究分等单元代码的编码依据；本研究有1996年和2000年两套行政区划工作底图，为此分等单元特征代码共设14位，依次为江苏省代码（2位）－市代码（2位）－2000年县或区代码（2位）－2000年乡镇代码（2位）－1996年县或区代码（2位）－1996年乡镇代码（2位）－分等单元号（2位）。其中，省、市、县（区）的行政代码按国家统一代码，乡镇级代码在县（区）范围内根据划分分等单元的需要依次编码；分等单元编号的原则是不破乡镇界，即单元号是在同一乡镇内部自行编码。示例：32011501210101，指1996年江苏（32）南京（01）市江宁县（21）由于2000年行政调整变更为南京（01）的江宁区（15）。按行政体系分级编码的优点是有利于空间查询和国土资源管理部门根据工作需求按行政级别分类汇总统计数据。

2属性数据库

江苏省农用地分等信息系统采用关系型数据库来存储数据，优点是结构清晰明了，数据的更新维护方便，通过索引能优化数据库，建立快速的查询浏览（表3-26～表3-30）。

表3-26 行政代码数据结构表

表3-27 土壤属性数据结构表

表3-28 农田水利设施数据结构表

表329 指定农作物投入－产出数据结构表

表3-30 农业耕作制度及农业区划表

（四）系统模型库

系统以《农用地分等定级规程》（国土资源大调查专用）中的相关技术方法和计算模型为基础，在模型库中预先内置了分等计算模型。模型库是动态，它允许专家根据情况动态调整计算模型形式及其参数。系统主要模型的数学计算公式如下：

（1）农用地自然质量分值（Clij）计算公式见式（3-11）。

（2）样点土地利用系数计算公式：

中国耕地质量等级调查与评定（江苏卷）

式中：

Klj´——样点的第j种指定作物土地利用系数；

Yj——样点的第j种指定作物实际单产；

Yj,max——第j种指定作物最大标准粮单产。

（3）等值区土地利用系数计算公式：

中国耕地质量等级调查与评定（江苏卷）

式中：

Klj——等值区内第j种指定作物土地利用系数；

Klj´——参与计算的同一等值区内合格样点第j种指定作物土地利用系数；

n——排除异常数据后参与计算的样点的个数。

（4）样点土地经济系数计算公式：

中国耕地质量等级调查与评定（江苏卷）

式中：

Kcj′——样点的第j种指定作物土地经济系数；

Yj——样点第j种指定作物实际单产；

Cj——样点第j种指定作物实际成本；

Aj——第j种指定作物最高“产量－成本”指数。

（5）等值区土地经济系数计算公式：

中国耕地质量等级调查与评定（江苏卷）

式中：

Kcj——等值区内土地经济系数；

Kcj´——参与计算的同一等值区内合格样点第j种指定作物土地经济系数；

n——排除异常数据后参与计算的样点的个数。

（6）农用地自然质量等指数（Ri）计算公式见式（3-12）和式（3-13）。

（7）农用地利用等指数（Yi）计算公式见式（3-14）和式（3-15）。

（8）农用地经济等指数（Gi）计算公式见式（3-16）和式（3-17）。

数据库设计(Database Design)是指对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，使之能够有效地存储数据，满足各种用户的应用需求（信息要求和处理要求）。在数据库领域内，常常把使用数据库的各类系统统称为数据库应用系统。

数据库设计的设计内容包括：需求分析、概念结构设计、逻辑结构设计、物理结构设计、数据库的实施和数据库的运行和维护。

数据库设计(Database Design)是指根据用户的需求，在某一具体的数据库管理系统上，设计数据库的结构和建立数据库的过程。数据库系统需要 *** 作系统的支持。

数据库设计是建立数据库及其应用系统的技术，是信息系统开发和建设中的核心技术。由于数据库应用系统的复杂性，为了支持相关程序运行，数据库设计就变得异常复杂，因此最佳设计不可能一蹴而就，而只能是一种“反复探寻，逐步求精”的过程，也就是规划和结构化数据库中的数据对象以及这些数据对象之间关系的过程。

关系：优点是基于严格的数学概念，一个单一的，相关的实体和实体的概念是由

的关系，就这么简单的数据结构，清晰，透明的用户访问路径，因此较高的数据独立性和代表

更好的安全保密性。其缺点是，该查询效率比非关系数据库，它必须被用于查询优化，增加显影

加上数据库管理系统中的困难。

以上就是关于数据库进阶：ERP管理软件数据库系统的几种设计方法全部的内容，包括:数据库进阶：ERP管理软件数据库系统的几种设计方法、系统数据库和模型库设计、什么是数据库设计等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！