Show Menu
Cheatography

Codd’s 12 Rules Relational Database Management Cheat Sheet (DRAFT) by [deleted]

Codd’s 12 Rules Relational Database Management

This is a draft cheat sheet. It is a work in progress and is not finished yet.

Introd­uction

Edgar F. Codd wrote a paper in 1985 defining rules for Relational Database Management Systems (RDBMS), which revolu­tio­nized the IT industry. In 1993, Codd and colleagues worked up these 12 rules for defining OLAP (Online Analytical Proces­sing), an industry of software and data processing which allows consol­idation and analysis of data in a multid­ime­nsional space. Codd’s 12 rules are:
Source: Codd E.F., Codd S.B., and Salley C.T. “Providing OLAP (On-line Analytical Proces­sing) to User-A­nal­ysts: An IT Mandate”. Codd & Date, Inc 1993. <http:/­/ww­w.f­pm.c­om­/re­fer­/co­dd.html>

1. Multid­ime­nsional conceptual view

User-a­nalysts would view an enterprise as being multid­ime­nsional in nature – for example, profits could be viewed by region, product, time period, or scenario (such as actual, budget, or forecast). Multi-­dim­ens­ional data models enable more straig­htf­orward and intuitive manipu­lation of data by users, including “slicing and dicing“.

2. Transp­arency

When OLAP forms part of the users’ customary spread­sheet or graphics package, this should be transp­arent to the user. OLAP should be part of an open systems archit­ecture which can be embedded in any place desired by the user without adversely affecting the functi­onality of the host tool. The user should not be exposed to the source of the data supplied to the OLAP tool, which may be homoge­neous or hetero­gen­eous.

3. Access­ibility

The OLAP tool should be capable of applying its own logical structure to access hetero­geneous sources of data and perform any conver­sions 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 perfor­mance

Perfor­mance of the OLAP tool should not suffer signif­icantly as the number of dimensions is increased.

5. Client­/server archit­ecture

The server component of OLAP tools should be suffic­iently intell­igent that the various clients can be attached with minimum effort. The server should be capable of mapping and consol­idating data between disparate databases.
 

Codd;'s 12 Rules

6. Generic Dimens­ion­ality

Every data dimension should be equivalent in its structure and operat­ional capabi­lities.

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. Unrest­ricted cross-­dim­ens­ional operations

Comput­ational facilities must allow calcul­ation and data manipu­lation across any number of data dimens­ions, and must not restrict any relati­onship between data cells.

10. Intuitive data manipu­lation

Data manipu­lation inherent in the consol­idation path, such as drilling down or zooming out, should be accomp­lished 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 inform­ation in any way the user wants to view it.

12. Unlimited Dimensions and aggreg­ation levels

The number of data dimensions supported should, to all intents and purposes, be unlimited. Each generic dimensions should enable an essent­ially unlimited number of user-d­efined aggreg­ation levels within any given consol­idation path.