Database

Database migration
Database design
Public data sets
https://restdb.io/

Articles

ACID:
A: Atomicity (ALL or NONE)
C: Consistency. The transaction should leave the system in a consistent state.
I: Isolation. If there are two transaction T1, and T2, and they are executed 
   in parallel. The result should be the same as though they were executed in 
   sequence.
D: Durability. After the changes are done, even if the system crash, when it 
   come back online, the result should be the same (the value of the change 
   should be persistent). The result of the transaction should be saved 
   completely.

The 3 problems that a fully ACID compliant database have to deal with:

1. Dirty read: a read is done while there is another parallel transaction 
     updating the same cell.
2. Non-repeatable read: in the same transaction, you execute the same query but 
   get different result, because another transaction has either insert, delete, 
   or update rows.
3. Phantom read: This is similar to non-repeatable read, but in the case of
   non-repeatable read, you get the same row back, but you may get different
   values for the individual cells, or no row is return.  When the phantom read,
   you may get more rows or less rows because another transaction has either
   insert, delete, or update rows.

The 4 isolation levels:

1. Read uncommitted: When a transaction try to read, it may get an uncommitted 
   result of another ongoing transaction. This is not a good isolation level. 
   This level does not solve any of the 3 common read problems.
2. Read committed: When a transaction try to read, it will wait until other 
   transaction committed.  This is accomplished using a write lock.
3. Repeatable reads: This isolation level solves the "dirty read" problem and 
   the "non-repeatable read" problem by using a write lock, and a read lock.
4. Serializable: This isolation level solves all 3 problems by using a write lock,
   a read lock and a range lock

Example of Consistency: Consider that we are transfering $100 dollar from
one account (A) to another account (B).  Let say that the initial amount in
account A is $1000 and the initial amount in account B is $200.  This is a two
steps process.  First, $100 is deducted from account A.  Second, $100 is 
deposited into account B.  If the system failed in between the two steps, the
transaction should be rolled back.  The total amount between the two accounts
should be $12,000.  If the transaction succeeded, the total amount between
two accounts should also be $12,000, assuming that we do not charge a fee
for the service.

What does ACID abbreviate for?

  1. A -> Atomicity (ALL or NONE)
  2. C -> Consistency. The transaction should leave the system in a consistent state.
  3. I -> Isolation. If there are two transaction T1, and T2, and they are executed in parallel. The result should be the same as though they were executed in sequence.
  4. D -> Durability. After the changes are done, even if the system crash, when it come back online, the result should be the same (the value of the change should be persistent). The result of the transaction should be saved completely.

What are the 3 problems that a fully ACID compliant database have to deal with?

  1. Dirty read: a read is done while there is another parallel transaction updating the same cell.
  2. Non-repeatable read: in the same transaction, you execute the same query but get different result, because another transaction has either insert, delete, or update rows.
  3. Phantom read

What are the 4 isolation levels?

  1. Read uncommitted: When a transaction try to read, it may get an uncommitted result of another ongoing transaction. This is not a good isolation level. This level does not solve any of the 3 common read problems.
  2. Read committed: When a transaction try to read, it will wait until other transaction committed.
  3. Repeatable reads: This isolation level solves the "dirty read" problem and the "non-repeatable read" problem by using a read lock.
  4. Serializable: This isolation level solves all 3 problems by using a read lock and a range lock
Isolation level / read problem Dirty read Non-repeatable read Phantom read
Read uncommitted problem problem problem
Read committed SOLVED problem problem
Repeatable reads SOLVED SOLVED problem
Serializable SOLVED SOLVED SOLVED

https://www.periscopedata.com/ab
http://www.sitepoint.com/0xdbe-first-look

http://foxydb.com/
firebase
pouchdb
MySQL
Oracle

MongoDB
Redis
Cassandra
NoSQL
Liquibase
Vertica
Distributed Databases

Memcache
MemcacheDB

DB Visual Architect

http://couchdb.apache.org/
http://www.couchbase.com

Greenplum (Both Commercial and Open-source)
Infobright (Both Commercial and Open-source)
KDB
Kickfire
ParAccel
SAND CDBMS
SAP HANA
Sensage
Sybase_IQ
Vectorwise
Vertica
LucidDB
Metakit
MonetDB
C-Store
S (programming language) and R (programming language) incorporate column-oriented data structures for statistical analyses
HBase is an open source, non-relational, distributed database modeled after Google's BigTable and is written in Java. It is developed as part of Apache Software Foundation's Apache Hadoop project and runs on top of HDFS (Hadoop Distributed Filesystem), providing BigTable-like capabilities for Hadoop. That is, it provides a fault-tolerant way of storing large quantities of sparse data. HBase features compression, in-memory operation, and Bloom filters on a per-column basis as outlined in the original BigTable paper.[1] Tables in HBase can serve as the input and output for MapReduce jobs run in Hadoop, and may be accessed through the Java API but also through REST, Avro or Thrift gateway APIs. HBase is not a direct replacement for a classic SQL Database, although recently its performance has improved, and it is now serving several data-driven websites,[2][3] including Facebook's Messaging Platform.

http://www.sitepoint.com/rethinkdb-ruby-map-reduce-joins/
http://www.sitepoint.com/a-look-at-orientdb-the-graph-document-nosql/
NoSQL

Teradata
ProClarity
Cloud 9 Query Builder
HANA Database

Things that I need to expand on

  • When to use each of these model?
  • What are some software / vendors available for each of these model?
  • What is the difference between hierarchical model and network model?
  • How do hierarchial model and network model store data in memory and on disk? How is this compared to relational model?
  • What are the disadvantage of relational model compared to other models?
  • What does a relational DBMS have to do to store the data in memory or on disk?

What is a Data Dictionary?

Data Dictionary is a set of tables that are used to maintain information about "real" tables, indexes, clusters, etc.

What does DDL abbreviate for?

Data Definition Language. These commands are used to create and modify schema objects. These commands provide ability to create, alter, and drop objects; grant and revoke privileges and roles; establishing auditing options, and add comments to the data dictionary. These commands are related to the management and administration of the database.

What does DML abbreviate for?

Data Manipulation Language. These command allows you to query and modify data within existing schema objects. DML statements consist of DELETE, INSERT, SELECT, UPDATE, EXPLAIN, LOCK TABLE

What is the difference between Object-Relational Model and Object-Oriented Model?

I am not 100% sure on this, but I think the difference maybe:

Object-Relational Model has some concept of object oriented programming, but the data is stored using relational tables where complex data structure must be flattened out to fit into tables or joined together from those tables to form the in-memory structure. Object-Relational database management systems (ORDBMSs) add ability to store object to the relational systems. This allows integrated management of traditional fielded data, and complex objects geospatial data and diverse binary media such as audio, video, images, and applets. By encapsulating methods with data structures, an ORDBMS server can execute comple x analytical and data manipulation operations to search and transform multimedia and other complex objects.

Object-Oriented Model bring database functionality (persistent storage) to object programming languages. Object-Oriented Model extends the semantics of the C++, Smalltalk and Java object programming languages to provide full-featured database programming capability, while retaining native language compatibility. A major benefit of this approach is the unification of the application and database development into a seamless data model and language environment. The object-oriented model / database (OODB) paradigm is the combination of object-oriented programming language (OOPL) systems and persistent systems. The power of the OODB comes from the seamless treatment of both persistent data, as found in databases, and transient data, as found in executing programs.

Object-Oriented Model have no performance overhead to store or retrieve a web or hierarchy of interrelated objects. This one-to-one mapping of object programming language objects to database objects has two benefits over other storage approaches: it provides higher performance management of objects, and it enables better management of the complex interrelationships between objects. This makes object DBMSs better suited to support applications such as financial portfolio risk analysis systems, telecommunications service applications, world wide web document structures, design and manufacturing systems, and hospital patient record systems, which have complex relationships between data.

Object-Oriented Model may imply embedding relational database or object-relational database inside your application. Object-Oriented Model may also imply extending the language in such a way that the developer do not have to worry much about the nitty gritty of how the data is stored or retrieved. Think about a system where developer do not have to use SQL (all the SQL stuff for getting data and saving data is abstracted away underneath the objects). Think of Object-Oriented Model as a programming language or extension to a programming language where there is minimal concept or existence of a database (it is there, but almost completely abstracted away underneath the objects or nearly hidden from developers, and developers do not have to use SQL)

What is the Hierarchical Model?

The hierarchical model organizes data in a tree structure. There is a hierarchy of parent and child data segments. An organization might store information about an employee's children. The employee and children data forms a hierarchy, where employee's data represent the parent segment, and the children data represent the child segment. If an employee has three children, then there would be three child segments associated with one employee segment. In a hierarchical database, the parent-child relationship is one to many. This restricts a child segment to only one parent segment. Hierarchical DBMSs were popular from late 1960 through 1970s.

What is the Network Model?

The popularity of the network data model coincided with the popularity of the hierarchical data model. Some data were more naturally modeled with more than one parent per child. So, the network model permitted the modeling of many to many relationships in data. The basic data modeling construct in the network model is the set construct. A set consists of an owner record type, a set name, and a member record type. A member record type can have that role in more than one set, hence the multiparent concept is supported (a record can have the role of "child" for multiple parents, or record can have the role of "parent" for multiple children). An owner record type can also be a member or owner in another set. The data model is a simple network, and link and intersection record types (called junction records by IDMS) may exist, as well as sets between them . Thus, the complete network of relationships is represented by several pairwise sets; in each set some (one) record type is owner (at the tail of the network arrow) and one or more record types are members (at the head of the relationship arrow).

What is the Relational Model?

A relational database allows the definition of data structures, storage and retrieval operations and integrity constraints. In such a database, the data and relations between them are organized in tables. A table is a collection of records and each record in a table contains the same fields.

What is the Object/Relational Model?

ORDBMS add new object storage capabilities to the relational systems. These new facilities integrate management of traditional field data, complex objects such as time-series and geospatial data and diverse binary media such as audio, video, images, and applets. By encapsulating methods with a data structures, and ORDBMS server can execute complex analytical and data manipulation operations to search and transform multimedia and other complex objects. ORDBMS inherit the robust transaction and performance from RDBMS, and the flexibility of its object-oriented cousin. Database designers can work with familiar tabular structures and data definition languages while assimilating new object-management possibilities. Query and procedural languages and call interfaces in ORDBMSs are familiar: SQL3, vendor procedural languages, and ODBC, JDBC, and proprietary call interfaces are all extensions of RDBMS languages and interfaces. Leading vendors are IBM, Informix, and Oracle.

What is the Object-Oriented Model?

Object DBMSs (OODB) add database functionality to object programming languages. They bring much more than persistent storage of programming language objects. Object DBMSs extend the semantics of the C++, Smalltalk and Java object programming languages to provide full-featured database programming capability, while retaining native language compatibility. A major benefit of this approach is the unification of the application and database development into a seamless data model and language environment. As a result, applications require less code, use more natural data modeling, and code bases are easier to maintain. Object developers can write complete database applications with a modest amount of additional effort.

The object-oriented database (OODB) paradigm is the combination of object-oriented programming language (OOPL) systems and persistent systems. The power of the OODB comes from the seamless treatment of both persistent data, as found in databases, and transient data, as found in executing programs.

In contrast to a relational DBMS where a complex data structure must be flattened out to fit into tables or joined together from those tables to form the in-memory structure, object DBMSs have no performance overhead to store or retrieve a web or hierarchy of interrelated objects. This one-to-one mapping of object programming language objects to database objects has two benefits over other storage approaches: it provides higher performance management of objects, and it enables better management of the complex interrelationships between objects. This makes object DBMSs better suited to support applications such as financial portfolio risk analysis systems, telecommunications service applications, world wide web document structures, design and manufacturing systems, and hospital patient record systems, which have complex relationships between data.

What is the Semi-structured Model?

In semistructured data model, the information that is normally associated with a schema is contained within the data, which is sometimes called “self-describing”. In such database there is no clear separation between the data and the schema, and the degree to which it is structured depends on the application. In some forms of semistructured data there is no separate schema, in others it exists but only places loose constraints on the data.

Semi-structured data is naturally modelled in terms of graphs which contain labels which give semantics to its underlying structure. Such databases subsume the modelling power of recent extensions of flat relational databases, to nested databases which allow the nesting (or encapsulation) of entities, and to object databases which, in addition, allow cyclic references between objects.

Semistructured data has recently emerged as an important topic of study for a variety of reasons. First, there are data sources such as the Web, which we would like to treat as databases but which cannot be constrained by a schema. Second, it may be desirable to have an extremely flexible format for data exchange between disparate databases.

What is the Associative Model?

The associative model divides the real-world things about which data is to be recorded into two sorts:

  • Entities are things that have discrete, independent existence. An entity’s existence does not depend on any other thing.
  • Associations are things whose existence depends on one or more other things, such that if any of those things ceases to exist, then the thing itself ceases to exist or becomes meaningless.

An associative database comprises two data structures:

  1. A set of items, each of which has a unique identifier, a name and a type.
  2. A set of links, each of which has a unique identifier, together with the unique identifiers of three other things, that represent the source source, verb and target of a fact that is recorded about the source in the database. Each of the three things identified by the source, verb and target may be either a link or an item.

For additional information, refer to:

What is the Entity-Attribute-Value (EAV) Model?

The best way to understand the rationale of EAV design is to understand row modeling (of which EAV is a generalized from). Consider a supermarket database that must manage thousands of products and brands, many of which have a transitory existence. Here, it is intuitively obvious that product names should not be hard-coded as names of columns in tables. Instead, one stores product descriptions in a Products table: purchases/sales of individual items are recorded in other tables as separate rows with a product ID referencing this table.

Conceptually an EAV design involves a single table with three columns:

  1. an entity (such as an olfactory receptor ID)
  2. an attribute (such as species, which is actually a pointer into the metadata table)
  3. a value for the attribute (e.g., rat).

In EAV design, one row stores a single fact. In a conventional table that has one column per attribute, by contrast, one row stores a set of facts. EAV design is appropriate when the number of parameters that potentially apply to an entity is vastly more than those that actually apply to an individual entity.

For detail information on EAV, refer to The EAV/CR Model of Data Representation

What is the Context Model?

The context data model combines features of all the above models. It can be considered as a collection of object-oriented, network and semistructured models or as some kind of object database. In other words this is a flexible model, you can use any type of database structure depending on task. Such data model has been implemented in DBMS ConteXt.

The fundamental unit of information storage of ConteXt is a CLASS. Class contains METHODS and describes OBJECT. The Object contains FIELDS and PROPERTY. The field may be composite, or object of another class. The property is a set of fields that belongs to particular Object. (similar to AVL database). In other words, fields are permanent part of Object but Property is its variable part.

The header of Class contains the definition of the internal structure of the Object, which includes the description of each field, such as their type, length, attributes and name.

Context data model has a set of predefined types as well as user defined types. The predefined types include not only character strings, texts and digits but also pointers (references) and aggregate types (structures).

A context model comprises three main data types: REGULAR, VIRTUAL and REFERENCE.

A regular (local) field can be ATOMIC or COMPOSITE. The atomic field has no inner structure. In contrast, a composite field may have a complex structure, and its type is described in the header of Class. The composite fields are divided into STATIC and DYNAMIC. The type of a static composite field is stored in the header and is permanent. The type of a dynamic composite field is stored within the Object and can vary from Object to Object.

Like a NETWORK database, apart from the fields containing the information directly, context database has fields storing a place where this information can be found, i.e. POINTER (link, reference) which can point to an Object in this or another Class. Because main addressed unit of context database is an Object, the pointer is made to Object instead of a field of this Object. The pointers are divided on STATIC and DYNAMIC. All pointers that belong to a particular static pointer type point to the same Class (albeit, possibly, to different Object). In this case, the Class name is an integral part of the that pointer type. A dynamic pointer type describes pointers that may refer to different Classes. The Class, which may be linked through a pointer, can reside on the same or any other computer on the local area network. There is no hierarchy between Classes and the pointer can link to any Class, including its own.

In contrast to pure object-oriented databases, context databases is not so coupled to the programming language and doesn't support methods directly. Instead, method invocation is partially supported through the concept of VIRTUAL fields.

A VIRTUAL field is like a regular field: it can be read or written into. However, this field is not physically stored in the database, and in it does not have a type described in the scheme. A read operation on a virtual field is intercepted by the DBMS, which invokes a method associated with the field and the result produced by that method is returned. If no method is defined for the virtual field, the field will be blank. The METHODS is a subroutine written in C++ by an application programmer. Similarly, a write operation on a virtual field invokes an appropriate method, which can changes the value of the field. The current value of virtual fields is maintained by a run-time process; it is not preserved between sessions. In object-oriented terms, virtual fields represent just two public methods: reading and writing. Experience shows, however, that this is often enough in practical applications. From the DBMS point of view, virtual fields provide transparent interface to such methods via an aplication written by application programer.

A context database that does not have composite or pointer fields and property is essentially RELATIONAL. With static composite and pointer fields, context database become OBJECT-ORIENTED. If the context database has only Property in this case it is an ENTITY-ATTRIBUTE-VALUE database. With dynamic composite fields, a context database becomes what is now known as a SEMISTRUCTURED database. If the database has all available types… in this case it is ConteXt database!

You can download the conteXt DBMS from UnixSpace Download Center (you have to search for ConteXt using CTRL+F after this page is loaded)

For more information see: Concepts of the ConteXt database

What is one of the weak point of a relational database?

A relational database management system must show its data as two-dimensional tables, of columns and rows, but store it as one-dimensional string. For example, a database might have this table (see the first page of http://en.wikipedia.org/wiki/Column-oriented_DBMS)

This table exists in the computer's memory (RAM) and storage (hard drive). There are some differences between RAM and hard drive. Still, the database must coax its two-dimensional table into one-dimensional series of bytes for the operating system to write to either RAM or the hard drive or both.

A row-oriented database serializes all of the values in a row together, then the values in the next row, and so on.

A column-oriented database serializes all of the values of a column together, then the values of the next column, and so on.

This is a simplification. Partitioning, indexing, caching, views, OLAP cubes, and transactional systems such as write ahead logging and multiversion concurrency control all dramatically affect the physical organization. That said, online transactional processing (OLTP)-focused RDBMS systems are more row-oriented, while online analytical processing (OLAP)-focused systems are a balance of row-oriented and column-oriented.

Following is a set of over-simplified observations which attempts to paint a picture of the trade-offs between column-oriented systems versus row-oriented systems:

  • Column-oriented systems are more efficient when an aggregate needs to be computed over many rows but only for a notably smaller subset of all columns of data because reading that smaller subset of data can be faster than reading all the data.
  • Column-oriented systems are more efficient when new values of a column are supplied for all rows at once because that column data can be written efficiently and replace old values without touching any other columns.
  • Row-oriented systems are more efficient when many columns of a single row are required at the same time, and when row-size is relatively small because the entire row can be retrieved with a single disk seek
  • Row-oriented systems are more efficient when writing a new row if all of the data for the row is supplied at the same time because the entire row can be written with a single disk seek.

In practice, row-oriented architectures are well-suited for OLTP workloads / systems, which are more heavily loaded with interactive transactions. Column-oriented architectures are well-suited for OLAP-like workloads / systems (like data warehouses) which typically involve a smaller number of highly complex queries over all data (possibly terabytes). However, there are a number of proven row-based OLAP RDBMS that handles terabytes, or even petabytes, such as Teradata.

Column data is of uniform type. Therefore, there are some opportunities for storage size optimizations (compression) available in column-oriented data that are not available in row-oriented data. For example, many popular modern compression schemes, such as LZW or run-length encoding, make use of the similarity of adjacent data to compress. While the same techniques may be used on row-oriented data, a typical implementation will achieve less effective result.

Columnar compression achieves a reduction in disk space at the expense of efficiency of retrieval (the data need to be uncompressed when we need to read from disk, or compressed when we need to write to disk). The question is whether we should use compression if disk space is not limited. Due to this trade off between disk space and efficiency, column-oriented architectures are sometimes (but not always) accompanied by additional mechanisms aimed at minimizing the need to access compressed data.

Is column-oriented RDBMS better than row-oriented RDBMS?

Not always. It depends on what it is intended for.

Are there proven row-based OLAP RDBMS that can handle terabytes, or even petabytes of data?

Yes, such as Teradata.

What are the different Columnar RDBMS implementations (vendors)?

  1. TAXIR: was the first application of column-oriented database storage system with focus on information-retrieval in biology in 1969
  2. RAPID: was implemented by Statistics Canada in 1976 and used for its processing and retrieval of the Canadian Census of Population and Housing as well as several other statistical applications. RAPID was shared with other statistical organizations throughout the world and used widely in the 1980s. It continued to be used by Statistics Canada until the 1990s..
  3. Sybase IQ: was, for many years, the only commercially available product in the column-oriented DBMS industry. However, that has changed rapidly in the last few years with many open source and commercial implementations.
  4. 1010data is a privately-held company that provides a cloud-based software platform and associated services for complex business analytics on and database publishing of very large data sets. The 1010data service is used in a variety of industries, including financial services, retail, consumer packaged goods, telecom, insurance, and others.
  5. Aster Data Systems is a data management and analysis software company. Aster Data's nCluster is a massive parallel processing analytic database management system that runs on a cluster of commodity servers. The architecture of Aster nCluster is optimized for data warehousing and analytic applications, also called Online analytical processing (OLAP) as opposed to Online Transaction Processing (OLTP). Aster Data created a framework called SQL-MapReduce that allows the Structured Query Language (SQL) to be used with the MapReduce technology. Teradata had acquired Aster Data Systems in 2011. An early large customer of Aster Data Systems was MySpace, which used the product primarily for clickstream analysis by 2008. Other clients include comScore, LinkedIn, Share This, Intuit, Akamai, and Full Tilt Poker. Aster Data Systems relies on partnerships with solution providers and technology companies to complement its nCluster database. Featured technology partners include Dell for its hardware platform, MicroStrategy to integrate MapReduce and business intelligence software, and Informatica's data integration software. See MapReduce, SQL-MapReduce® Resources & Learning, Introduction to Aster Data and nCluster
  6. InfiniDB by Calpont. (Both Commercial and Open-source) Calpont is a database management software company based in Frisco, TX. Calpont makes InfiniDB, a scalable, software-only columnar database for analytic applications. InfiniDB has been selected as finalist in the Best Database Solution category at the 26th and 27th SIIA Annual CODiE Awards. InfiniDB Enterprise is a scalable database built for Big Data analytics, business intelligence, data warehousing and other read-intensive applications. InfiniDB's column-store architecture enables very quick load and query times. Its massive parallel processing (MPP) technology scales linearly with any type of storage hardware, growing as analytic needs and data volumes grow. InfiniDB is accessed through a MySQL interface. It then parallelizes queries and executes in a Map-Reduce fashion. Each thread within the distributed architecture operates independently, avoiding thread-to-thread or node-to-node communication that can cripple scaling. InfiniDB is used to enable performance-intensive analytic applications. Current customers include Bandwidth.com, Tucows, Warner Music Group, Aviation Software International, Navigant Consulting and 1&1 Internet. Calpont resellers worldwide include SkySQL (including many former MySQL employees) and KK Ashisuto in Japan. InfiniDB can be used in two varieties: InfiniDB Community Edition and InfiniDB Enterprise Edition. InfiniDB Community Edition (CE) is an open-source version of the database that can be used at no charge. (See applicable license restrictions.) However, CE doesn’t support MPP scale-out and has other limited features. InfiniDB Enterprise Edition (EE) is the commercial version of InfiniDB. It supports scaling out to any number of nodes. Both editions of InfiniDB offer a Hadoop connector free-of-charge.
  7. EXASolution from EXASOL. EXASOL is an analytic database management software company. Its product is called EXASolution, a RDBMS. EXASolution is a parallelized relational DBMS which runs on a cluster of standard hardware servers. Following the SPMD model, on each node the identical code is executed simultaneously. The data is stored in a column-oriented way and proprietory InMemory compression methods are used. The company claims that tuning efforts are not necessary since the database includes some kind of automatic self-optimization (like automatic indices, table statistics, and distributing of data). Furthermore, EXASolution is designed to run In Memory, although data is persistently stored on disc following the ACID rules. EXASolution supports the SQL Standard 2003 and can be integrated via standard interfaces like ODBC, JDBC or ADO.NET. Additionally, a SDK is provided for native integration. The license model is based on the allocated RAM for the database software (per GB RAM) and independent to the physical hardware. Customers gain the maximal performance if their compressed active data fits into that licenced RAM, but it can also be much larger. EXASOL has implemented a so called Cluster Operating System (EXACluster OS). It is based on standard Linux and provides functionality for parallel programs. It can be compared to Virtualization, but instead of virtualizing the hardware of a single server, it virtualizes a cluster of nodes to a single one. Cluster management algorithms are provided like failover mechanisms or automatic cluster installation. See http://www.exasol.com/en/exasolution/technical-details.html
  8. FAME: (Forecasting Analysis and Modeling Environment) is a time series database from SunGard which comes along with a suite of APIs and domain-specific programming language. FAME was originally developed by GemNet, an independent development company located in Ann Arbor, Michigan, and was purchased by Citigroup in 1984. During this time, development focused on creating and improving the database engine and extending the FAME 4GL scripting language. Citigroup sold FAME to private investors headed by Warburg Pincus in 1994. Management focused on fixing bugs, developing remote database server access to FAME, and invested in expanding the FAME database engine. Emphasis was also placed on extending FAME by creating an object-oriented Java interface called TimeIQ (now called the FAME Java Toolkit) that replicated the features of FAME 4GL in Java. This period also saw the release of accessPoint (now known as FAME Web Access), which provides URL access to FAME objects and multiple output formats. The acquisition of FAME by SunGard in 2004 resulted in a new set of priorities that focused on the core FAME engine and on extending the 4GL scripting language, including:
    • Modernizing the connections into the FAME database environment for better integration with enterprise software solutions
    • Support for Services Oriented Architectures (SOA) via the FAME Web Access middleware server
    • Creating workflow-oriented dashboards and wizards for extracting, transforming and loading data into FAME databases
    • Improving querying tools, including connectors to third-party applications
    • Extending managed content, including tools for building metadata on top of FAME databases
    • Another key goal has been to modernize the tools that support working in the FAME software environment. For example, developers have worked to leverage FAME Web Access and transform FAME into software that can be run as a service. This allows developers and architects to plug the online analytical processing capabilities of the FAME software into existing enterprise software and empower these internal systems to better handle the complex queries made by financial professionals.
    • Many of today’s FAME customers run the environment within an overall technology stack, providing improved access and wider distribution of data and analytics. Rather than access standalone FAME installations, these enterprise-oriented technology teams load FAME databases and procedures within a Multiple Client Analytical Database Server (MCADBS), providing access to FAME data via browser applications, Microsoft Excel, statistical applications and advanced reporting systems such as Crystal Reports.
    • See http://en.wikipedia.org/wiki/FAME_%28database%29
  9. Fluidinfo, formerly named FluidDB until early 2011, is an online cloud data store based on an attribute-value centric data model. Fluidinfo is written in Python and characterized by a publicly writeable schema-less database that provides a query language, a fine-grained permissions model and promotes data sharing, both publicly and in groups. See http://en.wikipedia.org/wiki/FluidDB

What does ACID abbreviate for?

NEED TO COMPLETE THIS

What is a trigger?

Trigger is a mechanism that allows you to write procedure that are automatically executed whenever an INSERT, UPDATE, or DELETE statement is executed on a table or view. Trigger can be used to enforce integrity constraints or automate some other custom function.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License