🦒
System Analyst | Knowledge base
  • Введение
  • Soft skills
    • 📍Продукт
      • Роли в IT продукте
        • Системный аналитик (SA)
        • Бизнес-аналитик (BA)
        • SA vs BA
        • 📎Другие аналитики
      • Жизненный цикл продукта
      • Методологии разработки
        • Waterfall
        • Agile
          • Scrum
          • Kanban
      • 📎Целеполагание
        • SMART
        • Матрица Эйзенхауэра
        • RICE
        • 🔒HADI
    • 📍Требования
      • Классификация требований
        • Уровень: Бизнес
        • Уровень: Пользователь
          • Use case
          • User story
          • 📎Job story
        • Уровень: Продукт
          • Функциональные требования
          • Нефункциональные требования
      • Качества требований
      • Методы сбора требований
      • Техническое задание (ТЗ)
  • Hard skills
    • 📍Базы данных
      • Реляционные
        • Транзакции
          • 🔒CAP
        • Нормальные формы
        • SQL
          • DML
          • DDL/DCL/TCL
          • 📎Представления VIEW
        • Констрейты
        • 📎Типы данных
        • 🔒Middle+
          • Особенности работы с конкертными реляционными БД
      • Нереляционные
        • Примеры использования
        • 🔒Middle+
          • Колоночные
            • Сlickhouse
          • Ключ-значение
          • Матричные
          • Документо-ориентированные
          • Графовые
            • JanusGraph | Neo4j etc
      • Масштабирование БД
      • Оптимизация БД
        • 📎Типы индексов
        • 📎Уникальные индексы
        • 🔒Анатомия плана запроса
      • 📎Какую СУБД выбрать
      • 📎Хранение и анализ данных
        • ETL
        • DWH
          • DWH vs Data Lake vs Data Mart
        • OLAP
          • OLAP vs OLTP
        • BI-аналитика
    • 📍Интеграции
      • Форматы данных
        • JSON + JSON Schema
          • 🔒AVRO
        • JSON vs XML
      • Виды интеграций
        • Синхронное взаимодействие
          • REST
            • RESTful принципы
              • Отсутствие состояния (Авторизация)
                • 🔒OAuth / OpenID Connect
              • Кеширование
              • Единообразие интерфейса (CRUD)
                • Запрос/ответ
              • 🔒Cтепень зрелости REST API
            • Проектирование API
            • 📎Асинхронный REST
          • SOAP
            • XSD
            • WSDL
          • REST vs SOAP
        • Асинхронное взаимодействие
          • Kafka
          • RabbitMQ
          • Kafka vs RabbitMQ
          • ESB
          • gRPC
            • Правила proto-контракта
            • Protobuf vs JSON
            • Сравнительная таблица
          • Другое
          • 🔒WebSocket API
        • Sync vs Async
      • 🔒Middle+
        • Stateful vs Stateless
        • Apache Flink
        • оркестрация и хореография
    • 📍Проектирование
      • Архитектура
        • Монолит
        • Микросервисы
          • Паттерны реализации
        • Монолит vs Микросервисы
        • 🔒Middle+
          • Бессерверная
          • Сервис-ориентированная (SOA)
          • Другое
      • Нотации и диаграммы
        • UML
          • Диаграмма классов
          • Диаграмма последовательности
            • Фреймы
          • Диаграмма прецедентов (use case)
          • 🔒Middle+
            • Диаграмма деятельности/активности
            • Диаграмма состояний
        • BPMN
          • Основные элементы
        • BPMN vs UML
        • ERD
        • 📎IDEF0
      • Прототипирование
        • Figma vs Axure
      • Мониторинг
        • Логирование
        • Метрики
        • Алерты
        • 🔒Инструменты
          • Grafana
          • Prometheus
          • ELK
            • Elasticsearch
            • Logstash
            • Kibana
      • 🔐Системный дизайн
    • 📎DevOps for SA
      • Основы сетей
        • OSI
        • TCP/IP
        • HTTP
        • DNS
      • Git (VCS)
        • GitHub vs GitLab
      • Развертывание приложений
        • CI/CD
        • 🔒Middle+
          • Виртуализация/контеризация
            • ✍️Docker
            • Kubernetes
              • ✍️Openshift
      • Cloud Native
        • Сервисы облачных вычислений
        • Cloud-native app vs Traditional app
      • Командная строка
    • 📎QA for SA
      • Postman | Insomnia
      • Swagger
      • Верификация vs Валидация
      • Идентификация/Аутентификация/Авторизация
    • 📎PM for SA
      • Метрики
        • Метрики привлечения
        • Метрики вовлечённости
          • ARPU
          • LTV
          • NPV
          • ROI
          • NPS
      • Прокси метрики
      • Дерево метрик
      • Фреймворки
      • Юнит-экономика
      • Модель Кано
  • Другое
    • Литература
    • Советы по составлению резюме
    • Общие вопросы на собеседовании
    • Вопросы которые надо задать интервьюеру
  • Контакты
Powered by GitBook
On this page
  • Транзакция. ACID.
  • SQL
  • Констрейты
  • Основные характеристики реляционных баз данных
  • Примеры
  • MySQL
  • SQLite
  • PostgreSQL

Was this helpful?

  1. Hard skills
  2. Базы данных

Реляционные

PreviousБазы данныхNextТранзакции

Last updated 1 year ago

Was this helpful?

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

Транзакция. ACID.

Транзакция — это комплекс последовательных операций с применением операторов SQL, имеющих определенную цель. Все транзакции должны отвечать четырем требованиям ACID:

  • Атомарность (англ. atomicity) — транзакция является неделимым блоком и выполняется или полностью, или никак.

  • Согласованность (англ. consistency) — завершенная транзакция сохраняет согласованность базы данных.

  • Изолированность (англ. isolation) — параллельные транзакции не могут влиять друг на друга.

  • Устойчивость (англ. durability) — никакой сбой в системе не может влиять на результат завершенной транзакции.

Подробнее в главе:

SQL

Для взаимодействия с любой реляционной базой данных используется SQL (Structured Query Language) — язык структурированных запросов. Это основа интерфейса систем управления базами данных. Он стандартизирован с 1986 года и поддерживается всеми известными ядрами реляционных баз данных. SQL позволяет работать со строками таблиц, а также извлекать нужные блоки информации и производить транзакции.

Подробнее в главе:

Констрейты

  • NOT NULL

  • UNIQUE

  • CHECK

  • DEFAULT

  • PRIMARY KEY (ПК, Первичный ключ)

  • FOREIGN KEY (ВК, Внешний ключ)

Подробнее в главе:

Основные характеристики реляционных баз данных

Признак
Пояснение

Множество сущностей

Объекты со строго определенным набором атрибутов, с помощью которых они связываются между собой, формируют понятную и простую для восприятия структуру.

Табличный формат

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

Язык SQL

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

Масштабирование по вертикали

Реляционные базы данных хорошо масштабируются по вертикали. Но это значит, что по мере накопления информации в какой-то момент ее обработка потребует больших аппаратных ресурсов и финансовых затрат.

Масштабирование по горизонтали

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

Наличие требований к параметрам данных

Реляционные базы данных умеют работать только со структурированными данными. Но современный цифровой мир полон неструктурированных данных (например, фото и видео), к которым нельзя применять принципы реляционной модели.

Примеры

MySQL

Главные её преимущества — бесплатность и высокая скорость работы с данными. MySQL создавалась для обработки огромных массивов информации в промышленных масштабах, но благодаря доступности и быстродействию оккупировала Всемирную паутину, заслужив звание «СУБД всея интернета». И сегодня MySQL всё ещё самая удобная СУБД для работы с интернет-страницами и веб-приложениями.

SQLite

Основным ее достоинством считается встраиваемость, которая обусловлена тем, что SQlight в отличие от остальных СУБД является не приложением на подобие «клиент-сервер», а подключаемой библиотекой.

PostgreSQL

Её можно назвать самой продвинутой. Это не просто реляционная, а объектно-реляционная свободная СУБД.

PostgreSQL поддерживает не только типы данных, которые есть в других реляционных СУБД. Помимо числовых, текстовых, булевых и других стандартных типов, в ней можно хранить и обрабатывать геометрические и денежные данные, сетевые адреса, JSON, XML, массивы, а также создавать собственные типы данных.

Источники:

Это открытая СУБД, купленная Oracle. С ней работают (41,09%) всех разработчиков (по опроса, который в 2023 году провёл сайт StackOverflow.com).

📍
Транзакции
SQL
Констрейты
результатам
https://cloud.yandex.ru/docs/glossary/relational-databases
https://skillbox.ru/media/code/sql_i_nosql_in_i_yan_v_mire_baz_dannykh