De acordo com sua descrição do ambiente de negócios em consideração, existe uma estrutura de supertipo-subtipo que engloba Item —o supertipo— e cada uma de suas Categorias , ou seja, Carro , Barco e Avião (juntamente com mais dois que não foram divulgados) — os subtipos—.

Vou detalhar abaixo o método que eu empregaria para gerenciar esse cenário.

Regras do negócio

Para começar a delinear o esquema conceitual relevante, algumas das regras de negócios mais importantes determinadas até agora (restringindo a análise apenas às três categorias divulgadas , para manter as coisas o mais breves possível) podem ser formuladas da seguinte forma:

• Um usuário possui zero-um-ou-muitos itens .
• Um Item pertence a exatamente um Usuário em um instante específico.
• Um Item pode ser propriedade de um-para-muitos Usuários em pontos distintos no tempo.
• Um Item é classificado por exatamente uma Categoria .
• Um Item é, em todos os momentos,
  • ou um carro
  • ou um barco
  • ou um avião .

Diagrama IDEF1X ilustrativo

A Figura 1 exibe um diagrama IDEF1X ¹ que criei para agrupar as formulações anteriores junto com outras regras de negócios que parecem pertinentes:

Supertipo

Por um lado, Item , o supertipo, apresenta as propriedades ^† ou atributos comuns a todas as Categorias , ou seja,

• CategoryCode —especificado como FOREIGN KEY (FK) que faz referência a Category.CategoryCode e funciona como um discriminador de subtipo , ou seja, indica a Categoria exata de subtipo com a qual um determinado Item deve ser conectado—,
• OwnerId —diferenciado como um FK que aponta para User.UserId , mas atribuí a ele um nome de função ² para refletir suas implicações especiais com mais precisão—,
• Foo ,
• Barra ,
• Baz e
• DataDataCriada .

Subtipos

Por outro lado, as propriedades ^‡ que pertencem a cada categoria particular , ou seja,

• Qux e Corge ;
• Grault , Garply e Plugh ;
• Xyzzy , Thud , Wibble e Flob ;

são mostrados na caixa de subtipo correspondente.

Identificadores

Então, a Item.ItemId PRIMARY KEY (PK) migrou ³ para os subtipos com diferentes nomes de função, ou seja,

• CarId ,
• BoatId e
• PlaneId .

associações mutuamente exclusivas

Conforme ilustrado, há uma associação ou relacionamento com uma razão de cardinalidade de um para um (1:1) entre (a) cada ocorrência de supertipo e (b) sua instância de subtipo complementar.

O símbolo de subtipo exclusivo retrata o fato de que os subtipos são mutuamente exclusivos, ou seja, uma ocorrência de Item concreto pode ser suplementada por uma única instância de subtipo: seja um Carro , ou um Avião , ou um Barco (nunca por zero ou menos, nem por dois ou mais).

_{^{† , ‡} Empreguei nomes de espaços reservados clássicos para autorizar algumas das propriedades do tipo entidade, pois suas denominações reais não foram fornecidas na pergunta.}

Layout de nível lógico expositivo

Conseqüentemente, para discutir um projeto lógico expositivo, deriguei as seguintes instruções SQL-DDL com base no diagrama IDEF1X exibido e descrito acima:

-- You should determine which are the most fitting 
-- data types and sizes for all your table columns 
-- depending on your business context characteristics.

-- Also, you should make accurate tests to define the 
-- most convenient INDEX strategies based on the exact 
-- data manipulation tendencies of your business context.

-- As one would expect, you are free to utilize 
-- your preferred (or required) naming conventions. 

CREATE TABLE UserProfile (
    UserId          INT      NOT NULL,
    FirstName       CHAR(30) NOT NULL,
    LastName        CHAR(30) NOT NULL,
    BirthDate       DATE     NOT NULL,
    GenderCode      CHAR(3)  NOT NULL,
    Username        CHAR(20) NOT NULL,
    CreatedDateTime DATETIME NOT NULL,
    --
    CONSTRAINT UserProfile_PK  PRIMARY KEY (UserId),
    CONSTRAINT UserProfile_AK1 UNIQUE ( -- Composite ALTERNATE KEY.
        FirstName,
        LastName,
        GenderCode,
        BirthDate
    ),
    CONSTRAINT UserProfile_AK2 UNIQUE (Username) -- ALTERNATE KEY.
);

CREATE TABLE Category (
    CategoryCode     CHAR(1)  NOT NULL, -- Meant to contain meaningful, short and stable values, e.g.; 'C' for 'Car'; 'B' for 'Boat'; 'P' for 'Plane'.
    Name             CHAR(30) NOT NULL,
    --
    CONSTRAINT Category_PK PRIMARY KEY (CategoryCode),
    CONSTRAINT Category_AK UNIQUE      (Name) -- ALTERNATE KEY.
);

CREATE TABLE Item ( -- Stands for the supertype.
    ItemId           INT      NOT NULL,
    OwnerId          INT      NOT NULL,
    CategoryCode     CHAR(1)  NOT NULL, -- Denotes the subtype discriminator.
    Foo              CHAR(30) NOT NULL,
    Bar              CHAR(40) NOT NULL,
    Baz              CHAR(55) NOT NULL,  
    CreatedDateTime  DATETIME NOT NULL,
    --
    CONSTRAINT Item_PK             PRIMARY KEY (ItemId),
    CONSTRAINT Item_to_Category_FK FOREIGN KEY (CategoryCode)
        REFERENCES Category    (CategoryCode),
    CONSTRAINT Item_to_User_FK     FOREIGN KEY (OwnerId)
        REFERENCES UserProfile (UserId)  
);

CREATE TABLE Car ( -- Represents one of the subtypes.
    CarId INT          NOT NULL, -- Must be constrained as (a) the PRIMARY KEY and (b) a FOREIGN KEY.
    Qux   DATE         NOT NULL,
    Corge DECIMAL(5,2) NOT NULL,   
    --
    CONSTRAINT Car_PK         PRIMARY KEY (CarId),
    CONSTRAINT Car_to_Item_FK FOREIGN KEY (CarId)
        REFERENCES Item (ItemId),
    CONSTRAINT ValidQux_CK    CHECK       (Qux >= '1990-01-01')   
);

CREATE TABLE Boat ( -- Stands for one of the subtypes.
    BoatId INT      NOT NULL, -- Must be constrained as (a) the PRIMARY KEY and (b) a FOREIGN KEY.
    Grault SMALLINT NOT NULL,
    Garply DATETIME NOT NULL,   
    Plugh  CHAR(63) NOT NULL, 
    --
    CONSTRAINT Boat_PK         PRIMARY KEY (BoatId),
    CONSTRAINT Boat_to_Item_FK FOREIGN KEY (BoatId)
        REFERENCES Item (ItemId),
    CONSTRAINT ValidGrault_CK  CHECK       (Grault <= 10000)  
);

CREATE TABLE Plane ( -- Denotes one of the subtypes.
    PlaneId INT      NOT NULL, -- Must be constrained as (a) the PRIMARY KEY and (b) a FOREIGN KEY.
    Xyzzy   BIGINT   NOT NULL,
    Thud    TEXT     NOT NULL,  
    Wibble  CHAR(20) NOT NULL, 
    Flob    BIT(1)   NOT NULL,   
    --
    CONSTRAINT Plane_PK         PRIMARY KEY (PlaneId),
    CONSTRAINT Plane_to_Item_PK FOREIGN KEY (PlaneId)
        REFERENCES Item (ItemId),
    CONSTRAINT ValidXyzzy_CK    CHECK       (Xyzzy <= 3258594758)
);

^{Isso foi testado neste db<>fiddle rodando no MySQL 8.0.}

Conforme demonstrado, o tipo de superentidade e cada um dos tipos de subentidade são representados pela tabela base correspondente.

As colunas CarId, BoatIde PlaneId, restritas como as PKs das tabelas apropriadas, ajudam a representar a associação um-para-um em nível conceitual por meio de restrições FK ^§ que apontam para a ItemIdcoluna, que é restrita como a PK da Itemtabela. Isso significa que, em um “par” real, as linhas do supertipo e do subtipo são identificadas pelo mesmo valor de PK; assim, é mais do que oportuno mencionar que

• (a) anexar uma coluna extra para conter valores substitutos controlados pelo sistema ^‖ para (b) as tabelas que representam os subtipos é (c) totalmente supérfluo .

_{^§ Para evitar problemas e erros relativos às definições de restrições (especialmente FOREIGN) KEY —situação que você mencionou nos comentários—, é muito importante levar em conta a existência-dependência que ocorre entre as diferentes tabelas em questão, conforme exemplificado em a ordem de declaração das tabelas na estrutura DDL expositiva, que também forneci neste db<>fiddle .}

_{^Por exemplo, anexar uma coluna adicional com a propriedade AUTO_INCREMENT a uma tabela de um banco de dados construído em MySQL.}

Considerações sobre integridade e consistência

É importante ressaltar que, em seu ambiente de negócios, você deve (1) garantir que cada linha de “supertipo” seja sempre complementada por sua correspondente “subtipo” correspondente e, por sua vez, (2) garantir que o referido linha “subtipo” é compatível com o valor contido na coluna “discriminador” da linha “supertipo”.

Seria muito elegante impor tais circunstâncias de maneira declarativa , mas, infelizmente, nenhuma das principais plataformas SQL forneceu os mecanismos adequados para fazê-lo, até onde eu sei. Portanto, recorrer ao código processual dentro de ACID TRANSACTIONS é bastante conveniente para que essas condições sejam sempre atendidas em seu banco de dados. Outra opção seria empregar GATILHOS, mas eles tendem a desarrumar as coisas, por assim dizer.

Declarando visualizações úteis

Tendo um desenho lógico como o explicado acima, seria muito prático criar uma ou mais visões, ou seja, tabelas derivadas que compreendem colunas pertencentes a duas ou mais tabelas base relevantes. Dessa forma, você pode, por exemplo, SELECT diretamente dessas visualizações sem ter que escrever todos os JOINs toda vez que precisar recuperar informações “combinadas”.

Dados de amostra

A esse respeito, digamos que as tabelas base são “preenchidas” com os dados de amostra mostrados abaixo:

--
INSERT INTO UserProfile 
    (UserId, FirstName, LastName, BirthDate, GenderCode, Username, CreatedDateTime)
VALUES
    (1, 'Edgar', 'Codd', '1923-08-19', 'M', 'ted.codd', CURDATE()),
    (2, 'Michelangelo', 'Buonarroti', '1475-03-06', 'M', 'michelangelo', CURDATE()),
    (3, 'Diego', 'Velázquez', '1599-06-06', 'M', 'd.velazquez', CURDATE());

INSERT INTO Category 
    (CategoryCode, Name)
VALUES
    ('C', 'Car'), ('B', 'Boat'), ('P', 'Plane');

-- 1. ‘Full’ Car INSERTion

-- 1.1 
INSERT INTO Item
    (ItemId, OwnerId, CategoryCode, Foo, Bar, Baz, CreatedDateTime)
VALUES
    (1, 1, 'C', 'Motorway', 'Tire', 'Chauffeur', CURDATE());
 
 -- 1.2
INSERT INTO Car
    (CarId, Qux, Corge)
VALUES
    (1, '1999-06-11',  999.99);

-- 2. ‘Full’ Boat INSERTion

-- 2.1
INSERT INTO Item
    (ItemId, OwnerId, CategoryCode, Foo, Bar, Baz, CreatedDateTime)
VALUES
    (2, 2, 'B', 'Ocean', 'Anchor', 'Sailor', CURDATE());

-- 2.2
INSERT INTO Boat
    (BoatId, Grault, Garply, Plugh)
VALUES
    (2, 10000, '2016-03-09 07:32:04.000', 'So far so good.');

-- 3 ‘Full’ Plane INSERTion

-- 3.1   
INSERT INTO Item
    (ItemId, OwnerId, CategoryCode, Foo, Bar, Baz, CreatedDateTime)
VALUES
    (3, 3, 'P', 'Sky', 'Wing', 'Aviator', CURDATE());

-- 3.2

INSERT INTO Plane
    (PlaneId, Xyzzy, Thud, Wibble, Flob)
VALUES
    (3, 3258594758, 'Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut sollicitudin pharetra sem id elementum. Sed tempor hendrerit orci. Ut scelerisque pretium diam, eu sodales ante sagittis ut. Phasellus id nunc commodo, sagittis urna vitae, auctor ex. Duis elit tellus, pharetra sed ipsum sit amet, bibendum dapibus mauris. Morbi condimentum laoreet justo, quis auctor leo rutrum eu. Sed id nibh non leo sodales pulvinar. Nam ornare ipsum nunc, eget molestie nulla ultrices vel. Curabitur fermentum nisl quis lorem aliquam pretium aliquam at mauris. In vestibulum, tellus et pharetra sollicitudin, mi lacus consectetur dolor, id volutpat nulla eros a mauris. ', 'Here we go!', TRUE);

--

Então, uma visualização vantajosa é aquela que reúne colunas de Item, Care UserProfile:

--

CREATE VIEW CarAndOwner AS
    SELECT C.CarId,
           I.Foo,
           I.Bar,
           I.Baz,
           C.Qux,
           C.Corge,           
           U.FirstName AS OwnerFirstName,
           U.LastName  AS OwnerLastName
        FROM Item I
        JOIN Car C
          ON C.CarId = I.ItemId
        JOIN UserProfile U
          ON U.UserId = I.OwnerId;

--

Naturally, a similar approach can be followed so that you can as well SELECT the “full” Boat and Plane information straight FROM one single table (a derived one, in these cases).

After that —if you do not mind about the presence of NULL marks in result sets— with the following VIEW definition, you can, e.g., “collect” columns from the tables Item, Car, Boat, Plane and UserProfile:

--

CREATE VIEW FullItemAndOwner AS
    SELECT I.ItemId,
           I.Foo, -- Common to all Categories.
           I.Bar, -- Common to all Categories.
           I.Baz, -- Common to all Categories.
          IC.Name      AS Category,
           C.Qux,    -- Applies to Cars only.
           C.Corge,  -- Applies to Cars only.
           --
           B.Grault, -- Applies to Boats only.
           B.Garply, -- Applies to Boats only.
           B.Plugh,  -- Applies to Boats only.
           --
           P.Xyzzy,  -- Applies to Planes only.
           P.Thud,   -- Applies to Planes only.
           P.Wibble, -- Applies to Planes only.
           P.Flob,   -- Applies to Planes only.
           U.FirstName AS OwnerFirstName,
           U.LastName  AS OwnerLastName
        FROM Item I
        JOIN Category IC
          ON I.CategoryCode = IC.CategoryCode
   LEFT JOIN Car C
          ON C.CarId = I.ItemId
   LEFT JOIN Boat B
          ON B.BoatId = I.ItemId
   LEFT JOIN Plane P
          ON P.PlaneId = I.ItemId               
        JOIN UserProfile U
          ON U.UserId = I.OwnerId;

--

The code of the views here shown is only illustrative. Of course, doing some testing exercises and modifications might help to accelerate the (physical) execution of the queries at hand. In addition, you might need to remove or add columns to said views as the business needs dictate.

The sample data and all the view definitions are incorporated into this db<>fiddle so that they can be observed “in action”.

Data manipulation: Application program(s) code and column aliases

The usage of application program(s) code (if that is what you mean by “server-side specific code”) and column aliases are other significant points that you brought up in the next comments:

• I did manage to workaround [a JOIN] issue with server-side specific code, but I really don't want to do that -AND- adding aliases to all columns might be "stressing".

• Very well explained, thank you very much. However, as I suspected, I'll have to manipulate the result set when listing all data because of the similarities with some columns, since I don't want to use several aliases to keep the statement cleaner.

It is opportune to indicate that while using application program code is a very fitting resource to handle the presentation or graphical features —i.e., the external level of representation of a computerized information system— of data sets, it is paramount that you avoid carrying out data retrieval on a row-by-row basis to prevent execution speed issues. The objective should be to “fetch” the pertinent data sets in toto by means of the robust data manipulation instruments provided by the (precisely) set engine of the SQL platform so that you can optimize the behaviour of your system.

Furthermore, utilizing aliases to rename one or more columns within a certain scope may appear stressing but, personally, I see such resource as a very powerful tool that helps to (i) contextualize and (ii) disambiguate the meaning and intention ascribed to the concerning columns; hence, this is an aspect that should be thoroughly pondered with respect to the manipulation of the data of interest.

Similar scenarios

You might as well find of help this series of posts and this group of posts which contain my take on two other cases that include supertype-subtype associations with mutually exclusive subtypes.

I have also proposed a solution for a business environment involving a supertype-subtype cluster where the subtypes are not mutually exclusive in this (newer) answer.

Endnotes

_{¹ Definição de integração para modelagem de informações ( IDEF1X ) é uma técnica de modelagem de dados altamente recomendável que foi estabelecida como umastandard in December 1993 by the U.S. National Institute of Standards and Technology (NIST). It is solidly based on (a) some of the theoretical works authored by the sole originator of the relational model, i.e., Dr. E. F. Codd; on (b) the entity-relationship view, developed by Dr. P. P. Chen; and also on (c) the Logical Database Design Technique, created by Robert G. Brown.}

_{² Em IDEF1X, um nome de função é um rótulo distintivo atribuído a uma propriedade (ou atributo) FK para expressar o significado que ela possui dentro do escopo de seu respectivo tipo de entidade.}

_{³ O padrão IDEF1X define a migração de chave como “O processo de modelagem de colocar a chave primária de uma entidade pai ou genérica em sua entidade filha ou categoria como uma chave estrangeira”.}

Vamos chamar a tabela principal de Produtos. Isso hospeda os atributos compartilhados. Então, digamos que temos uma mesa de carro, uma mesa de avião e uma mesa de barco. Essas três tabelas teriam uma chave ProductID com uma restrição FK na linha ID da tabela Product. Se você quiser todos eles - junte-se a eles. Se você quiser apenas os carros, junte carros à esquerda com produtos (ou junte produtos e carros à direita, mas prefiro sempre usar junções à esquerda).

Isso é chamado de modelo de dados hierárquico. Para um número baixo de subtabelas, pode fazer sentido em uma tabela longa (milhões de produtos).