Несколько примеров:
Надо добавить сущность "Издательство" с атрибутом "Название" (как минимум).
Книги связаны с издательствами отношением "многие-ко-многим": книга может публиковаться в разных издательствах. Поэтому на физическом уровне потребуется промежуточная таблица "Публикации" с атрибутом "Год издания".
(Разумеется, это упрощенная модель; при желании ее можно уточнять еще очень долго.)
Добавим сущность "Серия". К серии относится не сама книга, а ее конкретная публицация, так что имеет смысл вывести "Публикацию" на уровень ER-модели и связать ее с серией отношением "один-ко-многим" (каждая публикация принадлежит к одной серии, каждая серия может включать несколько публикаций).
Также серия связана отношением "один-ко-многим" с издательством (у издательства может быть несколько серий, а каждая серия принадлежит конкретному издательству).
Остается вопрос о внесерийных изданиях. Его можно решить либо введением фиктивной серии "Без серии", либо возможностью не указывать для публикации внешний ключ серии.
Рассматривая каждый конкретный тип комплектующих, можно без труда выделить необходимые атрибуты. Какие-то атрибуты будут общими (скажем, фирма-производитель и название модели), а какие-то будут иметь смысл только для данного конкретного типа. Например:
Проблема в том, что рынок комплектующих очень динамичен. Некоторое время назад жесткие диски определялись частотой вращения и емкостью, а сейчас важен тип (твердотельный, вращающийся, гибридный). Для мониторов во времена ЭЛТ была важна частота обновления, а сейчас важен тип матрицы. Дисководы уже никому не нужны, зато появились флеш-накопители. И так далее.
Таким образом, либо придется постоянно изменять схему данных (а, значит, и постоянно изменять приложение, которое работает с этими данными!), либо искать более универсальную модель за счета отказа от жесткой структуры и контроля согласованности. Некоторые универсальные модели (например, хранение части данных в JSON) мы затрагивали в презентации.