Структура таблицы базы данных Mysql для таблицы Excel, имеющей несколько подколонок в одной колонке

#mysql #database #database-design

#mysql #База данных #база данных-дизайн

Вопрос:

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

 Name             Mon-Fri                   Sat                Sun       
            Asia      UK    USA      Asia   UK  USA     Asia    UK  USA
Name1       0.25     0.25   0.5       0.5   -   -        -     0.5   -
Name2       0.5      0.5     1         1    -   -        -      -    - 
Name3       0.25     0.25   0.5       0.5   -   -        -     0.5   -
  

Комментарии:

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

Ответ №1:

Обычно вы делаете это, добавляя Time столбец к данным и «нормализуя» его:

 Name   Region   Time    Amount
------|-------|--------|-------
Name1   Asia    Mon-Fri 0.25
Name1   Asia    Sat     0.5
Name1   Asia    Sun     -
Name2   UK      Mon-Fri 0.25
Name2   UK      Sat     -
...
  

Смотрите https://en.wikipedia.org/wiki/Database_normalization также

Ответ №2:

Для этого сначала создайте таблицу дней

tbl_days

идентификатор, имя_дня

Затем создайте группу с этими днями. Группа может содержать один день или несколько дней

tbl_group

идентификатор, имя группы, дни (разделите его идентификатором дня через запятую)

Затем создайте мастер страны

tbl_countries

идентификатор, имя_страны_

Затем назначьте вычисление, как показано ниже

tbl_calculation

идентификатор, group_id, country_id, значение (обнуляемое)

Ответ №3:

Вы можете использовать следующую структуру таблицы

tbl_Region —

  ID , Name
    1,UK
    2,Asia
  

tbl_Date_allocation —

     ID,WEEK_DAY_NAME
    1, Mon
    2 , Wed
    3 ,...
  

tbl_types

 Id, Name
1, Name 1
2, Name 2
......
  

tbl_allocation

 id,region_id,date_allocation_id,type_id,value
1,1,2,1,0.25

id - auto increment 
region_id,date_allocation_id,type_id - foreign keys to other table 
  

Ответ №4:

У вас есть две сущности: нечто, у чего есть имя, давайте назовем их People, и географическая область — три из которых являются значениями Asia, UK и USA. Затем вы представили отношения между людьми и GAs. Как видно из ваших данных, Person может относиться к 0 или более GAs, а GA может относиться к 0 или более людям. Такое отношение «многие ко многим» поддерживается таблицей пересечения или перекрестной таблицей (два названия для одного и того же объекта). Далее вы показываете два аспекта этой взаимосвязи: термин («Пн-Пт», «Сб» и «Вс») и сумму.

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

 create table PersonGO(
  PersonID  int not null references People( ID ),
  GAID      int not null references Areas( ID ),
  Term      int not null check( Term in (1, 2, 3 )),
  Amount    float not null,
  constraint PK_PersonGO primary key( PersonID, GRID )
);
  

Данные, хранящиеся в такой таблице, будут выглядеть следующим образом:

 PersonID  GAID  Term  Amount
       1     1     1  0.25   -- Name1 Asia Mon-Fri
       1     1     2  0.50   -- Name1 Asia Sat
       1     2     1  0.25   -- Name1 UK   Mon-Fri
       1     2     3  0.50   -- Name1 UK   Sun
       1     3     1  0.50   -- Name1 USA  Mon-Fri
       2     1     1  0.50   -- Name2 Asia Mon-Fri
       2     1     2  1.00   -- Name2 Asia Sat
       2     2     1  0.50   -- Name2 UK   Mon-Fri
       2     3     1  1.00   -- Name2 USA  Mon-Fri
       3     1     1  0.25   -- Name3 Asia Mon-Fri
       3     1     2  0.50   -- Name3 Asia Sat
       3     2     1  0.25   -- Name3 UK   Mon-Fri
       3     2     3  0.50   -- Name3 UK   Sun
       3     3     1  0.50   -- Name3 USA  Mon-Fri
  

Там, где нет связи для конкретного человека с определенной областью на определенном сроке, например, Name1 с UK в субботу, запись отсутствует. У вас не было бы записи с 0 или NULL в поле суммы. В этом не было бы необходимости.

Поскольку ваши примерные данные выглядят как данные за одну неделю, и, вероятно, для каждой недели года будет один набор этих записей, в таблице может быть другое поле, WeekNum, с возможными значениями, такими как 201601 для первой недели 2016 года, 201602 для второй недели и так далее. Здесь у вас есть большая гибкость. С таким же успехом вы могли бы объединить это с полем Term: 2016011 для Пн-Пт первой недели, 2016012 для воскресенья первой недели и так далее. Вы могли бы придумать что-то совершенно другое. Все, что имеет наибольший смысл для вас.