DailyPips
Blogger
Share this content

How to build a database from scratch

18th Sep 2020
DailyPips
Blogger
Share this content

Are you looking to build a database?   Do you have any technical experience?

Building an online database can be both interesting and daunting. It is something that requires a certain level of skills and expertise.However, the DIY data revolution has made things relatively more straightforward. Hence, there is no need for technical experience for building an online database.

We have developed a step by step guide on building a database by yourself without technical experience and coding skills.

Let’s cut to the chase:

A Guide on Building a Database by Yourself without Technical Experience

Building an online database is simple and easy. You do not need any knowledge of coding or technical experience to get started.

The golden rule of building a database is to ensure accuracy and completeness is good. Besides that, it helps to prevent duplicate information from occurring.

So, can you design a database without technical experience? Yes. But you will be required to know the purpose of your database.

Here are steps on how to design a database by yourself:

Determine the Database Purpose

Always have the habit of writing down the purpose of the database on a piece of paper. The information will help you consider the database in every perspective during the design process.

For instance, if you were making a customer database, you would want to consider a list of customer information to produce reports and emails.

The idea will help to have a well-developed mission statement for offering guidance when making crucial decisions.

Finding and Organizing Information

Start by gathering any existing information that will be included in the database. Organize the type of data you want to store.

For instance, keeping the customer list on the index card will show the customer name, address, city, state, zip code, and email address. Keep each item on a potential column in a table.

Also, consider the type of report you might want to produce from the database. For example, a product sale report will show product name, price, quantity in stock, and quantity on order.

After gathering and organizing all this information, you are ready for the next step.

Divide the Information into Tables

Here you need to divide the information items into major entities. Each entity should display the product, supplier, customer, and orders.

For example:

Customer

  • · Customer name
  • · Address
  • · City, State, Zip
  • · Email Address

Supplier

  • · Company name
  • · Contact name
  • · Address
  • · City, State. Zip

Product

  • · Product name
  • · Price
  • · Units in stock
  • · Units on order

Ensure each row in the table has information about the product and supplier. We recommend recording the supplier information in a different table and then link the tables. It helps avoid wastage of disk since supplier information will be repeated several times.

Turning Information Items into Columns

The number of columns in a table will be determined by the information that is supposed to be tracked. Example of a customer table: name, address, city-state-zip, email address, and salutation.

Refine the columns to ensure they produce more accurate and organized information. Also, decide whether the database will hold the information for the customer for future use.

Specify Primary Keys

Choose the primary key for each table. The primary key is a unique column that helps to identify each row based on product ID or order ID.

Ensure the primary key has a value that will not change. It is used as a reference in a database that uses several tables.

Creating the Tables Relationship

You can now divide the information into a separate and subject-based table. Then use the table relationship to bring together as needed.

You can opt for one-to-one relationships, one to many relationships, or many to many relationships. This is one of the ways to bring information together in a meaningful way.

After compiling the information properly by creating a table relationship, then move to the next step.

Refine your Design

Ensure the product table shows the category of products such as beverages, seafood, and condiments. This will help to prevent product sales from falling under the same general category.

Make categories a new subject for the database to track its table and primary key. Then add the primary access from the category table to the product table as a foreign key.

Here the category will have more than one product, but the product can only belong to one category. It implies that categories and products have too many relationships.

Apply the Normalization Rules

Our last entry on the list is the application of data normalization rules. These rules help to ensure the tables have been structured correctly.

They are normalizing the database to help arrive at the preliminary design. However, the rules cannot be used to ensure you have captured the correct data.

Here are the norms to apply in the rule of succession:

First Norm Form

It states that every column and row intersection should have a single value. It should never contain a list of values.

Second Norm Form

It states that the non-key column should be entirely dependent on the entire primary key. However, this is applicable where the primary key has more than one column.

For example:

  • · Order ID (primary key)
  • · Product ID (primary key)
  • · Product Name

Here the product name is dependent on product ID and not on order ID. Hence, it is not reliant on the entire primary key. The type of design violet the second norm, and it is advisable to remove the product name from the table.

Third Norm Form

It states that every non-key column should be not only dependent on the primary key but also independent of each other.

For instance, a table containing the following columns

  • · Product ID (primary key)
  • · Name
  • · SRP
  • · Discount

If the discount depends on SRP, then it violates the third norm. This is because both the discount and SRP are non-key columns.

We recommend moving a discount to another table that is keyed to SRP. It will help to create column independence among the non-key columns.

 

 

Replies (0)

Please login or register to join the discussion.

There are currently no replies, be the first to post a reply.