数据仓库设计的21条原则：7个步骤,7个禁忌和7种思路
数据库设计原则与方法
数据库设计原则与方法近年来，随着计算机技术的飞速发展，数据库已经成为了企业和机构管理和运营的核心组成部分。
而在这个过程中，数据库设计显得尤为重要，因为数据本身就是企业和机构最重要的资产之一。
为此，本文将围绕数据库设计原则与方法这个话题来展开，旨在帮助读者更好地理解数据库设计的重要性，并提供一些实用的解决方案。
一、数据库设计的三大原则首先，数据库设计需要遵循三大原则：完整性原则、一致性原则和有效性原则。
完整性原则是指在设计数据库时，必须尽量减少数据的冗余，让数据表中每个数据项都能够独立且唯一地表示一个实体。
这一原则的主要目的是为了避免数据丢失、数据冗余以及数据不一致等问题，提高数据的可维护性和可重复性。
一致性原则是指在设计数据库时，需要对数据进行统一规范和格式化，并确保每一个数据项都符合设计规范。
这一原则的主要目的是为了避免数据质量低下、数据不可靠等问题，提高数据的可靠性和可用性。
有效性原则是指在设计数据库时，需要考虑到数据访问的速度和效率等因素，确保数据查询操作的高效和优化。
这一原则的主要目的是为了提高数据的可访问性和可操作性。
二、数据库设计的六大步骤除了遵循上述三大原则之外，数据库设计还需要遵守一定的设计流程和步骤。
一般来说，数据库设计包括六个主要步骤：1.确定数据库系统的目标：首先，需要明确自己设计数据库系统的目标，明确数据设计的用途和目的。
2.收集和分析数据要求：其次，需要对设计数据库系统所需的数据进行收集和分析，明确数据的来源、内容和结构。
3.建立概念模型：根据收集到的数据，建立逻辑模型和概念模型，明确数据库中表、关系和数据项之间的关系和联系。
4.规划和实现物理模型：在完成概念模型设计之后，需要制定具体的物理模型规划方案，并实现物理模型。
5.编写数据库管理系统：根据设计的物理模型，编写数据库管理系统，包括数据的插入、修改和删除等操作。
6.测试和维护：最后，需要对数据库管理系统进行测试和维护工作，确保系统的稳定性和安全性，并及时处理出现的问题和异常。
数据仓库设计的七个步骤
数据仓库设计的七个步骤在处理一个数据仓库项目时需要注意的问题很多，但同时也有很多有建设性的参考可以帮助你更顺利的完成任务。
开放思维，不断尝试新的途径，对于找到一种可行的数据仓库实现方法来说也是必需的。
1. 配备一个全职的项目经理或你自己全面负责项目管理在通常情况下，项目经理都会同时负责多个项目的实施。
这么做完全是出于资金和IT资源方面的考虑。
但是对于数据仓库项目的管理，绝对不能出现一人身兼数个项目的情况。
由于你所处的领域是你和你的团队之前没有进入过的领域，有关数据仓库的一切－数据分析、设计、编程、测试、修改、维护－全都是崭新的，因此你或者你指派的项目经理如果能全心投入，对于项目的成功会有很大帮助。
2. 将项目管理职责推给别的项目经理由于数据仓库实现过程实在是太困难了，为了避免自虐，你可以在当前阶段的项目完成后就将项目管理职责推给别的项目经理。
当然，这个新的项目经理一定要复合第一条所说的具有全职性。
为什么要这么做呢？首先，从项目经理的角度看，数据仓库实施过程的任何一个阶段都足以让人身心疲惫。
从物理存储设备的开发到Extract-Transform-Load的实现，从设计开发模型到OLAP，所有阶段都明显的比以前接触的项目更加困难。
每个阶段不但需要新的处理方法、新的管理方法，还需要创新性的观点。
所以将管理职责推给别的项目经理不但不会对项目有损害，还可以起到帮助作用。
3.与用户进行沟通这里所讲的内容远比一篇文章本身要重要的多。
你必须明白，在数据仓库的设计阶段，那些潜在用户自己也不清楚他们到底需要数据仓库为他们做什么。
他们在不断的探索和发现自己的需求，而你的开发团队也在和客户的接触中做着同样的事情。
更加频繁的与客户接触，多做记录，并让你的团队更关注于项目需求讨论的结果而不是讨论的过程本身。
既然你和客户的交流是为了了解存储的数据是何种类型以及如何有效存储数据，你也许需要（和你的用户一起）采用一种新的方法观察数据，而不是直接处理数据。
数据库的设计原则与规范
数据库的设计原则与规范随着信息化的发展，数据库成为了处理和管理数据的重要工具。
在进行数据库设计时，遵循一定的原则和规范可以提高数据库的效率、可靠性和可维护性。
本文将介绍数据库设计的原则与规范，旨在帮助读者建立一个高质量的数据库系统。
一、原则：1. 数据库设计原则的第一个目标是满足用户需求。
在设计数据库时，要深入了解和分析用户的需求，确保数据库可以提供准确、全面和及时的数据，以支持用户的业务需求。
2. 数据库设计原则的第二个目标是简化和标准化。
数据库设计应遵循简单和标准化的原则，避免冗余和重复的数据。
通过正规化过程，将数据拆分为更小的、相互关联的实体，以减少数据存储和维护的开销。
3. 数据库设计原则的第三个目标是保证数据完整性。
数据完整性是指数据库中的数据准确性和一致性。
通过定义适当的主键、外键和约束条件，限制数据的插入、更新和删除操作，确保数据的完整性。
4. 数据库设计原则的第四个目标是提高性能。
在设计数据库时，应考虑通常的查询需求和频率，合理选择和优化索引、视图和查询语句，以提高数据库的查询和处理性能。
5. 数据库设计原则的第五个目标是考虑安全性。
保护数据的安全性是数据库设计不可忽视的方面。
通过权限控制、数据加密和备份策略等措施，保护敏感数据的安全性和机密性。
二、规范：1. 表命名规范：表名应具备描述性，使用英文单词或缩写，避免使用特殊字符和关键词，尽量使用小写字母，可使用下划线分隔单词。
例如，学生表可以命名为 "students"。
2. 字段命名规范：字段名应具备描述性，使用英文单词或缩写，避免使用特殊字符和关键词，尽量使用小写字母，可使用下划线分隔单词。
例如，学生的姓名字段可以命名为 "student_name"。
3. 数据类型规范：选择合适的数据类型来存储不同类型的数据，以节省空间和提高查询性能。
例如，使用整数类型来存储整数值，使用字符类型来存储文本值。
数据库设计原则和方法
数据库设计原则和方法概念数据库设计指的是将现实世界中的信息转化为计算机系统中的数据结构的过程。
在设计数据库时需要遵循一系列的原则和方法，以确保最终数据库能够满足应用系统的需求，且结构合理、高效。
本文旨在讨论数据库设计的原则和方法，并探讨如何应用这些原则和方法来设计出一个高质量的数据库。
第一部分：数据库设计原则设计数据库时需要遵循以下原则：1. 数据库设计应该从应用系统的需求出发，而不是从数据的角度出发。
在数据库设计的过程中，需要深入了解应用系统的需求，以便能够尽可能的将应用系统的需求转化为数据库结构，从而保证数据库的高效性和合理性。
2. 数据库的结构应该具有可扩展性和可维护性。
在数据库设计时，需要考虑到数据库可能需要随着时间的推移进行扩展，因此需要设计具有扩展性的结构。
同时，数据库设计也需要考虑到数据库的维护，以确保维护人员能够轻松的进行维护和管理。
3. 数据库设计应该遵循第一范式、第二范式和第三范式。
第一范式要求关系数据库中的每一列都是不可分割的原子数据项，即每一列都不应该再进行拆分，以确保数据的完整性和一致性。
第二范式要求关系数据库中的每一个非主属性都完全依赖于主属性，以确保数据的完整性和高效性。
第三范式要求关系数据库中的每一个非主属性都不直接依赖于另一个非主属性，以确保数据的高效性和可维护性。
4. 数据库设计应该考虑到数据的完整性和一致性。
数据库中的数据应该有一定的完整性和一致性，合理的数据结构和正确的约束可以帮助确保数据的完整性和一致性。
第二部分：数据库设计方法1. 确定数据库中需要存储的数据。
在数据库设计的开始阶段，需要明确需要存储哪些数据，并了解这些数据的类型、属性和相关的约束条件。
2. 定义实体和实体之间的关系。
在数据库设计的过程中需要将现实生活中的实体转化为数据库中的实体，并确定这些实体之间的关系。
这可以通过ER模型进行实现。
3. 定义数据库模式。
数据库模式可以看作是数据库的设计蓝图，它定义了数据库中的各个表、字段和相关的约束条件。
数据仓库数据安全管理制度
第一章总则第一条为确保公司数据仓库数据的安全、完整和可用，防止数据泄露、篡改、丢失等风险，特制定本制度。
第二条本制度适用于公司所有涉及数据仓库的数据收集、存储、使用、处理、传输、销毁等活动。
第三条本制度遵循以下原则：1. 隐私保护原则：对个人隐私数据进行严格保护，未经授权不得泄露。
2. 完整性原则：确保数据仓库数据的准确性和一致性。
3. 可用性原则：确保数据仓库数据在需要时能够及时、准确地提供。
4. 安全性原则：采取有效措施，防止数据泄露、篡改、丢失等风险。
第二章数据分类与分级第四条公司数据仓库数据分为以下几类：1. 公开数据：指对内对外公开的数据，如公司年报、产品介绍等。
2. 内部数据：指公司内部使用的数据，如员工信息、财务数据等。
3. 高级内部数据：指涉及公司核心业务、技术秘密的数据。
第五条公司数据仓库数据分级如下：1. 一级数据：涉及公司核心业务、技术秘密，对数据安全要求极高的数据。
2. 二级数据：涉及公司内部使用的数据，对数据安全要求较高的数据。
3. 三级数据：涉及公司公开数据，对数据安全要求较低的数据。
第三章数据安全责任第六条公司董事会对数据安全负有最终责任。
第七条公司高层管理人员对数据安全方针和政策负责，并由数据安全团队负责执行与管理数据安全。
第八条数据安全团队工作职责：1. 制定与颁布数据安全政策和规程。
2. 定期开展数据安全教育和训练。
3. 监测和识别数据安全风险。
4. 负责数据安全事件的调查和处理。
第九条所有公司员工应遵守数据安全制度，将数据安全作为工作的重中之重。
第四章数据收集与存储第十条数据收集应遵循以下原则：1. 合法性原则：收集数据应合法合规，不得侵犯他人合法权益。
2. 诚信原则：收集数据应诚实守信，不得虚构、篡改数据。
第十一条数据存储应遵循以下要求：1. 选用安全可靠的数据存储设备。
2. 对数据进行加密存储，防止数据泄露。
3. 定期对数据进行备份，确保数据安全。
第五章数据使用与处理第十二条数据使用应遵循以下原则：1. 依法使用原则：使用数据应符合法律法规的要求。
数据仓库设计方案
数据仓库设计方案【正文】一、引言数据驱动的决策已经成为企业中不可或缺的一部分。
为了有效地管理和分析海量的数据，数据仓库设计方案应运而生。
本文将介绍数据仓库的概念、设计原则和关键步骤，帮助企业构建高效可靠的数据仓库。
二、数据仓库概述数据仓库是指将各类数据整合、清洗、转化并存储于统一的数据存储区域，旨在为决策支持系统提供准确可靠的数据服务。
其设计方案需要考虑多个方面，包括数据源、数据的抽取与转换、数据建模和数据的加载等。
三、数据仓库设计原则1. 一致性：数据仓库应该保持与源系统的数据一致性，确保决策所依据的数据准确无误。
2. 高性能：数据仓库需要具备高性能的查询和分析能力，以满足用户对数据的实时性和响应性要求。
3. 安全性：严格管理数据仓库的访问权限，确保敏感数据的安全性和隐私保护。
4. 可扩展性：数据仓库需要具备良好的扩展能力，能够适应数据量的增长和业务需求的变化。
5. 可维护性：数据仓库的设计应该具备良好的可维护性，便于数据的更新、维护和监控。
四、数据仓库设计步骤1. 需求分析：明确数据仓库的功能和目标，分析业务需求和数据源的特点，为后续的设计提供指导。
2. 数据抽取与转换：根据需求分析的结果，选择合适的数据抽取方式，并进行数据的清洗、转换和集成。
3. 数据建模：根据业务需求和数据源的特点，设计数据仓库的物理和逻辑模型，并建立相应的维度表和事实表。
4. 数据加载：将清洗和转换后的数据加载到数据仓库中，并进行合理的存储和索引，以便进行后续的查询和分析。
5. 数据质量控制：定期监控数据仓库的数据质量，并进行必要的修复和优化，确保数据准确无误。
6. 安全管理：建立合适的权限控制机制，确保数据仓库的安全性和合规性。
五、数据仓库设计工具和技术1. ETL工具：ETL（Extract-Transform-Load）工具可以帮助实现数据的抽取、转换和加载，实现数据仓库的数据集成和清洗。
2. 数据建模工具：数据建模工具可以辅助设计数据仓库的物理和逻辑模型，提供建模、维护和文档化的功能。
数据库设计原则
数据库设计原则数据库设计是构建稳健可靠的数据库系统的关键步骤。
一个好的数据库设计可以提高数据管理和操作的效率，保证数据的完整性和安全性。
本文将介绍一些常用的数据库设计原则，帮助您设计出高质量的数据库。
1. 规范化规范化是数据库设计过程中最基本的原则之一。
它是指将数据库中的数据组织成不同的表，通过消除冗余数据、确保数据依赖正确等方式，提高数据库的完整性和一致性。
规范化的具体步骤包括将数据分解为多个表，建立主键和外键关系等。
2. 适当的数据类型选择在数据库设计中，选择适当的数据类型可以提高数据库的性能和存储效率。
例如，对于存储整数的字段，选择较小的整数类型（如TINYINT）可以减少存储空间的占用。
而对于存储大型文本数据的字段，选择合适的文本类型（如VARCHAR或TEXT）可以避免数据截断问题。
3. 建立正确的索引索引是数据库中用于提高查询效率的重要手段。
正确选择和建立索引可以显著提高数据库的查询性能。
在设计数据库时，需要根据数据表的访问模式和查询需求，选择适当的字段作为索引并为其创建索引。
同时，需要注意索引的维护成本，合理使用组合索引和覆盖索引等技术。
4. 数据库安全性保护数据库中的数据免受非法访问和损坏是数据库设计的重要考虑因素。
为了保证数据库的安全性，需要采取一系列措施，如设置合适的用户权限和角色、使用强密码、定期备份数据等。
此外，对于包含敏感信息的数据，可以采用加密技术进行数据保护。
5. 异常处理在数据库设计过程中，需要考虑各种异常情况的处理。
例如，数据插入或更新时出现异常、连接中断或数据库崩溃等情况。
为了保证数据库的稳定性和可恢复性，可以设置事务机制、使用存储过程和触发器等技术，对异常情况进行处理和恢复。
6. 性能调优数据库的性能也是一个重要的设计考虑因素。
通过合理的索引设计、优化查询语句、分区等技术，可以提高数据库的查询响应速度和并发处理能力。
同时，需要对数据库进行性能监控和调优，及时发现和解决潜在的性能问题。
数据库设计的原则
数据库设计的原则数据库设计是一个关键的步骤，它会直接影响到后续的数据管理和应用使用。
一个良好的数据库设计能够提高数据的可靠性、安全性和性能。
在进行数据库设计时，需要考虑一些重要的原则，本文将介绍一些数据库设计的原则和注意事项。
一、需求分析和规范化在开始数据库设计之前，首先需要进行需求分析。
仔细了解用户的需求，明确数据库的功能和数据要求。
在需求分析的基础上，进行数据的规范化。
数据规范化是指将数据库中的表设计为满足特定的范式要求，以提高数据的一致性、减少冗余和避免更新异常。
常见的范式有第一范式、第二范式和第三范式。
二、适当的数据类型选择在数据库设计中，选择适当的数据类型是非常重要的。
不同的数据类型适用于不同的数据存储需求。
例如，对于整数型数据可以选择INT，对于字符串型数据可以选择VARCHAR。
选择合适的数据类型可以有效地节省存储空间，并提高查询和更新操作的效率。
三、合理的表结构设计数据库的表结构设计是整个数据库设计的核心。
在设计表结构时，应该遵循以下原则：1. 根据数据的关系划分表：将具有相同属性的数据划分为一个表，避免在一张表中存储过多的信息。
2. 定义主键：每个表必须有一个主键，用于唯一标识表中的每条记录。
3. 建立关系：在关系型数据库中，可以通过外键建立表与表之间的关系，保证数据的一致性和完整性。
四、索引的创建和优化索引是提高数据库性能的关键因素之一。
在数据库设计中，需要合理地创建索引，并优化已有的索引。
创建索引可以加快数据检索的速度，但是过多或不必要的索引会增加数据的插入和更新的成本。
在创建索引时，需要根据实际需求进行权衡。
五、数据完整性、安全性和备份保持数据的完整性和安全性是数据库设计的重要原则之一。
通过合理的约束条件和权限控制，可以保证数据的一致性和安全性。
此外，及时进行数据备份和恢复，以防止数据丢失和系统故障。
六、性能优化和扩展性考虑在设计数据库时，需要考虑系统的性能和扩展性。
通过合理的表结构设计、索引优化和查询优化，可以提高数据库的查询和更新效率。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
高效实现数据仓库的七个步骤数据仓库和我们常见的RDBMS系统有些亲缘关系，但它又有所不同。
如果你没有实施过数据仓库，那么从设定目标到给出设计，从创建数据结构到编写数据分析程序，再到面对挑剔的用户的评估，整个过程都会带给你一种与以往的项目完全不同的体验。
一句话，如果你试图以旧有的方式创建数据仓库，那你所面对的不是预算超支就是所建立的数据仓库无法良好运作。
在处理一个数据仓库项目时需要注意的问题很多，但同时也有很多有建设性的参考可以帮助你更顺利的完成任务。
开放思维，不断尝试新的途径，对于找到一种可行的数据仓库实现方法来说也是必需的。
1. 配备一个全职的项目经理或你自己全面负责项目管理在通常情况下，项目经理都会同时负责多个项目的实施。
这么做完全是出于资金和IT资源方面的考虑。
但是对于数据仓库项目的管理，绝对不能出现一人身兼数个项目的情况。
由于你所处的领域是你和你的团队之前没有进入过的领域，有关数据仓库的一切－数据分析、设计、编程、测试、修改、维护－全都是崭新的，因此你或者你指派的项目经理如果能全心投入，对于项目的成功会有很大帮助。
2. 将项目管理职责推给别的项目经理由于数据仓库实现过程实在是太困难了，为了避免自虐，你可以在当前阶段的项目完成后就将项目管理职责推给别的项目经理。
当然，这个新的项目经理一定要复合第一条所说的具有全职性。
为什么要这么做呢？首先，从项目经理的角度看，数据仓库实施过程的任何一个阶段都足以让人身心疲惫。
从物理存储设备的开发到Extract-Transform-Load的实现，从设计开发模型到OLAP，所有阶段都明显的比以前接触的项目更加困难。
每个阶段不但需要新的处理方法、新的管理方法，还需要创新性的观点。
所以将管理职责推给别的项目经理不但不会对项目有损害，还可以起到帮助作用。
3.与用户进行沟通这里所讲的内容远比一篇文章本身要重要的多。
你必须明白，在数据仓库的设计阶段，那些潜在用户自己也不清楚他们到底需要数据仓库为他们做什么。
他们在不断的探索和发现自己的需求，而你的开发团队也在和客户的接触中做着同样的事情。
更加频繁的与客户接触，多做记录，并让你的团队更关注于项目需求讨论的结果而不是讨论的过程本身。
既然你和客户的交流是为了了解存储的数据是何种类型以及如何有效存储数据，你也许需要（和你的用户一起）采用一种新的方法观察数据，而不是直接处理数据。
你可以尝试从中找出隐藏的信息，比如在一段时期内的数字涨落等。
不要试图追寻项目需求的答案，而是要让答案找上门来。
4. 以技术/信息库作为领导由于数据仓库实施的各个阶段都有很大不同，因此你需要有人能起到维持整个项目的连续进行的作用，不过这个职责并不需要那种全职性。
项目实施有三个重要方面：架构、技术和业务。
将架构作为重点可以保证在整个项目中，数据仓库的架构从物理层往上，都会受到良好的维护。
而我们应该将技术作为重点，因为开发团队和关键用户都在使用他们以前从未用过的工具，必须有人监督开发过程以及工具使用的一致性。
最后，在数据仓库的应用过程中浮现出来的业务需求必须被详细分析和记录，以促机开发过程持续下去。
如果用户不能很好的开发人员以及其它用户沟通，那么数据分析和度量方面的开发进程就会延期，所以必须有人关注业务方面的开发，推动开发进入更高级别。
5. 跳出反复修改程序的陷阱第一次实现的数据仓库肯定不会是最终交付的版本。
为什么呢？实际上在真正见到产品前，你无法确定的知道自己的目标是什么。
或者说，最终用户只有在使用数据仓库产品一段时间后，才能明确告诉你这个产品是不是他所希望的。
与你以往处理的项目不同，业务智能还处于发展的初期，每个公司对业务智能都有不同的解释，因此你的项目决不会一次成功。
为了以正确的格式获得数据，你需要在不断变化的状况中摸索前进。
BI 具有很强的个性，不同的环境、不同的市场以及不同的企业都有不同的BI。
这又代表什么呢？这表示你需要把数据库管理员放在一个消息相对封闭的环境中，不要让他知道数据仓库的数据结构以及ETL程序在不断的改变。
对此没有别的办法。
这样可以减轻你和DBA所承受的压力。
6. 对大量的前端资源进行数据源分析在数据仓库实现过程中，你不得不在旧有的数据中艰难跋涉，这些数据来自老的数据库、老的磁带机以及远程的数据。
它们中的大部分都凌乱不堪，并且难以获取。
你要对这些数据进行大量处理，并且还要设计ETL程序来寻找其中的有用信息。
如果你希望整个项目做起来比较顺利，并且找到一种方法能够一次成功，那就需要你的开发人员必须花费足够的时间来充分研究这些旧有数据，将凌乱的数据规则化，并尽力设计和实现强壮的数据采集和转换过程。
数据仓库的ETL部分会占用整个项目资源的百分之八十，所以一定要确定你的资源都用在刀刃上了。
7. 将人际关系处理放在首位在数据仓库实现过程中真正的地狱不是来自技术或者开发方面，而是来自你周围的人。
你也许会遇到一个对项目并不乐观而又没时间听你陈述的领导。
你也许会遇到一些开发人员将进度拖延太长时间还抱怨为什么不能用老方法实施。
你也许还会遇到一些抱有不切实际的幻想的用户，他们希望轻点鼠标就能实现想象中的功能，但却不愿在他们那边多做些智力投资，更好的培训他们自己的员工。
而你也已经疲惫不堪，鼓励投资，以及在开发团队和用户（甚至老板）中推广新的开发技巧。
总之你要保持微笑。
当一切搞定，你的烦恼也就一扫而空了，笑到最后才笑得最轻松。
数据仓库开发过程中的七个禁忌过去我们一直使用的OLTP技术也许隐藏着许多严重的缺陷。
数据仓库的实现并不是一个简单的任务，你会发现以前积累下来的丰富经验，并不适合处理每个数据仓库的独特需求。
下面列出的条款是你在实现数据仓库过程中一定会面对的问题，其中一些看起来并没有想象中那么严重，但是你还是应该尽量避免出现类似问题。
数据仓库并不是一个事务处理系统，它没有一定的标准也不会实现某个特定的应用，但它本质上是非常有组织性的。
总之，每个公司所建立的数据仓库都是唯一的，并且每一次数据仓库的实现方法都不是一成不变的。
在实现数据仓库时需要注意的不单是"应该如何作"，更要注意"不该如何做"。
下面就是我们总结的七点"不该如何作"。
1.不要编写自己无法快速修改的代码你所要编写的程序主要用于数据分析，而不是处理事务。
而你的用户也并不真正知道他们自己真正想要一个什么样的程序。
因此你不得不反复修改代码好几次，才会明白用户到底需要一个什么样的程序。
如果你编写的程序具有良好的结构和灵活性，就算需要修改也不会太浪费力气。
反之，你会被自己累死。
2. 不要使用无法修改的数据库访问API在过去，你的数据库可以为大量的客户提供稳定的数据查询服务。
而如今，你的程序必须能够应付更多的数据查询。
这使得重新改写程序以使得每个查询请求能得到最大的数据量成为势在必行的工作，而一般来说这种代码修改都不会一次成功，所以只有选择合适的可以修改的API，才能使程序尽快适应新的需求。
3. 不要设计任何无法扩展的东西在联机处理过程（OLTP）应用中，数据分析并不是一个真正的应用程序。
实际上，数据分析的关键是获取大量旧的数据，从中提取数据模型，并以此模型推断出新的信息。
而你所编写的访问潜在信息的代码应该具有可扩展性，可以附加新的数据。
千万别在支持数据分析的代码中假定数据都是固定格式的。
4. 不要附加不必要的功能一个仓库要做的是恰到好处的服务，用户走进仓库，从货架上取得自己所需得信息，仅此而已。
由于业务智能、分析以及规律性的问题都有各自的处理程序，因此你的客户唯一的需要就是获取信息。
他们需要一种应用环境，可以让他们快速的从数据仓库中取得分析过程所需的数据，而不论这个数据是什么样子的。
也许你想帮助他们精炼一下获得的数据，但最好不要这么做。
一定要记住，不要给客户的数据分析程序添加任何会影响数据访问性能的功能。
5. 不要简化数据清除和数据源分析的步骤在实现数据仓库过程中最应该注意的地方就是为Extract-Transform-Load机制分析数据源，以及为优化负载而清除数据。
安全的做法是假设项目经理在这个阶段会需要整个项目资源的一半以上。
相反，如果你在这方面进行了简化，稍后肯定会后悔。
所以就算系统工作缓慢，也不要简化清理旧的数据的过程。
6. 不要避免颗粒度和分区问题在数据仓库设计过程中有两个最大的数据存储问题，第一是如何给转换数据定位一个恰当的颗粒度等级，第二是如何将数据绝对的分区。
为什么这两点问题如此重要呢？因为整个数据仓库的响应能力受颗粒度影响，并且数据访问的效率直接与数据分区性能有关。
因此这是具有关键性的工作，不要试图避免面对这些问题。
7. 不要在没考虑业务问题前就使用OLAP用户在亲眼见到程序前通常都不知道自己到底想要个什么样的程序。
因此他们的观点有不少错误，比如他们希望分析结果会忠实反应性能度量，或者希望程序会使他们部门或公司的业务工作有所不同。
而你必须跳出自己的职责范围，从IT管理者的角度考虑用户部门直至整个企业的运行方式，才能在开发过程中避免这类问题。
在通常的OLTP开发中，你可以比较方便的理解业务流程。
而在联机分析处理（OLAP）领域，任何事情都需要亲自考察，而在你周围工作的人也许并不会发现你对业务方面存在的误解。
因此，不要自以为已经了解了足够的信息。
不断的询问才能使你真正了解"业务智能"中的"业务"到底是什么样子的顺利开发数据仓库的七种思路对于大多数IT顾问来说，实现一个数据仓库的难度比以前做过的任何项目难度都要大。
考虑到不同的数据结构、用途以及应用程序开发方法，以前所积累的经验和技巧大部分都无用武之地了。
但是只要在你的前进道路上稍加修正，你就会发现实现一个数据仓库并不是难事，就算你是第一次实现数据仓库也没问题。
下面列出了数据仓库实施过程需要考虑的步骤，有一些你可能从来没有意识到，而另一些可能已经在实施过程中使用到了，但是重新思考一番也许你会有更多的领悟。
开放思维，不断尝试新的途径，找到一种可行的数据仓库实现方法。
1. 再三考虑应用程序的实现方法数据仓库并不涉及事务处理，并且在报表方面也仅占一小部分。
而数据仓库应用程序的本质是分析，尤其是针对业务智能的分析。
BI并不是通常所说的数据：它是一种从旧有数据中,模型化得到的新的数据。
那么如何才能从旧有数据中挖出这些新数据呢？事实上，这个工作不是让你来完成的，而是你的客户所要完成的。
从项目主管的角度看，应该有一个经验丰富的数据表格设计师与你合作，进而决定如何将各类程序融合在一起。
其中所遇到的最主要的挑战将是如何用新的方法观察数据，这也是你的客户正在试图使用的方法。
2. 创建抽象的、良好部署的数据库访问组件在过去你接触过的数据库项目和现在的数据仓库之间，有一点绝对不同，那就是：在Online Transaction Processing （OLTP）环境中，用户数量非常大，但使用到的数据却比较少；而在Online Analytical Processing （OLAP）环境中情况却正好相反，少量的用户在使用大量的数据。