Интерфейсы Классы
---------- ------
Object
Iterable
Collection AbstractCollection
List AbstractList
AbstractSequentialList
LinkedListвозникло подозрение...Если внимательно читать доку и понимать устройство/свойства разных структур данных, на смену подозрениям может придти уверенное понимание :) Если заглянуть вот сюда https://docs.oracle.com/javase/8/docs/technotes/gu... (Collection Implementations), без всяких сравнений становится понятно, какого быстродействия на каких операциях / наборах данных можно ожидать от той или иной имплементации. А заодно разобраться, чем отличается интерфейс от реализации.
Если так сделать, то да - все равно будет "нормализовано", просто, в меньшей степени, чем если бы их вынести в отдельные таблицы. А вот правильно это будет или нет, зависит только от самих свойств. Самая общая рекомендация: если свойства имманентны (т.е. присущи всем и каждому department-у), смело пихайте их в эту таблицу - это не создаст дополнительной избыточности, но позволит избежать в запросах одного бесполезного JOIN; а те, которые специфичны (или могут быть специфичны), пихайте в отдельную. Но, опять же, как в каждом конкретном случае "правильно", зависит не только от моделируемых сущностей, но и от того, что конкретно предполагается делать с этой моделью. Например (пофантазируем): где-то в UI захочется поиметь редактируемый список всех (общих и специфических) свойств одного конкретного department-а в виде key-value, в котором будут редактироваться только значения. Тогда программисту потребуется для каждого свойства еще его признак (общее/специфичное). Для такого случая гораздо удобнее вынести и общие свойства в отдельную таблицу с таким же точно набором полей, как и в "специфичных", т.е. тогда эта общая рекомендация уже будет неверной ))
2. "Любой учебник по SQL", по теории реляционных БД и т.д. - это хорошо, но только начало. Изучение теории позволит, грубо говоря, уверенно отвечать на вопрос, в большей или меньшей степени нормализована та или иная структура, но мало что даст в смысле ответа на вопрос "как правильно" )) По-настоящему понять все закономерности можно только спроектировав большое количество разных систем, совершив при этом все возможные ошибки и прочувствовав на собственной шкуре их последствия. (Это, разумеется, мое личное IMHO... я повидал кучу теоретиков, проектировавших офигительно нормализованные БД, приводившие в результате к полной заднице в проектах. Возможно, мне просто не везло в жизни и где-то есть правильные книжки, которые им следовало бы изучить вместо тех, которые они изучали...)
3.а На практике есть, в принципе, два подхода к проектированию: DB first или code first. То, что Вы, видимо, пытаетесь делать, это DB first, а настоящий Дзен, как обычно, где-то посередине ))
3.б В смысле архитектуры принято говорить об уровне абстракции доступа к данным (Data Access Layer). Это как раз и есть тот код, который распутывает/запутывает клубки связей между сущностями, чтоб программист на уровне бизнес-логики мог сосредоточится именно на ней, а не на заморачиваться на тему конкретных JOINов или диалекта SQL. Но его тоже кто-то пишет. Готового решения из коробки нет, но есть куча паттернов (от наиболее распространенных, вроде DAO, DTO и до экзотики типа QBE). Но паттерны - это просто общие рекомендации. А по сути все так или иначе сведется либо к использованию ORM, либо к собственному "велосипеду".
4. Эту конкретную схему я набросал в Enterprise Architect и из него же сгенерировал DDL (просто был под рукой на момент написания ответа), но должен предупредить, что EA - далеко не лучший выбор для таких дел. Есть много подобных тулзов попроще, но для конкретно MySQL, сам бог велел воспользоваться MySQL Workbench.