Организация таблиц в базе данных

Question

Здравствуйте! Вопрос по организации БД. Думаю, что такое распределение таблиц не совсем правильно с практической точки зрения. Но с логической оно меня утраивает. Проект учебный. Скажите, как правильнее - перенести все поля из дополнительных таблиц в "Товар" или так и оставить?

Скриншот таблиц:

Answer 1

Есть мелкие ошибки:

1. Для разных товаров может быть одна фотка
   
2. Поле "доступен" - в таблице товар можно вычислить (если количество товара на складе больше нуля)
   
3. Для размеров я б выделил отдельную сущность. т.к. многие книги идут одного формата (напр. серия книжек), тип обложки тоже можно отдельно вынести (слепить эти 2 группы свойств в одну таблицу или в 2 разных - это уже ваше дело)
   
4. Вы забыли, что у каждой книги есть издатель и год издания, по которому и стоит определять, новинка данная книга или нет. Если предположить, что книга считается новинкой 1 год, то новинками будут все книги, у которых год издания больше предыдущего года.
   
5. Думаю, для некоторых книг будет сложно однозначно определить категорию, почему не может быть фентезийная книга в то же время драмой или еще чем-то там (по аналогии с фильмами). В таком случае нужна связь многие к многим.
   
6. Скидка - это тоже интересная штука, - она не может действовать вечно. У нее должно быть время начала и время окончания действия. Посему нужна отдельная сущность.

В итоге у нас получится:

/* - описание продукта - */
product
--------------- 
id  
name    
description 
format_id   (format.id)
publisher_id    (publisher.id)
publish_date    /* int, фактически только год и нужен */
count       /* склад один значит нет смысла выделять в отдельную таблицу */
/* - описание категории  - 
p.s. если надо добавить ограничение по возрасту, то легче всего это сделать добавив поле в эту таблицу
напр.: задав для категории "эротика" ограничение. чтоб камасутру не продавали детям школьного возраста */
category

id,
name,
description
/* - привязка книг к категориям - 
позволяет одновременно задать разные категории для книг,
напр: приключения + роман или детектив, драма */
product_categories

product_id  (product.id)
category_id (category.id)
/* - скидки - */
discount

id
startdate
enddate
discount
/* - привязка товаров к скидкам - 
в принцыпе можно было в таблицу discount добавить поле product_id,
но в этом случае субд было бы неудобно пользоватся,

для каждого товара вам придется вбивать скидку что думаю будет неудобно.

пример: вам надо сделать скидку на все книги которые вышли 10 лет назад
*/
product_discounts

product_id  (product.id)
discount_id (discount.id)
format
id
dimension /* размеры /
format    / тип обложки */

update: Простите, забыл добавить рейтинг, думаю, его реализация зависит от того, что вы подразумеваете под рейтингом, если значение как покупатели оценивают книгу, тогда надо сделать так, как у вас, если это "продаваемость книги", другими словами колчество продаж за единицу времени, то лучше считать находу: количество продаж / (дата последней продажи - дата первой продажи)

Answer 2

Прочтите что такое нормализация данных. Есть замечательная статья посвященная этой большой и очень полезной науке. Фтыкать сюда. Если совсем коротко, то нужно найти правильный баланс между избыточностью данных и сложностью структуры.

Про теорему Бойса-Кодда уж умолчу.

Answer 3

Согласен с уважаемым @AVP, что складов может быть много и склады эти - не "квалифицированы". В таком случае необходима развязывающая отношение "многое ко многому" таблица Склад - Товар. Неверно, с моей точки зрения, отношение в таблицах Товар - Фототовар: должно быть "один к одному", раз уж так приспичило создавать Фототовар (из схемы такой необходимости не усматриваю). Рейтинг должен быть полем в Товарах, а не отдельной таблицей. Фух, я все сказал. Впрочем, если это не Рейтинг, а Отзывы, то правильно, но, в таком случае, Varchar2(45) - маловато будет.