RSS

Sharing ideas (shared data)

Sharing ideas and data amongst many:

Multi-user database

bookcase order 070

Shared information

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 as required, you will need a way of storing it and a way of tracking it so that it does not get too confusing for the people who have to use it.

This page looks at how to set about designing a system where you create a database of information that is shared with others and where the information can be updated by different people. It comes from my own experience of working in engineering project teams 

Sharing ideas – A design introduction

The need to create a database for sharing and managing information can initially be based upon one of the following scenarios:  

  • The project is just beginning, therefore a new database design will be required with an original structural layout set up according to the requirements. 
  • The project is bringing together information from different sources, so a merging of databases will be required, often requiring a new structural layout of the database to be designed.
  • The database has become confusing and it is not easy to find things, so the overhauling of a database will be required, even more so if the information is no longer reliable.

Whichever of these scenarios fit your requirements the approach is the same to begin with – You will need to understand what information (data) is going into the database and the relationship between that information, just as you do for a single-user database design.

Considerations for a multi-user database 
The key difference between single and multiple user databases is how it is used. In addition to all of the considerations required for a single user database (See Managing your ideas and plans), the following will also need to be thought through

  1. The kind of people who will be using it and what they will use it for (user operations)
  2. How the information is to be shared between those using it (data sharing)
    1. What information is common to everyone
    2. What information is shared between some
    3. What information is unique to a person 
  3. How to manage changes to the database (change control)

Accessing the information
Understanding how the information is to be accessed and shared between users and the type of people who will be using it and in what way they will use it, will take up a lot of design time. An understanding of these relationships is essential as they deal with the fundamental user operations of the database and the data sharing, which in turn will influence the design of the physical structure of the database.

Change Control
This is covered in a separate article: Change Control  

 

Starting the design – structural and data layout

To help understand some of the concepts presented here, the example of a warehouse will be used to represent a database, with the contents of the warehouse representing the data and how it is to be managed – Usually databases relate to paper or computers, but this example is easier to visualise and simpler to explain. The example will be in italics within brackets 

Sorting out the fundamentals
The first stage is to sort out as much as you can about the information that is going into the database and its relationship with the other information in there (what is to be stored in the warehouse). 

Start by sorting out the data requirements of the database design just as you would for a single-user database, collecting together as much information that you can. First work through Managing your ideas and plans to obtain this, but stop when you come to the part where you begin to set up the database.

Once this first stage is completed you should now have a good definition of all of the types of data that will be going into the database and how they relate to each other. (You now know what type of goods are going into the warehouse and any connections between them. For example trousers and socks are connected by being clothes, roses and daffodils are connected by being plants)

How the information can be shared, the different groups of data sharing
Once we have the data part of the database worked out (as far as possible) we need to begin to understand the human interactions with the database. The key aspect we need to learn for this stage is identifying how the data will be shared.

There are three types of data sharing:

  1. Shared by all: – every user can reference the information
  2. Shared by some: – Specific groups of users reference specific items
  3. Unique to an individual person or role: – Only used by one user

All of the information in a database will fall into one of those three categories, unless it is obsolete and archived and so can be ignored for this task. It is now a case of going through the data you have identified and sorting out which category each belongs too. From this the configuring of the database will take place. 

Example: data sharing levels for a book fair event: 

‘Shared by all’ information This information would be common to all and stored in a common place, such as details of the event location, opening times, what general resources are available, and so on.
Shared by some This would relate to the different areas within the book fair, such as those selling fiction, factual, or providing catering, etc. For example those involved in providing catering will need to know what site rules there are for selling food, the prices they can charge, and so on, whereas the booksellers would not need to know this information.
Unique/Individual ‘user’ information  This could be for each person there, each stall would have details unique to it such as its theme and stall holder name. Details on where and how to set up their stall would be found here   

 

Designing for multiple users 

Once you understand what the data is that is going into the database and how it needs to be shared, then comes the task of setting up the database to accommodate these design requirements.

There are two different aspects for designing a database for sharing information with others. these are:

  1. Physical configuration – How the data is actually grouped within the database (covered below)
  2. Virtual configuration  – A mapping that defines how the user accesses the information (covered later)

Physical (Data) Configuration

The physical configuration relates to the internal structure of the database, how the information is grouped into the storage area (akin to placing the items into aisles and shelves in a warehouse).

Two of the data sharing groups are easy to sort space out for in the database: Those that are shared by all and those that are unique to a specific user (If the warehouse stored car parts, then car cleaning equipment will be common to all, but items for a specific car type will only be used by those with that car type).

The third group, where items can be shared by some and in many different ways, requires more understanding of the multi-user aspect of the design to correctly configure the database (Items for a specific car maker will be shared across their make of cars, but not by other makes of cars).

Designing the physical database layout:

  1. Shared by all. Begin this task by taking the data that is common to all and putting it into the database, (akin to having shelves in a common area that everyone has access too). If there is a lot of information that is common then it may need to be subdivided (akin to separate shelves within the common area).
  2. Unique items. The next stage is to put the items that are unique to a user into the database, allocating space in the database and placed each item into there own area within it (akin to labelling individual shelves that are referenced by one car type only, and stacking individual car items onto those shelves) .
  3. Shared by some. Now comes the tricky bit, sorting out how the shared information is allocated in the data base (for the warehouse car scenario, these could be the items that are shared across all cars of a particular car maker). How this is done will relate to the type of database you are using.
    1. In some situations Virtual Configuration (see later) is the way to achieve this.
    2. In others actually allocating a space for every combination of shared data is the better way (in the warehouse scenario you may allocate an aisle to a particular car maker).

 

Virtual Configuration – (mapping)

The Virtual configuration of a database is where the physical structure of the database does not correspond directly to how the user will see or use the database.

Within the physical database the contents are not necessarily close to each other. Everything within a specific group will be together (in a warehouse, items for a specific car maker will still be physically placed together) but another related group could be found in a location in a very different place (in a warehouse the items specific to a car maker, but relating to a different car, are found 15 aisles away).

The access into the database will be via ‘virtual mapping‘ where you are giving the locations within the database (which directory) to find you information (in the warehouse you would be handed a map of the place)

User access to the database

This map will present to the user only the aspects of the database that relate to their needs and ignore the rest (in the warehouse, an assistant could indicate on the map the actual aisles you need to visit). PC Databases are commonly designed like this.

For every possibly user of a database, whether a person or a job title, a virtual configuration will be created for them that will provide access to the actual items within the database that relate to their needs. There will be a reference list of which items they need, whether shared by all, shared by some or unique to them (akin to having a shopping list of what items you need in every category, and knowing what different parts of the warehouse you need to visit to locate them).

Designing a database with virtual mapping

Now comes the tricky bit:

How to design a multi-user database that contains every item only once, and that every person who needs to use that item can do so without making copies or updating it without affecting others who also use it! 

Basically, from a managing perspective, you will need to design a database system where changes are managed and everyone is kept up-to-date with any changes to items that they may need to use. Essential when a database has ‘virtual mapping’ – for in this instance the users will not directly see the structure of the database

The important points that you need to consider for shared database designing are listed below, each topic is considered in more detail afterwards:

  • What the key roles are for managing a shared database once the database is operational
  • That understanding the user is just as important as understanding the data
  • A good naming convention is essential for ease of use
  • Producing a guide for the users of the database.
  • Producing a design guide for your own understanding

The key roles for shared database management once the design is complete

To ensure that a shared database maintains its integrity the following roles will need to be filled. It is worth being aware of them during the initial design stages as you do not want to get to the end and discover that there is nothing in place to keep it nice and tidy

  • Database manager: You will need someone who can make changes to the database, who has the authority and ability to modify the design of the database. These tasks will include: adding in new categories, removing (or archiving) obsolete information, modifying existing contents   
  • Configuration Controller: Not everyone should be able to update the contents of a database at a whim, you will need some process in place so that updates are controlled. One method, especially on large databases, is to have a configuration controller (warehouse manager) who has sole responsibility for updating the database (warehouse records) with the changes – every change must go through this person. Whether that person actually does the updates or just authorises them for others to do will depend upon your design
  • Approval system: Some method of peer approval will be essential for any updates that will effect other users. All those who use a piece of data (or an item) in there work that is being updated will need to know about it before the database is updated as they will need to use it (maybe a book stored in the warehouse has been replaced by a new edition that people need to use).
  • Notification system: A method of notifying everyone who is connected with the database of any changes that take places will need to be created. When anyone makes changes to the database (Database manager, Configuration controller, authorised user, …), these changes must be related to any interested parties, this may include non-users such as managers.

Understanding the users is just as important as understanding the data

You need to understand the way the database is going to be used just as well as you need to understand how it is to be set up
Every possible combination of how the database is to be accessed and updated needs to be understood. Methods for doing this include:

  • Talking to the potential, or current, users to see how they think it should behave. (Market research)
  • Looking at the target use of the database and working out a structure based upon that purpose. (‘End Product’ Research)
  • Reading more about what your database is intended to be used for and what may already exist for similar requirements (technical/current research) 

A good ‘naming convention’ is essential for ease of use 

When it comes to naming the different categories, products, users, files, data items, etc. of your database, you need to come up with a way of naming (or labeling) these different parts of the database so that they make sense to other people when they come to use it.

  • For categories, choose names that relate to their purpose within the database. For example in a book fair you could choose names such as ‘Fiction’, ‘Reference’, ‘gardening’
  • Choose names that can handle expansion if this could possibly happen. For example if you have four variations of a product, then use a naming convention that would not be out of place if a new variation is introduce. One way is to directly use numbers to identify the different products – simple but effective!

Produce a user guide 

Some instructions on how it works need to be written down. Whether this can be a single sheet of paper, or require a booklet of 50 pages, will depend on the complexity of the database. User guides can be tailored, if necessary, to the role of the people who are going to use it. Always write one for yourself so you do not get confused if you come back to it after a break away from it

Examples:

  • in a warehouse, people who update/restock the warehouse will need a guide of where the items can be found to take out into the warehouse, how to correctly carry the items (safety issues), how to stack them and so on.
  • In a computer database, people will need to know how to activate/switch on the database (password?), how to search for what they are looking for, the procedures required to extract files, the process for re-entering a file (change control?), and so on    

Produce a database design guide 

Always write a good design guide – you may need to reference it yourself. Contents should include

  • Purpose of design: Why you have designed it the way you have.
  • Structure of the database: How the database has been designed at a ‘data contents’ level
  • Mapping of the database: How the inside bits connect to the outside bits. Basically, what user has access to what data

 Jenny Maryl ~  Inspiring the Imagination ~ Contact Me

 

Comments are closed.

 
%d bloggers like this: