相关疑难解决方法(0)

这个问题与我在其他问题中可以找到的架构有关. 基本上在我的数据库中,我存储用户,位置,传感器等.所有这些都可以由用户在系统中编辑,并且可以删除.

但是 - 当编辑或删除项目时,我需要存储旧数据; 我需要能够在变更之前看到数据是什么.

数据库中还有不可编辑的项目,例如"读数".他们真的更像是一个日志.读数记录在传感器上,因为它是特定传感器的读数.

如果我生成一个读数报告,我需要能够看到读取时位置或传感器的属性.

基本上我应该能够重建任何时间点的数据.

现在,我之前已经完成了这项工作,并通过在每个可编辑表中添加以下列来使其运行良好:

valid_from
valid_to
edited_by

如果valid_to = 9999-12-31 23:59:59则那是当前记录.如果valid_to等于valid_from,则删除记录.

但是,我对我需要用来强制执行外键一致性的触发器感到满意.

我可以通过使用"PostgreSQL"数据库的扩展来避免触发器.这提供了一个名为"period"的列类型,它允许您存储两个日期之间的一段时间,然后允许您执行CHECK约束以防止重叠周期.这可能是一个答案.

我想知道是否有另一种方式.

我见过人们提到使用特殊的历史表,但我真的不喜欢几乎每1个表维护2个表的想法(尽管它仍然可能).

也许我可以砍掉我的初步实施,以不打扰检查不属于"当前"记录的一致性 - 即只懒得去查制约记录中,其中的失效日期9999-12-31 23:59:59.毕竟,使用历史表的人似乎没有对这些表进行约束检查(出于同样的原因,你需要触发器).

有没有人对此有任何想法？

PS - 标题还提到了可审计的数据库.在我之前提到的系统中,总是有edited_by字段.这允许跟踪所有更改,以便我们始终可以看到谁更改了记录.不确定可能会有多大差异.

谢谢.

您喜欢哪种符号,方法和数据库设计,建模,图表工具以及为什么？
哪种符号,标准,方法是最广泛使用和涵盖的不同供应商？
哪个是标准的,哪个不是？
即哪些是坚持和哪些要避免

和PerformaneDBA的个人问题:
为什么你更喜欢IDEF1X？
坚持使用内置于RDBMS的旧客户端工具中的工具,符号是否更为舒适？

更新:
我刚刚阅读了您最有用的数据库标准是什么？.
我很惊讶 - 那里有十几个答案,绝对没有名字或参考,只有冗长的描述.
是否所有数据库开发人员都使用定制的术语和约定？

我更新了标题,包括"名称",不包括"方法".
我要求的是名称(可能是参考)而不是描述.
符号,例如,UML,IDEF1X.巴克,信息工程

好吧,我主要是SQL Server dev,正如@dportas所提到的,我在SSMS和msdn docs,书籍,文章的图表中看到了一些符号.

在尝试学习数据存储的艺术时,我一直在尝试尽可能多地获取可靠的信息.PerformanceDBA在以下帖子中发布了一些非常有用的教程/示例:我的数据是否已标准化？和关系表命名约定.我已经在这里询问了这个模型的子集问题.

因此,为了确保我理解他提出的概念,我在其他地方看到过,我想进一步采取一两步,看看我是否掌握了这些概念.因此这篇文章的目的,希望其他人也可以学习.我所呈现的一切都是对我和学习的概念,而不是在某些生产系统中应用它.自从我使用他的模型开始以来,从PerformanceDBA获得一些输入会很酷,但我很欣赏任何人提供的所有输入.

由于我是数据库的新手,尤其是建模,我将首先承认我可能并不总是提出正确的问题,清楚地解释我的想法,或者由于缺乏关于该主题的专业知识而使用正确的问题.因此,请记住这一点,如果我偏离轨道,请随时引导我朝正确的方向前进.

如果对此有足够的兴趣,我想从逻辑到物理阶段采取这种方式来展示过程的演变并在Stack上分享它.我将为逻辑图保留此线程,并为其他步骤启动新线程.根据我的理解,我将最终构建一个MySQL数据库来运行一些测试,看看我想出的是否真的有用.

以下是我想在此概念模型中捕获的内容列表.编辑V1.2

1. 这样做的目的是列出乐队,他们的成员,他们将出现的活动,以及提供音乐和其他商品出售
2. 会员将能够与朋友匹配
3. 会员可以在乐队,他们的音乐和他们的活动上撰写评论.
   • 每个成员在给定项目上只能进行一次审核,尽管他们可以编辑他们的评论并保留历史记录.
   • BandMembers将有机会撰写关于他们所关联乐队的评论的单一评论.作为乐队,每次评论只允许一个评论.
   • 然后,成员可以对所有评论和评论进行评级,但每个给定的实例仅评
4. 会员可以选择自己喜欢的乐队,音乐,商品和活动
5. 乐队,歌曲和事件将被分类为它们所属的类型,然后在必要时进一步细分为SubGenre.Band或Event可以归入多个Genre/SubGenre组合.
6. 将为特定乐队发布活动日期,时间和地点,会员可以显示他们将参加活动.活动可以由多个乐队组成,多个活动可以在同一天的单个地点举行
7. 每一方都将至少与一个地址绑定,并保留地址历史记录.每个方也可以一次绑定多个地址(即计费,运输,物理)
8. 将存储Bands,BandMembers和一般成员的配置文件.

所以它可能有点涉及,但对于许多人来说可能是一个很好的学习工具,因为这个过程在不断发展,社区也会提供意见.有什么输入？

编辑v1.1 响应PerformanceDBA

U.3)这意味着数据库中没有Band商品以外的商品.正确吗？ 这是我最初的想法,但你让我思考.也许该网站想要出售自己的商品甚至是乐队的其他商品.不确定为此做出的模式.它是否需要对目录部分进行整个返工,或者只需要与乐队存在的识别关系？试图销售完整的专辑或歌曲的mod.无论哪种方式,它们都是电子格式,只能下载.这就是为什么我将专辑列为由歌曲组成而不是两个独立的实体.

U.5)我理解你提出的关于与Favorite的循环关系的内容.我想谈谈这个"它是一个具有某种形式的差异的实体(FavoriteType),它确定了它的处理方式"但我怎么不清楚.我在这里错过了什么？

u.6) "业务规则这可能是你唯一的弱点."
感谢您的诚实回应.我将重新阅读这些内容,但我希望首先通过回复给您的回复清除我脑中的一些疑惑.

Q.1)是的我希望接受,拒绝和阻止.我不确定你指的是如何改变逻辑模型？

Q.2)一个人不一定是用户.它们只能作为BandMember存在.那是你在问什么？

次要问题

零,一个或多个...哎呀我承认我在构建模型时忘记了这个注意事项.我按原样提交此版本,并将在未来版本中解决.我需要阅读更多关于约束检查的内容,以确保我理解事物.

M.4)取决于您将来是否设想OrderPurchase.你能扩展一下这里的意思吗？

编辑V1.2 响应PerformanceDBA输入...

得到教训.

1. 我正在混合识别/不识别和基数(即类型/子格)的概念,并且这样做不一致,使事情变得更糟.
2. 逻辑图中不需要关联表,因为它们可以描述多对多关系,然后在物理模型中进行扩展.
3. 在很多关系中我忽略了基数
4. 使用有效的动词短语来阅读关系的重要性,以确保我正在模拟我想要完成的事情.

U.2) 在该模型的概念中,只需要将场地作为事件的位置进行跟踪.无需收集更多数据.据说,活动将在特定的EventDate上进行,并将在场地举行.场地将在给定日期举办多个活动和可能的多个活动.在我的新模型中,我的想法是EventDate已经与Event绑定.因此,Venue不需要与EventDate建立关系.你在U.2)下列出的第5和第6发子弹让我质疑我的想法.我在这里错过了什么吗？

U.3)是时候将Item和Band之间的链接移动到Item和Party了吗？根据目前的设计,我没有看到有可能出售与你乐队无关的商品.

U.5)我按照你的输入离开,而不是使它成为一个离散的超类型/子类型关系,因为我没有看到这种类型的卷起的好处.

其他修订

AR.1)在完成对FavoriteItem的练习之后,我觉得要审核的项目需要多对多关系才能显示出来.必要？

好的,我们去v1.3

我在这个版本上花了几天时间,按照我的设计来回走动.一旦逻辑过程完成,我想看看我是否走在正确的轨道上,我将深入了解我所学到的知识以及我作为初学者在整个过程中遇到的麻烦.这个版本的重点是投入了一些密钥以帮助看到我过去缺少的东西.经历矩阵的过程也证明了它的巨大帮助.无论如何,如果不是因为PerformanceDBA提供的输入,我仍然会是一个在黑暗中琢磨的失落的灵魂.谁知道我现在的设计可能会重申我仍然是,但我学到了很多,所以我知道我手里至少有一个手电筒.

在这个时候,我承认我仍然对识别和非识别关系感到困惑.在我的模型中,我不得不使用非空值的非标识关系来加入我想要建模的关系.在阅读这个主题时,似乎在这个问题上存在很多分歧和犹豫不决,所以我做了我认为在我的模型中代表正确事物的东西.何时强制(识别)和何时自由(不识别)？有人有投入吗？

编辑V1.4

Ok拿了V1.3输入并清理了这个V1.4

目前正在开发V1.5以包含属性.

编辑V1.6

好吧,自从我在这里发布以来已经有一段时间了但是这个项目的工作仍在进行中.我现在正在发布V1.6,其中包括V1.4上次发布的一些更改.此版本显示了Keys的进一步发展.它仍然不包括属性或任何AK或IE.我已经开始研究物理模型,并使用它来帮助处理属性,并尝试阐明我在定义AK和IE时遇到的问题.逻辑模型的下一个发布将包括这些键和属性.

我正在制作一个简单的测验数据库,其中一个问题有一个答案和一个或多个图像文件,属于一个子主题,而该子主题又属于一个主题.此外,每个组可能属于三个级别之一.

这就是我设置数据库的方式:

QUESTION
-------------------
question_id      pk
question    varchar
answer      varchar
subtopic_id foreign_key

MEDIA
-------------------
media_id         pk
file_name   varchar
question_id foreign_key


SUBTOPIC
-------------------
subtopic_id      pk
subtopic    varchar
topic_id    foreign_key


TOPIC
-------------------
topic_id         pk
topic       varchar
level       choices(1,2,3)

我的数据库设计得当吗？如果没有,我怎样才能让它变得更好？

编辑:我希望显示一个问题(和图像,如果存在),并将用户的答案与正确答案进行比较.我需要主题和子主题才能显示正确的问题.

Edit2:添加了你的建议.

Edit3:更新了数据库描述.

请看一下这个图:

一些说明:

1. 级别可以具有唯一(主题1和3)和共享(主题2)主题.
2. 主题可以包含一个或多个子主题,但子主题不能属于多个主题.
3. 子主题可以有一个或多个问题,但问题只属于一个子主题.两个问题(问题2和3)可能具有相同的子主题和主题,但它们的级别可能不同.虽然,主题(主题2)和副主题(子主题2和3)可能属于许多级别(级别1和级别2),但某些子主题仅包含级别1的问题,而其他子主题包含级别2的问题(问题4)(子主题3) .
4. 一个问题只能有一个答案,答案不能属于另一个问题.
5. 答案(或它的问题)可以有一个可选的图像文件,该图像文件可以用于其他问题.

谢谢.

我有一个建模数据库来存储一些Java对象的问题(将对象映射到关系数据库的经典问题).一个例子远比长描述好,这就是东西.

可用类列表:
- A类包含双精度数组
- B类包含A数组
- C类包含B数组和A数组(它可以继续...)

所有对象实现相同的父对象(比如说StorableObject).可以有尽可能多的组合.

如何存储所有这些值,而且,如何使用某些FK创建模型,删除父对象时删除其所有子项.我的意思是,由于孩子们可以存储在各种表格中,所以我无法在父母的字段上放置简单的FK.

谢谢 ;)