# Transforming raw data into standardised one

I have a huge problem with transforming raw data into standardised one. I would be grateful for your help. Below is a description of the case.

The blue picture shows norm table that transforms the raw results of a given questionnaire into standardised results (by age and gender of the respondent). The first column (Sten) presents a standardised values. The other columns (neo, eks, otw, etc.) present raw values for each scale of the questionnaire. The table on the left is for women and the table on the right is for men in the 20-29 age group.

I have a big problem with changing the raw value to a standardized one. I have raw results from many subjects and I would like to assign standardised value to them. For example, a woman aged 25 years who completed the questionnaire and obtained a raw value of 8 on the NEU scale should receive a standardized value of 1.

Does anyone have an idea how to do it? Thank you very much for any suggestions.

Hi @Przemek_Sawicki,
Iâ€™m not sure if I correctly got your point, look if this formula in the `neu` column for the normal value could help `Questionaire.neu.PercentileRank(thisRow.neu)` .

Let me know if this is what you needed.

Cheers,
federico

Hi @Federico_Stefanato unfortunately it is not what i need. Look at the red arrows in the picture - they show why the first person in the neu_sten column has a value of 1. Gee, itâ€™s hard for me to explain but the process is trivial - until now I did it manually with a pencil and a sheet of paper. I thought Iâ€™d be able to automate this process with Codaâ€¦

Ok, second tryâ€¦
Is it a â€śtranslationâ€ť issue? i.e. getting the value based on a predefine range?
Take a look:

Let me know

1 Like

Great - thatâ€™s what I meant! When I manage to rewrite all the blue tables (I have only pictures of them, unfortunately) I will come back to ask about one more thing. Meanwhile, thank you very much:)

Happy we found out a way
Let me know when/if you need further help: Coda community is indeed very supportive.

Cheers!

1 Like

As you rewrite the tables, thereâ€™s a likely bit of usability that will suffer as you split the NEU ranges into separate columns. To avoid doubling the number of columns in the translation table and thus separating the beginning and end ranges, you could continue to publish them as paired values delimited with a dash (-).

By using the Split() function, youâ€™d simply use a more complex filter to set the range values by parsing the NEU cell values dynamically.

``````[Translation Table].Filter(
thisRow.neu >= [Neu].Split("-")[0] &&
thisRow.neu <= [Neu].Split("-")[1]).Sten
``````
1 Like

Gee, another stopâ€¦ Now Iâ€™m trying to get the interpretation value from the level table. What is wrong with my formula? @Federico_Stefanato would you take a look? Thank you very much.

Hi @Przemek_Sawicki, have a look:

1. You can make a selectable list to return the entire row, in order to avoid â€śid filteringâ€ť
2. You can (wellâ€¦ should!) modify your data model in order to retrieve the data in a more comfortable and efficient way. In this case I provided an alternative solution by adding the entire `Level` row into the `Questionnaire` table. this way you can access easier to internal references.

Also, it might be pedantic but it happens quite often in data manipulation: as a very basic rule of thumb, when you have to retrieve the data ask yourself: [Where my data is]-[How to filter them]-[What attribute(s) I need]. i.e. `Table-Filter-Attribute`(s)
So, start your formula with the table you need to get the data first.

I hope it helps.
Cheers!

1 Like

Even better would have been to have `Level` table referenced into `Translation` table and, in turn `Translation` into `Questionnaire`.

But it really depends on the final usage and features you need.