Как сформировать таблицу исходных отношений при проектировании базы данных?
В настоящий момент пытаюсь разобраться в вопросе проектирования баз данных (далее по тексту - БД). Прочитал одноименный раздел из учебника Хомоненко А.Д., Цыганков В.М., Мальцев М.Г. "Базы данных. Учебник для ВУЗов" (далее по тексту - Учебник).
На первый взгляд, все понятно. Проектирование БД начинается с определения атрибутов, сведения их в единую таблицу исходных отношений, далее занимаемся декомпозицией этой таблицы.
Попробовал поставить и решить подобную задачу самостоятельно. Итак, составим таблицу исходных отношений... И уже тут у меня начались трудности. С приведенной в Учебнике таблицей все было понятно, но на практике у меня вдруг появилась необходимость поставить данные из разных строк этой таблицы в зависимость друг от друга. Думаю, будет проще пояснить на примере.
Пусть есть таблица работников и выполняемых ими работ. Некоторые работы могут выполняться только после окончания предшествующих:
Работник --- Работа
Октавиан --- Возводит стены
Клавдий --- Вешает картины
Клавдий может повесить картину на стену только после того, как Октавиан ее построит Как отразить это отношение в исходной таблице? Разбить работы по этапам? Вроде того:
Работник --- Работа 1 этапа --- Работа 2 этапа
Октавиан --- Возводит стены --- Отдыхает
Клавдий --- Отдыхает --- Вешает картины
Присвоить дополнительный атрибут некого "веса" работам, из которого будет следовать очередность их выполнения?
Работник --- Работа --- Вес работы
Октавиан --- Возводит стены --- 1
Клавдий --- Вешает картины --- 2
Или сразу формировать две разных таблицы исходных отношений, проводить отдельно их декомпозицию, а потом как-то увязывать результат?
Или, может, я сразу пошел по неверному пути и мне надо было как-то иначе выделять атрибуты для таблицы исходных отношений?
ChairfaceChippendale, декомпозиция, нормализация отношений, приведение к нормальной форме более высокого порядка. Если набросать более-менее подробно атрибуты какого-либо реального производственного процесса, получается весьма существенное их количество. Так просто сразу раскидать их по таблицам - не получается. Вернее, получается - но криво и постоянно приходится все "перекраивать". Ищу какой-нить способ сделать все по-уму, при этом совсем не разбираюсь в теме. Вот и начал с учебника.
При проектирование структуры лучше идти от физической модели предметной области максимально абстрагируясь. Получив главные вершины идти обратно в детализацию, стараясь не плодить схожие сущности.
В вашем примере вершины: "Работник", "Задание". "Задание" состоит из "Этапов". "Этап" из "Работы" (она появляется только здесь). Вот для выполнения этой "Работы" и набираются "Работники". Причём у "Работы" нет прямой связи с "Работником", так как у "Работы" должен быть "Список выполнения" из "Видов работ", к которому уже и подключаются конкретные исполнители (именно во множественном числе).
Тут у Вас как минимум 3 таблицы: 1-я Работники:
Октавиан,
Клавдий,
Август 2-я Виды работ:
Возведение стен,
Развешивание картин,
Руководство процессом 3-я связующая Этапы работ:
1-й этап Октавиан - работает
1-й этап Август- руководит
2-й этап Клавдий - работает
2-й этап Август- руководит
ChairfaceChippendale, Ну мы же только набрасываем структуру. Затем у Работников появятся персональные данные а у видов работ расценки и время. К этапам добавим даты начала и завершения и т.д....
Деление на отдельные таблицы предусмотрено дальнейшими шагами Учебника. На первом этапе нужно собрать все в одну исходную, которую последовательно потом буду приводить к нормальным видам.
В исходной может быть значительно больше атрибутов нежели в приведенном примере и так сразу на составляющие ее разделить будет сложно. Потому и хочется попробовать пройти путем из Учебника.
Slava Rozhnev, пример - всего лишь пример, а не конечная задача. В задаче которую я бы в итоге хотел для себя решить - сотни атрибутов (и это, к сожалению, еще не конец), которые "пересекаются" в различных сочетаниях. На первых порах получалось логически раскидать их по таблицам, и все даже получалось вполне красиво. Но появлялось все больше и больше трудностей по ходу работы. Приходилось все чаще "перекраивать" структуру.
В связи с этим, решил найти что-нибудь мало-мальски фундаментальное по данному вопросу, чтобы понимать с чего, по-хорошему, следовало бы начинать.
Slava Rozhnev, в реальном мире последняя ваша таблица формируется динамически. Расчистили площадку под стену, оказалось - болото. Позвали Тиберия осушать болото. Потом только стена. И т.п.
При наличии сотен операций имеем миллионы вариантов сочетаний - не все же их в таблице прописывать. Удобнее решать это условиями в коде. Но при этом иметь в БД какие-то данные по "весу" работ что-ли...
ChairfaceChippendale, например, выделяешь на начальном этапе сущность "работы". В процессе учета всех требуемых тебе характеристик работ ты понимаешь, что у тебя для разных работ появилось слишком много уникальных атрибутов (в коде - еще и методов) и каждую конкретную работу проще вывести в свою отдельную сущность. Под это переписываешь весь код. Хотелось понять, может есть какие-то алгоритмы первоначального анализа, которые позволят подобные вещи выявить на старте.
Средний
Простой
Средний
