I'd like to talk a little about joins, with the aim of drawing a more clear distinction in your mind of how they work:
INNER JOINs do not result in "all combinations of rows" - that's what a CROSS JOIN does
OUTER JOINs are useful where you have one table with all the values(the solid table), and you need to join it to other tables that don't necessarily have any row that is related to the solid table - these are sparse tables (holes in the data). Outer joins come in 3 flavours: left, right and full. Left and right are the same thing, you just pick the appropriate keyword depending on the order of your tables. Essentially a left join b
and b right join a
amount to the same thing - the keyword left/right declares which table you consider to be solid and which you consider to be sparse.
An inner join of a solid and sparse table pair would eliminate some solid rows in the results leaving only the sparse rows and the related solid rows. An outer join would represent all solid rows, and empty cells where no matching sparse row was found
Natural JOINs are JOINs where you don't explicitly state how the tables are related, you just let the database guess based on equal column names in both tables. Don't use natural JOINs, theyre nearly always a stupid idea and a pointless "optimisation" that saves a few seconds of keystrokes in exchange for hours of frustrating debugging
Your query here doesn't seem to require outer JOINs, as you state you want to know which pieces are provided by which company.. that's just
SELECT c.* FROM
Provider r
JOIN Provides s ON r.code = s.provider
JOIN Pieces c ON c.code = s.piece
WHERE
R.Name = 'Mattel'
Edit:
Philipxy has made a reasonable point that the keywords "solid" and "sparse" have particular meanings in maths, and I'd like to point out that I'm using them here to convey a concept rather than drag that particular aspect of maths into it. As you're looking for understanding, I thought I'd discuss things in this way because I've classically found it an easy way for learners to grasp the concepts, but these are essentially my own terms for referring to the shape of the database data you're working with and I don't necessarily guarantee that a future fellow professional who is heavily invested in his understanding of mathematics will be able to grasp the meaning of what you're saying, if you use keywords that he only uses/understands in a particular way. In that case you may need to add a similar disclaimer if you're using "solid" and "sparse" that you simply mean them in the generally accepted English Language meanings, rather than the mathematical sense