归一化 - 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)
我正在设计一个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)