M>  ........
M>class C
M>{
M>    SuitableForC * a;
M>    void use() { /* никак не используем */ }
M>};
M> .........
M>

class Generic_A
{
       void foo() {/* код */}
       void bar() {/* код */}
       void car() {/* код */}
};

class SuitableForB: public Generic_A
{
       //вообще может быть пустым.
}


class SuitableForС: public Generic_A
{
       //вообще может быть пустым.
}

class Derived_A1 : public SuitableForB { ... };
class Derived_A2 : public SuitableForB, SuitableForC { ... }; //тут как-то хитро надо "ромбик" разводить, но это решаемо.
class Derived_A3 : public SuitableForB, SuitableForC { ... };
class Derived_A4 : public Generic_A { ... };

class B
{
    SuitableForB * a;
    void use() { a->foo(); a->bar(); a->сar();}
};

class C
{
    SuitableForC * a;
    void use() { a->foo(); a->bar(); a->сar();}
};

D>В принципе, я уже начинаю понимать о чем Вы говорите. Действительно, по сути производные классы материалов являются всего лишь хранилищами данных (физических характеристик) какого-либо типа материала. Но как выглядит реализация всего этого дела, я еще не могу понять. Может быть я не очень понятно задачу описал...

• Широченная таблица с колонками для хранения всех возможных параметров. Если нормальная СУБД и с данными планируется активно работать, то на этом лучше и остановиться
  
• Все параметры хранятся в одном строковом атрибуте. Например в XML.
  
• Разбить все возможные параметры материала на класса и выделить под их хранение отдельные таблицы (по таблице на каждый тип параметров) и плюс таблицы для связи всего этого барахла. (ИМХО выглядеть это будет красиво, но работать с этим будет неудобно)

class B
{
    Generic_A* a;

public:
    B(Derived_A1* a1);
    B(Derived_A2* a2);
    B(Derived_A3* a3);
};

class C
{
    Generic_A* a;

public:
    C(Derived_A2* a2);
    C(Derived_A3* a3);
};