Object-Oriented Database: Adoption of Object Databases

Download as doc, pdf, or txt
Download as doc, pdf, or txt
You are on page 1of 5

Object-oriented database

An object database (also object-oriented database) is a database model in which information is represented in the form of objects as used in object-oriented programming. When database capabilities are combined with object-oriented (OO) programming language capabilities, the result is an object database management system (ODBMS). Todays trend in programming languages is to utilize objects, thereby making OODBMS ideal for OO programmers because they can develop the product, store them as objects, and can replicate or modify existing objects to make new objects within the OODBMS. Information today includes not only data but video, audio, graphs, and photos which are considered complex data types. Relational DBMS arent natively capable of supporting these complex data types. By being integrated with the programming language, the programmer can maintain consistency within one environment because both the OODBMS and the programming language will use the same model of representation. Relational DBMS projects using complex data types would have to be divided into two separate tasks: the database model and the application. As the usage of web-based technology increases with the implementation of Intranets and extranets, companies have a vested interest in OODBMS to display their complex data. Using a DBMS that has been specifically designed to store data as objects gives an advantage to those companies that are geared towards multimedia presentation or organizations that utilize computeraided design (CAD). Some object-oriented databases are designed to work well with object-oriented programming languages such as Ruby, Python, Perl, Java, C#, Visual Basic .NET, C++, Objective-C and Smalltalk; others have their own programming languages. ODBMSs use exactly the same model as object-oriented programming languages. Adoption of object databases Object databases based on persistent programming acquired a place in application areas such as engineering and spatial databases, telecommunications, and scientific areas such as high energy physics and molecular biology. They have made little impact on mainstream commercial data processing, though there is some usage in specialized areas of financial services. Technical features Most object databases also offer some kind of query language, allowing objects to be found by a more declarative programming approach. It is in the area of object query languages, and the integration of the query and navigational interfaces, that the biggest differences between products are found. An attempt at standardization was made by the ODMG with the Object Query Language, OQL. Access to data can be faster because joins are often not needed (as in a tabular implementation of a relational database). This is because an object can be retrieved directly without a search, by following pointers. (It could, however, be argued that "joining" is a higher-level abstraction of pointer following.) Another area of variation between products is in the way that the schema of a database is defined. A general characteristic, however, is that the programming language and the database schema use the same type definitions. Multimedia applications are facilitated because the class methods associated with the data are responsible for its correct interpretation. Many object databases, for example VOSS, offer support for versioning. An object can be viewed as the set of all its versions. Also, object versions can be treated as objects in their own right. Some object databases also provide systematic support for triggers and constraints which are the basis of active databases. Advantages and disadvantages The main benefit of creating a database with objects as data is speed. OODBMS are faster than relational DBMS because data isnt stored in relational rows and columns but as objects. Objects have a many to many relationship and are accessed by the use of pointers. Pointers are linked to objects to establish relationships. Another benefit of OODBMS is that it can be programmed with small procedural differences without affecting the entire system. This is most helpful for those organizations that have data relationships that arent entirely clear or need to change these relations to satisfy the new business requirements. Benchmarks between OODBMSs and RDBMSs have shown that an OODBMS can be clearly superior for certain kinds of tasks. The main reason for this is that many operations are performed using navigational rather than declarative interfaces, and navigational access to data is usually implemented very efficiently by following pointers. Compared to relational databases another major advantage of OODBMSs is that they do not need any object relational mapping layer and object marshaling to map the application object model to the database object model. In RDBMS, this mapping is also source of the impedance mismatch, which does not occur when using OODBMS. Avoiding this layer also improves performance and saves effort for implementation and maintenance. Critics of navigational database-based technologies like ODBMS suggest that pointer-based techniques are optimized for very specific "search routes" or viewpoints; for general-purpose queries on the same information, pointer-based techniques will tend to be slower and more difficult to formulate than relational. Thus, navigation appears to simplify specific known uses at the expense of general, unforeseen, and varied future uses.[citation needed] However, with suitable language support, direct object references may be maintained in addition to normalised, indexed aggregations, allowing both kinds of access; furthermore, a persistent language may

index aggregations on whatever its content elements return from a call to some arbitrary object access method, rather than only on attribute value, which allows a query to 'drill down' into complex data structures. Other things that work against ODBMS seem to be the lack of interoperability with a great number of tools/features that are taken for granted in the SQL world, including but not limited to industry standard connectivity, reporting tools, OLAP tools, and backup and recovery standards.[citation needed] Additionally, object databases lack a formal mathematical foundation, unlike the relational model, and this in turn leads to weaknesses in their query support. However, this objection is offset by the fact that some ODBMSs fully support SQL in addition to navigational access, e.g. Objectivity/SQL++, Matisse, and InterSystems CACH. Effective use may require compromises to keep both paradigms in sync.

Distributed database
A distributed database is a database that is under the control of a central database management system (DBMS) in which storage devices are not all attached to a common CPU. It may be stored in multiple computers located in the same physical location, or may be dispersed over a network of interconnected computers. Collections of data (e.g. in a database) can be distributed across multiple physical locations. A distributed database can reside on network servers on the Internet, on corporate intranets or extranets, or on other company networks. Replication and distribution of databases improve database performance at end-user worksites. To ensure that the distributive databases are up to date and current, there are two processes: replication and duplication. Replication involves using specialized software that looks for changes in the distributive database. Once the changes have been identified, the replication process makes all the databases look the same. The replication process can be very complex and time consuming depending on the size and number of the distributive databases. This process can also require a lot of time and computer resources. Duplication on the other hand is not as complicated. It basically identifies one database as a master and then duplicates that database. The duplication process is normally done at a set time after hours. This is to ensure that each distributed location has the same data. In the duplication process, changes to the master database only are allowed. This is to ensure that local data will not be overwritten. Both of the processes can keep the data current in all distributive locations. Besides distributed database replication and fragmentation, there are many other distributed database design technologies. For example, local autonomy, synchronous and asynchronous distributed database technologies. These technologies' implementation can and does depend on the needs of the business and the sensitivity/confidentiality of the data to be stored in the database, and hence the price the business is willing to spend on ensuring data security, consistency and integrity. Basic architecture A database User accesses the distributed database through: Local applications applications which do not require data from other sites. Global applications applications which do require data from other sites. A distributed database does not share main memory or disks. Important considerations Care with a distributed database must be taken to ensure the following: The distribution is transparent users must be able to interact with the system as if it were one logical system. This applies to the system's performance, and methods of access among other things. Transactions are transparent each transaction must maintain database integrity across multiple databases. Transactions must also be divided into subtransactions, each subtransaction affecting one database system.

Advantages of distributed databases Management of distributed data with different levels of transparency. Increase reliability and availability. Easier expansion. Reflects organizational structure database fragments are located in the departments they relate to. Local autonomy a department can control the data about them (as they are the ones familiar with it.) Protection of valuable data if there were ever a catastrophic event such as a fire, all of the data would not be in one place, but distributed in multiple locations. Improved performance data is located near the site of greatest demand, and the database systems themselves are parallelized, allowing load on the databases to be balanced among servers. (A high load on one module of the database won't affect other modules of the database in a distributed database.)

Economics it costs less to create a network of smaller computers with the power of a single large computer. Modularity systems can be modified, added and removed from the distributed database without affecting other modules (systems). Reliable transactions - Due to replication of database. Hardware, Operating System, Network, Fragmentation, DBMS, Replication and Location Independence. Continuous operation. Distributed Query processing. Distributed Transaction management.

Single site failure does not affect performance of system. All transactions follow A.C.I.D. property: a-atomicity, the transaction takes place as whole or not at all; c-consistency, maps one consistent DB state to another; i-isolation, each transaction sees a consistent DB; d-durability, the results of a transaction must survive system failures. The Merge Replication Method used to consolidate the data between databases. Disadvantages of distributed databases Complexity extra work must be done by the DBAs to ensure that the distributed nature of the system is transparent. Extra work must also be done to maintain multiple disparate systems, instead of one big one. Extra database design work must also be done to account for the disconnected nature of the database for example, joins become prohibitively expensive when performed across multiple systems. Economics increased complexity and a more extensive infrastructure means extra labour costs. Security remote database fragments must be secured, and they are not centralized so the remote sites must be secured as well. The infrastructure must also be secured (e.g., by encrypting the network links between remote sites). Difficult to maintain integrity in a distributed database, enforcing integrity over a network may require too much of the network's resources to be feasible. Inexperience distributed databases are difficult to work with, and as a young field there is not much readily available experience on proper practice. Lack of standards there are no tools or methodologies yet to help users convert a centralized DBMS into a distributed DBMS. Database design more complex besides of the normal difficulties, the design of a distributed database has to consider fragmentation of data, allocation of fragments to specific sites and data replication. Additional software is required. Operating System should support distributed environment. Concurrency control: it is a major issue. It is solved by locking and timestamping.

Client server databases


The clientserver model of computing is a distributed application structure that partitions tasks or workloads between the providers of a resource or service, called servers, and service requesters, called clients. Often clients and servers communicate over a computer network on separate hardware, but both client and server may reside in the same system. A server machine is a host that is running one or more server programs which share their resources with clients. A client does not share any of its resources, but requests a server's content or service function. Clients therefore initiate communication sessions with servers which await incoming requests. Description The clientserver characteristic describes the relationship of cooperating programs in an application. The server component provides a function or service to one or many clients, which initiate requests for such services. Functions such as email exchange, web access and database access, are built on the clientserver model. Users accessing banking services from their computer use a web browser client to send a request to a web server at a bank. That program may in turn forward the request to its own database client program that sends a request to a database server at another bank computer to retrieve the account information. The balance is returned to the bank database client, which in turn serves it back to the web browser client displaying the results to the user. The clientserver model has become one of the central ideas of network computing. Many business applications being written today use the clientserver model. So do the Internet's main application protocols, such as HTTP, SMTP, Telnet, and DNS. The interaction between client and server is often described using sequence diagrams. Sequence diagrams are standardized in the Unified Modeling Language. Specific types of clients include web browsers, email clients, and online chat clients.

Specific types of servers include web servers, ftp servers, application servers, database servers, name servers, mail servers, file servers, print servers, and terminal servers. Most web services are also types of servers. Comparison to peer-to-peer architecture In peer-to-peer architectures, each host or instance of the program can simultaneously act as both a client and a server, and each has equivalent responsibilities and status. Both clientserver and peer-to-peer architectures are in wide usage today. Details may be found in Comparison of Centralized (Client-Server) and Decentralized (Peer-to-Peer) Networking. Advantages In most cases, a clientserver architecture enables the roles and responsibilities of a computing system to be distributed among several independent computers that are known to each other only through a network. This creates an additional advantage to this architecture: greater ease of maintenance. For example, it is possible to replace, repair, upgrade, or even relocate a server while its clients remain both unaware and unaffected by that change. All data is stored on the servers, which generally have far greater security controls than most clients. Servers can better control access and resources, to guarantee that only those clients with the appropriate permissions may access and change data. Since data storage is centralized, updates to that data are far easier to administer in comparison to a P2P paradigm. In the latter, data updates may need to be distributed and applied to each peer in the network, which is both time-consuming and error-prone, as there can be thousands or even millions of peers. Many mature clientserver technologies are already available which were designed to ensure security, friendliness of the user interface, and ease of use. It functions with multiple different clients of different capabilities.

Disadvantages As the number of simultaneous client requests to a given server increases, the server can become overloaded. Contrast that to a P2P network, where its aggregated bandwidth actually increases as nodes are added, since the P2P network's overall bandwidth can be roughly computed as the sum of the bandwidths of every node in that network. The clientserver paradigm lacks the robustness of a good P2P network. Under clientserver, should a critical server fail, clients requests cannot be fulfilled. In P2P networks, resources are usually distributed among many nodes. Even if one or more nodes depart and abandon a downloading file, for example, the remaining nodes should still have the data needed to complete the download.

knowledge based database


A knowledge base (abbreviated KB, kb or ) is a special kind of database for knowledge management, providing the means for the computerized collection, organization, and retrieval of knowledge. Also a collection of data representing related experiences, their results are related to their problems and solutions. The knowledge based systems are artificial intelligent tools working in a narrow domain to provide intelligent decisions with justification. Knowledge is acquired and represented using various knowledge representation techniques rules, frames and scripts. The basic advantages offered by such system are documentation of knowledge, intelligent decision support, self learning, reasoning and explanation. [also add Reference: Akerkar RA and Sajja Priti Srinivas: Knowledge-based systems, Jones & Bartlett Publishers, Sudbury, MA, USA (2009)] Knowledge bases are categorized into two major types: Machine-readable knowledge bases store knowledge in a computer-readable form, usually for the purpose of having automated deductive reasoning applied to them. They contain a set of data, often in the form of rules that describe the knowledge in a logically consistent manner. An ontology can define the structure of stored data - what types of entities are recorded and what their relationships are. Logical operators, such as And (conjunction), Or (disjunction), material implication and negation may be used to build it up from simpler pieces of information. Consequently, classical deduction can be used to reason about the knowledge in the knowledge base. Some machine-readable knowledge bases are used with artificial intelligence, for example as part of an expert system that focuses on a domain like prescription drugs or customs law. Such knowledge bases are also used by the semantic web. Human-readable knowledge bases are designed to allow people to retrieve and use the knowledge they contain. They are commonly used to complement a help desk or for sharing information among employees within an organization. They might store troubleshooting information, articles, white papers, user manuals, knowledge tags, or answers to frequently asked questions. Typically, a search engine is used to locate information in the system, or users may browse through a classification scheme. A text based system that can include groups of documents including hyperlinks between them is known as Hypertext Systems. Hypertext systems support the decision process by relieving the user of the significant effort it takes to relate and remember things." Knowledge bases can exist on both computers and mobile phones in a hypertext format.

Knowledge base analysis and design (also known as KBAD) is an approach that allows people to conduct analysis and design in a way that results in a knowledge base, which can later be used to make informative decisions. This approach was first implemented by Dr. Steven H. Dam.

You might also like