Table In The Database Hier example essay topic

Foreword Since I am more comfortable with creative writing and fiction, I decided to write this paper as a short story about three members of the Database Family. The story is narrated by the youngest member, who is observing the interaction between the three great women. The characters are Hier, Nettie, and Rela. Heir will discuss the workings of the Hierarchal database, including its history, failures, and successes. Nettie, short for Network, will further explain when the Network Database family began and how it is used in today's world of information technology. Rela will further engage us by discussing the greatness of the Relational database clan.

Yes, I could have made them patriarchs of the family but I am a strong believer that women rule the world. Having said that, let's go to dinner with Heir, Nettie, and Rela. Let your imagination run free. Dinnertime with Hier, Nettie, and Rela It was a great October day, one of my favorite months, never too hot or too cool, but perfect for outdoor adventures. Today the air had a fresh clean smell.

The humidity of the summer lingered gently in the background as the aroma of the fall season began to take effect. The wind nestled in the trees and a humble breeze settled across the pale blue sky. It was the beginning of the evening while the day was still clear enough to see the settling of the sun. I scrambled to the edge of the hallway in my jammies. There was so much about our family history to hear and this was the opportunity of a lifetime.

Hier, Nettie and Rela, the oldest members of the Database family, were sitting down to discuss the finer things of life. I could see a small ray of sun break through the slightly opened blinds and crease across Hier's dusty lid, when she began to speak. "I am the oldest of the database models. Back in those days, we really didn't give too much attention to writing things down, so the initial date of my conception and birth is unclear. But suffice it to say, I came about between the 50's and 60's, way before your time, Rela, and, I have crossed more bridges and roads than you can ever imagine". Rela made a slight chuckle.

Rela felt she was the "be all" and "end all" of the database family and she had no use for Hier's stories. However, she would show her the respect of listening to her again. Hier continued: "When I laid out all the data sets in a tree fashion, the developers felt a great sense of accomplishment. Finally, I had given some order to databases. My data is hierarchically-arranged in the form of parent-child relationships. The key thing was that I took an upside down approach by establishing the root of the tree as the parent or top.

Now, a parent could have multiple children but a child could only have one parent". Hier took a deep slow breath. Her arthritic hands trembled as she spoke. She was still a very strong database, but currently, she was limited to the legacy systems of certain banks and insurance companies. She was also called upon to work in inventory and accounting systems of government departments and hospitals. (web) She had begun to feel useless 10 years ago until the Windows-based directory management systems (like Windows Explorer) had given her the juice in the arm she needed. Her greatest fear was retirement.

We all knew it was coming soon. She looked so radiant and a sense of excitement filled her voice as she continued. "I don't think you really understand how it works Rela. But let me explain it to you again. I put the data in different records.

The records have a set of field values attached. I collect all the instances of a specific record together as a record type. It is similar to your tables, Rela". ( . Unixspace. com) Nettie was intently listening but Rela looked as smug as ever. Hier looked a little frustrated with the entire scene.

She explained how she created links using the Parent-Child relationships. Starting with one database (the parent); it is linked to the databases beneath it (the child databases) by using a one-to-many mapping relationship. (Nzokah, Lecture 4) The parents and children are tied together by links called 'pointers' and a parent will have a list of pointers to each child. (Sol, 1) It is all done by using trees. I could see that Rela was about to pounce on Hier.

She never wanted to give recognition to anyone other than herself. She rolled her eyes in an upward fashion. "Hier, you know how sickly you are. You have more problems and ailments. Sure, you were an improvement over the traditional flat-file system but you still had some serious issues in your day". Nettie was very fond of Hier.

She looked at Rela with disgust. How could Rela be so disrespectful? Hier stared through the blinds. A squirrel was running across the yard and it broke the ray of sunshine on her forehead for a second. She stood up to open the windows and allow the breeze to flow through. Rela looked at Nettie's expression, with a under-headed look of daring and continued to berate Hier.

"I'm just saying that you have some issues. You can't link data between two child databases. (Nzokah) You don't handle many-to-many relationships well, and you still create redundant data within the database. You are not friendly, and nobody can add records to your child databases". Rela stood up with her hands folded. She appeared angry but Hier was not fazed by her actions.

"Rela, I know I've had problems, and that is why Nettie came along". Hier stroked Nettie's face softly. Nettie leaned towards Hier, looked into her eyes and smiled with adoration. Nettie thought her primary goal in life was to help solve Heir's problems. They were so intertwined and quite a bit alike.

Nettie also used set theory to give a tree structure similar to Hier's model. Nettie was a lot quieter than Rela and wasn't comfortable speaking out unless challenged. Well, it appeared that Rela had just engaged Nettie in a challenge, when she glared at both of them, saying: "Nettie, you are no better."Quite the contrary, Rela, I did make some improvements. I allow children to have multiple parents.

I also support many-to-many relationships without difficulty". (Sol, 1) Nettie was obviously not good at this type of discussion. She floundered as she explained her history. She was officially defined in 1971 by the Conference on Data Systems Languages (CODASYL). Basically, the network model uses the set construct. A set consist of an owner record type, a set name, and a member record type.

A member record type can have that role in more than one set, thereby having the multi parent concept. ( . Unixspace) "I helped reduced the data redundancy issues, and I made the searching capabilities better". (Nzokah, 1) Nettie glanced at Hier for a show of support. Hier nodded her head as if to say, "you are doing well, Nettie". Nettie talked about Codasyl.

Codasyl is made up of data-items, records, and sets. A data-item is the same as a column or attribute in a RDBMS. A record is a collection of data-items. Once again, repeating groups are allowed. A set defines the relationship between records. This is where the parent is called the 'owner' and the child is the 'member'.

Defining a Codasyl database is like defining a Cobol data structure. (Whorten, 1) Rela was on a rampage. "Nettie, you look like a tree, you smell like a tree, and as far as I am concerned, you are still a tree. You require so much work to maintain and implement. And, I might add, you still have that issue with record creation".

(Nzokah) "I am the one that works the hardest and is more efficient than both of you". Hier intervened. "Alright, Rela, calm down. No one is dismissing your claim to fame.

We are all family and we support one another. Why don't you just sit down a spell and tell us your story". Hier put her arms around Rela and guided her back to her chair. Rela began to talk about her marriage to E.F. Codd. Codd groomed and designed Rela to the database she is today by anchoring her functionality to mathematical concepts. Rela allows the definition of data structures, storage and retrieval operations and integrity constraints.

The data is organized in tables. A table is a collection of records. It is made up of horizontal rows (called tuples) and fields (vertical columns also known as attributes.) (Sol, 1) Rela was really getting into herself at this point. Both Nettie and Hier listened carefully as she sought to enlighten them about the essence of tables.

"I have a few rules to be followed when constructing tables. First, each entry must be singled valued. You can not have an array of values in the row and column intersection. Secondly, each entry in a column must have the same format.

For example, if an integer is used in the column, then all entries must match and be an integer as well. Last but not least, I have to have a primary key to uniquely identify each row". Nettie murmured beneath her breath, "and let's not forget about the normalization rules, too". Rela snapped her head to Nettie and shouted, "at least I am more flexible than you are". Heir prompted Rela to continue. There was some confusion about the construction of the construction of the tables so Rela went into further detailed.

She made a point of explaining the table rules. According to her, o A column is drawn from a DOMAIN, that is, a set of values from which the actual values are taken. More than one column in a table may draw its values from the same domain. o A column entry in any row is SINGLE-VALUED, i.e. it contains exactly one item only (e.g. a surname). Repeating groups, i.e. columns which contain sets of values rather than a single value, not allowed. o Each row of a table is uniquely identified by a PRIMARY KEY composed of one or more columns. This implies that a table may not contain duplicate rows. o The ENTITY INTEGRITY RULE of the model states that no component of the primary key may contain a NULL value. o A column or combination of columns that matches the primary key of another table is called a FOREIGN KEY. o The REFERENTIAL INTEGRITY RULE of the model states that, for every foreign key value in a table there must be a corresponding primary key value in another table in the database (Kroenke, 2000) Hier put her feeble hands in the air, "okay, ladies, okay.

We have come a long way. Some of us are faster than the other, one of us is more flexible and simpler to use, but we are all still working in some form or another. That fella, Mr. Kroenke did some studies a couple of years ago about all of us. "According to the studies contacted by Kroenke, the hierarchical model is more structured than the network model, since it only allows a single tree, with no links between layers in different branches of the tree. This means the hierarchical database architecture has more structured form than the relational model, this was done to improve throughput for transactions (adding, updating and deleting records) and to increase the simplicity of the interface for users. Network database model is easy to maintain for its shared configuration, has bottleneck of the central server, is more scalable and but difficult to manage the number of connections (Kroenke, 2000).

Hier didn't say much of anything else. She stared out the window as if she were alone in the world. She knew her time was ending soon. But she had a legacy in DL / I, Network lived on in CODASYL, and Relational had just given birth to object-rel. The setting of the sun was the ending of the day. With a pale orange hue, and border of pink and yellow shining over the horizon, it was the end of one day and the beginning of another.

Bibliography

Retrieved September 26, 2003 from: web Nzokah, James.
Week 4 Lecture Retrieved September 26, 2003 from: web Sol, S.
Hierarchical Databases. 1998.
Retrieved September 26, 2003 from: web Sol, S.
Introduction to Databases for Web Developers. 1998.
Retrieved September 27, 2003 web.