方案如下:
n ownership 1
stocks <-------------------- users
n belong to n
users -----------------------> sectors
n having 1
stocks <---------------------- sectors
我为他们设计了6个表:T_Stocks,T_Users,T_Sectors,T_UserStocks,T_UserSectors,T_SectorStocks,但我认为这不是一个好的设计。如果您对此有任何了解,请与我分享。
答案 0 :(得分:1)
你是对的,这不是一个好的设计。 (抱歉!:P)由于每个stock
只有一个user
作为其所有者,因此您只需在ownerId
表格中添加stocks
列即可。给它一个外键约束,并记得在其上放一个索引!同样,每个sector
只有一个user
,因此您也可以在userId
中拥有sectors
列。 (但这对我来说似乎是倒退;你是否打算以相反的方式建立这种关系?)
但是,此时将sectorId
放入stocks
中断规范化,因为您可以创建其用户与其扇区用户不同的股票。如果你不关心正常化,你可以祈祷你永远不会搞砸了。或者,由于后两个关系的组合意味着第一个,您可以放弃userId
上的stocks
列,并且只有sectorId
。
答案 1 :(得分:1)
如果用户只能拥有他们参与的行业中的股票,那么用户交叉点(n:m)的行业可能不是必需的。用户是否可以在该扇区中但在该扇区中拥有 no 股票?如果一个用户严格依赖于拥有该行业的股票,那么您的模型就会变得更加简单。像这样:
SECTOR
sector_id
, name_of_sector
, ... (anything else about sectors)
STOCK
stock_id
, name_of_stock
, ... (whatever that pertains to the stock as a whole)
, sector_id -- What sector is this stock in?
STOCK_CERTIFICATE
stock_certificate_id
, stock_id -- Which stock is it?
, quantity -- number of shares, etc.
, user_id NULL -- who owns this stock, could be nobody?
USER
user_id
, user_name
, ... (anything else about the user)
现在,如果你想知道谁拥有你在STOCK_CERTIFICATE表中看到多少股票。如果您想知道用户所在的扇区,您可以使用如下查询:
SELECT DISTINCT
A.sector_id
, A.name_of_sector
FROM SECTOR A
INNER JOIN STOCK B
ON A.sector_id = B.sector_id
INNER JOIN STOCK_CERTIFICATE C
ON B.stock_id = C.stock_certificate_id
WHERE
C.user_id = {whatever your user ID is}
如果你想知道哪个用户在给定的扇区中,你也可以做另一个方向的类似的不同选择。
编辑:用户的会计在他们所属的SECTOR中有一个角色......
如果用户通过在该部门中发挥作用参与部门(根据@OP的评论),那么您需要在USER和SECTOR之间建立一个交叉表,如下所示......
USER_ROLE_IN_SECTOR
user_id (PK, FK)
, sector_id (PK, FK)
, role_id (PK, might be FK if you also have a ROLE table...)
这假设用户可以在任何给定的扇区中拥有一个或多个角色。如果用户在任何给定扇区中最多只能有一个角色,则必须在user_id + sector_id上包含唯一约束。如果只有一个用户可以在任何给定的扇区中拥有特定的角色,那么你需要对sector_id + role_id有一个唯一的约束。
这个新表处理的事实是,用户可以参与某些行业而无需在特定行业拥有任何股票。最初提出的其他表格仍然是记录谁拥有哪些股票以及哪些股票属于哪些部门的最佳方式。此模型采用第三范式,因此即使在USER_ROLE_IN_SECTOR表中重复了user_id和sector_id,也没有冗余本身。
如果您想强加一个业务规则,表明用户不能拥有某个行业的股票,除非他们在该行业中扮演某个角色,否则您还需要其他类型的约束。没有干净的方法来做这种类型的约束与普通的香草参照完整性。这是需要进行程序样式检查而不是引用约束的事情。