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