Database Design Service

Database Design Service

The skills and experience of our DBAs allow us to design the best infrastructure for your needs.

PV Technosoft has accumulated years of cross-industry expertise in database design, database development and programming, database integration and conversion, database management and administration, database maintenance and support. Profound knowledge and extensive hands-on experience in Oracle, MS SQL Server, MySQL, PostGreSQL, IBM DB2, Sybase and other relational database management systems (RDBMS) ensures our clients will get most out of their business being provided with a highly sophisticated database solution that is fast, scalable and efficient.

Whether you need a database driven web site or a full-featured, large-scale customer relationship management system incorporating Oracle database servers with complex structure, Blend IT Solutions can offer you the top-of-the-line database application development services tailored to your specific needs and providing you with an important competitive advantage.

Our ability to combine strategic vision with in-depth expertise in a wide variety of cutting-edge database technologies ensures our clients are delivered robust database systems that automate and streamline their business processes, improve operational efficiency and management effectiveness, increase market reach and maximize return on investment.



Our Process of Database Design

Getting the database model right

The first step in designing a great database for your web application is requirements analysis - in other words, finding out what's needed, and working out the best way to deliver a system that fulfills those needs.

Designing the database will then take place as part of an overall system design phase. Getting the data-model right is always an iterative process - an initial draft data model will be sketched out by one team member and then passed around for peer review. Issues that arise from the database design process will feed into the overall system design; queries that get answered here may throw up questions that need to be addressed elsewhere.

Cans of worms and other wriggly creatures

Some aspects of the model will seem simple at first - for example, it might seem obvious that an individual's name should be stored as a two short text strings, forename and surname. But how should a middle name or initial be stored? Should we have a field for 'title'? Should a title field have a controlled vocabulary? Should the title field be 'normalised' (see below)?

There's not always an obvious answer to these questions, and the database model that works for one project might not quite make sense on another project. Tricky questions that arise at this stage might prompt a brief trip back to the requirements analysis stage to better capture what the system does and doesn't need to do.


To normalise, or not to normalise

One aspect of data model design which always needs to be considered is whether (or specifically, to what extent) to 'normalise' data. Data normalisation is essentially the removal or reduction of duplication. For example - rather than store a piece of text for a person's title ('Mr', 'Mrs', 'Dr', etc) you might store a number that refers to another table which contains an exhaustive list of all the possible titles.

Normalising data is generally a good thing - after all, it reduces duplication of data - but it will mean more complex queries are required to pull out useful combinations of data. Sometimes a combination of normalised tables and de-normalised 'caching' columns can be used to make life easier while keeping the master data in a nicely normalised form.