Jump to content

英文维基 | 中文维基 | 日文维基 | 草榴社区

Data hierarchy

From Wikipedia, the free encyclopedia

Data hierarchy refers to the systematic organization of data, often in a hierarchical form. Data organization involves characters, fields, records, files and so on.[1][2] This concept is a starting point when trying to see what makes up data and whether data has a structure. For example, how does a person make sense of data such as 'employee', 'name', 'department', 'Marcy Smith', 'Sales Department' and so on, assuming that they are all related? One way to understand them is to see these terms as smaller or larger components in a hierarchy. One might say that Marcy Smith is one of the employees in the Sales Department, or an example of an employee in that Department. The data we want to capture about all our employees, and not just Marcy, is the name, ID number, address etc.

Purpose of the data hierarchy

[edit]

"Data hierarchy" is a basic concept in data and database theory and helps to show the relationships between smaller and larger components in a database or data file. It is used to give a better sense of understanding about the components of data and how they are related.

It is particularly important in databases with referential integrity, third normal form, or perfect key. "Data hierarchy" is the result of proper arrangement of data without redundancy. Avoiding redundancy eventually leads to proper "data hierarchy" representing the relationship between data, and revealing its relational structure.

Components of the data hierarchy

[edit]

The components of the data hierarchy are listed below.

A data field holds a single fact or attribute of an entity. Consider a date field, e.g. "19 September 2004". This can be treated as a single date field (e.g. birthdate), or three fields, namely, day of month, month and year.

A record is a collection of related fields. An Employee record may contain a name field(s), address fields, birthdate field and so on.

A file is a collection of related records. If there are 100 employees, then each employee would have a record (e.g. called Employee Personal Details record) and the collection of 100 such records would constitute a file (in this case, called Employee Personal Details file).

Files are integrated into a database.[3] This is done using a Database Management System. If there are other facets of employee data that we wish to capture, then other files such as Employee Training History file and Employee Work History file could be created as well.

Illustration of the data hierarchy

[edit]

An illustration of the above description is shown in this diagram below:

Data Hierarchy diagram

The following terms are for better clarity. With reference to the example in the above diagram:

Data field label = Employee Name or EMP_NAME

Data field value = Jeffrey Tan

The above description is a view of data as understood by a user e.g. a person working in Human Resource Department.

The above structure can be seen in the hierarchical model, which is one way to organize data in a database.[2]

In terms of data storage, data fields are made of bytes and these in turn are made up of bits.

See also

[edit]
  • Data dictionary – Set of metadata that contains definitions and representations of data elements
  • Data element – Semantic representation of data
  • Data acquisition – Process of sampling signals from sensors and converting into digital data

References

[edit]
  1. ^ Blaauw, Gerrit Anne; Brooks, Jr., Frederick Phillips; Buchholz, Werner (1962), "4: Natural Data Units" (PDF), in Buchholz, Werner (ed.), Planning a Computer System – Project Stretch, McGraw-Hill Book Company, Inc. / The Maple Press Company, York, PA., pp. 39–40, LCCN 61-10466, archived from the original (PDF) on 2017-04-03, retrieved 2017-04-03
  2. ^ a b Laudon, Kenneth C.; Laudon, Jane P. (2007). Management Information Systems - Managing the Digital Firm (9 ed.). Upper Saddle River, USA: Pearson Prentice Hall. pp. 226, 229. ISBN 978-0-13-157984-2.
  3. ^ Marston, Tony. "The Relational Data Model - Normalisation and Effective Database Design". Archived from the original on 2012-01-17. Retrieved 2013-08-20.