Alternative databases and data warehouses
Choose storage models from workload/data characteristics, then explain why analytical warehouses differ from operational databases.
Model choice follows the workload
- outline NoSQL, cloud, spatial and in-memory approaches;
- connect them to e-commerce, GIS, managed services, real-time analytics, social media and SaaS;
- explain append-only, subject-oriented, integrated, time-variant and non-volatile warehouse data;
- explain query-performance optimization for business intelligence.
Rapid Recall Deck
Attempt each card first. If a term is new, flip and study it, then answer it again without looking. Mark only secure recall as “Know it”.
NoSQL + spatial
NoSQL fit
A social-media/e-commerce platform has rapidly changing document structures at large scale. Why consider NoSQL?
A NoSQL approach can offer flexible/non-relational structures and distributed scale when irregular data does not fit a rigid table schema naturally. The fit still depends on query, consistency and transaction needs.
Spatial fit
A GIS must find all emergency vehicles within 2 km. Why spatial DB?
Spatial databases store geometry/location and support distance, containment/intersection and related spatial queries directly.
Cloud + in-memory
Cloud database
A SaaS provider wants managed scalable storage without owning physical database servers. Outline the fit.
Cloud DBs provide managed network-accessible database resources and scalable infrastructure. Trade-offs include provider dependence, network latency, security/compliance and ongoing cost.
In-memory
A real-time analytics system needs very low latency. Explain fit + risk.
RAM-based working data avoids slower persistent-storage access, improving latency. Main memory is volatile/expensive, so persistence, replication and recovery still matter.
Warehouse objective
Why a warehouse?
sales | CRM | website | finance
\ | /
transform + integrate
↓
DATA WAREHOUSE
↓
BI queriesWhy not run every five-year BI query directly on live sales/CRM/finance transaction systems?
A warehouse integrates historical data from multiple sources into consistent analytical structures and can optimize heavy read/aggregate queries without imposing the same workload/schema demands on operational transaction systems.
Subject-oriented, integrated, time-variant
Subject-oriented
Organized around analysis subjects such as customer/product/sales.
Integrated
Source names, formats, codes and definitions are made consistent.
Time-variant
Historical states/periods are retained so trends can be compared.
Append-only, non-volatile, query-optimized
Append-only
New history is added instead of repeatedly overwriting old analytical history.
Non-volatile
Loaded analytical data is relatively stable/read-focused.
Query optimized
Structures favour large scans/aggregates/reporting over tiny transactional writes.
Operational DB or warehouse?
Choose the system
A retailer needs (A) one immediate payment and (B) five-year regional/product trend analysis. Explain the database role for each.
A uses the operational transaction DB for current reliable updates. B uses the warehouse because it integrates historical time-variant data and is optimized for analytical queries. Operational data can be transformed/loaded into the warehouse.
Finish the learning cycle
Case study / exam preparation
Post-IA focus: extend case-study research on very large image/model datasets and data infrastructure using credible sources.
Paper 1 — short practice
Create a model-selection table for NoSQL/cloud/spatial/in-memory and recall all six warehouse properties.