归一化 - SQL - 3NF

Normalisation - SQL - 3NF

我正在设计一个SQL数据库,需要是5-table数据库才能满足Air-Crewe的要求。到目前为止我有以下内容:

我有 UNF 的这个:

CrewID、Crew Type、Title、Forename、Surname、Gender、CAALicenceNum、FlightID、FlightNum、IATADep、IARAArr、Date、SchDep、SchArr、Comments、A/CType、A/CReg、A/CManuf

我有这个 1NF:

TBLCrew(CrewID[PrimaryKey], CrewType, CrewTitle, Forename, Surname, gender, CAALicenceNum, FlightID*)

TBLFlight(FlightID[PrimaryKey], FlightNumber, IATADep, IATAArr, Date, SchArr, comments, A/CType, A/CReg, A/CManuf)

我有这个 2NF:

TBLCrew(CrewID[PrimaryKey], CrewType, CreweTitle, Forename, Surname, gender, CAALicenceNum)

TBLFlight(FlightID[PrimaryKey], FlightNum, IATADep, IATAArr, Date, SchArr, comments, A/CType, A/CReg, A/CManuf)

TBLCrewFlight(CreweID[composite/compoundKey], FlightID[composite/compoundKey])

3NF 需要分成五个 table,但我不知道如何实现 - 谁能帮帮我?如果我在上面的规范化中犯了错误,或者纠正我(你可能会说我是规范化的新手)

首先 - 我什至不确定第一种形式。 Comments 意味着评论的多个实例,因此它可能不是原子的,我也会为它们制作一个 table。它将具有三个属性 - comment_ID、评论、FlightID。

在第 3 种形式中,table 的每个非素数属性都非传递地依赖于 table 的每个超键。因此,通俗地说,如果您在逻辑上识别依赖于另一个非关键属性的属性,则需要将它们转换为另一个 table.

性别是否取决于名字是有争议的。其他分解有点困难,因为我没有列的描述(不完全确定它们代表什么)。

然而在这里我提出一些我的推测:

  • CrewTitle 可能取决于性别 - bam new table
  • 出发和到达取决于航班号 - bam new table
  • A/C 类型和制造商可能取决于 A/C Reg - bam new table

但是,您应该对各个列有更好的了解,因此您应该自己做出这些决定。这些示例应该可以帮助您理解第三种形式的概念。

我想你实际上快到了。我将飞机信息拆分成自己的 table

Aircraft(CraftId[PimaryKey], A/CType, A/C Rep, A/C Manuf)

然后将飞机分配给航班

AircraftFlight(CraftId, FlightId) [Composite Key]

接受的答案可以有更多的飞机飞行,我认为这是不正确的。

TBLCrew(CrewID[PrimaryKey], CrewType, CreweTitle, Forename, Surname, gender, CAALicenceNum)

TBLFlight(FlightNum[PrimaryKey], IATADep, IATAArr, Date, SchArr, A/CReg[composite/compoundKey])

TBLCrewFlight(CreweID[composite/compoundKey], FlightNum[composite/compoundKey], Comments)

Aircraft(A/CReg[PrimaryKey], A/CType[composite/compoundKey])

TBL_A/CType(A/CType[PrimaryKey], A/C Manuf)