1

I have to process biological data input in the format of 96-well plates.

explainer for the non-biologists:

These plates are basically a 2D matrix of 8 rows x 12 columns of small cups called wells. Each well is used for different assay conditions. During an assay each plate iterates through several assay steps: coating a sample of interest on the bottom of the wells, putting a sample on top and detecting if the sample reacted with the thing on the bottom. Several of the plates can make up an experiment.

end of explainer

So the data/object modeling seemed straightforward at first: Experiment -> Plate -> Well. The Well object would then contain a list of assaysteps starting with the type of "coating" and ending with the "detection" step. The read-out values obtained for each well in the end are also stored in the Well object. Everything would also be linked to a MySQL table as entities.

All good and well for the first two steps: the coating and sample steps can be very diverse, but a lot of the time the detections steps are the same for nearly all wells. Meaning I would have for one plate 95 table entries that read "anti-His detection" and 1 well that reads "blank control". Also the detection step is not always "anti-His detection", it could be "anti-HA detection" next time for like half a plate.

So I guess my question is: am I missing something? I feel like I did the modeling as it should, but at the same time, having 48 or 95 repeats of the same thing per plate doesn't sit well. Should I split up the assaysteps list into different variables? One for the variable things like "coating" and "sample" and one for the detectionstep that can be a reference to a limited set of detectionstep objects? In the database you'd then have reference to a detectionstepid. This way doesn't seem right to implement for the "samples" because there you can have 96 different entries, so having 96 different new specialty objects/lines in a DB table seems overkill to having just an entry in a String list. Or is splitting things up overcomplicating things for little reason? Any suggestions welcome!

  • What is your concern with the repetition of detection steps? Is it the storage? is it the chance that a typo is made and one entry reads "antu-HIS detection" that might not be understood? Is it something else? – Bart van Ingen Schenau May 23 '19 at 10:43
  • The typo's are not really an issue. I guess my biggest problem with it is that during my lessons on database design my teacher didn't stop emphasizing that repeating stuff too many times is bad. That's why I started doubting that my initial solution was ok. The detection step can and will be anything in any Well at some time, so you need the flexibility of it being able to be anything. However, most of the time it's not just anything, but coming from a limited set of possibilities. That's what led me to doubt and to seeking the opinion of smarter people than myself... – Nanobody May 23 '19 at 16:14
0

You appear to be overcomplicating and overthinking stuff.

Your teacher is right that information should not be duplicated in a database, but the simple fact that 2 or 95 rows contain the same text does not immediately mean that information has been duplicated.

The problem with duplicated data in a database is that if you update only one copy of the data, then the database does no longer contain a consistent set of information. The other side of this is that if you can freely change the detection step for any Well without impacting the consistency of the data in the database, then the per-Well storing of the detection method is not duplicating data.

You might still want to use a table of known/supported detection methods and only store a key as detection step for each Well, but that would then primarily be to ensure a consistent naming and possibly to store additional information about the detection methods.

  • Thanks that cleared it up. I don't really have IT people in my environment to bounce ideas of ;-) – Nanobody May 24 '19 at 12:57
1
Alice Smith  
Bob Smith  
Charily Smith  
Edger Smith  
Fred Smith  
Greg Smith  

Normalizing data isn't really about repetition. Repetition is a symptom of ignoring structure. The problem is, not every repetition represents actual underling structure. Are all these people part of the same family or are they simply victims of a popular last name?

Don't stick me with meaningless structure. You create the illusion of relations where they don't exist. Normalize around real meaningful structure.

When you find repetition look into it. But don't be fanatical about it. Create something useful.

  • Thanks for emphasizing what Bart mentioned above. – Nanobody May 24 '19 at 13:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.