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

Этапы процесса

1. Идентификация
   Пользователь сообщает системе, кто он такой.
• Пример: Ввод логина или адреса электронной почты.
• Назначение: Система узнает, с каким пользователем предстоит работать.
2. Аутентификация
   Система проверяет, действительно ли пользователь является тем, за кого себя выдает.
• Пример: Ввод пароля, PIN-кода, предоставление биометрических данных.
• Назначение: Подтверждение подлинности введенных данных.
3. Авторизация
   Система определяет, какие действия пользователь имеет право совершать.
• Пример: Доступ к чтению писем, но не к их удалению; снятие наличных, но не пополнение счета.
• Назначение: Предоставление или ограничение прав доступа к ресурсам и функциям.

1. Абстракция

• Суть: Выделение ключевых характеристик и поведения объектов, которые важны для решения конкретной задачи, и скрытие несущественных деталей.
• Пример: При использовании телевизора нам не нужно знать, как он работает внутри, достаточно знать, как управлять им с помощью пульта.

2. Инкапсуляция

• Суть: Сокрытие внутренней реализации объекта и предоставление доступа к его данным и методам только через определенный, контролируемый интерфейс.
• Преимущества: Это защищает данные от некорректных изменений и позволяет легко модифицировать внутреннюю структуру объекта, не затрагивая остальной код.

3. Наследование

• Суть: Способность создавать новые классы (потомков) на основе существующих (родителей), перенимая их свойства и методы, но добавляя или изменяя их под свои нужды.
• Пример: Класс «Собака» может наследовать общие свойства от класса «Животное» (например, иметь имя), но добавить свои уникальные характеристики (например, лаять).

4. Полиморфизм

• Суть: Возможность использовать один и тот же метод для объектов разных классов, при этом каждый объект будет выполнять действие по-своему, в соответствии со своей реализацией.
• Пример: Метод «издать звук» у разных животных будет вызывать разное звучание: кошка мяукать, а собака лаять.

Основные компоненты и принципы TOGAF

Метод разработки архитектуры (ADM)
Это основной процесс TOGAF, который описывает итеративный подход к созданию и управлению архитектурой предприятия.

Фреймворк контента
Определяет стандартные элементы и строительные блоки, используемые при описании архитектуры.

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

Четыре домена архитектуры

1. Бизнес-архитектура
Определяет стратегию предприятия, структуру управления и ключевые бизнес-процессы.

2. Архитектура данных
Описывает структуру данных организации и ресурсы для управления ими.

3. Архитектура приложений
Представляет собой карту корпоративных приложений, описывая их роль в бизнес-процессах и взаимодействие.

4. Архитектура технологий
Описывает аппаратное и программное обеспечение, необходимое для поддержки бизнес- и ИТ-архитектуры.

Зачем используется TOGAF

1. Согласование бизнеса и ИТ
Помогает организациям связать свои ИТ-системы и процессы со стратегическими целями бизнеса.

2. Структурированный подход
Предоставляет стандартизированный подход к проектированию и управлению архитектурой.

3. Управление изменениями
Позволяет организациям эффективно управлять изменениями и адаптироваться к новым требованиям.

4. Общий язык
Обеспечивает общий язык и терминологию для всех участников процесса архитектуры.

Разберём каждый уровень отдельно:

1. Контекст (Context)

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

2. Контейнеры (Containers)

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

3. Компоненты (Components)

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

4. Код (Code)

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

Преимущества модели C4

• Масштабируемость:
  Позволяет "приближать" или "отдалять" детали, показывая систему с разной степенью детализации.
• Понятность:
  Простота нотации делает диаграммы понятными для разных специалистов, от бизнес-аналитиков до разработчиков.
• Иерархичность:
  Чёткое разделение на уровни помогает постепенно раскрывать сложность системы, не перегружая диаграммы лишней информацией.
• Гибкость:
  Модель не навязывает строгие формальные нотации и может использовать различные инструменты для создания диаграмм, включая UML и Miro.

Вот заметил, что в HR-среде появился новый формат - "Прожарка резюме". Это очень правильно. Ибо много раз замечал, что прекрасные высококвалифицированные работники просто не понимают, как себя сначала эффектно подать, а потом по дороже продать.

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

Итак вот небольшая цитата требований к соискателю:

• Опыт работы в роли системного аналитика от 3 лет;
• Опыт работы с web-сервисами. Знаешь варианты интеграций между системами (JSON, XML, REST, SOAP, Kafka, MQ);
• Опыт описания бизнес процессов(UML, BPMN)
• Опыт написания функциональных требований/бизнес-требований/технических спецификаций на разработку;
• Опыт с микросервисной архитектурой или был опыт переноса с монолита на микросервисы.
• Опыт работы с БД на уровне построения сложных запросов и готов это продемонстрировать на собеседовании.

Давайте пройдёмся по пунктам.

1. "Опыт работы в роли системного аналитика от 3 лет".

Тут вопросов нет, тут всё понятно. Но только меня бесит слово "роль" в этом предложении? Вот к этому слову множество вопросов. Неужели нельзя просто написать: "Опыт работы системным аналитиком от 3 лет" ? Или это - слишком просто для такой сложной вакансии? Или хотят отсечь тех, кто уже в IT, но роль системного аналитика пока не выбрал или выбрал достаточно поздно?

2. "Опыт работы с web-сервисами"

Вы меня извините, а что это такое? Вот у меня формулировки не было, полез искать. Вот что нашёл в wiki: "идентифицируемая уникальным веб-адресом (URL-адресом) программная система со стандартизированными интерфейсами". Стало понятнее? Вот и мне - тоже. Но звучит очень круто. Неопытного соискателя должно отпугнуть (может быть, на это и расчёт?).

Но вот особенно радует следующее предложение.

3. "Знаешь варианты интеграций между системами (JSON, XML, REST, SOAP, Kafka, MQ)".

Как там было у Алёны Апиной: "Я тебя слепила из того, что было".

Давайте разбираться.

• JSON и XML - стандарты передачи данных.
• SOAP - протокол передачи данных.
• REST - "архитектурный стиль".
• Kafka - брокер сообщений.
• MQ... Тут, как мне кажется, имелся ввиду "IBM WebSphere MQ" - семейство сетевого ПО. Ну или "Rabbit MQ" - брокер сообщений.

Тут почему-то внезапно к соискателю перешли на "ты". Типа знаешь вот это вот всё? Применял на практике? От аббревиатуры MQ не падаешь в обморок? Можешь объяснить разницу между ежом и ужом SOAP и REST?

NB. Уже давно не удивляет, как в IT-среде любят мешать всё в кучу, не разбираясь, что есть что. Но первые 10-15 лет очень бесило, например, как стандарт "ISO 8583" называли "протоколом". А типа аббревиатура ISO вам ничего не говорит?!

4. Опыт описания бизнес процессов(UML, BPMN)

Для начала давайте переведу на русский.

UML - это Unified Modeling Language (унифицированный язык моделирования).

BPMN - это Business Process Model and Notation (нотация и модель бизнес-процессов).

То есть, язык моделирования и нотация и модель бизнес-процессов. Умолчу о том, что UML позволяет строить 12 видов диаграмм. И далеко не все из них можно использовать для описания бизнес-процессов (например, все структурные диаграммы: классов, объектов и компонент).

Но да, что-то про бизнес-процессы и их описание.

5. Опыт написания функциональных требований/бизнес-требований/технических спецификаций на разработку.

Так и хочется спросить: "А вам не надо будет описывать нефункциональные требования? Вы точно в это уверены?". Но к этой строчке претензий других нет, тут всё по делу.

6. Опыт с микросервисной архитектурой или был опыт переноса с монолита на микросервисы.

Только мне странно, что вместо пафосного определения "миграция" было использовано простое русское слово "перенос"?

Но меня больше задело само определение и союз "или" в нём. Типа был опыт переноса был, но при этом опыта с микросервисной архитектурой не было. А это, извините, как? Может быть лучше было написать так: "Опыт работы с микросервисной архитектурой, опыт миграции из монолитного решения на микросервисы"?

7. Опыт работы с БД на уровне построения сложных запросов и готов это продемонстрировать на собеседовании.

Вот меня уже много лет удивляют требования к системным аналитикам про сложные SQL-запросы. Вас не удивляет? А зря! Да, какие-то элементарные знания SQL, конечно же, аналитику нужны, кто спорит! Например, чтобы найти что-то в базе данных, или посчитать число записей, или отсортировать что-то по каким-то условиям. Но вот "сложные запросы"... Вы точно системного аналитика ищите? Часто в своём опыте приходилось и приходится иметь дело с SQL. Но вот ни разу не страдал от того, что не могу мгновенно без шпаргалки сочинить сложный запрос. Да и нужны бывают такие запросы в работе раз в год по праздникам. Плюс теперь есть искусственный интеллект, который за 5 минут тебе почти любой запрос напишет (если умеешь им пользоваться, конечно).

P.S. Кстати, вы не знаете, почему очень часто в описании вакансии размер заработной платы указывают в самую последнюю очередь (если вообще указывается). Прямо как в роликах автоблогеров, которые так любят называть стоимость автомобиля в конце ролика.

Протокол TLS (Transport Layer Security) — криптографический протокол, который обеспечивает защищённый обмен данными между сервером и клиентом. TLS расположен на уровень ниже протокола HTTP в модели OSI. Это означает, что в процессе выполнения запроса сперва происходят все “вещи”, связанные с TLS-соединением и уже потом, все что связано с HTTP-соединением. TLS пришёл на смену устаревшего протокола SSL.

Зачем нужно шифрование

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

Принцип работы TLS

Чтобы защитить данные, TLS создаёт во время передачи специальный канал, где их нельзя прочитать или изменить без секретного ключа. Ключ — это подсказка, как именно читать сообщение.

В зависимости от количества ключей в TLS используется один из двух классов шифрования: симметричное и асимметричное.

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

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

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

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

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

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

REST - самый популярный способ разработки веб-сервисов. По итогам опросов, проводимых Postman, использование немного снизилось за последние два года — с 92% до 86%. Но простота, масштабируемость и легкость в интеграциях с веб-сервисами закрепляют позицию REST на первом месте.

Как любой инструмент или подход, REST не всегда лучший выбор для всех сценариев.

REST точно не нужен в следующих случаях:

➖Онлайн взаимодействие: для приложений, требующих постоянного соединения для быстрого обмена данными в онлайн режиме (онлайн-игры, чаты). WebSocket или другие протоколы реального времени подойдут лучше.

➖Различные наборы данных под каждого клиента: если клиенты (например, мобильное приложение и веб-сайт) требуют разных наборов данных, GraphQL может предоставить больше гибкости, позволяя клиентам запрашивать только те данные, которые им нужны.

➖Бинарный Протокол: если требуется эффективность и минимальные затраты на передачу данных, то протоколы, такие как gRPC, использующие бинарные форматы передачи данных, могут быть более эффективными.

➖Служебная Информация: если ваш API должен передавать много служебной информации вместе с данными (например, метаданными или инструкциями обработки), SOAP может быть более подходящим, так как он предоставляет стандартизированный способ включения такой информации в сообщения.

➖Обратная Совместимость: если ваша система уже имеет существующие интеграции на основе другого протокола (например, SOAP), и переход на REST может вызвать сбои или требует значительной переработки, может быть рационально продолжить использовать текущий протокол.

Structure Diagrams (Структурные диаграммы):

• Class diagram (Диаграмма классов)
• Component diagram (Диаграмма компонентов)
• Composite structure diagram (Диаграмма композитной/составной структуры)
• Collaboration (UML2.0, Диаграмма кооперации)
• Deployment diagram (Диаграмма развёртывания)
• Object diagram (Диаграмма объектов)
• Package diagram (Диаграмма пакетов)
• Profile diagram (UML2.2, Диаграмма профилей)

Behavior Diagrams (Диаграммы поведения):

• Activity diagram (Диаграмма деятельности)
• State Machine diagram (Диаграмма состояний)
• Use case diagram (Диаграмма прецедентов или диаграмма вариантов использования)
• Interaction Diagrams (Диаграммы взаимодействия):
• Communication diagram (UML2.0) / Collaboration (UML1.x) (Диаграмма коммуникации / Диаграмма кооперации)
• Interaction overview diagram (UML2.0) (Диаграмма обзора взаимодействия)
• Sequence diagram (Диаграмма последовательности)
• Timing diagram (UML2.0) (Диаграмма синхронизации)

Ниже дано краткое описание диаграммы каждого вида.

1. Диаграмма классов

Диаграмма классов (Class diagram) — статическая структурная диаграмма, описывающая структуру системы, демонстрирующая классы системы, их атрибуты, методы и зависимости между классами.

Существуют разные точки зрения на построение диаграмм классов в зависимости от целей их применения:

• концептуальная точка зрения — диаграмма классов описывает модель предметной области, в ней присутствуют только классы прикладных объектов;
• точка зрения спецификации — диаграмма классов применяется при проектировании информационных систем;
• точка зрения реализации — диаграмма классов содержит классы, используемые непосредственно в программном коде (при использовании объектно-ориентированных языков программирования).

2. Диаграмма компонентов

Диаграмма компонентов (Component diagram) — статическая структурная диаграмма, показывает разбиение программной системы на структурные компоненты и связи (зависимости) между компонентами. В качестве физических компонентов могут выступать файлы, библиотеки, модули, исполняемые файлы, пакеты и т. п.

3. Диаграмма композитной/составной структуры

Диаграмма композитной/составной структуры (Composite structure diagram) — статическая структурная диаграмма, демонстрирует внутреннюю структуру классов и, по возможности, взаимодействие элементов (частей) внутренней структуры класса.

Подвидом диаграмм композитной структуры являются диаграммы кооперации (Collaboration diagram, введены в UML 2.0), которые показывают роли и взаимодействие классов в рамках кооперации. Кооперации удобны при моделировании шаблонов проектирования.

Диаграммы композитной структуры могут использоваться совместно с диаграммами классов.

4. Диаграмма развёртывания

Диаграмма развёртывания (Deployment diagram, диаграмма размещения) — служит для моделирования работающих узлов (аппаратных средств, node) и артефактов, развёрнутых на них. В UML 2 на узлах разворачиваются артефакты (artifact), в то время как в UML 1 на узлах разворачивались компоненты. Между артефактом и логическим элементом (компонентом), который он реализует, устанавливается зависимость манифестации.

5. Диаграмма объектов

Диаграмма объектов (Object diagram) — демонстрирует полный или частичный снимок моделируемой системы в заданный момент времени. На диаграмме объектов отображаются экземпляры классов (объекты) системы с указанием текущих значений их атрибутов и связей между объектами.

6. Диаграмма пакетов

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

7. Диаграмма деятельности

Диаграмма деятельности (Activity diagram) — диаграмма, на которой показано разложение некоторой деятельности на её составные части. Под деятельностью (activity) понимается спецификация исполняемого поведения в виде координированного последовательного и параллельного выполнения подчинённых элементов — вложенных видов деятельности и отдельных действий (action), соединённых между собой потоками, которые идут от выходов одного узла к входам другого.

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

8. Диаграмма автомата

Диаграмма автомата (State Machine diagram, диаграмма конечного автомата, диаграмма состояний) — диаграмма, на которой представлен конечный автомат с простыми состояниями, переходами и композитными состояниями.

Конечный автомат (State machine) — спецификация последовательности состояний, через которые проходит объект или взаимодействие в ответ на события своей жизни, а также ответные действия объекта на эти события. Конечный автомат прикреплён к исходному элементу (классу, кооперации или методу) и служит для определения поведения его экземпляров.

9. Диаграмма прецедентов (Диаграмма вариантов использования)

Диаграмма прецедентов или диаграмма вариантов использования (Use case diagram) — диаграмма, на которой отражены отношения, существующие между акторами и вариантами использования.

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

10. Диаграммы коммуникации и последовательности

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

Диаграмма коммуникации (Communication diagram, в UML 1.x — диаграмма кооперации, collaboration diagram) — диаграмма, на которой изображаются взаимодействия между частями композитной структуры или ролями кооперации. В отличие от диаграммы последовательности, на диаграмме коммуникации явно указываются отношения между элементами (объектами), а время как отдельное измерение не используется (применяются порядковые номера вызовов).

Диаграмма последовательности (Sequence diagram) — диаграмма, на которой показаны взаимодействия объектов, упорядоченные по времени их проявления. В частности, на ней изображаются участвующие во взаимодействии объекты и последовательность сообщений, которыми они обмениваются.

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

По причине того, что диаграммы Sequence и Collaboration являются разными взглядами на одни и те же процессы, Rational Rose позволяет создавать из Sequence диаграммы диаграмму Collaboration и наоборот, а также производит автоматическую синхронизацию этих диаграмм.

11. Диаграмма обзора взаимодействия

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

Этот тип диаграмм включает в себя диаграммы Sequence diagram (диаграммы последовательностей действий) и Collaboration diagram (диаграммы сотрудничества). Эти диаграммы позволяют с разных точек зрения рассмотреть взаимодействие объектов в создаваемой системе.

12. Диаграмма синхронизации

Диаграмма синхронизации (Timing diagram) — альтернативное представление диаграммы последовательности, явным образом показывающее изменения состояния на линии жизни с заданной шкалой времени. Может быть полезна в приложениях реального времени.

Ключевое слово ORDER BY

Ключевое слово ORDER BY используется для сортировки результирующего набора в порядке возрастания или убывания. По умолчанию упорядочение по ключевым словам сортирует записи в порядке возрастания. Для сортировки записей в порядке убывания используйте ключевое слово «описание».

Примеры:

SELECT * FROM Customers ORDER BY Country

Эта инструкция выбирает всех записи из таблицы «Customers», отсортированной по столбцу «Country» (по алфавиту). Если надо вывести те же данные, но в порядке, обратном алфавитному, надо использовать описание "DESC" (сортировка по убыванию).

SELECT * FROM Customers ORDER BY Country DESC

Для сортировки по возрастанию можно использовать описание "ASC" (используется по умолчанию).

Заметим, что можно соритровать информацию по нескольким столбцам:

SELECT * FROM Customers ORDER BY Country ASC, CustomerName DESC

Эта инструкция выбирает все записи из таблицы «Customers», отсортированных по алфавиту значения поля в столбце «Country» и в обратном алфавитном порядке по значению поля в столбце «CustomerName».

Предложение SELECT Top/Limit

Предложение SELECT Top/Limit используется для указания количества возвращаемых записей. Предложение SELECT Top/Limit полезно для больших таблиц с тысячами записей. Возврат большого количества записей может повлиять на производительность. Кроме того, такие данные просто тяжело читать.

Почему Top/Limit? Некоторые версии SQL (например, MySQL) не поддерживает предложение "Top", но поддерживают предложение "Limit" (и наоборот).

Примеры:

1. SELECT * FROM Customers LIMIT 100

2. SELECT TOP 100 * FROM Customers

Выводятся первые 100 записей из таблицы «Customers» отсортированные по умолчанию.

Теперь соединим оба описываемых параметра в одном примере:
SELECT TOP 10 * FROM Customers ORDER BY Country

По данному запросу выводятся 100 первых записей из таблицы «Customers» отсортированные по алфавиту названия страны.

SQL расшифровывается как "структурированный язык запросов". SQL позволяет обращаться к базам данных и управлять ими. SQL стал стандартом американского Национального института стандартов (ANSI) в 1986, и международной организации по стандартизации (ISO) в 1987.

Самые используемые команды SQL

DML — язык изменения данных (Data Manipulation Language)

• SELECT - Извлекает данные из базы данных;
• UPDATE - обновляет данные в базе данных;
• DELETE - Удаление данных из базы данных;
• INSERT INTO - Вставка новых данных в базу данных;

DDL — язык определения данных (Data Definition Language)

• CREATE DATABASE - создает новую базу данных;
• ALTER DATABASE - изменяет базу данных;

• CREATE TABLE - Создание новой таблицы;
• ALTER TABLE - изменяет таблицу;
• DROP TABLE - Удаление таблицы;

• CREATE INDEX - создает индекс (ключ поиска);
• DROP INDEX - Удаляет индекс.

DCL — язык управления данными (Data Control Language)

• GRANT - Наделяет пользователя правами;
• REVOKE - Отменяет права пользователя.

Ограничения (constraints)

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

Среди наиболее распространенных ограничений можно назвать следующие:

• NOT NULL — колонка не может иметь нулевое значение;
• DEFAULT — значение колонки по умолчанию;
• UNIQUE — все значения колонки должны быть уникальными;
• PRIMARY KEY — первичный или основной ключ, уникальный идентификатор записи в текущей таблице;
• FOREIGN KEY — внешний ключ, уникальный идентификатор записи в другой таблице (таблице, связанной с текущей);
• CHECK — все значения в колонке должны удовлетворять определенному условию;
• INDEX — быстрая запись и извлечение данных.

Любое ограничение может быть удалено с помощью команды ALTER TABLE и DROP CONSTRAINT + название ограничения. Некоторые реализации предоставляют сокращения для удаления ограничений и возможность отключать ограничения вместо их удаления.

Целостность данных

В каждой СУБД существуют следующие категории целостности данных:

• целостность объекта (Entity Integrity) — в таблице не должно быть дубликатов (двух и более строк с одинаковыми значениями);
• целостность домена (Domain Integrity) — фильтрация значений по типу, формату или диапазону;
• целостность ссылок (Referential integrity) — строки, используемые другими записями (строки, на которые в других записях имеются ссылки), не могут быть удалены;
• целостность, определенная пользователем (User-Defined Integrity) — дополнительные правила.

Нормализация БД

Нормализация — это процесс эффективной организации данных в БД. Существует две главных причины, обуславливающих необходимость нормализации:

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

Нормализация предполагает соблюдение нескольких форм. Форма — это формат структурирования БД. Существует три главных формы: первая, вторая и, соответственно, третья. Я не буду вдаваться в подробности об этих формах, при желании, вы без труда найдете необходимую информацию.

Типы данных

Каждая колонка, переменная и выражение в SQL имеют определенный тип данных (data type). Основные категории типов данных:

Точные числовые

Приблизительные числовые

Дата и время

Строковые символьные

Строковые символьные (юникод)

Бинарные

Смешанные

Синтаксис SQL

Логические операторы

Встроенных функций для чисел

• AVG — вычисляет среднее значение;
• SUM — вычисляет сумму значений;
• MIN — вычисляет наименьшее значение;
• MAX — вычисляет наибольшее значение;
• COUNT — вычисляет количество записей в таблице.
• ROUND — округляет число;
• TRUNCATE — обрезает дробное число до указанного количества знаков после запятой;
• CEILING — возвращает наименьшее целое число, которое больше или равно текущему значению;
• FLOOR — возвращает наибольшее целое число, которое меньше или равно текущему значению;
• POWER — возводит число в указанную степень;
• SQRT — возвращает квадратный корень числа;
• RAND — генерирует случайное число с плавающей точкой в диапазоне от 0 до 1.

Встроенных функций для строк

• CONCAT — объединение строк;
• LENGTH — возвращает количество символов в строке;
• TRIM — удаляет пробелы в начале и конце строки;
• SUBSTRING — извлекает подстроку из строки;
• REPLACE — заменяет подстроку в строке;
• LOWER — переводит символы строки в нижний регистр;
• UPPER — переводит символы строки в верхний регистр и т.д.

Встроенные инструменты для работы с временем и датой

Возвращает текущую время и дату:

SELECT CURRENT_TIMESTAMP;

CURRENT_TIMESTAMP — это и выражение, и функция (CURRENT_TIMESTAMP()). Другая функция для получения текущей даты и времени — NOW().

Функции для разбора даты и времени:

• DAYOFMONTH(date) — возвращает день месяца в виде числа
• DAYOFWEEK(date) — возвращает день недели в виде числа
• DAYOFYEAR(date) — возвращает номер дня в году
• MONTH(date) — возвращает месяц
• YEAR(date) — возвращает год
• LAST_DAY(date) — возвращает последний день месяца в виде даты
• HOUR(time) — возвращает час
• MINUTE(time) — возвращает минуты
• SECOND(time) — возвращает секунды и др.

Функции для манипулирования датами:

• DATE_ADD(date, interval) — выполняет сложение даты и определенного временного интервала
• DATE_SUB(date, interval) — выполняет вычитание из даты определенного временного интервала
• DATEDIFF(date1, date2) — возвращает разницу в днях между двумя датами
• TO_DAYS(date) — возвращает количество дней с 0-го дня года
• TIME_TO_SEC(time) — возвращает количество секунд с полуночи и др.

Для форматирования даты и времени используются функции DATE_FORMAT(date, format) и TIME_FORMAT(date, format), соответственно.

Инструкция "SELECT"

Инструкция SELECT используется для выбора данных из базы данных.

Возвращаемые данные хранятся в результирующей таблице, называемой результирующим набором.

SELECT column1, column2, ...
FROM table_name

Где:

• column1, column2 - имена столбцов;
• table_name - имя таблицы.

1. Можно использовать синтаксис SELECT * FROM table_name.

По выполнению этого запроса выводится вся таблица полностью.

2. Можно использовать некоторое условие (condition). Например, для запроса:

SELECT * FROM table_name WHERE name <> 'example'

будут выводиться только те сроки таблицы table_name, поле name у которых не равно значению "example".

Операторы в WHERE

• "=", равно - строгое равенство какому-то значению;
• "<>" - не равно - строгое неравенство какому-то значению;
• ">", больше - больше какого-то значения (корректно работает только для числовых значений или единичных символов);
• "<", меньше - меньше какого-то значения (корректно работает только для числовых значений или единичных символов);
• ">=", больше или равно - равно или больше какого-то значения (корректно работает только для числовых значений или единичных символов);
• "<=", меньше или равно - равно или меньше какого-то значения (корректно работает только для числовых значений или единичных символов);
• "BETWEEN", между - между каким-то инклюзивным диапазоном;
• "LIKE", похоже - используется для поиска по какому-то шаблону;
• "IN", в - используется для задания нескольких конечных значений;
• "IS NULL" - используется для выбора данных, не имеющих значения (или имеющих значение "NULL").

NULL - это принятое в SQL обозначение пустого значения. Очевидно, что 0 не может быть пустым значением. Значение "NULL" означает, что значение пока не было задано или было удалено.

Кроме того, в операторе WHERE может находиться несколько условий поиска, между которыми могут операторы "AND", "OR" или "NOT".

• AND - отображает те записи, для которых все условия выполняются;
• OR - отображает те записи, для которых какое-либо из условий выполняется;
• NOT - отображает те записи, для которых условие не выполняется.

Рассмотрим применение каждого оператора

1. Равно
   SELECT * FROM table_name WHERE name = 'example'
   Выводит из таблицы "table_name", только те строки, в которых значение столбца "name" принимает значение "example".
2. Не равно
   SELECT * FROM table_name WHERE name <> 'example'
   Выводит из таблицы "table_name", только те строки, в которых значение столбца "name" принимает значение не "example".
3. Больше
   SELECT * FROM table_name WHERE number > '1'
   Выводит из таблицы "table_name", только те строки, в которых значение столбца "number" больше 1.
4. Меньше
   SELECT * FROM table_name WHERE number < '1'
   Выводит из таблицы "table_name", только те строки, в которых значение столбца "number" меньше 1.
5. Больше или равно
   SELECT * FROM table_name WHERE number >= '1'
   Выводит из таблицы "table_name", только те строки, в которых значение столбца "number" больше или равно 1.
6. Меньше или равно
   SELECT * FROM table_name WHERE number <= '1'
   Выводит из таблицы "table_name", только те строки, в которых значение столбца "number" меньше или равно 1.
7. BETWEEN
   SELECT * FROM table_name WHERE number BETWEEN '1' AND '3'
   Выводит из таблицы "table_name", только те строки, в которых значение столбца "number" больше или равно 1 и меньше или равно 3.
   Очевидно, что данный запрос можно заменить на запрос:
   SELECT * FROM table_name WHERE number >= '1' AND number <= '3'
8. LIKE
   SELECT * FROM FamilyMembers WHERE status LIKE '%ther%'
   Выводит из таблицы "FamilyMembers ", только те строки, в которых значение столбца "status" содержит "ther" (например, "mother" и "father").
9. IN
   SELECT * FROM table_name WHERE number IN ('1','3','5')
   Выводит из таблицы "table_name", только те строки, в которых значение столбца "number" равно 1, 2 или 3.
10. IS NULL
    SELECT * FROM table_name WHERE number IS NULL
    Выводит из таблицы "table_name", только те строки, в которых значение столбца "number" не задано (или равно NULL). Очевидно, что можно заменить на
    SELECT * FROM table_name WHERE number = NULL
    Но использование IS NULL более наглядно.