You are on page 1of 30

Contents

Page

1.

CHANGE HISTORY...................................................................................................................................1

2.

SPORTSBOOK INTRODUCTION.......................................................................................................1

3.

BETTING TYPES AND RESULTS.......................................................................................................2

3.1 BET CONTENTS STRUCTURE..........................................................................................................................2


3.2 BET STRUCTURE..............................................................................................................................................3
3.3 BET TYPES.......................................................................................................................................................3
3.3.1 Single Bet.............................................................................................................................................3
3.3.2 Multi (Combination) Bet.................................................................................................................3
3.3.3 System Bet..........................................................................................................................................4
3.3.4 Banker Bet...........................................................................................................................................5
3.4 RESULTING.......................................................................................................................................................7
3.5 DEAD HEAT DIVISOR.....................................................................................................................................9
4.

BWIN PRODUCT GROUPS...................................................................................................................9

5.

IMPORTANT SPORTSBOOK OBJECTS.........................................................................................10

5.1
5.2
5.3
5.4
5.5
5.6
5.7
6.

EVENT, SLIP, BET, REGION, GAME AND RESULT RELATED DETAILS IN BUS LAYER..........................10
PRODUCT DETAILS IN WHMAIN...............................................................................................................21
DATA FLOW TO LOAD DATA INTO UDPT TABLES.....................................................................................22
IMPORTANT VIEWS OF WHMAIN...............................................................................................................24
LOOKUP TABLES............................................................................................................................................27
CASH VIEW AND GAME VIEW CONCEPTS..................................................................................................28
MAINTAINING DEPENDENCY IN BUS LAYER..............................................................................................29
IMPORTANT RACEBOOK OBJECTS...............................................................................................30

6.1

RACEBOOK AGGREGATE TABLE BUS.AD_RACEBOOK_UDPT.........................................................30

1. Change History
Version
1.0

Date
14.01.2011

Changes
Initial Document

Author
Ranajoy Upadhyay

2. Sportsbook Introduction
Sportsbook subject area deals with the bets placed on different kind of sports that are being played like
Football, Lawn Tennis, Motorsport, Basketball etc. Several entertainment events are included within the
Sportsbook subject area. About 99% of the Sportsbook is actually the real sports. But this subject area
also sometimes deals with specific events like Oscar, Economics etc.

Racebook is another subject area and it is independent from Sportsbook. But it has some similarities with
Sportsbook also. Racebook mainly deals with different kind of bets that are placed on Horse Racing.

3. Betting Types and Results


3.1

Bet Contents Structure

Soccer

Sport

Region

(sTSport)
1

(sTRegion)
1
n

England

League

Premier League

(aTLeague)
1
n

Tournament

Default (used only


inside database)

(aTTournament)
1
n

Event

Arsenal FC Manchaster United

(aTEvent)
1
n

Game

3 Way (1 X 2)

(aTGame)
1
n

Result

Arsenal wins (1) Odds 1,75

(aTResult)

The above figure depicts the Bet Contents structure for the Sportsbook subject area.
Region is like Countries or Continents like Asia or Europe.
Sport deals with different kind of Sports like Soccer, Lawn Tennis, Basketball etc.
League is basically the Tournaments like English Premier League, Wimbledon etc.
Tournament is the connection between League and Event. This hierarchy was created earlier,
now-a-days it is not used very frequently.
Event is the match on which bets are being placed like Manchester United vs. Arsenal or Roger
Federer vs. Rafael Nadal etc.

Game is the IT terminology for the Business terminology Market. Generally in a game, there
can be three options win, loss and draw. Game can be like Yellow/Red Cards would be less
than 3 in a particular match or Is there any penalty etc. One football match can have about 100
different games.
Result is the IT terminology for the business terminology Option. All the bets are evaluated
from the Result level.
3.2

Bet Structure

(
3.3
3.3.1

SystemSlip

(aTSlipSystem)

Slip

Bet

(aTSlip)
User

Result1

(aTBet)

Stake

Odds 1,5

Bet Types
Single Bet
Customer
Camembert

Arsenal wins with an Odds of 1,75

Slip

Bet

(aTSlip)

(aTBet)

UserID

ResultID

Stake

Odds

CurrencID
Timestamp of conclusion

For Single
Bet,
one single
slip contains one bet only.
BetSlipID
1N50EF2ZYP

3.3.2

Type Single

Multi (Combination) Bet

Customer
Camembert

Slip

Bet1

(aTSlip)

(aTBet)

Arsenal wins with an Odds of 1,5


ResultID1

UserID
Stake

Bet2
(aTBet)

Timestamp of conclusion

Type: Multi

ResultID2
Odds2

CurrencID

BetSlipID 1N50EF2ZYP

Odds1
Rapid Vienna wins with an Odds of 2,5

Bet12
(aTBet)

For Multi Bet, combo slip contains multiple bets.

3.3.3

System Bet

System Slip contains multiple slips. System Slip is optional. One can use Slip or System Slip.

Customer
Camembert

Multi bet 1

Slip1

Bet1

ResultID1

(aTSlip)

(aTBet)

Odds

UserID

Bet2

ResultID2

(aTBet)

Odds

Stake 2
System Bet 2/3

CurrencID

SystemSlip

Slip2of conclusion
Timestamp

Bet3

(aTSlipSystem)

Type:(aTSlip)
Multi

(aTBet)

SystemBet 2/3
BetSlipID 1N50EF2ZYC

Multi bet 2
ResultID1
Odds

Bet4

ResultID3

(aTBet)

Odds

Slip3

Bet5

Multi bet 3
ResultID2

(aTSlip)

(aTBet)

Odds

Bet6

ResultID3

(aTBet)

Odds

Customer wants to place a system bet 2/3 with a stake of 2 based on a selection of three
specific results.
The bet conclusion engine will generate following entries.
Result1: Arsenal wins with an Odds of 1,5
Result2: Rapid Vienna wins with an Odds of 2,5
Result3: Real Madrid wins with an Odds of 1,2
This means for the system bet 2/3 3 multi-bets with two results will be generated.

Result 1 Result 2 Result 3


Combination 1

Combination 2

Combination 3

x
x
x

Most frequently, 2/3 slips are used.


3.3.4

Banker Bet

Customer
Camembert

Multi bet 1

Slip1

Bet1

(aTSlip)

(aTBet)

UserID
Stake 2
CurrencID
Timestamp of conclusion
Type: Multi

ResultID2

(aTBet)

Odds

Bet3
Banker

(aTSlip)

(aTBet)

Odds

Multi bet 2
ResultID1

Bet5

Odds
ResultID3

(aTBet)

Odds

Bet6
Banker

(aTSlipSystem)

ResultID4
Odds

(aTBet)

SystemBet 2/3 with 1


Banker
BetSlipID 1N50EF2ZZC

ResultID4

(aTBet)

Bet4

SystemSlip

Odds

Bet2

Slip2

System Bet 2/3


with 1 Banker

ResultID1

Slip3

Bet7

Multi bet 3
ResultID2

(aTSlip)

(aTBet)

Odds

Bet8
(aTBet)

Bet9
Banker

ResultID3
Odds
ResultID4
Odds

(aTBet)

Customer wants to place a system bet 2/3 with a stake of 2 based on a selection of three
specific results and one Banker result.

The bet conclusion engine will generate following entries.


Result1: Arsenal wins with an odds of 1,5
Result2: Rapid Vienna wins with an odds of 2,5
Result3: Real Madrid wins with an odds of 1,2
Result4 Banker: Bayern Mnchen wins with an odds of 1,1
This means for the system bet 2/3 3 multi-bets with two results and the added banker result
will be generated.
Result 1
Combination 1
Combination 2
Combination 3

Result 2

Result3

x
x
x

Banker Result 1
X

Banker Bet is actually a must win option. If someone is choosing a Banker Bet, then he/she has
to win that Banket Bet, otherwise the entire money would be lost. If the person wins the other
bets but looses the Banker Bet, then also the money would be lost.
From Business point of view, if someone is choosing with extremely low odds, it is also called
Banker Bet.
There is a betting limit for every person in every category of bets. Suppose someones betting
limit is getting exceeded in some category, then different combinations of betting can be selected
like Banker Bet.

3.4

Resulting

Single Bet

Slip

Bet

(aTSlip)

(aTBet)

result status slip status


lost

lost

cancel0

lost

won

won

cancel1

canceled

Multi Bet
Slip

Bet1

(aTSlip)

(aTBet)

ResultID
1
Odds1

Bet2

ResultID2

(aTBet)

Odds2

result status slip status


result 1

n.d.

result 2

n.d.

n.d.

result status slip status


result 1

n.d.

result 2

lost

lost

If at least one result is lost or cancel0, the whole slip is


lost

result status slip status


result 1

n.d.

result
2

won

n.d.
result status slip status

result status slip status


result 1

won

result 2

cancel1

won

result 1

won

result 2

won

Winning amount:
odds1*odds2*stake

won
Because at least one
result marked won,

slip is won

Winning amount: odds1*1(due to cancel1)*stake


result status slip status
result 1

cancel1

result 2

cancel1

Because all results ins state cancel 1, slip is in state cancel


1

cancel1
Winning amount: 1(due to cancel1)*1(due to
cancel1)*stake Customer will get his amount back

Cancellation can be of two types:

If the game is cancelled due to may be rain then the entire money would be returned and
it would be multiplied by 1(as shown in the above example).

If the status is cancelled due to some exceptional situation i.e. heating, then no money
would be refunded.

3.5

ResultID2 (d/h won)


Odds2

Dead Heat Divisor

If there is more than one result won inside a market, they are market as d/h won via using a
Dead Heat Divisor on this market all winnings depending on a d/h won result will be reduced
(odds/divisor).

Slip

Bet1

ResultID1 (won)

(aTSlip)

(aTBet)

Odds1

Bet2

ResultID2 (d/h won)

(aTBet)

Odds2

Winning amount:
odds1*odds2/dh divisor*stake

d/h divisor: 2

Suppose, the question is like Which three Italian teams would go to the Champions League next
year? These kind of bets can be part of Dead Heat Divisor.

4. Bwin Product Groups


There are four main product groups:

Sports

Poker

Casino

Games

The Sports subject area can be categorized into three areas:

Sports Betting (Mainbook Bets / Fixed Odds Bet)

Live Betting (Live Bet)

Horse Racing (Racebook) Its under the Sportsbook product group, but its
not directly related.

There are about 25 products. In the hierarchy, Product comes under Product Group.

5. Important Sportsbook Objects


5.1

Event, Slip, Bet, Region, Game and Result related Details in BUS Layer

D_SPORT
The Sport hierarchy is as follows:-

SPORTGROUP2

SPORTGROUP1

Sport

League

Tournament

Event
The Sports can be categorized via different Sport Groups.
Sportgroup1 values are the following:
SPORTGROUP1ID SHORTDESC

LONGDESC

Mixed

Mixed

Soccer

Fuball

Tennis

Tennis

American Sports

American Sports

Winter Sports

Winter Sports

General Sports

Allgemein

Motor Sports

Motorsport

Ball Sports

Ball Sports

Pub/Brit Sports

Pub/Brit Sports

Sportgroup2 values are the following:


SPORTGROUP2ID SHORTDESC

LONGDESC

N/A

Not Available

PS

Prime Sports

CDS

Core Development Sports

HPS

High Potential Sports

Now-a-days, SportGroup2 is mainly used. In some reports, SportGroup1 still might be used.
The candidate D_SPORT table consists of approximately 94 records.
TRANS_DT is the sysdate of the time of loading for all dimensions and facts in the BUS layer.
Loading date timestamp is called the LOAD_DT in Stage and Base layer.

D_REGION
The Region hierarchy is as below:-

Region

League

Tournament

Event
The region hierarchy is similar to the sport hierarchy and a region can be either a country or a
continent name.
In the field TRANS_DT, all the date timestamps are same. In most of the cases in the BUS layer,
the full load is done. Most of these objects are loaded in Truncate Insert mode in the BUS layer.
D_REGION table consists of approximately 230 records.
D_LEAGUE
OBSOLETE is a flag in D_LEAGUE. Some leagues were created earlier but it is not used
anymore. These leagues are denoted by this flag.
There is another flag called LIVEBET in League Dimension. If the value of this flag is 1, then it
is Live Betting and if the value is 0, then it is Fixed Odds Betting / Sport Betting (Mainbook).
One important flag in League Dimension is TOPLEAGUE. This value is inferred from
LU_DE_TOPLEAGUE of the BASE layer. This table denotes which leagues are of topmost
priority from Bwin business perspective. This table is loaded based on the data filled in excel
received from the business. If the flag TOPLEAGUE in the league dimension is 1, then this
league is present in the corresponding lookup table and if it is 0, then it is not present.
The details of this kind of LU_DE lookup tables in the BASE layer would be explained in the
subsequent section.

D_EVENT

The table stores the live and non live Sportsbook event related information. To provide the event
start and end time accurately sometimes can be difficult as this information is highly depending
on the proper usage of bookie tool.
EVENT_ID is the Primary Key.
CREATOREMPLOYEEID denotes the person who created the event in the bookie tool.
RESPONSIBLEEMPLOYEEID is the person who is responsible for maintaining the event data.
If some event is extremely popular, then it is very difficult for one person to manage all the odds
and other details during the event. In this kind of situations some person assists the employee
during the event. This bookmaker details is kept in the field ASSISTANTEMPLOYEEID. These
employees are from Bwin, actually they are bookmakers.
DATEGMT is the Event Start Date. It is not 100% accurate. The actual start time of the Event is
stored in the EVENTSTART field of F_LIVEEVENT.
DERIVEDLIVEEVENTENDTIME stores the event end time. This field is calculated based on
the maximum payout time of the markets within the event. This field is not used now-a-days. So
in most of the cases, this would be blank.
CALCULATEDENDTIME stores the event end time. This field uses the event start date as a
base time and add the estimated duration time which is a unique value for every sport. This field
is not used now-a-days and in most cases, this would be blank.
NOLIVEBETBONUS originally stores bookie bonus information but its not loaded and used
anymore.
ATVENUE flag stores if its a special event and the Bwin bookmakers are sent to the event
location to do their job near to the game.
If the event is streaming as video or audio the Streaming flag marks the information in the
STREAMING field.
LIVEEVENT field makes a difference between live and non-live events.
In case of live events if the event is shown on tv then TV flag would be set to 1.
LIVETICKER field indicates if the bookies are using Live Ticker table and following the live
event via a web based live ticker application.
If its not possible to watch the live event on tv, all relevant information is transmitted via phone
and in this case the TELEPHONE flag marks the event is broadcasted via phone.

PROVIDERFLAGS is a new flag. It is the combination of different flags Atvenue, Telephone,


Streaming, Liveticker, Tv etc.
EVENTGROUPID can be same for different events. Under one Eventgroup, there may be many
events.
SOURCEEVENTID is available for Live Events only. Otherwise it is similar to EventGroupId.
If the event can be seen on television i.e. the event is available to the external viewers then the
field EXTERNALSTREAMING would be set to 1. If it is view access in only restricted to some
privileged users, then STREAMING field can se set to 1 but EXTERNALSTREAMING would
be set to 0.
F_GAME
This table stores sportsbook data on game granularity level. The games are also named as
markets in the bookie terminology. The Sportsbook games are always associated to a Sportsbook
event, and within one event it is provided multiple games to the users. One gametemplate is used
for every market to manage the market data and ensure the trading. When a bookie opens a
market the gametemplate for the market will be online and available for users to place any bets
on the game. When a bookie closes the market or makes some odds changes the gametemplate is
offline, no more bet can be placed on it and the market will be payout after that. Market payout
means that the winning amounts are written to the user BWIN account, but it doesnt mean real
money payout as the user may want to reuse the winning money and keep the amount on the
BWIN account.
In F_GAME, there is no specific measure. So, this is not a typical fact.
GAMEID is the Primary Key.
Real payout date is stored in PAYOUTDATEGMT field.
RESULTTIMESTAMPGMT represents the date when the market is closed and the bookie
requests to pay the finished markets.
GAMETEMPLATEID stores the id of the gametemplate.
PAYINGOUTEMPLOYEEID represents the bookie who requested the payout.
F_LIVEEVENT
This table stores the Event Start and End time accurately. EVENTSTART and EVENTEND
fields represent Event Start time and Event End time respectively. These are actually applicable
for the Live Events. Mainbook details wouldnt be available here. The entire details of the
Mainbook and Live Betting would be available in D_EVENT.

EVENTSTART represents actual start date time of a particular event.


EVENTEND represents the actual end date time of a particular event.
PLACEDONWEBSTART is the start date time before the start of the event. It can be 10 minutes
or 1 hour before the Event Start. It is basically the Event Start Date Time on the Bwin webpage.
On the web page, the events get started before the match.
PLACEDONWEBEND is basically the Event End date time on Bwin webpage.
DURATIONREALEVENT is the duration of the event in minutes.
DIFFWEBSTARTMINGSTARTDATE is the measurement in minutes. This field should usually
be very close to zero. If this value is in positive, say 1, then it is 1 minute before the event start.
Is the value is in negative, say -3, then it is 3 minutes after the event has started.
DIFFEVENTENDMAXGTENDDATE is the field where difference in minutes is maintained
after the event if finished so that no bets can be placed. The values in this field should always be
either zero or negative as it is not possible to place any bet after the completion of the event. If
the value is positive then some cheating has occurred. If the value in this field is -5, then it means
Bwin event is already closed 5 minutes before and no bets can be placed on it.
When a new live event is created DEFAULTOPENDATEGMT denotes the estimated date and
time when the event would start.
If an event is started before midnight and ends after midnight then ISOVERMIDNIGHT flag is
set to 1.
F_RESULT
The table stores all the results which can occur within the BWIN Sportsbook games. The results
are also named as options in the bookie terminology.
Using the ResultId field the table can be easily connected to F_BET table in order to collect the
bet information related to any specific results. Apart from that the table can be used to connect to
F_GAME table and collect game related information associating with each possible result.
RESULTID is the Primary Key.
RESULTODD field stores the result odds which can be different comparing with the Bet odds.
When the user places a bet with a bet odds the final odds may change during the time of bet
conclusion. It is possible that bookies are changing the odds in the time period when the user
places a bet and the final accepted result odds can be different from the bet odds sent by the user.
RESULTSTATUS field stores the result status id with the following descriptions:

1 - active
2 - lost
3 - won
4 - cancelled record1
5 - cancelled record2
RESULTDESCRIPTION field stores a short description of the result. The most popular results
can occur within the football game with 3 possible results: 1, X, 2.
F_SLIP
The table contains the slip related data on a daily basis. When a user wants to place a single or a
combo bet with a particular stake one slip record will be populated to the table. This table stores
important transactions like how much is the money odds, what is the stake etc. The table can be
queried based on two different time dimensions.
SLIPID is the Primary Key.
The amount of stake is stored in local currency in the field SLIPMONEY.

Event

Game
Result

Slip

Bet
Number of records

The amount of stake is stored in Euro in the field SLIPMONEYEURO.


SLIPTIMESTAMP field stores the date when the bet was placed and concluded. The view based
on the SlipTimestamp is called the Cash View.
SLIPTRANSTIMESTAMP field stores the date when the bet is evaluated and determined
whether the user wins some amount of money. The view based on SlipTransTimestamp is called
the Game view as it is generated after the game is finished. If the game is not finished and the
slip is still open the SlipTransTimestamp field shows a NULL value.
SLIPTRANSDONE flag is marked to 1 if the bet has been already evaluated.
Based on the SLIPTRANSDONEHOW field it can be decided if the user won some money or
lost. If the user has won some money then this flag would be marked as 1.
If the slip contains more bets, then ISCOMBOBET flag would be marked as 1.
If it is a system bet then ISSYSTEMBET flag would be marked as 1. If the slip contains more
bets, the IsCombobet and/or the IsSystemBet fields make a difference from single bets and also
based on the NumberOfBets can also be easily decided if the slip contains a single bet
(NumberOfBets =1) or more bets(NumberOfBets >=2).
SPORTID field makes a connection with D_SPORT table and the slip records can be categorized
on a sport level.
Based on the field NUMBEROFBETS it can easily be decided if the slip contains a single bet
(NumberOfBets =1) or more bets (NumberOfBets >=2).
The winning money in Euro is only stored in the field SLIPWINMONEYEURO.
LEAGUEID field makes a connection with D_LEAGUE table and the slip records can be
collected and categorized between different leagues.
REGIONID field provides the possibility to categorize the slips based on different regions and
makes the reference to D_REGION table.
The flag ISLIVEBET is 0 if the slip relates to the Fixed Odds Bet or Mainbook Bets. If the slip is
from Live Betting area, then this flag would be set to 1.
APPLICATIONID field describes which application was used by user when the bet was placed.
The slips can be also categorized based on different applications. Obviously slips can be
collected based on two or more dimension tables to generate slip related data on the granularity
of sports and regions together.
When the slips are clearly connected to one event then the EVENTID field makes a reference to
D_EVENT table. If the combo/system slips relate to more events, sports, leagues or regions then

the field stores a zero value to mark that the slip contains more bets and the bets connect more
events, sports leagues or regions.
SLIPTRANSODD stores the odds that can be seen in the webpage or in the user interface i.e. the
transactional odds. Odds can be of different types. Suppose, in the website the odds is 1.5.
Usually 10 to 15 seconds is taken to evaluate the conditions of betting to place a bet. If someone
is placing the bet in the Live event and meanwhile something has happened in the event, then the
odds get changed. There can two kind of options for the users for selecting the odds. First option
is like that whatever be the change of odds in the system, its automatically accepted. Second
option is that whatever be the change id the odds, the user would accept the higher odds. This
odd is similar to the Bet Odd that is present in F_BET table.
CALCULATEDODD represents the odds after the final calculation of the odds. Usually, its
calculated during the event if its Live Bet. If its Mainbook, then the odds would be the same as
it was before the match. This odd is similar to the Result Odd which is present in the F_RESULT.
CURRENCYID is the id and it can be linked to the view DV_CURRENCY_CR of WHMAIN
and also with DV_TAB_ZOLLWERTKURSE view of WHMAIN. Further details of the
Currency related details would be mentioned in subsequent sections.
If the value of TESTACCOUNT is 0, then its the Real User. If the value of the flag is 1, then it
would be Test User. In Live Environment, few hundred test users are present for testing purpose.
TestAccount is available in many tables in BUS layer.
The table is partitioned on SLIPTIMESTAMP_D field. This field contains the same value as the
field SLIPTIMESTAMP without the timestamp. This field is used for quicker access.
SLIPTRANSTIMESTAMP_D field is also used for quicker access. This field contains the same
value as the field SLIPTRANSTIMESTAMP without the timestamp. On this field, indexing is
done.
COMPANYID denotes the slip belongs to which organization. If CompanyId=1, then it is Bwin
related data. If the value is 2, then it is Sajoo related data. Sajoo is a partner organization of
Bwin. There are two reporting layers i.e. WHMAIN and WHSAJOO. Based on the value of
CompanyId, the data goes either to WHMAIN or to WHSAJOO.

F_BET
SLIPID and RESULTID are the Primary Keys of the table.

While the F_SLIP table stores the data on a slip level, this table contains information in a lower
level. If a combo slip / system slip consists of more bets, each bet is stored one by one in the
F_BET table. One slip record and one result record represent together one bet therefore the table
can be connected to the F_SLIP table via SlipId and to the F_RESULT table via ResultId.
BETODD field contains the odd value for each bet when the user places the bet.
BETBETMONEY stores the stake on each bet in local currency. If a user places a combo bet, the
BetBetMoney is calculating according to the BetOdd.
BETWINMONEY calculates the possible Winning Money in local currency for each bet.
TESTACCOUNT and COMPANYID are similar as F_SLIP.
The detailed calculation is described in the following table:

BetBetMoney

WK
WHSlip.SlipMoneyEuro
qi WHBet.BetOdds

BetWinMoney

WK
WHSlip.SlipMoneyEuro
qi WHBet.BetOdds

F_USERTRANSACTIONS
In this table, all the transactions are stored for various products like Casino, Poker etc.

TYPEID field represents different transaction types. If TYPEID=100, then it is a Bet Placement
Transaction and if TYPEID=0, then it is a Winning Transaction. If someone is winning some
money, then they will have two transactions for both these TypeIds in this table. These two
transactions would be merged into one row in F_SLIP table.
SLIPSYSTEMID field is actually same as the SLIPSYSTEMID of the F_SLIP2SLIPSYSTEM.
For a particular SlipSystemId, there can be multiple SlipIds. If the slip is a system slip, then
ISSYSTEMBET=1 for F_SLIP. If this condition is satisfied, then based on the join condition on
SLIPID between F_SLIP and F_SLIP2SLIPSYSTEM, SLIPSYSTEMID is fetched from
F_SLIP2SLIPSYSTEM.
For the Bet Placement Transaction i.e. TYPEID=100 of F_USERTRANSACTIONS then
TRANSMONEY field would be same as SLIPMONEY of F_SLIP and TRANSMONEYEURO
is same as SLIPMONEYEURO.
EMPLOYEEID denotes the id of the employee who are requesting for the payout for the
Winning Transactions i.e. TYPEID=0. In other cases, this field would be blank.
SLIPODD is basically the Transactional Odd of the Slip.
D_APPLICATION and D_APPLICATIONGROUP
Application is also known as labour in the business term. Application group is the parent and
application is the child in this hierarchy.
The examples of Application Groups are bwin.com, bwin.it etc.
Application Group is sub-divided based on the Company Id.
The ApplicationGroupId=18 (sajoo.fr) is related to Sajoo (CompanyId=2) and
ApplicationGroupId =19 (bwin.fr) is related to Bwin (CompanyId=1).
F_SLIP2SLIPSYSTEM
F_SLIP2SLIPSYSTEM is a bridge table between F_SLIP and F_SLIPSYSTEM. The
relationship between these two tables is one to many.
D_EMPLOYEE_HYP
This table represents the Bookmaker employee related details.

5.2

Product Details in WHMAIN

DV_PRODUCTTYPE_CR

There are about 25 Product Types in this view. This view is present in the WHMAIN schema.
The term CR in the name of the view represents the Current Records.
PRODUCTTYPEID is the Primary Key.
PRODUCTDESCRIPTION and PRODUCTDESCRIPTIONSHORT contain the name of the
product and a short name for the product respectively.
PRODUCTTYPEGROUPID and PRODUCTTYPECLASSID consist of the Product Type Group
Id
of
DV_PRODUCTTYPEGROUP_CR
and
Product
Type
Class
Id
of
DV_PRODUCTTYPECLASS_CR view respectively.
PRODUCTGGRTYPEID field determines whether the product is of GGR (Gross Gaming
Revenue) type. The value can be either 1 or 2 based on the Rake or Non Rake product.
PRODUCTTYPEMOBILECLASSID is a lookup object in WHMAIN schema. But there is no
entry for Racebook.
DV_PRODUCTTYPEGROUP_CR
The hierarchy is like that under a Product Group there can be several Products.
There are five Product Type Groups. They are as follows:PRODUCTTYPEGROUPID

PRODUCTTYPEGROUPDESC

Sportsbook

Casino

Games

Poker

RaceBook

But at this moment, PRODUCTTYPEGROUPID =5 is not used and Racebook comes under
PRODUCTTYPEGROUPID=1.

DV_PRODUCT_CR
This view is also present in the WHMAIN schema. This view contains the details of the
products. It contains three fields like ID, NAME and a flag called ISEXTERNAL.

ISEXTERNAL is the flag which determines if the application is Bwin external application or
Bwin provides the frame of the website but the core application is done by external vendor.

5.3

Data Flow to load data into UDPT Tables

Level 1
BUS.F_SLIP is the main source for the Aggregate tables. If ISLIVEBET =0, then the data belong
to the Product Type 1 (Sports Book Fixed Odds) and if ISLIVEBET=1, then data belong to the
Product Type 2 (Sports Book Live Bet).
There is a separate table F_RACEBOOK which consists of the where Racebook data (Product
Type 9) is stored.
There are similar detailed tables for other products.
Level 2
This level stores the details of daily aggregation for each product. These daily aggregations for
each product are stored in the tables BUS.AD_SLIP_SLIPLIVE_UDPT,
BUS.AD_RACEBOOK_UDPT etc.
AD_SLIP_SLIPLIVE_UDPT
Attribute Name

Description

TURNOVERCV

Turnover Cash View where cash view is in the time of bet


placement.

HOLDCV/GGRCV

Hold Cash View (GGR Cash View is the Gross gaming Revenue in
Cash View).

FCOUNT/NROFBETSCV

Number of slips in cash view

TURNOVERGV

Turnover Game View where game view is at the time of resulting


i.e. after the match is over.

HOLDGV/GGRGV

Hold Game View (GGR Game View is the Gross Gaming Revenue
in Game View).

NROFBETSGV

Number of slips in game view.

Level 3

The data is populated in the table BUS.AD_USERGAMEPRODUCTTYPE. All the product


aggregations are put into this table. This is a more detailed table in case of game products as it
contains the GameId column additionally and this can be referred from WHMAIN.
DV_GAMES_CR.
The granularity of AD_USERGAMEPRODUCTTYPE is USERID, DATE_D, GAMEID,
PRODUCTTYPEID, CHANNELID and APPLICATIONID.
The views related to these aggregate tables would be present in WHMAIN.
AD_USERGAMEPRODUCTTYPE
DATE_D field is usually the day of bet placement, day of playing activity in any Bwin products
(Cash View). In Sportsbook, if the match is resulted later, then the game view data is loaded. In
this case DATEFTAG is the day when the bet is resulted.
USERLOSSEUR and STAKEEUR are poker relevant data.
In Sportsbook, GGR is calculated as GGR = TURNOVER CUST WIN.
In Poker, there is no Turnover and for non customer winnings the GGR is fixed percentage based
on the user stakes.
The Turnover is populated from SLIPMONEYEURO of F_SLIP and CUST WIN is populated
from SLIPWINMONEYEURO of F_SLIP.
Level 4
If the end users want to see what is the performance of the products like Poker, Casino,
Sportsbook etc. on a daily basis, then BUS.AD_USERDAYPRODUCTTYPE table needs to be
used.
The granularity of AD_USERDAYPRODUCTTYPE is USERID, DATEFTAG,
PRODUCTTYPEID, CHANNELID and APPLICATIONID.
In case of Sportsbook, if the match is resulted later then the game view data is loaded. In this
case the DATEFTAG of AD_USERDAYPRODUCTTYPE is the day when the bet was resulted.

5.4

Important Views of WHMAIN

DV_APPLICATION
Application is sometimes called as Labor. Application refers to different websites like bwin.com,
bwin.it (for Italy), bwin.fr (for France) etc based on the APPLICATIONID.

Applications are further placed under certain Application Groups and APPLICATIONGROUPID
field denotes the Ids for that. The Application Groups can be found from
DV_APPLICATIONGROUP.
There are flags like ISCASINOAPPLICATION, ISSPORTSBOOK and
ISPOKERAPPLICATION in the view DV_APPLICATION. If a particular application belongs to
some product group, then the flag corresponding to that product would be set to 1. In some cases
all the three flags can be 0 as some of these applications are not in use anymore.

DV_CHANNEL_CR
Channel information is like Web Channel, SMS, Wireless etc. Almost 99% of the users are
coming via Web Channel.
The Channels which are not defined are denoted by the CHANNELID = 0.

The Channel Id and Channel Name are as below:Channel Id

Channel Name

Web

Wap

Sms

Download

DV_CHANNELGROUP_CR
The channels are part of some Channel Groups. There are two Channel Group Ids:- 1 denotes the
Channel Group Web and 2 denotes Wireless. The Channel Groups which are not defined are
denoted by 0.
DV_COMPANY_CR

There are two reporting layers WHMAIN and WHSAJOO.


There is a field called Company Id. If Company Id=1, then it is Bwin related data and if it is 2,
then it is Sajoo related data.
Based on the Company Id, the data goes either to WHMAIN or WHSAJOO.
SAJOO is basically a partner organization of BWIN.
One can place any kind of bets without real money. This can be done on freebwin
(freebwin.com) and for this the Company Id =3.
DV_COUNTRY
This view deals with the country related details.
COUNTRYNAME2 and COUNTRYNAME3 store the short name for the country.
This table is populated from BASE.BW_COUNTRY.
DV_COUNTRY_CR
This view has some kind of duplication to DV_COUNTRY.
ID field of this view stores the value of COUNTRYID of the view DV_COUNTRY.
SHORTNAME2 and SHORTNAME3 represent the short names for the countries.
FEDERALSTATESPRESENT is the flag which is used for maintaining the regulations. If the
value of the flag is 1, then there exists some kind of regulation and this flag is 1 for Germany and
Argentina. If the value of this flag is 0, then it is the normal country without any regulation.
DV_COUNTRY_EXTENDED
COUNTRYID is the country id of DV_COUNTRY. Apart from the normal country ids, there are
certain country ids like 10000 (GERMANY.COM), 10001 (GERMANY.NET), 10002
(GREECE.BAW), 10003 (GREECE.BTO) etc. and these are some kind of mixtures of country
formation. Every user has two different countries:- 1) Real User Country and 2) Application User
Country. If one is German, then Real User Country is the nationality of the user i.e. German and
the Application User Country deals with the applications on which one is registered (e.g.
bwin.fr).
DV_COUNTRYGROUP_CR and DV_COUNTRYGROUP_EXTENDED
The countries are grouped into different country groups for easier access to all the users. This is
done for creating the mixture of country specific details.

DV_CURRENCY_CR
This is a lookup view and it is used mainly to get currency name.
There is a stake limit for a single bet in a particular currency. This value is maintained in
MAXBETSINGLE field.
The stake limits for combo bets in a particular currency is stored in MAXBETCOMBO field.
DV_TAB_ZOLLWERTKURSE_CR
To get the currency rate, a view is present in WHMAIN schema called
DV_TAB_ZOLLWERTKURSE_CR. In this view the monthly currency rates are present. The
CURRENCYID of this view can be linked to the CURRENCYID of F_SLIP. It is generally
calculated at the beginning of every month say on 1st day of every month.
The field DATE_M consists of the first days of every month for a particular CURRENCYID and
the RATE field stores the currency conversion rates for a particular CURRENCYID
corresponding to a particular month.
If the final currency rates are available say, on 10th November, all the transactions for the first 10
days needs to be updated in the tables F_USERTRANSACTION and F_SLIP.
The view DV_TAB_ZOLLWERTKURSE_CR is updated when the currency rate is available
from the source system.
DV_TRANSACTIONSTYPES
This is a lookup view.
If the value of TRANSTYPECASHTYPE is either 1 or 3 then these are deposit transactions. If
the value is either 2 or 4, then these are withdrawal transaction types.
DV_EMPLOYEE_CR
This view stores the employee related details.

5.5

Lookup Tables

The lookup tables are present in the BASE layer and the naming convention for those starts with
LU_DE. Most of the dimensions and lookup tables are historized.
There are some common fields which are present in all these lookup tables.

Attribute Name

Description

DELETED_YN

If the record is deleted in the source system then this flag is set
to Y, otherwise it would be N.

CURRENT_RECORD

If the record is current then it would be 1 and if the record is


not current then it would be 0.

RSD

This stores the Record Start Date and it is the sysdate when the
record is loaded. The default date is 1/1/1900.

RED

This stores the Record End Date. If this is current record, then
this field is defaulted to 12/31/9999 11:59:59 PM.

There is a separate schema called WHLOOKUP for storing the lookup tables.
In WHCODE schema, the procedures like CR8_DE_TableName or CR8_FE_TableName are
used to populate the data to the Staging Area. Dedicated jobs are there for loading the LookUp
Tables.
For further usage of data in any kind of procedures, the Base layer tables are used as the source.
The tables present in WHLOOKUP schema are used for loading the data for the first time i.e. for
the initialization of data. In the past, there was a package to populate the lookup tables. By the
procedures like CR8_DE or CR8_FE, data gets populated to the tables present in
WHLOOKUP schema.

5.6

Cash View and Game View Concepts

In the Aggregate tables, the fields are represented as below:Attribute Name


TURNOVERCV

Description
Turnover Cash View where cash view is in the time of bet
placement.

HOLDCV/GGRCV

Hold Cash View (GGR Cash View is the Gross gaming Revenue in
Cash View).

FCOUNT/NROFBETSCV

Number of slips in cash view

TURNOVERGV

Turnover Game View where game view is at the time of resulting


i.e. after the match is over.

HOLDGV/GGRGV

Hold Game View (GGR Game View is the Gross Gaming Revenue
in Game View).

Let us consider the following example:TO CV

CUST WIN GGR CV TO GV

GGR GV

01/05/2009

10

10

29/07/2009

50

-50

10

-40

10

50

-40

10

-40

sum:

In Sportsbook, GGR is calculated as GGR = TURNOVER CUST WIN.


In the above example, 10 Euro bet is placed on 01/05/2009, so TO CV would contain the value
of 10. The game would be resulted on 29/07/2009 i.e. on this date the match is over. User wins
an amount of 50 Euro on this day. So, CUST WIN is 50 on 29/07/2009 and TO GV for this day
would be 10. As per the above formula, GGR CV = TO CV CUST WIN = 10-0 =10 on
01/05/2009 and 0-50 = -50 on 29/07/2009. Similarly, GGR GV = TO GV CUST WIN = 0-0 = 0
on 01/05/2009 and 10-50 = -40 on 29/07/2009.
There would be two separate rows in the aggregate tables as aggregate tables are based on a
particular user on a particular day. If a user places two bets on two different days and the game is
played on a different day than those two days of bet placement, then there would be 3 rows in the
aggregate tables. If the bet is placed three times by a user on a single day, then only one row
would exist for the cash view in the aggregate table.
If the cash view and game view both are populated for a user in a single row, then the bet is
placed on the same day in which the game would be resulted or the match would be played. If
the match is played on a different day than the bet placement day then for the match day the cash
view values would be zero and the game view values would be populated and vice versa.
If TO CV is 0 for a particular day for a user, then the user is not active on that day. So, to find the
number of active users, the Turnover CV field needs to be checked.

.
5.7

Maintaining Dependency in BUS Layer

The dependencies of the jobs are maintained by WHMETA.DWH_PROC_STATUS table.


The descriptions of the attributes for DWH_PROC_STATUS are as below:Attribute Name

Description

JOB_ID

Identifier of the job (Lookup to WHMETA.JOB_LKUP)

JOB_NAME

Job Name from the Lookup WHMETA.JOB_LKUP

STEP_SEQUENCE_NO

Starting Sequence Number representing the order in which the


procedures run within a job.

PROC_SCHEMA

Schema name of the procedure to be started.

PROC_NAME

Name of the procedure.

PROC_PARAMETER

Optional parameter of the procedure.

PROC_BLOCKING_NAME A unique name for the procedure against which it can be blocked.
BLOCKING_JOB_ID

The procedure defined corresponding to the row is blocked


against a complete job. This column can consist of several Job
Ids separated by | and this gives the option of blocking one
procedure based on the successful completion of multiple
procedures.

BLOCKING_STEP_NAME

This field can consist of multiple PROC_BLOCKING_NAMEs


separated by | so that one procedure can be blocked based on
the status of multiple procedures.

ISCRITICAL_YN

This flag explains whether the procedure is critical. If the value


of the flag is Y then it is critical and if it is N then it is not so
critical.

ISACTIVE_YN

This flag defines whether the procedure is active. If the flag is


Y then the procedure is active.

STEP_RUN_STATUS

This field contains the run status of the procedure. This field can
have values like Y (Running), N (Normal) and F (Failed).

6.

Important Racebook Objects


6.1

Racebook Aggregate Table BUS.AD_RACEBOOK_UDPT

In the Aggregate Table AD_RACEBOOK_UDPT, the columns are represented as below:Attribute Name

Description

RACEDAY

Date of the bet placement. Most of the time it is the date of the
race.

TOTALIZERID

This field has reference with ID field of


WHMAIN.DV_RB_TOTALIZER_CR. If the value of ID is 1, then
it corresponds to XGate and if it is 2, then it is for EasyGate.

You might also like