Can SAP leverage MM and classification (CL-system) data-model?

Question

Dear all,
At the moment I’m working for a telecom company, setting up the Functional Management department activities to manage 2nd line support calls, and general overall application functional support.
One of the issues is simplifying the work of monitoring Item (products, articles etc.) Master Data. Below you can see the data model where Items, their classes, the characteristics of classes and prices are stored. 
The Legacy system has the following data-model (as ERD, <a href="http://sapparking2007.freehostia.com/LegacyModel.JPG">LegacyModel</a> )
Main Product (i.e. Nokia 6110)
     - has zero, one or more Characteristics (i.e. 220v cord, 3v battery etc.)      
     - has zero, one or more Variants (i.e. Nokia 6110i,  Black, Red etc.)
     A Variant  (Nokia 6110i, Black)
          - has zero, one or more Characteristics (i.e. 200h stand by time etc.)      
          - has zero, one or more Deliveries (i.e. we sell “a package”)
          A Delivery (certain combination of a package : Nokia 6110i, Red, Prepaid, 1 year)
               - Has zero, one or more Characteristics (i.e. prepaid simcard, free service etc.)
               - Has zero, one or more Delivery Prices (i.e. prices)
               A Delivery Price
                    - Has zero, one or more Characteristics (i.e. 1 month warenty)
                    - Has zero, one or more Prices (i.e. offer price, sales, periods)
Well, almost perfectly normalised data-model.
The implementation in SAP is as follows:
Main Products , Variant and Deliveries are all stored in table MARA.
Product is Artikeltype Z01A,
Variant is type KMAT,
Deliveries is type HAVA and DIEN.
See image:
<a href="http://sapparking2007.freehostia.com/Model01.JPG">Current Data Model</a>
The Characteristics are stored in table CABN etc…
The prices are stored in the SD table KONP .. (price condition). etc.
The MARA table is connected to Classes table (KSSK) via the INOB table.
Classes are connected to Classes with in de KSSK table.
The filed that stores Class in the KSSK and the field that stores the Class below are 2 different type of fields (18C , and 50CN)  and they would simply wont join in a SAP query.
The filed that stores Item to Class in the INOB and the field that stores the Class in the KSSK are 2 different type of fields (18C , and 50CN)  and they would also wont join in a SAP query.
Therefore we have created extra Z. “Tables” (Types actually) that does the join for us.
Functional Management personnel – are not ABAP and SQL people. So we have to keep it simple.
After a training session – it proved to be still too complicated. After a Change Request, to create the product structure in a separated, single table, has resulted in a batch job, that create the file periodically, but not all of it. And – at the end, you never know if your data is up-to-date.
To me it seems logical – to add a (derived) field to the KSSK and the INOB to accumulate the underlying class with the same attributes as the MARA and KSSK, so it can be properly joined. But here there is too much resistant in conjunction with SAP releases etc. AND it seem to be impossible (not sure) to define a “type table” with a derived field.
To let programmers produce more ABAP is not a clean option either, and yes I realise one can create a sap query on a single table, and add a long SQL statement on Record level.
So the question:
-     Is this implementation “the best” possible in SAP?
-     How to overcome the “unjoinable” friendly database?
In other query tools it is possible to create “tables” as output (on the fly), where the tables can be used as input tables in a next query, and can be joined further.
-     Is this somehow possible in SAP?
I wonder if anyone can shade some light on this approach. We have 2 FTE to monitor 2.5 million products combinations, and the propagation of this data to over 30 sales channels – daily.    
Thank you in advance for taking the time!
Kind Regards,
Doron.

Answer 1

Ashish:
Please search the space threads before posting.  There are several posts where this is already covered.
regards,
bill.