Sql For Dummies

Unveiling the Power of SQL: A Beginner’s Guide to Data Mastery

In a world brimming with data, the ability to manage and analyze it efficiently is a superpower. Whether you’re a data scientist, software developer, or aspiring tech enthusiast, SQL (Structured Query Language) is the foundational skill that opens the doors to data manipulation and decision-making.

SQL isn’t just a tool; it’s a language that speaks the essence of databases. From querying small datasets for personal projects to managing enterprise-level databases, SQL has become the go-to solution for anyone aiming to unlock insights from data.

In this blog, we’ll take a deep dive into the world of SQL. Whether you’re a beginner or someone looking to polish your skills, this guide will serve as your ultimate starting point. Let’s unravel the magic of SQL and turn complex data into meaningful information!

  • History of SQL

  • What is Database?

    • What Is a Database Management System?

    • Database Models

    • Why relational is better

    • Enjoy the view

    • Schemas, domains, and constraints

History of SQL

The SQL (Structural Query language) was first created in the 1970s by IBM researchers Raymond Boyce and Donald Chamberlin. The Query language, known then as SEQUEL, was created following the publishing of Edgar Frank Todd's paper, In 1970, A Relational Model of Data for Large Shared Data Banks. In his paper, Todd proposed that all the data in a database be represented in the form of relations. It was based on this theory that Chamberlin and Boyce came up with SQL. The original SQL version was designed to retrieve and manipulate data stored in IBM's original RDBMS known as "System R." It wasn't until several years later, however, that the Structural Query language was made available publicly. In 1979, a company named as Relational Software, which later became Oracle, commercially released its version of the SQL language called Oracle V2. Since that time, the American National Standards Institute (ANSI) and the International Standards Organization have deemed the SQL language as the standard language in relational database communication. While major SQL vendors do modify the language to their desires, most base their SQL programs off of the ANSI approved version.

What Is a Database

A database is a well-ordered collection of data. A database is an electronic system that permits data to be easily manipulated, accessed, and updated, or an organization uses a database as a method of managing, storing, and retrieving information. Modern databases are handled using a database management system (DBMS).

What Is a Database Management System?

A database management system (DBMS) is a set of programs used to define, administer, and process databases and their associated applications. The database being “managed” is, in essence, a structure that you build to hold valuable data. A DBMS is the tool you use to build that structure and operate on the data contained within the database. Many DBMS programs are on the market today. Some run only on mainframe computers, some only on minicomputers, and some only on personal computers. A strong trend, however, is for such products to work on multiple platforms or on networks that contain all three classes of machines. A DBMS that runs on platforms of multiple classes, large and small, is called scalable. Whatever the size of the computer that hosts the database and regardless of whether the machine is connected to a network the flow of information between database and user is the same.

Database Models

Different as databases may be in size, they are generally always structured according to one of three database models:

Relational: Nowadays, new installations of database management systems are almost exclusively of the relational type. Organizations that already have a major investment in hierarchical or network technology may add to the existing model, but groups that have no need to maintain compatibility with “legacy systems” nearly always choose the relational model for their databases.

Hierarchical: Hierarchical databases are aptly named because they have a simple hierarchical structure that allows fast data access. They suffer from redundancy problems and a structural inflexibility that makes data base modification difficult.

Network: Network databases have minimal redundancy but pay for that advantage with structural complexity.

The first databases to see wide use were large organizational databases that today would be called enterprise databases, built according to either the hierarchical or the network model. Systems built according to the relational model followed several years later.

Why relational is better

In applications written with DBMSs that follow the hierarchical or network model, database structure is hardcoded into the application that is, the application is dependent on the specific physical implementation of the data base. If you add a new attribute to the database, you must change your application to accommodate the change, whether or not the application uses the new attribute.

Relational databases offer structural flexibility; applications written for those databases are easier to maintain than similar applications written for hierarchical or network databases. That same structural flexibility enables you to retrieve combinations of data that you may not have anticipated needing at the time of the database’s design.

view

Tables can contain many columns and rows. Sometimes all of that data interests you, and sometimes it doesn’t. Only some columns of a table may interest you or only rows that satisfy a certain condition. Some columns of one table and some other columns of a related table may interest you. To eliminate data that is not relevant to your current needs, you can create a view. A view is a subset of a database that an application can process. It may contain parts of one or more tables. Views are sometimes called virtual tables. To the application or the user, views behave the same as tables. Views, however, have no independent existence. Views allow you to look at data, but views are not part of the data.

Schemas, domains, and constraints

A database is more than a collection of tables. Additional structures, on sev eral levels, help to maintain the data’s integrity. A database’s schema provides an overall organization to the tables. The domain of a table column tells you what values you may store in the column. You can apply constraints to a data base table to prevent anyone (including yourself) from storing invalid data in the table.

  • Schemas

The structure of an entire database is its schema, or conceptual view. This structure is sometimes also called the complete logical view of the database. The schema is metadata — as such, it’s part of the database. The metadata itself, which describes the database’s structure, is stored in tables that are just like the tables that store the regular data. Even metadata is data; that’s the beauty of it.

  • Domains

An attribute of a relation (that is, a column of a table) can assume some finite number of values. The set of all such values is the domain of the attribute.

  • Constraints

Constraints are an important, although often overlooked, component of a database. Constraints are rules that determine what values the table attrib utes can assume. By applying tight constraints to a column, you can prevent people from enter ing invalid data into that column. Of course, every value that is legitimately in the domain of the column must satisfy all the column’s constraints. As I men tion in the preceding section, a column’s domain is the set of all values that the column can contain. A constraint is a restriction on what a column may contain. The characteristics of a table column, plus the constraints that apply to that column, determine the column’s domain. By applying constraints, you can prevent the entry into a column of data that falls outside the column’s domain.

11
Subscribe to my newsletter

Read articles from URANDUR BATI MURARI directly inside your inbox. Subscribe to the newsletter, and don't miss out.

Written by

URANDUR BATI MURARI
URANDUR BATI MURARI