#transactions #sas #large-data
#транзакции #sas #большие данные
Вопрос:
Итак, мой вопрос касается специфической проблемы, с которой я сталкиваюсь в отношении одной из областей, в которой мне приходится работать в рамках моей текущей работы.
Домен — транзакции по кредитным картам. Таким образом, он уникален на уровне транзакции. Но один человек может выполнять несколько транзакций. Теперь, очевидно, каждая транзакция не будет идентичной.
Итак, у меня есть этот базовый набор данных характеристик, которым я могу легко управлять. Из этого набора данных я хочу оценить производительность на уровне клиента по сегментам, которые должны быть легко доступны без необходимости запускать мой код для разных комбинаций переменных. По сути, то, к чему я стремлюсь, — это представление на уровне клиента, которое не приводит к потере информации с точки зрения учетной записи, и я все еще могу просматривать производительность на уровне клиента по сегментам.
Кто-нибудь из вас проводил подобный анализ? Или у вас есть какие-либо яркие идеи относительно того, как я должен это сделать? Я не знаю, насколько ясным является это объяснение, но дайте мне знать, если вам нужны дополнительные пояснения. Спасибо за вашу помощь!
Комментарии:
1. вам нужно быть более конкретным. Что у вас есть, чего вы хотите, что вы пробовали……
2. Хорошо, итак, у меня есть идентификаторы транзакций. Которые уникальны. Для каждого идентификатора транзакции будет указан идентификатор учетной записи. Это будет повторяться. Каждая транзакция будет определяться набором переменных категории. Допустим, у меня есть переменные A, B, C, D для каждой транзакции. И я должен дать анализ производительности каждой комбинации этих переменных. Идентификаторы учетной записи будут уникальными в каждой комбинации. Скажем, проблема в том, что я должен суммировать свою производительность на уровне A, B; и на уровне A, B и C. Я хочу просмотреть оба представления в одном csv. В настоящее время все, о чем я думаю, — это сводка процесса и переключение переменной типа .
3. Если вам нужна помощь, сделайте так, чтобы люди могли вам помочь. Опубликуйте небольшой образец вашей базы данных с тем, что у вас есть, а затем попытайтесь опубликовать небольшой макет того, что вы хотели бы
4. docs.google.com/spreadsheets/d/… Может быть, это поможет?
5. ну, это лучше, но то, что вы показываете, похоже, не имеет смысла. у a есть только e и f, а у b есть только g. также у b есть несколько записей, поэтому сумма будет намного больше, чем 300 долларов. Либо более подробно объясните, что вы пытаетесь сделать, либо опубликуйте пример согласованных наборов данных
Ответ №1:
Предположим, у вас есть данные по 30 транзакциям, которые поступили от 10 клиентов (по три транзакции каждая). В реляционной базе данных (и часто это хорошая идея и в SAS) Обычно имеется таблица транзакций (со столбцами TransactionID, CustomerID, TransactionDate, TransactionAmount) и таблица клиентов (со столбцами CustomerID, CustomerName, customerSegment и т. Д.). Это часть нормализации базы данных. Вы отделяете данные уровня транзакции от данных уровня клиента.
Если вы являетесь поклонником PROC SQL, эта настройка будет хорошо работать для вас в SAS. Если вы хотите проанализировать транзакции для определенного сегмента клиентов, вы просто объединяете таблицы (или подзапрос или что-то еще).
Другим вариантом в SAS было бы объединить две таблицы по идентификатору клиента, создав набор данных, содержащий одну запись на транзакцию и содержащий некоторые переменные, которые являются атрибутами транзакции, и другие переменные, которые являются атрибутами клиента. Так может выглядеть:
custID transID transDate transAmount customerSegment customerDOB
1 1 1/1/2015 100 A 1/1/1990
1 2 1/2/2015 50 A 1/1/1990
1 3 1/3/2015 75 A 1/1/1990
2 4 1/1/2015 10 B 12/12/1950
2 5 1/2/2015 5 B 12/12/1950
2 6 1/3/2015 75 B 12/12/1950
Это менее эффективное хранилище (и менее нормализованное), поскольку значения атрибутов клиента повторяются для каждой транзакции от одного и того же клиента. Но это может упростить жизнь, если вы хотите проанализировать данные транзакции по атрибуту клиента.
Подробнее об этом в нормализации базы данных Google. У Тоби Данна есть несколько хороших статей по нормализации в SAS, например http://analytics.ncsu.edu/sesug/2007/TU03.pdf