Системные и бизнес-аналитики часто решают задачу составления ТЗ на разработку информационных систем. Однако, специфицировать требования к алгоритмам обработки данных невозможно без определения самой модели данных хотя бы на концептуальном уровне. Поэтому сегодня специально для начинающих аналитиков разберем основные понятия теории баз данных: таблицы, связи между ними, ключи, SQL-операторы и NoSQL-СУБД.
Что такое SQL, реляционная база данных, чем это отличается от СУБД и какие они бывают
BABOK®Guide упоминает технику моделирования данных как одно из наиболее востребованных умений бизнес-аналитика. В частности, модель данных входит в спецификацию требований к ПО согласно шаблонам из стандартов ISO IEEE 29148-2018 и IEEE 830-1998, которые мы разбирали здесь. В этом практическом смысле модель данных, разработанная аналитиком, ляжет в основу схемы базы данных, которую создает ИТ-архитектор или ведущий разработчик.
База данных – это хранилище данных в структурированном виде. Причем структура может быть различной. В реляционных базах данные хранятся в виде связанных таблиц с ограниченным числом столбцов, в каждом из которых хранятся данные одного типа: строковые (символы и текст), числовые (целые и вещественные), временные (дата и время), логические. В качестве средства доступа к этим данным выступает язык структурированных запросов SQL, который поддерживается в системах управления базами данных (СУБД). Без СУБД как инструмента обращения к данным и манипулирования ими база данных является просто большим файлом на жестком диске или структурой в памяти и не представляет собой ценности. Примеры популярных реляционных СУБД: MySQL, PostgreSQL, Microsoft SQL Server, SQLite, Oracle Database и пр.
На концептуальном уровне каждая таблица в реляционной базе данных представляет собой сущность предметной области, характеристики которой, значимые с точки зрения рассматриваемого контекста, называются атрибуты. По аналогии с классом в ООП, таблица является хранилищем записей — объектов с одинаковыми характеристиками. Запись таблицы представляет собой строку и полностью описывает все характеристики рассматриваемого экземпляра сущности. В отличие от UML-диаграммы классов, диаграммы сущность-связь (ERD, Entity Relationship Diagram) не говорят о поведении объектов, т.е. не содержат методов. Однако, на концептуальном уровне при разработке модели предметной области это почти не имеет значения, и тогда ERD и UML-диаграмма классов будут выглядеть практически одинаково.
DDD, ООП и UML для аналитика
Код курса
BUML
Ближайшая дата курса
1 июля, 2025
Продолжительность
22 ак.часов
Стоимость обучения
48 000 руб.
Например, сущность «Студент» (Student), у которого есть имя, отчество и фамилия, а также дата рождения и адрес. Студенты могут объединяться в группы (сущность Class), причем в одну группу может входить множество студентов и один студент может входить во множество групп. Получается, таблицы Student и Class будут связаны отношением с кратностью «много-ко-многим», что не считается хорошей практикой, т.к. не позволяет однозначно отслеживать изменение данных. Расшить такие множественные связи помогает дополнительная таблица, которая хранит ключи связываемых. В нашем примере это будет таблица Student_in_Class.
Ключ – это один или несколько столбцов, которые однозначно идентифицируют каждую запись в таблице. Ключ бывает первичный (Primary Key, PK), когда он не зависит от других таблиц и внешний (Foreign Key, FK), когда зависит. Внешний ключ показывает, что поведение записи в одной таблице (зависимой сущности) меняется при изменении или удалении записей из другой связанной таблицы (независимой сущности). Внешний или ссылочный ключ нужен для объединения двух таблиц. Можно сказать, FK в одной таблице – это один или несколько столбцов, значения которых соответствуют PK в другой таблице. Связь между двумя таблицами задается через соответствие Первичного ключа в одной таблице внешнему ключу во второй. Например, в таблице Student_in_Class внешними ключами будут поля class и student, соответствующие первичным ключам (id) в таблицах Class и Student.
Поскольку ключи являются идентификаторами записей, повторы в них недопустимы. Это достигается автоматической генерацией поля id с инкрементом, т.е. увеличением на 1 при создании новой записи. Как правило, современные СУБД сами следят за этим, т.е. на уровне концептуального проектирования при описании модели предметной области, этот атрибут не обязательно добавлять в словарь данных.
Разработка ТЗ на информационную систему по ГОСТ и SRS
Код курса
TTIS
Ближайшая дата курса
28 июля, 2025
Продолжительность
22 ак.часов
Стоимость обучения
48 000 руб.
Дополним вышерассмотренную ER-диаграмму таблицами для информационной системы формирования расписания. Появятся сущности, описывающие преподавателя (Teacher), учебную дисциплину (Subject), продолжительность занятия (Timepair), первичные ключи которых будут являться внешними ключами для агрегирующей таблицы с расписанием (Schedule).
Подобная структура, когда данные из нескольких таблиц агрегируются в одной, часто используется в OLAP-системах (Online Analytical Processing) для многомерного анализа данных. Например, показать данные по продажам отдельных товарных категорий по разным странам в заданные периоды времени. Для этого используется центральная таблица ключевых фактов, по которым делаются запросы. К ней присоединяется множество таблиц измерений, которые показывают, как могут анализироваться агрегированные реляционные данные.
Как уже было отмечено, для доступа к данным в реляционных СУБД используется язык структурированных запросов SQL (Structured Query Language) — декларативный язык программирования. Он содержит операторы определения данных (DDL), манипулирования данными (DML), определения доступа к данным (DCL) и управления транзакциями (TCL). Все эти операторы реализуют не только базовые CRUDL-операции, но и обеспечивают целостность и непротиворечивость информации.
На практике чаще всего используются DML-операторы, особенно SELECT для выбора отдельных записей из одной или нескольких таблиц. Например, следующий SQL-запрос покажет, сколько студентов в группе под названием W22:
Select count(*) from Student_in_class Join Class on Class.id=Student_in_class.class WHERE Class.name=' W22'
Подробно рассматривать все операторы этого запроса не входит в задачи настоящей статьи. Более детально про проектирование модели данных и SQL-запросы я рассказываю здесь. Для тех, кто хочет самостоятельно освоить SQL, рекомендую следующие онлайн-учебники и тренажеры:
- https://sql-academy.org/ru/guide
- https://learndb.ru/articles
- https://www.sql-ex.ru/
- https://stepik.org/course/63054/promo?search=882582677
Также есть нереляционные базы данных, которые мы рассмотрим далее.
Основы бизнес-анализа: вход в профессию для начинающих
Код курса
INTRO
Ближайшая дата курса
7 июля, 2025
Продолжительность
24 ак.часов
Стоимость обучения
54 000 руб.
Что такое NoSQL
Если структура данных не определена или может меняться, жесткий подход с типизацией столбцов не подойдет. Например, для хранения больших файлов, кэшей, JSON/XML-документов и графов используются NoSQL-хранилища (Not Only SQL). Они оптимизированы для распределенных приложений, которые должны быстро обрабатывать большие объемы данных с разной структурой. NoSQL-СУБД бывают следующих типов:
- Ключ-значение (Key-value)– наиболее простой вариант хранилища данных, использующий ключ для доступа к значению в рамках большой хэш-таблицы, например, Oracle NoSQL Database, Berkeley DB, MemcacheDB, Redis, Riak, Amazon DynamoDB. Пример работы с Redis я описываю здесь.
- документное хранилище, где данные в виде пар ключ-значение представлены как полуструктурированный документ типа JSON, XML и пр. тегированные форматы, например, CouchDB, Couchbase, MongoDB, eXist, Berkeley DB XML. Примеры работы с MongoDB я рассматриваю в новой статье.
- колоночное хранилище, где ключами являются строки и столбцы разреженной матрицы. Примеры: Google Big Table, Apache HBase, Cassandra, ScyllaDB, Apache Accumulo и Hypertable;
- графовое хранилище, где данные представлены в виде вершин, связанных ребрами. Благодаря сохранению ребер, обход такого графа не требует дополнительных вычислений подобно соединению таблиц через JOIN в SQL-запросе. Примеры графовых СУБД: InfoGrid, Neo4j, Amazon Neptune, OrientDB, AllegroGraph, Blazegraph, InfiniteGraph, FlockDB, Titan, ArangoDB. Как работать с Neo4j, я рассказываю в этом материале.
Разумеется, каждая из отмеченных СУБД имеет свои варианты применения, особенности и недостатки, которые следует учитывать в качестве ограничений при выборе инструмента. Особенно важны такие характеристики, как способность к масштабированию, задержка обработки данных, оптимизация на операции чтения (OLAP) или записи (OLTP), наличие интеллектуального вычислительного движка, например, полнотекстовый и нечеткий поиск как в Elasticsearch. Однако, выбор дизайна как средства реализации требования, т.е. СУБД уже выходит за компетенции аналитика и находится в области ответственности ИТ-архитектора или ведущего разработчика на проекте. Тем не менее, понимание основ теории баз данных поможет аналитику описать сущности предметной области и связи между ними, чтобы специфицировать функциональные и нефункциональные требования к информационной системе.
Основы архитектуры и интеграции информационных систем
Код курса
OAIS
Ближайшая дата курса
4 августа, 2025
Продолжительность
22 ак.часов
Стоимость обучения
48 000 руб.
Проверить, как вы усвоили материал этой статьи можно бесплатно прямо на нашем сайте, выполнив интерактивный тест по основам баз данных и языку запросов SQL.
10 вопросов по основам теории баз данных и SQL: тест для начинающих
А на практике усвоить все упомянутые в статье темы вам помогут курсы Школы прикладного бизнес-анализа в нашем лицензированном учебном центре обучения и повышения квалификации системных и бизнес-аналитиков в Москве:
- Основы архитектуры и интеграции информационных систем
- Разработка ТЗ на информационную систему по ГОСТ и SRS
