I can't see the image at the moment (blocked by my firewall @ the office). but I'll try to give you some ideas.
The general idea is to organize your measurable 'facts' into what are called fact tables. There are 3 main types of facts, but that is a topic for a different day (but I'd be happy to go into this if needed). Each of these facts are what you'd see in the center of typical 'star schema'. The other attributes within the fact tables are typically FK references to the dimension tables.
Regarding dimensions, these are groups of attributes that share commonality (the most notable being a calendar dimension). This is important because when you're doing analysis across multiple facts the dimensions are what you use to connect them.
If you consider this simple example: A product is ordered and then shipped. We could have 2 transaction facts (one that contains the qty ordered - measure, type of product ordered - dimension, and transaction date - dimension). We'd also have a transaction fact for the product shipping ( qty shipped - measure, product type - dimension, and ship date - dimension). This simple schema could be used to answer questions like 'how many products by product type last quarter were ordered but not shipped'.
Hopefully this helps you get started.
responsesis many to everything so it's clearly a fact table. Ifquestionsis a finite list of textual questions, then clearly it is a dimension table. You would generally combinequestionswithoptionsto make a single denormalised dimension about questions. Once you combine your options and questions, you actually end up with three tables in a star schema. - Nick.McDermaidquestion count,correct count,incorrect count- Nick.McDermaid