NoSQL is a database movement that began in early to mid 2009 and which promotes non-relational data stores that do not need a fixed schema, and that usually avoid join operations. From [1]:

Next Generation Databases mostly address some of the points: being non-relational, distributed, open-source and horizontal scalable. The movement began early 2009 and is growing rapidly. Often more characteristics apply as: schema-free, replication support, easy API, eventually consistency, and more. So the misleading term “nosql” (some call it ”not only sql”) should be seen as an alias to something like the definition above …

I just read a very insightful article from Michael Stonebraker [2], one of the pioneers of modern database theory and Relational Database Management Systems (RDBMS) and “father” of systems like Ingres and Postgres [3, 4]: ‘The “NoSQL” Discussion has Nothing to Do With SQL‘ [5]. In this article, published in the blog of the Communications of the ACM, Dr. Stonebraker responds to some of the arguments from the supporters of the NoSQL movement. There are two possible reasons to move away from structured Relational Database Management Systems and adopt an alternate DBMS technology: performance and flexibility:

The performance argument goes something like the following. I started with MySQL for my data storage needs and over time found performance to be inadequate. My options were: … 2. Abandon MySQL and pay big licensing fees for an enterprise SQL DBMS or move to something other than a SQL DBMS.

The flexibility argument goes something like the following. My data does not conform to a rigid relational schema. Hence, I can’t be bound by the structure of a RDBMS and need something more flexible. ….

Focusing on the performance argument, he explains what is more or less a common knowledge in the database community: The major performance burden of modern RDBMS  comes from all those extra features like transaction possessing (especially insuring the ACID properties), logging, etc and not from the core engine for executing an SQL query:

… However, the net-net is that the single-node performance of a NoSQL, disk-based, non-ACID, multithreaded system is limited to be a modest factor faster than a well-designed stored-procedure SQL OLTP engine. In essence, ACID transactions are jettisoned for a modest performance boost, and this performance boost has nothing to do with SQL.

…

In summary, blinding performance depends on removing overhead. Such overhead has nothing to do with SQL, but instead revolves around traditional implementations of ACID transactions, multi-threading, and disk management. To go wildly faster, one must remove all four sources of overhead, discussed above. This is possible in either a SQL context or some other context. …

I believe that anyone interested in the inner workings of modern RDBMS should read this short post from Dr. Stonebraker and continue with a very interesting paper from Harizopoulos, et.al “OLTP through the looking glass, and what we found there” [6]. I am getting tired of discussing with people outside the database community who after writing a couple of SQL queries think that they know all about modern RDBMS and insist that the MySQL’s MYISAM engine is the best engine out there just because it is fast(er) or question my motives when I consult them that a “Lite SQL” (no reference to any real product)  solution is just not enough..

PS. Dr. Stonebraker is not just an exceptional database researcher, but a visionary whose ideas have shaped the modern Database landscape. A short abstract from an article in SIGMOD Record when he received the IEEE John von Neumann Medal [7]:

… The relational data model and its associated benefits of “data independence” and “non-procedural access” were first invented by Tedd Codd. However, more than any other individual, Mike is responsible for making Codd’s vision of independence a reality through the architectures and algorithms embodied in the series of open-source prototypes and commercial systems that he has initiated and led. While many others have certainly made important contributions to the field, no one else comes close to his continuous sequence of landmark innovations over a period of almost 30 years.

… Mike has been the primary driving force behind major shifts in the research agenda of the database community, including two occasions where he launched entire new directions for the field to follow (the implementation of relational systems and object-relational systems).

News Facts

Oracle Exadata V2 Increases Oracle’s Performance and Price-Performance Leadership

Supporting Quotes

This document took me a long time to write :).  Actually had written it for my team and shared it with them some six months ago. Thought it might be a good idea to share it with everyone. Most of the stuff I have written in this document came with experience. All the other stuff required some painful browsing and learning . There might be a few spelling and grammatical errors in the document, but I assume they will not hamper the readability of the document (a bit lazy to correct the doc )

So, if you like the pdf pls drop a comment. If you think anything is incorrect in the document then please feel free to point it out and ‘suggest‘ your correction (this is a very important feedback you can give ).

SQL Coding Guidelines (Pdf) – The Link

Pratap.

PS: Will follow it up with a document on design guidelines. Think it needs some cleaning before I can upload it .

BTW. Sorry for disappointing you Girish … Another post on SQL Server… Will try to write something non-technical in my next post.

In this article I have not described more advanced setups, such as clusters, replication, etc. This article is designed as an overview of a basic, one-server, OLTP environment.

I have categorized configuration options into server options, disk configuration and startup options.

sp_configure 'show advanced options', 1
go
reconfigure
go
sp_configure
go

Or

select * from sys.configurations
go

affinity mask

affinity io mask

cost threshold for parallelism

fill factor

index create memory

locks

max degree of parallelism

max worker threads

min and max server memory

min memory per query

priority boost

recovery interval

Startup Options

-g memory_to_reserve

-T trace flag

-x

SQL Server Configuration – The Basics.

Two approach to designing databases:

1) OLTP (OnLine Transaction Processing) and 2) OLAP (OnLine Analytical Processing)

The OLTP as approach is used for collecting data. It is aimed to transactions.

The OLAP as approach has got aims such as selecting and processing huge amount of data.

OLTP (online transaction processing) is a class of program that facilitates and manages transaction-oriented applications, typically for data entry and retrieval transactions in a number of industries, including banking, airlines, mailorder, supermarkets, and manufacturers. Probably the most widely installed OLTP product is IBM’s CICS (Customer Information Control System).

Most businesses store data in relational data stores that are optimized for online transaction processing (OLTP) operations. OLTP databases are optimized for applications that need to insert and modify data as well as read data, and are generally normalized to reduce data duplication. This makes it easier to manage data modifications, because data values generally only need to be updated in one place. While it is possible to query an OLTP database to retrieve data for analysis, the normalized design of most relational databases means that the queries required to retrieve the data can be extremely complex, making it difficult for business users to perform their own analytical queries.

OLAP databases are generally denormalized to reduce the number of joins that must be performed when querying the data. This denormalization results in potential duplication of data, but OLAP databases store historical data that does not need to be modified, so this duplication of data is acceptable. Additionally, the data in an OLAP database is usually organized into facts (quantifiable business metrics) and dimensions (aspects of the business by which the facts can be aggregated).

Data warehouses and data marts

In most OLAP solutions, business data is extracted from the production online transaction processing (OLTP) systems, and other sources of business data, and loaded into a denormalized database, where it is optimized for analytical processing. In some scenarios, this denormalized database acts as a central repository for analytical data
from across the organization, in which case it is usually referred to as a data warehouse. Alternatively, an organization might contains a number of discrete departments, each with its own data sources and analysis needs, in which case multiple denormalized databases, called data marts, might exist.

OLAP cubes

Although the data warehouse or data marts can be queried to generate reports or to import data into analytical tools such as Microsoft Office Excel, most OLAP solutions include a multidimensional database that contains one or more cubes based on the OLAP data source. A cube stores the business dimensions and aggregated facts in a form that makes it easy for users to analyze the data by viewing the aggregated values where dimensions and facts intersect. This process is generally known as slicing and dicing the data.

© Microsoft Corporation

Most databases in a business environment are designed as online transaction processing (OLTP) systems where data is frequently inserted and updated. In an analysis solution, most operations read data in order to allow users to analyze key business metrics and make informed business decisions. There are two main categories of analysis: multidimensional analysis and data mining. An analysis solution allows users to perform one or both of these kinds of analysis.

Multidimensional data analysis

The most common kind of analysis is a multidimensional data analysis– sometimes referred to as online analytical processing (OLAP). In a multidimensional analysis solution, data is arranged in a multidimensional cube structure in which aggregations of numerical business measures are intersected by various dimensions of the business. For
example, you could create a multidimensional analysis solution that allows users to view sales totals by order date and by customer.

Data mining

Data mining solutions use mathematical algorithms to analyze data and generate trends and predictions based on statistics and patterns in the data. A data mining solution consists of one or more data mining models in which a particular data mining algorithm has been applied to a representative set of business data in order to identify trends,
clusters, or statistical relationships between key data items. The data model can then be used to predict business measures for similar data. For example, you could use a data mining model to analyze past purchases made by customers, and then use the model to suggest products that an individual customer is likely to buy based on purchases made by customers with a similar demographic profile.

© Microsoft Corporation

O data cu SQL Server 2005, Microsoft a introdus o serie de noi functionalitati. Aceste noi functionalitati usureaza munca unui administrator sau dezvoltator in scrierea codului T-SQL si a intretinerii bazelor de date.  In continuare vom discuta despre funtiile de rang. Functiile de rang intorc o valoare rang pentru fiecare rand dintr-un set de date. Aceste functii sunt nondeterministice. Functie de functia utilizata, mai multe randuri pot avea aceeasi valoare sau valori indivituale.

Functiile de rang permite inumararea secventiala a setului de date. Pentru a exemplifica rezultatul executiei acestor functii, se considera tabela si inregistrarile de mai jos:

CREATE TABLE Persoane(
            Nume VARCHAR(50),
            Varsta INT,
            SEX CHAR(1)
)

INSERT INTO Persoane VALUES (‘Ion’,53,’M')
INSERT INTO Persoane VALUES (‘Vasile’,45,’M')
INSERT INTO Persoane VALUES (‘Gheorghe’,89,’M')
INSERT INTO Persoane VALUES (‘Maria’,21,’F')
INSERT INTO Persoane VALUES (‘Stefan’,46,’M')
INSERT INTO Persoane VALUES (‘Adriana’,69,’F')
INSERT INTO Persoane VALUES (‘Mircea’,56,’M')
INSERT INTO Persoane VALUES (‘Mihai’,2,’M')
INSERT INTO Persoane VALUES (‘Daniela’,46,’F')
INSERT INTO Persoane VALUES (‘Cristina’,25,’F')
INSERT INTO Persoane VALUES (‘Andreea’,14,’F')

Transact – SQL furnizeaza urmatoarele functii: RANK(), DENSE_RANK(), NTILE(), ROW_NUMBER()

RANK

Uneori se doreste ca doua sau mai multe randuri care au aceasi clauza de ordonare (order by) ca aibe acelasi rang. Sintaxa generala este:

RANK ( )  OVER ( [ <partition_by_clause> ] <order_by_clause> )

Unde:
[ <partition_by_clause> ] – reprezinta coloana sau coloanele dupa care se creaza grupari in setul de date
<order_by_clause> – reprezinta coloana sau coloanele dupa care se realizeaza ordonarea pentru stabilirea valorilor rang in cadrul partitiei.

Functia RANK inumara secvential valorile din clauza ORDER BY. Cand doua sau mai multe randuri au aceeasi valoare in ORDER BY, primesc acelasi rang. Chiar si in acest caz, valoarea de rang este incrementata iar cand o noua valoare este determinate in ORDER BY, rangul determinat va fi mai mare cu 1 decat numarul de randuri aflat inaintea randului current. In exemplul urmator, s-a aplicat functia RANK peste coloana Varsta.

SELECT      RANK() OVER(ORDER BY Varsta) as RankNumber,
            Nume,
            Varsta
FROM Persoane

Se poate observa ca acolo unde varsta este aceeasi, si valoarea rang este identical. Atunci cand se intalneste o noua varsta, rangul devine numarul de randuri de dinaintea randului current incrementat cu 1. Cu alte cuvinte, Andreea are rangul 3 pentru ca inaintea ei sunt alte 2 persoane care avand aceeasi varsta, au primit acelasi rang.

SELECT      RANK() OVER(PARTITION BY Sex ORDER BY Varsta) as RankNumber,
            Nume,
            Varsta,
            Sex
FROM Persoane

In exemplul 2, setul de date a fost grupat dupa sex iar apoi s-a atribuit valoarea de rang (individual pentru fiecare partitie a setului de date).

 DENSE_RANK

Aceasta functie este similara funtiei RANK cu exceptia faptului ca valorile rang sunt in ordine, nu lipseste niciuna. Cu alte cuvinte, o valoare rang este ori valoarea rang a randului precedent ori valoarea rang a randului precedent incrementat cu 1. Aceste valori sunt in ordine, fara valori “lipsa”.

SELECT      DENSE_RANK() OVER(ORDER BY Varsta) as RankNumber,
            Nume,
            Varsta
FROM Persoane

NTILE

Aceasta functie este similara celorlalte si imparte un set de date in subgrupuri.

SELECT      NTILE(3) OVER(ORDER BY Varsta) as RankNumber,
            Nume,
            Varsta
FROM Persoane

In exemplul de mai sus, setul de date a fost impartit in 3 subgrupuri (3 este valoarea parametrului functiei NTILE). Folosirea acestei functii va avea ca effect divizarea setului de date in subgrupuri de date cu acelasi rang.

ROW_NUMBER

Aceasta functie intoarce o valoare rang data de numarul randului. Fiecare rand din setul de date va fi cu 1 mai mare decat precedentul rand si cu 1 mai mic decat urmatorul rand. Primul rand din setul de date va avea valoarea 1. Acest rang se poate aplica sip e partitii de date ale setului de date (aduca pe grupuri de date).

SELECT      ROW_NUMBER() OVER(ORDER BY Varsta) as RankNumber,
            Nume,
            Varsta
FROM Persoane

In exemplul de mai sus, numerotarea randurilor s-a realizat dupa coloana Varsta. Daca vom dori afisarea setului de date in alta ordine, adica adaugarea clauzei Order by, in acest caz, numai afisarea o sa se realizeze dupa noua ordine, numerotarea randurilor se va realiza dupa clauza order by a functiei ROW_NUMBER.

SELECT      ROW_NUMBER() OVER(ORDER BY Varsta) as RankNumber,
            Nume,
            Varsta
FROM Persoane
ORDER BY NUME

Acum se poate observa ca afisarea s-a realizat dupa noua ordine dar valorile rang sunt aceleasi.

to get more information about Microsoft SQLServer 2008 R2 you can visit SQLServer2008 R2

to find full comparison of key capabilities between SQL Server 2008 Enterprise, Standard, Workgroup, Web and Express editions

Just click on Microsoft

SQLHero delivered June Session in Business Intelligence Scenarios (SQL 2008)

With the arrival of SQL Server 2008 we gained access to a new feature called Change Data Capture (CDC). CDC enables you to constantly stream change data to a consuming process, most notably Extract, Transform, and Load (ETL) applications. In the SQL Server environment the ETL application used is of course SQL Server Integration Services (SSIS). 

the first obvious constraint in regard to SQL Server 2008’s CDC feature is that it is only available to SSIS applications that source their data from an OLTP system built on SQL Server 2008. In the field of implementing Microsoft BI there are many relational database systems we have to source data from that are not SQL Server based (and if they are SQL Server based there is a good chance it is not using the 2008 version). All major relational database systems use some form of a transaction log to record the history of its actions in case of rollback or hardware failure. I would imagine that the actual contents of each database vendor’s log is different, however they have the same basic requirement to temporarily persist database actions.

So how to enable Change Data Capture on a database, and on a table, and how to keep track of Data Definition Language changes on a table.

Step 1

Let’s create a database named SqlHero as shown below.

USE [master]
GO

/*** Object:  Database [SqlHero]   ***/
IF  EXISTS (SELECT name FROM sys.databases WHERE name = N'SqlHero')
DROP DATABASE [SqlHero]
GO
USE [master]
GO

/*** Object:  Database [SqlHero]   ***/
CREATE DATABASE [SqlHero]
GO

Step 2

Now let’s create a table named MyTable on the SqlHero database, as shown Below.

USE [SqlHero]
GO

/*** Object:  Table [dbo].[MyTable]   ***/
IF  EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[dbo].[MyTable]')
	AND type in (N'U'))
DROP TABLE [dbo].[MyTable]
GO
USE [MyDataBase]
GO

/*** Object:  Table [dbo].[MyTable]   ***/
SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO

SET ANSI_PADDING ON
GO

CREATE TABLE [dbo].[MyTable](
	[ID] [int] NOT NULL,
	[Name] [varchar](100) NULL,
 CONSTRAINT [MyTable_PK] PRIMARY KEY CLUSTERED
(
	[ID] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF,
	IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON,
	ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]

GO

SET ANSI_PADDING OFF
GO

Step 3

In order to track changes on the table, we need to enable the Change Data Capture feature on the database. We can enable the Change Data Capture feature using the following Transact SQL command, as shown below.

Until this point, the only schema that exists on the database is dbo. Once we enable Change Data Capture, a new schema with a bunch of objects will be created.

USE [SqlHero]
GO
EXEC sys.sp_cdc_enable_db_change_data_capture
GO

The following CDC tables are created under the CDC schema, as shown below

cdc.captured_columns
cdc.change_tables
cdc.ddl_history
cdc.index_columns
cdc.lsn_time_mapping

When you query these tables, you will see only zero number of rows.

select * from cdc.captured_columns
select * from cdc.change_tables
select * from cdc.ddl_history
select * from cdc.index_columns
select * from cdc.lsn_time_mapping

Result

(0 row(s) affected)
 (0 row(s) affected)
(0 row(s) affected)
 (0 row(s) affected)
 (0 row(s) affected)

Step 3

In order to track changes on the table, we need to enable the Change Data Capture feature on the table as well. Let’s enable the Change Data Capture feature using the following Transact SQL command, as shown below.

USE [SqlHero]
GO
EXEC sys.sp_cdc_enable_table_change_data_capture
@source_schema = 'dbo',
@source_name = 'MyTable',
@role_name = 'cdc_MyTable'
GO

Result

Job 'cdc.MyDataBase_capture' started successfully.
Job 'cdc.MyDataBase_cleanup' started successfully.

By reading the result, we can easily understand that SQL Server Agent is a must to do the capture and cleanup. We can see these jobs are actually created as SQL Server Scheduled jobs. [Refer Fig 1.6, 1.7]

Now let’s execute the following Transact SQL to see if any data has been inserted on any of the CDC tables.

select * from cdc.captured_columns
select * from cdc.change_tables
select * from cdc.index_columns

Result

object_id, column_name, column_id, column_type, column_ordinal, is_computed
389576426, ID, 1, int, 1, 0
389576426, Name, 2, varchar, 2, 0

(2 row(s) affected)

object_id,  version,  source_object_id, capture_instance, start_lsn, end_lsn, supports_net_changes, has_drop_pending,
	role_name, index_name, filegroup_name, create_date
389576426, 0, 53575229, dbo_MyTable, NULL, NULL, 0, NULL, cdc_MyTable, MyTable_PK, NULL,
(1 row(s) affected)

object_id, column_name, index_ordinal, column_id
389576426, ID, 1, 1

(1 row(s) affected)

You can see that the CDC schema stores metadata information about which tables and columns are being tracked by Change Data Capture. It also stores information about what Index the table that has been tracked has.

Step 4

We can check to see if Change Data Capture is enabled on a database by using the following transact SQL statement.

SELECT is_cdc_enabled FROM sys.databases WHERE name = 'SqlHero'

Result

is_cdc_enabled
--------------
1

(1 row(s) affected)

Step 5

We can check to see if Change Data Capture is enabled on a table, by using the following transact SQL statement.

SELECT is_tracked_by_cdc FROM sys.tables WHERE name = 'MyTable'

Result

is_tracked_by_cdc
-----------------
1

(1 row(s) affected)

Step 6

Now let’s make some changes to table structure and see if Change Data Capture captures the changes. Execute the following query as shown below.

USE [SqlHero]

GO

Alter Table MyTable add Address varchar(500)

GO

Alter Table MyTable add Salary money

GO

Alter Table MyTable add Bonus money

GO

Query the cdc table ddl_history as shown below.

select * from cdc.ddl_history

Result

source_object_id, object_id, required_column_update, ddl_command, ddl_lsn, ddl_time
53575229, 389576426, 0, Alter Table MyTable add Address varchar(500)
, 0x0000001C000001350001,
53575229, 389576426, 0, Alter Table MyTable add Salary money
, 0x0000001C000001370018, 53575229, 389576426, 0, Alter Table MyTable add Bonus money
, 0x0000001C0000013D0018,
(3 row(s) affected)

you can now test SQL Server 2008 new features through virtual labs on line in Business intelligence, Data warehousing, OLTP and Application Deployments

believe me really useful

http://www.microsoft.com/sqlserver/2008/en/us/virtual-labs.aspx

The term Analytics mean a branch of logic dealing with analysis. So one can safely assume that Siebel Analytics means branch of Siebel dealing with Analysis. Siebel has always been transactional application and it is very difficult to do analysis of data that is residing in Siebel. Just to give an example of what it means.

Suppose a sales manager wants to know that: How many opportunities in the last 6 months from a UK region for product X have a sales figure of over 5 million dollars?

Now this is not a easy way to get this kind of data in Siebel easily and this is just very small requirement that a sales manager might have it can get very complex easily.

This is where Siebel Analytics comes into picture. It is a wrapper over Siebel Application.

Siebel Analytics allow an enterprise to measure and evaluate business performance across customers. It helps in analyzing past, present and future opportunities with the help of Dashboard Reports to determine actions required to meet the sales targets. With the help of Dashboard reports one can determine which products and customers are generating most of the revenue.

For understanding Siebel Analytics in more depth one has to know the basic difference between OLAP and OLTP.

OLTP stands for On Line Transaction Processing:
OLAP stands for On Line Analytical Processing

The data available at transaction side (Siebel Application) is OLTP and when that data is moved from transaction side for analyzing (Siebel Analytics) that becomes OLAP data.

OLAP brings into picture the concept of Data warehouse.Data warehouse is a Relational /Multidimensional database that is designed for query and analysis rather for transaction processing. A data warehouse usually contains historical data that is derived from transaction data. By On Line Analytical Processing (OLAP) one can ‘Slice and dice’ the data. Sales and Marketing business owners will get all kinds of reports to improve the business. Example:- Compare the revenue between various time periods and predict the next quarters or next years revenue and sales information.

By OLAP, we mean these things:-

1) Viewing data in a multidimensional way.

2)”SLICE & DICE” for data warehouse.

3) OLAP is a multidimensional way of storing and viewing the data.

OLAP EXAMPLES:- 1) Amazon analyzes purchases by its customers to come up with an individual screen with products of likely interest to the customer.

2.) Analysts at Wal-Mart look for items with increasing sales in some region.

3.) Sales and Marketing department doing the trend analysis on certain product line with and without customer

4.) ………. List goes on.

Another important concept when we are talking about to Siebel Analytics is ETL.

ETL stands for Extract, Transform, and Load.

ETL is a concept that enables businesses to consolidate their disparate data while moving it from OLTP to OLAP and it doesn’t really matter that that data sources are in different forms or formats. The data can come from any source such as Oracle, SQL server, flat files, CSV etc.

One important function of ETL is “Cleansing” data. ETL consolidation protocols also include the elimination of duplicate or fragmentary data, so that what passes from the ‘E’ portion of the process to the ‘L’ portion is easier to assimilate and/or store.

Such cleansing operations can also include eliminating certain kinds of data from the process. If someone don’t want to include certain information, one can customize the ETL to eliminate that kind of information from his/her transformation. The ‘T’ portion of the equation, of course, is the most powerful. ETL can transform data from different sources.

For Example: – Data in an Oracle CRM could be transformed right along with data from an SAP Marketing application, with the result being a common data from both the application.

For more information, visit:- www.creativeprobers.com

Un poco de teoría.

No se recomienda la implementación de almacenes de datos corporativos (Datawarehouse) o almacenes sobre una problemática concreta del negocio de la organización (Datamarts) en el mismo sistema y/o espacio de los sistemas operaciones (OLTP: On-Line Transaction Processing), ya que requiere modelos de datos orientados a la consulta de la información (modelos en estrella o copo de nieve) y no se quiere interferir el funcionamiento de los sistemas transaccionales con la capacidad de proceso que requiere un proceso de ETL realizado sobre las tablas del operacional cada vez que se requiera una consulta o con la necesidad de proceso que se requiere para consultar la información si se está trabajando incluso con sistemas orientados a cubos.

Es decir, la teoría tradicional recomienda entornos distintos para los sistemas operacionales y para los sistemas orientados al soporte a la decisión, de manera que unos no influyan sobre los otros.

En los sistemas de soporte a la decisión, sobre todo aquellos orientados a los cuadros de mando y al análisis OLAP, la solución de modelado de datos se recomienda que esté orientada a modelos en estrella o copos de nieve, basados en la existencia de una o más tablas de hechos que muestran cada una de ellas un indicador a medir y las dimensiones, que no es otra cosa que los diferentes puntos de vista por los que se puede consultar un indicador, por ejemplo, punto de vista temporal, punto de vista geográfico, etc… Para sistemas orientados al reporting o al análisis puro y duro de la información es más recomendable otras soluciones, ya que en estos casos no resulta tan interesante la información agregada, siendo más importante tener la información en detalle.

Mi recomendación es que si se necesita una solución mixta, basada por un lado por cuadros de mando y análisis OLAP y por otro por reporting o análisis de la información, se implementen dos soluciones, una orientada a los modelos en estrella o modelos copo de nieve y otra basada en la desnormalización del modelo de datos operacional quedándonos solo con la información que se precisa o se prevé precisar para la confección de los listados o para la realización del análisis de la información.

I become an IT Consultant in 1995 as mainframe programmer / analyst and become an expert in CICS, Cobol, and DB2 in no time. CICS is my first online transaction processing (OLTP) system (and then IMS is my second OLTP). Large number of financial, B2B, EDI, insurance transactions must have been processed by the programs I wrote and maintained and I am not surprise to know that they are still productive and efficient until now. Some of my projects involved Data Warehouse and Data Mart which are being processed by CICS and involved CICS integration with distributed systems, natively or through message-oriented middleware.

In 2003 and 2004, I have a chance to work with SOAP for CICS (which is still a CICS feature pack at this time) and with multiple projects of integrating CICS with web application and message-oriented middleware in distributed and mainframe systems. This is the renaissance of CICS being modernized with emerging technologies like SOAP, AXIS, etc. Also WebSphere HATS (Host Access Transformation Server) are enabling mainframe systems for web applications. This also the time when WebSphere is the transaction server of choice in distributed platform if not in mainframe platform.

Currently, I still consider CICS as my choice of OLTP and platform for large enterprise. WebSphere Application Server, WebSphere Message Broker, WebSphere MQ, WebSphere Process Server and other WebSphere products run on mainframe. Part of these software products, if not all, run as CICS applications in mainframe.

Trivia #1: Do you know that Hurlsley is the birthplace of WMQ and CICS?

Trivia #2: Do you know that VSE is the first Virtual Systems environment? (Not z series, p series or VMware)

Trivia #3: Do you know that CICS is the first application that sleep when not doing a tasks to improve processor performance?

History

IBM “Blue Letter” 269-44, dated July 8, 1969 announced the availability of the System/360 Customer Information Control System, Program Product 5736-U11, was “ready for shipment”.

CICS is born

In 1968, CICS became available as a free, Type II Application Program, with users in every industry category. Transamerica in Los Angeles, Northern Indiana Public Service Company (NIPSCO), Colorado Public Service of Colorado, United Airlines, and many others were early adopters of the software known as CICS. The other accounts which had begun to develop their own approach (Commonwealth Edison, ConEd, etc) continued with their proprietary software.

In 1969, IBM announced Program Products and CICS was no longer a free software offering. This did inhibit sales and customer acceptance. CICS enabled customers, in any industry, to quickly implement their online systems, most of which were inquiry only at that time.

The VSE factor

In 1971, the huge demand from smaller customers was heard and CICS for the Disk Operating System (precursor to VSE) was announced and delivered. There was the standard version of CICS/DOS but also a very small, entry level version called CICS/DOS Entry.

In 1972, the IBM 3270 was announced and delivered, and customers were ready to evolve from the hard copy terminals, such as the AT&T Teletype and the IBM 1050 or 2740/41 to video display terminals. CICS was an early supporter of the new technology.

CICS goes virtual

Also in 1972, IBM announced the notion of ‘virtual systems’ and a new operating systems would be introduced to support the new technology. Unlike the Primary Control Program (PCP), Multiprogramming with a Fixed number of Tasks (MFT) or Multiprogramming with a Variable number of Tasks (MVT) of the past, CICS was being asked to support the new VS environment.

In 1972-73, CICS moved quickly to support the new virtual system, for both the large MVS-class customer, but also for the smaller DOS/VS customer. By this time customers had made serious commitments to online systems, and a number of new technologies were added to CICS, including support for online update and recovery/restart. Support of new data management technology, such as DL/I was incorporated into both the MVS and DOS versions of CICS.

In the 1975-76 timeframe, IBM introduced VTAM and System Network Architecture, taking users from the previous, primitive support of BTAM into newer, more capable support of networking. CICS delivered its first support of VTAM/SNA in 1975/76.

Command Level

In 1977, CICS introduced its command level programming interface, a dramatic change in application programming which has had its positive effect to this day. Command level program isolates the application from its physical environment and has enabled customers to implement distributed systems (client/server).

Multiple Region Operation

In the 1978-1980 timeframe, CICS delivered its support for Multiple Region Operation (MRO) and Intersystem Communication (ISC), enabling the customer to easily distribute applications and data resources across multiple locations. This allowed customers to overcome the early storage limitations of virtual systems, and enabled the customer to have multiple, concurrent units of CICS-related work running on multiple machine processors (multi-processors).

High availability

The 1980s brought continued enhancements to CICS and more capability for the CICS customer. High availability was enhanced with the new XRF support, CICS was ported to new environments, such as the personal computer (CICS OS/2). More portability of CICS was offered with CICS running on UNIX machines, the AS/400 and non-IBM environments such as DEC or HP.

the 1990’s we go parallel!

CICS had evolved its distributed architecture beginning in the 1978-1980 timeframe. This has served it well and the needs of its users as well, with the advent of parallel systems in the 1990s. CICS, with its MRO architecture, fits extremely well, with the concepts and goals of parallel systems. Parallel systems users are motivated to have higher system thruput and/or higher system and application availability. CICS support of parallel systems supports these goals. Work can be distributed across any number of MVS regions or systems within a sysplex, and applications can be cloned and data can be shared, such that if any single component becomes unavailable, its work can be carried out by the other system.

The Internet

In addition to CICS’ support of parallel systems, the product was quick to provide support of the Internet. Beginning with the CICS Internet Gateway and the [[CICS Gateway for Java]], CICS has since evolved its support to now offer multiple ways for the user to web enable his applications. A web browser can access CICS directly or through an outboard server such as AIX or Windows NT, or via the operating system’s web server. The CICS Transaction Gateway can be used either on an outboard server or in its own address space on MVS.

Java

Business applications, written in Java to work with CICS applications and data resources, can execute as applets on a desktop web browser, on an outboard server as a servlet, in a CICS Transaction Gateway region as a servlet, or even within the CICS address space. IBM’s WebSphere Application Servers can be used as front-ends to CICS. CICS is very much on the forefront of e-commerce and e-business.

Open Transaction Environment

In version 3.2 (2007) IBM enhanced the CICS-MQ interface to support the OTE environment. Also the IBM TCP/IP interface EZACIC01 support the OTE environment starting with z/OS R7 as well.

SOA

In addition to CICS’s comprehensive support for Java and the Internet, the most recent releases of CICS now offer support for new environments through the use of [[Service Oriented Architecture]] (SOA). The goal of SOA is to enable applications, residing anywhere, can access other applications, with security understood and have the results of the called application returned to the requester. Reusability of existing applications is a major benefit of SOA, meaning applications and their services can be implemented on any system, not just the system of the requesting application.

CICS has increased its interoperability with IBM’s Websphere Application Server (WAS) and Enterprise Java Beans (Java applications). A CICS EJB can invoke an EJB executing in a WAS environment and vice versa. CICS’s Transaction Gateway is now the strategic interface for CICS applications to invoke WebSphere applications located in other operating systems environments (images).

XPLINK

Starting with version 3.1 (2006) IBM introduce an new X8/X9 TCB like the L8/L9 TCB for DB2 in order to support a C/C++ XPLINK enviroment.
Of course where are other new TCBs with CTS 3.1

the 2007 we go 64-bit!

Starting with CTS 3.2 (2007) we got 64bit support for CHANNELS/CONTAINER. A new feature is also Dynamic DFHRPL.

Source of history: History – CICS Wiki

I become an IT Consultant in 1995 as mainframe programmer / analyst and become an expert in CICS, Cobol, and DB2 in no time. CICS is my first online transaction processing (OLTP) system (and then IMS is my second OLTP). Large number of financial, B2B, EDI, insurance transactions must have been processed by the programs I wrote and maintained and I am not surprise to know that they are still productive and efficient until now. Some of my projects involved Data Warehouse and Data Mart which are being processed by CICS and involved CICS integration with distributed systems, natively or through message-oriented middleware.

In 2003 and 2004, I have a chance to work with SOAP for CICS (which is still a CICS feature pack at this time) and with multiple projects of integrating CICS with web application and message-oriented middleware in distributed and mainframe systems. This is the renaissance of CICS being modernized with emerging technologies like SOAP, AXIS, etc. Also WebSphere HATS (Host Access Transformation Server) are enabling mainframe systems for web applications. This also the time when WebSphere is the transaction server of choice in distributed platform if not in mainframe platform.

Currently, I still consider CICS as my choice of OLTP and platform for large enterprise. WebSphere Application Server, WebSphere Message Broker, WebSphere MQ, WebSphere Process Server and other WebSphere products run on mainframe. Part of these software products, if not all, run as CICS applications in mainframe.

Trivia #1: Do you know that Hurlsley is the birthplace of WMQ and CICS?

Trivia #2: Do you know that VSE is the first Virtual Systems environment? (Not z series, p series or VMware)

Trivia #3: Do you know that CICS is the first application that sleep when not doing a tasks to improve processor performance?

History

IBM “Blue Letter” 269-44, dated July 8, 1969 announced the availability of the System/360 Customer Information Control System, Program Product 5736-U11, was “ready for shipment”.

CICS is born

In 1968, CICS became available as a free, Type II Application Program, with users in every industry category. Transamerica in Los Angeles, Northern Indiana Public Service Company (NIPSCO), Colorado Public Service of Colorado, United Airlines, and many others were early adopters of the software known as CICS. The other accounts which had begun to develop their own approach (Commonwealth Edison, ConEd, etc) continued with their proprietary software.

In 1969, IBM announced Program Products and CICS was no longer a free software offering. This did inhibit sales and customer acceptance. CICS enabled customers, in any industry, to quickly implement their online systems, most of which were inquiry only at that time.

The VSE factor

In 1971, the huge demand from smaller customers was heard and CICS for the Disk Operating System (precursor to VSE) was announced and delivered. There was the standard version of CICS/DOS but also a very small, entry level version called CICS/DOS Entry.

In 1972, the IBM 3270 was announced and delivered, and customers were ready to evolve from the hard copy terminals, such as the AT&T Teletype and the IBM 1050 or 2740/41 to video display terminals. CICS was an early supporter of the new technology.

CICS goes virtual

Also in 1972, IBM announced the notion of ‘virtual systems’ and a new operating systems would be introduced to support the new technology. Unlike the Primary Control Program (PCP), Multiprogramming with a Fixed number of Tasks (MFT) or Multiprogramming with a Variable number of Tasks (MVT) of the past, CICS was being asked to support the new VS environment.

In 1972-73, CICS moved quickly to support the new virtual system, for both the large MVS-class customer, but also for the smaller DOS/VS customer. By this time customers had made serious commitments to online systems, and a number of new technologies were added to CICS, including support for online update and recovery/restart. Support of new data management technology, such as DL/I was incorporated into both the MVS and DOS versions of CICS.

In the 1975-76 timeframe, IBM introduced VTAM and System Network Architecture, taking users from the previous, primitive support of BTAM into newer, more capable support of networking. CICS delivered its first support of VTAM/SNA in 1975/76.

Command Level

In 1977, CICS introduced its command level programming interface, a dramatic change in application programming which has had its positive effect to this day. Command level program isolates the application from its physical environment and has enabled customers to implement distributed systems (client/server).

Multiple Region Operation

In the 1978-1980 timeframe, CICS delivered its support for Multiple Region Operation (MRO) and Intersystem Communication (ISC), enabling the customer to easily distribute applications and data resources across multiple locations. This allowed customers to overcome the early storage limitations of virtual systems, and enabled the customer to have multiple, concurrent units of CICS-related work running on multiple machine processors (multi-processors).

High availability

The 1980s brought continued enhancements to CICS and more capability for the CICS customer. High availability was enhanced with the new XRF support, CICS was ported to new environments, such as the personal computer (CICS OS/2). More portability of CICS was offered with CICS running on UNIX machines, the AS/400 and non-IBM environments such as DEC or HP.

the 1990’s we go parallel!

CICS had evolved its distributed architecture beginning in the 1978-1980 timeframe. This has served it well and the needs of its users as well, with the advent of parallel systems in the 1990s. CICS, with its MRO architecture, fits extremely well, with the concepts and goals of parallel systems. Parallel systems users are motivated to have higher system thruput and/or higher system and application availability. CICS support of parallel systems supports these goals. Work can be distributed across any number of MVS regions or systems within a sysplex, and applications can be cloned and data can be shared, such that if any single component becomes unavailable, its work can be carried out by the other system.

The Internet

In addition to CICS’ support of parallel systems, the product was quick to provide support of the Internet. Beginning with the CICS Internet Gateway and the [[CICS Gateway for Java]], CICS has since evolved its support to now offer multiple ways for the user to web enable his applications. A web browser can access CICS directly or through an outboard server such as AIX or Windows NT, or via the operating system’s web server. The CICS Transaction Gateway can be used either on an outboard server or in its own address space on MVS.

Java

Business applications, written in Java to work with CICS applications and data resources, can execute as applets on a desktop web browser, on an outboard server as a servlet, in a CICS Transaction Gateway region as a servlet, or even within the CICS address space. IBM’s WebSphere Application Servers can be used as front-ends to CICS. CICS is very much on the forefront of e-commerce and e-business.

Open Transaction Environment

In version 3.2 (2007) IBM enhanced the CICS-MQ interface to support the OTE environment. Also the IBM TCP/IP interface EZACIC01 support the OTE environment starting with z/OS R7 as well.

SOA

In addition to CICS’s comprehensive support for Java and the Internet, the most recent releases of CICS now offer support for new environments through the use of [[Service Oriented Architecture]] (SOA). The goal of SOA is to enable applications, residing anywhere, can access other applications, with security understood and have the results of the called application returned to the requester. Reusability of existing applications is a major benefit of SOA, meaning applications and their services can be implemented on any system, not just the system of the requesting application.

CICS has increased its interoperability with IBM’s Websphere Application Server (WAS) and Enterprise Java Beans (Java applications). A CICS EJB can invoke an EJB executing in a WAS environment and vice versa. CICS’s Transaction Gateway is now the strategic interface for CICS applications to invoke WebSphere applications located in other operating systems environments (images).

XPLINK

Starting with version 3.1 (2006) IBM introduce an new X8/X9 TCB like the L8/L9 TCB for DB2 in order to support a C/C++ XPLINK enviroment.
Of course where are other new TCBs with CTS 3.1

the 2007 we go 64-bit!

Starting with CTS 3.2 (2007) we got 64bit support for CHANNELS/CONTAINER. A new feature is also Dynamic DFHRPL.

Source of history: History – CICS Wiki

De la inceput, sistemele relationale de baze de date au fost utilizate pentru a stoca informatii primare pentru afacere precum comenzile sau facturile utilizand procesarea bazata pe tranzactii. Aceasta orientare pe datele afacerii are avantaje si dezavantaje. Un avantaj este acela ca performanta scazuta a primelor sisteme relationale de baze de date s-a imbunatatit substantial astfel incat, in zilele noastre, multe sisteme relationale de baze de date pot executa zeci de tranzactii pe secunda (bineinteles daca si componentele hardware permit acest lucru). Pe de alta parte, orientarea spre afaceri a sistemelor tranzactionale au prevenit aparitia altor sisteme naturale de baze de date pentru a se analiza si a umple nevoia de informatii din datele existente intro companie sau department.

OLTP (online transaction processing)

Dupa cum am spus deja, performanta este principala problema a sistemelor bazate pe procesarea tranzactionala. Un exemplu tipic al aplicarii acestor sisteme este retragerea de fonduri de la un bancomat (ATM). Catva dintre principalele proprietati ale sistemelor OLTP sunt:

1.       Tranzactii scurte

2.       Multi utilizatori (sute sau chiar mii)

3.       Operatii continue de citire si scriere bazate pe un numar redus de randuri

4.       Date de dimensiuni medii sunt stocate in baza de date

Performanta bazelor de date va creste daca tranzactiile sunt scurte. Motivul este acela ca tranzactiile folosesc lock-uri pentru a preveni posibilul efect negativ  al problemelor de acces concurential. Daca tranzactiile sunt lungi, numarul de lock-uri si durata lor cresc, scazand performanta accesului la date si a performantei pentru alte tranzactii.

Sistemele OLTP mari au ,de obicei, multi utilizatori care acceseaza sistemul simultan. Un exemplu tipic este cel al unui sistem de rezervare a biletelor pentru o companie aeriana, care trebuie sa proceseze zeci de cereri ,aproape imediat, pentru bilete de calatorie intro tara sau pe intreg cuprinsul planetei. In acest tip de sistem, utilizatorii isi doresc ca asteptarile lor legate de timp sa fie satisfacute – sistemul sa raspunda cat mai repede si sa fie disponibil 24 de ore pe zi timp de 7 zile pe saptamana.

Utilizatorii sitemelor OLTP executa instructiuni DML (data manipulation language) in mod continu realizand operatii de citire si scriere in acelasi timp. Pentru ca datele unui asemenea sistem se schimba des se poate spune ca sistemul este foarte dinamic. In mod normal, aceste operatii (sau rezultatul lor) implica o cantitate mica de date, altfel, daca sistemul aceseaza multe randuri va fi nevoie sa fie accesate una sau mai multe tabele din baza de date (ceea ce poate produce lock-uri conducand spre scaderea performantelor).

In utlimii ani, cantitatea de date stocate intro baza de date operationala (baza de date gestionata de un sistem OLTP) a crescut rapid. Astazi, multe baze de date pot stoca pana la cateva zeci sau chiar sute de GB de date. Si dupa cum vom vedea, aceasta cantitate este mica in comparatie cu depozitele de date (data warehouse).

Sistemele de Inteligenta Artificiala (business inteligence)

Inteligenta artificiala (BI – business inteligence) este procesul de integrare a cantitatilor uriase de date intrun singur spatiu de stocare in care utilizatorii sa poata rula interogari si rapoarte pentru a analiza datele existente. Cu alte cuvinte, scopul BI este de a pastra datele care pot fi accesate de utilizatorii care iau decizii pe baza analizelor. Aceste sisteme sunt adesea numite analitice sau informative, pentru ca accesand datele, utilizatorii pot obtine informatii pe baza carora pot lua decizii mai bune.

Scopul sistemelor BI este diferit de scopul sistemelor OLTP. Spre exemplu urmatoarea intrebare este o interogare pentru sistemele  BI: „Care este cea mai bine vanduta categorie de produse pentru fiecare regiune in semestrul al 3-lea din anul 2008 ?”. De aceea, un sistem BI are proprietati diferite fata de cele listate la sistemele OLTP (prezentate mai sus). Cateva dintre cele mai importante proprietati ale sistemelor BI sunt urmatoarele:

1.       Operatiunile de incarcare (load) se bazeaza pe un numar mare de randuri

2.       Numar mic de utilizatori

3.       Cantitati mari de date sunt stocate in baza de date

In afara de incarcarea cu date realizata la intervale regulate (de obicei, zilnic), sistemele BI sunt de obicei, sisteme deschise doar pentru citire (de aceea natura natura datelor intrun asemenea sistem este statica). Datele sunt aduse din surse diferite, curatate (se asigura consistenta) si incarcate intro baza de date numita depozit de date (data warehouse sau data mart). Datele curatate raman, de obicei, nemodificate dar ele pot fi modificate dupa procesul de curatare si inainte de incarcare. Pentru ca sistemele BI sunt utilizate pentru a obtine informatii, numarul utilizatorilor simultani este foarte mic in comparatie cu numarul utilizatorilor care acceseaza simultan un sistem OLTP. De obicei, utilizatorii unui sistem BI genereaza rapoarte care afiseaza diferiti indicatori cu privire la starea financiara a unei intreprinderi (sau departament), sau executa interogari complexe pentru a compara datele.

O alta deosebire intre sistemele OLAP si BI este aceea legata de disponibilitate, in timp ce un sistem OLTP poate fi accesat non – stop, un sistem BI poate fi accesat numai dupa ce acesta este incarcat cu date.

In timp ce un sistem OLTP stocheaza numai datele curente, un sistem BI trebuie sa tina cont si de modificarile istorice (spuneam mai devreme ca un sistem BI realizeaza comparatii intre date, ei bine acest lucru se poate realiza pe perioade diferite de timp). Din acest motiv, cantitatea de date stocata intr-un depozit de date este foarte mare.

Chissà quanti di voi si saranno posti questa domanda, vero?? Bene, cercherò di colmare le vostre lacune con questo post. Quindi mettetevi comodi davanti al vostro pc e leggete tutto con la massima attenzione in modo tale da non perdere nessun passaggio fondamentale.

Innanzitutto partiamo dal definire cos’è un Data warehouse. Esso è un archivio informatico contenente i dati di un’organizzazione. I DW sono progettati per consentire di produrre facilmente relazioni ed analisi.

Vengono considerati componenti essenziali di un sistema Data warehouse anche gli strumenti per localizzare i dati, per estrarli, trasformarli e caricarli, come pure gli strumenti per gestire un dizionario dei dati.

L’integrazione dei dati costituisce la principale caratteristica distintiva del DW rispetto ad altri sistemi di supporto alle decisioni. La raccolta dei dati deve essere: integrata, orientata al soggetto, variabile nel tempo e non volatile.

Esso si differenzia in modo sostanziale dai normali sistemi gestionali che, al contrario, hanno il compito di automatizzare le operazioni di routine.

Inoltre i  DW sono basi informative costruite per fornire informazioni aggregate e organizzate per aree tematiche. Le banche dati interattive sono applicazioni OLAP (On Line Analytical Processing) per l’analisi dei dati via Internet, basate su Data Warehouse costruiti a partire da archivi di diverse fonti e formati.
I prodotti consentono di interagire dinamicamente con le banche dati per ottenere report multidimensionali visualizzabili sia in forma tabellare che grafica (barre, torte, mappe territoriali) ed esportabili in Excel.
Le variabili disponibili e il dettaglio raggiungibile sono legati a differenti profili di utenza (utente anonimo, istituzionale con ambito nazionale/regionale/comunale).

A differenza delle analisi con tecnologia OLAP , la tecnologia OLTP non prevede la creazione di banche dati separate, infatti le analisi vengono effettuate direttamente sui dati di esercizio. Questa soluzione permette di avere i dati sempre aggiornati ed evita fasi intermedie di trasformazione dei dati, tuttavia per la sua stessa natura non è facilmente applicabile in situazioni dove la quantità di dati da analizzare sia molto elevata ed in questi casi viene generalmente preferito l’utilizzo di analisi di tipo OLAP.

Un Datawarehouse è un archivio informatico contenente i dati di un’organizzazione. Sono progettati per consentire di produrre facilmente relazioni ed analisi.
Vengono considerati DW anche gli strumenti per localizzare, estrarre, trasformare, gestire e caricare i dati. Requisiti fondamentali di un DW sono: l’ integrazione dei dati raccolti, l’orientamento al soggetto (temi aziendali specifici piuttosto che applicazioni o funzioni), variabilità nel tempo, non volatilità dei dati.

I sistemi di datawarehouse sono OLAP (On Line Analytical Processing) e la struttura dati OLAP  è costituita da poche tabelle non normalizzate. I sistemi OLTP, invece, sono On Line Transaction Processing e si differenziano dai sistemi OLAP per diverse caratteristiche:

Accuratezza:

• OLTP sul dettaglio
• OLAP sul consolidato

Copertura:

• OLTP funzionale
• OLAP Integrata

Ampiezza temporale/aggiornamento:

• OLTP limitata, immediato
• OLAP vasta (giorni o settimane)

Granularità:

• OLTP dettagli
• OLAP dettagli e aggregati

Query ad hoc:

• OLTP rare
• OLAP frequenti

L’ On-Line Analytical Proccessing (OLAP) è  l’analisi di grandi quantità di dati organizzati in modo denormalizzato in tabelle “dimensionali” (dimension tables) e “fatti” (fact tables).

Una struttura OLAP creata per questo scopo è chiamata “cubo” multidimensionale, in cui la tabella dei “fatti” elenca i principali elementi su cui sarà costruita l’interrogazione, collegate a questa tabella vi sono le tabelle delle “dimensioni” che specificano come i dati saranno aggregati. La tabella dei fatti racchiude dati generalmente in forma numerica (quantità, vendite, guadagni, perdite…) che vengono aggregati tramite funzioni (somma, media…) in base alle dimensioni specificate.

Le funzioni di base di questo strumento sono:

• Slicing: è l’operazione di rotazione delle dimensioni di analisi. È un’operazione fondamentale per analizzare totali ottenuti in base a dimensioni diverse o se si vogliono analizzare aggregazioni trasversali;
• Dicing: è l’operazione di estrazione di un subset di informazioni dall’aggregato che si sta analizzando. L’operazione di dicing viene eseguita quando l’analisi viene focalizzata su una ‘fetta del cubo’ avente particolare interesse per l’analista. In alcuni casi l’operazione di dicing può essere ‘fisica’ nel senso che non consiste solo nel filtrare le informazioni di interesse ma anche nell’estrarle dall’aggregato generale per distribuirne i contenuti

· roll-up: strumento di aggregazione dei dati, può accorpare due dimensioni di uno stesso cubo

· drill down: strumento di disaggregazione dei dati, attraverso l’ esplosione del dato nelle sue determinanti

· filtering: consente di selezionare i dati che ci interessano su ogni dimensione

Good morning everyone!

We are getting ready to wrap up the module on database management. As you are probably aware by now, relational databases underlie most of the modern information systems. Ecommerce websites, hospitals and college admissions offices would be in big trouble if their databases are not working properly.

On the other hand, well-designed databases open doors to so many exciting opportunites. Better marketing tactics, greater financial forecasting capabibilities, and real-time business intelligence at our fingertips. A better understanding of how relational databases work helps you become a better decision maker, provide better customer service, and run your organization more effectively.

IT150 gives you a sneak preview of database management – key jargons, basic skills, its potential benefits. To develop a more comprehensive understanding of database management, you can consider taking more advnaced  courses on this topic.

In the mean time, make sure you have accomplishes these learning objectives of this module:

• Articulate the differences between spreadsheets and databases
• Understand basic elements of Microsoft Access – fields, tables, primary keys, foreign keys, relationships, queries, forms, reports
• Describe principles of E-R diagramming – entities, relationships, cardinality, normalization
• Describe the differences between databases and data warehouses
• Describe the differences between OLTP and OLAP

So, how are you doing on this module? What is the most interesting part of this module? Which part is the most frustrating? What is intriquing? What is counter-intuitive?