I suggest you keep all components in one table but have a related field so that you can relate different parts to each other.
I would go further than suggested by Johann. I would keep broad details of each component in one table (componentID, Fuel Pump for aircraft X, part no. xxx-yyy-999), but specific stocked items in a separate Stock table (stockID, fk_componentID, serialNo). The Component table gives you a listing of all the types of components in your database, while the Stock table lists each specific instance of each component in stock. This is the time you would then link to a Deployment table which would in turn link to an Aircraft table, so that you could track exactly which item was deployed where and when.
You might consider multiple foreign keys in the parts table. For example you could have a key for current aircraft. Part ( engine ) moves to another aircraft, it is easy to update the location foreign key.
Another key would be a parent component. As your stated, engines have a number of related parts. You can have a parentID so that engine widget X is attached to an engine. Part goes out for maintennce and is replaced by another widget. Change the foreign keys in both records and the new widget is attached to the engine and the original isn't.
All parts are still in the same table, but can be displayed through table occurrences connected by the correct foreign key.