Shuster - B5: Object-Oriented Databases

An object-oriented database (OOD) is one that uses the concept of "objects" rather than tables to organize and display data. These databases utilize a query system that allows users to extract specific data from the set without having to look at the raw information itself, which can be overwhelming. However, the way that each object-oriented database allows its user to query is different from system to system. Some use language to define search parameters, whereas some are visual graphic interfaces. In being defined as an object-oriented database, a system exhibits characteristics that are broken down into three groups: mandatory, optional, and open. Mandatory characteristics are ones that must exist within any OOD. They include, but are not limited to:

• Type or class of the data
• Inheritance (whether the information is based on another type of information, such as "student" being a subclass of "person")
• Extensibility (whether the system takes into account and sets up for future growth)
• Persistence (whether the data continues to exist after it is finished being inputted)

Optional characteristics, as their name implies, are not mandatory. Instead, they can be added to a database to improve its functions. They may include:

• Distribution (whether the database is distributed among a number of servers rather than being stored in just one)
• Multiple inheritance (whether information may be a subtype or subclass of multiple types/classes, such as "cat" being a subclass of both "mammal" and "pet")
• Type checking (whether the inputted information is in sequence with the data that should be inputted for that type)

Finally, open characteristics are ones that may differ database to database, depending on how the programmer decides to design them. Examples include:

• Uniformity (whether the database is consistent throughout, sticking to the same definition for each type of information and database detail)
• Programming paradigm (which programming language is used to create the database)
• Type system (which specific functions, variables, etc. are used to define database properties)

The main function of OODs, as I see it, is to take a highly complex database and make it appropriate for human consumption. This could mean making it easier to manage for the programmers, but also could mean making it so that the end-user or client can actually make any sense out of it. Because of this, I think that OODs, which have been around in some form since the '80s, are a great way to store and query information. In the context of intelligent building design, OODs can be a great way to store the complex details of the design in a way that is still manageable by the designers. As intelligent buildings become increasingly complex, it becomes more difficult to keep track of all of the components involved, and OODs could be a great way to do that.

Sources:

W. Kim, J. M. Nicholas, and S. Nishio, “The Object-Oriented Database System Manifesto,” in Deductive and Object-Oriented Databases, Kyoto, Japan: Kyoto Research Park, 1989, pp. 223–240.

Sources:

Mark,
I think you really got the basic understanding of relational databases! You definitely seem to understand that while they're basic in concept, they can be used to store and query complex information. I highly recommend trying your hand at some basic database programming in SQL or an equivalent program. I found that it was the best way to really understand how the whole thing worked. It takes some trial and error, but overall it's a pretty straightforward language.

Sarah,
I never realized that SQL is compatible with Excel - I'm interested in learning more about that. I'm glad you brought it up in your blog post! I like that beyond just describing what SQL is, you went on the talk about some of its advantages and disadvantages. Having used SQL, I definitely agree with some of the criticisms of the language. The basics of it are straightforward, but after that there's a very steep learning curve to start understanding all of its complex capabilities.

Chris,
You brought up a lot of points I hadn't considered before. It seems obvious to me now that construction firms would have the same need as design firms to keep track of all their projects and project details. In particular, construction is a field that relies heavily on tight scheduling, so a database could definitely be crucial for keeping on top of that. I'm also glad you gave an example for how a database could be used to help with estimating - that's definitely a huge part of construction.