MSBI的Subversion存储库结构

时间:2013-11-06 21:42:10

标签: svn reporting-services ssas data-modeling tabular

我们刚刚开始使用Microsoft的工具堆作为我们的BI解决方案。

我们将为公司内部的每个功能区域创建/使用SSRS报告,SSAS表格模型,Excel Services.PowerPivot模型和PowerView报告。

对于每个功能区域说(“人力资源”),我们将有一套报告,数据模型,仪表板等

我想知道你是否有人能指出我正确的方向来维护版本控制下的所有项目(我们将使用SVN)。有没有一种标准方法可以在SVN下维护所有这些不同类型的文件/文件夹?

或者简单来说,你可以指出我在下面使用一个优于其他的好处。

1)为每个功能区创建单独的文件夹,例如“人力资源”,“销售”等,并存放与其各自文件夹中该功能区域相关的所有报告,模型

文件夹结构看起来像这样

人力资源 - > HR模型 - > HRDataModelProject1(此级别将是svn的根目录 - 开发人员将从此级别检出项目)
人力资源 - >人力资源报告 - > ReportProject1

销售 - >销售模型 - > SalesModelProject1
销售 - >销售报告 - > SalesReportProject1,

或者

2)为每种内容类型创建单独的文件夹,例如数据模型,报告等,作为单独的文件夹和每个功能区域的房屋报告或模型

模型 - > HumanResources - > HRDataModelProject1(此级别将是svn的根目录 - 开发人员将从此级别检出项目)
模型 - >销售 - > SalesModelProject1

报告 - > HumanResources - > HRReportProject1
报告 - >销售 - > 销售报表项目1

上述方法有什么优点和缺点吗?或者还有其他方法可以更有效地完成吗?非常感谢您的建议!

非常感谢,

BiDev

1 个答案:

答案 0 :(得分:0)

我更喜欢第一个版本,因为它将更紧密相关的内容保持在一起。如果在将来,您将需要更改HR报告,并且可能需要多维数据集中的其他属性,这可能需要在ETL过程中进行少量更改才能填充,然后所有这些更改都将在一个区域,而不是分布在存储库的不同部分。

话虽如此,您的第二个版本也可以使用,部署解决方案的管理人员可能更喜欢它,因为他们将知道在哪里查找Integration Services包,SQL脚本,报告或Analysis服务项目。