时间依赖PK？ [英] Time dependant PK?
问题描述
或者与PK中的Nulls有关。这显然是错误的。
好的，在转移到必须赚钱回到免费的一个之后。
管弦乐管理系统。
在ER等级：
活动（音乐会等），一个乐器（乐器），一个乐团
（管弦乐队，乐队等），一种乐器。
这四件事合起来，一个玩家（一个）在
活动中，作为合奏的一部分（可能是一个）演奏一个或多个b $ b或更多的乐器。让我们称之为表演（不是最好的词，但它会做）。
那个实体，表演，似乎有一个很好的标识符 -
球员，合奏，事件。它甚至可能有一个代理键，音乐家。那些具有管弦乐知识的你b $ b你可能会建议办公桌，就像我为一个
做的那样，直到我记得桌面上有2个弦乐员。但
代理键值将类似于''第一单簧管'，''第二单簧管''
等.PK / SK将用作其中一部分联结表中的PK -
musicianInstrument - 使用表格仪器。因为一个音乐家可能会在演唱会上播放更多的乐器。
我认为一切都很好。最后我破解了模型的这个角落。
所以用户正在开始工作。对于这场音乐会，她需要第一小提琴1/1
（第一桌上的球员1，领队），第一小提琴2/1，第一单簧管等。
等每个标签都是独一无二的，可以被认为是一个
代理键。无论发生什么事情，玩家+事件+合奏的PK似乎非常好。
非常正确。在任何特定的音乐活动中，一个玩家只能作为特定合奏的一部分玩一次
。但是她还不知道玩家。
会有一个。我已经在极端情况下对其进行了逻辑测试。第一首
单簧管在去演出的路上被一辆公共汽车碾过。在这种情况下，从数据库中删除了
第一条单簧管唱片 - 那天晚上那张椅子上没有第一个单独的
单簧管演奏者。等等。
但我如何应对以下事实：
1.我希望数据库引擎强制执行RI
2.我想使用看似非常明显的自然键（即使我使用
a正版自动编号作为代理）
3.数据输入时不知道PK的一个字段。
我搜索了档案。关于autonumbers对我的争论太多了！
我考虑过一种前进方式：
性能实际上是与音乐家PK的事件/合奏（如第1页
单簧管，第2单簧管等），作为FK发布在
音乐家/乐器表中。
表现与玩家之间有一个联结表 - 称之为预订。这是从玩家到预订的一对多，从表演到预订的一对一。而那个
的PK是FK的组合。所以一个玩家可能不止一次被预订了各种各样的表现，但是......该死的，没有那个不起作用，因为玩家
然后可以不同活动预订了多次。
有什么想法吗？
TIA，Mike MacSween
2003年12月3日星期三07:14:20 -0000，Mike MacSween
< mi ****** ************@btinternet.com>写道：
[snippage贯穿]一个事件（音乐会等），一个（乐器）的演奏者，一个合奏
（乐团）乐队等乐器。
这四件事结合在一起，一个演奏者（一个人），演奏一个或多个乐器，作为整体的一部分（可能是一个），在一个
事件。让我们称之为表演（不是最好的词，但它会做）。
好的。你可能会考虑是否
<有些词我不能想出>
- >音乐家
- >合奏
在逻辑上类似于
派对（超类型）
- >人（子类型）
- >组织（子类型）
该实体，表现，似乎有一个很好的标识符 -
播放器，合奏，事件。
如果到目前为止我已经了解你，我会想{合奏，活动名称，活动
date}。 （实际上，我认为你需要合奏的超级类型。）某些东西
喜欢迈克的风五重奏，圣诞节与迈克的风等等。 （年度
事件）和2003-12-20事件（今年的活动）。我想，
有时你会知道什么时候会发生，但是你不知道谁会玩b $ b $
但<代理键值将是''第一单簧管'，''第二单簧管''
等。
我认为你的意思是候选人密钥。但是我不确定。
PK / SK将被用作联结表中PK的一部分 -
musicianInstrument - 带有一个表乐器。因为音乐家可能会在音乐会上播放更多的乐器。
我想我到目前为止和你在一起。
我认为一切都很好。最后我破解了模型的这个角落。
所以用户正在开始工作。对于这场音乐会，她需要第一小提琴1/1
（第一桌上的1号球员，领队），第1小提琴2/1，第1单簧管等。
等。每个标签都是独一无二的，可以被认为是代理密钥。无论发生什么事情，玩家+事件+合奏的PK似乎都非常正确。
我想我跟着你，但我不确定我是否同意你的看法。对于我来说，似乎对玩家来说，玩家是一个整体的成员，就像人们是一个组织的员工一样。 （其中人员和组织是超类型派对的子类型。）
在任何特定的音乐活动中，一个玩家只能玩<一旦作为特定合奏的一部分。
[大片，我们等待更多信息]
但玩家可能作为特定合奏的一部分演奏不止一种乐器。 （打击乐器演奏了很多乐器。我
一直想成为打击乐手。）
-
Mike Sherrill
信息管理系统
2003年12月3日星期三16:54:17 -0500，Mike Sherrill
< MS ************* @ compuserve.com>在comp.databases.ms-access中写道：
在任何特定的音乐活动中，一个玩家只能作为游戏的一部分玩一次特别合奏。
[大片，我们等待更多信息]
但玩家可能会演奏多个乐器作为特定乐团的一部分。 （打击乐手演奏很多乐器。我一直想成为打击乐手。）
是的，所以也许迈克（MacSween）意味着音乐家只是扮演一个
乐器在任何给定的时刻，虽然在给定的乐曲中可以播放多个乐器
。但是那会让史蒂夫离开哪里？
Turre？也许pk的另一个组成部分应该是身体部位，并且即使是身体部位的部分也是如此（即一个人嘴巴的左/右侧）/ b $ b $史蒂夫's案例）？
Peter Miller
__________________________________________________ __________
PK解决方案 - Microsoft Access / Jet / SQL数据恢复
免费报价，保证最低价格和最佳结果
www.pksolutions.com 1.866.FILE.FIX 1.760.476.9051
" Mike MacSween" < MI ****************** @ btinternet.com>写在
新闻：3f *********************** @ news.aaisp.net.uk：
< blockquote class =post_quotes>或者与PK中的Nulls有关。这显然是错误的。
好吧，在转移后不得不赚钱回到免费的一个。管弦乐管理系统。
在ER级：
一个事件（音乐会等），一个（乐器）的演奏者，一个
合奏（乐团）乐队等乐器。
这四件事结合起来，一个演奏者（一个人），演奏一个或多个乐器，作为整体的一部分（可能是
一），在一个事件。让我们称之为表演（不是最好的词，但它会做）。
那个实体，表演，似乎有一个很好的标识符 -
播放器，合奏，事件。它甚至可能有一个代理键，''音乐家''。
那些拥有管弦乐知识的人可能会建议桌子，就像我做了一段时间一样，直到我记得有两个弦乐播放器到
一张桌子。但代理键的价值就像''第一单簧管'，''第二单簧管'等.PK / SK将被用作PK的一部分
在交联表中 - musicianInstrument - 带有桌子乐器。
因为音乐家可以在音乐会上演奏更多的乐器。
我认为一切都很好。最后我破解了
模型的这个角落。
所以用户正在开始工作。对于这场音乐会，她需要第一小提琴
1/1（第一桌上的选手1，领队），第一小提琴2/1，第一单簧管等。每个标签都是独一无二的，并且可能被认为是代理关键。无论发生什么事情，玩家+事件+合奏的PK似乎都非常正确。在任何特定的音乐活动中，一个玩家只能作为特定
合奏的一部分进行一次演奏。但她还不知道这名球员。会有一个。我已经在极端情况下对其进行了逻辑测试。在去演出的路上，第一支单簧管被一辆公共汽车降下来。在这种情况下，第一支单簧管
记录将从数据库中删除 - 那天晚上那个椅子里没有第一个单簧管
玩家。等等。
但我如何应对以下事实：
1.我希望数据库引擎强制执行RI
2。我想使用看似非常明显的自然键（即使我使用真正的自动编号作为替代品）
3. PK的一个领域是不知道的数据录入时间。
我搜索了档案。关于自动编号的争论对我来说太多了！
我考虑过的一种前进方式：
性能实际上是与音乐家PK的事件/合奏（如<第一个单簧管，第二个单簧管等），作为FK发布到
音乐家/乐器表。
性能和玩家之间有一个联结表 - 称之为预订。这是从玩家到预订的一对多，但从表现到预订都是一对一的。而那个PK就是FK的组合。所以一名球员可能不止一次为各种表现而被预定，但是......该死的，没有那个没有工作，因为玩家可以多次预订
不同的活动。
任何想法？
TIA，Mike MacSween
我认为你的问题在于选择玩家而不是乐器。
PK。
考虑表现如下：当你想要产生一个
表演，你知道你需要特定的乐器（例如First
小提琴），这就是乐谱中的内容（假设你正在谈论正式的音乐而不是音乐会话） ），而不是扮演它的人。
Bob
Or something to do with Nulls in PK. Which is obviously wrong.
OK, after a diversion of having to earn money its back to the free one. The
orchestral management system.
At the E-R level:
An event (concert etc.), a player (of musical instruments), an ensemble
(orchestra, band et al), an instrument.
These four things combined, a player (one single human being), playing one
or more musical instruments, as part of an ensemble (possibly of one), at an
event. Lets call that a performance (not the best term, but it''ll do).
That entity, performance, seems to have a good identifier -
player,ensemble,event. It might even have a surrogate key, ''musician''. Those
of you with orchestral knowledge might have suggested desk, as I did for a
while, till I remembered that there are 2 string players to a desk. But the
surrogate key values would be something like ''1st Clarinet'', ''2nd Clarinet''
etc. The PK/SK would be used as part of a PK in a junction table -
musicianInstrument - with a table Instrument. Because a musician may play
more that one instrument at a concert.
All well and good I think. At last I''ve cracked this corner of the model.
So the user is starting work. For this concert she needs 1st Violin 1/1
(player 1 on the 1st desk, the leader), 1st Violin 2/1, 1st Clarinet, etc.
etc. Each of those labels will be unique, and could be thought of as a
surrogate key. Whatever happends the PK of player+event+ensemble seems very
very right. At any particular musical event one player can only be playing
once as part of a particular ensemble. But she doesn''t know the player yet.
There will be one. I''ve tested it logically on the extreme cases. The first
clarinet gets mown down by a bus on the way to the gig. In which case the
first clarinet record is deleted from the database - there wasn''t a first
clarinet player in that chair that night. And so on.
But how do I cope with the fact that:
1. I want the database engine to enforce RI
2. I want to use what seems to be a very obvious natural key (even if I use
a genuine autonumber as a surrogate)
3. One field of the PK isn''t known at data entry time.
I had a search of the archives. Too many arguments over autonumbers for me!
One way forward I considered:
Performance is actually, event/ensemble with a PK of musician (as in 1st
Clarinet, 2nd Clarinet etc.) which is posted out as a FK to the
musician/instruments table. And there is a junction table between
performance and player - called it booking. Which is one to many from player
to booking, but one to one from performance to booking. And the PK of that
is a combination of the FKs. So a player might be booked more than once for
various performance, but....damn, no that doesn''t work, because the player
can then be booked more than once for different events.
Any ideas?
TIA, Mike MacSween
On Wed, 3 Dec 2003 07:14:20 -0000, "Mike MacSween"
<mi******************@btinternet.com> wrote:
[snippage throughout]An event (concert etc.), a player (of musical instruments), an ensemble
(orchestra, band et al), an instrument.
These four things combined, a player (one single human being), playing one
or more musical instruments, as part of an ensemble (possibly of one), at an
event. Lets call that a performance (not the best term, but it''ll do).
Ok. You might think about whether
<Some word I can''t come up with>
-> musician
-> ensemble
is logicially similar to
Parties (supertype)
-> Persons (subtype)
-> Organizations (subtype)
That entity, performance, seems to have a good identifier -
player,ensemble,event.
If I''ve understood you so far, I''d think {ensemble, event name, event
date}. (Actually, I think you need "ensemble''s" supertype.) Something
like "Mike''s Wind Quintet", "Christmas with Mike''s Winds" (an annual
event), and "2003-12-20" (this year''s event). I imagine that
sometimes you know when the event will be, but you don''t know who will
play.
But the
surrogate key values would be something like ''1st Clarinet'', ''2nd Clarinet''
etc.
I think you mean "candidate key". But I''m not sure.
The PK/SK would be used as part of a PK in a junction table -
musicianInstrument - with a table Instrument. Because a musician may play
more that one instrument at a concert.
I think I''m with you so far.
All well and good I think. At last I''ve cracked this corner of the model.
So the user is starting work. For this concert she needs 1st Violin 1/1
(player 1 on the 1st desk, the leader), 1st Violin 2/1, 1st Clarinet, etc.
etc. Each of those labels will be unique, and could be thought of as a
surrogate key. Whatever happends the PK of player+event+ensemble seems very
very right.
I think I follow you, but I''m not sure I agree with you yet. It seems
to me like players are members of an ensemble much like persons are
employees of an organization. (Where "persons" and "organizations" are
subtypes of the supertype "parties".)
At any particular musical event one player can only be playing
once as part of a particular ensemble.
[big snip, as we wait for more info]
But the player might play more than one instrument as part of a
particular ensemble. (Percussionists play lots of instruments. I
always wanted to be a percussionist.)
--
Mike Sherrill
Information Management Systems
On Wed, 03 Dec 2003 16:54:17 -0500, Mike Sherrill
<MS*************@compuserve.com> wrote in comp.databases.ms-access:
At any particular musical event one player can only be playing
once as part of a particular ensemble.
[big snip, as we wait for more info]
But the player might play more than one instrument as part of a
particular ensemble. (Percussionists play lots of instruments. I
always wanted to be a percussionist.)
Yes, so perhaps Mike (MacSween) meant that a musician plays just one
instrument at any given moment, although multiple instruments may well
be played during a given piece. But then where would that leave Steve
Turre? Perhaps another component of the pk should be body parts, and
even parts of body parts (ie left/right sides of one''s mouth in
Steve''s case)?
Peter Miller
__________________________________________________ __________
PK Solutions -- Data Recovery for Microsoft Access/Jet/SQL
Free quotes, Guaranteed lowest prices and best results
www.pksolutions.com 1.866.FILE.FIX 1.760.476.9051
"Mike MacSween" <mi******************@btinternet.com> wrote in
news:3f***********************@news.aaisp.net.uk:
Or something to do with Nulls in PK. Which is obviously wrong.
OK, after a diversion of having to earn money its back to the free
one. The orchestral management system.
At the E-R level:
An event (concert etc.), a player (of musical instruments), an
ensemble (orchestra, band et al), an instrument.
These four things combined, a player (one single human being), playing
one or more musical instruments, as part of an ensemble (possibly of
one), at an event. Lets call that a performance (not the best term,
but it''ll do).
That entity, performance, seems to have a good identifier -
player,ensemble,event. It might even have a surrogate key, ''musician''.
Those of you with orchestral knowledge might have suggested desk, as I
did for a while, till I remembered that there are 2 string players to
a desk. But the surrogate key values would be something like ''1st
Clarinet'', ''2nd Clarinet'' etc. The PK/SK would be used as part of a PK
in a junction table - musicianInstrument - with a table Instrument.
Because a musician may play more that one instrument at a concert.
All well and good I think. At last I''ve cracked this corner of the
model.
So the user is starting work. For this concert she needs 1st Violin
1/1 (player 1 on the 1st desk, the leader), 1st Violin 2/1, 1st
Clarinet, etc. etc. Each of those labels will be unique, and could be
thought of as a surrogate key. Whatever happends the PK of
player+event+ensemble seems very very right. At any particular musical
event one player can only be playing once as part of a particular
ensemble. But she doesn''t know the player yet. There will be one. I''ve
tested it logically on the extreme cases. The first clarinet gets mown
down by a bus on the way to the gig. In which case the first clarinet
record is deleted from the database - there wasn''t a first clarinet
player in that chair that night. And so on.
But how do I cope with the fact that:
1. I want the database engine to enforce RI
2. I want to use what seems to be a very obvious natural key (even if
I use a genuine autonumber as a surrogate)
3. One field of the PK isn''t known at data entry time.
I had a search of the archives. Too many arguments over autonumbers
for me!
One way forward I considered:
Performance is actually, event/ensemble with a PK of musician (as in
1st Clarinet, 2nd Clarinet etc.) which is posted out as a FK to the
musician/instruments table. And there is a junction table between
performance and player - called it booking. Which is one to many from
player to booking, but one to one from performance to booking. And the
PK of that is a combination of the FKs. So a player might be booked
more than once for various performance, but....damn, no that doesn''t
work, because the player can then be booked more than once for
different events.
Any ideas?
TIA, Mike MacSween
I think your issue lies in the choice of player instead of instrument in
the PK.
Consider the performance as follows: When you desire to produce a
performance, you know that you need specific instruments (e.g. First
Violin), That is what is in the score ( assuming you are talking formal
music and not a jam session), not the person who plays it.
Bob
这篇关于时间依赖PK？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
