Segmentation:
Segmentation is a memory management scheme which supports programmer’s view of memory. Programmers never think of their programs as a linear array of works. Rather, the think of their programs as a collection of logically related entities, such as subroutines or procedures, functions, global or local data areas, stack etc., as depicted in following figure.
Address mapping in Segment system:
An important component of address mapping in a segmented system is a segment table.
A virtual (logical) address consists of two parts: a segment number and an offset into that segment. The Segment number provides in the virtual address is used as in index into the segment table. Each row of the segment table contains a starting address (base address) of Segment and a size of the segment. The offset of the virtual address must be within (less than or equal to) the size of the segment. If the offset of virtual address is not within the range, it is trapped by the operating System otherwise the offset is added to the base address of the segment to produce physical address of the desired segment.
Wednesday, June 15, 2011
Monday, June 13, 2011
Difference between RDBMS and OODBMS
RDBMS is Relational Database Management system which is based on establishing relationship among tables is purely based on mathematics. OODBMS is Object Oriented Database Management System which is based on the concept of object. RDMBSs were never designed to allow for the nested structure. These types of applications are extensively found CAD/CAF, aerospace etc. OODMBS can easily support these applications. Moreover, it is much easier and natural to navigate through these complex structures in form of objects that model the real world in OODBMS rather than table, tuples and records in RDBMS. It is hard to confuse a relational database with an object-oriented database. The normalized relational model is based on the fairly elegant mathematical theory. Relational database drive a virtual structure at run time based on values from sets of data stored in tables. Databases construct views of the data by selecting data from multiple tables and loading it into a single table (ODBMs traverse the data from object to object.
Relational database have a limited number if simple, built-in data types, such as integer and string, and a limited number of built-in operations that can handle these data types. You can create complex data types in relational database, but you must do it on a linear basis, such as combing fields into records. And the operations on these new complex types are restricted, again, to those define for the basic types (as opposed to arbitrary data types or sub-classing with inheritance as found in OODMs).
The object model supports browsing of object class libraries, which allows the reuse, rather than the reinvention of, of commonly used data elements. Objects in an OODB survive multiple sessions they are persistent. If you delete an object stored in a relational database, other objects may be left with references to the deleted one and may now be incorrect. The integrity of the data thus becomes suspect and creates inconsistencies versions.
In the relational database, complex objects must be broken up and stored in separate tables. This can only be done in a sequential procedure with the next retrieval replying on the outcome of the previous. The relational database does not understand a global request and thus cannot optimize multiple requests; OODBs can issue a single message that contains multiple transactions.
The relational model, however, suffers at least one major disadvantage. It is difficult to express the semantics of complex objects with only a table model for data storage. Although relational databases are adequate for accounting or other typical transaction-processing applications where the data types are simple and few in number, the relational model offers limited help when data types become numerous and complex.
Object-oriented databases are favored for applications where the relationships among elements in the database carry the key information. That is, object-oriented models capture the structure of the data; relational models organize the data itself. If a record can be understood is isolation, then the relational databases is probably suitable. If a record makes sense only in the context of other records, then an object-oriented database is more appropriate.
Relational database have a limited number if simple, built-in data types, such as integer and string, and a limited number of built-in operations that can handle these data types. You can create complex data types in relational database, but you must do it on a linear basis, such as combing fields into records. And the operations on these new complex types are restricted, again, to those define for the basic types (as opposed to arbitrary data types or sub-classing with inheritance as found in OODMs).
The object model supports browsing of object class libraries, which allows the reuse, rather than the reinvention of, of commonly used data elements. Objects in an OODB survive multiple sessions they are persistent. If you delete an object stored in a relational database, other objects may be left with references to the deleted one and may now be incorrect. The integrity of the data thus becomes suspect and creates inconsistencies versions.
In the relational database, complex objects must be broken up and stored in separate tables. This can only be done in a sequential procedure with the next retrieval replying on the outcome of the previous. The relational database does not understand a global request and thus cannot optimize multiple requests; OODBs can issue a single message that contains multiple transactions.
The relational model, however, suffers at least one major disadvantage. It is difficult to express the semantics of complex objects with only a table model for data storage. Although relational databases are adequate for accounting or other typical transaction-processing applications where the data types are simple and few in number, the relational model offers limited help when data types become numerous and complex.
Object-oriented databases are favored for applications where the relationships among elements in the database carry the key information. That is, object-oriented models capture the structure of the data; relational models organize the data itself. If a record can be understood is isolation, then the relational databases is probably suitable. If a record makes sense only in the context of other records, then an object-oriented database is more appropriate.
Subscribe to:
Comments (Atom)