@FrolVII

Как сформировать таблицу исходных отношений при проектировании базы данных?

В настоящий момент пытаюсь разобраться в вопросе проектирования баз данных (далее по тексту - БД). Прочитал одноименный раздел из учебника Хомоненко А.Д., Цыганков В.М., Мальцев М.Г. "Базы данных. Учебник для ВУЗов" (далее по тексту - Учебник).
На первый взгляд, все понятно. Проектирование БД начинается с определения атрибутов, сведения их в единую таблицу исходных отношений, далее занимаемся декомпозицией этой таблицы.
Попробовал поставить и решить подобную задачу самостоятельно. Итак, составим таблицу исходных отношений... И уже тут у меня начались трудности. С приведенной в Учебнике таблицей все было понятно, но на практике у меня вдруг появилась необходимость поставить данные из разных строк этой таблицы в зависимость друг от друга. Думаю, будет проще пояснить на примере.
Пусть есть таблица работников и выполняемых ими работ. Некоторые работы могут выполняться только после окончания предшествующих:

Работник --- Работа
Октавиан --- Возводит стены
Клавдий --- Вешает картины

Клавдий может повесить картину на стену только после того, как Октавиан ее построит Как отразить это отношение в исходной таблице? Разбить работы по этапам? Вроде того:

Работник --- Работа 1 этапа --- Работа 2 этапа
Октавиан --- Возводит стены --- Отдыхает
Клавдий --- Отдыхает --- Вешает картины

Присвоить дополнительный атрибут некого "веса" работам, из которого будет следовать очередность их выполнения?

Работник --- Работа --- Вес работы
Октавиан --- Возводит стены --- 1
Клавдий --- Вешает картины --- 2

Или сразу формировать две разных таблицы исходных отношений, проводить отдельно их декомпозицию, а потом как-то увязывать результат?
Или, может, я сразу пошел по неверному пути и мне надо было как-то иначе выделять атрибуты для таблицы исходных отношений?
  • Вопрос задан
  • 161 просмотр
Пригласить эксперта
Ответы на вопрос 2
tsklab
@tsklab
Здесь отвечаю на вопросы.
При проектирование структуры лучше идти от физической модели предметной области максимально абстрагируясь. Получив главные вершины идти обратно в детализацию, стараясь не плодить схожие сущности.
В вашем примере вершины: "Работник", "Задание". "Задание" состоит из "Этапов". "Этап" из "Работы" (она появляется только здесь). Вот для выполнения этой "Работы" и набираются "Работники". Причём у "Работы" нет прямой связи с "Работником", так как у "Работы" должен быть "Список выполнения" из "Видов работ", к которому уже и подключаются конкретные исполнители (именно во множественном числе).
Ответ написан
rozhnev
@rozhnev
Fullstack programmer, DBA, медленно, дорого
Тут у Вас как минимум 3 таблицы:
1-я Работники:
Октавиан,
Клавдий,
Август
2-я Виды работ:
Возведение стен,
Развешивание картин,
Руководство процессом
3-я связующая Этапы работ:
1-й этап Октавиан - работает
1-й этап Август- руководит
2-й этап Клавдий - работает
2-й этап Август- руководит
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы