Relational Database Concepts, Research Paper Example

Relational database concepts

A relational model has mainly three components:  (1) A collection of objects or relations, (2)   Operators that act on the objects or relations. (3) Data integrity methods.  A relational database management system (RDBMS) may be defined as: “all data is stored in Relations which (to the user) are tables with rows and columns. Each table is composed of records (called Tuples) and each record is identified by a field (attribute) containing a unique value. Every table shares at least one field with another table in ‘one to one,’ ‘one to many,’ or ‘many to many’ relationships.” (Business Dictionary, 2011)

The illustration to the right illustrates a typical Relational Database Design concept.  Fig 1 refers

Relational databases are important for data manipulation. This refers to the rearranging of data without changing the base information i.e. sorting, re-arranging, analysis, moving the data around.  This is often used for purposes of comparative analysis and to obtain different views or perspectives on the data.  One aspect is to change the relationship between two variables in order to determine the effect of that change. (S. Sumathi, 2007)

Data Modelling:  The data model is a graphic representation of the data that will be contained within the database storage. It is essentially a definition of the entities, attributes and relationships between data.  It forms an integral part of the requirements specification in the data requirements definition (Fig 2 refers)

Concept of normalization

Normalization:  In data base design concepts normalization means the process of efficiently organizing data in a database.  This means the elimination of redundant data i.e. storing data twice in different tables, ensuring that the data dependencies make sense ( they relate to one another), getting the right nomenclatures i.e. apples, oranges and pears = fruit. There are a series of professional guidelines for following out the procedures for the normalization of database designs. These are termed as ‘normal forms’ and are enumerated from the lowest form of normalization to the lowest form called first normal form. Fig 2 illustrates the graphical concept of normalization.

Logical and physical design

Logical design of a system is a precursor to the physical design. This is often a common failing of software development teams. They spend too much time on examination of the technical system as opposed to understanding the functional requirements of the business. A technical solution should never be attempted without first understanding the nature of the business and the requirements to serve the business. Physical implemention is based upon the available technology and is more concerned with items like communications and infrastructure requirements. (Carlos Coronel, 2012)

Context diagrams are often useful in order to gain a high level representation of the logical business systems requirements. A context diagram essentially clarifies the interfaces and boundaries of a project or process. It creates a high level representation that depicts a project or process.  These diagrams are useful in the analysis and clarity of a though process; somewhat similar to mind maps. They provide the high level representation of a particular subject area that requires further decomposition

and analysis. The focus of attention is on the external factors and events before the development of a more detailed diagram.  The main components of a context diagram are: (i) The Process – a rounded rectangle (ii) the external entity – An object, concept or event.  Fig 4 refers.

Data Flow Diagrams (DFD’s) may be used to show either Physical or Logical data constructs. A Data Flow Diagram (DFD) shows the movement of data from one process to another and associates its logical storage criteria. It is important to make sure that the data is consistent from one level to the next level (inputs and outputs). Data can be separated and split from one level to the next, but new data cannot be added in the middle of the diagram. The names and labels should be consistent throughout the diagram. The diagram to the right, Fig 5,  illustrates a typical data flow diagram showing the relationship between processes and the data flows between them.  Note the logical data stores or files where information is either obtained or stored. The concept of levelling and balancing in Data Flow Diagram is to show the decompositions and hierarchy in the process mapping. For example a Level 0 (top level) process statement might say prepare the accounts.  The second level might of the data flow diagram might identify the number of account processes being prepared e.g.  Accounts Payable, Accounts Receivable, General Ledger.  A third level might explain the processes for each of the subsidiary account levels identified and so on until a satisfactory level of decomposition has been completed.

Sql language

There are advantages and disadvantages in the use of Structured Query Language (SQL) as a report program generator.  In essence languages like that of Crystal and SQL have been widely accepted in use with RDBMS systems like that of Oracle.  It is mainly for their ease of use and ability to learn the language quickly with a minimum of external training requirements. A good command of the language is normally acquired in a 3-6 month period.   It does not offer a great deal of progression for technical software developers and is more designed as a technical interface for end users to gain increased familiarity with the system and the ability to manipulate data.  It does offer the advantage of creating suites of management information reports that have continued use.  There are some criticisms to its limited capacity but for all intents and purposes SQL has served its purpose very well.

As the design and development of SQL goes back to the 1970’s it is now somewhat dated technology and the move towards object oriented languages offered more abstraction and interpretation of data.

References

Business Dictionary. (2011). Relational Database. Retrieved 11 9, 2011

Carlos Coronel, S. M. (2012). Database Systems: Design, Implementation, and Management. New York: Cengage Learning.

Sumathi, S. E. (2007). Fundamentals of Relational Database Management Systems. New York: Springer.