DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Please enter at least three characters to search
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Zones

Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Modernize your data layer. Learn how to design cloud-native database architectures to meet the evolving demands of AI and GenAI workkloads.

Secure your stack and shape the future! Help dev teams across the globe navigate their software supply chain security challenges.

Releasing software shouldn't be stressful or risky. Learn how to leverage progressive delivery techniques to ensure safer deployments.

Avoid machine learning mistakes and boost model performance! Discover key ML patterns, anti-patterns, data strategies, and more.

Related

  • Keep Calm and Column Wise
  • SQL Data Manipulation Language (DML) Operations: Insert, Update, Delete
  • Navigating the Divide: Distinctions Between Time Series Data and Relational Data
  • Architecture and Code Design, Pt. 1: Relational Persistence Insights to Use Today and On the Upcoming Years

Trending

  • Solid Testing Strategies for Salesforce Releases
  • GDPR Compliance With .NET: Securing Data the Right Way
  • Cookies Revisited: A Networking Solution for Third-Party Cookies
  • Emerging Data Architectures: The Future of Data Management
  1. DZone
  2. Data Engineering
  3. Databases
  4. Highlighting the Importance of Codd's 12 Rules

Highlighting the Importance of Codd's 12 Rules

A walkthrough of Dr. Codd's concept of Relational Database Systems. We'll explore each rule he outlines and why it's important to crafting an appropriate, functioning system.

By 
Mahesh Sharma user avatar
Mahesh Sharma
·
Jun. 21, 21 · News
Likes (4)
Comment
Save
Tweet
Share
8.9K Views

Join the DZone community and get the full member experience.

Join For Free

Every database includes tables, and constraints can't be referred to as a rational database system. When any database has only relational data model, it can't be a Relational Database System (RDBMS). So, some rules specify a database to function as appropriate RDBMS.  

These principles were developed by Dr. Edgar F. Codd (E.F. Codd) at 1985, who has vast research knowledge on the Relational Model of Database Systems. Codd presents his 13 principles to get a database to test the idea of DBMS contrary to his inaugural model, and when a database follows the principle, it's referred to as a true relational database (RDBMS).  

All these 13 rules are popular in RDBMS, known as Codd's 12 Rules. The database has to be in relational form so that the system can handle the database through its relational capabilities.

Rule 1: Information 

A database contains various information, and this information must be kept in each cell of a table in the shape of columns and rows.

Rule 2: Secured Access  

Every single or exact data (atomic value) can be accessed logically from a relational database using the combination of primary key value, table name and column title.

Rule 3: The Null Value

This principle defines the systematic treatment of Null values in database documents. The null value has various meanings in the database, e.g. missing the data, no worth in a cell, inappropriate data, anonymous data and that the primary key should not be null.

Rule 4: Logical Structure 

It represents the entire logical structure of this descriptive database that has to be stored online and is referred to as a database dictionary. It provokes users to access the database and implement a similar query language to get the database.

Rule 5: Comprehensive Data Sub Language  

The relational database supports different languages, and when we want to get into the database, the language must be the explicit, linear or well-defined syntax. It must also feature character strings and support the following: data definition, view definition, data manipulation, integrity constraints, and restrict trade management operations.  

If the database allows access to the data with no language, it's considered a breach of this database.

Rule 6: View Updating  

All perspectives table could be updated and has to be practically upgraded by the database systems.

Rule 7: Relational Level Operation 

A database system must follow high-level relational operations like "update," "insert" and "delete" in each level or a single row. It also supports "union," "intersection" and "minus operation" from the database system.

Rule 8: Physical Data Independence 

All saved data in a database or an application must be independent to access the database. Each data should not depend on other data or a program. If data is upgraded or the physical construction of the database is altered, it will not demonstrate any impact on outside applications that are accessing the information from your database.

Rule 9: Logical Data Independence  

It's similar to physical data independence. This implies that, if any changes occurred to the logical level (table constructions ), it shouldn't affect the consumer's perspective (program). For example, suppose a table either split into two different tables or two table joins to create a single table, these changes should not be impacted on the user perspective program.

Rule 10: Integrity Freedom

A database must maintain integrity independence when inserting data into table's cells using the SQL query language. All entered values shouldn't be altered or rely on any outside factor or application to keep integrity. It is also valuable in making the database-independent for each front-end application.

Rule 11: Distribution Freedom 

The supply independence principle reflects a database that must work correctly, even if it's stored in various places and utilized by distinct end-users. Suppose an individual accesses the database through an application; in that case, they shouldn't be aware that a different user utilizes specific data, along with the information they consistently get is just located on one site. The end users may access the database, and all these access data should be independent for every single user to do the SQL queries.

Rule 12: Non-Subversion

The non-submersion rule defines RDBMS as a SQL language to store and manipulate the data in the database. If a system has a non or separate language other than SQL to access the database system, it ought not subvert or bypass integrity to change information.

Relational database Database Data (computing) sql

Opinions expressed by DZone contributors are their own.

Related

  • Keep Calm and Column Wise
  • SQL Data Manipulation Language (DML) Operations: Insert, Update, Delete
  • Navigating the Divide: Distinctions Between Time Series Data and Relational Data
  • Architecture and Code Design, Pt. 1: Relational Persistence Insights to Use Today and On the Upcoming Years

Partner Resources

×

Comments
Oops! Something Went Wrong

The likes didn't load as expected. Please refresh the page and try again.

ABOUT US

  • About DZone
  • Support and feedback
  • Community research
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • support@dzone.com

Let's be friends:

Likes
There are no likes...yet! 👀
Be the first to like this post!
It looks like you're not logged in.
Sign in to see who liked this post!