Dark Matter Photography
A collection of my photographs and slides.
Sp@m C@tcher
"Your last line of defense against SPAM"
Research Central
My personal site
Office of the Privacy Commissioner of Canada
Collection of essays on DPI (Deep Packet Inspection)
Domain Crawler
[ Thanks to Mary ]
What can you do for your customer?
Provide a solution to their immediate and future needs within the realm of web-based applications.
What is a database?
A database is simply a collection of data, usually relating to a particular subject or topic. The simplest database is a list. A grocery list is a database, as it contains a collection of data about what to buy when at a grocery store. A more complex database would be the inventory of parts necessary to build an airplane. In this case, merely having a list of parts would not be of much use. For each part we would also need to know a part number, how many are in stock, who the supplier is, and so on. Most companies have a database of their customers, including such things as their address, phone number, account number, etc.
Why is a database important?
A database is used to do one thing very well - manage separate pieces of data and combine them in several ways for retrieval at some future time. A simple list might do for a few dozen or maybe even a few hundred 'things', but it can only be organized in a limited number of ways. A grocery list could be organized alphabetically but that's about it. Remember, we only have the names of items, not whether they are a vegetable, fruit, or whatever. So we can't even put all the veggies together. If we wanted to do this, we would need something more about each item.
What happens if you have a poorly designed database?
The worst thing about a poorly designed database is the unknown. That is, how do you know if it's answering your queries completely, without missing an item, or adding ones that don't match your search criteria? This could lead to all kinds of problems, such as missing customers who haven't paid their last bill, or including women in a men-only marketing campaign.
What does your approach to databases offer the customer?
Every database is unique, even though it may do a similar job, such as manage customer information. Since each business has different needs, and each business owner has different ideas as to what they want to do with their data, their database becomes unique as well. I approach each project with an open mind, while not losing sight of past experiences. This ensures the database is designed specifically to meet the needs of that particular client.
How does your approach or service differ from your competition?
Since I am the hands-on designer and programmer, when you talk to me, it doesn't have to be passed on to someone else. You are in direct communication with the factory floor. Since I usually only work on one project at a time, each project gets all my attention until it's finished. This also means I take full responsibility for the whole project, and it usually gets done faster.
Why should the customer pick you over anyone else?
I typically do more work than I get paid for on projects. It's very difficult for me to do a job right to the letter of a contract, since there are always things I discover that should be implemented, but were not thought of at the time. In each case, I either implement it quietly, or if it's a major point, discuss it with the client.
What are the steps involved with designing a database for a customer?
Step one is talking with the client at depth to discover what their particular needs are, and how they are running their business now. If it's a new business, this becomes a little trickier since they don't have a particular way of doing things yet. This may be a good thing, as they have not fallen into any bad procedures yet as well. The goal of this stage is to gather as much information as possible about all the kinds of information handled by the company during a typical year. Also, find out how the information is used. This may require talking with different employees in different departments, and following an order all the way through the system to see what happens to it.
Step two is to categorize each piece of information. A database holds information about things or events. If the data is about a 'thing', we need to know what are the qualities or features (attributes) that describe it. In the case of an inventory of parts, this could be colour, weight, part number, size, quantity in stock, etc. If it were about an event, such as a purchase, we would want to know the date and time, who purchased it, how many did they purchase, was it shipped, when, etc. This stage is still paper-and pencil work.
Next is to take each category, eg. customers, and gather all the information about that category together. There will be more than one category in all but the most simplistic situations. For example, in a retail business, we would have a customer category, a supplier category, a product category, and a purchase category at the very least.
Once we have all the data in all the categories, we look for instances where the same data is in more than one place. For example, we may have customer data in one area, and the same data in another (maybe a different department). This is a major no-no in database design. When you have duplicated data, you never know which is the most current, and you will always forget to update all the places it occurs. To resolve the duplication, we either throw one set out, or break the data into smaller chunks, and split them up if needed. But never duplicated.
At this stage we can now start designing the actual database on the computer. This involves setting up each category in its own table. It also involves determining what kind of data it is. Each piece of data is a particular kind of data. This could be an integer, a decimal number, a string of characters, or even a whole chapter in a book.
Throughout this process, we also have to be considering how the data is going to be used, which in turn determines how we organize, or 'relate' the categories. Thus, we have a 'relational' database.
Once we have a working database, we populate it with (preferably) real data so we can now test out our queries and confirm their correctness and completeness. Remember, we only want what we ask for - nothing more, nothing less. This may lead to changing the design slightly or adding some additional fields. This step is repeated until both the client and myself are sure it is doing what it is supposed to.
Today: Saturday, 04-Feb-2012 13:45:21 EST | Updated: Friday, 06-Aug-2010 14:43:19 EDT