You are trying to badly deviate from
relational model. At the same time, all your problems are simply resolved in the relational model. First, let's start from the notion of "sub-category". You can have just one table "Category" with the key "Id". If you add the columns "ParentCategory" which carries the IDs of the categories parent in relation to the category of the current record, you will have the tree of arbitrary depth built on the base of the
parent-child relationships between categories.
The rest of it depends on what on what the attribute should be and what "different attributes" may mean. You never need to create a table dynamically. "Different attributes" does not mean different types. So, you can have only one table for all attributes, and they will be different, because the attribute's attributes are different (different values in some or all columns). But let's suppose you have different types of attributes, which means that you have different set of columns for each table. Now, it depends on where those types come from. If the attribute types are known in advance, you need to have a separate attribute table per attribute type, so the problem is reduced to a previous one.
And finally, let's consider the case when you need to create a new attribute type dynamically. It simply means that the type should be represented not as the type of the table, but become a data type. The most basic approach is this: create one new table of dynamic attributes. It can have, say, name, value, and, importantly, a column "owner" with the foreign key pointing to the attribute object. That said, you can have the object "attribute" each having unlimited number of "dynamic attributes".
Please see:
http://en.wikipedia.org/wiki/Relational_model[
^],
http://en.wikipedia.org/wiki/Relation_(database)[
^],
http://en.wikipedia.org/wiki/Foreign_key[
^].
—SA