MINISIS Database Architecture
MINISIS Database Architecture MINISIS is uniquely different from other typical data management solutions in that it is neither a hierarchical nor relational database; rather, it is a hybrid of the two. Below is a discussion of how MINISIS operates and how it differs from other solutions. Hierarchical Databases Hierarchical database technology was the first major data model to be largely accepted. Many legacy servers have been hosting hierarchical databases for decades. A hierarchical database operates on the principle that a record will contain groups of similar objects. These groups are organized into a cascading hierarchy. As can be seen in the diagram to the right, sales information is embedded right into a customer’s record. Inside the sales sub-group is information about the items sold, and inside that group, information about the manufacturers of those items. Repeating groups
Most hierarchical databases support the concept of repeating groups (a group of fields that may store multiple values). For example, in the diagram to the right, a customer could have many sales listed in his name. These would be handled by adding a separate entry for each sale into the Sale repeating group. The concept behind a hierarchical database model is that sales information is part of a customer’s record and should therefore be stored with customer information. Hierarchical databases are typically very fast and conceptually simple; unfortunately, they are usually inflexible due to their flat file structures. XML and LDAP are two technologies that use hierarchical data models effectively. However, many complex systems are more easily built with relational database models.
Written by Steve Kwan (
[email protected])
Page 1/6
MINISIS Database Architecture Many-to-many relationships
The most significant limitation in a hierarchical database structure is the inability to support many-to-many relationships. As seen in the diagram to the right, we can state that an item has more than one manufacturer, because we can make the manufacturer a repeating group. The screwdriver here was made by two organizations: ABC Inc. and DEF Inc. However, we cannot state that a manufacturer has made many items. That is, if ABC Inc. makes screwdrivers and hammers, we can only store information on the screwdriver.
Referential integrity
If we wanted to store information on the hammer, we would have to duplicate all of ABC Inc.’s information and copy it into a record for the hammer. This is known as a lack of referential integrity, and is a significant limitation in the database structure. Having to copy the same record to multiple areas of the database is inefficient and can cause serious data flaws if the records are changed.
Written by Steve Kwan (
[email protected])
Page 2/6
MINISIS Database Architecture
Relational Databases Relational databases are a common alternative to the hierarchical databases described in the prior section. Many information systems are too complicated to be modeled as a hierarchical database. In these cases, relational data models may be more practical. SQL
In a relational database, different data groups are separated into their own databases. These databases are linked together via complex query statements (such as those used in SQL, the Structured Query Language). Relational databases do not usually suffer from the referential integrity problems that occur in hierarchical databases. However, relational databases are usually more complex and significantly slower than hierarchical databases.
Database scattering
Unfortunately, one of the largest drawbacks of a relational database is its inability to handle queries efficiently. For example, examine the diagram on the right. Because different portions of a transaction are stored in different databases, more work is required to gather that data if a query is performed.
Written by Steve Kwan (
[email protected])
Page 3/6
MINISIS Database Architecture
If, for example, a user wished to determine to run a report on all sales to Bill Smith, the database engine would have to do the following: 1. Find Bill Smith in the Customer table 2. Use Bill Smith’s ID to find all related Sales information in the Sale table 3. Use the Item IDs in the item table to find all the items that Mr. Smith purchased 4. Use the Manufacturer IDs in the Item table to find out who made the items Mr. Smith purchased. If a hierarchical database were being used, and the same report was run, the database would: 1. Find Bill Smith in the Customer table and report his sales information. As the previous steps indicate, with a hierarchical database only one database needs to be opened to conduct the example sales search; if a relational database is in use, four databases must be opened, which will take quite a bit longer. Aside from speed, the other major problem with relational database engines is their complexity. Relational databases are generally far more complex than hierarchical ones, and usually require dedicated programmers to build and administer them. Because there are usually more databases involved in a relational model, the query statements required to do searches are quite complex. SQL (a common query language) is so complicated that its specifications are 1,100 pages long. No vendor has ever fully implemented the SQL standard.
Written by Steve Kwan (
[email protected])
Page 4/6
MINISIS Database Architecture
MINISIS: A Hybrid Database MINISIS is a hybrid of hierarchical and relational database concepts. Hierarchical and relational data models both have significant strengths and weaknesses; MINISIS strives to capitalize on the strengths of both data models. In MINISIS, it is possible to implement a fully hierarchical database, a fully relational database, or some combination of the two. A sample MINISIS database is shown to the right. The Customer database has a hierarchically nested database called Sale, whereas the Item database has a hierarchically nested database called Manufacturer. However, despite the hierarchical nature of these two databases, they are linked via a relational join. It is this level of flexibility that makes MINISIS so easy to optimize and modify: it can be as fast or as flexible as you need it to be. Malleability
With MINISIS, you can structure a database to fit into your business logic. You can design complicated hierarchical data blocks, or link them relationally – whichever makes the most sense to you. Other database engines – particularly relational ones – force the user to “think like a programmer” by imposing complicated database design upon the user.
Optimization
Due to MINISIS’ malleable nature, optimizing your database is simple. Because parts of your database will likely be created with hierarchical databases, your system will likely be optimized by design as it is built.
Written by Steve Kwan (
[email protected])
Page 5/6
MINISIS Database Architecture
XML
Due to its extensive flexibility, MINISIS can work together with almost any other data protocol. For example, MINISIS has no difficulty importing/exporting XML data. Many other databases are incapable of properly dealing with XML, as it is generally provided as a flat file. To the right is a diagram that explains how MINISIS handles XML. A relational database would have trouble importing the example XML file provided, because the XML file has a hierarchical structure. A hierarchical database would have less difficulty importing the file, because the database could be built to match the XML format. With the database shown below, XML data from the above file could be imported right into the database. MINISIS supports XML importing through various formats such as Dublin Core, with more formats being added all the time.
ODBC
MINISIS also supports ODBC importing. Several different engines can handle XML, and several ODBC, but not many can handle both, as MINISIS can do. ODBC is a relational database concept, whereas XML is a hierarchical one. Most databases would have trouble handling both of these very important protocols. Because MINISIS is a hybrid engine, it is capable of both XML and ODBC compatibility.
Written by Steve Kwan (
[email protected])
Page 6/6