\documentclass[11pt,twoside]{article}\makeatletter

\IfFileExists{xcolor.sty}%
  {\RequirePackage{xcolor}}%
  {\RequirePackage{color}}
\usepackage{colortbl}
\usepackage{wrapfig}
\usepackage{ifxetex}
\ifxetex
  \usepackage{fontspec}
  \usepackage{xunicode}
  \catcode`⃥=\active \def⃥{\textbackslash}
  \catcode`❴=\active \def❴{\{}
  \catcode`❵=\active \def❵{\}}
  \def\textJapanese{\fontspec{Noto Sans CJK JP}}
  \def\textChinese{\fontspec{Noto Sans CJK SC}}
  \def\textKorean{\fontspec{Noto Sans CJK KR}}
  \setmonofont{DejaVu Sans Mono}
  
\else
  \IfFileExists{utf8x.def}%
   {\usepackage[utf8x]{inputenc}
      \PrerenderUnicode{–}
    }%
   {\usepackage[utf8]{inputenc}}
  \usepackage[english]{babel}
  \usepackage[T1]{fontenc}
  \usepackage{float}
  \usepackage[]{ucs}
  \uc@dclc{8421}{default}{\textbackslash }
  \uc@dclc{10100}{default}{\{}
  \uc@dclc{10101}{default}{\}}
  \uc@dclc{8491}{default}{\AA{}}
  \uc@dclc{8239}{default}{\,}
  \uc@dclc{20154}{default}{ }
  \uc@dclc{10148}{default}{>}
  \def\textschwa{\rotatebox{-90}{e}}
  \def\textJapanese{}
  \def\textChinese{}
  \IfFileExists{tipa.sty}{\usepackage{tipa}}{}
\fi
\def\exampleFont{\ttfamily\small}
\DeclareTextSymbol{\textpi}{OML}{25}
\usepackage{relsize}
\RequirePackage{array}
\def\@testpach{\@chclass
 \ifnum \@lastchclass=6 \@ne \@chnum \@ne \else
  \ifnum \@lastchclass=7 5 \else
   \ifnum \@lastchclass=8 \tw@ \else
    \ifnum \@lastchclass=9 \thr@@
   \else \z@
   \ifnum \@lastchclass = 10 \else
   \edef\@nextchar{\expandafter\string\@nextchar}%
   \@chnum
   \if \@nextchar c\z@ \else
    \if \@nextchar l\@ne \else
     \if \@nextchar r\tw@ \else
   \z@ \@chclass
   \if\@nextchar |\@ne \else
    \if \@nextchar !6 \else
     \if \@nextchar @7 \else
      \if \@nextchar (8 \else
       \if \@nextchar )9 \else
  10
  \@chnum
  \if \@nextchar m\thr@@\else
   \if \@nextchar p4 \else
    \if \@nextchar b5 \else
   \z@ \@chclass \z@ \@preamerr \z@ \fi \fi \fi \fi
   \fi \fi  \fi  \fi  \fi  \fi  \fi \fi \fi \fi \fi \fi}
\gdef\arraybackslash{\let\\=\@arraycr}
\def\@textsubscript#1{{\m@th\ensuremath{_{\mbox{\fontsize\sf@size\z@#1}}}}}
\def\Panel#1#2#3#4{\multicolumn{#3}{){\columncolor{#2}}#4}{#1}}
\def\abbr{}
\def\corr{}
\def\expan{}
\def\gap{}
\def\orig{}
\def\reg{}
\def\ref{}
\def\sic{}
\def\persName{}\def\name{}
\def\placeName{}
\def\orgName{}
\def\textcal#1{{\fontspec{Lucida Calligraphy}#1}}
\def\textgothic#1{{\fontspec{Lucida Blackletter}#1}}
\def\textlarge#1{{\large #1}}
\def\textoverbar#1{\ensuremath{\overline{#1}}}
\def\textquoted#1{‘#1’}
\def\textsmall#1{{\small #1}}
\def\textsubscript#1{\@textsubscript{\selectfont#1}}
\def\textxi{\ensuremath{\xi}}
\def\titlem{\itshape}
\newenvironment{biblfree}{}{\ifvmode\par\fi }
\newenvironment{bibl}{}{}
\newenvironment{byline}{\vskip6pt\itshape\fontsize{16pt}{18pt}\selectfont}{\par }
\newenvironment{citbibl}{}{\ifvmode\par\fi }
\newenvironment{docAuthor}{\ifvmode\vskip4pt\fontsize{16pt}{18pt}\selectfont\fi\itshape}{\ifvmode\par\fi }
\newenvironment{docDate}{}{\ifvmode\par\fi }
\newenvironment{docImprint}{\vskip 6pt}{\ifvmode\par\fi }
\newenvironment{docTitle}{\vskip6pt\bfseries\fontsize{22pt}{25pt}\selectfont}{\par }
\newenvironment{msHead}{\vskip 6pt}{\par}
\newenvironment{msItem}{\vskip 6pt}{\par}
\newenvironment{rubric}{}{}
\newenvironment{titlePart}{}{\par }

\newcolumntype{L}[1]{){\raggedright\arraybackslash}p{#1}}
\newcolumntype{C}[1]{){\centering\arraybackslash}p{#1}}
\newcolumntype{R}[1]{){\raggedleft\arraybackslash}p{#1}}
\newcolumntype{P}[1]{){\arraybackslash}p{#1}}
\newcolumntype{B}[1]{){\arraybackslash}b{#1}}
\newcolumntype{M}[1]{){\arraybackslash}m{#1}}
\definecolor{label}{gray}{0.75}
\def\unusedattribute#1{\sout{\textcolor{label}{#1}}}
\DeclareRobustCommand*{\xref}{\hyper@normalise\xref@}
\def\xref@#1#2{\hyper@linkurl{#2}{#1}}
\begingroup
\catcode`\_=\active
\gdef_#1{\ensuremath{\sb{\mathrm{#1}}}}
\endgroup
\mathcode`\_=\string"8000
\catcode`\_=12\relax

\usepackage[a4paper,twoside,lmargin=1in,rmargin=1in,tmargin=1in,bmargin=1in,marginparwidth=0.75in]{geometry}
\usepackage{framed}

\definecolor{shadecolor}{gray}{0.95}
\usepackage{longtable}
\usepackage[normalem]{ulem}
\usepackage{fancyvrb}
\usepackage{fancyhdr}
\usepackage{graphicx}
\usepackage{marginnote}

\renewcommand{\@cite}[1]{#1}


\renewcommand*{\marginfont}{\itshape\footnotesize}

\def\Gin@extensions{.pdf,.png,.jpg,.mps,.tif}

  \pagestyle{fancy}

\usepackage[pdftitle={Mediation of Lazy Update Propagation in a Replicated Database over a Decentralized P2P Architecture},
 pdfauthor={}]{hyperref}
\hyperbaseurl{}

	 \paperwidth210mm
	 \paperheight297mm
              
\def\@pnumwidth{1.55em}
\def\@tocrmarg {2.55em}
\def\@dotsep{4.5}
\setcounter{tocdepth}{3}
\clubpenalty=8000
\emergencystretch 3em
\hbadness=4000
\hyphenpenalty=400
\pretolerance=750
\tolerance=2000
\vbadness=4000
\widowpenalty=10000

\renewcommand\section{\@startsection {section}{1}{\z@}%
     {-1.75ex \@plus -0.5ex \@minus -.2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\Large\bfseries}}
\renewcommand\subsection{\@startsection{subsection}{2}{\z@}%
     {-1.75ex\@plus -0.5ex \@minus- .2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\Large}}
\renewcommand\subsubsection{\@startsection{subsubsection}{3}{\z@}%
     {-1.5ex\@plus -0.35ex \@minus -.2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\large}}
\renewcommand\paragraph{\@startsection{paragraph}{4}{\z@}%
     {-1ex \@plus-0.35ex \@minus -0.2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\normalsize}}
\renewcommand\subparagraph{\@startsection{subparagraph}{5}{\parindent}%
     {1.5ex \@plus1ex \@minus .2ex}%
     {-1em}%
     {\reset@font\normalsize\bfseries}}


\def\l@section#1#2{\addpenalty{\@secpenalty} \addvspace{1.0em plus 1pt}
 \@tempdima 1.5em \begingroup
 \parindent \z@ \rightskip \@pnumwidth 
 \parfillskip -\@pnumwidth 
 \bfseries \leavevmode #1\hfil \hbox to\@pnumwidth{\hss #2}\par
 \endgroup}
\def\l@subsection{\@dottedtocline{2}{1.5em}{2.3em}}
\def\l@subsubsection{\@dottedtocline{3}{3.8em}{3.2em}}
\def\l@paragraph{\@dottedtocline{4}{7.0em}{4.1em}}
\def\l@subparagraph{\@dottedtocline{5}{10em}{5em}}
\@ifundefined{c@section}{\newcounter{section}}{}
\@ifundefined{c@chapter}{\newcounter{chapter}}{}
\newif\if@mainmatter 
\@mainmattertrue
\def\chaptername{Chapter}
\def\frontmatter{%
  \pagenumbering{roman}
  \def\thechapter{\@roman\c@chapter}
  \def\theHchapter{\roman{chapter}}
  \def\thesection{\@roman\c@section}
  \def\theHsection{\roman{section}}
  \def\@chapapp{}%
}
\def\mainmatter{%
  \cleardoublepage
  \def\thechapter{\@arabic\c@chapter}
  \setcounter{chapter}{0}
  \setcounter{section}{0}
  \pagenumbering{arabic}
  \setcounter{secnumdepth}{6}
  \def\@chapapp{\chaptername}%
  \def\theHchapter{\arabic{chapter}}
  \def\thesection{\@arabic\c@section}
  \def\theHsection{\arabic{section}}
}
\def\backmatter{%
  \cleardoublepage
  \setcounter{chapter}{0}
  \setcounter{section}{0}
  \setcounter{secnumdepth}{2}
  \def\@chapapp{\appendixname}%
  \def\thechapter{\@Alph\c@chapter}
  \def\theHchapter{\Alph{chapter}}
  \appendix
}
\newenvironment{bibitemlist}[1]{%
   \list{\@biblabel{\@arabic\c@enumiv}}%
       {\settowidth\labelwidth{\@biblabel{#1}}%
        \leftmargin\labelwidth
        \advance\leftmargin\labelsep
        \@openbib@code
        \usecounter{enumiv}%
        \let\p@enumiv\@empty
        \renewcommand\theenumiv{\@arabic\c@enumiv}%
	}%
  \sloppy
  \clubpenalty4000
  \@clubpenalty \clubpenalty
  \widowpenalty4000%
  \sfcode`\.\@m}%
  {\def\@noitemerr
    {\@latex@warning{Empty `bibitemlist' environment}}%
    \endlist}

\def\tableofcontents{\section*{\contentsname}\@starttoc{toc}}
\parskip0pt
\parindent1em
\def\Panel#1#2#3#4{\multicolumn{#3}{){\columncolor{#2}}#4}{#1}}
\newenvironment{reflist}{%
  \begin{raggedright}\begin{list}{}
  {%
   \setlength{\topsep}{0pt}%
   \setlength{\rightmargin}{0.25in}%
   \setlength{\itemsep}{0pt}%
   \setlength{\itemindent}{0pt}%
   \setlength{\parskip}{0pt}%
   \setlength{\parsep}{2pt}%
   \def\makelabel##1{\itshape ##1}}%
  }
  {\end{list}\end{raggedright}}
\newenvironment{sansreflist}{%
  \begin{raggedright}\begin{list}{}
  {%
   \setlength{\topsep}{0pt}%
   \setlength{\rightmargin}{0.25in}%
   \setlength{\itemindent}{0pt}%
   \setlength{\parskip}{0pt}%
   \setlength{\itemsep}{0pt}%
   \setlength{\parsep}{2pt}%
   \def\makelabel##1{\upshape ##1}}%
  }
  {\end{list}\end{raggedright}}
\newenvironment{specHead}[2]%
 {\vspace{20pt}\hrule\vspace{10pt}%
  \phantomsection\label{#1}\markright{#2}%

  \pdfbookmark[2]{#2}{#1}%
  \hspace{-0.75in}{\bfseries\fontsize{16pt}{18pt}\selectfont#2}%
  }{}
      \def\TheFullDate{2019-01-15 (revised: 15 January 2019)}
\def\TheID{\makeatother }
\def\TheDate{2019-01-15}
\title{Mediation of Lazy Update Propagation in a Replicated Database over a Decentralized P2P Architecture}
\author{}\makeatletter 
\makeatletter
\newcommand*{\cleartoleftpage}{%
  \clearpage
    \if@twoside
    \ifodd\c@page
      \hbox{}\newpage
      \if@twocolumn
        \hbox{}\newpage
      \fi
    \fi
  \fi
}
\makeatother
\makeatletter
\thispagestyle{empty}
\markright{\@title}\markboth{\@title}{\@author}
\renewcommand\small{\@setfontsize\small{9pt}{11pt}\abovedisplayskip 8.5\p@ plus3\p@ minus4\p@
\belowdisplayskip \abovedisplayskip
\abovedisplayshortskip \z@ plus2\p@
\belowdisplayshortskip 4\p@ plus2\p@ minus2\p@
\def\@listi{\leftmargin\leftmargini
               \topsep 2\p@ plus1\p@ minus1\p@
               \parsep 2\p@ plus\p@ minus\p@
               \itemsep 1pt}
}
\makeatother
\fvset{frame=single,numberblanklines=false,xleftmargin=5mm,xrightmargin=5mm}
\fancyhf{} 
\setlength{\headheight}{14pt}
\fancyhead[LE]{\bfseries\leftmark} 
\fancyhead[RO]{\bfseries\rightmark} 
\fancyfoot[RO]{}
\fancyfoot[CO]{\thepage}
\fancyfoot[LO]{\TheID}
\fancyfoot[LE]{}
\fancyfoot[CE]{\thepage}
\fancyfoot[RE]{\TheID}
\hypersetup{citebordercolor=0.75 0.75 0.75,linkbordercolor=0.75 0.75 0.75,urlbordercolor=0.75 0.75 0.75,bookmarksnumbered=true}
\fancypagestyle{plain}{\fancyhead{}\renewcommand{\headrulewidth}{0pt}}

\date{}
\usepackage{authblk}

\providecommand{\keywords}[1]
{
\footnotesize
  \textbf{\textit{Index terms---}} #1
}

\usepackage{graphicx,xcolor}
\definecolor{GJBlue}{HTML}{273B81}
\definecolor{GJLightBlue}{HTML}{0A9DD9}
\definecolor{GJMediumGrey}{HTML}{6D6E70}
\definecolor{GJLightGrey}{HTML}{929497} 

\renewenvironment{abstract}{%
   \setlength{\parindent}{0pt}\raggedright
   \textcolor{GJMediumGrey}{\rule{\textwidth}{2pt}}
   \vskip16pt
   \textcolor{GJBlue}{\large\bfseries\abstractname\space}
}{%   
   \vskip8pt
   \textcolor{GJMediumGrey}{\rule{\textwidth}{2pt}}
   \vskip16pt
}

\usepackage[absolute,overlay]{textpos}

\makeatother 
      \usepackage{lineno}
      \linenumbers
      
\begin{document}

             \author[1]{Katembo Kituta  Ezechiel}

             \author[2]{Shri  Kant}

             \author[3]{Ruchi  Agarwal}

             \affil[1]{  Sharda University}

\renewcommand\Authands{ and }

\date{\small \em Received: 6 December 2018 Accepted: 4 January 2019 Published: 15 January 2019}

\maketitle


\begin{abstract}
        


While replicating data over a decentralized Peer-to- Peer (P2P) network, transactions broadcasting updates arising from different peers run simultaneously so that a destination peer replica can be updated concurrently, that always causes transaction and data conflicts. Moreover, during data migration, connectivity interruption and network overload corrupt running transactions so that destination peers can experience duplicated data or improper data or missing data, hence replicas remain inconsistent. Different methodological approaches have been combined to solve these problems: the audit log technique to capture the changes made to data; the algorithmic method to design and analyse algorithms and the statistical method to analyse the performance of new algorithms and to design prediction models of the execution time based on other parameters. A Graphical User Interface software as prototype, have been designed with C #, to implement these new algorithms to obtain a database synchronizer-mediator. A stream of experiments, showed that the new algorithms were effective. So, the hypothesis according to which ?The execution time of replication and reconciliation transactions totally depends on independent factors.? has been confirmed.

\end{abstract}


\keywords{peer-to-peer (P2P), database replication, data reconciliation, transaction serialization, synchronizer-mediator.}

\begin{textblock*}{18cm}(1cm,1cm) % {block width} (coords) 
\textcolor{GJBlue}{\LARGE Global Journals \LaTeX\ JournalKaleidoscope\texttrademark}
\end{textblock*}

\begin{textblock*}{18cm}(1.4cm,1.5cm) % {block width} (coords) 
\textcolor{GJBlue}{\footnotesize \\ Artificial Intelligence formulated this projection for compatibility purposes from the original article published at Global Journals. However, this technology is currently in beta. \emph{Therefore, kindly ignore odd layouts, missed formulae, text, tables, or figures.}}
\end{textblock*}


\let\tabcellsep& 	 	 		 
\section[{Introduction}]{Introduction}\par
n computing, a Distributed Database System (DDBS) is a database whose storage devices are not necessarily all linked to a common processing unit; but rather in this approach, the database can be stored on multiple computers, located in the same physical location or can be scattered on networked computers \hyperref[b0]{[1]}, \hyperref[b7]{[8]}. The distribution transparency is the fundamental principle of the DDBS which consists of making a distributed system to appear similar to a centralized system to the users. The distribution transparency as well as the management of a DDBS are ensured by a program called Distributed Database Management System (DDBMS) \hyperref[b2]{[3]}. The design of a DDBS requires that it be entirely resident on different sites of a computer network but not necessarily all. This means that at least two sites must host the database and not necessarily each site in the network, as depicted in the Fig. \hyperref[fig_0]{1}.\par
Thus, there are two distribution strategies: data fragmentation and data allocation on the one hand and data replication on the other hand. So, to make a good design, all these strategies are compiled \hyperref[b1]{[2]}, \hyperref[b2]{[3]},  {\ref [33]}. The fragmentation consists in splitting a relation (a table of a database) into a number of sub-relations, called fragments; which can be horizontal, vertical or hybrid. Horizontal fragments are subsets of tuples (table records), vertical fragments are subsets of attributes (table columns), and hybrid fragmentation consists of mixing the two preceding ones. In turn the allocation is nothing more than the assignment of fragments to the sites in an optimal way \hyperref[b1]{[2]}. When allocated fragments have to share data among them, they need the replication procedure. However, this work focuses on the data replication strategy. The replication consists of duplication and storage of multiple copies or replicas (at least two) of the same fragment or the entire relation (in the case of a fully replicated database) of a DDBS in multiple different sites. The replication is the strategy used to ensure the data exchange between fragments or relations in a fully replicated database \hyperref[b1]{[2]}, \hyperref[b2]{[3]}, \hyperref[b3]{[4]}, as illustrate in Fig. \hyperref[fig_1]{2}. In any case, the main problem of the data replication is the synchronization of replicas. Data synchronization is nothing than keeping consistent replicas in a Replicated Database System (RDBS) \hyperref[b4]{[5]}. This means ens uring the exchange of updates between replicas. Nowadays P2P computer network is in full emergence. Comparatively to client/server model, in a P2P system, each client is itself a server. In this way replicating a Database over a P2P network require that all peers keep the same data copy. In the same way, the emergence of advanced applications of P2P systems, requiring general replication capabilities with different levels of granularity and multi-master mode \hyperref[b10]{[11]}, where each peer can transfer updates to all others and the same replica can be updated by several peers in a replicated databases environment \hyperref[b3]{[4]}, \hyperref[b9]{[10]}, the serialization of updates and the reconciliation of data turns out to be the particular P2P replication problems because those flows of updates (data) and refresh transactions conflict each other \hyperref[b7]{[8]},  {\ref [30]},  {\ref [33]}.\par
For example, the operations on an account, of a customer, opened in a bank with multiple branches can be replicated by several branches of the same bank and must be able to be updated by any branch anytime, to acquire reception of a transfer, for a deposit to the account, a withdrawal from the account, etc. Concretely, changes made by refresh transactions from different peers reach a destination site at the same time and multiple updates of the same replicas by different peers break the reliability and the consistency of replicas \hyperref[b1]{[2]}. This is why this study aims to introduce an effective approach to serialize refresh transactions and to reconcile replicas in the case of inconsistency. To overcome one of DDBS homogeneity aspects, namely the same DBMS, the result of this design needs to be implemented as a synchronizer-mediator for database replication in a Graphical User Interface (GUI) using lazy decentralized sites strategy on a P2P network. To reach this purpose, the structure of this paper is organized as follow: the first section introduced by presenting the context of this research as well as the status of the problem, the second section will review the related works, the third will present the methodology, fourth section will show the simulation environment for experimentation, the fifth section will offer the result and finally the sixth section will conclude this study. 
\section[{II.}]{II.} 
\section[{Related Works}]{Related Works}\par
This section will rapidly review certain research works already realized to attempt to solve these two aforementioned problems. 
\section[{a) Data replication}]{a) Data replication}\par
Designing a RDBS pursue four majeure objectives, namely : improving data availability, improving performance, ensuring scalability and users applications requirements. These purposes can be summarized as "improving consistency and/or reliability" \hyperref[b1]{[2]}, \hyperref[b2]{[3]}. To ensure consistency between replicas, the synchronization procedure uses the transaction running technique. A transaction is a collection of operations that transforms the database from a consistent state to another consistent state \hyperref[b5]{[6]}, as illustrated in Fig. \hyperref[fig_2]{3}. A transaction has a Begin Of Transaction (BOT) and an End Of Transaction (EOT). This End is managed by three different functions: either a "commit" to validate, a "rollback" to cancel, or an "abort" to interrupt the execution of operations inside the transaction. The consistency and/or reliability of a transaction are guaranteed by 4 properties: Atomicity, Coherence, Isolation, Durability (ACID) that make the "acidity" of a transaction \hyperref[b1]{[2]}, \hyperref[b6]{[7]}. As we are dealing with data flow, our focus remains on the Structured Query Language (SQL) operators, especially the Data Manipulation Language operators in most of DDBMSs, which contains \hyperref[b8]{[9]}: The write operators (Insert, Update and Delete SQL commands) and the read operator (Select SQL command). Typically, like the structuring of instructions of a procedural language, a transaction "T" can have the following structure:\par
Begin\textunderscore Of\textunderscore Transaction T Insert operator Update operator Delete operator Select operator End\textunderscore Of\textunderscore Transaction T However, to solve the aforementioned main problem of data replication, i.e. the synchronization of replicas, there already exits four replication strategies, resulting from the combination of two factors: "when" and "where". The "when" factor specifies when updates are broadcasted (synchronously/eagerly or asynchronously/lazily), while the "where" factor indicate where updates occur on a centralized site (primary copy/mono-master) or on decentralized sites (everywhere/multi-master) before being propagated. So when we take the factor "where" in "when", it emerges \hyperref[b0]{[1]}, \hyperref[b1]{[2]}, \hyperref[b2]{[3]}, \hyperref[b3]{[4]},  {\ref [30]},  {\ref [33]}, \hyperref[b26]{[34]}:\par
A. Synchronous or Eager Replication: All replicas must be updated before the transaction commit i.e. in real-time. Here, the most up to date value of an item is guaranteed to the end user. There are two different strategies in synchronous replication:\par
1) Eager centralized site: This method is beneficial in case where reads are much more frequent than writes. It works under the principle "Read-One, Write-All (ROWA)". After transaction commitment, any one of replicas can be read; so the write process must update all replicas. 2) Eager decentralized sites: The principle is "update everywhere"; in this logic every site is allowed to propagate updates to all sites in the same transaction, at the same time so that on the end of the transaction updates become available on all sites.\par
B. Asynchronous or Lazy Replication: Allows different replicas of the same object to have different values for a short periods of time i.e. in near realtime. They are updated after a predefined interval of time. There are two different strategies in asynchronous replication:\par
1) Lazy centralized site: It works with the principle such that one copy of replicas is assigned as the "primary copy or mono-master" so that changes of data or writes are possible only on it. These changes are periodically propagated to the secondary copies. The secondary copies of data can only be read. 2) Lazy decentralized sites: Here the principle is so that changes can be performed "everywhere or multi -master", on each site. So these changes are propagated independently to other sites sporadically.\par
These replication strategies, have already been implemented in most of modern DDBMSs \hyperref[b8]{[9]}. It is largely the centralized strategy that is much more wrapped in the replication models offered by almost all DBMSs. But, although these modelling are done, there remains a problem to emphasize in eager centralized site approach such that if there is a site unavailable during updates propagation by the master site, the transaction cannot commit. So, some researches are already attempting to design an optimal algorithm that can allow the update transaction commitment on the available sites and to update unavailable sites as soon as they become available again; hence the approach "Read-One, Write-All Available (ROWA-A)" \hyperref[b1]{[2]}, [30],  {\ref [33]}. In addition, one could expect the problem related to the momentary interpolation of the line of communication between the master site and the slave sites, because it is enough for example that the master site overlord or be inaccessible so that the slaves no more access to updates \hyperref[b7]{[8]}. Well, there is only the decentralized strategy that can clear this concern.\par
Nevertheless, eager decentralized sites experience the same problem as eager centralized site, whereby update transactions that arise from all sites, if they find at least one site unavailable they abort. But to overcome this problem, such kind of systems should be able first of all to commit transactions on only available sites and so update unavailable sites as soon as they become available again; hence the approach "Update Everywhere Available" \hyperref[b16]{[17]}. So nowadays, some researches attempt to improve these algorithms by distributed voting algorithm \hyperref[b3]{[4]}. Thus, if the sites number quorum is reached the transaction commit on them; so afterwards, when writing, update all fraction of the replicas and when reading, read enough replicas to ensure you get at least one copy of the most recent value.\par
In view of the above, it seems that the lazy strategy is appropriate for P2P topology, especially since it allows replicas of various sites to diverge for a given moment. So as in a P2P network, the participants (Peers) are present or absent momentarily, updates propagation can be applicable on the present Peers while the absent Peers will remain with non -updated replicas in order to receive their updates when they become available again \hyperref[b9]{[10]},  {\ref [33]}. Thus, lazy centralized sites approach is appropriate for the centralized P2P topology because updates are performed only on the central site and then forwarded to slave sites in near real-time while lazy decentralized sites approach is the most appropriate for the materialization of replication on a decentralized P2P topology because in near real-time, like centralized approach, updates can be performed everywhere, i.e. on each peer and then be broadcasted to all others.\par
Referring on our problem concerning replication over a decentralized P2P architecture, the observation has been that only a few of DDBMSs have already tried to implement the lazy decentralized strategy in order to formalize the P2P replication; let us quote for instance SQL Server \hyperref[b12]{[13]} and Oracle \hyperref[b13]{[14]}. Unfortunately, the particular problems of P2P replication still exist and will be developed in following lines:\par
? Transaction conflicts: Several updates carried by refreshing transactions, from different sites reach a destination site at the same time but they cannot be performed on the same time, then reliability and consistency will be lost and there will be the risk of transaction conflicts \hyperref[b1]{[2]}, [30],\par
[33], \hyperref[b27]{[35]}. DDBMSs must ensure that transaction execution meets a set of properties that lead to the consistency of distributed databases and conveniently summarized by the ACID, since when the execution is always concurrent \hyperref[b5]{[6]}, \hyperref[b6]{[7]}. Thus, several researches have already been undertaken to solv e the transaction concurrency control problem. Concurrent execution without harmonization constraints poses a number of problems, the most important of which is the loss of operations and incorrect readings. Therefore, it is necessary to set the serializability, a property determining a correct execution of the completion of transactions \hyperref[b2]{[3]}. ? Data conflicts: P2P replication allows to perform changes on each peer in the topology and then forward them to other peers. However, as changes are performed at different peers, probable data conflicts are to be pointing out when modifications are being broadcasted \hyperref[b1]{[2]},\par
[30],  {\ref [33]}. Thus, in all DDBMSs which have already succeed to implement the lazy decentralized sites approach to make it P2P replication, one can distinguish three types of data conflicts \hyperref[b12]{[13]}, \hyperref[b13]{[14]},\par
[20], \hyperref[b19]{[21]}: a) Primary key or uniqueness conflict: Occurs when a record with the same primary key has been created and inserted at more than one peer in the topology. So when those peers need to exchange updates, it is then impossible to violate the criterion of entity integrity; b) Foreign key conflict: Can occurs if in any case the refresh transaction forward updates which contains a record with a foreign key column but whose primary key is not yet forwarded to the destination peer. So it is then impossible to violate the criterion of referential integrity; 
\section[{Data modifications conflicts:}]{Data modifications conflicts:}\par
? Update conflict: occurs when the same record has been updated on more than one peer; ? Insertion/Update conflict: occurs when a record has been updated on a peer and the same record has been deleted and re-inserted on another peer; ? Insert/Delete conflict: occurs when a record has been deleted on a peer and the same record has been deleted and re-inserted on another peer; ? Update/Delete conflict occurs when a record has been updated on one peer and the same record has been deleted on another peer;\par
? Deletion conflict: occurs when a record has been deleted on more than one peer. Thus it is necessary to think about a certain number of rules to warranty the conflict policy avoidance in the decentralized P2P replicated environment. Apart from the inconsistency of data caused by transaction conflicts and data conflicts, there are other phenomena which make the replicated data inconsistent. Thus, although the transaction that propagates the updates is successfully committed, the data remains inconsistent. Hence, there is the need of an automatic data reconciler. 
\section[{b) Data reconciliation}]{b) Data reconciliation}\par
Database reconciliation is a process of verifying data when there has been a migration or transfer of data from a source database to a destination. The purpose of this process is to ensure that the migration has been done accurately  {\ref [22]}. In this logic, in a global manner, the data is the set of tables of a given database and in a basic way, the set of records of definite tables which can be accessed by a certain selection criterion. In a replicated Databases environment, updates broadcasting as well consists to migrate or to transfer data changes from a Prima ry site toward Secondary sites \hyperref[b20]{[23]}.\par
However, during data migration, errors may have occurred \hyperref[b11]{[12]}. Most are like execution failures due to network interruptions as well as network overload those end up corrupting transactions and causing data to be lost or remain in an invalid state at the destination \hyperref[b7]{[8]}, \hyperref[b26]{[34]}. These phenomena lead to a series of problems such as: missing records, duplicate records, incorrect values, missing values, incorrectly formatted values, broken relationships between tables in case of forced redundancy, etc.\par
[22]. But, some researches have already been undertaken to find solutions in several ways and some algorithms are already implemented in DDBMs and particular software to reconcile data after migration process.\par
Oracle Corporation \hyperref[b21]{[24]}, possesses some databases reconciliation tools for their DDBMSs: Upgrade Reconciliation Toolkit is used to compare the data on the Oracle DB source and Oracle DB destinations after data migration and after running the parallel End Of Day (EOD) activities mostly for different branches of a bank. This tool generates also the reconciliation report at the end of the process. Another tool is mysqldbcompare especially for MySQL, this tool compares two databases by identifying differences between databases objects; changed or missing rows of tables are shown in standard formats like grid, table, etc. It is going beyond the data comparison; this utility compare also objects data definition of two databases \hyperref[b22]{[25]}. Nevertheless, all these tools run reconciliation between one source and one destination. The only one which can reconcile one source and multiple destinations is Upgrade Reconciliation Toolkit for Oracle. Unfortunately, it is only limitated to Oracle DB. The tools mysqldbcompare and MySQL\textunderscore Diff are also limitated to MySQL and they are not taking in to account multiple destinations. The Tool LegiTest's should be more interesting because it is able to reconcile multi-DBM S databases, but it is also one source, one destination; and all others which have been listed in this review present such kind of limitation.\par
Moreover, these data reconciliation tools rely on simple counting of records to keep track if the expected number of records has been migrated. It can be esteemed that this was mainly due to the importance of the processing of essential data to carry out field validation of a given data. Nowadays, for more accuracy, the data migration algorithm should provide data reconciliation capabilities that allow the reconciliation of each data or each field, i.e. at the intersection of each row an d each column (attributes by record) of each database table \hyperref[b11]{[12]}.\par
To preserve data inconsistency and to maintain acidity, all instructions of the replication procedure must be wrapped in transactions \hyperref[b1]{[2]}, \hyperref[b6]{[7]}. The instructions of a transaction are the commands or operators of the data manipulation language. But, when an operator of the data modification language is executed on a site, some time passes while waiting for the response. While a transaction may have more than one operator and the factors are likely to be varied in a P2P environment, this phenomenon should greatly influence the temporal complexity in the event of variation of different factors. So it is necessary to design a prediction model of replication and reconciliation execution time.\par
The assumption of this study is formulated as follows: "it seems that P2P replication systems experience the weak performance, especially since the time to replicate and to reconcile data from a Master Peer to Slave Peers dependent, if not totally, partially of certain factors, such as: the number of records in each table, the number of tables whose data has changed, the number of peers connected during the propagation of updates and other factors (number of columns per table, data types columns, etc.)".\par
However, these problems deserve a special attention; that is why there is a reason to wonder about setting up "a synchronizer-mediator for lazy replicated databases over a decentralized P2P architecture". This system should be able to serialize updates performed simultaneously on different replicas of the same database and to reconcile this replicas, effectively, over a decentralized P2P network. 
\section[{III.}]{III.} 
\section[{Methodology}]{Methodology}\par
To ensure strong replica consistency in a distributed database, traditionally the implementation of a syn chronous or eager refresh algorithm which is specially Two -Phase-Commit (2PC) based technique is the unique gateway to avoid discrepancies between replicas \hyperref[b1]{[2]}. However, this solution is inapplicable in a P2P architecture because does not guarantee the updates delivery to all peers as they are not all always available at the same time \hyperref[b14]{[15]}. Thus, asynchronous or lazy replication is more appropriate for P2P systems because it allows replicas to be updated independently and to remain divergent until a refresh transaction takes place \hyperref[b15]{[16]}. Modifications which have been done to the local replica, by local transactions are captured and the refresh transaction propagates them to remote replicas asynchronously i.e. in near real-time. The technique used in this work to capture modifications is audit-log. 
\section[{a) Audit-log technique}]{a) Audit-log technique}\par
Almost all DDBMSs support this technique by running triggers belonging to a specific table in order to capture data modifications. A trigger is attached to an event produced by an Insert or Update or Delete operator so that it captures changes before or after the event has taken place in the database \hyperref[b4]{[5]},  {\ref [33]}. So, in this work the interest is carried on after trigger. To achieve this, for each data-table the creation of one ( ) C audit-table is necessary. The audit-table is composed by the data-table primary key column, other data-table columns (apart from the primary key), the updated column name, the audit action, the timestamp and the synchronization ID. These elements are required for a record to do the comparison between data. Each table in the database would need three triggers to run after Insert, after Update and after Delete. The flow chart, Fig. \hyperref[fig_3]{4} here below illustrates the audit-log creation. Suppose that the database is homogenous and full replicated, as soon as the audit log creation of each data table completed, on each peer, for each SQL data modification operation, the DDBMS performs following action accordingly:\par
? After each Insert operation in the data table, the "insert trigger" captures the newly added record and inserts it in the audit table, as shown in Fig.  The column synchronisation ID (Sync\textunderscore ID) in Audit -tables don't have same value; for a Master Peer Audit-table its content is "Local-Transaction", value automatically provided by the trigger procedure when the transaction is initiated locally by the user application whereas for a remote transaction the synchronization procedure update automatically this column by the sync. ID provided by the Sync. Mediator-System. So, the synchronization procedure select only data whose Sync\textunderscore ID is equal to "Local-Transaction" and whose Audit\textunderscore Timestamp is in the interval of begging date and time to ending date and time and apply them to Slave Peers according to the Audit\textunderscore Action value. This technique permits us to resolve the problem of the endless loop in the sync. procedure used two -ways or symmetrical replication which was knowing old synchronizers \hyperref[b4]{[5]}. 
\section[{b) Algorithmic method}]{b) Algorithmic method}\par
The Algorithmic method will be used to design and to analyse instructions of algorithms and steps of a Peer-to-Peer Synchronizer. This method will take in account the Circulatin g Token Ring Algorithm, the Decentralized Peer-to-Peer Replication Algorithm and the Decentralized Peer-to-Peer Data Reconciliation Algorithm. 
\section[{i. Network Topology and Algorithm}]{i. Network Topology and Algorithm}\par
When a peer needs to broadcast its captured updates toward other peers, it needs a token which gives it the state of a Master i.e. the permission to forward its updates and other peers become automatically Slaves. A fully replicated P2P database system includes p peers and each peer has a complete copy of the database. Peers communicate with each other by exchanging messages and forwarding updates or accessing peer data by performing transactions \hyperref[b16]{[17]}. In this way, updates will be applied according to a circulating token, as depicted in Fig. \hyperref[fig_6]{6}, which determine transactions serialization order or one can give the privilege to updates from certain sites considered to be mo re important or privileged.\par
Suppose a network consisting of four peers A, B, C and D all networked. The Fig. \hyperref[fig_6]{6} below presents the decentralized topology of peer-to-peer token ring network.  A predefined order of releasing or getting the token, since we are in a P2P network where a peer p may or may not be available, is not needed. The optimization policy here is to give the token directly to a peer which needs it instead of going through a list of peers that we are not sure of their availability at the time of the token release. So, transaction serialization is managed by the new circulating token algorithms 1 and 2, successively for getting the token and releasing the token.  Since when a peer (p), which can be "A" or "B" or "C" or "D" gets the token, it executes the transactions according to the algorithm 3, 4 and 5 for data replication and 6 for data reconciliation. Consequently, all transactions performed are accepted and none rejection because only a peer which possess the token can perform a transaction of its updates broadcasting and reconcile other peers' data with its updates. As soon as peer "A" finishes to perform updates and reconciliations with peers "B, C and D", it releases the token and other peers like "B" or "C" or "D" can randomly take it, but according to the token request minimum date and time, and do the same, unless a privileged peer requests it.  
\section[{ii. Replication Protocol and Algorithm}]{ii. Replication Protocol and Algorithm}\par
Assuming that the database is homogenous, full replicated and each Peer work under a Two-Phase-Locking (2PL) concurrency control technique. The model of the lazy replication over a decentralized Peer-to-Peer Architecture is presented as follows: let W(x) be a write transaction where x is a replicated data item at Peers A, B, C and D. The Fig. \hyperref[fig_8]{7}, here below depicts how transactions update different copies at all Peers and after commit the refresh transaction, wrapped in the Sync. Mediator-System, forward updates to all peers.     
\section[{iii. Reconciliation Protocol and Algorithm}]{iii. Reconciliation Protocol and Algorithm}\par
After a large data transmission, to overcome the problem of data inconsistency due to untimely interruptions of connectivity, network overload and other technical hazards, updates forwarded to each peer in the replication procedure must be reconciled.\par
The model of the Decentralized Peer-to-Peer Data Reconciliation is presented as follows: let R(x) be a read transaction where x is a replicated data item at Peers A, B, C and D. The Fig. \hyperref[fig_11]{8}, here below depicts how reconciliation is performed on different copies of all peers.   After the implementation of these algorithms presented above, the main goal, according to which setting up a synchronizer-mediator for database replication being able to serialize the propagation of updates and their reconciliation in a replicated databases system over a decentralized P2P network is achieved. Although this goal be achieved, it is appropriate to know here that in computing the performance of an algorithm is assessed on the basis of its complexity \hyperref[b17]{[18]}. The analysis of the theoretical complexity of this algorithm will be more concerned the time complexity than the space complexity especially as the data will be momentarily transit through the buffer to the destination. Nevertheless, the practical time that the execution of this algorithm takes will result from the simulation and will be calculated by the statistical method. 
\section[{c) Statistical method}]{c) Statistical method}\par
The performance of a system depends on a certain number of factors. We have to determine the practical time, that makes our system to execute successively transactions of updates propagation or replication (insert, update and delete) and transactions of data reconciliation. To analyse this performance, we will use the linear regression test with the random sampling technique. The linear regression test is a statistical analysis method that describes the variations of an endogenous variable associated with the variations of one or more exogenous variables i.e. the relation between an endogenous variable and one or more exogenous variables. In the case where the study concerns an endogenous variable with one exogenous variable, it's a simple regress ion and when it's an endogenous variable with more than one exogenous variable, it is a multiple regression \hyperref[b18]{[19]}. This test will be used not only to determine the execution time based on a certain sample, but also to make a linear regression model that will be used to predict the execution time , which is the dependant factor or endogenous variable, based on other independent factors or exogenous variables, namely the number of records, the number of tables in the database and the number of Slave Peers. The following variables are selected:\par
? Y i : is a random variable to explain "the time the synchronization algorithm takes to broadcast updates and to reconcile replicas for an execution i"; ? X i1 : is an explanatory variable "the number of records the synchronization algorithm broadcast from a Master Peer to Slaves and reconcile between the Master and Slaves for an execution i"; ? X i2 : is an explanatory variable "the number of tables in the database whose records knew updates which need to be broadcasted and reconciled with Slaves for an execution i" ? X i3 : is an explanatory variable "the number of Slave Peers available to receive updates and to be reconciled for an execution i". Given a sample (Y i , X i1 , X i2 , X i3 ) whose i ? [1, n], we will try to explain, as precisely as possible, the values taken by Y i , the so-called endogenous variable from a series of explanatory variables X i1 , X i2 , X i3 . The model formulated in terms of random variables, takes the form: ?? ?? = ?? 0 + ?? 1 ?? ??1 + ?? 2 ?? ??2 + ?? 3 ?? ??3 + ?? ?? Where:\par
? i = 1, 2, . . . , n ? b 0 is the constant term;\par
? b 1 , b 2 and b 3 are coefficients of the regression to be estimated; ? ? i : is the model error that expresses or summarizes the missing information in the linear explanation of the values of Y i from X i1 , X i2 , X i3 (a random variable of zero mathematical expectation in this model i.e. problem of specifications, variables not taken into account, etc.). The intensity of the relation between the independent variables and the dependent variable will be expressed by the correlation coefficient "R", which is the square root of the "R²", the determination coefficient of a linear regression model. The coefficient of correlation, will be used to determine the degree of linkage between the independent variables and the dependent variable while the coefficient of determination will help to measure the proportion of dependence of the dependent variable explained by independent variables. Thus, two sets of hypothesises are evoked as follow: These hypotheses will be verified at the end of the results which will be produced by a series of experiments perpetrated on a simulation environment which will be described in the following section.\par
IV. 
\section[{Simulation Environment}]{Simulation Environment}\par
The implementation and experimentations will be run on a P2P network consisting of 4 traditional computers depicted in the Fig. \hyperref[fig_13]{9}, with the following properties: Processor: Intel Core i5, CPU 2.40GHz, Memory (RAM): 8.00GB and Storage: 1TB. The network will be based on a desktop switch of 100 Mbps of transmission speed, to establish a simple LAN using twisted -pair cables connection and RJ45 connectors. These computers will run under Windows 10 Professional 64 bits and SQL Server Management Studio 2012 Express as DDBMS, to manage databases and establish the connectivity between them. According to this Fig. \hyperref[fig_13]{9} above, a node is composed by hardware and software as required previously. But in this same figure one can point out the presence of a "Mediator" for each peer. The mediator is nothing else than the synchronization system, "Sync. Mediator-System", a C\# software which has been designed and in which it has been implemente d algorithms, already described in the methodology, to lead to a windows application running under a graphical user interface, as presented in the Multiple-Document Interface (MDI) window here below in the Fig. \hyperref[fig_14]{10}. Thus this mediator must be installed on each node to manage the replication transactions and the reconciliation of replicas. For the execution to be effective, there are prerequisites to fulfil. 
\section[{a) Prerequisites}]{a) Prerequisites}\par
When designing the global schema of the database, each table must have:\par
? The name such as "Data\textunderscore tbTableName" and the first column as its primary-key to identify data and to make the difference between records. The creation of primary keys by automatic incremental systemprovided by the DBMSs is disadvised, it is preferable to program an automatic primary key combined with the site number to avoid redundancy;\par
? Bear in mind that the database is homogeneous i.e. the data structure of the replicated database must be uniform on all peers. Before the actual processing phase begins, under expected replication, "Sync. Mediator-System" provides two procedures that must be performed automatically in advance for each table, as showed in the window, Fig. \hyperref[fig_16]{11}: ? To create one audit table named "Audit\textunderscore tbTableName", to store changes captured by 3 triggers belonging to each table. Each audit table must have its next four last columns to store respectively the updated column name, the audit action, the audit timestamp and the last column to store the synchronization ID;\par
? To create three triggers to run after Insert, after Update and after Delete, to capture data changes and store them in the specific audit table. 
\section[{The new circulating token algorithm has two phases: i. Data replication}]{The new circulating token algorithm has two phases: i. Data replication}\par
Update transaction serialization: All update transactions must be executed in serial order. Before initiating a refresh transaction, each peer must first receive a single token of a sequential series, to get the order in which the transaction will be executed. Once a token has been assigned to a peer p, this last becomes directly a Master so it performs update transactions to all connected Slave peers, as showed in the window, Fig. \hyperref[fig_17]{12}. Update transaction performing: When a Slave peer receives an executing transaction, it places it according to its Master peer's token as well as its number (Sync\textunderscore ID, in Fig. \hyperref[fig_4]{5}) and updates are performed to the Slave peer database. As soon asthe transaction ends on each Slave peer, it sends an appropriate message to the Master peer to certify the transaction commitment. The peers connected during the initiation of the transaction and whose transaction has been aborting during transaction performing, due to any kind of issue to the site which host the peer, must be mentioned in the pending list in order to be updated later in a new procedure reusing the same Sync\textunderscore ID. Then the main transaction, initiated on the Master peer, ends when it has been executed on all peers and give immediately the relay to the reconciliation procedure.\par
ii. Data reconciliation Reconciliation transaction serialization: Reconciliation in turn will benefit from the serial order of their "Mather" update transactions. This phase must begin on the Master peer once the replication is complete. The reconciliation procedure must also initiate transactions to read updates received by Slave peers. These readings consist of a comparison between the data s ent by the Master peer and the data received by the Slave peers. The comparison operation is performed according to data carrying the token of the same Master initiator of the replication transactions, as revealed in the window, Fig. \hyperref[fig_17]{12}. All errors like missing records, duplicate records, incorrect values, missing values, incorrectly formatted values are retained in order to be fixed.\par
Reconciliation transaction execution: This phase consists of fixing all retained errors so that missing records are inserted, duplicate records are deleted, missing values are added to their respective fields, incorrectly formatted values are replaced by correct values. Data reconciliation process can be however restarted if the first one done didn't put replicas in consistent state. So procedure can be repeated until all replicas become consistent, then the Master peer can release the token. In the case where the inconsistency persists among data, probably it can be caused by conflicts. 
\section[{c) Conflicts avoidance rules}]{c) Conflicts avoidance rules}\par
To avoid potential conflicts among data in the P2P replicated database environment, some rules must be respected:\par
? When using the database, it is inadvisable not to update the value of the primary key; instead, it is better to delete the entire record and re-insert it; ? When designing an application which communicate with the database, create procedures which cannot allow from a peer to update or to delete a record whose insertion was not performed on that same peer i.e. the modification of a data must be done only and After the configuration be performed as indicated in this section to simulate the replication process on a P2P network, the test and/or experiment sets yielded the results which are presented in the next section.\par
V. 
\section[{Result}]{Result}\par
This section is dedicated to testing this new synchronizer of databases, results and evaluating the performance of the newly proposed algorithm. To achieve this, it is necessary to analyse the performance in order to jus tify the effectiveness of the algorithm. 
\section[{a) Performance analysis}]{a) Performance analysis}\par
Suppose that this algorithm has to broadcast updates emerging from the replicated database over 4 peers A, B, C, and D, local servers of a bank branches. Being fully replicated and homogeneous, the physical schema of this database consists of 3 tables, as presented in Fig. \hyperref[fig_19]{13}. So, for all cases, consider the sample of 12 executions, to operate randomly and based on the reality of the replicated data manipulation in the distributed environment of banking database. However, in all cases, insertions are greater than or equal to updates and deletes. But updates can be more or less than deletions.\par
After the replication transaction has completed, if there has been an overload or interruption of the network corrupting the replication transaction, then assume that the data that the destination peers have received has experienced some inconsistencies with respect to those of the master peer. Fro m the total replicated data (inserts, updates, and deletes), consider that 25\% are missing records that require re-insertion, incorrect values, missing values, and incorrectly formatted values which need to be updated and duplicate records that require deletion, as typically data to be reconciled does not exceed ¼ of that of replication \hyperref[b1]{[2]},  {\ref [22]}. Thus, it resorts the data presented in the table 1 hereafter: For analysing the effectiveness of our algorithm, the experimentation will be realized in four scenarios, namely:\par
1. Experimentation based one table stored on a master peer with two slave peers ; 2. Experimentation based two tables stored on a master peer with two slave peers ; 3. Experimentation based one table stored on a master peer with three slave peers; 4. Experimentation based two tables stored on a master peer with three slave peers.\par
To carry out the analysis of the performance, based on the prediction of the execution time according to the data of the sample presented in the Table \hyperref[tab_7]{1} above, it results the execution times obtained after experimentation and presented successively in the tables and charts below: All basic factors remaining unchanged i.e. one table stored on a master peer with two slave peers, replication and reconciliation models are successively presented as follow : insert operator, Fig. \hyperref[fig_21]{14(a}     By varying the factor number of tables, from one to two tables stored on a master peer, dividing the number of records equitably between two tables and maintaining unchanged the factor number of slave peers in "two (2) peers", the replication and the reconciliation models are successively given as follow: Year     When we increase the number of tables from one to two, in 1 second, the prediction of the execution time (y), during which this algorithm can successively replicate and reconcile the number of records (x), is calculated from the following way:\par
? For insert operator ? In replication procedure (Fig. \hyperref[fig_23]{16(a)}) : 1 = 0.021 ?? ? 1.3366 ??0.021 ?? =?1.3366 ? ?? =111.26 ? ?? ? 111 inserted records to be replicate in 1 second. So, as the coefficient of determination R² = 0.9846 then the dependence degree of insertion execution time compared to the number of records is 98.46\% and as the coefficient of correlation R= ??? 2 ? R = ?0.9846 ? R = 0.9923 then the degree of linking between the insertion execution time and the number of records is 99.23\%.\par
? In reconciliation procedure (Fig. \hyperref[fig_24]{17}    The experimentation of this algorithm on a topology consisting of two (2) slave peers proves that the variation of the number of tables containing data to replicate and reconcile in a P2P replication system has a significant impact o nly for the replication transaction as illustrated in Fig. 18. For all data modification operators , illustrated by graphs of Fig. 18(a), Fig. 18(b) and Fig. 18(c), successively, taken into account in the replication process, the execution time, when record s originate from one (1) table, is greater than the execution time when the same number of records emerge from two (2) different tables while for reconciliation the impact is not too great.\par
Hence this variation has no significant effect on the execution time of data reconciliation because the number of records to reconcile from one (1) table and average of execution time, calculated in Table \hyperref[tab_8]{2}, are not far different from those to reconcile from two (2) tables and whose average of execution time is calculated in Table \hyperref[tab_10]{3}. This is why the curves of the graphs depicted in Fig. 18(d  So, partially we can conclude that this algorithm is efficient for the replication of databases because generally a database does not have one table i.e. data to replicate are scattered in several tables. As for reconciliation, since it takes place only when it is necessary and mostly data to be reconciled do not exceed one quarter of that of replication, little importance should be attached to the computational time of this phenomenon. Year This conclusion was obtained after varying the factor number of tables. However, by keeping unchanged all other factors, except the number of slave peers that vary from two (2) to three (3) peers, using the same sample in Keeping the factor number of table unchanged, one table stored on a master peer with three slave peers, the replication and reconciliation models are successively presented as follow: insert operator, Fig. 19    In 1 second (y) we predict that this algorithm can successively replicate and reconcile following number of records (x):\par
? For insert operator ? In replication procedure (Fig. 19   Varying the factor number of table stored on a master peer with three slave peers, the replication and reconciliation models are successively presented as follow: insert operator, Fig. 21   After increasing the number of tables from one to two, in 1 second, the prediction of the execution time (y), during which this algorithm can successively replicate and reconcile the number of records (x), is established as follows:\par
? For insert operator ? In replication procedure (Fig. 21 When running this algorithm on a topology consisting of three (3) slave peers, the experimentation result proves that the variation in the number of tables containing data to replicate and to reconcile in a P2P replication systemhas a significant impact on the execution time of replication and reconciliation transactions, as shown in Fig. \hyperref[fig_2]{23}. Fig. \hyperref[fig_2]{23}: Effectiveness of replication and reconciliation based one table stored on a master peer with three slave peers vs two tables stored on a master peer with three slavepeers.\par
However, this impact is explained only by the comparison of averages, in Table \hyperref[tab_14]{4 and 5} Mediation of Lazy Update Propagation in a Replicated Database over a Decentralized P2P Architecture execution time with one table. But, in terms of predictive models, we found that, when the records come from one table, the execution time is greater than the execution time when the same number of records is split and comes from two different tables. This phenomenon is clarified by the successive resolution of the prediction equations of the replication and reconciliation models which proved that the number of records to replicate and reconcile to 1 second, with two tables of origin is greater than those when there is only one table.\par
Thus, partially we can conclude that this algorithm is effective for the replication of databases, its performance increases with the increase of the tables for a certain number of records. So, since the data to replicate is usually scattered across multiple tables, we can count on its effectiveness. Fig. \hyperref[fig_3]{24}: Effectiveness of replication and reconciliation based one table stored on a master peer with two slave peers vs one table sto red on a master peer with three slave peers.\par
The result we have achieved so far comes from the analysis of performance by varying the numbers of tables in which the data to be replicated and reconciled originate. Nevertheless, later on, we have to analyse the performance of this algorith m starting from the variation of the slave peers. Thus, Fig. \hyperref[fig_3]{24} and Fig. 25, show the effectiveness result when increasing the number of slave peers but the data to replicate and reconcile successively from a single table and two table. After increasing the number of slave peers, the execution time of the replication transaction as well as the reconciliation of the data, successively from a table, as illustrated in Fig. \hyperref[fig_3]{24} and two tables, as shown in Fig. 25, knows a significant increase. This increase in execution time affects negatively the ? Secondly by comparing the predicted values, in this case the prediction of the number of records to replicate and reconcile to 1 second. After the successive resolution of the prediction models equations for replication and data reconciliation, we found that the number of records to replicate and reconcile are declining after increasing a slave peer. However, based on these observations from all the cases i.e. with the data to be replicated and reconciled from one or two tables, we can partially conclude that the increase of the number of slave peers on a Replicated Databases over a Decentralize d P2P topology is causing the loss of performance of the synchronization algorithm. 
\section[{b) Result summary}]{b) Result summary}\par
In view of what we have just achieved as a result, it is necessary to summarize and give a general conclusion. Thus, the Table \hyperref[tab_15]{6} here below will first give a summary of the results. Starting from the results presented above and summarizin g in Table \hyperref[tab_15]{6}, our first group of hypotheses of the significance test of each independent variable gives the conclusion that each independent variable is a significant predictor of the dependent variable. In other words, the number of records in each table (xi1), the number of tables whose data has chan ged (xi2), the number of peers connected during the propagation of updates (xi3) and other factors (?) like number of columns per table, data types columns, etc., each taken separately predict significantly the execution time (y) of the replication transaction as well as that of reconciliation because almost all coefficient of determination (R²) are greater than or equal to the confidence level of 95\%. In all the cases the execution time depend on other factors beyond 95\% and these factors correlate positiv ely and tightly of the totality. This means that the changes made to one of these independent variables affect in 95\% or more of the dependant variable and vice versa. Hence, we accept the alternative hypothesis (H1) and thus reject the null hypothesis (H0). As for the second group of hypotheses, since for all experimental scenarios all independent variables (the number of records in each table (xi1), the number of tables whose data has changed (xi2), the number of peers connected during the propagation of updates (xi3) and other factors (?) like number of columns per table, data types columns, etc.,) are significant predictors of the dependent variable which is the replication and reconciliation transaction execution time (y), the overall model of the regression is significant, at the same thresholds significance derived from the combination of factors by the experimental scenarios summarized in the Table \hyperref[tab_15]{6} above.\par
The experimental results show that our algorithms are performant since when to 1 second, a time elementary unity, it can replicate and reconcile a considerable number of records, like present the last column in the Table \hyperref[tab_15]{6}, for the present experimental environment. However, since the performance of a computer algorithm is due to its execution time, this is how we assert our main hypothesis that P2P replicated databases systems experience the weak performance, especially since the time of transmission of updates from a Master Peer toward Slave Peers dependent in more than 95\% of the number of records, the number of tables whose data know changes, the number of peers connected during the propagation of updates and other factors.\par
Nevertheless, as we have just seen, when we take two by two experimental scenarios those can be noted successively I: 1 and 2, II: 3 and 4, III: 1 and 3 and finally IV: 2 and 4 of Table \hyperref[tab_15]{6} above, I made a good performance, II also made a performance gain but not far from the average, III made a loss of performance and IV made a loss as well. Taking III and IV it emerges the variation of number of peers connected whereas from I and II emerge the variation of the tables. During the experiment, it was found that the variation of number of the tables did not lose the performance, contrariwise it improved it. Moreover, among the independent variables, the number of records and the number of tables being factors directly related to the database before even hinting at the data replication, it is clear that it is the growth of number of connected peers which is at the base of the considerable loss of the performance i.e. the increase of the execution time of a synchronization algorithm of distributed databases.\par
Thus, as a future work to be carried out, as part of improving the performance of this proposed algorithm, the thought will revolve around synchronization algorithm for replicated databases over a decentralized P2P architecture with supernodes or super-peers [31], \hyperref[b25]{[32]} belonging to peers clusters in order to reduce execution time of transactions and to reach load balancing during data transmission \hyperref[b27]{[35]}. 
\section[{VI.}]{VI.} 
\section[{Conclusion}]{Conclusion}\par
This article proposes a prototype of a synchronizer-mediator for lazy replicated databases over a decentralized P2P architecture in a Graphical User Interface. The motivation arises from the common problem of databases replication consisting to maintain consistent replicated databases over a decentralized P2P network.\par
However, two specific problems caught our attention: transactions broadcasting updates from different peers are performed concurrently on a destination peer replica, which always causes transactions conflicts and data conflicts. Moreover, during data migration, connectivity interruptions and network overload corrupt transactions so that destination peer databases can contract duplicated records, unsuitable data o r missing records which make replicas inconsistent. Differen t methodologies have been used to solve these problems : the audit log technique to capture and store data changes in audit tables; the algorithmic method to design and analyse algorithms for transactions serialization, for data replication transactions and the replicas reconciliation transactions end finally the statistical method to analyse the performance of algorithms and to produce prediction models of the execution time.\par
The C \# prototype software has been designed to implement algorithms and permit to execute the test in order to make out the effectiveness of each experimental scenarios. Afterwards it has been shown that the algorithm has a good performance because it can replicate and reconcile a considerable number of records to 1 second. Finally, the assumption according to which "The execution time of replication and reconciliation transactions totally depends on independent factors" has been affirmed.\begin{figure}[htbp]
\noindent\textbf{1}\includegraphics[]{image-2.png}
\caption{\label{fig_0}Fig. 1 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{2}\includegraphics[]{image-3.png}
\caption{\label{fig_1}Fig. 2 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{3}\includegraphics[]{image-4.png}
\caption{\label{fig_2}Fig. 3 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{4}\includegraphics[]{image-5.png}
\caption{\label{fig_3}Fig. 4 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{5}\includegraphics[]{image-6.png}
\caption{\label{fig_4}Fig. 5 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{6}\includegraphics[]{image-7.png}
\caption{\label{fig_6}Fig. 6 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{1}\includegraphics[]{image-8.png}
\caption{\label{fig_7}Algorithm 1 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{7}\includegraphics[]{image-9.png}
\caption{\label{fig_8}Fig. 7 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{}\includegraphics[]{image-10.png}
\caption{\label{fig_9}Figure legend}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{1}\includegraphics[]{image-11.png}
\caption{\label{fig_10}1 .}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{8}\includegraphics[]{image-12.png}
\caption{\label{fig_11}Fig. 8 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{1}\includegraphics[]{image-13.png}
\caption{\label{fig_12}Figure legend 1 .}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{9}\includegraphics[]{image-14.png}
\caption{\label{fig_13}Fig. 9 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{10}\includegraphics[]{image-15.png}
\caption{\label{fig_14}Fig. 10 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{}\includegraphics[]{image-16.png}
\caption{\label{fig_15}}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{11}\includegraphics[]{image-17.png}
\caption{\label{fig_16}Fig. 11 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{12}\includegraphics[]{image-18.png}
\caption{\label{fig_17}Fig. 12 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{}\includegraphics[]{image-19.png}
\caption{\label{fig_18}}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{13}\includegraphics[]{image-20.png}
\caption{\label{fig_19}Fig. 13 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{}\includegraphics[]{image-21.png}
\caption{\label{fig_20}}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{14}\includegraphics[]{image-22.png}
\caption{\label{fig_21}Fig. 14 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{15}\includegraphics[]{image-23.png}
\caption{\label{fig_22}Fig. 15 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{16}\includegraphics[]{image-24.png}
\caption{\label{fig_23}Fig. 16 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{17}\includegraphics[]{image-25.png}
\caption{\label{fig_24}Fig. 17 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{}\includegraphics[]{image-26.png}
\caption{\label{fig_25}}\end{figure}
                      \begin{figure}[htbp]
\noindent\textbf{} \par 
\begin{longtable}{P{0.85\textwidth}}
( ) C\\
concerned record, with the new data that has just\\
been set, and inserts it in the audit table, as\\
shown in Fig. 6, row 6 to 8 in Slave Peer Audit-\\
table;\\
© 2019 Global Journals\end{longtable} \par
  {\small\itshape [Note: 6, row 1 to 5 in Slave Peer Audit-table; ? After each Update operation of a column of data table, the "update trigger" captures the Mediation of Lazy Update Propagation in a Replicated Database over a Decentralized P2P Architecture]} 
\caption{\label{tab_1}?}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{} \par 
\begin{longtable}{P{0.00467940414507772\textwidth}P{0.4068329015544041\textwidth}P{0.41536593264248706\textwidth}P{0.023121761658031086\textwidth}}
\tabcellsep \multicolumn{3}{l}{Algorithm 3: P2P Replication Algorithm for Data Insertion}\\
\tabcellsep \multicolumn{2}{l}{Input: Master peer inserted records}\\
\tabcellsep \multicolumn{3}{l}{Output: Transaction Commitments or Abortions Algorithm 5: P2P Replication Algorithm for Data Delete begininsertFunction() Input: Master peer deleted records 1: begininsertMainTransaction 2: Output: Transaction Commitments or Abortions selectall Available Slave Peers 3: begindeleteFunction() for(p ?0 toNumberOfAvailableSlavePeers -1)do 4: 1: begindeleteMainTransaction begininsertSubTransactionPeer(p) 5: 2: selectall Available Slave Peers selectall Audit Table Names in Mater Peer Database 6: 3: for(p ?0 toNumberOfAvailableSlavePeers -1)do selectall Data Table Names in Slave Peer(p) Database 7: 4: begindeleteSubTransactionPeer(p) for(ts?0 toNumberOfDataTableNamesInSlavePeer(p)Database -1)do 8: selectall Rows in Audit Table(ts) of Master Peer Databasewhere AuditAction = 'Inserted' 5:}\\
Year 2 019\tabcellsep 9: 10:\tabcellsep \multicolumn{2}{l}{and AuditTimeStamp ?BeginningDateAndTime and AuditTimeStamp?EndingDateAndTime for(rtm?0 toRowsInAuditTable(ts)OfMasterPeerDatabase -1)do selectall Column Names in Data Table(ts) of Slave Peer(p) Database}\\
12\tabcellsep 11: 12:\tabcellsep \multicolumn{2}{l}{for(cts?0 to NumberOfColumnNamesInDataTable(ts)OfSlavePeer(p)Database -1)do ColumnNames?ColumnNames\&ColumnNames[cts]}\\
\tabcellsep 13:\tabcellsep \multicolumn{2}{l}{Values ?Values \& Row[rtm]Column[cts]}\\
\tabcellsep 14:\tabcellsep end for cts\\
\tabcellsep 15:\tabcellsep \multicolumn{2}{l}{insert in toDataTableNames(ts)InSlavePeer(p)Database (ColumnNames)values(Values)}\\
\tabcellsep 16:\tabcellsep end for rtm\\
\tabcellsep 17:\tabcellsep end for ts\\
\tabcellsep 20:\tabcellsep \multicolumn{2}{l}{endinsertSubTransaction(Commit or Abort)}\\
\tabcellsep 21:\tabcellsep end for p\\
\tabcellsep \multicolumn{2}{l}{22: endinsertMainTransaction(Commit or Abort)}\\
\tabcellsep \multicolumn{2}{l}{23: returnTransaction Commitments or Abortions}\\
\tabcellsep \multicolumn{2}{l}{endinsertFunction}\\
\tabcellsep \multicolumn{2}{l}{After records which have been inserted be}\tabcellsep which has the instructions in transactions of the\\
\tabcellsep \multicolumn{2}{l}{replicated to slave peers, the algorithm 4 here below,}\tabcellsep update function, also runs in turn.\\
( ) C\tabcellsep \multicolumn{3}{l}{Algorithm 4: P2P Replication Algorithm for Data Update Input: Master peer updated records}\\
\tabcellsep \multicolumn{2}{l}{Output: Transaction Commitments or Abortions}\\
\tabcellsep \multicolumn{2}{l}{beginupdateFunction()}\\
\tabcellsep \multicolumn{2}{l}{1: beginupdateMainTransaction}\\
\tabcellsep 2:\tabcellsep selectall Available Slave Peers\\
\tabcellsep 3:\tabcellsep \multicolumn{2}{l}{for(p ?0 toNumberOfAvailableSlavePeers -1)do}\\
\tabcellsep 4:\tabcellsep beginupdateSubTransactionPeer(p)\\
\tabcellsep 5:\tabcellsep \multicolumn{2}{l}{selectall Audit Table Names in Mater Peer Database}\\
\tabcellsep 6:\tabcellsep \multicolumn{2}{l}{selectall Data Table Names in Slave Peer(p) Database}\\
\tabcellsep 7:\tabcellsep \multicolumn{2}{l}{for(ts?0 toNumberOfDataTableNamesInSlavePeer(p)Database -1)do}\\
\tabcellsep 8:\tabcellsep \multicolumn{2}{l}{selectall Rows in Audit Table(ts) of Master Peer Databasewhere AuditAction = 'Updated'}\\
\tabcellsep \tabcellsep \multicolumn{2}{l}{and AuditTimeStamp?BeginningDateAndTime and}\\
\tabcellsep \tabcellsep AuditTimeStamp?EndingDateAndTime\\
\tabcellsep 9:\tabcellsep \multicolumn{2}{l}{for(rtm?0 toRowsInAuditTable(ts)OfMasterPeerDatabase -1)do}\\
\tabcellsep 10:\tabcellsep \multicolumn{2}{l}{selectall Column Names in Data Table(ts) of Slave Peer(p) Database}\\
\tabcellsep 11:\tabcellsep \multicolumn{2}{l}{for(cts?0 toNumberOfColumnNamesInDataTable(ts)OfSlavePeer(p)Database -1) do}\\
\tabcellsep 12:\tabcellsep \multicolumn{2}{l}{if(ColumnName(cts)InDataTable(ts)OfSlavePeer(p)Database =}\\
\tabcellsep \tabcellsep UpdatedColumnName)then\\
\tabcellsep 13:\tabcellsep \multicolumn{2}{l}{updateDataTable(ts)OfSlavePeer(p)DatabasesetColumnName(cts)InDataTable(ts)Of}\\
\tabcellsep \tabcellsep \multicolumn{2}{l}{SlavePeer(p)Database ?'Row[rtm]Column[cts]'}\\
\tabcellsep \tabcellsep \multicolumn{2}{l}{whereColumnName(0)InDataTable(ts)OfSlavePeer(p)Database =}\\
\tabcellsep \tabcellsep 'Row[rtm]Column[0]'\\
\tabcellsep 14:\tabcellsep end if\\
\tabcellsep 15:\tabcellsep end for cts\\
\tabcellsep 16:\tabcellsep end for rtm\\
\tabcellsep 17:\tabcellsep end for ts\\
\tabcellsep 20:\tabcellsep \multicolumn{2}{l}{endupdateSubTransaction(Commit or Abort)}\\
\tabcellsep 21:\tabcellsep end for p\\
\tabcellsep \multicolumn{2}{l}{22: endupdateMainTransaction(Commit or Abort)}\\
\tabcellsep \multicolumn{2}{l}{23: returnTransaction Commitments or Abortions}\\
\tabcellsep \multicolumn{2}{l}{endupdateFunction}\\
\tabcellsep © 2019 Global Journals\tabcellsep \end{longtable} \par
  {\small\itshape [Note: selectall Audit Table Names in Mater Peer Database 6: selectall Data Table Names in Slave Peer(p) Database 7: for(ts?0 toNumberOfDataTableNamesInSlavePeer(p)Database -1)do 8: selectall Rows in Audit Table(ts) of Master Peer Databasewhere AuditAction = 'Deleted' and AuditTimeStamp?BeginningDateAndTime and AuditTimeStamp?EndingDateAndTime 9: for(rtm?0 to RowsInAuditTable(ts)OfMasterPeerDatabase-1) do 10: selectall Column Names in Data Table(ts) of Slave Peer(p) Database 11: deletefromDataTable(ts)OfSlavePeer(p)DatabasewhereColumnName(0)InDataTable(ts) OfSlavePeer(p)Database = 'Row[rtm]Column[0]' 12: end forrtm 13: end for ts 14: enddeleteSubTransaction(Commit or Abort) 15: end for p 16: enddeleteMainTransaction(Commit or Abort) 17: returnTransaction Commitments or Abortions enddeleteFunction]} 
\caption{\label{tab_4}}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{} \par 
\begin{longtable}{P{0.0027884986491702045\textwidth}P{0.7825839444230027\textwidth}P{0.017387109224237748\textwidth}P{0.03493824778077962\textwidth}P{0.012302199922809726\textwidth}}
\tabcellsep \multicolumn{3}{l}{Mediation of Lazy Update Propagation in a Replicated Database over a Decentralized P2P Architecture Mediation of Lazy Update Propagation in a Replicated Database over a Decentralized P2P Architecture}\\
Year 2 019\tabcellsep \multicolumn{3}{l}{2. Processing: ? Reading forwarded to other replicas by the refresh of updates independently transactions (in (2) dashed arrows); ? Comparison with the Master data read in (1) undashed arrows; ? Reconciliation is written to the Slave peers (in (2) undashed arrows). 3. The commitment (or cancelation) of a reconciliation transaction makes replicas consistent. 41: 42: else //Call function to delete duplicated records function of the algorithm 6 here below: 43: deleteDuplicatedRecordFunction(arguments) 44: end if end if instructions in transactions of the reconciliation 40: startSlaveLoop?rts + 1 The whole reconciliation process is established by 32: startSlaveLoop?0 33: Input: DataTableName(ts)OfSlavePeer(p)Database, UpdatedColumnName, cts, rtm for(rtm ? 0 toNumberOfRowsInAudit Table(ts)OfMasterPeerDatabase -1)do 34: Output: Nothing for(rts ? startSlaveLooptoNumberOfRowsInAudit Table(ts)OfSlavePeer(p)Database -beginupdateIncorrectValuesFunction(args) 1)do 35: 1: if(ColumnName(cts)InDataTable(ts)OfSlave Peer(p)Database=UpdatedColumnName)then if(Row[rtm]Column[0]InAudit Table(ts)OfMasterPeerDatabase = 2: updateDataTable(ts)OfSlavePeer(p)DatabasesetColumnName(cts)InDataTable(ts)OfSlave Row[rts]Column[0]InAuditTable(ts)OfSlavePeer(p)Database)then 36: Peer(p)Database = 'Row[rtm]Column[cts]'whereColumnName(0)InDataTable(ts)OfSlave if(rtm<NumberOfRowsInAudit Table(ts)OfMasterPeerDatabase -1)then 37: Peer(p)Database = 'Row[rtm]Column[0]' startSlaveLoop?rts + 1 38: 3: end if end for rts 39: else endupdateIncorrectValuesFunction}\tabcellsep Year 2 019 Year 2 019\\
14\tabcellsep \multicolumn{3}{l}{Algorithm 6: P2P Algorithm for Data Reconciliation 45: end for rts 46: end for rtm Input: Master peer replicated (inserted, updated and deleted) records 47: else Output: Transaction Commitments or Abortions //Reconcile incorrect, missing and incorrectly formatted values process start beginreconcileFunction() 48: for (rtm = 0 to NumberOfRowsInAudit Table(ts)OfMasterPeerDatabase -1)do 1: beginreconcileMainTransaction 2: 49: for (cts = 0 to NumberOfColumnNamesInDataTable(ts)OfSlavePeer(p)Database -selectall Available Slave Peers 3: 1)do for(p ?0 toNumberOfAvailableSlavePeers -1)do 4: 50: if (Row[rtm]Column[cts]InAudit Table(ts)OfMasterPeerDatabase ? beginreconcileSubTransactionPeer(p) 5: Row[rtm]Column[cts]InAuditTable(ts)OfSlavePeer(p)Database) then selectall Audit Table Names in Mater Peer Database //Call function to update Incorrect values, missing values, incorrectly formatted 6: values}\tabcellsep 13\\
\tabcellsep 51:\tabcellsep \tabcellsep updateIncorrectValuesFunction(arguments)\\
\tabcellsep 52:\tabcellsep \tabcellsep end if\\
\tabcellsep 53:\tabcellsep \tabcellsep end for cts\\
( ) C\tabcellsep \multicolumn{3}{l}{11: 12: 13: 14: endreconcileFunction Table(ts)OfMasterPeerDatabase -1)then if(NumberOfRowsInAudit Table(ts)OfSlavePeer(p)Database -1 <NumberOfRowsInAudit 60: returnTransaction Commitments or Abortions sortRows of Audit Table(ts) of Slave Peer(p) Database 59: endreconcileMainTransaction(Commit or Abort) sortRows of Audit Table(ts) of Master Peer Database 58: end for p selectall Column Names in Data Table(ts) of Slave Peer(p) Database 57: endreconcileSubTransaction(Commit or Abort) 'Remote' 54: end for rtm 55: end if 56: end for ts}\tabcellsep ( ) C ( ) C\\
\tabcellsep \multicolumn{3}{l}{15: To insert missing records, the algorithm 7 here is called. rts?0}\tabcellsep //Reconcile missing records process start\\
\tabcellsep \multicolumn{3}{l}{16: Algorithm 7: Function to insert missing records for(rtm?0 toNumberOfRowsInAuditTable(ts)OfMasterPeerDatabase -1)do}\\
\tabcellsep \multicolumn{3}{l}{17: Input: DataTable(ts)OfSlavePeer(p)Database, cts, rtm repeat}\\
\tabcellsep \multicolumn{2}{l}{18: Output: Nothing}\tabcellsep if(rts?NumberOfRowsInAudit Table(ts)OfSlavePeerDatabase -1)then\\
\tabcellsep \multicolumn{3}{l}{19: begininsertMissingRecordFunction(args) if(Row[rtm]Column[0]InAudit Table(ts)OfMasterPeerDatabase =}\\
\tabcellsep \multicolumn{3}{l}{Row[rts]Column[0]InAuditTable(ts)OfSlavePeer(p)Database)then 1: for(cts?0 to NumberOfColumnNamesInDataTable(ts)OfSlavePeer(p)Database -1)do}\\
\tabcellsep 20: 2:\tabcellsep \multicolumn{2}{l}{Continue(rts ++) ColumnNames?ColumnNames\&ColumnNames[cts]}\\
\tabcellsep 21: 3:\tabcellsep \multicolumn{2}{l}{end repeat Values ?Values \& Row[rtm]Column[cts]}\\
\tabcellsep \multicolumn{2}{l}{22: 4: end for cts}\tabcellsep else\\
\tabcellsep \multicolumn{3}{l}{//Call function to insert missing records 5: insert in toDataTableNames(ts)InSlavePeer(p) Database (ColumnNames) values (Values)}\\
\tabcellsep \multicolumn{3}{l}{23: endinsertMissRecordFunction insertMissingRecordFunction(arguments)}\\
\tabcellsep \multicolumn{3}{l}{24: 25: To delete duplicated records, the algorithm 8 here is called. end if else}\\
\tabcellsep \multicolumn{3}{l}{//Call function to insert missing records Algorithm 8: Function to delete duplicated records 26: insertMissingRecordFunction(arguments) 27: Input: DataTable(ts)OfSlavePeer(p)Database, rtm end repeat 28: Output: Nothing end if 29: begindeleteDuplicatedRecordFunction(args) until(Row[rtm]Column[0]InAudit Table(ts)OfMasterPeerDatabase = 1: deletefromDataTable(ts)OfSlavePeer(p)DatabasewhereColumnName(0)InDataTable(ts)OfSlave Row[rts]Column[0]InAuditTable(ts)OfSlavePeer(p)Database) 30: Peer(p)Database = 'Row[rtm]Column[0]' end for rtm 31: else if(NumberOfRowsInAudit Table(ts)OfSlavePeer(p)Database -1 enddeleteDuplicatedRecordFunction}\\
\tabcellsep \multicolumn{3}{l}{>NumberOfRowsInAuditTable(ts)OfMasterPeerDatabase -1)then To update incorrect values, the algorithm 9 is called.}\\
\tabcellsep \tabcellsep \tabcellsep //Reconcile duplicated records process start\\
\tabcellsep © 2019 Global Journals\tabcellsep \tabcellsep © 2019 Global Journals © 2019 Global Journals\end{longtable} \par
  {\small\itshape [Note: selectall Audit Table Names in Slave Peer(p) Database 7: selectall Data Table Names in Slave Peer(p) Database 8: for(ts?0 toNumberOfDataTableNamesInSlavePeer(p)Database -1)do 9: selectall Rows in Audit Table(ts) of Master Peer Database where TransactionType = 'Local' and AuditTimeStamp?BeginningDateAndTime and AuditTimeStamp?EndingDateAndTime 10: selectall Rows in Audit Table(ts) of Slave Peer(p) Database where TransactionType =]} 
\caption{\label{tab_5}}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{1} \par 
\begin{longtable}{P{0.19378238341968912\textwidth}P{0.3435233160621762\textwidth}P{0.3126943005181347\textwidth}}
Nbr.\tabcellsep Number of rows\tabcellsep Number of rows\\
Obs.\tabcellsep to replicate\tabcellsep to reconcile\\
1.\tabcellsep 723\tabcellsep 181\\
2.\tabcellsep 900\tabcellsep 225\\
3.\tabcellsep 120\tabcellsep 30\\
4.\tabcellsep 2500\tabcellsep 625\\
5.\tabcellsep 1253\tabcellsep 313\\
6.\tabcellsep 80\tabcellsep 20\\
7.\tabcellsep 3000\tabcellsep 750\\
8.\tabcellsep 5000\tabcellsep 1250\\
9.\tabcellsep 450\tabcellsep 113\\
10.\tabcellsep 4860\tabcellsep 1215\\
11.\tabcellsep 600\tabcellsep 150\\
12.\tabcellsep 235\tabcellsep 59\\
Mean\tabcellsep 1643.42\tabcellsep 410.92\\
Total\tabcellsep 19721\tabcellsep 4931\end{longtable} \par
 
\caption{\label{tab_7}Table 1 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{2} \par 
\begin{longtable}{P{0.1095703125\textwidth}P{0.0498046875\textwidth}P{0.166015625\textwidth}P{0.0630859375\textwidth}P{0.166015625\textwidth}P{0.06640625\textwidth}P{0.166015625\textwidth}P{0.0630859375\textwidth}}
\multicolumn{2}{l}{Sample}\tabcellsep \multicolumn{2}{l}{Insert execution}\tabcellsep \multicolumn{2}{l}{Update execution}\tabcellsep \multicolumn{2}{l}{Delete execution}\\
\multicolumn{2}{l}{numbering}\tabcellsep \multicolumn{2}{l}{time (in Sec.)}\tabcellsep \multicolumn{2}{l}{time (in Sec.)}\tabcellsep \multicolumn{2}{l}{time (in Sec.)}\\
Nbr.\tabcellsep Master\tabcellsep Repli\tabcellsep Reconci\tabcellsep Repli\tabcellsep Reconci\tabcellsep Repli\tabcellsep Reconci\\
Obs.\tabcellsep Peer\tabcellsep cation\tabcellsep liation\tabcellsep cation\tabcellsep liation\tabcellsep cation\tabcellsep liation\\
1.\tabcellsep B\tabcellsep 19\tabcellsep 2\tabcellsep 19\tabcellsep 3\tabcellsep 20\tabcellsep 2\\
2.\tabcellsep A\tabcellsep 24\tabcellsep 2\tabcellsep 24\tabcellsep 4\tabcellsep 24\tabcellsep 2\\
3.\tabcellsep C\tabcellsep 3\tabcellsep 0\tabcellsep 3\tabcellsep 1\tabcellsep 4\tabcellsep 0\\
4.\tabcellsep C\tabcellsep 67\tabcellsep 5\tabcellsep 68\tabcellsep 12\tabcellsep 69\tabcellsep 8\\
5.\tabcellsep A\tabcellsep 35\tabcellsep 3\tabcellsep 35\tabcellsep 5\tabcellsep 36\tabcellsep 4\end{longtable} \par
 
\caption{\label{tab_8}Table 2 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{2} \par 
\begin{longtable}{}
\end{longtable} \par
 
\caption{\label{tab_9}Table 2 ,}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{3} \par 
\begin{longtable}{P{0.12506234413965087\textwidth}P{0.04663341645885286\textwidth}P{0.15261845386533665\textwidth}P{0.07206982543640898\textwidth}P{0.15261845386533665\textwidth}P{0.07418952618453865\textwidth}P{0.15261845386533665\textwidth}P{0.07418952618453865\textwidth}}
\multicolumn{2}{l}{Sample}\tabcellsep \multicolumn{2}{l}{Insert execution}\tabcellsep \multicolumn{2}{l}{Update execution}\tabcellsep \multicolumn{2}{l}{Delete execution}\\
\multicolumn{2}{l}{numbering}\tabcellsep \multicolumn{2}{l}{time (in Sec.)}\tabcellsep \multicolumn{2}{l}{time (in Sec.)}\tabcellsep \multicolumn{2}{l}{time (in Sec.)}\\
Nbr.\tabcellsep Master\tabcellsep Repli\tabcellsep Reconci\tabcellsep Repli\tabcellsep Reconci\tabcellsep Repli\tabcellsep Reconci\\
Obs.\tabcellsep Peer\tabcellsep cation\tabcellsep liation\tabcellsep cation\tabcellsep liation\tabcellsep cation\tabcellsep liation\\
1.\tabcellsep B\tabcellsep 12\tabcellsep 2\tabcellsep 12\tabcellsep 3\tabcellsep 11\tabcellsep 2\\
2.\tabcellsep A\tabcellsep 15\tabcellsep 2\tabcellsep 15\tabcellsep 4\tabcellsep 16\tabcellsep 3\\
3.\tabcellsep C\tabcellsep 2\tabcellsep 0\tabcellsep 2\tabcellsep 1\tabcellsep 3\tabcellsep 1\\
4.\tabcellsep C\tabcellsep 45\tabcellsep 5\tabcellsep 47\tabcellsep 11\tabcellsep 46\tabcellsep 7\\
5.\tabcellsep A\tabcellsep 24\tabcellsep 3\tabcellsep 24\tabcellsep 5\tabcellsep 25\tabcellsep 4\\
6.\tabcellsep A\tabcellsep 1\tabcellsep 0\tabcellsep 2\tabcellsep 0\tabcellsep 2\tabcellsep 1\\
7.\tabcellsep B\tabcellsep 61\tabcellsep 7\tabcellsep 61\tabcellsep 9\tabcellsep 63\tabcellsep 10\\
8.\tabcellsep B\tabcellsep 104\tabcellsep 12\tabcellsep 110\tabcellsep 24\tabcellsep 116\tabcellsep 18\\
9.\tabcellsep A\tabcellsep 12\tabcellsep 1\tabcellsep 12\tabcellsep 2\tabcellsep 12\tabcellsep 1\\
10.\tabcellsep C\tabcellsep 115\tabcellsep 11\tabcellsep 121\tabcellsep 23\tabcellsep 125\tabcellsep 16\\
11.\tabcellsep C\tabcellsep 16\tabcellsep 1\tabcellsep 16\tabcellsep 2\tabcellsep 16\tabcellsep 1\\
12.\tabcellsep B\tabcellsep 7\tabcellsep 1\tabcellsep 6\tabcellsep 1\tabcellsep 7\tabcellsep 1\\
Mean\tabcellsep \tabcellsep 34.50\tabcellsep 3.75\tabcellsep 35.67\tabcellsep 7.08\tabcellsep 36.83\tabcellsep 5.42\\
Total\tabcellsep \tabcellsep 414\tabcellsep 45\tabcellsep 428\tabcellsep 85\tabcellsep 442\tabcellsep 65\end{longtable} \par
 
\caption{\label{tab_10}Table 3 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{1} \par 
\begin{longtable}{P{0.12291666666666667\textwidth}P{0.04583333333333334\textwidth}P{0.15208333333333332\textwidth}P{0.07083333333333333\textwidth}P{0.15208333333333332\textwidth}P{0.07708333333333332\textwidth}P{0.15416666666666665\textwidth}P{0.075\textwidth}}
\multicolumn{2}{l}{Sample}\tabcellsep \multicolumn{2}{l}{Insert execution}\tabcellsep \multicolumn{2}{l}{Update execution}\tabcellsep \multicolumn{2}{l}{Delete execution}\\
\multicolumn{2}{l}{numbering}\tabcellsep \multicolumn{2}{l}{time (in Sec.)}\tabcellsep \multicolumn{2}{l}{time (in Sec.)}\tabcellsep \multicolumn{2}{l}{time (in Sec.)}\\
Nbr.\tabcellsep Master\tabcellsep Repli\tabcellsep Reconci\tabcellsep Repli\tabcellsep Reconci\tabcellsep Repli\tabcellsep Reconci\\
Obs.\tabcellsep Peer\tabcellsep cation\tabcellsep liation\tabcellsep cation\tabcellsep liation\tabcellsep cation\tabcellsep liation\\
1.\tabcellsep B\tabcellsep 22\tabcellsep 2\tabcellsep 23\tabcellsep 3\tabcellsep 23\tabcellsep 2\\
2.\tabcellsep A\tabcellsep 28\tabcellsep 2\tabcellsep 28\tabcellsep 5\tabcellsep 28\tabcellsep 2\\
3.\tabcellsep C\tabcellsep 3\tabcellsep 0\tabcellsep 3\tabcellsep 1\tabcellsep 5\tabcellsep 0\\
4.\tabcellsep C\tabcellsep 78\tabcellsep 6\tabcellsep 79\tabcellsep 14\tabcellsep 80\tabcellsep 11\\
5.\tabcellsep D\tabcellsep 41\tabcellsep 3\tabcellsep 41\tabcellsep 6\tabcellsep 42\tabcellsep 5\\
6.\tabcellsep A\tabcellsep 3\tabcellsep 0\tabcellsep 2\tabcellsep 0\tabcellsep 3\tabcellsep 0\\
7.\tabcellsep B\tabcellsep 97\tabcellsep 8\tabcellsep 97\tabcellsep 17\tabcellsep 101\tabcellsep 15\\
8.\tabcellsep D\tabcellsep 185\tabcellsep 14\tabcellsep 200\tabcellsep 30\tabcellsep 218\tabcellsep 21\\
9.\tabcellsep A\tabcellsep 17\tabcellsep 1\tabcellsep 16\tabcellsep 2\tabcellsep 16\tabcellsep 1\\
10.\tabcellsep C\tabcellsep 165\tabcellsep 12\tabcellsep 170\tabcellsep 27\tabcellsep 172\tabcellsep 20\\
11.\tabcellsep D\tabcellsep 28\tabcellsep 2\tabcellsep 28\tabcellsep 3\tabcellsep 29\tabcellsep 3\\
12.\tabcellsep B\tabcellsep 12\tabcellsep 1\tabcellsep 11\tabcellsep 1\tabcellsep 12\tabcellsep 1\\
Mean\tabcellsep \tabcellsep 56.58\tabcellsep 4.25\tabcellsep 58.17\tabcellsep 9.08\tabcellsep 60.75\tabcellsep 6.75\\
Total\tabcellsep \tabcellsep 679\tabcellsep 51\tabcellsep 698\tabcellsep 109\tabcellsep 729\tabcellsep 81\end{longtable} \par
 
\caption{\label{tab_11}Table 1 ,}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{4} \par 
\begin{longtable}{P{0.85\textwidth}}
( ) C\end{longtable} \par
 
\caption{\label{tab_12}Table 4 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{4} \par 
\begin{longtable}{}
\end{longtable} \par
 
\caption{\label{tab_13}Table 4 ,}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{5} \par 
\begin{longtable}{P{0.1107394366197183\textwidth}P{0.05088028169014084\textwidth}P{0.16161971830985913\textwidth}P{0.0658450704225352\textwidth}P{0.16161971830985913\textwidth}P{0.06883802816901409\textwidth}P{0.16161971830985913\textwidth}P{0.06883802816901409\textwidth}}
\multicolumn{2}{l}{Sample}\tabcellsep \multicolumn{2}{l}{Insert execution}\tabcellsep \multicolumn{2}{l}{Update execution}\tabcellsep \multicolumn{2}{l}{Delete execution}\\
\multicolumn{2}{l}{numbering}\tabcellsep \multicolumn{2}{l}{time (in Sec.)}\tabcellsep \multicolumn{2}{l}{time (in Sec.)}\tabcellsep \multicolumn{2}{l}{time (in Sec.)}\\
Nbr.\tabcellsep Master\tabcellsep Repli\tabcellsep Reconci\tabcellsep Repli\tabcellsep Reconci\tabcellsep Repli\tabcellsep Reconci\\
Obs.\tabcellsep Peer\tabcellsep cation\tabcellsep liation\tabcellsep cation\tabcellsep liation\tabcellsep cation\tabcellsep liation\\
1.\tabcellsep B\tabcellsep 22\tabcellsep 3\tabcellsep 19\tabcellsep 5\tabcellsep 18\tabcellsep 3\\
2.\tabcellsep A\tabcellsep 26\tabcellsep 3\tabcellsep 28\tabcellsep 6\tabcellsep 28\tabcellsep 5\\
3.\tabcellsep C\tabcellsep 6\tabcellsep 0\tabcellsep 7\tabcellsep 1\tabcellsep 6\tabcellsep 2\\
4.\tabcellsep C\tabcellsep 90\tabcellsep 8\tabcellsep 93\tabcellsep 18\tabcellsep 92\tabcellsep 15\\
5.\tabcellsep D\tabcellsep 58\tabcellsep 5\tabcellsep 51\tabcellsep 8\tabcellsep 76\tabcellsep 6\\
6.\tabcellsep A\tabcellsep 6\tabcellsep 0\tabcellsep 6\tabcellsep 0\tabcellsep 6\tabcellsep 0\\
7.\tabcellsep B\tabcellsep 188\tabcellsep 12\tabcellsep 181\tabcellsep 13\tabcellsep 180\tabcellsep 23\end{longtable} \par
 
\caption{\label{tab_14}Table 5 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{6} \par 
\begin{longtable}{P{0.1533298374410068\textwidth}P{0.051704247509176716\textwidth}P{0.0766649187205034\textwidth}P{0.48450445726271635\textwidth}P{0.07354483481908757\textwidth}P{0.0004457262716308338\textwidth}P{0.009805977975878342\textwidth}}
Experimental scenarios\tabcellsep T ransaction\tabcellsep Operator\tabcellsep Model\tabcellsep R²\tabcellsep R\tabcellsep Prediction (to 1 Sec.)\\
1. Experimentation based one table stored on a master peer with two slave peers\tabcellsep Replication Reconciliation\tabcellsep Insert Update Delete Insert Update Delete\tabcellsep ??=0.0302???0.5595+? ??=0.0318???2.0714+? ?? = 0.0336?? ? 2.528 + ? ??=0.0093???0.0777+? ??=0.0208???0.4639+? ??=0.0148???0.4124+?\tabcellsep \multicolumn{3}{l}{98.65\% 99.34\% 52 records 97.89\% 98.94\% 97 records 96.63\% 96.63\% 105 records 98.76\% 99.38\% 116 records 99.56\% 99.78\% 70 records 99.22\% 99.61\% 95 records}\\
2. Experimentation based two tables stored on a master peer with two slave peers\tabcellsep Replication Reconciliation\tabcellsep Insert Update Delete Insert Update Delete\tabcellsep \multicolumn{4}{l}{??=0.0210???1.3366+? ??=0.0230???2.0949+? ??=0.0239???2.4175+? ??=0.0093???0.0671+? ?? = 0.0184?? ? 0.4798 + ? 98.32\% 99.16\% 80 records 98.46\% 99.23\% 111 records 99.25\% 99.63\% 135 records 98.32\% 99.16\% 143 records 96.91\% 98.44\% 115 records ?? = 0.0136?? ? 0.1746 + ? 98.59\% 99.29\% 86 records}\\
3. Experimentation based one table stored on a master peer with three slave peers\tabcellsep Replication Reconciliation\tabcellsep Insert Update Delete Insert Update Delete\tabcellsep \multicolumn{4}{l}{?? = 0.0348?? ? 0.5762 + ? 99.14\% 99.57\% 45 records ?? = 0.0368?? ? 2.3047 + ? 99.05\% 99.52\% 52 records ?? = 0.0387?? ? 2.8053 + ? 98.49\% 99.24\% 98 records ?? = 0.0106?? ? 0.0883 + ? 99.64\% 99.82\% 103 records ?? = 0.0235?? ? 0.5576 + ? 97.35\% 98.67\% 66 records ?? = 0.0176?? ? 0.4611 + ? 98.48\% 99.24\% 83 records}\\
4. Experimentation based two tables stored on a master peer with three slave peers\tabcellsep Replication Reconciliation\tabcellsep Insert Update Delete Insert Update Delete\tabcellsep \multicolumn{4}{l}{?? = 0.0539?? ? 2.9424 + ? 94.95\% 97.44\% 73 records ?? = 0.0527?? ? 4.3298 + ? 96.22\% 98.09\% 101 records ?? = 0.0566?? ? 5.5273 + ? 97.05\% 98.51\% 115 records ?? = 0.0206?? ? 1.0387 + ? 95.93\% 97.94\% 99 records ?? = 0.0293?? ? 0.8713 + ? 97.09\% 98.53\% 64 records ?? = 0.0266?? ? 0.7763 + ? 98.12\% 99.05\% 67 records}\end{longtable} \par
 
\caption{\label{tab_15}Table 6 :}\end{figure}
 			\footnote{© 2019 Global Journals} 			\footnote{© 2019 Global JournalsMediation of Lazy Update Propagation in a Replicated Database over a Decentralized P2P Architecture} 		 		\backmatter   			 
\subsection[{Acknowledgement}]{Acknowledgement}\par
Firstly, we are grateful to the Grace of Almighty God. We would also like to thank the academic corps of the Butembo (D. R. Congo) Institute of Building and Public Works for their encouragement and follow-up of our investigations. On finish, we thank the Research Technology and Development Centre (RTDC) of Sharda University, for its facilities to realize this work. 			  			  				\begin{bibitemlist}{1}
\bibitem[ Oracle Corporation web site ()]{b19}\label{b19} 	 		\textit{},  	 	 		\textit{Oracle Corporation web site}  		2018.  	 
\bibitem[ Oracle Corporation web site ()]{b22}\label{b22} 	 		\textit{},  	 	 		\textit{Oracle Corporation web site}  		2018.  	 
\bibitem[ ApexSQL LLC web site ()]{b25}\label{b25} 	 		\textit{},  	 	 		\textit{ApexSQL LLC web site}  		2018.  	 
\bibitem[Zhang ()]{b15}\label{b15} 	 		‘A Novel Replication Model with Enhanced Data Availability in P2P Platforms’.  		 			T Zhang 		.  	 	 		\textit{International Journal of Grid and Distributed Computing}  		2016. 9  (4)  p. .  	 
\bibitem[Kituta et al. ()]{b29}\label{b29} 	 		‘A systematic review on distributed databases systems and their techniques’.  		 			K Kituta 		,  		 			S Kant 		,  		 			R Agarwal 		.  	 	 		\textit{Journal of T heoretical and Applied Information Technology}  		2019. 96  (1)  p. .  	 
\bibitem[Kudo ()]{b6}\label{b6} 	 		‘An implementation of concurrency control between batch update and online entries’.  		 			T Kudo 		.  	 	 		\textit{18 th International Conference on Knowledge-Based and Intelligent Information \& Engineering Systems -KES2014, Procedia Computer Science},  				2014. 35 p. .  	 
\bibitem[George and Balakrishnan ()]{b14}\label{b14} 	 		‘An optimized strategy for replication in peer-to-peer distributed databases’.  		 			A George 		,  		 			C Balakrishnan 		.  	 	 		\textit{IEEE International Conference on Computational Intelligence and Computing Research},  				2012.  	 
\bibitem[Kituta et al. ()]{b26}\label{b26} 	 		‘Analysis of database replication protocols’.  		 			K Kituta 		,  		 			S Kant 		,  		 			R Agarwal 		.  	 	 		\textit{International Journal of Latest T rends in Engineering and T echnology}  		2018. 2018. p. .  	 	 (Special Issue ICRMR) 
\bibitem[Filip et al. ()]{b10}\label{b10} 	 		‘Considerations about an Oracle Database Multi-Master Replication’.  		 			I Filip 		,  		 			C Vasar 		,  		 			R Robu 		.  	 	 		\textit{IEEE 5th International Symposium on Applied Computational Intelligence and Informatics},  				2009.  	 
\bibitem[Souri et al. ()]{b30}\label{b30} 	 		‘Consistency of data replication protocols in database systems: A review’.  		 			A Souri 		,  		 			S Pashazadeh 		,  		 			A Navin 		,  		 			H 		.  	 	 		\textit{International Journal on Information Theory (IJIT)}  		2014. 3  (4)  p. .  	 
\bibitem[Cormen ()]{b17}\label{b17} 	 		 			T Cormen 		,  		 			H 		.  		\textit{Introduction to Algorithms},  				 (London, England)  		2012. The MIT Press.  	 	 (4th ed.) 
\bibitem[Fatos ()]{b28}\label{b28} 	 		‘Data Replication in Collaborative Systems’.  		 			X Fatos 		.  	 	 		\textit{IEEE Seventh International Conference on P2P, Parallel, Grid, Cloud and Internet Computing},  				2012.  	 
\bibitem[T Ing and Yu ()]{b16}\label{b16} 	 		‘Database Replication T echnology having high Consistency Requirements’.  		 			Z T Ing 		,  		 			W Yu 		.  	 	 		\textit{IEEE Third International Conference on Information Science and Technology},  				2013.  	 
\bibitem[Database Schema Difference Reconciliation ()]{b23}\label{b23} 	 		 \url{https://www.perpetual-beta.org/weblog/mysql-diff.html}  	 	 		\textit{Database Schema Difference Reconciliation},  				 (Jonathan, H., MySQL\textunderscore Diff)  		2018. 2018.  	 
\bibitem[Silberschatz et al. ()]{b8}\label{b8} 	 		\textit{Database system concepts},  		 			A Silberschatz 		,  		 			H F Korth 		,  		 			S Sudarshan 		.  		1997. New York: McGraw-Hill.  	 
\bibitem[Diallo et al. ()]{b7}\label{b7} 	 		‘Distributed Database Management T echniques for Wireless Sensor Networks’.  		 			O Diallo 		,  		 			Joel Rodrigues 		,  		 			J Sene 		,  		 			M Lloret 		,  		 			J 		.  	 	 		\textit{IEEE T ransactions on Parallel and Distributed Systems}  		2015. 26  (2)  p. .  	 
\bibitem[Shahin et al. ()]{b21}\label{b21} 	 		\textit{Dynamic Data Allocation with Replication in Distributed Systems. 30 th IEEE International Performance Computing and Communications Conference},  		 			K Shahin 		,  		 			G Pedram 		,  		 			D Khuzaima 		.  		2011.  	 
\bibitem[Mansouri and Buyya ()]{b11}\label{b11} 	 		‘Dynamic replication and migration of data objects with hot -spot and coldspot statuses across storage data centers’.  		 			Y Mansouri 		,  		 			R Buyya 		.  	 	 		\textit{Journal of Parallel and Distributed Computing}  		2018. 126 p. .  	 	 (Publisher: Elsivier) 
\bibitem[Santana and Francesc ()]{b31}\label{b31} 	 		‘Evaluation of database replication techniques for cloud systems’.  		 			M Santana 		,  		 			Enrique 		,  		 			J Francesc 		,  		 			D 		.  	 	 		\textit{Computing and Informatics}  		2015. 34 p. .  	 
\bibitem[Experian Ltd web site ()]{b20}\label{b20} 	 		\textit{Experian Ltd web site},  		 \url{https://www.edq.com/uk/glossary/data-reconciliation/}  		2018.  	 
\bibitem[Sebastian ()]{b12}\label{b12} 	 		\textit{Fundamentals of SQL Server},  		 			M Sebastian 		.  		2012. 2013. New York, United States of America: Simple T alk Publishing.  	 
\bibitem[Pandey and Shanker ()]{b5}\label{b5} 	 		‘IDRC: A Distributed Real-T ime Commit Protocol’.  		 			S Pandey 		,  		 			U Shanker 		.  	 	 		\textit{th International Conference on Smart Computing and Communications ICSCC 2017},  				2017. 125 p. .  	 	 (Publisher: Elsivier) 
\bibitem[Kothari and Garg ()]{b18}\label{b18} 	 		‘In-House’.  		 			C Kothari 		,  		 			R Garg 		,  		 			G 		.  	 	 		\textit{Research methodology methods and techniques},  				2014. 2018. 20.  	 	 (Microsoft Corporation web site) 
\bibitem[Kirtikumar ()]{b13}\label{b13} 	 		\textit{Oracle Streams 11g Data Replication},  		 			D Kirtikumar 		.  		2011. New York, United States of America: McGraw-Hill.  	 
\bibitem[Vu et al. ()]{b9}\label{b9} 	 		\textit{Peer-to-Peer Computing -Principles and Applications},  		 			Q Vu 		,  		 			M Lupu 		,  		 			C Ooi 		.  		2010. Springer.  	 
\bibitem[Pragmatic Works Inc. web site ()]{b24}\label{b24} 	 		 \url{https://dbconvert.com/30}  		\textit{Pragmatic Works Inc. web site},  				2018. 2018.  	 
\bibitem[Spaho ()]{b27}\label{b27} 	 		 			E Spaho 		.  	 	 		\textit{Modeling and Processing for Next -Generation Big-Data T echnologies. Modeling and Optimization in Science and Technologies},  				 			F Xhafa,  			L Barolli,  			A Barolli,  			P Papajorgji 		 (ed.)  		2015. Springer. 4 p. .  	 	 (P2P Data Replication: T echniques and Applications) 
\bibitem[Kituta et al.]{b0}\label{b0} 	 		‘Synchronous and Asynchronous Replication’.  		 			K Kituta 		,  		 			R Agarwal 		,  		 			B Kaushik 		.  	 	 		\textit{International Conference on Machine Learning and Computational Intelligence},  				2017.  	 	 (International) 
\bibitem[Gudakesa et al. ()]{b4}\label{b4} 	 		‘T woways database synchronization in homogeneous DBMS using audit log approach’.  		 			R Gudakesa 		,  		 			M Sukarsa 		,  		 			G Sasmita 		.  	 	 		\textit{Journal of T heoretical and Applied Information Technology}  		2014. 65 p. .  	 
\bibitem[Magdalena ()]{b2}\label{b2} 	 		‘The Replication Technology in E-learning Systems’.  		 			N Magdalena 		,  		 			I 		.  	 	 		\textit{Procedia -Social and Behavioral Sciences}  		2011. 28 p. .  	 	 (Publisher: Elsivier) 
\bibitem[Wiesmann ()]{b3}\label{b3} 	 		‘Understanding Replication in Databases and Distributed Systems’.  		 			M Wiesmann 		.  	 	 		\textit{IEEE 20th International Conference on Distributed Computing Systems},  				2002.  	 
\bibitem[Özsu and Valduriez ()]{b1}\label{b1} 	 		 			M T Özsu 		,  		 			P Valduriez 		.  		\textit{Principles of Distributed Database Systems},  				 (New York, USA)  		2011. Springer Science \& Business + Media.  	 	 (3rd ed.) 
\end{bibitemlist}
 			 		 	 
\end{document}
