See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/323714070

The 3 steps of best data warehouse model design with leaning implementation
for sales transaction in franchise restaurant

Conference Paper · November 2017

DOI: 10.1109/CYBERNETICSCOM.2017.8311704

CITATION READS

1 302

3 authors:

Junaidi Junaidi Harco Leslie Hendric Spits Warnars

Raharja University Binus University
25 PUBLICATIONS   27 CITATIONS    222 PUBLICATIONS   736 CITATIONS   

SEE PROFILE SEE PROFILE

Yaya Heryadi
Binus University
71 PUBLICATIONS   255 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Executive Information Systems for Cabin Base Aircraft Maintenance at PT. GMF AeroAsia Tbk View project

Perfecting A Video Game with Game Metrics View project

All content following this page was uploaded by Harco Leslie Hendric Spits Warnars on 12 November 2020.

The user has requested enhancement of the downloaded file.

 The 3 steps of best Data Warehouse model design
With Leaning Implementation For Sales Transaction in Franchise Restaurant
Mohammad Subekti Junaidi
Computer Science Department, School of Computer
School of Computer Science, Science
Bina Nusantara University STMIK Raharja
Jakarta, Indonesia 11480 Banten, Indonesia 15117
Subekti@binus.ac.id junaidi@raharja.info
Abstract—Doing Data Warehouse (DW) to your business or
system is not only think about the trend only, but how to
understand the DW knowledge itself and how to implement it.
DW as a real technology of Artificial Intelligent (AI) which show
up as how to think like a human, inevitably help the human
particularly in making quick decision reports. Doing DW to your
systems should apply to the mother knowledge of AI which we
recognized as Software Engineering (SE) where we should apply
best software application in more importantly we should satisfy
the user. In order to make a good DW model design as user
expectation then we should apply 3 steps such as collect all the
needed reporting, order all the reports start from the most
needed reports and mapping all the ordered reports into fact
constellation schema. In this paper the 3 steps to model DW
schema is applied in sale transaction in franchise restaurant as
an example data. Building franchise restaurant must supported
by information technology such as Data Warehouse (DW) in
order to manage and control the business process, the branch, the
sale, the staff and so on.
Keywords—Star Schema; Snowflake; Fact Constellation; Data
Warehouse; OLAP
I. INTRODUCTION
The Big Data rhetoric has drowned the glory of the data
warehouse with big data rhetoric such as Velocity, Volume and
Variety. Data Warehouse(DW) when was invented by father of
DW Bill Inmon, strongly clear that DW is not hardware or
software implementation but it’s a technology how to improve
your information system application. In term of V for Volume,
DW has been recognized for handling huge or large volume of
data and term of V for Variety, Bill Inmon had done the
implementation of DW in unstructured data but lost the
prestige with Big Data. Moreover, in term of V for Velocity,
there were some DW implementation using MapReduce or
parallel computation (sometimes called distributed computing
or grid computing) and MapReduce is recognizes as parallel
computation algorithm as well.
Data Warehouse is not a hardware or a software, but it is
intelligent technology where how we create best performance
database environment for making fast response reports in
decision making system[1,4]. Best performance database
environment for creating fast creating report only can be done
where they have unnormalized database, where the
unnormalized database will reduce join tables process in sql
Harco Leslie Hendric Spits Warnars1,
Yaya Heryadi2
Computer Science Department, BINUS Graduate
Program – Doctor of Computer Science
Bina Nusantara University
Jakarta, Indonesia 11480
Spits.hendric@binus.ac.id 1,
yayaheryadi@binus.edu 2
statement[2,3,6]. Thus, less of join tables in sql statement will
boost the sql query process and at the end will speed up
creating reports for supporting decision making.
Regarding with unnormalized database, then we recognized
this is as data warehouse in form of database with schemas
such as star schema, snowflake schema or fact constellation
schema and wrapped up as OLAP (Online Analytical
Processing)[7]. On other hand, we have OLTP (Online
Transcational Processing) or sometime can be said as TPS
(Transactional Processing Systems) as a system for dealing
with day to day activity business and equipped with normalized
database as opposed of OLAP with unnormalized
database[10,11,12]. The unnormalized database in OLAP is
came from normalized database in OLTP with ETL (Extraction
Transformation and Loading) process[8,9].
Meanwhile, restaurant as easy convenient for generate
profit money income, inevitably the thing most people look for.
Human should and need to eat and can we imagine how human
can life without eating? Indeed, restaurant business is an easy
peasy business, where if you have good recipe, and people like
it, then you can have their money with selling food to them.
Moreover, franchise restaurant is booming fast food chain
restaurant, where for those who want to raise the profit from
food industry can easily to join with some term conditions and
investment. Franchise restaurant is an easy peasy business
where the investor do not need to create their own recipes or
restaurant management, but only focus with how much money
what to invest[13].
Along with the growing interest of the people to invest their
money in the franchise restaurant business, and the growing of
number option of franchise restaurant, it cannot be denied by
the increasing number of members of the investors and
branches of franchise restaurants, then there will problems in
reporting process, particularly for quick decision making
process. The more the number of branches of a managed
franchise restaurant will make it more difficult to determine
strategic decisions related to branch development and
competition among franchised restaurants. As franchise
branches grow more and more, managers will find it difficult to
manage where the amount of data gets bigger and complex
with the problems of each branch. Managers will find it
difficult, when determining the right type and price of food
menu to be relocated, given some types of food menu outdated
170
or competition with other restaurant industries or other
franchise restaurants. In addition, it may be an outdated type or
price of food menu, still an idol in some branches.
restaurant as profitable venture, inevitably become one
option to invest. People need to eat on daily basis and more
than that people need beyond the food that they eat and
restaurant is profitable business which is not only feed the
customer but beyond that entertain their customer, with the
view and the presentation the place and the food itself.
Building business restaurant as a franchise restaurant is another
possible profit income, but inevitably create new problem
where the more branches the more problem will raise
particularly for management purposes. One of recognized
problem is lack of update information technology support
particularly for data streaming and data updating on daily basis
or even hourly basis. Inevitably, building franchise restaurant
must supported by information technology such as Data
Warehouse (DW) in order to manage and control the business
process, the branch, the sale, the staff and so on. DW has been
recognized as powerful technology which can delivered reports
which can be used by franchise restaurant management or
owner in order to control the profit. This paper will give view
with the optional to implement the sales transaction into DW
which explanation for each model DW design. At the end user
will make decision which one suitable DW schema design.
Obviously, we need to implement intelligent application in
order to support the restaurant franchise business when running
their business and compete with others in terms of franchise
restaurant management. Data Warehouse is one the door to
enter the others intelligent application and truly we should
prepare by creating ideal data warehouse schema based on
current OLTP database system.
4. Menu1 (MenuID(PK), TypeMenuID(FK), MenuName,
Price)
Table Menu1 is a table which content the menu is offered
in the franchise restaurant.
5. TypeMenu1 (TypeMenuID(PK), TypeMenuName)
Table TypeMenu1 is a table which content the type of
menu offered.
6. Staff1 (StaffID(PK), BranchID(FK), StaffName, Address,
DateBirth, Gender, CheckID(FK))
Table Staff1 is a table which record the staff data which
was assigned to one of franchise restaurant branch.
7. Branch1 (BranchID(PK), BranchName, Location,
CheckID)
Table Branch1 is a table which record the franchise
restaurant branch.
8. Payment1 (PaymentID(PK), TypeDiscountID(FK),
TypePaymentID(FK), Price)
Table Payment1 is a table which record the way the
transaction is paid and if there is a discount.
9. TypeDiscount1 (TypeDiscountID(PK), DiscountName)
Table TypeDiscount1 is a table which record type of
payment.
10. TypePayment1 (TypePaymentID(PK),
TypePaymentName)
Table TypePayment1 is a table which record type of
discount.

II. CURRENT OLTP DATABASE SYSTEMS

Figure 1 is class diagram of sale transaction at franchise
restaurant where the PK is Primary Key while FK is Foreign
Key, where each table has PK and each FK as connection to
other table[14] . There are 10 tables normalized database in
figure 1 and they are :
1. Check1 (CheckID(PK), BranchID(FK), StaffID(FK),
PaymentID(FK), TransactionID(FK), NomorCheck,
Status, DateOpen, DateClosed, Subtotal, Tax,
ServiceCharge, TotalPrice)
Table Check1 is a table which record each order which
made by customer and as complement of table
Transaction1, where each customer can have many
transactions.
2. Details1 (DetailsID(PK), TransactionID(FK),
CheckID(FK), MenuID(FK), TypeDetails, QtyBuy,
PriceBuy)
Table Details1 is a table which record how many type of
menu which ordered by each customer’s transaction.
3. Transactions1 (TransactionID(PK), DateActionOpen,
DateActionClosed, StaffID(FK), DetailsID(FK))
Table Transactions1 is a table which record each
transaction ordered by customer and as complement table Fig. 1. Design class diagram of sale transaction at franchised restaurant
Check1.

171
 III. DATA WAREHOUSE MODEL DESIGN Key) in star schema in figure 2 and PK (Primary Key) in
Database model design in figure 1 shows as database for OLTP tables. Those attributes are DateID, MenuID, PayID,
transactions purpose where we recognized as OLTP/TPS BranchID, StaffID and all of them become 5 dimension tables
where it is as day to day system which dealing with customer (DateTrans, Branch, Menu, Payment, Staff) where in each
or external entity. On other hand, data warehouse is database dimension table has PK as Primary Key which refer to their
model design for reporting purposes which we recognized as FK as Foreign Key in fact table Sale. As a result, in figure 3,
OLAP. It is better for systems to split between transactional there are 1 fact table (sale) and 5 dimension tables where each
and reporting or between OLTP and OLAP, where at the end of them have relationship 1 to many association to the fact
the performance will be achieved for both of them. table sale.
In Data Warehouse, there are many option database model Figure 4 is a normalization of each table dimension in
design which can be opted and its represent in schemas which figure 3, for example only table staff does not have
can be called such as star schema, snowflake schema, fact normalization, where table branch is normalized become
constellation schema or galaxy schema. This schema will be subdimension table SubBranch, and table Payment is
built based on sale reporting which needed by the system. normalized into subdimension table CatPayment. Moreover,
Figure 2 is an example of star schema with only 1 fact table, table DateTrans has double normalization where normalized to
where the data in its fact table came from the sale reporting table week and table Week is normalized to table Month.
which consist each attribute in that fact table. Meanwhile, Table Menu is normalized into table SubMenu
and its table is normalized into table CatMenu.
Sale The arrow which appoint the fact table shows as
DateID
DateTrans unNormalization and its means the more inside the table the
MenuID
MenuName more unNormal the table. On other hand, the arrow which
TypeMenuName leave the fact table shows as Normalization and its means the
Qtybuy
Pricebuy more outside the table the more Normal the table.
Subtotal
Tax
ServiceCharge Month unNormalization
Discount MonthID (PK) 1 CatMenu
TotalPrice MonthTrans 1 CatMenuID (PK)
PayID Normalization CatMenuName
BranchID
Branchname
SubBranchName Week * Sale SubMenu
StaffID WeekID (PK) MenuID (FK) * SubMenuID (PK)
WeekTrans 1 StaffID(FK)
SfaffName Monthid (FK) 1 SubMenuName
DateID(FK) CatMenuid(FK)
* PayID(FK)
Fig. 2. Star schema with only fact table of sale transaction at franchised BranchID(FK) *
restaurant DateTrans 1 * Qtybuy Menu
DateID (PK) Pricebuy * 1 MenuID (PK)
DateTrans Subtotal MenuName
The record/tuple in fact table figure 2 is recognized as Weekid(FK) Tax’ SubMenuid(FK)
ServiceCharge
unnormalized data where there are repeating in some Discount
1 * TotalPrice * 1
attributes. For example, attributes such as Branchid, Branch Payment
BranchID(PK) PayID(PK)
Branchname, SubBranchName will be repeated since in one Branchname * Way2Pay
SubBranchid(FK) CatPayid(FK)
order transaction in one branch restaurant will have many 1
ordered menu. *
Staff *
SubBranch StaffID(PK) CatPayment
SubBranchID(PK) 1 StaffName 1 CatPayID(PK)
DateTrans SubBranchname CatPayName
Menu
DateID (PK) 1 * Sale
DateTrans * 1 MenuID
MenuName
(PK)
Fig. 4. Snowflake schema of sale transaction at franchised restaurant
WeekTrans MenuID (FK)
StaffID(FK) SubMenuName
MonthTrans CatMenuName
DateID(FK)
PayID(FK) Figure 4 is recognized as snowflake schema, where sub
1 * BranchID(FK) * 1
Branch Qtybuy Payment dimension table is created and figure 4 shows a snowflake
BranchID(PK) PayID(PK)
Branchname Pricebuy Way2Pay table with 1 fact table Sale, 4 dimension tables such as
SubBranchName Subtotal CatPayName
Tax’ DateTrans, Branch, Staff, Menu and Payment. Moreover, it
ServiceCharge has 4 sub dimension tables such as Week, SubBranch,
Discount * 1
TotalPrice Staff SubMenu and CatPayment and 2 subsub dimension tables
StaffID(PK)
StaffName such as Month and CatMenu.
Fig. 3. Star schema of sale transaction at franchised restaurant The furthest table from the fact table will have one to
many association to the next associated table and so do with
Figure 3 is an example of normalization of star schema in the next associated table to the fact table. Obviously, subsub
figure 2, where some class or entity such as Date, Menu, dimension table has 1 to many association to sub dimension
Branch, Payment and Staff are created. The creation of each table and sub dimension table has 1 to many association to
dimension table come from chosen of unique attribute in star dimension table and thus dimension table has 1 to many
schema in figure 2 or recognized as attribute FK (Foreign association to the fact table. Each of subsub dimension table

172
has PK which associated to its FK in its sub dimension table,
and each sub dimension table has PK which associated to its
FK in its dimension table. Moreover, each dimension table has
PK which associated to its FK in fact table. For example, table
CatMenu as subsub dimension table has PK=CatMenuID
which become FK in table SubMenu as sub dimension table
and table SubMenu has PK=SubMenuID which become FK in
table Menu as dimension table. Finally, table Menu has
PK=MenuID which become FK in fact table sale.
This snowflake table is possible become fact constellation
schema or recognized as galaxy schema, when there is another
fact table which associated to at least one of dimension or sub
dimension or subsub dimension tables. Thus, when dimension
or sub dimension or subsub dimension tables has association
with more than one fact table then it will be called snowflake
or galaxy schema Data Warehouse.
IV. JUSTIFICATION BETTER SCHEMA DESIGN FOR
IMPLEMENTATION
After we got star schemas in figure 2 and 3 and snowflake
schema in figure 4, then the next question is which one as best
Data Warehouse (DW) schema? We should define why star
schema in figure 2 or 3 is as best excellence DW schema or
why snowflake schema in figure 4 is more better! But first of
all, we should understand with the fact table, how to build the
fact table, what the criteria or requirement to build the fact
table! Since DW was invented for reporting purposes, where
split between OLTP and OLAP then in order to find which
one as best excellent DW schema then we should find which
one as DW schema with best excellent reporting performance.
The fact table in DW represents the report in the system
and there is limitation how many reports resources can create
how many fact tables. The minimum requirement is from 1
report can create 1 fact table, and possible as well if 1 fact
table can be created based on many reports. Let say, one or
more reporting can create one or more fact table, but
impossible if from 1 report create many fact table, because it
will make the ambiguity and of course the redundancy.
Star schema in figures 2 is more faster for creating reports
rather than star schema in figure 3, but star schema in figure 2
is wasteful in data storage allocation rather than star schema in
figure 3. Creating report with star schema in figure 2 does not
need join operation between tables in sql statement, so that is
why star schema in figure 2 is faster for creating report differ to
star schema in figure 3. On other hand, creating report with star
schema in figure 3 will need join tables operation in sql
statement where at the end will decrease the report creation
performance differ with creating report with star schema in
figure 2. Remember, in sql statement running the sql statement
only for 1 table is more faster rather than running sql statement
with more than 1 table where there is needed to make joint
operation.
The next question is which one as suitable
implementation? Star schema with only 1 fact table as shown
in figure 2 or star schema with 5 dimension tables as shown in
figure 3 or snowflake schema in figure 4? To answer this
question, then we should reverse back to the theory of
software enginnering (SE), where the point of SE is how to
deliver best excellent software application in order to satisfy
the user. As long as the user are not satisfied with the software
application implementation then we have done the wrong SE,
no matter what the reasons behind that.
Since DW was invented for creating report purposes, then
the satisfaction of user when using DW technology is when
the DW can make faster reporting which particularly to
support in quick response decision making process. When the
DW can make quick response reporting then the user as
usually middle and high level management will satisfy,
otherwise its catastrophe.
In order to make faster DW environment which rely on
creating reporting, then we should do the next steps:
1. Collect all the needed reporting.
2. Order all the reports start from the most needed reports.
3. Mapping all the ordered reports into fact constellation
schema.
So, going back again, to the problem, which one as best
excellent DW schema? The answer is again! we should do
best excellent SE where making a good software application
which satisfy our user.
Sometimes, there is a question in our head regarding with
join sql statement, where if join process in sql statement will
decrease the performance then why do not just only having
star schema without dimension table as seen in figure 2? Why
there is star schema with dimension tables as shown in figure
3 or even snowflake schema which including content sub and
subsub dimension tables as shown in figure 4? We are agree
that the fact table only in figure 2 is more faster to create
reporting rather than star schema in figure 3 or even snowflake
schema in figure 4. More than that fact constellation schema is
the most applied DW schema and in reality DW environment,
we can not have DW schema with 1 or 2 fact tables only.
Absolutely, fact constellation schema is the most suitable and
the most applied DW schema.
Fig. 5. Mapping reporting order in snowflake schema
173
 Figure 5 shows the 3rd process as mention above, how to
map all the ordered reports into fact constellation schema and
as mention before that fact constellation schema is the most
applied DW schema, but for example we run to snowflake
schema in figure 4 as for convenience and easy to explain. In
figure 5, there are 4 numbering which represent the ordered
reports start from report number 1 as the most needed report to
report number 4:
1. Report number 1 is a report which is created from table
sale only.
2. Report number 2 is a report which is created from 3 tables
such as sale, DateTrans and Week.
3. Report number 3 is a report which is created from 4 tables
such as sale, DateTrans, Week and Month.
4. Report number 4 is a report which is created from 7 tables
such as sale, Menu, SubMenu, CatMenu, Payment,
CatPayment and Staff.
Report number 1 was mapped since as the most needed
report by the management and probably, this is kind of report
which usually needed on minutely basis, where it should be
created in minutes. Off course, since this is the most needed
report then it only has 1 table only which is the fact table,
where at the end there is no join process in sql statement and
at the end will increase time to create the report. Meanwhile,
other reports such as report number 2 as the second ordered
needed report needs 3 tables to create the report, report
number 3 needs 4 tables whilst report number 4 needs 7 tables.
Thus, join process in sql statement upon tables databases will
decrease time to delivery or easy to say as performance.
Obviously, when mapping the ordered report into fact
constellation schema, we have to think the 1st order needed
report should have the minimum time to deliver the report and
other report will follow as an ordered time report delivery. Its
means that the DW schema design should confirm as to fulfil
the SE concept where we need to deliver best excellent
software application in order to satisfy the user.
Conclusion
When deliver our Data Warehouse (DW) environment or as
recognized as DW schema, we have to apply Software
Engineering (SE concept) where we should create best
excellent software application which is literally to satisfy our
user. No mater normal or unNormal DW schema design, we
believe that unNormalizing will boost the performance whilst
normalizing will decrease the performance. However, we do
not keen only in unnormalizing since there are many repeating
and recognize as digital rubbish and difficult as well when
dealing with this repeating think. On other hand, normalizing,
is more convenient to maintain and easy to follow, but since
including many tables then the cost of performance will
decrease.
The three steps such as collect all the needed reporting,
order all the reports start from the most needed reports and
mapping all the ordered reports into fact constellation schema
is the easy way to create best SE implementation in order to
create best DW schema design. Moreover, user requirement
tools such as questionnaire, interview, Meeting, observation
View publication stats
can be applied in order to implement the three steps of best
DW schema design implementation.
REFERENCES
[1] H.L.H.S, Warnars and R. Randriatoamanana. Datawarehouser: A Data
Warehouse artist who have ability to understand data warehouse schema
pictures. IEEE TENCON 2016 (Technologies for Smart Nation), pp.
2207-2210, 22-25 Nov 2016, Singapore, 2016.
[2] H.L.H.S, Warnars. Rancangan Infrastruktur E-Bisnis Business
Intelligence Pada Perguruan Tinggi. Journal Telkomnika, 6(2), 115-124,
August 2008.
[3] H.L.H.S, Warnars. Analisa Dampak Investasi Teknologi Informasi
Proyek Data Warehouse Pada Perguruan Tinggi Swasta Dengan Metode
Simple Roi. Journal Informatika, 9(2), 101-108, November 2008.
[4] H.L.H.S, Warnars. Desain ETL dengan contoh kasus Perguruan Tinggi.
Journal Informatika, vol. 10, no. 2, pp. 86-93, November 2009.
[5] H.L.H.S, Warnars. Simple ROI untuk justifikasi investasi proyek Data
Warehouse pada perguruan tinggi swasta. Journal Ilmiah Teknik
Komputer, vol. 1, no.1, pp. 64-84, November 2009.
[6] H.L.H.S, Warnars. Desain model data warehouse dengan contoh kasus
perguruan tinggi. Journal of Industrial Engineering and Management
System (JIEMS), vol. 3, no. 1, pp. 9-20, February 2010.
[7] H.L.H.S, Warnars. Tata Kelola Database Perguruan Tinggi Yang
Optimal Dengan Data Warehouse. Journal Telkomnika, vol.8, no. 1, pp.
25-34, April 2010.
[8] H.L.H.S, Warnars. Perbandingan penggunaan Database OLTP (Online
Transactional Processing) dan Data Warehouse. Creative
Communication and Innovative Technology (CCIT) journal, vol. 8, no.1,
pp. 83-100, September 2014.
[9] H.L.H.S, Warnars, E. Suria and D.K. Jeremy. Pemahaman teori Data
Warehouse bagi Mahasiswa tahun awal jenjang strata satu bidang ilmu
komputer. Jurnal informatika, vol. 13, no. 1, pp. 20-24, Mei 2015.
[10] H.L.H.S, Warnars. Multidimensi pada Data Warehouse dengan
menggunakan rumus Kombinasi. The 2nd National Seminar, National
Seminar Information Technology Application 2006, University of Islam
Indonesia, pp. 1-6, Yogyakarta, 17 June 2006.
[11] H.L.H.S, Warnars. Multidimensi pada Data Warehouse dengan
menggunakan rumus Kombinasi. The 2nd National Seminar, engineer
industry and information technology, Sekolah Tinggi Teknologi
Nasional, Yogyakarta, 15 July 2006.
[12] H.L.H.S, Warnars. Multidimensional Datwarehouse with Combination
formula. The 2nd International Conference on Information and
Communication Technology and Systems (ICTS), Informatics
Department, Faculty of Information Technology, Institute of Technology
Sepuluh Nopember (ITS), Surabaya, Indonesia, 29 August 2006.
[13] P.P. Oleynik, O.I. Nikolenko and S.Y. Yuzefova. Information System
for Fast Food Restaurants, Engineering and Technology, vol. 2, no.4,
pp.186-191, 2015.
[14] P.U. Maurif, Penerapan data mining dengan teknik attribute oriented
induction untuk mencari characteristic dan discriminant rule transaksi
penjualan pada restoran franchise pt. Sushitei indonesia , Thesis S2,
Bina Nusanatara university, 2014.
[15] E. Capriolo, D. Wampler and J. Rutherglen. Programming Hive: Data
Warehouse and Query Language for Hadoop. 1 st ed., O’Reilly Media,
Inc. , California, USA, October 2012.
[16] S. Maitrey and C.K. jha, Mapreduce: Simplified Data Analysis of Big
Data, Procedia Computer Science, vol. 57, pp. 563-571, 2015.
[17] A.Thusoo, J.S. Sarma, N. Jain, Z. Shao, P. Chakka, N. Zhang, S.
Antony, H. Liu and R. Murthy, Hive- A petabyte scale Data Warehouse
using Hadoop, 26th International Conference on Data Engineering
(ICDE), Callifornia, USA, 1-6 March 2010.
[18] W.H. Imnon and K. Krishnan. Building the unstructured data
warehouse: architecture, Analysis and Design, 1st ed., Technic
publications, New Jersey, USA, January 2011.
174