Document databases, also known as document-oriented databases or NoSQL databases, are a type of non-relational database that store data in a semi-structured format as documents. Unlike traditional relational databases which store data in tables, with rows and columns, document databases store data in flexible, nested structures that can more closely match the data’s natural hierarchical relationships.
Some of the most popular document databases include MongoDB, Couchbase, and RavenDB. These databases are often used in web and mobile applications that need to store large amounts of semi-structured or unstructured data, such as user profiles, product catalogs, and social media feeds.
Advantages of Document Databases
Flexibility: One of the biggest advantages of document databases is their flexibility. They allow you to store data in any format, without the need to define a schema beforehand. This makes it easier to add new fields or nested structures as your application evolves, without having to make changes to the database schema.
Performance: Document databases are designed for high performance when dealing with large amounts of semi-structured or unstructured data. They use indexing, caching, and other techniques to speed up queries and provide quick access to the data.
Scalability: Document databases are highly scalable, making it easy to add more capacity as your application grows. They can be scaled out horizontally, by adding more nodes to the database cluster, or vertically, by increasing the resources of the individual nodes.
Easy to use: Document databases are designed to be easy to use, with simple APIs for storing, retrieving, and querying data. They often come with user-friendly tools for managing the database, such as web-based management consoles or command line tools.
Disadvantages of Document Databases
Lack of consistency: Since document databases do not enforce a strict schema, there is a risk of data inconsistencies and data anomalies. This can make it difficult to ensure the quality and integrity of the data over time.
Lack of transactions: Many document databases do not support transactions, which can make it difficult to ensure that related data updates are made atomically. This can lead to problems such as data loss or inconsistent data in the event of a crash or network failure.
Complexity: While document databases can be easy to use for simple applications, they can become complex to manage and maintain as the data grows. This is especially true for large-scale applications with complex data structures and relationships.
In conclusion, document databases are a type of NoSQL database that are well-suited for storing large amounts of semi-structured or unstructured data. They offer advantages such as flexibility, performance, scalability, and ease of use, but also come with disadvantages such as a lack of consistency, lack of transactions, and increased complexity as the data grows. When choosing a document database, it’s important to consider your specific use case and requirements, and weigh the advantages and disadvantages carefully.
We will be using SQL Server Management Studio in the following lessons. If you have SQL Server installed on your machine, search for MS SQL Server Management Studio in programs or search for SSMS. If you need to install MS Sql Server: click here
Once it opens, enter the server you are looking to connect to and pick your authentication method (I’m using Windows Authentication, but you could set up a SA account and use Server Authentication)
If you properly connect to the server, you should get an object explore like the one seen below
Create a database
If you are working on work or school SQL Server, you may not have rights to create a database, you will most likely have a database assigned to you that you can build tables in. You can skip to the table creation part of the lesson.
Method 1: Using the Gui
Right click on database in the object explore, click New Database
Next name your new database, leave all other settings as is. Click Ok
Your new database’s name will appear in the list of databases now
Method 2: Use SQL
This is my preferred method. And again, we will just be using the default settings here to make this lesson easier.
Click the New Query Button to open a new query window
In the new window, type the following (note the semicolon at the end of the line, this is standard SQL and used by most system. SQL Server allows you to replace ; with the word GO. It is completely legit, I just don’t use it because no other system does either)
Create Database Test2;
Then click Execute
If you don’t see your new database appear in the Object Explorer, right click Database ,and select Refresh
Select Database to Work With
Method 1: Gui
From your query workspace, select your database from the drop down menu
Method 2: SQL Code
Go to a query workspace and type in the following code
I tend to like this method because you can put it on the top of code you might share and it will guide people to the right database
Method 1: Gui
Hit the + next to your database to expand
Right Click Tables > New > Table…
Now manually enter column names and datatypes for your new table
Once you are done. Click the X to close this tab. You will be first asked to save changes (yes) then you will be asked to Name you new table
Method 2: Sql Code
From your query window, use the following code to create a table:
Choose Microsoft Excel as Data source, browse for your file, make sure First row has column names is selected, click Next
Select SQL Server Native client as destination. If you have more than one to pick from, choose the higher number. Click Next
Leave default options – Click Next
Select the top option, You can change the destination table name if you choose.
I choose to change it and then click Next
Leave default selections, click Next
Make sure you got 75 rows Transferred and click close
Move data to production tables
Permit_Landing is a Landing Table. That means a table you load data into initially before it is verified and moved to production tables
Refresh your database to see the new added tables. Right click on Permits_Landing and Select Top 1000 Rows
A query window should pop up and give you the following results
The goal is to move this data to the Permit table. But note, the Permit Table has a column ContractorID that is not present in Permits_Landing. So we have to use code like seen below.
insert into permit (PermitID, StartDate, ProjectTitle, [Location], Fee)
select * from Permit_Landing;
Note, we have Insert Into Permit (like before) — but we now include a list columns. We only list the columns we want to load data into. Since we don’t have ContractorID column in the landing table, we will not include it here.
Also, notice the  around Location. This is because location is a SQL key word. To let SQL Server know we are talking about a column and not a keyword, we put square brackets around it
Finally, we choose the data to load into the table using a simple select statement: Select * from Permit_Landing
I made these video walkthroughs as an alternative to following the lab in the text book. I know some people (myself included) learn better from watching videos.
This is a walkthrough for Lab 1 for my course on Database Development and Design. Feel free to watch video, but I will not be sharing any files as they were not created by me and I do not have permission to share them.
An important first step for developing a data model is taking the time to learn about the data and how the data relates.
Remember not all data is useful. While you may wish to include data that does not directly relate to the problem, this can quickly become problematic as your data model can grow into an unmanageable mess.
Keep in mind, a data model should work for:
A set of assumptions
Function within the limitations of the problem scope
Lets start with an example of a soccer (football for all my non-US friends) club data model. Here is an example of a class you could build for holding team data:
The attributes are used to capture data about each team.
But let’s look at a new problem we haven’t really discussed yet:
Look at the AgeGroup above. If I asked you what teams are in the U-12 age group, as a human you could look at the table above and tell me that Rage and Hurricanes are. However, if you tried running a query for U-12, it would only return Rage, as U – 12 and U-12 are viewed as completely different terms by a computer.
To prevent this, one approach could be to create a new class
Now, U-12 will only appear once in the Agegroup table, this removes the risk of someone typing it in differently like in the table before. Integrity of data accuracy is something to consider when deciding how many tables to create.
Now lets look at the issue of team captains, considering a team captain is also a player. The diagram below shows there are 2 relationships between Player and Team classes. This is perfectly okay.
•Do you want to select objects based on the value of an attribute? Then you may want to introduce a class for that information.
(Ex: you want to see all teams that are in age group “U-12”)
•Do you need to store other data about this information? Then you may want to introduce a class for that information. (Ex: We are storing the team captain’s name but also want his/her email and phone number)
•Are you already storing similar information? Then you may want to use a relationship among existing classes. (Ex: the information about team captain is the same as the information about the players, so use that class with a new relationship)
Multiple Companies in One Building
Now consider the example of a building housing multiple companies. While the diagram below is not completely incorrect, I will argue against the relationship between Employee and Room. In this example, it appears that you can infer the Employee location through the Company-Room relationship. While having multiple route for data isn’t wrong, make sure they convey different information.
•Each employee belongs to one division
•Divisions are made up of many Groups
•The problem here is if you try to infer something that was not intended
•You know it’s a fan trap when you have 2 relationships with many cardinality on the outside ends
They way the data model is written, a division can have many different employees and a division can also belong to many different groups. So trying to determine what group an employee belongs to via their division is impossible in this data model.
•Each employee can belong to at most 1 group
•Each group belongs to 1 and only 1 division
•Divisions are made up of many Groups
•Can you answer the question, “What division does each employee belong to?”
•You know it’s a chasm trap when the connection is not always there or there is a gap in a route between classes
•Ann doesn’t belong to a group since the optionality is 0
•We can only determine division based on group assigned
•So we have no idea what division Ann is in
Multiple Routes Between Classes:
•Whenever there is a closed loop, check to see if the same information is being stored more than once (don’t be redundant).
•Make sure you are not inferring more than you should from a route. Always look out for the case when a class is related to two other classes with a cardinality of many at both outer ends.
•Ensure that a path is available for all objects. Are there optional relationships along the route?
You an even have a Self Relationship
•Say that a club requires an existing member to sponsor any new members
•You wouldn’t have a class for member and a class for sponsor because they have the same data
•You can represent this type of situation with a self relationship because objects of a class can be related to each other
The entire purpose of related tables is that they allow you to query information from multiple tables at once. In this example we will be creating a query that looks at the Class and Teacher tables we built in the intro to MS Access Lesson: link to lesson
To start, we will select Create from the Menu bar and Query Design from the Ribbon
Next drag the Teacher and Class table over to the blank space for Query1
down below you can select the columns (fields) you want to bring in from the tables.
Next, put all the all the available columns in the Fields below
Right click on the query tab and select datasheet view.
Note the two tables are matched up by the teacherID in two different tables. That is the relationship. That is how relational database allow tables to interact
Lets remove the teacherID from the query
Go back to design view and uncheck the columns to hide them from the query
To see the results, click on the Query1 tab and select Datasheet view
So you can see, our query returned information found in 2 different tables
Now, let’s right click on Query1 tab and select SQL View
This is how you would write this query using SQL
Select Class.ClassID, Class.Class_NM, teacher.teacher_name — This means that we want to see these three columns. Note the table name is in front, followed by the column or field name, separated by a ‘.’ This is common practice in SQL. It tells the database which table the field is in. And in situations like the teacherID column that is found in both tables, it clarifies which one you want.
from teacher INNER JOIN Class ON teacher.teacherID= Class.TeacherID; — this is a typical join statement. It says use both teacher and Class tables, and match the records up using the TeacherID field.
I am using the same database I build in the previous lesson. You can start a new one if you want, but since most of these early lessons will be sandboxing( a programming term for playing around with a software platform) in Access it doesn’t really matter if you just use the same database for everything.
From the Home screen in Access, click on the External Data tab and open up the External Data ribbon
Select New Data Source > From File > Excel
Browse for your excel file, select Import the source data into a new table and click ok (note, if you want to use a different Excel file, you can)
My excel file has column names in the first row, so I make sure that is check and I click next
Up top, you can change column names, and data types, but in this case, Access did a good job of assigning datatypes for me. Next>
I check Let Access add primary key, you could just select your own from the drop down though. Next >
Name your table whatever you want and hit Finish
If you spent a lot of time fixing data types and column names or if you are going to upload a file like this on a regular basis, you can save import steps, but I am going to skip this for now, just hit close
Click on your new table to open it up
Filters and sorting work like they do in Excel, here I select my column and Sort Largest to Smallest
Here is select Model and filter down to a single model (Accuvix A30)