Базовый дизайн базы данных - необязательное участие

Работа с домашней работой по базовому дизайну базы данных и рисунком ERD в Visio и не может обернуть мою голову вокруг этой проблемы.

United Helpers - некоммерческая организация, которая оказывает помощь людям после стихийных бедствий. Основываясь на следующей краткой описание операций, создайте соответствующие полностью помеченные Crows Foot ERD.

• Люди добровольно выполняют свое время для выполнения задач организации. Имя, адрес и номер телефона для каждого добровольцы отслеживаются. Каждому добровольцу могут быть назначены несколько задач в течение времени, когда он или она занимается добровольческой работой, и некоторые задачи требуют много добровольцев. Волонтер может быть в системы, еще не назначенной задачей. Можно задачи, которые никто не назначил. Когда добровольцу назначают задача, система должна отслеживать время начала и время окончания назначение.

• Для каждой задачи есть код задачи, описание задачи, тип задачи и состояние задачи. Например, может быть задача с кодом задачи "101", описание "ответа на телефон", тип "повторяющихся", и статус "продолжающийся". Может быть другая задача с кодом "102", описание "подготовить 5000 пакетов основных медицинских принадлежности", тип "упаковки" и статус "открыто".

• Для всех задач типа "упаковка" есть список упаковки, который определяет содержимое пакетов. Есть много разных упаковочные листы для производства различных упаковок, таких как базовые медицинские пакеты, пакеты для детей, пакеты продуктов и т.д. Каждый упаковочный лист имеет идентификационный номер упаковочного листа, название упаковочного листа и упаковочный лист описание, в котором описываются элементы, которые в идеале этот тип упаковки. Каждая задача упаковки связана только с одной товарная накладная. Список упаковок не может быть связан с какими-либо задачами или может быть связано со многими задачами. Задачи, не связанные с упаковкой не связаны с каким-либо упаковочным листом.

• Задачи упаковки приводят к созданию пакетов. Отслеживается каждый отдельный пакет поставок, который создается организацией. Каждому пакету присваивается идентификационный номер. Дата, когда пакет был и общий вес пакета записывается. Данный пакет связан только с одной задачей. Некоторые задачи (например, "ответ" телефоны ") не будут выпускать какие-либо пакеты, в то время как другие задачи (например," подготовить 5000 пакетов основных медицинских принадлежностей") будет связанных со многими пакетами.

• В упаковочном листе описывается идеальное содержимое каждого пакета, но не всегда возможно включить идеальное количество каждого элемента. Поэтому фактические предметы, включенные в каждую упаковку, должны быть отслеживаются. Пакет может содержать много разных элементов, и данный элемент может использоваться во многих различных пакетах.

• Для каждого элемента, который предоставляет организация, есть номер идентификатора элемента, описание позиции, значение элемента и количество элементов, хранящихся вручную в системе. Наряду с отслеживанием фактических предметов, помещенных в каждый пакет, количество каждого предмета, помещенного в пакет, должно быть отслеживается тоже. Например, в упаковочном листе может указываться, что основные медицинские пакеты должны включать 100 бинтов, 4 бутылки йода и 4 бутылки перекиси водорода. Однако из-за ограниченного предложения предметов, данная упаковка может включать только 10 бинтов, 1 бутылку йода и пероксида водорода. Тот факт, что этот пакет включает бинты и йод необходимо регистрировать вместе с количеством каждый из которых включен. Организация может иметь предметов, которые еще не были включены в пакет, но каждый пакет будет содержать хотя бы один элемент.

Моя мысль была бы сущностью VOLUNTEER и TASK, создавая составной объект ASSIGNMENT, который мог бы сгенерировать задачу УПАКОВКА, В этой задаче используется СПИСОК УПАКОВКИ и ITEMS, который генерирует ПАКЕТ.

enter image description here

Однако моя уверенность в этом решении равна нулю. Хотите узнать, правильно ли он исправлен? Или я полностью об этом ошибаюсь?

Спасибо

Ответы

Ответ 1

Вы делаете это правильно или, по крайней мере, направляетесь в правильном направлении, но конечный результат неверен (хотя сущности в верхней строке вашей диаграммы более или менее правильны)

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

Ответ 2

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

Однако очень возможно, что ваш учитель не видит этого так же, как я. Большое количество профессионалов используют ERD в качестве альтернативы реляционным схемам и выражают структуру базы данных в ERD. Ваше решение выглядит как дизайн для меня, а не анализ.

Если ваш учитель не проводит различия между анализом и дизайном (а некоторые нет), есть что-то фундаментальное, что вам нужно учиться, и что ваш учитель не сможет научить вас. Вам нужно различать особенности проблемы и особенности предлагаемого решения проблемы. Если вы не сделаете это различие, вы окажетесь в одной из нескольких подводных камней.

Самая распространенная ошибка заключается в правильном решении неправильной проблемы. Я видел, как это происходило снова и снова в поле.

Вторая наиболее распространенная ошибка - это изменение определения проблемы, чтобы облегчить задачу. Иногда это делается намеренно, чтобы соответствовать предельному сроку с ограниченными ресурсами. Но когда это произошло непреднамеренно, возникает множество проблем.

Третья ловушка - это то, что можно назвать "мышлением внутри коробки". В этой ловушке решатель будет добавлять ограничение, которое не было в исходном определении проблемы, но является признаком первого ошибочного решения. "Ящик" является признаком предлагаемого (ошибочного) решения, а не особенностью проблемы, как изначально было указано. Но как только он был принят как часть проблемы, проблема становится неразрешимой.

Ответ 3

Я думаю, что это должно быть так.

A существует только пять таблиц. Указано, что я делаю задачу упаковки, является таблицей задач.