下载文档原格式
做数据库实验的心得体会做数据库实验的心得体会范文（通用13篇）当我们经过反思，对生活有了新的看法时，心得体会是很好的记录方式，这样我们就可以提高对思维的训练。
但是心得体会有什么要求呢？下面是小编精心整理的做数据库实验的心得体会范文，希望能够帮助到大家。
做数据库实验的心得体会篇1持续一个月的数据库实训，让我参与了软件工程化的开发过程。
其中体会最深的便是我们这个实训网的几个之最：一、项目最大：项目大是因为我们这个事业起点网站涉及到用户众多—高校，企业，学生，老师，专家，第二个原因是网站的功能多—用户管理，网上实习，网上竞赛，毕业实习设计，项目管理，人才库管理，人才推荐，搜索。
项目大很容易造成系统范围的泛滥，在我们的开发初期，由于需求不太明确，功能实现没有重点，造成了需求范围的扩大，给项目开发进度造成了严重的滞后性。
然后我们召开了会议讨论了这个问题，一致认同先把项目的基本功能实现，将网站的基本架构搭建起来，最后再在这个基础上继续增加我们网站的其他功能。
因此在这个过程中，我深刻体会到了软件工程初期阶段的需求分析以及概要设计的重要性，这两个文档是指导我们后期开发的最重要的依据。
二、数据库表最多：如此庞大的系统，就需要庞大的数据库来支持，所以项目大的直接后果就是我们的数据库表特别多，而且表与表之间的依赖关系也复杂，实体类之间的关系众多，设计起来有一定的难度。
数据库的另外一个问题是—数据表的属性，数据表属性的设计完全是依赖于我们刚开始做的需求分析文档，如果需求分析不完整的话，就会造成数据库表属性的缺失，从用户的角度看，就会觉得你的系统提供的数据不够全面，信息量小。
三、开发团队最大：我们团队一共有十四个人，这个对于我们的项目经理来说，是一个相当严峻的问题，毕竟十四个人的团队相当于其他几个小组加起来的人数总和，管理起来有相当大的难度。
对于我们这些小组成员来说，由于沟通渠道太多，造成了我们项目中遇到问题，不知道去跟哪个小组成员沟通。
数据库实训总结和体会数据库实训总结和体会，学习完了数据库有什么总结呢?下面是带来的数据库实训总结和体会，欢迎阅读!数据库实训总结和体会在这个学期的后几周，我参加了数据库的工程实训。
这是我第一次系统地，完整的接触软件设计的全过程。
我的设计的题目是“VC基于SQL-SERVER的企业合同管理系统”。
在这次课程设计中，我的能力得到了锻炼，自己也有许多体会。
这次的工程实训是自己第一次全面接触软件的制作过程。
以前仅仅是对软件的开发有一个大体的印象，通过这次的工程实训，我对软件的开发有了切身的体会。
软件并不像我原来所想的那样十分神秘，而是有着一个相对固定的模式和流程。
我们只要按照这个模式和流程，就能够比较规范的完成一个软件的制作。
软件的制作是一个系统的工程，需要我们掌握多方面的知识。
在这次工程实训中，我觉得自己的知识面还是有欠缺的。
需要在以后的学习工作中加以注意，要全面的提高自己的知识面与知识层次。
在编程的过程中，我体会到编程是十分辛苦的。
在工程实训这一段时间里，我每天的生活基本是在不断的调试程序和修改代码中完成的。
有时，这种生活令人感到乏味和疲倦，但是在这种近似枯燥的生活中，我的编程水平有了一定程度的提高，这是工程实训中我最大的收获。
以前学习计算机语言，总是静不下心来，不能认真的看书。
这次工程实训，为了顺利的完成编程工作，我认真的学习了VC语言和数据库知识，并有了一定的心得体会。
所以在以后的工作学习中，自己全身心的投入，这样学习才会有效率，才会有效果。
工程实训已经结束了，但在工程实训的这些体会要应用到今后的工作生活中去。
在以后的工作生活中，我觉得自己要在以下几个方面加以注意:首先，在编程的时候要注意理论联系实际。
注意将课本上的知识应用到日常的操作中，真正做到学以致用。
只有这样，才能做到目的明确，才能有足够的学习动力。
其次，在工作过程中要经常与同事进行交流，讨论所遇到的问题，并一起解决。
在讨论中解决问题，会节约很多时间，并且在交流的过程中，我们也可以学到更多的东西。
数仓工作总结在过去的一年里，我有幸参与了公司的数仓工作，并且取得了一些成果。
在这篇文章中，我想对这一年的数仓工作进行总结，分享一些我所学到的经验和教训。
首先，我要感谢团队中的每一位成员。
在整个项目的过程中，大家都非常努力地工作，相互配合，共同克服了许多困难。
我们一起制定了项目的目标和计划，并且按照计划一步步地推进工作。
在这个过程中，我学会了如何有效地与团队成员合作，如何分配任务和管理时间，以及如何克服困难和挑战。
其次，我要提到在数仓工作中所遇到的一些技术挑战。
在整个项目的过程中，我们遇到了许多技术上的问题，比如数据清洗和整合、性能优化、数据质量保障等等。
通过不断地学习和尝试，我们最终找到了解决这些问题的方法，并且取得了一些令人满意的成果。
在这个过程中，我学会了如何利用各种工具和技术来解决问题，如何进行技术选型和优化，以及如何保证数据的准确性和完整性。
最后，我要提到在数仓工作中所取得的一些成果。
在整个项目的过程中，我们不断地改进和优化数仓的架构和流程，使其更加稳定和高效。
我们还建立了一套完善的数据质量管理体系，保证了数据的准确性和完整性。
最重要的是，我们成功地将数仓的数据应用到了业务中，为公司的决策和运营提供了有力的支持。
在这个过程中，我学会了如何将技术和业务结合起来，如何将数据转化为价值，以及如何与业务部门进行有效的沟通和合作。
总的来说，这一年的数仓工作对我来说是非常宝贵的经验。
通过这个项目，我不仅学会了许多技术上的知识和技能，还学会了如何与团队合作、如何解决问题、以及如何将数据转化为价值。
我相信这些经验和教训将对我的未来职业发展产生积极的影响。
感谢这一年的数仓工作，让我收获了很多。
仓库数据员工作总结6篇第1篇示例：仓库数据员工作总结作为仓库数据员，我在过去一年中承担了数据记录、整理、分析等工作，对仓库业务有了更深入的了解，也积累了丰富的工作经验。
在这一年中，我所面对的工作挑战和解决方案，以及工作中的收获和反思，我将在下文中进行总结。
在过去的工作中，我需要负责对仓库进出货物的数据进行记录和整理。
每天都需要对进出货物进行记录，并将这些数据录入系统进行储存和管理。
对于大量的数据需要快速而准确的记录，这对我的工作速度和准确性提出了较高的要求。
在面对这一挑战的过程中，我通过不断练习和积累经验，提高了自己的工作效率和准确性，也熟练运用了相关的数据管理软件，提高了自己的工作技能。
在数据整理和分析方面，我需要对仓库的库存情况进行定期的整理和分析，以便管理人员能够及时了解库存情况，做出相应的调整和决策。
在这个过程中，我通过对数据进行综合分析，发现了仓库某些商品的库存过多或过少的情况，及时向管理人员汇报，有助于及时调整进货计划和库存管理，提高了仓库的运营效率和货物周转率。
在工作中，我还要负责对仓库其他相关工作的数据记录和整理，如货物损耗情况、库存盘点等。
对于这些工作，我需要严格按照操作规程进行记录和储存，以便在需要时能够进行查询和核对，对保障仓库的正常运营和管理起到了关键的作用。
在工作中，我发现自己在准确性和效率方面有了较大的进步，但在沟通和合作方面还需要继续努力。
在与同事的合作中，我有时会因为个人工作繁忙而无法及时与同事进行沟通和协作，带来了一些不必要的麻烦。
我意识到这一点后，我主动和同事沟通，协商合作方式，希望能够更好地协作，提高工作效率。
在未来的工作中，我将继续努力提高沟通和协作能力，更好地与同事合作。
我也会继续加强对相关软件和技能的学习和提高，不断提升自己的工作水平。
我相信，在公司的培养和帮助下，我将能够更好地发挥自己的能力，为公司的发展做出更大的贡献。
第2篇示例：仓库数据员工作总结一、工作内容概述作为仓库数据员，主要负责仓库内货物的数据管理工作，包括货物的收发、入库、出库等环节的数据录入和管理。
dw学习心得在近年来，数据科学和人工智能的兴起，让数据仓库(DW)成为了企业中重要的系统之一。
DW以其能够提供高效、可靠、一致的数据支持，为企业决策提供了重要的依据。
作为一名数据科学家，我深刻认识到DW学习的重要性，并在学习过程中有了一些心得体会。
首先，对于DW的学习，我发现了其复杂性。
DW涉及到数据的抽取、转换、加载等多个环节，需要掌握各种数据处理技术和工具。
在理解这些知识点时，我通过查阅专业书籍和参加培训课程来提高自己的知识水平。
同时，通过实际操作和项目实践，我逐渐掌握了不同的DW技术和工具，并能够运用于实际的数据治理和决策分析中。
其次，DW学习过程中，数据质量的重要性也越发突出。
DW的数据源通常来自多个系统和部门，其中可能存在着数据不一致、缺失、冗余等问题。
为了保证DW的数据质量，我学习了数据清洗和数据质量管理的方法和技巧。
通过数据清洗和数据校验等步骤，我能够对数据进行有效的处理和筛选，从而保证DW中的数据准确、可信。
此外，DW学习还需要不断地关注行业发展的最新趋势和技术变革。
数据科学和人工智能领域，新的技术和工具层出不穷，而这些新技术往往能够为DW带来更高的性能和更广泛的应用。
因此，我通过参加行业会议、关注学术论文和技术博客等方式，及时了解并学习最新的DW技术，以保持自身的竞争力。
最后，我认识到与人交流和合作的重要性。
在DW学习过程中，我积极参加社区活动和行业研讨会，与其他从业者进行交流和学习。
通过与他人的分享和讨论，我不仅拓宽了自己的知识面，还了解到了不同企业和行业中DW的应用案例和实践经验。
此外，在实际项目中，我与数据架构师、数据工程师等专业人士积极合作，共同完成了一系列DW建设和优化的任务。
综上所述，DW的学习对于数据科学家来说至关重要。
通过学习和实践，我逐渐掌握了DW的核心技术和方法，并将其应用于实际的数据处理和决策分析中。
同时，我也认识到DW学习是一个不断迭代和更新的过程，需要关注最新的技术和行业发展趋势。
数据库学习心得4篇心得体会是一种产生感想之后写下的文字，主要作用是用来记录自己的所思所感，是一种读书和学习实践后所写的感受文字，以下是我整理的数据库学习心得4篇，仅供参考，大家一起来看看吧。
数据库学习心得篇3这学期我们学习了数据库应用教程这门课，以前并不知道这门课是干什么的，也不懂得什么是数据库，通过这一学期的学习，虽然了解的不是非常多，但也有了初步的一点认识。
我大概的明白数据库技术是处理信息，管理数据最有效的一种方法。
它具有完善的数据管理功能，还具有操作方便，简单实用等特点。
因为我是非计算机专业的学生，所以我学起来就感觉很难，在上第一堂课的时候，因为不了解，于是心里充满了对这门课的神秘感，在第一堂课上我听得很认真，我感觉它与其他的课程没有什么联系，不需要其它太多的知识，我想它可能是一门从头开始学的课，就没有太多的担忧，然而事实并不是我想的这样，随着时间的延长，我发现每一堂课都比前一堂课难，逐渐的我听得就越来越吃力，还好书上除了理论知识外还有很多例题和图片，这对我对知识的理解有很大的帮助。
同时老师每堂课都用详细的和书上相似的PPT，并且老师讲的非常细致，书上的每一个知识他都会仔细的给我们讲解，有时遇到比较难的问题他还会很耐心的讲解好几遍直到我们都明白了为止，有时候我们好多人都没有听，但只要有人听，他就会很认真的讲。
本书的第一章主要介绍数据库系统的基本概念，VFP的开发环境，项目管理器等知识，还记得上第一章时老师就告诉我们这一门课程对我们来说比较难学，也鼓励我们不要放弃，要慢慢的理解，老师总是态度很和蔼的与我们说话，更减少了我们对这一门课的恐惧感。
为了让我们更好的理解所学的知识，老师还为我们准备了与教学知识相关的实验内容，一般在每堂理论课后都会有实验课，所做的实验都是我们刚学的那些基本的，重点的知识。
这种理论与实验相结合的方式加深了我们对教材的理解。
刚开始做实验时，因为是初学，所以老师会把所有的步骤都写上，让我们照着做，先熟悉它的基本操作，再慢慢的理解，时间久了，老师就会省去一些简单的步骤，让我们自己练习。
仓库管理系统心得体会在参与仓库管理工作之前，我对于仓库管理的认知，大概就停留在“一个放东西的地方”这种简单又粗糙的层面。
然而，当真正深入其中，才发现这里面的学问，那可真是比我想象的要多得多。
我所接触的这个仓库，那可不是一般的大，各种货物琳琅满目，堆积如山。
刚开始的时候，我走进仓库，就像一只无头苍蝇，完全不知道从哪里下手。
东西到处乱放，找个东西简直就是大海捞针，别提多费劲了。
这时候，仓库管理系统就像一位救星一样出现了。
这个系统呀，一开始我觉得它可复杂了，那么多的按钮，那么多的数据输入框，看得我眼花缭乱。
但没办法，为了能把工作做好，我只能硬着头皮去学。
我记得有一次，我们接到了一个紧急的订单，需要马上找出一批特定的货物发出去。
按照以前的方式，那估计得找上半天。
但这次，我依靠着仓库管理系统，输入了货物的相关信息，系统马上就给我指出了货物所在的区域和货架位置。
我顺着系统的提示一路找过去，嘿，还真就很快找到了！那一刻，我心里那个激动呀，就像在黑暗中摸索了好久突然看到了光明。
在使用仓库管理系统的过程中，我还发现了它的一个特别实用的功能——库存预警。
这可真是帮了大忙了！以前，经常会出现货物短缺但我们却不知道的情况，导致订单延误，客户抱怨。
但有了这个预警功能，一旦某种货物的库存数量低于设定的警戒线，系统就会自动提醒我们。
有一回，一种热销的商品库存快要见底了，系统及时发出了警报。
我们赶紧联系供应商补货，这才避免了缺货的尴尬局面。
还有啊，这个系统对于货物的出入库记录那叫一个详细。
每一笔进出库的货物，什么时间，多少数量，由谁操作的，都记得清清楚楚。
这可给我们查账和盘点带来了极大的方便。
有一次月度盘点的时候，我原本以为会是一场噩梦，因为仓库里的货物实在是太多了。
但有了系统准确的记录，再加上实际的清点，整个盘点过程居然比我预想的要顺利得多。
不过，使用仓库管理系统也不是一帆风顺的。
比如说，有时候网络会突然卡顿，导致数据录入延迟，这可把我急得直跺脚。
学习数据库心得(精品5篇)学习数据库心得篇1学习数据库心得在这篇*中，我将分享我学习数据库的经历。
通过学习数据库，我不仅掌握了数据存储的基本原理，也学会了使用SQL语言进行数据查询和分析。
学习数据库的初衷：在当今数据驱动的时代，数据库作为存储和管理数据的重要工具，其重要性不言而喻。
我选择学习数据库，是因为我希望掌握一种可以持久化存储数据的方法，同时能够快速、高效地查询和分析数据。
学习过程：我选择了MySQL作为我的学习数据库。
在学习过程中，我首先学习了数据库的基本概念，如表、列、主键、外键等。
同时，我学习了SQL语言，包括SELECT、INSERT、UPDATE和DELETE等语句。
我通过实践编写简单的SQL查询，并不断修改和优化，从而加深了对数据库的理解。
学习心得：学习数据库的过程是充满挑战的，我遇到了许多问题。
其中最大的问题是理解数据库的设计原则，如关系型数据库的设计，如何根据需求设计出高效、安全、可扩展的数据库。
另外，SQL语言的学习也并非一蹴而就，我通过大量的练习，逐渐掌握了它的语法和用法。
总结：学习数据库让我掌握了数据存储和管理的基本技能，使我能够更好地应对实际工作中的各种数据问题。
我深刻理解到数据库设计的重要性，以及SQL 语言的灵活性和强大功能。
在未来，我将继续深入学习数据库，进一步优化我的数据库设计和查询能力。
学习数据库心得篇2探索数据库世界的奇妙旅程：我的学习心得自从我开始学习数据库以来，我对数据有了更深入的理解，也更加欣赏这个神奇的数据世界。
下面，我将分享我的学习心得，希望能激励更多的人走进数据库的世界，发现它的奇妙之处。
1.理解数据库的重要性学习数据库的第一步是理解它在现代社会中的重要性。
无论是个人还是企业，我们都在不断地收集、处理和使用数据。
数据库就像是一个数据仓库，帮助我们将这些信息有序地组织起来，让我们可以更快地查找、分析和理解数据。
2.掌握基本概念学习数据库需要掌握一些基本概念，如数据库管理系统（DBMS）、数据库模式、表、列、数据类型、索引等。
空间数据库实习心得在大学的学习生涯中，实习是一个非常重要的环节，它让我们能够将课堂上学到的理论知识应用到实际工作中，从而更深入地理解和掌握所学的专业知识。
我有幸参加了空间数据库的实习，在这个过程中，我不仅学到了专业技能，还获得了许多宝贵的经验和体会。
实习之初，我对空间数据库的概念还比较模糊，只知道它是一种用于存储和管理空间数据的数据库系统。
但随着实习的深入，我逐渐了解到空间数据库在地理信息系统、城市规划、交通管理等领域有着广泛的应用。
它能够有效地存储和处理各种空间数据，如点、线、面等几何对象，以及与之相关的属性数据。
在实习过程中，我首先接触到的是空间数据库的设计。
设计一个合理的空间数据库结构是至关重要的，它直接影响到数据的存储效率和查询性能。
我们需要根据实际的应用需求，分析数据的特点和关系，确定合适的数据模型和字段类型。
这需要我们对空间数据的概念和数据结构有深入的理解，同时还需要考虑数据的完整性、一致性和安全性等方面的问题。
在进行数据库设计时，我遇到了不少困难。
例如，如何合理地划分空间数据和属性数据，如何建立有效的索引以提高查询效率，如何处理空间数据的拓扑关系等。
为了解决这些问题，我查阅了大量的资料，请教了老师和同学，经过不断地尝试和改进，终于完成了数据库的设计。
通过这个过程，我不仅提高了自己的问题解决能力，还学会了如何团队合作和沟通。
接下来是数据的采集和录入。
空间数据的采集是一项繁琐而细致的工作，需要我们使用各种测量仪器和技术获取地理空间信息。
在实习中，我们使用了 GPS 定位仪、全站仪等设备进行实地测量，获取了一些建筑物、道路等的空间坐标。
同时，我们还从相关部门获取了一些电子地图和统计数据，作为补充和验证。
数据录入则需要我们将采集到的数据按照设计好的数据库结构进行整理和输入，这需要我们非常细心和耐心，以确保数据的准确性和完整性。
在数据采集和录入的过程中，我深刻体会到了实地工作的艰辛和重要性。
数据库心得体会6篇（经典版）编制人：__________________审核人：__________________审批人：__________________编制单位：__________________编制时间：____年____月____日序言下载提示：该文档是本店铺精心编制而成的，希望大家下载后，能够帮助大家解决实际问题。
文档下载后可定制修改，请根据实际需要进行调整和使用，谢谢!并且，本店铺为大家提供各种类型的经典范文，如工作报告、心得体会、计划方案、条据文书、合同协议、规章制度、演讲致辞、教学资料、作文大全、其他范文等等，想了解不同范文格式和写法，敬请关注!Download tips: This document is carefully compiled by this editor. I hope that after you download it, it can help you solve practical problems. The document can be customized and modified after downloading, please adjust and use it according to actual needs, thank you!Moreover, our store provides various types of classic sample essays for everyone, such as work reports, reflections, plans, policy documents, contract agreements, rules and regulations, speeches, teaching materials, essay summaries, other sample essays, and more. If you want to learn about different sample essay formats and writing methods, please stay tuned!数据库心得体会6篇写心得体会是我提升自我修养的重要方式，通过写心得体会，我们能够更好地认识自己，以下是本店铺精心为您推荐的数据库心得体会6篇，供大家参考。
Data warehouse 心得By jyzhang8 2004-6-17 msn：jyzhang8@ 一、为什么要推动data warehouse自然演化体系会带来很多的问题：1、数据可信性（两个部门提供的数据是不一样的，让管理者无所适从）；a、时间的基准不一；b、算法差异；（认知不一致）c、无公共的起始数据源要靠推动data warehouse使各部门之间对相同元素认知、定义和算法一致或者趋于一致；2、报表的生产率的问题；由于oltp的单项系统导致数据的分散性和相同元素定义不一致所致；3、 oltp的系统中无法保留很久的历史数据；单项系统之间保留的历史数据时间范围不一致；无法满足dss分析的需要；4、 oltp的单项系统中对维表的关键栏位的更改很少有记录；（如：客户的业务员的变更问题）5、面向应用的设计无法满足面向主题的分析的需求；oltp和dw对后台设计要求的重点不同，oltp主要在意的是update和insert，而dw主要在意的是select；6、因为决策的需求大多是“灵光一现”的，是“前无古人”，“后无来者”的，是启发式的，而非固定式的；7、分散的系统导致业务行为不可控，dw能够对各地的业务行为进行事后的监控；（如：产品代号，折让的问题）；8、 dw能够把user从复杂的统计工作中解放出来，从而提升企业的管理，让user有时间从事对企业更有益的事情。
还可以精简企业的人员；9、降低企业获取信息的费用；提高企业的决策速度，加快企业对市场的反应能力；10、没有dw，IT部门总是处在鞭梢的位置，总是在被动的响应状态；（因为主管感兴趣的事情总是不时的变化的）；11、可以透过dw来观察公司的新的政策或者新的行销活动给公司带来的变化；(事件映射)12、dw是EIS和数据挖掘的基础；二、推动以前IT人员要有的观念1、首先满足用户的需求，再在用户使用过程中去引导用户朝正确的方向走；2、老板看的投资回报；3、永远比user考虑的明细；因为管理是一步步精细的；4、 dw是反复才能建成的，所以dw的版本要不停的迭代开发；5、 olap 软件可以是dw的组成部分，但不是必选的，大多的olap的软件数据库是多维的，从dw中把资料刷新至多维的数据库中会比较慢，但对多维的数据库查询起来速度必二维的速度快的多；所以是要根据user 需求来进行合理的选择；6、前端的展现工具一定要有向上和向下钻取的功能；三、和老板沟通的观念1. dw不可能满足所有的需求，Data warehouse 项目同样需要界定边界；2. 同样的资料，角度不同（如财务，销售，市场，管理），结果就不一致，所以允许差异的存在，但差异要在可解释的范围内；通过定义不同的规则来玩这个游戏；3. 问题的关键不在工具的好坏，而在于资料的可信度，原始数据和业务行为的规范；4. 业务术语的定义和解释应由专门的单位来处理，从而保证集团自上至下的对术语定义的一致性；（如销售业务行为中“铺货率”的定义）5. 企业高层的支持非常重要；6. 公司内的oltp系统数据是动态的，总是在变的，所以dw中的数据也会随之变化，dw中昨天看到的数据和今天看到看到的不一样，不要大惊小怪；7. dw是用来做趋势分析、预测和提供数据挖掘的，对数据的要求不是非常精确，所以千万不要拿dw中的数据来计算sales的奖金；8. 集团上下对为什么要推动dw及dw的作用的认知一致是非常重要的；9. 最终用户专业化，要花很多的时间对end user进行培训，提高user的认知，最终的目标是user自己设计报表；当然是在前端，而不是在“厨房”(后台)中；10．软件选择宜横向联合，强强联手，不是一家的软件可以搞定一切的；四、dw设计模式和方法1．dw应建立在RDBMS(关系型数据库)中，而dm可以建立在一个RDBMS或者MDDB(多维数据库)中；2．dm采用星型设计是原则，雪花模型是可选的；3．dw的设计模式和oltp的设计模式不一样的，oltp的设计模式是以需求为驱动的，而dw的设计模式是以数据为驱动（分析处理为驱动）的；4．面向主题的设计，数据从操作型的环境流入dw中时，数据必须是集成的，而不仅仅是将数据扔到dw中；5．一次开发一个主题的原则；6．在dm中逆规范化的设计是必要的，以空间的冗余换取响应速度的加快；7．遵循给“用户想要的东西，然后用户才能告诉你需求是什么”的发现模式来开发，成功的关键在于结构设计人员和dss分析人员（user）之间的反馈循环, 迭代开发的模式；8．开发流程：首先应建立企业数据模型（描述企业的信息需求，明确了企业主要的主题域，不一定是企业已有的东西，不考虑任何的技术问题）→分解至中间层模型→定义记录系统（数据源的定义）→设计数据仓库→设计oltp与dw之间的接口；9．5％的dss处理的需求在原子层，95％的在概要层；（查询分离的设计）；10．从fact表开始设计，然后开始设计dimension表；维表的设计要逆规范化，事实表的设计要3nf；11．弹性的设计（建立规则库，通过规则解析引擎解释规则至最小的粒度的设计）12．资料可信度的设计；13．规则库和规则转换设计；14．各地的对相同的栏位定义不一致（如：有的地方用0和1表示男女，有的地方用m和f表示男女）没有关系，但dw中的定义要一致，通过清洗程式转换成dw中的规则；15．有限的使用的代理健；16．有限的使用外健来保证参照完整性；可以使用procedure检查；17． Slowly changing dimension（慢速变化维）表的处理：不要使用oltp系统中的business key（业务健）作为维表的primary key（主健），而使用代理健，当慢速变化维的关键栏位发生变化时，不要update原来的记录，而插入一条新的记录；这样能够dw不会出现错误而且可以跟踪维的历史；18．字段级映射（field level mapping）一定要建立;19．集团总部dw的资料可以回流至各分公司的数据库中，这样可以灵活的处理需求，一致的需求，总部处理，特殊需求，各地处理；20．dw中无论是fact table还是dimension table，强烈建议给每条记录加上时间戳；五、粒度的选择1、资料的粒度级别需要权衡，采用多重粒度的设计；在磁盘允许的情况下，建议尽可能的按最细粒度存储数据；因为dw中存储的粒度越细，dw回答问题的能力就越强；要先估算事实表的行数（一年内的最少行数和最多行数乘以字段长度）2、对于不活跃的数据可以分离（至磁带或者备份的磁盘上）；减轻dw刷新和管理的难度；3、dw的特性之一，表现为汇总数据还是细节数据是由观察者的不同角度决定的；六、dw的安全1、根据user的不同的权限看到的数据也不一样；2、数据库放在内网的是原则；3、通过profile限制并行的用户数；4、在brio server中限制帐号一个月不使用者封帐号（更改密码为当天的日期）；5、装载阶段限制ip和user登陆（通过trigger）；七、dw 性能增强方案和oracle的技术的运用1、可以使用的技术有：materialized view（物化视图），星型查询，专用大回退段, QUERY REWRITE(查询重写),partition table，organization index table（索引组织表），PARALLEL（并行）2、充分的index，建立必要的概要表（summary table），大表必须分区，query rewrite和mv均可大大提高dw的性能；3、小技巧：加载前drop一些index以提高加载的性能，加载完毕后重建index；还可以通过view来实现和简化查询重写；4、 oracle优化模式rbo和cbo的选择：建议尽量使用cbo；5、作为数据仓库的后台数据库，oracle的安装方式和init参数的是有别于oltp系统的后台的数据库；6、加载阶段和访问阶段采用不同的参数设置来启动db；7、访问阶段使db只读，减少db的本身的管理损耗；8、由于dw特性，不用在数据块上保留很多的自由空间用于以后的记录的更新和插入；9、修改os的参数，如：加大os的串行预读参数，异步io，甚至修改cpu的时间片；10、磁盘阵列的选择：条件允许的情况下建议raid01；八、规则库的定义和设计1、业绩公式规则；2、单位对资料可信度影响的权数的规则；3、业绩归属的定义；4、上级组织在不同的角度是不同的（如：财务和销售）九、dw运用的％2％的bpm、kpi的管理；3％的数据挖掘；15％的数据分析；80％的report；十、让我头疼的几个问题及解决方法1、由于是从分散的系统中抽取资料，所以各个公司相同的系统中基本资料中对基本数据定义可能会不一样；如：A这个产品代号在华东表示冰红茶，在华南可能表示冰绿茶；抽取至dw中的数据失去可比性；我的对策：a、如果是关键性的基本资料，在集团总部和各个公司建立一个公共系统（PUB），把各系统基本资料抽取出来，并规划出哪些栏位是总部必须要控管的，然后放入PUB系统在集团总部控管，所有系统的基本资料的总部控管栏位的来源只有从PUB系统中来，集团总部有修改和新增的权利，下属各公司只有查询的权利，下属各公司如要新增和修改必须至总部申请；对于非总部控管的栏位各公司可以自己更改；PUB系统的table资料定期的同步至各公司的数据库中；b、如果是非关键性的基本资料，建立对照表翻译成dw中的定义；只不过抽取程序设计会麻烦一点；2、业务的术语定义集团内没有共识；如：华东区认为销售铺货率应该这样计算，而东北区认为应该那样计算，而集团总部又是一种说法；我的对策：请集团的高层建立或者指定相关的权威部门协调各方并给出标准的定义；不要迁就于各分公司的不同的算法而客制出不同的报表，那样只会让各分公司看到的报表数据失去可比性且让各方因为数据的问题吵的不可开交；3、由于lotp系统老化且分散在各分公司中，所以导致各分公司相同的系统其中的运行的逻辑会有差异，相同的table相同的栏位存储的数据计算规则不一致；我的对策：没有什么好的方法，要修改老化的系统使大家一致不太实际；因为会牵涉的系统的太多，并且老的语言精通的人不多，如果修改不知道会发生不可预测的问题；所以我只有请各公司了解自己的规则并填入我们规划的规则库，我们的抽取程序依照规则库中的规则来抽取，并且各分公司的规则更改时，也请他们更新规则库；4、各分公司IT部门以前替各自分公司的开发的类似dw系统在使用并且数据可能会与总部的dw中数据不一致，各分公司对集团总部推的dw系统有抗拒心理；我的对策：首先请集团的高层向各分公司做说服，并且向集团的高层申请“上方宝剑”，其次通过dw的资料回流至各分公司数据库，使各分公司的自己开发的类似的系统的数据源来源于dw中，这样就把集团总部和各分公司捆绑在一起；5、dw中资料刷新的问题，因为oltp系统的可变性，导致抽取程序在从oltp系统中抽取资料时不知道应该扫描哪些资料，oltp哪些资料自上次抽取后被更新了(变化数据捕获的问题)；我的对策：这个应该是所有的做dw项目均会碰到的问题；a、如果抽取的table是比较小的table，在不影响可以oltp系统性能的情况下，可以在oltp的系统的table上加入trigger来记录更新；抽取程序可以根据记录来只抽取更新的记录；如果加trigger有困难，每次把table的全部资料抽取回来也可；b、上面的方法只能解决小部分的问题，大部分是要通过时间戳的比较，或者充分理解oltp系统的规则，如oltp系统不会更改多久以前资料，oltp系统是否有结转的概念，如果要更改已结转的资料是不是在什么地方有记录之类；根据具体情况具体解决；我现在负责的这个项目的销售这一块在oltp系统中有结转的概念，如果要更改已结转的资料必须要进行结转回复；所以我们在设计抽取程序时有一个抽取记录的table，用来记录该分公司的销售系统资料日期、该日是否已结转、抽取的次数等等；并且要求oltp系统中日结的程序加入，如果做日结回复必须update 抽取记录的table其中的抽取次数为0；我们的抽取规则就是：抽取抽取次数为0的日期的资料，但未日结的资料不管次数为多少均抽取；抽取完毕后update该table相关栏位；十一、其他1、后台的程式执行出错时，log记录至table中；并自动发出mail通知相关的人；2、执行成功，成功的记录至succmsg中；<*the end*>。
