Apostila de Banco de Dados e SQL

Apostila de Banco de Dados e SQL

(Parte 3 de 8)

Álvaro Maurício

Cláudio

Registro de Alunos

O exemplo anterior representa uma instância de connjunto, no caso Disciplinas (Tópicos Avançados) e seus alunos (no caso Álvaro, Amorim e Cláudio).

Banco de Dados Orientados ao Objeto

Representam os dados como coleções que obedecem propriedades. São modelos geralmente conceituais dispondo de pouquíssimas aplicações reais. Neste Modelo não seria interessante a existência de uma tabela de funcionários e dentro dela alguma referência para cada registro, de forma a podermos saber onde (em que departamento) o funcionário está alocado. Um conjunto de regras disponibilizaria em separado os funcionários da fábrica, que no entanto estariam agrupados aos demais, para o sistema de folha de pagamento.

Banco de Dados Universal

Usa fortemente o conceito dos bancos de dados relacionais (ainda a serem vistos), no que concerne ao tratamento da informação dita caracter e muito do Modelo Orientado ao Objeto, no tocante ao tratamento de Imagens e Sons. É um dos assuntos top do momento, e será alvo de pesquisas na disciplina Tópicos Avançados - Atualidades, não sendo objeto imediato de nossa matéria.

Banco de Dados Relacional

O Modelo de Dados relacional representa os dados contidos em um Banco de Dados através de relações. Estas relações contém informações sobre as entidades representadas e seus relacionamentos. O Modelo Relacional, é claramente baseado no conceito de matrizes, onde as chamadas linhas (das matrizes) seriam os registros e as colunas (das matrizes) seriam os campos. Os nomes das tabelas e dos campos são de fundamental importância para nossa compreensão entre o que estamos armazenando, onde estamos armazenando e qual a relação existente entre os dados armazenados.

Cada linha de nossa relação será chamada de TUPLA e cada coluna de nossa relação será chamada de ATRIBUTO. O conjunto de valores passíveis de serem assumidos por um atribruto, será intitulado de DOMÍNIO.

Estes tópicos serão estudados cuidadosamente na disciplina Análise de Sistemas, que se incumbirá de apresentar cuidadosamente regras e normas para elaboração destes modelos.

Em nosso curso, voltado à construção prática dos Bancos de Dados, e não de sua construção teóricas, apenas citaremos os aspectos básicos da construção teórica, de forma a facilitar ao estudante o relacionamento que existe entre Análise de Sistemas e Banco de Dados (uma das sub-disciplinas de Tópicos Avançados).

O domínio consiste de um grupo de valores atômicos a partir dos quais um ou mais atributos retiram seus valores reais. Assim sendo Rio de Janeiro, Paraná e Pará são estados válidos para o Brasil, enquanto que Corrientes não é um estado válido (pertence a Argentina e não ao Brasil).

O esquema de uma relação, nada mais são que os campos (colunas) existentes em uma tabela. Já a instância da relação consiste no conjunto de valores que cada atributo assume em um determinado instante. Portanto, os dados armazenados no Banco de Dados, são formados pelas instâncias das relações.

As relações não podem ser duplicadas (não podem existir dois estados do Pará, no conjunto de estados brasileiros, por exemplo), a ordem de entrada de dados no Banco de Dados não deverá ter qualquer importância para as relações, no que concerne ao seu tratamento. Os atributos deverão ser atômicos, isto é, não são íveis de novas divisões.

Chamaremos de Chave Primária ao Atributo que definir um resgistro, dentre uma coleção de registros. Chave Secundária (Terceária, etc), serão chaves que possibilitarão pesquisas ou ordenações alternativas, ou seja, diferentes da ordem criada a partir da chave primária ou da ordenação natural (física) da tabela. Chamaremos de Chave Composta, aquela chave que contém mais de um atributo (Por exemplo um cadastro ordenado alfabéticamente por Estado, Cidade e Nome do Cliente, necessitaria de uma chave composta que contivesse estes três atributos). Chamaremos de Chave Estrangeira, aquela chave que permitir a ligação lógica entre uma tabela (onde ela se encontra) com outra na qual ele é chave primária.

Exemplo :

CidadeEstado
*CidCodi*EstCodi
CidNomeEstNome

EstCodi (E)

CidCodi e EstCodi, são chaves primárias respectivamente das tabelas Cidade e Estado, enquanto EstCodi é chave estrangeira na tabela de cidades. É precisamente por este campo (atributo, ou coluna), que será estabelecida a relação entre as tabelas Cidade-->Estado.

Forma Normal

A disciplina Análise de Sistemas abordará detalhadamente esta importante metodologia para definição das tabelas que irão compor a base de dados, que aqui apenas citaremos.

Primeira Forma Normal: Uma relação se encontra na primeira forma normal se todos os domínios de atributos possuem apenas valores atômicos (simples e indivisíveis), e que os valores de cada atributo na tupla seja um valor simples. Assim sendo todos os atributos compostos devem ser divididos em atributos atômicos.

Segunda Forma Normal: Uma relação se encontra na segunda forma normal quando estiver na primeira forma normal e todos os atributos que não participam da chave primária são dependentes desta. Assim devemos verificar se todos os atributos são dependentes da chave primária e retirar-se da relação todos os atributos de um grupo não dependente que dará origem a uma nova relação, que conterá esse atributo como não chave. Desta maneira, na segunda forma normal evita inconsistências devido a duplicidades.

Terceira Forma Normal: Uma relação estará na terceira forma normal, quando estiver na primeira forma norma e todos os atributos que não participam da chave primária são dependentes desta porém não transitivos. Assim devemos verificar se existe um atributo que não depende diretamente da chave, retirá-lo criando uma nova relação que conterá esse grupo de atributos, e defina com a chave, os atributos dos quais esse grupo depende diretamente.

O processo de normalização deve ser aplicado em uma relação por vez, pois durante o processo de normalização vamos obtendo quebras, e por conseguinte, novas relações. No momento em que o sistema estiver satisfatório, do ponto de vista do analista, este processo iterativo é interrompido. De fato existem literaturas indicando quarta, quinta formas normais, que não nos parece tão importante, nem mesmo academicamente.

A normalização para formas apoiadas em dependências funcionais evita inconsistências, usando para isso a própria construção da Base. Se a mesma consistência for passível de ser garantida pelo aplicativo, a normalização pode ser evitada com ganhos reais no desempenho das pesquisas. No caso da consistência não ser importante, também podemos não normalizar totalmente uma Base de Dados.

Exemplo: Normalizar os seguintes atributos:

Nº do Pedido, Nome do Cliente, Nome dos Produtos, Quantidades

Nº do Pedido, Código do Cliente, Nome dos Produtos, Quantidades Código do Cliente, Nome do Cliente

Nº do Pedido, Código do Cliente, Código dos Produtos, Quantidades Código do Cliente, Nome do Cliente Código do Produto, Nome do Produto

Nº do Pedido, Código do Cliente Código do Cliente, Nome do Cliente Código do Produto, Nome do Produto Nº do Pedido, Código do Produto, Quantidade

CliCodiPedNume PedNume ProCodi
CliNomeCliCodi ProCodi ProNome

Cliente Pedido Item Produto IteQtde

O esquema apresentado anteriormente poderia ser inferido diretamente, usando metodologia tipicamente apresentada em Organização e Método. Se soubermos, por hipótese, que um profissional habilitado desenhou o pedido da empresa, e que esta o está utilizando com sucesso, poderíamos basear nosso modelo de dados neste formulário. Devemos notar que muitos Analistas de Sistemas não adotam estes procedimentos, por preferirem os métodos convencionais para elaboração do Modelo de Dados.

Considerando qualquer formulário de pedidos podemos notar que o

Número do Pedido geralmente tem destaque e sempre é único, ou seja encontramos nossa chave primária da

Tabela de Pedidos , como sabemos que um cliente pode fazer mais de uma compra, achamos nossa

Tabela de Clientes, que pode ter um

Código , portanto achamos sua chave primária, que por conseguinte será a chave estrangeira da Tabela de Pedidos.

Um ponto delicado, diz respeito aos itens do pedido, que formam geralmente um espaço destacado dentro do formulário de pedidos. Geralmente, e este é um dos casos, estas áreas em separado dos formulários darão origem a tabelas filhas, como é o caso típico das duplicatas em notas fiscais, ou dos dependentes na ficha de funcionários. Portanto achamos nossa

Tabela de Itens que será ligada à Tabela de Pedidos através do

Número do Pedido, que é ao mesmo tempo chave primária e chave estrangeira para a Tabela de Itens.

Finalmente podemos perceber, que da mesma forma como os clientes se repetem em relação a Tabela de Pedidos, os produtos podem se repetir na tabela de itens (observe que não obstante não termos nenhum pedido com o mesmo item grafado duas vezes, este item pode ser adquirido em outro pedido). Assim descobrimos nossa quarta tabela, a Tabela de

Produtos e a chave primária Código do Produto.

SQL - Structured Query Language

Introdução

Quando os Bancos de Dados Relacionais estavam sendo desenvolvidos, foram criadas linguagens destinadas à sua manipulação. O Departamento de Pesquisas da IBM, desenvolveu a SQL como forma de interface para o sistema de BD relacional denominado SYSTEM R, início dos anos 70. Em 1986 o American National Standard Institute ( ANSI ), publicou um padrão SQL.

A SQL estabeleceu-se como linguagem padrão de Banco de Dados Relacional.

SQL apresenta uma série de comandos que permitem a definição dos dados, chamada de DDL (Data Definition Language), composta entre outros pelos comandos Create, que é destinado a criação do Banco de Dados, das Tabelas que o compõe, além das relações existentes entre as tabelas. Como exemplo de comandos da classe DDL temos os comandos Create, Alter e Drop.

Os comandos da série DML (Data Manipulation Language), destinados a consultas, inserções, exclusões e alterações em um ou mais registros de uma ou mais tabelas de maneira simultânea. Como exemplo de comandos da classe DML temos os comandos Select, Insert, Update e Delete.

(Parte 3 de 8)

Comentários