Разработка базы данных по нескольким датам

Я проектирую доступ .accdb для управления проектами. Контракт по проекту предусматривает ряд этапов для каждого проекта с соответствующей датой. Точное количество этапов зависит от «или/или» случае размера проекта, но не более 6Разработка базы данных по нескольким датам

Мой работодатель хотел бы отслеживать [Forecast] дату, [Actual] дату и [Paid] дату каждого этапа, то есть проект большого размера заканчивается 24 дат, связанных с ней, часто дублируется (если проект бежит время, все четыре даты будут идентичны)

в настоящее время у меня есть tblMilestones, который имеет FK ссылки на tblProject и запись для каждого Milestone, с 4 связанными датами в качестве полей в записи и поле, чтобы отметить веху как полную или текущую.

Я чувствую, что мы собираем, храним и вводим много довольно бессмысленных данных, особенно дату [Forecast], для которой мы собираем данные от наших менеджеров проектов (в любом случае, это не самые надежные данные). После завершения этапа и ввода даты [Actual][Forecast] дата довольно бессмысленная

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

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

источник

2013-02-20 KDJ

Знаете ли вы, для чего должна использоваться прогнозируемая дата? Вы можете думать, что это бессмысленно, но для будущего анализа это может быть очень важно. – Oded

Спасибо! Я обеспокоен тем, что моя настройка неправильно учитывает будущий анализ. Дата прогноза - это дата, когда премьер-министр думает, что эта веха будет достигнута. Это важно на активной стадии этапа: хорошо знать, как проект работает против графика. Он будет меняться с ежемесячной отчетностью от PM, поэтому ближе к завершению этапа, тем ближе дата прогноза к фактическому. Мой текущий простой tbl не отслеживает изменения в дате прогноза. – KDJ

Возьмите страницу из размерных дизайна и хранить даты хранилища данных в их собственной таблице с DateID:

DateID DateValue 
------ ---------- 
    1 2000-01-01 
    ...  ... 
    9999 2012-12-31

Затем включите все поля даты - прогноз, фактический, платный, и т.д. .-- в внешние ссылки на поле DateID таблицы даты.

Чтобы заполнить таблицу даты вы можете пойти двумя путями:

Используйте некоторые VBA для создания большой набор дат, скажем, 2005-01-01 до 2100-12-31, и вставить их в таблицы дат как одноразовая операция.
Всякий раз, когда кто-то вводит новую дату, проверьте таблицу дат, чтобы увидеть, существует ли она, а если нет, вставьте ее.

Какой бы способ вы этого не сделали, вам, очевидно, понадобится индекс DateValue.

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

Таким образом, вы можете отслеживать только дату завершения вехи и дату платежа в своей транзакционной базе данных, а хранилище данных будет фиксировать изменения со временем завершения с течением времени.И разрешите вам проводить анализ и прогнозирование, не увязывая производительность транзакционной (прикладной) базы данных.

источник

2013-02-21 04:08:40 Yawar

Спасибо за понимание моего затруднения, и я думаю, что понимаю, что вы рекомендуете. Есть только googled ETL, и это имеет смысл. Я понимаю, что мои вопросы всегда, кажется, приводят к новым вопросам: сопоставление дат с проектами, позволяющее вводить данные пользователя, а затем представлять данные людям в формах, которые они понимают/хотят. Тем не менее, я предпочел бы правильно разместить данные, а затем обработать остальные. Еще раз спасибо, я буду экспериментировать с этим завтра. – KDJ

еще один вопрос: так что у меня будет tblmsmge с числовыми указателями на даты в таблице даты и выполнить что-нибудь, чтобы сохранить любые изменения данных на другой tbl в качестве моего «склада»? – KDJ

@KDJ - лучшие вопросы, которые приводят к большему количеству вопросов. Поэтому, чтобы ответить на ваш вопрос: да, у вас были бы идентификаторы DateID в качестве внешних ключей в ваших рабочих таблицах, если вы хотите использовать гибридный подход для отслеживания дат завершения веха. Если вы хотите использовать подход с чистым хранилищем данных, вы можете просто сохранить даты сами в своей транзакционной базе данных (но не прогнозируемая дата, вторая прогнозируемая дата, фактическая дата и т. Д.) Только одна). Затем у вас будет процесс ETL, который периодически запускается (скажем, каждую ночь), чтобы обновить ваш аналитический склад даты с последними изменениями – Yawar

Разработка базы данных по нескольким датам

ответ

Смежные вопросы