Part I
The term database refers to a specific set of data, which can be accessed and manipulated through a database management system (DBMS). The databases themselves can be object-oriented, relational or hierarchical and there is a wide variety to choose from. Some DBMS are available only for specific operating systems. They can be small or large and they come at a price or for free (open source). In the following I will describe the basics of a relational database management system (RDBMS).
The conceptual description of your business is a data model. In your model you have entities with attributes. If you were to sell shoes one of your entities is shoe and attributes are price, size, colour etc. You assign to each attribute a domain, which is a specific data type. If we take the attribute price the data type “decimal number†would not be sufficient, so we specify the domain, which is currency. This makes sure the decimal number has only two decimal places and cannot have any negative values.
In your data model it is important to analyse what kind of relationship there is in between the entities. If your shoe business is big enough to have several stores you could have another entity called “storeâ€, which should be connected to the shoe entity. To do so it is important to analyse the number of participants in this relationship (cardinality) as there are four general options, which are one to one, one to many, many to one, many to many. Let us say a certain pair of shoes is just sold in one store. You all will agree this is a one to one relationship. But if the same pair is sold in various stores, then this is certainly a one to many relationship. I am sure you will also agree there might be more than one pair of shoes, which is sold in a certain department (many to one) and it even could be that there are 5 different pair of shoes, which are sold in 3 different stores (many to many). Let us also consider the direction of the relationship (directionality). If the relationship flows in both ways it is bidirectional, otherwise a unidirectional. As the one to many and many to one bidirectional relationship is one and the same thing this gives you seven options to choose from.
To simplify the relationship issue you can use entity relationship diagrams (ERD), which will help you to get a clearer understanding of the existing relationships. Those use symbols as entities and arrows to show the direction(s) of the relationship. They also show how many participants are taken part in any given relationship. If you were interested in the use of them just enter “entity relationship diagrams†into Google and you will come up with a wealth of information. For a great definition of ERD please relate to "http://en.wikipedia.org/wiki/Entity-relationship_model".
This is all very theoretical, but it will save time and effort later on if done with the necessary commitment. Once you have your data model established you start your data schema, which is the physical design of your database. Part II will explain how to design the actual database and should follow in due course
The term database refers to a specific set of data, which can be accessed and manipulated through a database management system (DBMS). The databases themselves can be object-oriented, relational or hierarchical and there is a wide variety to choose from. Some DBMS are available only for specific operating systems. They can be small or large and they come at a price or for free (open source). In the following I will describe the basics of a relational database management system (RDBMS).
The conceptual description of your business is a data model. In your model you have entities with attributes. If you were to sell shoes one of your entities is shoe and attributes are price, size, colour etc. You assign to each attribute a domain, which is a specific data type. If we take the attribute price the data type “decimal number†would not be sufficient, so we specify the domain, which is currency. This makes sure the decimal number has only two decimal places and cannot have any negative values.
In your data model it is important to analyse what kind of relationship there is in between the entities. If your shoe business is big enough to have several stores you could have another entity called “storeâ€, which should be connected to the shoe entity. To do so it is important to analyse the number of participants in this relationship (cardinality) as there are four general options, which are one to one, one to many, many to one, many to many. Let us say a certain pair of shoes is just sold in one store. You all will agree this is a one to one relationship. But if the same pair is sold in various stores, then this is certainly a one to many relationship. I am sure you will also agree there might be more than one pair of shoes, which is sold in a certain department (many to one) and it even could be that there are 5 different pair of shoes, which are sold in 3 different stores (many to many). Let us also consider the direction of the relationship (directionality). If the relationship flows in both ways it is bidirectional, otherwise a unidirectional. As the one to many and many to one bidirectional relationship is one and the same thing this gives you seven options to choose from.
To simplify the relationship issue you can use entity relationship diagrams (ERD), which will help you to get a clearer understanding of the existing relationships. Those use symbols as entities and arrows to show the direction(s) of the relationship. They also show how many participants are taken part in any given relationship. If you were interested in the use of them just enter “entity relationship diagrams†into Google and you will come up with a wealth of information. For a great definition of ERD please relate to "http://en.wikipedia.org/wiki/Entity-relationship_model".
This is all very theoretical, but it will save time and effort later on if done with the necessary commitment. Once you have your data model established you start your data schema, which is the physical design of your database. Part II will explain how to design the actual database and should follow in due course