По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
SQL, произносится как "эс-кью-эль", является критическим инструментом для ученых в области данных. На самом деле, возможно, это самый важный язык для работы с данными. В этом руководстве для начинающих рассмотрим основы SQL.
Начнем с ответа на простой вопрос:
Что такое SQL?
SQL (Structured Query Language) расшифровывается как язык структурированных запросов. Язык запросов - это своего рода язык программирования, предназначенный для облегчения получения конкретной информации из баз данных, именно это делает SQL. Проще говоря, SQL - это язык баз данных.
Это важно, потому что большинство компаний хранят свои данные в базах данных. И хотя есть много типов баз данных (как MySQL, PostgreSQL, Microsoft SQL Server), большинство из них говорят на SQL, так что, взяв на вооружение основы SQL, вы сможете работать с любым из них.
Даже если вы планируете выполнить анализ на другом языке, таком как Python, в большинстве компаний, скорее всего, потребуется использовать SQL для извлечения необходимых данных из базы данных компании. Согласно данным платформы Indeed на данный момент на только в США существует более 80 000 предложений по SQL.
Давайте начнем с изучения SQL! В руководстве мы будем работать с набором данных сервиса обмена велосипедами Hubway, который включает в себя данные о более чем 1,5 миллионах поездок, совершенных через этот сервис.
Мы начнем с того, что рассмотрим базы данных, каковы они и почему мы их используем, прежде чем начнем писать собственные запросы в SQL.
Для изучения нам потребуется база, которую вы можете загрузить здесь:
Скачать БД
Основы SQL: реляционные базы данных
Реляционная база данных - это база данных, которая хранит связанную информацию в нескольких таблицах и позволяет запрашивать информацию из нескольких таблиц одновременно.
Легче понять, как это работает, продумав пример. Представьте, что у вас есть бизнес и вы хотите следить за информацией о продажах. В Excel можно настроить электронную таблицу со всей информацией, которую необходимо отслеживать, в виде отдельных столбцов: Номер заказа, дата, сумма к оплате, номер отслеживания отгрузки, имя, адрес и номер телефона клиента.
Такое решение отлично подойдет для отслеживания информации, на начальных этапах работы, но, когда вы начнете получать повторные заказы от одного и того же клиента, вы обнаружите, что их имя, адрес и номер телефона хранятся в нескольких строках вашей электронной таблицы.
По мере роста вашего бизнеса и увеличения количества отслеживаемых заказов эти избыточные данные займут ненужное место и, как правило, снизят эффективность вашей системы отслеживания продаж. Также могут возникнуть проблемы с целостностью данных. Например, нет гарантии, что для каждого поля будет установлен правильный тип данных или что имя и адрес будут каждый раз вводиться одинаково.
При использовании реляционной базы данных, как и на приведенной выше схеме, можно избежать всех этих проблем. Можно настроить две таблицы: одну для заказов и одну для клиентов. Таблица "Клиенты" будет включать уникальный идентификационный номер для каждого клиента, а также имя, адрес и номер телефона, которые мы уже отслеживали. Таблица "Заказы" будет включать номер заказа, дату, сумму к оплате, номер отслеживания и вместо отдельного поля для каждой позиции данных клиента будет содержать столбец для идентификатора клиента.
Это позволяет нам получить всю информацию о клиенте для любого заказа, но записи будут введены в базу только один раз, избегая при этом избыточных данных.
С чем бы будем работать
Начнем с открытия нашей базу данных. База данных имеет две таблицы, trips ( далее "поездки") и stations (далее "станции"). Давайте просто посмотрим на таблицу trips. Она содержит следующие столбцы:
id - уникальное целое число, которое служит ссылкой на каждую поездку.
duration - продолжительность поездки, измеренная в секундах;
start_date - Дата и время начала поездки;
start_station - целое число, соответствующее столбцу id в таблице stations для станции, на котором был арендован велосипед;
end_date - Дата и время окончания поездки;
end_station - Идентификатор станции, на которой завершилась поездка;
bike_number - уникальный идентификатор Hubway для велосипеда, используемого в поездке;
sub_type - тип подписки пользователя. "Зарегистрированный" для пользователей с членством, "Случайный" для пользователей без членства;
zip_code - почтовый индекс пользователя (доступен только для зарегистрированных участников);
birth_date - год рождения пользователя (доступен только для зарегистрированных участников);
gender - пол пользователя (доступен только для зарегистрированных участников);
Что мы анализируем
Внизу перечислены вопросы, на которые мы должны ответить, используя информацию из БД и командами SQL, которые мы изучим чуть позже:
Какова была продолжительность самого длительного путешествия?
Сколько поездок совершили "зарегистрированные" пользователи?
Какова средняя продолжительность поездки?
Кто совершил более длительные поездки: зарегистрированные пользователи или гости?
Какой велосипед использовался для большинства поездок?
Какова средняя продолжительность поездок пользователей старше 30 лет?
Команды SQL, которые мы будем использовать для ответа на эти вопросы:
SELECT
WHERE
LIMIT
ORDER BY
GROUP BY
AND
OR
MIN
MAX
AVG
SUM
COUNT
Установка и настройка
В данном руководстве мы будем использовать систему баз данных под названием SQLite3. SQLite стала частью Python начиная с версии 2.5, так что, если у вас установлен Python, почти наверняка уже в системе есть и SQLite. Python и библиотеку SQLite3 можно легко установить и настроить с помощью Anaconda, если они еще не установлены.
Использование Python для запуска кода SQL позволяет импортировать результаты в датафрейм Pandas, что существенно облегчит отображение результатов в удобном для чтения формате. Это также означает, что мы сможем выполнить дальнейший анализ и визуализацию данных, которые мы получим из базы данных, хотя это будет выходить за рамки данного учебного пособия.
Если же не хотите использовать или устанавливать Python, SQLite3 можно запустить из командной строки. Просто загрузите "предварительно скомпилированные двоичные файлы" с сайта SQLite3 и используйте следующую команду для открытия базы данных:
~$ sqlite hubway.db SQLite version 3.14.0 2016-07-26 15:17:14 Enter ".help" for usage hints.sqlite>
Отсюда можно просто ввести запрос, который нужно выполнить, и увидеть возвращенные данные, в нашем окне терминала.
Альтернативой использованию терминала является подключение к базе данных SQLite через Python. Это позволит нам использовать Jupyter для отображения результатов наших запросов в аккуратно отформатированной таблице.
Для этого определим функцию, которая принимает наш запрос (сохраненный в виде строки) в качестве входных данных и показывает результат в виде форматированного датафрейма:
import sqlite3
import pandas as pd
db = sqlite3.connect('hubway.db')
def run_query(query):
return pd.read_sql_query(query,db)
SELECT
Первая команда, с которой мы будем работать - SELECT. SELECT будет основой почти каждого запроса, который мы напишем - он сообщает базе данных, какие столбцы мы хотим видеть. Можно указать столбцы по имени (разделенные запятыми) или использовать подстановочный знак * для возврата всех столбцов из таблицы.
В дополнение к столбцам, которые мы хотим получить, мы также должны сообщить базе данных, из какой таблицы их получить. Для этого используется ключевое слово FROM, за которым следует имя таблицы. Например, если требуется просмотреть start_date и bike_number для каждой поездки в таблице trips, можно использовать следующий запрос:
SELECT start_date, bike_number FROM trips;
В этом примере мы начали с команды SELECT, чтобы база данных знала, что она должна найти некоторые данные. Затем мы сказали базе данных, что нас интересуют столбцы start_date и bike_number. Наконец, чтобы сообщить базе, что столбцы, которые мы хотим получить, являются частью таблицы trips мы использовали команду FROM.
Важно знать, что при записи SQL-запросов необходимо заканчивать каждый запрос точкой с запятой (;). На самом деле не каждая база данных SQL требует этого, но такой стиль считается хорошим тоном создания запросов, поэтому лучше всего сформировать эту привычку.
LIMIT
Следующая команда, которую мы должны знать перед началом выполнения запросов к нашей базе данных Hubway, - LIMIT. LIMIT просто сообщает базе данных, сколько строк требуется вернуть.
Запрос SELECT, который мы рассмотрели в предыдущем разделе, возвращает запрашиваемую информацию для каждой строки в таблице trips, но обычно это очень большое количество данных, в которых нет необходимости в данный момент. Если всех записей из БД нужно получить start_date и bike_number только для первых пяти поездок, к запросу следует добавить ключевое слово LIMIT следующим образом:
SELECT start_date, bike_number FROM trips LIMIT 5;
Мы просто добавили команду LIMIT, а затем число, представляющее количество строк, которые мы хотим вернуть. В данном примере мы использовали 5, но вы можете заменить их любым числом, чтобы получить соответствующий объем данных для проекта, над которым вы работаете.
Мы будем много использовать LIMIT в наших запросах к базе данных Hubway в этом учебном пособии - таблица поездок содержит более 1,5 миллионов строк данных, и нам, конечно, не нужно отображать все.
Давайте запустим наш первый запрос в базе данных Hubway. Сначала сохраним наш запрос в переменной типа "строка", а затем используем функцию, определенную ранее, чтобы отправить запрос к базе данных. Взгляните на следующий пример:
query = 'SELECT * FROM trips LIMIT 5;'
run_query(query)
Этот запрос использует * в качестве подстановочного символа вместо указания возвращаемых столбцов. Это означает, что команда SELECT вернула нам каждый столбец из таблицы trips. Мы также использовали функцию LIMIT, чтобы ограничить вывод первыми пятью строками таблицы.
Вы часто столкнетесь с ситуацией, когда программисты в своих запросах ключевые слова будут писать с заглавной буквы. Это негласное соглашение, которому мы будем следовать в этом учебном пособии, хотя это в основном вопрос предпочтения. Просто заглавная буква облегчает чтение кода, но на самом деле она никак не влияет на его функциональность. Если вы предпочитаете писать запросы строчными буквами, они будут выполняться правильно.
В предыдущем примере были возвращены все столбцы из таблицы поездок. Если бы нас интересовали только длительность и дата начала, подстановочный символ можно было бы заменить на названия столбцов следующим образом:
query = 'SELECT duration, start_date FROM trips LIMIT 5'
run_query(query)
ORDER BY
Последняя команда, которую мы должны знать, прежде чем мы сможем ответить на первый из наших вопросов, - ORDER BY. Эта команда позволяет отсортировать базу данных по указанному столбцу.
Чтобы использовать его, просто укажите имя столбца, по которому требуется выполнить сортировку. По умолчанию, ORDER BY сортирует результаты по возрастанию. Если требуется указать порядок сортировки базы данных, можно добавить ключевое слово ASC для сортировки по возрастанию или DESC - по убыванию.
Например, если требуется отсортировать вывод из таблицы поездок от самой короткой по продолжительности до самой длинной, в запрос можно добавить следующую строку:
ORDER BY duration ASC
Вооружившись командами SELECT, LIMIT и ORDER BY мы теперь можем попытаться ответить на наш первый вопрос: какова была продолжительность самой длительной поездки?
Чтобы ответить на этот вопрос, полезно разбить его на разделы и определить, какие команды нам потребуются для каждой части.
Сначала нам нужно извлечь информацию из столбца duration таблицы поездок. Затем, чтобы найти, какая поездка самая длинная, мы можем отсортировать столбец длительности в порядке убывания. Итак, чтобы сформировать запрос, который получит нужную нам информацию, мы можем следовать следующей последовательности:
Использовать SELECT для извлечения столбца duration FROM таблицы trips.
Использовать ORDER BY для сортировки по столбцу duration и ключевое слово DESC для сортировки в порядке убывания.
Использовать LIMIT, чтобы ограничить вывод 1 строкой
Использование этих команд таким образом вернет одну строку с наибольшей длительностью, что даст нам ответ на наш вопрос.
Еще одна деталь, которую следует отметить - по мере увеличения длины запроса, чтобы облегчить чтение кода, лучше разделять запрос на несколько строк. Это, как и в случае с заглавным шрифтом, вопрос личного предпочтения. Это не влияет на выполнение кода (система считывает код от начала до точки с запятой), но может сделать запросы более четкими и простыми для выполнения. В Python можно разделить строку на несколько строк, используя тройные кавычки.
Давайте выполним запрос и выясним, сколько длилась самая длинная поездка.
query = '''
SELECT duration FROM trips
ORDER BY duration DESC
LIMIT 1;
'''
run_query(query)
Теперь мы знаем, что самая длинная поездка длилась 9999 секунд, или чуть более 166 минут. С максимальным значением 9999, однако, мы не знаем, действительно ли это длина самого длинного рейса или база данных была настроена только для разрешения четырехзначного номера.
Если это правда, то более длительные поездки сокращаются базой данных до четырех символов. В результате ожидаемо увидеть много поездок длительностью 9999 секунд. Чтобы убедиться, что все отрабатывает корректно, попробуем выполнить тот же запрос, что и раньше, но изменим LIMIT так, чтобы вернуть 10 наибольших по длительности поездок:
query = '''
SELECT durationFROM trips
ORDER BY duration DESC
LIMIT 10
'''
run_query(query)
Судя по выводу, в базе нет кучи поездок продолжительностью 9999, а это означает, что база ничего не отсекает. Но все еще трудно сказать, является ли это реальной длиной поездки или только максимально допустимое значение.
Hubway взимает дополнительную комиссию за поездки длительностью более 30 минут (кто-то, продержавший велосипед в течение 9999 секунд, должен был бы заплатить дополнительные 25 долларов в виде комиссии), поэтому вполне вероятно, что разработчики решили обойтись 4-мя цифрами для отслеживания большинства поездок.
WHERE
Предыдущие команды отлично подходят для извлечения отсортированной информации для определенных столбцов, но что делать, если существует определенное подмножество данных, которые мы хотим просмотреть? Вот здесь на помощь приходит WHERE. Команда WHERE позволяет использовать логический оператор для указания строк, которые должны быть возвращены. Например, можно использовать следующую команду, чтобы вернуть каждую поездку, выполненную велосипедом с ID B00400:
WHERE bike_number = "B00400"
Наверное, уже заметили, что в этом запросе используем кавычки. Это потому, что bike_number хранится в виде строки. Если столбец содержит числовые типы данных, необходимость в кавычках отпадает.
Давайте напишем запрос, который использует WHERE для возврата каждого столбца в таблице поездок для каждой строки длительностью больше 9990 секунд:
query = '''
SELECT * FROM trips
WHERE duration > 9990;
'''
run_query(query)
Как мы видим, этот запрос вернул 14 различных поездок, каждая продолжительностью 9990 секунд или более. Что-то, что выделяется в этом запросе, что все, кроме одного из результатов имеет sub_type "Случайный". Возможно, это свидетельствует о том, что "Зарегистрированные" пользователи больше осведомлены о дополнительных сборах за длительные поездки. Может быть, Хабуэй мог бы лучше передать свою политику ценообразования случайным пользователям, чтобы помочь им избежать чрезмерных расходов.
Мы уже видим, что даже SQL запрос начального уровня может помочь нам ответить на бизнес-вопросы и найти информацию в наших данных.
Возвращаясь к WHERE, мы также можем объединить несколько логических тестов в нашем предложении WHERE, используя AND или OR. Если, например, в нашем предыдущем запросе мы хотели получить только поездки длительностью более 9990 секунд, которые также имеют sub_type Registered, мы могли бы использовать оператор AND для указания обоих условий.
Вот еще одна личная рекомендация: используйте круглые скобки, чтобы разделить каждый логический блок, как показано в коде ниже. Это не обязательно для работы кода, но круглые скобки упрощают понимание запросов по мере их усложнения.
Давайте сейчас запустим этот запрос. Мы уже знаем, что это должно вернуть только один результат, так что должно быть легко проверить, что мы получили его правильно:
query = '''
SELECT * FROM trips
WHERE (duration >= 9990) AND (sub_type = "Registered")
ORDER BY duration DESC;
'''
run_query(query)
Следующий вопрос, который мы изложили в начале статьи, - "Сколько поездок было совершено "зарегистрированными" пользователями?" Чтобы ответить на него, мы могли бы выполнить тот же запрос, что и выше, и изменить выражение WHERE, чтобы вернуть все строки, где sub_type равно "Registered", а затем подсчитать их.
На самом деле SQL имеет встроенную команду COUNT для такого рода подсчетов, так что напрягать глаза нам не придется.
COUNT позволяет выполнять вычисления в базе данных и избавить нас от проблем с написанием дополнительных сценариев для подсчета результатов. Чтобы использовать его, мы просто включаем COUNT (column_name) вместо (или в дополнение к) столбцов, которые мы хотим выбрать, как указано ниже:
SELECT COUNT(id)
FROM trips
В данном случае не имеет значения, какой столбец мы выбираем для подсчета, потому что каждый столбец должен иметь данные для каждой строки в нашем запросе. Но иногда запрос может иметь отсутствующие (или "нулевые") значения для некоторых строк. Если мы не уверены, содержит ли столбец значения null, мы можем запустить COUNT для столбца id - столбец id никогда не имеет значение null, поэтому мы можем быть уверены, что наш счетчик не пропустит ничего.
Мы также можем использовать COUNT (1) или COUNT (*) для подсчета каждой строки в нашем запросе. Стоит отметить, что иногда может потребоваться выполнение COUNT для столбца со значениями NULL. Например, может потребоваться узнать, сколько строк в нашей базе данных имеют пустые значения для указанного столбца.
Давайте посмотрим на запрос, который позволит ответить на наш вопрос. Мы можем использовать SELECT COUNT (*) для подсчета общего количества возвращенных строк и WHERE sub_type = "Registered", чтобы убедиться, что мы подсчитываем только поездки, сделанные зарегистрированными пользователями.
query = '''
SELECT COUNT(*)FROM trips
WHERE sub_type = "Registered";
'''
run_query(query)
Этот запрос сработал и вернул ответ на наш вопрос. Но заголовок столбца не особенно показателен. Если кто-то еще посмотрит на эту таблицу, он не сможет понять, что это значит. Если мы хотим сделать наши результаты более читаемыми, мы можем использовать ключевое слово AS, чтобы дать нашему выводу псевдоним. Давайте снова запустим предыдущий запрос, но дадим
query = '''
SELECT COUNT(*) AS "Total Trips by Registered Users"
FROM trips
WHERE sub_type = "Registered";
'''
run_query(query)
Функции агрегирования
COUNT не единственный математический трюк, которым располагает SQL. Мы также можем использовать функции SUM, AVG, MIN и MAX для возврата суммы, среднего значения, минимума и максимума столбца соответственно. Эти функции наряду с COUNT называются функциями агрегирования.
Итак, чтобы ответить на наш третий вопрос "Какова была средняя продолжительность поездки?", мы можем использовать функцию AVG для столбца duration (и, еще раз, использовать AS, чтобы дать нашему выходному столбцу более описательное имя):
query = '''
SELECT AVG(duration) AS "Average Duration"
FROM trips;
'''
run_query(query)
Получается, что средняя продолжительность поездки составляет 912 секунд, что составляет около 15 минут. Это имеет смысл, так как мы знаем, что Hubway взимает дополнительную плату за поездки в течение 30 минут. Сервис рассчитан на то, чтобы участники брали велосипеды на короткие дистанции, односторонние поездки.
Как насчет нашего следующего вопроса, какие пользователи выполняют более длительные поездки? Мы уже знаем один способ ответить на этот вопрос - мы могли бы запустить два запроса SELECT AVG (duration) FROM trips добавив ключевое слово WHERE, которые ограничивают вывод для "зарегистрированных" и для "случайных" пользователей по отдельности.
Но давайте сделаем это по-другому. SQL имеет в своем арсенале функцию и для ответа на этот вопрос в одном запросе с помощью команды GROUP BY.
GROUP BY
GROUP BY разделяет строки на группы на основе содержимого определенного столбца и позволяет выполнять агрегирующие функции для каждой группы.
Чтобы лучше понять, как это работает, давайте посмотрим на столбец gender. Каждая строка может иметь одно из трех возможных значений в столбце пола "Мужской", "Женский" или "Нулевой" (отсутствует; у нас нет гендерных данных для случайных пользователей).
Когда мы используем GROUP BY, база данных будет разделять каждую из строк на разные группы на основе значения в столбце пола, примерно так же, как мы можем разделить колоду карт по мастям. Это можно представить, как две группы, в одной все представители мужского пола, в другой - женского.
Как только у нас будут две отдельные кучи, база данных будет выполнять любые агрегирующие функции в нашем запросе по каждой из них по очереди. Например, если бы мы использовали COUNT, запрос подсчитывал бы количество строк в каждой группе и возвращал бы значение для каждого по отдельности.
Давайте посмотрим, как именно написать запрос, чтобы ответить на наш вопрос о том, кто совершает более длительные поездки: зарегистрированные пользователи или случайные.
Как и в случае с каждым из наших запросов, мы начнем с SELECT, чтобы сообщить базе данных, какую информацию мы хотим получить. В этом случае нам нужны sub_type и AVG (duration).
Мы также включим GROUP BY sub_type, чтобы разделить наши данные по типу подписки и вычислить средние значения зарегистрированных и случайных пользователей по отдельности.
Вот как выглядит код, когда мы складываем все вместе:
query = '''
SELECT sub_type, AVG(duration) AS "Average Duration"
FROM trips
GROUP BY sub_type;
'''
run_query(query)
Это большая разница! В среднем зарегистрированные пользователи совершают поездки продолжительностью около 11 минут, в то время как случайные пользователи тратят почти 25 минут на поездку. Зарегистрированные пользователи, вероятно, совершают более короткие и частые поездки, возможно, в рамках поездок на работу. Случайные пользователи, с другой стороны, тратят в два раза больше времени на поездку.
Вполне возможно, что случайные пользователи, как правило, приезжие (например, туристы), которые более склонны совершать более длительные поездки, чтобы убедиться, что они обойдут и увидят все достопримечательности. Как только мы обнаружим эту разницу в данных, компания сможет исследовать ее, чтобы лучше понять, что данная разница вызвана
Однако давайте продолжим. Наш следующий вопрос был: "Какой велосипед использовался для большинства поездок?" Мы можем ответить на это с помощью очень похожего запроса. Взгляните на следующий пример и посмотрите, можете ли вы выяснить, что делает каждая строка - мы пройдем ее шаг за шагом после этого, чтобы вы могли проверить, правильно ли вы получили:
query = '''
SELECT bike_number as "Bike Number", COUNT(*) AS "Number of Trips"
FROM trips
GROUP BY bike_number
ORDER BY COUNT(*) DESC
LIMIT 1;
'''
run_query(query)
Как видно из выходных данных, велосипедные B00490 взяли больше всего поездок. Давайте рассмотрим, как получили данное значение:
Первая строка - это предложение SELECT, указывающее базе данных, что мы хотим получить столбец bike_number и число всех строк в БД. В запросе также используется AS для указания базе данных отображать каждый столбец с более понятным названием.
Во второй строке используем FROM, чтобы указать, что данные, которые мы ищем, находятся в таблице поездок.
В третьей строке прибегли к хитрости. Тут используется команда GROUP BY, чтобы указать функции COUNT в первой строке подсчитать каждое значение для bike_number отдельно.
В четвертой строке у нас есть функция ORDER BY, чтобы отсортировать таблицу в порядке убывания и убедиться, что наш наиболее используемый велосипед находится на самом верху.
Наконец, мы используем LIMIT, чтобы ограничить вывод одной строкой, которая, как мы знаем, будет велосипедом, который использовался в наибольшем количестве поездок из-за того, как мы сортировали данные на четвертой строке.
Арифметические операторы
Наш последний вопрос немного сложнее других. Мы хотим знать среднюю продолжительность поездок зарегистрированных участников в возрасте старше 30 лет.
Мы могли бы просто найти год, в котором родились 30-летние, а затем подставить это значение. Но есть более элегантным решение - использование арифметических операций непосредственно в нашем запросе. SQL позволяет использовать +, -, * и/для выполнения арифметической операции над всем столбцом одновременно.
query = '''
SELECT AVG(duration) FROM trips
WHERE (2017 - birth_date) > 30;
'''
run_query(query)
JOIN
До сих пор мы рассматривали запросы, которые извлекают данные только из таблицы поездок. Однако одна из причин, по которой SQL настолько эффективен, заключается в том, что он позволяет извлекать данные из нескольких таблиц в одном запросе.
Наша база данных по обмену велосипедами содержит вторую таблицу, станции. Таблица stations содержит информацию о каждом терминале в сети Hubway и включает столбец id, на который ссылается таблица trips.
Прежде чем мы начнем работать с некоторыми реальными примерами из этой базы данных, давайте посмотрим на гипотетическую базу данных отслеживания заказов из более ранних. В этой базе данных были две таблицы, заказы и клиенты, и они были связаны столбцом customer_id.
Допустим, мы хотели написать запрос, который вернул order_number и name для каждого заказа в базе данных. Если они оба были сохранены в одной таблице, можно было бы использовать следующий запрос:
SELECT order_number, name
FROM orders;
К сожалению, столбец order_number и столбец name хранятся в двух разных таблицах, поэтому необходимо добавить несколько дополнительных команд. Давайте подумаем о дополнительных командах, которые должна знать база данных, прежде чем она сможет вернуть нужную информацию:
В какой таблице находится столбец order_number?
В какой таблице находится столбец name?
Как информация в таблице заказов связана с информацией в таблице клиентов?
Чтобы ответить на первые два из этих вопросов, мы можем включить имена таблиц для каждого столбца в нашу команду SELECT. Способ сделать это - просто написать имя таблицы и имя столбца, разделив их символом точки ".". Например, вместо SELECT order_number мы бы написали SELECT orders.order_number, customers.name. Добавление здесь имен таблиц помогает базе данных находить столбцы, которые мы ищем, указывая, в какой таблице искать каждый из них.
Чтобы сообщить базе данных, как соединяются таблицы заказов и клиентов, мы используем JOIN и ON. JOIN указывает, какие таблицы должны быть соединены, а ON указывает, какие столбцы в каждой таблице связаны.
Мы будем использовать внутреннее соединение, что означает, что команда вернет только те строки, где столбцы, указанные в ON, совпадают. В этом примере мы хотим использовать JOIN для любой таблицы, которую мы не включили в команду FROM. Таким образом, мы можем либо использовать FROM orders INNER JOIN customers, либо FROM customers INNER JOIN orders.
Как мы уже обсуждали ранее, эти таблицы связаны между собой столбцом customer_id в каждой таблице. Поэтому используем ON, чтобы сообщить базе данных, что эти два столбца ссылаются на одно и то же:
ON orders.customer_ID = customers.customer_id
Еще раз используем "." чтобы база данных знала, в какой таблице находится каждый из этих столбцов. Итак, когда мы сложим все это вместе, мы получим запрос, который выглядит следующим образом:
SELECT orders.order_number, customers.name
FROM orders
INNER JOIN customers
ON orders.customer_id = customers.customer_id
Этот запрос вернет номер каждого заказа в базе данных наряду с именем клиента, который сделал данные заказ.
Возвращаясь к нашей базе данных Hubway, мы теперь можем написать несколько запросов, чтобы увидеть JOIN в действии.
Прежде чем начать, мы должны взглянуть на остальные столбцы в таблице станций. Вот запрос, чтобы показать нам первые 5 строк, чтобы мы могли увидеть, как выглядит таблица станций:
query = '''
SELECT * FROM stations
LIMIT 5;
'''
run_query(query)
id - уникальный идентификатор для каждой станции (соответствует столбцам start_station и end_station в таблице поездок);
station - название станции;
municipality - муниципалитет, в котором находится станция (Бостон, Бруклин, Кембридж или Сомервилл);
lat - Широта станции;
lng - долгота станции;
А вот вопросы, на которые мы должны ответить, исследовав данные из базы:
Какие станции чаще всего используются для поездок в оба конца?
Сколько поездок начинается и заканчивается в разных муниципалитетах?
Как и прежде, мы попытаемся ответить на некоторые вопросы основываясь на данных, первый вопрос: "Какая станция является наиболее частой отправной точкой?" Давайте шаг за шагом сформируем запрос для ответа на этот вопрос:
Сначала мы используем SELECT для возврата столбца station из таблицы станций и COUNT для получения числа строк.
Далее мы указываем таблицы, которые мы хотим объединить JOIN, и указываем базе данных соединить их столбцом ON start_station из таблицы поездок и столбцом id в таблице станций.
Затем переходим к основной части нашего запроса - мы группируем по столбцу станция таблицы станций (GROUP BY station), чтобы наш COUNT подсчитал количество поездок для каждой станции отдельно
Наконец, мы можем отсортировать по нашим COUNT ORDER BY COUNT LIMIT и ограничить вывод для управления количеством результатов.
query = '''
SELECT stations.station AS "Station", COUNT(*) AS "Count"
FROM trips INNER JOIN stations
ON trips.start_station = stations.id
GROUP BY stations.station
ORDER BY COUNT(*) DESC
LIMIT 5;
'''
run_query(query)
Если вы знакомы с Бостоном, вы поймете, почему это самые популярные станции. Южный вокзал является одной из главных пригородных железнодорожных станций в городе, Чарльз-стрит проходит вдоль реки недалеко от некоторых красивых живописных маршрутов, а улицы Бойлстон и Бикон находятся прямо в центре вблизи офисных зданий.
Следующий вопрос, который мы рассмотрим, - какие станции чаще всего используются для поездок туда и обратно? Мы можем использовать тот же запрос, что и раньше. Мы будем выбирать те же выходные столбцы и присоединять таблицы таким же образом, но на этот раз мы добавим условие WHERE, чтобы ограничить наш COUNT поездками, где start_station совпадает с end_station.
query = '''
SELECT stations.station AS "Station", COUNT(*) AS "Count"
FROM trips INNER JOIN stations
ON trips.start_station = stations.id
WHERE trips.start_station = trips.end_station
GROUP BY stations.station
ORDER BY COUNT(*) DESC
LIMIT 5;
'''
run_query(query)
Как мы видим, ряд станций из этого списка аналогичен предыдущему списку, но их количество значительно ниже. Самые загруженные станции те же самые, но более низкие цифры в целом дают возможность предполагать, что люди обычно используют велосипеды Hubway, чтобы добраться от точки A до точки B, а не ездить на велосипеде некоторое время, прежде чем вернуться туда, где они начали.
Здесь есть одно существенное отличие - Эспланд, который не был одной из самых загруженных станций по результатам нашего первого запроса, кажется самым загруженным для поездок туда и обратно. Почему? Что ж, картина стоит тысячи слов. Это, безусловно, выглядит как хорошее место для велопробега:
На следующий вопрос: сколько поездок начинается и заканчивается в разных муниципалитетах? Этот вопрос делает заставляет нас двигаться дальше. Мы хотим знать, сколько поездок начинается и заканчивается в другом муниципалитете. Чтобы достичь этого, нам нужно присоединить таблицу поездок к таблице станций дважды. Один раз по столбцу start_station, а затем по столбцу end_station.
Для этого необходимо создать псевдоним для таблицы станций, чтобы можно было различать данные, относящиеся к start_station, и данные, относящиеся к end_station. Мы можем сделать это точно так же, как присваивали псевдонимы отдельным столбцам, чтобы они отображались с более интуитивным именем, используя AS.
Например, чтобы присоединить таблицу станций к таблице поездок с помощью псевдонима "start", можно использовать следующий код. Затем мы можем объединить "start" с именами столбцов с помощью "." для ссылки на данные, полученные из этого конкретного JOIN (вместо второго JOIN, где мы объединим таблицы по end_station столбец):
INNER JOIN stations AS start ON trips.start_station = start.id
Вот как будет выглядеть последний запрос при его выполнении. Обратите внимание, что мы использовали " " для представления "не равно", но != также будет работать.
query =
'''
SELECT COUNT(trips.id) AS "Count"
FROM trips INNER JOIN stations AS start
ON trips.start_station = start.id
INNER JOIN stations AS end
ON trips.end_station = end.id
WHERE start.municipality end.municipality;
'''
run_query(query)
Это показывает, что около 300 000 из 1,5 миллионов поездок (или 20%) закончились в другом муниципалитете, - еще одно доказательство того, что люди в основном используют велосипеды Hubway для относительно коротких путешествий, а не более длительных поездок между городами.
Если вы зашли так далеко, поздравляю! Вы начали осваивать основы SQL. Мы рассмотрели ряд важных команд, а также агрегирующие и арифметические функции. Они дадут вам прочную основу для развития по мере того, как вы продолжите свой путь в изучении SQL.
Что дальше?
После завершения данного руководства по SQL можно будет выбрать базу данных, которую вы найдете интересной, и написать запросы для извлечения информации из неё. Хорошим первым шагом может быть продолжение работы с базой данных Hubway, чтобы узнать, чего еще интересного можно достать из этой базы. Вот несколько вопросов, на которые вы можете попытаться ответить:
Сколько поездок понесли дополнительные сборы (длились дольше 30 минут)?
Какой велосипед использовался дольше всего?
Какие пользователи, зарегистрированные или случайные, совершали больше поездок в оба конца?
Какой муниципалитет имеет наибольшую среднюю продолжительность?
Linux поддерживает множество файловых систем, таких как ext4, ZFS, XFS, Btrfs, Reiser4 и другие.
Различные типы файловых систем решают разные проблемы, и их использование зависит от приложения.
Что такое файловая система Linux
Почти каждый бит данных и программ, необходимых для загрузки системы Linux и поддержания ее работы, сохраняется в файловой системе. Например, сама операционная система, компиляторы, прикладные программы, разделяемые библиотеки, файлы конфигурации, файлы журналов, точки монтирования мультимедиа и т.д.
Файловые системы работают в фоновом режиме. Как и остальная часть ядра операционной системы, они практически невидимы при повседневном использовании.
Файловая система Linux обычно представляет собой встроенный уровень операционной системы Linux, используемый для управления данными хранилища. Он контролирует, как данные хранятся и извлекаются. Он управляет именем файла, размером файла, датой создания и другой информацией о файле.
Файловая система ext4
В 1992 году была запущена файловая Extended File System или ext специально для операционной системы Linux. Она уходит своими корнями в операционную систему Minix. В 1993 году было выпущено обновление под названием Extended File System 2 или ext2, которое в течение многих лет было файловой системой по умолчанию во многих дистрибутивах Linux. К 2001 году ext2 была обновлена до ext3, которая ввела журналирование для защиты от повреждений в случае сбоев или сбоев питания.
Ext4 была представлена в 2008 году и является файловой системой Linux по умолчанию с 2010 года. Она была разработана как прогрессивная версия файловой системы ext3 и преодолевает ряд ограничений в ext3. Она имеет значительные преимущества перед своим предшественником, такие как улучшенный дизайн, лучшая производительность, надежность и новые функции.
В настоящее время ext4 является файловой системой по умолчанию в большинстве дистрибутивов Linux. Она может поддерживать файлы и файловые системы размером до 16 терабайт. Она также поддерживает неограниченное количество подкаталогов (файловая система ext3 поддерживает только до 32 000). Кроме того, ext4 обратно совместима с ext3 и ext2, что позволяет монтировать эти старые версии с драйвером ext4.
Есть причина, по которой ext4 является выбором по умолчанию для большинства дистрибутивов Linux. Она опробована, протестирована, стабильна, отлично работает и широко поддерживается. Если вам нужна стабильность, ext4 - лучшая файловая система Linux для вас.
Однако несмотря на все свои функции, ext4 не поддерживает прозрачное сжатие, прозрачное шифрование или дедупликацию данных.
Файловая система XFS
XFS - это высокомасштабируемая файловая система, разработанная Silicon Graphics и впервые развернутая в операционной системе IRIX на базе Unix в 1994 году. Это файловая система с журналированием которая отслеживает изменения в журнале перед фиксацией изменений в основной файловой системе. Преимущество заключается в гарантированной целостности файловой системы и ускоренном восстановлении в случае сбоев питания или сбоев системы.
Первоначально XFS была создана для поддержки чрезвычайно больших файловых систем с размерами до 16 эксабайт и размером файлов до 8 эксабайт. Она имеет долгую историю работы на больших серверах и массивах хранения.
Одной из примечательных особенностей XFS является гарантированная скорость ввода-вывода. Это позволяет приложениям зарезервировать пропускную способность. Файловая система рассчитывает доступную производительность и корректирует свою работу в соответствии с существующими резервированиями.
XFS имеет репутацию системы, работающей в средах, требующих высокой производительности и масштабируемости, и поэтому регулярно оценивается как одна из самых производительных файловых систем в больших системах с корпоративными рабочими нагрузками.
Сегодня XFS поддерживается большинством дистрибутивов Linux и теперь стала файловой системой по умолчанию в Red Hat Enterprise Linux, Oracle Linux, CentOS и многих других дистрибутивах.
Лучшие варианты использования файловой системы XFS
У вас большой сервер? У вас большие требования к хранилищу или у вас есть локальный медленный диск SATA?
Если и ваш сервер, и ваше устройство хранения большие и нет необходимости уменьшать размер файловой системы, XFS, вероятно, будет лучшим выбором. XFS - отличная файловая система, которая хорошо масштабируется для больших серверов. Но даже с меньшими массивами хранения XFS работает очень хорошо, когда средние размеры файлов велики, например, размером в сотни мегабайт.
Файловая система btrfs
Btrfs - это файловая система Linux общего назначения нового поколения, которая предлагает уникальные функции, такие как расширенное интегрированное управление устройствами, масштабируемость и надежность. Он распространяется под лицензией GPL и открыт для внесения вклада кем угодно. Для файловой системы используются разные имена, в том числе «Butter FS», «B-tree FS» и «Better FS».
Разработка Btrfs началась в Oracle в 2007 году. Она была объединена с основным ядром Linux в начале 2009 года и дебютировала в версии Linux 2.6.29.
Btrfs не является преемником файловой системы ext4 по умолчанию, используемой в большинстве дистрибутивов Linux, но предлагает лучшую масштабируемость и надежность. Btrfs - это файловая система с копированием при записи (Copy-on-Write - CoW), предназначенная для устранения различных недостатков в текущих файловых системах Linux. Основное внимание уделяется отказоустойчивости, самовосстановлению и простоте администрирования.
Btrfs может поддерживать до 16 эксбибайт раздела и файл того же размера. Если вас смущают цифры, все, что вам нужно знать, это то, что Btrfs может поддерживать до шестнадцати раз больше данных Ext4.
Как работает Copy-on-Write и зачем вам это нужно
В традиционной файловой системе при изменении файла данные считываются, изменяются, а затем записываются обратно в то же место. В файловой системе с копией при записи он считывает данные, изменяет их и записывает в новое место. Это предотвращает потерю данных во время транзакции чтения-изменения-записи, поскольку данные всегда находятся на диске.
Поскольку вы не «перенаправляете» до тех пор, пока новый блок не будет полностью записан, если пропадет питание или выйдет из строя в середине записи, вы получите либо старый блок, либо новый блок, но не наполовину записанный поврежденный блокировать. Таким образом, вам не нужно проверять файловые системы при запуске, и вы снижаете риск повреждения данных.
Вы можете сделать снимок файловой системы в любой момент, создав запись снимка в метаданных с текущим набором указателей. Это защищает старые блоки от последующего сбора мусора и позволяет файловой системе представить том в том виде, в котором он был во время моментального снимка. Другими словами, у вас есть возможность мгновенного отката. Вы даже можете клонировать этот том, чтобы сделать его доступным для записи на основе снимка.
Особенности Btrfs
Copy-on-Write и создание снепшотов - Сделайте инкрементное резервное копирование безболезненным даже из файловой системы в процессе работы или виртуальной машины (VM).
Контрольные суммы на уровне файла - метаданные для каждого файла включают контрольную сумму, которая используется для обнаружения и исправления ошибок.
Сжатие - файлы можно сжимать и распаковывать "на лету", что увеличивает скорость чтения.
Автоматическая дефрагментация - файловые системы настраиваются фоновым потоком, пока они используются.
Подтомы - файловые системы могут совместно использовать единый пул пространства вместо того, чтобы помещаться в свои собственные разделы.
RAID - Btrfs выполняет свои собственные реализации RAID, поэтому LVM или mdadm не требуются для наличия RAID. В настоящее время поддерживаются RAID 0, 1 и 10. RAID 5 и 6 считаются нестабильными.
Разделы необязательны - хотя Btrfs может работать с разделами, он может напрямую использовать необработанные устройства (/dev/<device>).
Дедупликация данных - поддержка дедупликации данных ограничена; однако дедупликация со временем станет стандартной функцией Btrfs. Это позволяет Btrfs экономить место, сравнивая файлы через двоичные файлы diff.
Хотя это правда, что Btrfs все еще считается экспериментальным и в настоящее время находится в активной разработке, время, когда Btrfs станет файловой системой по умолчанию для систем Linux, приближается. Некоторые дистрибутивы Linux уже начали переходить на него в своих текущих выпусках.
Файловая система ZFS
ZFS (Zettabyte File System) остается одной из наиболее технически продвинутых и полнофункциональных файловых систем с момента ее появления в октябре 2005 года. Это локальная файловая система (например, ext4) и менеджер логических томов (например, LVM), созданные Sun Microsystems. ZFS публиковалась под лицензией с открытым исходным кодом, пока Oracle не купила Sun Microsystems и не закрыла лицензию.
Вы можете думать о ZFS как о диспетчере томов и как о RAID-массиве одновременно, что позволяет добавлять дополнительные диски к вашему тому ZFS, что позволяет одновременно добавить дополнительное пространство в вашу файловую систему. В дополнение к этому ZFS обладает некоторыми другими функциями, которых нет в традиционных RAID.
ZFS сильно зависит от памяти, поэтому для запуска вам потребуется не менее 8 ГБ. На практике используйте столько, сколько можете получить в соответствии с вашим аппаратным обеспечением или бюджетом.
ZFS обычно используется сборщиками данных, пользователями NAS и другими гиками, которые предпочитают полагаться на собственную избыточную систему хранения, а не на облако. Это отличная файловая система для управления несколькими дисками с данными, которая может соперничать с некоторыми из лучших конфигураций RAID.
ZFS похожа на другие подходы к управлению хранилищем, но в некотором смысле радикально отличается. ZFS обычно не использует Linux Logical Volume Manager (LVM) или разделы диска, и обычно удобно удалять разделы и структуры LVM перед подготовкой носителя для zpool.
Zpool - это аналог LVM. Zpool охватывает одно или несколько устройств хранения, а члены zpool могут быть нескольких различных типов. Основные элементы хранения - одиночные устройства, зеркала и raidz. Все эти элементы хранения называются vdevs.
ZFS может обеспечить целостность хранилища намного лучше, чем любой RAID-контроллер, поскольку он досконально знает структуру файловой системы. Безопасность данных - важная особенность конструкции ZFS. Все блоки, записанные в zpool, тщательно проверяются контрольной суммой для обеспечения согласованности и правильности данных.
Для использования на сервере, где вы хотите почти полностью исключить любую возможность потери данных и стабильности, вы можете изучить ZFS.
Возможности ZFS
Бесконечная масштабируемость. Что ж, технически она не бесконечна, но это 128-битная файловая система, способная управлять зеттабайтами (одним миллиардом терабайт) данных. Поэтому независимо от того, сколько у вас места на жестком диске, ZFS подойдет для управления им.
Максимальная целостность. Все, что вы делаете внутри ZFS, использует контрольную сумму для обеспечения целостности файла. Вы можете быть уверены, что ваши файлы и их резервные копии не испытают скрытого повреждения данных. Кроме того, пока ZFS незаметно проверяет целостность ваших данных, она будет выполнять автоматическое восстановление в любое время.
Объединение дисков. Создатели ZFS хотят, чтобы вы думали об этом как о том, как ваш компьютер использует оперативную память. Когда вам нужно больше памяти на вашем компьютере, вы вставляете другую карту, и все готово. Точно так же с ZFS, когда вам нужно больше места на жестком диске, вы вставляете другой жесткий диск, и все готово. Не нужно тратить время на разбиение на разделы, форматирование, инициализацию или что-то еще с вашими дисками. Если вам нужен «пул» хранилища большего размера, просто добавьте диски.
RAID. ZFS поддерживает множество различных уровней RAID, обеспечивая при этом производительность, сравнимую с производительностью аппаратных RAID-контроллеров. Это позволяет сэкономить деньги, упростить настройку и получить доступ к превосходным уровням RAID, которые были улучшены в ZFS.
Файловая система Reiser4
ReiserFS - это файловая система общего назначения с журналированием, первоначально разработанная и реализованная командой Namesys во главе с Хансом Райзером. Представленная в версии 2.4.1 ядра Linux, это была первая файловая система с журналированием, включенная в стандартное ядро.
За исключением обновлений безопасности и исправлений критических ошибок, Namesys прекратила разработку ReiserFS. Reiser4 является преемницей файловой системы ReiserFS. Добавилось шифрование, улучшил производительность и многое другое.
Reiser4 обеспечивает наиболее эффективное использование дискового пространства среди всех файловых систем во всех сценариях и рабочих нагрузках. ReiserFS предлагает преимущества перед другими файловыми системами, особенно когда дело доходит до обработки большого количества небольших файлов. Она поддерживает ведение журнала для быстрого восстановления в случае возникновения проблем. Структура файловой системы основана на деревьях. Кроме того, Reiser4 потребляет немного больше ресурсов ЦП, чем другие файловые системы.
Reiser4 обладает уникальной способностью оптимизировать дисковое пространство, занимаемое небольшими файлами (менее одного блока). Они полностью хранятся в своем индексном дескрипторе, без выделения блоков в области данных.
Помимо реализации традиционных функций файловой системы Linux, reiser4 предоставляет пользователям ряд дополнительных возможностей: прозрачное сжатие и шифрование файлов, полное ведение журнала данных, а также практически неограниченную (с помощью архитектуры подключаемых модулей) расширяемость.
Однако в настоящее время нет поддержки прямого ввода-вывода (началась работа по реализации), квот и POSIX ACL.
Будьте осторожны с тем, какие ссылки вы открываете и по каким сайтам переходите - это может быть мошенничество!
Фишинг - это мошенническая деятельность, направленная на выманивание вашей личной информации, такой как номера кредитных карт, пароли и другие важные данные. Это также можно описать как кражу личных данных или как разновидность социальной инженерии.
Мошеннические схемы часто опираются на строки в электронных письмах, веб-сайтах или в чате, которые, исходят от службы такой, как ваш банк, поставщик платежных карт или ваша социальная сеть. Цель социальной инженерии обычно состоит в том, чтобы незаметно установить шпионское ПО или обмануть вас, раскрыв ваши пароли или другую личную информацию.
Никогда не отвечайте на запросы об обновлении информации вашей учетной записи, если вы сами их не запрашивали. Такие сообщения могут быть попытками мошенничества, направленного на кражу вашей личности. Большинство уважаемых компаний никогда не отправляют незапрашиваемые сообщения с запросом вашего пароля или другой личной информации. И помните, если что-то звучит слишком хорошо, чтобы быть правдой, это, вероятно, не так.
Как вы можете защитить себя от мошеннической информации? Последующие советы могут помочь избежать мошенничества в интернете:
Держите брандмауэр включенным.
Всегда поддерживайте свое программное обеспечение и операционную систему в актуальном состоянии.
Всегда держите свой антивирус в актуальном состоянии.
Уделите достаточно внимания ссылкам на сайт! Поскольку многие мошенники в интернете полагаются на то, что пользователь нажимает на ссылку, это очень хороший способ защитить себя, просто обращая внимание на то, что вы нажимаете в электронной почте, в чате или на веб-сайтах. Если вы получили письмо, которое вы не ожидали, и оно содержит ссылку, и вы хотите ее открыть, напишите ссылку непосредственно в свой веб-браузер. Если веб-ссылка приходит с сайта, который вы часто посещаете, используйте свои интернет-закладки для доступа к сайту.
Удалить спам! Не открывайте его и не отвечайте на него, даже если вы хотите, чтобы вас удалили из списка рассылки. Когда вы отвечаете, вы подтверждаете отправителю, что ваша учетная запись активна.
Будьте осторожны при предоставлении ваших личных или финансовых данных в интернете. Не заполняйте формы в электронных письмах, которые запрашивают у вас личную или финансовую информацию.
Используйте надежные пароли и избегайте использования одних и тех же паролей для разных интернет-банков и других важных учетных записей.
Регулярно проверяйте свои банковские выписки и немедленно сообщайте о платежах, на которые вы не дали своего согласия.
Ни при каких обстоятельствах не оплачивайте счета или не выполняйте другие финансовые операции на общедоступном компьютере, если вы находитесь в открытой общедоступной беспроводной сети. Если вам все-таки нужно войти на общедоступном компьютере, отдайте предпочтение тому, который требует пароля, это повышает безопасность.