A role hierarchy is an organizational term most often used in databases and computer security systems. Users possess escalating roles that branch upward like the branches of a tree. As users of the system are promoted through these roles. They inherit the additional attributes, duties, and related variables of the role they adopt, without losing any of their attributes from their former role(s). The advantage to this is that it allows for a simple organizational standard for designing databases and security permissions. Disadvantages come from the fact that oftentimes, individual roles do not bleed neatly into one another, forcing awkward or improper constructions in the design of the system.
Picture a snowball rolling downhill. As it progresses, it accumulates more and more size without losing any of its original content. By the time it reaches the bottom of the hill, or the higher tier of the database, it has expanded far beyond its original size. This is the basic concept of a role hierarchy.
For example, consider a role hierarchy of an employees database. The most elementary tier of the database will be the Employees table, which naturally contains every record of every person working at the company, as they are all employees. Above Employees might be the Managers table, which might add additional attributes such as lists of the employees that each manager supervises. The Managers table will naturally be more exclusive, however; as every manager is an employee, but not every employee is a manager. The role hierarchy table will continue to "trickle up" in a pyramid-like shape, possibly adding a table for Branch Managers, Corporate Managers, Vice-Presidents, and so on.
From a security perspective, the peak of the hierarchy would be an unrestricted system administrator, which can perform any modification or change to a computer system. Whereas the lowest tier would be a simple user, who might only be able to access a handful of programs without being allowed to make any substantial changes. In both cases — either a database or security situation — the role hierarchy schema allows an effective "bleeding upward," allowing users of the system to migrate from one position to the next in a fairly linear format.
The downside to this comes from complex organizations, in which the attributes of one entity do not necessarily bleed smoothly into another. Consider a case where employees are promoted to a management position after holding a role as either a programmers or human resources workers. Assume that company rules prohibit individuals from working as both a programmer and a human resource workers. Now, according to the role hierarchy structure, everyone in the Managers table must inherit both the attributes of a programmer and those of someone working in human resources. This results in wasted space and null attributes within the database, as no single manager will possess both the attributes of a programmer and someone in human resources.
