Hey guys, welcome to database development and design for everyone. This is Trevor Williams talking to you. And I'll be here to guide you through each step as we go through the world of database development. Now, just spare me about five minutes as we get started, we'll be exploring some of the jargon some of the key words used in database development. And we'll just have an underlying foundational knowledge. But this course is going to be completely practical.

So I'm not going to bore you guys with much theory. The first thing we want to take a look at is data. And what it is now data is any facts related to an object, an object can be a person within the context, and the beats are related to the person or the facts related to the person could be their name, their age, their date of birth, stuff like that. All of those things are called data. And then a database is essentially a systematic collection of these data points are these facts related to the objects and database within the context of my SQL, or other similar engines will help us to store and manipulate this data and make management of it easy. Now, my SQL is what you call a database server or relational database management system, and essentially a database management system that allows users to access manipulate and represent the data in whatever form they wish.

And my SQL Server is actually free for development. There is an Enterprise Edition but for all purposes, and for the purposes of this class, it is free. Now whenever you talk about a database, and most times that relational database you see the three letters Sq and L, it is in my SQL, Microsoft SQL PostgreSQL, lots of them are SQL they all have this that these three letters SQL, or SQL as some people call it. So SQL is really standard language. across most relational databases for manipulating and retrieving data, and it is short for Structured Query Language. And if you look at the examples I have outlined here, you'll see in all caps, those are the key words.

And in lower caps, those would be more user defined. So the customer is for instance, in the first line, select star from customers select means I want to bring up the records star or the asterisk really means all from and then we have the table named customers. So we have all the data from the Customers table coming back and the Customers table is really storing all of the data points relating to any one customer. Now I just alluded to a table called customers. So we'll just look at what exactly a table is. And basically a database consists of one or more tables.

Table is usually created for each entity or objects that you want to track. Facts are data points on and that the table is made up of rows and columns. Just think of an Excel spreadsheet, you have columns with headings, and then you have rows and each cell contains some value corresponding to the column of a head and the rule would represent one hold record. That is pretty much the layout of any database table in a relational database, where the rule is contains data points. And the columns basically specify the data type and what type of data should be stored. It is always best practice to one name the table very uniquely according to what it is you're storing data on.

So the like we just saw we had a table specifically for customers. We don't expect to see anything but customer information or data in that table. And also each customer or rule or record in this customer's table should be uniquely identifiable and This unique identifier is called a primary key. So for every table we create, we will create the records using a primary key. Now very quickly, we look at what our relationship is, lets us go back to the example of customers. And let's say Amazon needs to track all its customers.

And also all of the orders that these customers make. No, the orders will be stored in a table called orders, and the customers in a table called customers. So our relationship exists between the customer and one or many orders. And essentially, we need a mechanism to be able to link an order to a customer because an order can't exist without the customer. So that is essentially what our relationship allows us to do, where we have two distinctly different data sets and we're linking them showing that they are related to each other. Now whenever we talk about relationships, we'll also talk about four keys on a foreign key is essentially that link that is used to facilitate our relationship.

So the example this time is about teachers, all teachers in the teachers table are uniquely identifiable by a primary key. And then we have a class table to see that, okay, a class exists because this subject is being taught at this time in this room by this teacher. So we need a way to track the teacher that is associated with the class. So instead of trying to duplicate this teacher's information for every class that this teacher might have, we import that unique identifier from the teacher table into the classes table for each class record. And then once we see that this foreign key, right so we have the teacher ID in the teachers table, and we import that value over to the classes tables below. It's called a foreign key.

And once you see that this foreign key matches a primary key In the teachers table, then we know that there is a relationship. So I'm not going to go into too much theory here with you guys. I just want you to have an appreciation of how databases work in the grand scheme of things and throughout the rest of this course we will get into far more detail and like I said, it's far more practical than this. That's it for boring you with theory and PowerPoint slides. So let's get right into the meat of the matter. The next video we will be installing Microsoft, my SQL Server and workbench