RSS

Managing your ideas and plans

Managing Your Ideas and Plans:

 Keeping control of all that information  

FF ChYrd bird ID
When your imagination (or any serious thinking) is working on a project that requires a lot of information to be managed, and it is going to carry on expanding into the foreseeable future, then you need to find a good way of keeping control of all of that information.  

A database is a way of keeping track of ever-expanding information. Traditionally  Paper documents or more recently computer files are the main methods used for keeping track of information, but items such as shelves, boxes or rooms (e.g. Libraries) are just as valid for keeping track of information. Likewise it does not have to apply just to written information, keeping track of objects falls within this design, even a warehouse can fall into this category! 

Basically, a Database can be defined as anything you can put stuff into and take stuff out of, whether it be written information or physical objects! 

On this page we look at how to go about keeping track of your information in a structured format that allows you to cross-reference and update the information as the details expand and change – And it will work just as well for a warehouse full of items as it would for a directory full of files

  • To see a real example of designing a personal database (once you have understood the basics) go to Managing your ideas and plans – an example
  • If you are interested in learning about how to share ideas with others and keep track of that shared information then go to Sharing Ideas (Shared data)
  • If you are going to need to modify your database and you want to keep track of modifications then, to find out how to do this, go to Change Control

 

Databases – storing information for referencing

(Books, files, Spreadsheets, Shelves, Boxes, Warehouses, …)

A Database is anything where information is stored and referenced, and which can be updated or expanded in size as required. It can exist anywhere where anything can be stored, updated or removed. Normally the term relates to computers and the information contained on them, but it is just as good for any other type of storage management 

Regardless of the type of information you want to manage, a database should be designed with the following properties in mind: 

  • Referencing – Easy to access and reference the information  
  • Updating – Easy to update and enter new information
  • Navigable – Capable of finding your way around it, and as easily as possible
  • Removing – Capable of removing  items from the database (if that feature is desired)

The different types of databases: 
There are a number of different types of database formats and the one that you need will depend upon the purpose of your database and how changes are to be made to it.

  1. Adding new information only – This type of database will need to have enough space for future additions and include no method for removing items. Generally these are used for chronological records, recording information that will never change (e.g. a log of people passing through).   
  2. Adding and Removing information – This type of database may still be chronological in its order of contents, but you will be able to remove (or delete) earlier items (e.g. a log of who has entered a room, then crossing them out when they leave). 
  3. Adding, Removing and Updating your information – This type of database will require some method of replacing items back into the database after they were removed for updating. It may also be designed to allow you to move the information so that new information can be placed where you require it to go (e.g. a record of members addresses, updating them when they move or leave, and adding new members in the correct place alphabetically).
  4. Adding, Removing and Updating shared information – A database that is shared can be very complex in its operation and may require a lot of thinking about, for it will need to take into consideration who, when, what, why and how people will interact with it. This type of design is covered separately elsewhere on this site as it goes far beyond the requirements for the other three types. Go to Sharing Ideas (Shared data) to learn how to design for this scenario .

IMPORTANT – A data management design only gives you a database that is easy to navigate and use once it is operational – it does not make it easy to design and set up to start with!
So lets get on with looking at how we can achieve this!

Understanding the purpose of your database

And what you want to do with it

To help explain the concepts and the design process, the theme of a ‘car’ will be used:

The purpose of this test-case database is to provide you with a way of keeping the details of different cars. It will supply you with a way of looking up the details of what each car is composed of in terms of its parts, allowing you to check what you can find in which car and to make changes to the information.

The objective of the deign is to have a database that allows you to keep records of individual cars and the parts that they are made up from. It will have as its Categories the different major aspects from which a car is made, and the Attributes as the parts that make up each of those aspects. It will also look at what happens in a database if a change is required to a car, and the impact that that change may have elsewhere in that database.

1) Identifying the key categories for your data 

The key aspect to managing complex information is to identify the categories under which the information is to be stored; every piece of data must belong to a category that defines its general purpose.

  • Each category should cover a topic within the subject for the database
  • Each category should have distinctive features that are easy to identify from other categories.
  • They should be kept as ‘simple’ as possible. Do not give deep details at this stage 
  • There should be as ‘few’ as possible. Lots of categories can make it complicated to understand what goes where

For the car database, the key categories could include:

  • Car frame
  • Car parts
  • Engine
  • Dashboard
  • Fixtures and fittings 

Useful Tip – an ‘everything else‘ category in a database may take care of any odds and ends that are not easy to classify. In some ways the ‘fixtures and fittings’ category could contain whatever does not belong in any of the other categories.

Once you have thought through your category requirements, if you are not sure if you have identified every category then do not worry too much at this stage, they will reveal themselves as you go along. If this happens then all you need to do is to create a new category and move the items across into it.

2) Identifying the attributes for each category  

Once the key categories have been identified then you need to look at the information that relates to a category and identify the different attributes that exist within that category.

For the car, the attributes related to each category could include:

  • Car frame :- Outer shell, roof, bonnet, …
  • Car parts:- doors, wheels, …
  • Engine :- Carburettor, gears, … 
  • Dashboard :-  Radio, dials, …
  • Fixtures and Fittings :- mirrors, fluffy dice, …

Testing it out and refining it
When the attributes for each category have been identified, test it by creating a couple of pieces of data and entering their attributes into their categories. Are there any attributes of the data that have not been included in the design (did you leave the floor out of the car frame)? Are there attributes listed that are not used (did you really need those fluffy dice)?

During this time you may also discover that you have a category that had not been recognised before. If this happens then create the category and set about identifying its attributes – possibly the car electrics need to become a category in their own right.

Adjust the test data and repeat the test until you have created some data that fulfils all of the attribute requirements that you need for a category. This may require adjusting the attributes (adding, removing, renaming) as you learn more about the design requirements for a category. Missing attributed usually poke their heads up at some point during this exercise  

Once this stage is completed you would have identified all of the attributes for each category, with some test data written for each.

 

3) Identifying the interconnectivity between the categories

One important consideration of information stored in a database is that, quite often, it does not work in isolation – an action upon a piece of data in one category may have an impact on data in another category. In this situation this relationship needs to be recognised in the design to stop future problems.
If this possibility is not a feature of your database design then carry on to stage 5. 

Multiple interconnectivity
The potential of multiple interconnectivity must be designed into the database at this stage and this is achieved by identifying the impact that a change in one category may have upon another (the connection between them) and then making allowances for it.

A change to a piece of data may have an influence on other pieces of data within the database, the impact of that change may then, in turn, affect other items in the database. For example if a car part is modified then any item connecting to it will need to be checked to see if it requires a modification so that it can still connect to it – and if it does, then are there any car parts that may have to change due to that change? and so on… This can easily become a nightmare and why a good functional database can be so useful 

Car interconnectivity example
There is a lot of interconnectivity in the car. To summarise:

The Frame contains Car parts and has the Engine encase under the Bonnet.  The Dashboard sits inside the Frame and may possibly connect to the Engine via some form of wiring. The Fixtures and Fittings connect to all categories 

Every category therefore has a connection with at least one other category, they all work together to make a whole, a change in one category has a chance of requiring a change in another. 

All interconnectivity requirements between the categories will need to be identified and recorded before you start to build in the complexity into your database (mapping)

This process is a bit like drawing a map, where you have your key locations (=categories) marked onto the map and you are now looking at drawing the routes between the locations before you start doing any of the ground work.

For each of your categories: cross-reference them to each of the other categories to see if there is a relationship between them. If there is then, in simplified terms, make a note on what that relationship is. For the car this will include connections such as: 

  • The dashboard will need to fit into the frame, so these two categories are connected to each other
  • The fixtures and fittings will connect to all categories in different ways, so just make a note of this on every category

 

4) Identifying the connection between categories and attributes  

There are two actions that need to be taken when a change is made between categories:

Making changes internally to attributes 
Once you have identified the interconnections between categories, you will then need to take a look to see what impact that a change in a connected Category may have upon the attributes of this Category. The Category will need to identify the specific attributes within itself that will be affected by any changes caused by a different Category.

Making further changes to other categories 
If you do need to make an update to a connected Category, you would then need to carry on and take a look at that connected Category to see what any changes to their attributes may cause upon another Category, and so on – thus allowing you to move from Category to Category until all of the changes have been implemented.

For example if the radio design has to change

  • The Dashboard will need to be modified to accept the new one, you would also need to check if the Frame needs to be changed to accept the new dashboard.
  • This may or may not need to be changed – for example, the change may have resulted in a smaller slot in the dashboard, in which case there would be no impact on the frame.
  • But if the Frame does need to be modified then the Car Parts attached to the Frame (Doors, windows, …) will also need to be checked to see if they now need to be changed as well.

So we have the Dashboard making potential changes to the Frame, which in turn may make potential changes to the Car Parts and possibly the Engine as well if the new design requires the Frame to move (an exaggeration I know, but it demonstrates the point). 

Changes to attributes between categories should never have a direct impact back to where they started from.

A change should ‘ripple’ out but it should not require a change to go back to the original, otherwise you will end up going round in circles – there should be only one starting point.

  • For the car if the frame cannot accept the new dashboard design, it cannot force the dashboard to change shape. People may need to rethink the design, but the car itself cannot do it!

 

5) Setting up the database  

You should now have all your categories specified, the interconnections between the categories identified, and the data standing-by that is required to be entered into the database. So here goes…

  1. Set up you database structure in the format defined by the categories and attributes identified in steps 1 and 2
  2. If interconnectivity is possibly then set up the links between the categories identified in steps 3 and 4. These links will need to be created in the format that your database will allow. Due to this wide variation it cannot easily be covered here – however the example will show one way of doing this
  3. For each item of data, enter the details into the database under its correct category
  4. If interconnectivity is possibly then for each item of data, check to see if you need to update any of the links connected to it.

Entering the data – considerations 

  • Each piece of data should have some unique reference that will allow you to identify it. The subject of the database may provide a method for sorting out this unique ID 
    • For the car – You would lable each piece of data (= a car) with a unique car ID, e.g. Car X123, Car Y456, Car Z789, …. and then enter the information one car at a time
    • For chronological databases – this could be a date and time. Possibly some extra code if there are a lot at the same time.
    • For a Name & Address database – it would be the surname  
  • Check for duplications as you go along. If you find any then you will need to decide whether one needs to be deleted, or if it needs to be given a new unique ID
  • If you have a large quantity of data (such as a lot of cars) to enter into the database, then do it over a period of time, do a little bit of it each time until it has all been entered.
    • CAUTION: Don’t do it when you are tired, you may make mistakes!

 

An example piece of data  

Now comes the moment of entering a whole test item into the database (for the car, one piece of ‘data’ will be the equivalent of one car)

For the car – Let’s lable the car as ‘test_car1’

Data ID: test_car1

  • Car frame
    • Bonnet ID: Bonnet_123
    • Doors ID: Set_Blue_123
    • …
  • Engine
    • Carburettor ID: 123987
    • …
  • Dashboard
    • Radio ID: Posh_Maker
    • …
  • And so on ….

A Final Warning: 

Any item should exist only once within the database

  • There must be one, and only one, entry of any piece of data into the database.
  • For example no two cars should have the same name (or Data ID), otherwise problems can arise over tracing the history of it and updating the correct car
  • Likewise a car should not have two engine components, otherwise you could rip the car into two pieces if they were to try and drive the car in different directions when you started moving. 

Once this stage is completed you should have a complete database containing everything that you need!

 Jenny Maryl ~  Inspiring the Imagination ~ Contact Me

 

Comments are closed.

 
%d bloggers like this: