Skip to main content
Engineering LibreTexts

5.8: Unstructured Data

  • Page ID
  • \( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \) \( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)\(\newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\) \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\) \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\) \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\) \( \newcommand{\Span}{\mathrm{span}}\) \(\newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\) \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\) \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\) \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\) \( \newcommand{\Span}{\mathrm{span}}\)\(\newcommand{\AA}{\unicode[.8,0]{x212B}}\)

    Before leaving the topic of objects, there is a concept that just doesn’t seem to make sense to most programmers, and that is unstructured data. This is probably because most of the CS industry is built around structure data39. Data in a relational database is structured into tuples and relations. Data in OOP is built into classes and instances. When unstructured data is encountered, programmers go to great lengths to build work arounds, none of which seem to work well40. The author has seen many of these problems and has yet to see a good solution in a relational database.

    To understand unstructured data, an example will be given that occurs when working with maps. On a map there can be placed various features, which can be thought of as markers on a google map. These features have standard properties, such as position, title, marker style, and description, and these properties can be stored in a structured format as a tuple (record) in a relational database.

    Now consider a real application, for example a map of the monuments on the Gettysburg Battlefield ( In this map various features are placed on the map. These features represent many different types of monuments. Some features are regimental monuments and may/may not be associated with states. Some features are monuments to people who fought at Gettysburg, and could are associated with a person, but could also be associated with a state or regiment. Some monuments are buildings, and could be associated with person, or a regiment, or a part of the battlefield.

    To make the situation even harder, the application should not define what are valid associations when the application is written. If a new association type, such as casualty percentage, is to be added to some of the features in the future, this data should be stored and easily searched.

    While this type of design might not be a common business problem, it is not uncommon. Probably the reason it is not more common is because programmers are always inventing work arounds to handle the problems, and most work arounds using relational databases are poor hacks.

    However, using unstructured data (e.g. a JSON type format), this problem of unstructured information and relationships does not exist. Because all objects are just property maps, it is possible to add attributes of any type to any object.

    One important aspect of learning JavaScript and its object definition is that it often requires the program to look at object-oriented design in a completely new and different manner, increasing the tools they have to solve problems.

    39 For more information about unstructured data, see information about NoSQL database, such as


    This page titled 5.8: Unstructured Data is shared under a CC BY license and was authored, remixed, and/or curated by Charles W. Kann III.

    • Was this article helpful?