{"id":3348,"date":"2014-09-29T15:54:08","date_gmt":"2014-09-29T15:54:08","guid":{"rendered":"http:\/\/www.odbms.org\/blog\/?p=3348"},"modified":"2014-09-30T15:38:58","modified_gmt":"2014-09-30T15:38:58","slug":"odbms-industry-watch-interview-jutta-bremm-peter-palm","status":"publish","type":"post","link":"https:\/\/www.odbms.org\/blog\/2014\/09\/odbms-industry-watch-interview-jutta-bremm-peter-palm\/","title":{"rendered":"Using NoSQL at BMW. Interview with Jutta Bremm and Peter Palm."},"content":{"rendered":"

“We need high performance databases for a wide range of challenges and analyses that arise from a variety of different systems and processes.”–Jutta Bremm, BMW<\/strong><\/p><\/blockquote>\n

BMW<\/a> is using a NoSQL database, CortexDB<\/a>, for the configuration of test vehicles. I have interviewed Jutta Bremm<\/strong>, IT Project Leader at BMW, and Peter Palm<\/strong>, CVO at Cortex.<\/p>\n

RVZ<\/p>\n

Q1. What is your role, and for what IT projects are you responsible for at BMW?<\/strong><\/p>\n

Jutta Bremm:<\/strong> I am IT Project Leader for IT projects at BMW with a volume of more than 10 million Euro per year.<\/p>\n

Q2. What are the main technical challenges you have at BWM?<\/strong><\/p>\n

Jutta Bremm:<\/strong> We need high performance databases for a wide range of challenges and analyses that arise from a variety of different systems and processes.<\/p>\n

These don\u2019t only include recursive, parameterized explosions for bills of materials, but also the provision of standardized tools to the business departments. That way, they can run their own queries more often and are not so dependent on IT to do it for them.<\/p>\n

Q3. You define CortexDB as a schema-less multi-model database. What does it mean in practice? What kind of applications is it useful for?<\/strong><\/p>\n

Peter Palm:<\/strong> In CortexDB<\/a>, datasets are stored as independent entities (cf. objects). To achieve this, the system transforms all content into a new type of index structure. This ensures that every item of content and every field \u201cknows\u201d the context in which it is being used. As a result, the database isn\u2019t searched. Instead, queries are run on information that is already known and the results are combined using simple procedures based on set theory.<\/p>\n

This is why there\u2019s no predefined schema for the datasets \u2013 only for the index of all fields and the content.
\nThis is what differentiates CortexDB from all other databases, which require the configuration of at least one index even though the datasets themselves are stored in schema-less mode.<\/p>\n

The innovative index structure means that no administrative adaptation or optimization of the index is necessary.
\nNor is there any requirement for an index for a specific applications \u2013 and that enables users to query all the content whenever they want and combine queries with each other too. That makes it very flexible for them to query any field and easily make any necessary development changes to in-house applications.<\/p>\n

From the server\u2019s perspective, the fields and content, as well as the interpretation of dataset structure and utilization, are not that important. The application working with the data creates a data structure that can be changed at any time (this is known as schema-less). For CortexDB, all that\u2019s relevant is the content-based structure, which can be used in a generalized way and modified any time. This design gives customers a significant advantage when working with recursive data structures.<\/p>\n

This is why CortexDB is particularly well suited to tasks whose definitive structure cannot be fixed at the beginning of the project, as well as for systems that change dynamically. The content-based architecture and the innovative index also deliver significant benefits for BI systems, as ad hoc analyses can be run and adapted whenever required.<\/p>\n

In addition, users can add a validity period (\u201cvalid from\u2026\u201d) to any item of content. This enables them to view the evolution of particular data over time (known as historization). This evolutionary information is ideal for storing data that change frequently, such as smart metering and insurance information. For each field in a dataset, users don\u2019t only see the information that was valid at the time of the transaction, but also the validity date after which the information was\/is\/will be valid. This is what we call a temporal database.<\/p>\n

These benefits are complemented by the fact that individual fields can be used alone or in combination with others and repeated within a dataset. This \u2013 together with the use of validity dates \u2013 is what we call a \u201cmulti-value\u201d database.<\/p>\n

The terms \u201cmulti-model\u201d, \u201cmulti-value\u201d and \u201cschema-less\u201d also explain the fact that benefits of the database functions mentioned above apply to other NoSQL databases<\/a> too, but users can extend these with new functions. In principle, any other database can be seen as a subset of CortexDB:<\/p>\n

Database type: Key\/Value Store<\/a><\/em>
\nFunction: One dataset = one key with one value (a value or value list) => a single, large index of keys
\nHow it works in CortexDB: Every value and every field is indexed automatically and can be freely combined with others by using an occurrence list<\/p>\n

Database type: Document Store<\/a><\/em>
\nFunction: One dataset combines several fields using a common ID (often json objects)
\nHow it works in CortexDB: One ID combines fields that belong together in a dataset. Datasets can be output as json objects via an API.<\/p>\n

Database type: GraphDB<\/a><\/em>
\nFunction: Links to other datasets are saved as meta information and can be used via proprietary graph queries.
\nHow it works in CortexDB: Links are stored as actual data in a dataset and can be edited using additional fields. Fields can be repeated as often as required.<\/p>\n

Database type: Big Table<\/a><\/em>
\nFunction: Multi-dimensional tables that use timestamps to define the validity of information. Its datasets can have a variety of attributes.
\nHow it works in CortexDB: The use of a validity date in addition to a transaction date delivers a temporal database. Additional content can be added despite the dataset description.<\/p>\n

Database type: Object oriented<\/a><\/em>
\nFunction: A class model defines the objects that need to be monitored persistently.
\nHow it works in CortexDB: With the Cortex UniPlex application, users can define dataset types. Compared with classes, these define the maximum attributes of a dataset. Nevertheless, users can add more fields at any time, even if they have not been defined for UniPlex.<\/p>\n

Q4. Can you please describe the use cases where you use CortexDB at BMW?<\/strong><\/p>\n

Jutta Bremm:<\/strong> The current use case for which we\u2019re working with CortexDB is the explosion of bills of material<\/a> for the configuration of test vehicles.<\/p>\n

The construction of test vehicles must be planned and timed just as carefully as with mass production. To make the process smoother, we conduct reviews before starting construction to ensure that the bills of materials include the right parts and are therefore complete and free of any errors and conflicts.<\/p>\n

One thing I\u2019d like to point out here is that every vehicle comprises 15,000 parts, so there are between 10\u00a0to the power of\u00a030 and 10\u00a0to the power of\u00a060 configuration possibilities! It\u2019s easy to understand why this isn\u2019t an easy task. This high variance is due to the number of different models, engine types, displacements, optional extras, interior fittings and colors. As a result, a development BOM can only be stored in a highly compressed format.<\/p>\n

To obtain an individual car from all this, the BOM must be \u201cexploded\u201d recursively. Multiple parameters have an effect on this, including validities (deadlines for parts, products, optional extras, markets etc.), construction stipulations (\u201cthis part can only be installed together with a navigation device and a 3-liter engine\u201d) and structures (\u201cthis part is comprised of several smaller parts\u201d).<\/p>\n

Unlike conventional solutions, for which an explosion function is complex and expensive, the interpretation of the compressed BOM is very easy for CortexDB due to its bidirectional linking technology.<\/p>\n

Q5. Why did you select CortexDB and not a classical relational database system? Did you compare CortexDB with other database management systems?<\/strong><\/p>\n

Jutta Bremm:<\/strong> We were looking for a product that would be easy to use, as well as simple and flexible to configure, for our users in product data management. We also wanted the highest possible level of functionality included as standard.<\/p>\n

We looked at 4 products that appeared to be suitable for use by the departments for analysis and evaluation. The essential functions for product data management \u2013 explosion and the documentation of components used \u2013 were only available as standard with CORTEX. For all other products, we were looking at customer-specific extensions that would have cost several hundred thousand euros.<\/p>\n

Q6. How do you store complex data structures (such as for example graphs) in CortexDB?<\/strong><\/p>\n

Peter Palm:<\/strong> CortexDB sees graphs as a derivative of certain database functions.<\/p>\n

Firstly, it uses the \u201cinternal reference\u201d field type (link). This is a data field in which the UUID<\/a> of a target dataset is stored. That alone enables the use of simple links.<\/p>\n

Second, users can choose to define fields as \u201crepeating fields\u201d. That means that the same field can also be used within a dataset. This is useful when a contact has more than one email address or phone number, and for links to individual parts in a BOM.<\/p>\n

Repeating fields defined in this way can be grouped together to produce \u201crepeating field groups\u201d. Content items that belong together are thus stored as an information block. An example of this is bank account details that comprise the bank\u2019s name, the sort code and the account number.<\/p>\n

The use of repeating field groups, in which validity values are added to linked fields, enables complex data structures within a single dataset.<\/p>\n

In addition, every dataset \u201cknows\u201d which other dataset is pointing to it. This bidirectional information using a simple link means that data administration is only required for one dataset. It is only necessary in both datasets if there are two conflicting points of view on a graph (e.g. \u201cmy friend considers me as an enemy\u201d).<\/p>\n

In addition, result sets can be combined with partial sets resulting from links when running queries and making selections. This limits the results to those that include certain details about their link structures.<\/p>\n

Q7. How do you perform data analytics with CortexDB?<\/strong><\/p>\n

Peter Palm:<\/strong> The content in every field \u201cknows\u201d the field context it is being used in and how often (“occurrence list” or “field index”). By combining partial sets (as in set theory), result sets are determined extremely fast, eliminating the need for read access to individual datasets.<\/p>\n

CortexDB comes with an application that lets users freely configure queries, reports and graphical output. There is also an application API (data service) that enables these elements to be used within in-house applications or interfaces.<\/p>\n

The solution also identifies correlations itself using algorithms, even if they are connected via graphs. Unlike data warehouse systems, this lets users do more than just test estimates or ideas \u2013 it determines a result on its own and delivers it to the user for further analysis or for modification of the algorithm.<\/p>\n

Q8. Do you some performance metrics for the analysis of recursive structured BOMs (bill of material) for your vehicles?<\/strong><\/p>\n

Jutta Bremm:<\/strong> Internal tests on BOM explosion with conventional relational databases showed that it took up to 120 seconds. Compare that with CortexDB, which delivers the result of the same explosion in 50 milliseconds.<\/p>\n

Q9. How do you handle data quality control? <\/strong><\/p>\n

Jutta Bremm:<\/strong> We require 100% data quality (consistency at all times) and CortexDB delivers that.<\/p>\n

Q10. What are the main business benefits of using CortexDB for these use cases?<\/strong><\/p>\n

Jutta Bremm:<\/strong> The agile modeling, the flexible adaptation options and the level of functionality delivered as standard shortens the duration of a project and reduces the costs compared to the other products we tested (see Q5).<\/p>\n

Qx. Anything else you wish to add?<\/strong>
\nJutta Bremm, Peter Palm: <\/strong>By using the temporal capabilities (time of transaction and time of validity), users can easily see which individual value in a dataset was\/is\/will be valid and from when.
\nIn addition, the server-side JavaScript is used to calculate ad hoc results from the recursive structure, eliminating the need for these to be calculated and saved in the database beforehand.<\/p>\n

——————–
\nJutta Bremm<\/strong>, IT Project Manager, BMW.
\nJutta is a IT Project Leader at BMW in product data management since 1987.
\nShe was involved in IT projects at Siemens, Wacker Chemie, Sparkassenverband since 1978.<\/em><\/p>\n

Peter Palm<\/strong>, Chief Visionary Officer (CVO) at Cortex.
\nStarted CortexDB development in 1997.
\nHolds a Master in electronic engineering.
\nArea of expertise: Computer hardware development, Chip design, Independent Design Center for Chip Design (Std-Cell, Gate Array), Operating system development, CRM development since 1986.<\/em><\/p>\n

Resources<\/strong><\/p>\n

– ODBMS.org: Resources related to Cortex.<\/a><\/p>\n

Related Posts<\/strong><\/p>\n

–NoSQL for the Internet of Things. Interview with Mike Williams. ODBMS Industry Watch,June 5, 2014<\/a><\/p>\n

– On making information accessible. Interview with David Leeming. ODBMS Industry Watch, July 30, 2014
\n<\/a>
\n– On SQL and NoSQL. Interview with Dave Rosenthal. ODBMS Indutry Watch, March 18, 2014<\/a><\/p>\n

Follow ODBMS.org on Twitter: @odbmsorg<\/a><\/strong><\/p>\n

##<\/p>\n","protected":false},"excerpt":{"rendered":"

“We need high performance databases for a wide range of challenges and analyses that arise from a variety of different systems and processes.”–Jutta Bremm, BMW BMW is using a NoSQL database, CortexDB, for the configuration of test vehicles. I have interviewed Jutta Bremm, IT Project Leader at BMW, and Peter Palm, CVO at Cortex. RVZ […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[35,728,723,729,724,725,726,412,413,727],"_links":{"self":[{"href":"https:\/\/www.odbms.org\/blog\/wp-json\/wp\/v2\/posts\/3348"}],"collection":[{"href":"https:\/\/www.odbms.org\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.odbms.org\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.odbms.org\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.odbms.org\/blog\/wp-json\/wp\/v2\/comments?post=3348"}],"version-history":[{"count":12,"href":"https:\/\/www.odbms.org\/blog\/wp-json\/wp\/v2\/posts\/3348\/revisions"}],"predecessor-version":[{"id":3494,"href":"https:\/\/www.odbms.org\/blog\/wp-json\/wp\/v2\/posts\/3348\/revisions\/3494"}],"wp:attachment":[{"href":"https:\/\/www.odbms.org\/blog\/wp-json\/wp\/v2\/media?parent=3348"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.odbms.org\/blog\/wp-json\/wp\/v2\/categories?post=3348"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.odbms.org\/blog\/wp-json\/wp\/v2\/tags?post=3348"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}