Нормализация на простом английском

Question

Я понимаю концепцию нормализации базы данных, но мне всегда трудно объяснить ее простым английским языком - особенно на собеседовании. Я прочитал пост wikipedia , но мне все еще трудно объяснить эту идею не-разработчикам. «Проектирование базы данных таким образом, чтобы не получать дублированные данные» - это первое, что приходит на ум.

У кого-нибудь есть хороший способ объяснить концепцию нормализации базы данных простым языком? И какие хорошие примеры показывают разницу между первой, второй и третьей нормальными формами?

Скажем, вы идете на собеседование, и человек спрашивает: Объясните концепцию нормализации и как будет разрабатываться нормализованная база данных. Какие ключевые моменты ищут интервьюеры?

Answer 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

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

Answer 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-листам, а не к реляционным базам данных.) Подход из одной таблицы заставляет меня повторить некоторую информацию, если я хочу, чтобы данные были согласованными. Проблема с этим дизайном заключается в том, что некоторые факты, такие как информация о том, что адрес Боба - «Колокольня», повторяются дважды, что является избыточным и затрудняет запрос и изменение данных и (наихудшее) возможное введение логических несоответствий. 1015 *

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

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

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

Answer 3

Вот что я спрашиваю у респондентов:

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

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

Answer 4

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

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

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

Answer 5

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

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

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

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

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

Answer 6

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

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

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

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

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

Answer 7

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

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

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

Что касается части разработки и реализации, тогда вы можете вернуться к «жаргонному языку» и сохранить его от непрофессионалов, но я полагаю, вы могли бы упростить. Сначала вы говорите, что вам нужно, а затем, когда приходит нормализация, вы говорите, что убедитесь в следующем:

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

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

Answer 8

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

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

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

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

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

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

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

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

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

Избегание повторных групп полей:

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

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

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

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

Answer 9

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

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

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

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

Ссылки

• Когда не нужно нормализовать базу данных SQL

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

Answer 10

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

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

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

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

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