Что такое атомарность в dbms

Ответ 1

"Каждый столбец должен быть атомарным".

Chris Date говорит: "Пожалуйста, обратите внимание очень осторожно, что это не просто простые вещи, как целое число 3. Это законные значения. Напротив, значения могут быть сколь угодно сложными, например, значение может быть геометрической точкой или многоугольник или рентгеновский снимок, или XML-документ, или отпечаток пальца, или массив, или стек, или список, или отношение (и т.д.)." [1]

Он также говорит: "relvar находится в 1NF тогда и только тогда, когда в каждом юридическом значении этого реврара каждый кортеж содержит ровно одно значение для каждого атрибута". [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.
• В случае "определяемого пользователем" типа "пользователь" считается программистом базы данных, а не клиентом базы данных.

Ответ 2

Re "atomic"

В оригинале Кодда 1969 года и 1970 он объяснил, что "атомный" означает не относящийся к значению (т.е. не табличный):

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

Он использовал "простые", "атомные" и "неразложимые" как нереляционные неформальные пояснительные понятия. Он понимал, что отношение имеет строки, из которых каждый столбец имеет ассоциированное имя и значение, и какое бы то ни было значение ( "одиночное" ) не было. Единственное структурное свойство, которое имеет отношение к реляционным отношениям, является отношением. Это также просто значение, но вы можете запросить его. Затем он использовал "непростые" и т.д., Что означает отношение.

К моменту выпуска книги Codd 1990 Реляционная модель для управления базой данных: версия 2:

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

В реляционной модели существует только один тип составных данных: связь. Значения в областях, на которых определяется каждое отношение должны быть атомарными относительно СУБД. Реляционная База данных - это совокупность отношений разных степеней. Все операторы запросов и манипуляций находятся на отношениях, и все они генерировать отношения как результаты. Зачем сосредотачиваться только на одном типе соединения данные? Основная причина заключается в том, что любые дополнительные типы составных данных добавьте сложность без добавления мощности.

"В реляционной модели есть только один тип составных данных: отношение."

К сожалению, "атомный = не отношение" - это не то, что вы собираетесь услышать. (К сожалению, Кодд не был самым ясным писателем, и его объяснительные замечания путаются с его нижней строкой.) Практически все презентации реляционной модели не имеют ничего общего с тем, что было для Кодда просто ступенью. Они пропагандируют бесполезное запутанное нечеткое понятие, канонизированное/канонизированное как "атомное", определяющее "нормированное". В то время как Кодд использовал повседневные "неатомические", чтобы вводить определяющие реляционные "неатомические" как отношения-значные и определенные "нормированные" как свободные от отношениязначных областей.

(Также не "повторяющаяся группа" не является "атомарной" ), определяя ее как не что-то, что даже не является реляционным понятием. И, конечно же, в 1970 году Кодд говорит: "Термины терминов и повторяющаяся группа в настоящей терминологии базы данных примерно аналогично простой области и непростой области, соответственно". "Примерно аналогичный".)

Например: Это неправильное толкование продвигалось в течение долгого времени с самого начала Крисом Даном, почетным ранним реляционным объяснителем и прозелитизмом, в первую очередь в его оригинальной книге "Введение в системы баз данных". Который теперь (2004 8-е издание) с благодарностью представляет полезное реляционно-ориентированное расширенное понятие отличительных отношений, строк и "скалярных" (не связанных между собой) доменов:

В этом определении просто указано, что все [переменные отношения] находятся в 1NF

Например: классика Майера Теория реляционных баз данных (1983):

Определение атома является туманным; значение, которое является атомарным в одном приложении, может быть неатомным в другом. Для общего руководства значение неатомное, если приложение имеет дело только с частью значения.

Например: Текущая статья Википедии о первом разделе нормальной формы. Атоматичность фактически цитируется из вводных частей выше. И затем игнорирует точный смысл. (Тогда он говорит что-то непонятное о том, когда неатомные черепахи должны остановиться.):

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

Re "normalized" и "1NF"

Когда Codd использовал "нормализацию" в 1970 году, он имел в виду исключить отношения ( "непростые" ) домены из реляционной базы данных:

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

Позже возникло понятие "высших нормальных форм" (включая зависимость от объединения), и "нормализация" приобрела другое значение. В теории нормализации быть в 1-й нормальной форме всегда означало просто быть отношением. Таким образом, можно "нормализовать" в первоначальном смысле переход от справедливых отношений к "нормированной" форме без ссылочных столбцов, и можно "нормализовать" в смысле теории нормализации переход от справедливых отношений aka "1NF" к более высокому нормальной формы, игнорируя, являются ли домены отношениями. И "нормализация" также используется для разработки реляционной версии нереляционной базы данных (либо в 1NF, либо без отношения к нормализу).

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

Ответ 3

Atomicity и 1NF... это не об атомных транзакциях, а об определении и содержимом столбца.

"Атомная" означает "не может быть разделена или разделена на более мелкие части". Применительно к 1NF это означает, что столбец не должен содержать более одного значения. Он не должен составлять или комбинировать значения, имеющие свой собственный смысл.

Это типично относится к двум очень распространенным ошибкам разработчиков баз данных:

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 не создает этой проблемы, но может представлять другие... как правило, для поиска и сортировки.

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

Ответ 4

это означает, что столбец не должен содержать несколько значений (например, разделенные запятыми значения).

plz см. ниже ссылку.

http://www.studytonight.com/dbms/database-normalization.php