Chapter Legacy Databases
Uploaded by
sureshkaswanChapter Legacy Databases
Uploaded by
sureshkaswanCommon questions
Powered by AIProcedural DML is crucial for retrieving and manipulating data in both hierarchical and CODASYL databases, as it necessitates explicitly navigating the structural paths set by each model . In hierarchical databases, this means users must traverse predefined parent-child paths to access data, limiting flexibility and necessitating intricate navigation routes from the root node downward . In contrast, CODASYL's procedural DML allows navigating through network structures, which, though still requiring precise navigation instructions, enables more varied access patterns due to the model’s inherent flexibility in entity association via multiple set types . As a result, procedural DML in CODASYL accommodates more complex data queries and operations compared to its hierarchical counterpart.
In the hierarchical model, a record type represents a collection of records describing similar entities, with each record consisting of fields like product number or name . These record types form tree-like structures with strict parent-child relationships . Conversely, the CODASYL model also defines record types as collections but allows them to be part of multiple set types, facilitating more complex network connections between data entities . Additionally, CODASYL introduces vectors and repeated groups to accommodate multivalued and composite attributes within a record type, offering more versatile representations for data .
The CODASYL model expands on the concept of set types by allowing not only hierarchical but also network structures where a member record can associate with multiple owners . This approach facilitates more dynamic and versatile relationship types, such as N:M through dummy records . Unlike the hierarchical model, which strictly imposes a 1:N hierarchy, CODASYL’s set types enable multiple connections without redundancy, support logical ordering of member records, and permit systemic ownership of root record types, thus offering enhanced flexibility and better reflecting real-world relational complexities .
The hierarchical model does not natively support recursive relationships, requiring the use of virtual child record types to handle them, adding complexity and making the structure less intuitive . Conversely, CODASYL does not support recursive set types directly either but introduces dummy record types to implement such relationships, allowing more flexibility in constructing networks without strictly hierarchical constraints . While both models require additional constructs to represent recursion, CODASYL's approach is more integrated with its network model, facilitating better handling of recursion compared to the hierarchical method.
In the hierarchical model, N:M relationship types can introduce redundancy because one record type is designated as parent and the other as child, with relationship attributes added to the child record type . An alternative method in this model involves creating two hierarchical structures connected by a virtual child record type, reducing redundancy but increasing structural complexity . In contrast, the CODASYL model handles N:M relationships by introducing a dummy record type as a member in two set types, each owned by the record types involved in the original relationship, thus avoiding redundancy altogether . The CODASYL approach is more flexible as it allows for more complex network structures and avoids hierarchy-specific constraints.
The hierarchical model is limited by its rigidity and lack of support for various relationship types. It only supports hierarchical structures with 1:N relationship types, disallowing N:M or 1:1 relationships . This restricts its expressive power, making it imperative to navigate data procedurally from the root node . Additionally, the model introduces redundancy when implementing N:M relationships by designating one record type as parent, increasing storage and complexity . Also, since a child record cannot exist without a parent, changes to the structure are cumbersome . These limitations impact usability by restricting flexibility and increasing maintenance complexity.
The hierarchical model does not support 1:1 relationship types natively, relying instead on procedural implementation within application programs . This limitation arises because relationship types in this model are constrained to 1:N hierarchies, making direct representation of 1:1 relationships impractical . To circumvent this, 1:1 relationships must be implemented at the application-level logic, or they can be mapped as virtual child record types to simulate the relationship in the database structure, although this adds complexity and overhead .
In the hierarchical model, data navigation is procedural and involves navigating from the root node downward to retrieve all necessary data, which makes access rigid and limited to predefined paths . Conversely, the CODASYL model offers greater flexibility with its network structure, allowing more complex navigation paths as member records do not rely on a single owner and can connect to multiple set types . While both models use procedural DML, the CODASYL model's network structure simplifies data access patterns by circumventing the linearity of hierarchical navigation.
The hierarchical model introduces redundancy in N:M relationships by having to place the relationship type attributes within the child record type, effectively repeating similar data across records . This redundancy can lead to inconsistencies if updates to shared data attributes are not carefully executed across all affected records, leading to potential data anomalies . Additionally, storage inefficiency is a repercussion, as duplicated data increases database size unnecessarily . While this method simplifies certain queries by having all related data in one place, the long-term impact on data integrity and storage can be substantial.
By using virtual child record types, hierarchical databases can represent complex relationships like N:M or recursive relationships which are not natively supported . This introduces indirect referencing, allowing cross-referencing of separate structures, reducing redundancy, and avoiding direct cyclic dependencies . However, it increases complexity as it requires additional layers of abstraction, increased maintenance costs due to the specialized logic needed to navigate virtual constructs, and potentially hampers performance due to additional lookup operations needed to resolve these relationships . Thus, while functional, using virtual child types complicates the schema and operational management of data.