Pattern Of Parent Child Table Relationship example essay topic

Abstract Understanding how databases work is an important process. Key elements of databases contain attribute, column, field, file, record, relation, row, table, and tuples. Deletion anomaly and Insertion anomaly can occur, but have since been eliminated. Binary relationships exist in databases. Domain Key / Normal Form is part of modern database Normalization. Parent / Child relationships exist as well as Strong / Weak relationships, Cardinality and Constraints.

DATABASE CONCEPTS Learning how databases are built is an important lesson. You are better off teaching a man to fish than giving him fish. With that said, understanding database concepts will advance how we can apply our gained knowledge of databases. Databases contain attribute, column, field, file, record, relation, row, table, and tuples. Attributes are columns of the table of the same type of information. An attribute of a table (Calendar) would contain entries like January, February, March, April, and so on.

Each entry in the table contains a row that may or may not have more than one field. The notation for the table can then be simplified with the following schema: Calendar (January, February, March, April, ... ) Each column in a database must have a unique name. How the database columns or attributes relate to one another is important. In order for the tables to form a relationship to each other, tables are bound with a domain which describes the physical and logical entries into the fields of the column.

The rows of the table form records and the records can also be referred to as tuples. Each table must contain a primary key which must be a unique field in order for the tables to be partitioned into separate logical records. Singular or multiple tables can be saved in the same project as a file. Records can be modified, deleted, and added to the file at any time.

In some instances records are dependant on other records and can form anomalies when data is added or removed tuples in a table. For instance, a table may contain the following information: Student (LastName, FirstName, Grade, Classes, TuitionFee). You would create a deletion anomaly if you removed the record because the TuitionFee will be removed as well as the student. Just because the student has been removed from the class does not mean there is no fee associated with how much the classes cost. In this case the TuitionFee column should be placed in a separate table from the Student table. Like wise an insertion anomaly would be created if you did not have the student information.

You would like to place a price in the TuitionFee but can not until a student joins the class. There are three types of binary relationships that show how record relationships are managed. Tree relationships, simple networks, and complex networks best describe this connection. A tree relationship has one or more one to many relationships.

Tree e.g. Simple networks show that many relationships can be formed by one field noted in a one-to-many (1: N) fashion. A child can have several friends. One to Many e.g. Complex networks explain how many-to-many (N: N) relationships work. Many to Many e.g. Codd, inventor of Normal Form produce different levels ranging from one through three of Normal Form referred to as 1 NF, 2 NF, and 3 NF.

(Kroenke, 2000, p. 152). Codd with Boyce later solidified Boyce-Codd Normal Form Four and Five (4 BCNF, 5 BCNF). Codd's 1 NF, 2 NF and 3 NF were designed to reduce and try to eliminate all forms of anomalies. The Normal Forms were formed on the principle of keeping relations focused on one theme. Any relation having more than one theme was divided into two relations, both having a distinct themes. Later, Fagin developed the theory of Domain Key / Normal Form (DK / NF.) His theory proves that a database can be produced without any anomalies regardless of Normal Form level by using DK / NF (Kroenke, 2000, p. 153).

Table relationships play a role in how tables are constructed. Often tables produce a pattern of Parent / Child table relationship. However, unlike having two parents, at most a child table can have one parent. The table relationship indicates that the child table is dependant on the parent table. Tables can also produce patterns of dominance in a Strong / Weak table relationship. The weak needs the strong table to survive; however, the strong table does not need the weaker table to survive.

The dependency of the relationship is noted in the schema of the database. If the stronger row is deleted, so is the weaker record that is dependent on the stronger record. Cardinality rules are also applicable to database concepts. In the previous drawing of the relationship between Child to Toy's, the maximum cardinality rule is said to be 1: N or One to Many. If the example had stated a playing card to a deck of cards with 1: 54, then the maximum cardinality can be said to be 1: 54. A minimum cardinality can exist also.

This can be shown by a hash mark across the relationship line which must exist and an oval across the line which is optional. An employee can have a one to many (1: N) relationship with a computer, but yet an employee does not need a relationship with a computer to exist. Column constraints must exist as a business rule by means of documentation since it is not possible to enforce the rules by relational design. Constraints can be: Must, Must Not, and Must Cover. These business rules are part of the database plan and are considered in effect throughout the entire database management system. These rules can not be altered.

All table fields must contain the name the fields are to be considered and the field belongs to a data type such as text or integers. The fields also contain a description field which is included for description of the type of field. All these parts are the logical and physical constraints to which a database are held. In some instances, a field is defined as having value Not Null, indicating that the field must contain data.

Database concepts are important in understanding the theory behind the database. The topics covered all play in integral role in how a database schema works. By learning these concepts of database files, a person is able to grasp an understanding of how to build a database, thus learning how to fish.

Bibliography

1. Kroenke, D. (2000). Database Processing: Fundamentals, Design & Implementation (Seventh ed. ). New Jersey: Prentice-Hall, Inc.