Online Bookshop Project (Part 2)

Introduction

In the previous post, I went over the process of analysis for the project I had been tasked with, by going over the data flow diagram that I constructed to visualize the comprehensive view of the system's architecture. With the overall understanding of what the system consist of under our belt, we will move on to the next step of the analysis phase, by focusing on the database design to fully accommodate our needs for storing various data in an efficient, standardized manner. Storing data is the single most important aspect of the system, and for that simple reason, it is very imperative not to neglect getting things right. The proper design of the system results in various upsides, such as the elimination of data redundancy, high efficiency in queries, thus improving the performance of the system. In order to kick-start the process of the DB design, we will go over the E-R diagram for the system.

E-R Diagram

An E-R diagram is a tool that provides a template you can use for designing the DB of the system. It allows you to visualize the overall looks of the system by picturing various "things" that we need for the system, and drawing the relationships between those "things". There are three main components that comprise an E-R diagram: Entity, Attributes, and Relationships. An entity in a diagram represents something in real life that is either tangible or intangible. When we talk about something tangible, some of its examples would be Human, Bike, Car, etc. When it comes to the intangibles, the examples are Order, Review, Roles. Those are something that can neither be touched nor seen, while all we can do is to sort of picture how they may seem in our brain. In order to identify entities necessary for the system, we have to focus on what the system is all about. For example, since the system I am working on is the e-commerce website for books, you can easily infer that I need to store the data related to books. And also, in order to keep track of the orders made by each customer, you can easily infer that I need an entity for both customers and orders they make. Every entity we identify will always be mapped to one of the tables of the database, and used to store various data related to it. Each entity has a distinct set of attributes that uniquely represent the relevant aspects of itself for the system to operate seamlessly. It is our job to fully identify and specify the types of data we are trying to store in relation to each entity. To establish a relationship between two or more objects, you simply draw a line that connects one to another, and specify further by defining associations and dependencies that occur between objects. For example, each customer in the system may have one or more orders at any given moment. And each order may be associated with one or more books, and each book may be associated with one or more orders, which makes it a "Many-to-Many Relationship." Each element in an E-R diagram serves to enhance the understanding of how the system should operate and how it may be improved by spotting the glaring problems that we may identify from each iteration of a diagram. With that being said, let's look at the E-R diagram I came up with.

As you can see, there are various entities that comprehensively represent the distinct part of the data of the system, and shares relationships with various entities. Let's briefly delve into the diagram by using a few key entities that the system will primarily deal with. The User entity represents a table for storing the data of users for the system. As you can see, I added various attributes, such as email, password, nickname, etc. to distinguish each user from another. Every email that a user provides for registration must be completely unique, as in, there should be no other users with the same email at the time of registration. Besides those attributes I already defined, there could be various attributes that I may add in the near future, depending on the needs arising from various circumstances, but what I already defined would suffice for now. There is a Book entity, which is not directly related to the User entity, but they are kind of intertwined with each other based on the Order entity. Just with the User entity, the Book entity is adequately structured for the system as of now, and it shares relationships with various entities in a way that aligns with the concept of normalization. The Order entity basically gives away the type of data it stores, but they are directly related to both the User and Book entity. It directly stores the "id" attribute of the User entity, and indirectly stores a number of books via the Order_Books entity. There are other entities that greatly enhance the quality of the system, but the User, Book, Order are essentially the core that ultimately enable the system I envision.

With that being out of the way, I think it is about time to start designing and implementing the system, based on two previous artifacts. I could potentially take more time analyzing and identifying more needs for the system before I move on to the designing phase of the project, but since this is meant to be relatively simple, rather than too complex, I believe that those will suffice as the foundation for developing the project without too many issues. If anything, I can always go back and modify them or add a few artifacts to meet the needs that I may have yet to discover and resolve. For the next post, I will go over the basic design of the API endpoints that I came up with, prior to actually implementing them using JavaScript.