Системные и бизнес-аналитики часто решают задачу составления ТЗ на разработку информационных систем. Однако, специфицировать требования к алгоритмам обработки данных невозможно без определения самой модели данных хотя бы на концептуальном уровне. Поэтому сегодня специально для начинающих аналитиков разберем основные понятия теории баз данных: таблицы, связи между ними, ключи, 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
Ближайшая дата курса
12 мая, 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
Ближайшая дата курса
2 июня, 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
Ближайшая дата курса
26 мая, 2025
Продолжительность
22 ак.часов
Стоимость обучения
48 000 руб.
Проверить, как вы усвоили материал этой статьи можно бесплатно прямо на нашем сайте, выполнив интерактивный тест по основам баз данных и языку запросов SQL.
10 вопросов по основам теории баз данных и SQL: тест для начинающих
А на практике усвоить все упомянутые в статье темы вам помогут курсы Школы прикладного бизнес-анализа в нашем лицензированном учебном центре обучения и повышения квалификации системных и бизнес-аналитиков в Москве:
- Основы архитектуры и интеграции информационных систем
- Разработка ТЗ на информационную систему по ГОСТ и SRS
