Distributed Database Systems and Object Orientation

The assignment content discusses various aspects of databases, including distributed database systems, cost/benefit analysis, and relational databases. It also explores how relational databases can be used to support object-oriented programming concepts. Additionally, it touches on multimedia databases and data warehousing concepts. The paper provides actionable recommendations for non-technical people to interact with specialists and the IT team.

<University>
EXPLANATIONS AND RECOMMENDATIONS FOR
THE WINE CELLAR DATABASE
by
Student Number:
Module Name:
Submission Deadline:
15th March 2017
<Lecturer’s Name and Course Number>
 <Your Name> <Your Student Number> 2017 1 of 22

Table of Contents
Explanations and Recommendations for The Wine Cellar Database.............................5
Task 1.............................................................................................................................6
Limitations of Relational Databases for The Wine Cellar Scenario..........................6
Data Warehouse and Their Support in Decision-Making..........................................8
Issues in Designing and Implementing a Data Warehouse........................................9
Data Structure Model for The Wine Cellar Scenario...............................................10
Task 2...........................................................................................................................12
Distributed Databases and Potential Issues Before Final Design Decisions............12
Relevance of Distributed Database for The Wine Cellar Organization and
Costs/Benefits...........................................................................................................14
Recommendation of Type of Distributed Database and Justifications....................15
Task 3...........................................................................................................................15
How Relational Databases Support Object Oriented Development?.......................15
Relational Databases Relevance for Multimedia Requirements in The Wine Cellar
Scenario....................................................................................................................16
Conclusion....................................................................................................................17
References....................................................................................................................19
 <Your Name> <Your Student Number> 2017 2 of 22

Data is the oil that runs the machinery of the present-day society. Data is everywhere,
and new is being generated every moment from many sources. Being able to store and
retrieve data in an efficient way is an essential requirement for the success of any
organisation. Also, different databases are optimised for different roles. Some may be
optimised for read-heavy operations, while others may be optimised for write-heavy
operations. Optimising one parameter entails a drawback in other parameters. Also,
the underlying structure of a database system has a significant bearing on the
applications. This paper deals with the new requirements of a (fictitious) company in
England, which is engaged in sourcing wine and accessories from all over the world
and selling them. The company has experienced growth in the recent years and has
opened branches throughout the country. However, the database handling is still
keeping in mind a single location. The consequence has been the delay and manual
effort required in compiling company-wide reports. In addition to the reporting
requirement, the company also wants to promote selected products via short videos on
a website. This paper details the various database technologies and provides
recommendations for the new scenarios of reporting and multimedia promotions
which have cropped up for The Wine Cellar.
 <Your Name> <Your Student Number> 2017 3 of 22

 <Your Name> <Your Student Number> 2017 4 of 22

Explanations and Recommendations for The Wine Cellar Database
Data is the new oil (Toonders 2014), and this implies a likewise importance to the
means for managing data. Data needs to be stored, edited, deleted, copied and
retrieved to be of relevance to the success of a business or an organisation. All of
these operations to the data need to be done in a performant way. If data is not
handled efficiently, then instead of becoming a competitive advantage and blooming
to its full potential, data becomes additional work without the benefits (Jones 2016).
The means of managing the data (including the data itself, paradigms, schemas, and
the software used) come under the term of databases (Gupta 2011, p.5). Databases are
thus a solution to our world's requirement for storing significant amounts of data and
retrieving it quickly and accurately (Ward and Dafoulas 2006, p.2). Databases are of
many types and have been evolving since their inception in the 1970s (Ward and
Dafoulas 2006, p.2), and many variants have been developed, each with its
advantages and shortcomings. Some of the types of databases are flat-file, relational,
distributed, NoSQL, and others (Data Warehouses 2012). It is not the case that one
type of a database management system (DBMS) is intrinsically better than another,
but each is suited to some particular scenarios. Since efficiency is an essential
requirement for the database, the scenario at hand needs to be considered before
selecting a particular database.
This paper is about the database requirements of a (fictitious) company that operates
in England. This company, The Wine Cellar is engaged in selling a selection of fine
wine, spirits and accessories. The company arranges wines and accessories to sell
from sellers all over the world. The company has experienced growth in the last few
years with the resulting expansion. The company now operates from many branches
within England. Each branch maintains its private database and submits a summary
file each week to the head office at the end of every week. This submission from silo-
like databases at each outlet does fulfil the requirements for the data at the head
office, but the turnaround time is very high. Currently, the individual files are
analysed individually, and the results are amalgamated. Also, this process is labour-
intensive, both at the branch and the head-office level. Given the growth and
 <Your Name> <Your Student Number> 2017 5 of 22

expansion of The Wine Cellar and the future potential, timely and accurate data is
critical. The management will be better equipped to make company-wide strategic
decisions if the company-wide information is easily available at short notice. This
agility in data querying is something that the current solution cannot provide. Also,
the company would like to promote selected products by showcasing short videos via
a website. These two requirements will be attended to in the paper, in addition to
providing a theoretical knowhow of the database technologies relevant to the
discussion.
The Information Technology (IT) team of The Wine Cellar is skilled in relational
database design, and this skill-set served the company well until recently. However,
keeping in mind the recent growth and the future possibilities, the IT team will have
to expand their skill set to include some new technologies, or some new hires with the
relevant skills will have to be made. The company is more interested in training and
increasing the skills of the current team. This paper will look into these new
technologies and will suggest ways in which the existing experience of the team can
be utilised while developing new ones.
Task 1
Limitations of Relational Databases for The Wine Cellar Scenario
In the relational database paradigm, data is represented in the form of tables, and
relations among the tables help enforce data consistency (Rouse 2006). In the process
of developing relational database schema for a scenario, the entities to be represented
in the database are identified first. Then, the parameters of these entities are
recognised and finally the relations among them, so that there is no duplication of data
and any information about any entity is linked and can be traced. Such a paradigm
allows for naturally enforcing constraints. This system was proposed in the 70s by
E.F. Codd (Codd 1982, pp.109-117). Relational Database is implemented via tables,
columns, rows, primary keys, and foreign keys. In other words, tables represent
entities (e.g. products, customers), columns represent parameters about the entities
(e.g. product name, manufacturing date, volume). The rows represent one particular
 <Your Name> <Your Student Number> 2017 6 of 22

instance of the entity (e.g. all the details of a single person), a primary key uniquely
identifies each row in a table (e.g. social security number), and foreign keys map one
row to another to implement relations.
The key point to note from the preceding discussion is the foundation of the paradigm
is relations, and indeed the relational database management system (RDBMS) are
based on mathematical theories (Duffy 2011). Thus these systems are good at
enforcing data consistency, both at the individual column level and in between tables.
However, such systems are traditionally centralised, and this has both advantages and
disadvantages. Till a few years, the centralised system was serving The Wine Cellar
well, but the geographical distribution of the sources of data to different outlets call
for another solution. By centralisation, we mean that the entire database system - the
software to manage the data, the computer hardware, and the data are located on a
single machine in a single location. This type of a concentrated architecture has some
advantages and disadvantages. As we will see in a moment, the centralised systems
serve the outlets of The Wine Cellar well but fail when it comes to company-wide
manoeuvring.
The current scenario of the company is that the outlets manage their data in a
centralised relational database system e.g. inventory, sales, tax, customer details and
other data. This centralisation serves them well as a centralised system has the
advantages of being faster, cheaper, and being easier to manage. However, this makes
interaction, specifically programmatic interaction with the head office a difficult
thing. The senior staff at the head office would be interested in knowing the up-to-
minute performance of their various branches and make strategic and tactical
decisions accordingly. However, as confirmed in the briefing for this paper, the
outlets submit a file each week which has to be manually analysed and results
compiled for the perusal of the senior staff. This process is cumbersome, slow and
prone to errors. In a nutshell, the centralisation of traditional relational database
systems and the consequent inability to allow access to multiple (physically separated)
parties is a limitation in the context of The Wine Cellar's growth. This situation is a
 <Your Name> <Your Student Number> 2017 7 of 22

typical one in that the databases end up becoming islands of information with even
one department's system not being able to talk to another department (Martin n.d.).
Data Warehouse and Their Support in Decision-Making
We will now explore two types of database systems - OLTP (Online Transaction
Processing) and OLAP (Online Analytical Processing). Imagine a lake in which water
flows into from different streams. After a while of the streams pouring their water into
the lake, the lake begins to fill and will soon overflow. However, before that happens,
the deeper water is taken out and placed in a separate well which has been designed to
preserve this water. Now, in this comparison, the streams are the routine transactions
that are taking place regularly e.g. thousands of bank transactions take place in a
banking system every minute. The lake is the transactional database that handles the
operations and is a reflection of the current state of the organisation (OLTP database).
The movement of old data into a system which is specifically made for maintaining
archives is the OLAP database. OLTP is also referred to as operational data stores.
OLAP is also referred to as a data warehouse. A transactional database by its very
nature does not make itself amenable to analytics (Cardon n.d.) and thus is born the
need for OLAP systems. It must be emphasised that OLTP is not suitable for business
intelligence or analytics (Why Business Intelligence on OLTP is evil n.d.).
Technically, the OLTP has different goals that OLAP. OLTP is designed to support
the running of the organisation and performance is the main criteria. Its main focus is
on updates, which are short but multiple and are triggered by end-users. The queries
are standardised and few in variety. Here, the data consistency is paramount, and
usually high normalisation of data is maintained to enforce consistency and integrity
of data. OLTP is the storehouse of the original data. In contrast, OLAP is an archive
of historical data i.e. transactions that have taken place and are not likely to edited
further. Its focus is on retrieval (OLAP vs OLTP: what makes the difference n.d.).
Also, this consolidated data of OLAP comes from multiple places, and this
multiplicity of the sources often dictates that a separate step be executed (a staging
area) where the data is treated, and the format is modified before being saved in the
 <Your Name> <Your Student Number> 2017 8 of 22

OLAP database. This operation is often referred to as ETL (Extract, Transform,
Load). Since OLAP deals with historical data (which is not expected to change), the
priority of the system and the scope of its service is poles apart from the transactional
one. The priority of an OLAP system is supporting complex and non-typical queries
in an ad-hoc manner, some of which are often long running. Many common and long-
running queries are executed in advance to precompute the reports that may be later
requested. Its scope is to help with planning, problem-solving and supporting
decision-making. Another aspect of OLAP is that data normalisation is dropped in
favour of data redundancy and simpler associations so that complex queries can be
executed faster.
Now, an OLAP or a data warehouse is characterised by being subject-oriented to a
particular metric (e.g. sales), integrated (using multiple sources of data), non-volatile
(data once entered into warehouse is not likely to be changed or deleted), and time
variant (being able to analyze how a metric has changed over time e.g. months or
years) (Lane and Schupmann 2002). This availability of an ocean of data which is
disjoint from the transactional data, coupled with specialised tools, allows managers
to look into the past and ask questions to mine data, extract trends, see how metrics
are moving up or down, and then decide what is in the best interests of their
organisation. Such an arrangement also eases the database managers' responsibilities.
Issues in Designing and Implementing a Data Warehouse
As detailed in the previous section, a data warehouse is an ideal system to help
management look into the past and come up with answers to questions like the change
in a metric over time, hidden trends and other data mining questions. Still, the process
of establishing and maintaining a data warehouse is non-trivial. In this section, we
will talk about the challenges encountered in the implementation of a data warehouse.
One issue is of the data quality. In a data warehouse, the source of data are multiple
and not directly the end-users. Also, to help meet a data warehouse's goal of
uncovering significant trends, we cannot skip on data sources. Now, whenever
different sources are merged, errors happen in data due to the different format, the
 <Your Name> <Your Student Number> 2017 9 of 22

level of quality, logic conflicts, missing data (Wentzlaff 2014). The reasons for the
low quality of data at the sources include incorrect information entered in the primary
source, incomplete knowledge of interdependencies among the data sources, inability
to cope with the ageing data, varying timelines of the data sources, and others (Pandey
2014, pp.18-24). Some practitioners suggest that not all low-quality data needs to be
cleaned. Sometimes, acknowledging the bounds of clean data is prudent (McKnight
2007). Another concern is the model to be chosen for the data warehouse. As pointed
out earlier, since the goals of the transactional database and a warehouse are poles
apart, therefore the underlying structure cannot be same. Thus the data models for
transactional are not suited for warehousing environments (Becker 2002, pp.22-76). A
multidimensional data model (MDDM) storing data as facts and dimensions as
opposed to rows and columns of a relational database are more suited to handle the
scope of a data warehouse - ad-hoc and complex queries joining a great many
numbers of entities. The schemas common are star schema and snowflake schema
(Nepomnjashiy 2001). Then, there are some implementation issues which need to be
sorted out, like the amount of data that will be shipped around the network and the
network's capability to cope with it, the amount of disk space required, and its speed.
Also, expenses need to be tailored to the goals in a decision like solid-state drives
(SSDs) or traditional hard disk drives (Whitehorn 2011).
Data Structure Model for The Wine Cellar Scenario
In this section, we will walk through the process of creating a data structure model for
the company. Initially, we will identify the entities involved. Then, we will determine
their parameters. After that, relations among them will be finalised. The company is a
business engaged in selling products. It buys products from sellers and sells them
using its outlets. We will be concentrating on these aspects of the firm. A real
business has many other nuances like the costs and management of shipping the goods
to the outlets, salaries, taxes, etc. We will focus on the problem of report generation
for the management. The company deals in products, which are of different types, and
are sold in the outlets of the company throughout the country. The emphasised words
give us an idea of the entities identified. All of these will form their table. Also, each
 <Your Name> <Your Student Number> 2017 10 of 22

table will have its primary key. A table consisting of the types of products sold will be
created e.g. red wine, white wine, beer, etc. It will have an ID for the kind of product.
An outlets table will be housing the details of all the outlets of the company. A
products table will be using this ID to identify the product that has been sold. There
will be a sales table which will be inserted to whenever there is a new sale is made in
any outlet. If the data is synchronised and is common among all the outlets (which is
an essential characteristic of any database system and will be explored later in the
paper), then the head office should have no difficulty in querying the database
howsoever it wishes and getting the results it wants within moments. This newly
proposed system would be dramatically better than the current situation where files
are manually being sent to the head office once a week, and then those files are
analysed, and a report is amalgamated.
The above figure (Fig. 1) shows the database structure for the narrow scope of the
problem being handled in this paper. PK stands for the primary key. It has not been
depicted in the figure above, but the databases are related to each other. "Product type
ID" of "Product Types" table is related to Products. "Sales" table is related to both the
"Products ID" and the "Outlet ID". It may be noticed that in the structure proposed,
there is no duplication of data. Additionally, any detail about any entity can be
queried.
 <Your Name> <Your Student Number> 2017 11 of 22
Fig 1.Database model for a the sales management

Task 2
Distributed Databases and Potential Issues Before Final Design Decisions
A distributed database is in contrast to a centralised database. A database which is
implemented across multiple computers, which may be spread apart geographically is
a distributed database system. Such systems are connected by a network (e.g.
Internet). Depending upon the underlying hardware and software, there are two types
of distributed systems - homogeneous and heterogeneous. Before we move further, it
is relevant to bear in mind that for the user, this distribution is transparent. For a
distributed database, this location transparency exists for the database administrators
also. As an example, consider email service by Google, Gmail. A Gmail user does not
know where in the world and on which servers his emails are being stored and
processed. We note that the data itself, as well as the processing required to serve a
query, may be spread across the multiple systems (which may even be in different
continents or across oceans) which are part of the distributed database. The sites
which make up a distributed database do not share any physical components and run
independently of each other. Some authors believe that the distribution of the
processing load among multiple computers may improve an end user's performance.
A homogenous distributed database system is one in which all participating sites have
the same software, are aware of each other and share the workload of processing user
requests. All of them agree that they will not change the schema or software without a
consensus. In contrast, in a heterogeneous distributed database system, the
participating sites have the freedom to use different software. They are also free to use
different schemas for the databases. As expected, such a difference gives rise to
technical challenges. Also, the sites may not be aware of each other and may
cooperate in a limited way only. Now, this distribution of data among the underlying
worker machines introduces the problems of data consistency and accuracy in the face
of physically separate computers which are possibly running different software and
schemas.
 <Your Name> <Your Student Number> 2017 12 of 22

As is evident from the discussion, maintaining data consistency among the different
sites is a technical challenge. Techniques have been devised to ensure this and include
replication, fragmentation, or a combination of both. Replication is creating an exact
copy of the database at the various sites. Fragmentation is partitioning the database so
that separate parts of the database are kept in separate sites. Fragmentation may be
horizontal (row-wise) or vertical (column-wise). Retrieving a complete record is then
a matter of querying the database sites concerned, compiling the results and
presenting to the user.
Distributed systems offer advantages, and they are more suited to certain scenarios.
Distributed systems mimic the organisational units as well as the physical separation
of the various branches of an organisation. Such sites also need to share data among
themselves. As in the case of The Wine Cellar, the company after experiencing
growth is facing delays and inefficiencies in retrieving data from the different outlets
because of the centralised nature of traditional database systems. Distributed systems
provide the hope of being able to remedy this. Furthermore, such databases support
transactional as well as data warehouse technologies. Such a database system is more
resilient to software/hardware failures as the number of locations where the data in
preserved is multiple, thereby eliminating any single point of failure. Additionally, the
data quality constraints of ACID (Atomicity, Consistency, Isolation, Durability) can
be preserved, though this requires technical prowess (Erb 2012).
However, distributed databases are a non-trivial endeavour, and there are some issues.
It would be beneficial if The Wine Cellar could work out some issues before
finalising the design for a distributed database. These systems are complex and extra
effort must be expended along with specialised skills to establish and maintain. The
company needs to decide if this is something it is willing to commit to right now or in
the future. Since a significant amount of data, which is proprietary will be moving
through the network, expenses must be incurred in bandwidth as well as securing the
line of communication (e.g. Virtual Private Network (VPN) over the Internet).
Technical problems would be the domain of professional database and network
managers. The company need to commit itself to the ongoing expenses and the
 <Your Name> <Your Student Number> 2017 13 of 22

arrangement of necessary skills to manage the new IT system. This fulfilment of the
skills may be in the form of new hires or upgrading the skills of the existing staff.
Relevance of Distributed Database for The Wine Cellar Organization and
Costs/Benefits
We opened this paper with a discussion of a centralised database system and what are
its advantages and disadvantages. As far as The Wine Cellar is concerned, if it had a
single branch, then the centralised database would have sufficed well. We are here to
help the organisation manage its growth. The company now has many outlets and
would understandably want to keep tabs on each and every outlet, not only for
monitoring purposes but also to uncover trends to help make strategic decisions. It is
our recommendation that distributed databases be considered for the new scenario of
the company. The relevance and costs/benefits of such a recommendation are detailed
next.
The company has grown from a single site to multiple sites which are located
throughout England. The IT staff that was mobilised initially was keeping in mind the
single-site nature of the business. Now, new branches have been opened, and each of
them has their local data to maintain, besides keeping the head office in the loop.
Currently, a workaround with weekly updates of files, and then a later manual
analysis has been put in place. This is labour-intensive and prone to errors. We find
that a distributed database would be better suited to handle the new scenario as well as
help the company in its growth by scaling when the number of branches and the
workload grows further. A distributed database system will provide the company
access to the latest activity and status of all data of every outlet. The benefit for the
head office is that they can run queries at any time of the day to find the information
they need. Also, the manual movement of files will be done away with and the staff
thus occupied can be used for other tasks. Authorisation controls can be put in place
so that the outlets cannot access the head-office data or one another's data, while the
head-office has free access to all data. As detailed earlier, technical challenges are the
domains of experts and those skills will have to arranged and paid for. Also, ongoing
 <Your Name> <Your Student Number> 2017 14 of 22

costs will be introduced for the maintenance of the underlying infrastructure. In the
present-day business, information is power, and any delay in actionable information
can hurt business goals. It is our recommendation that company approve the expenses
for a distributed database system. The next section will detail our recommendations
for the implementation, along with justifications.
Recommendation of Type of Distributed Database and Justifications
The preceding discussions detail distributed databases, and we claim that it would be
a good fit for the company's current and future scenario. We recommend a relational
architecture which is fully replicated with no fragmentation. It is our belief that
multiple copies of the complete database will help tide against any software/hardware
failures at any of the sites. A homogenous solution is recommended. Since all the
branches are under a single organisation, maintaining equipment and software would
be simple. The resulting advantage would be the ease of technical management. Also,
we do not see terabytes of data and thus recommend keeping the implementation and
the maintenance simple by skipping fragmentation at all. Since this will be a new
initiative for the IT team, it is suggested to break into this domain gradually as live
data (and thus the business) is at stake.
Task 3
How Relational Databases Support Object Oriented Development?
Object-oriented development is a paradigm for developing software. The goal is to do
away with procedures and mimic the real world more closely. As an illustration,
consider a dog which is an extension of a mammal. We can see the properties of
inheritance at play here in that mammals give birth to young ones and so do dogs.
Also, properties and behaviours are encapsulated into a single instance e.g. a dog has
four legs, colour of coat, etc. as its properties, and it can walk, run, bark, etc as its
behaviours. Object-oriented design has proved its worth and is the primary way of
developing commercial software of all sizes.
 <Your Name> <Your Student Number> 2017 15 of 22

Relational databases manage information about the world by identifying the entities
and assigning separate tables for each of them. A relational database system is based
on mathematics and every operation possible in the relational database system has an
equivalent. For example, SELECT is equivalent to the union in set theory. This
relational algebra is has a solid mathematical background, is high-level, simple,
powerful, expressive, non-procedural and data-independent. Such a system is ideal for
optimising.
The thing to note is that simple object-oriented databases, as well as a hybrid object-
relational databases also exist. However, the tremendous amount of investment in the
purely relational database paradigm ensured that it was never completely replaced.
Also, both these technologies followed a similar timeline of growth and many features
of object oriented design had been incorporated into the relational database designing.
However, there is an "impedance mismatch", which is to used to classify the
difficulties encountered when a relational database is accessed using an object-
oriented programming language software.
Relational Databases Relevance for Multimedia Requirements in The Wine Cellar
Scenario
Multimedia is the use of multiple media, notably other than text. Multimedia includes
images, audio, and videos (Multimedia Database 2016). It must be noted that in
general, the handling of text and other media is very different. Often specialised
databases, referred to as MultiMedia Database Management Systems (MM-DBMS)
are utilised for a full-fledged multimedia usage. Such a system manages many
different details about the media including media data (the actual data e.g. mp3 file),
media format data, media keyword data, media feature data. Except for the main data
file, all the others are metadata. Multimedia Databases have certain characteristics
which dictate that a different handling be done while designing them. These include
enormous data size, complexity of representation, and others (Multimedia Database
2016). The huge size of MMDBs, temporal nature, richness of content, complexity of
representation and subjective interpretation (Raj n.d.) make multimedia databases a
 <Your Name> <Your Student Number> 2017 16 of 22

unique technical challenge. To be able to provide a suitable environment a MM
DBMS must support the media in addition to the standard DBMS functions (Adjeroh
and Nwosu 1997, pp.24-33). Relational databases are not very capable of handling the
multimedia requirements. One of the reasons is the that BLOB (Binary Large Object)
data type is blind to the data it contains. It cannot make sense of the contents, thus
being unable to support convenient searches based on content (Multimedia Database
2016). Having noted the less than ideal applicability of relational databases, we note
that for the scenario at hand - showing short video, BLOBs of relational database will
work fine. We propose a separate a new column with the BLOB data type in Products
table. Whenever is video is to be showcased for a particular product, the data can be
fetched and played in the web browser.
Conclusion
The Wine Cellar is a (fictitious) company which is based in England and sells wines
and accessories which are sourced from sellers all over the world. For the purpose of
this paper, a new requirement which has emerged after the company's success in the
last few years is considered. The growth of The Wine Cellar has seen the company
open up new branches in various parts of the country. Earlier, the company might
have sufficed with a single branch and thus a centralised database system. The
centralised database systems which may be operational and functioning satisfactorily
in the outlets of the company fail when a company-wide report has to be generated.
The current workaround is the outlets sending files to head-office once a week. At the
head office, the reports from various branches are analysed, and a combined report is
prepared. Such a process is labour-intensive and prone to errors. This paper provides
an alternative in the form of distributed databases. The paper is divided into three
sections and approach the knowledge of databases that may be relevant for the
company brass to make decisions about the proposed database systems. Relational
databases are introduced, along with their limitations in their centralised form. Data
warehouses and transactional databases are introduced and compared. Also, a simple
data structure for the problem being discussed is presented. Later on, a distributed
database is introduced along with some of its technical characteristics. Some issues
 <Your Name> <Your Student Number> 2017 17 of 22

found in the implementation of a distributed database are presented. It is advised that
the company reach a decision on these before final design decisions are made. Next, a
cost/benefit analysis is done about the distributed systems. Some reasons as to why
this is a recommendation for the requirement of the company are presented. Finally,
for this section, a particular type of distributed database is provided along with
justifications. Later on, object orientation is tackled, and details are provided how a
relational database can be used to support the object oriented programming concepts.
The paper does not delve into object oriented databases per se but focuses on how
relational databases may be used to implement the likes of an object-orientation. Since
the company also wants to promote selected products via a website, using relational
databases for multimedia has been explored. The paper thus intends to provide
actionable recommendations along with theoretical know how to understand the
databases and allow non-technical people to interact with specialists and the IT team.
 <Your Name> <Your Student Number> 2017 18 of 22

References
Adjeroh, D. and Nwosu, K., 1997. Multimedia database management-
requirements and issues. IEEE Multimedia, [online] 4 (3), 24-33. Available
from: http://citeseerx.ist.psu.edu/viewdoc/download?
doi=10.1.1.353.5639&rep=rep1&type=pdf [Accessed 15 Mar. 2017].
Anon, 2012. Data Warehouses. 1st ed. Resource Development International
Ltd.
Anon, 2016. Multimedia Database. [online] Tech-faq.com. Available from:
http://www.tech-faq.com/multimedia-database.html [Accessed 15 Mar.
2017].
Anon, n.d. OLAP vs OLTP: what makes the difference. [online]
Cbsolution.net. Available from:
http://www.cbsolution.net/ontarget/olap_vs_oltp_what_makes [Accessed 15
Mar. 2017].
Anon, n.d. Why Business Intelligence on OLTP is evil. [online] Cbsolution.net.
Available from:
http://www.cbsolution.net/ontarget/why_business_intelligence_on_oltp
[Accessed 15 Mar. 2017].
Becker, S., 2002. Data warehousing and Web engineering. 1st ed. Hershey,
Pa. [u.a.]: IRM Press, pp.22-76.
Cardon, D., n.d. Database vs. Data Warehouse: A Comparative Review.
[online] Health Catalyst. Available from:
https://www.healthcatalyst.com/database-vs-data-warehouse-a-comparative-
review [Accessed 15 Mar. 2017].
Codd, E., 1982. Relational database: a practical foundation for productivity.
Communications of the ACM, [online] 25 (2), 109-117. Available from:
 <Your Name> <Your Student Number> 2017 19 of 22

https://pdfs.semanticscholar.org/dbdc/1bf899872c55734d9843dc3e8e2d808
560a6.pdf [Accessed 15 Mar. 2017].
Duffy, M., 2011. What is the difference between a Relational and Non-
Relational Database?. [online] Stackoverflow.com. Available from:
http://stackoverflow.com/a/4811779/ [Accessed 15 Mar. 2017].
Erb, B., 2012. 6.1 The Challenge of Distributed Database Systems. [online]
Berb.github.io. Available from:
http://berb.github.io/diploma-thesis/original/061_challenge.html#acid
[Accessed 15 Mar. 2017].
Gupta, G., 2011. Database Management System. 1st ed. Tata McGraw-Hill
Education, p.5.
Jones, S., 2016. How data analytics can give you a competitive advantage.
[online] Businessrevieweurope.eu. Available from:
http://www.businessrevieweurope.eu/technology/681/How-data-analytics-
can-give-you-a-competitive-advantage [Accessed 15 Mar. 2017].
Lane, P. and Schupmann, V., 2002. Data Warehousing Concepts. [online]
Docs.oracle.com. Available from:
https://docs.oracle.com/cd/B10500_01/server.920/a96520/concept.htm
[Accessed 15 Mar. 2017].
Martin, A., n.d. Disadvantages of a Relational Database | Techwalla.com.
[online] Techwalla. Available from:
https://www.techwalla.com/articles/disadvantages-of-a-relational-database
[Accessed 15 Mar. 2017].
McKnight, W., 2007. Data cleansing: The business impact of dirty data.
[online] SearchDataManagement. Available from:
http://searchdatamanagement.techtarget.com/answer/Data-cleansing-The-
business-impact-of-dirty-data [Accessed 15 Mar. 2017].
 <Your Name> <Your Student Number> 2017 20 of 22

Nepomnjashiy, A., 2001. OLAP and Data Warehousing (The Problem and
Solution) — DatabaseJournal.com. [online] Databasejournal.com. Available
from: http://www.databasejournal.com/sqletc/article.php/1457031/OLAP-
and-Data-Warehousing-The-Problem-and-Solution.htm [Accessed 15 Mar.
2017].
Pandey, R., 2014. Data Quality in Data warehouse: problems and solution.
IOSR Journal of Computer Engineering, [online] 16 (1), 18-24. Available
from: http://www.iosrjournals.org/iosr-jce/papers/Vol16-issue1/Version-4/
D016141824.pdf [Accessed 15 Mar. 2017].
Raj, P., n.d. Multimedia Database. [online] Peterindia.net. Available from:
https://www.peterindia.net/MultimediaDatabase.html [Accessed 15 Mar.
2017].
Rouse, M., 2006. What is relational database? - Definition from WhatIs.com.
[online] Searchsqlserver.techtarget.com. Available from:
http://searchsqlserver.techtarget.com/definition/relational-database
[Accessed 15 Mar. 2017].
Toonders, J., 2014. Data Is the New Oil of the Digital Economy. [online]
WIRED. Available from: https://www.wired.com/insights/2014/07/data-
new-oil-digital-economy/ [Accessed 13 Mar. 2017].
Ward, P. and Dafoulas, G., 2006. Database management systems. 1st ed.
London: Thomson, p.2.
Wentzlaff, A., 2014. 7 Challenges in Building a Data Warehouse -
OnApproach. [online] OnApproach. Available from:
http://www.onapproach.com/7-challenges-consider-building-data-
warehouse/ [Accessed 15 Mar. 2017].
Whitehorn, M., 2011. Key issues to consider when building a data warehouse.
[online] SearchDataManagement. Available from:
 <Your Name> <Your Student Number> 2017 21 of 22

http://searchdatamanagement.techtarget.com/answer/Key-issues-to-
consider-when-building-a-data-warehouse [Accessed 15 Mar. 2017].
 <Your Name> <Your Student Number> 2017 22 of 22