12.1. What are the origins of the object-oriented approach?
The origin of the object-oriented strategy is structured programming, and it helps in
signifies figures and maintains the concept of encapsulation and inheritance. The first
object-oriented language was Simula (Simulation of natural systems), developed in
1960 by researchers at the Norwegian Computing Center. The path towards an object-
oriented strategy is described, and several object-oriented programming languages are
examined. Since the object-oriented paradigm guaranteed to revolutionize software
development, in the 1990s, demand for object-oriented software systems grew
dramatically; consequently, several methodologies have been introduced to support
software development based on that model.
12.7. What is the difference between persistent and transient objects? How is
persistence handled in typical OO database systems?
Transient Objects are those that have been just instantiated. These objects don't have
description and identifier values in the databases. The garbage collector will destroy
the transient objects if they don't have any use and reference in the database.
Persistent Objects have representation in databases and identifiers. These objects are
produced and stored in any Objected Oriented database and persistent, i.e., their
instance exists even after the program is eliminated. Furthermore, these objects persist
until they are deleted explicitly by the user.
The persistence in Object-Oriented Databases is handled by creating Persistent
Objects and Transient Objects. As stated above, the persistent objects have
representations in the databases. An OO database can prolong the existence of objects
so that they are stored lastingly in a database. Hence, the objects become persistent
objects exceeding program termination and can be reclaimed later and shared by other
programs. In other words, OO databases store persistent objects permanently in
secondary storage and enable the sharing of these objects among multiple programs
and applications.
12.21. What is meant by the type orthogonality of OQL?
Object Query Language is a version of the Structured Query Language created for
use in Network Manager. The elements create and interact with their databases using
OQL.
Type orthogonality of OQL means properties, relationships, and operation name
scan is used correspondently within a path appearance, as long as the type method of
OQL is not negotiated. Thus, one can write the following queries to reclaim the grade
point average of all senior students majoring in Engineering, with the result ordered
by GPA, within that by last name and first name.
13.3. What are the differences between the use of tags in XML versus HTML?
HTML (HyperText Markup Language) and XML (eXtensible Markup Language)
both are used to create web pages and web applications.
XML is strict for the closing tag.
XML tags are extensible.
XML does not use predefined tags.
XML formats data in binary.
HTML doesn't provide namespaces support.
HTML is not strict for closing tag.
HTML has limited tags.
HTML does use predefined tags.
HTML formats data in plain text.
13.4. What is the difference between data-centric and document-centric XML
documents?
Data-Centric is one class of XML, uses XML as an interchange format. For example,
one computer transmits a message to another, often as part of a transaction, and this
message typically carries information that started or ended up in a database.
Data-centric XML is used to exchange data between machines.
Document-centric XML is used to exchange data between humans and between
machines. Markup without the data values less. Content is often stored in elements.
Document Centric uses XML to impose structure on information that unusually fits
into a relational database, mainly intended for publishing.
14.3. Why should NULLs in a relation be avoided as much as possible? Discuss
the problem of spurious tuples and how we may prevent it.
A NULL value indicates that no entry has been made into the column. They should
be avoided to dodge the complexity in select & update queries and because columns
with constraints like primary or foreign key constraints cannot contain a NULL value.
When aggregate operations such as SUM and AVG are performed on the attribute
with a null value, the result will be inaccurate.
When the JOIN operation comprises an attribute with null values, the result may be
inconstant.
The NULL value has a different meaning. For example, it may be undiscovered, not
appropriate, or absent.
Spurious tuples are created as the outcome of bad design or improper disintegration
of the base table. They are generated when a JOIN operation is performed on poorly
designed associations. The main obstacle with spurious tuples is that they are
recognized invalid as they do not appear in the base tables.
It can be avoided by:
The relations should be planned in such a way that when a JOIN operation is
executed, the attributes included in the JOIN operation must be a primary key in
one table and a foreign key in another table
While decomposing a base table into two tables, the tables must have a common
attribute. The expected attribute must be the primary key in one table and the
foreign key in another table.
15.2. What is meant by the completeness and soundness of Armstrong’s
inference rules?
Armstrong's axioms are the fundamental inference rule. Armstrong's axioms are used
to achieve functional dependencies on a relational database. The inference rule is a
type of contention. Thus, it can apply to functional dependencies to derive other
functional dependencies. Using the inference rule, we can derive further functional
dependence from the initial group.
Soundness
Armstrong's rules are sound: we can never derive dependencies that do not hold:
if Σ |− X → Y, then Σ |= X → Y.
completeness
Armstrong's rules are complete: if a dependency X → Y is a logical consequence of
Σ, then we can derive X → Y from Σ.
If Σ |= X → Y, then Σ |− X → Y.
15.7. Why are normal forms alone insufficient as a condition for a good schema
design?
Normal forms only help avoid a few problems in the schema. Other attributes and
documents are needed to support the schema thrive instead of dying.
When your system is easy and there is low traffic, a third simple form is enough.
When your system is complex and heavily loaded, you should examine how the
system reads from and writes to your database and separate data based on the
frequency of writes and reads.
References:
1. Elmasri, R., & Navathe, S. (2015). Fundamentals of Database Systems (7th ed.).
Pearson.
2. Elmasri, R., & Navathe, S. (2007). Fundamentals of database systems. Boston:
Pearson/Addison Wesley.
