I'd like to create a clothing database, where items from tables such as 'tops' or 'bottoms' (pants, skirts) can be matched with each other and with items in other tables such as hats or shoes.
I want to be able to relate all tables to each other in both directions (each skirt goes with many tops, and each top goes with many pants, etc) and I want each table to be related to each other. E.g, I want to query 'what items look good with these pants' and see a list of shirts, shoes, etc.
Using a relational database would requires in-between tables for every relationship, which creates a ridiculous amount of tables.
I thought I might be able to do this with a NoSQL databases, but as I'm learning what those are, they don't seem to fit. Am I wrong?
Are there bi-directional relational databases, and what are they called?
They are called "relational databases".
Querying in relational databases has no directionality. Each table (base table or query result) in a relational database represents an application relationship of interest. A table holds the rows of values that are related in that way. (When subrows of values identify application entities, the relationship is about both values and application entities.) A base table is set to the rows of values that satisfy its associated application relationship. A query returns the rows of values that satisfy its application relationship that has been expressed in terms of the base table relationships.
Given that each base table represents a necessary application relationship, one defines sufficient base tables to describe the overall application state. To say that the number of tables is ridiculous is ridiculous. The decomposition of certain tables/relationships into others as suggested by normalization not only makes that description simpler but reduces redundancy and complications in manipulation.
The foreign key constraints in a relational database can reasonably be called directed. They tell the DBMS that the values under some columns in one place have to appear as values under some columns elsewhere. In ER (Entity-Relationship) modeling these are diagrammed as lines from entities and identifying relationships to the relationships they participate in. (The latter are your "in-between tables".) But which foreign key constraints hold has no effect on query composition.
You need to read an introduction to relational databases & DBMSs. (Avoid presentations based on ER modeling and ORM (Object-Relational Mapping) approaches, which do not really understand the relational model.) (NoSQL approaches don't either.)