проектирование базы данных переработки

Question

Я изо всех сил пытаюсь придумать правильный дизайн для хранения данных об утилизации. Данные собираются по трехмесячному циклу для каждой недели этого месяца. поэтому данные выглядят следующим образом (сейчас они собирают данные в Excel):

    Month 1     | Plastic       | Metal  | Newspaper |  Cardboard | Paper
 ---------------------------------------------------------------------------------
   Measurement: | (x) 19 Gal    | 19 Gal | 19 Gal    |  19 Gal    | 19 Gal
                |   36 Gal      | 36 Gal | 36 Gal    |  36 Gal    | 36 Gal 
                |   Lbs         | Lbs    | Lbs       |  Lbs       | Lbs   
                |   Other:(txt) | Other  | Other     |  Other     | Other                      
 ---------------------------------------------------------------------------------
   Week 1       |    1
   Week 2       |
   Week 3       |
   Week 4       | 
   Week 5       |    2
 ----------------------------------------------------------------------------------
    Total (Lbs) |    Z

В этом примере общее значение (Z) будет преобразованием 3 бункеров по 19 галлонов в фунты

Часть, из-за которой у меня болит голова, - это каждый вторично перерабатываемый продукт, к которому также прикреплено несколько атрибутов, поэтому у Plastic есть размер корзины, способ ее переработки и т. Д. ...

Я прочитал EAV и наследование таблиц классов , но они не чувствуют себя "подходящими" для этой проблемы. Заранее спасибо.

Answer 1

Ваш случай выглядит как образец шаблона проектирования Gen-Spec. Gen-spec знакома объектно-ориентированным программистам по иерархии суперкласс-подкласс. К сожалению, введение в проектирование реляционных баз данных, как правило, пропускает, как разрабатывать таблицы для ситуации Gen-Spec. К счастью, это хорошо понято. Поиск в Интернете по теме «Специализация обобщения реляционных баз данных» даст несколько статей на эту тему. Некоторые из ваших хитов будут предыдущими вопросами здесь, на SO.

Хитрость в том, как назначается PK для таблиц подкласса (специализированных). Он не генерируется какой-либо функцией автонумерации. Вместо этого это копия PK в суперклассовой (обобщенной) таблице, и, следовательно, ссылка на нее FK.

Таким образом, если бы речь шла о транспортных средствах, грузовиках и седанах, у каждого грузовика или седана была бы запись в таблице транспортных средств, у грузовиков также была бы запись в таблице грузовых автомобилей с PK, который является копией соответствующего PK в Стол транспортных средств. Аналогично для седанов и седанов. Легко определить, является ли транспортное средство грузовиком или седаном, просто выполнив объединения, и в любом случае вы обычно хотите объединить данные в запросе такого типа.

Answer 2

Для начала, скажите, пожалуйста, что вы не используете "Неделя 1" и т. Д., А Интервал (т.е. дата начала, дата окончания).

Теперь ... какие у вас проблемы с наследованием таблиц? Это выглядит как классический пример. Базовый класс / таблица будет перерабатываемым продуктом с небольшим количеством общих атрибутов ... это проблема? Не можете найти ничего «общего», кроме названия?

А как насчет единицы измерения? То есть ссылка на другую таблицу с подробным описанием кг, галлонов, кубических футов и т. д .?

Может быть, "Опасный" флаг?

С этого момента вы можете специализировать "Пластик", добавив поле для "Метод переработки". Что указывает на другую таблицу с перечнем доступных альтернатив. «Размер корзины» будет единицей измерения? Должно ли это быть основным атрибутом «класса» (т. Е. Все пластмассы измеряются по весу) или оно должно зависеть от разных вещей? (т.е. тип пластика? тип точки сбора?)

Совершенно нормально, если в базовой таблице много всего, кроме числового идентификатора и некоторых описательных полей.

Answer 3

Разве вы не хотите что-то вроде:

Month | Recycling_Type | Recycling_ID

---

Week1 Plastic 2342
Week2 Plastic 2343
Week2 Metal 4

Затем создайте отдельную таблицу для каждого типа переработки:

Plastic
ID, Bin Size

---

2342 5
2343 6

и т.д.