SSAS Entity Framework Provider (tm) (patent pending) enables you to use LINQ and Microsoft ADO.NET Entity Framework to query OLAP cubes, offline cube files and SSAS in-memory Tabular model (BISM) like a regular relational database, but with the same outstanding performance offered by OLAP cubes, even when your cube size measures in dozens of terabytes and the cube data source is in petabytes. You can make your read LINQ queries orders of a magnitude faster, and reuse existing applications for volumes of Big Data scale with trivial LINQ Data Access layer modifications. Our product also allows you to expose data in your existing and new cubes to external applications via OData. It is the only product on the market that allows OData queries to group and aggregate OData service data server-side. SSAS Entity Framework Provider (tm) generates MDX behind the scenes, passes it to ADOMD.NET and converts ADOMD.NET result recordset into populated and connected objects (POCO / entities). There is no need to write MDX queries manually any more.
Say good-bye to the time spent on denormalization, complex ETL and performance optimizations of your SQL. It has been claimed that for complex queries OLAP cubes can produce an answer up to 0.1% of the time required for the same query on OLTP row-oriented RDBMS. With our product LINQ is much faster than SQL with queries to big data volumes (the key is not to ask for more rows than you display), and your data warehouse physical DB schema can stay perfectly normal, putting all denormalization work on OLAP cube. And if you do not have to merge tables from multiple OLTP data sources, you have an option to use Single Entity Data Model for both Data Entry/OLTP and Reporting/OLAP. You have an option, but you do not have to - our product will work with multiple models and star schemas with no issues.
SSAS Entity Framework Provider (tm) uses a streamlined dialect of LINQ - SDX (LINQ Simple Dimensional eXtensions).
See SDX LINQ example: LINQ vs. SDX vs. MDX Comparison
Even if you never knew neither LINQ nor MDX, you will find that SDX LINQ is extremely easy to learn and straightforward to use. Business analysts can use SDX LINQ with LINQPad to query cubes very similar to how they query relational databases with SQL. Installed Visual Studio and .NET knowledge are not required for ad hoc cube queries. SDX follows Do not Repeat Yourself principle and protects you from many of potential mistakes that would slow down your MDX query.You do not need to specify join, group by, sum, average, orderby and so on any more.You do not need that because most of the time your cube already knows how to join, group, aggregate and sort data. In fact SSAS cubes store your data in a pre-aggregated, pre-joined and compressed format, that is why SSAS MOLAP runs most queries in a fraction of a second, even when your OLTP relational database size is big enough to make a corresponding SQL query run many hours.
We tested our product with Microsoft SQL Server Analysis Services (SSAS), but SSAS is not required - you can use either offline cube files or any MDX OLAP Server that supports XMLA. E.g. experts report that ADOMD.NET works with Oracle Essbase, meaning that our product also does.
Creating and maintaining general purpose SSAS cubes takes a fraction of time spent on denormalizing relational data structures for each specific long running query, optimizing indexes and optimizing / retesting SQL queries and ETL. Note also that OLAP cubes fit Event Sourcing, planning, budgeting and accounting models perfectly, because cubes and MDX allow to pivot and unpivot data extremely fast and easy.
See Getting Started Walkthrough for detailed step-by-step instructions how to setup and run SDX.