I have a simple master-detail relation in which both entities share an attribute (which happens to be a timestamp, and is not part of the key.) The detail records are ranked (by some other attribute) from top to bottom. The business rule is: (a) If there are detail records, apply the timestamp of the top one to the master; (b) otherwise, the master must have a timestamp regardless; and (c) (rarely) permit the master to have a timestamp that differs from the that of the top detail records. The most common case is (a) and I'd like to avoid duplicating the timestamp in both the master and the top detail. How would you design for this situation? Many thanks
可以将文章内容翻译成中文,广告屏蔽插件可能会导致该功能失效(如失效,请关闭广告屏蔽插件后再试):
问题:
回答1:
A straightforward design is to have tables like
master: [m] is a master & ...
master_dated: master [m] has differing date [d]
detail: "master [m] detail line [l] was on date [d] & ...
You can then reorganize these. Eg replace the first 2 by a left join of them. Something like those ought to be the design you come up with in the first place. If you now have a single master-detail table then presumably it's a select from an inner/natural join of the latter, detail & an aggregation of detail.
master-detail:
( master [m] has differing date [d]
OR master [m] has no differing date
AND [d] = SELECT MAX(d) FROM detail WHERE [m]=m
)
AND [m] is a master & ...
AND master [m] detail line [l] was on date [d] & ...
PS Things are even simpler with master_undated, master_dated & detail. But different tradeoffs.
PS Normalization replaces a table by projections of it that natural join back to it. Moving from your single table to these others reduces certain redundancy but it isn't normalization--evident from the single not being a natural join of the others.