Теория реляционных БД. Часть 2

Традиционный подход к хранению данных и его недостатки

Раньше работа с данными строилась вокруг пользователя, приложений и отдельных файлов. Пользователь через доступное ему приложение получал доступ к определённому набору файлов с данными. Права доступа регулировались на уровне приложения или файловой системы (например, через FTP). При этом разные пользователи даже в рамках одного приложения могли видеть разное множество документов.

У такой организации множество недостатков:
• Избыточность данных. Информация дублируется, чтобы обеспечить одновременный доступ многим сотрудникам к одним и тем же документам.
• Противоречивость данных. Приложения слабо связаны. Изменения, внесённые одним сотрудником в файл через одно приложение, могут конфликтовать с правками другого сотрудника, работающего через другое приложение. Автоматической связи между файлами нет, поэтому, например, корректировка сметы не запускает пересчёт связанных финансовых показателей. Проверять согласованность приходится вручную.
• Ограниченная доступность данных.
• Сложность организации и управления. Архитектура запутанная и не оптимизированная.
• Недостаточные средства защиты. Данные хранятся как простые файлы, и уровень защиты ограничен возможностями файловой системы, что значительно слабее специализированной защиты базы данных.
• Низкая производительность в многопользовательской среде. Архитектура плохо масштабируется.
• Отсутствие процедур восстановления. Нет механизмов репликации или отказоустойчивости.
• Отсутствие средств манипулирования данными. Данные предоставляются «как есть», без встроенных инструментов обработки.
• Высокая стоимость разработки и сопровождения. Несмотря на неэффективность, создание и поддержка такой системы обходятся дороже.
• Негибкость к изменениям.

Ключевые понятия

• Данные — это информация об объектах окружающего мира, представленная в формализованном виде, пригодном для передачи, хранения и обработки. Это может быть не только текст или числа, но и изображения, видео, аудио и многое другое.
• База данных (БД) — именованная совокупность данных, организованных по единым правилам, предусматривающим общие принципы описания, хранения и манипулирования данными независимо от прикладных программ. То есть заранее разрабатываются общие принципы работы с данными, которые затем применяются к любой сохраняемой информации.
• Предметная область — часть реального мира, которая подлежит изучению для организации управления и последующей автоматизации.
• СУБД (Система управления базами данных, DBMS) — совокупность языковых и программных средств, предназначенных для создания, ведения и совместного использования базы данных многими пользователями. Если БД предоставляет возможности для хранения и манипулирования, то СУБД — это конкретный инструмент, который эти операции физически выполняет.
• Банк данных (БнД) — система специальным образом организованных данных (самих баз данных), программных, технических, языковых и организационно-методических средств, предназначенная для централизованного накопления и коллективного многоцелевого использования данных. Это полная совокупность БД и всех обеспечивающих её функционирование компонентов.

Новая архитектура: единый источник данных

При использовании баз данных у нас также есть пользователи и приложения, но приложения адаптированы для работы с БД, а не с файловой системой. Все они взаимодействуют с данными через СУБД, в рамках которой действует администратор баз данных (АБД). Все приложения и пользователи сходятся к одному источнику информации — базе данных. Такой подход решает большинство проблем, присущих традиционной файловой организации.

Трёхуровневая модель представления данных (ANSI/SPARC)

Американский национальный институт стандартов (ANSI) предложил архитектуру, разделяющую представление данных на три уровня:
1. Внешний уровень (External Level). Это представление данных с точки зрения конкретного пользователя или приложения. Например, сотрудник отдела кадров видит не сложную схему из связанных таблиц с кодами, а готовую сводную таблицу, где все коды заменены на текстовые значения, выполнены группировки и фильтрации, необходимые для его операционной деятельности.
2. Концептуальный уровень (Conceptual Level). Это обобщённое, интегральное представление данных, описывающее, как данные должны видеться всем пользователям в принципе, без привязки к их специализации. Здесь определяются общие правила, например, что все справочные коды должны быть декодированы и подставлены связанные сущности.
3. Внутренний уровень (Internal Level). Это физическое представление данных — то, как они реально хранятся в БД: в виде таблиц, с первичными и внешними ключами, индексами, наследуемыми атрибутами. Это та самая схема данных, которую проектирует и с которой работает администратор.

Компоненты системы баз данных и языковые средства

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

Для взаимодействия с БД служат два типа языковых средств:
• DDL (Data Definition Language) — язык определения данных. С его помощью описывается структура: что это за данные, их тип, домены, задаются ограничения целостности.
• DML (Data Manipulation Language) — язык манипулирования данными. Наиболее известный пример — SQL (Structured Query Language), язык структурированных запросов. Он позволяет выбирать, вставлять, обновлять и удалять данные.

Категории пользователей

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

Функции администратора баз данных

Работа администратора БД критически важна и включает следующие задачи:
1. Анализ предметной области. Понимание бизнес-процессов, чтобы верно определить необходимость связей между сущностями и избежать будущих противоречий.
2. Проектирование структуры БД. Создание схемы данных на основе технического задания и анализа предметной области.
3. Задание ограничений целостности. Описание логики проверок, которые БД должна выполнять автоматически при манипулировании данными. Пример: процедура, не позволяющая назначить 3D-фильм в зал, который поддерживает только 2D.
4. Первоначальная загрузка и ведение БД. Заполнение справочной информации (списки городов, стран, сотрудников) при запуске системы.
5. Защита данных и обеспечение восстановления. Организация контуров защиты, резервное копирование и восстановление после сбоев.
6. Анализ обращений пользователей. Отслеживание подозрительной активности (например, DDoS-атак), поиск источника противоречий через логирование сессий, оценка активности сотрудников.
7. Анализ эффективности функционирования. Изучение характера запросов для их оптимизации: введение дополнительных индексов, переписывание запросов на основе рекомендаций встроенных анализаторов СУБД.
8. Работа с конечными пользователями. Выяснение их реальных потребностей для создания нужных аналитических выгрузок, графиков и отчётов.
9. Подготовка и поддержание системных средств. Мониторинг аппаратных ресурсов сервера (память, перегрев), обеспечение корректной работы клиентских приложений, предотвращение «зависания» транзакций, способного привести к частичной записи данных.

Краткие итоги

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

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

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