需要在 Tableau 中计算布尔值答案

【问题标题】：Need to count boolean values in Tableau需要在 Tableau 中计算布尔值
【发布时间】：2020-12-26 04:26:32
【问题描述】：

我在 Tableau 中使用 mongo，并且有一个名为“已验证”的布尔值，显示为真与假。

每个用户都可以在他/她的记录中添加“证书”，然后我们使用管理工具将证书标记为已验证：true 或已验证：false。我想显示一个简单的表格，其中包含每个用户的认证数量，然后是另一个包含已验证数量的列。

目前我正在使用“COUNTD([Certifications.Verified])”来计算已验证的数量，但我认为它的计数并不准确。

这只是计算“已验证”的子模式是否以真或假状态存在，因此数字不准确。请注意，在某些情况下，此节点不存在并显示为空。

如果已验证=true，则我需要计数，如果不存在已验证节点，则为 1；如果已验证：false，则为 0。

如何添加逻辑以在 Tableau 中准确计数？

更新：感谢 Mongo 查询，但我正在寻找 Tableau 自定义字段来显示这一点。

【问题讨论】：

标签： tableau-api

【解决方案1】：

您将要在.aggregate() 运算符中使用$cond 管道操作。它允许您根据条件指定您希望返回的内容，在您的情况下是Verified 字段。我不知道您的数据是如何构造的，但我会想象使用这样的东西：

$sum: { $cond: ["$Certifications.Verified", 1, 0] }

如果Verified 对该认证为真，它将返回一个1，这将在$sum 运算符中进行说明。您是想使用 $group 运算符还是 $project 来创建此求和字段，取决于您的偏好/用例。

【讨论】：

对不起。需要明确的是，我并不想在 Mongo 中找到它。我正在使用 Tableau 构建报告，因此我正在寻找一种在 Tableau 中创建自定义字段的方法。
@Otis 我对 Tableau 不太熟悉，但快速搜索发现 this forum response。您可能想尝试类似：SUM(IF [Field]=TRUE then 1 else 0 end)

【解决方案2】：

您可以使用它来返回计数。

schemaName.find({Certifications.Verified : true}).count(function (error,count) { 
  console.log(count);
});

如果证书已验证 = true 存在，则返回非零值（文档不满足条件）否则返回 0

【讨论】：

对不起。需要明确的是，我不想在 Mongo 中找到它。我正在使用 Tableau 来构建报告，因此我正在寻找一种在 Tableau 中创建自定义字段的方法。

【解决方案3】：

用RowID替换你的表键：

COUNTD(IIF([Certifications.Verified]=1, RowID, NULL))

【讨论】：

你所说的“table's Key”是什么意思？比如认证的唯一标识符？
如果不假设您的数据是如何存储的，很难说，但如果每个用户+证书组合都有一个唯一的标识符，那就是它。将 RowID 替换为您实际计算的值。
这真的行不通。基本上它显示的是 1 或 0，而不是所有已验证证书的总和。该结构基本上在verified:true 或false 的证书级别具有模式。如果为 true，则创建一个由 verifyBy:string、verifiedAt:date、notes:string 组成的数组。屏幕截图：imgur.com/a/9KZE5Xr 这个问题是每个证书都没有真正的唯一 ID。
@Otis 分配给配置文件（预验证）时的认证没有获得密钥？
对不起。证书确实获得了密钥。证书验证没有。

【解决方案4】：

COUNTD() 很有用，但在大型数据集上计算效率可能很低，因此不要在更简单、更快的聚合函数同样有效的情况下使用 COUNTD()。

如果你只是想知道有多少条记录满足 From Tableau，只需使用SUM(INT(<condition>)) INT() 类型转换函数将 True 转换为 1，将 False 转换为 0。所以如果您的数据的详细级别每条记录THING，并且您想知道有多少 THING 满足您的条件，只需使用 SUM(INT(<condition>)) 就可以解决问题，比在记录 id 上使用 count distinct 更快。

甚至有一些数据源，比如 MS Access，没有实现 COUNTD()

底线，

SUM(INT()) 是计算满足条件的记录的最简单方法
COUNTD() 非常灵活且有用，但速度可能很慢。对于大型数据集或高性能环境，请考虑重塑数据等替代方案。

顺便说一句，类似的建议适用于 LOD 计算。它们非常有用且灵活，但会带来复杂性和性能成本。必要时使用它们，但不要在更简单、更快的方法就足够时使用它们。我看到很多人只是对所有事情都使用 FIXED LOD 计算，大概是因为它看起来很像 SQL。过度使用会导致解决方案非常脆弱。

【讨论】：