SQL и нормализация

Question

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

Мои мысли первоначально были сотрудниками, которые могут совершать много перерывов, и один перерыв будет для одного сотрудника. Один ко многим.

Тем не менее, возможно (теоретически), чтобы работник мог совершить много перерывов и один перерыв. взято многими сотрудниками - многими-ко-многим. Например, Джон и Фред делают перерыв в 12.00, говорят и возвращаются в 1.00pm.

Мы приступаем к расщеплению волосков, хотя со мной склонны идти по принципу «один ко многим». Например, Джон делает перерыв в 12:01 вечера, говорят, что Фред уезжает в 12.00, когда они возвращаются в разные временные интервалы, 1.05pm и 1.03pm.

Можете ли вы предложить несколько хороших методов проектирования баз данных для этого типа сценариев? Идеи в картинках ниже:

many to many one to many

Answer 1

пойти на один-ко-многим. Определенно

Вы можете добавить таблицу «стандартного перерыва», где вы можете хранить стандартные значения, такие как «от 12 до 1» для обеденного перерыва. Когда сотрудник (или группа сотрудников) принимает один из этих «стандартных перерывов», в таблицу «breaks» добавляются соответствующие строки «breaks».

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

Ваших таблицы могут выглядеть:

Tbl_Break: 
    id_Break (primary key) 
    id_Employee (not null) 
    breakStartTime (not null) 
    breakEndTime (not null)   
    id_StandardBreak (nullable) 

Tbl_StandardBreak: 
    id_StandardBreak (primary key) 
    standardBreakStartTime (not null) 
    standardBreakEndTime (not null) 
    standardBreakDescription (not null) 
    id_Schedule (not null) 

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

Answer 2

Я бы рекомендовал подход один-ко-многим. Когда у вас есть данные в db, вы можете проанализировать их и выяснить, кто сделал перерыв с кем.

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