Sistemas de Bases de Dados vs. Sistemas de Ficheiros e Conceitos SGBD

Sistemas de Bases de Dados vs. Sistemas de Ficheiros

Os sistemas de base de dados surgiram com o intuito de colmatar as limitações dos sistemas baseados em ficheiros. Nos sistemas de base de dados existe uma centralização da informação, que pode ser assim acedida simultaneamente por diversos utilizadores, eliminando assim a separação e isolamento dos dados, bem como a redundância da informação, características dos sistemas baseado em ficheiros. Num sistema de base de dados existe independência entre a informação e as aplicações que fazem uso dela, melhorando assim em relação ao sistema de ficheiros onde as aplicações eram desenhadas para um tipo de ficheiros específico.

Vantagens e Desvantagens de um SGBD

Vantagens do SGBD

• Controlo sobre a redundância de dados
• Consistência de dados
• Partilha de dados
• Mais segurança
• Mais produtividade
• Mais concorrência
• Mais informação tendo em conta os mesmos dados
• Melhoria na manutenção através da independência de dados
• Integridade de dados melhorada
• Implica uso de standards
• Acessibilidade aos dados e rapidez de resposta melhorados
• Requisitos conflituosos balanceados
• Serviços de cópias de segurança e de recuperação de falhas melhoradas
• Economia de escala
• Suporte a transações
• Serviços de controlo de concorrência

Desvantagens do SGBD

• Custo do hardware acrescido
• Custo de conversão
• Performance (pode ser afetada)
• Maior impacto em caso de falha
• Complexidade
• Tamanho
• Custo do SGBD

Quando Preferir Sistemas de Ficheiros

Quando a quantidade de informação armazenada é baixa e tem o propósito de servir apenas um departamento é preferível um sistema menos complexo tal como um sistema de ficheiros. Para além do tamanho e complexidade serem baixos o custo comparativamente a um SGBD é também muito inferior e em caso de falha o impacto é inferior.

Funções que um SGBD Deve Satisfazer

• Armazenamento, pesquisa e actualização de dados
• Dicionário de dados
• Serviços de recuperação
• Serviços de autenticação
• Suporte e comunicação de dados
• Serviços de integridade
• Serviços que promovam a independência de dados
• Serviços utilitários

Definição de Termos

a. Bases de Dados

Coleção partilhada de dados, logicamente relacionados e a descrição desses dados, desenhado para satisfazer a necessidade de informação de uma organização.

b. Sistema de Gestão de Bases de Dados (SGBD) e Componentes

Sistema de software que permite aos utilizadores, definir, criar, manter e controlar o acesso à base de dados. Componentes: Hardware, software, dados, procedimentos e pessoas.

c. Metadados

Repositório de informação que descreve os dados na base de dados. Este disponibiliza a descrição dos dados para obtermos aplicações independentes. Armazena normalmente: nomes de utilizadores, nomes de itens de dados na base de dados, restrições sobre cada item de dados, itens de dados acessíveis por utilizadores e por tipo de acesso.

Modelo Relacional

Definição de Termos do Modelo Relacional

a. Chave Candidata

Super chave (K) tal que nenhum subconjunto de atributos seja super chave na relação. Nenhum subconjunto de atributos de K tem a propriedade unicidade.

b. Chave Primária

Chave candidata selecionada para identificar univocamente tuplos na relação, é escolhida de acordo com o “negócio”.

c. Chave Estrangeira

Atributo, ou conjunto de atributos, numa relação que são chaves candidatas de alguma (pode ser a mesma) relação. Toma o valor de onde é chave primaria ou então toma o valor de NULL.

Cláusulas do Comando SELECT

• FROM: especifica a(s) tabela(s) a ser utilizadas
• WHERE: filtra linhas sujeitas a alguma condição
• GROUP BY: forma grupos de linhas com o mesmo valor na coluna
• HAVING: filtra grupos sujeitos a alguma condição
• ORDER BY: especifica a ordem do resultado

Independência de Dados

O conceito de independência de dados significa que mudanças realizadas nos níveis inferiores não afetam os níveis superiores. Existem dois tipos de independência de dados: lógicos e físicos. Este conceito é muito importante porque quando são realizadas alterações tais como adições de entidades, atributos ou relações estas devem ser possíveis de serem realizadas, sem se ter de mudar o nível externo ou ter de se voltar a escrever a aplicação.

Funções de Agregação e Valores Nulos (NULL)

As funções de agregação, à exceção do COUNT(*), primeiro eliminam os valores nulos e depois operam sobre os restantes. COUNT, MIN e MAX aplicam-se a campos numéricos e não numéricos, mas SUM e AVG só se aplicam a campos numéricos. A parte de COUNT(*) cada função elimina primeiro os nulos e opera apenas nos valores restantes.

Integridade Referencial e Ações ON DELETE/ON UPDATE

Qualquer INSERT/UPDATE que tente criar um valor na FK da tabela filha sem que exista um valor idêntico na chave candidata da tabela pai é rejeitado. As ações referenciam a forma como a atualização/apagamento na tabela pai afeta as tabelas filhas:

• CASCADE: apaga a linha da tabela pai e linhas correspondentes das tabelas filhas e assim sucessivamente em cascata.
• SET NULL: apaga a linha da tabela pai e muda todas as colunas FK na tabela filha para NULL. Só é valido se as colunas FK não estiverem a NOT NULL.
• SET DEFAULT: apaga a linha da tabela pai e muda cada componente da FK da tabela filha para o valor DEFAULT especificado. Só é válido se houver um valor DEFAULT especificado para as colunas FK.
• NO ACTION: rejeita a operação da tabela pai. (opção por defeito)

Materialização e Resolução de Vistas

Mecanismo de Materialização de Vistas

Os nomes das colunas da vista na lista SELECT são traduzidos para os nomes das colunas correspondentes na definição da vista. Os nomes das vistas no FROM são substituídos pelos correspondentes da lista do FROM da definição da vista. As cláusulas GROUP BY e HAVING são copiadas da definição da vista. O ORDER BY é copiado da query e o nome da coluna traduzido para o nome da coluna da definição da vista. O resultado final da query é então apresentado. Como a vista é armazenada numa tabela temporária, à medida que as tabelas base são actualizadas, existe uma dificuldade em manter a actualidade da vista à medida que as tabelas base são actualizadas.

Mecanismo de Resolução de Vistas

Os nomes das colunas da vista na lista SELECT são traduzidos para os nomes das colunas correspondentes na definição da vista. Os nomes das vistas no FROM são substituídos pelos correspondentes da lista do FROM da definição da vista. O WHERE da query do utilizador é combinado com o WHERE da definição da vista usando o AND. As cláusulas GROUP BY e HAVING são copiadas da definição da vista. O ORDER BY é copiado da query e o nome da coluna traduzido para o nome da coluna da definição da vista. O resultado final da query é então apresentado.

Cursores SQL

Para manusear uma query que pode retomar um número aleatório de linhas que podem ser (0, 1 ou várias) o SQL usa cursores para permitir aceder as linhas resultantes da query uma de cada vez. Como resultado os cursores funcionam como ponteiros para uma linha específica do resultado da query.

Subquery vs. Junção

Se as colunas do resultado que pretendermos obter resultarem de mais do que uma tabela não é possível realizar uma subquery e temos que utilizar uma operação de junção. Uma subquery produz uma tabela temporária com origem numa só tabela, já uma join produz uma tabela com origem em mais do que uma tabela.

Desenho de Base de Dados com Múltiplas Vistas de Utilizadores

As três principais abordagens são:

1. Centralizada: Requisitos de cada vista de utilizador é agregada numa só coleção de requisitos. É criado um modelo global de dados baseado neste conjunto de requisitos.
2. Integração de vistas: São utilizados os requisitos de cada vista de utilizador para criar um modelo de dados separado (modelo de dados local). Os modelos de dados locais são depois fundidos para produzir o modelo de dados global.
3. Combinação das duas anteriores.

Ciclo de Vida de uma Aplicação de Bases de Dados

• Recolha e análise de requisitos
• Desenho da base de dados
• Seleção do SGBD (opcional)
• Desenho da aplicação
• Prototipagem (opcional)
• Implementação
• Manutenção operacional.

Operações de Junção

• Theta Join: Produz uma tabela que satisfaz os tuplos do predicato F do produto cartesiano de R e S.
• Equijoin: Produz uma relação que contém tuplos que satisfaçam o predicato de F (que contém comparações equivalentes) do produto cartesiano de R e S.
• Natural Join: É um equijoin da relação R e S sobre todos os atributos em comum. Uma ocorrência de atributos em comum é eliminada.
• Outer Join: Um join em que tuplos de R que não têm valores iguais aos de S são também apresentados no resultado final.
• Semijoin: Produz uma relação em que contém os tuplos de R que participam no join de R com S a satisfazer o predicato de F.

Anomalias de Atualização

Os tipos de anomalias de atualização são:

• Inserção: inserir funcionária, num escritório não existente.
• Remoções: apagar funcionário único num escritório e apagar esse escritório também, tudo o que estiver associado a esse escritório será perdido/inconsistente.
• Modificações: ter informação duplicada e apenas actualizar parte dessa informação, não actualizando toda a informação duplicada, o que vai criar inconsistência de dados.

Arquitetura de Referência para SGBDs Distribuídos vs. ANSI/SPARC

Dada a diversidade, não existe uma arquitetura equivalente à arquitetura de 3 níveis ANSI/SPARC. A arquitetura de referência consiste em:

• Conjunto de esquemas globais externos
• Esquema global conceptual (GCS)
• Esquema de fragmentação e de alocação
• Conjunto de esquemas para cada SGBD local em conformidade com os 3 níveis ANSI/SPARC

Alguns níveis podem não aparecer, dependendo dos níveis de transparência suportados.

Objetivos da Arquitetura de Três Níveis ANSI/SPARC

• Todos os utilizadores devem poder aceder aos mesmos dados.
• A vista de um utilizador não muda com alterações feitas noutras vistas.
• Os utilizadores não precisam saber pormenores sobre o armazenamento físico da base de dados.
• As alterações no armazenamento físico não devem afectar a estrutura interna.
• O DBA pode alterar estrutura de armazenamento da base de dados sem que tal afecte as vistas dos utilizadores.

Data Warehouse

Data Mart vs. Data Warehouse

Um Data Mart é um subconjunto de um Data Warehouse que suporta os requisitos de um determinado departamento ou funções de negócio.

Razões para a criação de um Data Mart:

• Melhorar o tempo de resposta aos utilizadores finais através da redução do volume de dados que precisam de aceder.
• Disponibilizar os dados devidamente estruturados como foram especificados nos requisitos das ferramentas dos utilizadores finais.
• Construir um Data Mart é mais simples que construir um Data Warehouse.
• O custo de implementação de um Data Mart é normalmente inferior ao custo necessário para a criação de um Data Warehouse.
• Potenciais utilizadores de um Data Mart são mais facilmente definidos e podem ser mais facilmente descobertos de forma a obter maior suporte à criação de um projecto de um Data Mart ao invés de um projecto de um Data Warehouse.

Arquitetura Cliente-Servidor (2 Níveis vs. 3 Níveis)

A arquitetura cliente-servidor refere-se à maneira como componentes de software interagem. Existe um cliente que faz um pedido de informação e o servidor responde a esse pedido. No modelo de dois-níveis, o cliente trata da aplicação e do processamento, e o servidor trata das funções da base de dados. Na web o modelo de dois-níveis é substituído pelo modelo de três-níveis, este modelo consiste no interface do utilizador (client), processamento de dados (application server) e a base de dados (database server). O modelo de três-níveis pode ser facilmente estendido, com cada extensão adicionada maior flexibilidade e escalabilidade é obtida.

Propriedades das Relações no Modelo Relacional

• O nome da relação é distinto do nome de todas as outras relações do mesmo esquema relacional.
• Valores de um atributo são todos do mesmo domínio.
• Cada célula de uma relação contém exatamente um único valor.
• Cada atributo tem um nome distinto.
• Cada tuplo é distinto, não existem tuplos duplicados.
• A ordem dos atributos não tem qualquer significado.
• A ordem dos tuplos não tem qualquer significado, teoricamente porque por vezes interessa apresentar os tuplos ordenados no caso de uma consulta à base de dados.

Vista (View) vs. Relação Base

Uma visão no modelo relacional é uma relação virtual ou derivada que é criado dinamicamente a partir da relação de base subjacente(s), quando necessário. Vistas proporcionam segurança e permitem que cada vista seja personalizada de acordo com o utilizador. Nem todas as vistas podem ser actualizáveis.

Triggers de Bases de Dados

Um trigger “dispara” uma ação ou conjunto de ações que devem ser realizadas quando algum evento ocorre na aplicação. As vantagens são: eliminação de código redundante, simplificar modificações, aumento de segurança, melhoramento da integridade, melhoramento do poder de processamento, boa integração com a arquitetura cliente-servidor. As desvantagens são: overhead de performance, efeito de cascata, não podem ser agendados e não podem ser partilhados entre diferentes implementações de DBMS.

Arquitetura Típica de um Data Warehouse

A arquitetura típica de um Data Warehouse é composta por:

• Operational data (ou Operational data store): os dados do data warehouse são fornecidos por operações de dados do mainframe, dados de outras bases de dados, dados privados de outros servidores e fontes externas.
• ETL Manager (aka Load Manager): trata de todas as operações de inserção de dados no data warehouse.
• Warehouse Manager: trata de todas as tarefas associadas à gestão de dados no warehouse.
• Query Manager: trata de gerir todas as operações de query’s provenientes dos utilizadores.
• Detailed Data: armazena todos os dados detalhados no esquema da base de dados.
• Lightly and Highly Summarized Data: armazena todos os dados gerados pelo warehouse Manager, pouco e muito resumidos.
• End-User Access Tools: o principal propósito para uma data warehouse é ajudar com base na informação disponível a tomar uma decisão de negocio.
• Metadata: área onde é armazenada todos as definições de dados utilizados por todos os processos na warehouse.
• Archive/Backup Data: área onde é armazenada toda a informação detalhada e resumida para backup.