ИИ заберёт мою работу. А с какой стороны вы?
Невозможно пройти мимо хайпа на тему ИИ. Кажется, это не обсудил только ленивый. Одни боятся, что их профессия перестанет быть востребованной из-за автоматизации. Другие же радуются возможностям, которые дают новые технологии, ускоряющие рабочие процессы или решающие рутинные задачи.
Думаю, по настроению абзаца выше несложно определить, с какой стороны этого стремительного автобуса прогресса сижу я😉
Переживаю ли я, что в ближайшем будущем меня "заменят роботы"😑 ? Боюсь, что с гениальностью построения некоторых архитектур и используемых инструментов (ведь где-то всё ещё используются системы начала 2000х 😬 ) пока сможет справиться только человек 😀
В конце концов я уверена: стремление к развитию и освоение новых технологий открывают перед нами неограниченные возможности и помогают оставаться востребованными в быстро меняющемся мире.
Безусловно, в обозримом будущем часть работы будет автоматизирована с помощью ИИ, но станет ли от этого меньше задач? Мне думается, что скорее нет, чем да. Конечно они будут трансформироваться, но, вероятно, станут только интереснее.
Современные исследования показывают, что внедрение ИИ в производственные и аналитические процессы не приводит к массовом увольнениям. Наоборот, оно создаёт новые возможности для проф.роста и развития. Всемирный экономический форум рассуждает о том, что ИИ изменит значительную часть рабочих мест во всем мире, но в ходе этого процесса будут созданы новые, особенно в технологически развитых отраслях.
Уже сейчас я активно использую ИИ в рабочих и повседневных задачах, не только как "умный гугл", но и как автоматизатор рутины или "уточку" для размышлений (прочитайте на досуге мой пост о методе утёнка). Да, пока что иногда он промахивается, иногда "промахиваюсь" я (привет прокачке внимательности, это тема для отдельного разговора), но в общей массе он упрощает и ускоряет выполнение задач, в особенности однообразных. А ещё классно помогает изучать новое.
А вы используете ИИ в работе и жизни?😎
Невозможно пройти мимо хайпа на тему ИИ. Кажется, это не обсудил только ленивый. Одни боятся, что их профессия перестанет быть востребованной из-за автоматизации. Другие же радуются возможностям, которые дают новые технологии, ускоряющие рабочие процессы или решающие рутинные задачи.
Думаю, по настроению абзаца выше несложно определить, с какой стороны этого стремительного автобуса прогресса сижу я
Переживаю ли я, что в ближайшем будущем меня "заменят роботы"
В конце концов я уверена: стремление к развитию и освоение новых технологий открывают перед нами неограниченные возможности и помогают оставаться востребованными в быстро меняющемся мире.
Безусловно, в обозримом будущем часть работы будет автоматизирована с помощью ИИ, но станет ли от этого меньше задач? Мне думается, что скорее нет, чем да. Конечно они будут трансформироваться, но, вероятно, станут только интереснее.
Современные исследования показывают, что внедрение ИИ в производственные и аналитические процессы не приводит к массовом увольнениям. Наоборот, оно создаёт новые возможности для проф.роста и развития. Всемирный экономический форум рассуждает о том, что ИИ изменит значительную часть рабочих мест во всем мире, но в ходе этого процесса будут созданы новые, особенно в технологически развитых отраслях.
Уже сейчас я активно использую ИИ в рабочих и повседневных задачах, не только как "умный гугл", но и как автоматизатор рутины или "уточку" для размышлений (прочитайте на досуге мой пост о методе утёнка). Да, пока что иногда он промахивается, иногда "промахиваюсь" я (привет прокачке внимательности, это тема для отдельного разговора), но в общей массе он упрощает и ускоряет выполнение задач, в особенности однообразных. А ещё классно помогает изучать новое.
А вы используете ИИ в работе и жизни?
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1
Методология Кимбалла: эволюция подходов к хранилищам данных
В отличие от подхода Билла Инмона, Ральф Кимбалл в конце 1980-х годов предложил построение хранилища данных снизу вверх. Сначала создаются маленькие, но полнофункциональные модули — звёздные схемы, которые легко масштабируются и интегрируются. Это упрощает доступ к данным и их анализ.
Ключевая идея Кимбалла — использовать денормализованные звёздные схемы для быстрого и эффективного извлечения данных. Данные изначально структурируются для запросов и анализа. Это делает методологию идеальной для бизнес-аналитики, где важен быстрый доступ к актуализированным данным. Хранилище по Кимбаллу — это по сути коллекция витрин данных.
Важные принципы методологии:
— Узнаем какие отчеты нужны, изучаем источники, на этапе подготовки преобразуем данные, затем создаем витрины.
— Денормализация данных уменьшает количество соединений (JOIN) в запросах.
— Простая и понятная архитектура ускоряет разработку и внедрение. Нет детального слоя в понимании Инмона.
— Методология способствует быстрой адаптации к изменениям в бизнес-требованиях, благодаря модульному подходу.
Однако, методология Кимбалла может привести к некоторым проблемам с управлением данными на больших объемах из-за денормализации. Здесь важен баланс между производительностью и точностью данных.
Преимущества и недостатки:
+ Быстрая реализация проектов с "нуля".
+ Гибкость в добавлении новых источников данных.
+ Простота понимания и управления.
+ Простота запросов.
- Риск возрастания избыточности данных.
- Нет единого источника истины.
- Потенциальные трудности в поддержании целостности данных на больших объемах.
Основные отличия подхода Кимбалла от Инмона:
1. Проектирование сверху вниз против снизу вверх.
2. Денормализация данных.
3. Ориентация на быстрый доступ и анализ данных.
4. Низкая целостность данных.
4. Простота и скорость внедрения (по сравнению с Инмоном).
Методология Кимбалла отлично подходит для средних и малых предприятий, где требуется быстрая доставка результатов. Гибкий и модульный подход позволяет быстро адаптироваться к изменяющимся потребностям бизнеса, что делает её предпочтительным выбором для динамичных организаций.
#dwh
В отличие от подхода Билла Инмона, Ральф Кимбалл в конце 1980-х годов предложил построение хранилища данных снизу вверх. Сначала создаются маленькие, но полнофункциональные модули — звёздные схемы, которые легко масштабируются и интегрируются. Это упрощает доступ к данным и их анализ.
Ключевая идея Кимбалла — использовать денормализованные звёздные схемы для быстрого и эффективного извлечения данных. Данные изначально структурируются для запросов и анализа. Это делает методологию идеальной для бизнес-аналитики, где важен быстрый доступ к актуализированным данным. Хранилище по Кимбаллу — это по сути коллекция витрин данных.
Важные принципы методологии:
— Узнаем какие отчеты нужны, изучаем источники, на этапе подготовки преобразуем данные, затем создаем витрины.
— Денормализация данных уменьшает количество соединений (JOIN) в запросах.
— Простая и понятная архитектура ускоряет разработку и внедрение. Нет детального слоя в понимании Инмона.
— Методология способствует быстрой адаптации к изменениям в бизнес-требованиях, благодаря модульному подходу.
Однако, методология Кимбалла может привести к некоторым проблемам с управлением данными на больших объемах из-за денормализации. Здесь важен баланс между производительностью и точностью данных.
Преимущества и недостатки:
+ Быстрая реализация проектов с "нуля".
+ Гибкость в добавлении новых источников данных.
+ Простота понимания и управления.
+ Простота запросов.
- Риск возрастания избыточности данных.
- Нет единого источника истины.
- Потенциальные трудности в поддержании целостности данных на больших объемах.
Основные отличия подхода Кимбалла от Инмона:
1. Проектирование сверху вниз против снизу вверх.
2. Денормализация данных.
3. Ориентация на быстрый доступ и анализ данных.
4. Низкая целостность данных.
4. Простота и скорость внедрения (по сравнению с Инмоном).
Методология Кимбалла отлично подходит для средних и малых предприятий, где требуется быстрая доставка результатов. Гибкий и модульный подход позволяет быстро адаптироваться к изменяющимся потребностям бизнеса, что делает её предпочтительным выбором для динамичных организаций.
#dwh
❤1
Дайджест статей за апрель 🚀
DWH
Методология Инмона — классика в области хранилищ данных
Методология Кимбалла: эволюция подходов к хранилищам данных
Soft skills и размышления
Математическое мышление в работе и жизни
ИИ заберёт мою работу. А с какой стороны вы?
#дайджест
DWH
Методология Инмона — классика в области хранилищ данных
Методология Кимбалла: эволюция подходов к хранилищам данных
Soft skills и размышления
Математическое мышление в работе и жизни
ИИ заберёт мою работу. А с какой стороны вы?
#дайджест
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1
Повторение — мать учения
Забавно, как с годами начинаешь иначе смотреть на народную мудрость над которой смеялся в школе😅 Помню как бесили эти бесконечные призывы учителей "повторите", а теперь каждый раз чувствую как нейронные связи говорят "спасибо". Чем больше раз повторяю что-то, тем лучше начинаю это делать и быстрее осваиваю новое.
Эта идея подтверждается научными исследованиями. Герман Эббингауз, пионер в изучении памяти, в 1880-х годах впервые исследовал то, как мы забываем информацию. Он провел серию экспериментов с запоминанием бессмысленных слогов и создал "кривую забывания", показывающую, что большая часть информации вылетает из головы через пару дней.
Но есть хорошая новость: он также обнаружил, что систематическое повторение сокращает количество забываемой информации. Чем чаще вы что-то повторяете, тем дольше это остаётся в вашей памяти. Как будто загружаете данные на жесткий диск, а не в оперативку.
Возьмём в пример изучение иностранных языков. Сначала новые слова кажутся чем-то непонятным и забываются через пять минут после зубрежки. Но повторяя их снова и снова, вы замечаете, как они "прилипают" к памяти. Также и с фразами, правилами — через некоторое время вы начинаете использовать их автоматически, без раздумий, потому что у вашего мозга уже есть наработанный "шаблон" действия.
Но, как в любом деле, есть и подводные камни. Многократно выполняя какое-то действие, мы можем начать действовать на автомате и уйти из зоны осознанности. Это, в свою очередь, повышает риск совершения ошибок, поскольку мы перестаем активно анализировать происходящее вокруг.
Несмотря на риск перехода в рутину, систематическое и разнообразное повторение остаётся одним из наиболее эффективных способов обучения и развития как в профессиональной сфере, так и в личной жизни.
Таким образом, хотя повторение может казаться монотонным, оно играет ключевую роль в обучении, закреплении и применении знаний.
Не бойтесь повторяться; бойтесь остановиться на достигнутом!😎
#soft_skills
Забавно, как с годами начинаешь иначе смотреть на народную мудрость над которой смеялся в школе
Эта идея подтверждается научными исследованиями. Герман Эббингауз, пионер в изучении памяти, в 1880-х годах впервые исследовал то, как мы забываем информацию. Он провел серию экспериментов с запоминанием бессмысленных слогов и создал "кривую забывания", показывающую, что большая часть информации вылетает из головы через пару дней.
Но есть хорошая новость: он также обнаружил, что систематическое повторение сокращает количество забываемой информации. Чем чаще вы что-то повторяете, тем дольше это остаётся в вашей памяти. Как будто загружаете данные на жесткий диск, а не в оперативку.
Возьмём в пример изучение иностранных языков. Сначала новые слова кажутся чем-то непонятным и забываются через пять минут после зубрежки. Но повторяя их снова и снова, вы замечаете, как они "прилипают" к памяти. Также и с фразами, правилами — через некоторое время вы начинаете использовать их автоматически, без раздумий, потому что у вашего мозга уже есть наработанный "шаблон" действия.
Но, как в любом деле, есть и подводные камни. Многократно выполняя какое-то действие, мы можем начать действовать на автомате и уйти из зоны осознанности. Это, в свою очередь, повышает риск совершения ошибок, поскольку мы перестаем активно анализировать происходящее вокруг.
Несмотря на риск перехода в рутину, систематическое и разнообразное повторение остаётся одним из наиболее эффективных способов обучения и развития как в профессиональной сфере, так и в личной жизни.
Таким образом, хотя повторение может казаться монотонным, оно играет ключевую роль в обучении, закреплении и применении знаний.
Не бойтесь повторяться; бойтесь остановиться на достигнутом!
#soft_skills
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1
Немного выпала из блога. Уезжала греть костички под жарким солнцем и делать "ничего".
Удивительный опыт, учитывая, что обычно наши путешествия — это многокилометровые перемещения на авто и без. А сейчас были две недели купаний, расслабления, лёгких прогулок и крепкого сна.
Исследования показывают, что отпуск без инфо-шума позволяет мозгу полностью восстановиться. Часы, проведенные на пляже без гаджетов и книг, снижают уровень стресса и улучшают общее самочувствие.
Как оказалось, абсолютное безделье тоже полезный опыт для головы. Вернулась тотально отдохнувшей😄 теперь нужно взять себя в руки и продуктивно вернуться в работу и жизнь.
#life
Удивительный опыт, учитывая, что обычно наши путешествия — это многокилометровые перемещения на авто и без. А сейчас были две недели купаний, расслабления, лёгких прогулок и крепкого сна.
Исследования показывают, что отпуск без инфо-шума позволяет мозгу полностью восстановиться. Часы, проведенные на пляже без гаджетов и книг, снижают уровень стресса и улучшают общее самочувствие.
Как оказалось, абсолютное безделье тоже полезный опыт для головы. Вернулась тотально отдохнувшей
#life
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2💯1
Как писать документацию, которую захотят читать
Натолкнулась на хорошую статью "Как написать код, который полюбят все", с которой рекомендовала бы познакомиться каждому.
Для меня же отдельная польза в том, что её практики прекрасно ложатся не только на написание кода, но и на любую документацию.
Давайте выделим основные принципы, которые сделают доки понятными и полезными:
1. Читаемость и компактность. Текст должен быть кратким и понятным. В инструкции "Открыть терминал. Ввести команду Х" звучит лучше, чем "Запустите командную строку и выполните следующую последовательность действий". Чуть полнее этот тезис я раскрывала в посте "ТЗ должно быть полным, но кратким".
2. Структура. Документация должна быть структурированной. Используем заголовки, подзаголовки и списки. Если есть несколько разделов, обязательно добавляем в начало оглавление. Читатель сразу увидит, где искать нужную информацию.
3. Выразительность. Пишем просто и ясно. Избегаем сложных терминов, если в этом нет необходимости. Если нужно использовать сложные термины, обязательно объясняем их. Так читатель не запутается.
4. Конкретность. Используем конкретные примеры. Это помогает лучше понять написанное. Например, если объясняем, как подключиться к базе данных, приводим примеры кода и скриншоты. Это лучше, чем абстрактное описание.
5. Последовательность. Нужно быть последовательным в использовании терминов и обозначений. Например, если в одном месте пишем "сервис", а в другом "служба", это может сбить с толку. Всегда используем одно и то же слово для одного и того же понятия.
6. Комментирование. Не забываем про комментарии. Хорошие комментарии помогут понять сложные моменты. Например, если есть сложный кусок кода, объясняем, что он делает (а не ждём, что читающий с одного беглого взгляда всё поймёт). Это сэкономит время читателю.
7. Обновляемость. Важно регулярно обновлять документацию. Устаревшая информация может привести к ошибкам. Нет ничего хуже, чем протухшее описание логики витрин или некорректные инструкции по подключению. Для сохранения истории используем контроль версий.
8. Визуализация. Добавляем схемы, диаграммы, скриншоты. Визуальные элементы помогают лучше понять информацию. Например, если есть сложная архитектура системы, добавляем схему. Это лучше, чем длинное, запутанное текстовое описание.
9. Инструменты. Используем инструменты для написания документации. Это могут быть редакторы с поддержкой разметки, системы контроля версий и/или платформы для совместной работы. Чуть подробнее об инструментах я писала здесь.
Следуя этим простым принципам, документация станет в разы более полезной и удобной.
#документация
Натолкнулась на хорошую статью "Как написать код, который полюбят все", с которой рекомендовала бы познакомиться каждому.
Для меня же отдельная польза в том, что её практики прекрасно ложатся не только на написание кода, но и на любую документацию.
Давайте выделим основные принципы, которые сделают доки понятными и полезными:
1. Читаемость и компактность. Текст должен быть кратким и понятным. В инструкции "Открыть терминал. Ввести команду Х" звучит лучше, чем "Запустите командную строку и выполните следующую последовательность действий". Чуть полнее этот тезис я раскрывала в посте "ТЗ должно быть полным, но кратким".
2. Структура. Документация должна быть структурированной. Используем заголовки, подзаголовки и списки. Если есть несколько разделов, обязательно добавляем в начало оглавление. Читатель сразу увидит, где искать нужную информацию.
3. Выразительность. Пишем просто и ясно. Избегаем сложных терминов, если в этом нет необходимости. Если нужно использовать сложные термины, обязательно объясняем их. Так читатель не запутается.
4. Конкретность. Используем конкретные примеры. Это помогает лучше понять написанное. Например, если объясняем, как подключиться к базе данных, приводим примеры кода и скриншоты. Это лучше, чем абстрактное описание.
5. Последовательность. Нужно быть последовательным в использовании терминов и обозначений. Например, если в одном месте пишем "сервис", а в другом "служба", это может сбить с толку. Всегда используем одно и то же слово для одного и того же понятия.
6. Комментирование. Не забываем про комментарии. Хорошие комментарии помогут понять сложные моменты. Например, если есть сложный кусок кода, объясняем, что он делает (а не ждём, что читающий с одного беглого взгляда всё поймёт). Это сэкономит время читателю.
7. Обновляемость. Важно регулярно обновлять документацию. Устаревшая информация может привести к ошибкам. Нет ничего хуже, чем протухшее описание логики витрин или некорректные инструкции по подключению. Для сохранения истории используем контроль версий.
8. Визуализация. Добавляем схемы, диаграммы, скриншоты. Визуальные элементы помогают лучше понять информацию. Например, если есть сложная архитектура системы, добавляем схему. Это лучше, чем длинное, запутанное текстовое описание.
9. Инструменты. Используем инструменты для написания документации. Это могут быть редакторы с поддержкой разметки, системы контроля версий и/или платформы для совместной работы. Чуть подробнее об инструментах я писала здесь.
Следуя этим простым принципам, документация станет в разы более полезной и удобной.
#документация
Библиотека программиста
Как написать код, который полюбят все
Набор практик хорошего кода, не зависящих от языка программирования. Примените их, и ваш код будет не только работать, но и читаться.
❤1
От идеи до таблицы: моделирование данных шаг за шагом
Моделирование выходит далеко за рамки таблиц и баз данных. Оно не только помогает разработчикам понять бизнес, но и помогает бизнесу понять себя.
Классически моделирование делится на три этапа:
— концептуальное
— логическое
— физическое
В этой заметке кратко раскроем каждое понятие, а затем в отдельных статьях поговорим про каждый этап подробнее.
Концептуальное моделирование
Это самый абстрактный этап. Он помогает понять, что именно нужно бизнесу. Здесь важна общая картина, а не детали. Представьте, что вы описываете свою компанию другу. Вы говорите о том, что у компании есть клиенты, товары и заказы. Но при этом не уточняете, как именно всё работает.
Концептуальное моделирование помогает всем в компании говорить на одном языке. Бизнес определяет ключевые сущности и связи между ними, архитекторы и/или аналитики создают простую диаграмму для наглядности. Это позволяет всем участникам проекта видеть общую картину.
Логическое моделирование
На этом этапе мы начинаем погружаться в детали, и уточняем все атрибуты и связи. Например, то, что у товара есть название, цена, размер и количество.
Логическое моделирование делает данные и их взаимосвязи понятными для всех участников. Бизнес подробно описывает сущности и процессы более детально, а аналитики конкретизируют эти данные и их связи.
Физическое моделирование
Наконец, заключительный этап — здесь логическая модель преобразуется в конкретное представление для выбранной СУБД. На этом этапе решаются вопросы, как именно данные будут организованы и управляться в выбранной базе данных.
Физическое моделирование включает:
— определение таблиц, столбцов и типов данных
— разработка индексов и партиционирования (при необходимости) для оптимизации производительности
— определение первичных и внешних ключей для обеспечения целостности данных
— прочие технические тонкости, включая data quality
Если коротко:
— Концептуальное моделирование: определяем ключевые сущности и их связи.
— Логическое моделирование: детализируем атрибуты и связи, уточняем типы данных.
— Физическое моделирование: подготавливаем всю техничку для создания в конкретной СУБД.
Зная об этих этапах, становится ясно, как данные проходят путь от абстрактных понятий, до конкретной реализации в базе данных. В итоге хранилище соответствует бизнесу и работает эффективно.
Но нужно понимать, что моделирование — это не событие, а процесс и он продолжается вместе с развитием компании.
#dwh
Моделирование выходит далеко за рамки таблиц и баз данных. Оно не только помогает разработчикам понять бизнес, но и помогает бизнесу понять себя.
Классически моделирование делится на три этапа:
— концептуальное
— логическое
— физическое
В этой заметке кратко раскроем каждое понятие, а затем в отдельных статьях поговорим про каждый этап подробнее.
Концептуальное моделирование
Это самый абстрактный этап. Он помогает понять, что именно нужно бизнесу. Здесь важна общая картина, а не детали. Представьте, что вы описываете свою компанию другу. Вы говорите о том, что у компании есть клиенты, товары и заказы. Но при этом не уточняете, как именно всё работает.
Концептуальное моделирование помогает всем в компании говорить на одном языке. Бизнес определяет ключевые сущности и связи между ними, архитекторы и/или аналитики создают простую диаграмму для наглядности. Это позволяет всем участникам проекта видеть общую картину.
Логическое моделирование
На этом этапе мы начинаем погружаться в детали, и уточняем все атрибуты и связи. Например, то, что у товара есть название, цена, размер и количество.
Логическое моделирование делает данные и их взаимосвязи понятными для всех участников. Бизнес подробно описывает сущности и процессы более детально, а аналитики конкретизируют эти данные и их связи.
Физическое моделирование
Наконец, заключительный этап — здесь логическая модель преобразуется в конкретное представление для выбранной СУБД. На этом этапе решаются вопросы, как именно данные будут организованы и управляться в выбранной базе данных.
Физическое моделирование включает:
— определение таблиц, столбцов и типов данных
— разработка индексов и партиционирования (при необходимости) для оптимизации производительности
— определение первичных и внешних ключей для обеспечения целостности данных
— прочие технические тонкости, включая data quality
Если коротко:
— Концептуальное моделирование: определяем ключевые сущности и их связи.
— Логическое моделирование: детализируем атрибуты и связи, уточняем типы данных.
— Физическое моделирование: подготавливаем всю техничку для создания в конкретной СУБД.
Зная об этих этапах, становится ясно, как данные проходят путь от абстрактных понятий, до конкретной реализации в базе данных. В итоге хранилище соответствует бизнесу и работает эффективно.
Но нужно понимать, что моделирование — это не событие, а процесс и он продолжается вместе с развитием компании.
#dwh
❤1
Ключевые понятия Data Vault
Что ж, мы уже познакомились с Кимбаллом и Инмоном, теперь пора рассказать про Data Vault. Для начала разберем основные термины, которые нужно понимать.
Data Vault — это методология для работы с данными, объединяющая лучшие практики. Она помогает интегрировать данные из разных систем и анализировать их. Это фундамент на котором можно построить что угодно.
Hub — это таблица, где хранятся уникальные бизнес-ключи, например, ID клиентов. Это основа, на которой будут строиться все связи в хранилище данных.
Link связывает различные сущности в Data Vault, храня информацию о том, какие бизнес-ключи из Hubs связаны между собой. Например, Link покажет, какой клиент (из таблицы клиентов) сделал какой заказ (из таблицы заказов).
Satellite хранит описательные данные о сущности, представленной в Hub или Link. Например это может быть информация о продукте: название, цена и так далее. Здесь записываются все изменения и история этих данных.
Raw Vault — это слой после этапа интеграции данных. Здесь данные моделируются и готовятся для дальнейшей обработки и анализа.
Business Vault — это слой, где применяются бизнес-правила и выполняются различные преобразования данных. Здесь данные обрабатываются, фильтруются и агрегируются, чтобы получить полезные инсайты и отчеты. То есть это место, где сырые данные превращаются в информацию, готовую для анализа и принятия решений.
Point-in-Time (PIT) — это дополнительные структуры, которые помогают ускорить запросы к данным. Они делают доступ к историческим снимкам данных проще, что важно для анализа трендов.
Bridge Table упрощает навигацию между различными частями модели данных в Data Vault. Она позволяет быстро и эффективно выполнять повторяющиеся запросы, объединяя связанные данные из Hubs и Links. Например, Bridge Table может помочь быстро найти все заказы клиентов по разным регионам, объединяя данные из таблиц клиентов и заказов.
Business Key — уникальный идентификатор, который используется для представления бизнес-сущности. Это основной ориентир для интеграции и анализа данных.
Hash Key — хешированное представление бизнес-ключа. Оно используется для оптимизации запросов и обеспечения консистентности данных.
Surrogate Key — системные идентификаторы, которые уникально идентифицируют записи.
Hash-diff — это столбец, который содержит хешированное значение, созданное из множества других столбцов. Если хоть одно из этих значений изменилось, хеш-значение тоже изменится, что позволяет быстро обнаружить изменения в данных.
Data Vault — это инструмент для организации и анализа данных. Он объединяет лучшие практики и упрощает работу с большими объемами информации. Понимание ключевых понятий, таких как Hub, Link, Satellite, и других, поможет нам в дальнейшем подробнее рассмотреть нюансы самой методологии. До встречи в следующих постах😎
#dwh
Что ж, мы уже познакомились с Кимбаллом и Инмоном, теперь пора рассказать про Data Vault. Для начала разберем основные термины, которые нужно понимать.
Data Vault — это методология для работы с данными, объединяющая лучшие практики. Она помогает интегрировать данные из разных систем и анализировать их. Это фундамент на котором можно построить что угодно.
Hub — это таблица, где хранятся уникальные бизнес-ключи, например, ID клиентов. Это основа, на которой будут строиться все связи в хранилище данных.
Link связывает различные сущности в Data Vault, храня информацию о том, какие бизнес-ключи из Hubs связаны между собой. Например, Link покажет, какой клиент (из таблицы клиентов) сделал какой заказ (из таблицы заказов).
Satellite хранит описательные данные о сущности, представленной в Hub или Link. Например это может быть информация о продукте: название, цена и так далее. Здесь записываются все изменения и история этих данных.
Raw Vault — это слой после этапа интеграции данных. Здесь данные моделируются и готовятся для дальнейшей обработки и анализа.
Business Vault — это слой, где применяются бизнес-правила и выполняются различные преобразования данных. Здесь данные обрабатываются, фильтруются и агрегируются, чтобы получить полезные инсайты и отчеты. То есть это место, где сырые данные превращаются в информацию, готовую для анализа и принятия решений.
Point-in-Time (PIT) — это дополнительные структуры, которые помогают ускорить запросы к данным. Они делают доступ к историческим снимкам данных проще, что важно для анализа трендов.
Bridge Table упрощает навигацию между различными частями модели данных в Data Vault. Она позволяет быстро и эффективно выполнять повторяющиеся запросы, объединяя связанные данные из Hubs и Links. Например, Bridge Table может помочь быстро найти все заказы клиентов по разным регионам, объединяя данные из таблиц клиентов и заказов.
Business Key — уникальный идентификатор, который используется для представления бизнес-сущности. Это основной ориентир для интеграции и анализа данных.
Hash Key — хешированное представление бизнес-ключа. Оно используется для оптимизации запросов и обеспечения консистентности данных.
Surrogate Key — системные идентификаторы, которые уникально идентифицируют записи.
Hash-diff — это столбец, который содержит хешированное значение, созданное из множества других столбцов. Если хоть одно из этих значений изменилось, хеш-значение тоже изменится, что позволяет быстро обнаружить изменения в данных.
Data Vault — это инструмент для организации и анализа данных. Он объединяет лучшие практики и упрощает работу с большими объемами информации. Понимание ключевых понятий, таких как Hub, Link, Satellite, и других, поможет нам в дальнейшем подробнее рассмотреть нюансы самой методологии. До встречи в следующих постах
#dwh
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1👍1
Эра информационного изобилия: как большие данные меняют мир
Задумывались, сколько информации мы производим каждый день? Невероятное количество. Представьте, объем данных в мире удваивается каждые два года.
Это океан информации — от лайков в соцсетях до показаний умных часов. И знаете, интересно, что около 80% всех данных неструктурированы. Но именно в этом хаосе скрывается невероятный потенциал для исследований и инноваций.
Вот несколько примеров из реальной жизни:
1. Умные города: В Лос-Анджелесе система управления трафиком, анализирующая огромные массивы данных, сократила время в пробках на 16%. А в Москве система интеллектуального управления дорожным движением, анализируя данные с более чем 2000 камер и 3700 датчиков, помогла сократить среднее время поездки на 20% с 2012 года.
2. Точные прогнозы погоды: Европейский центр ECMWF ежедневно обрабатывает более 40 миллионов наблюдений. Это делает прогнозы всё более точными, что помогает лучше планировать жизнь и бизнес.
3. Персонализированное обучение: Платформа Knewton, анализируя данные об успеваемости, подстраивается под каждого студента. В итоге результаты студентов улучшились на 18%, а процент отчислений упал на 47%.
4. Финансовые технологии: Сбербанк, используя большие данные, предотвратил мошеннические операции на сумму более 57 млрд рублей в 2020 году.
5. Сельское хозяйство: Использование данных с дронов и спутников помогает фермерам оптимизировать использование удобрений и пестицидов, что приводит к снижению затрат и увеличению урожайности на 10-15%.
Это лишь малая часть вариантов применения больших данных. Примеры выше показывают, как аналитика помогает улучшать эффективность, снижать затраты и повышать качество жизни людей по всему миру.
Хочется добавить, что несмотря на все эти технологические достижения, главными героями информационной революции пока что всё ещё остаемся мы — обычные люди. Именно наше участие и любопытство двигают прогресс вперед🚀
#dwh
Задумывались, сколько информации мы производим каждый день? Невероятное количество. Представьте, объем данных в мире удваивается каждые два года.
Это океан информации — от лайков в соцсетях до показаний умных часов. И знаете, интересно, что около 80% всех данных неструктурированы. Но именно в этом хаосе скрывается невероятный потенциал для исследований и инноваций.
Вот несколько примеров из реальной жизни:
1. Умные города: В Лос-Анджелесе система управления трафиком, анализирующая огромные массивы данных, сократила время в пробках на 16%. А в Москве система интеллектуального управления дорожным движением, анализируя данные с более чем 2000 камер и 3700 датчиков, помогла сократить среднее время поездки на 20% с 2012 года.
2. Точные прогнозы погоды: Европейский центр ECMWF ежедневно обрабатывает более 40 миллионов наблюдений. Это делает прогнозы всё более точными, что помогает лучше планировать жизнь и бизнес.
3. Персонализированное обучение: Платформа Knewton, анализируя данные об успеваемости, подстраивается под каждого студента. В итоге результаты студентов улучшились на 18%, а процент отчислений упал на 47%.
4. Финансовые технологии: Сбербанк, используя большие данные, предотвратил мошеннические операции на сумму более 57 млрд рублей в 2020 году.
5. Сельское хозяйство: Использование данных с дронов и спутников помогает фермерам оптимизировать использование удобрений и пестицидов, что приводит к снижению затрат и увеличению урожайности на 10-15%.
Это лишь малая часть вариантов применения больших данных. Примеры выше показывают, как аналитика помогает улучшать эффективность, снижать затраты и повышать качество жизни людей по всему миру.
Хочется добавить, что несмотря на все эти технологические достижения, главными героями информационной революции пока что всё ещё остаемся мы — обычные люди. Именно наше участие и любопытство двигают прогресс вперед
#dwh
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2❤1
Как lag и lead помогают заглянуть в прошлое и будущее ваших данных
Привет!
Сегодня хочу рассказать про оконные функции lag и lead в SQL. Если кратко: они помогают сравнивать значения между строками.
Например, у вас есть таблица с продажами по дням и вы хотите сравнить сегодняшние продажи со вчерашними. Или увидеть сколько продаж было на следующий день. Здесь и пригодятся функции lag и lead.
Lag смотрит назад, то есть в своём запросе вы можете увидеть то, что было в предыдущей строке. Lead, наоборот, смотрит вперед. С ним вы узнаете, что будет в следующей строке.
Посмотрим на примерах:
Этот запрос покажет вам продажи за текущий день, вчерашний день и следующий день. Всё в одной витрине, красиво и удобно.
Также можно использовать эти функции для расчета разницы между значениями:
Так можно увидеть насколько выросли или упали продажи по сравнению с предыдущим днем.
Что круто, lag и lead можно применять не только к соседним строкам, а можно заглянуть на несколько дней назад или вперед:
Этот запрос покажет продажи за сегодня и за неделю до этого.
Кроме того, lag и lead часто используют для заполнения пропусков в данных. Если у вас нет данных за какой-то день, вы можете взять значение из предыдущего дня (обратите внимание, что пример ниже не бизнесовый, а только для отражения возможностей использования функции):
Теперь вы знаете, как использовать lag и lead. Эти функции помогут лучше понимать ваши данные и находить интересные закономерности.
#sql #оконные_функции
Привет!
Сегодня хочу рассказать про оконные функции lag и lead в SQL. Если кратко: они помогают сравнивать значения между строками.
Например, у вас есть таблица с продажами по дням и вы хотите сравнить сегодняшние продажи со вчерашними. Или увидеть сколько продаж было на следующий день. Здесь и пригодятся функции lag и lead.
Lag смотрит назад, то есть в своём запросе вы можете увидеть то, что было в предыдущей строке. Lead, наоборот, смотрит вперед. С ним вы узнаете, что будет в следующей строке.
Посмотрим на примерах:
SELECT
sales_dt,
sales_amount,
LAG(sales_amount) OVER (ORDER BY sales_dt) AS sales_previous_day,
LEAD(sales_amount) OVER (ORDER BY sales_dt) AS sales_next_day
FROM sales_daily;
Этот запрос покажет вам продажи за текущий день, вчерашний день и следующий день. Всё в одной витрине, красиво и удобно.
Также можно использовать эти функции для расчета разницы между значениями:
SELECT
sales_dt,
sales_amount,
sales_amount - LAG(sales) OVER (ORDER BY sales_dt) AS sales_change_daily
FROM sales_daily;
Так можно увидеть насколько выросли или упали продажи по сравнению с предыдущим днем.
Что круто, lag и lead можно применять не только к соседним строкам, а можно заглянуть на несколько дней назад или вперед:
SELECT
sales_dt,
sales_amount,
LAG(sales_amount, 7) OVER (ORDER BY sales_dt) AS sales_week_ago
FROM sales_daily;
Этот запрос покажет продажи за сегодня и за неделю до этого.
Кроме того, lag и lead часто используют для заполнения пропусков в данных. Если у вас нет данных за какой-то день, вы можете взять значение из предыдущего дня (обратите внимание, что пример ниже не бизнесовый, а только для отражения возможностей использования функции):
SELECT
sales_dt,
COALESCE(sales_amount, LAG(sales) OVER (ORDER BY sales_dt)) AS sales_filled
FROM sales_daily;
Теперь вы знаете, как использовать lag и lead. Эти функции помогут лучше понимать ваши данные и находить интересные закономерности.
#sql #оконные_функции
❤1✍1
Дайджест статей за май-июнь 🚀
DWH
От идеи до таблицы: моделирование данных шаг за шагом
Ключевые понятия Data Vault
SQL
Как lag и lead помогают заглянуть в прошлое и будущее ваших данных
Документация
Как писать документацию, которую захотят читать
Soft skills и размышления
Повторение — мать учения
Эра информационного изобилия: как большие данные меняют мир
#дайджест
DWH
От идеи до таблицы: моделирование данных шаг за шагом
Ключевые понятия Data Vault
SQL
Как lag и lead помогают заглянуть в прошлое и будущее ваших данных
Документация
Как писать документацию, которую захотят читать
Soft skills и размышления
Повторение — мать учения
Эра информационного изобилия: как большие данные меняют мир
#дайджест
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1
Durability — Устойчивость
Кажется я задолжала вам рассказ о последнем свойстве ACID — устойчивости (durability).
Устойчивость — это гарантия того, что после завершения транзакции данные останутся в базе. Даже если система внезапно выключится или случится какой-то сбой, изменения не пропадут.
Как это работает на практике? Когда транзакция завершается успешно, СУБД физически записывает все изменения. Только после этого транзакция считается завершенной.
Для обеспечения устойчивости базы данных используют разные техники. Одна из них — логирование. Система записывает все изменения в специальный журнал до того, как внести их в основную базу. Если произойдет сбой, СУБД сможет восстановить данные из этого журнала.
Также часто применяют репликацию, т.е. данные копируются на несколько серверов. Если один выйдет из строя, другие продолжат работу.
Устойчивость особенно важна для финансовых систем. Представьте, вы перевели деньги, а потом случился сбой и ваши деньги просто исчезли. Ужасно, правда?
А еще устойчивость=надёжность важна для бизнес-аналитики. Компании полагаются на исторические данные для принятия решений. Если бы данные могли пропасть из-за сбоя, это сильно усложнило бы анализ.
Однако обеспечение устойчивости может замедлять работу системы. Запись на диск и синхронизация реплик требуют времени. Поэтому разработчики всегда ищут баланс между скоростью и надежностью.
Устойчивость — это ключевое свойство для надежных баз данных. Оно гарантирует, что ваши данные в безопасности, что бы ни случилось с системой.
#dwh #acid
Кажется я задолжала вам рассказ о последнем свойстве ACID — устойчивости (durability).
Устойчивость — это гарантия того, что после завершения транзакции данные останутся в базе. Даже если система внезапно выключится или случится какой-то сбой, изменения не пропадут.
Как это работает на практике? Когда транзакция завершается успешно, СУБД физически записывает все изменения. Только после этого транзакция считается завершенной.
Для обеспечения устойчивости базы данных используют разные техники. Одна из них — логирование. Система записывает все изменения в специальный журнал до того, как внести их в основную базу. Если произойдет сбой, СУБД сможет восстановить данные из этого журнала.
Также часто применяют репликацию, т.е. данные копируются на несколько серверов. Если один выйдет из строя, другие продолжат работу.
Устойчивость особенно важна для финансовых систем. Представьте, вы перевели деньги, а потом случился сбой и ваши деньги просто исчезли. Ужасно, правда?
А еще устойчивость=надёжность важна для бизнес-аналитики. Компании полагаются на исторические данные для принятия решений. Если бы данные могли пропасть из-за сбоя, это сильно усложнило бы анализ.
Однако обеспечение устойчивости может замедлять работу системы. Запись на диск и синхронизация реплик требуют времени. Поэтому разработчики всегда ищут баланс между скоростью и надежностью.
Устойчивость — это ключевое свойство для надежных баз данных. Оно гарантирует, что ваши данные в безопасности, что бы ни случилось с системой.
#dwh #acid
Telegram
В мире больших данных
ACID: atomicity, consistency, isolation and durability
Звучит как заклинание, но на самом деле это важнейший набор требований к работе с данными, гарантирующий надёжность транзакций.
Рассмотрим ACID обзорно, а в последствии раскроем каждое из понятий, так…
Звучит как заклинание, но на самом деле это важнейший набор требований к работе с данными, гарантирующий надёжность транзакций.
Рассмотрим ACID обзорно, а в последствии раскроем каждое из понятий, так…
❤1👍1
Наведите порядок в данных: кратко про нормальные формы
Сегодня поговорим о нормальных формах и нормализации. Это важные понятия в мире баз данных, они помогают нам правильно организовывать информацию.
Представьте базу данных в виде большого шкафа для хранения информации. Без правильной организации найти нужные данные будет сложно, как и отыскать конкретную вещь в разбросанном хаосе. Нормализация — это процесс систематизации данных, схожий с наведением порядка в шкафу, но применительно к информации.
Нормальные формы — это набор правил, помогающих структурировать данные оптимальным образом. Существует несколько уровней нормальных форм, каждый из которых улучшает организацию базы данных.
Первая нормальная форма (1NF) устанавливает базовое правило: "Одна ячейка — один факт". Это означает, что нельзя хранить множественные значения в одном поле. Например, контактные номера клиента должны храниться в отдельных записях или столбцах, а не списком в одной ячейке.
Вторая нормальная форма (2NF) развивает эту идею дальше. Она требует, чтобы все неключевые атрибуты зависели от полного первичного ключа, а не от его части. Это похоже на разделение шкафа на секции по типам одежды.
Третья нормальная форма (3NF) вводит дополнительное требование: атрибуты, не зависящие напрямую от первичного ключа, должны быть вынесены в отдельные таблицы. Это помогает избежать избыточности данных и экономит пространство.
Существуют и более высокие нормальные формы о которых стоит поговорить отдельно.
Основная цель нормализации заключается в следующем:
— Минимизация дублирования данных, что снижает риск ошибок и несоответствий.
— Упрощение процесса обновления информации. Централизованное хранение данных облегчает их модификацию.
— Повышение понятности структуры базы данных, что упрощает ее поддержку и развитие.
Исследования показывают, что корректно нормализованные базы данных могут обеспечить экономию до 30% дискового пространства. Это особенно актуально для крупномасштабных систем.
Важно отметить, что нормализация — это не одноразовое мероприятие, а непрерывный процесс. По мере роста и эволюции бизнеса структуру данных необходимо периодически пересматривать и оптимизировать.
Таким образом, при работе с базами данных всегда следует учитывать принципы нормальных форм. Это позволит создать более эффективную и удобную в использовании систему хранения и обработки информации. Чуть позже рассмотрим различные нормальные формы на примерах.
#dwh #databasedesign
Сегодня поговорим о нормальных формах и нормализации. Это важные понятия в мире баз данных, они помогают нам правильно организовывать информацию.
Представьте базу данных в виде большого шкафа для хранения информации. Без правильной организации найти нужные данные будет сложно, как и отыскать конкретную вещь в разбросанном хаосе. Нормализация — это процесс систематизации данных, схожий с наведением порядка в шкафу, но применительно к информации.
Нормальные формы — это набор правил, помогающих структурировать данные оптимальным образом. Существует несколько уровней нормальных форм, каждый из которых улучшает организацию базы данных.
Первая нормальная форма (1NF) устанавливает базовое правило: "Одна ячейка — один факт". Это означает, что нельзя хранить множественные значения в одном поле. Например, контактные номера клиента должны храниться в отдельных записях или столбцах, а не списком в одной ячейке.
Вторая нормальная форма (2NF) развивает эту идею дальше. Она требует, чтобы все неключевые атрибуты зависели от полного первичного ключа, а не от его части. Это похоже на разделение шкафа на секции по типам одежды.
Третья нормальная форма (3NF) вводит дополнительное требование: атрибуты, не зависящие напрямую от первичного ключа, должны быть вынесены в отдельные таблицы. Это помогает избежать избыточности данных и экономит пространство.
Существуют и более высокие нормальные формы о которых стоит поговорить отдельно.
Основная цель нормализации заключается в следующем:
— Минимизация дублирования данных, что снижает риск ошибок и несоответствий.
— Упрощение процесса обновления информации. Централизованное хранение данных облегчает их модификацию.
— Повышение понятности структуры базы данных, что упрощает ее поддержку и развитие.
Исследования показывают, что корректно нормализованные базы данных могут обеспечить экономию до 30% дискового пространства. Это особенно актуально для крупномасштабных систем.
Важно отметить, что нормализация — это не одноразовое мероприятие, а непрерывный процесс. По мере роста и эволюции бизнеса структуру данных необходимо периодически пересматривать и оптимизировать.
Таким образом, при работе с базами данных всегда следует учитывать принципы нормальных форм. Это позволит создать более эффективную и удобную в использовании систему хранения и обработки информации. Чуть позже рассмотрим различные нормальные формы на примерах.
#dwh #databasedesign
❤1
Системный анализ: от хаоса к пониманию через качественные требования
На Хабре вышла неплохая, но немного хаотичная статья про важность качественных требований в системном анализе и их влияние на итоговый продукт. Ведь работа системного аналитика — это не только понимание данных, архитектуры хранилища и умение писать SQL-запросы. Немалую часть времени занимает общение со всеми участниками процессов и создание грамотной документации.
Техническое задание — один из ключевых документов в работе системного аналитика. Бизнес-заказчики редко приходят с кристально ясным видением своей идеи. Задача аналитика — превратить эти размытые образы в четкий план действий.
Процесс сбора и уточнения требований — это настоящее искусство. Оно требует терпения, внимательности и умения задавать правильные вопросы. Каждый упущенный нюанс может обернуться часами лишней работы или, что еще хуже, разочарованием заказчика.
Четкие требования — основа успешного проекта.
В статье же раскрыты такие важные моменты при работе с требованиями, как:
1. Цель аналитика: обеспечить удовлетворенность конечного пользователя через точные и понятные требования.
2. Качество требований: что такое качество и как его можно повысить для улучшения требований.
3. Типы мышления: какие из них своейственны для системного аналитика.
4. Важность ясности мышления и его развития.
5. Роль саморевью: постоянное саморевью и ревью коллег для улучшения требований.
6. Обратная связь: активное взаимодействие с коллегами и заказчиками для уточнения и улучшения требований.
В статье подчёркивается: для повышения качества своей работы, системному аналитику стоит развивать различные типы мышления, следить за своим состоянием и практиковать управление знаниями.
Сочетание ясного мышления и умения формулировать четкие требования — это не просто профессиональные навыки, а настоящее искусство. С их помощью можно гораздо легче создавать продукты и формировать процессы, которые радуют пользователей и приносят пользу бизнесу.
#системный_анализ #документация
На Хабре вышла неплохая, но немного хаотичная статья про важность качественных требований в системном анализе и их влияние на итоговый продукт. Ведь работа системного аналитика — это не только понимание данных, архитектуры хранилища и умение писать SQL-запросы. Немалую часть времени занимает общение со всеми участниками процессов и создание грамотной документации.
Техническое задание — один из ключевых документов в работе системного аналитика. Бизнес-заказчики редко приходят с кристально ясным видением своей идеи. Задача аналитика — превратить эти размытые образы в четкий план действий.
Процесс сбора и уточнения требований — это настоящее искусство. Оно требует терпения, внимательности и умения задавать правильные вопросы. Каждый упущенный нюанс может обернуться часами лишней работы или, что еще хуже, разочарованием заказчика.
Четкие требования — основа успешного проекта.
В статье же раскрыты такие важные моменты при работе с требованиями, как:
1. Цель аналитика: обеспечить удовлетворенность конечного пользователя через точные и понятные требования.
2. Качество требований: что такое качество и как его можно повысить для улучшения требований.
3. Типы мышления: какие из них своейственны для системного аналитика.
4. Важность ясности мышления и его развития.
5. Роль саморевью: постоянное саморевью и ревью коллег для улучшения требований.
6. Обратная связь: активное взаимодействие с коллегами и заказчиками для уточнения и улучшения требований.
В статье подчёркивается: для повышения качества своей работы, системному аналитику стоит развивать различные типы мышления, следить за своим состоянием и практиковать управление знаниями.
Сочетание ясного мышления и умения формулировать четкие требования — это не просто профессиональные навыки, а настоящее искусство. С их помощью можно гораздо легче создавать продукты и формировать процессы, которые радуют пользователей и приносят пользу бизнесу.
#системный_анализ #документация
❤1
Как схема "звезда" упрощает работу с данными
Помните, мы обсуждали методологию Кимбалла? Так вот, ключевой элемент этого подхода — схема типа "звезда" (Star Schema). Давайте разберемся, что это такое и почему она так важна.
Схема "звезда" — это способ организации данных в хранилище. Она состоит из двух основных элементов: центральной таблицы фактов и окружающих ее таблиц измерений (но на самом деле есть ещё и справочники).
Таблица фактов (Fact Table) — это сердце схемы. В ней хранятся количественные показатели бизнеса. Например, показатели продаж или отдельные транзакции. Часто это очень большие таблицы, с миллионами строк и множеством различных столбцов.
Таблицы измерений (Dimension Tables) — "спутники" центральной таблицы. Они содержат атрибуты, которые описывают бизнес-объекты. Например, подробные данные о клиентах и товарах.
Таблица фактов связана с каждой таблицей измерений с помощью отношения первичный-внешний ключ.
Конечно же, фактов может быть множество, как и измерений.
Такая структура имеет несколько преимуществ:
+ Простота понимания. Даже неспециалист легко поймет, как устроены данные. Это упрощает работу аналитиков и менеджеров.
+ Скорость запросов. Благодаря простой структуре, запросы выполняются быстрее. Не нужно делать множество сложных соединений между таблицами.
+ Гибкость. Добавить новое измерение или факт довольно просто. Это позволяет быстро адаптироваться к изменениям в бизнесе.
Однако у этой схемы есть и недостатки:
- Избыточность данных. Денормализация приводит к дублированию информации.
- Проблемы с обновлением информации в таблицах измерений. При изменениях данных требуется обновлять множество записей.
Давайте рассмотрим простой пример.
Финансовая организация использует схему "звезда" для анализа транзакций: таблица фактов содержит данные о транзакциях, а таблицы измерений — информацию о клиентах и типах транзакций.
Таблица фактов:
Транзакции: ID транзакции, Дата, ID клиента, сумма, ID типа транзакции.
Таблицы измерений:
Клиенты: ID клиента, Имя, Дата рождения, Пол, Адрес.
Тип транзакции: ID типа транзакции, Наименование, Дата добавления.
Хочу заметить, что в современных системах хранения данных схемой "звезда" редко пользуются в чистом виде. Чаще всего она адаптируется и комбинируется с другими подходами, подстраиваясь под специфические потребности бизнеса. Например, Data Vault используется для построения оперативного хранилища данных, где данные интегрируются и историзируются. А схема "звезда" внедряется на этапе витрин данных (Data Marts) для оптимизации аналитических запросов.
#dwh
Помните, мы обсуждали методологию Кимбалла? Так вот, ключевой элемент этого подхода — схема типа "звезда" (Star Schema). Давайте разберемся, что это такое и почему она так важна.
Схема "звезда" — это способ организации данных в хранилище. Она состоит из двух основных элементов: центральной таблицы фактов и окружающих ее таблиц измерений (но на самом деле есть ещё и справочники).
Таблица фактов (Fact Table) — это сердце схемы. В ней хранятся количественные показатели бизнеса. Например, показатели продаж или отдельные транзакции. Часто это очень большие таблицы, с миллионами строк и множеством различных столбцов.
Таблицы измерений (Dimension Tables) — "спутники" центральной таблицы. Они содержат атрибуты, которые описывают бизнес-объекты. Например, подробные данные о клиентах и товарах.
Таблица фактов связана с каждой таблицей измерений с помощью отношения первичный-внешний ключ.
Конечно же, фактов может быть множество, как и измерений.
Такая структура имеет несколько преимуществ:
+ Простота понимания. Даже неспециалист легко поймет, как устроены данные. Это упрощает работу аналитиков и менеджеров.
+ Скорость запросов. Благодаря простой структуре, запросы выполняются быстрее. Не нужно делать множество сложных соединений между таблицами.
+ Гибкость. Добавить новое измерение или факт довольно просто. Это позволяет быстро адаптироваться к изменениям в бизнесе.
Однако у этой схемы есть и недостатки:
- Избыточность данных. Денормализация приводит к дублированию информации.
- Проблемы с обновлением информации в таблицах измерений. При изменениях данных требуется обновлять множество записей.
Давайте рассмотрим простой пример.
Финансовая организация использует схему "звезда" для анализа транзакций: таблица фактов содержит данные о транзакциях, а таблицы измерений — информацию о клиентах и типах транзакций.
Таблица фактов:
Транзакции: ID транзакции, Дата, ID клиента, сумма, ID типа транзакции.
Таблицы измерений:
Клиенты: ID клиента, Имя, Дата рождения, Пол, Адрес.
Тип транзакции: ID типа транзакции, Наименование, Дата добавления.
Хочу заметить, что в современных системах хранения данных схемой "звезда" редко пользуются в чистом виде. Чаще всего она адаптируется и комбинируется с другими подходами, подстраиваясь под специфические потребности бизнеса. Например, Data Vault используется для построения оперативного хранилища данных, где данные интегрируются и историзируются. А схема "звезда" внедряется на этапе витрин данных (Data Marts) для оптимизации аналитических запросов.
#dwh
❤1
Data Vault: революция в организации корпоративных хранилищ данных
Теперь, когда мы разобрались с основными терминами Data Vault, давайте рассмотрим, как эта методология работает. Она сочетает в себе уже знакомую вам "звезду" и 3-ю нормальную форму (о которой я подробно ещё здесь не написала😁 ).
Методологию разработал Дэн Линстедт в 2000 году, и это стало настоящим прорывом в организации корпоративных хранилищ. Его целью было создать метод, сочетающий гибкость Кимбалла и надежность Инмона. И у него получилось!
Сегодня существует две версии Data Vault: 1.0 и 2.0. Различия между ними мы обсудим в следующих статьях, а сейчас осветим общие моменты.
Data Vault помогает справиться с проблемами, которые часто возникают при работе с большими объемами информации из разных источников.
Когда новые данные попадают в хранилище (про ETL-ELT проговорим ещё раз позже), они распределяются по Hub, Link и Satellite таблицам. Хабах хранят только уникальные бизнес-ключи. В Линках — связи между хабами, а в Сателлитах содержатся атрибуты, описывающие хабы и линки.
Главная фишка Data Vault — его гибкость. Вы можете добавлять новые данные, не ломая то, что уже построено.
Также Data Vault отлично справляется с хранением истории изменений. Вы всегда можете "отмотать" данные назад и увидеть, как они выглядели в любой момент времени. Это особенно полезно для анализа трендов или аудита.
Для аналитиков Data Vault — настоящий подарок. Он позволяет быстро получать нужную информацию, комбинируя данные из разных источников. Например, можно легко связать данные с рекламы, посещения сайта, продажи и информацию о себестоимости для глубокого анализа.
Но у Data Vault есть и свои сложности. Его внедрение требует тщательного планирования и может занять много времени. Дело в том, что Data Vault использует концепцию "бизнес-ключей" вместо суррогатных ключей, что позволяет легко интегрировать данные из разных систем. Но при этом очень усложняет первоначальное проектирование. Поэтому очень важны специалисты, которые хорошо понимают эту методологию (иначе беды не избежать😈 ).
Методология особенно эффективна для больших компаний с множеством разнородных источников данных. Она помогает создать единую "версию правды" для всей организации.
Data Vault — сложный, но крутой инструмент для работы с информацией, который помогает бизнесу стать более гибким и основанным на данных.
#dwh
Теперь, когда мы разобрались с основными терминами Data Vault, давайте рассмотрим, как эта методология работает. Она сочетает в себе уже знакомую вам "звезду" и 3-ю нормальную форму (о которой я подробно ещё здесь не написала
Методологию разработал Дэн Линстедт в 2000 году, и это стало настоящим прорывом в организации корпоративных хранилищ. Его целью было создать метод, сочетающий гибкость Кимбалла и надежность Инмона. И у него получилось!
Сегодня существует две версии Data Vault: 1.0 и 2.0. Различия между ними мы обсудим в следующих статьях, а сейчас осветим общие моменты.
Data Vault помогает справиться с проблемами, которые часто возникают при работе с большими объемами информации из разных источников.
Когда новые данные попадают в хранилище (про ETL-ELT проговорим ещё раз позже), они распределяются по Hub, Link и Satellite таблицам. Хабах хранят только уникальные бизнес-ключи. В Линках — связи между хабами, а в Сателлитах содержатся атрибуты, описывающие хабы и линки.
Главная фишка Data Vault — его гибкость. Вы можете добавлять новые данные, не ломая то, что уже построено.
Также Data Vault отлично справляется с хранением истории изменений. Вы всегда можете "отмотать" данные назад и увидеть, как они выглядели в любой момент времени. Это особенно полезно для анализа трендов или аудита.
Для аналитиков Data Vault — настоящий подарок. Он позволяет быстро получать нужную информацию, комбинируя данные из разных источников. Например, можно легко связать данные с рекламы, посещения сайта, продажи и информацию о себестоимости для глубокого анализа.
Но у Data Vault есть и свои сложности. Его внедрение требует тщательного планирования и может занять много времени. Дело в том, что Data Vault использует концепцию "бизнес-ключей" вместо суррогатных ключей, что позволяет легко интегрировать данные из разных систем. Но при этом очень усложняет первоначальное проектирование. Поэтому очень важны специалисты, которые хорошо понимают эту методологию (иначе беды не избежать
Методология особенно эффективна для больших компаний с множеством разнородных источников данных. Она помогает создать единую "версию правды" для всей организации.
Data Vault — сложный, но крутой инструмент для работы с информацией, который помогает бизнесу стать более гибким и основанным на данных.
#dwh
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
В мире больших данных
Ключевые понятия Data Vault
Что ж, мы уже познакомились с Кимбаллом и Инмоном, теперь пора рассказать про Data Vault. Для начала разберем основные термины, которые нужно понимать.
Data Vault — это методология для работы с данными, объединяющая лучшие практики.…
Что ж, мы уже познакомились с Кимбаллом и Инмоном, теперь пора рассказать про Data Vault. Для начала разберем основные термины, которые нужно понимать.
Data Vault — это методология для работы с данными, объединяющая лучшие практики.…
❤1
Дайджест статей за июль 🚀
DWH
Наведите порядок в данных: кратко про нормальные формы
Как схема "звезда" упрощает работу с данными
Data Vault: революция в организации корпоративных хранилищ данных
БД
Durability — Устойчивость
Системный анализ
Системный анализ: от хаоса к пониманию через качественные требования
#дайджест
DWH
Наведите порядок в данных: кратко про нормальные формы
Как схема "звезда" упрощает работу с данными
Data Vault: революция в организации корпоративных хранилищ данных
БД
Durability — Устойчивость
Системный анализ
Системный анализ: от хаоса к пониманию через качественные требования
#дайджест
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
В мире больших данных
Наведите порядок в данных: кратко про нормальные формы
Сегодня поговорим о нормальных формах и нормализации. Это важные понятия в мире баз данных, они помогают нам правильно организовывать информацию.
Представьте базу данных в виде большого шкафа для хранения…
Сегодня поговорим о нормальных формах и нормализации. Это важные понятия в мире баз данных, они помогают нам правильно организовывать информацию.
Представьте базу данных в виде большого шкафа для хранения…
👍3❤1✍1
1 и 2 НФ: первые шаги к упорядоченным данным
Совсем недавно я рассказывала про нормализацию, а сегодня хочу с примерами поговорить о первой (1НФ) и второй (2НФ) нормальных формах. Это базовые правила организации данных в таблицах, которые помогают избежать путаницы и дублирования информации.
Начнем с 1НФ.
Представьте, что у вас есть таблица с данными о студентах и их курсах. И в одной ячейке вы храните несколько курсов через запятую. Это нарушает 1НФ.
Пример таблицы, нарушающей 1НФ (таблицы могут некорректно отображаться на небольших телефонах🥲 смотрите в горизонтальной ориентации):
Чтобы привести таблицу к 1НФ, нужно:
— Убрать повторяющиеся группы значений из отдельных ячеек
— Создать отдельную запись для каждого значения в исходной или новой связанной таблице
— Определить уникальный первичный ключ для каждой таблицы
Пример таблиц, приведенных к 1НФ:
Теперь таблицы приведены к 1НФ, и данные структурированы таким образом, чтобы избежать дублей и обеспечить целостность данных.
2НФ строится на основе 1НФ.
Здесь главное избавиться от частичных зависимостей. Например, если у вас есть таблица "student_courses" с составным ключом из student_id и course_id, а поле "student_name" зависит только от student_id — это нарушение 2НФ.
Пример таблицы, нарушающей 2НФ:
Чтобы привести к 2НФ:
— Выделите зависимые атрибуты в отдельную таблицу
— Свяжите новую таблицу с исходной через первичный ключ
Пример таблиц, приведенных к 2НФ:
Теперь данные о студентах будут в отдельной таблице. Это уменьшит избыточность и упростит анализ информации.
Применение 1НФ и 2НФ помогает:
+ Улучшить целостность данных
+ Уменьшить избыточность
+ Упростить обновление информации
Помните, нормализация — это непрерывный процесс.
Также стоит отметить, что современные системы управления базами данных (СУБД) часто автоматизируют процесс нормализации. Например, PostgreSQL с версии 10 предлагает функции для автоматической нормализации таблиц. Но не все и не всегда ими пользуются, и не везде это работает корректно😁 так что понимать основы нужно обязательно.
В следующий раз уделим немного внимания 3НФ.
А вы применяете нормализацию в своих проектах? Какие сложности встречали?
#dwh
Совсем недавно я рассказывала про нормализацию, а сегодня хочу с примерами поговорить о первой (1НФ) и второй (2НФ) нормальных формах. Это базовые правила организации данных в таблицах, которые помогают избежать путаницы и дублирования информации.
Начнем с 1НФ.
Отношение находится в 1НФ, если все его атрибуты являются простыми, все используемые домены должны содержать только скалярные значения. Не должно быть повторений строк в таблице.
Представьте, что у вас есть таблица с данными о студентах и их курсах. И в одной ячейке вы храните несколько курсов через запятую. Это нарушает 1НФ.
Пример таблицы, нарушающей 1НФ (таблицы могут некорректно отображаться на небольших телефонах
| student_id | student_name | courses |
|------------|--------------|---------------------|
| 1 | Иван | Математика, Физика |
| 2 | Марья | Химия, Биология |
Чтобы привести таблицу к 1НФ, нужно:
— Убрать повторяющиеся группы значений из отдельных ячеек
— Создать отдельную запись для каждого значения в исходной или новой связанной таблице
— Определить уникальный первичный ключ для каждой таблицы
Пример таблиц, приведенных к 1НФ:
| student_id | student_name |
|------------|--------------|
| 1 | Иван |
| 2 | Марья |
| student_id | course |
|------------|--------------|
| 1 | Математика |
| 1 | Физика |
| 2 | Химия |
| 2 | Биология |
Теперь таблицы приведены к 1НФ, и данные структурированы таким образом, чтобы избежать дублей и обеспечить целостность данных.
2НФ строится на основе 1НФ.
Отношение находится во 2НФ, если оно находится в 1НФ и каждый не ключевой атрибут неприводимо зависит от Первичного Ключа.
Здесь главное избавиться от частичных зависимостей. Например, если у вас есть таблица "student_courses" с составным ключом из student_id и course_id, а поле "student_name" зависит только от student_id — это нарушение 2НФ.
Пример таблицы, нарушающей 2НФ:
| student_id | course_id | student_name | grade |
|------------|-----------|--------------|-------|
| 1 | 101 | Иван | 5 |
| 1 | 102 | Иван | 4 |
| 2 | 101 | Мария | 3 |
Чтобы привести к 2НФ:
— Выделите зависимые атрибуты в отдельную таблицу
— Свяжите новую таблицу с исходной через первичный ключ
Пример таблиц, приведенных к 2НФ:
| student_id | student_name |
|------------|--------------|
| 1 | Иван |
| 2 | Мария |
| student_id | course_id | grade |
|------------|-----------|-------|
| 1 | 101 | 5 |
| 1 | 102 | 4 |
| 2 | 101 | 3 |
Теперь данные о студентах будут в отдельной таблице. Это уменьшит избыточность и упростит анализ информации.
Применение 1НФ и 2НФ помогает:
+ Улучшить целостность данных
+ Уменьшить избыточность
+ Упростить обновление информации
Помните, нормализация — это непрерывный процесс.
Также стоит отметить, что современные системы управления базами данных (СУБД) часто автоматизируют процесс нормализации. Например, PostgreSQL с версии 10 предлагает функции для автоматической нормализации таблиц. Но не все и не всегда ими пользуются, и не везде это работает корректно
В следующий раз уделим немного внимания 3НФ.
А вы применяете нормализацию в своих проектах? Какие сложности встречали?
#dwh
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2👍2🤝1
Ранжирующие функции в SQL: как создавать рейтинги и топы
Привет! Сегодня поговорим о ранжирующих оконных функциях в SQL. С ними вы легко сможете находить лучшие продукты, оценивать эффективность сотрудников или составлять списки топовых клиентов.
Ранжирующие функции — это особый вид оконок. Они присваивают каждой строке таблицы номер (ранг) в рамках группы данных, определенной оператором OVER(). Этот номер может быть уникальным или учитывать равенство значений в строках.
В SQL есть три основные ранжирующие функции:
- ROW_NUMBER() или простая нумерация — присваивает уникальный номер каждой строке. Даже если значения в строках одинаковы, номера будут различаться.
- RANK() или ранжирование с пропусками — присваивает одинаковый ранг строкам с одинаковыми значениями. Следующая строка получает номер с пропуском на количество одинаковых значений (т.е., например, 1 1 1 4). Можно использовать, когда важно показать, сколько объектов находится выше по рейтингу.
- DENSE_RANK() или ранжирование без пропусков — похожа на RANK(), но не пропускает номера. Если несколько строк имеют одинаковый ранг, следующая строка получит номер, идущий непосредственно за ними (1 1 1 2). Пригодится для создания категорий или групп на основе значений.
Пример ранжирования с пропусками:
Результат:
Если нужна нумерация внутри групп, необходимо скомбинировать ранжирующие функции с
Функция присваивает ранг каждой строке в пределах группы (категории). Если две строки имеют одинаковое значение sales_amount, они получат одинаковый ранг, а следующая строка пропустит номер и возьмёт следующий. Не понятно?) Посмотрим на примере вывода:
Ранжирующие функции полезны, если нужно создавать рейтинги или анализировать данные с учетом их позиции в наборе. Например, если нужно найти первую строчку в группе, определить топ-продавцов, сравнить позиции или ранжировать сотрудников по их результатам. Эти функции помогают решать задачи быстрее и проще, чем с использованием сложных подзапросов.
В следующих статьях мы разберем каждую функцию подробнее и посмотрим на более сложные примеры их применения. А пока попробуйте применить их к своим данным😉
#sql #оконные_функции
Привет! Сегодня поговорим о ранжирующих оконных функциях в SQL. С ними вы легко сможете находить лучшие продукты, оценивать эффективность сотрудников или составлять списки топовых клиентов.
Ранжирующие функции — это особый вид оконок. Они присваивают каждой строке таблицы номер (ранг) в рамках группы данных, определенной оператором OVER(). Этот номер может быть уникальным или учитывать равенство значений в строках.
В SQL есть три основные ранжирующие функции:
- ROW_NUMBER() или простая нумерация — присваивает уникальный номер каждой строке. Даже если значения в строках одинаковы, номера будут различаться.
- RANK() или ранжирование с пропусками — присваивает одинаковый ранг строкам с одинаковыми значениями. Следующая строка получает номер с пропуском на количество одинаковых значений (т.е., например, 1 1 1 4). Можно использовать, когда важно показать, сколько объектов находится выше по рейтингу.
- DENSE_RANK() или ранжирование без пропусков — похожа на RANK(), но не пропускает номера. Если несколько строк имеют одинаковый ранг, следующая строка получит номер, идущий непосредственно за ними (1 1 1 2). Пригодится для создания категорий или групп на основе значений.
Пример ранжирования с пропусками:
SELECT
product_name,
sales_amount,
DENSE_RANK() OVER (ORDER BY sales_amount DESC) AS sales_rank
FROM product_sales;
Результат:
| product_name | sales_amount | sales_rank |
|--------------|--------------|------------|
| iPhone | 100000 | 1 |
| MacBook | 100000 | 1 |
| AirPods | 80000 | 2 |
| iPad | 60000 | 3 |
Если нужна нумерация внутри групп, необходимо скомбинировать ранжирующие функции с
PARTITION BY. Например, разобъём данные на группы по категориям:
SELECT
category,
product_name,
sales_amount,
RANK() OVER (PARTITION BY category ORDER BY sales_amount DESC) AS category_rank
FROM product_sales;
Функция присваивает ранг каждой строке в пределах группы (категории). Если две строки имеют одинаковое значение sales_amount, они получат одинаковый ранг, а следующая строка пропустит номер и возьмёт следующий. Не понятно?) Посмотрим на примере вывода:
| category | product_name | sales_amount | category_rank |
|----------|----------------|--------------|---------------|
| Phones | iPhone 13 | 150000 | 1 |
| Phones | Galaxy S21 | 130000 | 2 |
| Phones | Pixel 6 | 130000 | 2 |
| Phones | OnePlus 9 | 90000 | 4 |
| Laptops | MacBook Pro | 200000 | 1 |
| Laptops | Dell XPS | 180000 | 2 |
| Laptops | ThinkPad X1 | 150000 | 3 |
| Laptops | MateBook 14 | 150000 | 3 |
Ранжирующие функции полезны, если нужно создавать рейтинги или анализировать данные с учетом их позиции в наборе. Например, если нужно найти первую строчку в группе, определить топ-продавцов, сравнить позиции или ранжировать сотрудников по их результатам. Эти функции помогают решать задачи быстрее и проще, чем с использованием сложных подзапросов.
В следующих статьях мы разберем каждую функцию подробнее и посмотрим на более сложные примеры их применения. А пока попробуйте применить их к своим данным
#sql #оконные_функции
Please open Telegram to view this post
VIEW IN TELEGRAM
👨💻2❤1✍1
Путешествие по миру современных баз данных
Хочу рассказать о современных базах данных. Мир баз данных постоянно развивается, и сейчас у нас есть целый арсенал инструментов для различных целей. Разберемся с некоторыми из них.
Реляционные базы данных (RDBMS) — это классический вид, основанный на табличной модели. Идеальны для структурированной информации с четкими связями. Н-р, для банковских систем или управления заказами в интернет-магазине.
Фишка: поддерживают сложные запросы и гарантируют целостность данных.
Согласно отчету DB-Engines Ranking на сегодня, Oracle, MySQL и MS SQL остаются самыми популярными СУБД в мире.
══════════
NoSQL — предлагает подходы, отличные от стандартного реляционного шаблона. Они появились, когда стало ясно, что не все данные удобно хранить в таблицах. Эти СУБД бывают документоориентированные (MongoDB), ключ-значение (Redis), графовые (Neo4j). Они часто используются в веб-приложениях, системах реального времени или для работы с большими данными.
Фишка: легко масштабируются и быстро обрабатывают большие объемы данных.
MongoDB — самая популярная NoSQL база среди разработчиков по данным Stack Overflow Developer Survey 2023.
══════════
Колоночные базы данных — в них данные также организованы в таблицы, но хранятся по столбцам, а не по строкам. Отлично подходят для аналитики с большими объемами данных.
Фишка: молниеносно обрабатывают аналитические запросы на терабайтах данных.
Примеры таких СУБД: ClickHouse, Google BigQuery, Apache Cassandra.
══════════
NewSQL базы данных наследуют реляционную структуру и семантику, но построены с использованием более современных, масштабируемых конструкций, обеспечивая высокую масштабируемость и согласованность данных.
Фишка: могут обрабатывать тысячи транзакций в секунду, сохраняя при этом ACID-свойства.
Популярные системы: CockroachDB, Google Spanner, VoltDB. Они хорошо подходят для приложений, которым нужна высокая доступность и горизонтальная масштабируемость.
══════════
Многомодельные базы данных поддерживают несколько моделей данных в рамках одной системы. Они упрощают разработку сложных приложений, где нужны разные типы данных и связей между ними.
Фишка: позволяют использовать одну базу данных вместо нескольких, упрощая архитектуру приложения.
Пример: ArangoDB (работает с документами, графами и данные в формате ключ-значение).
══════════
Базы данных на основе блокчейна используют технологию распределенного реестра. Они обеспечивают высокую безопасность и неизменяемость данных.
Фишка: гарантируют прозрачность и защиту от несанкционированных изменений.
Примеры таких баз: BigchainDB, Bluzelle. Они популярны в финтехе, управлении цепочками поставок и других областях, где важна прозрачность и безопасность.
══════════
Хранилища данных и базы данных для аналитики оптимизированы для обработки огромных объемов данных и сложных аналитических запросов.
Фишка: быстро анализируют петабайты данных и предоставляют результаты в удобном виде для бизнес-аналитики и машинного обучения.
Примеры: Snowflake, Amazon Redshift, Google BigQuery.
══════════
In-Memory базы данных хранят данные в оперативной памяти, что обеспечивает молниеносную сверхвысокую скорость работы. Часто используются как кэш или для обработки данных в реальном времени, особенно в приложениях, требующих минимальной задержки.
Фишка: обеспечивают время отклика в микро- или даже наносекундах, что критично для таких приложений, как финансовые системы, системы интернет-рекламы и игровые платформы.
Самые известные представители: Redis, Memcached, SAP HANA (для более сложных аналитических задач), Apache Ignite (для распределенных вычислений и кэширования).
══════════
Как вы можете заметить, некоторые из известных вам СУБД хочется отнести к нескольким видам. И это важно понимать: границы между типами баз данных часто размыты. Многие современные СУБД сочетают черты разных типов, адаптируясь под сложные требования своих клиентов.
Признаюсь честно, пока писала эту статью, узнала о нескольких новых для себя видах. А вы? С чем приходилось работать?😎
#databasedesign #dwh
Хочу рассказать о современных базах данных. Мир баз данных постоянно развивается, и сейчас у нас есть целый арсенал инструментов для различных целей. Разберемся с некоторыми из них.
Реляционные базы данных (RDBMS) — это классический вид, основанный на табличной модели. Идеальны для структурированной информации с четкими связями. Н-р, для банковских систем или управления заказами в интернет-магазине.
Фишка: поддерживают сложные запросы и гарантируют целостность данных.
Согласно отчету DB-Engines Ranking на сегодня, Oracle, MySQL и MS SQL остаются самыми популярными СУБД в мире.
══════════
NoSQL — предлагает подходы, отличные от стандартного реляционного шаблона. Они появились, когда стало ясно, что не все данные удобно хранить в таблицах. Эти СУБД бывают документоориентированные (MongoDB), ключ-значение (Redis), графовые (Neo4j). Они часто используются в веб-приложениях, системах реального времени или для работы с большими данными.
Фишка: легко масштабируются и быстро обрабатывают большие объемы данных.
MongoDB — самая популярная NoSQL база среди разработчиков по данным Stack Overflow Developer Survey 2023.
══════════
Колоночные базы данных — в них данные также организованы в таблицы, но хранятся по столбцам, а не по строкам. Отлично подходят для аналитики с большими объемами данных.
Фишка: молниеносно обрабатывают аналитические запросы на терабайтах данных.
Примеры таких СУБД: ClickHouse, Google BigQuery, Apache Cassandra.
══════════
NewSQL базы данных наследуют реляционную структуру и семантику, но построены с использованием более современных, масштабируемых конструкций, обеспечивая высокую масштабируемость и согласованность данных.
Фишка: могут обрабатывать тысячи транзакций в секунду, сохраняя при этом ACID-свойства.
Популярные системы: CockroachDB, Google Spanner, VoltDB. Они хорошо подходят для приложений, которым нужна высокая доступность и горизонтальная масштабируемость.
══════════
Многомодельные базы данных поддерживают несколько моделей данных в рамках одной системы. Они упрощают разработку сложных приложений, где нужны разные типы данных и связей между ними.
Фишка: позволяют использовать одну базу данных вместо нескольких, упрощая архитектуру приложения.
Пример: ArangoDB (работает с документами, графами и данные в формате ключ-значение).
══════════
Базы данных на основе блокчейна используют технологию распределенного реестра. Они обеспечивают высокую безопасность и неизменяемость данных.
Фишка: гарантируют прозрачность и защиту от несанкционированных изменений.
Примеры таких баз: BigchainDB, Bluzelle. Они популярны в финтехе, управлении цепочками поставок и других областях, где важна прозрачность и безопасность.
══════════
Хранилища данных и базы данных для аналитики оптимизированы для обработки огромных объемов данных и сложных аналитических запросов.
Фишка: быстро анализируют петабайты данных и предоставляют результаты в удобном виде для бизнес-аналитики и машинного обучения.
Примеры: Snowflake, Amazon Redshift, Google BigQuery.
══════════
In-Memory базы данных хранят данные в оперативной памяти, что обеспечивает молниеносную сверхвысокую скорость работы. Часто используются как кэш или для обработки данных в реальном времени, особенно в приложениях, требующих минимальной задержки.
Фишка: обеспечивают время отклика в микро- или даже наносекундах, что критично для таких приложений, как финансовые системы, системы интернет-рекламы и игровые платформы.
Самые известные представители: Redis, Memcached, SAP HANA (для более сложных аналитических задач), Apache Ignite (для распределенных вычислений и кэширования).
══════════
Как вы можете заметить, некоторые из известных вам СУБД хочется отнести к нескольким видам. И это важно понимать: границы между типами баз данных часто размыты. Многие современные СУБД сочетают черты разных типов, адаптируясь под сложные требования своих клиентов.
Признаюсь честно, пока писала эту статью, узнала о нескольких новых для себя видах. А вы? С чем приходилось работать?
#databasedesign #dwh
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2