Why SAP HANA Database and HANA Architecture is a Relational Database

Executive Summary

  • The SAP HANA database is often described as a columnar database, but what is this?
  • We fact-check whether SAP statements the SAP HANA database being lower maintenance than what SAP HANA replaces.

Introduction

SAP has given a strange storyline to their HANA architecture and database, and as a consequence, there are a great many misunderstood topics on the SAP HANA database. One of the greatest is that SAP HANA database is somehow not a relational database.

To explain why this is not the case we will get into the HANA architecture. That topic is what this article will focus on.

HANA Architecture Changes in Hardware, Changes in Query Capability and Changes in Table Structures with the SAP HANA Database

The changes to the data storage structure are that data can be stored in columns rather than as “rows.” This is a primary component to the HANA architecture. This is often stated in the literature on the topic, but it is not normally clear why this is the case. In fact, at first glance, it appears that it should be the opposite. A columnar database still has rows, but each row is only one field. It is perhaps more accurate to say that the data can be stored in columns, that would look a bit like this.

Tom, Jason, Julie, Stan, Jack, Jack, Blake, Fred, Rebecca, etc..

The Name Table

There are several flaws in the conventional explanation of columnar databases, which explain why columnar databases are still considered mysterious to many people that consume the messaging on this topic. It is also why often the hype appears to overshadow the understanding of this subject.

Several of these flaws have been described up to this point, but a third flaw in the standard explanation is that columnar databases are not the opposite of or set to replace relationally (or should I say row based) databases. In fact, a columnar database is as relational as a row based database. Because a columnar database still has tables pointing to other tables.

Therefore it is not like a Big Data database like NoSQL.

Maintenance

Database Maintenance Issues

Relational databases can take a lot of maintenance, which is part of the role of a database administrator. Tables often have custom columns added to them, which makes each table less efficient for a variety of tasks.

Using Specialized Structures Build for Analytics

The disadvantage of standard relational databases for analysis has been known since analytical applications have been in use, and have been addressed at various points in the history of database design with data cubes.

Data cubes pre-build relationships. And which are run from specialized or not standard relational databases, as well as star schemas, which allow queries to be performed on a dedicated data structure where a predefined combination of tables is used within a standard relational database.

The Use of Data Cubes

Data cubes have been utilized for a long time to speed the ability to retrieve data.

Data cubes do have more overhead, and HANA architecture or a column based on memory database generally, can have many advantages over cubes, in addition to requiring much less IT overhead, and reports development is a major bottleneck in most companies. But the HANA architecture has had problems making the database dueal mode, that is as good at other types of database processing other than analytics processing for which column oriented designs are optimized.

Once queries can be changed, this means how that how data is stored needs to change to leverage this shift.

HANA Architecture and Reducing Unruly Table Growth

Another benefit of columnar databases is that they do not lead to the unruly growth of tables. As was previously noted, many analytical tables have 100 or even 200 columns. This is because new attributes are added to existing tables over time. As each column is added, queries slow. The more columns that are added, the more time it takes the database to find any one field as it must scan the entire row. Therefore table growth does directly lead to slower database queries. This is why the columnar database scales so much better than the row based design. Each new column is added to its table.

However, it should be understood that this does increase the number of tables in the database, and the relationships that have to be created. Although because of less redundancy, the total amount of data that is stored is lower.

For instance, if we take the example of color, if a color is not recorded at one point, and then recorded and added to the database, rows may often increase in number as what was once aggregated to a universal color is now broken into multiple colors that apply to that record.

This greatly depends upon the details, but several scenarios are possible.

Other Areas of Maintenance

As tables grow in columns, they require more maintenance. Row-based or what is known as relational databases do require more indexes and do have other overhead. Some of this overhead is reduced with column based databases. However, other types of maintenance increase with column based databases.

Secondly, the column-based database has far less history on which to base support claims. This is because there are so few column based databases in use. But maintenance is not necessarily lower simply because of the HANA architecture. There are other factors at play.

  • Column-based databases also have far fewer people trained in how to work with them, so the similar metaphors would apply to purchasing a car that very few people own.
  • Few mechanics who work on that car will mean higher cost and lower availability of the required skills.
  • Overall, much more data is required before anything substantial can be said about the maintenance costs of column-based databases. And this is not the only question.

What is the Accuracy SAP’s Communicated HANA Architecture?

When HANA was introduced and for several years after SAP gave a distinct impression that the HANA architecture was 100% column-based. However, after several years it was communicated that many of HANA’s tables were row-oriented.

Advice on Enjoying the Quiz

To see the full screen just select the lower right-hand corner and expand. Trust us, expanding makes the experience a whole lot more fun.

 

Conclusion

Columnar databases are relational databases as are row-based databases. A better explanation would be to call databases that store mixed data in single tables that are not organized as non-relational, but even that can be a confusing topic.

Relationships still exist with a columnar database, and in fact, there are more of them because there are now more “tables” that are each table being a column.

The SAP HANA is most definitely a relational database design.

SAP’s statements regarding lower maintenance on the SAP HANA database are most undoubtedly unproven, and while SAP can point to some technical support improvements, it is mostly guesswork. The SAP HANA architecture, as with any columnar databases has some areas that are lower in maintenance than traditional databases. But other areas are higher in maintenance.

Secondly, SAP HANA is quite new and has much less history behind it than other databases likes Oracle 12C or other alternatives. Therefore it would be very premature to conclude that the SAP HANA database is lower in maintenance than alternatives.

SAP’s Inaccurate Messaging on HANA as Communicated in SAP Videos

Fact-Checking SAP’s HANA Information

This video is filled with extensive falsehoods. We will address them in the sequence they are stated in this video.

SAP Video Accuracy Measurement

SAP's Statement
Accuracy
Brightwork Fact Check
Link to Analysis Article
HANA is a Platform
0%
HANA is not a platform, it is a database.How to Deflect You Were Wrong About HANA
HANA runs more "in-memory" than other databases.
10%
HANA uses a lot of memory, but the entire database is not loaded into memory.How to Understand the In-Memory Myth
S/4HANA Simplifies the Data Model
0%
HANA does not simplify the data model from ECC. There are significant questions as to the benefit of the S/4HANA data model over ECC.Does HANA Have a Simplified Data Model?
Databases that are not HANA are legacy.
0%
There is zero basis for SAP to call all databases that are not HANA legacy.SAP Calling All Non-HANA DBs Legacy.
Aggregates should be removed and replaced with real time recalculation.
0%
Aggregates are very valuable, and all RDBMS have them (including HANA) and they should not be removed or minimized in importance.Is Hasso Plattner Correct on Database Aggregates?
Reducing the number of tables reduces database complexity.
0%
Reducing the number of tables does not necessarily decrease the complexity of a database. The fewer tables in HANA are more complicated than the larger number of tables pre-HANA.Why Pressure SAP to Port S/4HANA to AnyDB?
HANA is 100% columnar tables.
0%
HANA does not run entirely with columnar tables. HANA has many row-oriented tables, as much as 1/3 of the database.Why Pressure SAP to Port S/4HANA to AnyDB?
S/4HANA eliminates reconciliation.
0%
S/4HANA does not eliminate reconciliation or reduce the time to perform reconciliation to any significant degree.Does HANA Have a Simplified Data Model and Faster Reconciliation?
HANA outperforms all other databases.
0%
Our research shows that not only can competing databases do more than HANA, but they are also a better fit for ERP systems.How to Understand the Mismatch Between HANA and S/4HANA and ECC.

The Problem: A Lack of Fact-Checking of HANA

There are two fundamental problems around HANA. The first is the exaggeration of HANA, which means that companies that purchased HANA end up getting far less than they were promised. The second is that the SAP consulting companies simply repeat whatever SAP says. This means that on virtually all accounts there is no independent entity that can contradict statements by SAP.

The Necessity of Fact Checking

We ask a question that anyone working in enterprise software should ask.

Should decisions be made based on sales information from 100% financially biased parties like consulting firms, IT analysts, and vendors to companies that do not specialize in fact-checking?

If the answer is “No,” then perhaps there should be a change to the present approach to IT decision making.

In a market where inaccurate information is commonplace, our conclusion from our research is that software project problems and failures correlate to a lack of fact checking of the claims made by vendors and consulting firms. If you are worried that you don’t have the real story from your current sources, we offer the solution.

Inaccurate Messaging on HANA as Communicated in SAP Consulting Firm Videos

For those interested in the accuracy level of information communicated by consulting firms on HANA, see our analysis of the following video by IBM. SAP consulting firms are unreliable sources of information about SAP and primarily serve to simply repeat what SAP says, without any concern for accuracy. The lying in this video is brazen and shows that as a matter of normal course, the consulting firms are happy to provide false information around SAP.

SAP Video Accuracy Measurement

SAP's Statement
Accuracy
Brightwork Fact Check
Link to Analysis Article
HANA runs more "in-memory" than other databases.
10%
HANA uses a lot of memory, but the entire database is not loaded into memory.How to Understand the In-Memory Myth
HANA is orders of magnitude faster than other databases.
0%
Our research shows that not only can competing databases do more than HANA, but they are also a better fit for ERP systems.How to Understand the Mismatch Between HANA and S/4HANA and ECC.
HANA runs faster because it does not use disks like other databases.
0%
Other databases also use SSDs in addition to disk.Why Did SAP Pivot the Explanation of HANA In Memory?
HANA holds "business data" and "UX data" and "mobile data" and "machine learning data" and "IoT data."
0%
HANA is not a unifying database. HANA is only a database that supports a particular application, it is not for supporting data lakes.
SRM and CRM are part of S/4HANA.
0%
SRM and CRM are not part of S/4HANA. They are separate and separately sold applications. SAP C/4HANA is not yet ready for sale. How Accurate Was Bluefin Solutions on C-4HANA?
Netweaver is critical as a platform and is related to HANA.
0%
Netweaver is not relevant for this discussion. Secondly Netweaver is not an efficient environment from which to develop.
HANA works with Business Objects
10%
It is very rare to even hear about HANA and Business Objects. There are few Buisness Objects implementations that use HANA.SAP Business Objects Rating
Leonardo is an important application on SAP accounts.
0%
Leonardo is dead, therefore its discussion here is both misleading and irrelevant.Our 2019 Observation: SAP Leonardo is Dead
IBM Watson is an important application on SAP accounts.
0%
Watson is dead, therefore its discussion here is both misleading and irrelevant.How IBM is Distracting from the Watson Failure to Sell More AI and Machine Learning
Digital Boardroom is an important application on SAP accounts.
0%
SAP Digital Boardroom is another SAP item that has never been implemented many places.

Financial Disclosure

Financial Bias Disclosure

Neither this article nor any other article on the Brightwork website is paid for by a software vendor, including Oracle, SAP or their competitors. As part of our commitment to publishing independent, unbiased research; no paid media placements, commissions or incentives of any nature are allowed.

Search Our Other Who Was Right and Wrong on HANA Content

References

I cover how to interpret risk for IT projects in the following book.

The Risk Estimation Book

Rethinking Enterprise Software Risk: Controlling the Main Risk Factors on IT Projects

Better Managing Software Risk

The software implementation is risky business and success is not a certainty. But you can reduce risk with the strategies in this book. Undertaking software selection and implementation without approximating the project’s risk is a poor way to make decisions about either projects or software. But that’s the way many companies do business, even though 50 percent of IT implementations are deemed failures.

Finding What Works and What Doesn’t

In this book, you will review the strategies commonly used by most companies for mitigating software project risk–and learn why these plans don’t work–and then acquire practical and realistic strategies that will help you to maximize success on your software implementation.

Chapters

Chapter 1: Introduction
Chapter 2: Enterprise Software Risk Management
Chapter 3: The Basics of Enterprise Software Risk Management
Chapter 4: Understanding the Enterprise Software Market
Chapter 5: Software Sell-ability versus Implementability
Chapter 6: Selecting the Right IT Consultant
Chapter 7: How to Use the Reports of Analysts Like Gartner
Chapter 8: How to Interpret Vendor-Provided Information to Reduce Project Risk
Chapter 9: Evaluating Implementation Preparedness
Chapter 10: Using TCO for Decision Making
Chapter 11: The Software Decisions’ Risk Component Model

Risk Estimation and Calculation

Risk Estimation and Calculation

See our free project risk estimators that are available per application. The provide a method of risk analysis that is not available from other sources.

project_software_risk