0

Here is a flat version of my datamodel. It is sensor readings for various data acquisition equipment.

0

https://i1295.photobucket.com/albums/b628/colnewman26/Work%20Screen%20Shots/RobinDataModel_zpsdfc40151.png~original

Here is my Relational Database model. Does this make sense.

1

https://i1295.photobucket.com/albums/b628/colnewman26/RobinDataModel_zps847d94b5.png~original

If not what you suggest?

3
  • 2
    Looks good to me. But it really depends on how well it maps to your requirements matrix. Aug 14, 2014 at 15:54
  • as per @RobertHarvey, what are you going to do with the data in the relational model? If you're usually/only going to reconstruct/manipulate the measurements table from the first image, then a table of events with a lot of fields would suffice. If you're going to be doing time-series analysis on discrete event/measurement types, you might want to consider a simpler representation of quantities and measurements (e.g. see Analysis Patterns, by Martin Fowler) Aug 15, 2014 at 1:28
  • Well it's mostly just used for graphing for reports, and finding highs and lows etc. Each test instance will have a different number of channels for each type of sensor, and I also need to ability to add new types of tests in the future. Aug 15, 2014 at 1:59

1 Answer 1

2

Seems to me you may have over normalized this based on the original table design. Unless you are certain that you will need an indeterminate number of factors, you pay a pretty high penalty in insertion and retrieval of data with that schema. Having worked with high data volume sensors (GPS readings) I found that performance considerations pay a heavy role as you start viewing trending data as the data volume grows.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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