Download Complete (Ebook) Getting Started with SQL and Databases: Managing and Manipulating Data with SQL by Mark Simon ISBN 9781484294925, 1484294920 PDF for All Chapters
Download Complete (Ebook) Getting Started with SQL and Databases: Managing and Manipulating Data with SQL by Mark Simon ISBN 9781484294925, 1484294920 PDF for All Chapters
com
https://ebooknice.com/product/getting-started-with-sql-and-
databases-managing-and-manipulating-data-with-sql-50493568
OR CLICK HERE
DOWLOAD EBOOK
ebooknice.com
ebooknice.com
(Ebook) Getting Started with SQL: A Hands-On Approach for
Beginners by Thomas Nield ISBN 9781491938614, 1491938617
https://ebooknice.com/product/getting-started-with-sql-a-hands-on-
approach-for-beginners-5323866
ebooknice.com
https://ebooknice.com/product/getting-started-with-sql-a-hands-on-
approach-for-beginners-5475674
ebooknice.com
ebooknice.com
https://ebooknice.com/product/getting-started-with-z-os-data-set-
encryption-50195594
ebooknice.com
https://ebooknice.com/product/getting-started-with-net-
gadgeteer-2627330
ebooknice.com
Getting Started
with SQL and
Databases
Managing and Manipulating Data
with SQL
—
Mark Simon
Getting Started with
SQL and Databases
Managing and Manipulating Data
with SQL
Mark Simon
Getting Started with SQL and Databases: Managing and Manipulating Data
with SQL
Mark Simon
Ivanhoe VIC, VIC, Australia
Introduction������������������������������������������������������������������������������������������������������������xxi
v
Table of Contents
Summary������������������������������������������������������������������������������������������������������������������������������������ 18
Writing SQL���������������������������������������������������������������������������������������������������������������������������� 19
Columns��������������������������������������������������������������������������������������������������������������������������������� 20
Comments����������������������������������������������������������������������������������������������������������������������������� 20
Filtering Data������������������������������������������������������������������������������������������������������������������������� 20
Row Order������������������������������������������������������������������������������������������������������������������������������ 21
Clause Order�������������������������������������������������������������������������������������������������������������������������� 21
Coming Up����������������������������������������������������������������������������������������������������������������������������������� 21
Chapter 2: Database����������������������������������������������������������������������������������������������� 23
About the Sample Database�������������������������������������������������������������������������������������������������������� 23
Database������������������������������������������������������������������������������������������������������������������������������� 24
Tables������������������������������������������������������������������������������������������������������������������������������������ 26
Normalized Tables����������������������������������������������������������������������������������������������������������������� 27
Multiple Values���������������������������������������������������������������������������������������������������������������������� 33
Summary������������������������������������������������������������������������������������������������������������������������������� 37
Coming Up����������������������������������������������������������������������������������������������������������������������������� 39
vi
Table of Contents
vii
Table of Contents
viii
Table of Contents
ix
Table of Contents
x
Table of Contents
xi
Table of Contents
CHECK���������������������������������������������������������������������������������������������������������������������������������� 287
Foreign Keys������������������������������������������������������������������������������������������������������������������������ 287
Indexes�������������������������������������������������������������������������������������������������������������������������������� 289
Adding Rows to a Table������������������������������������������������������������������������������������������������������������� 290
Deleting Rows from a Table������������������������������������������������������������������������������������������������������ 292
Adding More Rows�������������������������������������������������������������������������������������������������������������������� 294
Updating Rows�������������������������������������������������������������������������������������������������������������������������� 295
Altering the Table���������������������������������������������������������������������������������������������������������������������� 297
DML in Real Life������������������������������������������������������������������������������������������������������������������������ 299
Security������������������������������������������������������������������������������������������������������������������������������� 299
Front-End Software������������������������������������������������������������������������������������������������������������� 300
Summary���������������������������������������������������������������������������������������������������������������������������������� 301
Data Types��������������������������������������������������������������������������������������������������������������������������� 301
Constraints�������������������������������������������������������������������������������������������������������������������������� 301
Foreign Keys������������������������������������������������������������������������������������������������������������������������ 302
Indexes�������������������������������������������������������������������������������������������������������������������������������� 302
Manipulating Data��������������������������������������������������������������������������������������������������������������� 302
xii
Table of Contents
Index��������������������������������������������������������������������������������������������������������������������� 369
xiii
About the Author
Mark Simon has been involved in training and education
since the beginning of his career. He started as a teacher
of mathematics but soon moved into IT consultancy and
training because computers are much easier to work
with than high school students. He has worked with and
trained in several programming and coding languages and
currently focuses mainly on web development and database
languages. When not involved in work, you will generally
find him listening to or playing music, reading, or just
wandering about.
xv
About the Technical Reviewer
Atul Tyagi is a database developer who has worked
extensively in the field of data analytics for over eight years.
He has worked with various industries, including general
insurance and banking domains, and has contributed
significantly to several projects involving reporting,
datamarts, automation, data model development, and
project migration.
Atul is skilled in SQL, SAS, Python, and ETL tools such as
Informatica, SAS DI, Datastage, and SAS Visual Analytics. His
expertise in these areas has helped numerous organizations
effectively manage and analyze their data, leading to
improved decision-making and business outcomes. Atul has worked with leading
companies such as Accenture Solutions, Wipro Pvt Ltd, Acxiom Technologies, and EXL
Services.
Apart from his professional work, Atul is also passionate about sharing his
knowledge, cloud platforms, and data analytics. In his free time, he enjoys reading,
traveling, and exploring new cuisines.
xvii
Acknowledgments
The sample data includes information about classical paintings and their artists. This
information is an extract of the hard work that went into the WebMuseum
(www.ibiblio.org/wm/).
xix
Introduction
In the distant past, data was managed by computers in all sorts of ways, and there was
no one way to do this. There still isn’t, which isn’t a bad thing, because not all data can
be handled the same way. There is, however, a large body of data which can be handled
in a common way, and the early 1970s saw the development of a set of mathematical
principles in the relational model.
Starting in a lab at IBM, software was developed to handle relational data, and a
language was developed to manage it. The language eventually became the Structured
Query Language. In the early days, different vendors had their own idea of how the
language should work, but this was eventually rolled into a standard. The standard has
grown over the decades, which means that the language is also growing.
Not all database vendors follow the standard to the same degree. Some standards
were late in coming, and database vendors filled in some gaps with their imagination.
Other standards are harder to implement than it looks, and some vendors are “still
working on it.” And sometimes, the vendor just wants to do something differently.
This book looks at using SQL for basic tasks. Mostly that means fetching data and
possibly processing it. There are many database packages available, all with their own
quirks, and all with their own variations of the SQL standard. This book covers a few of
the most popular packages and makes a point of showing not only what the standard
says but also how the individual packages do things.
We’ll also look at how databases are designed, but not because we’ll be designing
any. One of the big mysteries to any new SQL user is why do we do things this way or
that, and why is the data the way it is. By understanding some design principles, you’ll be
in a better position to know why.
In this book, we make no assumptions about your prior knowledge, except that you
have an idea what a table is. You have probably had some experience with spreadsheets
as well.
As to what you might do afterward, that depends. It might be your job to fetch data to
feed it into some sort of analysis or reporting software. You might do all of your analysis
in SQL directly, or you might write queries in a specialized database application. Or you
might be a web developer looking to manage a blog or an ecommerce site.
xxi
Introduction
• PostgreSQL: https://sample-db.net/?dbmss[]=pgsql-10&db=prin
ts&br=crlf&refresh&download
• SQLite: https://sample-db.net?dbmss[]=sqlite-script&db=print
s&br=crlf&refresh&download
• MySQL/MariaDB: https://sample-db.net/?dbmss[]=mysql-ansi&d
b=prints&br=crlf&refresh&download
• Oracle: https://sample-db.net/?dbmss[]=oracle-12&db=prints&b
r=crlf&refresh&download
These links are for current versions of the software. If you want older versions, visit
the preceding site.
xxii
Introduction
Notes
Throughout the book, you’ll come across a few terms and a few expectations:
xxiii
CHAPTER 1
• Customers
• Paintings
• Artists
We will have a closer look at the structure of the database later, but the important
thing at this point is that the data is not mixed up. For example, the customers table has
all of the information about customers, and nothing else.
Each table contains rows and columns. A row is one instance of the data. For
example, each row in the customers table represents one customer. A column has
a detail of the row. For example, the customers table has separate columns for the
customer’s email address, phone number, and so on.
Of course, there’s more to a database than that, and Chapter 2 will focus on these
ideas more thoroughly.
In this chapter, we will explore the contents of one table, the customers table, using
the SELECT statement, which is the basic command to fetch data. Along the way, you’ll
see how the results can be filtered, recalculated, and sorted.
1
© Mark Simon 2023
M. Simon, Getting Started with SQL and Databases, https://doi.org/10.1007/978-1-4842-9493-2_1
Chapter 1 Starting with SQL
Everything we cover here will be covered in more detail in later chapters, so you can
take a fairly relaxed approach to what we’re doing in this chapter.
If you run the following sample code, your results may not be exactly the same.
This is because the sample data, which is randomized, may not be the same as
the data used in the book. You may also find differences in the way DBMSs present
unsorted data.
~ 304 rows ~
This is called a SELECT statement and will fetch all the rows from the
customers table.
Statements usually comprise two or more clauses. In this case, they are the SELECT
clause and the FROM clause.
2
Chapter 1 Starting with SQL
Note
• SELECT doesn’t mean display, although the database client doesn’t know what
else to do with the results. Other software might simply fetch the data to be
further processed.
• The * doesn’t mean all rows. It is a shorthand for all columns of the table.
Case Sensitivity
The SQL language is case insensitive, meaning that you can type the statement in upper
or lower case:
This book will use UPPER CASE for keywords, but you don’t have to.
Spacing
Although a simple statement might easily fit on one line, you can add as many line
breaks and extra spaces or tabs as you like:
SELECT
*
FROM customers;
The most important thing is to keep your code readable and to use spacing to help in
managing the statement.
As the book progresses, there will be more recommendations on layout. However,
these are recommendations only, as SQL will work just as well with minimal spacing.
3
Chapter 1 Starting with SQL
Clause Ordering
The original proposed name for SQL was SEQUEL, Structured English Query Language.
The idea was that the syntax would resemble the English language.
This has led to a syntax quirk. For example, if you say
you first go to the refrigerator and then get the milk. That is, From is processed
before Get.
Similarly, in the SELECT statement, the FROM clause is processed before the
SELECT clause.
However, you cannot write the statement that way:
Later, you will see additional clauses and where they fit in.
In this simple example, the fact of the clause order is not important. However, later,
the clause order will explain why some more complex examples don’t work the way you
would expect.
• Most DBMSs will allow you to ignore the semicolon if there is a single
statement. However, you will at least need a semicolon between
multiple statements.
• Microsoft SQL will also allow you to omit semicolons for multiple
statements, unless you have them on one line, but even Microsoft
doesn’t think that’s a good idea (see https://docs.microsoft.com/
en-us/sql/t-sql/language-elements/transact-sql-syntax-
conventions-transact-sql#transact-sql-syntax-conventions-
transact-sql).
4
Chapter 1 Starting with SQL
We recommend that you always use semicolons, even for a single statement or for
Microsoft SQL. This way, you make sure that your code is less prone to errors.
~ 304 rows ~
• Note that in this case the givenname and familyname order is reversed
and that the email column is omitted.
• The space after the comma is optional: include it if you think it makes
it more readable.
5
Chapter 1 Starting with SQL
• The comma is a separator: don’t put a column after the last column,
as SQL will expect another column.
It’s a good idea to always specify the columns, even if it’s all of them.
Column Order
The default column order, which you see with SELECT *, is defined when the table is
created. You may not be able to change it, even if you have permission.
In SQL, there is no correct column order, and there is no performance difference if
you select in a different order. That is, there is no preferred column order, so you choose
the order which best suits your needs, either for presentation or to feed into another
application.
Layout
With a growing column list, it makes sense to lay the columns out more creatively:
SELECT
id,
givenname, familyname
FROM customers;
• The column list is indented from the SELECT command to show that
they are part of the same clause.
• givenname and familyname are on the same line to show that
conceptually they are related to each other.
You will find layout easier to maintain if you remember to use the tab key.
6
Chapter 1 Starting with SQL
Also, as mentioned before, you can use any spacing you like; just make sure that the
statement is as readable as possible.
Using SELECT *
It is considered bad practice to use SELECT * in real life, even if you really want all of the
columns; always specify all of the columns. This is because
However, in this book, you will see SELECT * used very often:
Just remember that when using SQL in earnest, you should always list the actual
column names.
Calculated Columns
The selected columns don’t have to be the original columns. They can be derived from
one or more columns. Among other things, this means that the table never needs to keep
variations on a value since it can always be recalculated when the time comes.
For example:
SELECT
id, givenname, familyname,
height, -- height in centimetres
height/2.54 -- height in inches
FROM customers;
7
Chapter 1 Starting with SQL
~ 304 rows ~
In the customers table, height is measured in centimeters. For those who prefer a
legacy measurement, you can convert to inches by dividing by 2.54.1
It would have been a mistake to design a table with both centimeters and inches.
Tables should never have a column which is basically the same as another in disguise. As
you see, you can always recalculate the other value.
Aliases
When experimenting with a SELECT statement, you can leave calculations as they are, but
you will notice that the result will have a missing or dummy name.
When taking your SELECT statement seriously, you will need to give calculated
columns a distinct name:
SELECT
id, givenname, familyname,
height as centimetres,
height/2.54 as inches
FROM customers;
1
Apparently, only three countries haven’t yet officially adopted the metric system: Myanmar,
Liberia, and the United States. However, the United States has long adopted the metric system as
the basis for customary units. In this case, the old inch is now fixed at exactly 2.54 cm.
8
Chapter 1 Starting with SQL
~ 304 rows ~
As you see, you can also alias uncalculated columns if you feel the need to make the
point clearer.
You will see more on calculated columns and aliases later.
Comments
In an elaborate script, it is useful to include comments about what is going on. A
comment is any text which will be ignored by SQL, but is meant for humans to read.
You’ve already seen a few comments in the previous examples. The standard
comment is text following the -- characters, until the end of the line:
SELECT
id, givenname, familyname,
height/2.54 as inches -- 1in = 2.54cm
FROM customers;
You will find out soon enough which variations work for your DBMS. Usually,
comments are highlighted in a different color.
Block Comments
Most DBMSs also support an unofficial block comment:
/* block comment */
This style is also known as the C-style comment because of its use in the C
programming language.
The block comment begins with the /* combination and ends with the reverse */
combination. It can span multiple lines or take up just part of a line.
Normally, you should avoid non-standard SQL features, since you never know what
the future holds. However, this one is so widely supported that you can regard it as
simply a missing feature supplied unofficially.
Uses of Comments
Since SQL completely ignores comment text, you can write anything you like, even if it
amounts to gibberish. However, the following are common uses of comments:
/* SQL Sampler
10
Chapter 1 Starting with SQL
================================================
This is an introductory SELECT statement
The rest of the book will go into more detail
================================================ */
SELECT
id,
-- email,
givenname, familyname,
height/2.54 as inches -- 2.54 cm = 1 inch
FROM customers;
In the preceding example, the email column is disabled, the inches column is
explained, and the whole script is preceded by a header comment block. The actual
query is also indented for good measure.
Normally, if you want to disable code, you simply delete it. Using a comment
instead is called commenting the code out. The reasons why you would comment code
out include
• Testing or troubleshooting
As regards explanatory code, don’t overcomment. Only explain what isn’t obvious.
Saying too much is like the boy who cried wolf. As a rule, others will simply tune out.
Filtering Rows
Often, you don’t want all rows of a table, but only some of them. The WHERE clause is used
to decide which rows to select:
SELECT
id,
givenname,familyname,
height/2.54 AS inches
FROM customers
WHERE state='NSW';
11
Chapter 1 Starting with SQL
~ 67 rows ~
The expression state='NSW' is called an assertion and is either true or false. The
WHERE clause selects only those rows where the assertion is true.
Note the single quotes ' … ' around the NSW. In SQL, text values are called strings
and are enclosed in single quotes. Don’t use double quotes " … " because most DBMSs
will interpret double quotes differently. Also, note that the string is in UPPER CASE,
which matches the data in the customers table. In some DBMSs, you can also use lower
case, but not in others.
You will learn more about strings later in the book.
Clause Ordering
The WHERE clause is evaluated after FROM, but before SELECT:
SELECT …
FROM …
-- SELECT processed here!
WHERE … ;
12
Chapter 1 Starting with SQL
Remember, however, that you must write the SQL in the preceding order.
SELECT *
FROM customers;
WHERE state='NSW' -- oops
This is because you have correctly ended the previous version with a semicolon and
simply added a new clause after it. While you are developing your code, it may be helpful
to put the semicolon on a separate line:
SELECT *
FROM customers
WHERE state='NSW'
;
This makes it easier to add the additional clauses as you go. You can always tidy up
the semicolon when you have finished everything.
SELECT
id,
givenname, familyname,
13
Chapter 1 Starting with SQL
height/2.54 as inches
FROM customers
WHERE state='NSW'
ORDER BY familyname, givenname;
~ 67 rows ~
In this example, you order the results by familyname and, in the event of a tie, by the
givenname.
You can order by one or more columns, in ascending or descending order.
Strictly speaking, the result is no longer a set, as a set is unordered. In some cases,
you won’t be able to do any more processing once the ORDER BY clause is used.
You will learn more about the ORDER BY clause later.
Clause Order
The ORDER BY is both written and evaluated last:
SELECT …
FROM …
WHERE …
-- SELECT processed here
ORDER BY … ;
14
Chapter 1 Starting with SQL
Remember, however, that you must still write the SQL in the preceding order.
Distinct Rows
Sometimes, you will need to interpret what somebody asks for. For example, if you want
a list of email addresses, the following would do the job:
judy.free474@example.net
ray.gunn186@example.net
ray.king144@example.net
ivan.inkling179@example.com
drew.blood475@example.net
seymour.sights523@example.net
~ 304 rows ~
On the other hand, if you want a list of states, the following is probably not what
you want:
NSW
VIC
NSW
WA
QLD
VIC
NSW
NSW
QLD
TAS
~ 304 rows ~
You will, of course, get a list of all of the state values (as well as a few NULLs which
represent missing values). However, you probably don’t want the duplicates. If you want
one of each, you will need to use DISTINCT:
16
Chapter 1 Starting with SQL
WA
[NULL]
TAS
VIC
NSW
NT
QLD
SA
~ 8 rows ~
Using DISTINCT treats each value not as an individual value but as a group. You can
say that you now have the state groups.
Note that one of the groups is NULL, meaning that you also have some missing states.
The DISTINCT operator acts only on what is in the SELECT clause. If you add the town
column as well:
17
Chapter 1 Starting with SQL
SA Windsor
[NULL] [NULL]
VIC Belmont
SA Alberton
NSW Hamilton
WA Wattle Grove
VIC Stirling
VIC Gordon
TAS Beaconsfield
SA Richmond
~ 79 rows ~
Here, you will get distinct combinations of state and town. In the result set, it’s not
the state which is distinct nor the town—it’s the combination. We can say that we now
have state/town groups.
Again, you will see the NULL as a separate group. In this set of data, there is no state
without a town and vice versa, which is why there’s only one group with NULLs.
Summary
Here is a sample of the SQL we have been developing:
/* SQL Sampler
================================================
This is an introductory SELECT statement
The rest of the book will go into more detail
================================================ */
18
Chapter 1 Starting with SQL
SELECT
id,
-- email,
givenname, familyname,
height/2.54 as inches -- 2.54 cm = 1 inch
FROM customers
WHERE state='NSW'
ORDER BY familyname,givenname;
This illustrates the main parts of an SQL SELECT statement, as well as the use of
comments and layout.
The basic SELECT statement is
SELECT columns
FROM table;
Writing SQL
SQL is a simple language which has a few rules and a few recommendations for
readability.
• SQL is relaxed about using extra spacing. You should use as much
spacing as required to make your SQL more readable.
• The SQL language is case insensitive, as are the column names. Table
names may be case sensitive, depending on the operating system.
Remember, some parts of the language are flexible, but there is still a strict syntax to
be followed.
19
Chapter 1 Starting with SQL
Columns
The SELECT statement will select one or more columns of data from a table.
Remember that in well-written SQL statements, you shouldn’t use SELECT * for your
columns. However, in this book we’ll use it to focus on the new clauses.
Comments
A comment is additional text for the human reader which is ignored by SQL.
Remember to use comments sparingly, only when they actually tell the reader what
they need to know.
Filtering Data
Rows can be filtered with a WHERE clause.
• When filtering strings, the values may or may not be case sensitive,
depending on the DBMS and the actual database.
The WHERE clause can be used to return a single row, which is known to be unique, or
a subset of rows. Occasionally, you’ll get nothing which matches the criterion.
20
Chapter 1 Starting with SQL
Row Order
SQL tables are unordered collections of rows.
Technically, once you use ORDER BY, the result is not a true set. Often, that doesn’t
matter, but some operations can’t be performed after ORDER BY.
Clause Order
The four main clauses so far are written in this order:
SELECT columns
FROM table
WHERE conditions
-- SELECT is evaluated here
ORDER BY columns
The SELECT clause is the last to be evaluated before the ORDER BY clause.
Coming Up
This has been a simple sampler of how SQL works. In the following chapters, you’ll see
more details on the individual clauses as well as how to work with multiple tables, how
to calculate and summarize data, and how to make simple changes to the data.
Before that, however, we’ll have a look at how SQL databases are structured.
21
CHAPTER 2
Database
In Chapter 1, you had a taste of using SQL to extract data from a database. We were
a little bit in the dark there, since we weren’t fully informed about what was in the
database. Sadly, that’s often the case in real life, but here we’ll get a better look at the
databases itself.
In this chapter, we’ll look at what’s going on. This will be on two fronts:
• You’ll learn a little about the theory and practice of database design:
Why is it the way it is?
• You’ll also learn about the details of the sample database itself: What
specifically is in this database?
The theory part won’t be too heavy. You’ll learn about tables, which are the basic
structure of all data, and the rules of so-called normal tables: how data is structured to
be as simple and reliable as possible. You’ll also look at how we manage working with
multiple values.
The sample database follows a typical design, even if it’s quite a small database. It
will have enough to make it worth searching and analyzing. More to the point, it will
have a bit of everything we need to explore.
23
© Mark Simon 2023
M. Simon, Getting Started with SQL and Databases, https://doi.org/10.1007/978-1-4842-9493-2_2
Chapter 2 Database
• One detail of the paintings is the artist. We do not store the artist’s
details in the paintings table. Instead, there is a separate table, and
the painting has a reference to the artist.
Figure 2-1 will give you a good idea of how the database is structured.
In this chapter, we’ll have a look at some of the ideas that go into designing a
database, and we will also get a closer look at the sample database for the exercises.
Database
SQL databases are based on the theory of Relational Database. In turn, this is based on
some important mathematical concepts, including Sets and Logic.
An important principle of Relational Database is this:
There is one unique place for each item of data.
In particular, this means
24
Chapter 2 Database
In theory, SQL databases are a limited version of “pure” Relational Databases. For
this reason, we will refer to them more specifically as SQL databases.
Database Terminology
We’ll try not to get too pedantic on terminology, but some terms are important to make
things clear.
A database is a collection of data. In theory, this data can be managed any way you
like, such as in word processing documents or record cards or on notches on pieces of
wood. Here, of course, we’re talking about managing the data on a computer system.
A DBMS is the software that manages the data. There are, of course, many DBMSs
available, and this book accommodates some of the more popular ones.
SQL, or Structured Query Language (officially, it is pronounced as it is spelled), is the
language used to communicate with the database. There is an official ISO standard, but
all DBMSs have variations on this standard.
Some users try to pronounce it as SeQueL, which was earlier proposed as its official
name. Due to a naming conflict with other software, in the end it was just called SQL. If
you like, you can also pronounce it as SQuaLl, SQueaL, SQueLch, or SQuaLlid.
25
Chapter 2 Database
Tables
An SQL database is a collection of distinct tables. Each table describes a type of data,
such as a customer or a painting.
For example:
When you run the preceding code, you will find that the customer table has nothing
to say about paintings, and vice versa.
Table Terminology
SQL uses the language of tables, and tables have rows and columns.
You will sometimes see some other words used to describe the data, but they are not
the language of SQL. Table 2-1 shows some of the alternative terminology used for some
of the concepts.
In particular, avoid using the terms Record and Field in the company of other SQL
developers, as they will tend to look down their noses at you. On the other hand, the word
Field in particular does sometimes appear in official documentation, so it’s not quite so bad.
In this book, we will use the standard SQL terminology. You will sometimes see the
word record used in its original sense, that of saving information.
26
Chapter 2 Database
Normalized Tables
In principle, you could organize your data table any way you want, but if you want your
data to be as maintainable as possible, it needs to follow some rules.
The following rules are not there just to make the game more interesting. The rules
will result in tables where data is in its simplest, most dependable form. Mathematicians
refer to this form as its normal form.
Overall, the goal of normalization is to ensure that every piece of data has exactly one
place. There should be no repetitions and no ambiguity.
As you’ll see, this often results in creating additional tables, so the data you’re
looking for may be spread all over the place. That can be inconvenient. Later, when we
look at joining tables, we’ll see how we can manage this inconvenience.
Database theory defines a number of levels of normalization, but most of the
principles are covered in the following text.
In real life, you’ll find that database developers often relax some of these principles
to avoid spreading the data in too many places, making even the simplest query a
challenge. However, that always risks making the data less reliable.
Data Is Atomic
If you select
SELECT
id,
givenname, familyname
FROM customers;
you will note that the given name and family name are in separate columns. This
makes it easier to sort the data and to search for it.
Data should be in its smallest practical unit. If it is, we say that the data is atomic,
from a Greek word meaning that it can’t get any smaller.
Note the word “practical” earlier. You could try the same thing with the email
address:
SELECT
id,
email
FROM customers;
27
Random documents with unrelated
content Scribd suggests to you:
back
Welcome to our website – the ideal destination for book lovers and
knowledge seekers. With a mission to inspire endlessly, we offer a
vast collection of books, ranging from classic literary works to
specialized publications, self-development books, and children's
literature. Each book is a new journey of discovery, expanding
knowledge and enriching the soul of the reade
Our website is not just a platform for buying books, but a bridge
connecting readers to the timeless values of culture and wisdom. With
an elegant, user-friendly interface and an intelligent search system,
we are committed to providing a quick and convenient shopping
experience. Additionally, our special promotions and home delivery
services ensure that you save time and fully enjoy the joy of reading.
ebooknice.com