Apostila Banco de Dados II

Jos Corra Viana

jcorrea@unipam.edu.br jcorreavian@hotmail.com twitter.com/rhuodox facebook.com/ jcorreaviana

Patos de Minas, 2012

Agradecimentos
Gostaria de agradecer a todas as pessoas que confiam na minha pessoa e no meu trabalho. Sem elas, chegar at aqui seria impossvel. Agradeo em especial a minha famlia. Ao meu pai Jos Donisete, minha me, Gessi Aparecida e meus irmos, Pedro Corra e Maria Laura Corra que sempre me apoiaram em todas as minhas decises. Agradeo separadamente a minha namorada Jessyka Cristina, que tambm faz parte da minha famlia, que me motiva e me encanta a cada minuto que se passa de minha vida. Agradeo a todos os meus colegas de trabalho, professores, colegas da rea de TI, pelo auxlio no desenvolvimento desse material e na ajuda de todos os dias. Em especial ao Fernando Corra por acreditar sempre em mim e ao Rafael Igor pelo esclarecimento de dvidas sobre assuntos novos para mim. Agradeo a todas as pessoas e empresas citadas nas referncias, pelos valiosos repositrios para buscas. Agradeo aos meus alunos que se depositaram em mim a possibilidade de aprender e ensinar. E fechando com chave de ouro, agradeo a voc que est lendo esse material agora. Muito Obrigado!

O que voc encontrar aqui

Um guia para esclarecimento, aprendizagem e atualizao de informaes sobre Banco de Dados, desde sua modelagem, aplicao de tcnicas de melhoria de performance e ferramentas de gesto, tanto para a Equipe de TI, quanto para a equipe estratgica das Empresas. Dvidas, sugestes e tudo mais que possa agregar valor essa apostila, basta entrar em contato.

Primeiros Conceitos
Definindo basicamente a linguagem SQL, vimos que ela visa definir uma linguagem global de manipulao de dados, que teve incio em 1970. Classificamos suas operaes em trs tipos, apresentados na tabela abaixo:
DML (Data Manipulation Language) DDL (Data Definition Language) DCL (Data Control Language)

SELECT; INSERT; UPDATE; DELETE. Nvel de dados

CREATE; ALTER; DROP. Nvel de tabela

GRANT; REVOKE.

Nvel de segurana

Na primeira aula realizamos um exerccio para normalizao de uma tabela, que representava um banco. Com a aplicao das trs formas de normalizao de banco, chegamos ao seguinte DER, seguindo algumas regras de negcio:

Lembrando que esse a primeira verso do DER, que provavelmente ter modificaes de acordo com novas regras de negcio definidas. Aps criarmos o DER, devemos criar um banco de dados, e, dentro desse banco, criarmos as tabelas, seguindo o modelo projetado:

Criando o Banco de Dados

Para criarmos o banco de dados, usamos a seguinte sintaxe: CREATE DATABASE Academico

Ou seja, estamos criando um novo banco de dadados, seguindo as configuraes padres do SQL Server 2008 para um novo banco de dados denominado Academico.

Criando as tabelas
Nesse primeiro instante, no iremos nos preocupar com os relacionamentos entre as tabelas. O script para gerao das tabelas, de acordo com o DER, segue abaixo:
USE Academico Create table [Pessoa] ( [IdPessoa] Integer Identity(1,1) NOT NULL, [IdSexo] Integer NOT NULL, [Nome] Varchar(200) NOT NULL, [DataNascimento] Datetime NOT NULL, [CPF] Varchar(11) NOT NULL, [NomePai] Varchar(200) NULL, [NomeMae] Varchar(200) NOT NULL, Primary Key ([IdPessoa]) ) go Create table [Disciplina] ( [IdDisciplina] Integer Identity(1,1) NOT NULL, [IdPessoaProfessor] Integer NOT NULL, [DescricaoDisciplina] Varchar(200) NOT NULL, Primary Key ([IdDisciplina]) ) go Create table [DisciplinaAluno] ( [IdDisciplina] Integer NOT NULL, [IdPessoa] Integer NOT NULL, [Nota] Integer NULL,

Primary Key ([IdDisciplina],[IdPessoa]) ) go Create table [Endereco] ( [IdEndereco] Integer Identity(1,1) NOT NULL, [IdPessoa] Integer NOT NULL, [IdCidade] Integer NOT NULL, [Logradouro] Varchar(200) NOT NULL, [Bairro] Varchar(100) NOT NULL, [Numero] Bigint NULL, Primary Key ([IdEndereco]) ) go Create table [Cidade] ( [IdCidade] Integer Identity(1,1) NOT NULL, [IdUF] Integer NOT NULL, [NomeCidade] Varchar(100) NOT NULL, Primary Key ([IdCidade]) ) go Create table [UF] ( [IdUF] Integer Identity(1,1) NOT NULL, [UF] Char(2) NOT NULL, [Estado] Varchar(100) NOT NULL, Primary Key ([IdUF]) ) go Create table [Usuario] ( [IdUsuario] Integer Identity(1,1) NOT NULL, [IdPessoa] Integer NOT NULL, [Usuario] Varchar(50) NOT NULL, [Senha] Varchar(200) NOT NULL, Primary Key ([IdUsuario]) ) go Create table [Aluno] ( [IdPessoa] Integer NOT NULL, [Matricula] Varchar(10) NOT NULL, [Usuario] Varchar(50) NOT NULL, [Senha] Varchar(200) NOT NULL, Primary Key ([IdPessoa]) ) go Create table [Telefone] ( [IdTelefone] Integer Identity(1,1) NOT NULL, [IdPessoa] Integer NOT NULL, [IdTipoTelefone] Integer NOT NULL, [Numero] Varchar(10) NOT NULL, Primary Key ([IdTelefone])

) go Create table [TipoTelefone] ( [IdTipoTelefone] Integer Identity(1,1) NOT NULL, [Descricao] Varchar(100) NOT NULL, Primary Key ([IdTipoTelefone]) ) go Create table [Sexo] ( [IdSexo] Integer Identity(1,1) NOT NULL, [Descricao] Char(1) NOT NULL, Primary Key ([IdSexo]) ) go Create table [Professor] ( [IdPessoa] Integer NOT NULL, Primary Key ([IdPessoa]) ) go

O comando USE Academico define em qual banco ser executado o script, nesse caso, no banco Academico. Quando utilizamos o IDENTITY(1,1) estamos querendo dizer que o campo definido com essa clusula ser incrementado de um valor inicial (primeiro parmetro) de acordo com o incremento definido (segundo parmetro). Portanto, no nosso projeto, o campo ter valores 1, 2, 3..., n. Se fosse IDENTITY(1,2) seria 1, 3, 5, ..., n.

PRIMARY KEY ([NomeCampo]) um exemplo de definio de chave primria em uma tabela. Outra maneira de definir um campo como chave primria poderia ser tambm: o [NomeCampo] INTEGER IDENTITY(1,1) PRIMARY KEY NOT NULL

Com isso teremos o nosso banco de dados j com as tabelas criadas. J podemos tambm inserir alguns dados no banco.

Comando Insert
Inicialmente, vamos fazer insero em duas tabelas na respectiva ordem: UF e Cidade.
INSERT VALUES ('MG', ('SP', ('RJ', GO INTO UF(UF, Estado) 'Minas Gerais'), 'So Paulo'), 'Rio de Janeiro')

INSERT INTO Cidade (IdUF, NomeCidade) VALUES (1, 'Patos de Minas'), (1, 'Uberlndia'), (2, 'So Paulo'), (3, 'Rio de Janeiro'), (1, 'Lagoa Formosa') GO

A relao entre um estado e uma cidade o campo que define de qual estado pertence uma cidade.
CREATE TABLE [Cidade] ( [IdCidade] INTEGER IDENTITY(1,1) NOT NULL, [IdUF] INTEGER NOT NULL, [NomeCidade] VARCHAR(100) NOT NULL, PRIMARY KEY ([IdCidade]) ) GO

Nesse caso IdUF o campo que faz essa ligao. Realizando algumas consultas:
SELECT * FROM UF SELECT * FROM Cidade

As consultas acima trazem todas as colunas e todos os registros da tabela. J as consultas abaixo utilizam parmetros de consulta. o A primeira consulta ir retornar todas as cidades que contenham MINAS no final de seu nome e o % indica que no h restrio para qualquer outro nome antes de MINAS. o A segunda retornar as cidades que tenham LAGOA como nome inicial, ignorando qualquer restrio de consulta para o restante.

Lembrando que o espao antes da expresso tambm pode afetar a consulta, pois assim estamos dizendo que existe uma diferenciao caso exista nomes compostos, como no exemplo.

SELECT * FROM Cidade WHERE NomeCidade LIKE '% MINAS' SELECT * FROM Cidade WHERE NomeCidade LIKE 'LAGOA %'

Comando Update
Atravs desse comando possvel realizar alteraes nos dados de uma tabela. A insero pode ser feita em uma ou mais linhas, de acordo com a necessidade. Vamos a alguns exemplos:
UPDATE Cidade SET NomeCidade = 'Americana' where IdUF = 2

A instruo Update acima atualiza a tabela chamada Cidade, alterando o campo NomeCidade para Americana onde o IdUF seja igual a 2. Notamos que independente que quantidade de cidades que temos, TODAS as cidades que tenham IdUF = 2 tero como no campo NomeCidade o valor Americana.

Porm podemos ser mais especficos e alterar o nome de apenas um registro por exemplo, atravs do seguinte comando:

UPDATE Cidade SET NomeCidade = 'So Paulo' where NomeCidade = 'Americana'

Com isso estaremos atualizando o valor para So Paulo somente onde campo NomeCidade possuir o valor Americana.

Alterando a estrutura de uma tabela

Existem DDLs para controle da tabela. Vamos falar da instruo Alter Table. Essa instruo pode ser utilizada para: o Adicionar uma nova coluna; o Alterar o tipo de dados de uma colua ou; o Remover colunas de uma tabela.

Vamos realizar uma alterao na tabela Endereco. Nessa tabela iremos adicionar o CEP do Endereo. Ento vamos l:
ALTER TABLE Endereco ADD CEP DATETIME NULL

Com essa estrutura estamos dizendo que vamos realizar uma alterao no banco, adicionando o CEP na tabela Endereco. Vamos realizar uma alterao nesse campo, pois sabemos que valor do tipo DateTime no interessante (e nem possvel) armazenar a estrutura do CEP de um endereo. para

ALTER TABLE Endereco ALTER COLUMN CEP VARCHAR (8) NULL

Com essa estrutura estamos dizemos que vamos realizar uma alterao no banco, alterando a estrutura do campo CEP na tabela Endereco. Assim estamos determinando que o campo CEP agora ser no tipo Varchar(8), que o tamanho necessrio para armazenar o dado de CEP.

E se tivermos uma coluna que queremos excluir? Fcil! Iremos proceder da seguinte maneira (para apresentar essa clusula iremos criar um campo somente para apresentarmos a estrutura para excluso do campo):

ALTER TABLE Endereco ADD Complemento2 VARCHAR(100) NULL ALTER TABLE Endereco DROP COLUMN Complemento2

Com essa estrutura estamos dizemos que vamos realizar uma alterao no banco, excluindo o campo Complemento na tabela Endereco.

Caso queiramos excluir mais de uma coluna tambm possvel, seria assim:

ALTER TABLE Endereco DROP COLUMN Complemento2, Complemento3

Agora vamos fazer uma excluso na tabela cidade, seguindo a expresso:

DELETE FROM Cidade WHERE NomeCidade = 'Lagoa Formosa'

A consulta ir excluir o registro na tabela Cidade onde o nome seja igual Lagoa Formosa; Como no est sendo utilizado a condio LIKE juntamente com %, a excluso ser efetuada somente para o registro que contenha exatamente o mesmo valor da expresso;

Aps a execuo dessa expresso DML, a Cidade Lagoa Formosa ser excluda do banco de dados.

Agora vamos excluir um estado, seguindo a expresso:

DELETE FROM UF where IdUF = 1

Essa expresso DML acarretar na excluso do estado onde o IdUF seja igual a 1. Diferentes condies podem ser utlizadas para a seleo dos valores a serem excludos, como em uma consuta.

Porm, uma ao dessa traz alguns efeitos colaterais para as informaes contidas em nosso banco de dados. Vamos pensar: Existia um estado chamado Minas Gerais; Existe cidades vinculadas a esse estado; Eu exclu o estado; E agora?

Para evitar que aes como essas ocorram, existem restries que podemos inserir no banco de dados, ajudando a manter a integridade das informaes e garantindo que a regra de dependncia entre as tabelas seja cumprida. Vamos comear fazendo essa restrio para o nosso relacionamento entre a tabela UF e a tabela Cidade; Sabemos que um estado composto por uma ou mais cidades e que as cidades so pertencentes de um estado;

Portanto vamos criar essa estrutura de dependncia entre as informaes:

ALTER TABLE Cidade ADD CONSTRAINT FK_Cidade_UF FOREIGN KEY (IdUF) REFERENCES UF (IdUF)

Uma mensagem de erro semelhante a mensagem abaixo ir surgir:

Msg 547, Level 16, State 0, Line 1 The ALTER TABLE statement conflicted with the FOREIGN KEY constraint "FK_Cidade_UF". The conflict occurred in database "Academico", table "dbo.UF", column 'IdUF'.

Isso acontece pois ainda existem registros na tabela Cidade que no possuem o campo que cria a dependncia entre a tabela UF. Para criarmos a regra de integridade, vamos excluir os dados que referenciam um estado que no existe mais:

DELETE FROM Cidade WHERE IdUF = 1

Com essa consulta, exclumos todas as cidades que possuam Minas Gerais como estado. Vamos executar novamente a funo DDL para criar a regra de integridade entre as tabelas:

ALTER TABLE Cidade ADD CONSTRAINT FK_Cidade_UF FOREIGN KEY (IdUF) REFERENCES UF (IdUF)

Agora sim notamos que o script foi executado com sucesso. Vamos tentar excluir um estado que possui cidades vinculadas a ele:

DELETE FROM UF WHERE IdUF = 2

A seguinte mensagem de erro exibida:

Msg 547, Level 16, State 0, Line 1 The DELETE statement conflicted with the REFERENCE constraint "FK_Cidade_UF". The conflict occurred in database "Academico", table "dbo.Cidade", column 'IdUF'. The statement has been terminated.

Notamos que no foi possvel realizar a excluso do estado que possui o IdUF igual a 2. Isso ocorre pois existe no mnimo um registro que referencia o valor que queremos excluir, no caso, a cidade de So Paulo. Exsitem outras maneiras de se criar a regra de integridade.

DICA: mais cmodo realizar a criao das Constraints aps ter criado todas as tabelas, pois, para existir um relacionamento entre duas tabelas, necessrio que as mesmas estejam criadas.

Integridade de dados
S para relembrar, a integridade de dados o que garante a confiabilidade, a veracidade ou a consistncia dos dados salvos em um banco. Um exemplo da aplicao de uma regra de integridade j foi relizada anteriormente. Vamos relembrar:
ALTER TABLE Cidade ADD CONSTRAINT FK_Cidade_UF FOREIGN KEY (IdUF) REFERENCES UF (IdUF)

Com esse comando adicionamos uma regra de integridade entre duas tabelas, onde o campo que relacionado em uma tabela dependente, fica fortemente ligado a sua origem. Abaixo uma tabale com os tipos de integridade existentes: Tipo de Integridade Domnio Entidade Referencial Tipo de Constraint Default Check Primary Key Unique Foreign Key Check

Uma restrio pode ser criada no momento em que uma tabela: o criada (CREATE TABLE) ou; o alterada (ALTER TABLE).

Alm disso possvel adicionar contraints em tabelas com dados Podemos inserir constraints em uma ou vrias colunas: o Em uma coluna: nvel de coluna; o Em vrias colunas: nvel de tabela.

Tipos de Constraints
Neste tpico iremos estudar os tipos de constraints. Para exemplificar cada tipo, utitlizaremos como exemplo as tabelas de nosso banco de dados.

1. Constraints NOT NULL Essa constraint assegura que no exista valores nulos em uma coluna; Essa informao definida a nvel de coluna (deve ser informado para cada coluna); Ela pode ser criada da seguinte maneira:

Create table [TipoTelefone] ( [IdTipoTelefone] Integer Identity(1,1) NOT NULL, [Descricao] Varchar(100) NOT NULL, Primary Key ([IdTipoTelefone]) )

ou ento
Create table [TipoTelefone] ( [IdTipoTelefone] Integer Identity(1,1) NOT NULL, [Descricao] Varchar(100), ) ALTER TABLE TipoTelefone ALTER COLUMN Descricao Varchar(100) NOT NULL

2. Constraints PRIMARY KEY Essa constraint cria um ndice exclusivo em uma coluna especfica, onde os valores devem ser exclusivos e no podem ser nulos; permitido apenas uma restrio PRIMARY KEY por tabela.

Create table [TipoTelefone] ( [IdTipoTelefone] Integer Identity(1,1) NOT NULL, [Descricao] Varchar(100) NOT NULL, Primary Key ([IdTipoTelefone]) )

ou ento
Create table [TipoTelefone] ( [IdTipoTelefone] Integer Identity(1,1) Primary Key NOT NULL, [Descricao] Varchar(100) NOT NULL, )

ou ento
Create table [TipoTelefone] ( [IdTipoTelefone] Integer Identity(1,1) NOT NULL, [Descricao] Varchar(100) NOT NULL, Constraint PK_TipoTelefone Primary Key ([IdTipoTelefone]) )

possvel ainda realizar a criao da constraint aps a criao de uma tabela, desde que respeite a regra de integridade da constraint.

ALTER TABLE TipoTelefone ADD CONSTRAINT PK_TipoTelefone PRIMARY KEY (IdTipoTelefone)

Tambm possvel realizar a criao de chaves compostas, somente em nvel de tabela:

Create table [DisciplinaAluno] ( [IdDisciplina] Integer NOT NULL, [IdPessoa] Integer NOT NULL, [Nota] Integer NULL, Primary Key ([IdDisciplina],[IdPessoa]) )

ou ento
Create table [DisciplinaAluno] ( [IdDisciplina] Integer NOT NULL, [IdPessoa] Integer NOT NULL, [Nota] Integer NULL, CONSTRAINT PK_NotaAlunoDisciplina Primary Key ([IdDisciplina],[IdPessoa]) )

3. Constraints DEFAULT As instruo default so utilizadas para definir um valor padro para uma determinada coluna, permitindo tambm alguns valores permitidos pelo sistema. Essas constraints so aplicadas as instrues INSERT.

Create table [DisciplinaAluno] ( [IdDisciplina] Integer NOT NULL, [IdPessoa] Integer NOT NULL, [Nota] Integer Constraint [DF_NotaBase] Default 0 NOT NULL, CONSTRAINT PK_NotaAlunoDisciplina Primary Key ([IdDisciplina],[IdPessoa]) ) go

ou ento
Create table [DisciplinaAluno] ( [IdDisciplina] Integer NOT NULL, [IdPessoa] Integer NOT NULL, [Nota] Integer Default 0 NOT NULL, CONSTRAINT PK_NotaAlunoDisciplina Primary Key ([IdDisciplina],[IdPessoa]) )

ou ento
ALTER TABLE DisciplinaAlunoTeste ADD CONSTRAINT DF_NotaBase DEFAULT 0 FOR Nota

4. Constraints CHECK
Essa instrues podem ser utilizadas tanto para INSERT quanto para UPDATE. Alm disso possvel utilizar outras colunas da mesma tabela para referenciar, porm no podem conter subconsultas.
Create table [Pessoa] ( [IdPessoa] Integer Identity(1,1) NOT NULL, [IdSexo] Integer NOT NULL,

[Nome] Varchar(200) NOT NULL, [DataNascimento] Datetime CONSTRAINT CK_DataNascimento CHECK (DataNascimento > '01-01-1990' AND DataNascimento < GETDATE()) NOT NULL, [CPF] Varchar(11) NOT NULL, [NomePai] Varchar(200) NULL, [NomeMae] Varchar(200) NOT NULL, Primary Key ([IdPessoa]) )

ou ento
Create table [Pessoa] ( [IdPessoa] Integer Identity(1,1) NOT NULL, [IdSexo] Integer NOT NULL, [Nome] Varchar(200) NOT NULL, [DataNascimento] Datetime CHECK (DataNascimento > '01-01-1990' AND DataNascimento < GETDATE()) NOT NULL, [CPF] Varchar(11) NOT NULL, [NomePai] Varchar(200) NULL, [NomeMae] Varchar(200) NOT NULL, Primary Key ([IdPessoa]) )

ou ainda
ALTER TABLE Pessoa ADD CONSTRAINT CK_DataNascimento CHECK AND DataNascimento < GETDATE()) GO (DataNascimento > '01-01-1990'

5. Constraints UNIQUE
As constrains UNIQUE impem um ndice exclusico para o valor de um campo, permitidno valor nulo. permitido vrias restries UNIQUE em uma tabela:

Create table [UF] ( [IdUF] Integer Identity(1,1) NOT NULL, [UF] Char(2) NOT NULL UNIQUE, [Estado] Varchar(100) NOT NULL, Primary Key ([IdUF]) )

ou ento
Create table [UF] ( [IdUF] Integer Identity(1,1) NOT NULL,

[UF] Char(2) NOT NULL, UNIQUE (UF), [Estado] Varchar(100) NOT NULL, Primary Key ([IdUF]) )

possvel criar a constraint UNIQUE para mais de uma coluna:

Create table [UF] ( [IdUF] Integer Identity(1,1) NOT NULL, [UF] Char(2) NOT NULL, [Estado] Varchar(100) NOT NULL, Primary Key ([IdUF]), CONSTRAINT UK_Estado UNIQUE (UF, Estado) )

ou ento
ALTER TABLE UF ADD CONSTRAINT UK_Estado UNIQUE (UF, Estado)

6. Constraints FOREIGN KEY

Esse tipo de constraint deve fazer uma referncia a uma restrio PRIMARY KEY ou UNIQUE. utilizada para fornecer integridade referencial de uma ou vrias colunas, e os ndices no so criados automaticamente, como no caso de outras constraints. Os usurios devem ter permisses SELECT ou REFERENCES em tabelas que utilizam essa referncia. Essa a referncia a nvel de coluna:
Create table [Cidade] ( [IdCidade] Integer Identity(1,1) NOT NULL, [IdUF] Integer FOREIGN KEY REFERENCES UF (IdUF) [NomeCidade] Varchar(100) NOT NULL, Primary Key ([IdCidade]) )

NOT NULL,

Essa a referncia a nvel de tabela:

Create table [Cidade] ( [IdCidade] Integer Identity(1,1) NOT NULL, [IdUF] Integer NOT NULL, [NomeCidade] Varchar(100) NOT NULL FOREIGN KEY (IdUF) REFERENCES UF (IdUF) Primary Key ([IdCidade]) )

ou ento
ALTER TABLE Cidade ADD CONSTRAINT FK_Cidade_UF FOREIGN KEY (IdUF) REFERENCES UF (IdUF)

Integridade Referencial em Cascata

FOREIGN KEY vincula os dados da tabela filha enquanto exista referncia de dados com a tabela me; REFERENCES utilizado para indicar a tabela e qual coluna utilizada como referncia na tabela me; ON DELETE CASCADE: Ao efetuar uma excluso de um valor na tabela me, todas as linhas que dependiam desse valor tambm so excludas; ON UPDATE CASCADE: Ao efetuar uma atualizao de um valor na tabela me, todas as linhas que dependiam desse valor tambm so atualizadas.

Create table [Cidade] ( [IdCidade] Integer Identity(1,1) NOT NULL, [IdUF] Integer FOREIGN KEY REFERENCES UF (IdUF) ON DELETE CASCADE NOT NULL, [NomeCidade] Varchar(100) NOT NULL, Primary Key ([IdCidade]) )

ou ento
ALTER TABLE Cidade ADD CONSTRAINT FK_Cidade_Estado FOREIGN KEY([IdUF])

REFERENCES [dbo].[UF] ([IdUF]) ON DELETE CASCADE ON UPDATE CASCADE GO

Removendo uma constraint

Para remover uma constraint utilizamos a seguinte instruo:

ALTER TABLE UF DROP CONSTRAINT PK_UF

Para excluso de constraints PRIMARY KEY E UNIQUE KEY, suas referncias devem ser removidas, no podendo haver nenhuma outra constraint de FOREIGN KEY. Para efetuar a excluso: Remova primeiro a constraint de FOREIGN KEY. o No nosso caso, como a tabela Cidade referencia a tabela UF, devmos excluir a constraint FOREIGN KEY FK_Cidade_UF na tabela Cidade:
ALTER TABLE Cidade DROP CONSTRAINT FK_Cidade_UF

o E depois excluir a constraint PK_UF na tabela UF:

ALTER TABLE UF DROP CONSTRAINT PK_UF

Desativando uma constraint

Utilizado para processamento de operaes em lote (grande volume de dados); Utilizando essa instruo ignorada a verificao da relao entre as tabelas; S possvel desativar as constraints FOREIGN KEY e CHECK.

ALTER TABLE Cidade WITH NOCHECK ADD CONSTRAINT FK_Cidade_UF FOREIGN KEY (IdUF) REFERENCES UF (IdUF)

Criando uma constraint FOREIGN KEY dessa maneira estamos querendo dizer que no ser verificado se existe integridade de relacionamento entre a tabela Cidade e a tabela UF. Para desativar uma constraint de chave estrangeira:
ALTER TABLE Cidade NOCHECK CONSTRAINT FK_Cidade_UF

Aps essa modificao possvel realizar a insero de um dado que no obedea a regra de integridade:
INSERT INTO Cidade (IdUF, NomeCidade) VALUES (7, 'Maria Mole')

Para reativar a constraint, executamos a instruo:

ALTER TABLE Cidade CHECK CONSTRAINT FK_Cidade_UF

Agora, se tentarmos efetuar uma insero que no obedea a regra de integridade:

INSERT INTO Cidade (IdUF, NomeCidade) VALUES (8, 'Po de Queijo')

Ser exibido o erro:

Msg 547, Level 16, State 0, Line 1 The INSERT statement conflicted with the FOREIGN KEY constraint "FK_Cidade_UF". The conflict occurred in database "Academico", table "dbo.UF", column 'IdUF'. The statement has been terminated.

Informando que no possvel realizar insero, pois o IdUF que estamos informando no existe na tebela UF.

Criar Views

So instrues SELECT que so armazenadas no banco; O acesso delas via select.

A instruo para criao de uma View :

DROP VIEW VW_Pessoa GO CREATE VIEW VW_Pessoa AS SELECT IdPessoa, Nome, NomeMae, NomePai, CPF FROM Pessoa

As duas primeiras linhas so para a excluso da view, caso ela exista. Aps isso, criamos uma view com o nome de VW_Pessoa que busca na tabela Pessoa os dados IdPessoa, Nome, NomeMae, NomePai, CPF.

Alm disso possvel adicionar dados em uma view, e assim, adicionar valores em uma tabela:

CREATE VIEW VW_UF AS SELECT IdUF, UF, Estado FROM UF INSERT INTO VW_UF (UF, Estado) VALUES ('SC', 'Santa Catarina') SELECT * FROM VW_UF

Inicialmente criamos uma nova view chamada VW_UF; Aps isso realizamos um insert na prpria view, lembrando que necessrio obedecer as constraints existentes na tabela para fazer uma nova insero;

Aps isso realizamos uma consulta, para ver que o novo valor consta em nossa tabela UF.

Tambm podemos utilizar a view para gerar consultas atravs de unies entre as tabelas:
CREATE VIEW VW_Cidade_Estado AS SELECT C.NomeCidade, U.Estado, U.UF FROM UF AS U INNER JOIN Cidade AS C ON U.IdUF = C.IdUF SELECT * FROM VW_Cidade_Estado

Assim estamos criando uma view chamanda VW_Cidade_Estado, que realiza a unio entre a tabela Estado e a tabela Cidade, que so ligadas atravs do campo IdUF.

No final teremos uma view que nos apresenta o nome da cidade, o estado e a unidade federativa de cada estado.

Atualizao do banco de dados

De acordo com os novos requisitos indentificados e trabalhados em sala de aula, irei disponibilizar abaixo o DER e o Script para gerao do banco atualizado: Requisitos Cada professor deve possuir obrigatoriamente um contrato de trabalho; Tanto o aluno quanto o professor devem possuir um usurio; O usurio de aluno ser sua matrcula; O professor deve ter como usurio o cdigo do professor; O sistema deve registrar uma senha padro para acesso ao sistema, j criptografada em MD5; Uma turma pode ou no ter uma ou mais disciplinas e a disciplina pode ser de uma ou mais turmas Devem ser registrados os Cursos da instituio. As turmas so vinculadas a um curso. As turmas so apenas de um curso e um curso deve possuir no mnimo uma turma;

necessrio realizar o cadastro de um semestre. O semestre deve possuir um cdigo de identificao, a data incio e a data fim do semestre.

Tanto o professor quanto o aluno devem estrar matriculados em um semestre. Uma disciplina no precisa estar vinculada nem a um professor e nem a uma turma.

DER

Script do banco
CREATE TABLE [Pessoa] ( [IdPessoa] INTEGER IDENTITY(1,1) NOT NULL, [IdSexo] INTEGER NOT NULL, [Nome] VARCHAR(200) NOT NULL, [DataNascimento] DATETIME NOT NULL, [CPF] VARCHAR(11) NOT NULL, [NomePai] VARCHAR(200) NULL,

[NomeMae] VARCHAR(200) NOT NULL, PRIMARY KEY ([IdPessoa]) ) GO CREATE TABLE [Disciplina] ( [IdDisciplina] INTEGER IDENTITY(1,1) NOT NULL, [IdPessoaProfessor] INTEGER NOT NULL, [IdTurma] INTEGER NOT NULL, [DescricaoDisciplina] VARCHAR(200) NOT NULL, PRIMARY KEY ([IdDisciplina]) ) GO CREATE TABLE [DisciplinaAluno] ( [IdDisciplina] INTEGER NOT NULL, [IdPessoa] INTEGER NOT NULL, [Nota] INTEGER NULL, PRIMARY KEY ([IdDisciplina],[IdPessoa]) ) GO CREATE TABLE [Endereco] ( [IdEndereco] INTEGER IDENTITY(1,1) NOT NULL, [IdPessoa] INTEGER NOT NULL, [IdCidade] INTEGER NOT NULL, [Logradouro] VARCHAR(200) NOT NULL, [Bairro] VARCHAR(100) NOT NULL, [Numero] BIGINT NULL, PRIMARY KEY ([IdEndereco]) ) GO CREATE TABLE [Cidade] ( [IdCidade] INTEGER IDENTITY(1,1) NOT NULL, [IdUF] INTEGER NOT NULL, [NomeCidade] VARCHAR(100) NOT NULL, PRIMARY KEY ([IdCidade]) ) GO CREATE TABLE [UF] ( [IdUF] INTEGER IDENTITY(1,1) NOT NULL, [UF] CHAR(2) NOT NULL, [Estado] VARCHAR(100) NOT NULL, PRIMARY KEY ([IdUF]) ) GO

CREATE TABLE [Usuario] ( [IdPessoa] INTEGER NOT NULL, [Usuario] VARCHAR(50) NOT NULL, [Senha] VARCHAR(200) NOT NULL, PRIMARY KEY ([IdPessoa]) ) GO CREATE TABLE [Aluno] ( [IdPessoa] INTEGER NOT NULL, [Matricula] VARCHAR(10) NOT NULL, PRIMARY KEY ([IdPessoa]) ) GO CREATE TABLE [Telefone] ( [IdTelefone] INTEGER IDENTITY(1,1) NOT NULL, [IdPessoa] INTEGER NOT NULL, [IdTipoTelefone] INTEGER NOT NULL, [Numero] VARCHAR(10) NOT NULL, PRIMARY KEY ([IdTelefone]) ) GO CREATE TABLE [TipoTelefone] ( [IdTipoTelefone] INTEGER IDENTITY(1,1) NOT NULL, [Descricao] VARCHAR(100) NOT NULL, PRIMARY KEY ([IdTipoTelefone]) ) GO CREATE TABLE [Sexo] ( [IdSexo] INTEGER IDENTITY(1,1) NOT NULL, [Descricao] CHAR(1) NOT NULL, PRIMARY KEY ([IdSexo]) ) GO CREATE TABLE [Professor] ( [IdPessoa] INTEGER NOT NULL, [IdTipoContrato] INTEGER NOT NULL, [IdSemestre] INTEGER NOT NULL, [CodiGOProfessor] VARCHAR(10) NOT NULL, PRIMARY KEY ([IdPessoa]) ) GO

CREATE TABLE [TipoContrato] ( [IdTipoContrato] INTEGER IDENTITY(1,1) NOT NULL, [DescricaoTipoContrato] VARCHAR(100) NOT NULL, [CargaHorariaContrato] INTEGER NOT NULL, PRIMARY KEY ([IdTipoContrato]) ) GO CREATE TABLE [Turma] ( [IdTurma] INTEGER IDENTITY(1,1) NOT NULL, [CodiGOTurma] VARCHAR(30) NOT NULL, [IdCurso] INTEGER NOT NULL, PRIMARY KEY ([IdTurma]) ) GO CREATE TABLE [Curso] ( [IdCurso] INTEGER IDENTITY(1,1) NOT NULL, [CodiGOCurso] INTEGER NOT NULL, [DescricaoCurso] VARCHAR(100) NOT NULL, PRIMARY KEY ([IdCurso]) ) GO CREATE TABLE [Semestre] ( [IdSemestre] INTEGER IDENTITY (1,1) NOT NULL, [CodiGOSemestre] VARCHAR(6) NOT NULL, [DataInicioSemestre] DATETIME NOT NULL, [DataFimSemestre] DATETIME NOT NULL, PRIMARY KEY ([IdSemestre]) ) GO CREATE TABLE [AlunoSemestre] ( [IdPessoa] INTEGER NOT NULL, [IdSemestre] INTEGER NOT NULL, [MediaAlunoSemestre] DECIMAL(5,2) NULL, PRIMARY KEY ([IdPessoa],[IdSemestre]) ) GO

ALTER TABLE ADD FOREIGN GO ALTER TABLE ADD FOREIGN

[Endereco] KEY([IdPessoa]) REFERENCES [Pessoa] ([IdPessoa]) [Usuario] KEY([IdPessoa]) REFERENCES [Pessoa] ([IdPessoa])

GO ALTER TABLE [Aluno] ADD FOREIGN KEY([IdPessoa]) REFERENCES [Pessoa] ([IdPessoa]) GO ALTER TABLE [Telefone] ADD FOREIGN KEY([IdPessoa]) REFERENCES [Pessoa] ([IdPessoa]) GO ALTER TABLE [Professor] ADD FOREIGN KEY([IdPessoa]) REFERENCES [Pessoa] ([IdPessoa]) GO ALTER TABLE [DisciplinaAluno] ADD FOREIGN KEY([IdDisciplina]) REFERENCES [Disciplina] ([IdDisciplina]) GO ALTER TABLE [Endereco] ADD FOREIGN KEY([IdCidade]) REFERENCES [Cidade] ([IdCidade]) GO ALTER TABLE [Cidade] ADD FOREIGN KEY([IdUF]) REFERENCES [UF] ([IdUF]) GO ALTER TABLE [DisciplinaAluno] ADD FOREIGN KEY([IdPessoa]) REFERENCES [Aluno] ([IdPessoa]) GO ALTER TABLE [AlunoSemestre] ADD FOREIGN KEY([IdPessoa]) REFERENCES [Aluno] ([IdPessoa]) GO ALTER TABLE [Telefone] ADD FOREIGN KEY([IdTipoTelefone]) REFERENCES [TipoTelefone] ([IdTipoTelefone]) GO ALTER TABLE [Pessoa] ADD FOREIGN KEY([IdSexo]) REFERENCES [Sexo] ([IdSexo]) GO ALTER TABLE [Disciplina] ADD FOREIGN KEY([IdPessoaProfessor]) REFERENCES [Professor] ([IdPessoa]) GO ALTER TABLE [Professor] ADD FOREIGN KEY([IdTipoContrato]) REFERENCES [TipoContrato] ([IdTipoContrato]) GO ALTER TABLE [Disciplina] ADD FOREIGN KEY([IdTurma]) REFERENCES [Turma] ([IdTurma]) GO ALTER TABLE [Turma] ADD FOREIGN KEY([IdCurso]) REFERENCES [Curso] ([IdCurso]) GO ALTER TABLE [Professor] ADD FOREIGN KEY([IdSemestre]) REFERENCES [Semestre] ([IdSemestre]) GO ALTER TABLE [AlunoSemestre] ADD FOREIGN KEY([IdSemestre]) REFERENCES [Semestre] ([IdSemestre]) GO

Triggers
Trigger um bloco de comandos Transact-SQL que executando quando ocorre um comando INSERT, DELETE ou UPDATE for executando em um banco de dados. Alguns exemplos de aplicaes: Validaes; Rotinas; Consistncia de dados; Anlise de dados; Alterao em tabelas que referenciam uma tabela que est sendo trabalhada. Existem trs aspectos importantes de um gatilho: Evento: uma alterao que ativa a trigger; Condio: consulta ou teste executado quanto a trigger ativada; Ao: procedimento executando quando a condio atendida.

Abaixo, uma Trigger criada para nosso banco de dados Acadmico. Essa Trigger ser executada sempre que um novo aluno for inserido ou atualizado no banco:
USE [Academico] GO /*CRIAO DA TRIGGER NA TEBELA "Aluno", QUE SER EXECUTADA SEMPRE QUE UM VALOR FOR ADICIONADO OU ALTERADO NA TABELA*/ CREATE TRIGGER CriarUsuario ON Aluno /*DEFINIO DE QUANDO ELA SER EXECUTADA, NESSE CASO APS UM INSERT OU UPDATE*/ AFTER INSERT, UPDATE AS /*DECLARAO DAS VARIVEIS QUE SERO NECESSRIAS*/ DECLARE @IdPessoa INT DECLARE @Matricula VARCHAR(10) DECLARE @verificaUsuario BIT DECLARE @buscaUsuario VARCHAR(50) DECLARE @Mensagem VARCHAR(8000) /*BUSCA DE DADOS NA TABELA TEMPORRIA "INSERTED",

QUE J CRIADA PELO PRPRIO SQL SERVER*/ SELECT @IdPessoa = IdPessoa, @Matricula = Matricula FROM INSERTED SELECT @buscaUsuario = Usuario FROM Usuario WHERE Usuario = @Matricula /*CASO J EXISTA UM USURIO NO BANCO PARA A MATRCULA INFORMADA, A TRIGGER RETORNAR UM ERRO*/ IF (@buscaUsuario IS NOT NULL) BEGIN SELECT @Mensagem = 'J existe um usurio para a matrcula informada'; RAISERROR (@Mensagem, 16, 10) RETURN END /*CASO CONTRRIO, UM USURIO SER CRIADO PARA UM ALUNO ASSIM QUE ELE SEJA INSERIDO OU ATUALIZADO NO BANCO DE DADOS*/ ELSE --(@buscaUsuario IS NULL) BEGIN INSERT INTO Usuario (IdPessoa, Usuario, Senha) VALUES (@IdPessoa, @Matricula, HASHBYTES('MD5', '123456')) END RETURN GO

Vamos agora as definies das palavras reservadas de uma Trigger:

CREATE TRIGGER CriarUsuario

o comando para se criar uma nova

Trigger. o Caso uma Trigger j esteja criada possvel alterar ela atravs do comando ALTER TRIGGER Nome_Trigger criada; o O comando para excluso de uma Trigger DROP TRIGGER Nome_Trigger ;
ON Aluno AFTER INSERT, UPDATE

define em qual tabela a Trigger ser

criada e em quais condies ela ser executada. Exemplo: o Em nossa Trigger, caso efetuarmos um INSERT INTO ALUNO ou UPDATE ALUNO essa Trigger ser executada.
DECLARE @IdPessoa INT

e as demais declaraes de variveis so

utilizadas para criar variveis locais que sero utilizadas como apoio na estrutura da Trigger. o DICA: Sempre trabalhe com varivies que so compatveis com o valor que ela ir receber, tanto em tipo quanto em limite de

tamanho. Alm disso, crie variveis com nome amigveis, assim fica mais fcil de se situar durante a criao ou mapeamento de uma Trigger ou qualquer estrutura que necessecite da criao de variveis.
SELECT INSERTED @IdPessoa = IdPessoa, @Matricula = Matricula FROM

j nossa conhecida. A diferena existente a origem dos

dados. A tabela INSERTED uma tabela temporria criada no banco de dados. Ela utilizada para buscar os dados que so manipulados durante a execuo de uma Trigger. O SQL Server mantm duas tabelas para controle das transaes do banco: INSERTED E DELETED. o Ao executar o comando INSERT: O novo registro ser armazenado na tabela INSERTED; o Ao executar o comando DELETE: O registro excludo ser armazenado na tabela DELETED; o Ao executar o comando UPDATE: O novo registro ser armazenado na tabela INSERTED e o antigo armazenado na tabela DELETED. O comando
IF (@buscaUsuario IS NOT NULL) BEGIN SELECT

@Mensagem = 'J existe um usurio para a matrcula informada'; RAISERROR (@Mensagem, 16, 10) RETURN END

retorna uma mensagem

para o utilizador do banco, informando que uma condio no foi verdadeira. No nosso exemplo, se a pessoa j possuir um usurio cadastrado, ela no pode inserir mais um.

Caso a condio seja atendida, ento temos o

ELSE --(@buscaUsuario

IS NULL) BEGIN INSERT INTO Usuario (IdPessoa, Usuario, Senha) VALUES (@IdPessoa, @Matricula, HASHBYTES('MD5', '123456')) END

que realiza a insero de um novo usuario na tabela Usuario. DICA: Um post interessante como auxlio para estudos sobre Triggers: http://www.devmedia.com.br/introducao-a-triggers/1695 As Triggers criadas podem ser visualizadas pela prpria tabela para qual ela criada:

Alm disso possvel ativar ou desativar uma Trigger. Para isso basta clicar com o boto direito sobre a Trigger e clicar em Disable (ou Desabilitar dependendo do idioma):

Assim ela ficar com uma seta vermelha em seu cone, indicando que ela est desabilitada. Para habilit-la basta clicar com o boto direito sobre ela e escolher a opo Enable (ou Habilitar, dependendo do idioma):

Legal ! Vamos para o prximo tpico: Stored Procedure! \o/

Stored Procedures
Stored Procedure um trecho de cdigo Transact SQL armazenado no banco de dados, que pode receber parmetros e retornar valores. Quando uma Stored Procedure executada, realizada uma compilao da mesma. Resumindo, Stored Procedure basicamente pode ser uma ou mais aes que so salvas no banco de dados e que podem ser solicitadas sempre que necessrio. As SPs podem ser utilizadas para muitos fins, como: Executar comandos INSERT; Executar comandos DELETE; Executar comandos UPDATE; Executar comandos SELECT; Efetuar controle em lista de registros (Cursor); Efetuar a execuo de outras SPs.

Utilizando o banco Acadmico, iremos criar algumas SPS.

CREATE PROCEDURE SP_InsereSexo ( @Descricao CHAR (1) ) AS BEGIN INSERT INTO Sexo (Descricao) VALUES (@Descricao) END GO

A Stored Procedure acima acionada para realizar um INSERT na tabela Sexo.

O comando CREATE PROCEDURE SP_InsereSexo utilizado para definir que estamos criando uma Stored Procedure e que o nome dela ser SP_InsereSexo; Dentro dos parnteses informamos qual (so) a(s) varivel (eis) que sero utilizadas em nossa Stored Procedure. No caso dessa SP teremos apenas um campo, que no caso ser referenciado pela varivel @Descricao CHAR (1); No bloco AS BEGIN END informamos qual ou quais aes iremos realizar. No caso dessa SP iremos realizar um insert, ento iremos definir que para o campo Descricao na tablea Sexo, o valor a ser inserido ser o da varivel @Descrio.

A execuo da Stored Procedure pode ser feita de duas maneiras:

EXEC SP_InsereSexo 'M'

o comando realizado a nvel de script de

banco, onde passado o valor da varivel a ser inserida; Outra maneira de executar a SP diretamente pela tabela. Primeiramente abrimos o local onde se encontram as SPs:

Aps isso clicamos com o boto direito sobre a SP que queremos executar e escolhemos a opo Execute Stored Procedure...:

Depois disso informamos o valor para a(s) varivel (eis) da SP e clicamos em OK. Assim a SP ser executada:

Exemplo de Stored Procedure para UPDATE

CREATE PROCEDURE SP_AlteraSexo ( @Descricao CHAR (1) ) AS BEGIN UPDATE INTO Sexo (Descricao) VALUES (@Descricao) END GO

Exemplo de Stored Procedure para DELETE

CREATE PROCEDURE SP_ExcluiDisciplina ( @NomeDisciplina VARCHAR (100) ) AS BEGIN DELETE FROM Disciplina WHERE DescricaoDisciplina = @NomeDisciplina END GO

Exemplo de Stored Procedure para SELECT

CREATE PROCEDURE [dbo].[SP_BuscaTodasCidades] ( @IdUF INTEGER ) AS BEGIN SELECT * FROM Cidade WHERE IdUF = @IdUF END GO

Outro exemplo de Stored Procedure para INSERT (mais legal! )

CREATE PROCEDURE [dbo].[SP_Realiza_Media] ( @CodigoSemestre VARCHAR (6), @Matricula VARCHAR (10) ) AS BEGIN BEGIN TRANSACTION TR_Valida_Dados DECLARE @IdPessoa INT DECLARE @MediaAluno DECIMAL (5,2) DECLARE @Mensagem VARCHAR (200) SELECT @IdPessoa = Idpessoa FROM Aluno WHERE Matricula = @Matricula SELECT @MediaAluno = AVG(nota) FROM DisciplinaAluno WHERE IdPessoa = @IdPessoa IF (@IdPessoa IS NULL OR @MediaAluno IS NULL) BEGIN SELECT @Mensagem = 'No permitido valor nulo para essa operao'; RAISERROR (@Mensagem, 16, 10) ROLLBACK TRANSACTION TR_Valida_Dados RETURN END ELSE BEGIN UPDATE AlunoSemestre SET MediaSemestre = @MediaAluno WHERE IdPessoa = @IdPessoa COMMIT TRANSACTION TR_Valida_Dados END END GO

Na SP acima estamos realizando a mdia da nota do semestre do aluno na tabela Aluno, atualizando o campo MediaSemestre com o valor calculado. Uma coisa nova que no existe nas SPs anteriores o uso de um controle de transao. Transaes em SPs so importantes para garantir a integridade e segurana da execuo de uma alterao no banco, onde ela garante que somente ser alterado o banco se no houver erros durante o controle de uma transao, ou seja, s vai salvar se tudo der certo.
BEGIN TRANSACTION TR_Valida_Dados

utilizado para inicar a

transao. TR_Valida_Dados o nome para transao. Esse nome ajuda a identificar onde uma transao comea e termina.
ROLLBACK TRANSACTION TR_Valida_Dados

utilizado para reverter a

ao efetuada caso acontea algum erro. Assim, tudo que esteja dentro de uma transao desconsiderado.
COMMIT TRANSACTION TR_Valida_Dados

utilizado para submeter as

alteraes realizadas em uma transao. Ao fazer isso, todas os comandos realizados so registrados no banco.

Cursor
Um Cursor um comando que permite realizar operaes em linhas individuais de um resultado, ou seja, ao executarmos, por exemplo, um select que retorne mais de um item, podemos utilizar um Cursor para realizarmos aes sobre cada linha de resultado da consulta, podendo ser manipulada de qualquer maneira. Abaixo algumas definies: INSENSITIVE: na abertura do cursor, o resultado armazenado em uma tabela temporria, ou seja, as modificaes posteriores a sua abertura no sero conhecidas;

SCROLL: realizadas,

todas no

as

operaes as

de

movimentao pelo

podero

ser

somente

definidas

padro

ANSI/92

(movimentao frente); READ ONLY: no permite atualizaes utilizando o cursor; UPDATE [OF colunas]: permite atualizaes em todas (comportamento padro) ou somente algumas colunas; Monta e disponibiliza o resultado do cursor, sintaxe: o OPEN nome do cursor @@CURSOR_ROWS indica o nmero de linhas que atenderam a sua consulta. O Comando FETCH realiza a movimentao em um cursor, permitindo percorr-lo linha a linha, sintaxe: o FETCH [[NEXT | PRIOR | FIRST | LAST | ABSOLUTE n | RELATIVE n] FROM] nome_do_cursor [INTO @varivel1, @variavel2, ...]. A Varivel @@FETCH_STATUS utilizada para indicar o estado da movimentao: o @@FETCH_STATUS = 0: movimentao realizado com sucesso; o @@FETCH_STATUS = -1: cursor est na linha inicial ou final; o @@FETCH_STATUS = -2: a linha recuperada no valida (foi modificada) em um cursor no INSENSITIVE; NEXT: move para a prxima linha do cursor ou para a primeira, se o cursor foi recm aberto; PRIOR: move para a linha anterior; FIRST e LAST: move para a primeira e ltima linhas, respectivamente; ABSOLUTE n: move para a linha de posio n no cursor (se for positivo, a contagem inicia na primeira linha, se negativo, na ltima); RELATIVE n: move para n linhas para frente (positivo) ou para trs (negativo) a partir da posio atual; PRIOR, FIRST, LAST, ABSOLUTE n e RELATIVE n s podem ser realizados com cursores SCROLL;

INTO @variavel1[, @variavel2]: permite associar cada coluna do cursor a uma varivel declarada; Cada varivel listada no comando FETCH dever estar relacionada a uma coluna do cursor; A varivel deve possuir o mesmo tipo da coluna, no sendo realizadas converses implcitas. Um cursor pode ser fechado atravs do comando CLOSE, sintaxe: o CLOSE nome_do_cursor; o Um cursor fechado mantm as estruturas de dados criadas atravs do comando DECLARE CURSOR, ou seja, pode ser reaberto atravs do comando OPEN;

Um cursor pode ser desalocado, ou seja, ter eliminadas as estruturas de dados criadas atravs DEALLOCATE nome_do_cursor;

Um cursor desalocado no pode mais ser reaberto.

Vamos criar um Cursor para exercitarmos um pouco. O Cursor abaixo lista alguns dados da tabela Pessoa:
CREATE PROCEDURE SP_ListaPessoa AS BEGIN DECLARE @Nome VARCHAR (200) DECLARE @DataNascimento DATETIME DECLARE @Mensagem VARCHAR (500) DECLARE CursorLista SCROLL CURSOR FOR SELECT nome, datanascimento FROM pessoa FOR READ ONLY OPEN CursorLista FETCH NEXT FROM CursorLista INTO @Nome, @DataNascimento WHILE @@FETCH_STATUS = 0 BEGIN SELECT @Mensagem = 'O nome da pessoa : ' + LTRIM(@Nome) + ' - A data de nascimento : ' + CONVERT(CHAR(10), @DataNascimento, 103) PRINT @Mensagem FETCH NEXT FROM CursorLista INTO @Nome, @DataNascimento END DEALLOCATE CursorLista END GO

CREATE PROCEDURE SP_ ListaPessoa

como j sabemos, realiza a criao

da SP que ir utilizar um cursor; Aps isso declaramos as variveis que sero utilizadas. Essas variveis tem dependencia com os dados que buscamos dentro do cursos, ou seja, elas que iro receber os valores;
DECLARE CursorLista SCROLL CURSOR

o comando para criarmos um

novo cursor;
FOR SELECT Nome, DataNascimento FROM Pessoa FOR READ ONLY OPEN CursorLista

Inicia a busca dos dados que iremos trabalhar. Nesse caso, estamos buscando os campos Nome e DataNascimento da tabela Pessoa. Aps isso Abrimos o Cursor com o nome de CursorLista, ou seja, iremos comear a percorrer os dados da consulta atravs de um Cursor.
FETCH NEXT FROM CursorLista INTO @Nome, @DataNascimento WHILE @@FETCH_STATUS = 0 BEGIN SELECT @Mensagem = 'O nome da pessoa : ' + LTRIM(@Nome) + ' - A data de nascimento : ' + CONVERT(CHAR(10), @DataNascimento, 103) PRINT @Mensagem

Para uma linha buscada da consuta, iremos inserir na varivel @Nome o valor do campo Nome e na varivel @DataNascimento o valor do campo DataNascimento. O comando WHILE diz que enquanto a movimentao for realizada com sucesso, iremos retornar a mensagem abaixo, apresentando os dados buscados na tabela Pessoa e apresentaremos essa mensagem com o comando PRINT.
FETCH NEXT FROM CursorLista INTO @Nome, @DataNascimento END

Aps isso pegaremos a prxima linha do Cursor, e o mesmo ser feito at que todas as linhas sejam percorridas.
DEALLOCATE CursorLista END

O comando DEALLOCATE elimina ou fecha o Cursor que estava sendo trabalhado. O prximo e tlimo tpico a ser trabalhado sobre programao em banco de dados ser Funes.

Funes
As Funes so instrues criadas para auxiliar na busca e no tratamento de informao dentro de um banco de dados, onde possvel receber mais de um parmetro. Elas podem ser utilizadas para criar condies e para formatar e apresentar dados por exemplo, nunca modificando o estado do banco de dados. Basicamente, podem ser de trs tipos: 1. Scalar Funcition: Funo que retorna um valor simples, como em muitas linguagens de programao existentes; Utilizada para apresentar resultados pequenos. 2. In-Line Table-Valued Function: Funo que retorna obrigatoriamente os valores em forma de tabelas; Pode ser usada ao invs de Stored Procedure para retornar tabelas. 3. Multi-Statement Function: Funo que retorna os valores em forma de tabela, onde possvel atualizar a tabela em que os dados so armazenados. Pode ser usada para criar views parametrizadas.

Vamos demonstrar um exemplo de cada funo:

Scalar Function
CREATE FUNCTION FormatarTelefone (@numeroTelefone VARCHAR (10)) RETURNS VARCHAR(13) AS BEGIN DECLARE @telefone VARCHAR(13) SET @telefone = '(' + SUBSTRING(@numeroTelefone,1,2) + ')' + SUBSTRING(@numeroTelefone,3,4) + '-' + SUBSTRING(@numeroTelefone,7,4) RETURN @telefone END

Essa funo cria uma mscara para os telefones cadastrados. Como temos telefones no formato 3438230300, ao criarmos uma funo para organizar o campo Numero da tabela Telefone, teremos o seguinte resultado: (34) 3823-0300. Para executar a Funo basta realizar o seguinte comando:
SELECT dbo.FormatarTelefone(Numero) FROM Telefone

Como j vimos acima, uma funo no altera os dados de um banco, e s pode ser utilizado para tratar os dados de uma consulta. In-Line Table-Valued Function
CREATE FUNCTION RetornaPessoa(@Nome VARCHAR(100)) RETURNS TABLE AS RETURN (SELECT Nome , dbo.formatartelefone (t.Numero) AS Telefone FROM Pessoa AS p INNER JOIN Telefone as t on p.IdPessoa = t.IdPessoa WHERE nome LIKE '%' + dbo.Trim(@Nome) + '%') GO

Essa Funo ir retornar uma busca na tablea Pessoa, onde o nome da pessoa obedecer a condio WHERE. Alm disso, iremos buscar tambm os telefones da pessoa, j formatado.

Para executar a Funo basta realizar o seguinte comando:

SELECT * FROM RetornaPessoa('Maria')

Assim, iremos retornar todas as pessoas do nosso banco que possuam Maria em alguma parte do nome. Multi-Statement Function
CREATE FUNCTION TipoFuncao ( @CODIGO INT) RETURNS @TAB_RET TABLE ( COD INT , NOME VARCHAR(20) ) AS BEGIN IF @Codigo = 1 BEGIN INSERT com 1') END IF @Codigo = 2 BEGIN INSERT com 2') END RETURN END INTO @TAB_RET VALUES(@CODIGO,'Retorno INTO @TAB_RET VALUES(@CODIGO,'Retorno

Essa funo recebe como parmetro um valor Codigo e retorna um valor de acordo com a entrada. Caso o valor informado seja 1 ele retornar um resultado. Caso seja 2 retornar outro resultado. Para executar a Funo basta realizar o seguinte comando:
SELECT * FROM TipoFuncao(1)

ou ento
SELECT * FROM TipoFuncao(2)

Assim, de acordo com o valor passado, a funo ir retornar um valor. Com isso finalizamos a parte de programao em banco de dados. Vimos a importncia das Triggers, Stored Procedures, Cursores e Funes, e como

elas so teis e facilitam o tratamento, atualizao e manuteno em um banco de dados.

Linguagem de controle de dados

O SQL possui comandos para permitir ou negar privilgios, variando de cada verso SQL. GRANT: autoriza o usurio a executar ou setar operaes; REVOKE: remove ou restringe a capacidade de um usurio executar operaes. Para relizar testes, vamos criar um LOGIN.
CREATE LOGIN ManutencaoDados WITH PASSWORD = 'manutencao'

Depois vamos crar um banco de dados para testes e criar uma tabela:
CREATE DATABASE Privilegios GO CREATE TABLE Teste ( [IdTeste] INTEGER IDENTITY (1,1) PRIMARY KEY, [DescricaoTeste] VARCHAR (100) NOT NULL )

Agora vamos associar um usuario ao login:

CREATE USER [JoseCorrea] FOR LOGIN [ManutencaoDados]

Vamos definir agora, alumas permitir e negar alguns privilgios para o nosso LOGIN

ndice
ndices so utilizados para facilitar a busca de informaes em uma tabela do banco de dados tentando minimizar a quantidade de operaes realizadas para retornar as informaes de maneira mais eficiente. O SQL Server utiliza o modelo B-Tree para gravar a estrutra de ndice. Contm um n raiz que possui uma nica pgina de dados e subnveis desse n, chamandos de nveis folhas; Semelhante a estrutura de rvores em algortimos; Uma B-Tree sempre simtrica, ou seja, possui o mesmo nmero de pginas a esquerda e a direita de cada nvel.

Para ilustrar melhor a utilizao da estrutura B-Tree, vamos analisar a imagem da busca de um cdigo.

A busca pelo ndice realizada na seguinte sequncia: 1. Inicia-se pelo n raiz; 2. porcorrido todas as linhas at encontrar em qual grupo de valores o item a ser procurado se encontra; 3. Para cada subnvel ser realizado os passos anteriores at que a operao seja finalizada. Por exemplo, se quisermos buscar o Cdigo 23, a busca ser feita da seguinte maneira: 1. O nvel raiz percorrido; 2. SQL Server identifica que o Cdigo 23 est entre o subnvel Cdigo 21 e Cdigo 31 (subnvel do meio da subestrutura); 3. Verifica aps isso que o Cdigo 23 est no subnvel da Esquerda, ou seja, Cdigo 21 e Cdigo 30. Assim, possvel observar o potencial da criao de um ndice para consultas. Nesse exemplo ele consegiu eliminar mais de 50% das informaes em que se poderiam ser buscadas. Existem diversos tipos de ndices que podem ser gerados. Abaixo segue uma descrio resumida de cada ndice.

ndices Bons Chaves Primrias; Chaves Estrangeiras; Colunas acessadas por range (between); Campos utilizandos em group by ou order by.

ndices Ruins Campos do tipo text, image, decimal; Campos calculados; Campos com alta cardinalidade (Masculino ou Feminino).

ndice Clustered Gerado automaticamente aps criar uma chave primria, mas este no est diretamente ligado a chave; Ordena os registros por sequncia, o que facilita a busca; Cada tabela pode possuir apenas um ndice Clustered.

A sintaxe para criao de um ndice Clustered :

CREATE CLUSTERED INDEX IX_UF ON UF (UF)

Assim, estamos criando um ndice com o nome de IX_UF para o nosso campo UF da tabela UF. Para criao desse tipo de ndice devemos ter alguns parmetros pr-estabelecidos: Ser utilizado como base pelos outros ndices; interessante um ndice desse tipo quando as chances de repetio do mesmo valor sejam praticamente nulas.

ndice Non-Clustered No afetam a forma de armazenamento dos dados; possvel mais de um ndice Non-Clustered em uma tabela. At 249 ndices por tabela; Caso exista um ndice Clustered na tabela, os ndices Non-Clustered utilizaro ele como referncia; o Segundo nvel de busca(Clustered > Non-Clustered ). A sintaxe para criao de um ndice Non-Clustered :
CREATE NONCLUSTERED INDEX IX_Cidade ON Cidade (NomeCidade)

Assim, estamos criando um ndice com o nome de IX_Cidade para o nosso campo NomeCidade da tabela Cidade.

Os demais ndices abaixo sero apresentados somente nvel de curiosidade, onde no especificaremos sintaxes.

ndice Unique Usados quando os dados indexados no se repetem; Uma chave primria, por exemplo, uma boa candidata a receber um ndice do tipo Unique.

ndice Full-Text Utilizados para BLOBs (Binary Large Objects); Campos de texto so BLOBs; Servio administrado pela ferramenta Microsoft Full-Text Engine for

SQL SERVER.

ndice XML Utilizados para BLOBs (Binary Large Objects); Aplicado para o tipo XML, que pode armazenar at 2GB de dados; Custo alto de processamento/manuteno.

Tipos de ndices
Os ndices podem ser separados por tipos, e, basicamente, temos dois tipos: ndices simples e ndices compostos.

ndices simples Utilizam apenas uma coluna; Normalmente so as chaves primrias das tabelas;

A sintaxe de um ndice simples j vimos acima:

CREATE NONCLUSTERED INDEX IX_Cidade ON Cidade (NomeCidade)

ndices compostos Utilizam mais de uma coluna; Criados por ordem de seletividade: sequncia com os campos que sero definidos no ndice. A sintaxe para criao de um ndice composto :
CREATE NONCLUSTERED INDEX IX_Cidade ON Cidade (IdUF, NomeCidade)

Assim estamos criando um ndice que buscar a informao por dois campos, ou seja, IdUF e NomeCidade.

A sintaxe geral para criao de um ndice : CREATE [UNIQUE] {CLUSTERED|NONCLUSTERED} INDEX nome [WITH [FILLFACTOR = n] [[,] IGNORE_DUP_KEY] [[,] {SORTED_DATA|SORTED_DATA_REORG}] [[,] {IGNORE_DUP_ROW|ALLOW_DUP_ROW}]] [ON SEGMENT nome_do_segmento]

Custo de ndice
Um ndice realiza criao de novos objetos e consome recursos do banco de dados e da mquina. Assim, podemos considerar os seguintes critrios de custo ao criar um ndice: Capacidade de Armazenamento: ao se criar um ndice estamos realizando criao de novos objetos no banco. Quanto maior a tabela, maior ser a quantidade de ndices criados. possvel existir tabelas onde a estrutra de um ndice maior que a estrutura para o armazenamento da tabela; Custo de processamento: operaes de INSERT, UPDATE e DELETE afetam as pginas de ndices, o que interfere na performance da execuo.

FillFactor
Recurso til para minimizar o problema de manuteno dos ndices; Especifica a porcentagem de preenchimento que ser considerada na construo das pginas de ndice: o Fillfactor de 60% define que vamos preencher apenas esta proporo do espao fsico disponvel em cada pgina, deixando 40% de espao vazio. Este espao ser usado quando formos incluir novas informaes naquela pgina. um argumento opcional. Seu valor varia entre 0 e 100:

o Se ele for omitido, a pgina de ndice ser preenchida o mximo possvel, deixando espao para insero de mais um nico registro. O Fillfactor ideal pode mudar conforme o tipo de uso do banco de dados: o Bancos de dados que registram informaes transacionais (OLTP) geralmente usam ndices com Fillfactor de 70% ou menos. Consideramos este patamar porque sistemas OLTP tm muitas operaes de INSERT/DELETE/UPDATE; o No caso de sistemas de apoio deciso (OLAP), os dados so inseridos periodicamente e, geralmente, em lotes de milhares de registros. Nestes casos, os ndices usam Fillfactor na ordem de 80% a 90%.

Dicas para criao de ndices

Que sejam campos numricos. Indexar campos alfanumricos sempre um problema. As informaes costumam consumir tanto espao nas pginas de ndice que o SGBD acaba precisando armazenar um nmero enorme de pginas. Isto torna o ndice menos eficiente; Que os campos tenham uma alta seletividade. Um exemplo clssico: para que indexar um campo de Sexo, se s temos as opes Masculino ou Feminino? A seletividade baixssima. Ao escolhermos uma das opes, estamos selecionando aproximadamente metade dos registros de toda a tabela; Evitar ndices compostos sempre que possvel. Quando eles realmente forem necessrios, manter o ndice o mais curto possvel, ou seja, com o mnimo de colunas. Quanto menor o ndice, menos pginas de ndice sero necessrias e menos tempo de processamento ser necessrio para localizar um registro desejado;

Ainda no caso de ndices compostos, observar qual seria a melhor sequncia de campos, de modo a otimizar performance; Indexar apenas os campos que tragam um alto resultado. Um ndice bem projetado pode reduzir por um fator de 5 ou 10 o tempo de resposta de uma consulta. Nunca crie ndices para reduzir tempos de resposta a algo que seja superior metade do resultado da consulta sem ndice;

Se uma tabela merece ao menos um ndice, que seja um ndice

Clustered;
Toda tabela com alguns milhares de registros merece um ndice ou, no caso, uma chave primria; Em muitos casos, interessante criar ndices Non-Clustered em campos que contm chaves estrangeiras. Isso porque estes campos sempre sero usados em consultas em que fazemos a juno de tabelas.

Otimizao de consultas
J vimos que a utilizao de ndices pode nos ajudar a melhorar a performance do banco de dados. Mas, como medir isso? Como saber se a criao de um ndice est ou no tendo alguma alterao (positiva ou negativa) em nosso banco de dados? Felizmente existe uma soluo! . O PLANO DE EXECUO! \o/. A ideia do Plano de execuo apresentar os passos realizados pela operao para se chegar ao resultado esperado. Consultores de banco de dados utilizam essa ferramenta para verificar a custo de operaes em um banco e analisar quais as medidas viveis podem ser tomadas para que a performance do banco de dados possa aumentar. Para ilustrar isso, vamos verificar a consulta abaixo, de um banco de dados com muitos registros; Por curiosidade, vamos verificar a quantidade de registros existentes na tabela TB_Cobranca:

Executando o comando:
SELECT COUNT(*) FROM TB_Cobranca

Temos que existem 10.724.980 registros na tabela, ou seja, uma quantidade de registros interessante que possivelmente a utilizao de ndice pode melhorar o desempenho das operaes realizadas no banco. Vamos executar o seguinte comando:
SELECT IdTipoCobranca,COUNT(*) FROM TB_Cobranca GROUP BY IdTipoCobranca

Com esse comando estamos listando todas as cobranas existentes na tabela TB_Cobranca agrupadas pelo campo IdTipoCobranca. O plano de ao pode ser acionado no seguinte local:

Aps executar o comando SELECT com essa opo acionada, ser criada mais uma aba no retorno da consulta, como a imagem abaixo:

Ao clicar nela, podemos visualizar o plano de execuo da consulta.

Aps isso vamos criar o seguinte ndice para tentar facilitar a busca e minimizar recursos. Como o Campo IdTipoCobranca um bom candidato para possuir um ndice de consulta, vamos criar um ndice com esse valor:
CREATE NONCLUSTERED INDEX IX_IdTipoCobranca ON TB_Cobranca (IdTipoCobranca)

Para facilitar a visualizao das figuras abaixo, utilize o zoom do leitor do arquivo para que fique mais fcil a leitura das mesmas. Aps a criao desse ndice, devemos executar a consulta novamente, agora, com um novo ndice. Abaixo o plano de execuo da operao com o novo ndice:

Podemos ver que a consulta utiliza o novo ndice criado. Para a anlise utilizarei a comparao de apenas um operador da consulta, comparado o

Clustered Index Scan (busca pela chave primria) com o Index Scan (novo
ndice criado). A imagem da esquerda a consulta sem o ndice e a da direita a consulta executada com o novo ndice criado.

Anlise de ndice da consulta possvel notar que a fonte da busca das ifnormaes mudou. Ao invs de realizar a busca pelo objeto PK_TB_Cobranca_7E6CC920, o SQL optou por utilizar o novo ndice, IX_IdTipoCobranca. O Custo estimao de Entradas e Sadas Estimated I/O Cost baixou de 77 para 11 (valores arredondados). O custo do CPU Estimated CPU Cost se manteve constante. O custo do Operador Estimated Operator Cost baixou de 83 para 17, o que foi um ganho muito grande.

Assim podemos dizer que a criao do ndice favoreceu a busca de dados, resultado em uma melhoria significativa nos recursos utilizados para se obter uma resposta do banco de dados.

Data Warehouse
Os SPT (Sistema de Processamento de Transaes) de um ambiente corporativo lidam com informaes operacionais da empresa. A maior responsabilidade deste tipo de sistema exercer controle dos processos executados no nvel operacional. A obteno de dados variados e diversos sobre as transaes necessria para que esta condio de controle seja satisfeita. Estes dados acabam armazenados em diferentes sistemas e fontes de dados. No obstante, as informaes operacionais fornecem parmetros para que gestores de negcio avaliem o desempenho da organizao e faam projees. Mas apenas parte dos dados transacionais relevante para o nvel estratgico. Ainda assim, os SPT no atendem completamente demanda dos administradores no que diz respeito a suporte a decises. Uma soluo para a questo a criao do Data Warehouse, uma base de dados com capacidade de integrar informaes relevantes para a cpula organizacional de maneira concisa e confivel. Estas informaes se encontram espalhadas nos sistemas de processamento de transaes e em fontes externas. O DW se sobressai por fornecer dados e carter histrico e estatstico aos SAD (Sistema de Apoio Deciso). Estas duas caractersticas dos dados do DW so atributos essenciais para se identificar indicadores, que apresentam o grau de evoluo da organizao por completo, ou por segmentos. Este tipo de informao til para amparar administradores na tomada de decises. Notoriamente, os sistemas de apoio deciso e os sistemas de processamento de transaes atendem a diferentes nveis organizacionais: estratgico e operacional, respectivamente. Por causa disso, o Data

Warehouse deve ser criado em um novo ambiente, j que os fins de um SAD

e de um SPT so diferentes. Poupar esses diferentes sistemas de interveno entre si uma boa prtica porque a manipulao de dados ocorre de modo distinto entre eles. No

ambiente operacional, os sistemas so do tipo OLTP (On-Line Transaction

Processing Processamento Transacional On-Line). J no ambiente

estratgico, os sistemas so OLAP (On-Line Analytical Processing Processamento Analtico On-Line). O sistema OLTP armazena as transaes de um negcio em tempo real, recebendo dados constantemente. A estrutura de dados deste sistema tem que estar otimizada para validao a entrada, rejeitando dados que no atendem a determinadas regras de negcio. Devido grande abrangncia de sua estrutura de dados, um sistema OLTP fica sobrecarregado quando precisa responder uma consulta de alta complexidade. Este exemplo de consulta acontece quando se tenta levantar informaes de carter estratgico em um sistema OLTP. No sistema OLAP, a viso orientada anlise. Assim, a estrutura de dados montada para que consultas feitas por usurios do nvel estratgico da organizao retornem resultados em curto tempo. Alm disso, as informaes obtidas tm propsito exclusivamente analtico.

Caractersticas do Data Warehouse

O Data Warehouse sustentado por quatro aspectos: orientao por assunto, variao de tempo, no volatilidade e integrao. Orientao por assunto: as informaes armazenadas pelo Data

Warehouse so agrupadas por assuntos principais de cada uma das

reas essenciais da organizao. Variao de tempo: diferente de um banco de dados transacional, que armazena valor corrente, o Data Warehouse guarda dados histricos. Como indispensvel que o dado do DW refira-se ao seu momento de insero no sistema transacional, a data lhe um elemento chave. No volatilidade: o Data Warehouse um ambiente exclusivamente de consulta. Isto Impede que seus dados sejam editados. Depois que

determinada informao relacionada do ambiente transacional inserida no DW, as nicas operaes que Podem ser aplicadas a ela so (i) acesso, sem necessidade de bloqueio por concorrncia de usurios, e (ii) excluso, caso seja decidido que um dado no deve mais fazer parte do DW. Integrao: como os dados inseridos no Data Warehouse provm de um ambiente de mltiplas plataformas sistmicas, necessria a unicidade de informaes. Para alcanar isso, o DW segue conveno de nomes e valores de variveis, seguindo um padro para um mesmo tipo de elemento oriundo de plataformas distintas.

Componentes do Data Warehouse

Numa viso abrangente, possvel separar o Data Warehouse em trs partes elementares expostas a seguir. 1. Papis Este componente envolve as funes e responsabilidades presentes no desenvolvimento do Data Warehouse. Devido ao fato do DW abranger variados tipos de desenvolvedores e usurios, o cuidado com a gesto de papis neste ambiente maior do que a ateno dada ao mesmo assunto nos sistemas operativos. Os papis presentes em um Data Warehouse so: Analistas responsveis pela carga dos dados: conhecem e trabalham o mapeamento do DW com o banco de dados do sistema operativo e os requisitos de filtragem e integrao; Usurios finais: so os gerentes, executivos e analistas do negcio que tomam decises. Eles conhecem os problemas e oportunidades da empresa. Podem ser usurios diretos, aqueles que acessam

informaes de todo o DW, ou indiretos, os que acessam informaes de partes do DW; Analistas responsveis pelo desenvolvimento e manuteno do DW: so os DBA (Database Administrator Administrador de Banco de Dados) e os DA (Data Administrator Administrador de Dados) dos SGBD (Sistema Gerenciador de Banco de Dados) dos sistemas operativos. Cuidam dos metadados, da arquitetura e da estrutura dos dados, visando o bom desempenho de consultas.

2. Processos e Ferramentas No Data Warehouse, processos se resumem extrao dos dados dos sistemas operativos, na organizao e integrao destes dados de forma consistente para o DW e no acesso aos dados para consulta. Uma questo importante que deve ser observada no desenvolvimento destas atividades a garantia de consistncia e integridade das informaes para que elas retratem a realidade de negcios da organizao. Para a realizao dos processos so utilizadas ferramentas que auxiliam na execuo das atividades. Dentre estas ferramentas esto aplicaes que ficam responsveis por filtrar, limpar, sumarizar e concentrar os dados de fontes externas e de sistemas operativos. Alm destas aplicaes, h tambm as responsveis pelo acesso aos dados, que servem para permitir um acesso intuitivo aos dados, possibilitando a anlise de informaes mais significativas. Geralmente, o Data Warehouse utiliza os seguintes tipos de ferramentas: Ferramentas para pesquisa e relatrios: oferecem interface grfica para gerao de relatrios e anlise de dados histricos; Ferramentas OLAP: proporciona uma melhor viso analtica para identificar de maneira mais fcil as causas de resultados obtidos. So divididas em:

o ROLAP

(Relational

On-Line

Analytical

Processing

Processamento Analtico On-Line Relacional): ferramentas OLAP que acessam banco de dados relacionais; o MOLAP (Multidimensional On-Line Analytical Processing Processamento ferramentas o HOLAP Analtico OLAP que On-Line acessam Multidimensional): banco de dados

multidimensionais; (Hybrid

On-Line

Analytical

Processing

Processamento Analtico On-Line Hbrido): ferramentas OLAP que acessam tanto banco de dados relacionais quanto banco de dados multidimensionais; o DOLAP (Desktop

On

Line

Analytical

Processing

Processamento Analtico On-Line em Desktop): ferramentas OLAP que acessam banco de dados de computadores pessoais; SIE (Sistema de Informaes Executivas): apresentam uma visualizao mais simplificada dos dados, com informaes mais consolidadas, no requerendo experincia e tempo do usurio para fazer anlise;

Data Mining: ferramentas que permitem que o usurio avalie

tendncias e padres no visualizveis nos dados.

3. Dados Dados so armazenados no Data Warehouse em nveis de agregao diferentes dos sistemas operativos. Enquanto que nos sistemas operativos os dados so detalhados, no DW os dados so levemente ou altamente sumarizados. Para que o trabalhoso processo de extrao e tratamento de dados do sistema operativo no seja em vo, os repositrios de dados devem estar prontos para receber corretamente os dados, respeitando as caractersticas de construo do DW. A implementao de cada repositrio depende da arquitetura de dados apresentada pela empresa;

Em suma, quatro tipos de repositrios so comuns no Data Warehouse: ODS (Operational Data Storage Armazenamento de Dados Operacionais): repositrio de armazenamento intermedirio dos dados. Seus dados ficam em um nvel de compatibilidade com os dados dos sistemas legados. Por isso, o ODS uma base atual, ou quase atual. Isso faz com que seja usada (i) como uma rea provisria de reorganizao fsica de dados operacionais extrados, (ii) para fornecer relatrios operacionais, (iii) dar suporte a decises operacionais e (iv) ponto de consolidao, caso os dados operacionais sejam de vrias fontes. O principal amparo fornecido pela utilizao do ODS no DW o fato de que o ODS ajuda a evitar o carregamento indevido no DW;

Data

Warehouse:

repositrio

com

grande

capacidade

de

armazenamento, que integra os principais dados gerenciais da organizao de maneira concisa e confivel. a base de dados usada pelos SAD. Armazena informaes de cunho histrico e estatstico;

Data Mart: subconjunto de dados do Data Warehouse. O DM possui

dados direcionados a uma rea especfica de negcio e permite acesso de dados de modo descentralizado;

Cubo: banco de dados com escopo de informaes reduzido e processamento acelerado. Permite ao usurio armazenar dados em carter temporrio e ter uma viso analtica rpida por ser manipulado atravs ferramentas OLAP.

Tecnologia de Data Warehousing

Como o Data Warehouse tem o objetivo fornecer informaes de apoio tomada de decises, sua construo deve ser guiada por necessidades apontadas pelos gestores do negcio. Em cima destas condies, o DW projetado e construdo.

O processo de se fazer Data Warehouse acontece atravs da tecnologia de

Data Warehousing. Esta tcnica envolve a criao do projeto de Data

Warehouse, passa pela implementao do mesmo e at chegar sua utilizao pelos executivos da empresa. Os desenvolvedores de Data Warehouse tm que buscar a melhor alternativa de integrar o DW s diferentes fontes de dados existentes. Isto envolve a escolha da arquitetura e implementao adequadas para suprir as necessidades da organizao. Porm, apenas estes cuidados no tornam certo o sucesso do Data

Warehouse. O Data Warehousing um processo incremental, e uma

constante administrao e monitorao do Data Warehouse garante que ele ampare eventuais mudanas estratgicas e estruturais da empresa.

construo

do

Data
Isto

Warehouse

feita na

por

etapas acima.

que

so

interdependentes e incrementais. Assim, devem ser bem administradas e monitoradas sempre. ilustrado figura Conforme apresentado na figura, primeiro, o DW deve ser projetado e mapeado com base num sistema OLTP. Somente depois desta anlise, os dados so retirados do sistema transacional, tratados e carregados para o Data

Warehouse, onde ficam distribudos e ou replicados nos Data Marts. Depois

de toda esta montagem, o DW fica com acesso disponvel para anlise e utilizao estratgica no sistema OLAP.

ETL (Extract, Transform and Load Extrao, Transformao e Carga)

Dentre as atividades a serem feitas no Data Warehousing esto a extrao, a transformao e a carga dos dados. ETL um processo crtico e complexo, pois os dados que comporo o Data Warehouse so descendentes de diferentes sistemas OLTP. Isso faz com que seja necessrio definir quais informaes levar ao DW e realizar adaptaes relevantes como padronizaes de codificao, formato e unidades de medida para um mesmo tipo de dado que est inserido de diferentes formas nos sistemas legados. O processo de extrao, transformao e carga de dados envolve vrias operaes, cada uma contendo suas consideraes especiais: Extrao: processo de captura dos dados de banco de dados operacionais e outras fontes. Tende a ser um processo muito intenso em termos de entrada e sada, e que, para evitar interferncia em outras operaes do sistema de origem, normalmente realizada em paralelo; Limpeza: aprimoramento dos dados antes deles serem inseridos no DW. Geralmente feito em lotes e envolvem operaes como preenchimento de valores omitidos, correo de erros de digitao e outros erros de entrada de dados, estabelecimento de abreviaes e formatos padronizados, substituio de sinnimos por identificadores padro, entre outras. Os dados que no podem ser esmerados neste processo so depostos; Transformao e consolidao: modificao e mescla que precisam ser feitas nos dados e entre eles, para que sejam inseridos de forma correta no DW. Nesta fase, faz-se a diviso e ou a combinao de

registros retirados das tabelas do esquema fsico de um ou mais bancos de dados operacionais; Carga: transporte de dados transformados e consolidados para o DW, fazendo a verificao de integridade e construindo quaisquer ndices necessrios; Renovao: atualizao peridica dos dados do DW. Pode ser feita de modo parcial ou completo e envolve os mesmos pontos associados operao de carga.

Arquitetura de Data Warehouse

Como o projeto de Data Warehouse envolve um alto nvel de complexidade, a definio e a construo da estrutura que comportar o DW um ponto relevante na fabricao desta base de dados. A escolha da arquitetura do DW, geralmente, considera fatores como (i) infraestrutura disponvel, (ii) porte da organizao, (iii) abrangncia do projeto, (iv) capacitao dos empregados da empresa, e (v) recursos de investimento. Analisando estes componentes evita-se a perda da caracterstica de sinergia que deve existir entre o Data Warehouse e a estratgia organizacional.

Tipos de Arquitetura
Existem trs tipos de arquitetura de Data Warehouse: global, independente e integrada.

Arquitetura Global Nesta arquitetura, o Data Warehouse projetado e construdo para atender s necessidades da empresa como um todo. Isto faz com que cada

departamento da empresa tenha um alto grau de acesso s informaes, e que estas sejam muito utilizadas. Os usurios finais utilizam vises corporativas de dados. O processo de extrao, transformao e carga dos dados no Data

Warehouse de arquitetura global deve ser feito fora do horrio de pico de

operaes da organizao. Caso contrrio, os procedimentos no ambiente transacional, que a fonte dos dados que sero levados ao DW, podem ser prejudicados. Os dados dos sistemas operativos e de eventuais fontes externas so extrados em lote, em seguida filtrados e transformados de acordo com as necessidades levantadas no projeto de DW antes de serem carregados para o repositrio. Um ponto relevante no que diz respeito arquitetura global que ela se refere ao escopo de acesso e utilizao das informaes na empresa, e no a uma centralizao fsica da base de dados. A arquitetura global pode ser fisicamente centralizada ou fisicamente distribuda. Quando a empresa est estabelecida em apenas um local, existe uma centralizao fsica do Data Warehouse. J se a empresa est instalada em diferentes locais, os dados podem estar fisicamente distribudos em vrios repositrios repartidos nos diferentes estabelecimentos da empresa.

Arquitetura Independente Quando o Data Mart feito para atender s necessidades de um nico departamento da empresa, sem nenhum foco corporativo, tm-se uma arquitetura independente de Data Warehouse. Nesta arquitetura, um DM no tem conectividade com outro DM de um setor diferente da organizao. Se uma informao de outro Data Mart for relevante a um Data Mart de uma arquitetura independente, estas informaes so importadas e ajustadas.

A vantagem deste tipo de arquitetura a rapidez de implementao. Porm, no possvel ter uma viso total da empresa porque sua restrio possui um mnimo de integrao corporativa. Geralmente, isto tambm torna o

Data Mart inacessvel a outros departamentos, se no o que possui o

repositrio de dados.

Arquitetura Integrada A mescla das duas arquiteturas anteriores resulta na arquitetura integrada de Data Warehouse. Os Data Marts so implementados em cada departamento da empresa e, posteriormente, integrados ou interconectados. Alm de cada departamento possuir um Data Mart, como numa arquitetura independente, h uma viso corporativa maior das informaes, similar arquitetura global. O nvel de complexidade da arquitetura integrada considervel, pois o requisito de conectividade presente nela demanda funes e capacidades maiores do que as encontradas na arquitetura independente. No entanto, a dificuldade em se montar a arquitetura integrada menor que a de se fazer a arquitetura global, que necessita que toda a estrutura do Data Warehouse esteja pronta antes de sua implementao.

Tipos de Implementao do Data Warehouse

Assim como a definio da arquitetura do Data Warehouse, o tipo de implementao tambm depende dos recursos disponveis construo do DW e dos requisitos que este deve atender. Infraestrutura de Tecnologia da Informao, arquitetura escolhida, escopo da implementao e nveis de acesso so exemplos de fatores que influenciam na opo por um tipo de abordagem de implementao.

As abordagens de implementao de Data Warehouse consideradas mais importantes so a (i) top down, a (ii) bottom up e a (iii) combinao entre a

top down e a bottom up.

Implementao Top Down Dentre as implementaes existentes, a top down a que envolve maior tempo para planejamento e trabalho, mas que, em compensao, tem como produto o Data Warehouse que respeita totalmente as regras de negcio da organizao. Antes de iniciar o projeto de DW, so tratadas as definies conceituais de tecnologia, sendo abordadas questes relevantes estrategicamente e de alcance a todo o corpo da empresa. Pontos importantes devem ser determinados na fase de planejamento, como fontes de dados que sero utilizadas, estrutura de dados, qualidade de dados a ser considerada e padres de dados. Para isso, necessrio conhecimento do modelo de dados dos sistemas transacionais. O processo na implementao top down inicia-se com a extrao, a transformao e a integrao dos dados de sistemas operativos na base de armazenamento intermediria, por exemplo, o ODS. Em seguida, os dados e metadados so transferidos diretamente para o Data Warehouse. Somente depois disto, so extrados os dados e metadados para os Data Marts. Nos DM, o nvel de sumarizao dos dados menor do que o existente no DW, alm de, geralmente, no apresentarem o nvel histrico do DW. A centralizao do repositrio de metadados e regras existentes e a existncia de uma consequente herana de arquitetura presentes na implementao top down permitem a manuteno mais simples do que aquelas realizadas especificamente em cada um de vrios repositrios espalhados. Alm disso, a concentrao de todos os negcios no Data

Warehouse garantem uma melhor viso de empreendimento da empresa.

H tambm desvantagens na implementao top down. Como seu desenvolvimento muito longo e trabalhoso, ele fracassa, caso ele no seja bem planejado e trabalhado. Ainda considerando seu tempo de desenvolvimento, a implementao top down pode induzir frustrao de expectativas em toda a organizao. Tudo isto gera um alto nvel de risco para o investimento neste tipo de ambiente.

Implementao Bottom Up Em contrapartida implementao top down, a implementao bottom up proporciona resultados mais rpidos com uma estrutura menos complexa, pelo menos a princpio, e menos dispendiosa. Nesta implementao, os Data

Marts so desenvolvidos antes do Data Warehouse. Este formado pela

juno incremental de Data Marts construdos de modo independente. Desse modo, o Data Warehouse construdo sem uma prvia definio de estrutura corporativa. Assim, faz-se necessria uma ateno metodologia de desenvolvimento para coordenar a elaborao incremental do Data

Warehouse. Isto ajuda na preveno da existncia de metadados sem

padronizao e de dados redundantes e inconsistentes. A brevidade do desenvolvimento bottom up gera a maioria dos benefcios deste tipo de implementao. Amostra disso, os Data Marts podem ser colocados em produo num prazo relativamente curto. Isto gera maior confiana nas pessoas que compem a organizao, as quais visualizam melhor os resultados. Uma das boas consequncias disto gerao de estmulos para investimentos adicionais no projeto. Outro ponto vantajoso na implementao bottom up o desenvolvimento incremental do Data Warehouse. Ele permite que os principais negcios da empresa sejam enfocados inicialmente, sem que haja gastos com reas menos importantes. Alm disso, outro ganho diz respeito ao conhecimento adquirido pela equipe de desenvolvimento dos Data Marts que ganha

aprendizado ao trmino do desenvolvimento de cada Data Mart. Isto gera menos riscos nos resultados do Data Warehouse. J as desvantagens da implementao bottom up esto relacionadas com o risco de perda da viso geral do empreendimento da empresa. Como o desenvolvimento dos

Data Marts independente, h chances de

inviabilizao de integrao, que devem ser minimizadas com uma boa coordenao dos desenvolvimentos dos Data Marts.

Implementao Combinada Uma alternativa s implementaes top down e bottom up a implementao combinada que integra ambas. Neste ambiente, o Data

Warehouse modelado numa viso macro e os Data Marts so gerados a

partir do macro modelo de dados. Em seguida, depois de prontos, os DM so integrados ao modelo fsico do DW. A caracterstica de herana de modelo existente na implementao combinada evita desvantagens significativas das implementaes top down e bottom up. Os Data Marts gerados tm dados consistentes em virtude do mapeamento e controle dos dados, que resultado da existncia de apenas um modelo de dados. Isto retira a ateno dada ao controle de padronizao e consistncia de dados de Data Marts, atributo da implementao bottom up. Ao mesmo tempo, como os Data Marts so construdos separadamente na implementao combinada, as principais reas de negcios podem ser priorizadas. Assim, resultados podem ser apresentados organizao de maneira mais rpida e satisfatria. Alm disso, a construo evolutiva de vrios DM permite aprendizado da equipe de desenvolvimento do DW. Estes dois efeitos da fabricao separada de Data Marts contrabalanam com duas desvantagens da implementao top down: resultados demorados e ausncia de aprendizado da equipe de desenvolvimento.

Em suma, a implementao combinada a juno o planejamento top down com o desenvolvimento bottom up, sendo que as caractersticas destas duas partes ficam presentes no Data Warehouse.

Modelagem Multidimensional de Dados Um aspecto preponderante para se realizar modelagem de dados para Data

Warehouse o foco no negcio da empresa. Enquanto que o foco da

modelagem de dados para sistemas operativos enfoca o controle de negcios, a modelagem de dados do DW deve permitir que questes abstratas do negcio sejam visualizadas pelos usurios finais, os tomadores de deciso. Esta uma diferena essencial a ser considerada antes de se desenvolver a modelagem de dados para sistemas de ambiente OLAP. Devido a esses focos distintos, no apropriado aplicar completamente a teoria relacional, utilizada em sistemas OLTP, na modelagem de dados para Data Warehouse. A base de dados nos sistemas operativos segue as regras de normalizao para garantir a consistncia dos dados e a diminuio do espao de armazenamento. Para se realizar algumas consultas numa base de dados deste tipo so necessrias operaes complexas e lentas, que fazem juno de vrias tabelas do banco de dados. Entretanto, isto invivel no Data

Warehouse. Neste, as consultas realizadas pelos usurios finais devem ser

de manipulao fcil e retorno de resposta rpido. Para que esta caracterstica seja atendida, o DW, geralmente, tem um modelo de dados sem normalizao. No Data Warehouse, a base de dados construda sob a modelagem multidimensional, que uma tcnica de concepo e visualizao de um modelo de dados de um conjunto de medidas que descrevem aspectos comuns de negcios (MACHADO, 2006, p. 79). A modelagem multidimensional utilizada especialmente para sumarizar e reestruturar

dados e apresent-los em vises que suportem a anlises desses dados (MACHADO, 2006, p. 79). O modelo entidade-relacionamento pode ser utilizado para ambiente de

Data Warehouse com tcnica para modelagem multidimensional especfica

como mostra a figura abaixo. Isto no interfere no suporte ao ambiente de anlise multidimensional de dados e ainda facilita a modelagem de dados para desenvolvedores que esto acostumados com a modelagem entidaderelacionamento.

Na figura acima, podem ser identificados os trs elementos bsicos que formam um modelo multidimensional: (i) fatos, (ii) dimenses e (iii) medidas. O fato representado no modelo pela tabelas central. Os campos

Medida1 e Medida2 da ilustrao servem para armazenamento de medidas,

os valores numricos que sero analisados. As chaves estrangeiras da tabela fato, que devem fazer parte da composio da chave primria, se relacionam com tabelas dimenses, que so as perspectivas de anlise do fato. dimenses contm atributos que descrevem a perspectiva de anlise. As

Compreender os conceitos de fatos, dimenses e medidas importante para se construir modelos multidimensionais. Por isso, estes elementos so conceituados a seguir.

Fato Os elementos principais de um modelo multidimensional so os fatos. Um fato todo componente de negcio que pode ser representado por valores numricos que evoluem no decorrer do tempo e que podem ter histricos mantidos. O Data Warehouse nada mais do que a histria de um conjunto de fatos da organizao. A definio dos fatos de um modelo multidimensional requer uma ateno por parte dos analistas responsveis pelo desenvolvimento do Data

Warehouse que vai alm da abordagem tecnolgica. Os fatos devem

referenciar os principais componentes de negcio da empresa ara que os executivos tenham apoio na anlise de negcio de vrios pontos de vista. Assim, as decises so tomadas com base no comportamento dos fatos.

Por exemplo, a figura acima mostra a tabela FatoVenda. A venda est entre os principais componentes de negcio de um estabelecimento comercial. O atributo Valor de FatoVenda guarda os valores numricos que tero seu histrico mantido e serviro para anlise. A chave primria da tabela

FatoVenda

composta

por

duas

chaves

estrangeiras,

frutos

de

relacionamentos identificadores com dimenses vendedor e tempo. Estes relacionamentos servem para definir perspectivas de anlise do fato venda.

Assim, podem ser feitas anlises do valor de vendas por determinado vendedor e ou por determinado perodo de tempo.

Dimenso O fato constitudo por dimenses, que so elementos que propiciam, cada um, uma diferente perspectiva de anlise do fato. Desse modo, as dimenses determinam o contexto de um assunto de negcio. Por exemplo, o assunto de negcio venda pode ser analisado por vrios aspectos de negcios como vendedor e tempo. Neste caso, os aspectos vendedor e tempo so as dimenses do fato venda. Um caso especial entre as dimenses a dimenso tempo, que deve estar presente em todos os fatos do Data Warehouse. Isto se justifica pelo princpio de que o DW deve armazenar os dados de um assunto de negcio ao longo do tempo. Portanto, a dimenso tempo serve para atender o carter histrico do Data Warehouse. A representao de uma dimenso no modelo multidimensional feita atravs de uma tabela definida por sua chave primria, que mantm a integridade referencial numa tabela fato. normalmente no tm atributos numricos. Alm da chave primria, a As dimenses dimenso possui atributos de descrio e de classificao.

A figura acima mostra a tabela DimensoVendedor que se relaciona com a tabela FatoVenda apresentada de exemplo na figura anterior a essa. A chave da dimenso vendedor serve para manter a integridade referencial na

tabela fato e os atributos Nome e DataAdmisso descrevem a dimenso vendedor.

Hierarquia de Dimenses Normalmente, as informaes presentes no

Data

Warehouse

so

hierarquizadas para fins de anlise. Isto faz com que seja possvel agrupar informaes tanto por nveis gerais ou nveis mais especficos. A visualizao de hierarquia nas dimenses feita atravs do nvel de seus atributos. Por exemplo, um produto pode pertencer a uma subcategoria e esta fazer parte de uma categoria. Assim, estes trs atributos se relacionam mantendo uma subordinao onde, hierarquicamente, a categoria pertence ao maior nvel, a subcategoria ao nvel intermedirio e o produto em si ao menor nvel. Isto exibido na tabela dimensoProduto da figura abaixo.

A dimenso pode apresentar uma ou mais hierarquias, juntamente com outros atributos que no pertencem a nenhuma hierarquia.

Dimenso Mascarada Quando a entidade dimenso no possui um nmero significativo de ocorrncias, ela pode ser implementada como atributo do fato ao qual ela est relacionada. Neste caso, a dimenso denominada como dimenso mascarada.

A dimenso mascarada continua compondo a chave primria da tabela fato pelo qual referenciada, assim como aconteceria se ela fosse uma dimenso comum. Isto ocorre porque tambm ser necessrio classificar as informaes pela dimenso mascarada, e somente com ela estando na chave do fato que se podem inserir dados distintos para cada ocorrncia dela.

Na figura acima, tem-se uma amostra de dimenso mascarada. A tabela

FatoHospedagem conta com a dimenso mascarada TipoApartamento. Os

tipos de apartamento oferecidos em hotis no representam uma variedade significativa. Dependendo do contexto, com apenas as ocorrncias simples, duplo e sute pode-se preencher satisfatoriamente a dimenso tipo de apartamento. A hospedagem tambm pode ser classificada por tipo de apartamento j que a dimenso mascarada TipoApartamento compe a chave primria da tabela FatoHospedagem.

Medida O fato qualificado pela medida, um atributo numrico que representa o desempenho de um indicador de negcio relativo um contexto determinado pelas dimenses que participam do fato. As medidas so classificadas em (i) valores aditivos, (ii) valores no aditivos e (iii) valores semi-aditivos. Valores aditivos: nmeros absolutos que podem ser manipuladas algebricamente. Estes valores devem ser identificados para se modelar o Data Warehouse, pois compem os indicadores de desempenho de negcio.

Valores no-aditivos: valores que no podem ser manipulados livremente. Por exemplo, nmeros relativos, que tem seus valores baseados em nmeros absolutos. Estes valores devem ser identificados para se modelar o Data Warehouse, pois, assim como os valores aditivos, compem os indicadores de desempenho de negcio.

Valores semi-aditivos: valores que contm contagem dupla. Estes valores podem ser calculados envolvendo valores aditivos ou valores no-aditivos, desde que se refiram exclusivamente a uma determinada medida de base.

Hierarquia de Medidas A medida pode possuir hierarquia de composio de seu valor. Porm, no modelo multidimensional, a tabela fato pode ter ou no todos os elementos dessa hierarquia. A hierarquia de medida pode ser visualizada atravs de uma formulao matemtica de forma hierrquica, onde o produto da operao depende dos fatores que a geram. No exemplo da figura abaixo, o atributo Lucro composto por dois elementos menores: Receita e Despesa. Tem-se representada uma hierarquia de medidas, onde a subtrao do valor de Despesa no valor da Receita gera o atributo Lucro.

Na representao das medidas do fato do modelo multidimensional, a medida Lucro poder ou no estar acompanhada das medidas Receita e

Despesa, que esto num menor nvel hierrquico. O importante que na composio do valor de lucro, a hierarquia foi respeitada.

Tipos

de

Modelo

Entidade-Relacionamento

Aplicados

com

Tcnica Multidimensional
Existem dois principais tipos de modelo entidade-relacionamento que utilizam tcnica de modelagem multidimensional: modelo estrela e modelo floco de neve.

Modelo Estrela A composio tpica do modelo em estrela representada por uma entidade central, o fato, relacionado a entidades menores, ou seja, as dimenses, que ficam distribudas ao redor do fato, formando uma estrela. assimtrico do modelo estrela facilita a leitura e a interpretao. Esta representao apresentada na figura abaixo. A entidade central o fato venda que tem disposta ao seu redor as dimenses regio, produto, vendedor, cliente e data. O estilo

Os relacionamentos das entidades dimenses com a entidade fato uma simples ligao entre duas entidades em um relacionamento de um para muitos no sentido da dimenso para o fato. Numa viso entidaderelacionamento tradicional, a entidade fato associativa.

Modelo Floco de Neve Com a estrutura do modelo estrela como base, o modelo floco de neve o resultado da decomposio de uma ou mais dimenses que possuem hierarquia entre seus membros. O modelo floco de neve uma das maneiras de representar a hierarquia de dimenses. Nele, os atributos de menor nvel hierrquico se transformam em outras dimenses que podem se ligar uma nas outras at chegar dimenso que contm o atributo de maior nvel hierrquico, ou com cada atributo se relacionando diretamente com a dimenso que contm o atributo de maior nvel hierrquico. O entendimento deste modelo para desenvolvedores de sistemas OLTP fcil porque o modelo floco de neve a aplicao da terceira forma normal sobre as entidades da dimenso. Assim, como num modelo entidaderelacionamento, evitada a redundncia de valores textuais em uma tabela. Cabe lembrar que o Data Warehouse no possui incluso de dados de digitao, no necessitando normalizao do modelo para garantir unicidade de valores textuais. Isto deve ser provido anteriormente nos sistemas legados.

Na figura acima, alm da entidade fato venda rodeada pelas dimenses regio, produto, vendedor, cliente e data, como no modelo estrela, o modelo floco de neve caracterizado pela criao das dimenses semana, ms, estado, cidade e tipo de produto, que formam a hierarquia das dimenses s quais esto ligadas. A dimenso tipo de produto a hierarquia de menor nvel da dimenso produto. A dimenso regio esta ligada dimenso estado, nvel intermedirio da hierarquia, que se relaciona com a dimenso cidade, menor nvel da hierarquia. J na dimenso data existem duas hierarquias que so representadas pelas dimenses ms e semana, onde ambas ligam-se diretamente dimenso data.

Granularidade
A navegao feita pelos tomadores de deciso nas informaes

disponibilizadas pelo sistema OLAP comea com a visualizao das informaes no nvel maior de agregao e depois estas informaes podem ser detalhadas at o menor nvel de sumarizao disponibilizado pelo Data

Warehouse.

Este nvel de sumarizao dos elementos e de detalhe disponvel nos dados denominado granularidade. O nvel de detalhe inversamente proporcional ao nvel de granularidade. Quanto menos detalhado for o dado, maior a granularidade; quanto mais detalhado for o dado, menor a granularidade. A relevncia da granularidade tanta que ela considerada o aspecto mais importante do projeto de um Data Warehouse. Diferente do que acontece no sistema OLTP, quando certo que os dados so armazenados no menor nvel de granularidade, a granularidade no um pressuposto no ambiente de um

Data Warehouse. O volume de dados residentes no DW e o tipo de consulta

que pode ser atendido por ele afetada profundamente pela sua granularidade. Portanto, a definio do nvel de granularidade deve ser analisada e definida antes da construo do modelo multidimensional de dados. H de se lembrar que o Data Warehouse deve guardar informaes que auxiliem a tomada de deciso com uma velocidade de consulta maior que a de sistemas OLTP e, alm disso, manter a historicidade dos dados. Desse modo, os requisitos que devem ser atendidos para a definio da granularidade de um dado estabelecer at que nvel o dado deve ser detalhado para dar suporte tomada de deciso e se o volume de dados gerados com isso ser capaz de prejudicar o desempenho do sistema.

Operaes OLAP
A funcionalidade de ferramentas OLAP caracterizada pela anlise multidimensional dos dados, apoiando o usurio final ao extrair dados do

Data Warehouse e construir relatrios capazes de responder questes

gerenciais. Quatro tipos de operaes OLAP so utilizadas para anlise de dados. Operaes drill navegam nos dados modificando o nvel de granularidade da

consulta, enquanto que operaes de slice and dice navegam nas dimenses utilizadas pelo usurio final. Os tipos de operaes so explicados a seguir.

Drill down e roll up: o drill down ocorre quando se aumenta o nvel de
detalhe da informao, diminuindo seu nvel de granularidade. O processo inverso o roll up, quando se aumenta o nvel de granularidade da informao, diminuindo seu nvel de detalhe. Os caminhos de navegao so determinados pelas hierarquias de dimenso. Por exemplo, o usurio faz um drill down quando v os dados disponibilizados por meses do ano e depois os v por dias do ms. Quando faz o inverso, o usurio executa um roll up.

Drill across: ocorre quando o usurio pula um nvel intermedirio de

uma hierarquia dentro da dimenso. existe o atributo ms entre estes atributos. Por exemplo, detalhar diretamente um dado por ano para um dado por trimestre, sendo que

Drill throught: ocorre quando o usurio passa de uma informao

contida numa dimenso para outra. Por exemplo, primeiro o usurio est analisando a informao pela dimenso tempo e depois passa a analis-la pela dimenso regio.

Slice and dice: so operaes para navegar pelos dados atravs de um

cubo, que reduzem o escopo dos dados em anlise. O slice separa parte do cubo, mas mantm a mesma perspectiva de visualizao dos dados. J o dice a operao que muda a perspectiva de visualizao. Um exemplo disto quando o usurio visualiza o nmero de vendas de aparelhos de telefone por tipo de telefone, fixo ou celular, na regio sudeste do Brasil. Fazendo uma operao slice o usurio poderia visualizar o nmero de vendas apenas de celulares na regio sudeste. J a operao dice seria trocar o sentido da anlise. Se antes os dados eram vistos no sentido de tipo de telefone para regio, passando por um dice seria visto no sentido de regio para tipo de telefone. O dice seria como inverter as informaes de coluna e linha de uma tabela.

Estrutura de Arquivos e de Banco de Dados

Existem diversos tipos de armazenamento; So classificados por: o Velocidade de acesso aos dados; o Custo de mdia; o Confiabilidade; Tipos de armazenamento: o Cache; o Memria Principal; o Memria Flash; o Disco magntico; o Disco tico; o Fita.

Cache A figura abaixo ilustra uma memria cache:

Caractersticas: o Mais rpidas, porm mais caras; o Pequeno espao de armazenamento; o Gerenciado pelo Sistema Operacional.

Memria Principal A figura abaixo um exemplo de memria princial:

Caractersticas: o Memria pequena para o armazenamento de um banco de dados; o Executa processos gerenciados pelo Sistema Operacional; o Caso haja perda de energia, os dados so perdidos.

Memria Flash Abaixo, temos um exemplo de memrias do tipo flash:

Caractersticas: o Dados no so perdidos caso haja falta de energia;

o Leitura de dados similar a da memria principal, porm com escrita mais demorada; o Bastante utilizada para gerenciamento de pequenas quantidades de arquivos. Disco Magntico Alguns exemplos de discos magnticos:

Caractersticas o Armazena um Banco de Dados por completo; o Oferecem maior capacidade de armazenamento; o Disponibilizam o acesso dos dados para a memria voltil.

Discos ticos As imagens abaixo ilustram os discos ticos:

Caractersticas:

o Disponibilizam uma maneira de armazenar os dados em um disco flexvel; o Utilizados para gravar arquivos de dados; o Oferecem uma velocidade de acesso rpida comparada a outros dispositivos de armazenamento.

Fita Alguns exemplos de fitas so apresetandos na imagem abaixo:

Caractersticas: o Muito utilizado para backup ou arquivo de dados; o Acesso a dados mais lento; o Conhecido como memria de acesso sequencial.

Comparando os tipos de armazenamentos listados acima, podemos criar uma pirmide de Custo x Velocidade. Quanto maior o custo, maior ser a velocidade de acesso aos dados e vice-versa (prxima pgina).

Analisando a imagem, podemos ver que quem est no topo da velocidade consequentemente tendo um custo maior a memria cache. De maneira inversa, com baixo custo mas com uma velocidade menor, temos as fitas magnticas.

Raid (Redundant Array of Independent Disks)

RAID a sigla para Redundant Array of Independent Disks ou, em traduo livre, algo como Matriz Redundante de Discos Independentes. Trata-se, basicamente, de uma soluo computacional que combina vrios discos rgidos (HDs) para formar uma nica unidade lgica de armazenamento de dados. E o que unidade lgica? Em poucas palavras, no que se refere a RAID, trata-se de fazer com que o sistema operacional enxergue o conjunto de HDs como uma nica unidade de armazenamento, independente da quantidade de dispositivos que estiver em uso. Hoje, alm de HDs, possvel montar sistemas RAID baseados em SSD. Fazer com que vrias unidades de armazenamento trabalhem em conjunto resulta em muitas possibilidades:

Se um HD sofrer danos, os dados existentes nele no sero perdidos, pois podem ser replicados em outra unidade (redundncia); possvel aumentar a capacidade de armazenamento a qualquer momento com a adio de mais HDs; O acesso informao pode se tornar mais rpido, pois os dados so distribudos a todos os discos; Dependendo do caso, h maior tolerncia a falhas, pois o sistema no paralisado se uma unidade parar de funcionar;

Um sistema RAID pode ser mais barato que um dispositivo de armazenamento mais sofisticado e, ao mesmo tempo, oferecer praticamente os mesmos resultados.

Nveis de RAID
Para que um sistema RAID seja criado, necessrio utilizar pelo menos dois HDs (ou SSDs). Mas no s isso: necessrio tambm definir o nvel de RAID do sistema. Cada nvel possui caractersticas distintas justamente para atender s mais variadas necessidades. Iremos citar alguns nveis existentes.

RAID 0 Tambm conhecido como striping (fracionamento), o nvel RAID 0 aquele onde os dados so divididos em pequenos segmentos e distribudos entre os discos. Trata-se de um nvel que no oferece proteo contra falhas, j que nele no existe redundncia. Isso significa que uma falha em qualquer um dos discos pode ocasionar perda de informaes para o sistema todo, especialmente porque "pedaos" do mesmo arquivo podem ficar armazenados em discos diferentes.

O foco do RAID 0 acaba sendo o desempenho, uma vez que o sistema praticamente soma a velocidade de transmisso de dados de cada unidade. Assim, pelo menos teoricamente, quanto mais discos houver no sistema, maior a sua taxa de transferncia. No difcil entender o porqu: como os dados so divididos, cada parte de um arquivo gravada em unidades diferentes ao mesmo tempo. Se este processo acontecesse apenas em um nico HD, a gravao seria uma pouco mais lenta, j que teria que ser feita sequencialmente.

Por ter estas caractersticas, o RAID 0 muito utilizado em aplicaes que lidam com grandes volumes de dados e no podem apresentar lentido, como tratamento de imagens e edio de vdeos.

RAID 1 O RAID 1 , provavelmente, o modelo mais conhecido. Nele, uma unidade duplica a outra, isto , faz uma cpia da primeira, razo pela qual o nvel tambm conhecido como mirroring (espelhamento). Com isso, se o disco principal falhar, os dados podem ser recuperados imediatamente porque existe cpias no outro. Perceba que, por conta desta caracterstica, sistemas RAID 1 devem funcionar em pares, de forma que uma unidade sempre tenha um clone. Na prtica, isso significa que um sistema RAID composto por dois HDs com 500 GB cada ter justamente esta capacidade, em vez de 1 TB.

O nvel RAID 1 claramente focado na proteo dos dados, ou seja, no torna o acesso mais rpido. Na verdade, pode at ocorrer uma ligeira perda de desempenho, uma vez que o processo de gravao acaba tendo que acontecer duas vezes, uma em cada unidade. importante observar, no entanto, que o uso de RAID 1 no dispensa solues de backup. Como a duplicao dos dados feita praticamente em tempo real, significa que se uma informao indevida for gravada na primeira unidade (como um vrus) ou se um arquivo importante for apagado por engano, o mesmo acontecer no segundo disco. Por isso, RAID 1 se mostra mais adequado para proteger o sistema de falhas fsicas das unidades.

RAID 2, 3 e 4 Os nveis de RAID mostrados at agora so os mais utilizados, mas h alguns menos conhecidos, entre eles, RAID 2, RAID 3 e RAID 4: RAID 2 RAID um tipo de soluo de armazenamento que surgiu no final dos anos 1980. Naquela poca e nos anos seguintes, os HDs no tinham o mesmo padro de confiabilidade que tm hoje. Por este motivo, foi criado o RAID 2.

Ele , at certo ponto, parecido com o RAID 0, mas conta com um mecanismo de deteco de falhas do tipo ECC (Error Correcting Code). Hoje, este nvel quase no mais utilizado, uma vez que praticamente todos os HDs contam com o referido recurso. RAID 3 Este um nvel parecido com o RAID 5 por utilizar paridade. A principal diferena que o RAID 3 reserva uma unidade de armazenamento apenas para guardar as informaes de paridade, razo pela qual so necessrios pelo menos trs discos para montar o sistema. Este nvel tambm pode apresentar maior complexidade de implementao pelo fato de as operaes de escrita e leitura de dados considerarem todos os discos em vez de tratlos individualmente.

RAID 4 O RAID 4 tambm utiliza o esquema de paridade, tendo funcionamento similar ao RAID 3, com o diferencial de dividir os dados em blocos maiores e de oferecer acesso individual a cada disco do sistema. Este nvel pode apresentar algum comprometimento de desempenho, pois toda e qualquer operao de gravao exige atualizao na unidade de paridade. Por este motivo, seu uso mais indicado em sistemas que priorizam a leitura de dados, ou seja, que realizam muito mais consultas do que gravao.

RAIDS Hbridos
Alguns RAIDs so resultados da utilizao de mais de um tipo de RAID em conjunto, como veremos abaixo. RAID 01 ou RAID 0 + 1 Em uma implementao RAID 0+1, os dados so espelhados atravs de grupos de discos segmentados, isto , os dados so primeiro segmentados e para cada segmento criados feito um espelho, como demonstrado na figura abaixo:

Na figura acima vemos que o discos 1 e 2 formam um RAID 0 sendo aps espelhados pelo discos 3 e 4 tambm em RAID 0, formando assim RAID 1 sobre RAID 0. Apesar de ser uma configurao que proporciona alta performance, se perdermos um disco em um dos lados, praticamente teremos uma configurao em RAID 0, porque em uma configurao RAID 0 se um disco falha todo o conjunto falhar. Neste caso, se o disco 1 falhar, ento o disco 2 que est intacto ficar inutilizado, restando assim os discos 3 e 4 em RAID 0.

RAID 10 ou RAID 1 + 0 Em uma implementao RAID 1+0, os dados so segmentados atravs de grupos de discos espelhados, isto , os dados so primeiro espelhados e para depois serem segmentados como demonstrado na figura abaixo:

Na figura acima vemos que o discos 1 e 2 formam um RAID 1 e os discos 3 e 4 tambm sendo aps segmentados em RAID 0, formando assim RAID 0 sobre RAID 1. Alm de ser uma configurao que proporciona o mesmo nvel de performance proporcionado pelo RAID 01, o RAID 10 proporciona mais tolerncia falhas que o RAID 01 porque poderamos ter uma falha simultnea dos discos 1 e 3 e ainda assim o conjunto estaria intacto, pois teramos os espelhos em perfeito funcionamento. No meu ponto de vista, este conjunto o mais indicado nos casos onde necessitamos aliar performance e redundncia, como o caso, por exemplo, de bancos de dados Oracle de alta performance.

Concluso sobre RAID 01 e RAID 10 Nos dois casos (0+1 ou 1+0), a perda de um nico disco no resultar na falha do sistema RAID. A diferena aparece no caso da perda de um segundo disco que dependendo do disco, o sistema RAID 0+1 ficaria em desvantagem sobre o sistema RAID 1+0. Uma outra diferena na velocidade de recuperao, porque caso ocorra uma falha de disco, no sistema RAID 1+0 ser necessrio apenas re-espelhar um disco, ao contrrio do sistema RAID 0+1 que ser necessrio espelhar todo um conjunto segmentado. Portanto no se esquea que RAID 01 diferente de RAID 10. RAID 01 RAID 10

Tcinas de Recuperao de Banco de Dados

Este tpico tem como objetivo realizar um breve levantamento sobre a importncia da recuperao de Banco de Dados. Viso Geral: o Importante para recuperao de Banco de Dados; o Utilizao de transaes nas operaes que armazenam os dados; o Garante que os dados no sero perdidos caso ocorra alguma falha; o Armazenamento no arquivo Log do BD. Existem basicamente trs tipos de recuperao de Banco de Dados: o Simple;

o Bulk-Logged; o Full.

Simple
Log de transaes pouco utilizado nesse modelo de recuperao; Restaura informaes somente do ltimo backup; Utilizado em bancos de teste ou em bancos que no exista problema a se perder os dados.

Bulk-Logged
Registra mais informaes que o modelo Simple; No registra operaes de volume: SELECT INTO, INSERT, CREATE INDEX e operaes com campos do tipo texto; Nessa opo nem todos os dados so inseridos no Log do Banco de Dados.

Full
Realiza backup do Log de transaes; Armazena todas as informaes em um Log; Recupera o Banco de Dados at o ltimo minuto em que ocorreu o problema; Oferece um nvel maior de proteo; Indicado usar este sempre que possvel.

Segurana de Banco de Dados

Este tpico ser um breve comentrio da importncia da seguranca dos Bancos de Dados, que o repositrio do bem mais valioso das Organizaes dos dias de hoje: a informao.

Se baseia basicamente em quatro princpios: Confidencialidade: capacidade de um sistema permitir que um usurio acesse determinadas informaes ao mesmo tempo que impede que usurios no autorizados as vejam; Integridade: garante que a informao manipulada mantenha todas as caractersticas originais estabelecidas pelo proprietrio das informaes, como o controle de mudanas e garantia do seu ciclo de vida (nascimento, manuteno e destruio); Disponibilidade: garante que a informao esteja sempre disponvel para o uso legtimo, ou seja, para usurios autorizados pelo proprietrio da informao; Irretratabilidade: garante a impossibilidade de negar a autoria em relao a uma informao. A Poltica de Segurana da Informao segue o modelo PDCA: Planejar (Plan): identificar os ativos a serem protegidos atravs da anlise de riscos; Realizar (Do): colocar em ao o planejamento realizado e aplicar os mecanismos necessrios para atender os requisitos de proteo identificados; Verificar (Check): monitorar se o plano est sendo seguido e se necessita ser revisado;

Agir (Act): manter um plano de ao para reiniciar o clico e planejar

mudanas na poltica estabelecida pelo plano anterior.

Segurana Fsica Manter o servidor em uma sala onde somente pessoas autorizadas tem acesso; Manter sistemas de energia alternativos (no-breaks, geradores); Manter sistemas de refrigerao; Manter backups distribudos, ou seja, que no fiquem no mesmo lugar que o servidor e, de preferncia, em mais de um lugar; Organizar o meio fsico, como computadores, servidores, identificao de cabos, etc.

Seguranca Via Servios Instalar somente servios do SGBD que so utilizados; De acordo com a necessidade, ir instalando os demais servios disponveis; No script abaixo, possvel visualizar os servidos instalados e ativar ou desativar um servio. No exemplo, o servio Remote Access est sendo ativado: sp_configure show advanced options, 1; GO RECONFIGURE; GO sp_configure remote access, 1; GO RECONFIGURE; GO

Contas de Servios Configurao de nveis de acessos aos servios; Cada servio acessa somente o que precisa;

Tipos de contas (SQL Server 2008): o Domain user que no administrador do Windows; o Local user que no administrador do Windows; o Network Service; o Local System; o Local user e administrador Windows; o Domain user e administrador Windows.

Outras Ferramentas Ferramenta de anlise de segurana; Atualizao sempre que possvel do Sistema Operacional do do Sistema Gerenciador de Banco de Dados (SGBD): Patching SQL

Server e Windows;
TDE (Transparent Data Encryption): o Criptografia do Banco de Dados.

Auditoria no SQL Server Utilizado para obter informaes gerenciais do que ocorre no sistema; Ferramentas: o SQL Server Audit: Gerao de Logs: A nvel de servidor; A nvel de Banco de Dados.

o Change Data Capture (CDC): Logs de INSERT, UPDATE, DELETE; Controle de permisses de alteraes com o rollback.

Autenticao Exitem dois tipos: o Windows Authentication: recomendvel utilizar sempre que possvel; o Mixed

Mode Authentication: utilizar regras de senhas

complexas.

Banco de Dados Distribudos

Este tpico tem como objetivo dar uma breve descrio sobre Sistemas de Banco de Dados Distribudos. Caractersticas: o Relao entre diversos computadores (ns); o Gerenciamento das transaes feito em cada n; o Comunicao por ser feita com o uso de: Redes de alta velocidade; Redes sem fio.

Caractersticas do armazenamento: o Replicao: Rplica dos dados (espelhamento); Entre dois ou mais ns. Diviso dos dados em fragmentos (quebra dos dados); Diviso em fragmentos e replicao dos mesmos.

o Fragmentao: o Fragmenta e Replicao:

Transaes Atomicidade: todas as operaes sero refletidas no Banco de Dados ou nenhuma ser; Consistncia: execuo de uma transao preservar a consistncia dos dados; Isolamento: transao no toma conhecimento das transaes concorrentes; Durabilidade: transao efetuada com sucesso deve ser persistida no Banco de Dados.

Vantagens Compartilhamento e controle distribudo; Autonomia; Crescimento incremental; Disponibilidade; Consultas em paralelo.

Desvantagens Custo elevado; Grande potencial no aumento de bugs;

Necessidade de coordenao entre os ns;

Perda de dados durante a comunicao entre os ns.

Banco de Dados Orientados a Obejto

Hoje, o banco de dados orientados a objeto um fator emergente que integra banco de dados e a tecnologia de orientao a objetos. Por um lado, a necessidade de realizar manipulaes complexas para os banco de dados existentes e uma nova gerao de aplicaes de banco de dados geralmente requisitam mais diretamente um banco de dados orientado a objeto. Por outro lado, aplicaes de linguagens orientadas a objeto e sistemas esto exigindo capacidades de banco de dados, tais como continuidade, simultaneidade e transaes, dos seus ambientes. Estas necessidades esto levando criao de sistemas poderosos, chamados banco de dados orientados a objeto. Os bancos de dados orientados a objeto iniciaram-se primeiramente em projetos de pesquisa nas universidade e centros de pesquisa. Em meados dos anos 80, eles comearam a se tornar produtos comercialmente viaveis. Hoje, eles so mais de 25 produtos no mercado.

Conceitos Bsicos

O desenvolvimento dos Sistemas de Gerenciamento de Banco de Dados Orientado a Objetos (SGBDOO) teve origem na combinao de ideias dos modelos de dados tradicionais e de linguagens de programao orientada a objetos. No SGBDOO, a noo de objeto usada no nvel lgico e possui caractersticas no encontradas nas linguagens de programao tradicionais, como operadores de manipulao de estruturas, gerenciamento de armazenamento, tratamento de integridade e persistncia dos dados.

Os modelos de dados Orientados a Objetos tem um papel importante nos SGBDs porque, em primeiro lugar, so mais adequados para o tratamento de objetos complexos (textos, grficos, imagens) e dinmicos (programas, simulaes). Depois, por possurem maior naturalidade conceitual e, finalmente, por estarem em consonncia com fortes tendncias em linguagens de programao e engenharia de software. O casamento entre as linguagens de programao e banco de dados um dos problemas que esto sendo tratados de forma mais adequada no contexto de Orientao a Objetos. Apresenta-se adiante os conceitos bsicos de modelos de dados e SGBDs Orientados a Objetos.

Modelos de Dados Orientados a Objetos Superficialmente, pode-se dizer que Orientao a Objetos corresponde organizao de sistemas como uma coleo de objetos que integram estruturas de dados e comportamento. Alm desta noo bsica, a abordagem inclui um certo nmero de conceitos, princpios e mecanismos que a diferenciam das demais. Seus principais conceitos so apresentados em seguida.

Abstrao a considerao apenas das propriedades comuns de um conjunto de objetos, omitindo os detalhes, utilizada com frequncia na definio de valores similares e na formao de um tipo a partir de outro, em diferentes nveis de abstrao. O uso de abstraes permite a gerao de tipos baseada em hierarquias de tipos e de relacionamentos. Os principais conceitos de abstrao utilizados em banco de dados so generalizao e agregao. A generalizao corresponde associao um

onde, a partir de propriedades comuns de diferentes entidades, criada outra entidade. O processo inverso a especializao. A agregao corresponde a associao parte de.

Objeto Os objetos so abstraes de dados do mundo real, com uma interface de nomes de operaes e um estado local que permanece oculto. As abstraes da representao e das operaes so ambas suportadas no modelo de dados orientado a objetos, ou seja, so incorporadas as noes de estruturas de dados e de comportamento. Um objeto tem um estado interno descrito por atributos que podem apenas ser acessados ou modificados atravs de operaes definidas pelo criador do objeto. Um objeto individual chamado de instncia ou ocorrncia de objeto. A parte estrutural de um objeto (em banco de dados) similar noo de entidade no modelo EntidadeRelacionamento.

Identidade de Objeto Num modelo com identidade de objetos, estes tm existncia independente de seus valores correntes e dos endereos de armazenamento fsico. A identidade do objeto geralmente gerada pelo sistema. A impossibilidade de garantir a identificao de objetos exclusivamente atravs de suas propriedades estruturais e comportamentais motivou a definio de identificadores nicos de objetos, que persistem no tempo de forma independente ao estado interno do objeto. A identidade de objetos elimina as anomalias de atualizao e de integridade referencial, uma vez que a atualizao de um objeto ser automaticamente refletida nos objetos que o referenciam e que o identificador de um objeto no tem seu valor alterado.

Objetos Complexos Os objetos complexos so formados por construtores (conjuntos, listas, tuplas, registros, colees, arrays) aplicados a objetos simples (inteiros, booleanos, strings). Nos modelos Orientados a Objetos, os construtores so em geral ortogonais, isto , qualquer construtor pode ser aplicado a qualquer objeto. No modelo relacional este no o caso, visto que s possvel aplicar o construtor de conjuntos s tuplas e o construtor de registro a valores atmicos. A manuteno de objetos complexos, independente de sua composio, requer a definio de operadores apropriados para sua manipulao como um todo, e transitivos para seus componentes. Exemplos destas operaes so: a atualizao ou remoo de um objeto e cpia profunda ou rasa.

Encapsulamento O encapsulamento possibilita a distino entre a especificao e a implementao das operaes de um objeto, alm de prover a modularidade que permite uma melhor estruturao das aplicaes ditas complexas, bem como a segurana dentro do sistema. Em Banco de Dados se diz que um objeto est encapsulado quando o estado oculto ao usurio e o objeto pode ser consultado e modificado exclusivamente por meio das operaes a ele associadas. Existe uma certa discusso sobre as consultas em Banco de Dados quando est incorporada a noo de encapsulamento: Deve-se tornar visvel apenas as operaes e deixar ocultos os dados e as implementaes ? interessante relaxar o encapsulamento apenas para as consultas? Como deve ser realizada a otimizao de consultas em SGBDOO com encapsulamentos?

Tipo de Objetos O tipo de objeto pode ser visto como a descrio ou especificao de objetos. Um tipo possui duas partes, interface (visvel para o usurio do tipo) e implementao (visvel s para o usurio construtor do tipo). Existem vrias vantagens em se ter um sistema de tipos em um modelo de dados. Alm de modularidade e segurana, do ponto de vista da evoluo do sistema os tipos so especificaes do comportamento que podem ser compostos e modificados incrementalmente, para formar novas especificaes.

Classes Um conjunto de objetos que possui o mesmo tipo (atributos,

relacionamentos, operaes) pode ser agrupado para formar uma classe. A noo de classe associada ao tempo de execuo, podendo ser vista como uma representao por extenso, enquanto que o tipo uma representao intencional. Cada classe tem um tipo associado, o qual especifica a estrutura e o comportamento de seus objetos. Assim, a extenso da classe denota o conjunto dos objetos atualmente existentes na classe e o tipo prov a estrutura destes objetos.

Herana Herana um mecanismo que permite ao usurio definir tipos de forma incremental, por refinamento de outros j existentes, permitindo composio de tipos em que as propriedades de um ou mais tipos so reutilizadas na definio de um novo tipo. De fato, ela corresponde a transferncia de propriedades estruturais e de comportamento de uma classe para suas subclasses.

As principais vantagens de herana so prover uma maior expressividade na modelagem dos dados, facilitar a reusabilidade de objetos e definir classes por refinamento, podendo fatorar especificaes e implementaes como na adaptao de mtodos gerais para casos particulares, redefinindo-os para estes, e simplificando a evoluo e a reusabilidade de esquemas de banco de dados.

Tipos de Herana Os dois tipos de herana, simples e mltipla, so descritos a seguir:

Herana Simples: Na herana simples, um certo tipo pode ter apenas

um supertipo, da mesma forma uma subclasse s herda diretamente de uma nica classe. Podemos classificar esta herana em quatro subtipos: de substituio, de incluso, de restrio e de especializao.

Herana Mltipla: Nesta herana um tipo pode ter supertipos e os

mesmos refinamentos de herana simples. H basicamente dois tipos de conflitos referentes herana mltipla: entre o tipo e o supertipo e entre mltiplos supertipos. O primeiro pode ser resolvido dando-se prioridade definio presente no tipo, e no a no supertipo. Com os conflitos entre mltiplos supertipos, como uma resoluo por default pode causar heranas no desejadas, a abordagem mais segura baseada na requisio explcita da interveno do usurio.

Mtodos e Mensagens Um mtodo, em relao a um objeto, corresponde ao comportamento dos objetos, implementando uma operao associada a uma ou mais classes, de forma similar aos cdigos dos procedimentos usados em linguagens de programao tradicionais, que manipula o objeto ou parte deste. Cada objeto tem um certo nmero de operaes para ele definida. Para cada operao pode-se ter um ou mais mtodos de implementao associados.

As mensagens so a forma mais usada para se ativar os mtodos. Num SGBDOO os objetos se comunicam e so ativados atravs de mensagens enviadas entre eles.

Polimorfismo Em sistemas polimrficos uma mesma operao pode se comportar de diferentes formas em classes distintas. Como exemplo temos o operao

print que ser implementada de forma diferente se o objeto correspondente

for um texto ou uma imagem: dependendo do objeto teremos um tipo de impresso. Tem-se tambm polimorfismo quando ocorre a passagem de diferentes tios de objetos como parmetros enviados a outros objetos. Um mesmo nome pode ser usado por mais de uma operao definida sobre diferentes objetos, o que caracteriza uma sobrecarga (overloading). A redefinio do operador para cada um dos tipos de objetos definidos caracteriza uma sobreposio (overriding). As operaes so ligadas aos programas em tempo de execuo caracterizando o acoplamento tardio ou late binding.

Outros conceitos Finalmente h duas propriedades fundamentais para a construo de um SGBDOO: extensibilidade e completude computacional. A primeira garante que o conjunto de tipos oferecidos pelo sistema permite a definio de novos tipos e no h distino entre os tipos pr-definidos e os definidos pelo usurio. A segunda implica que a linguagem de manipulao de um Banco de Dados Orientado a Objetos pode exprimir qualquer funo computacional.

Tipos de dados

TINYINT: Armazena valores numricos inteiros, variando de 0 a 256. SMALLINT: Armazena valores numricos inteiros, variando de -32.768 a 32.767. INT: Armazena valores numricos inteiros, variando de -2.147.483.648 a 2.147.483.647. BIGINT: Armazena valores numricos inteiros, variando de -

9.223.372.036.854.775.808 a -9.223.372.036.854.775.807. SMALLMONEY: Valores numricos decimais variando de -214,748.3648 a 214,748.3647. MONEY: Valores numricos decimais variando de -

922,337,203,685,477.5808 a +922,337,203,685,477.5807. NUMERIC(18,0): Armazena valores numricos com casas decimais, utilizando preciso. O primeiro nmero entre os parnteses representa a quantidade de inteiros a ser armazenado, o segundo nmero, indica a quantidade de casas decimais do nmero. DECIMAL(18,0): Tem as mesmas funcionalidades do tipo NUMERIC, a diferena que o DECIMAL faz parte do padro ANSI e NUMERIC mantido por compatibilidade. FLOAT: Armazena valores numricos aproximados com preciso de ponto flutuante, variando de -1.79E + 308 a 1.79E + 308. REAL: Armazena valores numricos aproximados com preciso de ponto flutuante, variando de -3.40E + 38 a 3.40E + 38. Tipo BIT:

BIT: Armazena bits, ou seja, somente poder conter os valores lgicos 0 ou 1.

Tipo data:

SMALLDATETIME: Armazena data e hora, com preciso de minutos. DATETIME: Armazena data e hora, com preciso de centsimos de segundos. TIME: Armazena somente hora. Pode armazenar segundos at a frao de 9999999. DATE: Armazena somente data. DATETIME2: uma combinao dos tipos de dados DATE e TIME. A diferena para o tipo DATETIME a preciso ao armazenar as horas. DATETIMEOFFSET: Armazena valores data e hora com a combinao da hora do dia com o fuso horrio. O intervalo de deslocamento do fuso horrio de -14:00 a +14:00. Tipos caracteres:

CHAR(N): Armazena N caracteres fixos (at 8.000) no formato no Unicode. Independente da quantidade de caracteres utilizados, ir sempre armazenar o tamanho de caracteres do campo, sendo preenchido o restante com espaos em branco. VARCHAR(N): Armazena N caracteres (at 8.000) no formato no Unicode. VARCHAR(MAX): Armazena caracteres no formato no Unicode. MAX indica que o mximo a ser armazenado pode chegar a 2^31-1 bytes. TEXT: Armazena caracteres no formato no Unicode. Esse tipo de dado suporte at 2.147.483.647 caracteres e existem funes especficas para trabalhar com esse tipo de dado. NCHAR(N): Armazena N caracteres fixos (at 4.000) no formato Unicode. Independente da quantidade de caracteres utilizados, ir sempre armazenar

o tamanho de caracteres do campo, sendo preenchido o restante com espaos em branco. NVARCHAR(N): Armazena N caracteres (at 4.000) no formato Unicode. NVARCHAR(MAX): Armazena caracteres no formato Unicode. MAX indica que o mximo a ser armazenado pode chegar a 2^31-1 bytes. NTEXT: Armazena caracteres no formato Unicode. Esse tipo de dado suporte at 1.073.741.823 caracteres e existem funes especficas para trabalhar com esse tipo de dado. Outros tipos de dados:

BINARY(N): Armazena dados no formato binrio, podendo chegar at 8.000 bytes. Independente da quantidade de dados armazenados ser preenchido com espaos em brancos at completar o tamanho do campo. VARBINARY(N): Armazena dados no formato binrio, podendo chegar at 8.000 bytes. VARBINARY(MAX): Armazena dados no formato binrio, podendo chegar at 2^31-1 bytes. IMAGE: Armazena dados no formato binrio, podendo chegar at 2,147,483,647 bytes. SQL_VARIANT: Armazena todos os tipos de dados em um mesmo campo de uma tabela, com exceo dos tipos TEXT, NTEXT, TIMESTAMP e SQL_VARIANT. TIMESTAMP: Este tipo de dados permite a gerao automtica de um valor binrio para um campo de uma tabela. UNIQUEIDENTIFIER: Esse tipo de dados utilizado para a criao de um identificador global e nico para uma tabela do SQL Server.

GEOMETRY: Armazena dados espaciais utilizando representao plana da Terra (Flat Earth). GEOGRAPHY: Armazena dados espaciais utilizando representao redonda da Terra (Round Earth). HIERARCHYID: usado para representar uma posio em uma hierarquia. Uma coluna desse tipo no representa automaticamente uma arvore. at a aplicao para gerar e atribuir valores hierarchyid de tal forma que a relao desejada entre as linhas refletida nos valores.
XML: Armazena dados no formato XML, no podendo exceder a 2GB.

Concluso
Espero que ao final dessa apostila, voc tenha aprimorado e/ou aprendido coisas novas. Este documento estar em constante atualizao e sempre aberto crticas e sugestes. Um abrao e muito obrigado!

Referncias ALECRIM, Emerson, INFOWESTER. Sistemas RAID

(Redundant Array of Independet Disks). Jan. 2012. Disponvel em: <http://www.infowester.com/raid.php>. BLOG DA TI. Tipos de Dados SQL Server 2008. Disponvel em: <http://www.blogdati.com.br/index.php/2010/03/tipos-de-dadossql-server-2008/>. DEVMEDIA. Boas Prticas de segurana para SQL Server 2008/2008 R2. Ago. 2011. DEVMEDIA. Definindo Estratgia de Modelo de Recuperao para Banco de Dados SQL Server 2005. Set. 2007. DEVMEDIA. Entendendo e Utilizando ndices na Otimizao de Queries no SQL Server. Jan. 2008. DEVMEDIA. Segurana em Banco de Dados Aplicando Normas e Procedimentos. Set. 2012. DEVMEDIA. Microsoft SQL Server 2005 Trabalhando com ndices. Mar. 2008. DEVMEDIA. ndices no SQL Server. Out. 2010. GONTIJO, Rafael Igor Freire. Desenvolvimento do Data Mart Piloto do Centro Universitrio de Patos de Minas. Out. 2009. JNIOR, Fernando Corra de Mello. Sistemas de Banco de Dados II. Ago. 2009.

LEGATTI, Eduardo, ORACLE BLOG. Descomplicando RAID 01 (0+1) e RAID 10 (1+0). Mar. 2008. Disponvel em: <http://eduardolegatti.blogspot.com.br/2008/03/descomplicandoraid-01-01-e-raid-10-10.html>. MACHADO, Felipe Nery Rodrigues. Tecnologia e projeto de Data Warehouse: uma viso multidimensional. 2. ed. So Paulo: rica, 2006. 318 p. PORTAL EASYINFO. Notcias Web. Abr. 2010. Disponvel em: <http://migre.me/c6vgo>.