分析服务项目生命周期
是否存在启动分析服务项目的标准？我们的情况是，我们在本地机器上工作，关系数据库不在我们的域内，而分析服务数据库最终所在的服务器也在我们的域外。所以，我有很多问题：
您在哪里设置星型模式数据库（作为 OLAP 项目的源）？它在某个单独的服务器上吗？那么，与生产星型模式数据库相比，您如何拥有开发星型模式数据库？
当您在视觉工作室上创建新的 Anaylsis 项目时，它应该连接到哪里（开发星型模式？产品星型模式？）
分析服务仅支持 Windows 身份验证，那么如果您的本地计算机和开发分析服务不在同一服务器上，如何解决此问题？
在进行 ETL 工作（在 SSIS 上）时，您连接到哪个数据库？ （开发，我假设） - 但是你如何部署到生产？
如果您需要进行更改，那么接下来该怎么办？该流程如何运作？
我对随意的问题表示歉意，但我不太确定从哪里开始，所以如果有人有一个从开始到结束的标准流程，请告诉我..谢谢！
Is there a standard via which one should start an analysis services project? Out situation is that we work locally on our machines, and the relational DB is out of our domain - and the server that analysis services DB will eventually sit on is out of our domain. So, I have a bunch of questions:
Where do you set up the Star schema DB (as the source of the OLAP project)? Is it on a separate server somewhere? And then how do you have a dev star schema db, vs your production star schema DB?
When you create a new Anaylsis Project on your visual studio, where should it connect to (dev star schema? prod star schema?)
Analysis services only supports windows authentication, so how do you get around this if your local computer and the dev analysis services is not on the same server?
When doing ETL work (on SSIS) which DB do you connect to? (dev, I assume) - but then how do you deploy to production?
What about down the line if you need to make changes - how does that process work?
I apologise for haphazard questions, but I'm not really sure where to start, so if anyone has a process from start to finish that is a standard, please let me know.. thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
对于我最近建立的这个 SSAS 项目，我做了以下工作：
我有一台开发 PC 和一台服务器。两者都在同一域中。开发PC用于编辑VS工程。该服务器用于托管试验登台/星型模式数据库、真实登台数据库、SSAS 开发多维数据集和 SSAS 生产多维数据集。
在开发过程中，我使用试验登台数据库来测试 ETL，并部署到 SSAS 开发立方体。
为了构建真正的多维数据集，我将数据源切换为指向真正的临时数据库，并部署到新的 SSAS 多维数据集。旧的生产多维数据集保持不变，因此在我部署新多维数据集时用户仍然可以访问它们。部署新多维数据集后，我将宣布新多维数据集可用，然后我可以删除旧多维数据集。顺便说一句，我每个月都会这样做。
如果您的 SSAS 服务器不在同一域中，您可以创建 SSAS 数据库备份，并在该远程服务器中还原它。
为了使 Visual Studio 能够访问 SSAS 服务器，我必须以管理员身份运行 Visual Studio（右键单击 VS 快捷方式，“运行为...”）。或者您可以在服务器上使用 SSMS 打开 SSAS 服务器，然后将您的 Active Directory 用户设置为管理员组的成员。
For this one SSAS project that I recently set up, here is what I did:
I have a development PC and a server. Both in the same domain. The development PC is used to edit the VS project. The server is used to host the trial staging / star schema DB, real staging DB, SSAS development cube, and SSAS production cubes.
During development, I use the trial staging DB to test ETL, and deploy to the SSAS development cube.
To build the real cube, I switch the data source to point to the real staging DB, and deploy to a new SSAS cube. Old production cubes are left unchanged so users can still access them while I deploy the new cube. After the new cube is deployed, I will announce the availability of the new cube, and then I can delete the old one. BTW I do this monthly.
If your SSAS server is not in the same domain, you can create an SSAS DB backup, and restore it in that remote server.
To enable Visual Studio to access SSAS server, I had to run visual studio as administrator (right click VS shortcut, 'run as...'). Or you can open the SSAS server with SSMS on the server, then put your active directory user as member of administrator group.
听起来您的主要问题是您无法直接访问生产环境/域，并且不确定如何部署 SSAS 和 SSIS 工作。
在这两种情况下，您都需要针对开发数据库进行开发，希望该数据库是生产数据库的副本。
在 SSIS 中，您将创建使用指向您的开发环境的连接字符串的连接管理器。添加包配置文件以允许访问包属性，例如连接字符串。还有其他方法可以管理配置信息，但配置文件是最简单的。当您在启用“创建部署实用程序”选项的情况下构建项目时，将创建配置文件和 .manifest 文件。这些文件与您的包一起可以在目标服务器上运行，以在开发环境之外安装和配置项目。
同样，SSAS 有一个部署实用程序。有多种方法可以将 SSAS 项目部署到生产环境。请参阅：
SSIS 中的更改通常通过部署更新的包来处理。使用 SSAS，可以将更改编写为脚本，或者可以重新部署整个数据库。我将采取的方法取决于 SSAS 数据库的大小和复杂性以及正在发生的变化。
It sounds like your main problem is that you don't have direct access to the production environment/domain and you're not sure how to deploy your SSAS and SSIS work.
In both cases you'll want to develop against the development database, which is hopefully a copy of the production database.
In SSIS, you will create Connection Managers that use connection strings pointing to your development environment. Add a package configuration file to give access to package properties, like the connection string. There are other ways to manage configuration information, but a config file is the mos straightforward. When you build the project with the Create Deployment Utility option enabled, the config file and a .manifest file will be created. Together with your package(s), these files can be run on the target server to install and configure the project outside the development environment.
Similarly, SSAS has a deployment utility. There are several ways to get an SSAS project deployed to a production environment. See: Deploying an Analysis Services Database into the Production Environment for one overview of the options. Note that data sources in your project can be manually modified by an administrator by connecting to the Analysis Server database in SSMS after deployment.
Changes in SSIS are generally handled by deploying updated packages. With SSAS, changes can be scripted or the entire database can be redeployed. The approach I would take would depend on the size and complexity of the SSAS database and what is changing.