Как нормализовать этот отчет (таблицу)? - PullRequest
2 голосов
/ 09 февраля 2012

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

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

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

Вот ссылка на один из небольших отчетов. Это уже в 1NF (и это происходит таким образом, поэтому нет больших проблем там). Я хотел бы видеть пример того, как это выглядело бы нормализованным к 3NF, и это могло бы помочь зажечь что-то для остальных отчетов.

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

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

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

https://docs.google.com/spreadsheet/ccc?key=0ApvRcXXd6PiWdHFLRWVmNS1VUklpYkFvWVdKQmpvdWc

1 Ответ

1 голос
/ 16 февраля 2012

Нормализация через BCNF основана на ключах и функциональных зависимостях.В данных, которые вы разместили, действительно недостаточно информации, чтобы нормализовать ее до 3NF.

Например, есть только одно значение для региона, RSP и офиса.Итак, в ваших примерах данных все остальные столбцы будут определять одно и только одно значение для региона, для rsp и для офиса.

tech_code->region
tech_name->region
dish_week_end_date->region
last_change_date->region
...
tech_code->rsp
tech_name->rsp
dish_week_end_date->rsp
last_change_date->rsp
...
tech_code->office
tech_name->office
dish_week_end_date->office
last_change_date->office

Теперь, хотя last_change_date определяет одно и только одно значение для офисаэто реальная функциональная зависимость?Нет, это, наверное, просто совпадение.

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

«Номер рабочего задания» не являетсяключ;две строки имеют 23464504300055024. Поскольку я не могу скопировать данные, я не собираюсь пытаться выяснить, есть ли у вас ключ и какой он может быть.

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

office -> region
office -> rsp
tech_code -> tech_name
tech_name -> tech_code
last_change_date -> dish_week_end_date
work_order_number -> work_order_type
work_order_number -> account_number
work_order_number -> car

Скорее всего, количество будет зависеть только от ключа, если он есть.

Достаточно ли этого для продолжения?

...