Зачем системному аналитику sql

Проектирование БД и почему важен SQL для системного аналитика: гайд по улучшению качества требований

Берём в работу новую задачу или проект. Начинаем со сбора бизнес-требований. Затем переходим к проработке функциональных и нефункциональных требований. Потом архитектура системы и влияние требований на нее, БД, API, интеграции. И вот, в процессе разработки выясняется, что в требованиях опять что-то не учли. Что может быть хуже?

Может, коллеги! Когда через пол года вам же приходится возвращаться к задаче и вы понимаете, что требования к развитию системы по словам разработчиков нереализуемы. Или реализуемы, но они кривят лица: мы этого не ожидали, проще всё с нуля переделать, либо «костылями подопрем».

Меня, как начинающего системного аналитика, это выводило из себя. Как так?! Элементарная же задача! А потом мне показывают БД. И тут я всё понимаю. Да, действительно, пришло время делать выбор: дорого переделывать или «костыли» подойдут.

Один раз столкнувшись с такой ситуацией, больше не хочется оставлять без внимания базу данных. Даже если проектирование БД в компании находится в зоне ответственности разработчиков.

В этой статье:

1. Как в разработке систем возникают ситуации «костыли» или «переделываем», и почему обычно это связано с непродуманной структурой БД.
2. Как проектирование БД на ранних стадиях работы с проектом влияет на качество требований.
3. Дам пошаговый план проектирования БД.
4. SQL-запросы: почему нужно уметь читать.

«Костылями» подпираем или переделываем?

Главное отличие системного аналитика от других участников проекта заключается в его способности смотреть широко. Работая над конкретной задачей, аналитик видит не только её, но и весь проект в целом, как он функционирует сейчас и как будет развиваться в будущем.

1. Рассмотрим ситуацию с хранением ФИО в системе.

Изначально было решено хранить ФИО одной строкой.

Прошло время. Появилась необходимость интегрироваться с системами электронного документооборота (ЭДО), в которых по единому информционному протоколу это всегда три отдельных поля: имя, отчество и фамилия.

Кажется, что всё просто. Но нет.

Это простое изменение породило множество сложностей:

1. Создание алгоритма деления строки на части, который не для всех случаев с отчеством «Гаджи оглы» хорошо отработают.
2. Модификация API-методов. Минимум 1, максимум — все, если данные ФИО этой роли в системе везде.
3. Изменение пользовательского интерфейса (UI) всех мобильных и веб-приложений, где есть ФИО, и доработка взаимодействия по API с сервером.
4. Доработка существующих интеграций.

Все эти изменения были нужны лишь из-за одной «маленькой» новой функции! Моя боль об этом записана в этом видео с конференции.

2. Еще один пример — думали, что у машины может быть только один владелец в автосервисе.

Проблемы со связями в базах данных. Сначала была связь «один ко многим», где у одной машины был один владелец, и у одного владельца много машин. Но со временем эксплуатации системы в продакшн оказалось нормальной ситуацией, что иногда два человека приезжают обслуживать одну машину. Иногда даже три.

Структура БД меняется: для правильного поддержания процесса нужна связь «многие ко многим». И в одну задачу это изменение не сделать.

Важно проработать цепочку задач, которые обеспечат совместимые изменения. Если хорошо не продумать порядок перехода к новой структуре хранения данных, то можно встретить огромное количество ошибок по функциональности всей системы, так как машина и клиент главные сущности в системе автосервиса.

Простые изменения и требования? Да, если подумать логически, на верхнем уровне. Но из-за того, что «под капотом» системы огромный мир данных и механизмов по их хранению, получению и обработке, то иногда мы попадаем на серьезные работы по развитию.

Так и получается, что мы с разработчиками садимся обсуждать: проще сделать «костыли» или лучше переделать с нуля сейчас, чтобы через год опять не пожалеть о принятом решении.

Важно учиться искать баланс и на старте работ найти грань: не допустить овер-инжиниринга, и при этом сделать модель БД гибкой. Это нужно постигать.

База данных — фундамент системы

БД — это фундамент системы, который влияет на реализацию всех требований. Все бизнес-процессы и функции сводятся к одному – обработке данных.

Каждое действие, каждый клик — это запрос к базе данных. И в этой базе данных хранятся сведения, которые предстоит собирать и обрабатывать, чтобы обеспечиать выполнение бизнес-процессов и функций в ней.

Базовые определения и примеры, прежде чем читать далее

Сущности — реальные объекты этого мира. Например: стол, стул, машина, тарелка, цветок и другие.

Свойства (атрибуты) — характеристики сущностей, которые для каждого из объектов сущностей могут быть уникальны.

Например:- машина — сущность.- Tesla Model X 2023 г., Porsche 911 2023 г., Toyota Camry 2022 — конкретные объекты сущности «машина». — цвет, производитель, модель, год, объем двигателя — свойства (атрибуты) сущности «машина».

ER-диаграмма (Entity-Relationship) — графическое представление сущностей БД и связей. Нотация моделирования баз данных.

Пример про медицинскую систему

Рассмотрим медицинскую информационную систему для частной поликлиники.

1. Пациент хочет сделать запись на прием онлайн: система отображает пациенту данные о доступных услугах, врачей и время для записи.
2. Пациент записывается на прием: система обрабатывает информацию о пациенте, докторе, времени приема, кабинете.
3. Регистратура звонит пациенту и подтверждает запись на прием: система меняет в базе данных статус записи с «новая» на «подтверждена».
4. Когда пациент приходит на прием, то в регистратуре делают отметку о том, что пациент ожидает — опять смена статуса.
5. И это только начало! Процессов в поликлинике много, особенно связанных с приемом пациента 🙂

Мы, как аналитики, должны продумать все сценарии, связанные с записью пациента к врачу.

Мне в этом плане особенно нравится устаревшая нотация моделирования IDEF0, потому что она не только отражает все шаги процесса, но и показывает какие входные и выходные данные нужны для реализации каждого их них.

В результате прочтения требований к медицинской системе, получаю список сущностей и свойств — основа для логической модели БД.

Прежде чем смотреть что получилось, попробуйте сами быстро выделить список сущностей и свойств. Совпадём?

Сущности и свойства медицинской информационной системы на основе описания процесса записи на прием к врачу

1. Пациент: Человек, который обращается в поликлинику для получения медицинской услуги.
   • ФИО,
   • контактная информация,
   • история болезни,
   • и так далее.
2. Услуга: Конкретное медицинское вмешательство или процедура, доступная для предоставления пациентам.
   • название,
   • описание,
   • продолжительность,
   • стоимость.
3. Врач: Медицинский специалист — сотрудник поликлиники, предоставляющий конкретные услуги.
   • ФИО,
   • специализация,
   • график работы,
   • кабинет.
4. Запись на прием: Информация о планируемом визите пациента к врачу.
   • дата и время визита,
   • пациент,
   • врач, статус записи (новая, подтверждена, пациент ожидает и т.д.),
   • кабинет.
5. Кабинет: Помещение, где врачи принимают пациентов.
   • номер кабинета,
   • этаж,
   • врач(и), которые в нем принимают.
6. Регистратура:
   • Описание: Отдел или персонал поликлиники, ответственный за прием и регистрацию пациентов, а также подтверждение записей на прием.
   • Атрибуты: Сотрудники регистратуры, контактная информация, график работы.
7. Статус записи: Состояние, в котором находится запись на прием в данный момент.
   • новая,
   • подтверждена,
   • пациент ожидает,
   • завершена,
   • и т.д.

Более подробный пример можно будет почитать в моем канале, начиная с этого поста.

Проверка требований на полноту и непротиворечивость с помощью проектирования БД

Заметили, что в тексте я выделила жирным отдельные слова? Это я, каждый раз работая с требованиями, повторяю одну и ту же процедуру:

• Выделяю слова в тексте, обычно двумя цветами: сущности и их свойства.
• Т.к. я за ускорение процесса, то выделяю слова мысленно и сразу же начинаю строить ER-модель базы данных на логическом уровне: создаю список таблиц (сущностей в базе данных) и добавляю в них свойства.
• После того, как таблицы созданы, проверяю, всё ли логично и всего ли хватает.
  Обычно, в процессе такой проверки, я понимаю, что половина данных в описании бизнес-процесса упущена, т.к. в их описании такой уровень детализации не требовался. Глядя на список таблиц, дополняю их свойствами на основе вопросов к Google, ChatGPT с 2023 года и жизненного опыта. Всё, что вызывает вопросы, выношу на обсуждение с владельцем IT-продукта (заказчиком) о хранении информации про его бизнес сущности.
• Теперь можно строить связи и проставлять кратности (полезная картинка по кратностям). Т.к. требования я уже написала и прочитала (и выучила), то делаю это интуитивно. Если вы будете пользоваться моей стратегией, то лучше читать требования еще раз и проставлять связи.
• На ER-диаграмме ищу связи «многие-ко-многим» и убираю их. Дополняю БД внешними ключами, где их нет. Довожу до состояния полноценной логической модели данных, иногда даже сразу до физической.
• Тестирую требования: беру каждую функцию в системе и проверяю, как она будет работать с моей базой данных на запись и получение данных.
  Если я могу простыми словами объяснить разработчику в какие таблицы писать данные или из каких забирать, то всё хорошо. А если нет, то плохо.
• Проверяю масштабируемость: смотрю на список запланированных задач на следующих этап разработки или придумываю потенциально возможные сценарии к реализации. Здесь важно не фантазировать о чём-то невозможном, а продумать, что в ближайшие 3-5 лет работы системы вообще возможно по функциональности и в целом может уже работает в отрасли в других системах, у конкурентов.
  Не всегда можно всё предугадать, но как правило, эта проверка на потенциальное будущее поднимает новые вопросы на обсуждение с владельцем IT-продукта (заказчиком) о потенциальном развитии проекта.

Системный аналитик должен смотреть на систему в трех измерениях:
— как работает сейчас (AS IS),
— что просят сделать (текущие требования на разработку),
— во что это может перерасти в будущем (потенциальное развитие).
Это поможет сделать разработку качественной.

Что получилось после чтения требований? Логическая модель базы данных, связанной с задачей. На её основе ставлю задачи на разработчиков Backend, а также разработчикам мобильных и десктоп приложений, когда нужно сделать локальную базу данных, например, на SQLite.

Этот пример подхода был для проекта с нуля. Также можно работать с существующей базой данных в вашем проекте и смотреть, как новые требования повлияют на неё, какие задачи по её изменению поставите на разработчиков.

Этот подход помогает не упускать из требований важные детали, и до передачи работ разработчикам сразу же собрать полные требования по системе, а иногда даже увидеть противоречивые.

Результат:

• требования полные,
• меньше вопросов от разработчиков,
• система масштабируема и спроектирована с учетом потенциального развития.

Этап проектирования БД важен для системных и бизнес-аналитиков. Не игнорируйте его.

Пошаговый план проектирования БД

1. После завершения работы над описанием бизнес-процессов или требований, прочесть их и выделить по тексту список сущностей (таблиц БД) и свойств (полей таблиц).
2. Спроектировать логическую модель данных — ER-диаграмма:
   1. таблицы (сущности),
   2. поля (свойства),
   3. связи между таблицами,
   4. кратности связей между таблицами.

   Связи типа «многие-ко-многим» убрать.
   *Дополнительно, перед логической, можно сделать концептуальную, но она не всегда имеет практическую ценность.

   

3. Прочесть требования еще раз и проверить, что всех данных хватает.
   Недостающие данные дополнить на основе Google, ChatGPT, доступных документов и вопросов заказчику.
4. Дополнить логическую модель требованиями к типам данных, обязательности, уникальности, значениям по умолчанию и индексам свойств таблиц. Получена физическая модель БД.
5. Ставить задачи на разработчиков по их созданию, выстраивая последовательность и зависимости. Часто задачи можно делать параллельно нескольким разработчикам.

SQL для системных аналитиков

Для системного аналитика, владение SQL не просто «буквы для резюме», это ключевой навык, который:

1. Усиливает логическое мышление.
   SQL требует строгого и последовательного подхода к структурированию данных. Такой подход улучшает логические навыки, что в свою очередь помогает быстрее и точнее анализировать требования.
2. Позволяет понимать язык разработчиков и что «под капотом» системы.
   Когда аналитик знает, как устроена база данных, он может разрабатывать требования, учитывающие эту структуру, что уменьшает количество ошибок и доработок в дальнейшем. То же, что и с умением проектировать БД.
3. Помогает обращать внимание на «узкие места» в системе, где важно продумать нефункциональные требования по нагрузке, ограничения.
   Понимая, как устроен запрос и какие ресурсы он потребляет, можно заранее предусмотреть необходимые ограничения.
4. Позволяет с ходу оценивать реализуемость требований.
   Зная SQL, аналитик может сразу определить, насколько реализуемы требования, которые предлагает заказчик, и как они повлияют на производительность и структуру БД.

Знание SQL позволяет понимать, что происходит на встречах с разработчиками и какие технические детали они обсуждают. Даже знания базовых операторов как SELECT, WHERE, IF, JOIN уже многое дает. А когда речь идет о проектах с несколькими БД, то он лучше понимает последовательные цепочки запросов, обеспечивающие синхронизацию данных.

Заключение

Навык проектирования БД и понимание SQL-запросов выводит качество требований и постановок задач от аналитика на новый уровень. С его знанием аналитик точно осознает к каким техническим задачам ведет очередное бизнесовое требование. Кстати, для менеджеров проектов это тоже полезно.

В итоге аналитик ставит не одну общую задачу на «поменяйте на форме одно поле на три», а одну на бэкенд-разработчика по изменению БД, еще одну на изменение одного API-метода, и еще одного API-метода, и существующей интеграции, использующей это поле, и мобильных приложений, и т.д.

Из рекомендаций, что почитать и посмотреть по проектированию БД:

1. Книга: Технологии проектирования баз данных. Д. Л. Осипов.
2. Практический вебинар (видео): Проектирование БД: с чего начать.
3. Практический урок (видео): на проекте для автосервиса показывала, как сделать БД на логическом уровне.
4. Гайд по проектированию БД и SQL с помощью ChatGPT. Полезно, когда хочешь сделать свой демо-проект для портфолио или устал писать SQL-запросы сам.
5. Проект по проектированию БД Зоомагазина в моем канале — разбор с нуля, первое сообщение.

1. DBeaver. Особенно, если надо подключиться к БД и посмотреть ER-диаграмму на существующей базе.

БД — не сложно. Особенно, если на практике освоить все правила!

Бизнес-аналитик, UML и SQL с Python: лебедь, рак и щука или будущее data-driven анализа?

Сегодня ответим на несколько самых частых вопросов начинающих: должен ли бизнес-аналитик знать SQL, Python и UML. Читайте далее, почему SQL важнее для системного аналитика, чем для бизнес-аналитика, зачем UML требуется им обоим и кому нужно смотреть в сторону Python.

Нужен ли SQL и Python бизнес-аналитику

За годы практической работы в классическом бизнес-анализе (моделирование и оптимизация бизнес-процессов) мне ни разу не потребовалось самостоятельно писать SQL-запрос или скрипт на Python. Впрочем, из-за того, что я часто совмещаю роли бизнес-аналитика с ролями системного аналитика и проектировщика ИС, лезти в код приходится, и довольно часто. Но проецировать личный опыт в глобальном масштабе – это ошибка выжившего. Поэтому, чтобы объективно ответить на вопрос «должен ли бизнес-аналитик знать SQL и Python», обратимся к профстандартам и ситуации на рынке труда.

Начнем с последнего: сегодня большинство объявлений о вакансиях на должность системного аналитика включают базовые знания SQL в состав обязательных требований к компетенциям кандидата. А многие работодатели и HR-менеджеры до сих пор путают профессии системного и бизнес-аналитика, о различиях которых я говорила в этой статье, или стремятся сэкономить ФОТ, получив 2-в-1. Поэтому такое пожелание можно встретить и в вакансиях бизнес-аналитика. Но, в случае системного аналитика знание SQL действительно является must-have компетенцией для разработки требований к информационным и автоматизированным системам, а также их интеграции между собой.

Классический бизнес-аналитик, согласно российскому профстандарту и руководству BABOK®Guide, работает с требованиями совсем на другом уровне абстракции, фокусируя внимание на оптимальной организации процессов и их экономике. Поэтому знание SQL и теории баз данных – это hard skills системного аналитика. Впрочем, если бизнес-аналитик умеет писать или хотя бы может читать SQL-запросы, это будет приятным бонусом к его базовым компетенциям, которые мы разбирали здесь и здесь. Если вы не до конца поняли отличия системного и бизнес-аналитика, читайте мою новую статью с наглядным примером.

Что касается Python, то умение писать код на этом языке программирования является обязательным требованием к продуктовым аналитикам, веб-аналитикам, маркетинговым аналитикам и аналитикам данных. Несмотря на то, что компетенции всех этих специалистов частично пресекаются в части анализа больших объемов данных, в т.ч. с помощью Python и того же SQL, их рабочие задачи отличаются друг от друга. Тем не менее, в связи с отсутствием профстандартов на эти новые и весьма востребованные специализации, работодатели сами часто не понимают, кто именно нужен, а потому перечисляют их всех в своих вакансиях.

Впрочем, несмотря на наличие или отсутствие официальных стандартов, каждая компания в праве выдвигать собственные требования к компетенциям кандидата, что и наблюдается на сегодняшнем рынке труда. А с учетом всеобщей цифровизации и стремлению к data-driven менеджменту, компетенции в области анализа данных пригодятся также системному и бизнес-аналитику. Не случайно международный институт бизнес-анализа (IIBA®), под эгидой которого выходит BABOK®Guide, в 2020 году выпустил отдельное руководство по бизнес-аналитике данных (Guide to Business Data Analytics). В этот документ, структура которого похожа на BABOK, вошли задачи и техники анализа данных для получения инсайтов, ценных с точки зрения практического бизнеса. SQL и Python упоминаются в нем как рабочие инструменты реализации некоторых техник, таких как разведочный анализ данных (Exploratory Data Analysis) и ETL-процессы (Extract-Transform-Load). Поэтому вполне вероятно, что уже в обозримом будущем SQL с Python будут входить в набор профессиональных компетенций системного и бизнес-аналитика. Почему это уже стало реальностью, я разбираю в этом материале.

Зачем системному аналитику sql

+7 (499) 322 88 70
ok@systems.education

• Переподготовка
• Системный анализ
• Архитектура
• Интеграция
• Базы данных
• Бизнес-анализ
• Продуктовый дизайн

Что ждут от системного аналитика
Спрос на системных аналитиков на рынке труда
денис бесков
Кто такой системный аналитик? Профессия, требования, зарплата

Всё больше компаний сталкиваются с необходимостью разработки, внедрения и поддержки сложных информационных систем. Системный аналитик играет ключевую роль в этом процессе.

В РФ принято использовать сочетание «системный аналитик», но полное название профессии — аналитик-проектировщик (корпоративных) информационных систем. И все части здесь одинаково важны.

Не стоит путать системных аналитиков в ИТ с коллегами из других индустрий, которые, например, участвуют в проектировании киберфизических систем и делают современные автомобили, корабли, самолеты, вертолеты и так далее. Им тоже нужны системные аналитики, системные инженеры, но их задачи касаются в целом связи между оборудованием, датчиками, измерителями, приводами и лишь в том числе — с системным и прикладным софтом.

В статье я разберу несколько вопросов, касающихся сути профессии системного аналитика в ИТ:

• Зачем нужен системный аналитик: 6 основных задач
• Каких умений ждут от системного аналитика компании
• Спрос на профессию в мире и в РФ

Время на чтение статьи: 15 минут
Не любите читать? Посмотрите видео:
Оглавление

Программа переподготовки

«System Analyst Bootcamp»

Курс для тех, кто хочет продолжить своё развитие в ИТ, повысить свой уровень влияния на проекты, уверенно перейдя от задач бизнес-анализа, тестирования или разработки к задачам функционального и технического проектирования

Зачем нужен системный аналитик

Если мы спросим у ChatGPT о миссии системного аналитика, то получим достаточно общий ответ: «Миссия системного аналитика заключается в том, чтобы помочь организациям улучшать свою деятельность с помощью анализа и моделирования их бизнес-процессов и систем».

В целом — сложно поспорить с этим описанием, но предлагаю «вглядеться» в цели профессии чуть глубже. Говоря о миссии, я выделю 6 основных пунктов:

1. Системный аналитик, как и любой аналитик, помогает принимать решения — заказчикам, менеджерам, команде
2. Системный аналитик делает сложное и запутанное — ясным и простым
3. Для этого cистемный аналитик глубоко разбирается в автоматизируемой деятельности, существующих проблемах и ограничениях
4. Системный аналитик не только анализирует, но и проектирует — генерирует, обосновывает и прорабатывает решения
5. Системный аналитик стремится создавать полезные, удобные, эффективные, экономичные и экологичные информационные системы
6. Системный аналитик постоянно изучает новые технологии и методы работы

1. Системный аналитик, как и любой аналитик, помогает принимать решения — заказчикам, менеджерам, команде

Это основное, на что я обращаю внимание при оценке умений системного аналитика.

Аналитическая функция — эта функция, которая поддерживает управление, помогая принимать решения о том, что делать в различных ситуациях, куда развиваться и что менять. В данном случае — куда развивать информационную систему и как её модифицировать.

Фактически эта функция — принципиальная, важнейшая. Нередко бывают ситуации, когда решения пытаются принимать сами менеджеры, заказчики, сами команды. И зачастую они это делают не очень качественно. В момент такого осознания в командах и появляется отдельная роль — аналитик продукта, проекта, бизнеса. Для нашего случая — аналитик системы.

2. Системный аналитик делает сложное и запутанное — ясным и простым

Я бы назвал это «неформальной» миссией системного аналитика.

Есть не очень эстетичная, но тем не менее яркая метафора работы аналитика — «гора родила мышь». В проект приходит аналитик, делает много работы, перерабатывает огромное количество информации и получает на выходе 3 страницы.

В этом и заключается суть профессии: аналитик помогает находить самое главное, самое важное, самое интересное, самое нужное — чтобы сфокусировать команду на том, что и как необходимо сделать в первую очередь.

3. Для этого системный аналитик глубоко разбирается в автоматизируемой деятельности, существующих проблемах и ограничениях

Чтобы решить свою задачу, аналитик должен хорошо понимать предметную область: чем занимается компания, что делают её сотрудники, как они это делают и почему, какие есть проблемы и ограничения.

Нередко бывает так, что эти моменты не очень глубоко документированы и аналитику необходимо их изучить, построить модель или набор гипотез, объясняющих существующую ситуацию и позволяющих её правдоподобно воспроизвести и только потом делать выводы и оценки. Это важно, потому что ожидается, что аналитик должен большую часть своих решений и рекомендаций обосновывать, аргументировать.

4. Системный аналитик не только анализирует, но и проектирует — генерирует, обосновывает и прорабатывает решения

Если поговорить с заказчиками или командами, то можно понять, что очень часто мало кого интересует сам по себе анализ. Их интересует не сам факт потребности в изменении или его причины, а то, КАК это сделать, КАКИМ ОБРАЗОМ добиться желаемого нового качества или поведения системы.

Именно здесь проявляется скрытая задача аналитика: от него ожидается не только анализ, а на самом деле и в большой степени синтез. Например, системные требования часто являются не продуктом анализа, а продуктом синтеза.

Системный аналитик должен определить, какие функции будет выполнять система, исходя из деятельности и задач организации, законодательства, контекста рынка и так далее. И это уже про задачу проектирования.

При этом, если мы посмотрим какую-нибудь учебную литературу по разработке требований, то там задачу проектирования не видно вообще: аналитик порождает требования, как будто напрямую трассирует потребности заказчика на выраженные текстом требования к системе, минуя этап построения модели этой системы.

К сожалению, редко где можно встретить явное утверждение о том, что системный аналитик синтезирует решение. И это одна из тех идей, над которой мы будем работать с коллегами ближайшие несколько лет — делать более явной функцию проектирования ИТ-систем через обучение системных аналитиков (и трансформацию их в полноценных проектировщиков информационных систем).

5. Системный аналитик стремится создавать полезные, удобные, эффективные, экономичные и экологичные информационные системы

Это то, ради чего аналитик вообще что-то делает.

Нарисовать красивый процесс или написать классные требования — это не самоцель. Целью системного аналитика должно быть помочь компании, команде, заказчику сделать такую систему, которая улучшит работу компании. Именно на это глобальное изменение следует ориентироваться аналитику.

6. Системный аналитик постоянно изучает новые технологии и методы работы

Важно понимать, что наша индустрия достаточно быстро меняется, быстро развивается. Когда мы с коллегами активно осваивали профессию 15-20 лет назад, нам было достаточно изучить инженерию требований, изучить как работают СУБД, немножко про архитектуру ПО и уже с этим приносить большую пользу командам и компаниям.

Сейчас на передний план всё сильнее выходит тема интеграции ИТ-систем. Постоянно появляются новые технологии и подходы к разработке, которые необходимо изучать. Да, не так глубоко, как разработчикам, но на достаточно хорошем уровне, чтобы мочь эти технологии анализировать, описывать, рекомендовать к внедрению.

SQL ДЛЯ БИЗНЕС-АНАЛИЗА

Мы поистине гордимся нашими тренерами, поскольку каждый из них является экспертом в своей области и добился значительного успеха.

Дмитрий Жанжаров
Тренер и автор курса SQL

• Многолетний опыт в разработке и поддержке баз данных с использованием Oracle PL/SQL, Oracle Forms, Oracle Reports в ООО «АВТОПРОСТО».
• Построение финансовой отчётности компании с использованием SQL.
• Создание CRM системы компании.
• Автор программного обеспечения: ERP система для предприятия на рынке финансовых услуг (авторское свидетельство №41933).
• Опыт в разработка учебных материалов и обучение пользователей.

Форматы обучения и пакеты

Онлайн «свободный график»

Доступ к курсу: 3 мес Работа тренера: 3 мес Стоп уроки: Нет Расписание: Нет Язык записей: Русский Стоимость: 120 usd

Доступ к курсу: неограничен Работа тренера: 6 мес Стоп уроки: Нет Расписание: Нет Язык записей: Русский Стоимость: 160 usd

Доступ к курсу: неограничен Работа тренера: 12 мес Стоп уроки: Нет Расписание: Нет Язык записей: Русский Стоимость: 190 usd

Программа курса

Модуль 1. СОЗДАЕМ ПЕРВЫЕ ЗАПРОСЫ. ИНСТРУКЦИЯ SELECT

• Организация окна SSMS, объекты базы данных
• Разворачиваем учебную базу данных
• Язык интерфейса и региональные настройки
• Делаем нашу БД активной. Инструкция USE
• Работаем с файлами запросов: сохранение и открытие Региональные настройки. COLLATE
• «Горячие клавиши», IntelliSense («всплывающая» подсказка) Инструкция SELECT: базовая выборка данных из таблицы базы данных DISTINCT: отбираем только уникальные строки
• Агрегатные функции: получаем итоговые данные по таблице
• COUNT(*): а сколько строк в таблице?

Модуль 2. ЗНАЧЕНИЕ NULL, ВЫЧИСЛЯЕМЫЕ СТОЛБЦЫ И СОРТИРОВКА ВЫБОРКИ (ORDER BY)

• Значение NULL и как с ним поступают агрегатные функции
• Псевдонимы столбцов и AS: даем свои названия столбцам
• Добавляем вычисляемые столбцы в итоговую выборку
• ORDER BY: упорядочиваем строки
• Вложенная сортировка выборки: сортируем по нескольким столбцам
• Определяем порядок сортировки. ASC, DESC

Модуль 3. ДОБАВЛЯЕМ УСЛОВИЯ НА ОТБОР СТРОК. WHERE, TOP И ДРУГИЕ

• WHERE: накладываем условия на отбор строк
• Операции сравнения: простые и составные
• Комбинируем условия: AND, OR, BETWEEN…AND.
• IN — только то, что есть в списке
• LIKE: задание условий по текстовому шаблону, символы подстановки
• Операции отрицания: NOT и другие
• IS NULL, IS NOT NULL: только те, где есть данные или наоборот
• TOP и TOP…PERCENT: ограничиваем количество выводимых строк
• OFFSET … FETCH: смещаемся вниз и отбираем только строки …

Модуль 4. ГРУППИРУЕМ СТРОКИ И НАКЛАДЫВАЕМ УСЛОВИЯ. GROUP BY, HAVING

• GROUP BY: группируем строки и вычисляем итоги для групп строк
• HAVING: накладываем условия отбора на итоговые строки по группам
• Немного экзотики: WITH ROLLUP, WITH CUBE и GROUPING SET
• OVER: помещаем итоги по группам в каждую строку

Модуль 5. КАК ОРГАНИЗОВАНА РЕЛЯЦИОННАЯ БАЗА ДАННЫХ. ПРАКТИЧЕСКОЕ ИССЛЕДОВАНИЕ

• Чем нехороша одна большая таблица?
• Нормализация: разбиваем одну большую на много маленьких таблиц
• Реляционная база данных: немного теории, без которой дальше никак
• Первичные и внешние ключи, связи и типы связей между таблицами
• А как это выглядит у нас? Исследование нашей учебной базы данных

Модуль 6. ОБЪЕДИНЯЕМ ДАННЫЕ ИЗ РАЗНЫХ ТАБЛИЦ. JOINы И ПОДЗАПРОСЫ

• Расширяем возможности: добавляем в запрос столбцы из других таблиц
• JOINы: разбираемся детально и приобретаем устойчивое понимание
• Типы соединений, внутреннее и внешние соединения
• Практические кейсы с INNER JOIN, LEFT JOIN, RIGHT JOIN и FULL JOIN
• Подзапросы и когда они нужны
• Подзапрос как источник данных для столбца в SELECT
• Подзапрос как таблица-источник в FROM
• Подзапрос в условии WHERE или HAVING

Модуль 7. ПОДЗАПРОСЫ И ОБЪЕДИНЕНИЯ. UNION (ALL), EXCEPT, INTERSECT

• Подзапрос в WHERE или HAVING плюс IN() или EXISTS
• Неявное соединение таблиц
• Добавляем в запрос строки из других таблиц. Понимание операций над множествами
• Практические кейсы с UNION, UNION ALL, INTERSECT и EXCEPT

Модуль 8. ГДЕ И КАК АНАЛИТИК ИСПОЛЬЗУЕТ SQL?

• Экспорт результатов запроса
• Excel: Подключение к БД SQL Server с помощью классического инструмента
• Power Query для Excel и Power BI (direct queries, конвертация кода “M” в SQL)
• Power Pivot в Excel: подключение к БД SQL Server

Модуль 9. ПРАКТИКУМ. РЕЗЮМИРУЕМ РАБОТУ С ОДНО- И МНОГОТАБЛИЧНЫМИ ЗАПРОСАМИ

• Кейс-1. Какие модели каких поставщиков закупались / не закупались когда-либо?
• Кейс-2. Особенности использования «оконных» функций
• Кейс-3. Какие клиенты еще не купили, а какие сделали премиум покупки?

Модуль 10. ФУНКЦИИ SQL. ИСПОЛЬЗУЕМ ТЕКСТОВЫЕ ФУНКЦИИ

• Извлекаем недостающую информацию: CHARINDEX(), SUBSTRING(), REVERSE(), …
• Ищем и извлекаем по текстовым шаблонам: PATINDEX()
• Комбинируем текстовую информацию из разных таблиц: CONCAT(), SPACE(), TRIM(), …
• Находим, обрабатываем, заменяем, подставляем: REPLACE(), …

Модуль 11. ФУНКЦИИ SQL. ЛОГИЧЕСКИЕ ФУНКЦИИ И ВЫРАЖЕНИЯ. ФУНКЦИИ ДЛЯ РАБОТЫ С NULL

• Обрабатываем ситуации с ошибками и другие с помощью IIF()
• Решаем задачи классификации с помощью конструкции CASE … WHEN …
• Разные кейсы по обработке значений NULL: ISNULL(), NULLIF(), COALESCE()

Модуль 12. ФУНКЦИИ SQL. РАБОТАЕМ С ДАТАМИ И ВРЕМЕНЕМ

• Работаем с датами и временем: GETDATE(), DATENAME(), DATEFROMPARTS(), DATEADD(), …

Модуль 13. ФУНКЦИИ SQL. МАТЕМАТИЧЕСКИЕ ФУНКЦИИ И ФУНКЦИИ ПРЕОБРАЗОВАНИЯ ТИПОВ

• Работаем с числовыми данными: ISNUMERIC(), ABS(), FLOOR(), CEILING(), …
• Функции преобразования типов: CAST(), CONVERT(), особенности использования
• Функции преобразования в текстовые строки: STR(), FORMAT() и их особенности

Модуль 14. ПРАКТИКУМ. РЕЗЮМИРУЕМ РАБОТУ С ФУНКЦИЯМИ И ВЫРАЖЕНИЯМИ SQL

• Кейс-1. Анализ динамики продаж
• Кейс-2. ABC анализ
• Кейс-3. Равномерность спроса (XYZ)
• Кейс-4. Анализ структуры чека
• Кейс-5. Статистика продаж
• Кейс-6. Рейтинги продаж

Модуль 15. ЯЗЫК МАНИПУЛЯЦИИ ДАННЫМИ (DML): ДОБАВЛЕНИЕ, ИЗМЕНЕНИЕ И УДАЛЕНИЕ ДАННЫХ

• Добавляем новые данные в таблицы: INSERT
• Оператор изменения данных UPDATE, отбор строк на изменение по условиям
• Удаление данных из таблиц, условия на удаление строк: DELETE

Модуль 16. ЯЗЫК ОПРЕДЕЛЕНИЯ ДАННЫХ (DDL): ДОБАВЛЕНИЕ, ИЗМЕНЕНИЕ И УДАЛЕНИЕ ОБЪЕКТОВ БД

• Используем графический интерфейс SSMS
• Типы данных полей таблиц и их определение
• Создание ограничений (CONSTRAINT): первичные и внешние ключи, другие ограничения
• Индексы. Зачем они?
• Используем команды CREATE, ALTER, DROP
• Создание представлений (VIEW)
• Заполняем новую таблицу результатом запроса: SELECT INTO
• Импорт данных из файла .csv (Excel)

Модуль 17. ПРАКТИКУМ. РАЗРАБОТКА И КОНСТРУИРОВАНИЕ БД ДЛЯ МИНИ CRM СИСТЕМЫ

• Создаем новые объекты для учета взаимодействий с клиентами
• Добавляем справочные таблицы, определяем типы данных
• Создаем PRIMARY KEYs и FOREIGN KEYs
• Задаем другие типы ограничений (CONSTRAINT): NOT NULL и другие
• Заполняем новые таблицы данными

Модуль 18. ЭЛЕМЕНТЫ ЯЗЫКА ПРОГРАММИРОВАНИЯ В T-SQL

• Использование переменных: объявление и присвоение значений
• Табличные переменные
• Глобальные и локальные временные таблицы
• Операторы ветвления кода: IF … ELSE
• Организация циклов в коде: WHILE
• Пакеты

Модуль 19. ПОЛЬЗОВАТЕЛЬСКИЕ ПРОЦЕДУРЫ И ФУНКЦИИ, ТРИГГЕРЫ

• Пользовательские процедуры
• Создание и использование пользовательских функций
• Триггеры

Модуль 20. СОЗДАНИЕ БАЗЫ ДАННЫХ. ПРАВА ДОСТУПА

• Создание базы данных: основные параметры
• COLLATE и региональные настройки
• Пользователи, роли и схемы
• Разграничение прав доступа: GRANT, REVOKE

Модуль 21. ИСПОЛЬЗОВАНИЕ SQL ПРИ РАЗРАБОТКЕ ПРИЛОЖЕНИЙ (В ПРОГРАММИРОВАНИИ)

• Программная работа с базой данный (на примере кода в VBA)
• Программное извлечение данных из БД
• Программное изменение, запись и удаление данных в БД

Как проходит обучение

• ОЧНЫЙ КУРС
  ( КУРСЫ EXCEL КИЕВ)
• ОНЛАЙН КУРС
  (ЖИВЫЕ ЭФИРЫ)
• ОНЛАЙН КУРС
  (СВОБОДНЫЙ ГРАФИК)

Очные занятия
(8 занятий по 2,5 часа)

• Занятия проходят в компьютерном классе в малых группах
• Весь материал демонстрируется на большом экране
• После занятия в аудитории все студенты получают доступ к видеозаписям занятий

Самостоятельная
работа

• Просмотр видеозаписей занятий (закрепление аудиторного материала)
• Просмотр дополнительных видеоуроков
• Выполнение домашних заданий
• Выполнение курсового проекта

Поддержка
(6 месяцев)

• Во время прохождения курса получаете обратную связь от наших экспертов: в аудитории от тренера, во время самостоятельной работы — от онлайн-тренера поддержки
• Еще 6 месяцев по окончанию курса получаете поддержку онлайн-тренера в рамках курса и по Вашим рабочим задачам

Дополнительные
бонусы

• 2дополнительных видеоурока
• Доступ к видео — пожизненно

Онлайн занятия
(10 занятий по 2 часа)

• Занятия проходят в режиме вебинаров с преподавателем
• Любые вопросы можно задавать тренеру в чате в режиме реального времени
• После занятий в живом эфире все студенты получают доступ к видеозаписям занятий

Самостоятельная
работа

• Просмотр видеозаписей занятий (закрепление материала)
• Просмотр дополнительных видеоуроков
• Выполнение домашних заданий
• Выполнение курсового проекта

Поддержка
(6 месяцев)

• Во время прохождения курса получаете обратную связь от наших экспертов: в аудитории от тренера, во время самостоятельной работы — от онлайн-тренера поддержки
• Еще 6 месяцев по окончанию курса получаете поддержку онлайн-тренера в рамках курса и по Вашим рабочим задачам

Дополнительные
бонусы

• 2 дополнительных видеоурока
• Доступ к видео — пожизненно
• Возможность заниматься из любой точки мира

Доступ к модулю
(21 занятие по 1 часу)

• Сразу после оплаты получаете доступ к 1-му занятию
• Выбираете удобный для себя темп и время занятий
• Получаете доступ к следующему занятию только после успешного выполнения домашнего задания к предыдущему занятию

Самостоятельная
работа

• Просмотр дополнительных видеоуроков
• Выполнение домашних заданий
• Выполнение курсового проекта

• Во время прохождения курса получаете обратную связь от онлайн-тренера поддержки об успешности выполнения домашних заданий
• Получаете консультации в том числе по Вашим рабочим задачам

Дополнительные
бонусы

• 2 дополнительных видеоурока
• Доступ к видео — пожизненно в пакетах «6 месяцев» и «MAX»
• Возможность заниматься из любой точки мира

Часто задаваемые вопросы

Какое программное обеспечение на моем компьютере должно быть установлено для прохождения курса и выполнения заданий к нему?

Для успешного прохождения курса и выполнения его заданий рекомендуем, чтобы на вашем личном компьютере была установлена операционная система не ниже Windows 10. До старта курса, у вас будет доступ к вводному занятию с инструкцией по установке MS SQL Server Management Studio (бесплатно, с сайта Microsoft). Обратите, также, внимание на то, что для установки программного обеспечения у себя на компьютере у вас должны быть права администратора.

Если у меня Macbook, cмогу ли я на нём проходить курс?

Сможете в том случае, если на вашем Mac установлена виртуальная машина с Windows (Parallels Desktop) либо Docker. Обратите, пожалуйста, внимание, что данное программное обеспечение является платным (первое) и мы не сможем Вас проконсультировать и оказать помощь в их установке.

Какой диалект языка SQL используется в данном курсе?

В курсе мы используем transact-SQL компании Microsoft. Однако в подавляющем большинстве случаев курс содержит стандартный синтаксис SQL (стандарт SQL), который используется в MySQL, Oracle SQL и других SQL-ориентированных системах управления базами данных. В некоторых случаях мы используем специфические для t-SQL функции, но параллельно предоставляем варианты решения с использованием стандарта SQL.

На кого ориентирован данный курс?

При разработке данного курса мы ориентировались на бизнес-аналитиков, маркетинг-аналитиков, финансовых аналитиков и аналитиков продаж, всех, кто в своей повседневной рабочей жизни сталкивается с обработкой и анализом бизнес-данных, и кто хочет научиться использовать SQL «с нуля». Если ваша цель – стать разработчиком либо администратором баз данных, данный курс будет отличной стартовой площадкой для дальнейшего, более глубокого изучения реляционных баз данных и SQL.

Какой должен быть уровень подготовки для прохождения курса?

Для прохождения курса не требуется какая-либо специальная подготовка по базам данных и SQL. Курс – «с нуля». Вам необходимо быть обычным уверенным пользователем компьютера. Понадобится также логическое и абстрактное мышление. Если вы являетесь уверенным пользователем Excel, легко работаете с формулами – у вас это уже точно есть.

Можно ли во время прохождения курса и после его окончания получать консультации по своим рабочим вопросами?

Да, на протяжении курса и еще 6 месяцев после его окончания за вами закреплен онлайн-тренер поддержки, что включено в стоимость курса.

Другие вопросы

Если вы не нашли свой вопрос в списке выше, ниже есть кнопка «Часто задаваемые вопросы», в этом разделе находятся более общие вопросы и ответы на них, не относящиеся к конкретно взятому курсу

Что необходимо знать

Данный курс – о реляционных базах данных и языке запросов к базам данных SQL. Ориентирован в большей части на аналитиков и людей, кому нужно уметь извлекать «сырые» данные для дальнейшего их использования (моделирования, визуализации).

1. Для прохождения курса не требуются знания в области баз данных, SQL и программирования. Курс — с нуля.
2. Для получения наилучшего эффекта от прохождения курса желательно, чтобы вы:

• Имели представление и хотя бы минимальный опыт работы с данными: извлечение, подготовка и очистка, моделирование, визуализация
• Умели работать в Excel и/или других специализированных приложениях бизнес-аналитики (BI): Power BI, Tableau, Qlikview или других
• Понимали концепции формул, функций, логики (например, работая в Excel)

Если Вы все же делаете только первые шаги в бизнес-аналитике и работе с данными, рекомендуем к SQL вернуться немного позже, а начать с изучения подходов, методов и инструментов работы с данными, пройдя наиболее подходящий для этой цели курс Excel: