- Created on Friday, 24 May 2013 09:14
- Last Updated on Friday, 14 June 2013 00:25
In this article the case for requiring a database, to manage the site's FPGA based tutorials, projects and products, is presented. The decision is then taken to develop an in-house engineering database. The project is commenced with a task to create a things to do list entry by presenting a problem statement. From the problem statement the database's things to do list requirements are extracted. These requirements have then been presented graphically in the form of an entity-relationship diagram, which will be used as guidelines for coding the database
When this site started as a blog site, many moons ago, it was fairly basic and like life's junior years rather uncomplicated. On a not so regular basis the site was updated with a new blog article or two describing our ongoing technical developments and achievements in the world of FPGAs. Life was good.
However, as our topics of interest grew it became apparent that a more sophisticated approach to website content creation, management and user interaction was required. If a new approach had not been taken our time, that could have been spent on experimentation and technical content creation, would have been consumed by website management tasks. To this end our introduction to Content Management Systems (CMS) in general and to Joomla in particular has proven invaluable.
Now we are at a new crossroads, as we prepare to increase the site content, provide FPGA netlists (and where applicable source code) and add a product or two, based on our tutorials and project series. We now require a more engaging approach to project and product management, which could involve investing in configuration and project management tools or the development of a home grown solution. Since this website is about learning our choice is the latter.
By developing our own solution we mean unmothballing our relational database books, which only saw the light of day for 1 term (or semester) at university, never to be touched again. Our home grown solution means putting some of the knowledge harvested at the time to good use in developing a database to effectively manage our FPGA projects and products. So, as usual, we will just dive in and get on with it.
2.2. An Example Problem Statement: A Things To Do List
One of the more pressing tasks we have is to implement, as apart of a database, a list of things to do. We definetly have lists of things to do, lots of them on sticky notes, spreadsheets and basically we have lists all over the place. Now we would like to centralise our ad hoc system into a single database. We could just get on a computer and begin churning out some database code or we could follow the more organised approach and firstly write a problem statement.
Our intention in this project series is not to repeat material that has been meticulously presented in numerous text books. Instead we will simply provide our interpretation of the expected outcome and implement the results. Questions, suggestions and ways to do things better are more than welcomue through the usual avenues e.g Discussions forum, Article comments section at the end of the article, etc. After all, like you we are mere mortals!
It is required that a database is developed containing a things to do list. Each item in the list should be uniquely identified, have a description and a date showing when the item has been created. An item on the list should also have a status of open, until it has been closed.
Also, each item should have a degree of urgency associated with it, which can be of types TBD. Each item on the list can also have an associated set of comments. Each comment should have a creation date.
Well that's not too demanding now, is it? Later on, as our needs grow, we will begin to look at allocating persons to action items on the list and all that good stuff seen in professional project management systems. For now, for a "shout over the desk" group of people, we have enough bones to gnaw on. Let's add some meat to the bones by developing requirements based on the problem statement.
2.3 Extracting the Requirements
In this section of the document we examine the problem statement to understand the requirements of the database. Each requirement is extracted below.
- It is required that a database is developed containing a things to do list. Comment: Translates into create a table in a database called Thingstodo. N.B Database names in MYSQL on LINUX are case sensitive
- Each item in the list of things to do should be uniquely identified.
- Each item in the list should have a description.
- Each item in the list should have a date showing when the item has been created. Comment: Dates could contain a day, month and year and possibly a time in seconds, minutes and hours!
- An item on the list should also have a status of open, until it has been closed.
- Each item should also have a degree of urgency of TBD.
- Each item on the list can also have an associated set of notes in the form of comments. Comment: A thing to do could have many comments.
- Each comment should have a creation date.
2.4 Developing the E-R Diagram
We are now in a position to develop our E-R diagram. The statements listed in section 2.3 have been used to develop the E-R diagram shown, in Figure 1 below. The diagram consists of entities and attributes and shows the relationship between them.
Figure 1: Things to do list E-R diagram.
So what have we achieved so far? We have been able to generate an E-R diagram from a problem statement, which we intend to use to create tables to odd to our project and product management database. For those of you that are concerned about thow's mount of work involved in modifying the database as our needs grow. You need not be concerned as we intend to harness the full power of relational databases.
So what have we achieved so far? Well, we have been able to generate an E-R diagram, from a problem statement, showing relationships between entities and entities' attributes. From this diagram we will be able to create tables from entities and table columns from attributes. These will form the basis of our project and product management database. For those of you that are concerned about the volume of work required in modifying the database as our needs grow. You need not be concerned as we intend to harness the full power of relational databases to minimise this effort. In the next part, we will implement the E-R diagram using MySQL
Database Systems, A Practical Approach to Design, Implementation and Management, Thomas Connolly and Carolyn Begg, Fourth Edition Addison Wesley, 2005.