如何构建适当的数据库模式以在选定日期内具有“定期快照”表格？
亟待解决的问题： 对于DataBase来说我是新手，我试图找出在表中存储更改的最佳方法，即每天对某些状态进行快照：例如， “hotel_room_rentals”表（20列 - 每个都可以更改）。 我希望能够在选定的一天生成该表（例如生产中的数据变化，因此我必须将其存储在其他地方），或者对其进行一些其他转换（例如，在一段时间内平均租用的天数）如何构建适当的数据库模式以在选定日期内具有“定期快照”表格？
我的理论的例子 - 详细介绍： 比方说，进出口创建一个DB的酒店。 在生产系统中，我有一张表格显示酒店所有10 000间客房的信息。 这是每日快照 - 让我们假设表格每天更新一次。
房间的某些属性经常变化：例如， is_rented; customer_number，rate_usd。 某些属性不会经常更改：例如disabled_room，room_color，type_of_furniture。 Room_number显然不会改变（主键）
现在我想找到跟踪此表中的变化的最佳方式;根据此表格创建统计信息的最佳方式（例如，在一段时间内租用的平均天数）并能够生成选定日期的表格（例如2013-01-01）
我的想法： 由于我对数据库没有任何线索，因此我的想法是每天复制整个表，并添加一个名为“DB_dump_date”（带日期）的列。这是一个非常简单的方法，这可能需要很大的空间;自从我的10K房间表，将不得不在一年内复制365次。
其他解决方案： 在其他一些网站，我建议创建两个表： “保留”表，这些列：开始日期结束日期房价Occupant_name 然后向该表转换成FactReservations表：日期间Is_occupied Rate Occupant_name 我不明白这对我有什么帮助......事实上，我假设我必须制作20个中间表，然后再制作20个Fact表（因为我的数据库中有20个列）。
问题： 有什么建议的方法来解决这些问题？ 有没有准备好处理它的任何数据库模式，而无需用户制作神奇的ETL？ （例如，可以自己优化问题的数据库） 有什么替代方法？ 你，聪明的人会怎么做？ （最好是在MS Access ...或者一些免费技术）
编辑： 一两件事 - 一切都可以在表中的变化，不仅房间reservetions，应有尽有;我希望能够跟踪变化
停止 - 减速 - 和深呼吸。
不要 - 重复每天不要复制表格。这种方法是基础的方式。
你的问题是规范化问题。正如你所指出的那样 - 你还有其他建议如何正常化 - 这是你想要走的方向。
你的目标是找到一个结构，它可以容纳可以回答你的问题的SQL语句（希望还有更多你还没有想到的），这将是一个静态模型，其中表格不会改变或得到复制，而是静态 - 唯一改变的是表内的数据。 （理想情况下 - 对我来说也将有很少到没有更新，只有插入）
你一定需要一个ROOM表和一个CUSTOMER表，然后它们之间的关系可能是RESERVATION。然后
这些可以填补 - 你可以得到所有的答案，你没有任何复制或物化或任何..只是SQL提出的问题。
感谢您的回答......但林不知道它是否有帮助;我知道还有其他的解决方案，但我不知道他们，我没有看到任何有趣的逻辑，这将意味着20个额外的其他表，20 ETL和20 FactTables（正如我写的，每列可以改变）。我知道我可以将customer_number连接到客户信息，但这是无关紧要的 – fledgeling 2013-03-24 23:01:47
问题出在您设计的20列表格中。这需要被正常化 - 一条经验法则是一张桌子应该有5-7列最大。看看你是否可以得到第三范式 – Randy 2013-03-24 23:04:42
我试图学习什么是这种情况下的最佳做法。划分桌子听起来像一个有趣的想法;但我仍然没有真正看到好处，因为当我将某些东西划分为20个预留表+20个事实表时，信息仍然需要被复制，因此它位于某处（但我猜测它的操作更容易运行）。实际上是否有任何其他好处，用20个部分复制东西，而不是制作1个大副本？如果你真的感兴趣，我有一个类似的问题，由“顾问”创建，并作为最终用户解决它 - 想学习最佳实践 – fledgeling 2013-03-24 23:20:09
您需要专注于需求并从那里开始。到目前为止，对于要求我看到的是：
- 生成该表为选定的一天
在一段
租用如果我们考虑设计的两个极端，在更复杂的结束的天数 - 平均将会是一个带有SCD表的数据智能表，跟踪对房间的更改，并且在简单的结束处将会是某种日志表，如您已经提到的那样。
字里行间，我实在看不出任何要求的认识在某一天的房间的属性，但我确实看到了历史交易分析的要求。
所以我的建议是让你开始设计数据库之前好辛苦想想你的要求。
有没有神奇的设计来自动覆盖这一点。维度设计是对业务数据进行建模的标准方法，可以轻松进行分析，但可能会超出您的要求。
欢迎来到数据库世界！考虑到这一点 - 将几乎所有你知道的关于Excel的东西都拿出来扔到窗外。而在Excel中定义两张工作簿之间的关系并报告这两张不同的工作表之间的关系要困难得多，因此大多数情况下只需简单地将相同的数据复制到一张工作表中就简单多了，而使用访问或任何其他关系数据库。
通常你想要做的是创造一些规范化的表，并定义它们之间的关系。然后，在查询视图时，可以轻松地在表格之间进行连接以获取所需的数据。
所以，工作过，你正在构建这个简单的报告，而不是建立一个物业管理系统（如果您正在寻找在这一假设的 - 我建议你看看一些在玩家行业，像百万分之一或商Agilysys），根据我的经验，在行业工作，我建议如下表布局：
- 预订 - 这个拥有该保留的信息（客人姓名， 到达日期，出发日期，入住日期，退房日期，如果速度你 使用的混合率等）
- 客房 - 这个拥有信息您的机架上的信息（数量，机翼代码，客人，＃床位，吸烟/不吸烟，视图，类型等）。）
- 房间状态 - 只有当你需要跟踪，如果一个房间是 储备/暂停/ OOO/OTM（状态类型，日期开始，日结束）
- 房间状态类型 - 的房态类型持有，以及如何它会影响 库存（类型，出库存旗）
- 价格（如果你不使用的混合率） - 每次预订 一个条目每晚（客人，率）
就个人而言，我m是使用surrogate keys作为唯一标识符的巨大粉丝，因为我经常在某处发生变化时被烧毁在业务流程和以前独一无二的自然钥匙突然间可以重复。本着这一精神，每个表都具有一个代理键和连接情况如下：
- 预订的房间 - （多对一）
- 房间 - 房间状态（一对多）
- 房间状态 - 房间状态类型（多对一）
- 预订 - 价格（一对多）
如果在Access中正确定义的关系（即在其他DBMS外键关系），应该会自动将它们使用建立y我们在创建查询时加入（在几乎所有其他DBMS中称为Views）或报告。
对于学习数据库，我建议您阅读：
- Wikipedia on Join types
- Wikipedia on Slowly Changing Dimension（你可以使用一些 这些技术来记录一段时间内的房间信息的变化）
- Wikipedia on Relational Databases
- Office documentation on Access
- Kimball Group Design Tips（伟大的数据warehou SE /数据集市 设计）
IT负责人（不再在这里工作了），聘请了顾问（不再在这里工作+他们实际上被起诉了）创建了一个有200列和大约30 000行（每月增加50行）的平台，存储一些信息。每行有一个唯一的键。当我写它是唯一的，那意味着它是唯一的，所以请不要回来一些自作聪明答复。 创造这样一个怪物 - 听起来非常迟钝 - 这就是它的原因，但是当我写下制造它的延迟时，不再在这里工作。 – fledgeling 2013-03-28 18:18:56
无论如何，在这个表中大约有20-30（谁知道）列在那里变化很快（每天 - 几天）。休息慢慢改变，不要问我多久是慢慢 - 表没有字典，我不知道某些列中的东西。无论如何，我从那些白痴那里继承了那张垃圾表，并且必须在其上工作 - 有点。基本上我需要在5-10个月（谁知道？）专栏 - >一些月份（通常为“平均状态”）进行一些统计（ANALOGY酒店在这里非常有用 - 例如“租用的平均天数”）;我还需要能够在选定的一天生成此表。 – fledgeling 2013-03-28 18:19:27
使用Access（每个数据库的最大大小为2GB） - 这与每日拍摄酒店快照和计算维度（即客房，预订等）和您的事实（即费率）类似，您可以制定不改变/缓慢改变的项目并将它们放入维度中（如果它们没有变化，则为常规维度，如果不需要或不想维护维度历史，则输入1或2），然后构建度量/事实表连接到维度。任何数据库都应该能够轻松处理数百万行的内部连接。金博尔集团有一些伟大的指针。 – 2013-03-29 00:11:37
如果您需要使用您现有的表再下面是不适用的。如果数据可以迁移到新的模式，那么这将很容易解决挑战。 TRE是一种使用当前视图范例进行开发的方法，但完全支持数据的时间维度（系统时间=数据进入数据库和有效时间=适用于数据的业务时间）。通过使用TRE的当前视图方法，这种问题很简单。看看： - http://youtu.be/V1EcsuJxUno
@fillingling。 。 。你很想知道数据库。但是，如果这是一个真正的业务问题，则应该找到具有数据库和数据建模经验的人员来解决这个问题。你不知道如何判断一个特定的解决方案是否好，以及设计不佳的数据库会危及应用程序。 – 2013-03-24 23:44:56
听起来像你想要阅读http://en.m.wikipedia.org/wiki/Slowly_changing_dimension#section_3 – 2013-03-24 23:55:12