По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
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 минут)?
Какой велосипед использовался дольше всего?
Какие пользователи, зарегистрированные или случайные, совершали больше поездок в оба конца?
Какой муниципалитет имеет наибольшую среднюю продолжительность?
В продолжение нашей статьи про настройку Netflow на маршрутизаторах Mikrotik, сегодня мы расскажем про Ntopng — приложение, которое анализирует трафик в вашей сети. Устанавливать будем на CentOS 7.
Установка
Ntopng не доступен в дефолтных репозиториях CentOS 7, поэтому предварительно нам нужно будет выполнить определенные действия по их добавлению. Сперва, выполните команду по добавлению EPEL репозитория:
sudo yum install epel-release
Затем необходимо создать ntop репозиторий. Для этого нужно будет создать файл ntop.repo внутри директории /etc/yum.repos.d - для этого введите команду sudo nano /etc/yum.repos.d/ntop.repo.
В данный файл добавьте следующие строки:
[ntop]
name=ntop packages
baseurl=http://www.nmon.net/centos-stable/$releasever/$basearch/
enabled=1
gpgcheck=1
gpgkey=http://www.nmon.net/centos-stable/RPM-GPG-KEY-deri
[ntop-noarch]
name=ntop packages
baseurl=http://www.nmon.net/centos-stable/$releasever/noarch/
enabled=1
gpgcheck=1
gpgkey=http://www.nmon.net/centos-stable/RPM-GPG-KEY-deri
Для создания файла, конечно же, можно использовать любой текстовый редактор — не только nano. Но если хотите дотошно следовать инструкции, то, вероятно, сначала текстовый редактор придется установить с помощью команды yum install nano -y. После добавления нужных строк в файл сохраните изменения с помощью сочетания клавиш CTRL+O, и выйдите из файла командой CTRL+X.
Теперь переходим к непосредственно установке — выполните команду
sudo yum --enablerepo=epel install redis ntopng -y
. После этого просто соглашайтесь со всеми пунктами, и, спустя минут 5, все должно быть установлено.
Запуск сервисов и настройка ntopng
После установки ntopng, необходимо установить hiredis-devel пакет и запустить redis сервер до старта ntopng:
sudo yum --enablerepo=epel install hiredis-devel
Затем запускаем redis сервис и разрешаем ему автозапуск — и тоже самое делаем с ntopng.
sudo systemctl start redis.service
sudo systemctl enable redis.service
sudo systemctl start ntopng.service
sudo systemctl enable ntopng.service
Далее, проверим, работает ли ntopng командой sudo systemctl status ntopng.
Затем, превратим наш ntopng в бесплатную версию — для этого нужно отредактировать конфиг командой sudo nano /etc/ntopng/ntopng.conf и изменить строку:
-G=/var/tmp/ntopng.pid
на строку:
-G=/var/tmp/ntopng.pid
--community
После чего, сохраним и выйдем из файла и перезапустим ntopng:
sudo systemctl restart ntopng
Последний шаг — настроим фаерволл и перезагрузим его. Настройка заключается в разрешении порта 3000.
sudo firewall-cmd --permanent --add-port=3000/tcp
sudo firewall-cmd --reload
Первый запуск ntopng
Теперь осталось перейти по следующему адресу: http://yourhostip:3000. Логин и пароль по умолчанию — admin. Сразу после этого вам предложат изменить пароль.
Далее, вы увидите дэшборд, с разнообразной информацией, примерно как на скриншоте ниже:
Для понимания возможностей данного приложения — попробуйте посмотреть хосты, сети и прочие — в общем, попробуйте освоиться с функционалом.
Заключение
Всем спасибо за внимание, многие крупные вендоры сейчас уделяют особое внимание протоколу Netflow и придумывают различные сценарии применения. Как это может быть полезно именно для вас, пара примеров: после недельного анализа вашей сети вы поймете, что она была недостаточно сегментирована, или увидите какие-то подозрительные потоки. Дайте нам знать, если вам интересна более подробная настройка ntopng и софта, подобного ему — обязательно напишем про это статью! :).
Год назад компания OpenAI выпустила свой блокбастер — чат-бота ChatGPT. Сотни миллионов людей экспериментировали с этим инструментом, и мы видим, что он уже поменял представление о том, как будет выглядеть и восприниматься интернет для пользователей.
Сейчас ChatGPT больше не единственный инструмент для диалогового ИИ. У него есть серьезная конкуренция со стороны нескольких инструментов, например, Claude. Среди его отличий от ChatGPT — поддержка API, то есть бот можно встроить в экосистему бизнеса. Claude AI, разработанный исследователями из Anthropic, представляет собой альтернативу ChatGPT, которая генерирует текстовые ответы на диалог.
В этой статье мы рассмотрим некоторые интересные возможности ChatGPT и покажем, какую пользу он может принести вам, вашей работе и бизнесу.
Что умеет ChatGPT?
Обратите внимание на то, что ИИ не обладает собственными знаниями — его работа основана на анализе большого объема текстовых данных. Бот же старается предоставить информацию и помощь на основе этого обучения, например:
ответы на вопросы: вы можете спрашивать его о фактах, концепциях, истории и т.д.
Составление текста: он поможет написать статьи, эссе, письма, посты.
Обучение: если у вас есть вопросы, связанные с изучением новых тем, он найдет и предоставит вам нужную информацию.
Перевод: ИИ поможет с переводом текста с одного языка на другой.
Генерация идей: если вам нужны идеи для проекта, исследования или творчества, он предложит варианты.
Просто поговорить: вы можете пообщаться с чат-ботом на любые темы.
Написание кода: ИИ поможет с вопросами по программированию, предоставит фрагменты кода или объяснения алгоритмов.
В целом, AI-боты умеют много чего интересного: от поиска идей для украшений, планирования вечеринок, и до более полезных преимуществ, таких как помощь в программировании. Что может сделать нейросеть действительно хорошим помощником? Вы, а точнее, хорошие промты. Они несколько отличаются от привычных нам запросов для поисковых систем: давайте разберемся, как они выглядят.
Как правильно написать промт для чат-бота? Лайфхаки для ChatGPT
Промты играют решающую роль в том, какой результат вы получите от языковой модели. Промты — это то, что направляет ИИ в генерации ответа для пользователя. Давайте разберемся пошагово в том, что важно для написания хорошего запроса для языковой модели.
1. Определите контекст разговора
Чтобы успешно задействовать чат-бота, ваш запрос должен четко отражать контекст текущей ситуации. Например, почувствуйте разницу между запросами: «Напиши письмо с благодарностью для моего преподавателя» и «Напиши письмо от моего имени на 1000 символов о том, как мне понравилось учиться у моего преподавателя, как я усвоил основы программирования и нашел интересную работу благодаря ему».
2. Будьте максимально конкретны
Стремитесь писать свой запрос максимально четко и конкретно. Расплывчатые или двусмысленные обращения могут привести к тому, что бот начнет «изобретать велосипед» или просто выдаст результат, который не соответствует вашим ожиданиям.
3. Пишите запросы по очереди
Если вы используете ИИ-бот для выполнения какой-либо задачи, например, написания фрагмента текста или исследования темы, вы можете вписывать свои запросы по очереди. Таким образом, вместо того, чтобы запрашивать все сразу, вы можете создать диалог, основанный на предыдущем ответе бота. Таким образом вы сможете вести разговор до тех пор, пока не достигнете желаемого результата.
4. Используйте персонализацию
Пользовательский контекст сделает выдачу бота более актуальной. Вписывайте в свой запрос имена, которые должны фигурировать в ответе, местоположение, время или что-то еще, что имеет отношение к контексту.
5. Приводите примеры
Главная фишка любой нейросети — в ее способности к обучению, не зря существует такая должность, как промт-инженер. Добавляйте примеры в начало диалога, чтобы машина строила свои ответы на основе того, что вам нужно — это поможет ей более четко понять ваши ожидания.
Создание промтов для чат-бота GPT — это процесс, требующий нескольких итераций.
Советуем экспериментировать с различными формулировками, чтобы понять, что лучше всего подходит для ваших целей. Проверяйте свои запросы по ходу дела и наблюдайте, как на них реагирует чат-бот.
Затем вы можете проанализировать полученный результат и соответствующим образом уточнить подсказки. Чем чаще вы повторяете этот процесс, тем лучшего результата достигнет ваш чат-бот и тем лучше вы научитесь писать эффективные запросы.
Лайфхаки для написания эффективного промта
Вы можете потренироваться в написании хороших промтов самостоятельно, а можете изучить зарубежные источники: например, ресурс Great Prompts с исчерпывающей информацией о запросах для ИИ. Вот несколько примеров фраз, которые можно использовать для генерации промта в различных контекстах.
Для написания кода:
«напиши программу, которая...»,
«создай код для решения задачи...»,
«пример кода на [язык программирования] для...».
Для получения текстового описания:
«расскажи о принципах работы...»,
«сформулируй ответ на вопрос...»,
«опиши процесс...».
Для конкретизации запроса:
«дай подробное объяснение по теме...»,
«как работает...?»,
«поясни, что такое...».
Для тренировки навыков:
«подскажи примеры использования...»,
«какие существуют методы для...»,
«помоги мне разобраться в...».
Для генерации идей:
«предложи варианты для...»,
«какие идеи есть по теме...»,
«как можно улучшить/изменить...».
Для формирования мнения:
«как ты относишься к...»,
«какие преимущества и недостатки...»,
«сравни... и ... и дай свой вывод».
Чем более конкретный и четкий запрос вы дали, тем вероятнее, что модель предоставит вам нужную информацию. Экспериментируйте с разными формулировками, чтобы найти лучший способ взаимодействия с ботом.
Как использовать ИИ в программировании?
Если вы хотите повысить эффективность написания кода, ChatGPT может оказаться именно тем инструментом, который вам нужен. Вот почему:
скорость и эффективность: ChatGPT может быстро генерировать фрагменты кода, сокращая время и усилия, которые тратятся на ручное программирование.
Помощь в сложных задачах: он поможет в решении сложных задач по программированию — а вы можете сосредоточиться на стратегических задачах вашего проекта.
Снижение количества багов: ChatGPT дает дополнительный код-ревью, а это значит, он может свести к минимуму ошибки в вашем коде.
ChatGPT был обучен на огромном объеме данных, которые включали в себя и код из множества языков программирования. В результате он может помочь в программировании на различных языках:
Python,
JavaScript,
Java,
C++,
C#,
Ruby,
Swift ,
R.
Это всего лишь примеры — ChatGPT может обрабатывать запросы, включающие и другие языки программирования.
Как языковая модель поможет вам писать код
Прежде, чем мы разберемся, как ИИ поможет вам с написанием кода, определитесь, что должна делать ваша программа в конечном результате? Представьте, что вы платите за работу программисту, которого видите впервые. Даете ли вы этому человеку достаточно информации, чтобы он мог работать над вашим заданием? Или же ваши формулировки слишком расплывчаты, и человек, которого вы наняли, с большей вероятностью начнет задавать уточняющие вопросы или выдавать результат, который вас не устраивает?
Итак, если вы представили перед собой талантливого программиста, работающего только по четкому ТЗ, переходим к тому, с чем вы можете к нему обратиться:
Помощь с синтаксисом: если у вас возникли вопросы по синтаксису определенного языка программирования, вы можете получить полезную информацию.
Генерация кода: опишите задачу или конкретную проблему, с которой вы сталкиваетесь. Бот предложит фрагменты кода или примеры, которые могут помогут вам в решении.
Объяснение алгоритмов: бот предоставит объяснения и примеры, если у вас есть вопросы по поводу определенного алгоритма или концепции программирования.
Тестирование кода: если у вас есть кусок кода, который вы хотели бы протестировать, вы можете поделиться им чат-ботом, и он поможет выявить возможные ошибки или предложить улучшения.
С чем ИИ не работает или работает неправильно?
Разумеется, любой искусственный интеллект — это не панацея и точно не тот инструмент, который сделает все за вас. Вот несколько слабых сторон ИИ, о которых стоит помнить:
Отсутствие понимания контекста. ИИ, в том числе и модели на основе GPT-3.5, не всегда способен понимать контекст в том же смысле, в каком его понимает человек. Модели могут давать ответы, которые кажутся логичными, но они основываются на шаблонах и не всегда отражают объективную реальность.
Отсутствие эмоционального интеллекта. Разумеется, ИИ не способен распознавать и понимать эмоции человека так, как это делают люди. В общении с ИИ может отсутствовать эмоциональная составляющая и понимание контекста, связанного именно с эмоциями.
Неопределенность и недостаток критического мышления. ИИ может давать ответы даже на те вопросы, на которые нет однозначного ответа. Бот полагается на данные, на которых он обучен. Если эти данные предвзяты, неполны или ошибочны, то и результаты работы ИИ могут быть ложными.
Беспристрастность и бездушность. ИИ лишен собственных убеждений и чувств. Это означает, что он может предоставлять информацию или выполнять задачи без учета моральных, этических или социальных аспектов.
«С эмпатией все понятно, а могу ли я доверять коду, который пишет ИИ?», — спросите вы первым делом. Скорее нет, чем да. Но вы также не можете быть уверенными в коде, который пишут программисты-люди. Прежде чем брать конечный результат в работу, вам нужно провести серию тестов.
Правда ли, что ИИ может заменить человека в работе?
Первый вопрос, который задает каждый, кто познакомился с возможностями нейросетей — «заменит ли искусственный интеллект человека?»
Боты на основе ИИ не заменят сотрудника с его аналитическими данными, эмпатией и пониманием отдельных деталей его професси. Но нейросеть точно подойдет для продуктивного сотрудничества и улучшения перфоманса! Автоматизация рутинной работы может освободить вам время для творческих и стратегических задач.
Поэтому вакансии становятся более технологически ориентированными, требуя от сотрудников навыков в области взаимодействия с ИИ. Растет спрос на специалистов, способных обслуживать, программировать и развивать технологии искусственного интеллекта. Важно осознавать, что ИИ ограничен своим программным кодом и данными, на которых он обучен. Так что в областях, требующих творческого мышления, софт-скиллов и этических решений, человек остается попросту незаменимым.