2017年2月21日
微软的人一直在不断地为这两款手机添加新功能BI服务力量和在过去的十八个月内的下载Power Bi Desktop自2015年7月普通可用性。行级安全是一个这样的功能，允许开发人员限制用户看到哪些数据。与大多数其他主要功能一样，它首先被引入Power BI服务，然后最终添加到桌面。但是，与其他功能不同，在其桌面之外，它或其中大部分都被从服务中删除。毕竟，你真的只需要一个地方。在这两个地方都会造成混乱和冲突。但是，在部署具有定义行级安全性的模型之后需要注意的Power BI服务中存在一些挥之不去的方面。在此帖子中，我们将查看Power BI的此功能，如何在桌面上提升并运行，需要在服务中完成哪些常见场景，何时有用。
但在我们开始之前，您需要了解两点:首先，Power BI中的RLS与SQL Server 2016中的RLS是不同的。是的，这两者都是各自产品中很棒的新特性，并且在限制用户访问某些数据行方面做了几乎相同的事情。它们甚至共享相同的缩写，结果也几乎相同，但它们的实现方法却大不相同。SQL Server中的RLS使用T-SQL函数和SQL数据库中的其他构件，而Power BI使用DAX。另一个主要区别是，Power BI中的RLS可以使用，而不管数据源类型是什么。
第二个要点是，RLS和Power BI Dashboard的问答功能是互斥的。你可以有一个或另一个，但不能两者都有。虽然有些读者可能并不真正关心这一点，但其他人可能仅仅因为这个启示而停止阅读。但是在你因为这个限制而离开这个页面之前，花点时间在权力BI反馈这个特殊问题的网站。即使你不关心，有一天你可能会，我鼓励你就这个项目投票。去吧，我们等着。
好的,你回来了吗?很好，我们开始吧。
Power BI场景下的行级安全
我们将要探讨的第一个场景是，对每个特定的数据段都有硬编码的角色。对于所有这些场景的演示模型，我生成了遍布全球的数据，并将访问直接连接到各大洲，然后连接到国家。这使得一眼就能很容易地确定数据是否被正确过滤了。Power BI地图可视化是这方面的理想选择，因为您的眼睛可以很容易地确定哪些地理实体由数据表示。稍后我们将再次看到地图，但对于初学者来说，未经过滤的数据地图是这样的:
在设置此数据的安全性之前，我将稍微解释一下这个特定模型的数据结构:它由三个表组成，如下所示:country、customer和salesales。国家表列出了世界上所有的国家，以及它们所在的大陆。另外，该表位于与Customer(在[CountryCode]上)一对多关系的“一端”，而Customer又位于与Sales表关系的“一端”。
如果我们可以将这些国家限制在，比如说，北美，那就会将客户限制在那些位于那里的国家，这就会以一种级联过滤器的方式限制销售。我们最终只看到了面向北美客户的销售。这就像在SQL查询中添加WHERE谓词，过滤如下内容:
SELECT * FROM dbo. dbo。大洲= ' North America '的国家
让我们开始吧。
- 在modeling选项卡上，单击管理角色．
- 单击“创建”以添加新角色，并将其命名为“北美”。
- 在表格下，单击Country旁边的省略号，选择Add Filter，然后选择[Continent]字段
- 编辑表过滤器DAX表达式它产生了“北美”的“价值”
为了测试这个角色，回到造型选项卡上,单击查看为角色．选择北美角色。我得到的地图是这样的:
请注意报告页面顶部的黄色带，它不仅显示了查看数据的安全上下文，而且提供了返回未过滤数据的链接。
我们已经成功地为北美创建了一个安全角色。由于Country表中只有6个不同的大洲，因此为剩下的5个大洲添加额外的角色是一个简单的操作，每个角色都有适当的名称。
在将模型部署到Power BI服务之后，我们还有一些额外的工作。找到模型的数据集，单击它旁边的省略号并选择安全性。在这里您将指定谁在哪个角色中具有成员资格。显然，任何一个角色的成员身份都可以让您查看与该特定大陆相关的数据。没有什么可以阻止您向多个角色添加任何一个名称。正如你可以从下面的截图看到的，我已经添加了一些人到北美的角色。
请习惯这个操作，因为它将在其他两个场景中引用，但不再直接解释，因为操作完全相同。只有角色的名称会更改。
如果在层次结构的顶部(在本例中是大洲/国家/销售)有相对较少的不同值，且该列表不太可能更改，那么这种行级别安全性方法非常有用。值列表中的更改将指示对Roles的相应更改，以及Power BI模型的重新部署。但我想我们在地球上的六大洲至少在另一段时间内是安全的天文数字年左右。
Power BI场景下的行级安全
在这个场景中，我们将从Power BI Service中提取安全角色分配，并将它们保存在数据库层。我们将使用与前面场景相同的模型，减去前面定义的6个角色。这个型号包括一个额外的表格，大陆如下所示:
你可以想象，这个表现在移动到我们事实上的层次结构的顶部，它和国家表之间有一对多的关系，在字段[大陆]:
要在模型中设置安全性，我们将使用管理角色对话框。如果您继续从场景1开始，并且已经添加了Continent表，那么您可以删除之前添加的6个Roles，因为这里不需要它们。但是这一次，“Users”这个单一角色将在Continent表上进行筛选，使用DAX表达式:[UserName] = UserName ()
的达克斯用户名()函数返回登录用户的登录名和域名，格式为
为了测试这种保护数据的方法，我们将再次访问查看为角色按钮造型选项卡，但这次我们将勾选“Users”的Role，并通过提供用户名填充“Other user”选项。如果您还记得上面的Continent表，Eustice被分配到欧洲，所以她只看到欧洲的数据。请注意下面的大陆切片器是如何被过滤到一个值的，而下面的国家切片器也被过滤到Eustice可以访问的国家——那些在欧洲的国家。
在部署模型之后，我们仍然需要像以前一样将电子邮件地址添加到User角色中，但是这次我们需要关注一个角色，因此所有六个名字都可以添加到这个角色中。控制谁可以查看数据库中continent表的行中定义的哪个洲。通过更改或删除名称并将数据刷新到Power BI，我们将更改数据访问权限，而不需要重新部署模型或在站点上调整数据集的安全设置。
当您再次拥有一个清晰定义的自顶向下的层次结构，并且用户的访问是互斥的时候，这个场景非常方便。只有一个人可以进入每个大陆。我预计这将在一个模型中实现，其中销售人员表位于层次结构的顶端，通过过滤销售人员，客户和他们各自的销售也会得到过滤。我们肯定不希望为每个销售人员创建一个角色，重新部署模型，然后像在场景1中那样为每个销售人员分配各自的角色。相反，这种方法使用USERNAME()函数动态地处理安全分配。
请继续关注第2部分，我们将研究第三个场景，它涉及到多个用户、多个组、多个组成员和多个地缘政治区域。