Я намагаюся отримати остаточну версію того, що є Першою нормальною формою. Все, що я читаю, має дещо інший виток.

Багато органів влади, такі як Дата, кажуть, що за визначенням це відношення завжди знаходиться в Першій нормальній формі, а інші дають перелік вимог. Це означає, що для 1NF є багато нульових вимог.

Я припускаю, що різниця полягає в тому, що між таблицями та відносинами: таблиці можуть бути повним безладом, тоді як відносини дотримуються певних обмежень. Той факт, що відношення представлено у вигляді таблиці в SQL, створює певну плутанину.

Я зосереджуюсь конкретно на 1NF, оскільки це стосується баз даних SQL. Питання полягає в тому, які властивості потрібно забезпечити, щоб таблиця була у першому звичайному вигляді?

Багато органів влади припускають, що якщо таблиця представляє відношення , то вона вже в 1NF. Це підштовхує визначення 1NF до визначення відношення.

Ось деякі властивості таблиці в 1NF:

• Порядок стовпців незначний [1]
• Порядок рядків незначний
• Усі рядки однакової довжини (тобто дані рядків відповідають заголовкам стовпців)
• Немає повторюваних рядків (це можна гарантувати за допомогою сурогатного первинного ключа, але ПК само по собі не потрібно)
• Немає повторюваних стовпців
• Кожен стовпець містить одне значення (атомне)

[1] Технічні атрибути є не упорядкованими, але в таблиці дані рядків повинні бути в тому ж порядку, що і заголовки стовпців. Однак фактичний порядок незначний.

Про кілька даних :

Концепція атомних даних полягає в тому, що деталь не може бути надалі розбита. Ця концепція була кваліфікована тим, що хоча технічно все може бути розбито ad nauseum , ці дані не можуть бути практично зруйновані далі, залежно від того, як будуть використовуватися дані.

Наприклад, повна адреса або повне ім’я зазвичай слід розбивати далі, але такі компоненти, як дане ім'я чи назва міста, ймовірно, не слід більше розбивати, незважаючи на те, що вони можуть бути рядками.

Що стосується повторюваних стовпців, то в стовпчику поганої конструкції є майже повторювані стовпці, наприклад phone1, phone2тощо. Загалом, повторні дані вказують на необхідність додаткової пов'язаної таблиці.

Залежність

Між рядками не повинно бути ніяких зв’язків, окрім того, що вони відповідають однаковим заголовкам.

Між стовпцями також не повинно бути взаємин, але я вважаю, що це є предметом вищих нормальних форм.

Питання полягає в тому, як багато вищезазначеного є у визначенні 1NF? Чи впадають у нього також незалежні рядки?

Попередній

Визначення нормальної форми (яка з презентації «подальшої нормалізації бази даних Relational Model» в 1971 відомий як першої нормальної формі ) і по визначенню реляційної парадигми сама по собі була опублікована в 1970 році в науковій роботі , що при умови сильної основа для практики адміністрування баз даних, тобто, «Реляційна модель даних для великих Shared банків даних» (RM для стислості) , створений доктором Е. Ф. Кодда , який є одержувачем премії Тьюринга і повноваження щодо реляційної бази.

Так, існує багато пояснень, інтерпретацій, експозицій, відхилень та думок щодо тексту доктора Кодда, але я особисто вважаю за краще дотримуватися оригіналу джерела і настійно пропоную проаналізувати його самостійно, щоб можна було зробити власні висновки.

Я, звичайно, не розумію РМ у всій повноті, але те, що я розумію, дозволяє мені оцінити його досконалість, бачення, намір та масштаби, і хоча десятиліттями пізніше можна зазначити, що він має кілька незначних неточностей, вони не зменшуються, у будь-якому разі її геніальність та витонченість. У своїй галузі RM витримала випробування часом унікальним чином і залишається незрівнянною.

Акт наголошування вищезгаданих нарікань був би - використовуючи благодійний термін - несправедливим, оскільки, дивлячись на це з великої відстані, цей насіннєвий матеріал вимагав декількох уточнень та розширень, так, але головна частина роботи була твердою, сама концепція (і, справді, доктор Кодд зробив більшість - якщо не всі - таких удосконалень та розширень).

Я продовжую постійно читати RM, щоб зміцнити своє розуміння цього виняткового джерела знань (і моя пошана до цього постійно зростає з кожним перечитанням); мета - стати на плечі гігантів.

Відносини та таблиці

Важливо зазначити, що оскільки відносини є абстрактними ресурсами, доктор Кодд передбачав корисність їх представлення у табличній формі (спочатку він використовував термін "представлення масиву", але згодом використовував "таблицю" або "r-таблицю"), так що користувачі, дизайнери та адміністратори реляційної бази даних (RDB) можуть звернутися до них більш звичним або конкретним чином. Тому в контексті реалізації RDB доцільно використовувати таблицю як скорочення для зв'язку, поки згадана таблиця означає фактичне відношення. Ця особливість є - досить очевидною - досить істотною, оскільки, перш ніж оцінювати, чи таблиця представляє відношення, яке відповідає першій нормальній формі (1NF), вона повинна представляти саме відношення.

RM, природно, містить ті якості, які повинна мати таблиця, щоб визначити, чи насправді вона зображує відношення, але я запропоную тут неформальну та невибагливу інтерпретацію щодо них (ще одна, так!):

• Він повинен мати ім’я (кожне конкретне відношення в структурі бази даних повинно відрізнятися від решти).
• Кожен з його рядів повинен зображати рівно один кортеж відповідного відношення.
• Порядок її рядків не має значення взагалі.
• Кожен з його стовпців повинен мати ім’я, яке означає значення саме одного домену відповідного відношення, і вказане ім'я повинно відрізнятися від імен решти стовпців таблиці (стовпець повинен бути однозначно диференційований і повинен містити відмінне значення і так, роль, яку відіграють модельєр баз даних та бізнес-експерти для визначення кожної важливої ​​сфери з точністю, першорядна)
• Порядок його стовпців не має ніякого значення.
• Усі його ряди повинні мати однакову кількість стовпців.
• Він повинен мати принаймні один стовпчик або одну комбінацію стовпців, яка однозначно ідентифікує кожен кортеж, зображений за допомогою рядків; таким чином, всі рядки повинні бути різними (так, це підкреслює важливість наявності хоча б одного КЛЮЧОВОГО КЛЮЧУ, а коли є два або більше КЛЮЧІВ, один слід визначати як ПЕРВІЙНИЙ на основі прагматичних причин, тоді як решта можуть бути вважається ВІДПОВІДНИМ, але так, перш ніж приймати рішення, кожен з КЛЮЧІВ був "кандидатом" на визначення як ПЕРВИЧНИЙ).

Маючи таблицю, яка фактично являє собою відношення, є критичною, оскільки, коли вона піддається операціям маніпуляції реляційного типу, тоді результат, знову ж таки, є таблицею, яка представляє відношення. Таким чином, поведінка зазначеної таблиці передбачувана .

Атомні домени (стовпці)

У перших розділах РМ доктор Кодд представляє кілька зразків відносин, щоб ввести деякі поняття; тож, щоб зрозуміти значення атомного домену , почнемо із наступного уривку з RM, який детально описує деякі відповідні моменти:

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

Таким чином, можна сказати, що кожне з вищезгаданих описувальних відносин відповідає одному з двох видів, скажімо, або роду A або роду B :

• Вид A групи лише відносини (таблиці), структуровані з доменами (стовпцями), які містять виключно прості значення у кожному з їх кортежів (рядків), тобто такі домени (стовпці) не містять відносин (таблиць) як значень, які в цей контекст означає, що значення є атомними, оскільки їх не можна послідовно розкласти на нові відносини (таблиці). Отже, відносини цього класу є нормалізованими , тобто вони відповідають 1NF, їх форма бажана.

• Вид B винятково інтегрований відносинами (таблицями), які мають один або більше доменів (стовпців), які містять відносини як значення у кожному відповідному кортежі (рядку), і це означає, що ці значення неотомічні, оскільки вони можуть бути згодом розбиті на нові відносини (таблиці), тобто їх можна розкласти . Таким чином, відносини такого роду є ненормалізованими, тобто вони зачіпають 1NF, вони знаходяться в небажаній формі.

Нормалізація

Доктор Кодд представляє розділ про нормалізацію роботи в RM з наступним пунктом:

Відношення, домени яких просто всі, може бути представлене в сховищі двовимірним однорідним масивом стовпців такого типу, про які йшлося вище. Деякі складніші структури даних необхідні для зв'язку з одним або кількома непростими доменами. З цієї причини (та інших, які будуть наведені нижче) можливість усунення непростих доменів варто вивчити! Насправді існує дуже проста процедура усунення, яку ми назвемо нормалізацією.

Потім він продовжує показувати:

1. Група відносин, де людина ненормалізований (має домени, які містять відносини як значення, тобто вони неотомічні; тобто вони непрості)

2. Група відносин, які є нормалізованими (тобто такі, які були розкладені; тобто такі, які відносять цінні домени, були розбиті на прості, що означає, що вони атомні)

А потім він описує процедуру отримання нормалізованих відносин від ненормалізованих.

У цьому відношенні відносини, які він використовував для ілюстрації нормування та опис вправи, є цілком зрозумілими, і я рекомендую ще раз проаналізувати їх самостійно (і я сподіваюся, що це спонукає деяких читачів брати участь у тексті).

Послідовно він вказує:

Можливі подальші операції нормалізуючого виду. Вони не обговорюються в цій роботі.

І зазначені операції, тобто друга і третя нормальна форма (2NF і 3NF), фактично детально описані в «Подальшій нормалізації реляційної моделі бази даних», і як було сказано вище, після презентації (та подальшого друку та публікації) цього документу , первісна нормальна форма стала називатися першою нормальною формою.

Як зауважує практик, наявність ненормалізованих відносин (таблиць) вносить (майже завжди непотрібне) згортання в реалізацію RDB.

Відношення, що задовольняє 1NF, полегшує визначення обмежень та операцій з маніпулювання даними, які можуть бути реалізовані за допомогою підмовлення даних, що є менш складним, ніж необхідне для ненормалізованих відносин (таблиць), на що доктор Кодд вказує у наступних рядках:

Прийняття реляційної моделі даних, як описано вище, дозволяє розробити універсальний підязик даних на основі застосованого предикатного числення. Обчислення предикатів першого порядку достатньо, якщо збір відносин у нормальній формі. Така мова могла б забезпечити міркування мовної сили для всіх інших запропонованих мов даних, і сама була б сильним кандидатом для вбудовування (з відповідною синтаксичною модифікацією) у різні мови хостів (програмування, орієнтування на команду чи проблеми). […]

[…]

Універсальність підмовного мовлення даних полягає в його описовій здатності (а не в обчислювальній здатності).

Здивування

З моєї точки зору, здивування виникло через (a) вищезазначене перевищення інтерпретацій, пояснень тощо, близько 1NF та самої РМ, і через (b) подальших спроб переробити 1NF, що стверджує, що стосунки мають з доменами, які містять значення, які, у свою чергу, стосуються, відповідають 1NF, якщо вони є одним єдиним значенням для кожного відповідного кортежу.

Моє перейняти ваші інші точки

Між рядками не повинно бути ніяких зв’язків, окрім того, що вони відповідають однаковим заголовкам.

Я не впевнений, чи правильно я розумію намір цього твердження, але, крім відповідності тим самим заголовкам, має бути з'єднання між (кортежами) рядками відношення (таблиця), оскільки кожен з них повинен бути твердженням про особливе виникнення конкретного типу суб'єкта господарювання (визначеного в контексті бізнес-контексту), яке стосується (таблиця).

Між стовпцями також не повинно бути взаємин, але я вважаю, що це є предметом вищих нормальних форм.

Я не знаю, чи правильно я тлумачу значення цього твердження, але, власне, і відповідно до моєї відповіді на попередній аспект, між доменами (стовпцями) відносини (таблиці) також повинен бути взаємозв'язок , саме тому це співвідношення (істотна структура реляційної моделі та конкретна реалізація RDB).

Як приклад, стосовно гіпотетичного відношення (таблиця)

• Salary (PersonNumber, EffectiveDate, Amount)

кортеж (ряд)

• Salary (x, y, z)

передав би сенс

• The Salary payed to the Person identified by PersonNumber x, on EffectiveDate y corresponds to the Amount of z

Тому кожен кортеж (рядок) Salaryспіввідношення (таблиці) повинен відповідати структурі твердження, показаному вище, і різниця буде заміною значень відповідного домену (стовпця), але має існувати залежність між (a) всі Salaryдомени (стовпці), а також між (b) всі відповідні їм значення стосовно кожного кортежу (рядка); такі відносини незамінні.

Вищі нормальні форми (2NF та 3NF) корисні для позбавлення від функціональних залежностей між доменами (стовпцями) відношення (таблиця), вони допомагають уникнути небажаних зв’язків між доменами (стовпцями), оскільки зазначені небажані з'єднання дозволяють ввести аномалії оновлення . І 2NF, і 3NF корисні для перевірки надійності структури відносин (таблиць) у певній реалізації RDB.

Ілюстрація. Візьміть текстовий рядок, який містить типову адресу США:

"123 Cornhusk Rd., South Succotash, NY 12345"

Написання запиту, щоб знайти всіх жителів Корнушук-Роуд або конкретного жителя міста Південний Сукоташ або штату Нью-Йорк, було б непростим завданням. Особливо, коли у даних є такі рядки:

"123 Cornhusk Road, South Succotash, NY 12345"
"123 Cornhusk Rd., South Succotash, New York 12345"
"123 Cornhusk, South Succotash, NY 12345"
"123 Cornhusk Rd., SOUTH SUCCOTASH, NY 12345"

Кожен із них вказує ту саму фактичну адресу (і це навіть не враховує ймовірних неправильних написань на зразок "Succatash"), але написання алгоритму для їх успішного порівняння - це те, чого я НЕ хотів би присвятити останнім своїм останнім рокам на цій Землі.

Введіть першу звичайну форму. Я не буду вникати в деталі того, як це робиться, просто розглянемо загальну форму, як це спостерігається в більшості баз даних:

create table Addresses(
  ...
  Street  varchar,
  City    int        references Cities( ID ),
  State   char( 2 )  references States( ID ),
  Zip     int
  ...
);

Це не повна нормалізація. Наприклад, ви можете далі розділити Street на StreetNum і StreetName, але це досить далеко для простої ілюстрації, і це дійсно приблизно настільки, наскільки процес нормалізації проводиться в реальному житті. Існує ще невелика проблема пошуку всіх мешканців «Кукурузної дороги», але якщо ви шукали вулицю для підрядка «Кукурузник» і десь траплялося місто з назвою Корнуск, принаймні це не спричинило б заплутаності.

Проблема з визначенням, яке надає Date, та ін., Полягає в тому, що вони не вдається заглянути всередину фрагмента даних і врахувати значення цих даних. Не те, що я їх особливо звинувачую, це може бути досить складно.

Тому ми повинні взяти "рядок символів" і перетворити його на "адресу". Але придумати всеосяжне визначення адреси не так просто, як здається. Особливо при роботі з адресами в більш ніж одній країні.

Спочатку ми фіксуємо контекст. Ніщо не має сенсу без контексту. Наш контекст тут - адреса . У цьому контексті ми можемо побачити частини даних, які мають конкретні значення, наприклад, вулиця , місто тощо. Кожному значенню призначаємо окреме поле.

Важкою частиною є те, що дані, як слова, можуть мати різний зміст для різних людей, або деякі люди можуть бачити сенс там, де інших немає. Це може бути проектом все для себе і вимагає великих зусиль для співпраці. Але це важливий елемент хорошого дизайну баз даних.

Суть нормалізації полягає у усуненні або принаймні мінімізації аномальних даних. Розглянемо той факт, що у таблиці вище може бути введено місто чи поштовий індекс, який не існує у вибраному стані. Або введена вулиця, яка насправді не існує у вибраному місті. Ах, але зараз ми переходимо до другої та третьої нормальної форми, і це вже інша тема.

Розгляньте 1NF як вступ до математичної концепції відносин, а не конкретну структуру даних або фіксований набір правил. Математичні структури на зразок відносин можуть бути представлені по-різному - таблиці - це лише один із найзручніших способів. При використанні таблиць існують обмеження для того, щоб вони чітко відображали призначені відносини і що операції над таблицями були логічно обгрунтованими щодо представлених відносин.

Коли ми кажемо, що порядок стовпців та рядків та дублювання є незначними, це означає, що вся значна інформація записується як значення в таблиці та є доступною для наших запитів, а не кодується у поданні таблиці. Хоча мало хто, якщо такий є, автори прямо заборонили використовувати колір у таблицях, розуміння мети вищезазначених обмежень призведе до того, що аналогічно виключити використання значущих кольорів презентації, так що значні значення кольорів повинні бути явно записані. Дані та інші автори також знецінюють приховані ідентифікатори рядків з тієї ж причини.

Концепція атомарності полягає у тому, щоб вся значна структура була виражена у відносинах, щоб ми могли проаналізувати залежності у всіх наших даних та запобігти аномаліям, і щоб вся змістовна структура була рівномірно доступною для реляційних операцій. Складені значення не є недійсними, але вони вимагають розпакувати конкретні доменні оператори, що збільшує складність, і вони можуть ввести надмірність. Звичайно, на практиці деякі прості складені типи та пов'язані з ними оператори зручні та допомагають збільшити компактність та експресивність запитів, але це не суперечить теорії.

Рядкові залежності, як багатозначні залежності, не порушують 1NF, але подібно залежності серед стовпців є предметом вищих нормальних форм. Близько повторювані стовпці, як phone1, phone2тощо, також не порушують 1NF, навіть якщо вони поганий дизайн.

Визначення і пояснення з вікіпедії про 1NF, я думаю , що це дуже добре. - жоаноло

Розширення на одне речення у статті Вікіпедії:

Текст не атомний

Це може допомогти вам зрозуміти, чому так багато плутанини. Якщо це лише заклик тексту, то це атомний. Але якщо це розглядається як телефонні номери, то це не атомний. Дата та інші сторони вирішують це питання. Це стосується того, що означають дані. Аналізуючи тему, вам доведеться зрозуміти, що означають дані.

Чи є сенс далі її розбити, має відношення до питання, чи була дотримана перша нормальна форма. Справа за 1NF полягає в наданні доступу до всіх даних. Але якщо річ, яку ви отримуєте через ключ, має підструктуру, то у вас немає доступу до підструктури. - Вальтер Мітті

"1NF" використовується для позначення купки різних речей , багато з яких одночасно є безглуздими і загальними. Дивіться мою відповідь на "Нормалізація в системі управління базами даних" , включаючи її посилання. Одним із таких є моя відповідь на тему "Що таке атомність у dbms" . (Обидва у стеку переповнення.) - філіпсі

_{Відповідь Вікі спільноти створена з коментарів, залишених до питання}