Question

I cant seem to get my head around how to create this
Each Bold Letter is a Database Table
I need this to work with Entity Framework

Product

[ Product belongs to one group]
Product Group – [Computer]

[many to many]

[Group has many items]
[Product belongs to one Group Item]
Product Group Item – [Hard Drive]

[many to many]

[Group Items has Many Fields]
[Fields does not change for each product only changes for each Group Item]
Product Group Item Field – [Form Factor]

[Group Item Fields has many values]
[Field Values Change with each product]
Product Group Item Field Values – [ 3.5″ ]

I can pretty much get the first 3 to work
my problem is how to do the last two tables
I hope I explained it clear enough
thanks in advance

alt text http://myimgs.net/images/cjgo.gif

maybe this will help or just hurt who knows

Product = is a harddrive

so:

Group – Computer
GroupItem – Harddrive

GroupItemField – Form Factor : GroupItemFieldValue – 3.5″
GroupItemField – Capacity : GroupItemFieldValue – 600MB
etc…

but the field value changes for each product of type Harddrive but the field does not

Answer 1

I think you may be trying to over-generalise your solution.

It seems to me you want to standardise the information you capture for different kinds of products.

E.g. Hard Drives

1  Supplier1   Model 1a   3.5"    600MB
2  Supplier1   Model 1b   3.5"    200GB
3  Supplier2   Model X    2.5"    600MB

And you want to represent the attributes in a single table:

1 FormFactor   3.5"
1 Capacity     600MB
2 FormFactor   3.5"
2 Capacity     200GB
3 FormFactor   2.5"
3 Capacity     600MB

The problem is that over-generalising like this you lose all the data integrity controls that your RDBMS provides.

You may be better off with:

Product (*Id, Name, GroupId, Supplier, Model, …)
HardDrive (*Id, FormFactor, Capacity, …)
Monitor (*Id, Resolution, …)
Memory (*Id, Capacity, Speed, …)

Each of the above product specific tables has an optional-to-one reference to Product. With such a design, it becomes impossible to capture Monitor attributes for a hard-drive unless you add a Monitor row for the product.

That said, if you’re willing to forego integrity controls, or manage them yourself in code, then looking at sample data helps to produce your schema. (I’m going to use the terminology of attributes.)

AttributeValues (*ProductId, *AttributeId, Value) — Note a problem here: what type should Value be?

You will need some way of indicating what attributes are allowed for each Group:

HardDrive FormFactor  Req
HardDrive Capacity    Req
Monitor   Resolution  Req
Monitor   Colour      Opt
Memory    Capacity    Req
Memory    Speed       Req

GroupAttributes (*GroupId, *AttributeId, IsOptional)

Then you need to indicate the group to which a product belongs (so that you can figure out which values need to be filled in)

1  Supplier1   Model 1a   HardDrive
2  Supplier1   Model 1b   HardDrive
3  Supplier2   Model X    HardDrive
4  Supplier2   Model M1   Monitor

Products (*ProductId, Group, SupplierId, ModelNo)

I’m not sure where your GroupItems fit in.

Relationships
Products.GroupId -> Groups.GroupId
Products.SupplierId -> Suppliers.SupplierId
GroupAttribute.GroupId -> Groups.GroupId
GroupAttribute.AttributeId -> Groups.AttributeId
AttributeValue.ProductId -> Products.ProductId
AttributeValue.AttributeId -> Attributes.AttributeId

NOTE
I’ve illustrated how you can add columns defining rules for the attribute values. You could do the same for the Attributes table where you’d probably at a minimum need to indicate the data-type of the attribute.

You may notice that it won’t be long and you’ll soon be replicating the meta-data that your RDBMS provides to define tables and columns. The highly generalised solution does have its benefits such as using a simple template mechanism to capture and view products. But it becomes quite a bit more difficult (in code and processing time) to perform other tasks. So I suggest you consider your requirements holistically against the design.