Codd’s 12 Rules Relational Database Management
This is a draft cheat sheet. It is a work in progress and is not finished yet.
Edgar F. Codd wrote a paper in 1985 defining rules for Relational Database Management Systems (RDBMS), which revolutionized the IT industry. In 1993, Codd and colleagues worked up these 12 rules for defining OLAP (Online Analytical Processing), an industry of software and data processing which allows consolidation and analysis of data in a multidimensional space. Codd’s 12 rules are:
1. Multidimensional conceptual view
User-analysts would view an enterprise as being multidimensional in nature – for example, profits could be viewed by region, product, time period, or scenario (such as actual, budget, or forecast). Multi-dimensional data models enable more straightforward and intuitive manipulation of data by users, including “slicing and dicing“.
When OLAP forms part of the users’ customary spreadsheet or graphics package, this should be transparent to the user. OLAP should be part of an open systems architecture which can be embedded in any place desired by the user without adversely affecting the functionality of the host tool. The user should not be exposed to the source of the data supplied to the OLAP tool, which may be homogeneous or heterogeneous.
The OLAP tool should be capable of applying its own logical structure to access heterogeneous sources of data and perform any conversions necessary to present a coherent view to the user. The tool (and not the user) should be concerned with where the physical data comes from.
4 Consistent reporting performance
Performance of the OLAP tool should not suffer significantly as the number of dimensions is increased.
5. Client/server architecture
The server component of OLAP tools should be sufficiently intelligent that the various clients can be attached with minimum effort. The server should be capable of mapping and consolidating data between disparate databases.
6. Generic Dimensionality
Every data dimension should be equivalent in its structure and operational capabilities.
7. Dynamic sparse matrix handling
The OLAP server’s physical structure should have optimal sparse matrix handling.
8. Multi-user support
OLAP tools must provide concurrent retrieval and update access, integrity and security.
9. Unrestricted cross-dimensional operations
Computational facilities must allow calculation and data manipulation across any number of data dimensions, and must not restrict any relationship between data cells.
10. Intuitive data manipulation
Data manipulation inherent in the consolidation path, such as drilling down or zooming out, should be accomplished via direct action on the analytical model’s cells, and not require use of a menu or multiple trips across the user interface.
11. Flexible reporting
Reporting facilities should present information in any way the user wants to view it.
12. Unlimited Dimensions and aggregation levels
The number of data dimensions supported should, to all intents and purposes, be unlimited. Each generic dimensions should enable an essentially unlimited number of user-defined aggregation levels within any given consolidation path.