Database Administrator for Department Store

Database Administrator for Department Store

(Student Name)

(Professor Name)

(Course Title)

(Date)
 Database Administrator for Department Store

Following the successful expansion of the retail environment to several new stores there is a

clear need for an enterprise wide relational database especially with the envisaged increase in

sales as a result of current marketing activity.

There are several important steps to consider when designing a database, as a well-designed

database should be deployed and not only support the accuracy and integrity of business

information but also avoid redundant data and assist with enterprise level reporting tasks.

If we analyse the transactions carried out in each store we can produce a list of the principal

entities which are involved with a store based transaction:

 Customers – those who enter the store and buy the products

 Vendors – the companies who supply stock to the stores

 Products – the products themselves which are available in store for purchase

 Store – Location of the actual premises where the transaction takes place

 Employees – staff that work in each store and deal with the customers

 Sales – physical process of selling a product or product(s)

 Database Administrator for Department Store

These would make up the core entities of the database and each entity would have various

attributes with further relevant information which can be displayed in a hierarchical nature.

 Customers

o Customer #

o Name

o Address

o Phone Number

 Vendors

o Company ID

o Product

o Cost

o Contact Name

o Contact Address

o Contact Number

 Products

o Price

o Type

o Manufacturer

 Store

o Name

o Address
 Database Administrator for Department Store

 Employee

o Employee ID #

o Name

o Address

 Sales

o Products

o Date

o Customer

o Employee

o Store

These can be seen as the key attributes for each entity and provides the information required

from each transaction by capturing the essential essence of the business operations. At the

simplest level the organization, a store maintains various products stocks, is staffed by

various employees who service customers – assisting them with enquiries but ultimately

(hopefully) selling those products to these customers which is the main transaction we are

concerned with when it comes to designing the database.

Having worked out the required entities and attributes for the database the next step is to

determine the business rules which will be used concerning the sales transactions and their

storage in the database – these are similar to common business practices and how the

organization wishes to manage and organize their data but need to be quantified so that the

database can be designed accordingly.

 Database Administrator for Department Store

Before business rules are defined the information recorded would simply be a list of facts and

figures with no correlating relationships designed to assist in the reporting and visualization

of the data to allow proper analysis going forward.

In the proposed database design there should be several business rules:

Rule 1:

We have 6 stores that sell Products – this will translate into a field constraint in the database

where a designated code is assigned to each store location. Only these assigned codes will be

permitted as valid in this field.

Rule 2:

Each of our vendors must supply at least one product – even if there are discontinued or

legacy products/vendors then this would still hold true and be represented by a relationship

constraint within the database. This would be manifested whereby a single record in the

Vendors table would need to be related to at least one record in the Products table.

Having identified business rules that will underpin the database, the next step in designing the

database is to work out the relationship between each entity of which we identified:

Customers

Vendors

Products

Store

Employees
 Database Administrator for Department Store

Sales

Each entity will have a relationship with the others and this needs to be defined accurately for

the function of the database. At the highest level it is fairly easy to state that Sales happen in a

Store, Customers buy Products and Products are sold to Customers but this does not

accurately define the cardinality of each relationship which, shows the numeric quantity on

each side of the relationship. For example, how many sales take place in one store?

Following this procedure through we can arrive at a list which shows a detailed breakdown of

the relationships, and as we have 6 entities there should be a total of 30 relationships as each

entity will have a relationship with every other entity (5 each).

1. Customers  Sales: 1 customer can buy something several times

2. Sales  Customers: 1 sale is made per customer

3. Customers  Products: 1 customer can buy multiple products

4. Products Customers: 1 product can be purchased by multiple customers

5. Customers  Stores: 1 customer can purchase in multiple shops

6. Stores  Customers: 1 store can service multiple customers

7. Stores  Products: 1 store has multiple products

8. Products  Stores: 1 product can be sold in multiple stores

9. Stores  Sales: in 1 store multiple sales can be made

10. Sales  Stores: 1 sale can only be made in 1 store at the same time

11. Products  Sales: 1 product can be purchased in multiple sales

12. Sales  Products: 1 sale can be borne out of multiple products

13. Customers  Employees: 1 customer can be served by 1 employee

14. Employees  Customers: 1 employee can serve 1 customer

 Database Administrator for Department Store

15. Stores  Employees: 1 store can house multiple employees

16. Employees  Stores: 1 employee can work in multiple stores

17. Vendors  Customers: 1 vendor can be requested by multiple customers

18. Customers  Vendors: 1 customer can request multiple vendors

19. Products  Vendors: 1 product can be supplied by 1 vendor

20. Vendors  Products: 1 vendor can supply multiple products

21. Sales  Vendors: 1 sale can be from multiple vendors

22. Vendors  Sales: 1 vendor can supply multiple sales

23. Stores  Vendors: 1 store can stock multiple vendors

24. Vendors  Stores: 1 vendor can be stocked by multiple stores

25. Employees  Vendors: 1 employee can sell multiple vendors

26. Vendors  Employees: 1 vendor can be sold by multiple employees

27. Sales  Employees: 1 sale can be made by 1 employee

28. Employees  Sales: 1 employee can make 1 sale

29. Products  Employees: 1 product can be sold by multiple employess

30. Employees  Products: 1 employee can sell multiple products

As there are 30 relationships then we can conclude (based on 6 entities x 5 relationships) that

they have all been successfully captured and then the next step is to determine the cardinality

of each relationship and annotate this graphically so that each relationship is clearly defined.

Each relationship will take the form

1:1 One to One

1:N 1 to Many
 Database Administrator for Department Store

M:1 Many to 1

M:N Many to Many

These relationships are shown in the below diagram:

With the design of the database in place, it’s possible to envisage utilising the data in order to

provide added value to the organization – as each transaction is effectively logged it will

allow for the targeted use of information to retain our customers and also to increase our sales

volume.

Through analysing the database we will quickly be able to ascertain who our most profitable

customers are along with the frequency of their purchases so that any patterns can quickly be
 Database Administrator for Department Store

ascertained – similarly we can identify customers who have not purchased similar quantities

or indeed revisited our stores for similar products and then make contact with these customers

in order to find out the reasons why they are no longer utilising our stores – perhaps there was

a bad customer experience or compelling competing offers?

With the implementation of the database these avenues of discussion are presented to our

Sales & Marketing teams who will be able to make informed decisions about current

customer standings.

As the database will be logging transactions from each store then the size of the database will

quickly grow in size – while this is not a technical issue per se in respect of actual database

size and storage space it does mean that dealing with, and analysing large volumes of data

through the conventional database management tools becomes more difficult and necessitates

so called Big Data tools in order to successfully manipulate and extrapolate large quantities

of data, especially given the live nature of the database and the constantly updating stream of

information into each table.

To this end, Big Data Tools such as Jaspersoft’s BI Suite will allow the organization to

successfully retrieve the data from the various SQL tables and collate this in accordance with

the business requirements – rather than data being provided in numerical based CSV files or

SQL specific reports, tools such as this will allow the creation of PDF and graphical

representations of the data contained in the SQL database which will allow analysis and

response to be performed far quicker than conventional reporting methods.

 Database Administrator for Department Store

In addition to the comprehensive Big Data suite we can also use SQL Stored Procedures to

assist with the analysis of data – these will complete a series of SQL statements in order to

retrieve and display certain information.

For example, if promotional activity has been carried out in certain locations we can write a

stored procedure which will retrieve all customer records for this location, based on a

wildcard entry and then in turn view if they made any purchases or changed the

frequency/volume of purchases as a result of the commercial activity.

To do this, we would use the following SQL code:

CREATE PROCEDURE LocCheck @Address nvarchar 25)

AS

SELECT *

FROM [Link]

WHERE Address LIKE @Address + ‘%’

SELECT *

FROM [Link]

WHERE Customer = @Customer

GO

This will result in a Stored Procedure being available called LocCheck which could be run at

any time to report the results at the time of running via the below command:

EXEC LocCheck @Address = ‘ ‘

 Database Administrator for Department Store

Where the entry between quotes can be the desired location to search, and then the required

results will be returned. An alternative procedure could be used to return sales information

based on the transaction date and current date which could be beneficial in attempting to

identify any financial trends (e.g: month end/quarter end etc).

The command for this Stored Procedure would be as below:

CREATE PROCEDURE SalesDate

@BeginningDate DateTime.

@EndingDate DateTime

AS

SELECT

[Link]

[Link]

WHERE

[Link] BETWEEN @BeginningDate AND @EndingDate

GO

In exactly the same way as the previous stored procedure this could then be called via the

EXEC command in order for the information to be retrieved and displayed. Of these two

examples the most useful Stored Procedure in terms of business growth and expansion would

be the first example as this can be directly related to the planned and ongoing marketing and

promotional activities that are planned and be used as a method of ascertaining immediate
 Database Administrator for Department Store

feedback as to the value of such activity. Has customer presence and purchasing activity

increased since such activities were started – if so, has the increase in sales and return custom

been worth the value of the promotional activities or has the upturn in sales not been

sufficient to cover these costs? Such a quick way of retrieving and accessing the information

would be increasingly relevant as such plans are progressed.

Theoretically the proposed database will meet the requirements of the organization but there

are also technical concerns to be considered as well. As previously mentioned, due to the

number of stores and the frequency of transactions the size of the database will increase

rapidly and also require constant connectivity. While it would be possible to split the database

itself across multiple systems through a distributed DBMS structure where the combined

entities are presented as one database the scenario envisaged lends itself to a single database

configuration which will be optimised for High Availability, Scalability as well as being

backed up by Disaster Recovery mechanisms and best practices.

Utilizing the built in technologies of SQL server, we will setup a mirrored database with

failover clustering so that we not only have a backup of the database itself for Disaster

Recovery purposes but can also continue operations if the main database server ceases to

function or becomes unavailable for any reason. A further backup mechanism will involve

setting up a copy of the Backup Logs to designated networked machines along with regular

copies of the main database – by ensuring that the transaction logs are stored in this way it

further reduces the chances of data being lost due to system failures or security issues.

Due to the frequency of the transactions it is important to understand that there is always a

possibility of lost updates or data not being committed successfully to the database in such a

multi-user environment. Lost Updates occur when two or more transactions select the same
 Database Administrator for Department Store

row and then update the row based on the original value – being unaware of the other

transaction. This means the last update overwrites the previous update and that data is lost.

Similarly uncommitted data occurs when a second transaction selects a row that is being

updated by another transaction. The second transaction is reading data that has yet to be

committed to the database and may still be changed by the original transaction.

In order to alleviate these issues and ensure that transactions are executed correctly in this

environment then we can utilise the SQL Statement rowversion which will effectively version

stamp each table row to ensure that data is recorded accurately. In addition, the SQL JDBC

driver can be used to set the concurrency model as required – for example utilising the JDBC

driver to set the concurrency as

CONCUR_SS_SCROLL_LOCKS

Sets the database in a pessimistic read write model where it is assumed that row contention is

likely (probable in the event of a diverse, multi-user environment). As a result, row integrity

is maintained by locking each row during a transaction so it can only be updated once the

previous transaction has been completed and the row unlocked. There are varying models of

concurrency available via the JDBC driver and these could be adapted depending on the

business requirements.

These methods should address the technical concerns surrounding the database and the

successful capture of each transaction but there are also security threats to be considered. It

must be remembered that the database contains customer specific data as well as pricing and

employee data unique to the organization so the integrity of this information must be

protected.
 Database Administrator for Department Store

In addition to access control and permissions being applied across the database to ensure that

unauthorised access is prevented there are several other mechanisms that can be applied to

protect data in the retail environment. One of the easiest methods is to ensure that only

relevant data is retained – the less data that is stored then the less exposure there is to risk.

This needs to be borne in mind though with governmental and regulatory requirements as

well to ensure that the organization is able to respond to auditing requests as required.

A further mechanism to secure the database would be the use of Transparent Data Encryption

which results in a fully encrypted database but provides the same user experience as with an

unencrypted database – this also applies to subsequent backups of the database so care will be

needed to ensure that the relevant keys and authentication mechanisms are also safely stored.

Such a procedure will ensure that even with physical access to the database file it would not

be possible to view the data without the required encryption keys.

Having reviewed the various security issues and requirements in setting up such solutions it is

equally as necessary to investigate the various options regarding the deployment and

implementation of such solutions. Many of the major vendors offer Cloud-based services

such as:

 Microsoft – Azure SQL

 Amazon – Relational MySQL

 Salesforce – [Link]

 Google App Engine

Depending on the quantity of data and connectivity requirements then there are various costs

involved with vendors offering a choice of payment models – either on an annual or a pay as
 Database Administrator for Department Store

you go basis. For limited applications and low intensity usage there are even free versions

available from some vendors, Google among them. However, given the likely utilization of

an enterprise database which will require constant and intensive connectivity then the

consideration should be for a cloud based instance using several cores and gigabytes of RAM

in order to provide the required level of service. Below is a sample breakdown based on the

Microsoft Azure Model and based on 744 hours of utilization each month:

Name Virtual Cores RAM Price Per Hour

Extra Small – A0 Shared 768MB $0.02

Small – A1 1 1.75GB $0.08

Medium – A2 2 3.5GB $0.16

Large – A3 4 7GB $0.32

Extra Large – A4 8 14GB $0.64

A6 4 28GB $0.90

A7 8 56GB $1.80

While there is a general appreciation of cloud-based services there are various ways in which

this can be implemented. This can either be via Software as a Service, Platform as a Service

or Infrastructure as a Service.

Software as a Service refers to a delivery model whereby a particular software application

and all associated data would be hosted via a cloud-based facility which is then accessed

either through a web-based interface or a thin client that can be installed and configured on

local machines. This is perhaps the solution where an off-the-shelf solution is provided with

most of the configuration and implementation done by the vendor.

 Database Administrator for Department Store

Platform as a Service relates to a model whereby the vendor provides all the necessary

networking technologies, storage, servers and other resources but the customer then uses

these to develop and provide their own applications and services through the cloud-based

model. Essentially it allows an organization to deploy their own developed applications and

services without having to worry about the underlying hardware provisions and support.

Infrastructure as a Service completes the models whereby all resources and requirements that

are needed to sustain business operations are outsourced directly with all equipment and

resources being owned by the vendor – the client in this instance is simply charged on a

utilization basis dependent on the services that are required.

The approximate advantages and disadvantages can be summarized as below and while IaaS

offers perhaps the most competitive solution it is also the technology and model which would

require the biggest organizational ‘leap of faith’ in terms of handing over total ownership and

control of such systems.

Model Functionality Mobility Distributed Transaction Currency

SaaS Applications hosted via cloud Restricted, may require Latency and network speed can

connectivity from corporate largely be determined and monitored

locations in order to provide this

PaaS Development and Delivery As above As above

platform provided via cloud

IaaS Operational Systems provided Total – restriction of Connection latency and network

via cloud vendor physical location removed speed less controlled and may be

open to certain variables

 Database Administrator for Department Store

In order to provide data integrity each of the solutions would need to deliver secure

connectivity with https for example being used for any web based interface or client

connectivity and authentication being required.

With each model there are reasons which may or may not influence an organization to choose

a distributed DBMS structure. The traditional model for example, of a local server and

ownership and control of such a system has fared well but there are several areas where this

type of solution can be improved. One of the areas through which DBMS structures have

become more restrictive has been the growth in storage space required which in turn requires

additional backup capacity to be added to the overall solution.

In the example of the Department Store database outlined here, given the expansion to new

premises there is likely to be an exponential growth in customers, products and sales that will

require information space within the database.

As a result, it would be preferable to remove the burden for maintaining the database through

manual optimization procedures such as compacting as well as allocating additional storage

when required and co-ordinating backups to be held off-site in the event of a disaster

recovery solution.

A distributed DBMS which offers cloud-based storage and backup procedures would offer

the growing organization the flexibility to utilize their system in the most effective and

efficient way based on their organizational strategy.

Database Administrator for Department Store
 Database Administrator for Department Store

References
Carter, J. (n.d.). Database Design and Programming with Access, SQL, Visual Basic and ASP.

Churcher, C. (n.d.). Beginning Database Design .

Liu, L., & Ozsu, M. T. (n.d.). Encyclopedia of Database Systems. Springer.

O'Brien, M. C., & Winter, J. (n.d.). Developing Stored Procedures for Microsoft SQL Server.

Pratt, P. J., & Adamski, J. J. (n.d.). Concepts of Database Management.

Rob, P., & Coronel, C. (n.d.). Database Systems: Design, Implementation, and Management.