terça-feira, 3 de dezembro de 2013

Usando Aliases e Literais de Strings - SQL na Prática

O que são Aliases

As aliases podem ser atribuídas para colunas na lista de seleção e para fontes de dados na cláusula FROM; Declarações de SELECT podem ser feitas facilmente para serem lidas usando ALIASES (apelidos).

Aliases, tanto para colunas e tabelas, dentro de uma instrução SELECT são feitas para tornar a digitação e a leitura da declaração mais simples;

As Aliases não fazem somente a declaração mais fácil de ler, mas também podem fazer mais fáceis de ler e interpretar o conjunto de resultados;

Na prática:
- A cláusula opcional AS pode ser adicionada para que a declaração fique mais legível;
Ambas as declarações abaixo são equivalentes;

SELECT e.ContactID AS 'Employee Identification Number'
FROM HumanResources.Employee AS e

SELECT e.ContactID 'Employee Identification Number'
FROM HumanResources.Employee AS e


Literais de string:

- São valores constantes;
- Pode ser inserida dentro de uma coluna derivada para formatar um dado;
- Pode ser usada como valores alternativos em funções, como na função ISNULL();

-- Se MiddleName for null, ele retorna o '' (sem espaço)
-- Substring pega a desde a posição 1 (1º parâmetro)
-- de MiddleName, mais 1 caractere (2º parâmetro)

SELECT (LastName + ',' + FirstName + ''
 + ISNULL(SUBSTRING(MiddleName,1,1),'')) as Name
FROM Person.Contact
ORDER BY LastName,FirstName,MiddleName;

SELECT (LastName + ',' + SUBSTRING(FirstName,1,2)) as Name
FROM Person.Contact
ORDER BY LastName,FirstName,MiddleName;

Literais de strings são Strings estáticas que são inseridas dentro de colunas derivadas, como uma vírgula entre partes de um nome concatenado. Eles também podem ser usados como valores alternativos em vez do valor da coluna numa função como NULLIF() e COALESCE().

- Aliases de Colunas e tabelas não são literais de Strings;
- Literais de strings podem ser usadas por funções como retorno de valores alternativos;

segunda-feira, 28 de outubro de 2013

Mapeando MER para o Modelo Relacional | Atributos Multivalorados, Agregação e Relacionamento 1 para 1


  • Atributos Multivalorados: novas tabelas devem ser criadas para armazená-los juntamente com a chave primária da entidade que os possui. Exemplo:

Livros (No_tombo, título, ano, editora)
Autores (No_tombo, autor)
  • Agregação: como a agregação é a representação de um conjunto de relacionamentos como se fosse um conjunto de entidades, o mapeamento para tabelas é semelhante ao mapeamento aplicado em entidades e relacionamentos normais.
  • Relacionamentos de 1 para 1: para decidir como será feita a transposição de chaves, deve-se observar a participação total com relação ao relacionamento.
Exemplo:



Todo país tem uma capital, mas nem toda cidade é capital de um país, portanto a tabela de países é que deve receber a código da cidade que é capital.

Países (código, nome, continente, código_capital)
Cidades ( código, nome, população)

OBS: Relacionamentos Binários de 1 para n podem gerar tabela quando não há totalidade na associação.

Fonte: Apostila professores Cláudio e Carrilho, download em Março/2006

sexta-feira, 25 de outubro de 2013

Mapeando MER para o Modelo Relacional | Generalização e Especialização


  • Generalização e Especialização: há duas maneiras de definir as tabelas para uma generalização ou especialização:
    • Define-se uma tabela para o conjunto de entidades do nível mais alto (com os atributos comuns) e uma tabela para cada entidade do nível mais baixo (com seus atributos próprios + a chave primária da entidade do nível mais alto). Exemplo:


Contas (número, saldo)
Contas_corrente (número, limite)
Contas_poupança (número, data_base)

    • Define-se tabelas apenas para os conjuntos de entidades do nível mais baixo (com seus atributos próprios, mais todos os atributos herdados do conjunto de entidades do nível mais alto).
      Essa opção só é permitida se a generalização / especialização for mutuamente exclusiva (uma entidade não pertence a mais do que um dos subconjuntos) e total (todas as entidades do nível mais alto pertencem a um dos subconjuntos do nível de baixo). Exemplo:

Contas_corrente (número, saldo, limite)
Contas_poupança (número, saldo, data_base)

Fonte: Apostila professores Cláudio e Carrilho, download em Março/2006

quarta-feira, 23 de outubro de 2013

Mapeando MER para o Modelo Relacional | Relacionamentos


  • Conjunto de Relacionamentos: podem ou não gerar tabelas:
    • Relacionamentos Múltiplos ou Relacionamentos Binários de N para N: geram tabelas com as chaves primárias das entidades envolvidas mais os atributos próprios do relacionamento. Exemplo:
                 
                Usuários (COD, nome, fone)
                Livros (No_tombo, título, ano, editora)
                Empréstimos (COD, No_tombo, data_ret, data_dev)

    • Relacionamentos Binários de 1 para N ou de 1 para 1: não geram tabelas. Para associar as tuplas das tabelas no Modelo Relacional deve-se transpor a chave de um conjunto de entidades para o outro ( a chave da entidade do lado com 1 é transposta para a entidade do lado n). A chave transposta nesse caso não compõe a chave primária da entidade que a recebeu (é uma chave estrangeira).
      Obs: no caso da transposição de chave entre a entidade forte e a entidade fraca que dela depende, a chave transposta compõe a chave primária da entidade fraca). Exemplo:

                 Países (código, nome, continente)
                 Cidades ( código, nome, população, código_país)

Fonte: Apostila professores Cláudio e Carrilho, download em Março/2006

terça-feira, 22 de outubro de 2013

Mapeando MER para o Modelo Relacional | Entidades

Um Diagrama de Entidade relacionamento pode ser representado por um conjunto de tabelas ( esquema do Modelo Relacional)

  • Conjunto de Entidades: cada conjunto de entidades do DER gera uma tabela no Modelo Relacional.
    • Entidades Fortes: tabela com seus atributos próprios
Contas (Número, saldo)

    • Entidades fracas: tabela com chave primária da entidade forte da qual ela depende mais seus atributos próprios

Carros (chassi, marca, modelo, ano, cor, placa)
Reparos (chassi, data, tipo, valor, oficina)

Fonte: Apostila professores Cláudio e Carrilho, download em Março/2006

segunda-feira, 21 de outubro de 2013

Modelo Relacional e suas Definições

  • Banco de Dados representado por um conjunto de tabelas também chamadas de relações (relacionam um conjunto de valores).
  • Cada linha de uma tabela também é chamada de uma tupla. (n-upla).
  • Esquema de um BD Relacional: definição do conjunto de tabelas e seus atributos que irão compor a base de dados (estrutura do BD relacional)
  • Instância de um BD Relacional: conjunto de dados armazenados no BD em um determinado momento.

Exemplo:
  Esquema:
    usuários ( código inteiro [chave primária],
                   nome caracteres [30],
                   end_rua caracteres [20],
                   end_número inteiro,
                   ....)
    livros ( código inteiro [chave primária],
               título caracteres[20],
               editora caracteres[10],
               ano_pub inteiro)
    empréstimos ( cod_usuário inteiro [chave primária],
               cod_livro inteiro [chave primária],
               data_ret data [chave primária],
               data_dev data )

Instância:


Fonte: Apostila professores Cláudio e Carrilho, download em Março/2006

sexta-feira, 18 de outubro de 2013

Integridade Referencial - Banco de Dados

É um mecanismo utilizado para manter a consistência das informações gravadas. Dessa forma, não são permitidas a entrada de valores duplicados nem a existência de uma referência a uma chave inválida em uma entidade.

É importante enfatizar o conceito de integridade referencial. É também necessário que cada valor de chave estrangeira possua uma ocorrência na outra entidade à qual faz referência. Se isso não ocorrer, fica claro que estaremos perdendo uma informação importante para o sistema. Exemplo: se tivermos um valor na entidade CD correspondente à gravadora (chave estrangeira) e não tivermos o mesmo valor (chave primária) na entidade Gravadora, estaremos diante de um problema, pois teríamos um CD sem uma Gravadora válida.

A maior parte dos bancos de dados relacionais estabelece esse tipo de relacionamento e impede que durante uma inclusão, exclusão ou alteração uma chave estrangeira de uma entidade não tenha correspondente na chave primária da outra entidade. Assim, em uma inclusão na entidade com a chave estrangeira, caso seja informado um código que não exista, correspondente na outra entidade, deve ser gerada uma mensagem de erro. Assim, caso queiramos incluir um CD com um código de Gravadora que não exista, correspondente na tabela Gravadora, deve ser enviada uma mensagem de erro e impedida a gravação da informação.

No caso de uma alteração ou exclusão na chave primária da entidade, deve-se verificar se há registros dependentes (chave estrangeira) nas demais tabelas. Se houver, deve-se excluir todos os registros dependentes ou alterá-los, dependendo do caso. Isso poderia ocorrer caso quiséssemos excluir ou alterar uma Gravadora e tivéssemos CDs armazenados com o código da Gravadora. Se fosse permitido, teríamos uma informação inválida, pois ao tentarmos localizar a Gravadora deste CD, isso não seria possível.

Caso o seu banco de dados não disponha desse recurso, você deverá levar isso em consideração e criar mecanismos que evitem o problema. Quanto o banco de dados dispuser desse recurso, este adotará o nome CONSTRAINT.

Em alguns bancos de dados é possível controlar até a propagação de exclusões ou alterações na chave primária: ou se apagam todos os registros dependentes ou se altera o seu código. Assim, caso excluíssemos ou alterássemos uma determinada Gravadora, todos os CDs dessa gravadora seriam automaticamente excluídos ou alterados. Note que isso é bastante perigoso, pois normalmente nenhuma mensagem será dada ao usuário. A regra será a automática modificação das informações no banco de dados.

quinta-feira, 17 de outubro de 2013

Especificação - MER

As técnicas de orientação a objetos tiveram várias influencias sobre o projeto de bases de dados. Uma delas é o conceito de subclasse e herança. Muitas vezes queremos registrar características especiais de certos subconjuntos de um CE. Por exemplo, no CE Funcionários temos secretária, técnicos, engenheiros, gerentes etc, e para cada uma dessas categorias queremos guardar alguns atributos específicos, como habilidades das secretárias em digitação, informática, línguas etc. Outros atributos seriam requeridos para engenheiros e assim por diante. Seria ineficiente estender o CE Funcionários com todos esses atributos que só teriam valores para cada grupo específico de funcionários ficando vazios os não correspondentes ao grupo. Para este fim criamos os CE´s denominados Secretárias, Técnicos, Engenheiros etc, e um tipo especial de relacionamentos desses CE´s chamado “é um” e representado por um triângulo.


Esses novos CE´s são também chamados de especializações do CE Funcionários. Como o nome “é-um” indica, o relacionamento significa que uma secretária “é uma” funcionária, isto é, possui todos os atributos do CE funcionário.

O símbolo “+” indica que a especialização é do tipo “ou exclusivo”, ou seja, um funcionário pode ser especializado em apenas um dentre “Secretárias”, “Técnicos” e “Gerentes”.

quarta-feira, 16 de outubro de 2013

Agregações - MER

Há casos em que relacionamentos de grau superior a 2 não capturam as regras de negócio desejadas. Por exemplo, no relacionamento triplo MRP visto anteriormente em materiais, requisições e pedidos (ordens de compra), uma requisição está relacionada com um ou mais materiais e com um ou mais pedidos (ou com nenhum deles), o que é artificial.

Requisições precedem a pedidos no tempo e originalmente estão relacionadas apenas com Materiais, já que toda requisição é criada para comprar um ou mais materiais. Elas se originam em diversos setores da empresa e são encaminhadas ao setor de compras. O setor de compras associa um pedido de compra ao par (requisição, material), portanto, ao relacionamento, especificando a quantidade a ser comprada ( que pode ser diferente da requisitada, por exemplo, para obter um desconto maior ou devido a alguma restrição de tamanho de lote de venda). Esta separação de funções implica na existência de dois relacionamentos distintos; o segundo é chamado de agregação porque o relacionamento de Materiais com Requisição é agregado em um pseudo CE, que por sua vez se relaciona com Pedidos através do relacionamento “Itens de pedidos”.


terça-feira, 15 de outubro de 2013

Relacionamento de Grau 3 - MER

Os exemplos vistos até agora são de relacionamento envolvendo dois CE´s. Eles são ditos binários ou de grau 2 e são os mais comuns na prática. O grau de um relacionamento é um número de CE´s envolvidos no relacionamento. A figura abaixo mostra um relacionamento de grau 3, ou triplo, entre professores, alunos e disciplinas.

A cardinalidade desse relacionamento, 1 : N : N, pode ser interpretada da seguinte forma:
- dado um professor e uma determinada disciplina temos diversos alunos;
- dado um professor e um determinado aluno, temos diversas disciplinas;
- dado um aluno e uma certa disciplina, temos um único professor;



A figura abaixo mostra um relacionamento triplo chamado MRP entre Materiais, Pedidos e Requisições, típico de um sistema de compras de materiais, onde requisições vindas de diversos setores são agrupadas em pedidos ou ordens de compra e se deseja relacionar cada pedido com as requisições originais. O relacionamento possui dois atributos: quantidade requisitada e quantidade pedida. O relacionamento tem cardinalidade N : N : N e é total do lado de Pedidos e de Requisições (toda requisição está associada a um ou mais pedidos e pode conter vários materiais, idem para pedidos), mas é parcial do lado de Materiais (um dado material pode não estar sendo comprado no momento).