Например, так вышло, что там, где работал/работаю я, аналитики данных и даже веб-аналитики никогда не ставили цели в Яндекс Метрике, эта задача была в зоне ответственности продакт-менеджеров. И совершенно ничего страшного нет в том, что я это не умею. А еще я не работал в Apache Spark, никогда не видел интерфейс Qlick BI и, о господи, плохо разбираюсь, как работает Slack. Главное, что я уверен, что при необходимости освою все инструменты/методики/формулы, которые необходимы для решения конкретной задачи в отдельно взятой компании.
Навык быть честным с собой и окружающими и признавать свои слабые стороны будет полезен как опытным аналитикам, так и начинающим: куда правильнее на собеседовании открыто рассказать о своих умениях и опыте, чем придумывать себе навыки и подстраиваться под требования работодателя. Да, возможно, потребуется больше собеседований, возможно, понадобится изучить какую-то тему/инструмент самостоятельно или с помощью курсов, но с точки зрения подхода - так определенно правильнее.
Навык быть честным с собой и окружающими и признавать свои слабые стороны будет полезен как опытным аналитикам, так и начинающим: куда правильнее на собеседовании открыто рассказать о своих умениях и опыте, чем придумывать себе навыки и подстраиваться под требования работодателя. Да, возможно, потребуется больше собеседований, возможно, понадобится изучить какую-то тему/инструмент самостоятельно или с помощью курсов, но с точки зрения подхода - так определенно правильнее.
Разбор задачи SQL №3
#SQL_trainer2
Напомню, что в одной из предыдущих статей я начал разбирать задачи из этого онлайн-тренажера. Тренажер содержит 66 задач, но разбирать их по-порядку я не буду, какие-то буду определенно пропускать. Так, Задача №1 и Задача №2 не отличаются ничем, кроме таблицы, к которой происходит запрос. Поэтому сразу перепрыгиваем на третье упражнение.
Сегодня разберем задачу №3. Вывести все рейсы, совершенные из Москвы.
#SQL_trainer2
Напомню, что в одной из предыдущих статей я начал разбирать задачи из этого онлайн-тренажера. Тренажер содержит 66 задач, но разбирать их по-порядку я не буду, какие-то буду определенно пропускать. Так, Задача №1 и Задача №2 не отличаются ничем, кроме таблицы, к которой происходит запрос. Поэтому сразу перепрыгиваем на третье упражнение.
Сегодня разберем задачу №3. Вывести все рейсы, совершенные из Москвы.
Где искать рейсы? Думаю, в таблице Trip. Рядом с постановкой задачи в тренажере есть подсказка "Поля в результирующей таблице: *". Значок * означает "все поля". Давайте рассмотрим структуру самого простого SQL- запроса (вывести набор полей из таблицы с условиями) :
SELECT
поле1,
...
полеN
[если нужны все поля, то перечисление заменяется значком *]
FROM table
WHERE
условие1 AND/OR
...
условиеN
поле1,
...
полеN
[если нужны все поля, то перечисление заменяется значком *]
FROM table
WHERE
условие1 AND/OR
...
условиеN
По условию задачи необходимо вывести все рейсы из Москвы. Очевидно, пункт отправления лежит в таблице Trip в поле town_from. Но как нам узнать, как в этой таблице обозначается Москва? Может, "moscow", может, "MOS" или "msc"? Один из способов - написать простой запрос к таблице Trip и найти там Москву:
SELECT * FROM Trip LIMIT 10
В этом случае LIMIT 10 в конце ограничит выдачу 10-ю записями, что сильно ускорит выполнение подобного запроса к большим таблицам.
Видим, что Москва в поле town_from имеет значение "Moscow"
SELECT * FROM Trip LIMIT 10
В этом случае LIMIT 10 в конце ограничит выдачу 10-ю записями, что сильно ускорит выполнение подобного запроса к большим таблицам.
Видим, что Москва в поле town_from имеет значение "Moscow"
Полдела сделано, осталось написать запрос, чтобы Вывести все рейсы, совершенные из Москвы.
SELECT *
FROM Trip
WHERE
town_from = 'Moscow'
SELECT *
FROM Trip
WHERE
town_from = 'Moscow'
Разбор задачи SQL №4
#SQL_trainer3
Продолжаем цикл статей, обозначенный хештэгом #SQL_trainer, с разбором задач из онлайн-тренажера. На очереди четвертая задача, в рамках которой познакомимся с оператором LIKE.
#SQL_trainer3
Продолжаем цикл статей, обозначенный хештэгом #SQL_trainer, с разбором задач из онлайн-тренажера. На очереди четвертая задача, в рамках которой познакомимся с оператором LIKE.
LIKE позволяет искать данные в таблице по вхождению подстроки в строку. Допустим, в таблице Passenger есть значение "Ivan Ivanov", которое мы пытаемся найти. Как его найти?
Если мы точно знаем, что ищем, все просто: SELECT * FROM Passenger WHERE name = 'Ivan Ivanov'
Если мы помним только начало, то нам поможет LIKE: SELECT * FROM Passenger WHERE name LIKE 'Iva%'
Если помним только конец: SELECT * FROM Passenger WHERE name LIKE '%vanov'
Помним серединку - не беда: SELECT * FROM Passenger WHERE name LIKE '%van Ivan%'
Вот блин! Забыли одну букву - то ли "Ivan Ivanov", то ли "Lvan Ivanov", LIKE и тут выручит: SELECT * FROM Passenger WHERE name LIKE '_van Ivanov'
Ну в общем, понятно, значок процента заменяет любое кол-во символов, нижнее подчеркивание (одно или несколько) - заменяет соответственно один или несколько неизвестных символов.
Если мы точно знаем, что ищем, все просто: SELECT * FROM Passenger WHERE name = 'Ivan Ivanov'
Если мы помним только начало, то нам поможет LIKE: SELECT * FROM Passenger WHERE name LIKE 'Iva%'
Если помним только конец: SELECT * FROM Passenger WHERE name LIKE '%vanov'
Помним серединку - не беда: SELECT * FROM Passenger WHERE name LIKE '%van Ivan%'
Вот блин! Забыли одну букву - то ли "Ivan Ivanov", то ли "Lvan Ivanov", LIKE и тут выручит: SELECT * FROM Passenger WHERE name LIKE '_van Ivanov'
Ну в общем, понятно, значок процента заменяет любое кол-во символов, нижнее подчеркивание (одно или несколько) - заменяет соответственно один или несколько неизвестных символов.
Задача - Вывести имена людей, которые заканчиваются на "man". Никаких сложностей не видно: SELECT name FROM Passenger WHERE name LIKE '%man'
Разбор задачи SQL №5
#SQL_trainer4
Продолжаем цикл статей с разбором задач из онлайн-тренажера. На очереди пятая задача.
В SQL, помимо прочего, работают многие операторы, знакомые каждому школьнику с уроков информатики - SUM, COUNT, AVG, MIN/MAX, ROUND, ABS и прочие.
В пятой задаче нам как раз потребуется оператор COUNT для того, чтобы вывести количество рейсов, совершенных на TU-134.
#SQL_trainer4
Продолжаем цикл статей с разбором задач из онлайн-тренажера. На очереди пятая задача.
В SQL, помимо прочего, работают многие операторы, знакомые каждому школьнику с уроков информатики - SUM, COUNT, AVG, MIN/MAX, ROUND, ABS и прочие.
В пятой задаче нам как раз потребуется оператор COUNT для того, чтобы вывести количество рейсов, совершенных на TU-134.
Для начала, как и в предыдущей задаче, найдем обозначение TU-134 в таблице Trip с помощью запроса SELECT * FROM Trip LIMIT 10.
Никаких сюрпризов. Нужный нам самолет обозначен банально 'TU-134'. Нужно обратить внимание, что в задаче просят, чтобы результирующее поле носило имя count, что достигается использованием конструкции AS в блоке SELECT. Поэтому результирующий запрос будет таким:
Никаких сюрпризов. Нужный нам самолет обозначен банально 'TU-134'. Нужно обратить внимание, что в задаче просят, чтобы результирующее поле носило имя count, что достигается использованием конструкции AS в блоке SELECT. Поэтому результирующий запрос будет таким:
Что еще важно отметить. COUNT(*) посчитает все строки в таблице с учетом заданных условий. При использовании простых запросов к одной таблице без JOIN-ов COUNT(*) можно использовать, не задумываясь. Но если запрос сложный, происходит объединение и работа с несколькими таблицами, есть риск получить задвоенные/затроенные/заNенные цифры в ответе. Почему это может происходить коснемся в задаче, где появится первый JOIN.
Поэтому для надежности вычислений COUNT(*) можно заменить на COUNT(DISTINCT уникальный ключ), немного преобразовав запрос:
Поэтому для надежности вычислений COUNT(*) можно заменить на COUNT(DISTINCT уникальный ключ), немного преобразовав запрос:
#дайджест
В последнее время все посты выходили по теме разбора простеньких задач из тренажера SQL (уже скоро начнутся задачи поинтереснее), поэтому предыдущие посты немного затерялись, возможно, часть аудитории о них и не знает )
Поэтому небольшой дайджест тем, которые уже успели выйти на канале:
1. Что должен уметь аналитик данных?
2. О курсах и самообразовании
3. Как начать работать в Питоне тем, кто никогда с ним не сталкивался?
4. Какие бывают аналитики? Классификация
5. Зарплатные вилки аналитиков
6. Ключевой навык аналитика (и не только)
7. О джойнах и INNER/LEFT JOIN в частности
8. Краткий обзор плюсов и минусов PowerBI и Tableau
9. Про АБ-тесты
В последнее время все посты выходили по теме разбора простеньких задач из тренажера SQL (уже скоро начнутся задачи поинтереснее), поэтому предыдущие посты немного затерялись, возможно, часть аудитории о них и не знает )
Поэтому небольшой дайджест тем, которые уже успели выйти на канале:
1. Что должен уметь аналитик данных?
2. О курсах и самообразовании
3. Как начать работать в Питоне тем, кто никогда с ним не сталкивался?
4. Какие бывают аналитики? Классификация
5. Зарплатные вилки аналитиков
6. Ключевой навык аналитика (и не только)
7. О джойнах и INNER/LEFT JOIN в частности
8. Краткий обзор плюсов и минусов PowerBI и Tableau
9. Про АБ-тесты
Что надо помнить, изучая подобное Эйлеровское представление оператора JOIN?
1. Во-первых, учить все виды JOIN-ов, может, необходимо для экзамена в университете, но для решения реальных задач не нужно. 95% задач на практике решается с использованием INNER JOIN и LEFT JOIN, и уж поверьте, намного лучше досконально разобраться для начала только в этих типах соединений, чем по верхам изучить все, в т.ч. CROSS JOIN (в схеме не упомянут) или тот же FULL OUTER JOIN, а запросы писать попеременно с использованием то LEFT, то RIGHT JOIN-ов. Я, например, когда вижу запросы с RIGHT JOIN-ами, чувствую умственное напряжение сродни тому, которое испытываешь перед пешеходным переходом в Британии или на Кипре: 2-3 секунды уходит на то, чтобы переформатировать свой мозг под необычное движение не в ту сторону )
2. Во-вторых, надо помнить степень абстракции, с которой кружочки отражают действительность при объединении таблиц. Ошибки при работе кроются в дублировании данных при JOIN-ах, про которое некоторые забывают
1. Во-первых, учить все виды JOIN-ов, может, необходимо для экзамена в университете, но для решения реальных задач не нужно. 95% задач на практике решается с использованием INNER JOIN и LEFT JOIN, и уж поверьте, намного лучше досконально разобраться для начала только в этих типах соединений, чем по верхам изучить все, в т.ч. CROSS JOIN (в схеме не упомянут) или тот же FULL OUTER JOIN, а запросы писать попеременно с использованием то LEFT, то RIGHT JOIN-ов. Я, например, когда вижу запросы с RIGHT JOIN-ами, чувствую умственное напряжение сродни тому, которое испытываешь перед пешеходным переходом в Британии или на Кипре: 2-3 секунды уходит на то, чтобы переформатировать свой мозг под необычное движение не в ту сторону )
2. Во-вторых, надо помнить степень абстракции, с которой кружочки отражают действительность при объединении таблиц. Ошибки при работе кроются в дублировании данных при JOIN-ах, про которое некоторые забывают
Пусть есть табличка с книгами и их скачиваниями (books) и табличка с авторами этих книг (authors). На что стоит обратить внимание:
1. В таблице books есть книга "Сказки народов мира", у которой нет соответствия в таблице authors
2. У книги "Чудо-пилюли" из таблицы books есть 2 соответствия в таблице authors.
Результат JOIN-а нескольких таблиц - это таблица. И для избежания ошибок в запросах необходимо научиться мысленно визуализировать эту таблицу и понимать ее состав полей и особенности.
Держим в голове 2 пункта выше. Так как использован INNER JOIN, в результирующей таблице будут только те строки, которые есть в обеих таблицах, к которым написан запрос. Соответственно, книги "Сказки народов мира" в результате не будет. А книга "Чудо-пилюли" займет в результате 2 строки, т.к. соответствие в исходных таблицах для этой книги один-к-двум.
1. В таблице books есть книга "Сказки народов мира", у которой нет соответствия в таблице authors
2. У книги "Чудо-пилюли" из таблицы books есть 2 соответствия в таблице authors.
Результат JOIN-а нескольких таблиц - это таблица. И для избежания ошибок в запросах необходимо научиться мысленно визуализировать эту таблицу и понимать ее состав полей и особенности.
Держим в голове 2 пункта выше. Так как использован INNER JOIN, в результирующей таблице будут только те строки, которые есть в обеих таблицах, к которым написан запрос. Соответственно, книги "Сказки народов мира" в результате не будет. А книга "Чудо-пилюли" займет в результате 2 строки, т.к. соответствие в исходных таблицах для этой книги один-к-двум.