tools or a website to help with database normalization

Question

Are there any tools or online resources (FREX tutorials) that would help a neophyte with database normalization?

Answer 1

The best solution is that you should be able to fully understand how to normalize forms, for how long you will be dependent on any tools to do this for you? I would suggest you to study a bit about it so that you could come up with the best solution yourself. As a developer, you will face this every now and then, and what about an interview, let's suppose where you are asked about it? And as Mitch Wheat said, normalization should not require a tool :)

Here are some more resources to get you stared:

http://dev.mysql.com/tech-resources/articles/intro-to-normalization.html

Source: Mysql Website (Official)

Answer 2

An Introduction to Database Normalization

Wiki: Database normalization

Database Normalization Tips

Achieving a Well-Designed Database In relational-database design theory, normalization rules identify certain attributes that must be present or absent in a well-designed database. There are a few rules that can help you achieve a sound database design:

• A table should have an identifier. The fundamental rule of database design theory is that each table should have a unique row identifier, a column or set of columns used to distinguish any single record from every other record in the table. Each table should have an ID column, and no two records can share the same ID value. The column or columns serving as the unique row identifier for a table are the primary key of the table. In the AdventureWorks database, each table contains an identity column as the primary key column. For example, VendorID is primary key for the Purchasing.Vendor table.

• A table should store only data for a single type of entity. Trying to store too much information in a table can hinder the efficient and reliable management of the data in the table. In the AdventureWorks sample database, the sales order and customer information is stored in separate tables. Although you can have columns that contain information for both the sales order and the customer in a single table, this design leads to several problems. The customer information, name and address, must be added and stored redundantly for each sales order. This uses additional storage space in the database. If a customer address changes, the change must be made for each sales order. Also, if the last sales order for a customer is removed from the Sales.SalesOrderHeader table, the information for that customer is lost.

• A table should [try to] avoid nullable columns. Tables can have columns defined to allow for null values. A null value indicates that there is no value. Although it can be useful to allow for null values in isolated cases, you should use them sparingly. This is because they require special handling that increases the complexity of data operations. If you have a table with several nullable columns and several of the rows have null values in the columns, you should consider putting these columns in another table linked to the primary table. By storing the data in two separate tables, the primary table can be simple in design and still handle the occasional need for storing this information.

• A table should not have repeating values or columns. The table for an item in the database should not contain a list of values for a specific piece of information. For example, a product in the AdventureWorks database might be purchased from multiple vendors. If there is a column in the Production.Product table for the name of the vendor, this creates a problem. One solution is to store the name of all vendors in the column. However, this makes it difficult to show a list of the individual vendors. Another solution is to change the structure of the table to add another column for the name of the second vendor. However, this allows for only two vendors. Additionally, another column must be added if a book has three vendors. If you find that you have to store a list of values in a single column, or if you have multiple columns for a single piece of data, such as TelephoneNumber1, and TelephoneNumber2, you should consider putting the duplicated data in another table with a link back to the primary table. The AdventureWorks database has a Production.Product table for product information, a Purchasing.Vendor table for vendor information, and a third table, Purchasing.ProductVendor. This third table stores only the ID values for the products and the IDs of the vendors of the products. This design allows for any number of vendors for a product without modifying the definition of the tables, and without allocating unused storage space for products with a single vendor.

Ref.

Answer 3

As a beginner I used Relational Database Design.

Believe me its great! (because it works and requires no prerequisites i.e. ideal for beginners). On page 4 it covers normalization.

Answer 4

I use NORMA for conceptual database design. One side-effect is that it produces the schema for a properly normalized database.