Является ли эта нормализация нормализации данных хорошей реализацией?

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

Например, простейший случай, что в одном приложении существует следующий селектор:

You are: Lord 
     Lady

пыльник имеет это одно:

You are: Monsieur 
     Madame

Наконец то, что мне нужно в централизованной базе данных (Datawarehouse) является нормализованная таблица каждого клиента.

customer_id | customer_name | customer_type 
-------------------------------------------- 
     1  |  John |  Sir 
     2  |  Sia |  Madame

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

Например:

Мои нормализованные ожидаемые значения

id | value 
---------------- 
    1 | Sir 
    2 | Madame

Мои входных значений ожидается

id | value 
---------------- 
    1 | Lord 
    2 | Lady 
    3 | Monsieur 
    4 | Madame

Моя реляционная таблица

id | normalized_value_id | expected_value_id 
---------------------------------------------- 
1 |   1   |   1 
2 |   1   |   3 
3 |   2   |   2 
4 |   2   |   4

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

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

Кроме того, я могу использовать эти три таблицы, чтобы генерировать весь процесс нормализации для всех мультиселектора, например:

Улица Мультиселектор:

You live: Str 
      Ave

Другой:

You live: St 
     Av

Мой нормализуется ожидаемые значения

id | value 
---------------- 
    1 | Sir 
    2 | Madame 
    3 | Street 
    4 | Avenue

Мои входные ожидаемые значения

id | value 
---------------- 
    1 | Lord 
    2 | Lady 
    3 | Monsieur 
    4 | Madame 
    5 | Str 
    6 | St 
    7 | Av 
    8 | Ave

Моя реляционная таблица

id | normalized_value_id | expected_value_id 
---------------------------------------------- 
1 |   1   |   1 
2 |   1   |   3 
3 |   2   |   2 
4 |   2   |   4 
5 |   3   |   5 
6 |   3   |   6 
7 |   4   |   7 
8 |   4   |   8

Является ли эта реализация достаточно хорошо и последовательно за то, что я хочу сделать?

источник

2017-01-19 Maik

@philipxy Почему вы так говорите? Наконец, что вы делаете, это нормализовать данные (с идентификаторами вы можете ссылаться на любое из этих значений, а затем вы можете уменьшить избыточность данных) – Maik

Уменьшение избыточности базы данных «нормализация» предполагает замену отношения другими, которые присоединяются к нему. Это не связано с добавлением идентификаторов. (Во всяком случае, это сжатие данных.) Если вы думаете, что это так, вам нужно прочитать учебник. Когда я впервые прочитал ваше сообщение, я редактировал ваш заголовок, добавил тег «нормализация базы данных» и прокомментировал, что нормализация не связана с добавлением идентификаторов. Но потом я подумал, что вы подразумеваете «нормализацию» в смысле систематического изменения значений данных, как и в статистике, за «нормализацию» тега, как при преобразовании многих входных значений в один нормализованный. Поэтому я отменил эти изменения. – philipxy

Прежде всего - если вы еще не проверили процесс ETL, я бы рекомендовал его: https://en.m.wikipedia.org/wiki/Extract,_transform,_load

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

источник

2017-01-19 21:47:53

Спасибо за ваш ответ. У меня есть опыт в процессе ETL. Я буду использовать эти процессы в передаче данных и процессе нормализации, но я хочу иметь параметры нормализации в базе данных. Что вы имеете в виду при сопоставлении по умолчанию? Вы имеете в виду, например, присвоить значение по умолчанию для любого нового значения, например присваивать сэру любое новое значение в этом мультиселекторном типе? Я полагаю, что вы используете исходный столбец для назначения этого значения по умолчанию, верно? – Maik

Да - сопоставление по умолчанию должно быть присвоено новым значениям, которые еще не отображены, чтобы избежать необходимости устанавливать NULL в нормализованных значениях. Конечно, значение по умолчанию должно иметь имя, которое никогда не будет ожидаемым или нормализованным значением, поэтому что-то вроде # или *. Это чтобы избежать NULL, и я честно не знаю, является ли это лучшей практикой DWH или просто предпочтением. Исходный столбец предназначен только для удобства. –

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

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

источник

2017-01-19 21:37:35

Это правда, но я не знаю, сколько параметров мне придется нормализовать, поэтому я не вижу, что такое улучшение, чтобы избежать реляционной таблицы и использовать только простую таблицу для использования отношений «один ко многим». Может ли кто-нибудь объяснить мне это? – Maik

Неважно, сколько параметров вам необходимо нормализовать. Сначала это зависит от цели создания таблиц, для OLTP или OLAP. Если вы хотите создавать таблицы для OLTP, вам необходимо нормализовать таблицу до 4NF. Если вы хотите, чтобы таблицы работали для OLAP, вам необходимо денормализовать таблицы. –

Поскольку я нормализую то, что получаю от приложений (OLTP), к DWH (OLAP), я думаю, что мне нужно сосредоточить это как процесс нотариализации OLAP. Что вы имеете в виду как денормализовать таблицу? – Maik

В целом, план выглядит нормально. Возможно, дело №1 для нормализации: не имеют столбцов, означающих нечто большее.

На практике, 1-to-Many используется большую часть времени. По существу:

Таблица Название

ID | Desc 
1 | Sir 
2 | Madam

Таблица Person

ID | Name | Title 
1 | Dean | 1 
2 | Jess | 2

Где только заголовки добавляются в таблицу заголовков. Только лица находятся в таблице лиц, но идентификатор титула может быть любым в заголовке. Когда вы делаете Many-Many, вы хотите сохранить эту же концепцию.

источник

2017-01-19 21:58:49 Kevin

Является ли эта нормализация нормализации данных хорошей реализацией?

ответ

Смежные вопросы