Sharing ideas, An example

Sharing your ideas – An example:

How to share multiple files with other people 

When you need to share information with others over a period of time, maybe as part of a project, and where you need to reference it and update it, you will need a way of storing it and a way of tracking it so that it does not get confusing for the people who have to use it.

This page looks at a real example of a shared database design that I once had to do. This was required to keep track of files that are shared with others and where the files can be updated by different people and in different ways.

Consultations are available. See Contact page for more details

Data Management Scenario

The concepts presented here can be applied to any shared storage format:
Files, index cards, boxes, warehouses, and so on

This given example relates to files stored on a computer database, but other examples will be provided to help clarify different aspects of the design.

The scenario:

You are required to design a database structure that will hold over 400 software files (data), these files relate to 8 different products (user) each of which uses a cross-section of the files for their own needs, each product references about 250 files within the database.

Just to add to the mixture – some products share common files and some files are unique to a product.
This is why there can be over 400 files for products that use only 250 each – some of these files are shared by all products, others are common to some products, and some are used only by one product. Therefore those files not totally common (150+) are ignored by the products that do not require them.

These files must be accessible to a number of different people (user), each of whom could make a change to any file. If the changed file is a file that is shared between products then the other products would need to be informed of the change so they can include the updates into their product (change control).

In this scenario there are two groups of users that must be accommodated. The first are the products that use the files for their software operation, the second are the people who use the files to design the software for the products.

A data management nightmare!

Summarising the objective:

  • To have one set of files within a database structure designed to allow any of the 8 products to use any of the files that it requires.
  • To provide access into the database and to ensure that any updates to a shared file performed by a person must then relate to every product and must therefore then be used by them all.
  • That although some of those files are shared by more than one product, each file must only exist once within the database (critical design point)

Database Designing

Whenever a new product is to be designed that has similarities to existing products and you require software to be installed into that product, it is always wise to start with the existing software and use it as the basis for the new product.
For this task, the database that I needed to work with that was used to store the software files had been in existence for a very long time.

Investigating the current database structure the following were identified:

  • Each product had its own area within the database
  • Many of the files were duplicated, each area would have some file names common to other areas but had no connection to them   
  • Many of the duplicated files had been ‘tweaked’ slightly within their own areas, so although they shared the same name, the file contents did not always match the equivalent file in another area
  • The structure of the database did not efficiently reflect the structure required for the product
  • About 250 files were used to create the software package for an individual product. These files could vary between products, some shared common names, others were uniquely named for that product
  • There was obsolete code buried within many of the files, caused by being ‘tweaked’ over the years.
  • There was some unused (obsolete) files lurking in the corners

1) Informing the current users what you are planning to do

For multi-user databases the most important action at the start of the project is to talk to the other people who would be affected by these changes, to those whose files are stored in the database. From these conversations you can learn what the current problems are with the existing database and also what features they would like to see in the new design.

2) Identifying the key (basic) operational categories

The basic categories of the database need to be identified, for this example these categories would relate to the products operational features. They include:

  1. Files for controlling the system – Shared by all. These are responsible for the basic system operation of the products.
  2. Files for hardware component interfacing – Shared between those products who have that specific component in their design
  3. Files for what the products are required to do (functional requirements) – These files do the work within the product, using the system control files and hardware files to perform the requirements of the product – the products will each use a mixture of these functional requirements. Each requirement will form a separate category in the database and will need a collection of files to perform that action.
  4. Files that are unique to a product – only ever relating to the one product. These are often the ‘top level’ files that connect the person with the product, providing the unique interface to the product.

These categories would become part of the fundamental database structure design

3) Identifying the commonality of the requirements between the products

Having established the basic categories I turned my attention to the products and started to identify the commonality of the requirements (functional or hardware) between the products and, therefore, what operational categories they had in common with each other. For example which products had a hardware component that was also used on another product.

This task started by identifying the requirements that where common to all of the products, then moved on to identify the requirements that were shared between some of the products (making a note of which of those products shared that requirement). Once that task was completed then the only remaining requirements would be those that were unique to a single product.

The access of the products into the database design has now been identified

4) Creating the ideal database layout from the information gathered

Now comes the critical design stage. Ignoring the current database layout it was time to work out what the ideal structure design would be, based upon the information that had been collected.
In a bazaar way this task is almost 3-dimensional in it workings, or multi-layered in two different ways – on the one hand you had the unique operational categories that may or may not be used in a product, and on the other you had the unique products that may or may not share operations.

If you were to relate this to a car design scenario, on the one hand you would have common operational features shared at a fundamental level (Operational – engine, wheels) and, on the other, those shared across a manufacturer of a car (Product – a special feature of their range perhaps)

I choose to design the new database structure around the operational categories, starting with those shared by all products, then those shared by some, finally those operational categories that were unique to a product. NOTE: they may not stay unique if a future product decides to include that operation.

Each different category was given its own area within the database so that the files within it would exist only the once and would not be found anywhere else, thus ensuring that they remained unique and, where shared by products, common to all products.
In this example the database was configured to have one area for the files that dealt with the hardware components and another for the basic underlying system control, before creating areas to contain the files that performed the different shared or unique operations of the products.

5) Bringing the products requirements into the database

Once all of the different operational categories had been assigned their areas within the database, then each product was given its own area within the database, the information in here would provide the details of what operational categories they used, as well as the specifics about the product that may be required to be referenced by operational files.

It would be in this area that you would learn what hardware components it was required to work with, and the different optional operations it would provide as part of its design. 

For the car design it may contain details of the optional operational features it uses and what type of tyres it used

6) Making the ‘shared’ files common to all products

This is the most time consuming activity, for you must now enter the files into the database and ensure that ‘one file would fit all’.
Due to the duplication of the so-called common files, each file that was ‘shared’ across products required its contents to be examined to identify the differences between the files of the same name used between different products. Once the differences had been identified then changes to the file would need to be implemented in such a manner that whatever product used that file it would operate as that product had expected it to do within its own area. Great fun!

From a software perspective this would require a lot of extra testing in the software  (‘if – then – else’) and switch statements to be designed into it. The decision making would be defined by the product that is using it (if product A then do this… if product B then do that …).
Obsolete code was also checked for and removed during the process, as were any unused files.

For the car design scenario, the category could be ‘wheels’. Whenever a specific car used that category, a check of the car type would identify which specific wheels were required for that car (if car B then use …, else… ). Cars no longer being produced would be obsolete and could be removed  

7) Ensuring that it stays ‘tidy’ when people use it

Once you have your ‘well structured’ database you then need to ensure that it stays ‘tidy’ when it is used by many people, this is known as ‘change control’ and is a large topic in its own right and is covered separately: Change Control

However to give you an idea what this involves for this example I will give a brief description of how it was implemented for this database.This considers just a few points of change (or configuration) control that relates to this example only. 

Change control management for this database

(for full guidance: Change Control)

A requirement for some databases is the need to be able ‘track’ the changes over time, to be able to look back in time to see what the changes had been since then. For a PC database system that stores software files, the implementation of ‘change control’ system is the technique used that allows you to retrieve the software files that were used for a product at a specific version release in the past, ignoring any changes that had happened since to that file.

This enables you to look at the history of the products software to see how it performed the tasks for a specific version in the past. This requirement is essential if a problem occurs with the product, it enables you to look at the ‘Then and Now’ versions to see where the problem first appeared, what change you made to it that introduced the problem.

Archiving and file history details

A PC database should provide the facility that allows the files to be ‘archived’, allowing you to put newer versions of a file into the database and the previous version would still be available if you were to look at the file at the specific time in the past. This is an important requirement for configuration control as you may need to see the ‘history’ of a file so that you can see what the specific ‘configuration’ of the files were at the moment in time you are interested in

Updating the file

When a change occurs to a file, if the file is common to any other product then those products that use that file may need to check what the change is. This is important if it is fixing an issue with the software for although the other products have not had the problem, the potential for it to appear is still there – they have only to use that part of the software when it is running for it too fail.

 Jenny M L ~  Inspiring the Imagination ~ Contact Me


Comments are closed.

%d bloggers like this: