Как переводится слово "Entity" и слово "Relation" на русский язык в контексте ER-диаграммы? 🔄 Пишите свой выбор в комментариях!
Anonymous Quiz
19%
Entity - Существо, Relation - Связь
80%
Entity - Сущность, Relation - Отношение
0%
Entity - Часть, Relation - Разделение
2%
Entity - Единица, Relation - Взаимодействие
Кто из вас слышал это в своей голове? 👻
😓«Таких аналитиков с такими же скилами как у меня - полный рынок. Конкуренция. Я вряд ли сменю работу.»
😓«Пока я здесь без движения, другие идут вперёд. Смотрю на коллег, и кажется, что я мне никогда не догнать их. Я тупой.»
😓«А если я допущу ошибку, и всё рухнет? Это будет конец моей карьере! Лучше я помолчу, пусть они как-то сами решат, мое слово ничего не решит.»
Наши внутренние критики часто усердствуют, намекая на то, что наши достижения - пустяк, а успехи других - величие. Эти критики без устали анализируют каждый наш шаг, сравнивая нас с окружающими и, как правило, выводят, что другие лучше.
Помните ли вы моменты, когда родители, учителя или друзья ставили вам в пример кого-то другого? "Смотри на Васю, у него всё идеально!" или "Ты и это не можешь?". Это было так обидно! Ведь и ты тоже старался со всей душой.
А что если бы в такие моменты кто-то приговаривал: "Ты потрясающий! Посмотри, сколько ты уже достиг! Я тобой горжусь, это твои лучшие результаты и я вижу, ты способен на большее!!" 💖
Оценил свои небольшие достижения? — устрой праздник и своди себя в ресторан 🎉
Сложная задача на работе не поддалась сразу? — угости себя чем-нибудь вкусным, прогуляйся и вернись к решению чуть позже, на свежую голову 🍦
Всё, что ты делаешь, имеет значение. На ошибки не стоит смотреть как на провал, это шаг к целям. Это опыт. Пробуй. Всё получится. Я в тебя верю.
😓«Таких аналитиков с такими же скилами как у меня - полный рынок. Конкуренция. Я вряд ли сменю работу.»
😓«Пока я здесь без движения, другие идут вперёд. Смотрю на коллег, и кажется, что я мне никогда не догнать их. Я тупой.»
😓«А если я допущу ошибку, и всё рухнет? Это будет конец моей карьере! Лучше я помолчу, пусть они как-то сами решат, мое слово ничего не решит.»
Наши внутренние критики часто усердствуют, намекая на то, что наши достижения - пустяк, а успехи других - величие. Эти критики без устали анализируют каждый наш шаг, сравнивая нас с окружающими и, как правило, выводят, что другие лучше.
Помните ли вы моменты, когда родители, учителя или друзья ставили вам в пример кого-то другого? "Смотри на Васю, у него всё идеально!" или "Ты и это не можешь?". Это было так обидно! Ведь и ты тоже старался со всей душой.
А что если бы в такие моменты кто-то приговаривал: "Ты потрясающий! Посмотри, сколько ты уже достиг! Я тобой горжусь, это твои лучшие результаты и я вижу, ты способен на большее!!" 💖
Оценил свои небольшие достижения? — устрой праздник и своди себя в ресторан 🎉
Сложная задача на работе не поддалась сразу? — угости себя чем-нибудь вкусным, прогуляйся и вернись к решению чуть позже, на свежую голову 🍦
Всё, что ты делаешь, имеет значение. На ошибки не стоит смотреть как на провал, это шаг к целям. Это опыт. Пробуй. Всё получится. Я в тебя верю.
❤32🔥12👍5
Многие из нас слышали термины "БД" и "СУБД", но иногда они путают их, особенно в волнительные моменты собеседований. 🤔
😅«Что такое БД? Это то, что хранит все мои данные, верно?»
😅«СУБД... это как БД, только сложнее? Или это одно и то же?»
😅«Я слышал про MySQL, но это БД или СУБД? Ой, запутался!»
Разберемся! 🧐
БД, или база данных, – это место структурированного хранения информации. Это конкретные данные и структура их хранения в виде таблиц или в виде файлов определенного формата.
БД - огромный шкаф с файлами. Представьте себе шкаф в библиотеке, где каждый ящик – это таблица, а каждая папка в ящике – это запись. Например, в БД "Библиотека" может быть таблица "Книги", где каждая запись – это конкретная книга. 📚
Теперь СУБД! Это система управления базами данных. Если БД – это шкаф, то СУБД – это библиотекарь, который знает, какие папки где лежат, как их добавлять, удалять или изменять.
MySQL, PostgreSQL, Oracle – это примеры СУБД. Они помогают нам работать с нашими "шкафами" (БД).
Так что, когда ты слышишь о MySQL, это СУБД, которая управляет БД! 💡
😅«Что такое БД? Это то, что хранит все мои данные, верно?»
😅«СУБД... это как БД, только сложнее? Или это одно и то же?»
😅«Я слышал про MySQL, но это БД или СУБД? Ой, запутался!»
Разберемся! 🧐
БД, или база данных, – это место структурированного хранения информации. Это конкретные данные и структура их хранения в виде таблиц или в виде файлов определенного формата.
БД - огромный шкаф с файлами. Представьте себе шкаф в библиотеке, где каждый ящик – это таблица, а каждая папка в ящике – это запись. Например, в БД "Библиотека" может быть таблица "Книги", где каждая запись – это конкретная книга. 📚
Теперь СУБД! Это система управления базами данных. Если БД – это шкаф, то СУБД – это библиотекарь, который знает, какие папки где лежат, как их добавлять, удалять или изменять.
MySQL, PostgreSQL, Oracle – это примеры СУБД. Они помогают нам работать с нашими "шкафами" (БД).
Так что, когда ты слышишь о MySQL, это СУБД, которая управляет БД! 💡
👍35
Физическая модель реляционной БД – это финальный чертеж для вашей будущей базы данных. Остаётся только воплотить её в жизнь с помощью SQL-запросов или других полезных инструментов СУБД и готово! 💻 Можно писать логику систему, работать с функциями на получение и хранение данных.
Что показывает физическая модель базы данных:
🔵 таблицы с наименованиями, которые фактически будут БД,
🔵 поля с наименованиями, которые фактически будут БД,
🔵 типы данных и ограничения для полей,
🔵 первичные и внешние ключи,
🔵 обязательность для полей,
🔵 уникальность для полей,
🔵 связи между таблицами и за счет каких полей они реализуются.
Физическая модель дополняет и конкретизирует логическую модель.
Этот навык критически важен для системных аналитиков: понимание физической модели позволяет видеть, как данные будут храниться и использоваться в реальных системах.
Что показывает физическая модель базы данных:
🔵 таблицы с наименованиями, которые фактически будут БД,
🔵 поля с наименованиями, которые фактически будут БД,
🔵 типы данных и ограничения для полей,
🔵 первичные и внешние ключи,
🔵 обязательность для полей,
🔵 уникальность для полей,
🔵 связи между таблицами и за счет каких полей они реализуются.
Физическая модель дополняет и конкретизирует логическую модель.
Этот навык критически важен для системных аналитиков: понимание физической модели позволяет видеть, как данные будут храниться и использоваться в реальных системах.
👍6🔥6❤2
Продолжаем разбираться с физической моделью БД. Переходим к нашему примеру:
🐶 Мы рассматриваем онлайн-зоомагазин "petCo". Мы хотим хранить информацию о товарах для животных.
В логической модели у нас могла бы быть таблица:
▫️Товар
- id - системный идентификатор
- Название
- Тип животного
- Цена
- Описание
- Штрихкод
Теперь, преобразуем это в физическую модель для СУБД PostgreSQL:
▫️Product
- id (UUID, Not Null, Unique)
- name (varchar(128), Not Null)
- pet_type (varchar(64), Not Null)
- price (integer, Not Null, default: 0)
- description (varchar(512))
- barcode (varchar(64), Not Null)
Я уточнила СУБД PostgreSQL, так как ее типы данных я использую для перехода к физической модели.
Понимание как переходить логической к физической модели – это путь к пониманию того, как именно данные будут храниться и обрабатываться в реальной БД.
Работая над физической моделью, аналитики и разработчики объединяют свои усилия. Часто в работе переход от логической к физической модели это задача разработчиков. Особенно договоренности по выбору именования полей и типов данных - их зона ответственности. Бывают крутые дебаты)) И круто, когда можешь твердо аргументировать свою точку зрения!
Знание и понимание физической модели БД помогает аналитику оптимизировать хранение данных, улучшать производительность и экономить серверные ресурсы.
🐶 Мы рассматриваем онлайн-зоомагазин "petCo". Мы хотим хранить информацию о товарах для животных.
В логической модели у нас могла бы быть таблица:
▫️Товар
- id - системный идентификатор
- Название
- Тип животного
- Цена
- Описание
- Штрихкод
Теперь, преобразуем это в физическую модель для СУБД PostgreSQL:
▫️Product
- id (UUID, Not Null, Unique)
- name (varchar(128), Not Null)
- pet_type (varchar(64), Not Null)
- price (integer, Not Null, default: 0)
- description (varchar(512))
- barcode (varchar(64), Not Null)
Я уточнила СУБД PostgreSQL, так как ее типы данных я использую для перехода к физической модели.
Понимание как переходить логической к физической модели – это путь к пониманию того, как именно данные будут храниться и обрабатываться в реальной БД.
Работая над физической моделью, аналитики и разработчики объединяют свои усилия. Часто в работе переход от логической к физической модели это задача разработчиков. Особенно договоренности по выбору именования полей и типов данных - их зона ответственности. Бывают крутые дебаты)) И круто, когда можешь твердо аргументировать свою точку зрения!
Знание и понимание физической модели БД помогает аналитику оптимизировать хранение данных, улучшать производительность и экономить серверные ресурсы.
❤10👍4
Всем привет! 👋
В этот прекрасный воскресный день очень хотим поделиться мемами, которые непредумышленно создают в IT-продуктах 🤯😳
Именно поэтому очень важно, чтобы в команде был аналитик, который учитывает в проектируемом решении не только систему, но и дизайн, и возможные Use cases, и вообще всё! Вот такие мы с вами крутые ребята 🥷💥
В этот прекрасный воскресный день очень хотим поделиться мемами, которые непредумышленно создают в IT-продуктах 🤯😳
Именно поэтому очень важно, чтобы в команде был аналитик, который учитывает в проектируемом решении не только систему, но и дизайн, и возможные Use cases, и вообще всё! Вот такие мы с вами крутые ребята 🥷💥
😁21🔥5👍1
Когда мы говорим о больших объемах данных, производительность запросов становится ключевым моментом. Чтобы ускорить выборку данных из таблицы, мы используем индексы 🌟
Представьте их как оглавление в книге. Вместо того чтобы перебирать каждую страницу, вы можете быстро перейти к нужной вам, зная ее номер.
Для нашего магазина "PetCo" наиболее часто задаваемые запросы могут касаться поиска товара по названию, типу животного или штрихкоду. Создадим для этого индексы:
Теперь, когда запрос будет искать товар по названию или другому индексированному полю, СУБД (например, PostgreSQL) будет использовать индекс для быстрого нахождения записи.
Однако индексы не всегда "бесплатные". Их создание и поддержка требуют дополнительных ресурсов, в том числе по памяти. Поэтому важно уметь балансировать между количеством индексов и необходимостью их использования. Чрезмерное индексирование может замедлить операции создания и обновления записей в БД.
Индексы - мощный инструмент для оптимизации работы с БД. Но как и все мощные инструменты, их следует использовать с осторожностью и пониманием. Для системного аналитика важно знать, когда и как их применять, чтобы обеспечить гармоничное взаимодействие аналитики и разработчиков, а также максимальную производительность системы 🚀
Представьте их как оглавление в книге. Вместо того чтобы перебирать каждую страницу, вы можете быстро перейти к нужной вам, зная ее номер.
Для нашего магазина "PetCo" наиболее часто задаваемые запросы могут касаться поиска товара по названию, типу животного или штрихкоду. Создадим для этого индексы:
CREATE INDEX idx_product_name ON Product(name);
CREATE INDEX idx_product_pet_type ON Product(pet_type);
CREATE INDEX idx_product_barcode ON Product(barcode);Теперь, когда запрос будет искать товар по названию или другому индексированному полю, СУБД (например, PostgreSQL) будет использовать индекс для быстрого нахождения записи.
Однако индексы не всегда "бесплатные". Их создание и поддержка требуют дополнительных ресурсов, в том числе по памяти. Поэтому важно уметь балансировать между количеством индексов и необходимостью их использования. Чрезмерное индексирование может замедлить операции создания и обновления записей в БД.
Индексы - мощный инструмент для оптимизации работы с БД. Но как и все мощные инструменты, их следует использовать с осторожностью и пониманием. Для системного аналитика важно знать, когда и как их применять, чтобы обеспечить гармоничное взаимодействие аналитики и разработчиков, а также максимальную производительность системы 🚀
👍14
Индекс, как и другие функции, зависит от СУБД, и вот почему:
1. Типы индексов:
У разных СУБД могут быть свои уникальные типы индексов. Например, PostgreSQL предлагает B-tree, Hash, GiST, SP-GiST, GIN и BRIN, в то время как другая СУБД может предлагать другой набор типов индексов или даже свои эксклюзивные типы.
2. Оптимизация:
Каждая СУБД имеет свой собственный оптимизатор запросов. Оптимизатор принимает решение о том, когда и как использовать индекс. В разных СУБД этот процесс может отличаться.
3. Создание и обслуживание:
Процесс создания, обновления и удаления индексов может немного отличаться в зависимости от СУБД. Некоторые системы могут автоматически реорганизовать индексы, чтобы поддерживать их эффективность, в то время как другие могут требовать ручного вмешательства.
4. Ресурсные требования:
Индексы могут иметь разное влияние на производительность и потребление ресурсов в разных СУБД. В одной системе индекс может быстро создаваться и требовать небольшого дискового пространства, а в другой — создание индекса может быть более ресурсозатратным.
5. Ограничения и возможности:
В зависимости от СУБД могут быть определенные ограничения на количество индексов, их размер или другие характеристики. Также некоторые СУБД могут предлагать дополнительные возможности, связанные с индексами, например, индексы на выражениях или частичные индексы.
1. Типы индексов:
У разных СУБД могут быть свои уникальные типы индексов. Например, PostgreSQL предлагает B-tree, Hash, GiST, SP-GiST, GIN и BRIN, в то время как другая СУБД может предлагать другой набор типов индексов или даже свои эксклюзивные типы.
2. Оптимизация:
Каждая СУБД имеет свой собственный оптимизатор запросов. Оптимизатор принимает решение о том, когда и как использовать индекс. В разных СУБД этот процесс может отличаться.
3. Создание и обслуживание:
Процесс создания, обновления и удаления индексов может немного отличаться в зависимости от СУБД. Некоторые системы могут автоматически реорганизовать индексы, чтобы поддерживать их эффективность, в то время как другие могут требовать ручного вмешательства.
4. Ресурсные требования:
Индексы могут иметь разное влияние на производительность и потребление ресурсов в разных СУБД. В одной системе индекс может быстро создаваться и требовать небольшого дискового пространства, а в другой — создание индекса может быть более ресурсозатратным.
5. Ограничения и возможности:
В зависимости от СУБД могут быть определенные ограничения на количество индексов, их размер или другие характеристики. Также некоторые СУБД могут предлагать дополнительные возможности, связанные с индексами, например, индексы на выражениях или частичные индексы.
👍7❤2👎1
Последний десяток лет тема инвестиций особенно популярна🏅
Сейчас можно вложиться в:
💸 акции и облигации множество крупных и не очень компаний,
💸 драгоценные металлы,
💸 недвижимость,
💸 стартапы / готовые бизнесы,
и прочее, прочее.
Это всё здорово и очень интересно, это даже работает. Кроме этого, я считаю, что самая важная и необходимая инвестиция — образование 🙌
Наверняка вы смотрели множество американских фильмов. В них часто упоминается тема колледжа и про то, как родители мечтают, чтобы их ребёнок учился в этом заведении. Как они чуть ли не с рождения открывают счёт, чтобы начать копить на учёбу. И я вижу почему. Я наглядно вижу разницу между людьми с образованием и без, абсолютно разный уровень жизни.
На личном опыте я убедилась, что самая надёжная инвестиция — это инвестиции в саморазвитие!
Вложение средства и времени в обучение и развитие навыков — залог моего будущего. Где бы я ни оказалась, в какую страну или город бы не переехала, со мной всегда буду я и мои знания.
Чем больше мы знаем и умеем, тем больше возможностей открывается перед нами.
Конечно, это не означает, что нужно забывать о финансовой стороне вопроса и других сферах жизни. Но если передо мной стоит выбор куда вложить деньги, и на одной из стороне весов обучение, то я делаю выбор в пользу обучения.
Получение качественной информации останется трендом и лучшим стартапом для инвестирования. И стартап тут - наша жизнь, которую мы улучшаем.
Сейчас можно вложиться в:
💸 акции и облигации множество крупных и не очень компаний,
💸 драгоценные металлы,
💸 недвижимость,
💸 стартапы / готовые бизнесы,
и прочее, прочее.
Это всё здорово и очень интересно, это даже работает. Кроме этого, я считаю, что самая важная и необходимая инвестиция — образование 🙌
Наверняка вы смотрели множество американских фильмов. В них часто упоминается тема колледжа и про то, как родители мечтают, чтобы их ребёнок учился в этом заведении. Как они чуть ли не с рождения открывают счёт, чтобы начать копить на учёбу. И я вижу почему. Я наглядно вижу разницу между людьми с образованием и без, абсолютно разный уровень жизни.
На личном опыте я убедилась, что самая надёжная инвестиция — это инвестиции в саморазвитие!
Вложение средства и времени в обучение и развитие навыков — залог моего будущего. Где бы я ни оказалась, в какую страну или город бы не переехала, со мной всегда буду я и мои знания.
Чем больше мы знаем и умеем, тем больше возможностей открывается перед нами.
Конечно, это не означает, что нужно забывать о финансовой стороне вопроса и других сферах жизни. Но если передо мной стоит выбор куда вложить деньги, и на одной из стороне весов обучение, то я делаю выбор в пользу обучения.
Получение качественной информации останется трендом и лучшим стартапом для инвестирования. И стартап тут - наша жизнь, которую мы улучшаем.
🔥8
Иногда системный анализ кажется сложным лабиринтом, где каждый поворот приносит новый вызов.
Но момент, когда все технические детали начинают складываться в единое целое. Тот момент, когда ты вдруг осознаешь, что понимаешь, как работает система, что стоит за каждым нажитием на кнопку, какие запросы в базу данных идут, как работают строки кода... Это вау ❤️🙏 Ты видишь не какие-то отрывки и комбинации непонятных слов. Ты видишь и понимаешь всё.
Сегодня с командой по проектированию БД и SQL, на практической программе GetAnalyst, мы начинаем этот путь с предобучения по небольшим проектам. А дальше в шаг за шагом, задача за задачей будем подробно разбирать особенности проектирования БД, после которых вы осознаете, что технические детали стали друзьями, а не таинственными загадками.
Буквально вчера на созвоне с командой обсуждали, что часть наших текущих учеников сменили работу на пол пути прохождения практических программ. У меня шок. Приятный. Особенно от отзывов, что в работе нужно ровно то, что разбираем сейчас. Это то, что вдохновляет меня!!! И это то, почему мы постоянно стараемся актуализировать всю информацию под текущие запросы компаний.
Благодарю за то, что проходите путь роста и новые проекты вместе со мной и нашей командой ❤️
Но момент, когда все технические детали начинают складываться в единое целое. Тот момент, когда ты вдруг осознаешь, что понимаешь, как работает система, что стоит за каждым нажитием на кнопку, какие запросы в базу данных идут, как работают строки кода... Это вау ❤️🙏 Ты видишь не какие-то отрывки и комбинации непонятных слов. Ты видишь и понимаешь всё.
Сегодня с командой по проектированию БД и SQL, на практической программе GetAnalyst, мы начинаем этот путь с предобучения по небольшим проектам. А дальше в шаг за шагом, задача за задачей будем подробно разбирать особенности проектирования БД, после которых вы осознаете, что технические детали стали друзьями, а не таинственными загадками.
Буквально вчера на созвоне с командой обсуждали, что часть наших текущих учеников сменили работу на пол пути прохождения практических программ. У меня шок. Приятный. Особенно от отзывов, что в работе нужно ровно то, что разбираем сейчас. Это то, что вдохновляет меня!!! И это то, почему мы постоянно стараемся актуализировать всю информацию под текущие запросы компаний.
Благодарю за то, что проходите путь роста и новые проекты вместе со мной и нашей командой ❤️
👍10❤4🔥2🥰2
Привет! Продолжаем разбираться с индексами в БД.
И самый главный вопрос:
ЗАЧЕМ СИСТЕМНОМУ АНАЛИТИКУ ЗНАТЬ ПРО ИНДЕКСЫ В БД И ПОНИМАТЬ ИХ? 🤔
Абсолютно аналогичный вопрос у меня был про SQL. И он до сих пор иногда всплывает в моей голове, но я быстро вспоминаю ответ.
На первый взгляд, может показаться, что такие вопросы более актуальны для разработчиков или администраторов БД. Однако, даже если системный аналитик не занимается написанием запросов или оптимизацией индексов и это выходит за его зону ответственности, знание этих концепций дает прорыв понимании технических особенностей разработки.
Вопросы про индексы в БД и SQL стали актуальными на собеседованиях для системных аналитиков на позиции мидл и выше.
Особенно в таких сферах как банковский сектор. Это становится проверкой компетенции и широты знаний. И это не просто ради галочки.
Понимание индексов позволяет системному аналитику участвовать в дискуссиях с разработчиками на равных, выявлять потенциальные узкие места в проектах и предлагать решения для оптимизации.
По аналогии, умение читать и писать SQL-запросы открывает возможность более глубокого понимания логики работы с базов данных и понимать влияние каждой новой функциональности в системе на общую архитектуру решения.
Также эти навыки не просто делают аналитика "умнее", они делают его более ценным специалистом в команде, способным эффективно сотрудничать на всех этапах разработки: от описания Use Cases до сотрудничества с архитекторами. На собеседованиях это демонстрирует готовность кандидата к комплексному и многогранному подходу в проектировании систем.
Я придерживаюсь подхода "лучше знать, чем возмущаться". Широкий кругозор и умение быстро осваивать новую информацию одни из ключевых компетенций аналитиков.
Сохраняем материал про индексы и добавляем в свой чеклист подготовки к собеседованиям✔️
И самый главный вопрос:
ЗАЧЕМ СИСТЕМНОМУ АНАЛИТИКУ ЗНАТЬ ПРО ИНДЕКСЫ В БД И ПОНИМАТЬ ИХ? 🤔
Абсолютно аналогичный вопрос у меня был про SQL. И он до сих пор иногда всплывает в моей голове, но я быстро вспоминаю ответ.
На первый взгляд, может показаться, что такие вопросы более актуальны для разработчиков или администраторов БД. Однако, даже если системный аналитик не занимается написанием запросов или оптимизацией индексов и это выходит за его зону ответственности, знание этих концепций дает прорыв понимании технических особенностей разработки.
Вопросы про индексы в БД и SQL стали актуальными на собеседованиях для системных аналитиков на позиции мидл и выше.
Особенно в таких сферах как банковский сектор. Это становится проверкой компетенции и широты знаний. И это не просто ради галочки.
Понимание индексов позволяет системному аналитику участвовать в дискуссиях с разработчиками на равных, выявлять потенциальные узкие места в проектах и предлагать решения для оптимизации.
По аналогии, умение читать и писать SQL-запросы открывает возможность более глубокого понимания логики работы с базов данных и понимать влияние каждой новой функциональности в системе на общую архитектуру решения.
Также эти навыки не просто делают аналитика "умнее", они делают его более ценным специалистом в команде, способным эффективно сотрудничать на всех этапах разработки: от описания Use Cases до сотрудничества с архитекторами. На собеседованиях это демонстрирует готовность кандидата к комплексному и многогранному подходу в проектировании систем.
Я придерживаюсь подхода "лучше знать, чем возмущаться". Широкий кругозор и умение быстро осваивать новую информацию одни из ключевых компетенций аналитиков.
Сохраняем материал про индексы и добавляем в свой чеклист подготовки к собеседованиям
Please open Telegram to view this post
VIEW IN TELEGRAM
👍14❤5🔥1
Давайте подробно разберем, как работают индексы, на примере самого распространенного типа индекса в PostgreSQL – B-tree (сбалансированное дерево).
B-tree индекс – это, в некотором роде, иерархическая структура, напоминающая дерево. В начале у нас есть корневой узел, который в свою очередь ведет к нескольким дочерним узлам, и так далее до "листьев" этого дерева.
Есть прекрасный пример по игре "угадай число": Когда вы ищете число, например, 37, вместо того чтобы начать с первого числа и двигаться далее, как в переборе, вы бы задали вопрос: "Оно больше 25?". Если ответ "да", то вы переходите к дочернему узлу с большими числами. Далее: "Оно меньше 40?". Снова ответ "да", и вы двигаетесь ещё глубже в дерево.
Когда новые элементы добавляются или удаляются из базы данных, дерево значений "перебалансируется". Это значит, что структура дерева меняется таким образом, чтобы сохранить свою эффективность. Представьте, что у вас есть доска для игры в боулинг, и вы хотите, чтобы все кегли стояли в сбалансированном порядке. Если одна из кегель упала, вы быстро переставите остальные, чтобы сохранить равновесие.
Такой подход к поиску позволяет значительно сократить количество "шагов" или "вопросов", необходимых для нахождения нужной информации. Это как раз и является преимуществом B-tree: быстрый поиск, вставка и удаление данных.
Продолжение 👇
B-tree индекс – это, в некотором роде, иерархическая структура, напоминающая дерево. В начале у нас есть корневой узел, который в свою очередь ведет к нескольким дочерним узлам, и так далее до "листьев" этого дерева.
Есть прекрасный пример по игре "угадай число": Когда вы ищете число, например, 37, вместо того чтобы начать с первого числа и двигаться далее, как в переборе, вы бы задали вопрос: "Оно больше 25?". Если ответ "да", то вы переходите к дочернему узлу с большими числами. Далее: "Оно меньше 40?". Снова ответ "да", и вы двигаетесь ещё глубже в дерево.
Когда новые элементы добавляются или удаляются из базы данных, дерево значений "перебалансируется". Это значит, что структура дерева меняется таким образом, чтобы сохранить свою эффективность. Представьте, что у вас есть доска для игры в боулинг, и вы хотите, чтобы все кегли стояли в сбалансированном порядке. Если одна из кегель упала, вы быстро переставите остальные, чтобы сохранить равновесие.
Такой подход к поиску позволяет значительно сократить количество "шагов" или "вопросов", необходимых для нахождения нужной информации. Это как раз и является преимуществом B-tree: быстрый поиск, вставка и удаление данных.
Продолжение 👇
👍12❤2🔥2
Пример поиска по штрихкоду
Предположим, у нас есть индекс по полю barcode.
Как это работает без индекса:
Для каждого запроса поиска по штрихкоду, СУБД должна будет перебирать каждую строку в таблице (`full table scan`), что займет много времени при больших объемах данных - сотни тысяч записей записей в БД о товарах, для каждого зоомагазина.
Как это работает с индексом B-tree:
- Индекс B-tree можно представить как дерево, где каждый узел содержит значение и указатели на дочерние узлы.
- При запросе по штрихкоду, PostgreSQL начинает поиск с корневого узла дерева.
- Он сравнивает искомое значение штрихкода с значениями в узле.
- Если искомое значение меньше, PostgreSQL идет к левому дочернему узлу; если больше – к правому.
- Этот процесс повторяется, пока не будет найдена нужная запись или узел, который указывает на нее.
Пример поиска по названию товара
Как это работает с индексом B-tree:
- Когда клиент ищет определенный товар по названию, PostgreSQL будет использовать индекс по полю name.
- Алгоритм поиска аналогичен примеру с штрихкодом: СУБД начинает поиск с корневого узла дерева и двигается влево или вправо, сравнивая искомое значение с значениями в узле, пока не найдет нужную запись.
Ключевой момент в работе B-tree индекса – это способность быстро находить записи, даже на огромных объемах данных, путем систематического разделения данных на меньшие части (дерево). Вместо просмотра миллионов строк, СУБД может определить местоположение нужной строки, проверив всего лишь десяток или сотню узлов индекса. Это делает операции поиска намного быстрее 🤝🔑
Предположим, у нас есть индекс по полю barcode.
Как это работает без индекса:
Для каждого запроса поиска по штрихкоду, СУБД должна будет перебирать каждую строку в таблице (`full table scan`), что займет много времени при больших объемах данных - сотни тысяч записей записей в БД о товарах, для каждого зоомагазина.
Как это работает с индексом B-tree:
- Индекс B-tree можно представить как дерево, где каждый узел содержит значение и указатели на дочерние узлы.
- При запросе по штрихкоду, PostgreSQL начинает поиск с корневого узла дерева.
- Он сравнивает искомое значение штрихкода с значениями в узле.
- Если искомое значение меньше, PostgreSQL идет к левому дочернему узлу; если больше – к правому.
- Этот процесс повторяется, пока не будет найдена нужная запись или узел, который указывает на нее.
Пример поиска по названию товара
Как это работает с индексом B-tree:
- Когда клиент ищет определенный товар по названию, PostgreSQL будет использовать индекс по полю name.
- Алгоритм поиска аналогичен примеру с штрихкодом: СУБД начинает поиск с корневого узла дерева и двигается влево или вправо, сравнивая искомое значение с значениями в узле, пока не найдет нужную запись.
Ключевой момент в работе B-tree индекса – это способность быстро находить записи, даже на огромных объемах данных, путем систематического разделения данных на меньшие части (дерево). Вместо просмотра миллионов строк, СУБД может определить местоположение нужной строки, проверив всего лишь десяток или сотню узлов индекса. Это делает операции поиска намного быстрее 🤝🔑
👍18
Что использовать для проектирования БД - диаграмму классов UML или ER-диаграмму?
Вопрос с подвохом, хорош для собеседований.
Давайте разберем различия диаграммы классов UML или ER-диаграммы, и определим, для каких целей используется каждая из них.
Диаграмма классов UML
Это графическое представление структуры программного кода системы, создаваемой согласно принципам объектно-ориентированного программирования (далее - ООП), которое показывает классы, их атрибуты, методы и взаимосвязи между ними.
Элементы:
🔶 Классы программного кода (представлены прямоугольниками).
🔶 Атрибуты (свойства / переменные) программного кода (находятся внутри прямоугольника класса, сверху).
🔶 Методы программного кода (находятся внутри прямоугольника класса, снизу).
🔶 Взаимосвязи (стрелки между классами: ассоциация, наследование и др.).
Назначение:
Показывает как организовать структуру программного кода в системе.
Пример:
У нас есть класс "Пользователь" с атрибутами "имя", "электронная почта" и методом "заказать". Он связан с классом "Заказ", который содержит информацию о покупках.
ER-диаграмма (Entity-Relationship Diagram)
Это графическое представление структуры базы данных. Показывает сущности, их атрибуты и связи между сущностями.
Элементы:
🔶 Сущности (представлены прямоугольниками).
🔶 Атрибуты (находятся внутри прямоугольника сущности).
🔶 Связи (стрелки между сущностями).
Назначение:
Помогает разработчикам и аналитикам создавать и описывать структуру БД.
Пример:
У нас есть сущность "Пользователь" с атрибутами "имя" и "электронная почта". Эта сущность связана с сущностью "Заказ", который включает в себя номер, дату оформления, а также связан с различными товарами. Методов нет.
⬇️⬇️⬇️⬇️⬇️
Вопрос с подвохом, хорош для собеседований.
Давайте разберем различия диаграммы классов UML или ER-диаграммы, и определим, для каких целей используется каждая из них.
Диаграмма классов UML
Это графическое представление структуры программного кода системы, создаваемой согласно принципам объектно-ориентированного программирования (далее - ООП), которое показывает классы, их атрибуты, методы и взаимосвязи между ними.
Элементы:
🔶 Классы программного кода (представлены прямоугольниками).
🔶 Атрибуты (свойства / переменные) программного кода (находятся внутри прямоугольника класса, сверху).
🔶 Методы программного кода (находятся внутри прямоугольника класса, снизу).
🔶 Взаимосвязи (стрелки между классами: ассоциация, наследование и др.).
Назначение:
Показывает как организовать структуру программного кода в системе.
Пример:
У нас есть класс "Пользователь" с атрибутами "имя", "электронная почта" и методом "заказать". Он связан с классом "Заказ", который содержит информацию о покупках.
ER-диаграмма (Entity-Relationship Diagram)
Это графическое представление структуры базы данных. Показывает сущности, их атрибуты и связи между сущностями.
Элементы:
🔶 Сущности (представлены прямоугольниками).
🔶 Атрибуты (находятся внутри прямоугольника сущности).
🔶 Связи (стрелки между сущностями).
Назначение:
Помогает разработчикам и аналитикам создавать и описывать структуру БД.
Пример:
У нас есть сущность "Пользователь" с атрибутами "имя" и "электронная почта". Эта сущность связана с сущностью "Заказ", который включает в себя номер, дату оформления, а также связан с различными товарами. Методов нет.
⬇️⬇️⬇️⬇️⬇️
❤9🔥8👍3🤩3
‼️ Отличия диаграммы классов UML от ER-диаграммы ‼️
🔹 Фокус:
UML-диаграмма классов сфокусирована на структуре кода программы, ER – на структуре базы данных.
🔹Использование:
UML-диаграмма классов применяется в объектно-ориентированной разработке, ER-диаграмма – при проектировании баз данных.
По факту, в реальных проектах UML-диаграмму классов не используют. Это избыточная документация, которая меняется в процессе разработки программного кода. При большом желании можно автоматически создать UML-диаграмму на основе кода, но такой потребности у нас пока ни разу не возникало.
🔹Семантика:
UML-диаграмма классов имеет богатый набор отношений (наследование, ассоциация, агрегация и др.), в то время как ER-диаграмма обычно ограничивается типами отношений (один-ко-многим, многие-ко-многим и т.д.).
UML-диаграмма классов имеет методы, в то время как ER-диаграмма их не содержит, т.к. описывает только данные в БД, но не операции над ними.
Диаграммы классов UML можно использовать для проектирования баз данных. Однако стоит помнить, что UML первоначально был разработан для описания структуры программного кода, а не для баз данных. Несмотря на это, многие элементы и связи на диаграмме классов могут быть перенесены в контекст проектирования баз данных.
Для проектирования баз данных более подходяща нотация моделирования это ER-диаграмма (Entity-Relationship diagram). Она создана специально для описания структуры баз данных.
🔹 Фокус:
UML-диаграмма классов сфокусирована на структуре кода программы, ER – на структуре базы данных.
🔹Использование:
UML-диаграмма классов применяется в объектно-ориентированной разработке, ER-диаграмма – при проектировании баз данных.
По факту, в реальных проектах UML-диаграмму классов не используют. Это избыточная документация, которая меняется в процессе разработки программного кода. При большом желании можно автоматически создать UML-диаграмму на основе кода, но такой потребности у нас пока ни разу не возникало.
🔹Семантика:
UML-диаграмма классов имеет богатый набор отношений (наследование, ассоциация, агрегация и др.), в то время как ER-диаграмма обычно ограничивается типами отношений (один-ко-многим, многие-ко-многим и т.д.).
UML-диаграмма классов имеет методы, в то время как ER-диаграмма их не содержит, т.к. описывает только данные в БД, но не операции над ними.
Диаграммы классов UML можно использовать для проектирования баз данных. Однако стоит помнить, что UML первоначально был разработан для описания структуры программного кода, а не для баз данных. Несмотря на это, многие элементы и связи на диаграмме классов могут быть перенесены в контекст проектирования баз данных.
Для проектирования баз данных более подходяща нотация моделирования это ER-диаграмма (Entity-Relationship diagram). Она создана специально для описания структуры баз данных.
👍22❤7
Что выбрать для проектирования БД: UML-диаграмму классов или ER-диаграмму?
ER-диаграмма для проектирования баз данных. В ней
💠 таблицы (сущности),
💠 поля (свойства сущностей),
💠 отношения между таблицами БД.
UML-диаграмма для описания струткуры кода. В ней
💠 классы (описывают группы однотипных объектов, как сущности),
💠 поля (свойства сущностей),
💠 методы (функции - что можно делать с объектами классов),
💠 отношения между классами.
Сохраните ссылку на статью с подробным разбором и примерами в избранное, чтобы уверенно отвечать на этот теоретический вопрос на собеседованиях ❤️ В ней вы найдете лайфхаки по использованию UML-диаграммы классов для описания БД, код для PlantUML-диаграмм классов и объектов, а такде картинки этих диаграмм.
ER-диаграмма для проектирования баз данных. В ней
💠 таблицы (сущности),
💠 поля (свойства сущностей),
💠 отношения между таблицами БД.
UML-диаграмма для описания струткуры кода. В ней
💠 классы (описывают группы однотипных объектов, как сущности),
💠 поля (свойства сущностей),
💠 методы (функции - что можно делать с объектами классов),
💠 отношения между классами.
Сохраните ссылку на статью с подробным разбором и примерами в избранное, чтобы уверенно отвечать на этот теоретический вопрос на собеседованиях ❤️ В ней вы найдете лайфхаки по использованию UML-диаграммы классов для описания БД, код для PlantUML-диаграмм классов и объектов, а такде картинки этих диаграмм.
getanalyst.ru
Что выбрать для проектирования БД: сравнение UML-диаграммы классов и ER-диаграммы
Подходит ли диаграмма классов UML для проектирования баз данных? Давайте разберемся и сравним ее с ER-диаграммой.
👍15❤3
О личном. О наболевшем. И о том, что не надо воспринимать всё близко к сердцу, как я.
Наконец-то побывала в отпуске. Провела практический вебинар по БД и на следующий же день улетела. Последний раз мне реально удалось отдохнуть от работы и отключиться на 100% от сети в первых числах января 2022. На 4 дня. В обычной жизни отдых максимум на 1.5 дня с постоянным подключением в проекты и ответами по чатам.
С мая я больше не веду личные соцсети. Отказалась в пользу себя. Потому что сделать сториз в инстаграм = 1 час времени, который можно потратить на реальный отдых. У меня и до этого не было времени на них. Но хотелось как-то еще показывать, что я успеваю жить: мини-поездки, гастрономические приключения, 2-3 перелета в месяц, спорт каждый день, прогулки у океана. Это всё остается. Просто телефон в стороне.
Больше 30 человек с которыми я сейчас лично работаю и общаюсь по всем проектам. Эффективный менеджмент? В процессе перехода к нему. Но чтобы всё получилось как есть в моей жизни сейчас, надо было работать за семерых. Мои рабочие дни это 8-14 часов в сутки, 6 дней в неделю. Кроме GetAnalyst у меня есть актуальные проекты, которые я веду. И внутри GetAnalyst тоже большая загрузка по обучению и коммуникациям. Не всегда удается всем оперативно отвечать. Еще и на двух языках.
Я искренне люблю свою работу, искренне предана своему делу. Я очень хочу успевать больше, делать лучшее. Но иногда эта любовь переходит границы работа-жизнь. Я счастлива! Особенно тому, что я вижу результаты! Везде! Пусть и не так быстро, как хочется. Но такие нагрузки, которые я переношу, не пожелаю никому.
Всё не поместилось, продолжение в следующем посте 👇
Наконец-то побывала в отпуске. Провела практический вебинар по БД и на следующий же день улетела. Последний раз мне реально удалось отдохнуть от работы и отключиться на 100% от сети в первых числах января 2022. На 4 дня. В обычной жизни отдых максимум на 1.5 дня с постоянным подключением в проекты и ответами по чатам.
С мая я больше не веду личные соцсети. Отказалась в пользу себя. Потому что сделать сториз в инстаграм = 1 час времени, который можно потратить на реальный отдых. У меня и до этого не было времени на них. Но хотелось как-то еще показывать, что я успеваю жить: мини-поездки, гастрономические приключения, 2-3 перелета в месяц, спорт каждый день, прогулки у океана. Это всё остается. Просто телефон в стороне.
Больше 30 человек с которыми я сейчас лично работаю и общаюсь по всем проектам. Эффективный менеджмент? В процессе перехода к нему. Но чтобы всё получилось как есть в моей жизни сейчас, надо было работать за семерых. Мои рабочие дни это 8-14 часов в сутки, 6 дней в неделю. Кроме GetAnalyst у меня есть актуальные проекты, которые я веду. И внутри GetAnalyst тоже большая загрузка по обучению и коммуникациям. Не всегда удается всем оперативно отвечать. Еще и на двух языках.
Я искренне люблю свою работу, искренне предана своему делу. Я очень хочу успевать больше, делать лучшее. Но иногда эта любовь переходит границы работа-жизнь. Я счастлива! Особенно тому, что я вижу результаты! Везде! Пусть и не так быстро, как хочется. Но такие нагрузки, которые я переношу, не пожелаю никому.
Всё не поместилось, продолжение в следующем посте 👇
❤31🔥5👏2👍1