问题标签 [cardinality]

是否可以确定 c++ 的基数enum class：

我尝试使用sizeof，但是，它返回枚举元素的大小。

有没有获得基数的标准方法（在我的示例中为 5）？

所以，我已经在 stackoverflow 上阅读了很多答案，但我仍然对其整个概念感到困惑。具体来说，我已经阅读了这篇文章（包括它引用的所有文章），但似乎无法很好地掌握这个概念（或者可能是我在基数（n:m 等）和身份之间的混淆):

仍然对识别与非识别关系感到困惑

我的问题是：我知道识别关系意​​味着子实体的主键必须包含其外键，而非识别关系则相反（这是正确的吗？）。现在，这对我来说似乎有点太“前瞻性”了？在其中一个链接的其中一条评论中也说了同样的话。我怎样才能“退后一步”并真正看到哪些关系属于哪个身份？

例如，我有两个困境：

1. job_title（父母，1）到employee（孩子，1..*）。我的想法是否正确，因为 job_title 是一个查找表，它必须是一个非识别关系？或者说“没有职称就不能存在员工，因此它必须是识别”会更准确吗？或者是定义该场景的关系？
2. employeeto employee_equipment（m:n 基数之间的桥接实体） to equipment。现在，我读到这必须是employee_equipment 双方的识别关系。但是，如果员工不需要设备怎么办？可以有一个可选的识别关系吗？

我想我真的在寻找一种方法来确定应该属于哪些身份表，而不考虑主键/外键，或者任何与此相关的真正技术性的东西。

任何帮助将非常感激！

我在学校学习数据库系统的测试，我在互联网上没有找到类似的例子，我不确定。跟随关系的基数是什么？

我会说1：1。我的一些朋友说1：M。我对吗？

我一直在想：ET1 使用 atr3(FK) 与 ET2 紧密耦合，但也有自己的 atr1(PK)。所以 ET2:ET1 是 1:M。但是在 ET2 中存在 atr1(FK)，这种关系在我看来就像具有 ET1 的 ET2 只能与其 ET1 中的一个完全链接，因此结果关系应该是 1:1。

你怎么看 ？

非常感谢你们。

我们有一个Claim实体，可以通过a EmailVerification、放在MetaCode相关网站或上传来证明CertificateFile。现在的问题是，索赔人可以选择使用上述方法的任意组合来证明他们的索赔，但在每个类别中他们只获得了一次机会。意义 ：

所以这是有效的：

还有这个：

但不是这个：

因为#43 与两个EmailVerifications 有关。

现在我被困在表模式中，因为我不知道如何最好地建模0..1关系：

• 四个带有人工 PK（整数 id）的单独表，并像往常一样使用 1..* 关系
• 四个单独的表，但只有一个有一个id，另外 3 个使用这个id作为他们自己的 PK 和 FK 到Claim表？
• 只需将其他 3 个表聚合到Claim表中并用于Null指示缺乏关系？
• 别的东西？

编辑 看起来问题不是很清楚：一行Claim可以连接到 0（根本不连接）或其他 3 行中的任何一行，但任何单行不能Claim连接到超过一行任何其他 3 个表（如示例中的第 3 种情况）。

编辑一个可怕的错字潜伏在阴影中（Claim #34在每个示例的第一行错误地输入为Claim #43）！. 真对不起。顺便说一句，我认为正确的答案仍然成立。

I have the following issue. We are currently working on a system for a shuttle service company. Now, part of the entities in the database for this system include numerous lookup tables (such as vehicle_type, employee_status, etc), as well as some other tables, such as vehicle and vehicle_service log.

Now the issue we as a team are having is that we cannot agree on what the logical relationship cardinalities between entities should be. The two main problem relationships include the tables defined as follows:

which is linked to

The user table includes other irrelevant data. So the issue here is that I say (because MySQL Workbench reverse engineered it that way and it makes more sense) that the relationship should be 1-many, while another team member says that it should be 0-many (because some records may exist in the user_type table that aren't used in the user table)

The other table relationship we are having words about are defined as follows:

Again, with some other columns not relative to the question. This links with

Should this be 1-many or 0-many because a vehicle may not yet go in for a service? According to me it should be 1-many, but I don't know if this works logically.

We are all very confused about this whole logical modelling thing, so any help would be much appreciated!

I figured it would be easier for me to create the DB first and then reverse engineer it to a physical model, but never though about logical.

我有一个名为thetas包含大约 270 万个观测值的数据框。

我想使用ddply或一些类似的函数来求和估计误差（estError我的数据框中的列），但总和在我的模拟的每个条件内。问题是，我没有一种简单的方法来组合来自该数据框其他列的值来唯一标识所有这些条件。更具体地说：该列model包含 7 个可能的值。这些可能值中的三个仅与 和 中的一个可能值匹配rho_cnd，pct_cnd而 的其他四个可能值与和model中的 6 个可能的值对匹配。rho_cndpct_cnd

我知道，显而易见的解决方案是返回并创建一个变量来唯一标识我需要在此处标识的所有条件，以便以下代码可以工作：

但我只是不想回去重新创建这个数据框是如何构建的。现在我有两个数据框，通过两个单独的调用创建，然后对expand.grid它们进行rbind编辑和排序以创建一个列出所有有效条件的数据框，但即使我保留了那几行代码，我也不确定如何引用它们ddply. 我什至宁愿不使用这个解决方案，但如果有必要我会。

关于更好的代码和/或更高效率的任何建议？谢谢！

不久前，我开始优化 mysql db 的查询。我创建了一些索引并决定使用语法中的show index查看它们的参数。并看到基数不等于某些列的不同计数。

所以，我有桌子

在那个表中，我有 2M 行（实际上是 2M uniq PK）、500k uniq item_id、5 uniq status_id 和 20 uniq type_id

但是当我执行

我有

然后我决定执行

在这个输出之后是：

有谁知道这怎么可能？，因为我真的误解了为什么基数不等于 uniq 行数，即使是 PK 索引。

我正在从我的数据库生成代码（模型）。如果可能的话，我不确定如何设置我的数据库以创建包括基数的关系。这是可以做到的，还是因为我进行了数据优先设计，所以我只是坚持生成与没有关系或基数的表匹配的模型？

哦，如果我使用了不正确的术语，基数是关系的类型（一对一，一对多，多对多）。这样，我的模型将参考另一个模型或ICollection<T>模型生成。

例如：

我想一劳永逸地知道如何编写 UML 基数，因为我经常不得不就它们进行辩论（所以非常欢迎证明和来源：）

如果我想解释aMother可以有几个Children但aChild有一个且只有一个Mother，我应该写：

或者

?

我有这个类结构：

公共类活动{

这给了我这个模型

每条消息（活动、文件或行）都必须与活动相关联。为什么 2nd 和 3rd 级别的基数与 ActivityLogMessage 不同？我描述外键关系的尝试（通过模型构建器流畅）也失败了。

这对我来说真的是一个学术练习，让我真正了解 EF 如何映射到关系，这让我感到困惑。

问候，理查德