University of Phoenix

It is my understanding that your company has grown to be quite successful as of late. Due to your organization’s success, you are now in need of a database that will help you manage your companies inventory. I think I can help with this; I’ll recommend three out of six database architecture types that I think will be the most promising for your organization.

Database Architecture Types

There are six database architecture types to choose from. They are as followed:

My top 3 recommended database architecture types are:

Your organization’s needs are very common, you require that the eCommerce, sales, manufacturing, and customer service departments all have access to the new database. In effort to remain efficient and flexible I highly recommended a cloud-based database.

My rationale for recommending each architecture type

Truth be told most data models may serve you well, but every organization is different and the type of data they collect and how they store and access it makes a difference. The three data models I’ve recommended just makes a lot of sense to best match your companies goals. The cloud-based solution is ideal to allow every department access and enable any user to easily build reports. The NoSQL system allows users to build reports using a graphical user interface, no programming skills needed.

The relational and distributed relational data models are more along the traditional lines of building a database. The perk with these models is that you may be able to import the structured data you’ve already collected in spreadsheets helping you build tables in your database quickly.

Characteristics that make each architecture a top recommendation

A cloud-based database is a type of Storage as a Service (SaaS) which falls into two basic categories: Data as a Service (DaaS) and Database as a Service (DBaaS). DaaS offers the ability to define data in the cloud and subsequently query that data on demand, it does not use implement typical DBMS interfaces such as SQL . Instead, it queries the data via a common set of APIs and requires NoSQL.

DBaaS offers full database functionality to application developers. In DBaaS, a management layer is responsible for the continuous monitoring and configuring of the database to achieve optimized scaling, high availability, multi-tenancy (that is, serving multiple client organizations), and effective resource allocation in the cloud, thereby sparing the developer from ongoing database administration tasks .

Currently, DBaaS and DaaS characteristics make this architecture a top recommendation as it is preferred within the industry. Like any other database architecture types, there are a number of architectural disadvantages associated with DBaaS such as separate and shared servers. Those good part in having a separate server architecture is that your database is hosted on a server machine separately, this might be appropriate for your organization but does increase the costs of maintaining the equipment and backing up your data. The shared server is more cost-effective but you are sharing the server machine with several other tenants which may cause issues with memory and disk resources.

My second recommendation is the Relational database model which was first proposed by Edgar Codd in 1970 . The Relational data model is based on the concept of mathematical relations. In this model data and relationships to that data are represented as tables, each of which has a number of columns with unique names. This may closely match your current spreadsheet information which could speed up the process of building the tables within the database.

Depending on the type of management system you plan to use the application will have to follow a standardized set of rules to provide substantial grounds for dealing with data semantics, consistency and redundancy problems. In general, data can not be stored in the database unless it is considered “structured data”, this is something that must be checked before moving forward with this model.

Using relational databases can have it’s advantages since they are based on relational set theory. Normalization is a vital component of the relational model of databases. Relational operations, supported by relational databases work best with normalized tables. They also support an important concept of dynamic views . In this data model, a view is not a part of the physical schema, it is dynamic. Hence changing the data in a table alters the data depicted by the view. A disadvantage is that pulling data from the database may not be as easy, you’ll need someone who can program using a structured query language (SQL) to build ad-hoc reports for departments to review and analyze.

My third and final suggestion was the Distributed Relational data model, which works in the same way as the Relation data model mentioned previously. The distinct change to the model is that it introduces fragmentation, allocation, and replication. Fragmentation is a relation that may be divided into a number of sub relations which then are distributed. With allocation, each fragment is stored at the site with optimal distribution, and replication allows for the DDBMS to maintain a copy of a fragment at several different sites which helps you stay connected to your data even when a data node fails.

Reasons for not recommending the other data models

As I’ve mentioned earlier the other data models are not inline with your organization’s goals of maintaining an inventory database. While they are capable of storing the data you want or may function with the data management system of your choice; they just didn’t have the same perks as the ones I’ve recommended. Database design is a complex but necessary process. You want to ensure that it will be functional and the system will be reliable when managing all of the organization’s valuable information.