体育 Collection 数据库

Question

我正在创建一个包含不同运动项目的 collection 数据库，我对 table 和主要 keys/foreign 键组合的使用感到困惑，要求如下:

应该是第三范式或者至少是 3NF。

这里是我想做的事情的完整描述：

为 collection 张卡片设计一个数据库。
您只能购买当前市场价值（购买时）至少为 100.00 美元的卡。你的collection大约1000张卡片
你收集各种运动卡，从足球、篮球、曲棍球等等
您收集的这些卡片是由不同的供应商生产的，例如 ?Topps、Upper Deck、Leaf 和 Panini。
collection跨越collection多年，有些卡片甚至可以追溯到1900年代初，但也有更早制作的卡片
您的卡片状况也各不相同，并且根据 10 分 PSA 评分标准进行评分。 (评分table)
每次购买卡时，您必须知道购买日期、购买成本、购买的市场价值、从谁那里购买、运动、卡上的个人、卡数等
购买完成后，大约一周后将卡片寄出进行评分，您希望能够跟踪卡片寄出进行评分的时间、评分状态、当评级公司 return 收到 returned 卡时，将其分配给卡片。出于税收目的，您还想知道为分级服务（等级 table）
你确实买卖卡，所以你也想知道你卖卡的价格是多少，什么时候卖的，卖给谁，运费（如果适用）和任何相关的与销售交易相关的数据。您可以随意添加您认为对 table.

这是我目前的数据库...我觉得我遗漏了一些东西而且我没有正确地遵循要求

Answer 1

这看起来是个不错的开始。我对您的 tables/structure 有以下观察：

CardSellers：应该只存储有关 CardSeller 的信息；它应该具有的唯一值是 SellerID 和 SellerName

供应商：不应有 CardId

等级: SellerID 不属于这里

卡片：看起来不错

CardBuyers 不应有 DateOfPurchase 或 CostOfCard 或 Shipping Fee；这三个成员属于 CardTransaction。其实"DateOfPurchase"应该是"DateOfTransaction"

此外，由于 Vendor table 应该只存储 Vendor 数据，而 Card table 应该只存储卡数据，因此您还需要一个 M2M（多对多）table 连接两者；这应该有三个成员：ID (PK)、CardId (FK) 和 VendorId (FK)

更新

记住关于 table 设计的两件事：

(0) A table should only contain data about the object its named for and only references to other tables (via a FK - see below)
(1) DRY (Don't Repeat Yourself - IOW, don't store the same data in multiple places; instead, store a link to it, where needed, via FK (Foreign Key) fields referencing PK (Primary Key) fields).

就 table 的实际设计而言，这对我来说很有意义：

CARDS
-----
CardId (PK)
VendorId (FK)
CardFirstName
CardLastName
CardType
CardYear
MarketValue
Rarity
CollectionNumber    

COLLECTORS (Buyers and/or Sellers; no need to have separate tables for them)
---------
CollectorId (PK)
CollectorName
CollectorAddress    

TRANSACTIONS
------------
TransId (PK)
CardId (FK)
BuyerId (FK) <= CollectorId in the Collectors table
SellerId (FK) <= CollectorId in the Collectors table
TransactionDate
Price (if it may differ from CARDS.MarketValue)

GRADE
-----
GradeId (PK)
CardId (FK)
Points
AssignedGrade
Qualifiers
Status
CardFee
GradedDate
ReturnedDate

VENDORSLU ("LU" stands for "Lookup")
---------
VendorId (PK)
VendorName
CARDTYPESLU
-----------
CardTypeID (PK)
CardTypeDescription

RARITYLU
-----------
RarityID (PK)
RarityDescription

您可能会发现还需要添加其他字段，但应该差不多了。您甚至可能需要额外的查找 table，例如 GradeTable 中的 "Qualifiers" 和 "Status"。

您可能还想要一张 SPORTSLU table，然后将 SportId FK 添加到 CARDS table（如果 SportId == 1，则为足球卡，如果为 2，则为篮球卡, &c).

但是请注意，尽管关系数据库非常普遍且具有重要的历史意义，但还有另一种名为 "Non-SQL" 数据库（例如 MongoDB）的动物更 free-form/loosey-goosey/I'好吧，你是 okay/anarchistic，它允许你有记录，或者是 "documents"，它可以在运行中省略或添加它想要的任何成员。关系数据库可以与古典音乐（巴赫、莫扎特等）相提并论，而非 SQL 更像是爵士乐（自由流动、即兴创作）。

顺便说一句，为什么没有提到 Tiddlywinks？足球、棒球等都很好，但没有 Tiddlywinks（或 Bocci Ball，就此而言）?!?

体育 Collection 数据库

Sports Collection Database

database

database-normalization

更新