Week-10 Presentations

In the last class each group/individual will have prepared a presentation on their term project kusing PowerPoint. These presentations will be no more than eight minutes long and will have been submitted to VistaBB in advance.

Each topic-group will bring five copies of their PowerPoint slides (4 or six per page is economical) to share with the rest of their class group.
Because there are sixteen groups we cannot hear all of them.  The process we’ll follow, therefore, is to initially split into five class groups.

Group	Teams - See PDF for Topic and Members
A - BIM	5, 8, 12,14, 16
B - Green & BIM	2, 3, 4
C - Green & BIM	7, 9, 15
D - Sensors	6, 13, 18
E - Varied	10, 11, 17

The role of these class groups is to:

• Review the slides and hear a brief description from the others in their group.
• Decide which of them will present to the whole class – for an extra-credit point.
• Be prepared to tell the class about other interesting things they learned in the discussion.

The balance of the class will be devoted to the the five presentations by the chosen individuals/groups.

• Eight minutes long
• Five minutes of discussion after the presentation 

CadLab Class Meeting Place This Week 3/6/2012

We're going to do some work in class this week that will be best performed with access to computers.  For that reason we'll be meeting in the CadLab (CAT-167a) at the regular time.

What we'll be doing is looking at the application of the technologies we've discussed in this class throughout the term in more detail to the design and operation of a building throughout its lifespan.  In essence we'll attempt to be much more specific and look further into the future.

I will be taking attendance at this class.

A2b - Databases - Grading Comments

The grading is complete for all A2b submissions except those who received an extension.  Overall most people did well, though some comments are worth making.

• Links
• Those of you who just followed the tutorial had no problems with links.  Those who struck off on their own (admirable) had more problems.  The subject of the different kinds of links and how to make them is not intuitive for most of people, myself included.  It takes work and mistakes, and does eventually come clear.
• Dropdown Boxes
• I didn't want to make dropdown boxes required because it was one more layer of complexity.  Nonetheless they are almost essential in practice for data entry into forms.  One creates them using a "Combo Box".  There are reasonable explanations in the help files.  Without them one has to keep referring to other views (tables or queries) to determine what is the appropriate ID #.
• Extending Access
• As my comments about links and dropdown boxes indicate, to become a proficient database users takes considerable work.  
• Planning initially is extraordinarily important.
• Learning to import data is very helpful - one person did so.
• There are multiple types of queries, many of which are very helpful.
• To get really proficient you need to learn to use VBA - the programming language (:
• Sensor Information
• As I said in my comments to many of you, one of the purposes of this assignment was to give you a gut sense that picking the right sensor isn't as easy a process as one might think.  Manufacturers very often don't provide the information you know is important.  Tracking that down can be a pain and sometimes impossible.  In a work situation, a call to the representative is often the best solution.
• A related issue is how you set up your sensor information table.  Most of you had only a few fields in it.  In fact there's no problem in having many fields, with only a few fields being appropriate to each sensor type.  You can generate good reports by using a query that displays on the relevant fields.  You can also write queries that concatenate info from different fields or leave it blank if there's nothing in a field.
• Sensor Characteristics by Building System
• No one really tackled the criteria addressing whether there were differences between sensors by building system (structure, HVAC) etc.  The kinds of things that might have been addressed here are comments on:
• Size
• Ease of installation
• Appropriate frequency of measurement
• Other Databases
• There are many databases available - I used Access because you all have it with Office (though in future that won't be true thanks to Microsoft's business relationship with Drexel).
• My own favorite (Mac and PC) is FileMaker.  Unfortunately it's expensive, an expense I've found worthwhile because I do so many things with DB.
• Open Office (I prefer the LibreOffice version) has a free DB modeled on Access, but it's been buggy for years and doesn't operate the same way.  The latest LO version seemed pretty good to me when I tested a week ago, though it has some different interface design approaches.

A2b–Detailed Access/Query Question

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.

A2b–Required Sensor Information

Question:

I am looking up sensor information to put into my database and, as you said in class, there is a lot of information that is not available on the manufacturer's website. Do we need to find sensors and manufacturers that give us ALL the information to fill in our fields in our database? or can we indicate in some way that this information was not available in some cases?

 

Response:

You do NOT need to find sensors that have all the information – that’s quite likely impossible.  Leave blank the info you cannot find or put in something like “unavailable”.  What these gaps will illustrate is how difficult it is to find the “right” information.

P3–Term Project Draft–Comments

I’ve completed the grading of the term project drafts. 

• For those who provided Word documents I returned the marked-up draft with my comments at the end, and often pasted into the VBB comment box if they weren’t too long. 
• For those who submitted as PDF, I only pasted my comments into the text box of the grading form.

Overall Comments

A few students took a specific idea and pursued it in depth, providing information about the sources and drawing a specific conclusion(s). 

A number of you, however, had problems that I identified in the comments, with at least one suggestion of how to correct the problem.  The kinds of problems I identified included:

• Staying far too general in what you’re saying.  In several cases the papers read as though they could have been prepared without the benefit of anything we’ve discussed in this course.
• Not developing a logical argument leading to a conclusion.  It’s important that your paper first identify and then develop an idea, providing supporting (or sometimes contradicting) evidence for it.
• Not providing evidence for your assertions, either experimental or citations of sources.
• Not taking seriously into account the material that we’ve addressed in this course so far.  This was particularly important for those dealing with BIM issues.  Some of the papers read as though you’d had no experience with BIM and were just reciting manufacturer’s claims.

For those of you addressing the implementation of an “Intelligent Building” in some way I would have hoped that you’d consider the definition that I gave early in the course.  Only one group did so.  It’s not that you have to agree with my definition, it’s that it exists and should be considered, if only to be rejected.

A2b–Sensor Types

Question:

For the sensor entries, are we entering specific sensors? For example, the manufacturer name and model number of the sensor. Or are we just entering genres of sensors, i.e thermocouples or infrared laser?

Response:

Specific sensors with as much information as possible about manufacturer, characteristics, etc.