Beruflich Dokumente
Kultur Dokumente
Page
1.
CHANGE HISTORY...................................................................................................................................1
2.
SPORTSBOOK INTRODUCTION.......................................................................................................1
3.
5.
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
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.
Soccer
Sport
Region
(sTSport)
1
(sTRegion)
1
n
England
League
Premier League
(aTLeague)
1
n
Tournament
(aTTournament)
1
n
Event
(aTEvent)
1
n
Game
3 Way (1 X 2)
(aTGame)
1
n
Result
(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
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
Customer
Camembert
Slip
Bet1
(aTSlip)
(aTBet)
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)
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.
Combination 2
Combination 3
x
x
x
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)
ResultID4
(aTBet)
Bet4
SystemSlip
Odds
Bet2
Slip2
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.
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)
lost
cancel0
lost
won
won
cancel1
canceled
Multi Bet
Slip
Bet1
(aTSlip)
(aTBet)
ResultID
1
Odds1
Bet2
ResultID2
(aTBet)
Odds2
n.d.
result 2
n.d.
n.d.
n.d.
result 2
lost
lost
n.d.
result
2
won
n.d.
result status slip status
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
cancel1
result 2
cancel1
cancel1
Winning amount: 1(due to cancel1)*1(due to
cancel1)*stake Customer will get his amount back
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
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
(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.
Sports
Poker
Casino
Games
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.
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
LONGDESC
N/A
Not Available
PS
Prime Sports
CDS
HPS
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.
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 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
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
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
HOLDCV/GGRCV
Hold Cash View (GGR Cash View is the Gross gaming Revenue in
Cash View).
FCOUNT/NROFBETSCV
TURNOVERGV
HOLDGV/GGRGV
Hold Game View (GGR Game View is the Gross Gaming Revenue
in Game View).
NROFBETSGV
Level 3
5.4
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.
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
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
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
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
TURNOVERGV
HOLDGV/GGRGV
Hold Game View (GGR Game View is the Gross Gaming Revenue
in Game View).
GGR GV
01/05/2009
10
10
29/07/2009
50
-50
10
-40
10
50
-40
10
-40
sum:
.
5.7
Description
JOB_ID
JOB_NAME
STEP_SEQUENCE_NO
PROC_SCHEMA
PROC_NAME
PROC_PARAMETER
PROC_BLOCKING_NAME A unique name for the procedure against which it can be blocked.
BLOCKING_JOB_ID
BLOCKING_STEP_NAME
ISCRITICAL_YN
ISACTIVE_YN
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.
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