常见数据库设计(3)——历史数据问题之多记录变更

２０２３年６月第２５卷第３期㊀㊀沈阳建筑大学学报(社会科学版)㊀㊀ＪｏｕｒｎａｌｏｆＳｈｅｎｙａｎｇＪｉａｎｚｈｕＵｎｉｖｅｒｓｉｔｙ(ＳｏｃｉａｌＳｃｉｅｎｃｅ)Ｊｕｎ.㊀２０２３Ｖｏｌ.２５ꎬＮｏ.３㊀㊀收稿日期:２０２２－１１－２７㊀㊀基金项目:国家自然科学基金项目(５１９７８４２０)ꎻ辽宁省 兴辽英才计划 项目(ＸＬＹ２００７１４８)ꎻ辽宁省教育厅科学研究一般项目(ｌｎｊｃ２０１９１７)㊀㊀作者简介:郝鸥(１９８０ )ꎬ女ꎬ辽宁鞍山人ꎬ副教授ꎮ文章编号:１６７３－１３８７(２０２３)０３－０２３２－０９ｄｏｉ:１０.１１７１７/ｊ.ｉｓｓｎ.１６７３－１３８７.２０２３.０３.０３基于ＧＩＳ的辽阳东京城遗址空间数据库设计探究郝㊀鸥１ꎬ宋祖伟２(１.沈阳建筑大学建筑研究所ꎬ辽宁沈阳１１０１６８ꎻ２.沈阳建筑大学建筑与规划学院ꎬ辽宁沈阳１１０１６８)摘㊀要:近年来ꎬ随着空间信息技术的不断发展ꎬ越来越多的学者开始将其与文化遗产保护相结合ꎬ以实现景观考古的数字化研究ꎮ选取辽阳东京城为主要研究对象ꎬ通过实地调研和相关资料收集㊁归纳及分析ꎬ悉清东京城的现状信息和历史文化遗产信息ꎬ以ＡｒｃＧＩＳ软件为技术支持ꎬ对东京城地理㊁历史文化㊁遗迹遗存等数据进行整合并建立遗址空间数据库ꎬ以便于对古城地理格局变化㊁历史演变以及相关遗迹遗存的整体性空间布局有更清晰的认识ꎬ更准确地界定古城保护范围ꎬ为系统性的东京城研究提供科学依据和技术支撑ꎮ关键词:辽阳东京城ꎻ空间数据库ꎻ古城遗址ꎻ地理信息系统(ＧｅｏｇｒａｐｈｉｃＩｎｆｏｒｍａｔｉｏｎＳｙｓｔｅｍꎬＧＩＳ)ꎻ文化遗产中图分类号:ＴＵ２０１.４㊀㊀㊀文献标志码:Ａ㊀㊀空间数据库是指地理信息系统(ＧｅｏｇｒａｐｈｉｃＩｎｆｏｒｍａｔｉｏｎＳｙｓｔｅｍꎬＧＩＳ)在计算机物理存储介质上存储的与应用相关的地理空间数据的总和ꎬ一般是以一系列特定结构的文件形式组织在存储介质之上[１]ꎮ由于传统的数据主要是以图片和文字为主ꎬ后期在数据存储㊁管理㊁更新㊁查找方面存在许多缺陷ꎬ因此随着ＧＩＳ技术的引入ꎬ研究者以数据库的形式对繁琐的数据进行了统一的管理和共享ꎬ解决了数据的统计㊁存储和查询问题[２]ꎮ同时ꎬＧＩＳ技术具有强大的空间分析能力ꎬ通过将遗址遗存的地理信息㊁历史文化信息以及空间特征等数据进行整合并分层存储ꎬ建立全方位的遗址分布网络ꎬ为复杂环境下遗址与空间的关系研究提供技术支撑和参考ꎬ所以近年来在考古学㊁历史学等相关学科研究中被广泛应用ꎮ早在２０世纪７０年代末ꎬ欧美国家就已经将计算机技术引入考古研究ꎬ对遗址进行基础的空间分析ꎬ考古空间数据库的概念开始萌芽[３]ꎮ２０世纪８０年代ꎬ随着计算机技术的进一步普及ꎬ将ＧＩＳ技术与聚落考古相结合的研究开始大量出现[４]ꎮ此后ꎬ随着遥感㊁ＧＩＳ技术的快速发展ꎬ考古空间数据获取的途径更加多样化㊁便捷化ꎬ数据精度㊁数据处理的速度和质量也大幅提高ꎬ空间数据库在考古领域的应用因此更加普遍[５]ꎮ辽阳东京城遗址研究工作大致始于１９世纪中叶ꎬ经过长达半个世纪的研究积累ꎬ东京城遗址的相关数据类型较为丰富ꎬ将文件系统转换成数据库系统成为客观需要ꎮ笔者第３期郝㊀鸥等:基于ＧＩＳ的辽阳东京城遗址空间数据库设计探究２３３㊀对现阶段数据进行了整理与分析ꎬ并在田野调查的基础上ꎬ选择ＡｒｃＧＩＳ软件作为空间数据库的建库基础ꎬ构建了东京城遗址空间数据库ꎮ该数据库除了对东京城遗址遗存等资料实现了一体化存储和管理外ꎬ还从景观考古学的角度使人对东京城空间格局演变以及相关遗迹遗存的整体性空间布局有了清晰的认识ꎬ从而有助于更加科学地界定东京城的保护范围ꎮ一㊁东京城遗址研究概述东京城遗址位于辽宁省辽阳市太子河东岸ꎬ为后金时期努尔哈赤所建的关外三京之一[６]ꎮ据文物部门实测ꎬ遗址为菱形平面ꎬ全城周长３５１０ｍꎬ占地面积约为７５ｈｍ２ꎬ同时确定了八角殿㊁汗王宫㊁弥陀禅寺㊁城门㊁城墙等遗址的位置ꎬ西侧还可模糊地分辨出护城河的遗迹(见图１)ꎮ图１　东京城遗址遗存位置示意图㊀㊀东京城遗址保护工作可追溯至民国初期文物普查中对其进行的简要的登记造册ꎮ２０世纪３０年代ꎬ以鸟居龙藏为首的日本研究团队对辽阳地区的历史古迹进行了勘测记录ꎬ之后菊池贞二㊁吉村孝义㊁鸳渊一等人分别对东京城历史遗迹进行了研究ꎬ完成了简要的普查和概述ꎬ其中ꎬ吉村孝义对东京城遗址区域进行了测绘ꎬ并通过测绘结果证实了东京城城墙四周可能存在角楼的猜想ꎮ中华人民共和国成立后随着科研团队逐渐专业化ꎬ相关研究人员对东京城遗址开展了挖掘和测绘工作ꎬ当时的东京城被村庄覆盖ꎬ遗址遭到了较为严重的破坏ꎬ在新城村先后出土了天佑门㊁内治门㊁德盛门㊁抚近门的门额ꎬ均刻有 大金天命壬戌年 字样ꎬ证实了东京城所建年份ꎬ同时ꎬ城内还挖掘出部分石碑㊁门额㊁宫殿遗物等历史遗存ꎮ随着挖掘出的遗址数量不断增多ꎬ政府开展了对东京城遗址的保护工作ꎬ由于当时天佑门保存得相对完整ꎬ１９９８年政府对天佑门遗址进行了复建ꎬ修复后的天佑门与原初的遗存有明显的痕迹区分ꎬ反映了当时的考古修复潮流ꎮ同时ꎬ在实地考古研究的基础上ꎬ东京城的相关理论研究也日益丰富ꎬ其中ꎬ全晓红[７]在«东京城与东京陵»一书中对东京城㊁东京陵的历史㊁艺术㊁文化价值进行了全面深入的论述和科学评价ꎬ为东京城㊁东京陵两处文物晋升全国重点文物保护单位做出了贡献ꎮ王佩环[８]在«关外三都»中对兴京㊁东京和盛京３座都城的形制规模以及城域形制格局进行了介绍ꎬ对东京城的历史发展沿革进行了梳理ꎮ李声能等[９]通过分析女真族的建城特点ꎬ对东京城的营建特点进行了总结ꎮ这些丰富的理论研究为东京城遗址的保护工作提供了重要参考ꎮ此后随着各界学者的研究不断深入ꎬ２０１３年东京城获批成为全国第七批重点文物保护单位ꎬ２０１５年辽阳市政府陆续开展了对东京城的保护工作ꎬ先将遗址范围内的环境进行了整顿ꎬ拆除村庄ꎬ并对遗址区域进行了规划ꎬ２０２１年东京城遗址公园建设已基本完成ꎮ二㊁空间数据库的特点首先ꎬ空间数据库最大的特点是可以在数据整合的基础上开展各类空间分析ꎬ更加形象化㊁具体化地表现对象的特征和属性ꎮ从全局的角度对遗址群㊁遗址空间结构进行分析ꎬ恰好构成了景观考古学的基础[１０]ꎮ例如ꎬ在东京城考古发掘中发现的宫殿㊁城门㊁城墙以及护城河等遗址数据只能以文字和图片的形式保存ꎬ但在空间数据库中可用点㊁线㊁面的形式分别显示遗址的空间位２３４㊀㊀㊀㊀沈阳建筑大学学报(社会科学版)第２５卷置㊁面积㊁范围等信息ꎬ同时ꎬ结合影像图还可以进一步分析这些遗址周围的地形㊁地貌㊁空间格局等特征ꎬ更利于界定遗址的保护范围ꎮ其次ꎬ空间数据库还可以连接属性表进行相关属性信息的描述ꎮ例如ꎬ在ＡｒｃＧＩＳ中可以利用属性表对东京城内相关遗迹遗存的长度㊁宽度㊁面积等空间信息进行描述ꎬ从而形成空间位置与属性信息的关联ꎻ同时ꎬ空间数据库还可以将不同时间㊁不同比例尺的数据存储在同一数据库中ꎬ增加了数据库的时间属性ꎬ进而可以从时空两个层面对东京城遗址遗存进行综合分析[１１]ꎮ由于数据之间的坐标系不同ꎬ在存储时需要转换成统一的ＷＧＳ１９８４坐标系之后ꎬ再将数据导入存储即可叠加显示ꎮ三㊁东京城遗址空间数据库的设计通过实地调查和相关资料收集㊁归纳与分析ꎬ在悉清东京城现状信息的基础上ꎬ充分利用ＡｒｃＧＩＳ强大的空间分析功能ꎬ对东京城地理㊁历史文化㊁遗迹遗存等进行整合并建立空间数据库ꎬ为复杂环境下遗址空间信息与历史信息的整合研究提供技术支撑和参考ꎮ１.空间数据库的总体结构空间数据库是一个系统化的整体ꎬ各部分内容按照空间拓扑关系分层存储ꎬ形成子数据库ꎬ从而建立起数据库总体框架[１２]ꎮ通过对东京城数据的采集和整理ꎬ将东京城遗址空间数据库分为历史空间布局子数据库㊁基础地理现状子数据库㊁文化遗产专题子数据库(见图２)ꎮ其中ꎬ历史空间布局数据库主要用来存储各时期的空间布局图㊁历史舆图以及相关的历史信息数据ꎮ东京城遗址经过长期的研究和挖掘ꎬ积累了丰富的文献记载ꎬ这些文献既可以为东京城的深入研究提供理论基础ꎬ也可以成为遗产评估的重要依据ꎬ具有十分重要的意义ꎮ基础地理现状数据库用来存储东京城最新的栅格数据和矢量数据ꎬ包括遗址范围内的遥感影像数据㊁数字高程模型数据㊁不同比例的矢量数据等ꎮ文化遗产专题数据库主要用来存储与东京城遗址遗存相关的信息数据ꎬ包括遗址的空间位置㊁现存情况㊁矢量图像和栅格图像ꎬ同时还包括大量三维影像等资料以及各种属性数据ꎮ图２　东京城遗址空间数据库总体框架２.数据来源(１)东京城相关古籍ꎮ与东京城相关的历史古籍为东京城的研究及数据库建设提供了重要依据ꎬ所用古籍包括«东三省古迹遗闻»«满文老档»«清太祖高皇帝实录»«燕行録»等ꎮ(２)东京城相关近现代出版物ꎮ鸳渊一在«辽阳东京城及东京陵»中对东京城的城墙遗址㊁城镇聚落等进行了考察和研究ꎬ对遗址进行了简单的描述ꎮ全晓红[７]的«东京城与东京陵»和王佩环的[８]«关外三都»等论著对东京城的营建格局进行了探究ꎮ王飒等[１３]在«辽宁东部明代聚落研究回顾与评析»中对建州女真聚落研究进行了梳理ꎬ从辽宁地区自然与人文的历史特点出发ꎬ阐析了东京城遗址的独特性ꎮ(３)测绘数据与资料ꎮ１９４３年ꎬ吉村孝义对东京城进行了简单的测绘ꎬ并在«新城实测报告»中对其进行了描述ꎮ２０００年后随着研究的深入ꎬ专业的考古团队又对东京城进行了详细的测绘和挖掘ꎮ笔者参照东京城遗址考古报告及相关历史文献资料ꎬ于２０２２第３期郝㊀鸥等:基于ＧＩＳ的辽阳东京城遗址空间数据库设计探究２３５㊀年对东京城遗址地区进行了田野调查和实地测绘ꎬ并采集航拍影像资料ꎬ为空间数据库提供了更加详细的遗址信息ꎮ(４)卫星影像资料ꎮ空间数据库所需的影像资料包括数字高程模型数据和数字线划矢量数据ꎬ其中ꎬ数字线划矢量数据来源于国家基础地理信息中心ꎬ包括行政区划㊁河流㊁道路㊁湖泊水系等信息ꎮ东京城遗址空间数据库具体数据内容可分为以下几类(见表１)ꎮ表１㊀东京城遗址空间数据库数据内容分类数据类型数据名称数据包含内容历史舆图表现重要的历史要素的相对位置关系ꎬ在具体的位置㊁距离㊁形状上准确性较低历史空间布局数据空间布局图４个时期的空间布局平面推测文献资料古籍㊁现代出版物㊁考古资料等数字线化数据行政区划㊁河流㊁道路㊁植被等基础地理现状数据数字高程模型３０ｍ高程数据遥感影像数据ＴＭ/ＥＴＭ㊁高分一号等ＤＯＭ数据点 状遗址遗存遗址的地理信息㊁保存现状㊁遗址范围等文化遗产专题数据 线 状遗址遗存遗址的地理信息㊁保存现状㊁遗址范围等面 状遗址遗存遗址的地理信息㊁保存现状㊁遗址范围等生产生活遗址水源㊁水井等生活遗址信息３.概念设计概念设计是将分析得到的用户数据抽象成信息世界的概念结构模型的过程ꎬ是整个数据库系统设计的核心[１４]ꎮ由于东京城遗址历经时间较长㊁后期保护不到位㊁数据类型较多等因素ꎬ在数据库构建初期ꎬ需将基础数据划分出不同的要素层级ꎬ以便于将数据进行分类存储ꎮ数据结构如图３所示ꎮ图３　东京城遗址空间数据库图层结构示意图４.逻辑结构设计逻辑结构设计是将概念设计中的要素层级转化为计算机逻辑结构的模型ꎬ包括要素属性表设计㊁数据的分层存储设计等[１５]ꎮ笔者将入库的数据分为历史空间布局要素㊁基础地理现状要素和文化遗产要素３类(见表２)ꎮ其中ꎬ文化遗产要素主要包括 点 状文化遗产㊁ 线 状文化遗产和 面 状文化遗产ꎮ对于 点 状文化遗产ꎬ按照其功能可分为宫殿遗址㊁宗教寺庙遗址㊁城门遗址㊁墓葬遗址等ꎬ在存储时ꎬ为了便于显示ꎬ各遗址单独置于一个图层ꎮ 线 状文化遗产主要分为城墙遗址和护城河遗址ꎬ城墙遗址主要分为４段:东城墙㊁南城墙㊁西城墙和北城墙ꎬ各２３６㊀㊀㊀㊀沈阳建筑大学学报(社会科学版)第２５卷表２　东京城遗址空间数据库要素分类序号要素类型要素名称属性表名历史舆图ＬＳＹＴ１历史空间布局要素空间布局图ＫＪＢＪＴ文献资料ＷＸＺＬ２基础地理现状要素矢量数据ＳＬＳＪ栅格数据ＳＧＳＪ点 状文化遗产ＤＺＹＳ３文化遗产要素 线 状文化遗产ＸＺＹＳ面 状文化遗产ＭＺＹＳ段城墙信息分层存储ꎬ便于表达和查询ꎮ 面 状文化遗产主要包括八角殿和汗王宫的遗址所在片区ꎬ以及其余遗址遗存构成的片区[１６]ꎬ其空间信息各不相同ꎬ因此需要分层存储ꎮ东京城遗址空间数据库详细的逻辑结构如图４所示ꎮ图４　东京城遗址空间数据库逻辑结构第３期郝㊀鸥等:基于ＧＩＳ的辽阳东京城遗址空间数据库设计探究２３７㊀５.物理设计(１)数据的采集与录入东京城遗址空间数据库所采集的数据类型主要为影像图㊁高程图㊁文本资料和属性数据ꎮ数据采集录入流程如图５所示ꎮ其中ꎬ遥感影像数据和高程数据本身带有经纬坐标ꎬ只需要统一坐标系后直接在ＡｒｃＧＩＳ中进行添加ꎬ采用影像金字塔结构进行建库ꎮ考古资料图㊁历史舆图㊁历史照片及现状照片等数据大多为文本数据ꎬ一般没有地理坐标ꎬ通图５㊀东京城遗址空间数据库数据采集录入流程常的做法是需要将这些数据进行扫描ꎬ导入ＧＩＳ进行地理配准ꎬ将配准后带有坐标系统的图像数据重新导入数据库ꎮ(２)数据库更新及安全设计东京城文化遗产是活的文化遗产ꎬ数据的更新是必然的ꎮ随着东京城的保护研究工作不断深入ꎬ东京城的数据也会随之增加并更加全面ꎬ因此必须保证数据库可以随时更新并添加数据ꎬ保证数据库的安全共享ꎮ目前ꎬ东京城遗址空间数据库已部分建成ꎬ完成了对田野调查数据的整理与归纳工作ꎬ并进行了部分数据的入库存储ꎬ接下来在完善数据库的同时对库内数据不断进行补充ꎬ并在现阶段数据库的基础上开展空间分析工作ꎮ东京城遗址空间数据库部分界面如图６所示ꎮ图６㊀东京城遗址空间数据库界面与属性表截图四㊁东京城遗址空间数据库的应用１.空间分析在东京城遗址空间数据库的基础上ꎬ借助ＧＩＳ技术的空间分析功能ꎬ对东京城各个发展时期的空间布局进行分析ꎬ可以直观地反映出东京城的发展过程ꎮ例如ꎬ从努尔哈赤营建的众多城池的选址中可以看出ꎬ女真族早期的城池皆依山而建ꎬ大体上可分为山城和半山城两种类型[１７]ꎮ而从东京城选址的山川地势可以发现ꎬ其所处地域三面环山ꎬ一面临水ꎬ属于丘陵建城(见图７)ꎮ因此ꎬ东京城可以说是后金建城史上的转折点ꎬ是从山岗走向平原的代表ꎮ同时ꎬ根据建成之后的布局推测可以看出ꎬ东京城的营建较之后金城池营建的固有模式已经有了很大的改观ꎮ例如ꎬ城域内设置８座城门ꎬ每边城墙各设两座ꎬ内部整体格局近乎模糊的 井 字形(见图８~图１０)ꎮ城内八角殿和汗王宫两处行政体系首次采用宫殿分设的布局形式ꎬ皇宫的居住区在距八角殿之西约１００ｍ处的全城制高点上ꎬ八角２３８㊀㊀㊀㊀沈阳建筑大学学报(社会科学版)第２５卷图７㊀东京城建成前空间布局示意图图８㊀东京城建成后空间布局示意图图９㊀东京城倾圮后空间布局示意图图１０㊀东京城遗址公园空间布局示意图殿所在地则是场地内第二个高台ꎬ类似于汉文化 前朝后寝 的宫殿平面布局ꎮ东京城的宫殿布置已经摆脱了赫图阿拉那种宫殿混建的局面ꎬ而是采用宫殿分设的布局手法来区分处理政务的机关和皇家寝居ꎬ这是以努尔哈赤为首的女真社会向文明迈近的一步ꎮ在修建八角殿时ꎬ八角攒尖屋顶的建筑形制首次出现在女真族宫殿建筑上ꎬ该形式对后来沈阳盛京城的营建影响深远ꎮ２.地理分析在东京城遗址空间数据库的基础上ꎬ借助ＧＩＳ空间分析技术对东京城的高程㊁坡度㊁坡向进行分析(见图１１㊁图１２)ꎬ可以看出东京城区域内地势中间高㊁四周平坦ꎬ但从高程分析图来看ꎬ其高度相较于赫图阿拉城和佛阿拉城并不算高ꎬ因此ꎬ笔者认为东京城属于丘陵建城ꎬ而其宫殿则建在西南部的高台地上ꎬ由此可以看出努尔哈赤并没有完全摆脱择高而居的习惯ꎮ３.东京城遗址空间数据库未来的发展利用ＡｒｃＧＩＳ软件构建的东京城遗址空间数据库ꎬ可以为研究者提供东京城空间演变的真实信息ꎬ为大众提供东京城文化遗产的认知与普及教育ꎮ东京城遗址空间数据库最终要面向社会用户ꎬ因此它的设计需要满足社会各类人士保护㊁学习㊁研究等需求ꎬ在数据库建成之后还可以建设云ＧＩＳ数据平台以满足不同用户的使用需求[１８]ꎮ第３期郝㊀鸥等:基于ＧＩＳ的辽阳东京城遗址空间数据库设计探究２３９㊀图１１㊀东京城遗址区域高程分析图１２㊀东京城遗址区域坡向分析五㊁结㊀语文化遗产是城市的根基ꎬ是城市发展的基础ꎮ笔者从文化遗产的角度出发ꎬ基于ＡｒｃＧＩＳ软件构建东京城遗址空间数据库ꎬ完成了空间数据库概念模型㊁逻辑结构模型和物理模型设计ꎬ实现了对东京城研究资料的整理和分层存储ꎬ极大地提高了数据的利用效率ꎬ从而对东京城遗址的整体性布局有了清晰的认知ꎬ可以更好地界定古城的保护范围ꎬ为系统性的东京城研究提供科学依据ꎮ参考文献:[１]㊀周艳芳.空间数据库的概念及发展趋势探究[Ｊ].产业与科技论坛ꎬ２０１８ꎬ１７(２):５３－５４.[２]㊀王睛睛ꎬ刘伟ꎬ李旭祥ꎬ等.基于ＧＩＳ的西安市文化遗产空间数据库设计与实现[Ｊ].地理空间信息ꎬ２０１７ꎬ１５(１１):３９－４２.[３]㊀高任冠ꎬ魏坚.遥感与地理信息系统在城市考古中的实践[Ｊ].江汉考古ꎬ２０２０(４):１０２－２４０㊀㊀㊀㊀沈阳建筑大学学报(社会科学版)第２５卷１１１.[４]㊀康明娟.基于航测数据的环境考古数据库与三维可视化方法[Ｄ].石家庄:河北师范大学ꎬ２０１６.[５]㊀柳泽ꎬ毛锋ꎬ周文生ꎬ等.基于空间数据库的大遗址文化遗产保护[Ｊ].清华大学学报(自然科学版)ꎬ２０１０ꎬ５０(３):３３８－３４１. [６]㊀王禹浪ꎬ许盈.近３０年来清前期 关外三京 研究综述[Ｊ].黑河学院学报ꎬ２０１５ꎬ６(２):９０－１００.[７]㊀全晓红.东京城与东京陵[Ｍ].沈阳:辽宁民族出版社ꎬ２０１２.[８]㊀王佩环.关外三都[Ｍ].沈阳:沈阳出版社ꎬ２００４.[９]㊀李声能ꎬ陈伯超.盛京城:王城规划模式的范例:兼论汉文化对盛京城规划建设的影响[Ｊ].城市建筑ꎬ２０１０(８):１０６－１０８. [１０]张海.景观考古学:理论㊁方法与实践[Ｊ].南方文物ꎬ２０１０(４):８－１７.[１１]金鑫ꎬ董少春ꎬ王晓琪ꎬ等.基于ＡｒｃＧＩＳＧｅｏｄａｔａｂａｓｅ的浙江良渚古城遗址空间数据库的设计与实现[Ｊ].南京大学学报(自然科学)ꎬ２０１８ꎬ５４(１):１６３－１７５.[１２]张玉坤ꎬ徐凌玉ꎬ李严ꎬ等.空间人文视角下明长城文化遗产数据库建设及应用[Ｊ].古建园林技术ꎬ２０１９(２):７８－８３.[１３]王飒ꎬ沈欣荣.辽宁东部明代聚落研究回顾与评析[Ｊ].沈阳建筑大学学报(社会科学版)ꎬ２０１５ꎬ１７(５):４４６－４５１.[１４]卢岚ꎬ刘牛ꎬ刘兴权.京杭运河文化遗产保护数据库的设计[Ｊ].新型工业化ꎬ２０１６ꎬ６(４):２２－２６.[１５]陈欣.景德镇文化遗产保护数据库的建设与应用研究[Ｄ].北京:清华大学ꎬ２０１４. [１６]金琨智.遗产保护视角下东京城遗址公园景观设计研究[Ｄ].沈阳:沈阳建筑大学ꎬ２０２０. [１７]李声能.满族早期都城的空间特点分析[Ｊ].沈阳建筑大学学报(社会科学版)ꎬ２０１０ꎬ１２(３):２５７－２６３.[１８]吴洪桥ꎬ张新.云ＧＩＳ发展现状与趋势[Ｊ].国土资源信息化ꎬ２０１５(４):３－１１.ＤｅｓｉｇｎＡｎａｌｙｓｉｓｏｆＳｐａｔｉａｌＤａｔａｂａｓｅｉｎＬｉａｏｙａｎｇＤｏｎｇｊｉｎｇＣｉｔｙＳｉｔｅＢａｓｅｄｏｎＧＩＳＨＡＯＯｕ１ꎬＳＯＮＧＺｕｗｅｉ２(１.ＩｎｓｔｉｔｕｔｅｏｆＡｒｃｈｉｔｅｃｔｕｒｅꎬＳｈｅｎｙａｎｇＪｉａｎｚｈｕＵｎｉｖｅｒｓｉｔｙꎬＳｈｅｎｙａｎｇ１１０１６８ꎬＣｈｉｎａꎻ２.ＳｃｈｏｏｌｏｆＡｒｃｈｉｔｅｃｔｕｒｅａｎｄＵｒｂａｎＰｌａｎｎｉｎｇꎬＳｈｅｎｙａｎｇＪｉａｎｚｈｕＵｎｉｖｅｒｓｉｔｙꎬＳｈｅｎｙａｎｇ１１０１６８ꎬＣｈｉｎａ)Ａｂｓｔｒａｃｔ:Ｉｎｒｅｃｅｎｔｙｅａｒｓꎬｗｉｔｈｔｈｅｃｏｎｔｉｎｕｏｕｓｄｅｖｅｌｏｐｍｅｎｔｏｆｓｐａｔｉａｌｉｎｆｏｒｍａｔｉｏｎｔｅｃｈｎｏｌｏｇｙꎬｍｏｒｅａｎｄｍｏｒｅｓｃｈｏｌａｒｓｂｅｇａｎｔｏｃｏｍｂｉｎｅｉｔｗｉｔｈｔｈｅｆｉｅｌｄｏｆｃｕｌｔｕｒａｌｈｅｒｉｔａｇｅｐｒｏｔｅｃｔｉｏｎｔｏｒｅａｌｉｚｅｔｈｅｄｉｇｉｔａｌｒｅｓｅａｒｃｈｏｆｌａｎｄｓｃａｐｅａｒｃｈａｅｏｌｏｇｙ.ＩｎｔｈｉｓｐａｐｅｒꎬＬｉａｏｙａｎｇＤｏｎｇｊｉｎｇＣｉｔｙｉｓｓｅｌｅｃｔｅｄａｓｔｈｅｍａｉｎｒｅｓｅａｒｃｈｏｂｊｅｃｔ.ＴｈｒｏｕｇｈｆｉｅｌｄｒｅｓｅａｒｃｈａｎｄｃｏｌｌｅｃｔｉｏｎｏｆｒｅｌｅｖａｎｔｄａｔａꎬｉｎｄｕｃｔｉｏｎａｎｄａｎａｌｙｓｉｓꎬｔｈｅｃｕｒｒｅｎｔｓｉｔｕａｔｉｏｎａｎｄｉｎｆｏｒｍａｔｉｏｎｏｆｈｉｓｔｏｒｉｃａｌａｎｄｃｕｌｔｕｒａｌｈｅｒｉｔａｇｅｏｆＤｏｎｇｊｉｎｇＣｉｔｙａｒｅｕｎｄｅｒｓｔｏｏｄ.ＷｉｔｈＡｒｃｇｉｓａｓｔｈｅｔｅｃｈｎｉｃａｌｓｕｐｐｏｒｔꎬｔｈｅｇｅｏｇｒａｐｈｉｃｉｎｆｏｒｍａｔｉｏｎꎬｒｅｌｅｖａｎｔｈｉｓｔｏｒｉｃａｌｃｕｌｔｕｒｅａｎｄｈｅｒｉｔａｇｅｄａｔａｏｆＤｏｎｇｊｉｎｇＣｉｔｙａｒｅｉｎｔｅｇｒａｔｅｄａｎｄａｓｉｔｅｓｐａｔｉａｌｄａｔａｂａｓｅｉｓｅｓｔａｂｌｉｓｈｅｄｔｏｆａｃｉｌｉｔａｔｅｔｈｅｃｈａｎｇｅｏｆｔｈｅｇｅｏｇｒａｐｈｉｃａｌｐａｔｔｅｒｎｏｆｔｈｅａｎｃｉｅｎｔｃｉｔｙ.ＴｈｅｒｅｉｓａｃｌｅａｒｅｒｕｎｄｅｒｓｔａｎｄｉｎｇｏｆｔｈｅｈｉｓｔｏｒｉｃａｌｅｖｏｌｕｔｉｏｎａｎｄｔｈｅｏｖｅｒａｌｌｓｐａｔｉａｌｌａｙｏｕｔｏｆｔｈｅｒｅｌａｔｅｄｒｅｌｉｃｓꎬａｎｄａｍｏｒｅａｃｃｕｒａｔｅｄｅｆｉｎｉｔｉｏｎｏｆｔｈｅｐｒｏｔｅｃｔｉｏｎｓｃｏｐｅｏｆｔｈｅａｎｃｉｅｎｔｃｉｔｙꎬｐｒｏｖｉｄｉｎｇｓｃｉｅｎｔｉｆｉｃｂａｓｉｓａｎｄｔｅｃｈｎｉｃａｌｓｕｐｐｏｒｔｆｏｒｔｈｅｓｙｓｔｅｍａｔｉｃｓｔｕｄｙｏｆＤｏｎｇｊｉｎｇＣｉｔｙ.Ｋｅｙｗｏｒｄｓ:ＬｉａｏｙａｎｇＤｏｎｇｊｉｎｇＣｉｔｙꎻｓｐａｔｉａｌｄａｔａｂａｓｅꎻａｎｃｉｅｎｔｃｉｔｙｓｉｔｅｓꎻＧＩＳꎻｃｕｌｔｕｒａｌｈｅｒｉｔａｇｅ(责任编辑:高㊀旭㊀英文审校:林㊀昊)。

如何对表中数据的修改做历史记录现在有⼀张表User⾥⾯字段如下UserID ⽤户帐号(唯⼀不可修改)UserName ⽤户名Phone ⼿机号Email 邮箱CreateTime 创建时间UpdateTime 更新时间⽐较low的⽅式是建⽴⼀个记录表User_Record同样包含以上字段，每次修改插⼊⼀条修改之前的记录，这样有两个弊端1.数据冗余，及时⾄修改了⼀个字段也要插⼊⼀整条记录2.不利于扩展，如果主表新增字段，记录表User_Record也要相应增加，违背了DRY原则所以，在此提出⼀个相对优秀的解决⽅案新建⼀个UpdateEvent表，有如下字段EVENT_ID ⾃增IDVERSION 版本号OBJECT_TYPE 源数据的表名或者能唯⼀对应的源数据表的标识均可(可以看到此表⽀持多表进⾏扩展)当然，也可根据业务需求⾃⾏定义类别OBJECT_ID 源数据表主键FIELD_NAME 修改的源数据表的字段名OBJECT_CODE 源数据表主键对应的CODE(可以忽略)FIELD_OLD_VALUE 该字段原来的值FIELD_NEW_VALUE 该字段最新的值每次我们进⾏更新操作的时候，⾸先获取修改之前的实体oldUser和修改之后的newUser然后通过反射进⾏两个版本的⽐较,获得AuditData列表插⼊到数据库public class AuditData{public string EVENT_ID {get;set;}public string VERSION {get;set;}public string OBJECT_TYPE {get;set;}public string OBJECT_ID {get;set;}public string OBJECT_CODE {get;set;}public string FIELD_NAME {get;set;}public string FIELD_OLD_VALUE {get;set;}。

【转】mysql分库分表,数据库分库分表思路原⽂：同类参考：⼀. 数据切分关系型数据库本⾝⽐较容易成为系统瓶颈，单机存储容量、连接数、处理能⼒都有限。

当单表的数据量达到1000W或100G以后，由于查询维度较多，即使添加从库、优化索引，做很多操作时性能仍下降严重。

此时就要考虑对其进⾏切分了，切分的⽬的就在于减少数据库的负担，缩短查询时间。

数据库分布式核⼼内容⽆⾮就是数据切分（Sharding），以及切分后对数据的定位、整合。

数据切分就是将数据分散存储到多个数据库中，使得单⼀数据库中的数据量变⼩，通过扩充主机的数量缓解单⼀数据库的性能问题，从⽽达到提升数据库操作性能的⽬的。

数据切分根据其切分类型，可以分为两种⽅式：垂直（纵向）切分和⽔平（横向）切分1、垂直（纵向）切分垂直切分常见有垂直分库和垂直分表两种。

垂直分库就是根据业务耦合性，将关联度低的不同表存储在不同的数据库。

做法与⼤系统拆分为多个⼩系统类似，按业务分类进⾏独⽴划分。

与"微服务治理"的做法相似，每个微服务使⽤单独的⼀个数据库。

如图：垂直分表是基于数据库中的"列"进⾏，某个表字段较多，可以新建⼀张扩展表，将不经常⽤或字段长度较⼤的字段拆分出去到扩展表中。

在字段很多的情况下（例如⼀个⼤表有100多个字段），通过"⼤表拆⼩表"，更便于开发与维护，也能避免跨页问题，MySQL底层是通过数据页存储的，⼀条记录占⽤空间过⼤会导致跨页，造成额外的性能开销。

另外数据库以⾏为单位将数据加载到内存中，这样表中字段长度较短且访问频率较⾼，内存能加载更多的数据，命中率更⾼，减少了磁盘IO，从⽽提升了数据库性能。

垂直切分的优点：解决业务系统层⾯的耦合，业务清晰与微服务的治理类似，也能对不同业务的数据进⾏分级管理、维护、监控、扩展等⾼并发场景下，垂直切分⼀定程度的提升IO、数据库连接数、单机硬件资源的瓶颈缺点：部分表⽆法join，只能通过接⼝聚合⽅式解决，提升了开发的复杂度分布式事务处理复杂依然存在单表数据量过⼤的问题（需要⽔平切分）2、⽔平（横向）切分当⼀个应⽤难以再细粒度的垂直切分，或切分后数据量⾏数巨⼤，存在单库读写、存储性能瓶颈，这时候就需要进⾏⽔平切分了。

数据库管理的数据追溯与溯源方法引言在大数据时代，数据库管理已经成为了一个重要的课题。

随着数据量的增加，我们需要确保数据的可靠性和可追溯性。

因此，数据库管理的数据追溯和溯源方法变得尤为重要。

本文将讨论数据追溯与溯源的概念、方法和应用。

一、数据追溯与溯源的概念数据追溯的概念数据追溯是指能够追踪数据的来源、变更和操作过程，以便发现数据异常、数据泄漏或数据错误的过程。

通过数据追溯，我们可以准确了解数据的产生和流动路径，从而提高数据管理的效率和质量。

数据溯源的概念数据溯源是指追溯数据的历史变更记录，以便恢复数据的前后状态和探究数据的变更原因。

通过数据溯源，我们可以重建数据的演化过程，识别数据的错误来源，并进行数据的恢复和修复。

二、数据追溯与溯源的方法数据追溯的方法数据追溯的方法包括日志记录和审计跟踪。

日志记录是记录数据库操作的详细信息，包括操作时间、操作人员、操作内容等，可以通过记录日志来追踪数据的变更过程。

审计跟踪是对数据库操作进行监控和审计，可以及时发现异常操作并追踪操作的来源。

数据溯源的方法数据溯源的方法主要包括版本控制和恢复机制。

版本控制是为每个数据记录保留历史版本，通过比较不同版本的数据记录来追溯数据的变更历史。

恢复机制是在数据发生错误或破坏时，利用备份或数据快照来恢复数据到先前的正确状态。

三、数据追溯与溯源的应用数据追溯的应用数据追溯可以应用于食品安全、医疗和金融等领域。

在食品安全中，通过追溯食品的原产地、加工过程和分销路径，可以对食品进行全程监控和溯源，确保食品的安全性。

在医疗领域，数据追溯可以用于医疗记录的管理和患者信息的保护，以及疾病的溯源和治疗效果的评估。

在金融领域，数据追溯可以应用于交易记录的追踪和证据的保全，以提高金融交易的可信度和安全性。

数据溯源的应用数据溯源可以应用于软件开发、科学研究和刑侦调查等领域。

在软件开发中，数据溯源可以用于代码的版本控制和故障定位，以提高软件的可靠性和可维护性。

数据库管理的数据追溯与溯源方法第一节：介绍数据库管理的重要性和挑战在当今数据爆炸的时代，数据库管理扮演着至关重要的角色。

企业、政府和组织依赖数据库来存储和管理大量的数据，这些数据包含着重要的信息和价值。

然而，随着数据的不断增长和多样化，数据库管理带来了一系列的挑战。

其中一个重要的挑战是数据追溯和溯源。

本文将探讨数据库管理中的数据追溯与溯源方法。

第二节：数据追溯的含义及意义数据追溯是指追踪数据的变更历史和来源。

在数据库中，数据经常被更新、删除和修改，对于一些重要的信息和敏感的数据来说，需要确保数据的可信度和完整性。

数据追溯可以帮助我们了解数据的变更历史和操作记录，从而更好地管理和保护数据。

此外，数据追溯也对于审计、法律合规和安全性非常重要。

第三节：常见的数据追溯方法1. 数据记录和变更历史数据库中的数据记录对于数据追溯至关重要。

通过记录数据的变更历史，可以追踪到数据的来源和修改记录。

数据库中的日志记录功能是常用的数据追溯方法之一。

管理员可以通过查看和分析数据库的日志来了解数据的变更情况。

2. 数据版本控制数据版本控制是一种常见的数据追溯方法。

通过为每个数据版本分配一个唯一的标识符，可以跟踪数据的历史版本。

当数据发生更新或修改时，可以创建一个新的版本，这样就可以追踪到每个数据版本的来源和修改记录。

3. 数据备份和还原数据备份和还原是常用的数据追溯方法之一。

通过定期备份数据库，在数据出现问题或数据损坏时可以还原到之前的版本。

这样可以追溯到数据的历史状态，并且可以防止数据的永久丢失。

第四节：数据溯源的含义及意义数据溯源是指反向追踪数据的来源和流向。

有时候，在数据库中的数据可能出现异常或错误，需要找到数据的源头以及数据的流动情况，这就需要进行数据溯源。

数据溯源可以帮助我们定位数据问题的原因，并采取相应的措施来解决问题。

第五节：常见的数据溯源方法1. 数据流分析数据流分析是一种常见的数据溯源方法。

通过分析数据的流动路径，可以追踪到数据的来源和流向。

痕迹管理简介痕迹管理是一种重要的技术和工具，它用于记录和管理个体或系统在操作过程中留下的痕迹。

痕迹可以是日志、历史记录或其他形式的数据，可以用来审计、检测和调查操作的合规性、安全性和准确性。

痕迹管理在各个领域中都有广泛的应用，包括计算机科学、信息安全、法律和金融等。

痕迹的意义痕迹记录可以提供重要的信息和证据，帮助我们追溯和还原操作的全过程。

它可以用于：1.审计和合规性：痕迹记录可以被用来审查操作是否符合规定的流程和政策。

它可以帮助公司、政府和组织监督和管理内部操作的合规性，确保操作的安全、准确和可追溯。

2.安全和风险管理：通过对痕迹的分析和监控，可以发现潜在的安全漏洞和风险。

痕迹管理可以帮助我们检测和阻止未经授权的访问和操作，以及及时发现和应对安全事件。

3.故障排查和问题解决：当系统或应用出现故障或问题时，痕迹记录可以提供有关操作过程和环境的信息，帮助我们追踪和定位问题的根本原因，从而加快故障排查和问题解决的速度。

4.法律和法规遵从：在一些特定的行业和领域中，痕迹管理是强制性的要求。

例如，金融行业需要按照法律法规对交易和操作进行记录和管理，以确保交易的合法性和透明度。

痕迹管理的方法和工具为了实现有效的痕迹管理，我们可以使用以下方法和工具：1.日志记录：日志是一种常见的痕迹记录方式，它记录了系统或应用在运行过程中产生的事件和信息。

日志可以包括各种级别的详细信息，例如错误日志、访问日志和调试日志等。

通过分析和监控日志，我们可以了解系统的运行状态、用户的操作和应用的行为。

2.历史记录：历史记录可以用来记录个体或系统的操作历史。

例如，版本控制系统可以记录代码的修改历史，数据库可以记录数据的变更历史。

历史记录可以帮助我们追踪和还原操作的顺序和内容。

3.监控和审计工具：监控和审计工具可以帮助我们实时地监测和审计系统的操作和行为。

这些工具可以自动收集和分析痕迹数据，并相应的报告和告警。

4.数据分析和挖掘：通过对痕迹数据进行分析和挖掘，我们可以发现隐藏的模式和异常，提取有用的信息和洞察。

产品过往历史数据库管理程序（IATF16949-2016/ISO9001-2015）1.0目的建立产品过往历史经验库，作为产品及工装模具设计输入参考依据，有效防止同类问题再发及提升设计效率。

2.0范围本规定适用于过去质量问题（过去质量问题数据的建立、维护、存档管理及所有产品的设计变更履历管理。

3.0术语质量信息：产品和管理过程的质量统计信息以及产品在研发、生产、试验和使用过程中发生的不满足规定要求的个别问题。

历史数据库：针对所有过程中的质量统计信息纳入不良质量信息进行收集、分析统计处理的存档管理。

4.0职责4.1质量部质量工程师负责公司所有质量问题数据库的的建立、维护、存档。

4.2生产部负责设备、模具过程不良纳入不良过往经验库的建立、维护、存档。

4.3各技术工程师、质量工程师：根据质量部/生产部发出的质量信息单，组织分析确认根本原因，制定纠正/预防措施，并对效果进行跟踪验证，纳入过去问题数据，并定期向质量部传递存档。

5.0程序5.1信息来源5.1.1市场反馈质量信息，主要通过三包退货、索赔渠道整理。

5.1.2客户端不良质量信息，指主机厂/整车厂发生质量问题。

5.1.3内部不良质量信息，指在生产过程中，由于设备、工装、工艺、材料、环境和检测等方面的因素，造成产品的不合格的相关质量问题。

5.1.4采购件不良质量信息，主要指：5.1.4.1进货检验中，发现采购产品不符合规定质量要求的情况。

5.1.4.2生产过程中，因采购产品质量造成加工和装配产品的不合格。

5.1.5工装模具信息，在零件加工过程中出现的由于工装模具设计原因导致的质量问题。

5.1.6材料信息，同类产品的选材导致质量问题或质量不稳定。

5.2过去问题质量信息的收集5.2.1对市场索赔质量信息，质量部三包索赔整理后，分析出异常问题、重大问题，传递至相关责任单位。

5.2.2对售后不良质量信息，质量部在接到主机厂/整车厂的质量消息后，传递至生产部、相关责任单位。

2013年变更调查常见问题分析二〇一四年四月●本文档收集整理了2013年现状阶段更新上报中典型报错的处理方法。

文档仍在持续更新中，如有疏漏之处欢迎指正！一、注意事项1、由于复制粘贴区导致增量成果不能导入到质检中大多数作业单位的临时用地、当年验收非当年变更信息层中的范围都是经过平台的复制粘贴区完成，做完复制粘贴区之后一定要通过GDB企业管理器将该层转为6x数据，删除该HDF中的原图层，再通过GDB企业管理器将6x数据转成k9，去掉后缀“.wp”、“.wl”使其与删掉的图层名保持一致，再设置该图层的空间参考系。

如不进行上述步骤在后续属性维护和导出增量时会出现问题。

二、电脑环境问题1、数据检查不能创建数据库【报错举例】：数据检查时提示“不能创建数据库”。

【修改建议】：从其他好的电脑上拷贝C:\Program Files\Common Files\System\ado文件夹，然后使用“regsvr32 ”命令注册所有.dll动态库即可(否则出现增量报表输出不能取到年初值问题)。

三、增量数据包数据导入1、地类图斑更新层导入失败问题【报错举例】：【问题分析】：此类问题一般发生在数据库中存在以下几类情况下：（1）新增图层（“临时用地范围”、“当年验收非当年变更耕地信息”）图层空间参照系不正确情况；（2）数据库中标识码存在空值或0、要素代码为空、临时用地范围”、“当年验收非当年变更耕地信息”层的要素代码赋值不正确的情况；（3）更新过程层数据存在整条属性为空的记录情况下。

【修改建议】：请大家按照以下几种类型、逐一检查数据库，以上几类问题的处理方式分别为：（1）在地图文档上单个或修改图层空间参照系（坐标有带号数据请设置为北2的参照系）；（2）标识码存在空值或0、要素代码为空、要素代码赋值不正确后者与其他图层重复的情况，请将标识码进行补赋、或对要素代码进行赋值，如果是“临时用地范围”、“当年验收非当年变更耕地信息”两个图层，可利用“临时用地范围处理”、“当年验收非当年变更耕地信息处理”工具进行处理；（3）将新增图层导出成67数据后再导入K9数据（不能使用映射导入）即可。

数据库管理的数据追溯与溯源方法导言：数据库管理是现代信息技术领域的一项重要任务，数据库中的数据对于企业和组织来说十分宝贵。

然而，在庞大的数据库中进行数据追溯与溯源变得越来越困难，本文将探讨数据库管理中的数据追溯与溯源方法。

1. 数据追溯与溯源的概念数据追溯与溯源是指在数据库管理中，对于特定的数据进行回溯和溯源，了解其来源、产生过程和数据变更的相关信息。

通过数据追溯与溯源，可以提高数据的可靠性、可信度和可追溯性。

2. 数据备份与日志记录为了实现数据追溯与溯源，首先需要进行数据备份和日志记录。

数据库管理系统可以将数据周期性地备份到外部存储介质，以防止数据丢失或损坏。

此外，数据库管理系统还可以记录数据的修改、删除和插入操作，形成日志文件，以便后续查询和分析。

3. 版本控制版本控制是一种常用的数据追溯与溯源方法。

通过对数据进行版本管理，可以追踪和还原数据的历史状态。

在数据库中，可以使用时间戳或版本号等方式标记每次数据的修改，并保留每个版本的历史记录。

当数据发生错误或者出现问题时，可以通过版本控制还原到之前的某个版本，实现数据的追溯与溯源。

4. 数据差异分析数据差异分析是一种通过对比不同版本的数据，找出数据的差异和变化的方法。

通过数据差异分析，可以定位数据的修改和变更，并了解数据的追溯和溯源信息。

数据差异分析可以通过比较字段值、数据结构和数据量等指标来进行，从而找出不同版本之间的差异点。

5. 数据查询与索引优化为了支持数据追溯与溯源，数据库管理系统需要提供高效的查询功能。

在大规模的数据库中，通过优化查询和索引结构，可以大幅提升查询性能和效率。

利用数据库的查询语言和索引优化技术，可以快速定位和查询相关数据，实现数据的可追溯性。

6. 数据安全与权限控制数据追溯与溯源需要保证数据的安全性和完整性。

在数据库管理中，可以通过权限控制和数据加密等方式来保护数据的安全，防止未经授权的访问和篡改。

同时，还可以建立严格的数据审计机制，记录和监控对数据的操作，以满足数据追溯和溯源的需求。

NC系统操作注意事项及解决办法开关账检查未通过：组织启用日期为空：原因：相关业务单元未设置会计期间，设置方法：业务单元——辅助功能——业务期初期间物料委托优先级：物料档案先分配组织才能指定采购类型，指定采购类型时一旦指定了采购组织，那么在采购业务委托关系中再次指定其他采购组织将不会生效集采控制三种方式：1.物料指定采购组织，2.采购业务委托关系指定采购组织，3.集采控制指定采购组织采购订单付款计划：生产付款单是会提示“参数‘采购订单和合同付款是否需做付款申请’值为否，不能生成付款申请”企业建模平台——流程管理——交易类型管理和业务定义必须一致，即：交易类型管理中如果勾选到货，那么与之相关的业务流定义中必须生成到货单，否则业务将无法继续进行。

财务核算账簿：如果其中的存货账簿没有启用，需要在该财务组织下结算的物料无法进行结算，先启用存货核算账簿然后在权限中重新分配成本域。

收款单/付款单审核问题：AR01,应收科目,0001A910000000001NC6formula is matchview("AR01","应收科目","0001A910000000001NC6"企业建模平台—会计平台—转换模板-业务单元：选择出错的组织查看会计科目公式是否为空如果为空去企业建模平台—会计平台—分类定义-业务单元节点定义相应组织的应收会计科目内部结算规则：设置每种或每类物料的结算规则材料出库单：出库类型在交易类型—库存材料出库单中设置（影响现存量，影响成本打勾）成品对象设置方法：物料—生产信息—修改-成本对象成本计算：先设置会计期间在财务会计—存货核算—月末结账中设置期间批量调计价方式：财务会计—存货核算—计价方式调整当月未计算成本或是当月已结算才能调整暂估导致金额不正确：财务会计—存货核算—入/出库调整单价格审批询历史价：参照请购单生产价格审批单时，询历史价可在单据转换规则中赋值为true。

云南大学软件工程硕士《信息系统集成》课程考试试卷一、名词解释题(本类题共10题，每小题2分，共20分)1. 信息系统2. 体系结构3. B/S模式4. DNS5. 信息系统集成6. 数据集成7. 数据共享8. 接口集成9. 数据仓库技术10. J2EE1、信息系统是用信息化手段将业务逻辑固化的，是人、设备、应用软件、操作环境、业务流程的集合体。

信息系统是管理理念、整合实施水平的体现。

信息系统是由计算机硬件、网络和通讯设备、计算机软件、信息资源、信息用户和规章制度组成的以处理信息流为目的的人机一体化系统。

2、体系结构，指信息系统的每个组成部分之间的相互关系，包括：层次、拓朴结构、布局、接口、边界等；组成部分包括：硬件、软件、数据、操作规程、文档、参与的人员等。

3、B/S（Browser/Server，浏览器/服务器）模式又称B/S结构。

它是随着Internet技术的兴起，对C/S模式应用的扩展。

在这种结构下，用户工作界面是通过IE浏览器来实现的。

B/S 模式最大的好处是运行维护比较简便，能实现不同的人员，从不同的地点，以不同的接入方式（比如LAN, W AN, Internet/Intranet等）访问和操作共同的数据；最大的缺点是对企业外网环境依赖性太强，由于各种原因引起企业外网中断都会造成系统瘫痪。

4、DNS 是域名系统(Domain Name System) 的缩写，它是由解析器和域名服务器组成的。

域名服务器是指保存有该网络中所有主机的域名和对应IP地址，并具有将域名转换为IP地址功能的服务器。

将域名映射为IP地址的过程就称为“域名解析”。

域名解析需要由专门的域名解析服务器来完成，DNS就是进行域名解析的服务器。

DNS 命名用于Internet 等TCP/IP 网络中，通过用户友好的名称查找计算机和服务。

当用户在应用程序中输入DNS 名称时，DNS 服务可以将此名称解析为与之相关的其他信息，如IP 地址。

数据库操作记录日志
数据库操作记录日志是一种记录数据库操作的行为和变化的过程。

通过记录这些变化，可以有效地追踪并检索历史数据和信息。

以下是一些数据库常见的操作记录日志的方法：
1. 事务日志（Transaction Log）：事务日志是记录数据库中所有事务的操作过程的一种机制。

每个事务的所有操作都被记录下来，以便需要时可以恢复数据库。

2. 数据库日志（Database Log）：数据库日志是记录数据库所有修改操作的一种记录方式。

它包含了所有对数据库的更新、删除或插入等操作，包括对表、行和字段的修改。

3. 命令日志（Command Log）：命令日志是记录数据库执行的SQL命令的一种记录方式。

它可以用来检查执行的SQL语句是否正确，以及跟踪数据库执行的所有操作。

4. 连接日志（Connection Log）：连接日志是记录数据库用户连接和断开的一种记录方式。

它可以用来检查谁访问数据库，以及谁占用了数据库的连接资源。

5. 慢查询日志（Slow Query Log）：慢查询日志是记录数据库慢查询的一种记录方式。

慢查询通常指执行时间超过设定阈值的查询语句，通过记录这些查询可以帮助优化数据库性能。

记录数据库操作的日志是数据库管理的一个重要环节，可以帮助管理员追踪历史数据和信息，并及时发现和处理问题。

数据追溯与审计是数据库管理中重要且必不可少的环节。

随着数据的增长和应用的复杂性，数据追溯和审计在确保数据质量和合规性方面起着关键的作用。

本文将从数据追溯和审计的定义、重要性以及实施方法等方面进行论述。

一、数据追溯与审计的定义数据追溯是指通过记录和跟踪数据的来源、变更和使用等信息，以实现对数据的可追溯性的过程。

而数据审计则是对数据进行全面检查和评估，以确保数据的完整性、安全性和合规性。

数据追溯与审计不仅仅是一种技术手段，更是一种管理理念。

它可以帮助企业和组织了解数据的使用情况，及时发现和纠正数据错误和滥用行为，从而提高数据的价值和可信度。

二、数据追溯与审计的重要性1. 数据质量保障：数据追溯与审计可以通过追踪数据的来源，并及时发现和纠正源数据的错误，确保数据的准确性和一致性。

这对于企业和组织来说尤为重要，因为基于错误或不一致的数据做出的决策或分析结果往往是不可靠的。

2. 合规性要求满足：许多行业和领域存在严格的合规要求，涉及到敏感信息和隐私的数据使用更是需要审慎处理。

数据追溯与审计可以帮助企业和组织建立合规性的数据处理流程，并且对数据使用进行监控和审核，确保数据的合法使用，避免违反法规或道德准则。

3. 问题溯源与纠错：当数据出现问题或错误时，数据追溯与审计可以通过追溯数据的变更历史和使用情况，帮助快速定位问题的根源并进行纠错。

这对于数据管理和故障排查来说非常重要，可以缩短故障修复的时间，提高数据的可靠性和稳定性。

三、实施数据追溯与审计的方法1. 记录和跟踪数据变更：数据库管理系统可以通过记录数据的变更历史和数据访问日志，实现对数据变更的追踪。

管理员可以根据需要对数据变更进行审计，发现潜在的问题和滥用行为。

2. 引入审计规则和策略：通过引入审计规则和策略，可以对数据的使用行为进行监控和评估。

例如，制定访问权限规则，限制特定用户对敏感数据的访问；建立审计规则，对数据的读写行为进行监控和记录。

3. 数据备份和恢复：定期进行数据备份，并建立完备的数据恢复策略，可以确保数据在发生意外情况时能够及时恢复到之前的状态。

数据库设计参考标准数据库设计参考标准文档控制文档属性文档修订历史[1]数据库设计参考标准一、概述为明确公司项目中数据库逻辑设计及物理设计的内容和流程，特制定本规范，供数据库设计、开发及维护人员参考。

数据库设计方法目前可分为四类：直观设计法、规范设计法、计算机辅助设计法和自动化设计法。

新奥尔良法是目前公认的比较完整和权威的一种规范设计法。

新奥尔良法将数据库设计分成需求分析（分析用户需求）、概念设计（信息分析和定义)、逻辑设计(设计实现)和物理设计（物理数据库设计）。

目前，常用的规范设计方法大多起源于新奥尔良法,并在设计的每一阶段采用一些辅助方法来具体实现.以下是两种常用的规范设计方法：1. 基于E—R模型的数据库设计方法。

该方法是由P.P。

S。

chen于1976年提出的数据库设计方法，其基本思想是在需求分析的基础上，用E-R（实体—联系）图构造一个反映现实世界实体之间联系的企业模式，然后再将此企业模式转换成基于某一特定的DBMS的概念模式。

2. 基于3NF的数据库设计方法。

该方法是由S·Atre提出的结构化设计方法，其基本思想是在需求分析的基础上,确定数据库模式中的全部属性和属性间的依赖关系，将它们组织在一个单一的关系模式中，然后再分析模式中不符合3NF的约束条件，将其进行投影分解，规范成若干个3NF关系模式的集合。

其具体设计步骤分为五个阶段：（1）设计企业模式，利用规范化得到的3NF关系模式画出企业模式；（2）设计数据库的概念模式，把企业模式转换成DBMS所能接受的概念模式,并根据概念模式导出各个应用的外模式；（3）设计数据库的物理模式(存储模式）；（4）对物理模式进行评价；（5）实现数据库。

备注：数据库设计规范、数据编程规范、数据库物理设计规范中以Oracle 数据库为例，其它结构的数据库类似.二、数据库设计流程[2]数据库设计参考标准以规范性设计为例，把数据库设计流程分为以下几个阶段.(一) 需求分析阶段1. 需求收集和分析，得到数据字典描述的数据需求和数据流图描述的处理需求。