DBMS-Relational Database Design -Codd's Rule -SPPU
Codd designed these rules to define what is required from the relational database management system.
All these thirteen rules are followed by very few commercial products. Even the oracle follows eight
and a half rules out of thirteen.
Codd's rules are
Rule O: Foundation Rule
Foundation rule states that the system must be capable to manage its database systems through rulesits The remaining relational capabilities. All other twelve rules are derived from this foundation rule.
The remaining Representation twelve Representation are as follows :
Rule 1 : Information Representation
All the information in the database must be stored in the standard form of tables.
- Table is considered the best format to store and manage the data.
Rule 2: Systematic treatment of null values
In a database, the NULL values must be given. a systematic and uniform treatment. In applies veral number of cases up applies, we may have to set null gathers on the place of data. For Example, data is missing, data is not known, or data is not applicable.
Rule 3 : The guaranteed access rule
- In a database, every single data element must be accessible logically with a combination of table-name, primary-key (row value), and attribute-name (column value).
- There should not be a requirement for any other entity to access the data.
Rule 4: Active online catalog
- The description of the structure Of the entire database must be stored in an online catalog, known as data diction1try.
- Data dictionary can be accessed by authorized users. Metadata should be maintained for aU the data in tl}e database.
- The system must support an online, inline, relational catalog that is accessible to authorized us -is using their regular query language.
- That is nothing but, just like ordinary data the database description is represented at the logical level, so that is possible for authorized users to apply the same language of regular data to its interrogation.
Rule 5: The comprehensive data sublanguage rule
The database should not be directly accessible. It should always be accessible by using some strong. query language. This rule illustrates that the system should support at least one relational language. The
language•
a) has a near syntax
b) can be used both interactively and within application programs,
c) supports data definition operations (including view definitions), data manipulation operations (update as well as retrieval), security and integrity constraints, and transaction management operations (begin, commit. and rollback).
Rule 6: View updating rule
- Views are the virtual tables created using queries to show the partial"I or complete view of the table.
All views th. at are theoretically updatable must also be updatable by the system
The rule states that we should be able to make changes in views.
Rule 7: High-level lnset1, Update, and Delete Rule
- High Level means multiple rows from multiple columns are affected by the single query.
- This rule states that a database must sup()Ort insertion, updation, and deletion.
- This must not be limited to a single row, that is, it must also support the union, minus, and intersection operations to yield sets of data recot4s'.
For example,
- Suppose employees gOt 5% bii{e in a year. Then their salary has to be updated to reflect the new salary. Since this is the annual hike given to the employees, this increment applies to all employees.
- Hence, the query should not be written for updating the salary one by one for thousands of employees: A single q_Uecy should be strong enough to update the ent, ire employee's salary at a time.
Rule 8: Physical data independence
- Changes in the physical level (i.e. format of data storage or container of data like an array or linked list) must not require any change to an application.
tables, there should be no impact or change on the user application.
Rule 9: Logical data independence
- The user's view (application) should not be dependent on up applies logical data in a database.
- That means changes in logical data must not affect
the applications which use it. For example, if two r
tables are merged or one is split into two different
Rule 10: Integrity independence
- The integrity constraints · must be specified independently from application programs and stored in the catalog.
- We should be able to make changes in 'integrity constraints independently without the need for any change in the application.
Rule 11: Distribution independence·
- The distribution of the databases at various locations should not be visible to the end user.
- Users should always get the impression that the data iS is located at one site only.
- That means 1:ven though the data is distributed, it should not affect the speed _9f access and performance of data compared to centralized database_
Rule 12: The non-subversion rule
- If a relational system has a low-level (single-record-at-a-time) language, that low level cannot be used to subvert or bypass the integrity rules and constraints expressed in the higher level relational language.
This means anyhow those integrity rules and constraints must be followed, we cannot violet them by using any back door option.
Comments
Post a Comment