Ответ 1

Хорошо, если бы мне пришлось объяснить это моей жене, это было бы примерно так:

Основная идея - избежать дублирования больших данных.

Позвольте взглянуть на список людей и страну, из которой они пришли. Вместо того, чтобы держать имя страны, которая может быть до тех пор, пока "Босния и Герцеговина" для каждого человека, мы просто держим число, которое ссылается на таблицу стран. Поэтому вместо того, чтобы держать 100 "Боснии и Герцеговины", мы держим 100 # 45. Теперь, в будущем, как это часто бывает с балканскими странами, они разделились на две страны: Боснию и Герцеговину, мне придется менять ее только в одном месте. ну, вроде.

Теперь, чтобы объяснить 2NF, я бы изменил этот пример и предположил, что мы проводим список стран, в которые каждый посетил каждого. Вместо того, чтобы держать таблицу как:

Person   CountryVisited   AnotherInformation   D.O.B.
Faruz    USA              Blah Blah            1/1/2000
Faruz    Canada           Blah Blah            1/1/2000

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

Ответ 2

Отношение "один ко многим" должно быть представлено как две отдельные таблицы, связанные внешним ключом. Если вы попытаетесь перевести логическое отношение "один ко многим" в одну таблицу, то вы нарушаете нормализацию, что приводит к опасным проблемам.

Скажите, что у вас есть база данных ваших друзей и их кошек. Поскольку у человека может быть более одной кошки, у нас есть отношения "один ко многим" между людьми и кошками. Это требует двух таблиц:

Friends
Id | Name | Address
-------------------------
1  | John | The Road 1
2  | Bob  | The Belltower


Cats
Id | Name   | OwnerId 
---------------------
1  | Kitty  | 1
2  | Edgar  | 2
3  | Howard | 2

(Cats.OwnerId является внешним ключом для Friends.Id)

Вышеупомянутая конструкция полностью нормализована и соответствует всем известным уровням нормализации.

Но скажу, что я попытался представить приведенную выше информацию в одной таблице следующим образом:

Friends and cats
Id | Name | Address       | CatName
-----------------------------------
1  | John | The Road 1    | Kitty     
2  | Bob  | The Belltower | Edgar  
3  | Bob  | The Belltower | Howard 

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

Eg. если Боб движется, я должен убедиться, что я меняю адрес в обеих строках. Если Боб получает еще одну кошку, я должен обязательно повторить имя и адрес точно так же, как и в двух других строках. Например. если я сделаю опечатку в адресе Боба в одной из строк, вдруг в базе данных будет непоследовательная информация о том, где живет Боб. Не нормированная база данных не может препятствовать введению непоследовательных и противоречивых данных, и, следовательно, база данных не является надежной. Это явно неприемлемо.

Нормализация не может помешать вам ввести неверные данные. То, что предотвращает нормализация, - это возможность несогласованных данных.

Важно отметить, что нормализация зависит от бизнес-решений. Если у вас есть база данных клиентов, и вы решили записать только один адрес для каждого клиента, тогда дизайн таблицы (#CustomerID, CustomerName, CustomerAddress) будет прекрасен. Если, однако, вы решите, что вы разрешаете каждому клиенту регистрировать более одного адреса, то тот же дизайн таблицы не нормализуется, потому что теперь у вас есть отношения "один ко многим" между клиентом и адресом. Поэтому вы не можете просто взглянуть на базу данных, чтобы определить, нормализована ли она, вам нужно понять бизнес-модель за базой данных.

Ответ 3

Вот что я спрашиваю у интервьюируемых:

Почему мы не используем таблицу single для приложения вместо использования таблиц multiple?

Ответ - нормализация. Как уже говорилось, его следует избегать избыточности и там, благодаря аномалиям обновления.

Ответ 4

Это не полное объяснение, но одна из целей нормализации - обеспечить рост без неловкости.

Например, если у вас есть таблица user, и каждый пользователь будет иметь один и только один номер телефона, отлично иметь столбец phonenumber в этой таблице.

Однако, если каждый пользователь будет иметь переменное количество телефонных номеров, было бы неудобно иметь такие столбцы, как phonenumber1, phonenumber2 и т.д. Это происходит по двум причинам:

• Если ваши столбцы поднимаются до phonenumber3, а кому-то нужно добавить четвертое число, вам нужно добавить столбец в таблицу.
• Для всех пользователей с менее чем 3 телефонными номерами в своих строках есть пустые столбцы.

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

Ответ 5

Одна сторона указывает на нормализацию: полностью нормализованная база данных является пространственной эффективностью, но не обязательно является наиболее эффективным временем обработки данных в зависимости от шаблонов использования.

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

Для получения дополнительной информации об этом, найдите книги SQL, написанные Кеном Хендерсоном.

Ответ 6

Я бы сказал, что нормализация похожа на то, что записи замечены эффективно, так сказать:

Если у вас была записка, в которой говорилось, что вам нужно ходить по магазинам для мороженого без нормализации, вы должны были бы еще одно замечание, в котором говорится, что вам нужно идти покупки мороженого, только один в каждый карман.

Теперь, в реальной жизни, вы никогда не будете делать это так, зачем это делать в базе данных?

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

• В таблице не должно быть повторяющихся групп информации.
• Ни одна таблица не должна содержать данные, которые не зависят от основного файла таблиц
• Для 3NF мне нравится, как Билл Кент берет на себя: каждый неключевой атрибут должен предоставлять информацию о ключе, ключе целиком и ничего, кроме ключа.

Я думаю, что это может быть более впечатляющим, если вы говорите также о денормализации и о том, что у вас не всегда может быть лучшая структура и быть в нормальных формах.

Ответ 7

Нормализация - это набор правил, которые используются для создания таблиц, связанных через отношения.

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

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

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

Третья нормальная форма: каждый неклассический столбец не должен зависеть от других неключевых столбцов. Например, в таблице заказов столбец "Всего" зависит от "Цена за единицу" и "количество", поэтому столбец "Всего" должен быть удален.

Ответ 8

Я преподаю нормализацию в моих курсах доступа и разбиваю их несколькими способами.

После обсуждения прекурсоров с раскадрой или планирования базы данных, я затем вникаю в нормализацию. Я объясняю следующие правила:

Каждое поле должно содержать наименьшее значащее значение:

Я пишу поле имени на доске, а затем помещаю в него имя и фамилию, как Билл Лемберг. Затем мы запрашиваем у студентов и спрашиваем их, с чем у нас будут проблемы, когда первое имя и фамилия находятся в одном поле. В качестве примера я использую свое имя, которое Джим Ричардс. Если ученики не ведут меня по дороге, я держу их за руку и беру с собой.:) Я говорю им, что мое имя - это тяжелое имя для некоторых, потому что у меня есть то, что некоторые люди рассмотрят 2 первых имени, а некоторые меня называют Ричардом. Если вы пытались найти свою фамилию, это будет труднее для обычного человека (без подстановочных знаков), потому что моя фамилия похоронена в конце поля. Я также говорю им, что у них будут проблемы с удобной сортировкой поля по фамилии, потому что снова моя фамилия похоронена в конце.

Затем я даю им понять, что значимость основана на аудитории, которая также будет использовать базу данных. Мы, в нашей работе, не будем нуждаться в отдельном поле для номера квартиры или номера, если мы храним адреса людей, но судоходные компании, такие как UPS или FEDEX, могут нуждаться в этом, чтобы они могли легко вытащить квартиру или пакет, куда им нужно идти, когда они находятся в дороге и работают от поставки до доставки. Таким образом, это не имеет смысла для нас, но это определенно имеет значение для них.

Избегание пробелов:

Я использую аналогию, чтобы объяснить им, почему они должны избегать пробелов. Я говорю им, что Access и большинство баз данных не хранят пробелы, такие как Excel. Excel не волнует, если вы ничего не набрали в ячейке и не увеличите размер файла, но Access сохранит это пространство до этого момента времени, когда вы действительно будете использовать это поле. Поэтому, даже если он пуст, он все равно будет использовать пространство и объяснить им, что он также замедляет их поиск. Аналогия, которую я использую, - это пустые коробки для обуви в шкафу. Если у вас есть боксы для обуви в шкафу, и вы ищете пару ботинок, вам нужно будет открыть и посмотреть в каждой коробке на пару ботинок. Если есть пустые боксы для обуви, вы просто теряете пространство в шкафу, а также тратите время, когда вам нужно просмотреть их для этой определенной обуви.

Предотвращение избыточности данных:

Я показываю им таблицу с множеством повторяющихся значений для информации о клиенте, а затем скажу им, что мы хотим избежать дубликатов, потому что у меня есть колбасные пальцы и будут ошибочными в значениях, если мне придется снова и снова вводить одно и то же еще раз. Это "жир-пальцы" данных приведет к тому, что мои запросы не найдут правильные данные. Вместо этого мы разбиваем данные на отдельную таблицу и создаем отношения с использованием поля первичного и внешнего ключей. Таким образом мы экономим место, потому что мы не набираем имя, адрес и т.д. Несколько раз, а вместо этого просто используем идентификационный номер клиента в поле для клиента. Затем мы обсудим выпадающие списки/комбинированные поля/списки поиска или все, что Microsoft хочет назвать позже.:) Вы как пользователь не захотите искать и набирать номер клиента каждый раз в этом поле клиента, поэтому мы настроим раскрывающийся список, который даст вам список клиентов, где вы можете выбрать их имя и он заполнит идентификатор клиентов для вас. Это будет отношение "один ко многим", тогда как у 1 клиента будет много разных заказов.

Избегание повторяющихся групп полей:

Я демонстрирую это, когда говорю о взаимоотношениях "многие ко многим". Во-первых, я рисую 2 таблицы, 1 которые будут содержать информацию о сотрудниках и 1, которые будут содержать информацию о проекте. Таблицы расположены аналогично этому.

(Table1)
tblEmployees
* EmployeeID
First
Last
(Other Fields)….
Project1
Project2
Project3
Etc.
**********************************
(Table2)
tblProjects
* ProjectNum
ProjectName
StartDate
EndDate
…..

Я объясняю им, что это не будет хорошим способом установления отношений между сотрудником и всеми проектами, над которыми они работают. Во-первых, если у нас есть новый сотрудник, тогда у них не будет никаких проектов, поэтому мы будем тратить впустую все эти поля, во-вторых, если сотрудник здесь уже давно, тогда они могли бы работать над 300 проектами, поэтому мы бы включая 300 полей проекта. Те люди, которые являются новыми и имеют только 1 проект, будут иметь 299 проектов впустую. Этот дизайн также ошибочен, потому что мне придется искать в каждом из полей проекта, чтобы найти всех людей, которые работали над определенным проектом, потому что этот номер проекта может быть в любом из полей проекта.

Я рассмотрел довольно много основных понятий. Дайте мне знать, если у вас есть другие вопросы или вам нужна помощь в разъяснении/разбивке на простом английском языке. Страница wiki не читалась как простой английский, и для некоторых это может быть сложной задачей.

Ответ 9

Я много раз читал ссылки на wiki по нормализации, но я нашел лучший обзор нормализации из этой статьи . Это простое легко понять объяснение нормализации до четвертой нормальной формы. Дайте ему прочитать!

Предварительный просмотр:

Что такое нормализация?

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

http://databases.about.com/od/specificproducts/a/normalization.htm

Ответ 10

Нормализация базы данных - это формальный процесс проектирования вашей базы данных для устранения избыточных данных. Дизайн состоит из:

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

Используйте data-dictionary или некоторые другие представление метаданных для проверки дизайна.

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

Ссылки

• Если не нормализовать базу данных SQL

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

Ответ 11

+1 за аналогию с вашей женой. Я считаю, что говорить с кем-либо без технического ума требует некоторой легкости в этом типе беседы.

но...

Чтобы добавить к этому разговору, есть другая сторона монеты (что может быть важно, когда в интервью).

При нормализации вы должны посмотреть, как индексируются базы данных и как записываются запросы.

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

Честно говоря, проще писать плохие запросы в нормализованных таблицах высокого уровня.

Я думаю, что для каждого приложения есть средний уровень. В какой-то момент вы хотите легко получить все из нескольких таблиц, без необходимости присоединяться к тонне таблиц, чтобы получить один набор данных.