SEFA

Prof. Kleper Gomes

NOES SOBRE BANCO DE DADOS.

Um BD (Banco de dados) uma srie de

informaes armazenadas de forma eficiente, ou seja, ao se falar em um banco de dados devemos sempre lembrar de um conjunto de dados que sero guardados em um programa. o arquivo fsico de dados armazenado em meio eletrnico

DADO x INFORMAO

DADO X CONHECIMENTO X INFORMAO

PRINCIPAIS BANCOS DE DADOS

1.

Quanto ao nmero de usurios: Monousurios ou Multiusurios. outro usurio espera para utilizar o DB.

Monousurio quer dizer que apenas um usurio por vez, ou seja, quando estiver usando o BD,

Multiusurio da suporte a vrios usurios simultaneamente. 2.

Quanto localizao de dados: Centralizado ou Distribudo. centralizado.

Por exemplo, um banco que d suporte a dados localizados em um nico local chamado de BD

J um que d suporte a dados distribudos por vrios locais diferentes chamado de BD

distribudos.
3.

Quanto utilizao de dados: Banco de dados Operacional, DataWarehouse e Banco de

dados em XML, ......

Operacional quando so direcionados a transaes transacionais ou de produo, transaes que

devem refletir operaes dirias fundamentais de uma empresa.

Data Warehouses armazm de dados, focam na armazenagem dos dados utilizados para gerar

informaes necessrias tomada de decises tticas e estratgicas.

A Linguagem de Marcao Extensvel (XML), usada para representar e manipular elementos de

dados em formato textual.

SGBD Sistema gerencial de banco de dados

Ao se falar neste tema devemos fazer uma separao entre dados e regras de armazenamentos dividindo o BD em duas camadas: BD e SGBD. Assim temos os dados (somente as informaes) armazenados separadamente das regras de armazenamento.

IMPORTANTE SABER SOBRE SGBD

NIVEIS DE ABSTRAO

BANCO DE DADOS RELACIONAL

No modelo de dados relacional os dados so organizados e agrupados em

tabelas (relacionais). Estas tabelas guardam estes dados e pode possuir referncia a outra tabela (alguns autores usam o termo entidade). Assim o banco todo no passa de uma srie de tabelas que se referenciam (sempre que isto for necessrio, claro).

ENTIDADES OU TABELAS RELACIONAIS

As tabelas ou entidades so conceitos de coisas, que podem ser fsicas ou no, ou

seja, podemos ter um uma tabela de um banco de dados de vdeo-locadora denominada cliente que representa os clientes da empresa, assim a tabela o modelo abstrato de uma coisa fsica, real. Em contra partida podemos tambm ter uma tabela de nome locao que armazena o registro de locaes dos cientes. Agora temos uma entidade abstrada de uma coisa no fsica, pois a locao na verdade o ato de o cliente locar um ou vrios ttulos.

No exemplo acima temos duas tabelas que necessitam de uma ligao. Perceba que para se fazer uma consulta de informaes de um certo empregado, necessrio ter os dados do Empregado. Logo os dados do Empregado esto na tabela Empregado que est relacionado tabela Empregado_Telefones . Isto um exemplo de banco de dados relacional.

ESTRUTURA DE UMA TABELA OU ENTIDADE

Vimos que uma tabela a representao abstrata de um conjunto de dados (coisa). Uma tabela formada de um conjunto de campos ou colunas. Um campo a definio mais a precisa de um dado (nome, endereo, data do cadastro, etc.). O SGBD tem a capacidade de impor uma camada de regras para o correto preenchimento de valores a um campo. So as regras de validao ou consistncia. Os dados so cadastrados em tabelas em linhas onde cada linha representa um conjunto nico de dados. As linhas tambm so denominadas de registros ou tuplas.

IDENTIFICADORES DE REGISTROS (CHAVES)

So identificadores de registros. As chaves de uma tabela so responsveis por manter a integridade de dados de uma tabela e referenciar os relacionamentos entre estas entidades. A chave primria o identificador de registros de uma tabela. Ela de conter um valor nico e obrigatrio. Pode ser formada por um ou mais campos (neste caso chama-se chave primria composta).

CHAVE PRIMRIA

CHAVE ESTRANGEIRA
A chave estrangeira nada mais que a referncia a uma

outra tabela (relacionamento).

 Observe que as locaes do cliente 102 so identificadas em uma coluna Cdigo do Cliente da Tabela Locao, ou seja, a referncia da locao nada mais que a chave estrangeira. O Conceito de chave primria e chave estrangeira de fundamental importncia para a implementao de um banco de dados relacional.

MODELOS DE BANCO DE DADOS

So representaes grficas de um banco de dados, representado de duas formas: 1. Modelo Lgico: O Modelo lgico costuma ser menos utilizado por sua dependncia ao tipo de SGBD representado. Ou seja, existe diferena entre modelos de uma estrutura de banco relacional e uma estrutura de banco orientado a objetos ou em rede. 2. O Modelo conceitual faz uma representao grfica do esquema de dados utilizando um modelo grfico chamado de Modelo Entidade Relacionamento ou MER, alguns autores ainda utilizam o termo Diagrama Entidade Relacionamento ou DER.

 Veja

que as chaves primrias das entidades tem uma

representao

diferenciada

()

relacionamento

foi

representado por uma ligao em forma de linha e um losangolo. Na ponta de ligao entre as entidades temos a letra n na entidade Cliente e o nmero 1 na entidade Locao. Isto representa a cardinalidade, ou o tipo de relao entre as tabelas. Vamos abordar mais a frente este contedo.

MODELAGEM DE DADOS
Forma de modelar um projeto de dados. Entendendo os smbolos de um MER: Dentro de um diagrama MER temos vrios smbolos grficos. 1. Entidades (Tabelas): As entidades so representadas com um retngulo.

2.

Atributos (Campos): So representados por um oval, sendo que a chave primria tem o oval totalmente preenchido.

1.

Relacionamentos: Os relacionamentos so apresentados por uma linha que liga as entidades, nesta linha apresentado outro smbolo: um losangolo que representa a ao daquele relacionamento.

TIPOS DE RELACIONAMENTO (CARDINALIDADE)

A cardinalidade representa como os objetos de uma certa tabela de um SGBD se relaciona com certos objetos de uma outra tabela. A. Cardinalidade mnima: A cardinalidade mnima define se o relacionamento obrigatrio entre as entidades. Os smbolos que definem este relacionamento so: 1 ou I - Quando existe a obrigatoriedade de um vnculo entre as entidades. - Quando no existe a obrigatoriedade de vinculo entre as entidades. B. Cardinalidade mxima: A cardinalidade mxima representa a quantidade mxima de transaes (relacionamentos) que so permitidos entre entidades relacionadas.

Vamos entender melhor estes smbolos analisando os diagrama abaixo:

Cardinalidade mnima
Na relao acima, Cliente Dependente a cardinalidade mnima no impe o cadastramento

obrigatrio de um dependente ao se cadastrar um cliente, j que a cardinalidade definida com o smbolo (zero).
Na relao Dependente Cliente a cardinalidade mnima j impe a existncia obrigatria de

um cliente para se cadastrar um dependente, uma vez que a cardinalidade foi definida com o smbolo I (um).

Cardinalidade mxima

No relacionamento acima, Cliente Dependente ilimitada (ou n). Ou seja, um cliente pode possuir n (vrios) dependentes.

 As cardinalidades mnima e mxima podem ser utilizadas em conjunto no mesmo

relacionamento. Veja abaixo:

A figura acima representa um relacionamento com as duas cardinalidades em conjunto.

No relacionamento Dependente Cliente exige um cliente para o cadastramento

de um dependente (cardinalidade mnima); contudo o relacionamento Cliente Dependente nos diz que a existncia de um dependente para o cadastramento de um cliente no obrigatrio (cardinalidade mnima novamente) e sabemos que um cliente pode cadastrar vrios (n) dependentes (cardinalidade mxima).
O conceito deste tipo de cardinalidade do tipo 1:N ou Um para Muitos.

CARDINALIDADE UM PARA UM (1:1)

A cardinalidade um para um ou 1:1 a imposio do relacionamento de

um nico registro entre duas entidades relacionadas. um banco de dados que representa um condomnio residencial. Neste condomnio, temos a seguinte situao os condminos guardam seus veculos na garagem privativa do condomnio, contudo cada condomnio tem o direito a uma vaga de garagem. Assim poderamos representar (abstrair) estas informaes em um MER da seguinte maneira.
Um condmino possui somente uma vaga e uma vaga pertence a

somente um condmino.

CARDINALIDADE MUITOS PARA MUITOS (N:N)

N:N

acontece quando duas entidades possuem vrios registros se relacionando com vrios registros.

Um cliente pode locar vrios ttulos e um mesmo ttulo

pode ser locado por clientes. Este relacionamento pode ser representado da seguinte maneira acima.

Veja agora o diagrama a seguir que

mostra o mesmo relacionamento j no modelo fsico de dados.

NORMALIZAO DE DADOS
Forma de impor limitaes ao BD. 1. Primeira forma normal (1NF). Atributos de uma entidade que tem caractersticas de armazenamento de vrios valores, ou seja, campos podero assumir mais de um valor para um mesmo registro.

A entidade cliente possui os seguintes atributos: Cdigo, Nome, CPF, RG e Dependente.

Para aplicar a 1NF nos atributos basta verificar se o mesmo dever ter mais de um valor
para o mesmo registro.

Dica: Faa uma pergunta para o atributo utilizando o nome e propsito da entidade.
Pergunta: Um cliente pode ter mais de um nome? Resposta: No, o atributo no multi valorado. Pergunta: Um cliente pode ter mais de um CPF? Resposta: No, o atributo no multi valorado. Pergunta: Um cliente pode ter mais de um RG? Resposta: No, o atributo no multi valorado. Pergunta: Um cliente pode ter mais de um dependente? Resposta: Sim, o atributo deve gerar uma nova entidade.
Assim teremos o seguinte diagrama aps a aplicao da 1NF:

SEGUNDA FORMA NORMAL (2NF)

Fator de dependncia, ou seja, podemos dizer que todo atributo de uma

entidade que no depender exclusivamente da chave primria, deve gerar uma nova entidade. Vamos a pratica para entender melhor, vamos imaginar um sistema que gerencia associados de um determinado plano de sade. Veja o diagrama a seguir: Temos o seguintes atributos: Codigo, Nome, CPF, RG, Numero_contrato e Dt_vencimento_contrato. Para identificar quais destes atributos esto na 2NF devemos verificar se o atributo dependente do Cliente para isso basta verificar se o atributo se alterado descaracteriza o cliente, por exemplo, se trocarmos o atributo Nome o cliente ser descaracterizado? Sim, o cliente ficaria totalmente descaracterizado, se trocarmos o CPF e o RG? Teramos o mesmo resultado, pois estes atributos provam que so dependentes da chave primria.

 Agora vamos verificar o atributo Dt_vencimento_contrato, se

trocarmos o valor deste atributo o cliente ser descaracterizado? No, ser o mesmo cliente. J identificamos que este campo pode no ser dependente direto da chave primria. Vamos analisar melhor, Dt_vencimento_contrato depende da chave primria ou do atributo Numero_contrato? Este atributo depende no da chave primria, mas sim de outro atributo. A est um campo onde devemos aplicar a 2NF. Com a 2NF aplicada teramos o seguinte diagrama:

Ao aplicar a 2NF todos os atributos independentes devem ir para uma nova entidade relacionada a entidade de origem. No diagrama acima percebemos que o atributo Dt_vencimento_contrato gerou a entidade Contrato.

TERCEIRA FORMA NORMAL (3NF)

Principio de transitividade, modelo relacional mas utilizado no mercado, pois

ele permite atravs de seus relacionamentos transitarem de uma entidade a outra sem a necessidade de se recriar determinado atributo.
Vamos entender melhor a 3NF. Veja o diagrama ao lado: Vimos que existe uma relao entre as entidades Cliente, Cidade e Pedido. Vamos imaginar os seguintes atributos na entidade Cliente e cidade:

1. Cliente: Codigo, Nome, UF, codigo_cidade, nome_cidade 2. Cidade: Codigo e Nome 3. Pedido: Numero, Data, codigo_cliente, codigo_cidade

Analisando melhor os atributos vemos que Pedido tem relao com Cliente e com Cidade, mas a relao com Cidade desnecessria, pois atravs da relao da entidade Pedido com a entidade Cliente podemos chegar (transitividade) at a entidade Cidade.

EXPLICANDO MELHOR:
Teramos o seguinte fluxo: Pedido -> Cliente ->

Cidade, ou seja o cliente seria a ponte para se chegar a Cidade. Assim, o relacionamento Pedido - Cidade deve ser eliminada. Este o principio da 3NF, toda dependncia no transitiva deve ser eliminada.