then this item from table A can be used on 3 different systems ( imagine: ford, toyota, ferrari) this mean 3 different tables? ( table B ford , table C toyota, table D ferrrari)
No, it does not mean 3 different tables. It means one table that includes a field that SAYS Ford, Toyota, Ferrari. And you use queries if you want to see ONLY Fords or ONLY Toyotas or ONLY Ferraris.
The usage table DOESN'T CARE what it is because the item definition table DOES care. All that matters is that your status would be kept in the usage table NO MATTER WHAT the system happens to be. Is there that much difference between these systems for the USAGE table?
Now, as to different fields for different systems... Really? Are we talking about a LOT of fields or just a couple? Because there is nothing wrong with the idea that a given field will be blank for some things and not blank for others. Splitting out these different fields IS done sometimes, but not unless there is a very large number of totally unique fields that differ from system to system.
I'm beginning to think that at least part of your problem is NORMALIZATION. Have you studied that? It is crucial to having a good design. If you need to study that, here is my advice. You CAN search this forum for articles on normalization since this is a database forum. You can ALSO search the web for articles on DATABASE NORMALIZATION. You need to qualify it for a general web search because normalization is also used in chemistry, politics, diplomacy, mathematics, and medicine. If you go the web route, you might find articles in your preferred language, but in any case I would advise FIRST looking at articles from an .EDU domain, usually from colleges. They will focus on the academic side of the discussion and are less likely to try to sell you something. Once you get the idea, if you wanted to look at a couple of .COM domain entries, that is OK. They will just want to tell you about THEIR version of SQL or THEIR development environment.
The point of NORMALIZATION is to try to maintain purity of purpose for a given table. If a table describes items, it should not describe people or places. (That's a simplified way of looking at it.) It should also not describe ACTIONS even if those actions are related to the items, particularly if keeping a time-based history of actions is important.
Your question about "3 tables for 3 different kinds of systems" describes a situation that violates normalization by making a division of data where one should not be. If we use the Ford, Toyota, Ferrari model, then your top level table is really about automobiles. The table can SAY what kind of automobile it is, but it is always about automobiles. Ford, Toyota, and Ferrari all represent DATA in the automobile table, not separate tables.