OK, first of all read related books, concerning this thema. From my point of view a good starting point is a book of J.D.Ullman "A first Course in Database Systems" ( or so )- find and read it. Then, if you have studied computer science, reread your lectures on DB - it always work. Although you may know it, google is a great place to find all necessary information. Search for keywords like "ERD", "Entity relationship modelling". Hope it helps.
An entity-relationship diagram is helpful to understand the process flow of data through the system. Once an entity-relationship diagram is created, the developer must then create a special diagram that models the data stored in a database to represent the entities and relationships in the ERD. The name of this special diagram is "logical data model," or LDM for short. The LDM will be used to display how all data relating to the business process being modeled is stored in the database. A logical data model consists of a diagrammatic representation of tables in a database. Some of the tables for the example are EMPLOYEE, EXPENSE, BANK_ACCOUNT, and PHONE_NUMBER.
The first step in creating a list of table columns is to determine what will be the unique characteristic of any row in the table. The unique identifier for all employees may be a social security number or some other unique integer assigned by the company to an employee for the term of that employee’s employment. Following the determination of the primary key is determining what items could be included in the EMPLOYEE table—the developer will need to determine what features about employees must be stored in the database. The determination about whether to incorporate data as a column into the table should rest on two conditions:
Is this data functionally dependent on the primary key?
Will there be only one copy of this data per appearance of the primary key?
Once these factors are determined, the designer will know if he should include the column in the table or whether the column should be used to define another table. In this example of defining the EMPLOYEE table, the designer may want to include a few different elements, such as the person’s name, hire date, age, spouse name, various telephone numbers, and supervisor’s name.
In the case of bank accounts, employees may have several, each with a set of corresponding information such as bank name and ABA routing number. The additional storage overhead makes it difficult to store all bank account information in the EMPLOYEE table. Data components that have no functional dependency to the other data in a table record should be placed in separate tables. The designer may create a separate table containing bank account information, called BANK_ACCOUNT. The primary key of this table may be the bank account number and the associated employee who owns the account. In addition, there may be several columns that share a common functional dependency on the primary key. One final point is that since the bank account does eventually get associated back to an employee, it is required that there be some method to associate the two tables—a foreign key.
Data normalization is the act of breaking down column data to
place in tables where each column in the table is functionally
dependent on only one primary key. This process reduces data
storage costs by eliminating redundancy and minimizes dependency of any column in the "normalized" database to only
one primary key.