Your business changes. Your data changes. You can’t stand still while trying to model all that data into one relational schema. You need a multi-model database to handle all your data in one unified platform. In the words of one MarkLogic customer, MarkLogic’s flexible data model “removes the shackles of relational technology.”

At its core, MarkLogic is a multi-model database. MarkLogic provides native storage for JSON, XML, RDF, geospatial, and large binaries (e.g., PDFs, images, videos). With this approach, it is easy to get all of your data in and easy to make changes later on. Load all of your data as is — structured and unstructured data (and your metadata!) — without cumbersome ETL processes. If you need to add another data source or make changes to your schemas later on, go on! It’s flexible. It’s fast. It’s iterative.


Diagram Flexible Data Model

Load All Your Data From Any Source

  • Structured data
  • Unstructured data
  • Metadata
  • Regulated data
  • ERP Systems
  • Mainframe data
  • Geospatial data
  • IoT, Clickstream
  • + more
  • Oracle
  • IBM DB2
  • SQL Server
  • Sybase
  • Teradata
  • Netsuite
  • MS Excel
  • NoSQL
  • Hadoop
  • File System
  • + more

The Document Model – Flexible and Human-Oriented

The document database is the most flexible of the NoSQL data models, and the most popular. Documents are ideal for handling varied and complex data. They are human-readable, they closely map to the conceptual or business model of the data, and they avoid the impedance mismatch problem that relational databases have.

Whether it’s Java objects that represents business entities or free flowing text from a “document” in the more traditional sense (Microsoft Word documents, PDFs, etc.), they are all naturally stored as JSON and XML documents in MarkLogic.
  • Fast development
  • Schema-agnostic
  • Natural for humans
  • Data “de-normalized” 
  • Improved search and query
  • Leverages all attributes 
  • Queries everything in context
  • Ideal for data integration

Example of a JSON document representing a surgical procedure at a hospital:

{ “hospital”: “Johns Hopkins”,
  “operationType”: “Heart Transplant”,
  “surgeon”: “Dorothy Oz”,
  “operationNumber”: 13,
  “drugsAdministered”: [
    { “drugName”: “Minicillan”,
      “drugManufacturer”: “Drugs R Us”,
      “doseSize”: 200, “doseUOM”: “mg” },
    { “drugName”: “Maxicillan”,
      “drugManufacturer”: “Canada4Less”,
      “doseSize”: 400, “doseUOM”: “mg” },
    { “drugName”: “Minicillan”,
      “drugManufacturer”: “Drugs USA”,
      “doseSize”: 150, “doseUOM”: “mg” }

Built-In Graph Database For Relationships

Documents are fantastic for storing entities. But, when it comes to relationships in data, a graph database is best. A graph database is designed to store and manage relationships among people, customers, providers, or anything else.

MarkLogic has a built-in RDF Triple Store (a type of graph database) for storing and managing semantic data. We call this capability MarkLogic Semantics. Semantics enhances the document model by providing a smart way to connect and enhance the JSON and XML documents that MarkLogic stores, which is important for data integration and more powerful querying.

Semantics also provides context for your data. For example, consider a database that has information about parts, and one part is listed with a size of “42.” But, where is the contextual information: What are the units of “42”? What is the tolerance? Who measured it? When was it measured? Who can see this data? That contextual information is the semantics of your data.

Learn More

Built In Graph

Still Want Structured, Relational Views of Your Data?

Sometimes it’s really useful to have structured, relational views of your data in tabular form that you can query with good ol’ standard SQL. With MarkLogic, your developers will feel right at home.

MarkLogic supports standard SQL. The underlying data never changes — it’s still documents in MarkLogic. But, we made it possible for you to create relational views of your data to view your documents in a relational, tabular form.

The underlying technology that makes this level of SQL support possible is unique to MarkLogic. It’s called Template Driven Extraction (TDE), and it enables you to define a relational lens over your document data so you can query parts of your data using standard SQL.

You can also use the new Optic API to query your relational views. The Optic API provides a unified query interface to query across documents, relational views, or graph views (or a combination of them). You can even use the Optic API to do joins and aggregates over documents. Try doing that with another document database!

MarkLogic Optic Api

How the Multi-Model Approach Improves Data Integration

MarkLogic is schema-agnostic, not schema-absent. Being schema-agnostic just means the schema can change and multiple schemas can co-exist in the same database. This capability makes data integration easier and faster because, unlike with relational, you don’t have to map all your data back to one agreed upon über schema. And, with MarkLogic’s powerful indexes, you can search and query across all of your data using your language of choice—whether it is JavaScript, XQuery, SQL, or SPARQL.

  • Load and search source data as is
  • Preserve lineage, provenance, other metadata
  • Harmonize only what you need
  • Update the model later without re-ingesting
  • New schemas don’t impact existing data and applications
Multi Model Approach

Resources for Everyone

For the Business: Are You Ready to Escape the Matrix?

Want to learn more about why the multi-model approach to data integration is better than the traditional approach with relational? Watch David Gorbet, MarkLogic’s SVP of Engineering, explain how to escape the matrix and free your mind from the tyranny of the machines and show you what you thought was impossible.

For Architects: Technical Advantages of a Multi-Model Database

Read our free O’Reilly eBook, “Building on Multi-Model Databases” to understand how to manage multiple schemas in a single platform. Look at practical examples that illustrate how multi-model databases reduce complexity and risk, and improve time-to-value.

For Developers: Multi-Model Data Modeling in 16 Minutes

This short tutorial provides a technical overview of best practices for data modeling with documents and triples, including techniques such as the envelope pattern and progressive enhancement.

Feature-Rich and Built for the Enterprise

This website uses cookies.

By continuing to use this website you are giving consent to cookies being used in accordance with the MarkLogic Privacy Statement.