问题
并非所有用户都可以查看所有数据，这在构建报告时通常是必需的。与其根据用户可以看到和看不到的内容创建不同的报告，不如在Power BI中利用行级安全性 ？
解
随着来自许多来源的数据的不断增长，安全性已成为每个人的主意。拥有大量数据，我们需要就用户可以查看和不能查看哪些数据创建指南。Power BI中的安全性有几种不同的形式。首先，需要许可证（专业版与高级版）才能访问云中的Power BI服务（或Power BI Report Server中相关的本地资源）。接下来，必须授予对数据集，报告的访问权限，并且更适当地，应授予包含仪表板，报告和数据集的应用程序访问权限。此访问级别的重点是对整个应用程序及其报告或仪表板的访问。这种访问类似于授予文件系统中特定文件夹的权限。您可以访问该文件夹，也可以没有。
此外，还可以在各个工作空间内分配权限。但是，工作区权限通常集中在工作区中的成员和贡献者（编辑），查看者和管理员权限上，与行级权限没有直接关系。相反，成员和贡献者权限使报表使用者可以在Power BI Service中实际编辑报表（这又意味着他们可以调整行级别安全性选项）。相反，查看者权限允许用户仅查看工作空间和相关报告（而非数据集），但该同一用户无法在工作空间内编辑报告。最后，管理员角色允许用户完全管理工作区，包括对其进行更新和删除。再次，
数据集级别的最后访问层围绕行级别的安全性。尽管有点用词不当，因为它并不是真正的行级（由于可能的聚合，例如在数据级），但行级安全功能通过提供一种限制数据访问的方式在逐行级上起作用级别基于数据集中的特定值。当然，通过这种访问方式，确实存在一些限制，我们将在本文的稍后部分概述这些限制。在上一个技巧中，我们概述了根据为每个我们要限制访问的数据类别区域创建的角色来设置行级安全性。例如，我们可以根据销售地区创建角色；那么我们可以在Power BI Service中将用户或AD组分配给这些角色。 该技巧已在本技巧中概述。
在本技巧中，我们将行级安全性切换为动态使用已登录Power BI服务的用户，并将其与表中的值进行比较。将该用户与数据库中的表进行交叉引用，以确定该用户将有权访问哪些数据点（行）。尽管此概念与固定角色方法相似，但是可以从将访问数据插入数据库中的表的其他基于安全性的系统中删除该方法。与固定角色方法相反，有些人将此方法称为动态或数据库角色级别的安全性。此外，固定方法要求在Power BI文件中预定义每个角色（或在事后要求进行更改），而基于表的方法仅需要更新或插入表中即可进行更改。
了解使用基于表的行级安全性的好处的最佳方法是通过示例。在开始之前，您应该下载最新版本的Power BI桌面。我们还将使用WideWorldImportersDW数据库作为我们的数据源，可以从 此处下载 。有关将数据导入Power BI的更新， 请查看此技巧。
我创建了Power BI报表，并在报表中添加了两个选项卡。第一个选项卡包含一个条形图和切片器，第二个选项卡包含一个矩阵和另一个条形图，如以下两个屏幕截图所示。
现在已经设置了报告，下一步是识别与报告进行交互的用户。在Power BI中，两种不同的DAX功能可提供用户信息：
- 用户名（）
- USERPRINCIPALNAME（）
USERNAME（）提供在Power BI Desktop中连接到Power BI的用户的域名和用户名。该信息以域/用户名的格式返回，类似于在大多数Active Directory网络中看到的信息。相似但不完全相同，USERPRINCIPALNAME（）还以“域/用户名”格式提供Power BI Desktop中的用户信息。但是，这两个功能都提供了在联机查看报告或仪表板时连接到Power BI Services的用户的登录电子邮件地址。这些值不久将很重要。
要查看这两个函数返回的实际值，我们将首先在事实表中添加新列。
第一个字段是UserName_Login，它仅使用USERNAME（）函数。
要添加的第二个字段检索USERPRINCIPALNAME（）DAX函数。
将一个简单的表添加到设计网格中，然后将这两个字段添加到该表中，如下所示，以显示Power BI Desktop格式。
在线查看相同的报告显示，这两个字段都返回在线登录Power BI服务的用户的电子邮件地址。
接下来，我们需要创建数据库后端，以提高行级安全性。该表至少需要包含两个项目：1）用户名和2）将区分访问权限的相关类别值。用户名必须与Power BI服务上解析的用户名匹配。希望您现在可以看到为什么我们显示了用户名和用户主名称DAX函数的两个视图。用户名应反映user@organization.com 的电子邮件格式 。类别字段是区分用户访问权限的项目。可能是分支机构，销售区域或部门之类的东西。该值可以是文本或某些标识整数。这将取决于正在使用的事实表中的数据。
在下面的示例中，我们创建了一个简单的用户权限表，该表包括一个名为User_Key的整数ID列，一个名为User_Name_ID的电子邮件用户名字段，最后是一个适当地称为Sales_Territory的销售地区字段。
创建表后，现在必须使用需要访问权限的适当用户填充该表。在下图中，我们添加了一些示例用户及其相关的销售区域。
请注意，每个访问数据点都需要一行。因此，如果用户需要访问3个销售区域，则使用我们的示例，必须为每个用户销售区域组合插入一行。当然，有很多方法可以从活动目录或其他应用程序自动填充表。如果您有很多用户，则此设置当然可以快速增长。
此时，我们必须切换回Power BI桌面。新创建的用户权限表必须添加到模型中。
最后，必须设置事实表或类别维度与用户权限表之间的关系。如下图所示，将在Dimension City表中的Sales Territory和用户权限表中的Sales region之间创建联接。
在Power BI Desktop中的最后一步，我们还必须创建一个角色，该角色检查Dimension User_Provision表中的User_Name_ID，并将其与对DAX UserName函数的调用进行比较。
根据围绕DAX功能如何解析Power Bi Desktop中用户名的上述详细信息，您可能会猜测基于Power BI Desktop中用户名测试角色不会解析为权限表中列出的正确用户名。请记住，Power BI Desktop解析为域/用户名，而服务解析为username@organization.com。 因此，要完成设置过程，必须将Power BI文件发布到Power BI服务。
发布到Power BI Service之后，我们还有一个步骤完成行级安全性过程。要完成此过程，首先，您将转到工作区，找到报表数据集，然后转到“安全性”。
在“行级安全性”屏幕上，您将需要添加任何用户，或更适当地添加应访问报告的任何通讯组列表或组。此列表仅允许Power BI服务查看用户列表，并且不授予对数据的访问权限。
最后，我们可以使用“行级安全性”屏幕中的“角色测试”来测试访问权限。
在数据库中，我的用户ID与“东南”和“平原销售地区”（两行）相关联。如以下屏幕截图所示，仪表板报告仅向我显示东南和平原销售地区的数据。您会注意到State Province Slicer也已适当过滤。
信息中心中的第二个标签也仅显示了两个已分配的销售地区。
使用基于表的行级安全性可为Power BI仪表板的安全性基础架构增加额外的灵活性。此方法允许限制用户查看敏感数据的更可扩展的方法，并且可以与其他安全过程集成。