Объемное моделирование процесса ожидания

Бизнес-сценарий: я разрабатываю многомерную модель для обработки заявки в университет. В университете есть 15 колледжей. При подаче заявки абитуриент может указать варианты, такие как 1, 2, 3 и т. д. Дело в том, что если 1-й колледж отклонит заявление, затем оно автоматически поступает во 2-й колледж, после чего 2-й колледж может либо предложить, либо отклонить. Если 2-й колледж отклоняет, то заявление автоматически передается в 3-й и так далее, пока студент не получит место

Многомерная модель будет отвечать на такие вопросы, как, сколько абитуриентов было выбрано на основе их первого предпочтения, сколько времени проходит между решениями каждого колледжа. Показатели приема/отклонения и т. д.

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

Пожалуйста, предложите несколько полезных идей


sql-server dimensional-modeling star-schema database-design entity-relationship
person user1254579    schedule 03.09.2015    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Да, я думаю, вы можете смоделировать это в размерности, создав таблицу фактов с детализацией абитуриента и колледжа и вырожденными измерениями для номера предпочтения, даты подачи заявки, результата заявки («принято», «отклонено», « н/д"), дата начала процесса принятия решения для этого колледжа-заявителя, дата принятия решения и время ожидания.

Думаю, это ответит на все вопросы.

person David Aldridge    schedule 03.09.2015
comment
Я собираюсь создать таблицу фактов с детализацией предпочтений кандидатов, а не отдельных приложений. Приложение состоит из 1 или более предпочтений. Эти предпочтения будут храниться в измерении, а время ожидания и т. д. связано с каждым предпочтением на fctbtble. - person user1254579; 04.09.2015
comment
Заявитель и колледж фактически совпадают с заявителем и предпочтением, поэтому я думаю, что мы согласны с детализацией. Колледж был бы одним из измерений в вашей таблице, верно? - person David Aldridge; 04.09.2015
comment
да, колледж - это одно из измерений, которое содержит подробную информацию о колледжах при университете. Теперь решение такое, как вы упомянули. Сохранил номер предпочтения студента в таблице фактов как вырожденные измерения. Основное измерение приложения состоит из отдельных деталей приложения. Одно приложение в измерении приложений состоит из 1 или более предпочтений в фактической возможности. - person user1254579; 08.09.2015
comment
Да, таблица фактов — это, по сути, набор приложений, в которых ключами являются абитуриент и колледж, с числом предпочтений и результатом как вырожденных измерений. Возможно, заявка должна быть таблицей измерения вместо заявителя, с заявителем в качестве атрибута измерения, чтобы заявители могли подавать заявки в разные годы. - person David Aldridge; 08.09.2015
comment
На самом деле существует измерение заявителя, измерение приложения и таблица фактов (которая содержит суррогатный ключ приложения, номер предпочтения приложения в качестве ключа таблицы фактов). - person user1254579; 09.09.2015
comment
Таким образом, таблица фактов состоит из одного и того же идентификатора приложения с несколькими предпочтениями. Таблица фактов используется в качестве таблицы фактов транзакций. Потому что, если у учащегося нет никаких предпочтений, система генерирует номер притворства в oltp. Таблица фактов также состоит из даты, когда колледж получил заявление, даты решения, флагов для обозначения принятого, отклоненного и т. д. - person user1254579; 09.09.2015
comment
Звучит неплохо. Ключевой вопрос, который следует учитывать, заключается в том, можно ли ответить на бизнес-вопросы, на которые вы хотите получить ответ, с помощью относительно простого SQL. - person David Aldridge; 09.09.2015