Power by Design
|
Select A Section home public service database mgr data access data modeler site notes |
Currently In This Section AxleBase Nomenclature ( Please Scroll Down ) |
Section Pages summary description design limits notable tests shortcomings nomenclature operation |
|
This is a legally copyrighted work, Nomenclature Of Database Technology __________________________________________________ This address: jragan.com/axlenomen.htm#10.95.10 -- . -- Although inexact, the term "very large" is important in the database professions and has a special meaning. When a table is very large, support domains such as planning, budgets, hardware, manpower, etc. expand explosively beyond the ordinary. Before the outsourcing craze, very large data entities were managed and administered only by the top professionals. Although nebulous, it is common for professional publications, such as the AxleBase documentation, to use the term's acronym as though it has definitive meaning for a special class of table and database. For example, an understanding of the special nature of the AxleBase project assumes an acquaintence with the concept. The concept has been used through the years to mean a larger than ordinary object, but its application specificity has changed as hardware and software changed. That which was a very large table on a mainframe before the computer revolution is now routinely managed in a desktop database manager. The concept is based upon long and shared experience among those who work with databases and is assumed to exceed the "large" size. Part of its utility has come from its nebulous nature among professionals, but that cannot be tolerated when talking to others, so let's adopt a "ball park" number as a benchmark. This number is generally observed within AxleBase documents and will get little argument from professionals. Therefore, based on hands-on experience and general knowledge of the topic, let us arbitrarily say that a table is very large if it has a minimum of It is important to really look at that number. It is not just bigger than fifty million. A fifty billion row table has a thousand times more data than a fifty million row table, and can be that much more complex and costly to keep on line. Objects outside of tables are usually ignored by the "large" and "very large" concepts. Extraneous objects such as photographs, indices, etc. do require storage, and sometimes far more storage than do tables, but their management is trivial and secondary, so they are ignored when assessing the magnitude of a table. Notice also that row size is usually irrelevant unless it is very large; perhaps a million or so bytes. The term is seldom applied to a database, regardless of the number of data objects in it. It is usually applied when the database contains one or more very large tables. It is the table size that is important because the administration of such tables requires greater expertise and special tools such as AxleBase. ( If you gently insist that data professionals approximately adhere to your new concept while talking with you, they will seldom object.) ( Now that you have a handy definition, do not allow AxleBase to confuse the issue. The AxleBase project pushes beyond the very limits of human imagination ) Beyond Frontiers :
Two common acronyms :
End of Section. __________________________________________________ This address: jragan.com/axlenomen.htm#10.95.15 -- . -- "BLOB", pronounced blob, is the abbreviation or acronym for "binary large object". A few examples are photographs, scanned documents, architectural drawings, audio recordings, CT scans, and geology scans. Most BLOBs contain a lot of bytes and each is stored in its own file because of its size. A BLOB can be anything that can be stored in a computer file. It is therefore, not considered data. For example, "The Wizard Of Oz" restored movie occupies 200 terrabytes of storage, but that does not make it a database, a table, or even data. It is simply a large binary object; BLOB. Since they are not data, there is no need to store those large BLOB files in tables. Only their locations, called pointers, need to be in a table. When somebody wants the photo of a battleship, he specifies the battleship, the database manager looks it up in the table to find its pointer, and follows the pointer to the photo's file; usually faster than if those BLOBs were in the table. Managing BLOBs is extremely simple. AxleBase has been running a BLOB database for years with gigabytes of photos and audio recordings in it, but it is hardly worth note because the operation is so simple. Huge stores of astronomy photographs can be managed in tiny databases by inconsequential database managers. AxleBase can also store BLOBs inside a table. (See the "BLOB Discussions" in the Operating Manual page.) A problem with storing BLOBs within a table is that BLOBs are not data ; they can contain anything. That "anything" can even include control codes of the operating system, AxleBase, and host software. AxleBase offers tools that allow the DBA to create special tables to contain BLOBs, but that is not recommended. To the user, the two storage methods appear identical. The user requests the BLOB, and it is returned. Because of the way that they are handled, large text files such as letters, books, etc., are usually handled as BLOBs. However, AxleBase has special provisions for handling text files in data tables if necessary. ( Placing text files in data tables is not recommended and must be decided by the DBA before he designs and implements the database. ) Simplified Summation :
End of Section. __________________________________________________ A database is any organized collection of information. This address: jragan.com/axlenomen.htm#10.95.20 -- . -- Note the absence from that definition of the word "computer". The database concept was formalized because computers allow the management of very large databases, but databases have been around since the clay tablets of the ancient Sumerians, and will probably be around after the demise of the computer tool. Also, note the absence of software from the definition. A database and the software that manages it are distinctly separate, and they are as different as are an egg and an eggbeater. A database is simple data that is stored in an awesomely complex manner. A helpful concept is the table so that a database can be thought of as a collection of tables, each of which usually contains data about a certain kind of thing. Tables consist of rows that consist of columns. But you need not know much about the nature of a computer database because you will never encounter one. Even those who administer and work with them professionally do so entirely through database managers such as AxleBase. Simplified Summation :
End of Section. __________________________________________________ This address: jragan.com/axlenomen.htm#10.95.25 -- . -- Like much of database work, this is a simple concept that you can quickly grasp. But be cautioned that if you try to consider all of its ramifications, you may become overwhelmed by the complexities. There are types of databases such as relational, object oriented, hierarchical, etc.. The types are so different from each other at a fundamental level that each type must have its own type of database manager. The most useful and most widely used type is the relational database. AxleBase is identified as a relational database manager. A relational database consists of tables of data. A table has rows and columns that organize the data. The thing that makes it relational is the fact that the data in the various tables are related to each other so that the tables can be conceptually joined when data is requested from the database manager. For example, your personal information is in a row of a government table and your tax records are in rows in another table. Your personal record and your tax records can be easily joined together at will because your government control number is in the rows of both tables; i.e., the tables are related by that number. Notice that the name of the government control number is irrelevant; all that is important is that it makes the tables relational. Since the data is segmented in detail and there are many things relating the government's millions of tables, the relational database is a powerful tool. "Give me a list of people in New York who made over a million dollars last year." becomes a trivial operation. The raw data may or may not actually be stored in tabular form. Usually, it is not, for esoteric technical reasons, but that hardly matters because humans seldom ever see the raw data. The database manager is in charge of storing the data and in charge of maintaining and serving the human's tabular concept. It is perfectly valid for us to believe that our data is in tabular form because the database manager handles all of the technical details and is our interface to the database. ( The relational database was conceived by E.F. Codd, an American IBM mathematician, and has a succinct and rigorous definition that would be meaningless here. This one is far more practical for our purposes.) Simplified Summation :
End of Section. __________________________________________________ This address: jragan.com/axlenomen.htm#10.95.30 -- . -- A database manager is a tool, such as AxleBase, that manages a database and the data that it contains. ( "Manager" is a bit of a misnomer because it is only a tool that is used by the human manager, but the term is now in general use, so the person who manages databases and their database managers, regardless of their size and complexity, is called a database administrator (DBA).) Note the absence from that definition of the words "computer" and "software". The database manager of the ancient Sumerians was a team of priests who would rumage through their thousands of clay tablets looking for a bit of information (Ezra 5:17). Never before in all of Mankind's history have such powerful tools been available for the management of data as we now have on computers, but this, too, may be fleeting while the definition remains. But to temporarily bring our thoughts in line with those of the masses, let us state that a database manager is the computer software system that manages a database. The database manager seldom manages a single database. An AxleBase instance can easily manage many large databases. This is one of the many things that separate the database managers from the internet search engines and data warehouses. The actual tasks performed by database managers such as AxleBase are numerous beyond description and complex beyond the understanding even of their creators. Generally speaking, a database manager is told how we want the data managed and humans seldom need to look at it again. That includes massive operations such as copying millions of records to safety every night, and detailed operations such as finding a person's telephone when you dial the number, or demanding that age be entered on a person's record. It includes maintaining indices so your payment record can be found in a hundredth of a second instead of two centuries. And on and on... The database manager is one of the most complex systems built by Mankind. Simplified Summation :
Acronyms :
End of Section. __________________________________________________ This address: jragan.com/axlenomen.htm#10.95.33 -- . -- The terms "noSql database manager" and "non-relational database manager" were recently invented by marketing departments to legitimize a nonsensical parody of serious database managers. They are too nonsensical and ludicrous to be on this web site, but the masses are following the marketers, as usual, so let us address them here. A "noSql database manager" is one that is incapable of using standard SQL queries. That is not a minor shortcoming; SQL is the only tool that can effectively and reliably deliver data queries. A "noSql" DBMS uses various imitations of SQL with varying results, none of which compare favorably with even the simplest SQL queries. Whereas the SQL query is expected to perform a 100% reliable data return 100% of the time, the others peform returns that are known to be approximate. A "non-relational database manager" is one that is incapable of managing relational databases. There are fine specialized types of database managers that are not relational such as hierarchical, object-oriented, etc. that are professionally recognized, but this type is none of those. Its claim to fame is that it is simply incapable of managing relational databases. The marketers of one of those strange database managers has been calling it an object-oriented DBMS. It appears that they do so because their software stores information in an amorphous mass in a large pot. That is emphatically not the nature of a real object-oriented database. A genuine object-oriented database manager stores things in a well ordered, delineated, and labeled repository, and is specifically designed for management of objects. The term "object", also, is rigorously defined. For example, an object-oriented database may manage engineering drawings. The "noSql" and "non-relational" database managers are excellent models of the ancient Sumerian clay tablet archives. Their storage technology involves dumping a thing into a large room that is filled with things. When it is wanted, the computer or Sumerian priest is dispatched to rummage around in the large room to ( maybe ) find that which is needed. By using well known and professionally recognized terms in a deceitful manner, the marketers are attempting to share the respect for those terms with nonsensical software. Through the years, the masses have been able to destroy fine software in the marketplace by adopting and cheering for inferior software. Perhaps that will happen in this case. Beware of well-funded marketing departments in the computer business. Simplified Summation :
( We are blessed with a new generation of fools and their cattle herders every twenty years. This worthless section will be removed when the current brouhaha subsides. )
End of Section. __________________________________________________ This address: jragan.com/axlenomen.htm#10.95.35 -- . -- The classification of database managers has little to do with their types. Whereas the types correspond to their methods of managing data, the classes are approximately determined by the amount of data that they are able to control. Data professionals usually divide database managers into two classes :
The creation of AxleBase pushed the envelope out into an entirely new, and previously undreamed-of realm. His creation gave us a third class of database manager that sets far above the enterprise category wielding quantities so vast that are usually found only in astronomy. But the AxleBase class is still too new to be generally recognized. There may be no remaining undeveloped level in this classification because of the way that the technology works internally. The published AxleBase limit is artificially restrained. It was restrained years ago because there was fear that the vastness of his limits might seem humourous and therefore not be taken seriously. His restraint can be removed if needed. His internal technology and engineering can handle nearly any conceivable table size. ( Please. To protect us from self-pride, let us continually remind each other of him who does these things through men for his own purposes. ) Simplified Classes :
End of Section. __________________________________________________ This address: jragan.com/axlenomen.htm#10.95.40 -- . -- Databases are usually designed either for massive archival storage or for frequent processing of the data. The archival storage has little activity, whereas the active storage may undergo constant data inserts, deletes, and updates. The archival database is frequently referred to as a data warehouse or a Decision Support System, and the active database is known as an On-Line Transaction Processing database. (Decision Support Systems are sometimes referred to as On-Line Analytical Processing.) The distinction is non-trivial. Each type of storage requires very different database designs and administration. More importantly for us, is the fact that each type of database requires a different set of functions in the database manager. The importance of that can be seen because the organization usually must select a database manager before any other database decisions are made. Each domain is so different from the other that database managers are usually designed for one or the other. Some big name brands straddle the fence by throwing vast fortunes into hardware to compensate for their database manager's inabilities in one domain or the other. Updating a row in a twenty-trillion-row table is extremely complex. ( None can match the advanced architecture of AxleBase in this area. He supports OLTP in databases larger than any others of any type can even create. Yes, petabyte-sized table joins. Really.) Acronyms :
Simplified Summation :
End of Section.
__________________________________________________ -- . -- The database administrator is the person who is responsible for the database, for the software that manages it, and for the hardware that houses it. He is responsible for the integrity of the data and for its short term and long term safety. He is responsible for the data always being available when needed. He may also provide training and guidance in accessing data in the database. Although that very brief definition is accurate, it does not convey the esoteric complexity of some of the professional's duties. The administrator of a large mainframe database may deal in technical abstractions that are so incomprehensible that even if you think you understand a word that he used, you do not. Their work is so rarified and esoteric that professional certification would be a joke. They are the unsung heros of our civilization who cannot receive recognition because society cannot understand what they are doing at their terminals at three in the morning, but be certain of this, this civilization would stop without them. Acronym : DBA ( dee bee ae ) Simplified Summation :
End of Section. __________________________________________________ This address: jragan.com/axlenomen.htm#10.95.47 -- . -- Torrent Technology is the ability to digest a steady stream of vast quantities of data. This is becoming more of a problem as new ways of gathering data are found and as new uses are found for data. Data streams have surpassed anything that existed in the past. The problem currently is not that the data pipes are too small, but that they are able to carry such vast torrents of data. The problem arises at the destination where ordinary software systems and hardware are like a man trying to drink from a fire hose. Some data streams can easily overwhelm all ordinary software and hardware systems. New technologies are being developed to handle those data streams. For example, AxleBase can be configured to become the facilitating component of large arrays of data gathering systems. The Torrent Technology term was first used to describe AxleBase's power. Simplified Summation :
End of Section. __________________________________________________ This address: jragan.com/axlenomen.htm#10.95.48 -- . -- An "abend" is an abnormal, unexpected, or pathological ending. A system, software, or hardware crash might be called an abend.
End of Section. __________________________________________________ This address: jragan.com/axlenomen.htm#10.95.49 -- . -- If you have been around data management or system development for a while, then relax because the term "big data" is merely a rename of the old data warehouse functions. Surprisingly, it does not refer to big data stores. The term "big data" refers to data consumer operations, and seldom to the management of data stores. It usually refers to the analysis of data because people have rediscovered that computers can be used to process great amounts of information. Additionally, it usually deals with BLOBS because they contain a lot of bytes. Simplified Summation :
End of Section. __________________________________________________ This address: jragan.com/axlenomen.htm#10.95.50 -- . -- SQL is a computer language that is used to access and manipulate data in relational databases. SQL stands for structured query language and most people pronounce it as "seekwul". It is so common and easy to use that many people forget that it is a computer language, and even business executives routinely use it. It is so common that the acronym has become the name. SQL is a powerful tool for its purpose. Although it has practical and theoretical shortcomings as a language, it would be difficult to imagine a substitute. Because the database concept and the relational construct are woven into the foundation of the language, and because database managers such as AxleBase understand SQL, the language gives the ability to manipulate mountains of data with succinct statements. Those who use it routinely forget that they easily perform complex conceptual operations on their database that cannot be done any other way. Nearly all database managers around the world understand SQL. Therefore, someone who knows how to use SQL can access nearly any relational database anywhere in the world. It is so powerful that most programmers routinely embed SQL within the code of their primary programming language to perform data operations. SQL is itself, emphatically, not a programming language. It is a powerful query language. Fortunately, SQL is not owned or controlled by a brand name. Therefore, it has remained stable for decades and may be learned without fear of obsolescence or of anual "upgrades". It has become a true and solid standard in the data processing world. Simplified Summation :
End of Section. __________________________________________________ This address: jragan.com/axlenomen.htm#10.95.55 -- . -- A table is a concept and it is the major entity within a relational database. Hence, database professionals frequently refer to them as entities. A table is a collection of a specified type of data, and the type in each table is determined by the people who design the database. An airline company database might contain such tables as reservation, flight, airplane, and pilot. Each table has rows. The pilot table might have a row for each pilot. The reservation table might have a row for each reservation. Each row has columns. The pilot row might have a first name column, a last name column, and a hire-date column. The actual row and column types are determined by the people who design the database. It is sometimes helpful to visualize a table as a spreadsheet displayed on a computer monitor. But be sure to not confuse one with the other because they are entirely different things. Notice the interesting separation of the table from the database manager. Local administrators can design their databases as needed and the database manager will manage them. That flexibility is another characteristic of the database manager. Simplified Summation :
End of Section. __________________________________________________ This address: jragan.com/axlenomen.htm#10.95.57 -- . -- A tuple is similar to a row. A row is a component of a table, and a tuple is a component of a data return. A row is a real database component, but a tuple is a temporary construct that lasts only as long as the dataset lasts. You will seldom hear the term used. Data professionals, although they seldom use it, are very much aware of the tuples streaming out of their databases. Working alone on their many complex and abstract tasks, they are aware at all times of the permanent and the ephemeral; the row and the tuple. Simplified Summation :
End of Section. __________________________________________________ This address: jragan.com/axlenomen.htm#10.95.60 -- . -- Searching for a piece of information in a table can take more time than we want. If a computer takes a thousandth of a second to find a row, and the table contains a hundred million rows, then the search will take more than a day to find your friend's phone after you dial the number. You might consider that a problem. The solution to the problem is the index. To speed the search, the administrator issues a command to the database manager to create an index for that table. The index points to the information in the table so that a request for your friend's phone number will go directly (almost) to his name in the index to find the pointer to his row in the table. The pointer will be red, the system will follow it directly to his row in the table, and there read his phone number. Actually, that is a simplistic explanation; the index mechanism is far more complicated than that, but it is far far faster than reading the table despite its complexity. Because AxleBase is designed for extraordinarilly large tables, he provides an obvious example of the difference in speed. One of his test tables is so large that a thousand years would be needed to retrieve a piece of information, so it is indexed, which allows retrieval in seconds. Another interesting thing about indices is that a table usually has more than one. In our phone number example, there might be an index for the first names, one for the last names, and others. The indices for a table usually occupy more storage than does the table. Think of a book's index because a database index is conceptually similar. Paging through the book to find something is simple, but very slow. Using the index is more complicated, but much faster. If you have red this far, you may be wondering about the actual structure of the indexer in a database manager; how it does its magic. Each database manager has its own proprietary index mechanism. The indexer is the most complex sub-system in AxleBase; an entire book would be needed to describe it, and it is being extended even as this is being written. The indexer that converts massive and complex logic paths into speed is part of the hidden magic of computer science that runs your world. An interesting aspect of the AxleBase indices is that they are designed for very large table searches, meaning that they contain mechanisms that are not needed by ordinary database managers. They search very large tables extremely fast, and cannot search ordinary tables as fast as can ordinary database managers. Simplified Summation :
Examples :
( Data retrieval speed is an example of why those of us who build database managers become obsessed with numbers.)
End of Section. __________________________________________________ This address: jragan.com/axlenomen.htm#10.95.65 -- . -- The word "virtual" in general English usage is the honest man's way of telling a lie. Subtle issues accompany it, but that is its primary usage. If somebody says that something is virtually true, then it is certainly not true. The same usage is found in computer systems. If X is a virtual object, then you know that X is certainly not one of those objects. It usually bears a resemblance to its namesake with common logical roots and common functional usage. The best teacher in this case is an example. Most computer operating systems can create and use virtual disk drives. A virtual drive may be part of a disk, or part of memory, or someplace on another computer, and may be used like a real disk drive, but it is certainly not a disk drive and is certainly confusing, but virtual disks are helpful management tools. There are many reasons for virtual objects. In the case of AxleBase, the administrator may want to express many remote identical tables as a single table in the local database. He can do that through a virtual table. (The virtual tables of AxleBase are totally unlike those of the big-name brands.) Simplified Summation :
End of Section. __________________________________________________ No amount of steam valve improvement can make the steam locomotive a new technology. Cloud computing may actually predate the internet. This address: jragan.com/axlenomen.htm#10.95.75 -- . -- When cloud computing was first used, it was called time sharing because the users were sharing time on a remote mainframe. The user had a modem and a simple terminal, such as a teletype machine, that sent commands to a distant mainframe computer that processed the information and returned a response. That is the essence of what is today called cloud computing. Today's equipment is faster and cheaper, but cloud technology remains the same. Cloud computing is a remote data processor to which many terminals are connected. Even the old time-sharing concepts are resurfacing. Cloud computing is a simple client-server system that is different from distributed computing. The first terminals were called "dumb terminals" since they had no computing power. Later terminals were smart because they could do simple tasks such as updating the local display. The great power of today's PC is wasted as a terminal, so we may soon see the loss of personal power into the cloud. Cloud computing is a technology throwback to the mainframe and its new rise may cause technology to decline just as feudalism fed the dark ages. Many factors are driving the resurgence of old-fashioned cloud computing :
Simplified Summation :
( A historical note :
End of Section. __________________________________________________ This address: jragan.com/axlenomen.htm#10.95.80 -- . -- Concurrency in database operations refers to the simultaneous use of a database by multiple users and/or systems; i.e., concurrent usage. The concurrency problem is complex and heavy for database managers because they must service many clients simultaneously with high speed operations of the infrastructure. Simplified Summation :
End of Section. __________________________________________________ This address: jragan.com/axlenomen.htm#10.95.83 -- . -- File Server :
Node :
Most database managers use file servers. Few database managers have nodes. Most of those that claim to have nodes, do not. AxleBase uses both file servers and nodes, and their usage depends upon how the DBA configures AxleBase. He can place data on remote computers, which makes those computers file servers, and he can simultaneously have nodes operating on other computers or on the file server computers. Some system nodes are a bit more complex than the above description. An AxleBase node, for example, consists of an AxleBase instance, a host, communication software, communication hardware, and the computer on which all of it runs. Simplified Summation :
End of Section. __________________________________________________ This address: jragan.com/axlenomen.htm#10.95.85 -- . -- DASD is an old mainframe acronym that stands for Direct Access Storage Device. It usually refers to disk drives, but can be any storage device. It is a convenient term when working with systems such as AxleBase that can use any kind of storage that the infrastructure supports. It is usually pronounced as dazdee. Advanced technology has found a new need for the old DASD term. AxleBase has been tested with CDs, floppy drives, hard disks, and USB flash drives that simultaneously participated in storing a single data table that was distributed across them. Simplified Summation :
End of Section.
__________________________________________________
-- . -- Metadata is technically descriptive data about data. In a working setting, the metadata of a table gives the DBA a standardized description of the table's contents. It is usually given by column and can include datatype, length, and many other characteristics. Datatype includes a specific group of categorical terms such as "text", "numeric", "decimal", "boolean", etc. The location of data does not usually impact its metadata. If, for example, a database contains messages, its tables may be a message body table, a date table, and a recipient name table. All of those tables contain data; not metadata. The data is separated into those tables merely by the way in which the DBA designed that database, and not because any of that data is metadata. When using AxleBase, a table's metadata is obtained by submitting the command, ShowTable. The same can be done for a database, a database's columns, etc. Because it is technically descriptive, metadata is also used by systems. For example, AxleBase consults his metadata constantly as data is moved in or altered to insure the validity of the operation. He also sends a metadata header along with data that he sends to other systems. Metadata is a precise term that identifies a technical description of data, so the way that the term was used in the NSA's presentation to congress concerning its illegal and immoral universal surveillance was totally incorrect and misleading. Simplified Summation :
End of Section.
__________________________________________________
-- . -- This pertains to naming locations in a computer and in a network of computers.
When a computer is attached to a network of computers that can see and talk to each other, they must also use network locations on other computers. To avoid confusion, the shared computer storage locations on a network use the UNC (universal naming convention). The UNC is in the form
End of Section. |
|
Web site and technology |
|
|
Web site is maintained with Notepad.
|
|