Introduction to databases

. All right! Great! One thing you'll notice when studying programming languages is that the concepts you encounter are interrelated. This means focusing on a single topic can hardly deliver the content that must be explained in its entirety. To this story, SQL makes no exception. Despite that, we must start from somewhere, right? My working experience tells me you will be much faster in learning and writing efficient queries if you go through a brief introduction to databases. It is the best thing to begin with, so here's what I would like to share with you. The table you see here contains data about the customer cells of a furniture store. And, this is how we should read this information: Purchase number one was registered on the 3rd of September 2016. Then customer number one bought the item with code A1. Each of the four elements has a specific meaning. We will call each one a data value. All four data values make up one record. A record is each entry that exists in a table. It corresponds to a row of the table. Therefore, these four data values form one record, and these data values regarding purchase number two form another record. You could use the terms row and record interchangeably. Besides the rows, you can see the data is separated into four columns or fields. A field is a column in a table containing specific information about every record in the table. This means all the records in a table, regardless if they are 10, 10000, or 10 million, will have a certain purchase, number date of purchase, customer ID, and item information. When the data you have is organized in rows and columns, this means you are dealing with stored tabular data. That is important to mention because you will often see in the literature that database management relates to data stored in tabular form. Great! Here comes the more interesting part. In this table, we know nothing about a customer besides her ID. The information about customers is stored in another table, called 'Customers'. There are several fields, such as first and last names, email address, and the number of times customers have filed a complaint in our store. So, what would the logic of that structure be? Every time we have a customer with an ID number one in the 'Sales' table, we can refer to the customer with ID number one in the 'Customers' table and see her name, email, and number of complaints filed. Same goes for the 'Items' table. It contains the item code, product description, it's unit price ID, and name of the company that has delivered it, and the company's headquarters phone number. Here, the connection between the 'Sales' table and the 'Items' table is not the 'customer ID', but the 'item code'. Well, we could stuff this information into one table and it would look like this. Ouch! It is huge! I would not want to imagine what the table would look like if we had registered over 10 rows! My point is - there are too many columns, and it is hard to understand what type of information is contained in the larger table. Relational algebra allows us to use mathematical logic and create a relation between a few tables in a way that allows us to retrieve data efficiently. Namely, these three tables - 'Sales', 'Customers', and 'Items' - are related through the customer ID or the 'item code' columns and form a relational database. And, importantly, each one bears a specific meaning and contains data characterizing it. One of the tables contains information about sales, the other about customers, and the third about the items. To recap, remember the data values in a row form a record in a table, and each column represents a field that carries specific information about every record. A few related tables form a relational database. And, for those of you who are interested in slightly more technical definitions, remember the smallest unit that can contain a meaningful set of data is called an entity. Therefore, the rows represent the horizontal entity in the table, the columns - its vertical entity. The table is a bigger data entity on its own. It can also be referred to as a database object. A single row of a table, being a single occurrence of that entity, can be also called an entity instance. O. Great! We will gradually build the theoretical preparation you need before you begin coding. Stay tuned for the next lecture, where you'll see SQL's role when working with relational databases. Thanks for watching!