Что такое атомарность в дБмс
Я читал что-то вроде ниже в 1NF форме СУБД.
Было следующее предложение:
"Каждый столбец должен быть атомарным".
Может кто-нибудь, пожалуйста, объясните мне подробно с примером?
4 ответа
"Каждый столбец должен быть атомарным".
Крис Дэйт говорит: "Пожалуйста,обратите внимание, что не только простые вещи, такие как целое число 3, являются допустимыми значениями. Напротив, значения могут быть произвольно сложными, например, значение может быть геометрической точкой или многоугольником, или рентгеновский луч, или документ XML, или отпечаток пальца, или массив, или стек, или список, или отношение (и т. д.)."[1]
Он также говорит: "Relvar находится в 1NF тогда и только тогда, когда в каждом допустимом значении этого relvar каждый кортеж содержит ровно одно значение для каждого атрибута". [2]
Обычно он не одобряет использование слова " атомный", потому что оно имеет запутанную коннотацию.Одно значение, вероятно, лучше использовать термин.
Например, дата типа "2014-01-01" является одним значением. Это не неделимо; напротив, это вполне ясно делится. Но DBMS делает одну из двух вещей с отдельными значениями, которые имеют части. DBMS либо возвращает эти значения в целом, либо DBMS предоставляет функции для управления частями. (Клиенты не должны писать код для управления деталями.)[3]
В случае дат SQL может
- вернуть даты в целом (
SELECT CURRENT_DATE), - вернуть одну или несколько частей даты (
EXTRACT(YEAR FROM CURRENT_DATE)), - складывать и вычитать интервалы (
CURRENT_DATE + INTERVAL '1' DAY), - вычесть одну дату из другой (
CURRENT_DATE - DATE '2014-01-01'),
и так далее. В этом (узком) отношении SQL довольно реляционный.
- Введение в системы баз данных, 8-е изд., Стр. 113. Акцент в оригинале.
- Там же, стр. 358.
- В случае "пользовательского" типа "пользователь" считается программистом базы данных, а не клиентом базы данных.
Re "атомный"
В оригинальных работах Кодда за 1969 и 1970 годы он определил отношения как имеющие значение для каждого атрибута в ряду. Значение может быть любым, включая отношение. Здесь не использовалось понятие "атомный". Он объяснил, что "атомарный" означает не оцененный по отношению (то есть не табличный):
До сих пор мы обсуждали примеры отношений, которые определены на простых доменах - доменах, элементами которых являются атомарные (неразложимые) значения. Неатомарные значения могут обсуждаться в рамках отношений. Таким образом, некоторые домены могут иметь отношения как элементы.
Он использовал "простой", "атомарный" и "неразложимый" в качестве нереляционных неформальных объяснительных понятий. Он понял, что отношение имеет строки, с которыми у каждого столбца есть имя и значение; атрибуты по определению "однозначные"; значение любого типа. Единственное структурное свойство, которое имеет значение в отношениях - это отношение. Это также просто значение, но вы можете запросить его. Затем он использовал "непростой" и т. Д., Что означает отношение.
Ко времени выхода книги Кодда 1990 года "Реляционная модель управления базами данных: версия 2":
С точки зрения базы данных, данные можно классифицировать на два типа: атомарные и составные. Атомные данные не могут быть разложены на более мелкие части СУБД (исключая определенные специальные функции). Составные данные, состоящие из структурированных комбинаций атомарных данных, могут быть разложены СУБД.
В реляционной модели существует только один тип составных данных: отношение. Значения в доменах, в которых определяется каждое отношение, должны быть атомарными по отношению к СУБД. Реляционная база данных представляет собой совокупность отношений разных степеней. Все операторы запроса и манипуляции связаны с отношениями, и все они генерируют отношения как результаты. Зачем фокусироваться только на одном типе составных данных? Основная причина заключается в том, что любые дополнительные типы составных данных увеличивают сложность и не увеличивают мощность.
"В реляционной модели существует только один тип составных данных: отношение".
К сожалению, "atomic = non-Relations" - это не то, что вы услышите. (К сожалению, Кодд не был самым ясным автором, и его пояснительные замечания перепутаны с его практическим результатом.) Практически все представления реляционной модели не идут дальше, чем то, что было для Кодда просто ступенькой. Они продвигают бесполезное запутанное нечеткое понятие, канонизированное / канонизированное как "атомарное", определяющее "нормализованное". Иногда они ошибочно используют его для определения реальности. Принимая во внимание, что Кодд использовал повседневное "неатомное", чтобы ввести определение реляционного "неатомного" как отношения и определило "нормализованное" как свободное от отношения доменов.
(И "не повторяющаяся группа" не полезна как "атомарная", определяя ее как нечто, не являющееся даже реляционным понятием. И, конечно же, в 1970 году Кодд говорит, что "термин атрибут и повторяющаяся группа в современной терминологии базы данных примерно аналогичны простому"). домен и непростой домен, соответственно ".)
Например, это неправильное толкование долгое время пропагандировалось Крисом Дейтом, почетным ранним реляционным экспликатором и прозелитизатором, прежде всего в его оригинальной все еще актуальной книге "Введение в системы баз данных". Который сейчас (8-е издание 2004 г.), к счастью, представляет полезное реляционно-ориентированное расширенное понятие различения доменов отношений, строк и "скаляров" (не относящихся к ряду):
Это определение просто утверждает, что все [переменные отношения] находятся в 1NF
Например: классика Майерса " Теория реляционных баз данных" (1983):
Определение атома туманно; значение, которое является атомарным в одном приложении, может быть неатомарным в другом. Для общего руководства значение не является атомарным, если приложение имеет дело только с частью значения.
Например: текущая статья в Википедии, посвященная первому разделу NF (нормальная форма), на самом деле цитирует вводные части выше. И затем игнорирует точное значение. (Затем говорится что-то непонятное о том, когда неатомовые черепахи должны остановиться.)
Кодд утверждает, что "значения в доменах, в которых определяется каждое отношение, должны быть атомарными по отношению к СУБД". Кодд определяет атомарное значение как значение, которое "не может быть разложено на более мелкие части СУБД (исключая определенные специальные функции)", означающее, что поле не должно быть разделено на части, содержащие более одного вида данных, так что одна часть означает для СУБД зависит от другой части того же поля.
Re "нормализовано" и "1NF"
Когда Кодд использовал "нормализовать" в 1970 году, он имел в виду исключение реляционных ("непростых") доменов из реляционной базы данных:
По этой причине (и другим, которые будут приведены ниже) возможность исключения непростых доменов заслуживает изучения. На самом деле существует очень простая процедура исключения, которую мы будем называть нормализацией.
Позднее возникло понятие "высшие НФ" (включая JD (зависимости соединения)), и "нормализация" приобрела другое значение. Поскольку исходная нормализационная теория Кодда всегда давала результаты, применимые ко всем отношениям, а не только к отношениям 1NF Кодда. Таким образом, можно "нормализовать" в первоначальном смысле перехода от справедливых отношений к "нормализованной"/"1NF" форме без столбцов, имеющих отношение к отношениям, и можно "нормализовать" в смысле теории нормализации переход от справедливых отношений, называемых "1NF" "к более высоким NFs, игнорируя, являются ли домены отношениями. И "нормализация" также (плохо) используется для разработки реляционной версии нереляционной базы данных (будь то просто отношения и / или некоторый смысл "1NF").
Реляционный дух состоит в том, чтобы отказаться от нескольких столбцов с одинаковым значением или областей с интересными частями в пользу другой базовой таблицы. Но мы всегда должны прийти к неформальному эргономическому решению о том, когда прекратить представлять детали и просто рассматривать столбец как "атомарный" (не имеющий отношения к значению), а не "неатомный" (имеющий отношение к значению).
Атомность и 1NF... это не об атомарных транзакциях, а об определении и содержании столбцов.
"Атомный" означает "не может быть разделен или разделен на более мелкие части". Применительно к 1NF это означает, что столбец не должен содержать более одного значения. Он не должен составлять или объединять ценности, которые имеют собственное значение.
Это типично касается 2 очень распространенных ошибок, допущенных разработчиками баз данных:
1. несколько значений в одном столбце (список столбцов)
столбцы, которые содержат список значений, как правило, через пробел или через запятую, например, эта таблица сообщений в блоге:
id title date_posted content tags
1 new idea 2014-05-23 ... tag1,tag2,tag3
2 why this? 2014-05-24 ... tag2,tag5
3 towel day 2014-05-26 ... tag42
или эта таблица контактов:
id room phones
4 432 111-111-111 222-222-222
5 456 999-999-999
6 512 888-888-8888 333-3333-3333
Этот тип денормализации встречается редко, так как большинство разработчиков баз данных считают, что это не очень хорошая вещь. Но вы найдете такие таблицы. Обычно они происходят от изменений в базе данных, в то время как может показаться, что проще расширить столбец и использовать его для заполнения нескольких значений вместо добавления нормализованной связанной таблицы (которая часто нарушает существующие приложения).
2. сложные многокомпонентные колонны
В этом случае один столбец содержит разные биты информации и может быть спроектирован как набор отдельных столбцов.
Типичным примером являются полные имена и адресные столбцы:
id fullname address
1 Mark Tomers 56 Tomato Road
2 Fred Askalong 3277 Hadley Drive
3 May Anne Brice 225 Century Avenue - apartment 43/a
Эти типы денормализаций очень распространены, так как довольно трудно провести черту и то, что является атомным, а что нет. В зависимости от применения, столбец из нескольких частей вполне может быть лучшим решением в некоторых случаях. Это менее структурировано, но проще.
Структурирование адреса во многих атомарных столбцах может означать наличие более сложного кода для обработки результатов для вывода. Другая сложность связана с тем, что структура не подходит для всех типов адресов. Использование одного столбца VARCHAR не создает этой проблемы, но может создавать другие... как правило, для поиска и сортировки.
Крайним случаем столбцов из нескольких частей являются даты и время. Большинство СУБД предоставляют типы данных даты и времени и предоставляют функции для обработки алгебры даты и времени и извлечения различных битов (месяц, час и т. Д.). Мало кто посчитает удобным иметь отдельные столбцы year, mont, day в реляционной базе данных. Но я видел это... и по веским причинам: случай использования был датой рождения для базы данных министерства юстиции. Им приходилось обращаться со многими иммигрантами с небольшим количеством документов или вообще без них. Иногда вы просто знали, что человек родился в определенный год, но вы не знали бы ни дня, ни месяца, ни рождения. Вы не можете обработать этот тип информации с одним столбцом даты.
Это означает, что столбец не должен содержать несколько значений (например, значения, разделенные запятыми).
Пожалуйста, смотрите ссылку ниже.