Explorer Data Collector
A collection of shell scripts and a few binary executable that gathers information and creates a detailed snapshot of a system's configuration and state.
Explorer output enables Sun engineers to perform assessments of the system by applying the output against knowledge-based rules engine.
Information related to drivers, patches, recent system event history and log file entries is obtained from the Explorer output.
Can be used by Sun and Sun's customers to identify and solve problems
- To expedite problem diagnosis and resolution (reactive)
- To prevent future problems (proactive)
LWACT - Lightweight Availability Data Collector
A lightweight stand alone availability collection tool
It utilizes the existing explorer transport for transporting availability data back to Sun
It is installed on each Solaris operating system instance and is enabled for SPARC, x86, containers and zones.
This lightweight solution allows the user to track system availability, such as, boot, panic and halt events
LWACT is designed to simplify Sun's availability collection process and to accommodate customer network/security policies
SNEEP - Serial Number in EEPROM
Easy Serial Number and Asset Retrieval
Equipment Life Cycle Management
Changes logged to system log for audit compliance
Makes Serial Number required when opening Service Case readily available to system administrator
Communicated to Sun via Explorer and Service Tags
Interconnects Sun databases and Services
Service Tags
Service Tags enable auto-discover and bulk registration of assets.
Service Tags allow reporting static product data, vendor information and versions, among others.
Data can be uploaded to the Sun Inventory Channel or stored locally.
Sun Service Tags embedded in Sun software products.
Solaris CAT - Solaris Crash Analysis Tool
Solaris Crash Analysis Tool is used by Sun's Kernel Team
Customer install able
Allows users to extract crash data which automates the process of data collection and transmits that data to Sun
Latest release includes a stand-alone mode that allows users to extract crash data without having to run Solaris CAT first
samedi 30 janvier 2010
mercredi 27 janvier 2010
Video Modelagem
http://www.vimeo.com/5275437
site teradata de modelagem
MER
Transformar a semantica do negocio no modelo relacional
traduzir para um diagrama a etapa mais importante da modelagem
definir as entidades e suas chaves
definir os atributos e seus dominios
definir seus relacionamentos, graus e cardinalidades
caracteristicas
_obvio Nao existe ordem entre as tuplas (linhas)
_obvio existe ordem entre os atributos
_obvio valores atomicos
_obvio tuplas distintas
_obvio integridade
_obvio chaves minimas
_obvio suporte para gerenciamento de valores nulos: nulo é diferente de vazio
_obvio independencia de dados
Modelo conceitual: interage diretamente com o MERX definindo os relacionamentos, entidades
, chaves, abstracoes e generalizacoes.
Modelo logico: define as dependencias funcionais, normalizacao e
prepara o ambiente para ser processado por um SGBD
Modelo fisico: traduz o modelo logico para as caracteristicas do seu
SGBD e hardware de modo a obter melhor performance e retorno sobre
o investimento.
cliente pessoa fisica ou cliente pessoa juridica = isolar cada uma.
normalizacao
reduz a redundancia de dados
acaba com anomalias de atualizacao
agrega consistencia de dados
introduzidas por cood na dec 70
uma tabela deve contemplar sempre um unico assunto
existem varias formas normais, porem atingir a terceira forma normal
pode ser jaa considerado o estado da arte de normalizacao em alguns cenarios
reduz a quantidade de atributos e aumenta a qtde de tabelas, facilitando a
manutencao do modelo
1 forma normal: uma relacao esta em primeira forma normal se, e somente se, todos os dominios tiverem
apenas valores atomicos.
2 forma normal: uma relacao esta em segunda forma normal se, estiver na primeira forma normal e todo atributo nao chave for totalmente
dependente da chave primaria
3 forma normal: uma relacao esta em terceira forma normal se, estiver na segunda forma normal e e nao existir dependencias transitivas.
dependencia transitiva: caso pais, estado, cidade,bairro
MER
Transformar a semantica do negocio no modelo relacional
traduzir para um diagrama a etapa mais importante da modelagem
definir as entidades e suas chaves
definir os atributos e seus dominios
definir seus relacionamentos, graus e cardinalidades
caracteristicas
_obvio Nao existe ordem entre as tuplas (linhas)
_obvio existe ordem entre os atributos
_obvio valores atomicos
_obvio tuplas distintas
_obvio integridade
_obvio chaves minimas
_obvio suporte para gerenciamento de valores nulos: nulo é diferente de vazio
_obvio independencia de dados
Modelo conceitual: interage diretamente com o MERX definindo os relacionamentos, entidades
, chaves, abstracoes e generalizacoes.
Modelo logico: define as dependencias funcionais, normalizacao e
prepara o ambiente para ser processado por um SGBD
Modelo fisico: traduz o modelo logico para as caracteristicas do seu
SGBD e hardware de modo a obter melhor performance e retorno sobre
o investimento.
cliente pessoa fisica ou cliente pessoa juridica = isolar cada uma.
normalizacao
reduz a redundancia de dados
acaba com anomalias de atualizacao
agrega consistencia de dados
introduzidas por cood na dec 70
uma tabela deve contemplar sempre um unico assunto
existem varias formas normais, porem atingir a terceira forma normal
pode ser jaa considerado o estado da arte de normalizacao em alguns cenarios
reduz a quantidade de atributos e aumenta a qtde de tabelas, facilitando a
manutencao do modelo
1 forma normal: uma relacao esta em primeira forma normal se, e somente se, todos os dominios tiverem
apenas valores atomicos.
2 forma normal: uma relacao esta em segunda forma normal se, estiver na primeira forma normal e todo atributo nao chave for totalmente
dependente da chave primaria
3 forma normal: uma relacao esta em terceira forma normal se, estiver na segunda forma normal e e nao existir dependencias transitivas.
dependencia transitiva: caso pais, estado, cidade,bairro
dimanche 24 janvier 2010
Windows versions
Home
Professional
windows 7: Ultimate, Enterprise, Professional, Home Premium, Home Basic, Starter.
Windows 2008: Datacenter, Enterprise, HPC Edition, Foundation, Itanium-Based-Systems, Small Business, web server.
Windows Vista: Ultimate, Enterprise, Business, Home Premium, Home Basic, Starter
Windows 2003: Data center, Enterprise, Storage Server, Standard, Web Edition, Small Business Server, Compute Cluster Server
Window XP: Professional, Home, Starter Edition
windows 2000: Professional, Server, Advanced Server, Data Center Server
mardi 19 janvier 2010
lundi 18 janvier 2010
TIPS
VALOR CALCULADO NA FATO.
- Quando temos Valor de Custo e Valor de Venda na tabela fato. Devemos colocar uma coluna para LUCRO = (VL VENDA - VL CUSTO)ou deixar para ser calculado no SQL ou software? R. Devemos implementar uma coluna na tabela fato, SIM.
Date Key is Number or Date?
-Date column must be number type.
Date dimension versus date in Fact table
-Date type column in fact table it is ok, but the numerous classifications for dates cannot be obtained by SQL Date functions. For example: Major event column, that can hold "Jogos Olimpicos". Qual funcao sql para datas iria dizer isso?
-most databases do not index SQL date calculations, so queries constraining on an SQL-calculated field would not take advantage of an index. How oracle handles it?
Date and Time.
It is better if we create a date dimension(3650 linhas) and a date time dimension (5.256.000 linhas).
Devemos evitar nulos na tabela fato. Ex: Coloque um valor "Promocao nao se aplica" na dimensao Promocao com uma chave. Essa chave vai se relacionar com a fato.
Nonadditive Facts: Unit price, gross margin
Promotion dimension in 4 parts: It is possible to divide the promotion dimension, depends on requirements.
Devemos evitar snowflaking, com uma excecao: outtrigers
Cada processo de negocio pode ser representado com menos de 15 dimensoes, se houver mais de 24, o modelo precisa ser revisado.
Surrogate keys for date dimension must be in sequential order. Day 1 jan 1990 = 1, day 2 = 2...
We do not want to embed extensive calendar intelligence in these keys (for example YYYMMDD) because doing so may encorage people to bypass the date lookup dimension table.
SCDs (Slowly changing dimensions):
SCD1 = overwrite the value. NO historical.
SCD2 = ADD a dimension row. BAD for big dimensions. MOST USED.
SCD3 = ADD a dimension column.
Technique 1: chapter2 page 46 outtriger.
Technique 2: chapter2 page49 Promotion Coverage Factless Fact Table
Technique 3: chapter2 page 62 Market Bask Analysis
- Quando temos Valor de Custo e Valor de Venda na tabela fato. Devemos colocar uma coluna para LUCRO = (VL VENDA - VL CUSTO)ou deixar para ser calculado no SQL ou software? R. Devemos implementar uma coluna na tabela fato, SIM.
Date Key is Number or Date?
-Date column must be number type.
Date dimension versus date in Fact table
-Date type column in fact table it is ok, but the numerous classifications for dates cannot be obtained by SQL Date functions. For example: Major event column, that can hold "Jogos Olimpicos". Qual funcao sql para datas iria dizer isso?
-most databases do not index SQL date calculations, so queries constraining on an SQL-calculated field would not take advantage of an index. How oracle handles it?
Date and Time.
It is better if we create a date dimension(3650 linhas) and a date time dimension (5.256.000 linhas).
Devemos evitar nulos na tabela fato. Ex: Coloque um valor "Promocao nao se aplica" na dimensao Promocao com uma chave. Essa chave vai se relacionar com a fato.
Nonadditive Facts: Unit price, gross margin
Promotion dimension in 4 parts: It is possible to divide the promotion dimension, depends on requirements.
Devemos evitar snowflaking, com uma excecao: outtrigers
Cada processo de negocio pode ser representado com menos de 15 dimensoes, se houver mais de 24, o modelo precisa ser revisado.
Surrogate keys for date dimension must be in sequential order. Day 1 jan 1990 = 1, day 2 = 2...
We do not want to embed extensive calendar intelligence in these keys (for example YYYMMDD) because doing so may encorage people to bypass the date lookup dimension table.
SCDs (Slowly changing dimensions):
SCD1 = overwrite the value. NO historical.
SCD2 = ADD a dimension row. BAD for big dimensions. MOST USED.
SCD3 = ADD a dimension column.
Technique 1: chapter2 page 46 outtriger.
Technique 2: chapter2 page49 Promotion Coverage Factless Fact Table
Technique 3: chapter2 page 62 Market Bask Analysis
Glossario
Dimension (Dimensao): é uma tabela que contem NO MINIMO uma chave primaria e uma descricao. Uma dimensao que aparece em todos os modelos dimensionais é a dimensao tempo. Dimensao devem haver o maior numero de colunas possiveis, pois serao usado como filtro pelos usuarios.
Fact (Fato): é uma tabela que contem varias chaves estrangeiras mais os valores numericos, como quantidade, valor, lucro etc.
Star schemas: um modelo que forma em estrela, na qual a tabela fato esta no centro cercada por dimensoes.
Snow Flake schemas: um modelo em forma de estrela, porem contem dimensoes ligadas a dimensoes. Por exemplo, localidade pode estar normalizada (regiao, pais, cidade, estado).
Surrogate keys, Meaningless keys, integer keys, nonnatural keys, artificial keys, synthetic keys... = Sao numeros inteiros que sao determinadas sequencialmente para popular a dimensao.
Natural keys: identificador usado por sistemas operacionais. Por exemplo: BOXOMO1 significa caixa de sabao em po OMO. Esse codigo deve ser um atributo na dimensao, nao uma chave.
Causal dimensions: por ex: promotion dimension. because it describes factors thought to cause a change in product sales.
Degenerate dimensions (DD): Operational numbers such as order numbers, invoice numbers, and bill-of-landing numbers usually give rise to empty dimensions and are represented as DD.
DD often play an integral role in the fact table's primary key. Often, the primary key of a fact table is a subset of the tables's foreign key. We typically do not need every foreign key in the fact table to guarantee the uniqueness of a fact table row.
Conformed dimensions: are dimensions that can be used in different business process.
Fact (Fato): é uma tabela que contem varias chaves estrangeiras mais os valores numericos, como quantidade, valor, lucro etc.
Star schemas: um modelo que forma em estrela, na qual a tabela fato esta no centro cercada por dimensoes.
Snow Flake schemas: um modelo em forma de estrela, porem contem dimensoes ligadas a dimensoes. Por exemplo, localidade pode estar normalizada (regiao, pais, cidade, estado).
Surrogate keys, Meaningless keys, integer keys, nonnatural keys, artificial keys, synthetic keys... = Sao numeros inteiros que sao determinadas sequencialmente para popular a dimensao.
Natural keys: identificador usado por sistemas operacionais. Por exemplo: BOXOMO1 significa caixa de sabao em po OMO. Esse codigo deve ser um atributo na dimensao, nao uma chave.
Causal dimensions: por ex: promotion dimension. because it describes factors thought to cause a change in product sales.
Degenerate dimensions (DD): Operational numbers such as order numbers, invoice numbers, and bill-of-landing numbers usually give rise to empty dimensions and are represented as DD.
DD often play an integral role in the fact table's primary key. Often, the primary key of a fact table is a subset of the tables's foreign key. We typically do not need every foreign key in the fact table to guarantee the uniqueness of a fact table row.
Conformed dimensions: are dimensions that can be used in different business process.
4 Passos para o processo de criacao dimensional
1 - Selecionar o modelo de processo do negocio.
Quando criamos um modelo, precisamos pensar em processo do negocio, nao no departamento. Por exemplo: Temos o departamento Vendas e Marketing.
Nosso modelo poder ser de Pedidos. Pois serao acessado por ambos. Evitando duplicacao de dados.
2 - Declarar o grao do processo do negocio.
Significa especificar exatamente o que uma unica linha na tabela fato representa.
Responda a questao: "O que uma linha na fato representa?"
Exemplos:
-um bilhete de voo
-um empregado na empresa
-um bilhete de cinema
-um item de uma nota fiscal de compra de supermercado
-o saldo mensal de uma conta de banco
Escolher o nivel mais detalhado. Pois o conjunto delas formam dados agregados. Fazendo assim os papeis das tabelas agregadas.
ESSA ANALISE é CRITICA. Se estiver errado, ira estragar a estrutura toda, descobre-se nos passos 3 e 4 que a declaracao do grao esta errado.
3 - Escolher as dimensoes que aplicam a cada linha da tabela fato.
Responder a pergunta: "Como as pessoas de negocio descrevem os dados que resultam do processo de negocio?"
Exemplos: data, produto, cliente, status...
4 - Identificar as medidas fatos que irao popular cada linha da tabela fato.
Sao numeros. Responder a pergunta: "O que estamos medindo?"
Preço, lucro, quantidade.
Quando criamos um modelo, precisamos pensar em processo do negocio, nao no departamento. Por exemplo: Temos o departamento Vendas e Marketing.
Nosso modelo poder ser de Pedidos. Pois serao acessado por ambos. Evitando duplicacao de dados.
2 - Declarar o grao do processo do negocio.
Significa especificar exatamente o que uma unica linha na tabela fato representa.
Responda a questao: "O que uma linha na fato representa?"
Exemplos:
-um bilhete de voo
-um empregado na empresa
-um bilhete de cinema
-um item de uma nota fiscal de compra de supermercado
-o saldo mensal de uma conta de banco
Escolher o nivel mais detalhado. Pois o conjunto delas formam dados agregados. Fazendo assim os papeis das tabelas agregadas.
ESSA ANALISE é CRITICA. Se estiver errado, ira estragar a estrutura toda, descobre-se nos passos 3 e 4 que a declaracao do grao esta errado.
3 - Escolher as dimensoes que aplicam a cada linha da tabela fato.
Responder a pergunta: "Como as pessoas de negocio descrevem os dados que resultam do processo de negocio?"
Exemplos: data, produto, cliente, status...
4 - Identificar as medidas fatos que irao popular cada linha da tabela fato.
Sao numeros. Responder a pergunta: "O que estamos medindo?"
Preço, lucro, quantidade.
Componentes de um Data warehouse
Sistemas OLTP onde a informacao operacional é guardada.
Constitue de: Banco de dados ou arquivos texto.
Data Staging Area:
Area de armazenamento e conjunto de processos feitos pelo ETL. Fica entre o Operational Source Systems e a Data Presentation.
Constitue de: Arquivos texto, banco de dados normalizado, tabelas)
*Nao prove query ou apresentacao para usuarios.
Data Presentation:
O data Warehouse onde os usuarios rodam queries, fazem relatorios.
Constitue de: banco de dados dimensional, queries e relatorios.
Metadata:
Informacao dos dados do datawarehouse. Documentacao interna dos dados.
Constitue de: banco de dados, arquivos word, text e excel ou software.
ODS Operational data store:
implementado para relatorios operacionais que nao sao possiveis pelo mainframe ou OLTP.
Constitue de: banco de dados
Inscription à :
Commentaires (Atom)
