нормализация базы данных - таблицы объединения/объединения

Question

Просьба учитывать следующую ситуацию.

У нас есть таблица 0NF

StudentTeacherTable:

StudentName StudentDepartment StudentDepartmentAdd TeacherName TeacherDepartment TeacherDepartmentAdd 
    John   CS     London   Dave  Eng, CS    Oxford 
    Mike   CS     London   Dave  Eng, CS    Oxford 
    Chris   Eng     Oxford   Dave  Eng, CS    Oxford 

В идеале после нормализации я хотел бы иметь таблицы как

Студенческой таблица:

StudentName Department TeacherName 
    John  CS   Dave 
    Mike  CS   Dave 
    Chris  Eng  Dave 

учители таблица:

Name 
Dave 

TeacherDepartment Таблица:

TeacherName DepartmentName 
    Dave   CS 
    Dave   ENG 

Департамент Таблица:

Name Address 
    CS London 
    ENG Oxford 

Однако, если я следую за нормализацию к 3NF. я буду получать

Student Таблица:

StudentName Department TeacherName 
    John  CS   Dave 
    Mike  CS   Dave 
    Chris  Eng  Dave 

DepartmentForStudent Таблица:

Name Address 
    CS London 
    ENG Oxford 

Преподаватель Таблица:

Name 
Dave 

TeacherToDepartment Таблица:

TeacherName DepartmentName 
    Dave   CS 
    Dave   ENG 

DepartmentForStudent Таблица:

Name Address 
    CS London 
    ENG Oxford 

Мой вопрос заключается в том, что, в котором шаг в нормализации баз данных (1NF, 2nF, 3NF и т.д.) можно объединить/объединить studentDepartement с teacherDepartment столбцов в одну таблицу, чтобы получить нормированную форму выше?

Иными словами, в соответствии с нормализационными правилами. В итоге у меня будет таблица StudentDepartment и таблица TeacherDepartment, а не таблица из одного раздела для ученика и учителя

Answer 1

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

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

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

вариант 2: иметь один стол с колонкой дополнительного типа: pro и cons в противоположном направлении опциона 1

G *** может найти много ресурсов для этой темы.

---

2 примера: Сохранение иерархических данных (например, одна таблица с типом против нескольких таблиц с 1: 1 ключ и различия ...) в Relational Database Design Patterns?

http://sqlmag.com/sql-server/trouble-type-tables

Answer 2

Вы пишете «В идеале после нормализации я бы хотел ... »

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

Это говорит о том, что давайте попробуем это, учитывая, что набор нормализованных таблиц - это ваш результат, но нормализация - это процесс: точнее, производя 1, 2, 3NF в этом порядке, от небольшого образец данных, является точным процессом, который часто практикуется при обучении нормализации.

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

StudentID 
StudentName 
StudentDepartment 
StudentDepartmentAdd 
TeacherID 
TeacherName 
TeacherDepartment (repeating) 
TeacherDepartmentAdd 

Ваши данные сбивает с толку, потому что выборка невелика, и есть несколько киев, как там может быть в заполненной форме или отчете. Но я считаю, что могу сделать два предположения: (1) Учительский отдел зависит от учителя, как следует из названия; (2) каждый учитель (например, Дэйв в данных) имеет много студентов, которые участвуют в каждом отделе, где они работают. Если это так, то «studentdept» и «teacherdept» лучше всего обрабатывать как один атрибут, два столбца помогают просто выработать зависимости.

В этих двух предположениях, процесс становится знаком, только есть два уровня повторяющихся групп:

 UNF      1NF     2NF (and 3NF) 

    _TeacherID_   _TeacherID_   _TeacherID_ 
    TeacherName   TeacherName   TeacherName 
    TeacherDepartmentAdd TeacherDepartmentAdd TeacherDepartmentAdd 
| Department 
|| StudentID    _TeacherID_*   _TeacherID_* 
|| StudentName   _Department_   _Department_ 
|| StudentDepartmentAdd 
         _TeacherID_ )*  _StudentID_* 
         _Department_)  _Department_ 
         _StudentID_   TeacherID * 
          StudentName   
          StudentDepartmentAdd _Department_ 
               StudentDepartmentAdd 

               _StudentID_ 
               StudentName   

еще два предположения необходимо: что студент и отдел определить Учитель; и что отдел определяет адрес отдела (где этот отдел учит). Это не совсем очевидно из небольшого образца данных, но я принимаю их на основе результата, который, как вы сказали, вам следует получить. В любой реальной ситуации вы должны запросить более крупный образец данных или подтвердить структуру данных с ее фактическими пользователями. Исходя из этого, 3NF совпадает с 2NF, поэтому я не пишу выше.

Таким образом, приведенные данные: с результатами, которые вы ищете. Но, вы должны понимать:

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