26 Окт
В мире, где данные являются ключевым активом, доминирующее положение по-прежнему занимают реляционные системы управления базами данных (СУБД), такие как MySQL, PostgreSQL, Oracle и SQL Server. Их популярность основана на принципах надежности, согласованности и предсказуемости, которые были заложены более полувека назад.
В основе этой надежности лежит реляционная модель данных, разработанная математиком IBM Эдгаром Ф. Коддом в 1970-х годах. Чтобы система называлась по-настоящему реляционной, она должна соответствовать набору строгих критериев, известных как 13 Правил Кодда (нумерация которых начинается с нуля). Эти правила — конституция для любой серьезной СУБД, гарантирующая целостность и точность информации.
Почему Реляционные БД Не Сдают Позиций: Свойства ACID
Главное, что отличает реляционные СУБД от большинства новомодных NoSQL решений, — это гарантия соблюдения знаменитых свойств ACID:
- Атомарность (Atomicity): Транзакция выполняется либо полностью, либо не выполняется вообще. При частичном сбое все изменения откатываются.
- Согласованность (Consistency): База данных всегда переходит из одного корректного состояния в другое. Нарушающие правила операции (например, попытка списать больше денег, чем есть на счету) отклоняются.
- Изолированность (Isolation): Несколько транзакций, выполняемых одновременно, не должны мешать друг другу. Каждая транзакция видит базу данных в согласованном состоянии.
- Долговечность (Durability): Как только данные зафиксированы (закоммичены), они сохраняются и не будут потеряны даже в случае системного сбоя.
Ключевые Понятия Реляционной Модели
Прежде чем перейти к правилам, важно усвоить терминологию, которая делает модель Кодда столь строгой и мощной:
- Отношение (Relation): Соответствует привычной таблице (например,
Students). - Кортеж (Tuple): Соответствует одной строке или записи в таблице.
- Атрибут (Attribute): Соответствует столбцу в таблице (например,
Имя,Факультет). - Домен (Domain): Множество всех допустимых значений для конкретного атрибута (например, для поля
Городдомен может быть ограничен пятью городами, в которых работает компания). - Атомарность Значений: Каждый атрибут в кортеже должен хранить одно, неделимое значение (например, телефонный номер целиком, а не разделенный на код страны и локальный номер).
- NULL: Специальный маркер, обозначающий отсутствие или неизвестность значения. Важно: NULL — это не ноль и не пустая строка. Чрезмерное использование NULL усложняет запросы и может привести к логическим ошибкам.
- Ключи:
- Первичный Ключ (Primary Key, PK): Один или несколько атрибутов, которые уникально идентифицируют каждый кортеж. Поле с PK никогда не может содержать NULL.
- Внешний Ключ (Foreign Key, FK): Ссылка на первичный ключ другого отношения, которая связывает данные между таблицами и обеспечивает целостность ссылок.
Разбор 13 Правил Кодда (Правила 0-12)
Хотя на практике ни одна современная СУБД не соблюдает все правила на 100%, именно эти принципы формируют основу нашего понимания надежных баз данных.
Фундаментальные Принципы (0-4)
| Правило | Название | Суть и Значение |
| 0 | Фундаментальное | СУБД должна управляться целиком с помощью своих реляционных возможностей (таблиц, кортежей, связей). Исключается обращение к низкоуровневым указателям или физическим путям. |
| 1 | Правило Информации | Вся информация, включая пользовательские данные и метаданные, должна быть представлена только одним способом: как явные значения в ячейках таблиц. |
| 2 | Гарантированный Доступ | Каждый атомарный элемент данных должен быть логически доступен через комбинацию: Имя Таблицы + Значение Первичного Ключа + Имя Столбца. |
| 3 | Систематическое Обращение с NULL | Неизвестные значения должны систематически обрабатываться как NULL (отличный от нуля, пустой строки или иного известного значения), поддерживая трехзначную логику (True, False, Unknown). |
| 4 | Динамический Онлайн-Каталог | Описание базы данных (метаданные) должно храниться в виде обычных реляционных таблиц, к которым можно обращаться с помощью того же реляционного языка (например, SQL). |
Правила Языка и Независимости (5-9)
| Правило | Название | Суть и Значение |
| 5 | Комплексный Язык Данных | Должен существовать хотя бы один реляционный язык (SQL), поддерживающий все операции: определение данных (DDL), манипуляцию данными (DML), определение представлений, ограничения целостности, авторизацию и границы транзакций. |
| 6 | Обновление Представлений (View) | Все представления (виртуальные таблицы), которые теоретически могут быть обновлены, должны быть обновлены системой (изменения должны каскадно применяться к базовым таблицам). |
| 7 | Высокоуровневые Операции | Операции вставки, обновления и удаления должны быть применимы не только к одному кортежу, но и к целым наборам данных (Set-at-a-Time). |
| 8 | Физическая Независимость | Приложения не должны изменяться при изменении методов физического хранения данных (например, перенос таблицы на другой диск, изменение индексации). |
| 9 | Логическая Независимость | Приложения, не использующие новые столбцы или разделенные таблицы, не должны ломаться при изменении логической структуры (например, при добавлении нового столбца или разделении одной таблицы на две, если предоставляется View, имитирующий старую структуру). |
Правила Целостности и Распределения (10-12)
| Правило | Название | Суть и Значение |
| 10 | Независимость Целостности | Ограничения целостности (check, not null, primary key) должны быть определены и храниться в самом реляционном подязыке (SQL), а не в коде прикладных программ. Это гарантирует корректность данных независимо от приложения. |
| 11 | Независимость от Распределения | Приложения должны оставаться логически неизменными, независимо от того, распределены ли данные физически по нескольким узлам или хранятся на одном компьютере. Распределение должно быть прозрачным для пользователя. |
| 12 | Запрет Подрыва Системы | Любой низкоуровневый доступ к данным (например, через специальный API) не должен позволять обходить или нарушать правила целостности, определенные высокоуровневым реляционным языком. Целостность данных должна быть абсолютной. |
Понимание этих правил позволяет разработчику проектировать не просто работающие, но и по-настоящему надежные, масштабируемые и долговечные системы. Реляционная модель остается фундаментом серьезной разработки, и знание ее основ — это залог профессионального успеха в IT.
