Question:
In class last Tuesday, we created a list of many, many sensor "fields", and then broke them down based on major characteristics, including Physical properties, Measurements, Communication, etc... I know you said that we would not need to include all of these, and at this point, it is not my intention to. However; I have a question regarding how I might go about including a significant number of them. Hopefully I can explain it clearly enough that you have some context...
My intention is to have one 'Main' sensor table, with Primary Key, Manufacturer, Model, Cost, Parameter Measured, Output Units, Sensor Comments, Date of Installation and Specifications (a link to URL). In addition, I would like to have other tables showing: physical characteristics, additional measurement characteristics, communication, time, power, of each sensor. Each separate table would be comprised of 'fields' relating to those specific characteristics.
Now my question is: what is the best/appropriate way to do this? I have identified two ways that this might be done, but I am not sure which or if either would work:
1. 1 Query -> Multiple Tables
If I create these multiple tables, and then one query (and subsequent form) where I enter the data for every field of each sensor as I enter it into the database, will this in turn populate the tables with the information that each requires (so long as the necessary relationships exist)? I tried to do a simplified case of this, using players for a sports roster, broken down into the positions that they played. I entered all the players, such that each had a Primary Key, and also attached to them a Position Key, both of which were linked to the separate tables for position. However, when I entered all the players, it didn't populate any of the position tables. So this didn't seem to work, though I am not 100% certain that I did it correctly, so I don't want to rule it out completely.
2. 1 Table Filled By Multiple Queries
This was what my initial thinking was. It seems to make sense based on my somewhat still limited understanding of what the query actually does. Logically, if I have one table with all the information for each sensor, then I can have a individual sub-queries that provide specific packets of information, corresponding to the distinct categories we identified (physical, power, time, etc...). However, my experience with Access tells me that the table/tables are populated by information that you manually enter through a form, which is often linked to a query. In this case, for each characteristic query (physical, measurement, power, etc...) to populate column values in the Sensor Table, it will need to be related to that table by a "Key Sensor - Sensor ID" relationship. But wont this create issue if I call out Sensor ID in potential 3, 4 or 5 different queries? Or is database smart enough to take the information from each query and attach it to the correct column places in the Sensor Table.
My biggest confusion I think is my lack of strong grasp of what the query does. It seems to me that this is the mechanism that populates the tables in the database. But logic suggest that they would be how you can request specific groups of information, like Measurement, Sensor, Room, Building or Building, Date, Sensor Type, all corresponding measurements. If the later is true, then that suggests the 2nd option above would be the best, since I am creating queries based on what groupings of information I would like to gather from my database. On the other hand, though, if I am using these queries to populate the database, wont I run into issues of overlap and frustration (overlap wont actually occur since referential integrity would restrict it)?
Response:
I’m answering rapidly without having read every word of you question, in order to get something off early.
A query is PRIMARILY a method of drawing together from a carefully thought-through set of tables. Yes, it can do important other things such as updating records, deleting and appending them, but you always start with the tables.
What I think would address your approach is the following, which is what I showed in class using the FreeMind diagram of table relationships.
To be thorough you need two tables for sensors (minimum)
#1 has the information for all sensors of that type – model number, electrical power…. – Primary Key IDSensorType
#2 has the information for a specific instance of a sensor – e.g. the one in building #3, room 342, northwest wall – Primary Key IDSensorInstance + Foreign Key IDSensorType
#2 is linked to number #1 via the ForeignKey as a many-to one-relationship
You CAN have multiple table linked through 1:1 relationships that break a big table into multiple smaller ones, but for our purposes there really isn’t any need to do so.
If you set things up this way and get your links working properly, then a query can display information from ALL the linked tables simultaneously. Putting information into that query in each field will put information into the appropriate fields automatically.