Martin has 20 years experience in Information Systems and Information Technology, has a PhD in Information Technology Management, and a master's degree in Information Systems Management. He is an adjunct professor of computer science and computer programming.
An Alternative to SQL
Yes, we actually have no SQL Relational Databases!
It may seem like the landscape of database management systems is dominated by SQL and relational database management systems. A relational database is made up of tables, records, and columns, and the tables are connected together through specific relationships. Once built, they can be very complex and quite rigid; changing the relationships is often difficult. As the database increases in scope, the number of tables and relationships also increases. How are you supposed to manage data that are not necessarily organized/structured?
NoSQL does not mean the absence of SQL; instead, it means Not Only SQL. In other words, we are not limited to a single option to store and retrieve the data. As its name implies, there is no fixed definition for what NoSQL is or does, but the following concepts can help us understand what NoSQL is (and isn't):
- No relational model
- Data can be clustered
- Most solutions are open-source
- Built for the Web
- Lack of a schema
Since everyone is on the Web these days, it doesn't make a lot of sense to keep the database separate from the applications it serves. Think about sites like Facebook - their data storage needs are completely different than those of a large organization's administrative systems. The relational model just doesn't work as well for that large amount of data.
In part, this is because the relational model is fairly rigid, which means that changing an existing structure can be time-consuming. NoSQL, on the other hand, is very flexible. It can accept different data types with ease, including structured or unstructured. Structured data is arranged in neat rows and columns, and can be very tidy, if not huge and complex. Unstructured data, on the other hand, isn't organized; it doesn't follow the strict patterns found in relational databases.
Relational databases can also have very large tables, leaving them with records that can be bloated with huge numbers of columns. NoSQL, as the visuals in this lesson will show, isn't tied to this rigid nature. It offers things like a clustered approach that can actually improve performance.
Types of NoSQL
There are four broad categories of NoSQL databases: key-value, column family, document, and graph.
A key-value database is considered the backbone of NoSQL databases. The key-value database matches a key to a value; there are no relationships or structures. In the previous figure, the key is the customer ID, which grants access to that customer's orders.
This is the easiest data source to integrate with: A client can retrieve a key-value, update a key-value, or delete a key. The database doesn't care what is stored in the bucket; only the application needs to know what was stored. In the previous figure you can see that if you have the Customer ID key, you can get to all the data stored about that customer, from their address to the product they ordered. You could even add a data element, such as preferred name, to the Order bucket. This is a no-no in a relational model, but the NoSQL database doesn't care.
Accessing key-value database management systems is usually very fast, and this speed doesn't diminish as the database grows.
Column Family Databases
Unlike the specific key/row relationship found in relational databases, column-family databases store data in groups of rows. Any number of columns can be associated with the row key. This way we can access related data that is often queried together. For example, we can capture the user of a web application's profile when they are signing in.
This solution alleviates the column bloating that can be found in relational databases. Again, we see data in clusters and nodes rather than rigid structures.
When you have very deep, complex data structures, the document-based data store is a great option.
Here's a very simple example of how this might look to represent an album:
'Album':'Raised on Radio'
'Tags':['rock', 'classic rock', 'great albums']
We've just made the grand statement that NoSQL databases are alternatives to relational database management systems. But when we start discussing a graph database, we'll see that the terms entities and relationships come back.
Graph databases let you store entities and the relationships among them. Entities (the objects, people, places you are storing) are called nodes and have their own properties. For example, a node/entity could be an employee.
So how is this different than a typical relational model?
The relational model can show a single relationship, such as Manager Joe reports to Director Sandra. If you add other relationships, it means a lot of work to update the database. But in the graph database model, those many relationships can be defined.
Director Sandra can have reporting relationships with other managers but also be connected to other areas in which she works.
The graph database winds up looking like a cloud of concepts and connections, a template that's nearly impossible in relational databases.
This lesson covered NoSQL databases, or Not-Only SQL. These are non-relational databases that were born out of a need to manage large, unstructured data. There are four general types of NoSQL databases: graph database, key-value store, column store, and document database. NoSQL answers the need to work with huge data sets, a variety of data that could be unstructured, and data that could be located in different locations or data centers.
To unlock this lesson you must be a Study.com Member.
Create your account
Register to view this lesson
Unlock Your Education
See for yourself why 30 million people use Study.com
Become a Study.com member and start learning now.Become a Member
Already a member? Log InBack